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: Mon, 4 Jan 2021 21:19:30 +0000 [thread overview] Message-ID: <20210104211930.GI5645@sirena.org.uk> (raw) In-Reply-To: <20210104180831.GD552508@nvidia.com> [-- Attachment #1: Type: text/plain, Size: 6650 bytes --] On Mon, Jan 04, 2021 at 02:08:31PM -0400, Jason Gunthorpe wrote: > On Mon, Dec 21, 2020 at 06:51:40PM +0000, Mark Brown wrote: > > BTW I did have a bit of a scan through some of the ACPI devices and > > for a good proportion of them it seems fairly clear that they are > > not platform devices at all - they were mostly interacting with ACPI > > firmware functionality rather than hardware, something you can't > > really do with FDT at all. > Right, that is kind of the point. We also have cases where ACPI > devices are just an ioresource list and don't have any special > ACPIness. IIRC DT has a similar issue where there are DT drivers that > just don't work without the OF stuff. Why are they platform drivers? There *might* be some very legacy ones for actual OF systems but that's not really at all a thing for FDT which is essentially all DT usage at this point - to the extent that things won't work it's due to the non-enumarability of the hardware so it's just a question of where the data comes from rather than one of communicating with a firmware (and for more generic things like GPIOs exactly where the data comes from ends up abstracted away from the driver anyway which is all some devices need). The idiom with DT is more that it's just a different way of filling out the data you'd get from a board file, it's not a runtime thing like ACPI. > We fake this idea out by being able to convert platform to DT and OF, > but if platform is to be the universal device then why do we have PCI > device and not a 'platform to pci' operator instead? None of this is > consistent. If it were more common for there to be IPs that appear as both PCI and platform devices (Intel do it a bit but otherwise it's quite rare) I'd guess we would actually have helpers for that translation. > Regardless of the shortcut to make everything a struct > platform_device, I think it was a mistake to put OF devices on > platform_bus. Those should have remained on some of_bus even if they Like I keep saying the same thing applies to all non-enumerable buses - exactly the same considerations exist for all the other buses like I2C (including the ACPI naming issue you mention below), and for that matter with enumerable buses which can have firmware info. > are represented by struct platform_device and fiddling in the core > done to make that work OK. What exactly is the fiddling in the core here, I'm a bit unclear? > I agree with this, IMHO there is no really cohesive explanation for > when to create a bus vs use the "universal bus" (platform) that can > also explain the things platform is already doing. > This feels like a good conference topic someday.. We should have this discussion *before* we get too far along with trying to implement things, we should at least have some idea where we want to head there. > > Personally I'm even struggling to identify a practical problem that > > we're trying to solve here. Like Alexandre says what would an > > mfd_driver actually buy us? > Well, there is the minor issue of name collision eg > /sys/bus/XX/devices/* must list all devices in the system with no > collisions. > The owner of the bus is supposed to define the stable naming scheme > and all the devices are supposed to follow it. platform doesn't have > this: > $ ls /sys/bus/platform/devices/ > ACPI000C:00 dell-smbios.0 'Fixed MDIO bus.0' INT33A1:00 microcode PNP0C04:00 PNP0C0B:03 PNP0C14:00 > alarmtimer.0.auto dell-smbios.1 GHES.0 intel_rapl_msr.0 MSFT0101:00 PNP0C0B:00 PNP0C0B:04 PNP0C14:01 > coretemp.0 efi-framebuffer.0 GHES.1 iTCO_wdt pcspkr PNP0C0B:01 PNP0C0C:00 reg-dummy > dcdbas eisa.0 INT0800:00 kgdboc PNP0103:00 PNP0C0B:02 PNP0C0E:00 serial8250 > Why are ACPI names in here? It looks like "because platform drivers > were used to bind to ACPI devices" I think we decided that the ACPI namespace was sufficiently divergent from our general conventions that we could just safely use the string, ICBW though. > > I have some bad news for you about the hardware description problem > > space. Among other things we have a bunch of platform devices that > > don't have any resources exposed through the resource API but are still > > things like chips on a board, doing some combination of exposing > > resources for other devices (eg, a fixed voltage regulator) and > > consuming things like clocks or GPIOs that don't appear in the resource > > API. > So in these cases how do I use the generic platform bus API to find > the GPIOs, regulators, and so on to connect with? > If drivers take a platform device and immediately covert it to an OF > object and use OF APIs to find those connections then it really > *never* was a platform device in the first place and coding an OF > driver as platform is an abuse. Those APIs all take a struct device for lookup so it's the same call for looking things up regardless of the bus the device is on or what firmware the system is using - where there are firmware specific lookup functions they're generally historical and shouldn't be used for new code. It's generally something in the form api_type *api_get(struct device *dev, const char *name); with the strings being defined according to something in the hardware spec so there's a good chance of them working generically (and realistically it's only DT that's actually putting these names in firmware, otherwise it's just board files that we totally control, so this really is fine). > A decent step would be to accept that 'platform_device' is something > weird and special and split its bus_type. Only devices created > direclty in C code should be on the platform_bus, OF/ACPI/etc should > all be on their own bus_types, even though they all use the same > 'struct platform_bus' ...and then do the same thing for every other bus with firmware bindings. If it's about the firmware interfaces it really isn't a platform bus specific thing. It's not clear to me if that's what it is though or if this is just some tangent. > > that but it is not clear what the upside of doing that would be, > > especially given the amount of upheval it would generate and the > > classification issues that will inevitably result. > Well, I think the upside for existing is very small, but I would like > to see a shared idea about how to answer questions like 'when should I > use a existing device type' and 'when should I make a new device type'. Yes, very much so. [-- 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: Mon, 4 Jan 2021 21:19:30 +0000 [thread overview] Message-ID: <20210104211930.GI5645@sirena.org.uk> (raw) In-Reply-To: <20210104180831.GD552508@nvidia.com> [-- Attachment #1: Type: text/plain, Size: 6650 bytes --] On Mon, Jan 04, 2021 at 02:08:31PM -0400, Jason Gunthorpe wrote: > On Mon, Dec 21, 2020 at 06:51:40PM +0000, Mark Brown wrote: > > BTW I did have a bit of a scan through some of the ACPI devices and > > for a good proportion of them it seems fairly clear that they are > > not platform devices at all - they were mostly interacting with ACPI > > firmware functionality rather than hardware, something you can't > > really do with FDT at all. > Right, that is kind of the point. We also have cases where ACPI > devices are just an ioresource list and don't have any special > ACPIness. IIRC DT has a similar issue where there are DT drivers that > just don't work without the OF stuff. Why are they platform drivers? There *might* be some very legacy ones for actual OF systems but that's not really at all a thing for FDT which is essentially all DT usage at this point - to the extent that things won't work it's due to the non-enumarability of the hardware so it's just a question of where the data comes from rather than one of communicating with a firmware (and for more generic things like GPIOs exactly where the data comes from ends up abstracted away from the driver anyway which is all some devices need). The idiom with DT is more that it's just a different way of filling out the data you'd get from a board file, it's not a runtime thing like ACPI. > We fake this idea out by being able to convert platform to DT and OF, > but if platform is to be the universal device then why do we have PCI > device and not a 'platform to pci' operator instead? None of this is > consistent. If it were more common for there to be IPs that appear as both PCI and platform devices (Intel do it a bit but otherwise it's quite rare) I'd guess we would actually have helpers for that translation. > Regardless of the shortcut to make everything a struct > platform_device, I think it was a mistake to put OF devices on > platform_bus. Those should have remained on some of_bus even if they Like I keep saying the same thing applies to all non-enumerable buses - exactly the same considerations exist for all the other buses like I2C (including the ACPI naming issue you mention below), and for that matter with enumerable buses which can have firmware info. > are represented by struct platform_device and fiddling in the core > done to make that work OK. What exactly is the fiddling in the core here, I'm a bit unclear? > I agree with this, IMHO there is no really cohesive explanation for > when to create a bus vs use the "universal bus" (platform) that can > also explain the things platform is already doing. > This feels like a good conference topic someday.. We should have this discussion *before* we get too far along with trying to implement things, we should at least have some idea where we want to head there. > > Personally I'm even struggling to identify a practical problem that > > we're trying to solve here. Like Alexandre says what would an > > mfd_driver actually buy us? > Well, there is the minor issue of name collision eg > /sys/bus/XX/devices/* must list all devices in the system with no > collisions. > The owner of the bus is supposed to define the stable naming scheme > and all the devices are supposed to follow it. platform doesn't have > this: > $ ls /sys/bus/platform/devices/ > ACPI000C:00 dell-smbios.0 'Fixed MDIO bus.0' INT33A1:00 microcode PNP0C04:00 PNP0C0B:03 PNP0C14:00 > alarmtimer.0.auto dell-smbios.1 GHES.0 intel_rapl_msr.0 MSFT0101:00 PNP0C0B:00 PNP0C0B:04 PNP0C14:01 > coretemp.0 efi-framebuffer.0 GHES.1 iTCO_wdt pcspkr PNP0C0B:01 PNP0C0C:00 reg-dummy > dcdbas eisa.0 INT0800:00 kgdboc PNP0103:00 PNP0C0B:02 PNP0C0E:00 serial8250 > Why are ACPI names in here? It looks like "because platform drivers > were used to bind to ACPI devices" I think we decided that the ACPI namespace was sufficiently divergent from our general conventions that we could just safely use the string, ICBW though. > > I have some bad news for you about the hardware description problem > > space. Among other things we have a bunch of platform devices that > > don't have any resources exposed through the resource API but are still > > things like chips on a board, doing some combination of exposing > > resources for other devices (eg, a fixed voltage regulator) and > > consuming things like clocks or GPIOs that don't appear in the resource > > API. > So in these cases how do I use the generic platform bus API to find > the GPIOs, regulators, and so on to connect with? > If drivers take a platform device and immediately covert it to an OF > object and use OF APIs to find those connections then it really > *never* was a platform device in the first place and coding an OF > driver as platform is an abuse. Those APIs all take a struct device for lookup so it's the same call for looking things up regardless of the bus the device is on or what firmware the system is using - where there are firmware specific lookup functions they're generally historical and shouldn't be used for new code. It's generally something in the form api_type *api_get(struct device *dev, const char *name); with the strings being defined according to something in the hardware spec so there's a good chance of them working generically (and realistically it's only DT that's actually putting these names in firmware, otherwise it's just board files that we totally control, so this really is fine). > A decent step would be to accept that 'platform_device' is something > weird and special and split its bus_type. Only devices created > direclty in C code should be on the platform_bus, OF/ACPI/etc should > all be on their own bus_types, even though they all use the same > 'struct platform_bus' ...and then do the same thing for every other bus with firmware bindings. If it's about the firmware interfaces it really isn't a platform bus specific thing. It's not clear to me if that's what it is though or if this is just some tangent. > > that but it is not clear what the upside of doing that would be, > > especially given the amount of upheval it would generate and the > > classification issues that will inevitably result. > Well, I think the upside for existing is very small, but I would like > to see a shared idea about how to answer questions like 'when should I > use a existing device type' and 'when should I make a new device type'. Yes, very much so. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-01-04 21:20 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 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 [this message] 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=20210104211930.GI5645@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.