linux-gpio.vger.kernel.org archive mirror
 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, 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 [李琼斯]

  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).