[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC KERNEL PATCH v3 3/3] PCI/sysfs: Add gsi sysfs for pci_dev
On 2023/12/12 17:18, Roger Pau Monné wrote: > On Tue, Dec 12, 2023 at 06:34:27AM +0000, Chen, Jiqian wrote: >> >> On 2023/12/12 01:57, Roger Pau Monné wrote: >>> On Mon, Dec 11, 2023 at 12:15:19AM +0800, Jiqian Chen wrote: >>>> There is a need for some scenarios to use gsi sysfs. >>>> For example, when xen passthrough a device to dumU, it will >>>> use gsi to map pirq, but currently userspace can't get gsi >>>> number. >>>> So, add gsi sysfs for that and for other potential scenarios. >>>> >>>> Co-developed-by: Huang Rui <ray.huang@xxxxxxx> >>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@xxxxxxx> >>>> --- >>>> drivers/acpi/pci_irq.c | 1 + >>>> drivers/pci/pci-sysfs.c | 11 +++++++++++ >>>> include/linux/pci.h | 2 ++ >>>> 3 files changed, 14 insertions(+) >>>> >>>> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c >>>> index 630fe0a34bc6..739a58755df2 100644 >>>> --- a/drivers/acpi/pci_irq.c >>>> +++ b/drivers/acpi/pci_irq.c >>>> @@ -449,6 +449,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev) >>>> kfree(entry); >>>> return 0; >>>> } >>>> + dev->gsi = gsi; >>> >>> It would be better if the gsi if fetched without requiring calling >>> acpi_pci_irq_enable(), as the gsi doesn't require the interrupt to be >>> enabled. The gsi is known at boot time and won't change for the >>> lifetime of the device. >> Do you have any suggest places to do this? > > I'm not an expert on this, but drivers/pci/pci-sysfs.c would seem like > a better place, together with the rest of the resources. I'm not familiar with this too. But it seems pci-sysfs.c only creates sysfs node and supports the read/write method without initializing the values. If want to initialize the value of gsi here. An approach to initialize it is to call acpi_pci_irq_lookup to get gsi number when the first time it is read? > > Maybe my understanding is incorrect, but given the suggested placement > in acpi_pci_irq_enable() I think the device would need to bind the > interrupt in order for the gsi node to appear on sysfs? No, gsi sysfs has existed there, in acpi_pci_irq_enable is to initialize the value of gsi. > > Would the current approach work if the device is assigned to pciback > on the kernel command line, and thus never owned by any driver in > dom0? If assigned to pciback, I think pciback will enable the device, and then acpi_pci_irq_enable will be called, and then the gsi will be initialized. So, current can work. > >>> >>>> >>>> rc = acpi_register_gsi(&dev->dev, gsi, triggering, polarity); >>>> if (rc < 0) { >>>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c >>>> index 2321fdfefd7d..c51df88d079e 100644 >>>> --- a/drivers/pci/pci-sysfs.c >>>> +++ b/drivers/pci/pci-sysfs.c >>>> @@ -71,6 +71,16 @@ static ssize_t irq_show(struct device *dev, >>>> } >>>> static DEVICE_ATTR_RO(irq); >>>> >>>> +static ssize_t gsi_show(struct device *dev, >>>> + struct device_attribute *attr, >>>> + char *buf) >>>> +{ >>>> + struct pci_dev *pdev = to_pci_dev(dev); >>> >>> const >> Do you mean "const struct pci_dev *pdev = to_pci_dev(dev);" ? > > Yup. > > Thanks, Roger. -- Best regards, Jiqian Chen.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |