lkml.org 
[lkml]   [2022]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/3] add fwnode support to reset subsystem
+ 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/

\
 
 \ /
  Last update: 2022-04-05 22:44    [W:0.133 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site