From: Lee Jones <lee@kernel.org>
To: Ming Yu <a0282524688@gmail.com>
Cc: linus.walleij@linaro.org, brgl@bgdev.pl, andi.shyti@kernel.org,
mkl@pengutronix.de, mailhol.vincent@wanadoo.fr,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, wim@linux-watchdog.org,
linux@roeck-us.net, jdelvare@suse.com,
alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-watchdog@vger.kernel.org, linux-hwmon@vger.kernel.org,
linux-rtc@vger.kernel.org, linux-usb@vger.kernel.org,
Ming Yu <tmyu0@nuvoton.com>
Subject: Re: [PATCH v12 1/7] mfd: Add core driver for Nuvoton NCT6694
Date: Wed, 25 Jun 2025 15:53:21 +0100 [thread overview]
Message-ID: <20250625145321.GZ795775@google.com> (raw)
In-Reply-To: <CAOoeyxVuu-kKoQa84mGOX=thAc0hnzQU8L=MnycoRRhzoZMnNw@mail.gmail.com>
[...]
> > > > > > In the code above you register 6 I2C devices. Each device will be
> > > > > > assigned a platform ID 0 through 5. The .probe() function in the I2C
> > > > > > driver will be executed 6 times. In each of those calls to .probe(),
> > > > > > instead of pre-allocating a contiguous assignment of IDs here, you
> > > > > > should be able to use IDA in .probe() to allocate those same device IDs
> > > > > > 0 through 5.
> > > > > >
> > > > > > What am I missing here?
> > > > > >
> > > > >
> > > > > You're absolutely right in the scenario where a single NCT6694 device
> > > > > is present. However, I’m wondering how we should handle the case where
> > > > > a second or even third NCT6694 device is bound to the same MFD driver.
> > > > > In that situation, the sub-drivers using a static IDA will continue
> > > > > allocating increasing IDs, rather than restarting from 0 for each
> > > > > device. How should this be handled?
> > > >
> > > > I'd like to see the implementation of this before advising.
> > > >
> > > > In such a case, I assume there would be a differentiating factor between
> > > > the two (or three) devices. You would then use that to decide which IDA
> > > > would need to be incremented.
> > > >
> > > > However, Greg is correct. Hard-coding look-ups for userspace to use
> > > > sounds like a terrible idea.
> > > >
> > >
> > > I understand.
> > > Do you think it would be better to pass the index via platform_data
> > > and use PLATFORM_DEVID_AUTO together with mfd_add_hotplug_devices()
> > > instead?
> > > For example:
> > > struct nct6694_platform_data {
> > > int index;
> > > };
> > >
> > > static struct nct6694_platform_data i2c_data[] = {
> > > { .index = 0 }, { .index = 1 }, { .index = 2 }, { .index = 3 }, {
> > > .index = 4 }, { .index = 5 },
> > > };
> > >
> > > static const struct mfd_cell nct6694_devs[] = {
> > > MFD_CELL_BASIC("nct6694-i2c", NULL, &i2c_data[0], sizeof(struct
> > > nct6694_platform_data), 0),
> > > MFD_CELL_BASIC("nct6694-i2c", NULL, &i2c_data[1], sizeof(struct
> > > nct6694_platform_data), 0),
> > > MFD_CELL_BASIC("nct6694-i2c", NULL, &i2c_data[2], sizeof(struct
> > > nct6694_platform_data), 0),
> > > MFD_CELL_BASIC("nct6694-i2c", NULL, &i2c_data[3], sizeof(struct
> > > nct6694_platform_data), 0),
> > > MFD_CELL_BASIC("nct6694-i2c", NULL, &i2c_data[4], sizeof(struct
> > > nct6694_platform_data), 0),
> > > MFD_CELL_BASIC("nct6694-i2c", NULL, &i2c_data[5], sizeof(struct
> > > nct6694_platform_data), 0),
> > > };
> > > ...
> > > mfd_add_hotplug_devices(dev, nct6694_devs, ARRAY_SIZE(nct6694_devs));
> > > ...
> >
> > No, that's clearly way worse. =:-)
> >
> > The clean-up that this provides is probably not worth all of this
> > discussion. I _still_ think this enumeration should be done in the
> > driver. But if you really can't make it work, I'll accept the .id
> > patch.
> >
>
> Okay, I would like to ask for your advice regarding the implementation of IDA.
>
> Using a global IDA in the sub-driver like this:
> (in i2c-nct6694.c)
> static DEFINE_IDA(nct6694_i2c_ida);
>
> static int nct6694_i2c_probe(struct platform_device *pdev)
> {
> ida_alloc(&nct6694_i2c_ida, GFP_KERNEL);
> ...
> }
>
> causes IDs to be globally incremented across all devices. For example,
> the first NCT6694 device gets probed 6 times and receives IDs 0–5, but
> when a second NCT6694 device is added, it receives IDs starting from
> 6, rather than starting again from 0. This makes per-device ID mapping
> unreliable.
>
> To solve this, I believe the right approach is to have each NCT6694
> instance maintain its own IDA, managed by the MFD driver's private
> data. As mentioned earlier, for example:
> (in nct6694.c)
> struct nct6694 {
> struct device *dev;
> struct ida i2c_ida;
> };
>
> static int nct6694_probe(struct platform_device *pdev)
> {
> ...
> ida_init(&nct6694->i2c_ida);
> ...
> }
>
> (in i2c-nct6694.c)
> static int nct6694_i2c_probe(struct platform_device *pdev)
> {
> id = ida_alloc(&nct6694->i2c_ida, GFP_KERNEL);
> }
>
> This way, each device allocates IDs independently, and each set of
> I2C/GPIO instances gets predictable IDs starting from 0 per device. I
> think this resolves the original issue without relying on hardcoded
> platform IDs.
> Please let me know if this implementation aligns with what you had in mind.
This sounds like an acceptable way forward.
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2025-06-25 14:53 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 4:14 [PATCH v12 0/7] Add Nuvoton NCT6694 MFD drivers a0282524688
2025-06-04 4:14 ` [PATCH v12 1/7] mfd: Add core driver for Nuvoton NCT6694 a0282524688
2025-06-04 10:11 ` Oliver Neukum
2025-06-04 12:40 ` Guenter Roeck
2025-06-05 7:49 ` Ming Yu
2025-06-05 7:48 ` Ming Yu
2025-06-12 14:00 ` Lee Jones
2025-06-12 14:40 ` Ming Yu
2025-06-12 15:23 ` Lee Jones
2025-06-13 1:54 ` Ming Yu
2025-06-13 13:11 ` Lee Jones
2025-06-13 15:09 ` Ming Yu
2025-06-19 11:53 ` Lee Jones
2025-06-19 12:24 ` Ming Yu
2025-06-19 15:28 ` Lee Jones
2025-06-19 16:03 ` Ming Yu
2025-06-19 16:20 ` Greg KH
2025-06-19 16:58 ` Guenter Roeck
2025-06-19 17:18 ` Greg KH
2025-06-20 2:54 ` Ming Yu
2025-06-20 5:02 ` Greg KH
2025-06-25 9:01 ` Lee Jones
2025-06-25 10:54 ` Ming Yu
2025-06-25 13:46 ` Lee Jones
2025-06-25 14:24 ` Ming Yu
2025-06-25 14:53 ` Lee Jones [this message]
2025-06-04 4:14 ` [PATCH v12 2/7] gpio: Add Nuvoton NCT6694 GPIO support a0282524688
2025-06-04 4:14 ` [PATCH v12 3/7] i2c: Add Nuvoton NCT6694 I2C support a0282524688
2025-06-04 4:14 ` [PATCH v12 4/7] can: Add Nuvoton NCT6694 CANFD support a0282524688
2025-06-04 10:19 ` Vincent Mailhol
2025-06-04 4:14 ` [PATCH v12 5/7] watchdog: Add Nuvoton NCT6694 WDT support a0282524688
2025-06-04 4:14 ` [PATCH v12 6/7] hwmon: Add Nuvoton NCT6694 HWMON support a0282524688
2025-06-04 4:14 ` [PATCH v12 7/7] rtc: Add Nuvoton NCT6694 RTC support a0282524688
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=20250625145321.GZ795775@google.com \
--to=lee@kernel.org \
--cc=a0282524688@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=andi.shyti@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=brgl@bgdev.pl \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jdelvare@suse.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tmyu0@nuvoton.com \
--cc=wim@linux-watchdog.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.