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

["Diederik de Haas" <didi.debian@cknow.org>]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

On Tue Jul 1, 2025 at 10:55 AM CEST, Nicolas Frattaroli wrote:
> On Tuesday, 1 July 2025 10:19:33 Central European Summer Time Diederik de Haas wrote:
>> 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 ;)
>
> 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

Then I agree with you. I didn't realize it was not a functional change.
I guess I didn't (fully) understand the "just documentation" remark.

Cheers,
  Diederik

> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]