On Thu, Jan 18, 2024 at 12:15:27PM +0100, Greg Kroah-Hartman wrote:

On Thu, Jan 18, 2024 at 11:58:50AM +0100, Bartosz Golaszewski wrote:

quoted

On Wed, Jan 17, 2024 at 5:45 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

On Wed, Jan 17, 2024 at 05:07:43PM +0100, Bartosz Golaszewski wrote:

quoted

From: Bartosz Golaszewski <redacted>

In order to introduce PCI power-sequencing, we need to create platform
devices for child nodes of the port node.

Ick, why a platform device?  What is the parent of this device, a PCI
device?  If so, then this can't be a platform device, as that's not what
it is, it's something else so make it a device of that type,.

Greg,

This is literally what we agreed on at LPC. In fact: during one of the
hall track discussions I said that you typically NAK any attempts at
using the platform bus for "fake" devices but you responded that this
is what the USB on-board HUB does and while it's not pretty, this is
what we need to do.

Ah, you need to remind me of these things, this changelog was pretty
sparse :)

I believe I missed this part of the discussion, why does this need to be
a platform_device? What does the platform_bus bring that can't be
provided by some other bus?

(I'm not questioning the need for having a bus, creating devices, and
matching/binding them to a set of drivers)

Regards,
Bjorn

quoted

Now as for the implementation, the way I see it we have two solutions:
either we introduce a fake, top-level PCI slot platform device device
that will reference the PCI host controller by phandle or we will live
with a secondary, "virtual" platform device for power sequencing that
is tied to the actual PCI device. The former requires us to add DT
bindings, add a totally fake DT node representing the "slot" which
doesn't really exist (and Krzysztof already expressed his negative
opinion of that) and then have code that will be more complex than it
needs to be. The latter allows us to not change DT at all (other than
adding regulators, clocks and GPIOs to already existing WLAN nodes),
reuse the existing parent-child relationship between the port node and
the instantiated platform device as well as result in simpler code.

Given that DT needs to be stable while the underlying C code can
freely change if we find a better solution, I think that the second
option is a no-brainer here.

Ok, I remove my objections, sorry about that, my confusion.

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel