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, 20 Mar 2025 14:50:42 +0000 [thread overview]
Message-ID: <20250320145042.GS3890718@google.com> (raw)
In-Reply-To: <CAOoeyxUgiTqtSksfHopEDhZHwNkUq9+d-ojo8ma3PX2dosuwyQ@mail.gmail.com>
On Mon, 17 Mar 2025, Ming Yu wrote:
> Dear Lee,
>
> Thank you for reviewing,
>
> Lee Jones <lee@kernel.org> 於 2025年3月7日 週五 上午9:15寫道:
> >
> > On Tue, 25 Feb 2025, Ming Yu wrote:
> >
> > > The Nuvoton NCT6694 is a peripheral expander with 16 GPIO chips,
> > > 6 I2C controllers, 2 CANfd controllers, 2 Watchdog timers, ADC,
> > > PWM, and RTC.
> >
> > This needs to go into the Kconfig help passage.
> >
>
> Okay, I will move these to Kconfig in the next patch.
>
> > > This driver implements USB device functionality and shares the
> > > chip's peripherals as a child device.
> >
> > This driver doesn't implement USB functionality.
> >
>
> Fix it in v9.
>
> > > Each child device can use the USB functions nct6694_read_msg()
> > > and nct6694_write_msg() to issue a command. They can also request
> > > interrupt that will be called when the USB device receives its
> > > interrupt pipe.
> > >
> > > Signed-off-by: Ming Yu <a0282524688@gmail.com>
> >
> > Why aren't you signing off with your work address?
> >
>
> Fix it in v9.
>
> > > ---
> > > MAINTAINERS | 7 +
> > > drivers/mfd/Kconfig | 18 ++
> > > drivers/mfd/Makefile | 2 +
> > > drivers/mfd/nct6694.c | 378 ++++++++++++++++++++++++++++++++++++
> > > include/linux/mfd/nct6694.h | 102 ++++++++++
> > > 5 files changed, 507 insertions(+)
> > > create mode 100644 drivers/mfd/nct6694.c
> > > create mode 100644 include/linux/mfd/nct6694.h
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 873aa2cce4d7..c700a0b96960 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -16918,6 +16918,13 @@ F: drivers/nubus/
> > > F: include/linux/nubus.h
> > > F: include/uapi/linux/nubus.h
> > >
> > > +NUVOTON NCT6694 MFD DRIVER
> > > +M: Ming Yu <tmyu0@nuvoton.com>
> > > +L: linux-kernel@vger.kernel.org
> >
> > This is the default list. You shouldn't need to add that here.
>
> Remove it in v9.
Please snip everything that you agree with.
> > > +S: Supported
> > > +F: drivers/mfd/nct6694.c
> > > +F: include/linux/mfd/nct6694.h
> > > +
> > > NVIDIA (rivafb and nvidiafb) FRAMEBUFFER DRIVER
> > > M: Antonino Daplas <adaplas@gmail.com>
> > > L: linux-fbdev@vger.kernel.org
[...]
> > > + 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?
>
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x2),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x3),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x4),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x5),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x6),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x7),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x8),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0x9),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0xA),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0xB),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0xC),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0xD),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0xE),
> > > + MFD_CELL_BASIC("gpio-nct6694", NULL, NULL, 0, 0xF),
> > > +
> > > + MFD_CELL_BASIC("i2c-nct6694", NULL, NULL, 0, 0x0),
> > > + MFD_CELL_BASIC("i2c-nct6694", NULL, NULL, 0, 0x1),
> > > + MFD_CELL_BASIC("i2c-nct6694", NULL, NULL, 0, 0x2),
> > > + MFD_CELL_BASIC("i2c-nct6694", NULL, NULL, 0, 0x3),
> > > + MFD_CELL_BASIC("i2c-nct6694", NULL, NULL, 0, 0x4),
> > > + MFD_CELL_BASIC("i2c-nct6694", NULL, NULL, 0, 0x5),
> > > +
> > > + MFD_CELL_BASIC("nct6694_canfd", NULL, NULL, 0, 0x0),
> >
> > Why has the naming convention changed here?
> >
>
> I originally expected the child devices name to directly match its
> driver name. Do you think it would be better to standardize the naming
> as "nct6694-xxx" ?
Yes, that is the usual procedure.
> > > + MFD_CELL_BASIC("nct6694_canfd", NULL, NULL, 0, 0x1),
> > > +
> > > + MFD_CELL_BASIC("nct6694_wdt", NULL, NULL, 0, 0x0),
> > > + MFD_CELL_BASIC("nct6694_wdt", NULL, NULL, 0, 0x1),
> > > +
> > > + MFD_CELL_NAME("nct6694-hwmon"),
> > > + MFD_CELL_NAME("rtc-nct6694"),
> >
> > There doesn't seem to be any consistency here.
> >
>
> Do you think these two should be changed to use MFD_CELL_BASIC()?
No. I mean with the device nomenclature.
[...]
> > > +static void usb_int_callback(struct urb *urb)
> > > +{
> > > + struct nct6694 *nct6694 = urb->context;
> > > + unsigned int *int_status = urb->transfer_buffer;
> > > + int ret;
> > > +
> > > + switch (urb->status) {
> > > + case 0:
> > > + break;
> > > + case -ECONNRESET:
> > > + case -ENOENT:
> > > + case -ESHUTDOWN:
> > > + return;
> > > + default:
> > > + generic_handle_irq_safe(irq_find_mapping(nct6694->domain, irq));
> > > + *int_status &= ~BIT(irq);
> > > + }
> > > +
> > > +resubmit:
> > > + ret = usb_submit_urb(urb, GFP_ATOMIC);
> > > + if (ret)
> > > + dev_dbg(nct6694->dev, "%s: Failed to resubmit urb, status %pe",
> >
> > Why debug?
> >
>
> Excuse me, do you think it should change to dev_err()?
Probably a dev_warn() since you are not propagating the error.
Is this okay by the way? Is it okay to fail?
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2025-03-20 14:50 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 [this message]
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
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=20250320145042.GS3890718@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).