mbox series

[v1,0/9] Add Nuvoton NCT6694 MFD devices

Message ID 20241024085922.133071-1-tmyu0@nuvoton.com (mailing list archive)
Headers show
Series Add Nuvoton NCT6694 MFD devices | expand

Message

Ming Yu Oct. 24, 2024, 8:59 a.m. UTC 
This patch series introduces support for Nuvoton NCT6694, a peripheral
expander based on USB interface. It models the chip as an MFD driver
(1/9), GPIO driver(2/9), I2C Adapter driver(3/9), CANfd driver(4/9),
WDT driver(5/9), HWMON driver(6/9), IIO driver(7/9), PWM driver(8/9),
and RTC driver(9/9).

The MFD driver implements USB device functionality to issue
custom-define USB bulk pipe packets for NCT6694. Each child device can
use the USB functions nct6694_read_msg() and nct6694_write_msg() to issue
a command. They can also register a handler function that will be called
when the USB device receives its interrupt pipe.

The following introduces the custom-define USB transactions:
	nct6694_read_msg - Send bulk-out pipe to write request packet
			   Receive bulk-in pipe to read response packet
			   Receive bulk-in pipe to read data packet

	nct6694_write_msg - Send bulk-out pipe to write request packet
			    Send bulk-out pipe to write data packet
                            Receive bulk-in pipe to read response packet
                            Receive bulk-in pipe to read data packet

Ming Yu (9):
  mfd: Add core driver for Nuvoton NCT6694
  gpio: Add Nuvoton NCT6694 GPIO support
  i2c: Add Nuvoton NCT6694 I2C support
  can: Add Nuvoton NCT6694 CAN support
  watchdog: Add Nuvoton NCT6694 WDT support
  hwmon: Add Nuvoton NCT6694 HWMON support
  iio: adc: Add Nuvoton NCT6694 IIO support
  pwm: Add Nuvoton NCT6694 PWM support
  rtc: Add Nuvoton NCT6694 RTC support

 MAINTAINERS                      |  15 +
 drivers/gpio/Kconfig             |  12 +
 drivers/gpio/Makefile            |   1 +
 drivers/gpio/gpio-nct6694.c      | 489 ++++++++++++++++++
 drivers/hwmon/Kconfig            |  10 +
 drivers/hwmon/Makefile           |   1 +
 drivers/hwmon/nct6694-hwmon.c    | 407 +++++++++++++++
 drivers/i2c/busses/Kconfig       |  10 +
 drivers/i2c/busses/Makefile      |   1 +
 drivers/i2c/busses/i2c-nct6694.c | 166 ++++++
 drivers/iio/adc/Kconfig          |  10 +
 drivers/iio/adc/Makefile         |   1 +
 drivers/iio/adc/nct6694_adc.c    | 616 ++++++++++++++++++++++
 drivers/mfd/Kconfig              |  10 +
 drivers/mfd/Makefile             |   2 +
 drivers/mfd/nct6694.c            | 394 +++++++++++++++
 drivers/net/can/Kconfig          |  10 +
 drivers/net/can/Makefile         |   1 +
 drivers/net/can/nct6694_canfd.c  | 843 +++++++++++++++++++++++++++++++
 drivers/pwm/Kconfig              |  10 +
 drivers/pwm/Makefile             |   1 +
 drivers/pwm/pwm-nct6694.c        | 245 +++++++++
 drivers/rtc/Kconfig              |  10 +
 drivers/rtc/Makefile             |   1 +
 drivers/rtc/rtc-nct6694.c        | 276 ++++++++++
 drivers/watchdog/Kconfig         |  11 +
 drivers/watchdog/Makefile        |   1 +
 drivers/watchdog/nct6694_wdt.c   | 329 ++++++++++++
 include/linux/mfd/nct6694.h      | 168 ++++++
 29 files changed, 4051 insertions(+)
 create mode 100644 drivers/gpio/gpio-nct6694.c
 create mode 100644 drivers/hwmon/nct6694-hwmon.c
 create mode 100644 drivers/i2c/busses/i2c-nct6694.c
 create mode 100644 drivers/iio/adc/nct6694_adc.c
 create mode 100644 drivers/mfd/nct6694.c
 create mode 100644 drivers/net/can/nct6694_canfd.c
 create mode 100644 drivers/pwm/pwm-nct6694.c
 create mode 100644 drivers/rtc/rtc-nct6694.c
 create mode 100644 drivers/watchdog/nct6694_wdt.c
 create mode 100644 include/linux/mfd/nct6694.h

