linux-kernel - Re: [PATCH v12 1/7] mfd: Add core driver for Nuvoton NCT6694

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOoeyxXSTeypv2qQjcK1cSPtjch=gJGYzqoMsLQ-LJZ8Kwgd=w@mail.gmail.com>
Date: Thu, 19 Jun 2025 20:24:39 +0800
From: Ming Yu <a0282524688@...il.com>
To: Lee Jones <lee@...nel.org>
Cc: linus.walleij@...aro.org, brgl@...ev.pl, andi.shyti@...nel.org, 
	mkl@...gutronix.de, mailhol.vincent@...adoo.fr, andrew+netdev@...n.ch, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	wim@...ux-watchdog.org, linux@...ck-us.net, jdelvare@...e.com, 
	alexandre.belloni@...tlin.com, linux-kernel@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-i2c@...r.kernel.org, 
	linux-can@...r.kernel.org, netdev@...r.kernel.org, 
	linux-watchdog@...r.kernel.org, linux-hwmon@...r.kernel.org, 
	linux-rtc@...r.kernel.org, linux-usb@...r.kernel.org, 
	Ming Yu <tmyu0@...oton.com>
Subject: Re: [PATCH v12 1/7] mfd: Add core driver for Nuvoton NCT6694

Lee Jones <lee@...nel.org> 於 2025年6月19日 週四 下午7:53寫道：
>
> On Fri, 13 Jun 2025, Ming Yu wrote:
>
> > Lee Jones <lee@...nel.org> 於 2025年6月13日 週五 下午9:11寫道：
> > >
> > > On Fri, 13 Jun 2025, Ming Yu wrote:
> > >
> > > > Lee Jones <lee@...nel.org> 於 2025年6月12日 週四 下午11:23寫道：
> > > > >
> > > > > On Thu, 12 Jun 2025, Ming Yu wrote:
> > > > >
> > > > > > Dear Lee,
> > > > > >
> > > > > > Thank you for reviewing,
> > > > > >
> > > > > > Lee Jones <lee@...nel.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!


Sincerely,
Ming