Thread (5 messages) 5 messages, 2 authors, 2025-02-21

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

From: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Date: 2025-02-21 16:40:43
Also in: linux-clk, linux-mips, lkml

On Fri, Feb 21, 2025 at 4:37 PM Thomas Bogendoerfer
[off-list ref] wrote:
On Fri, Feb 21, 2025 at 03:50:09PM +0100, Sergio Paracuellos wrote:
quoted
Hi Thomas,

On Fri, Feb 21, 2025 at 3:05 PM Thomas Bogendoerfer
[off-list ref] wrote:
quoted
On Fri, Feb 21, 2025 at 11:48:34AM +0100, Sergio Paracuellos wrote:
quoted
Hi Thomas,

El El lun, 20 ene 2025 a las 10:21, Sergio Paracuellos <
sergio.paracuellos@gmail.com> escribió:
quoted
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 ]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help