From: Mark Brown <broonie@kernel.org> To: Dan Williams <dan.j.williams@intel.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>, Greg KH <gregkh@linuxfoundation.org>, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, alsa-devel@alsa-project.org, Kiran Patil <kiran.patil@intel.com>, linux-rdma <linux-rdma@vger.kernel.org>, Shiraz Saleem <shiraz.saleem@intel.com>, Martin Habets <mhabets@solarflare.com>, Liam Girdwood <lgirdwood@gmail.com>, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, Fred Oh <fred.oh@linux.intel.com>, Jason Gunthorpe <jgg@nvidia.com>, Dave Ertman <david.m.ertman@intel.com>, Jakub Kicinski <kuba@kernel.org>, Netdev <netdev@vger.kernel.org>, Leon Romanovsky <leonro@nvidia.com>, David Miller <davem@davemloft.net>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Parav Pandit <parav@mellanox.com>, lee.jones@linaro.org Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support Date: Fri, 18 Dec 2020 14:20:09 +0000 [thread overview] Message-ID: <20201218142009.GB5333@sirena.org.uk> (raw) In-Reply-To: <CAPcyv4h-jg0dxKZ89yYnHsTEDj7jLWDBhBVTgEC77tLLsz92pw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 2752 bytes --] On Thu, Dec 17, 2020 at 06:39:55PM -0800, Dan Williams wrote: > There is room for documentation improvement here. I realize reading it > back now that much of the justification for "why not platform bus?" > happened on the list, but only a small mention made it into the It wasn't clear from the list discussions either TBH, or at least the bits I happened to see (I did miss several versions of this). > document. It turns out that platform-bus has some special integrations > and hacks with platform-firmware implementations. For example, the > ACPI companion magic Could you be more specific about the problems that these cause for users of the bus? > and specific platform firmware integrations in > platform_match(). It's also an awkward bus name to use because these Going through a bunch of possible firmware interfaces is standard for buses that can't be enumerated, SPI has almost exactly the same code for example. Again, I'm not clear what problem this causes? > devices do not belong to the platform. The platform bus is for devices > that do not have an enumeration mechanism besides board files or > firmware descriptions. This is the one thing I was getting from what I did see, it was an abstraction thing. I'm still unclear what the abstraction is supposed to be - I had thought that it was supposed to be purely for MMIO devices but in a parallel reply Greg is suggesting that it applies to at least "firmware direct" devices which I guess is things enumerated by board files or firmware but that makes things even less clear for me as it's kind of random if people try to describe the internals of devices in DT or not, and ACPI goes the other way and doesn't really describe some things that physically exist. > > We already have a bunch of drivers in tree that have to share a state > > and register other drivers from other subsystems for the same device. > > How is the auxiliary bus different? > > There's also custom subsystem buses that do this. Why not other > alternatives? They didn't capture the simultaneous mindshare of RDMA, > SOF, and NETDEV developers. Personally my plans for using At least in the case of SOF they were getting active pushback from somewhere telling them not to use MFD. > auxiliary-bus do not map cleanly to anything else in the tree. I want > to use it for attaching an NPEM driver (Native PCIE Enclosure > Management) to any PCI device driver that opts-in, but it would be > overkill to go create an "npem" bus for this. This is why everyone is using platform devices here - people were making custom buses but people (including Greg!) pointed out that these were just carbon copies of the platform bus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org> To: Dan Williams <dan.j.williams@intel.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Kiran Patil <kiran.patil@intel.com>, alsa-devel@alsa-project.org, linux-rdma <linux-rdma@vger.kernel.org>, Greg KH <gregkh@linuxfoundation.org>, Martin Habets <mhabets@solarflare.com>, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, Liam Girdwood <lgirdwood@gmail.com>, Fred Oh <fred.oh@linux.intel.com>, Netdev <netdev@vger.kernel.org>, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, Jason Gunthorpe <jgg@nvidia.com>, Jakub Kicinski <kuba@kernel.org>, Dave Ertman <david.m.ertman@intel.com>, lee.jones@linaro.org, Shiraz Saleem <shiraz.saleem@intel.com>, David Miller <davem@davemloft.net>, Leon Romanovsky <leonro@nvidia.com>, Parav Pandit <parav@mellanox.com> Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support Date: Fri, 18 Dec 2020 14:20:09 +0000 [thread overview] Message-ID: <20201218142009.GB5333@sirena.org.uk> (raw) In-Reply-To: <CAPcyv4h-jg0dxKZ89yYnHsTEDj7jLWDBhBVTgEC77tLLsz92pw@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 2752 bytes --] On Thu, Dec 17, 2020 at 06:39:55PM -0800, Dan Williams wrote: > There is room for documentation improvement here. I realize reading it > back now that much of the justification for "why not platform bus?" > happened on the list, but only a small mention made it into the It wasn't clear from the list discussions either TBH, or at least the bits I happened to see (I did miss several versions of this). > document. It turns out that platform-bus has some special integrations > and hacks with platform-firmware implementations. For example, the > ACPI companion magic Could you be more specific about the problems that these cause for users of the bus? > and specific platform firmware integrations in > platform_match(). It's also an awkward bus name to use because these Going through a bunch of possible firmware interfaces is standard for buses that can't be enumerated, SPI has almost exactly the same code for example. Again, I'm not clear what problem this causes? > devices do not belong to the platform. The platform bus is for devices > that do not have an enumeration mechanism besides board files or > firmware descriptions. This is the one thing I was getting from what I did see, it was an abstraction thing. I'm still unclear what the abstraction is supposed to be - I had thought that it was supposed to be purely for MMIO devices but in a parallel reply Greg is suggesting that it applies to at least "firmware direct" devices which I guess is things enumerated by board files or firmware but that makes things even less clear for me as it's kind of random if people try to describe the internals of devices in DT or not, and ACPI goes the other way and doesn't really describe some things that physically exist. > > We already have a bunch of drivers in tree that have to share a state > > and register other drivers from other subsystems for the same device. > > How is the auxiliary bus different? > > There's also custom subsystem buses that do this. Why not other > alternatives? They didn't capture the simultaneous mindshare of RDMA, > SOF, and NETDEV developers. Personally my plans for using At least in the case of SOF they were getting active pushback from somewhere telling them not to use MFD. > auxiliary-bus do not map cleanly to anything else in the tree. I want > to use it for attaching an NPEM driver (Native PCIE Enclosure > Management) to any PCI device driver that opts-in, but it would be > overkill to go create an "npem" bus for this. This is why everyone is using platform devices here - people were making custom buses but people (including Greg!) pointed out that these were just carbon copies of the platform bus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-12-18 14:21 UTC|newest] Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-03 0:54 [resend/standalone PATCH v4] Add auxiliary bus support Dan Williams 2020-12-03 0:54 ` Dan Williams 2020-12-03 15:06 ` Greg KH 2020-12-03 15:06 ` Greg KH 2020-12-04 2:33 ` Jason Gunthorpe 2020-12-04 2:33 ` Jason Gunthorpe 2020-12-04 3:37 ` Dan Williams 2020-12-04 3:37 ` Dan Williams 2020-12-03 15:07 ` Greg KH 2020-12-03 15:07 ` Greg KH 2020-12-03 15:55 ` Leon Romanovsky 2020-12-03 15:55 ` Leon Romanovsky 2020-12-04 11:42 ` Greg KH 2020-12-04 11:42 ` Greg KH 2020-12-04 11:43 ` [PATCH 1/3] driver core: auxiliary bus: move slab.h from include file Greg KH 2020-12-04 11:43 ` Greg KH 2020-12-04 11:44 ` [PATCH 2/3] driver core: auxiliary bus: make remove function return void Greg KH 2020-12-04 11:44 ` Greg KH 2020-12-04 11:44 ` [PATCH 3/3] driver core: auxiliary bus: minor coding style tweaks Greg KH 2020-12-04 11:44 ` Greg KH 2020-12-04 11:48 ` Greg KH 2020-12-04 11:48 ` Greg KH 2020-12-04 11:49 ` [PATCH v2 " Greg KH 2020-12-04 11:49 ` Greg KH 2020-12-04 12:32 ` [resend/standalone PATCH v4] Add auxiliary bus support Leon Romanovsky 2020-12-04 12:32 ` Leon Romanovsky 2020-12-04 12:43 ` Parav Pandit 2020-12-04 12:43 ` Parav Pandit 2020-12-04 12:59 ` Greg KH 2020-12-04 12:59 ` Greg KH 2020-12-04 17:10 ` Ranjani Sridharan 2020-12-04 17:10 ` Ranjani Sridharan 2020-12-05 9:02 ` Greg KH 2020-12-05 9:02 ` Greg KH 2020-12-04 16:41 ` Dan Williams 2020-12-04 16:41 ` Dan Williams 2020-12-05 15:51 ` Greg KH 2020-12-05 15:51 ` Greg KH 2020-12-17 21:19 ` Alexandre Belloni 2020-12-17 21:19 ` Alexandre Belloni 2020-12-18 2:39 ` Dan Williams 2020-12-18 2:39 ` Dan Williams 2020-12-18 14:20 ` Mark Brown [this message] 2020-12-18 14:20 ` Mark Brown 2020-12-18 7:10 ` Greg KH 2020-12-18 7:10 ` Greg KH 2020-12-18 13:17 ` Mark Brown 2020-12-18 13:17 ` Mark Brown 2020-12-18 13:46 ` Lee Jones 2020-12-18 13:46 ` Lee Jones 2020-12-18 14:08 ` Jason Gunthorpe 2020-12-18 14:08 ` Jason Gunthorpe 2020-12-18 15:52 ` Mark Brown 2020-12-18 15:52 ` Mark Brown 2020-12-18 16:28 ` Jason Gunthorpe 2020-12-18 16:28 ` Jason Gunthorpe 2020-12-18 17:15 ` Alexandre Belloni 2020-12-18 17:15 ` Alexandre Belloni 2020-12-18 18:03 ` Mark Brown 2020-12-18 18:03 ` Mark Brown 2020-12-18 18:41 ` Jason Gunthorpe 2020-12-18 18:41 ` Jason Gunthorpe 2020-12-18 19:09 ` Lee Jones 2020-12-18 19:09 ` Lee Jones 2020-12-18 20:14 ` Jason Gunthorpe 2020-12-18 20:14 ` Jason Gunthorpe 2020-12-18 20:32 ` Mark Brown 2020-12-18 20:32 ` Mark Brown 2020-12-18 20:58 ` Jason Gunthorpe 2020-12-18 20:58 ` Jason Gunthorpe 2020-12-18 21:16 ` Alexandre Belloni 2020-12-18 21:16 ` Alexandre Belloni 2020-12-18 22:36 ` Dan Williams 2020-12-18 22:36 ` Dan Williams 2020-12-18 23:36 ` Jason Gunthorpe 2020-12-18 23:36 ` Jason Gunthorpe 2020-12-19 0:22 ` Alexandre Belloni 2020-12-19 0:22 ` Alexandre Belloni 2020-12-21 18:51 ` Mark Brown 2020-12-21 18:51 ` Mark Brown 2021-01-04 18:08 ` Jason Gunthorpe 2021-01-04 18:08 ` Jason Gunthorpe 2021-01-04 21:19 ` Mark Brown 2021-01-04 21:19 ` Mark Brown 2021-01-05 0:13 ` Jason Gunthorpe 2021-01-05 0:13 ` Jason Gunthorpe 2021-01-05 0:51 ` Dan Williams 2021-01-05 0:51 ` Dan Williams 2021-01-05 1:53 ` Jason Gunthorpe 2021-01-05 1:53 ` Jason Gunthorpe 2021-01-05 3:12 ` Dan Williams 2021-01-05 3:12 ` Dan Williams 2021-01-05 12:49 ` Jason Gunthorpe 2021-01-05 12:49 ` Jason Gunthorpe 2021-01-05 13:42 ` Mark Brown 2021-01-05 13:42 ` Mark Brown 2021-01-05 14:36 ` Jason Gunthorpe 2021-01-05 14:36 ` Jason Gunthorpe 2021-01-05 15:47 ` Mark Brown 2021-01-05 15:47 ` Mark Brown 2020-12-04 12:35 ` Greg KH 2020-12-04 12:35 ` Greg KH 2020-12-04 12:54 ` Leon Romanovsky 2020-12-04 12:54 ` Leon Romanovsky 2020-12-04 16:25 ` Jakub Kicinski 2020-12-04 16:25 ` Jakub Kicinski 2020-12-04 17:57 ` Saeed Mahameed 2020-12-04 17:57 ` Saeed Mahameed 2020-12-04 18:05 ` Ranjani Sridharan 2020-12-04 18:05 ` Ranjani Sridharan 2020-12-06 0:24 ` David Ahern 2020-12-06 0:24 ` David Ahern 2020-12-06 0:32 ` Dan Williams 2020-12-06 0:32 ` Dan Williams
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201218142009.GB5333@sirena.org.uk \ --to=broonie@kernel.org \ --cc=alexandre.belloni@bootlin.com \ --cc=alsa-devel@alsa-project.org \ --cc=dan.j.williams@intel.com \ --cc=davem@davemloft.net \ --cc=david.m.ertman@intel.com \ --cc=fred.oh@linux.intel.com \ --cc=gregkh@linuxfoundation.org \ --cc=jgg@nvidia.com \ --cc=kiran.patil@intel.com \ --cc=kuba@kernel.org \ --cc=lee.jones@linaro.org \ --cc=leonro@nvidia.com \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rdma@vger.kernel.org \ --cc=mhabets@solarflare.com \ --cc=netdev@vger.kernel.org \ --cc=parav@mellanox.com \ --cc=pierre-louis.bossart@linux.intel.com \ --cc=ranjani.sridharan@linux.intel.com \ --cc=shiraz.saleem@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.