linux-kernel - Re: [PATCH 0/2] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20220324111631.64208e6a@fixe.home>
Date:   Thu, 24 Mar 2022 11:16:31 +0100
From:   Clément Léger <clement.leger@...tlin.com>
To:     Philipp Zabel <p.zabel@...gutronix.de>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Allan Nielsen <allan.nielsen@...rochip.com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/2] add fwnode support to reset subsystem

Le Thu, 24 Mar 2022 11:08:15 +0100,
Philipp Zabel <p.zabel@...gutronix.de> a écrit :

> >  - It can be used as a PCIe endpoint, connected to a separate platform
> >    that acts as the PCIe root complex. In this case, all the devices
> >    that are embedded on this SoC are exposed through PCIe BARs and the
> >    ARM64 cores of the SoC are not used. Since this is a PCIe card, it
> >    can be plugged on any platform, of any architecture supporting PCIe.
> > 
> > Appart from adding software node support, the fwnode API would also
> > allow to add ACPI support more easily later.  
> 
> Thank you for the explanation. So this would be used by the sparx5
> switch reset driver to provide the microchip,lan966x-switch-reset
> controller via software node?

Exactly.

> 
> If that needs to be converted to fwnode anyway, it would be nice to
> include the conversion in this series as an example.

Yes indeed, the sparx5 driver was modified in my private tree. I will
change it to use fwnode.

> 
> [...]
> > On that side, I must say I'm not really competent regarding ACPI
> > which I do not know enough to answer you on that point.
> > 
> > The discussions we had with Mark Brown regarding fwnode ACPI support
> > pointed out the fact that we should not create unwanted ACPI support
> > by using the same descriptions/specifications that exists for the
> > device-tree. In order to avoid that, we suggested to explicitely left
> > out ACPI with this fwnode support. This will allow to specify that
> > support later and integrate it in the subsystem that have been
> > converted to fwnode.  
> 
> Ok.
> 
> > > 
> > > On the other hand, I think it would be good to avoid the direct of_node
> > > assignment, possibly by letting devm_reset_controller_register()
> > > initialize of_node or fwnode from the device for most cases, and by
> > > adding of_reset_controller_register() and
> > > fwnode_reset_controller_register() variants that take the node as an
> > > argument for the rest.
> > > That could allow to eventually get rid of the of_node pointer.  
> > 
> > Ok, I see that. Do you want this to be done in this series ?  
> 
> Just thinking out loudly, before starting to drop the
> rcdev->of_node assigment from drivers en masse, I'd like to use the
> opportunity and turn reset_controller_register() and friends into
> macros that provide the module owner as a parameter, so the explicit
> rcdev->owner = THIS_MODULE assignment can be removed from the drivers
> as well.

Indeed, that seems like a good thing to do, direct assignments are often
a pain to change all other the place. BTW, once drivers are converted
to avoid direct assignment of the of_node field, it will be removable,
the fwnode field will be sufficient for all operations.

Thanks,

Clément

-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com