On Fri, Feb 21, 2025 at 05:40:34PM +0100, Sergio Paracuellos wrote: > On Fri, Feb 21, 2025 at 4:37 PM Thomas Bogendoerfer > <tsbogend@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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. no, without your patches everything compiles. I guess dtc (?) doesn't allow #include in files, which were included via / include /. But that's just guesswork 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? I'll fix the includes while applying. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