Comments

Marc Kleine-Budde Oct. 24, 2024, 11:57 a.m. UTC | #1 
On 24.10.2024 16:59:13, Ming Yu wrote:
> This patch series introduces support for Nuvoton NCT6694, a peripheral
> expander based on USB interface. It models the chip as an MFD driver
> (1/9), GPIO driver(2/9), I2C Adapter driver(3/9), CANfd driver(4/9),
> WDT driver(5/9), HWMON driver(6/9), IIO driver(7/9), PWM driver(8/9),
> and RTC driver(9/9).
> 
> The MFD driver implements USB device functionality to issue
> custom-define USB bulk pipe packets for NCT6694. Each child device can
> use the USB functions nct6694_read_msg() and nct6694_write_msg() to issue
> a command. They can also register a handler function that will be called
> when the USB device receives its interrupt pipe.

What about implementing a proper IRQ demux handler instead?

Marc
Ming Yu Oct. 25, 2024, 8:22 a.m. UTC | #2 
Hi Marc,

I think the currently planned IRQ process meets expectations.
Is there anything that needs improvement?

Thanks,
Ming

Marc Kleine-Budde <mkl@pengutronix.de> 於 2024年10月24日 週四 下午7:57寫道：
>
> On 24.10.2024 16:59:13, Ming Yu wrote:
> > This patch series introduces support for Nuvoton NCT6694, a peripheral
> > expander based on USB interface. It models the chip as an MFD driver
> > (1/9), GPIO driver(2/9), I2C Adapter driver(3/9), CANfd driver(4/9),
> > WDT driver(5/9), HWMON driver(6/9), IIO driver(7/9), PWM driver(8/9),
> > and RTC driver(9/9).
> >
> > The MFD driver implements USB device functionality to issue
> > custom-define USB bulk pipe packets for NCT6694. Each child device can
> > use the USB functions nct6694_read_msg() and nct6694_write_msg() to issue
> > a command. They can also register a handler function that will be called
> > when the USB device receives its interrupt pipe.
>
> What about implementing a proper IRQ demux handler instead?
>
> Marc
>
> --
> Pengutronix e.K.                 | Marc Kleine-Budde          |
> Embedded Linux                   | https://www.pengutronix.de |
> Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |
Marc Kleine-Budde Oct. 25, 2024, 8:33 a.m. UTC | #3 
On 25.10.2024 16:22:01, Ming Yu wrote:
> Marc Kleine-Budde <mkl@pengutronix.de> 於 2024年10月24日 週四 下午7:57寫道：
> > On 24.10.2024 16:59:13, Ming Yu wrote:
> > > This patch series introduces support for Nuvoton NCT6694, a peripheral
> > > expander based on USB interface. It models the chip as an MFD driver
> > > (1/9), GPIO driver(2/9), I2C Adapter driver(3/9), CANfd driver(4/9),
> > > WDT driver(5/9), HWMON driver(6/9), IIO driver(7/9), PWM driver(8/9),
> > > and RTC driver(9/9).
> > >
> > > The MFD driver implements USB device functionality to issue
> > > custom-define USB bulk pipe packets for NCT6694. Each child device can
> > > use the USB functions nct6694_read_msg() and nct6694_write_msg() to issue
> > > a command. They can also register a handler function that will be called
> > > when the USB device receives its interrupt pipe.
> >
> > What about implementing a proper IRQ demux handler instead?

> I think the currently planned IRQ process meets expectations.
> Is there anything that needs improvement?

You can register the IRQs of the MFD device with the Linux kernel. This
way the devices can request a threaded IRQ handler directly via the
kernel function, instead of registering the callback.

With a threaded IRQ handler you can directly call the
nct6694_read_msg(), nct6694_write_msg() without the need to start a
workqueue from the callback.

