From: Mark Brown <broonie@kernel.org> To: Jason Gunthorpe <jgg@nvidia.com> Cc: Greg KH <gregkh@linuxfoundation.org>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Dan Williams <dan.j.williams@intel.com>, 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>, 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 15:52:04 +0000 [thread overview] Message-ID: <20201218155204.GC5333@sirena.org.uk> (raw) In-Reply-To: <20201218140854.GW552508@nvidia.com> [-- Attachment #1: Type: text/plain, Size: 2100 bytes --] On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote: > > As previously discussed this will need the auxilliary bus extending to > > support at least interrupts and possibly also general resources. > I thought the recent LWN article summed it up nicely, auxillary bus is > for gluing to subsystems together using a driver specific software API > to connect to the HW, MFD is for splitting a physical HW into disjoint > regions of HW. This conflicts with the statements from Greg about not using the platform bus for things that aren't memory mapped or "direct firmware", a large proportion of MFD subfunctions are neither at least in so far as I can understand what direct firmware means. To be honest I don't find the LWN article clarifies things particularly here, the rationale appears to involve some misconceptions about what MFDs look like. It looks like it assumes that MFD functions have physically separate register sets for example which is not a reliable feature of MFDs, nor is the assumption that there's no shared functionality which appears to be there. It also appears to assume that MFD subfunctions can clearly be described by ACPI (where it would be unidiomatic, we just don't see this happening for the MFDs that appear on ACPI systems and I'm not sure bindings exist within ACPI) or DT (where even where subfunctions are individually described it's rarely doing more than enumerating that things exist). > Maybe there is some overlap, but if you want to add HW representations > to the general auxillary device then I think you are using it for the > wrong thing. Even for the narrowest use case for auxiliary devices that I can think of I think the assumption that nobody will ever design something which can wire an interrupt intended to be serviced by a subfunction is a bit optimistic. If Greg's statements about not using platform buses for MMIO or direct firmware devices are accurate then those cases already exist, if nothing else a common subfunction for MFDs is an interrupt controller. [-- 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: Jason Gunthorpe <jgg@nvidia.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>, lee.jones@linaro.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Kiran Patil <kiran.patil@intel.com>, Liam Girdwood <lgirdwood@gmail.com>, linux-rdma <linux-rdma@vger.kernel.org>, Greg KH <gregkh@linuxfoundation.org>, Martin Habets <mhabets@solarflare.com>, alsa-devel@alsa-project.org, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, Fred Oh <fred.oh@linux.intel.com>, Netdev <netdev@vger.kernel.org>, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, Jakub Kicinski <kuba@kernel.org>, Dave Ertman <david.m.ertman@intel.com>, Dan Williams <dan.j.williams@intel.com>, 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 15:52:04 +0000 [thread overview] Message-ID: <20201218155204.GC5333@sirena.org.uk> (raw) In-Reply-To: <20201218140854.GW552508@nvidia.com> [-- Attachment #1: Type: text/plain, Size: 2100 bytes --] On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote: > On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote: > > As previously discussed this will need the auxilliary bus extending to > > support at least interrupts and possibly also general resources. > I thought the recent LWN article summed it up nicely, auxillary bus is > for gluing to subsystems together using a driver specific software API > to connect to the HW, MFD is for splitting a physical HW into disjoint > regions of HW. This conflicts with the statements from Greg about not using the platform bus for things that aren't memory mapped or "direct firmware", a large proportion of MFD subfunctions are neither at least in so far as I can understand what direct firmware means. To be honest I don't find the LWN article clarifies things particularly here, the rationale appears to involve some misconceptions about what MFDs look like. It looks like it assumes that MFD functions have physically separate register sets for example which is not a reliable feature of MFDs, nor is the assumption that there's no shared functionality which appears to be there. It also appears to assume that MFD subfunctions can clearly be described by ACPI (where it would be unidiomatic, we just don't see this happening for the MFDs that appear on ACPI systems and I'm not sure bindings exist within ACPI) or DT (where even where subfunctions are individually described it's rarely doing more than enumerating that things exist). > Maybe there is some overlap, but if you want to add HW representations > to the general auxillary device then I think you are using it for the > wrong thing. Even for the narrowest use case for auxiliary devices that I can think of I think the assumption that nobody will ever design something which can wire an interrupt intended to be serviced by a subfunction is a bit optimistic. If Greg's statements about not using platform buses for MMIO or direct firmware devices are accurate then those cases already exist, if nothing else a common subfunction for MFDs is an interrupt controller. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-12-18 15:53 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 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 [this message] 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=20201218155204.GC5333@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.