Re: [PATCH v2 0/3] add fwnode support to reset subsystem

[Rob Herring <robh@kernel.org>]

+ 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@kernel.org> 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@fixe.home/

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@xilinx.com/