public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Rosen Penev <rosenp@gmail.com>
Cc: linux-leds@vger.kernel.org, Pavel Machek <pavel@kernel.org>,
	Kees Cook <kees@kernel.org>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:KERNEL HARDENING (not covered by other
	areas):Keyword:b__counted_by(_le|_be)?b"
	<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH] leds: qcom-lpg: allocate channels with main struct
Date: Thu, 9 Apr 2026 18:02:50 +0100	[thread overview]
Message-ID: <20260409170250.GC3439476@google.com> (raw)
In-Reply-To: <CAKxU2N9xHS25zhcqwmOpXbgdMN-WDiOcDLTEgHs6WbqPuJ__dQ@mail.gmail.com>

On Thu, 09 Apr 2026, Rosen Penev wrote:

> On Thu, Apr 9, 2026 at 8:12 AM Lee Jones <lee@kernel.org> wrote:
> >
> > On Mon, 30 Mar 2026, Rosen Penev wrote:
> >
> > > Use a flexible array member to combine kzalloc and kcalloc. This
> > > required moving the struct lpg_channel definition up as flexible array
> > > members require a full definition.
> > >
> > > Add __counted_by for extra runtime analysis.
> > >
> > > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > > ---
> > >  drivers/leds/rgb/leds-qcom-lpg.c | 117 +++++++++++++++----------------
> > >  1 file changed, 56 insertions(+), 61 deletions(-)
> > >
> > > diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c
> > > index f6061c47f863..83cedf4a0cbf 100644
> > > --- a/drivers/leds/rgb/leds-qcom-lpg.c
> > > +++ b/drivers/leds/rgb/leds-qcom-lpg.c
> > > @@ -80,58 +80,8 @@
> > >  #define SDAM_PAUSE_HI_MULTIPLIER_OFFSET      0x8
> > >  #define SDAM_PAUSE_LO_MULTIPLIER_OFFSET      0x9
> > >
> > > -struct lpg_channel;
> > >  struct lpg_data;
> > >
> > > -/**
> > > - * struct lpg - LPG device context
> > > - * @dev:     pointer to LPG device
> > > - * @map:     regmap for register access
> > > - * @lock:    used to synchronize LED and pwm callback requests
> > > - * @pwm:     PWM-chip object, if operating in PWM mode
> > > - * @data:    reference to version specific data
> > > - * @lut_base:        base address of the LUT block (optional)
> > > - * @lut_size:        number of entries in the LUT block
> > > - * @lut_bitmap:      allocation bitmap for LUT entries
> > > - * @pbs_dev: PBS device
> > > - * @lpg_chan_sdam:   LPG SDAM peripheral device
> > > - * @lut_sdam:        LUT SDAM peripheral device
> > > - * @pbs_en_bitmap:   bitmap for tracking PBS triggers
> > > - * @triled_base: base address of the TRILED block (optional)
> > > - * @triled_src:      power-source for the TRILED
> > > - * @triled_has_atc_ctl:      true if there is TRI_LED_ATC_CTL register
> > > - * @triled_has_src_sel:      true if there is TRI_LED_SRC_SEL register
> > > - * @channels:        list of PWM channels
> > > - * @num_channels: number of @channels
> > > - */
> > > -struct lpg {
> > > -     struct device *dev;
> > > -     struct regmap *map;
> > > -
> > > -     struct mutex lock;
> > > -
> > > -     struct pwm_chip *pwm;
> > > -
> > > -     const struct lpg_data *data;
> > > -
> > > -     u32 lut_base;
> > > -     u32 lut_size;
> > > -     unsigned long *lut_bitmap;
> > > -
> > > -     struct pbs_dev *pbs_dev;
> > > -     struct nvmem_device *lpg_chan_sdam;
> > > -     struct nvmem_device *lut_sdam;
> > > -     unsigned long pbs_en_bitmap;
> > > -
> > > -     u32 triled_base;
> > > -     u32 triled_src;
> > > -     bool triled_has_atc_ctl;
> > > -     bool triled_has_src_sel;
> > > -
> > > -     struct lpg_channel *channels;
> > > -     unsigned int num_channels;
> > > -};
> > > -
> > >  /**
> > >   * struct lpg_channel - per channel data
> > >   * @lpg:     reference to parent lpg
> > > @@ -216,6 +166,55 @@ struct lpg_led {
> > >       struct lpg_channel *channels[] __counted_by(num_channels);
> > >  };
> > >
> > > +/**
> > > + * struct lpg - LPG device context
> > > + * @dev:     pointer to LPG device
> > > + * @map:     regmap for register access
> > > + * @lock:    used to synchronize LED and pwm callback requests
> > > + * @pwm:     PWM-chip object, if operating in PWM mode
> > > + * @data:    reference to version specific data
> > > + * @lut_base:        base address of the LUT block (optional)
> > > + * @lut_size:        number of entries in the LUT block
> > > + * @lut_bitmap:      allocation bitmap for LUT entries
> > > + * @pbs_dev: PBS device
> > > + * @lpg_chan_sdam:   LPG SDAM peripheral device
> > > + * @lut_sdam:        LUT SDAM peripheral device
> > > + * @pbs_en_bitmap:   bitmap for tracking PBS triggers
> > > + * @triled_base: base address of the TRILED block (optional)
> > > + * @triled_src:      power-source for the TRILED
> > > + * @triled_has_atc_ctl:      true if there is TRI_LED_ATC_CTL register
> > > + * @triled_has_src_sel:      true if there is TRI_LED_SRC_SEL register
> > > + * @channels:        list of PWM channels
> > > + * @num_channels: number of @channels
> > > + */
> >
> > Should we be reordering the kerneldoc descriptions for '@channels' and
> > '@num_channels' here to correctly match the updated order in the struct below?
> Yeah probably.
> >
> > > +struct lpg {
> > > +     struct device *dev;
> > > +     struct regmap *map;
> > > +
> > > +     struct mutex lock;
> > > +
> > > +     struct pwm_chip *pwm;
> > > +
> > > +     const struct lpg_data *data;
> > > +
> > > +     u32 lut_base;
> > > +     u32 lut_size;
> > > +     unsigned long *lut_bitmap;
> > > +
> > > +     struct pbs_dev *pbs_dev;
> > > +     struct nvmem_device *lpg_chan_sdam;
> > > +     struct nvmem_device *lut_sdam;
> > > +     unsigned long pbs_en_bitmap;
> > > +
> > > +     u32 triled_base;
> > > +     u32 triled_src;
> > > +     bool triled_has_atc_ctl;
> > > +     bool triled_has_src_sel;
> > > +
> > > +     unsigned int num_channels;
> > > +     struct lpg_channel channels[] __counted_by(num_channels);
> > > +};
> > > +
> > >  /**
> > >   * struct lpg_channel_data - per channel initialization data
> > >   * @sdam_offset:     Channel offset in LPG SDAM
> > > @@ -1475,12 +1474,6 @@ static int lpg_init_channels(struct lpg *lpg)
> > >       struct lpg_channel *chan;
> > >       int i;
> > >
> > > -     lpg->num_channels = data->num_channels;
> > > -     lpg->channels = devm_kcalloc(lpg->dev, data->num_channels,
> > > -                                  sizeof(struct lpg_channel), GFP_KERNEL);
> > > -     if (!lpg->channels)
> > > -             return -ENOMEM;
> > > -
> > >       for (i = 0; i < data->num_channels; i++) {
> > >               chan = &lpg->channels[i];
> > >
> > > @@ -1603,18 +1596,20 @@ static int lpg_init_sdam(struct lpg *lpg)
> > >
> > >  static int lpg_probe(struct platform_device *pdev)
> > >  {
> > > +     const struct lpg_data *data;
> > >       struct lpg *lpg;
> > >       int ret;
> > >       int i;
> > >
> > > -     lpg = devm_kzalloc(&pdev->dev, sizeof(*lpg), GFP_KERNEL);
> > > +     data = of_device_get_match_data(&pdev->dev);
> > > +     if (!data)
> > > +             return -EINVAL;
> > > +
> > > +     lpg = devm_kzalloc(&pdev->dev, struct_size(lpg, channels, data->num_channels), GFP_KERNEL);
> > >       if (!lpg)
> > >               return -ENOMEM;
> > >
> > > -     lpg->data = of_device_get_match_data(&pdev->dev);
> >
> > You just NULL-ptr-derefed yourself.  Did you test this?
> This can never return NULL. All compatible entries have a
> corresponding data value pointing to a statically allocated struct.

Where is lpg->data now set?

-- 
Lee Jones [李琼斯]

      reply	other threads:[~2026-04-09 17:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 21:18 [PATCH] leds: qcom-lpg: allocate channels with main struct Rosen Penev
2026-04-09 15:12 ` Lee Jones
2026-04-09 16:42   ` Rosen Penev
2026-04-09 17:02     ` Lee Jones [this message]

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=20260409170250.GC3439476@google.com \
    --to=lee@kernel.org \
    --cc=gustavoars@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@kernel.org \
    --cc=rosenp@gmail.com \
    /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