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 34566C27C4F for ; Fri, 21 Jun 2024 18:49:46 +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:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References:List-Owner; bh=wuCu3zSmWoY7pE33i7E42y3efzGjVGy58N5AETwVy9s=; b=mxHQ4kGMsAot8Ko0NhoAiltj5e noU5iqJHD/y5URMyYm/L9Ul2LfNKR77VH9JwVZP4tZ7nMkhpggMUKh+ae7aVVoLDoYOecAOwBhkQV cy2rE7muBtKMpJIVao+xlOrQDleqBxjlwFOhi48FRf5iABTtujmotoQYZWL8aNzqX8c+En/sDMoqX YR7CSqxsDcOaMQ1gbZvmPOz6kDRN2rWSUUQ/uMFnJFqbGmsKTksnglNz3QbkPL33KbbZjw3Yuhay8 ss1H7kUPc0Z2IEjpfCtiFpBBWqhDXEDT4GLmXLKgoQshu7JAFMEr8DB0CaB1MTKTKja4bD+dN6WvL q+iU+5aQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sKjKG-0000000AHO7-2sXH; Fri, 21 Jun 2024 18:49:32 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sKjKC-0000000AHNM-1SBI for linux-arm-kernel@lists.infradead.org; Fri, 21 Jun 2024 18:49:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id F02AECE3C65; Fri, 21 Jun 2024 18:49:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6002C2BBFC; Fri, 21 Jun 2024 18:49:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718995765; bh=H/7KJb3Hymr1bKAoWOE4wiwISddzEhYEUB2Cpn7f+Ag=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=dcpUiTfj0pZj8c9YnwxOVMJKgC183M8l4XD3bZKdRLAHBOa7QLAQ2dXK1BEXCuQNq kMQSxeZsDzahW34rhdDVxY1GWkssuw98Ekh37+4w35obX2lbQazn/8Yu/rSaZuKwgr iN1ulmzWHCXe66KikX/r72y+IVu3zRSmNHbr+d+qmBQA6Wk7+Jh/IimR3iOeIgGUSb 2K023F37o+dgCPwG4gzdRGBmx+l9DvcRCzNd4KN82/NT6njH7xHI8uFhcfhaV1Fvx2 M4nRoZP7Fd+AtL4hX8mcKUeI8EYaKYtfuVOFNE2ZmcHzTYo2HBppxQFy4HC2IadRAN R2oqIwo/a4xSg== Date: Fri, 21 Jun 2024 13:49:23 -0500 From: Bjorn Helgaas To: 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 , UNGLinuxDriver@microchip.com, Andrew Lunn , Heiner Kallweit , Russell King , Saravana Kannan , Bjorn Helgaas , Philipp Zabel , Lars Povlsen , Steen Hegelund , Daniel Machon , Alexandre Belloni , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, netdev@vger.kernel.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Allan Nielsen , Luca Ceresoli , Thomas Petazzoni Subject: Re: [PATCH v2 18/19] mfd: Add support for LAN966x PCI device Message-ID: <20240621184923.GA1398370@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240621_114928_824937_2B1F8AA0 X-CRM114-Status: GOOD ( 27.06 ) 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 On Fri, Jun 21, 2024 at 05:45:05PM +0200, Andy Shevchenko wrote: > On Thu, Jun 20, 2024 at 7:19 PM 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 PM 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: > > > > > > > +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@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. 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