Hi Bjorn, and Herve,
Bill Mahany from Microchip has now been in contact with PCI-SIG, and
has been able to get confirmation that Vendor ID 0x1055 is still
belonging to Microchip even though this is not visible on their
webpage.
I have attached a snippet of the conversation.
I hope this settles the matter of the Vendor ID 0x1055.
Best Regards
Steen
=== Copied from the conversation ===
Hi Bill,
Thank you for your email. We can confirm VID 4181 (1055 Hex) is
Microchip’s. This is not listed on the website because we are only
able to list one VID per company.
Please feel free to contact us if you have any questions.
Best Regards,
PCI-SIG Administration
Main: 503-619-0569 | Fax: 503-644-6708
3855 SW 153rd Drive, Beaverton, OR 97003 USA
Email: administration@xxxxxxxxxx
www.pcisig.com | Connect with us on LinkedIn and Twitter @pci_sig
From: bill.mahany@xxxxxxxxxxxxx (administration)
<administration@xxxxxxxxxx>
Sent: Monday, June 24, 2024 11:07 AM
To: administration@xxxxxxxxxx
Subject: RE: vendor id missing from member companies list
Hello once again.
Please refer to the below. Could you please reverify that Microchip
Technology is still in control of 4181 (0x1055).
Apparently, the lack of a search result for 4181 (0x1055) at
https://pcisig.com/membership/member-companiesis
Is still causing issues in the Linux community -
https://lore.kernel.org/all/20240621184923.GA1398370@bhelgaas/
Thanks
Bill Mahany
On Mon, 2024-06-24 at 13:46 +0200, Steen Hegelund wrote:
> Hi Bjorn,
>
> I am not sure what went wrong here.
>
> I have seen that lspci lists 'Microchip / SMSC' for the 0x1055 Vendor
> ID value and as mentioned previously there has been a number of
> aquicisions over the years, so that the ID has been absorbed but not
> necessarily re-registered.
>
> Anyway I have started an investigation, so we can determine what
> up/down in this.
>
> I agree that for now this will have to be PCI_VENDOR_ID_EFAR, and I
> will return with an update as soon as I know more.
>
> Best Regards
> Steen
>
> On Fri, 2024-06-21 at 13:49 -0500, Bjorn Helgaas wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > 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
>
