All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Ming Yu <a0282524688@gmail.com>
Cc: tmyu0@nuvoton.com, 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
Subject: Re: [PATCH v8 1/7] mfd: Add core driver for Nuvoton NCT6694
Date: Thu, 10 Apr 2025 09:21:32 +0100	[thread overview]
Message-ID: <20250410082132.GP372032@google.com> (raw)
In-Reply-To: <CAOoeyxVVgHGkH5ajQT0NGNPv7FmVPLzuZtGjCiF7mRRto70aAg@mail.gmail.com>

On Mon, 07 Apr 2025, Ming Yu wrote:

> Lee Jones <lee@kernel.org> 於 2025年4月4日 週五 下午10:21寫道:
> >
> > > ...
> > > > > > > +     MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x1),
> > > > > >
> > > > > > IDs are usually given in base-10.
> > > > > >
> > > > >
> > > > > Fix it in v9.
> > > > >
> > > > > > Why are you manually adding the device IDs?
> > > > > >
> > > > > > PLATFORM_DEVID_AUTO doesn't work for you?
> > > > > >
> > > > >
> > > > > I need to manage these IDs to ensure that child devices can be
> > > > > properly utilized within their respective modules.
> > > >
> > > > How?  Please explain.
> > > >
> > > > This numbering looks sequential and arbitrary.
> > > >
> > > > What does PLATFORM_DEVID_AUTO do differently such that it is not useful?
> > > >
> > >
> > > As far as I know, PLATFORM_DEVID_AUTO assigns dynamic IDs to devices,
> > > but I need fixed IDs.
> > > For example, the GPIO driver relies on these IDs to determine the
> > > group, allowing the firmware to identify which GPIO group to operate
> > > on through the API.
> >
> > PLATFORM_DEVID_AUTO will allocate IDs 0 through 16, the same as you've
> > done here.  These lines do not have any differentiating attributes, so
> > either way we are not allocating specific IDs to specific pieces of the
> > H/W.  I still do not understand why you need to allocate them manually.
> >
> 
> I'm using PLATFORM_DEVID_AUTO to allocate child device IDs with
> MFD_CELL_NAME(), like this:
> 
> static const struct mfd_cell nct6694_dev[] = {
>     MFD_CELL_NAME("nct6694-gpio"),
>     MFD_CELL_NAME("nct6694-gpio"),
>     ......
>     MFD_CELL_NAME("nct6694-gpio"),
>     MFD_CELL_NAME("nct6694-i2c"),
>     MFD_CELL_NAME("nct6694-i2c"),
>     ......
>     MFD_CELL_NAME("nct6694-i2c"),
>     ......
> };
> 
> For example, the device IDs retrieved in gpio-nct6694.c is 1~16, and
> i2c-nct6694.c is 17~22. Does this mean each driver should
> independently handle its dynamically assigned IDs?
> Additionally, I originally referred to cgbc-core.c with i2c-cgbc.c,
> and ab8500-core.c with pwm-ab8500.c for associating child devices. Do
> you think this approach is appropriate in my case?

Yes, if you _need_ the ranges to start from 0, then you will have to
call mfd_add_devices() separately on those ranges.  Otherwise one range
will follow directly on to another range.

But wait, you're using mfd_add_hotplug_devices(), which means you are
using PLATFORM_DEVID_AUTO.  So your .id values that you've added are
being ignored anyway.  Thus, if you have tested that this works, you
don't need them anyway, right?

-- 
Lee Jones [李琼斯]

  reply	other threads:[~2025-04-10  8:21 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-25  8:16 [PATCH v8 0/7] Add Nuvoton NCT6694 MFD drivers Ming Yu
2025-02-25  8:16 ` [PATCH v8 1/7] mfd: Add core driver for Nuvoton NCT6694 Ming Yu
2025-02-28  8:52   ` Marc Kleine-Budde
2025-03-17  2:26     ` Ming Yu
2025-03-07  1:15   ` Lee Jones
2025-03-17  2:57     ` Ming Yu
2025-03-20 14:50       ` Lee Jones
2025-03-26  2:52         ` Ming Yu
2025-04-04 14:21           ` Lee Jones
2025-04-07  2:25             ` Ming Yu
2025-04-10  8:21               ` Lee Jones [this message]
2025-04-21 11:00                 ` Ming Yu
2025-02-25  8:16 ` [PATCH v8 2/7] gpio: Add Nuvoton NCT6694 GPIO support Ming Yu
2025-02-25  8:16 ` [PATCH v8 3/7] i2c: Add Nuvoton NCT6694 I2C support Ming Yu
2025-03-19 23:58   ` Andi Shyti
2025-03-26  2:46     ` Ming Yu
2025-02-25  8:16 ` [PATCH v8 4/7] can: Add Nuvoton NCT6694 CANFD support Ming Yu
2025-02-27  2:08   ` Vincent Mailhol
2025-02-27  6:03     ` Ming Yu
2025-02-27 14:17     ` Marc Kleine-Budde
2025-03-17  2:08       ` Ming Yu
2025-02-28 10:44   ` Marc Kleine-Budde
2025-03-17  2:24     ` Ming Yu
2025-03-17  9:13       ` Marc Kleine-Budde
2025-03-26  2:27         ` Ming Yu
2025-03-26 17:41           ` Marc Kleine-Budde
2025-03-27  5:38             ` Ming Yu
2025-03-27  7:06               ` Marc Kleine-Budde
2025-03-28  2:37                 ` Ming Yu
2025-03-28  7:22                   ` Marc Kleine-Budde
2025-03-28  8:57                     ` Ming Yu
2025-03-28  9:11                       ` Marc Kleine-Budde
2025-03-17 10:41   ` Marc Kleine-Budde
2025-03-26  2:37     ` Ming Yu
2025-03-26 17:35       ` Marc Kleine-Budde
2025-03-27  5:30         ` Ming Yu
2025-03-26 21:56   ` Christophe JAILLET
2025-03-27  5:41     ` Ming Yu
2025-02-25  8:16 ` [PATCH v8 5/7] watchdog: Add Nuvoton NCT6694 WDT support Ming Yu
2025-02-25  8:16 ` [PATCH v8 6/7] hwmon: Add Nuvoton NCT6694 HWMON support Ming Yu
2025-02-25  8:16 ` [PATCH v8 7/7] rtc: Add Nuvoton NCT6694 RTC support Ming Yu

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=20250410082132.GP372032@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.