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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DB0LM56C47LH.YYFY0ZGCVVKC@cknow.org>
Date: Tue, 01 Jul 2025 11:07:51 +0200
From: "Diederik de Haas" <didi.debian@...ow.org>
To: "Nicolas Frattaroli" <nicolas.frattaroli@...labora.com>, "Sebastian
 Reichel" <sebastian.reichel@...labora.com>
Cc: "Rob Herring" <robh@...nel.org>, "Krzysztof Kozlowski"
 <krzk+dt@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>, "Heiko
 Stuebner" <heiko@...ech.de>, <devicetree@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <linux-rockchip@...ts.infradead.org>,
 <kernel@...labora.com>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/3] arm64: dts: rockchip: adjust dcin regulator on ROCK
 4D

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


Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)