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 82E74C2BD05 for ; Mon, 24 Jun 2024 11:47:34 +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=UXyhWmWqUF+A3EaGggTlBQHpsHmlB1hyBFiOougSmO4=; b=3KDFPXV317ALV0qXAUWzIBwz5h W95bN4QLMqX4GAh54OVDcig/onDlXuH1uA4jutb2B8E+utiMoqjoAZ9ejUjvcZ6LtdygSD3uRQEhu xLdg8oJTSTQTejSOlsCe4X7qHi45mfxYCbwoFlBKoF+/NCr+fLnRI/BMDQM/I6YH+0aKb/6W5DfXF Mj9jZ3lQJHcWK/zVJon3dcbQ/gPjZ6IqmnAnVk1mu3GQ05Nts1YOKHz5XNIJpW/syubNiznelkpCF YTo95FPsFeYLyosPf/L6lRtYP3oHf+WA3HjYvFspeMofAlxlAXbZVLwbbET1kN1XEmagprFPDQQDj y930kJtw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sLiAN-0000000GfS1-2k3G; Mon, 24 Jun 2024 11:47:23 +0000 Received: from esa.microchip.iphmx.com ([68.232.153.233]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sLiAI-0000000GfQh-0QYG for linux-arm-kernel@lists.infradead.org; Mon, 24 Jun 2024 11:47:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1719229638; x=1750765638; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=UXyhWmWqUF+A3EaGggTlBQHpsHmlB1hyBFiOougSmO4=; b=Ej/tv4+H3m3JpJdr9JXrMDesE0qwebMnZ04wkeknuz1xqjX7lXkqKzY3 tT4KmlTC7ArVkKmnzhFKG0eKE8kra3rHFMUM3ikiPByy4A0gkWvApUaak uocxj4QkxuJcQh55g9u490CceWuNlQg+matv9BKnh29ShCFTUorNIGgd/ qboNFHlTykuwVo6gUSKksIaGrrJuM6sqGVfMLsBSQ/saXEEKk3e6VPbS7 QUxba9B7GQtrJaGtaDkVPk6hR5qyYBZ7YGdZV9u87cF86UcPja8FSHqri /QLMRkGhYnqNIpTdsY6DhdV3Bb+elSnIFXR3KGGx07hgZuKwvoFFswMUY A==; X-CSE-ConnectionGUID: t0mypC8PTS6ZgrJ8E5DXQg== X-CSE-MsgGUID: RXLnRG+kTIWW+V7yloWFmg== X-IronPort-AV: E=Sophos;i="6.08,261,1712646000"; d="scan'208";a="28416866" X-Amp-Result: SKIPPED(no attachment in message) Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa3.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 24 Jun 2024 04:47:14 -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; Mon, 24 Jun 2024 04:46:34 -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; Mon, 24 Jun 2024 04:46:28 -0700 Message-ID: Subject: Re: [PATCH v2 18/19] mfd: Add support for LAN966x PCI device From: Steen Hegelund To: Bjorn Helgaas , Andy Shevchenko CC: Herve Codina , 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: Mon, 24 Jun 2024 13:46:32 +0200 In-Reply-To: <20240621184923.GA1398370@bhelgaas> 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-20240624_044718_437806_FE4924BB X-CRM114-Status: GOOD ( 39.65 ) 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, 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 >=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/ethe= rnet/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=A0shows = 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