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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yk2P4zgKP8dVYUWm@robh.at.kernel.org>
Date:   Wed, 6 Apr 2022 08:04:35 -0500
From:   Rob Herring <robh@...nel.org>
To:     Clément Léger <clement.leger@...tlin.com>
Cc:     Lizhi Hou <lizhi.hou@...inx.com>,
        Sonal Santan <sonal.santan@...inx.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Frank Rowand <frowand.list@...il.com>,
        Lars Povlsen <lars.povlsen@...rochip.com>,
        Steen Hegelund <Steen.Hegelund@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Allan Nielsen <allan.nielsen@...rochip.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        devicetree@...r.kernel.org,
        Stefano Stabellini <sstabellini@...nel.org>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v2 0/3] add fwnode support to reset subsystem

On Wed, Apr 06, 2022 at 09:52:13AM +0200, Clément Léger wrote:
> Le Tue, 5 Apr 2022 16:28:02 -0500,
> Rob Herring <robh@...nel.org> a écrit :
> 
> 
> > >
> > > No, the kernel already maintains its own tree of devices. You just
> > > need to use that to generate the tree. That's really not much more
> > > than nodes with a 'reg' property encoding the device and function
> > > numbers.
> > >
> > > We already support matching a PCI device to a DT node. The PCI
> > > subsystem checks if there is a corresponding DT node for each PCI
> > > device created and sets the of_node pointer if there is. For
> > > OpenFirmware systems (PPC), there always is a node. For FDT, we
> > > generally don't have a node unless there are additional
> > > non-discoverable properties. Hikey960 is an example with PCI device
> > > nodes in the DT as it has a soldered down PCIe switch with downstream
> > > devices and non-discoverable properties (e.g. reset GPIO for each
> > > port).  
> > 
> > Here's a quick and dirty implementation creating DT nodes for PCI devices:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/pop-pci-nodes
> 
> Ok, thanks, after looking at the branch, it appears that you expect the
> PCI nodes matching the probed PCI devices should be created by the PCI
> subsystem itself. My previous comment saying that the node would be
> created by the PCI driver itself is then wrong and I understand what
> you meant.

As I said before, the driver could create its node and all the parents. 
I went with the other option partly because I didn't have a particular 
driver. That has the advantage of only creating necessary nodes and 
provides a way to trigger doing so. The issue with it is the timing of 
when the node gets set (after parent devices have probed).

> Then, there is still a bit of magic to do to correctly fill the ranges
> for translation and then the driver "simply" have to load the dtbo and
> apply it with of_overlay_fdt_apply().

The host bridge resource list should have all the information needed.

Rob