Marc
Ming Yu Oct. 30, 2024, 8:30 a.m. UTC | #4 
Dear Marc,

I am trying to register interrupt controller for the MFD deivce.
I need to queue work to call handle_nested_irq() in the callback
of the interrupt pipe, right?

Best regards,
Ming

Marc Kleine-Budde <mkl@pengutronix.de> 於 2024年10月25日 週五 下午4:33寫道：
>
> On 25.10.2024 16:22:01, Ming Yu wrote:
> > Marc Kleine-Budde <mkl@pengutronix.de> 於 2024年10月24日 週四 下午7:57寫道：
> > > On 24.10.2024 16:59:13, Ming Yu wrote:
> > > > This patch series introduces support for Nuvoton NCT6694, a peripheral
> > > > expander based on USB interface. It models the chip as an MFD driver
> > > > (1/9), GPIO driver(2/9), I2C Adapter driver(3/9), CANfd driver(4/9),
> > > > WDT driver(5/9), HWMON driver(6/9), IIO driver(7/9), PWM driver(8/9),
> > > > and RTC driver(9/9).
> > > >
> > > > The MFD driver implements USB device functionality to issue
> > > > custom-define USB bulk pipe packets for NCT6694. Each child device can
> > > > use the USB functions nct6694_read_msg() and nct6694_write_msg() to issue
> > > > a command. They can also register a handler function that will be called
> > > > when the USB device receives its interrupt pipe.
> > >
> > > What about implementing a proper IRQ demux handler instead?
>
> > I think the currently planned IRQ process meets expectations.
> > Is there anything that needs improvement?
>
> You can register the IRQs of the MFD device with the Linux kernel. This
> way the devices can request a threaded IRQ handler directly via the
> kernel function, instead of registering the callback.
>
> With a threaded IRQ handler you can directly call the
> nct6694_read_msg(), nct6694_write_msg() without the need to start a
> workqueue from the callback.
>
> Marc
>
> --
> Pengutronix e.K.                 | Marc Kleine-Budde          |
> Embedded Linux                   | https://www.pengutronix.de |
> Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |
Marc Kleine-Budde Oct. 30, 2024, 10:12 a.m. UTC | #5 
On 30.10.2024 16:30:37, Ming Yu wrote:
> I am trying to register interrupt controller for the MFD deivce.
> I need to queue work to call handle_nested_irq() in the callback
> of the interrupt pipe, right?

I think you can directly demux the IRQ from the interrupt endpoint
callback. But handle_nested_irq() only works from threaded IRQ context,
so you have to use something like generic_handle_domain_irq_safe().

Have a look for how to setup the IRQ domain:

| drivers/net/usb/lan78xx.c
| drivers/net/usb/smsc95xx.c

But the IRQ demux in the lan78xx only handles the PHY IRQ. The ksz
driver does proper IRQ demux:

| net/dsa/microchip/ksz_common.c

regards,
Marc
Ming Yu Oct. 30, 2024, 2:21 p.m. UTC | #6 
Hi Marc,

okay, I will implement it in the next patch,
thank you very much!

Best regards
Ming

Marc Kleine-Budde <mkl@pengutronix.de> 於 2024年10月30日 週三 下午6:12寫道：
>
> On 30.10.2024 16:30:37, Ming Yu wrote:
> > I am trying to register interrupt controller for the MFD deivce.
> > I need to queue work to call handle_nested_irq() in the callback
> > of the interrupt pipe, right?
>
> I think you can directly demux the IRQ from the interrupt endpoint
> callback. But handle_nested_irq() only works from threaded IRQ context,
> so you have to use something like generic_handle_domain_irq_safe().
>
> Have a look for how to setup the IRQ domain:
>
> | drivers/net/usb/lan78xx.c
> | drivers/net/usb/smsc95xx.c
>
> But the IRQ demux in the lan78xx only handles the PHY IRQ. The ksz
> driver does proper IRQ demux:
>
> | net/dsa/microchip/ksz_common.c
>
> regards,
> Marc
>
> --
> Pengutronix e.K.                 | Marc Kleine-Budde          |
> Embedded Linux                   | https://www.pengutronix.de |
> Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
> Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |