Hi,
On 2023/6/10 01:52, Bjorn Helgaas wrote:
On Fri, Jun 09, 2023 at 09:37:02AM +0800, Sui Jingfeng wrote:
On 2023/6/9 01:32, Bjorn Helgaas wrote:
On Wed, Jun 07, 2023 at 06:55:49PM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng <suijingfeng@xxxxxxxxxxx>
This patch adds PCI driver support on top of what we already have. Take
the GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device
driver. There is only one GPU core for the GC1000 in the LS7A1000 and
LS2K1000. Therefore, component frameworks can be avoided.
+ {PCI_VENDOR_ID_LOONGSON, 0x7a15, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
+ {PCI_VENDOR_ID_LOONGSON, 0x7a05, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
PCI_VDEVICE()
This make it impossible to hook device-specific data in the future.
But currently there no device specific data associated with the
0x7a05 and 0x7a15,
so it's acceptable for now. Thanks.
Haha, ISTR having this conversation before, sorry for repeating it.
Indeed, it's fine as-is. But PCI_VDEVICE() actually *does* allow for
vendor-specific data because it doesn't include the data element,
which defaults to zero if you don't specify it.
So for example, drivers/net/ethernet/realtek/r8169_main.c has this:
{ PCI_VDEVICE(REALTEK, 0x8129) },
{ PCI_VDEVICE(REALTEK, 0x8136), RTL_CFG_NO_GBIT },
where 0x8129 has no driver_data (it defaults to zero), but 0x8136
does.
Yeah, I'm wrong.
PCI_VDEVICE macro end with two zero. (I thought it was three)
Thanks for the education.
With those lessons learned, I somewhat know how to create patch.
It should meet community's requirement before sending.
I'm too naive in the before.
Thanks a lot, really.
Bjorn
--
Jingfeng
