From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6C874C27C4F for ; Wed, 26 Jun 2024 07:18:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:MIME-Version: Content-Transfer-Encoding:Content-Type:References:In-Reply-To:Date:CC:To:From :Subject:Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=QViRDfGLyEs0qY03dwI3pJY9v0tzpCb0Eh9mfEK5Xmo=; b=mRIGhIWyYQkLSk2nelFAwyE9px sQ9sVclnCpxJvViQU4ajseReiK38PuXDx/gb2B6e6UzKJ+Ar6R7voso77pIEohqYwOzH4zPmGbbGb UsQpvKXFKFBaDtBGHCm4WApJ9AXXd6wVsebJwtzjr1psHeH4E8TYM6Jgzwm18BiPUbK3IZtOTjQSP rbNLep8QHJWrfciTmc8KdL+6THP7o4HTLf+Pj1VpsU7kVUB4kdgm9KJOUZlgNUKPBDB8owe0KBFt/ MHv/116Vf2/3U/kFb7TiHRMFnScc2bFZfK36HNe+jv5Gcb7ZPceCMeCvRbgnM2RHVAEGWwmvTRdkR 0XYIdraA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMMuj-00000005hdL-35Uy; Wed, 26 Jun 2024 07:17:57 +0000 Received: from esa.microchip.iphmx.com ([68.232.154.123]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMMuc-00000005hbn-0naA for linux-arm-kernel@lists.infradead.org; Wed, 26 Jun 2024 07:17:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1719386270; x=1750922270; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=NNwvsHzCjMXIwRySc9XDZBYK6afUB3U1wQUOdXPORNk=; b=E3oBVZcaz8dwAJWheTaA7UbgnLi8RrmrIQdjvDS9goe115kijwEjKaAa EFEr5tZgJLpsyaM5GJdEUGsckpzGfSlSfKPMHH4SfdA8Kktpoixbwt8oe hut7h4g+CWpq7Ihzb7MoosjcdCo2huEKZgmUOcyINnjM9v29Jz9pwXy60 jpR5C8ne+LLPpu6XDFLpP1Y1ETYayKb3k/tRVz+g13baowoK6On5I2vPz rjAZQqQXtP2cqf+wSlDLH/akBE4umnlfNpikwiVf+/OuK7hpH3avSfhkR yavKYPCdTUz2kYb2vwSmMxKfq/hPN/nXpOdbOX7Yc8lIeqk34G3KjqXbe A==; X-CSE-ConnectionGUID: zmiLeBagSOCL5GSsV7txlw== X-CSE-MsgGUID: rYtxGmevRsiWMD2me9JSwQ== X-IronPort-AV: E=Sophos;i="6.08,266,1712646000"; d="scan'208";a="28486986" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa4.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 26 Jun 2024 00:17:47 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 26 Jun 2024 00:17:15 -0700 Received: from DEN-DL-M31857.microsemi.net (10.10.85.11) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server id 15.1.2507.35 via Frontend Transport; Wed, 26 Jun 2024 00:17:09 -0700 Message-ID: Subject: Re: [PATCH v2 18/19] mfd: Add support for LAN966x PCI device From: Steen Hegelund To: Bjorn Helgaas , Andy Shevchenko , Herve Codina CC: Simon Horman , Sai Krishna Gajula , Thomas Gleixner , "Rob Herring" , Krzysztof Kozlowski , "Conor Dooley" , "David S. Miller" , "Eric Dumazet" , Jakub Kicinski , "Paolo Abeni" , Lee Jones , Arnd Bergmann , Horatiu Vultur , , Andrew Lunn , "Heiner Kallweit" , Russell King , Saravana Kannan , Bjorn Helgaas , Philipp Zabel , Lars Povlsen , Daniel Machon , Alexandre Belloni , , , , , , Allan Nielsen , Luca Ceresoli , Thomas Petazzoni Date: Wed, 26 Jun 2024 09:17:11 +0200 In-Reply-To: References: <20240621184923.GA1398370@bhelgaas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240626_001750_427202_79EE8523 X-CRM114-Status: GOOD ( 51.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 =3D=3D=3D Copied from the conversation =3D=3D=3D Hi Bill, =20 Thank you for your email. We can confirm VID 4181 (1055 Hex) is Microchip=E2=80=99s. This is not listed on the website because we are on= ly able to list one VID per company. =20 Please feel free to contact us if you have any questions. =20 Best Regards, =20 PCI-SIG Administration =20 Main: 503-619-0569 | Fax: 503-644-6708 3855 SW 153rd Drive, Beaverton, OR 97003 USA Email: administration@pcisig.com =20 =20 =20 www.pcisig.com | Connect with us on LinkedIn and Twitter @pci_sig =20 From: bill.mahany@microchip.com (administration) Sent: Monday, June 24, 2024 11:07 AM To: administration@pcisig.com Subject: RE: vendor id missing from member companies list =20 Hello once again. =20 Please refer to the below. Could you please reverify that Microchip Technology is still in control of 4181 (0x1055). =20 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/ =20 Thanks =20 Bill Mahany =20 On Mon, 2024-06-24 at 13:46 +0200, Steen Hegelund wrote: > Hi Bjorn, >=20 > I am not sure what went wrong here. >=20 > 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. >=20 > Anyway I have started an investigation, so we can determine what > up/down in this. >=20 > 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. >=20 > Best Regards > Steen >=20 > 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 > >=20 > > On Fri, Jun 21, 2024 at 05:45:05PM +0200, Andy Shevchenko wrote: > > > On Thu, Jun 20, 2024 at 7:19=E2=80=AFPM Herve Codina > > > wrote: > > > > On Thu, 20 Jun 2024 18:43:09 +0200 > > > > Herve Codina wrote: > > > > > On Thu, 20 Jun 2024 18:07:16 +0200 > > > > > Andy Shevchenko wrote: > > > > > > On Thu, Jun 20, 2024 at 5:56=E2=80=AFPM Herve Codina > > > > > > wrote: > > > > > > > On Wed, 5 Jun 2024 23:24:43 +0300 > > > > > > > Andy Shevchenko wrote: > > > > > > > > Mon, May 27, 2024 at 06:14:45PM +0200, Herve Codina > > > > > > > > kirjoitti: > >=20 > > > > > > > > > +static struct pci_device_id lan966x_pci_ids[] =3D { > > > > > > > > > +=C2=A0=C2=A0 { PCI_DEVICE(0x1055, 0x9660) }, > > > > > > > >=20 > > > > > > > > Don't you have VENDOR_ID defined somewhere? > > > > > > >=20 > > > > > > > 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/et= hernet/microchip/lan743x_main.h#L851 > > > > > > >=20 > > > > > > > I will patch pci-ids.h to create: > > > > > > > =C2=A0 #define PCI_VENDOR_ID_SMSC PCI_VENDOR_ID_EFAR > > > > > > > =C2=A0 #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 > > > > > > >=20 > > > > > > > And use PCI_VENDOR_ID_MCHP in this series. > > > > > >=20 > > > > > > 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. > > > >=20 > > > > Right, I wait for Bjorn reply before changing anything. > > >=20 > > > 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. > >=20 > > We have "#define PCI_VENDOR_ID_EFAR 0x1055" in pci_ids.h, but > > https://pcisig.com/membership/member-companies?combine=3D1055=C2=A0show= s > > no > > results, so it *looks* like EFAR/SMSC/MCHP are currently squatting > > on > > that ID without it being officially assigned. > >=20 > > I think MCHP needs to register 0x1055 with the PCI-SIG > > (administration@pcisig.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. > >=20 > > 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. > >=20 > > 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. > >=20 > > Bjorn >=20