linux-kernel - Re: [PATCH 2/4] backlight: ktz8866: add slave handler

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: <20250418181723.207795-1-mitltlatltl@gmail.com>
Date: Sat, 19 Apr 2025 02:17:16 +0800
From: Pengyu Luo <mitltlatltl@...il.com>
To: krzk@...nel.org
Cc: conor+dt@...nel.org,
	danielt@...nel.org,
	deller@....de,
	devicetree@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	jingoohan1@...il.com,
	krzk+dt@...nel.org,
	lee@...nel.org,
	linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-leds@...r.kernel.org,
	lujianhua000@...il.com,
	mitltlatltl@...il.com,
	pavel@...nel.org,
	robh@...nel.org
Subject: Re: [PATCH 2/4] backlight: ktz8866: add slave handler

On Tue, Apr 8, 2025 at 12:27 AM Daniel Thompson <daniel@...cstar.com> wrote:
> On Mon, Apr 07, 2025 at 05:51:17PM +0800, Pengyu Luo wrote:
> > Kinetic ktz8866, found in many android devices, nowadays, some oem use
> > dual ktz8866 to support a larger panel and  higher brightness, original
> > driver would only handle half backlight region on these devices,
> > registering it twice is unreasonable, so adding the slave handler to
> > support it.
> 
> Is there anything unique about KTZ8866 that allows it to be used like
> this? I think it would be better to add support for secondary backlight
> controllers into the backlight framework, rather than having to
> implement driver specific hacks for every backlight controller that
> appears in a primary/secondary configuration.
> 

According to my understanding, if I add the new api to backlight framework,
with a minimal modification, then I either do A or do B(I doubt it is my
fixed mindset)

A:
Tied two devices, registering the primary and the secondary device during
one probe, to do that, I access another KTZ8866 when probing. Those hack
is still here, that doesn't seem to help.

B:
Uncoupled, probing separately, the later one is registered as the
secondary one. Brightness control is a little uncoupled, there are two
sysfs, I doubt if userspace programs will write brightness to two
devices. Then we need synchronization, write primary => write primary
and write secondary, viceversa.

> Also, the kernel seeks to avoid adding new instances of master/slave
> terminology. See the coding style doc for suggested alternatives:
> https://www.kernel.org/doc/html/latest/process/coding-style.html#naming
> 

Agree.

Best wishes,
Pengyu