+ some Xilinx folks On Tue, Apr 05, 2022 at 09:24:34AM +0200, Clément Léger wrote: > Le Mon, 4 Apr 2022 12:41:37 -0500, > Rob Herring <robh@xxxxxxxxxx> a écrit : > > > On Thu, Mar 24, 2022 at 03:12:34PM +0100, Clément Léger wrote: > > > This series is part of a larger series which aims at adding fwnode > > > support in multiple subsystems [1]. The goal of this series was to > > > add support for software node in various subsystem but in a first > > > time only the fwnode support had gained consensus and will be added > > > to multiple subsystems. > > > > The goal is describing a solution. What is the problem? > > > > What's the scenario where you have a reset provider not described by > > firmware providing resets to devices (consumers) also not described by > > firmware. > > Hi Rob, there was a link attached to this series since there was a > previous one that was sent which described the problem. Here is a link > to the same thread but to a specific message which clarifies the > problem and the solutions that were mentionned by other maintainers > (ACPI overlays, DT overlays, software nodes and so on): > > https://lore.kernel.org/netdev/20220224154040.2633a4e4@xxxxxxxxx/ Thanks, but your commit message should explain the problem. The problem is not subsystems don't support fwnode. This is the exact same problem the Xilinx folks are trying to solve with their PCIe FPGA cards[1] (and that is not really a v1). They need to describe h/w downstream from a 'discoverable' device. Their case is further complicated with the dynamic nature of FPGAs. It's also not just PCIe. Another usecase is describing downstream devices on USB FTDI serial chips which can have GPIO, I2C, SPI downstream. And then you want to plug in 10 of those. I don't think swnodes are going to scale for these usecases. We moved h/w description out of the kernel for a reason. Why are we adding that back in a new form? The complexity for what folks want to describe is only going to increase. I think DT overlays is the right (or only) solution here. Of course the DT maintainer would say that. Actually, I would be happier to not have to support overlays in the kernel. I've told the Xilinx folks the same thing, but I would separate this into 2 parts. First is just h/w work in a DT based system. Second is creating a base tree an overlay can be applied to. The first part should be pretty straightforward. We already have PCI bus bindings. The only tricky part is getting address translation working from leaf device thru the PCI bus to host bus, but support for that should all be in place (given we support ISA buses off of PCI bus). The second part will require generating PCI DT nodes at runtime. That may be needed for both DT and ACPI systems as we don't always describe all the PCI hierarchy in DT. That could work either by the PCI subsystem creating nodes as it populates devices or your driver could make a request to populate nodes for its hierarchy. That's not a hard problem to solve. That's what OpenFirmware implementations do already. Rob https://lore.kernel.org/lkml/20220216050056.311496-1-lizhi.hou@xxxxxxxxxx/
