linux-kernel - Re: [PATCH v3 1/2] dt-bindings: Pinefeat cef168 lens control board

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: <20250819-lilac-harrier-of-saturation-323586@kuoka>
Date: Tue, 19 Aug 2025 10:21:42 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Conor Dooley <conor@...nel.org>
Cc: Aliaksandr Smirnou <support@...efeat.co.uk>, mchehab@...nel.org, 
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	devicetree@...r.kernel.org, linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: Pinefeat cef168 lens control board

On Mon, Aug 18, 2025 at 06:36:50PM +0100, Conor Dooley wrote:
> On Sun, Aug 17, 2025 at 02:05:48PM +0100, Aliaksandr Smirnou wrote:
> > Add the Device Tree schema and examples for the Pinefeat cef168 lens
> > control board. This board interfaces Canon EF & EF-S lenses with
> > non-Canon camera bodies, enabling electronic control of focus and
> > aperture via V4L2.
> > 
> 
> > Power supply is derived from fixed supplies via connector or GPIO
> > header. Therefore, the driver does not manage any regulator, so
> > representing any supply in the binding is redundant.
> 
> Wut? This doesn't make sense, you have supplies so they should be
> documented. The fact that they're shared with a bunch of other things on
> the SBC you're aiming the product at doesn't matter. What if someone

There is also some explanation at v2 discussion. I asked for that
because there is no known design (neither RPi or other boards having
compatible hat/connectors) which would have these supplies controllable.
Adding them now would mean you should make them also required (because
in fact they are), but since these are non-controllable there would be
just regulator-fixed with voltage and that's it. It's just bloat.

> doesn't use this sensor with an RPi and there is a dedicated regulator?

Unlikely but if ever such hardware appears, we can always add
regulators.

Best regards,
Krzysztof