public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ming Yu <a0282524688@gmail.com>
Cc: Lee Jones <lee@kernel.org>,
	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: Thu, 19 Jun 2025 18:20:46 +0200	[thread overview]
Message-ID: <2025061910-skies-outgoing-89cc@gregkh> (raw)
In-Reply-To: <CAOoeyxU7eQneBuxbBqepta29q_OHPzrkN4SKmj6RX72L3Euw5A@mail.gmail.com>

On Fri, Jun 20, 2025 at 12:03:01AM +0800, Ming Yu wrote:
> Lee Jones <lee@kernel.org> 於 2025年6月19日 週四 下午11:28寫道:
> >
> > On Thu, 19 Jun 2025, Ming Yu wrote:
> >
> > > Lee Jones <lee@kernel.org> 於 2025年6月19日 週四 下午7:53寫道:
> > > >
> > > > On Fri, 13 Jun 2025, Ming Yu wrote:
> > > >
> > > > > Lee Jones <lee@kernel.org> 於 2025年6月13日 週五 下午9:11寫道:
> > > > > >
> > > > > > On Fri, 13 Jun 2025, Ming Yu wrote:
> > > > > >
> > > > > > > Lee Jones <lee@kernel.org> 於 2025年6月12日 週四 下午11:23寫道:
> > > > > > > >
> > > > > > > > On Thu, 12 Jun 2025, Ming Yu wrote:
> > > > > > > >
> > > > > > > > > Dear Lee,
> > > > > > > > >
> > > > > > > > > Thank you for reviewing,
> > > > > > > > >
> > > > > > > > > Lee Jones <lee@kernel.org> 於 2025年6月12日 週四 下午10:00寫道:
> > > > > > > > > >
> > > > > > > > > ...
> > > > > > > > > > > +static const struct mfd_cell nct6694_devs[] = {
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 0),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 1),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 2),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 3),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 4),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 5),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 6),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 7),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 8),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 9),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 10),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 11),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 12),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 13),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 14),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-gpio", NULL, NULL, 0, 15),
> > > > > > > > > > > +
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-i2c", NULL, NULL, 0, 0),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-i2c", NULL, NULL, 0, 1),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-i2c", NULL, NULL, 0, 2),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-i2c", NULL, NULL, 0, 3),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-i2c", NULL, NULL, 0, 4),
> > > > > > > > > > > +     MFD_CELL_BASIC("nct6694-i2c", NULL, NULL, 0, 5),
> > > > > > > > > >
> > > > > > > > > > Why have we gone back to this silly numbering scheme?
> > > > > > > > > >
> > > > > > > > > > What happened to using IDA in the child driver?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > In a previous version, I tried to maintain a static IDA in each
> > > > > > > > > sub-driver. However, I didn’t consider the case where multiple NCT6694
> > > > > > > > > devices are bound to the same driver — in that case, the IDs are not
> > > > > > > > > fixed and become unusable for my purpose.
> > > > > > > >
> > > > > > > > Not sure I understand.
> > > > > > > >
> > > > > > >
> > > > > > > As far as I know, if I maintain the IDA in the sub-drivers and use
> > > > > > > multiple MFD_CELL_NAME("nct6694-gpio") entries in the MFD, the first
> > > > > > > NCT6694 device bound to the GPIO driver will receive IDs 0~15.
> > > > > > > However, when a second NCT6694 device is connected to the system, it
> > > > > > > will receive IDs 16~31.
> > > > > > > Because of this behavior, I switched back to using platform_device->id.
> > > > > >
> > > > > > Each of the devices will probe once.
> > > > > >
> > > > > > The first one will be given 0, the second will be given 1, etc.
> > > > > >
> > > > > > Why would you give multiple IDs to a single device bound to a driver?
> > > > > >
> > > > >
> > > > > The device exposes multiple peripherals — 16 GPIO controllers, 6 I2C
> > > > > adapters, 2 CAN FD controllers, and 2 watchdog timers. Each peripheral
> > > > > is independently addressable, has its own register region, and can
> > > > > operate in isolation. The IDs are used to distinguish between these
> > > > > instances.
> > > > > For example, the GPIO driver will be probed 16 times, allocating 16
> > > > > separate gpio_chip instances to control 8 GPIO lines each.
> > > > >
> > > > > If another device binds to this driver, it is expected to expose
> > > > > peripherals with the same structure and behavior.
> > > >
> > > > I still don't see why having a per-device IDA wouldn't render each
> > > > probed device with its own ID.  Just as you have above.
> > > >
> > >
> > > For example, when the MFD driver and the I2C sub-driver are loaded,
> > > connecting the first NCT6694 USB device to the system results in 6
> > > nct6694-i2c platform devices being created and bound to the
> > > i2c-nct6694 driver. These devices receive IDs 0 through 5 via the IDA.
> > >
> > > However, when a second NCT6694 USB device is connected, its
> > > corresponding nct6694-i2c platform devices receive IDs 6 through 11 —
> > > instead of 0 through 5 as I originally expected.
> > >
> > > If I've misunderstood something, please feel free to correct me. Thank you!
> >
> > 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?

What is wrong with increasing ids?  The id value means nothing, they
just have to be unique.

thanks,

greg k-h

  reply	other threads:[~2025-06-19 16:20 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 [this message]
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
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=2025061910-skies-outgoing-89cc@gregkh \
    --to=gregkh@linuxfoundation.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=lee@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox