From: Jonathan Derrick <jonathan.derrick@linux.dev>
To: david.e.box@linux.intel.com, Bjorn Helgaas <helgaas@kernel.org>
Cc: nirmal.patel@linux.intel.com, lorenzo.pieralisi@arm.com,
hch@infradead.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, michael.a.bottini@intel.com,
rafael@kernel.org, me@adhityamohan.in, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V7 3/4] PCI: vmd: Add vmd_device_data
Date: Fri, 28 Oct 2022 16:14:31 -0500 [thread overview]
Message-ID: <a7629245-850c-e854-9ad9-1e83f971e867@linux.dev> (raw)
In-Reply-To: <85336561282c1c444501b799096e9c94b23722e0.camel@linux.intel.com>
On 10/28/2022 3:22 PM, David E. Box wrote:
> On Fri, 2022-10-28 at 14:40 -0500, Bjorn Helgaas wrote:
>> On Fri, Oct 28, 2022 at 02:18:48PM -0500, Jonathan Derrick wrote:
>>> On 10/28/2022 2:13 PM, Bjorn Helgaas wrote:
>>>> On Mon, Oct 24, 2022 at 05:44:10PM -0700, David E. Box wrote:
>>>>> Add vmd_device_data to allow adding additional info for driver data.
>>>>> {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_VMD_9A0B),
>>>>> - .driver_data = VMD_FEAT_HAS_MEMBAR_SHADOW_VSCAP |
>>>>> - VMD_FEAT_HAS_BUS_RESTRICTIONS |
>>>>> - VMD_FEAT_OFFSET_FIRST_VECTOR,},
>>>>> + (kernel_ulong_t)&(struct vmd_device_data) {
>>>>> + .features = VMD_FEAT_HAS_MEMBAR_SHADOW_VSCAP |
>>>>> + VMD_FEAT_HAS_BUS_RESTRICTIONS |
>>>>> + VMD_FEAT_OFFSET_FIRST_VECTOR,
>>>>> + },
>>>>> + },
>>>>
>>>> It looks like these devices come in families where several device IDs
>>>> share the same features. I think this would be more readable if you
>>>> defined each family outside this table and simply referenced the
>>>> family here. E.g., you could do something like:
>>>>
>>>> static struct vmd_device_data vmd_v1 = {
>>>> .features = VMD_FEAT_HAS_MEMBAR_SHADOW_VSCAP |
>>>> VMD_FEAT_HAS_BUS_RESTRICTIONS |
>>>> VMD_FEAT_OFFSET_FIRST_VECTOR,
>>>> };
>>>
>>> I seem to recall it being similar to this in one of the previous revisions
>>> It's fine with me either way
>>
>> Indeed it was:
>> https://lore.kernel.org/r/366a9602-555f-7a1b-a8db-bbcbf84b7b08@linux.dev
>> I'd forgotten that.
>>
>> At the time there were four devices (0x467f 0x4c3d 0xa77f 0x9a0b)
>> that used the 467f data. The current series adds two more (0x7d0b
>> 0x0ad0b). Maybe the "vmd_467f_data" name could have been more
>> descriptive, but the code was definitely shorter:
>>
>> + { PCI_VDEVICE(INTEL, 0x467f), (kernel_ulong_t)&vmd_467f_data },
>> + { PCI_VDEVICE(INTEL, 0x4c3d), (kernel_ulong_t)&vmd_467f_data },
>> + { PCI_VDEVICE(INTEL, 0xa77f), (kernel_ulong_t)&vmd_467f_data },
>> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_VMD_9A0B),
>> (kernel_ulong_t)&vmd_467f_data },
>
> I prefer this too but don't know what's the best name. Could just be by the
> platform that started this grouping, e.g. vmd_tgl_data for Tiger Lake. What do
> you think Jonathan?
>
> David
vmd_client_data ? (meaning product class; client vs enterprise)
>
>>
>> I do wish pci_device_id.driver_data were a void pointer, as it is for
>> of_device_id, which makes it much more natural to express [1], but
>> that ship has long sailed.
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-kirin.c?id=v6.0#n768
>>
>>>> {PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_VMD_9A0B),
>>>> .driver_data = (kernel_ulong_t) &vmd_v1,
>>>>
>>>> Then you can add VMD_FEAT_BIOS_PM_QUIRK and the .ltr value in one place
>>>> instead of repeating it a half dozen times.
>>>>
>>>>> {0,}
>>>>> };
>>>>> MODULE_DEVICE_TABLE(pci, vmd_ids);
>>>>> --
>>>>> 2.25.1
>>>>>
>
next prev parent reply other threads:[~2022-10-28 21:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 0:44 [PATCH V7 0/4] PCI: vmd: Enable PCIe ASPM and LTR on select hardware David E. Box
2022-10-25 0:44 ` [PATCH V7 1/4] PCI/ASPM: Add pci_enable_link_state() David E. Box
2022-10-25 0:44 ` [PATCH V7 2/4] PCI: vmd: Use PCI_VDEVICE in device list David E. Box
2022-10-25 0:44 ` [PATCH V7 3/4] PCI: vmd: Add vmd_device_data David E. Box
2022-10-28 19:13 ` Bjorn Helgaas
2022-10-28 19:18 ` Jonathan Derrick
2022-10-28 19:40 ` Bjorn Helgaas
2022-10-28 20:22 ` David E. Box
2022-10-28 21:14 ` Jonathan Derrick [this message]
2022-10-28 21:24 ` Patel, Nirmal
2022-10-31 7:04 ` Christoph Hellwig
2022-10-31 15:40 ` David E. Box
2022-10-25 0:44 ` [PATCH V7 4/4] PCI: vmd: Add quirk to configure PCIe ASPM and LTR David E. Box
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7629245-850c-e854-9ad9-1e83f971e867@linux.dev \
--to=jonathan.derrick@linux.dev \
--cc=bhelgaas@google.com \
--cc=david.e.box@linux.intel.com \
--cc=hch@infradead.org \
--cc=helgaas@kernel.org \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=me@adhityamohan.in \
--cc=michael.a.bottini@intel.com \
--cc=nirmal.patel@linux.intel.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).