Re: [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode

[Dan Murphy]

Jacek

On 8/27/19 4:14 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 8/27/19 2:44 PM, Dan Murphy wrote:
> > Tony
> >
> > On 8/27/19 7:18 AM, Pavel Machek wrote:
> > > On Mon 2019-08-26 15:44:37, Tony Lindgren wrote:
> > > > * Pavel Machek <pavel@xxxxxx> [190826 22:14]:
> > > > > On Mon 2019-08-26 14:58:22, Tony Lindgren wrote:
> > > > > > Hi,
> > > > > >
> > > > > > * Dan Murphy <dmurphy@xxxxxx> [190820 19:53]:
> > > > > > > Fix the brightness control for I2C mode.  Instead of
> > > > > > > changing the full scale current register update the ALS target
> > > > > > > register for the appropriate banks.
> > > > > > >
> > > > > > > In addition clean up some code errors and random misspellings found
> > > > > > > during coding.
> > > > > > >
> > > > > > > Tested on Droid4 as well as LM3532 EVM connected to a BeagleBoneBlack
> > > > > > >
> > > > > > > Fixes: e37a7f8d77e1 ("leds: lm3532: Introduce the lm3532 LED driver")
> > > > > > > Reported-by: Pavel Machek <pavel@xxxxxx>
> > > > > > > Signed-off-by: Dan Murphy <dmurphy@xxxxxx>
> > > > > > > ---
> > > > > > >
> > > > > > > v3 - Removed register define updates -
> > > > > > > https://lore.kernel.org/patchwork/patch/1114542/
> > > > > > Looks like starting with this patch in Linux next the LCD on droid4
> > > > > > is so dim it's unreadable even with brightness set to 255. Setting
> > > > > > brightness to 0 does blank it completely though.
> > > > > >
> > > > > > Did something maybe break with the various patch revisions or are
> > > > > > we now missing some dts patch?
> > > > > Maybe missing dts patch. We should provide maximum current the LED can
> > > > > handle...
> > > > Or i2c control is somehow broken and only als control now works?
> > With only setting CONFIG_LEDS_LM3532=m to the next branch I get full
> > brightness with 255.
> >
> > I also see half brightness at 128 with the ramp down working.
> >
> > I am not able to reproduce this issue on my device.
> >
> > > Well, max current led is obviously missing. Plus code does not check
> > > the return from reading led-max-microamp.
> > led-max-microamp is optional so there is no need to check the return.
> It's also ugly to not check it when you have it assigned.
> We'll soon receive complaints from static checkers about pointless
> assignment.
>
> I'd distinguish between cases when parsing failed,
> and when property has not been provided.
>
> if (fwnode_property_present(child, "led-max-microamp")) {
> 	if (fwnode_property_read_u32(child, "led-max-microamp",
> 				&led->full_scale_current);
> 		dev_err(&priv->client->dev,
>                           "Failed to parse led-max-microamp property\n")

I am OK with doing this but I think the else case logging is extra.

Again the property is optional and if the user decides not to populate 
it then there should not

be a log of that it is missing.

Dan

> } else {
> 	dev_info(&priv->client->dev,
> 		 led-max-microamp property is missing\n")
> }
>
> > full_scale_current should be 0 if not populated and in the init only if
> > this variable is set does
> >
> > the code program the register otherwise it is default of 20.2 mA.