On Mon, Jun 02, 2025 at 03:04:54PM +0300, Eugen Hristev wrote:
> 
> 
> On 5/28/25 03:01, Tom Rini wrote:
> > We have this binding file in both include/dt-bindings/ and
> > dts/upstream/include/dt-bindings. These files are identical save for the
> > fact that we do not have commit adb2424d0d05 ("dt-bindings: clock: add
> > clock definitions for Ralink SoCs") from the kernel applied. However,
> > this change is rather important and should not have been omitted here
> > most likely. Remove our local copy to get in sync with upstream now.
> > 
> > Signed-off-by: Tom Rini <tr...@konsulko.com>
> > ---
> > Cc: Eugen Hristev <eugen.hris...@linaro.org>
> > Cc: Mihai Sain <mihai.s...@microchip.com>
> > 
> > The full kernel commit log is at
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b3292852863215825f88905b9dbafc3101e1d7e
> > and so this sounds very important. Please let me know if this should go
> > in master for v2025.07 (or Eugen, please pick it and send a PR). Thanks!
> 
> Hi Tom,
> 
> I do not see the connection with the Ralink SoCs. Maybe wrong commit
> referenced ?

Erm, the kernel link for me is "pinctrl: at91: Enable slewrate by
default on SAM9X60".

> Anyway, on the slewrate bits, as of today we have DIS==0 and ENA==1 and
> the driver treats them the same way. Hence DTs with DIS flag will have
> the bit erased in the register
> 
> With the kernel bindings file, DIS==1 and ENA==0, but the driver still
> considers DIS==0 and ENA==1 , so the DTs that have DIS as flags will get
> the bit written in the register.
> 
> If we also port the driver patch then the driver will also consider
> DIS==1 and ENA==0 , so the DTs with DIS flag will get the bit written in
> the register.
> 
> So there is an important change by changing the bits values, as the
> register eventually ends up with a different value.
> The driver patch apparently just interprets the DIS/ENA bits
> differently, but the end result is the same
> 
> Please correct me if my logic is wrong.
> 
> I would also believe testing on the sam9x60 would be required for the
> slew rate change. From what I remember back then, slew rate change was
> not needed in Uboot, but I might be wrong.

So, there's I guess two parts to all of this. First, yes it would be
good to test this change on real hardware and make sure things work as
expected. Second, yes, it looks like we need to make the parallel change
in drivers/pinctrl/pinctrl-at91.c (to match what the kernel did at the
time too) and we can't just remove the old binding file we need to
update them at the same time (since long term we need to remove all of
the old kernel dts stuff).  The final thing is that it really is
important to get them in sync as it's valid to pass our device tree to
the kernel to use. Can you take care of the changes here?  I don't have
hardware to test on, thanks.

-- 
Tom

Attachment: signature.asc
Description: PGP signature

Reply via email to