Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Svyatoslav Ryhel <clamor95@gmail.com>
Cc: "Lee Jones" <lee@kernel.org>,
	"Daniel Thompson" <danielt@kernel.org>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Pavel Machek" <pavel@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Helge Deller" <deller@gmx.de>, "Johan Hovold" <johan@kernel.org>,
	dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-iio@vger.kernel.org, linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v2 2/6] mfd: lm3533: Convert to use OF bindings
Date: Thu, 28 May 2026 15:50:01 +0100	[thread overview]
Message-ID: <20260528155001.2bcb7003@jic23-huawei> (raw)
In-Reply-To: <20260528135123.103745-3-clamor95@gmail.com>

On Thu, 28 May 2026 16:51:19 +0300
Svyatoslav Ryhel <clamor95@gmail.com> wrote:

> Since there are no users of this driver via platform data, remove the
> platform data support and switch to using Device Tree bindings.
> Additionally, optimize functions used only by platform data.


At least the IIO ones would have made much the same amount of sense for
dt, just that they weren't having in the first place. I'd prefer that
as a precursor patch to make the rest much more readable.

> 
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>

I only looked in detail at the iio bit. A few changes requested.

> ---
>  drivers/iio/light/lm3533-als.c      |  95 ++++------
>  drivers/leds/leds-lm3533.c          |  51 ++++--
>  drivers/mfd/lm3533-core.c           | 268 ++++++++++------------------
>  drivers/video/backlight/lm3533_bl.c |  52 ++++--
>  include/linux/mfd/lm3533.h          |  51 +-----
>  5 files changed, 212 insertions(+), 305 deletions(-)
> 
> diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
> index 99f0b903018c..cbd337b73bd9 100644
> --- a/drivers/iio/light/lm3533-als.c
> +++ b/drivers/iio/light/lm3533-als.c

> @@ -714,59 +720,33 @@ static const struct attribute_group lm3533_als_attribute_group = {
>  	.attrs = lm3533_als_attributes
>  };
>  
> -static int lm3533_als_set_input_mode(struct lm3533_als *als, bool pwm_mode)
> +static int lm3533_als_setup(struct lm3533_als *als)
>  {
> -	u8 mask = LM3533_ALS_INPUT_MODE_MASK;
> -	u8 val;
> +	struct device *dev = &als->pdev.dev;
>  	int ret;
>  
> -	if (pwm_mode)
> -		val = mask;	/* pwm input */
> -	else
> -		val = 0;	/* analog input */
> -
> -	ret = lm3533_update(als->lm3533, LM3533_REG_ALS_CONF, val, mask);
> -	if (ret) {
> -		dev_err(&als->pdev->dev, "failed to set input mode %d\n",
> -								pwm_mode);
> -		return ret;
> -	}
> -
> -	return 0;
> -}
> -
> -static int lm3533_als_set_resistor(struct lm3533_als *als, u8 val)
> -{
> -	int ret;
> -
> -	if (val < LM3533_ALS_RESISTOR_MIN || val > LM3533_ALS_RESISTOR_MAX) {
> -		dev_err(&als->pdev->dev, "invalid resistor value\n");
> -		return -EINVAL;
> -	}
> -
> -	ret = lm3533_write(als->lm3533, LM3533_REG_ALS_RESISTOR_SELECT, val);
> -	if (ret) {
> -		dev_err(&als->pdev->dev, "failed to set resistor\n");
> -		return ret;
> -	}
> +	device_property_read_u32(dev, "ti,resistor-value-ohm",
> +				 &als->r_select);
Does this have a default?  If so the pattern we've recently be setting on for IIO
is
	if (device_property_present(dev, "ti,resistor-value-ohm"))
		ret = device_property_read_u32();
		if (ret) //corrupt property in some fashion
			return ret;
	} else {
		//set default
	}
If there is no default then check it unconditionally.

