Re: [PATCH 1/3] arm64: dts: rockchip: adjust dcin regulator on ROCK 4D

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

Hello,

On Tuesday, 1 July 2025 10:19:33 Central European Summer Time Diederik de Haas wrote:
> Hi,
> 
> On Tue Jul 1, 2025 at 1:10 AM CEST, Sebastian Reichel wrote:
> > On Mon, Jun 30, 2025 at 08:12:27PM +0200, Diederik de Haas wrote:
> >> On Mon Jun 30, 2025 at 5:36 PM CEST, Nicolas Frattaroli wrote:
> >> > The ROCK 4D's actual DC input is 5V, and the schematic names it as being
> >> > 5V as well.
> >> >
> >> > Rename the regulator, and change the voltage it claims to be at.
> >> 
> >> Shouldn't it have a fixes tag then? Providing 12V where 5V is expected
> >> sounds problematic ;-)
> >
> > This is basically "just" documentation, as the DT just describes
> > a fixed regulator (i.e. nothing software controllable). This just
> > changes a number in sysfs :)
> >
> > Note, that the 5V DCIN is a USB-C port, which does not do any PD
> > negotiation, but has the 5K1 resistors on the CC lines to "request"
> > 5V. If for whatever reason a higher voltage is applied (which does
> > not happen as long as the power is provided by anything remotely
> > following the USB specifications) there also is an over-voltage
> > protection chip. So it's not problematic :)
> 
> I was worried about and wondered why I/we did NOT receive reports about
> boards being fried. Good to know, thanks!
> 
> > OTOH adding a Fixes tag does not hurt ;)
> 
> Cheers,
>   Diederik
> 

to add to what Sebastian already said: I purposefully didn't include the
Fixes: tag because there is no functional change here. I don't think
cosmetic fixes are worth pulling into stable kernels unless they're a
dependency of a follow-up functional fix patch, which isn't the case
right now. If such a functional fix patch does emerge, it can explicitly
declare its dependence on this patch, or even have our robot overlords
figure it out itself.

In that sense, I do think a Fixes tag hurts, because it needlessly
adds to the patch queue of the stable kernel people, and it's worth
pointing out that while I claim this patch has no functional change,
that's always predicated on the understanding that it does not
unintentionally break anything. In this case the chance is essentially
zero though, but I won't bother re-rolling this for that tag alone.

Regards,
Nicolas Frattaroli