linux-kernel - Re: [PATCH v2 18/19] mfd: Add support for LAN966x PCI device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 24 Jun 2024 13:46:32 +0200
From: Steen Hegelund <steen.hegelund@...rochip.com>
To: Bjorn Helgaas <helgaas@...nel.org>, Andy Shevchenko
	<andy.shevchenko@...il.com>
CC: Herve Codina <herve.codina@...tlin.com>, Simon Horman <horms@...nel.org>,
	Sai Krishna Gajula <saikrishnag@...vell.com>, Thomas Gleixner
	<tglx@...utronix.de>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
	<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Lee Jones
	<lee@...nel.org>, Arnd Bergmann <arnd@...db.de>, Horatiu Vultur
	<horatiu.vultur@...rochip.com>, <UNGLinuxDriver@...rochip.com>, Andrew Lunn
	<andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Russell King
	<linux@...linux.org.uk>, Saravana Kannan <saravanak@...gle.com>, "Bjorn
 Helgaas" <bhelgaas@...gle.com>, Philipp Zabel <p.zabel@...gutronix.de>, "Lars
 Povlsen" <lars.povlsen@...rochip.com>, Daniel Machon
	<daniel.machon@...rochip.com>, Alexandre Belloni
	<alexandre.belloni@...tlin.com>, <linux-kernel@...r.kernel.org>,
	<devicetree@...r.kernel.org>, <netdev@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>, "Allan
 Nielsen" <allan.nielsen@...rochip.com>, Luca Ceresoli
	<luca.ceresoli@...tlin.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 18/19] mfd: Add support for LAN966x PCI device

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@...tlin.com> wrote:
> > > On Thu, 20 Jun 2024 18:43:09 +0200
> > > Herve Codina <herve.codina@...tlin.com> wrote:
> > > > On Thu, 20 Jun 2024 18:07:16 +0200
> > > > Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> > > > > On Thu, Jun 20, 2024 at 5:56 PM Herve Codina
> > > > > <herve.codina@...tlin.com> wrote:
> > > > > > On Wed, 5 Jun 2024 23:24:43 +0300
> > > > > > Andy Shevchenko <andy.shevchenko@...il.com> 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@...sig.com) 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