linux-kernel - Re: [PATCH v3 0/6] mips: dts: ralink: update system controller nodes and its consumers

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: <CAMhs-H91Pv4bygmL2jL0=swn-wHT0mRYGaYO6Hjm5O-xmmrJ0w@mail.gmail.com>
Date: Fri, 21 Feb 2025 17:40:34 +0100
From: Sergio Paracuellos <sergio.paracuellos@...il.com>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Cc: linux-clk@...r.kernel.org, sboyd@...nel.org, mturquette@...libre.com, 
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	matthias.bgg@...il.com, angelogioacchino.delregno@...labora.com, 
	p.zabel@...gutronix.de, linux-mips@...r.kernel.org, 
	devicetree@...r.kernel.org, yangshiji66@...look.com, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/6] mips: dts: ralink: update system controller nodes
 and its consumers

On Fri, Feb 21, 2025 at 4:37 PM Thomas Bogendoerfer
<tsbogend@...ha.franken.de> wrote:
>
> On Fri, Feb 21, 2025 at 03:50:09PM +0100, Sergio Paracuellos wrote:
> > Hi Thomas,
> >
> > On Fri, Feb 21, 2025 at 3:05 PM Thomas Bogendoerfer
> > <tsbogend@...ha.franken.de> wrote:
> > >
> > > On Fri, Feb 21, 2025 at 11:48:34AM +0100, Sergio Paracuellos wrote:
> > > > Hi Thomas,
> > > >
> > > > El El lun, 20 ene 2025 a las 10:21, Sergio Paracuellos <
> > > > sergio.paracuellos@...il.com> escribió:
> > > >
> > > > > Hi all!
> > > > >
> > > > > Ralinks SoCs have a system controller node which serves as clock and reset
> > > > > providers for the rest of the world. This patch series introduces clock
> > > > > definitions for these SoCs. The clocks are registered in the driver using
> > > > > a bunch of arrays in specific order so these definitions represent the
> > > > > assigned
> > > > > identifier that is used when this happens so client nodes can easily use it
> > > > > to specify the clock which they consume without the need of checking
> > > > > driver code.
> > > > >
> > > > > DTS files which are currently on tree are not matching system controller
> > > > > bindings. So all of them are updated to properly match them.
> > > > >
> > > > > I'd like this series to go through kernel mips git tree if possible.
> > > > >
> > > > > Thanks in advance for your time.
> > > > >
> > > > > Changes in v3:
> > > > > - Address Krzysztof comments in v2 (Thanks!):
> > > > >   + Drop reset include file since what it was defined there were hardware
> > > > >     constants and no binding related indexes at all.
> > > > >   + Update patches for not referring to this reset removed file.
> > > >
> > > >
> > > > I was expecting this series going through the mips tree.
> > >
> > >   DTC     arch/mips/boot/dts/ralink/rt3883_eval.dtb
> > > Error: /local/tbogendoerfer/korg/linux/arch/mips/boot/dts/ralink/rt3883.dtsi:2.1-9 syntax error
> > > FATAL ERROR: Unable to parse input tree
> >
> > Weird, it looks like dtc is not happy with the "include" line with new
> > definitions? Are you getting this only with rt3883? Since all the
> > patches are almost the same and I compile tested this before sending..
> > Something got corrupted? I don't have my laptop now to check but I
> > will recheck again on monday.
>
> rt2880_eval.dts:/include/ "rt2880.dtsi"
> rt3052_eval.dts:#include "rt3050.dtsi"
> rt3883_eval.dts:/include/ "rt3883.dtsi"
>
> rt3052 works, rt2880 and rt3883 don't.
>
> changing the /include/ to #include makes them compile.

Mmmm...does this mean that this was broken before my patches? Since I
have not touched the files that need the replacement. So I probably
checked in the openwrt tree and missed this totally. Sorry for that.
How do you want to handle this? Should I send v4 including these
replacements? Or do you prefer to handle them directly?

Thanks again and sorry for the inconvenience.

Best regards,
     Sergio Paracuellos
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]