From: "Nuno Sá" <noname.nuno@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "Lee Jones" <lee@kernel.org>,
nuno.sa@analog.com, linux-gpio@vger.kernel.org,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-input@vger.kernel.org, "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Bartosz Golaszewski" <brgl@bgdev.pl>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Liu Ying" <victor.liu@nxp.com>
Subject: Re: [PATCH v3 02/22] mfd: adp5585: only add devices given in FW
Date: Tue, 13 May 2025 16:37:49 +0100 [thread overview]
Message-ID: <bbbd7ec7818f9dbcb753e2e47f03fe820489adce.camel@gmail.com> (raw)
In-Reply-To: <20250513151948.GA23592@pendragon.ideasonboard.com>
On Tue, 2025-05-13 at 17:19 +0200, Laurent Pinchart wrote:
> On Tue, May 13, 2025 at 04:02:11PM +0100, Nuno Sá wrote:
> > On Tue, 2025-05-13 at 15:34 +0100, Lee Jones wrote:
> > > On Mon, 12 May 2025, Nuno Sá via B4 Relay wrote:
> > >
> > > > From: Nuno Sá <nuno.sa@analog.com>
> > > >
> > > > Not all devices (features) of the adp5585 device are mandatory to be
> > > > used in all platforms. Hence, check what's given in FW and dynamically
> > > > create the mfd_cell array to be given to devm_mfd_add_devices().
> > > >
> > > > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > > > ---
> > > > drivers/mfd/adp5585.c | 45 +++++++++++++++++++++++++++++++++++++++++---
> > > > -
> > > > 1 file changed, 41 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/mfd/adp5585.c b/drivers/mfd/adp5585.c
> > > > index
> > > > 160e0b38106a6d78f7d4b7c866cb603d96ea673e..02f9e8c1c6a1d8b9516c060e0024d6
> > > > 9886
> > > > e9fb7a 100644
> > > > --- a/drivers/mfd/adp5585.c
> > > > +++ b/drivers/mfd/adp5585.c
> > > > @@ -17,7 +17,13 @@
> > > > #include <linux/regmap.h>
> > > > #include <linux/types.h>
> > > >
> > > > -static const struct mfd_cell adp5585_devs[] = {
> > > > +enum {
> > > > + ADP5585_DEV_GPIO,
> > > > + ADP5585_DEV_PWM,
> > > > + ADP5585_DEV_MAX
> > > > +};
> > > > +
> > > > +static const struct mfd_cell adp5585_devs[ADP5585_DEV_MAX] = {
> > > > { .name = "adp5585-gpio", },
> > > > { .name = "adp5585-pwm", },
> > > > };
> > > > @@ -110,12 +116,40 @@ static const struct regmap_config
> > > > adp5585_regmap_configs[] = {
> > > > },
> > > > };
> > > >
> > > > +static int adp5585_parse_fw(struct device *dev, struct adp5585_dev
> > > > *adp5585,
> > > > + struct mfd_cell **devs)
> > > > +{
> > > > + unsigned int has_pwm = 0, has_gpio = 0, rc = 0;
> > > > +
> > > > + if (device_property_present(dev, "#pwm-cells"))
> > > > + has_pwm = 1;
> > >
> > > This is a little sloppy. Instead of using throwaway local variables, do
> > > what you're going to do in the if statement.
> >
> > Then I would need to realloc my device cells... But as I realized below,
> > this is
> > indeed not needed.
> >
> > > > + if (device_property_present(dev, "#gpio-cells"))
> > > > + has_gpio = 1;
> > > > +
> > > > + if (!has_pwm && !has_gpio)
> > > > + return -ENODEV;
> > >
> > > Are we really dictating which child devices to register based on random
> > > DT properties? Why not register them anyway and have them fail if the
>
> The properties are not random.
>
> > > information they need is not available? Missing / incorrect properties
> > > usually get a -EINVAL.
> >
> > Well, this was something Laurent asked for... In the previous version I was
> > registering all the devices unconditionally.
>
> Registering them all means we'll get error messages in the kernel log
> when the corresponding drivers will probe, while nothing is actually
> wrong. That's fairly confusing for the user.
>
> In an ideal situation we would have child nodes in DT and only register
> child devices for existing child nodes. Unfortunately the DT bindings
> were not designed that way, so we have to live with the current
> situation.
>
> > > > + *devs = devm_kcalloc(dev, has_pwm + has_gpio, sizeof(struct
> > > > mfd_cell),
> > > > + GFP_KERNEL);
> > > > + if (!*devs)
> > > > + return -ENOMEM;
> > > > +
> > > > + if (has_pwm)
> > > > + (*devs)[rc++] = adp5585_devs[ADP5585_DEV_PWM];
> > > > + if (has_gpio)
> > > > + (*devs)[rc++] = adp5585_devs[ADP5585_DEV_GPIO];
> > >
> > > Passing around pointers to pointers for allocation (and later, pointer
> > > to functions) is not the way we wish to operate. See how all of the
> > > other MFD drivers handle selective sub-drivers.
> >
> > Any pointer from the top of your head (example driver)? Honestly, I do not
> > see
> > this being that bad. Pretty much is a dynamic array of struct mfd_cel but
> > anyways, no strong feelings
>
> I don't find it that bad either. I don't think you should use
> devm_kcalloc() though, as the memory should be freed as soon as it's not
> needed anymore.
>
Agreed... Sometimes I do forget we also have __free(kfree) even though I used it
in the keyboard driver.
> > But... I was actually being very stupid. First I did looked at an API to
> > only
>
> Occasionally overseeing a possible solution isn't being stupid. Or at
> least I hope it isn't, otherwise I would be very stupid too.
>
I know :)...
> > add one mfd device and failed to realize that I can use
> > devm_mfd_add_devices()
> > with n_devs = 1
> >
> > Nevermind, will refactor in v4
> >
> > > > + return rc;
> > > > +}
> > > > +
> > > > static int adp5585_i2c_probe(struct i2c_client *i2c)
> > > > {
> > > > const struct regmap_config *regmap_config;
> > > > struct adp5585_dev *adp5585;
> > > > + struct mfd_cell *devs;
> > > > unsigned int id;
> > > > - int ret;
> > > > + int ret, n_devs;
> > > >
> > > > adp5585 = devm_kzalloc(&i2c->dev, sizeof(*adp5585),
> > > > GFP_KERNEL);
> > > > if (!adp5585)
> > > > @@ -138,9 +172,12 @@ static int adp5585_i2c_probe(struct i2c_client
> > > > *i2c)
> > > > return dev_err_probe(&i2c->dev, -ENODEV,
> > > > "Invalid device ID 0x%02x\n", id);
> > > >
> > > > + n_devs = adp5585_parse_fw(&i2c->dev, adp5585, &devs);
> > > > + if (n_devs < 0)
> > > > + return n_devs;
> > > > +
> > > > ret = devm_mfd_add_devices(&i2c->dev, PLATFORM_DEVID_AUTO,
> > > > - adp5585_devs,
> > > > ARRAY_SIZE(adp5585_devs),
> > > > - NULL, 0, NULL);
> > > > + devs, n_devs, NULL, 0, NULL);
> > > > if (ret)
> > > > return dev_err_probe(&i2c->dev, ret,
> > > > "Failed to add child devices\n");
> > > >
next prev parent reply other threads:[~2025-05-13 15:37 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 12:38 [PATCH v3 00/22] mfd: adp5585: support keymap events and drop legacy Input driver Nuno Sá via B4 Relay
2025-05-12 12:38 ` [PATCH v3 01/22] dt-bindings: mfd: adp5585: ease on the required properties Nuno Sá via B4 Relay
2025-05-12 12:38 ` [PATCH v3 02/22] mfd: adp5585: only add devices given in FW Nuno Sá via B4 Relay
2025-05-13 14:34 ` Lee Jones
2025-05-13 15:02 ` Nuno Sá
2025-05-13 15:19 ` Laurent Pinchart
2025-05-13 15:37 ` Nuno Sá [this message]
2025-05-13 16:12 ` Lee Jones
2025-05-12 12:38 ` [PATCH v3 03/22] mfd: adp5585: enable oscilator during probe Nuno Sá via B4 Relay
2025-05-13 14:26 ` Lee Jones
2025-05-13 14:52 ` Nuno Sá
2025-05-13 16:07 ` Lee Jones
2025-05-13 15:24 ` Laurent Pinchart
2025-05-13 15:38 ` Nuno Sá
2025-05-12 12:38 ` [PATCH v3 04/22] pwm: adp5585: don't control OSC_EN in the pwm driver Nuno Sá via B4 Relay
2025-05-13 15:26 ` Laurent Pinchart
2025-05-13 15:39 ` Nuno Sá
2025-05-13 16:04 ` Lee Jones
2025-05-12 12:38 ` [PATCH v3 05/22] mfd: adp5585: make use of MFD_CELL_NAME() Nuno Sá via B4 Relay
2025-05-13 14:39 ` Lee Jones
2025-05-13 14:50 ` Nuno Sá
2025-05-12 12:38 ` [PATCH v3 06/22] dt-bindings: mfd: adp5585: document adp5589 I/O expander Nuno Sá via B4 Relay
2025-05-12 12:38 ` [PATCH v3 07/22] mfd: adp5585: refactor how regmap defaults are handled Nuno Sá via B4 Relay
2025-05-13 15:00 ` Lee Jones
2025-05-13 15:02 ` Lee Jones
2025-05-13 15:32 ` Nuno Sá
2025-05-13 15:36 ` Laurent Pinchart
2025-05-13 16:03 ` Lee Jones
2025-05-13 15:35 ` Laurent Pinchart
2025-05-13 15:41 ` Nuno Sá
2025-05-12 12:39 ` [PATCH v3 08/22] mfd: adp5585: add support for adp5589 Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 09/22] mfd: adp5585: add a per chip reg struture Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 10/22] gpio: adp5585: add support for the adp5589 expander Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 11/22] pwm: adp5585: add support for adp5589 Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 12/22] dt-bindings: mfd: adp5585: add properties for input events Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 13/22] mfd: adp5585: add support for event handling Nuno Sá via B4 Relay
2025-05-13 15:59 ` Lee Jones
2025-05-15 5:56 ` Nuno Sá
2025-05-15 6:14 ` Nuno Sá
2025-05-12 12:39 ` [PATCH v3 14/22] mfd: adp5585: support reset and unlock events Nuno Sá via B4 Relay
2025-05-13 16:22 ` Lee Jones
2025-05-14 8:35 ` Laurent Pinchart
2025-05-14 8:46 ` Lee Jones
2025-05-15 5:46 ` Nuno Sá
2025-05-12 12:39 ` [PATCH v3 15/22] mfd: adp5585: add support for input devices Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 16/22] gpio: adp5585: support gpi events Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 17/22] Input: adp5585: Add Analog Devices ADP5585/89 support Nuno Sá via B4 Relay
2025-05-19 22:29 ` Dmitry Torokhov
2025-05-20 8:32 ` Nuno Sá
2025-05-20 18:33 ` Dmitry Torokhov
2025-05-21 10:06 ` Nuno Sá
2025-05-12 12:39 ` [PATCH v3 18/22] Input: adp5589: remove the driver Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 19/22] mfd: adp5585: support getting vdd regulator Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 20/22] dt-bindings: mfd: adp5585: document reset gpio Nuno Sá via B4 Relay
2025-05-12 12:39 ` [PATCH v3 21/22] mfd: adp5585: add support for a reset pin Nuno Sá via B4 Relay
2025-05-13 16:26 ` Lee Jones
2025-05-15 5:39 ` Nuno Sá
2025-05-12 12:39 ` [PATCH v3 22/22] pwm: adp5585: make sure to include mod_devicetable.h Nuno Sá via B4 Relay
2025-05-19 16:11 ` Uwe Kleine-König
2025-05-19 16:19 ` Nuno Sá
2025-05-14 8:25 ` [PATCH v3 00/22] mfd: adp5585: support keymap events and drop legacy Input driver Lee Jones
2025-05-14 11:04 ` Nuno Sá
2025-07-02 13:34 ` Lee Jones
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=bbbd7ec7818f9dbcb753e2e47f03fe820489adce.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=brgl@bgdev.pl \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=ukleinek@kernel.org \
--cc=victor.liu@nxp.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;
as well as URLs for NNTP newsgroup(s).