linux-kernel - Re: [PATCH v5 2/4] backlight: add max25014atg backlight

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: <59c36699-ee54-467f-9342-6756a0092a98@gocontroll.com>
Date: Mon, 10 Nov 2025 11:03:27 +0100
From: Maud Spierings <maudspierings@...ontroll.com>
To: Daniel Thompson <daniel@...cstar.com>
Cc: Lee Jones <lee@...nel.org>, Daniel Thompson <danielt@...nel.org>,
 Jingoo Han <jingoohan1@...il.com>, Pavel Machek <pavel@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Helge Deller <deller@....de>,
 Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>, dri-devel@...ts.freedesktop.org,
 linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-fbdev@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 2/4] backlight: add max25014atg backlight

On 11/10/25 11:01, Daniel Thompson wrote:
> On Mon, Nov 10, 2025 at 09:40:07AM +0100, Maud Spierings wrote:
>> On 11/7/25 17:14, Daniel Thompson wrote:
>>> On Fri, Nov 07, 2025 at 01:49:59PM +0100, Maud Spierings via B4 Relay wrote:
>>>> +/**
>>>> + * @brief control the brightness with i2c registers
>>>> + *
>>>> + * @param regmap trivial
>>>> + * @param brt brightness
>>>> + * @return int
>>>> + */
>>>> +static int max25014_register_control(struct regmap *regmap, uint32_t brt)
>>>
>>> This isn't a good name for a function. It doesn't really say what it
>>> does. Please find a more descriptive name.
>>
>> Having a lot of difficulties find a succinct name that fits better,
>> max25014_register_brightness_control()?
>> max25014_i2c_brightness_control()?
> 
> I'd focus on what it does rather than how it does it meaning something
> like max25014_update_brightness() would work.
> 
> However, at present, this code is only called from
> max25014_update_status() so the simplest thing to do is to move the
> code into max25014_update_status() and remove this function entirely
> (then it doesn't matter what it is called ;-) ).
> 

Perhaps this could be seperated out if/when pwm functionality is 
implemented. I believe the brightness may also be controlled that way in 
hybrid mode, but I am not entirely sure.

> 
>>>> +/*
>>>> + * 1. disable unused strings
>>>> + * 2. set dim mode
>>>> + * 3. set initial brightness
>>>
>>> How does this code set the initial brightness? It doens't set the
>>> MAX25014_TON* registers.
>>
>> Yep forgot to remove that, I discovered the backlight core takes care of the
>> default brightness, so I removed it from here.
> 
> What do you mean by this? Are you sure you aren't relying on another
> driver to enable the backlight rather than the backlight core?

Not that I know of, there is the systemd backlight service, but I am 
pretty sure I can see it first turn on, then get switched to the old 
value by the systemd service. Unless the simple-panel driver controls 
it? The backlight is linked to that.

>>>> + * 4. set setting register
>>>> + * 5. enable the backlight
>>>> + */
>>>> +static int max25014_configure(struct max25014 *maxim)
> 
> 
>>>> +static int max25014_probe(struct i2c_client *cl)
>>>> <snip>
>>>> +
>>>> +	/* Enable can be tied to vin rail wait if either is available */
>>>> +	if (maxim->enable || maxim->vin) {
>>>> +		/* Datasheet Electrical Characteristics tSTARTUP 2ms */
>>>> +		usleep_range(2000, 2500);
>>>> +	}
>>>
>>> If you really want to keep the devm_regulator_get_optional() I guess
>>> maybe you could persuade me it's need to avoid this sleep... although
>>> I'd be fairly happy to remove the NULL checks here too!
>>
>> Just wait unconditionally?
> 
> If you think it will be unusual for the driver to be used without enable
> or regulator then it's ok to wait unconditionally (all examples you
> have added so far have an enable pin).

I think it may actually be a very common implementation to have the 
enable pin attached to Vin, we don't have it set up that way. But it is 
displayed that way in an example schematic in the datasheet.

Kind regards,
Maud