On Fri, Jun 21, 2024 at 05:45:05PM +0200, Andy Shevchenko wrote:
> On Thu, Jun 20, 2024 at 7:19 PM Herve Codina <herve.codina@xxxxxxxxxxx> wrote:
> > On Thu, 20 Jun 2024 18:43:09 +0200
> > Herve Codina <herve.codina@xxxxxxxxxxx> wrote:
> > > On Thu, 20 Jun 2024 18:07:16 +0200
> > > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > > > On Thu, Jun 20, 2024 at 5:56 PM Herve Codina <herve.codina@xxxxxxxxxxx> wrote:
> > > > > On Wed, 5 Jun 2024 23:24:43 +0300
> > > > > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > > > > > Mon, May 27, 2024 at 06:14:45PM +0200, Herve Codina kirjoitti:
> > > > > > > +static struct pci_device_id lan966x_pci_ids[] = {
> > > > > > > + { PCI_DEVICE(0x1055, 0x9660) },
> > > > > >
> > > > > > Don't you have VENDOR_ID defined somewhere?
> > > > >
> > > > > No and 0x1055 is taken by PCI_VENDOR_ID_EFAR in pci-ids.h
> > > > > but SMSC acquired EFAR late 1990's and MCHP acquired SMSC in 2012
> > > > > https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/microchip/lan743x_main.h#L851
> > > > >
> > > > > I will patch pci-ids.h to create:
> > > > > #define PCI_VENDOR_ID_SMSC PCI_VENDOR_ID_EFAR
> > > > > #define PCI_VENDOR_ID_MCHP PCI_VENDOR_ID_SMSC
> > > > > As part of this patch, I will update lan743x_main.h to remove its own #define
> > > > >
> > > > > And use PCI_VENDOR_ID_MCHP in this series.
> > > >
> > > > Okay, but I don't think (but I haven't checked) we have something like
> > > > this ever done there. In any case it's up to Bjorn how to implement
> > > > this.
> >
> > Right, I wait for Bjorn reply before changing anything.
>
> But we already have the vendor ID with the same value. Even if the
> company was acquired, the old ID still may be used. In that case an
> update on PCI IDs can go in a separate change justifying it. In any
> case, I would really want to hear from Bjorn on this and if nothing
> happens, to use the existing vendor ID for now to speed up the series
> to be reviewed/processed.
We have "#define PCI_VENDOR_ID_EFAR 0x1055" in pci_ids.h, but
https://pcisig.com/membership/member-companies?combine=1055 shows no
results, so it *looks* like EFAR/SMSC/MCHP are currently squatting on
that ID without it being officially assigned.
I think MCHP needs to register 0x1055 with the PCI-SIG
(administration@xxxxxxxxxx) if it wants to continue using it.
The vendor is responsible for managing the Device ID space, so this
registration includes the burden of tracking all the Device IDs that
were assigned by EFAR and SMSC and now MCHP so there are no conflicts.
I don't want to change the existing PCI_VENDOR_ID_EFAR, and I also
don't want to add a PCI_VENDOR_ID_MCHP for 0x1055 until that ID has
been registered with the PCI-SIG.
So I propose that you use PCI_VENDOR_ID_EFAR for now, and if/when MCHP
registers 0x1055 with PCI-SIG so it is unambiguously owned by MCHP, we
can add "#define PCI_VENDOR_ID_MCHP PCI_VENDOR_ID_EFAR" or similar.
As Andy points out, this would be a separate logical change in its own
patch.
Bjorn
