| Message ID | 20220401023306.79532-1-frank@zago.net |
|---|---|
| Headers | show |
| Series | WCH CH341 GPIO and SPI support | expand |
On Fri, Apr 1, 2022 at 4:33 AM frank zago <frank@zago.net> wrote: > The GPIO interface offers 16 GPIOs. 6 are read/write, and 10 are > read-only. > > Signed-off-by: frank zago <frank@zago.net> Looks good to me: Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Thu, 31 Mar 2022, frank zago wrote: > The CH341 is a multifunction chip, presenting 3 different USB PID. One > of these functions is for I2C/SPI/GPIO. This new set of drivers will > manage I2C and GPIO. > > Signed-off-by: frank zago <frank@zago.net> > --- > Documentation/misc-devices/ch341.rst | 114 +++++++++++++++++++++++++++ > Documentation/misc-devices/index.rst | 1 + Not sure I've seen this bundled with an MFD driver before. Please separate them into their own patches. > MAINTAINERS | 7 ++ > drivers/mfd/Kconfig | 10 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/ch341-core.c | 99 +++++++++++++++++++++++ > include/linux/mfd/ch341.h | 26 ++++++ > 7 files changed, 258 insertions(+) > create mode 100644 Documentation/misc-devices/ch341.rst > create mode 100644 drivers/mfd/ch341-core.c > create mode 100644 include/linux/mfd/ch341.h > > diff --git a/Documentation/misc-devices/ch341.rst b/Documentation/misc-devices/ch341.rst > new file mode 100644 > index 000000000000..bf0b83f2eb85 > --- /dev/null > +++ b/Documentation/misc-devices/ch341.rst > @@ -0,0 +1,114 @@ > +.. SPDX-License-Identifier: GPL-2.0-or-later > + > +=========================================================== > +WinChipHead (沁恒) CH341 linux driver for I2C and GPIO mode > +=========================================================== > + > +The CH341 is declined in several flavors, and may support one or more > +of UART, SPI, I2C and GPIO, but not always simultaneously: > + > + - CH341 A/B/F: UART, Printer, SPI, I2C and GPIO > + - CH341 C/T: UART and I2C > + - CH341 H: SPI > + > +They work in 3 different modes, with only one being presented > +depending on the USB PID: > + > + - 0x5523: UART mode, covered by the USB `ch341` serial driver > + - 0x5512: SPI/I2C/GPIO mode, covered by the ch341 MFD drivers > + - 0x5584: Parallel printer mode, covered by the USB `usblp` driver > + > +Mode selection is done at the hardware level by tying some > +pins. Breakout boards with one of the CH341 chip usually have one or > +more jumpers to select which mode they work on. At least one model > +(CJMCU-341) appears to need bridging some solder pads to select a > +different default. Breakout boards also don't usually offer an option > +to configure the chip into printer mode; for that case, connect the > +SCL and SDA lines directly together. > + > +The various CH341 appear to be indistinguishable from the > +software. For instance the ch341 MFD driver will present a GPIO > +interface for the CH341T although physical pins are not present, and > +the device will accept GPIO commands. > + > +The ch341 MFD driver has been tested with a CH341A, CH341B and > +CH341T. > + > +Some breakout boards work in 3.3V and 5V depending on some jumpers. > + > +The black chip programmer with a ZIF socket will power the CH341 at > +3.3V if a jumper is set, but will only output 5V to the chips to be > +programmed, which is not always desirable. A hardware hack to use 3.3V > +everywhere, involving some soldering, is available at > +https://eevblog.com/forum/repair/ch341a-serial-memory-programmer-power-supply-fix/ > + > +Some sample code for the CH341 is available at the manufacturer > +website, at http://wch-ic.com/products/CH341.html > + > +The repository at https://github.com/boseji/CH341-Store contains a lot > +of information on these chips, including datasheets. > + > +This driver is based on the pre-existing work at > +https://github.com/gschorcht/i2c-ch341-usb > + > + > +I2C Caveats > +----------- > + > +The ch341 doesn't work with a Wii nunchuk, possibly because the > +pull-up value is too low (1500 ohms). > + > +i2c AT24 eeproms can be read but not programmed properly because the > +at24 linux driver tries to write a byte at a time, and doesn't wait at > +all (or enough) between writes. Data corruption on writes does occur. > + > +The driver doesn't support detection of I2C devices present on the > +bus. Apparently when a device is not present at a given address, the > +CH341 will return an extra byte of data, but the driver doesn't > +support that. This may be addressed in the future. > + > + > +The GPIOs > +--------- > + > +16 GPIOs are available on the CH341 A/B/F. The first 6 are input/output, > +and the last 10 are input only. > + > +Pinout and their names as they appear on some breakout boards:: > + > + CH341A/B/F GPIO Names Mode > + pin line > + > + 15 0 D0, CS0 input/output > + 16 1 D1, CS1 input/output > + 17 2 D2, CS2 input/output > + 18 3 D3, SCK, DCK input/output > + 19 4 D4, DOUT2, CS3 input/output > + 20 5 D5, MOSI, DOUT, SDO input/output > + 21 6 D6, DIN2 input > + 22 7 D7, MISO, DIN input > + 5 8 ERR input > + 6 9 PEMP input > + 7 10 INT input > + 8 11 SLCT (SELECT) input > + 26 12 RST# (?) input > + 27 13 WT (WAIT) input > + 4 14 DS (Data Select?) input > + 3 15 AS (Address Select?) input > + > + > +GPIO interrupt > +~~~~~~~~~~~~~~ > + > +The INT pin, corresponding to GPIO 10 is an input pin that can trigger > +an interrupt on a rising edge. Only that pin is able to generate an > +interrupt, and only on a rising edge. Trying to monitor events on > +another GPIO, or that GPIO on something other than a rising edge, will > +be rejected. > + > + > +SPI > +--- > + > +This driver doesn't offer an SPI interface (yet) due to the > +impossibility of declaring an SPI device like I2C does. > diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst > index 30ac58f81901..52d03715601e 100644 > --- a/Documentation/misc-devices/index.rst > +++ b/Documentation/misc-devices/index.rst > @@ -19,6 +19,7 @@ fit into other categories. > bh1770glc > eeprom > c2port > + ch341 > dw-xdata-pcie > ibmvmc > ics932s401 > diff --git a/MAINTAINERS b/MAINTAINERS > index cbbd3ce7e0c2..b61af813fb9f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -21211,6 +21211,13 @@ M: David Härdeman <david@hardeman.nu> > S: Maintained > F: drivers/media/rc/winbond-cir.c > > +WINCHIPHEAD CH341 I2C/GPIO MFD DRIVER > +M: Frank Zago <frank@zago.net> > +L: linux-usb@vger.kernel.org > +S: Maintained > +F: drivers/mfd/ch341-core.c > +F: include/linux/mfd/ch341.h > + > WINSYSTEMS EBC-C384 WATCHDOG DRIVER > M: William Breathitt Gray <vilhelm.gray@gmail.com> > L: linux-watchdog@vger.kernel.org > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 3b59456f5545..893acc821a42 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -1784,6 +1784,16 @@ config MFD_LOCHNAGAR > help > Support for Cirrus Logic Lochnagar audio development board. > > +config MFD_CH341 > + tristate "WinChipHead CH341 in I2C/SPI/GPIO mode" > + depends on USB > + help > + If you say yes to this option, support for the CH341 series > + of chips, running in I2C/SPI/GPIO mode will be included. > + > + This driver can also be built as a module. If so, the > + module will be called ch341-core. > + > config MFD_ARIZONA > select REGMAP > select REGMAP_IRQ > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 858cacf659d6..fd615ab3929f 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -13,6 +13,7 @@ obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o > obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o > obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o > obj-$(CONFIG_MFD_BD9571MWV) += bd9571mwv.o > +obj-$(CONFIG_MFD_CH341) += ch341-core.o > obj-$(CONFIG_MFD_CROS_EC_DEV) += cros_ec_dev.o > obj-$(CONFIG_MFD_ENE_KB3930) += ene-kb3930.o > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > diff --git a/drivers/mfd/ch341-core.c b/drivers/mfd/ch341-core.c > new file mode 100644 > index 000000000000..0bb6eb8057e9 > --- /dev/null > +++ b/drivers/mfd/ch341-core.c > @@ -0,0 +1,99 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Core driver for the CH341A, CH341B and CH341T in I2C/SPI/GPIO > + * mode. There are cell drivers available for I2C and GPIO. SPI is not > + * yet supported. > + * > + * Copyright 2022, Frank Zago > + * Copyright (c) 2017 Gunar Schorcht (gunar@schorcht.net) > + * Copyright (c) 2016 Tse Lun Bien > + * Copyright (c) 2014 Marco Gittler > + * Copyright (c) 2006-2007 Till Harbaum (Till@Harbaum.org) > + */ > + > +#include <linux/kernel.h> > +#include <linux/mfd/ch341.h> > +#include <linux/mfd/core.h> > +#include <linux/module.h> > +#include <linux/slab.h> > +#include <linux/usb.h> > + > +static const struct mfd_cell ch341_devs[] = { > +}; > + > +static int ch341_usb_probe(struct usb_interface *iface, > + const struct usb_device_id *usb_id) > +{ > + struct usb_host_endpoint *endpoints; > + struct ch341_device *dev; Please rename this struct 'ch341_ddata' and s/dev/ddata/. > + int rc; 'ret' please. > + dev = devm_kzalloc(&iface->dev, sizeof(*dev), GFP_KERNEL); > + if (!dev) > + return -ENOMEM; > + > + dev->usb_dev = usb_get_dev(interface_to_usbdev(iface)); Can this come later? It would save on the goto dance. > + dev->iface = iface; > + mutex_init(&dev->usb_lock); > + > + if (iface->cur_altsetting->desc.bNumEndpoints != 3) { Why 3? > + rc = -ENODEV; > + goto free_dev; > + } > + > + endpoints = iface->cur_altsetting->endpoint; > + if (!usb_endpoint_is_bulk_in(&endpoints[0].desc) || > + !usb_endpoint_is_bulk_out(&endpoints[1].desc) || > + !usb_endpoint_xfer_int(&endpoints[2].desc)) { What has happened if we get here? Perhaps a comment would be useful? > + rc = -ENODEV; > + goto free_dev; > + } > + > + dev->ep_in = endpoints[0].desc.bEndpointAddress; > + dev->ep_out = endpoints[1].desc.bEndpointAddress; > + dev->ep_intr = endpoints[2].desc.bEndpointAddress; > + dev->ep_intr_interval = endpoints[2].desc.bInterval; > + > + usb_set_intfdata(iface, dev); > + > + rc = mfd_add_hotplug_devices(&iface->dev, ch341_devs, Why are you using 'hotplug' here? ch341_devs is empty right? So no child devices are registered. In which case this is not (yet) an MFD and cannot be accepted. Please add the children. > + ARRAY_SIZE(ch341_devs)); > + if (rc) { > + rc = dev_err_probe(&iface->dev, rc, > + "Failed to add mfd devices to core\n"); I'm not even sure what this means. Should be: "Failed to register child devices\n" > + goto free_dev; > + } > + > + return 0; > + > +free_dev: > + usb_put_dev(dev->usb_dev); > + > + return rc; > +} > + > +static void ch341_usb_disconnect(struct usb_interface *usb_if) > +{ > + struct ch341_device *dev = usb_get_intfdata(usb_if); > + > + mfd_remove_devices(&usb_if->dev); > + usb_put_dev(dev->usb_dev); > +} > + > +static const struct usb_device_id ch341_usb_table[] = { > + { USB_DEVICE(0x1a86, 0x5512) }, > + { } > +}; > +MODULE_DEVICE_TABLE(usb, ch341_usb_table); > + > +static struct usb_driver ch341_usb_driver = { > + .name = "ch341-mfd", > + .id_table = ch341_usb_table, > + .probe = ch341_usb_probe, > + .disconnect = ch341_usb_disconnect, > +}; > +module_usb_driver(ch341_usb_driver); > + > +MODULE_AUTHOR("Various"); This does not look valid. Please drop it. > +MODULE_DESCRIPTION("CH341 USB to I2C/SPI/GPIO adapter"); Is it? What makes it one of those? > +MODULE_LICENSE("GPL"); > diff --git a/include/linux/mfd/ch341.h b/include/linux/mfd/ch341.h > new file mode 100644 > index 000000000000..a87b23e30123 > --- /dev/null > +++ b/include/linux/mfd/ch341.h > @@ -0,0 +1,26 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* Definitions for the CH341 MFD driver */ Drop the term MFD please. > +#include <linux/mutex.h> > +#include <linux/types.h> > + > +#define DEFAULT_TIMEOUT_MS 1000 /* 1s USB requests timeout */ Where is this used? > +/* All commands fit inside a 32-byte segment. There may be several > + * of these segments in a USB command. > + */ This is not a properly formatted multi-line comment. > +#define SEG_SIZE 32 > + > +struct usb_device; > +struct usb_interface; > + > +struct ch341_device { > + struct usb_device *usb_dev; > + struct usb_interface *iface; > + struct mutex usb_lock; > + > + int ep_in; > + int ep_out; > + int ep_intr; > + u8 ep_intr_interval; > +};
On Thu, Mar 31, 2022 at 09:33:04PM -0500, frank zago wrote: > The CH341 is a multifunction chip, presenting 3 different USB PID. One > of these functions is for I2C/SPI/GPIO. This new set of drivers will > manage I2C and GPIO. > > Signed-off-by: frank zago <frank@zago.net> > --- > +static int ch341_usb_probe(struct usb_interface *iface, > + const struct usb_device_id *usb_id) > +{ > + struct usb_host_endpoint *endpoints; > + struct ch341_device *dev; > + int rc; > + > + dev = devm_kzalloc(&iface->dev, sizeof(*dev), GFP_KERNEL); > + if (!dev) > + return -ENOMEM; > + > + dev->usb_dev = usb_get_dev(interface_to_usbdev(iface)); No need to grab a reference unless you're going to hold on to it past disconnect(). > + dev->iface = iface; > + mutex_init(&dev->usb_lock); > + > + if (iface->cur_altsetting->desc.bNumEndpoints != 3) { > + rc = -ENODEV; > + goto free_dev; > + } > + > + endpoints = iface->cur_altsetting->endpoint; > + if (!usb_endpoint_is_bulk_in(&endpoints[0].desc) || > + !usb_endpoint_is_bulk_out(&endpoints[1].desc) || > + !usb_endpoint_xfer_int(&endpoints[2].desc)) { > + rc = -ENODEV; > + goto free_dev; > + } Please use usb_find_common_endpoints() for the above. > + > + dev->ep_in = endpoints[0].desc.bEndpointAddress; > + dev->ep_out = endpoints[1].desc.bEndpointAddress; > + dev->ep_intr = endpoints[2].desc.bEndpointAddress; > + dev->ep_intr_interval = endpoints[2].desc.bInterval; > + > + usb_set_intfdata(iface, dev); > + > + rc = mfd_add_hotplug_devices(&iface->dev, ch341_devs, > + ARRAY_SIZE(ch341_devs)); > + if (rc) { > + rc = dev_err_probe(&iface->dev, rc, > + "Failed to add mfd devices to core\n"); > + goto free_dev; > + } > + > + return 0; > + > +free_dev: > + usb_put_dev(dev->usb_dev); > + > + return rc; > +} > + > +static void ch341_usb_disconnect(struct usb_interface *usb_if) > +{ > + struct ch341_device *dev = usb_get_intfdata(usb_if); > + > + mfd_remove_devices(&usb_if->dev); > + usb_put_dev(dev->usb_dev); > +} Johan
On Thu, Mar 31, 2022 at 09:33:05PM -0500, frank zago wrote: > The GPIO interface offers 16 GPIOs. 6 are read/write, and 10 are > read-only. > > Signed-off-by: frank zago <frank@zago.net> > --- > +struct ch341_gpio { > + struct gpio_chip gpio; > + struct mutex gpio_lock; > + u16 gpio_dir; /* 1 bit per pin, 0=IN, 1=OUT. */ > + u16 gpio_last_read; /* last GPIO values read */ > + u16 gpio_last_written; /* last GPIO values written */ > + union { > + u8 gpio_buf[SEG_SIZE]; > + __le16 gpio_buf_status; > + }; > + > + struct urb *irq_urb; > + struct usb_anchor irq_urb_out; > + u8 irq_buf[CH341_USB_MAX_INTR_SIZE]; > + struct irq_chip irq_chip; > + > + struct ch341_device *ch341; > +}; > +static void ch341_complete_intr_urb(struct urb *urb) > +{ > + struct ch341_gpio *dev = urb->context; > + int rc; > + > + if (urb->status) { > + usb_unanchor_urb(dev->irq_urb); URBs are unanchored by USB core on completion. > + } else { > + /* > + * Data is 8 bytes. Byte 0 might be the length of > + * significant data, which is 3 more bytes. Bytes 1 > + * and 2, and possibly 3, are the pin status. The byte > + * order is different than for the GET_STATUS > + * command. Byte 1 is GPIOs 8 to 15, and byte 2 is > + * GPIOs 0 to 7. > + */ > + > + handle_nested_irq(irq_find_mapping(dev->gpio.irq.domain, > + CH341_GPIO_INT_LINE)); > + > + rc = usb_submit_urb(dev->irq_urb, GFP_ATOMIC); > + if (rc) > + usb_unanchor_urb(dev->irq_urb); > + } > +} > +static void ch341_gpio_irq_enable(struct irq_data *data) > +{ > + struct ch341_gpio *dev = irq_data_get_irq_chip_data(data); > + int rc; > + > + /* > + * The URB might have just been unlinked in > + * ch341_gpio_irq_disable, but the completion handler hasn't > + * been called yet. > + */ > + if (!usb_wait_anchor_empty_timeout(&dev->irq_urb_out, 5000)) > + usb_kill_anchored_urbs(&dev->irq_urb_out); > + > + usb_anchor_urb(dev->irq_urb, &dev->irq_urb_out); > + rc = usb_submit_urb(dev->irq_urb, GFP_ATOMIC); > + if (rc) > + usb_unanchor_urb(dev->irq_urb); This looks confused and broken. usb_kill_anchored_urbs() can sleep so either calling it is broken or using GFP_ATOMIC is unnecessary. And isn't this function called multiple times when enabling more than one irq?! > +} > + > +static void ch341_gpio_irq_disable(struct irq_data *data) > +{ > + struct ch341_gpio *dev = irq_data_get_irq_chip_data(data); > + > + usb_unlink_urb(dev->irq_urb); Same here... > +} > + > +static int ch341_gpio_remove(struct platform_device *pdev) > +{ > + struct ch341_gpio *dev = platform_get_drvdata(pdev); > + > + usb_kill_anchored_urbs(&dev->irq_urb_out); You only have one URB... And what prevents it from being resubmitted here? > + gpiochip_remove(&dev->gpio); > + usb_free_urb(dev->irq_urb); > + > + return 0; > +} > + > +static int ch341_gpio_probe(struct platform_device *pdev) > +{ > + struct ch341_device *ch341 = dev_get_drvdata(pdev->dev.parent); > + struct gpio_irq_chip *girq; > + struct ch341_gpio *dev; > + struct gpio_chip *gpio; > + int rc; > + > + dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); > + if (dev == NULL) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, dev); > + dev->ch341 = ch341; > + mutex_init(&dev->gpio_lock); > + > + gpio = &dev->gpio; > + gpio->label = dev_name(&pdev->dev); > + gpio->parent = &pdev->dev; > + gpio->owner = THIS_MODULE; > + gpio->get_direction = ch341_gpio_get_direction; > + gpio->direction_input = ch341_gpio_direction_input; > + gpio->direction_output = ch341_gpio_direction_output; > + gpio->get = ch341_gpio_get; > + gpio->get_multiple = ch341_gpio_get_multiple; > + gpio->set = ch341_gpio_set; > + gpio->set_multiple = ch341_gpio_set_multiple; > + gpio->base = -1; > + gpio->ngpio = CH341_GPIO_NUM_PINS; > + gpio->can_sleep = true; > + > + dev->irq_chip.name = dev_name(&pdev->dev); > + dev->irq_chip.irq_set_type = ch341_gpio_irq_set_type; > + dev->irq_chip.irq_enable = ch341_gpio_irq_enable; > + dev->irq_chip.irq_disable = ch341_gpio_irq_disable; > + > + girq = &gpio->irq; > + girq->chip = &dev->irq_chip; > + girq->handler = handle_simple_irq; > + girq->default_type = IRQ_TYPE_NONE; > + > + /* Create an URB for handling interrupt */ > + dev->irq_urb = usb_alloc_urb(0, GFP_KERNEL); > + if (!dev->irq_urb) > + return dev_err_probe(&pdev->dev, -ENOMEM, "Cannot allocate the int URB\n"); > + > + usb_fill_int_urb(dev->irq_urb, ch341->usb_dev, > + usb_rcvintpipe(ch341->usb_dev, ch341->ep_intr), > + dev->irq_buf, CH341_USB_MAX_INTR_SIZE, > + ch341_complete_intr_urb, dev, ch341->ep_intr_interval); > + > + init_usb_anchor(&dev->irq_urb_out); > + > + rc = gpiochip_add_data(gpio, dev); > + if (rc) { > + rc = dev_err_probe(&pdev->dev, rc, "Could not add GPIO\n"); > + goto release_urb; > + } > + > + return 0; > + > +release_urb: > + usb_free_urb(dev->irq_urb); > + > + return rc; > +} Johan
Hi Lee, >> + dev->ep_in = endpoints[0].desc.bEndpointAddress; >> + dev->ep_out = endpoints[1].desc.bEndpointAddress; >> + dev->ep_intr = endpoints[2].desc.bEndpointAddress; >> + dev->ep_intr_interval = endpoints[2].desc.bInterval; >> + >> + usb_set_intfdata(iface, dev); >> + >> + rc = mfd_add_hotplug_devices(&iface->dev, ch341_devs, > > Why are you using 'hotplug' here? I replaced with mfd_add_devices, however I'm not sure what the difference is since mfd_add_hotplug_devices() is just a helper with less parameters. That's what the viperboard driver does; I just copied since both devices are similar in functionality. > > ch341_devs is empty right? > > So no child devices are registered. > > In which case this is not (yet) an MFD and cannot be accepted. > > Please add the children. > >> + ARRAY_SIZE(ch341_devs)); >> + if (rc) { >> + rc = dev_err_probe(&iface->dev, rc, >> + "Failed to add mfd devices to core\n"); > > I'm not even sure what this means. Should be: > > "Failed to register child devices\n" Changed. The original string was also from the viperboard driver. > >> +MODULE_DESCRIPTION("CH341 USB to I2C/SPI/GPIO adapter"); > > Is it? What makes it one of those? That's what this chip does, in addition to UART and printer modes. See patch 4. Frank.
Hi Johan, On 5/23/22 10:56, Johan Hovold wrote: >> + >> + dev = devm_kzalloc(&iface->dev, sizeof(*dev), GFP_KERNEL); >> + if (!dev) >> + return -ENOMEM; >> + >> + dev->usb_dev = usb_get_dev(interface_to_usbdev(iface)); > > No need to grab a reference unless you're going to hold on to it past > disconnect(). I removed that. >> + >> + endpoints = iface->cur_altsetting->endpoint; >> + if (!usb_endpoint_is_bulk_in(&endpoints[0].desc) || >> + !usb_endpoint_is_bulk_out(&endpoints[1].desc) || >> + !usb_endpoint_xfer_int(&endpoints[2].desc)) { >> + rc = -ENODEV; >> + goto free_dev; >> + } > > Please use usb_find_common_endpoints() for the above. Thanks. I wasn't aware on that API. It simplifies things a bit. Regards, Frank.
On 5/23/22 11:16, Johan Hovold wrote: >> +static void ch341_complete_intr_urb(struct urb *urb) >> +{ >> + struct ch341_gpio *dev = urb->context; >> + int rc; >> + >> + if (urb->status) { >> + usb_unanchor_urb(dev->irq_urb); > > URBs are unanchored by USB core on completion. Fixed. > >> +static void ch341_gpio_irq_enable(struct irq_data *data) >> +{ >> + struct ch341_gpio *dev = irq_data_get_irq_chip_data(data); >> + int rc; >> + >> + /* >> + * The URB might have just been unlinked in >> + * ch341_gpio_irq_disable, but the completion handler hasn't >> + * been called yet. >> + */ >> + if (!usb_wait_anchor_empty_timeout(&dev->irq_urb_out, 5000)) >> + usb_kill_anchored_urbs(&dev->irq_urb_out); >> + >> + usb_anchor_urb(dev->irq_urb, &dev->irq_urb_out); >> + rc = usb_submit_urb(dev->irq_urb, GFP_ATOMIC); >> + if (rc) >> + usb_unanchor_urb(dev->irq_urb); > > This looks confused and broken. > > usb_kill_anchored_urbs() can sleep so either calling it is broken or > using GFP_ATOMIC is unnecessary. Right, that function can sleep. I changed GFP_ATOMIC to GFP_KERNEL. > > And isn't this function called multiple times when enabling more than > one irq?! There's only one IRQ, so only one URB will be posted at a time. It is reposted as soon as it comes back unless the IRQ is disabled or the device stops. > >> +} >> + >> +static void ch341_gpio_irq_disable(struct irq_data *data) >> +{ >> + struct ch341_gpio *dev = irq_data_get_irq_chip_data(data); >> + >> + usb_unlink_urb(dev->irq_urb); > > Same here... > >> +} >> + >> +static int ch341_gpio_remove(struct platform_device *pdev) >> +{ >> + struct ch341_gpio *dev = platform_get_drvdata(pdev); >> + >> + usb_kill_anchored_urbs(&dev->irq_urb_out); > > You only have one URB... > > And what prevents it from being resubmitted here? I don't see what would resubmit it here. The gpio is being released. Frank.
On Wed, Jun 15, 2022 at 08:29:31PM -0500, Frank Zago wrote: > On 5/23/22 11:16, Johan Hovold wrote: > >> +static void ch341_gpio_irq_enable(struct irq_data *data) > >> +{ > >> + struct ch341_gpio *dev = irq_data_get_irq_chip_data(data); > >> + int rc; > >> + > >> + /* > >> + * The URB might have just been unlinked in > >> + * ch341_gpio_irq_disable, but the completion handler hasn't > >> + * been called yet. > >> + */ > >> + if (!usb_wait_anchor_empty_timeout(&dev->irq_urb_out, 5000)) > >> + usb_kill_anchored_urbs(&dev->irq_urb_out); > >> + > >> + usb_anchor_urb(dev->irq_urb, &dev->irq_urb_out); > >> + rc = usb_submit_urb(dev->irq_urb, GFP_ATOMIC); > >> + if (rc) > >> + usb_unanchor_urb(dev->irq_urb); > > > > This looks confused and broken. > > > > usb_kill_anchored_urbs() can sleep so either calling it is broken or > > using GFP_ATOMIC is unnecessary. > > Right, that function can sleep. I changed GFP_ATOMIC to GFP_KERNEL. These callbacks can be called in atomic context so that's not an option, I'm afraid. > > And isn't this function called multiple times when enabling more than > > one irq?! > > There's only one IRQ, so only one URB will be posted at a time. It > is reposted as soon as it comes back unless the IRQ is disabled or > the device stops. AFAICT you have up to 16 (CH341_GPIO_NUM_PINS) interrupts, not one. So I still say this is broken. > >> +} > >> + > >> +static void ch341_gpio_irq_disable(struct irq_data *data) > >> +{ > >> + struct ch341_gpio *dev = irq_data_get_irq_chip_data(data); > >> + > >> + usb_unlink_urb(dev->irq_urb); > > > > Same here... > >> +} > >> + > >> +static int ch341_gpio_remove(struct platform_device *pdev) > >> +{ > >> + struct ch341_gpio *dev = platform_get_drvdata(pdev); > >> + > >> + usb_kill_anchored_urbs(&dev->irq_urb_out); > > > > You only have one URB... > > > > And what prevents it from being resubmitted here? > > I don't see what would resubmit it here. The gpio is being released. Your implementation needs to handle racing requests. The gpio chip is still registered here. Johan
The CH341 is a multifunction chip, presenting 3 different USB PID. One of these functions is for I2C/SPI/GPIO. This new set of drivers will manage I2C and GPIO. Changes from v4: I should have addressed all the comments: rework of the GPIO interrupt handling code to be more modern, changes in Kconfig wording, some code cleanup. Driver was tested again with up to 4 of these devices. No error seen. Changes from v3: - really converted to an MFD driver. Driver is now split into 3 modules (MFD+I2C+GPIO). - minor code cleanups Changes from v2: - bug fixes - more robust USB enumeration - Changed to an MFD driver as suggested frank zago (3): mfd: ch341: add core driver for the WCH CH341 in I2C/SPI/GPIO mode gpio: ch341: add GPIO MFD cell driver for the CH341 i2c: ch341: add I2C MFD cell driver for the CH341 Documentation/misc-devices/ch341.rst | 114 ++++++++ Documentation/misc-devices/index.rst | 1 + MAINTAINERS | 9 + drivers/gpio/Kconfig | 10 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-ch341.c | 383 +++++++++++++++++++++++++++ drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-ch341.c | 331 +++++++++++++++++++++++ drivers/mfd/Kconfig | 10 + drivers/mfd/Makefile | 1 + drivers/mfd/ch341-core.c | 105 ++++++++ include/linux/mfd/ch341.h | 26 ++ 13 files changed, 1002 insertions(+) create mode 100644 Documentation/misc-devices/ch341.rst create mode 100644 drivers/gpio/gpio-ch341.c create mode 100644 drivers/i2c/busses/i2c-ch341.c create mode 100644 drivers/mfd/ch341-core.c create mode 100644 include/linux/mfd/ch341.h -- 2.32.0