[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL1PR12MB584973D751EB57C3DE766AEEE78DA@BL1PR12MB5849.namprd12.prod.outlook.com>
Date: Wed, 13 Dec 2023 03:31:21 +0000
From: "Chen, Jiqian" <Jiqian.Chen@....com>
To: Roger Pau Monné <roger.pau@...rix.com>
CC: "Rafael J . Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
"Deucher, Alexander" <Alexander.Deucher@....com>,
"Koenig, Christian" <Christian.Koenig@....com>,
"Huang, Ray" <Ray.Huang@....com>,
"Chen, Jiqian" <Jiqian.Chen@....com>
Subject: 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@....com>
>>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@....com>
>>>> ---
>>>> 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.
Powered by blists - more mailing lists