public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: "Otto Pflüger" <otto.pflueger@abscue.de>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Orson Zhai <orsonzhai@gmail.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Chunyan Zhang <zhang.lyra@gmail.com>,
	Pavel Machek <pavel@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Sebastian Reichel <sre@kernel.org>,
	linux-rtc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH 4/6] mfd: sprd-sc27xx: Switch to devm_mfd_add_devices()
Date: Wed, 25 Mar 2026 11:22:28 +0000	[thread overview]
Message-ID: <20260325112228.GF2902881@google.com> (raw)
In-Reply-To: <ab2i6i2D5q0t0xZ5@abscue.de>

> Could you clarify what should be changed?

Sure.

> On Mon, Mar 09, 2026 at 06:58:56PM +0000, Lee Jones wrote:
> > On Sun, 22 Feb 2026, Otto Pflüger wrote:
> > 
> > > To allow instantiating subdevices such as the regulator and poweroff
> > > devices that do not have corresponding device tree nodes with a
> > > "compatible" property, use devm_mfd_add_devices() with MFD cells instead
> > > of devm_of_platform_populate(). Since different PMICs in the SC27xx
> > > series contain different components, use separate MFD cell tables for
> > > each PMIC model. Define cells for all components that have upstream
> > > drivers at this point.
> > 
> > We're not passing one device registration API's data (MFD)
> > through another (Device Tree).
> > 
> > Pass an identifier through and match on that instead.
> > 
> > Look at how all of the other drivers in MFD do it.
> >
> > [...]
> > > +static const struct mfd_cell sc2730_devices[] = {
> > > +	MFD_CELL_OF("sc2730-adc", NULL, NULL, 0, 0, "sprd,sc2730-adc"),
> > > +	MFD_CELL_OF("sc2730-bltc", NULL, NULL, 0, 0, "sprd,sc2730-bltc"),
> > > +	MFD_CELL_OF("sc2730-efuse", NULL, NULL, 0, 0, "sprd,sc2730-efuse"),
> > > +	MFD_CELL_OF("sc2730-eic", NULL, NULL, 0, 0, "sprd,sc2730-eic"),
> > > +	MFD_CELL_OF("sc2730-fgu", NULL, NULL, 0, 0, "sprd,sc2730-fgu"),
> > > +	MFD_CELL_OF("sc2730-rtc", NULL, NULL, 0, 0, "sprd,sc2730-rtc"),
> > > +	MFD_CELL_OF("sc2730-vibrator", NULL, NULL, 0, 0, "sprd,sc2730-vibrator"),
> > > +};
> > > +
> > > +static const struct mfd_cell sc2731_devices[] = {
> > > +	MFD_CELL_OF("sc2731-adc", NULL, NULL, 0, 0, "sprd,sc2731-adc"),
> > > +	MFD_CELL_OF("sc2731-bltc", NULL, NULL, 0, 0, "sprd,sc2731-bltc"),
> > > +	MFD_CELL_OF("sc2731-charger", NULL, NULL, 0, 0, "sprd,sc2731-charger"),
> > > +	MFD_CELL_OF("sc2731-efuse", NULL, NULL, 0, 0, "sprd,sc2731-efuse"),
> > > +	MFD_CELL_OF("sc2731-eic", NULL, NULL, 0, 0, "sprd,sc2731-eic"),
> > > +	MFD_CELL_OF("sc2731-fgu", NULL, NULL, 0, 0, "sprd,sc2731-fgu"),
> > > +	MFD_CELL_NAME("sc2731-poweroff"),
> > > +	MFD_CELL_NAME("sc2731-regulator"),
> > > +	MFD_CELL_OF("sc2731-rtc", NULL, NULL, 0, 0, "sprd,sc2731-rtc"),
> > > +	MFD_CELL_OF("sc2731-vibrator", NULL, NULL, 0, 0, "sprd,sc2731-vibrator"),
> > >  };
> 
> Assuming that these tables are the "registration API's data", I don't
> see where it is being passed through the device tree. The device tree
> contains nodes for some of these MFD components, and I've listed their
> compatibles here so that the MFD core finds these nodes and registers
> them with the corresponding devices (which was previously done
> automatically by devm_of_platform_populate).
> 
> > >  
> > >  /*
> > > @@ -59,12 +84,16 @@ static const struct sprd_pmic_data sc2730_data = {
> > >  	.irq_base = SPRD_SC2730_IRQ_BASE,
> > >  	.num_irqs = SPRD_SC2730_IRQ_NUMS,
> > >  	.charger_det = SPRD_SC2730_CHG_DET,
> > > +	.cells = sc2730_devices,
> > > +	.num_cells = ARRAY_SIZE(sc2730_devices),

Remove these from here.

Either replace them with an ID that you can match on or stop passing
'sc2730_data' through .data and pass an ID through there instead.  Then
choose 'sc2730_data' and 'sc2730_devices' in an switch() statement
instead, just like the vast majority of existing MFD drivers do.

> > >  };
> > >  
> > >  static const struct sprd_pmic_data sc2731_data = {
> > >  	.irq_base = SPRD_SC2731_IRQ_BASE,
> > >  	.num_irqs = SPRD_SC2731_IRQ_NUMS,
> > >  	.charger_det = SPRD_SC2731_CHG_DET,
> > > +	.cells = sc2731_devices,
> > > +	.num_cells = ARRAY_SIZE(sc2731_devices),
> > >  };
> 
> Here I am simply referencing the tables above in the device-specific
> MFD data. These structs containing device-specific data already exist,
> they are private to the MFD driver, and I wouldn't consider them part
> of the device tree.
> 
> I've looked at mt6397-core.c and it seems to be doing the exact same
> thing with its "struct chip_data".

That was a momentary oversight.  It's also passing a driver-level
call-back which I despise.  However, past mistakes are not good
justifications for new ones.

> Some other drivers use a numeric ID
> for this purpose, but how would that be different from a pointer as long
> as it identifies the same data within the MFD driver?

The point is that sc2731_data->cells would be passed through the Device
Tree's .data attribute, which is not allowed.

-- 
Lee Jones [李琼斯]

  reply	other threads:[~2026-03-25 11:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-22 13:16 [PATCH 0/6] mfd: sc27xx: Use MFD cells and devm_mfd_add_devices() Otto Pflüger
2026-02-22 13:16 ` [PATCH 1/6] dt-bindings: rtc: sc2731: Add compatible for SC2730 Otto Pflüger
2026-03-05 23:51   ` Rob Herring (Arm)
2026-02-22 13:16 ` [PATCH 2/6] dt-bindings: leds: " Otto Pflüger
2026-03-05 23:51   ` Rob Herring (Arm)
2026-03-09 18:54   ` (subset) " Lee Jones
2026-02-22 13:16 ` [PATCH 3/6] regulator: dt-bindings: sc2731: Deprecate compatible property Otto Pflüger
2026-03-02 16:28   ` Mark Brown
2026-03-05 23:53   ` Rob Herring (Arm)
2026-02-22 13:16 ` [PATCH 4/6] mfd: sprd-sc27xx: Switch to devm_mfd_add_devices() Otto Pflüger
2026-03-09 18:58   ` Lee Jones
2026-03-20 19:41     ` Otto Pflüger
2026-03-25 11:22       ` Lee Jones [this message]
2026-02-22 13:16 ` [PATCH 5/6] power: reset: sc27xx: Add platform_device_id table Otto Pflüger
2026-03-03  0:00   ` Sebastian Reichel
2026-02-22 13:16 ` [PATCH 6/6] regulator: sc2731: " Otto Pflüger
2026-03-02 16:06   ` Mark Brown

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=20260325112228.GF2902881@google.com \
    --to=lee@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=orsonzhai@gmail.com \
    --cc=otto.pflueger@abscue.de \
    --cc=pavel@kernel.org \
    --cc=robh@kernel.org \
    --cc=sre@kernel.org \
    --cc=zhang.lyra@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