>  
> -	return 0;
> -}
> +	als->r_select = clamp(als->r_select, LM3533_ALS_RESISTOR_MIN,
> +			      LM3533_ALS_RESISTOR_MAX);
> +	als->r_select = DIV_ROUND_UP(2 * MICRO, 10 * als->r_select);
>  
> -static int lm3533_als_setup(struct lm3533_als *als,
> -			    const struct lm3533_als_platform_data *pdata)
> -{
> -	int ret;
> +	als->pwm_mode = device_property_read_bool(dev, "ti,pwm-mode");
>  
> -	ret = lm3533_als_set_input_mode(als, pdata->pwm_mode);
> +	ret = lm3533_update(lm3533, LM3533_REG_ALS_CONF, als->pwm_mode ?
> +			    LM3533_ALS_INPUT_MODE_MASK : 0,

That's ugly.  Better as

	ret = lm3533_update(lm3533, LM3533_REG_ALS_CONF,
			    als->pwm_mode ? LM3533_ALS_INPUT_MODE_MASK : 0,

Though if there wasn't a layer hiding the regmap, it could just have been

	ret = regmap_assign_bits(lm3533->regmap, LM3533_REG_ALS_CONF,
				 LM3533_ALS_INPUT_MODE_MASK, als->pwm_mode);;

which would have been nicer.

I'm not particularly keen on the swashing of the helpers being in a patch
that is about switching the binding type as feels largely unrelated.
Should really have been a precursor, easier to review patch.


> +			    LM3533_ALS_INPUT_MODE_MASK);
>  	if (ret)
> -		return ret;
> +		return dev_err_probe(dev, ret, "failed to set input mode %d\n",
> +				     als->pwm_mode);
>  
>  	/* ALS input is always high impedance in PWM-mode. */
> -	if (!pdata->pwm_mode) {
> -		ret = lm3533_als_set_resistor(als, pdata->r_select);
> +	if (!als->pwm_mode) {
> +		ret = lm3533_write(lm3533, LM3533_REG_ALS_RESISTOR_SELECT,
> +				   (u8)als->r_select);

Same applies here. Mostly an unrelated change as the only thing switching that
is related to the patch is one parameter.

>  		if (ret)
> -			return ret;
> +			return dev_err_probe(dev, ret, "failed to set resistor\n");
>  	}
>  
>  	return 0;

> @@ -852,25 +825,28 @@ static int lm3533_als_probe(struct platform_device *pdev)
>  	indio_dev->channels = lm3533_als_channels;
>  	indio_dev->num_channels = ARRAY_SIZE(lm3533_als_channels);
>  	indio_dev->name = dev_name(&pdev->dev);
> -	iio_device_set_parent(indio_dev, pdev->dev.parent);

I'm not sure why this was there in the first place.  Hence not sure if it
is safe to remove.


> diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
> index 45795f2a1042..d707d43d5526 100644
> --- a/drivers/leds/leds-lm3533.c
> +++ b/drivers/leds/leds-lm3533.c

>  
>  	led->cb.dev = led->cdev.dev;
>  
> -	ret = lm3533_led_setup(led, pdata);
> +	device_property_read_u32(&pdev->dev, "led-max-microamp",
> +				 &led->max_current);

I'd prefer explicit setting of the default to be visible before this, or
the property_present pattern I mention in the IIO review above.

> +	led->max_current = clamp(led->max_current, LM3533_LED_MAX_CURRENT_MIN,
> +				 LM3533_LED_MAX_CURRENT_MAX);

I didn't look any further (busy day!)

  reply	other threads:[~2026-05-28 14:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28 13:51 [PATCH v2 0/6] mfd: lm3533: convert to OF bindings, improve support Svyatoslav Ryhel
2026-05-28 13:51 ` [PATCH v2 1/6] dt-bindings: leds: Document TI LM3533 LED controller Svyatoslav Ryhel
2026-05-28 14:54   ` Jonathan Cameron
2026-05-29  9:51   ` Daniel Thompson
2026-05-29 10:07     ` Svyatoslav Ryhel
2026-05-29 10:46       ` Daniel Thompson
2026-05-29 10:56         ` Svyatoslav Ryhel
2026-05-28 13:51 ` [PATCH v2 2/6] mfd: lm3533: Convert to use OF bindings Svyatoslav Ryhel
2026-05-28 14:50   ` Jonathan Cameron [this message]
2026-05-28 15:03     ` Svyatoslav Ryhel
2026-05-29  9:08       ` Jonathan Cameron
2026-05-29  9:39         ` Svyatoslav Ryhel
2026-05-29 10:48           ` Jonathan Cameron
2026-05-29 11:02             ` Svyatoslav Ryhel
2026-05-29 13:10               ` Jonathan Cameron
2026-05-29 11:00   ` Daniel Thompson
2026-05-29 11:06     ` Svyatoslav Ryhel
2026-05-28 13:51 ` [PATCH v2 3/6] mfd: lm3533: Add support for VIN power supply Svyatoslav Ryhel
2026-05-28 13:51 ` [PATCH v2 4/6] mfd: lm3533: Set DMA mask Svyatoslav Ryhel
2026-05-28 13:51 ` [PATCH v2 5/6] video: backlight: lm3533_bl: Set initial mapping mode from DT Svyatoslav Ryhel
2026-05-29 11:10   ` Daniel Thompson
2026-05-29 11:17     ` Svyatoslav Ryhel
2026-05-29 11:40       ` Daniel Thompson
2026-05-28 13:51 ` [PATCH v2 6/6] video: leds: backlight: lm3533: Support getting LED sources " Svyatoslav Ryhel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260528155001.2bcb7003@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=clamor95@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=danielt@kernel.org \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=johan@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=pavel@kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox