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] [day] [month] [year] [list]

Message-ID: <CAOoeyxXftk9QX_REgeQhuXSc9rEguzXkKVKDQdawU=NzGbo9oA@mail.gmail.com>
Date: Fri, 13 Jun 2025 23:09:22 +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月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.


Thanks,
Ming