linux-kernel - Re: [PATCH 1/2] misc: lan966x_pci: Fix dtc warns 'missing or empty reg/ranges property'

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: <CAL_Jsq+_VHsMKufVwUj3Q0pv1X6d8Xe0FN6A9svCmWJ3cuuUqQ@mail.gmail.com>
Date: Mon, 28 Oct 2024 14:52:09 -0500
From: Rob Herring <robh@...nel.org>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Philipp Zabel <p.zabel@...gutronix.de>, Stephen Rothwell <sfr@...b.auug.org.au>, 
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org, 
	Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Allan Nielsen <allan.nielsen@...rochip.com>, Horatiu Vultur <horatiu.vultur@...rochip.com>, 
	Steen Hegelund <steen.hegelund@...rochip.com>, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 1/2] misc: lan966x_pci: Fix dtc warns 'missing or empty
 reg/ranges property'

On Mon, Oct 28, 2024 at 12:43 PM Herve Codina <herve.codina@...tlin.com> wrote:
>
> Hi Rob,
>
> On Mon, 28 Oct 2024 08:55:24 -0500
> Rob Herring <robh@...nel.org> wrote:
>
> > On Mon, Oct 28, 2024 at 7:24 AM Herve Codina <herve.codina@...tlin.com> wrote:
> > >
> > > dtc generates the following warnings when building the LAN966x device
> > > tree overlay (lan966x_pci.dtso):
> > >   Warning (simple_bus_reg): /fragment@..._overlay__/pci-ep-bus@...pu_clk: missing or empty reg/ranges property
> > >   Warning (simple_bus_reg): /fragment@..._overlay__/pci-ep-bus@...dr_clk: missing or empty reg/ranges property
> > >   Warning (simple_bus_reg): /fragment@..._overlay__/pci-ep-bus@...ys_clk: missing or empty reg/ranges property
> > >
> > > Indeed, related nodes are under the pci-ep-bus (simple-bus) which is not
> > > correct.
> > >
> > > Put them outside this node.
> > >
> > > Reported-by: Stephen Rothwell <sfr@...b.auug.org.au>
> > > Closes: https://lore.kernel.org/all/20241025110919.64b1cffb@canb.auug.org.au/
> > > Fixes: 185686beb464 ("misc: Add support for LAN966x PCI device")
> > > Signed-off-by: Herve Codina <herve.codina@...tlin.com>
> > > ---
> > > The referenced commit is in the reset tree
> > > ---
> > >  drivers/misc/lan966x_pci.dtso | 36 +++++++++++++++++------------------
> > >  1 file changed, 18 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/misc/lan966x_pci.dtso b/drivers/misc/lan966x_pci.dtso
> > > index 7282687df25f..5466d013da7d 100644
> > > --- a/drivers/misc/lan966x_pci.dtso
> > > +++ b/drivers/misc/lan966x_pci.dtso
> > > @@ -19,6 +19,24 @@ __overlay__ {
> > >                         #address-cells = <3>;
> > >                         #size-cells = <2>;
> > >
> > > +                       cpu_clk: cpu_clk {
> >
> > Preferred node name is "clock-<freq-in-hz>"
>
> I based the name on the lan966x.dtsi
> https://elixir.bootlin.com/linux/v6.12-rc1/source/arch/arm/boot/dts/microchip/lan966x.dtsi#L38

That should be fixed too.

> Of course, I can rename the cpu_clk, ddr_clk and sys_clk nodes but this will create
> a difference against lan966x.dtsi on some points that should be identical.

Then maybe they should be sharing a .dtsi?

> Let me know with that in mind if I need to rename those nodes in this series.

Yes, easier now than later.

> > Also, as a general rule, don't use "_" in node names (and properties).
> >
> > Isn't there a schema for the device which needs these nodes added to
> > it? If not, there should be.
> >
>
> No, there is no schema yet for this device.
>
> How can we describe schema for this kind of devices that are using
> device-tree overlays?

Describing is not the issue. Running the checks is. Though you can run
the checks at runtime.

> I mean, this overlay is applied on a PCI device DT node. This DT node is
> computed at runtime. It is, in the end, available in the base DT before
> applying the overlay.
> The compatible string that could be used to check the dtso against schema
> cannot be set in the overlay (at least not at the correct place in the
> hierarchy) without causing a property memory leak at runtime. An overlay
> cannot add a property in a base DT node without generating a memory leak
> and so, we avoid adding such properties in the base DT from the overlay.

That's a problem with overlays in general which we need to solve at some point.

> Is this missing schema blocking for this series ?

No.

Rob