linux-kernel - Re: [PATCH v2] leds: lm3697: Rename struct into more appropriate name

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: <3f83953a-57ba-1fdc-f3ae-d3679e05474d@ti.com>
Date:   Mon, 12 Oct 2020 09:27:41 -0500
From:   Dan Murphy <dmurphy@...com>
To:     Marek Behun <kabel@...ckhole.sk>, Pavel Machek <pavel@....cz>
CC:     Gabriel David <ultracoolguy4@...tonmail.com>,
        <linux-leds@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] leds: lm3697: Rename struct into more appropriate name

Pavel

On 10/10/20 4:50 PM, Marek Behun wrote:
> On Sat, 10 Oct 2020 20:57:00 +0200
> Pavel Machek <pavel@....cz> wrote:
>
>> On Fri 2020-10-09 15:51:35, Gabriel David wrote:
>>> The mentioned struct, lm3697_led, was renamed to lm3697_bank since the
>>> structure is representing the control banks. This name, in my opinion,
>>> is more semantically correct. The pointers referring to it were also
>>> renamed.
>>> Signed-off-by: Gabriel David <ultracoolguy4@...tonmail.com>
>>> ---
>>> Yes, this is the same Gabriel David from ultracoolguy@...anota.org and
>>> ultracoolguy@...root.org. If you want me to confirm it I'll gladly do
>>> it.
>> No problem with that, and no need to resend. This can proably wait
>> for 5.11...
>>
>> I'd like some comment from Dan... and perhaps I'd want to understand
>> what the difference between LED and bank is.
>>
>> ...there can be more than one LED connected to the given bank, that's
>> what you are pointing out?
>>
>> ...but these LEDs will always work in unison, and they are handled as
>> single LED by Linux, right?
>>
> Pavel,
>
> the controller can connect 3 LED strips (to 3 different pins on the
> chip). There are 2 LED control banks (this is where you can set
> brightness). For each LED strip (each output pin) you can configure to
> which control bank it connects. So you have 3 LED strips and 2 control
> banks, that is 2^3 = 8 different configurations of connecting LED
> control bank to LED strip.
>
>  From the perspective of Linux you see the two control banks as 2 LED
> class devices (because you are setting brightness for control banks,
> not for the LED strips).

The way Marek explains it is correct and the way I wrote the driver 
intially.  There is no direct control of the LEDs only controlling the 2 
banks.

As an example a device can put LED string 1 and 2 on a single bank to 
control the backlight for a display and put LED string 3 on a different 
bank to control the backlight of a keyboard. Like in the Droid and Droid 
4 devices.  2 strings illuminate the display backlight and 1 string 
illuminates the keyboard the display backlight can have a independent 
brightness then the keyboard.

To me the name of the structure does not impose any functional changes 
just semantic changes.  And it just makes it a bit more difficult to 
back port functional fixes as this patch would be made mandatory for 
cherry picking.  But I do not get many requests to back port this driver 
so it maybe be a moot point.

Dan