Linux LED subsystem development
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Lee Jones <lee@kernel.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Pavel Machek" <pavel@ucw.cz>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Anjelique Melendez" <quic_amelende@quicinc.com>,
	"Rob Herring" <robh@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Luca Weiss" <luca@z3ntu.xyz>,
	"Bjorn Andersson" <quic_bjorande@quicinc.com>,
	linux-leds@vger.kernel.org, kernel@pengutronix.de,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v3 102/108] leds: qcom-lpg: Make use of devm_pwmchip_alloc() function
Date: Wed, 22 Nov 2023 18:15:32 +0100	[thread overview]
Message-ID: <ZV43NHr1QN79lsaJ@orome.fritz.box> (raw)
In-Reply-To: <20231122115621.GK173820@google.com>

[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]

On Wed, Nov 22, 2023 at 11:56:21AM +0000, Lee Jones wrote:
> On Tue, 21 Nov 2023, Uwe Kleine-König wrote:
> 
> > This prepares the pwm sub-driver to further changes of the pwm core
> > outlined in the commit introducing devm_pwmchip_alloc(). There is no
> > intended semantical change and the driver should behave as before.
> > 
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> >  drivers/leds/rgb/leds-qcom-lpg.c | 30 +++++++++++++++++++++---------
> >  1 file changed, 21 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c
> > index 68d82a682bf6..283227e02df6 100644
> > --- a/drivers/leds/rgb/leds-qcom-lpg.c
> > +++ b/drivers/leds/rgb/leds-qcom-lpg.c
> > @@ -77,7 +77,7 @@ struct lpg {
> >  
> >  	struct mutex lock;
> >  
> > -	struct pwm_chip pwm;
> > +	struct pwm_chip *pwm;
> >  
> >  	const struct lpg_data *data;
> >  
> > @@ -977,9 +977,15 @@ static int lpg_pattern_mc_clear(struct led_classdev *cdev)
> >  	return lpg_pattern_clear(led);
> >  }
> >  
> > +static inline struct lpg *lpg_pwm_from_chip(struct pwm_chip *chip)
> > +{
> > +	struct lpg **lpg = pwmchip_priv(chip);
> > +	return *lpg;
> > +}
> 
> I don't have easy-vis into the other patches, but if this is a common
> pattern, perhaps add a generic helper in <linux/pwm.h>?
> 
> >  static int lpg_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> >  {
> > -	struct lpg *lpg = container_of(chip, struct lpg, pwm);
> > +	struct lpg *lpg = lpg_pwm_from_chip(chip);
> >  	struct lpg_channel *chan = &lpg->channels[pwm->hwpwm];
> >  
> >  	return chan->in_use ? -EBUSY : 0;
> > @@ -995,7 +1001,7 @@ static int lpg_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> >  static int lpg_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> >  			 const struct pwm_state *state)
> >  {
> > -	struct lpg *lpg = container_of(chip, struct lpg, pwm);
> > +	struct lpg *lpg = lpg_pwm_from_chip(chip);
> >  	struct lpg_channel *chan = &lpg->channels[pwm->hwpwm];
> >  	int ret = 0;
> >  
> > @@ -1026,7 +1032,7 @@ static int lpg_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> >  static int lpg_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> >  			     struct pwm_state *state)
> >  {
> > -	struct lpg *lpg = container_of(chip, struct lpg, pwm);
> > +	struct lpg *lpg = lpg_pwm_from_chip(chip);
> >  	struct lpg_channel *chan = &lpg->channels[pwm->hwpwm];
> >  	unsigned int resolution;
> >  	unsigned int pre_div;
> > @@ -1089,13 +1095,19 @@ static const struct pwm_ops lpg_pwm_ops = {
> >  
> >  static int lpg_add_pwm(struct lpg *lpg)
> >  {
> > +	struct pwm_chip *chip;
> >  	int ret;
> >  
> > -	lpg->pwm.dev = lpg->dev;
> > -	lpg->pwm.npwm = lpg->num_channels;
> > -	lpg->pwm.ops = &lpg_pwm_ops;
> > +	lpg->pwm = chip = devm_pwmchip_alloc(lpg->dev, lpg->num_channels,
> > +					     sizeof(&lpg));
> > +	if (IS_ERR(chip))
> > +		return PTR_ERR(chip);
> >  
> > -	ret = pwmchip_add(&lpg->pwm);
> > +	*(struct lpg **)pwmchip_priv(chip) = lpg;
> 
> This is vile!

Indeed. This highlights one of the weaker parts of this whole design and
I really don't like it. The whole chip_alloc() construct works fine if
you have everything isolated nicely in a single driver and subsystem
(like you usually have in network land), but for cases like this where
things are spread throughout and a device is actually more than just a
PWM controller, it looks like we now have to work around this design
because it doesn't fit.

In fact, this reminds me about the "midlayer mistake" in many ways and
combined with what Bartosz said, I'm not sure this is going to hold up
very well the more special cases we get.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-11-22 17:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21 13:49 [PATCH v3 000/108] pwm: Fix lifetime issues for pwm_chips Uwe Kleine-König
2023-11-21 13:50 ` [PATCH v3 102/108] leds: qcom-lpg: Make use of devm_pwmchip_alloc() function Uwe Kleine-König
2023-11-21 15:16   ` Lee Jones
2023-11-21 15:58     ` Uwe Kleine-König
2023-11-22 11:56   ` Lee Jones
2023-11-22 17:15     ` Thierry Reding [this message]
2023-11-23 10:44       ` Uwe Kleine-König
2023-11-24 12:27         ` Thierry Reding
2023-11-24 18:22           ` Uwe Kleine-König
2023-11-24 21:21             ` Bartosz Golaszewski
2023-11-22 17:54     ` Uwe Kleine-König
2023-11-23 10:21       ` Lee Jones
2023-11-23 10:54         ` Uwe Kleine-König

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=ZV43NHr1QN79lsaJ@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=conor.dooley@microchip.com \
    --cc=keescook@chromium.org \
    --cc=kernel@pengutronix.de \
    --cc=lee@kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=luca@z3ntu.xyz \
    --cc=pavel@ucw.cz \
    --cc=quic_amelende@quicinc.com \
    --cc=quic_bjorande@quicinc.com \
    --cc=robh@kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /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