[PATCH RESEND] phy: tusb1210: Use devm_gpiod_get_optional for optional GPIOs
Also simplify the code a bit by specify direction and initial value for
output in devm_gpiod_get_optional function.
Signed-off-by: Axel Lin
Acked-by: Heikki Krogerus
Acked-by: Kishon Vijay Abraham I
---
Hi
This patch was sent on https://lkml.org/lkml/2015/5/31/221 with ACKs.
It's still not in linux-next, so here is a resend.
drivers/phy/phy-tusb1210.c | 28 ++--
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/phy/phy-tusb1210.c b/drivers/phy/phy-tusb1210.c
index 07efdd3..e0174da 100644
--- a/drivers/phy/phy-tusb1210.c
+++ b/drivers/phy/phy-tusb1210.c
@@ -61,32 +61,24 @@ static struct phy_ops phy_ops = {
static int tusb1210_probe(struct ulpi *ulpi)
{
- struct gpio_desc *gpio;
struct tusb1210 *tusb;
u8 val, reg;
- int ret;
tusb = devm_kzalloc(&ulpi->dev, sizeof(*tusb), GFP_KERNEL);
if (!tusb)
return -ENOMEM;
- gpio = devm_gpiod_get(&ulpi->dev, "reset");
- if (!IS_ERR(gpio)) {
- ret = gpiod_direction_output(gpio, 0);
- if (ret)
- return ret;
- gpiod_set_value_cansleep(gpio, 1);
- tusb->gpio_reset = gpio;
- }
+ tusb->gpio_reset = devm_gpiod_get_optional(&ulpi->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(tusb->gpio_reset))
+ return PTR_ERR(tusb->gpio_reset);
+ gpiod_set_value_cansleep(tusb->gpio_reset, 1);
- gpio = devm_gpiod_get(&ulpi->dev, "cs");
- if (!IS_ERR(gpio)) {
- ret = gpiod_direction_output(gpio, 0);
- if (ret)
- return ret;
- gpiod_set_value_cansleep(gpio, 1);
- tusb->gpio_cs = gpio;
- }
+ tusb->gpio_cs = devm_gpiod_get_optional(&ulpi->dev, "cs",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(tusb->gpio_cs))
+ return PTR_ERR(tusb->gpio_cs);
+ gpiod_set_value_cansleep(tusb->gpio_cs, 1);
/*
* VENDOR_SPECIFIC2 register in TUSB1210 can be used for configuring eye
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: XHCI, "brain-dead scanner", and microframe rounding
Hans-Peter Jansen writes: > just a heads up: retesting with 4.0.4 revealed, that this issue isn't fixed Thanks for the heads up; I'll stop trying to figure out the "clean" way to upgrade my Debian box that far ahead of their packages. :) > This behavior persists since Linux 3.16.x (where I setup this box). Just FYI, I already experienced this with 3.14 as well. > Please let me know, if I can be of any help for you for resolving this > issue. Count me in as well, although I'm not very familiar with the modern build process. (My last homebrew kernel was +12 years ago.) > I find it a little sad, that at the dawn of USB 3.1, we still fight with > such > issues on the linux USB 3.0 front. Don't forget the many frustrated users > observing this, that will not speak up. I was in this camp. I tried going through an external hub and a few other tricks without success, then jumped on Google. I saw that "they're talking about it in the kernel mailing lists, it'll get fixed! yay!!" and silently kept an eye on this thread and 1-2 others while my near-new Fujitsu ScanSnap S1500 sits on my desk unused (for the past 10 months because I use USB 3.0 for backups). I'm going to lose my cute uptime and switch my BIOS to USB 2 today though, to reduce my "to scan" pile... which is more reasonable than buying a USB 3 ScanSnap iX500 on impulse. :-/ I'll miss those fast backups though. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: optimal io size / custom alignment
I was not saying RAIDs are virtual devices. I just mentioned it because I saw things like virtio-blk or zram use blk_queue_io_opt(). I know they all use VPDs, but the main point is whether those hardware RAIDs or so are handled by sd_mod, and whether those "transfer lengths" info are still important when it's just a simple drive. To me they look like to be of different nature. That's why I think it's inappropraite that they use the same "variable" / "file" to report because that makes tools like fdisk have trouble determining when does those values really matters. In fact, (maybe I am just unlucky :P) VPDs of all my devices are to some extent broken. I just found out today my Intel 530 SSD connecting directly to SATA also reports totally garbage values for TRIM : ( To be honest the UAS thing doesn't really affect me a lot, I mostly use gdisk now (which doesn't care about i/o size AFAIK). I can also disable uas with the quirk so that VPDs are skipped when I really need fdisk for msdos/mbr. It's just I think that it kind of reveal a problem that has to be dealt with sooner or later, though you can optimistically think that vendors would do better on VPDs in the future. On 19 June 2015 at 05:01, Martin K. Petersen wrote: >> "Tom" == Tom Yan writes: > > Tom> No I put it in the wrong way. What I meant was "sd vs md". For > Tom> example, couldn't the scsi disk driver bind the value it reads from > Tom> the VPD to another variable instead of "optimal i/o size", so that > Tom> this value would be exclusively for RAID (and other virtual > Tom> devices)? > > Who says that RAID is a virtual device? Hardware RAID controllers as > well as SAS, iSCSI and Fibre Channel disk arrays all use the Block > Limits VPD to communicate their preferred I/O size and alignment to > us. As do enterprise disk drives. > > We deal with broken devices by blacklisting them. I suggest you try to > find a way we can reliably identify your UAS devices. If there is a > common pattern, we can entertain adding a workaround. > > -- > Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
[Patch] ax88179_178a: add reset functionality in reset_resume
Dear All, Attached patch fix iperf connection problem after reset resume of ethernet to usb dongle. Without reset functionality, i see ping works after reset resume but iperf connection fails with wrong checksum error message shown by tcpdump. Attached patch fix above issue. Thanks, Vivek 0001-ax88179_178a-add-reset-function-in-reset_resume.patch Description: Binary data
[PATCH 0/2] FTDI CBUS GPIO support
Yet another FTDI GPIO patchset. Yet somewhat different to previous implementations... There are three GPIO modes supported by FTDI devices: 1. Asynchronous Bit Bang Mode (used in Sacha's patch) 2. Synchronous Bit Bang Mode (used in Philipp's patch) 3. CBUS Bit Bang Mode (used in Philipp's patch and this patchset) Previous implementations: - Philipp Hachtmann (https://lkml.org/lkml/2014/5/31/181) - Sascha Silbe (https://lkml.org/lkml/2014/6/9/406) The first two modes allow to control the serial pins and use the USB standard data transfer (write/read) to set the GPIO output values. Hence these modes interference with the standard serial mode of the devices, but are fast. The third option uses the USB control transfer to set GPIOs (which makes bit banging slower), and allows to control only 4 pins. The controllable pins are predefined per device type (in FT232R CBUS0-3, in FT232H ACBUS5-9) and are not required for standard UART/serial communication. However, the default configuration is set to auxiliary functions such as TX/RXLED. Hence to make use of them in CBUS Bit Bang mode, the pins need to be reprogrammed to I/O mode first (EEPROM). All three modes are supported from userspace by libftdi afaik. In my use case I would like to use the additional GPIOs to control an embedded board (power off/reset etc.) and use the serial communication alongside. Using libftdi to use the CBUS Bit Bang mode is cumbersome, since libftdi requires to detach the kernel driver to get access to the device. The user needs then to reconnect the serial terminal every time a GPIO has been used. Hence, if any of these modes, I see most value in supporting the CBUS mode through the kernel's gpiolib API. However, since some functions are shared (e.g. set_bitmode to enable the different bit modes), this patchset is does some ground work for the other modes too, in case anybody wants to do further work on them. This patchset currently supports FT232R type of devices and has been tested using a FT232RL device. I think the FT232H (and probably later) types of devices should work too (at least the Table 3.5 in the FT232H data sheet mentions the ACBUS Signal Option "I/O mode"). However, I don't have such a device to test at my disposal. On the implementation side, I created a distinct GPIO driver in drivers/gpio and create that platform device directly from within the ftdi_sio driver. I understand that the mfd subsystem would be the way to go, however it seems to me quite a big change... At least all USB device IDs would need to be moved to the mfd core device since the mfd device would be registered as a USB driver. I guess the ftdi_sio driver would become a platform device and still live under drivers/usb/serial/...? I just saw that recent discussion by Grant and Linus did not approve this approach...? Stefan Agner (2): USB: ftdi_sio: add CBUS mode for FT232R devices gpio: gpio-ftdi-cbus: add driver for FTDI CBUS GPIOs drivers/gpio/Kconfig | 10 +++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio-ftdi-cbus.c | 167 ++ drivers/usb/serial/ftdi_sio.c | 57 ++ drivers/usb/serial/ftdi_sio.h | 22 ++ include/linux/usb/ftdi_sio.h | 32 include/linux/usb/serial.h| 2 + 7 files changed, 291 insertions(+) create mode 100644 drivers/gpio/gpio-ftdi-cbus.c create mode 100644 include/linux/usb/ftdi_sio.h -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
[PATCH 2/2] gpio: gpio-ftdi-cbus: add driver for FTDI CBUS GPIOs
This driver allows to use the CBUS pins, e.g. CBUS 0-3 on FT232R
type of devices. Note that the pins need to be configured first
by using I/O mode signal option in the EEPROM. This is _not_ the
factory default configuration of any of the four pins.
See also FTDI's Application Note AN_232R-01.
Signed-off-by: Stefan Agner
---
drivers/gpio/Kconfig | 10 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-ftdi-cbus.c | 167 ++
drivers/usb/serial/ftdi_sio.c | 16
4 files changed, 194 insertions(+)
create mode 100644 drivers/gpio/gpio-ftdi-cbus.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index caefe80..450ba9f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -975,6 +975,16 @@ endmenu
menu "USB GPIO expanders"
depends on USB
+config GPIO_FTDI_CBUS
+ tristate "FTDI FT232R CBUS bitmode GPIO support"
+ depends on USB_SERIAL_FTDI_SIO
+ help
+ Say yes to use up to four CBUS pins on FT232R type of devices
+ Note that the pins need to be configured in EEPROM using to
+ "I/O mode" signal option first. The factory configuration
+ does not ship with this signal option set for any of the four
+ supported CBUS pins.
+
config GPIO_VIPERBOARD
tristate "Viperboard GPIO a & b support"
depends on MFD_VIPERBOARD && USB
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f71bb97..a5d661b4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_GPIO_DWAPB) += gpio-dwapb.o
obj-$(CONFIG_GPIO_EM) += gpio-em.o
obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
obj-$(CONFIG_GPIO_F7188X) += gpio-f7188x.o
+obj-$(CONFIG_GPIO_FTDI_CBUS) += gpio-ftdi-cbus.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
diff --git a/drivers/gpio/gpio-ftdi-cbus.c b/drivers/gpio/gpio-ftdi-cbus.c
new file mode 100644
index 000..3a4dc46
--- /dev/null
+++ b/drivers/gpio/gpio-ftdi-cbus.c
@@ -0,0 +1,167 @@
+/*
+ * gpiolib support for FTDI SIO chips supporting CBUS GPIO's (FT232R class)
+ *
+ * Copyright 2015 Stefan Agner
+ *
+ * Author: Stefan Agner
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Note: To use the GPIOs on CBUS the signal option need to be set to
+ * I/O mode in EEPROM!
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct ftdi_cbus_gpio {
+ struct usb_serial_port *port;
+ struct gpio_chip gpio_chip;
+ u8 cbus_mask;
+};
+
+static inline struct ftdi_cbus_gpio *to_ftdi_cbus_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct ftdi_cbus_gpio, gpio_chip);
+}
+
+static int ftdi_cbus_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset)
+{
+ struct ftdi_cbus_gpio *fcg = to_ftdi_cbus_gpio(chip);
+
+ fcg->cbus_mask &= ~((1 << offset) << 4);
+
+ return ftdi_sio_set_bitmode(fcg->port, fcg->cbus_mask, BITMODE_CBUS);
+}
+
+static int ftdi_cbus_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ struct ftdi_cbus_gpio *fcg = to_ftdi_cbus_gpio(chip);
+
+ fcg->cbus_mask |= ((1 << offset) << 4);
+ if (value)
+ fcg->cbus_mask |= (1 << offset);
+ else
+ fcg->cbus_mask &= ~(1 << offset);
+
+ return ftdi_sio_set_bitmode(fcg->port, fcg->cbus_mask, BITMODE_CBUS);
+}
+
+static void ftdi_cbus_gpio_set(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ struct ftdi_cbus_gpio *fcg = to_ftdi_cbus_gpio(chip);
+ int ret;
+
+ if (value)
+ fcg->cbus_mask |= (1 << offset);
+ else
+ fcg->cbus_mask &= ~(1 << offset);
+
+ ret = ftdi_sio_set_bitmode(fcg->port, fcg->cbus_mask, 0x20);
+ if (ret < 0)
+ dev_warn(chip->dev, "error setting pin value, %d\n", ret);
+}
+
+static int ftdi_cbus_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct ftdi_cbus_gpio *fcg = to_ftdi_cbus_gpio(chip);
+ u8 val;
+ int ret;
+
+ ret = ftdi_sio_read_pins(fcg->port, &val);
+
+ if (ret < 0) {
+ dev_warn(chip->dev, "error getting pin value, %d\n", ret);
+ return 0;
+ }
+
+ if (val & (1 << offset))
+ return 1;
+ else
+ return 0;
+}
+
+static struct gpio_chip ftdi_cbus_gpio_chip = {
+ .label = "ftdi-cbus-gpio",
+ .owner = THIS_MODULE,
+ .direction_input= ftdi_cbus_gpio_direct
[PATCH 1/2] USB: ftdi_sio: add CBUS mode for FT232R devices
Add interface to allow CBUS access. The functions set_bitmode and
read_pins use control transfers only hence should not interfere
with the serial operation mode.
Signed-off-by: Stefan Agner
---
drivers/usb/serial/ftdi_sio.c | 41 +
drivers/usb/serial/ftdi_sio.h | 22 ++
include/linux/usb/ftdi_sio.h | 32
include/linux/usb/serial.h| 2 ++
4 files changed, 97 insertions(+)
create mode 100644 include/linux/usb/ftdi_sio.h
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 4c8b3b8..23a3280 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1384,6 +1384,47 @@ static int change_speed(struct tty_struct *tty, struct
usb_serial_port *port)
return rv;
}
+int ftdi_sio_set_bitmode(struct usb_serial_port *port, u8 bitmask, u8 bitmode)
+{
+ struct ftdi_private *priv = usb_get_serial_port_data(port);
+ __u16 urb_value = 0;
+ int rv = 0;
+
+ urb_value = bitmode << 8 | bitmask;
+
+ rv = usb_control_msg(port->serial->dev,
+usb_sndctrlpipe(port->serial->dev, 0),
+FTDI_SIO_SET_BITMODE_REQUEST,
+FTDI_SIO_SET_BITMODE_REQUEST_TYPE,
+urb_value, priv->interface,
+NULL, 0, WDR_SHORT_TIMEOUT);
+ return rv;
+}
+EXPORT_SYMBOL(ftdi_sio_set_bitmode);
+
+int ftdi_sio_read_pins(struct usb_serial_port *port, u8 *pins)
+{
+ struct ftdi_private *priv = usb_get_serial_port_data(port);
+ int rv;
+ u8 *buf;
+
+ buf = kmalloc(1, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ rv = usb_control_msg(port->serial->dev,
+usb_rcvctrlpipe(port->serial->dev, 0),
+FTDI_SIO_READ_PINS_REQUEST,
+FTDI_SIO_READ_PINS_REQUEST_TYPE,
+0, priv->interface,
+buf, 1, WDR_SHORT_TIMEOUT);
+ *pins = *buf;
+ kfree(buf);
+
+ return rv;
+}
+EXPORT_SYMBOL(ftdi_sio_read_pins);
+
static int write_latency_timer(struct usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
diff --git a/drivers/usb/serial/ftdi_sio.h b/drivers/usb/serial/ftdi_sio.h
index ed58c6f..a62eb15 100644
--- a/drivers/usb/serial/ftdi_sio.h
+++ b/drivers/usb/serial/ftdi_sio.h
@@ -35,6 +35,8 @@
#define FTDI_SIO_SET_ERROR_CHAR7 /* Set the error character */
#define FTDI_SIO_SET_LATENCY_TIMER 9 /* Set the latency timer */
#define FTDI_SIO_GET_LATENCY_TIMER 10 /* Get the latency timer */
+#define FTDI_SIO_SET_BITMODE 11 /* Set the bitmode */
+#define FTDI_SIO_READ_PINS 12 /* Read pins in bitmode */
/* Interface indices for FT2232, FT2232H and FT4232H devices */
#define INTERFACE_A1
@@ -345,6 +347,26 @@ enum ftdi_sio_baudrate {
*/
/*
+ * FTDI_SIO_SET_BITMODE
+ *
+ * Set the chip's bitbang mode. Used to switch FT232R into CBUSmode.
+ * For details see of the bitbang modes supported by FT232R devices
+ * refer to the FTDI Application Note AN_232R-01.
+ */
+
+#define FTDI_SIO_SET_BITMODE_REQUEST FTDI_SIO_SET_BITMODE
+#define FTDI_SIO_SET_BITMODE_REQUEST_TYPE 0x40
+
+/*
+ * FTDI_SIO_READ_PINS
+ *
+ * Read the current value of the bit mode.
+ */
+
+#define FTDI_SIO_READ_PINS_REQUEST FTDI_SIO_READ_PINS
+#define FTDI_SIO_READ_PINS_REQUEST_TYPE 0xC0
+
+/*
* FTDI_SIO_SET_EVENT_CHAR
*
* Set the special event character for the specified communications port.
diff --git a/include/linux/usb/ftdi_sio.h b/include/linux/usb/ftdi_sio.h
new file mode 100644
index 000..8e1a292
--- /dev/null
+++ b/include/linux/usb/ftdi_sio.h
@@ -0,0 +1,32 @@
+/*
+ * Interface for FTDI SIO driver used by CBUS GPIO driver
+ *
+ * Copyright 2015 Stefan Agner
+ *
+ * Author: Stefan Agner
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef __LINUX_USB_FTDI_SIO_H
+#define __LINUX_USB_FTDI_SIO_H
+
+#include
+
+/* MPSSE bitbang modes */
+enum ftdi_mpsse_mode {
+ /* switch off bitbang mode, back to regular serial/FIFO */
+ BITMODE_RESET = 0x00,
+
+ /* Bitbang on CBUS pins of R-type chips, configure in EEPROM before */
+ BITMODE_CBUS = 0x20,
+};
+
+int ftdi_sio_set_bitmode(struct usb_serial_port *port, u8 bitmask, u8 bitmode);
+int ftdi_sio_read_pins(struct usb_serial_port *port, u8 *pins);
+
+#endif /* __LINUX_USB_FTDI_SIO_H */
+
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index 704a1ab..d710656 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -17,6 +17,8 @@
#include
#inclu
Re: [PATCH 0/2] FTDI CBUS GPIO support
Stefan Agner wrote: > libftdi requires to detach the kernel driver to get access to the device Control transfers ought to be possible without a detach. //Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: optimal io size / custom alignment
> "Tom" == Tom Yan writes: Tom> I know they all use VPDs, but the main point is whether those Tom> hardware RAIDs or so are handled by sd_mod, and whether those Tom> "transfer lengths" info are still important when it's just a simple Tom> drive. To me they look like to be of different nature. We don't know whether a discovered device is "a simple drive". And once again: The whole point of the queue limit is to have an common abstraction for all block devices. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: cdc_acm / cdc_wdm issue. Connection to device lost (Sony Ericsson w660)
On Fri, 2015-06-19 at 19:43 +0200, Fab Stz wrote: > Oh ! I just realized my mistake. Actually it is not the kernel that is faulty > but my configuration (since I migrated from debian wheezy to jessie). > > I had connection/disconnection issues because of conflicts between gammu and > ModemManager. > > It is also ModemManager which took the control of my phone and switched to 3G > network. Yes, unless disabled or told to ignore your device, ModemManager will probe many serial devices with some AT commands which might conflict with other tools like gammu that want to do the same thing. But MM (at least 0.7 or later) shouldn't be changing any settings on your device unless it has been told to "enable" it by some other tool. NetworkManager will ask MM to enable the modem if NM's WWAN "switch" hasn't been turned off (nmcli radio wwan [on|off]). So that's probably what was happening. dan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: [PATCH 0/2] FTDI CBUS GPIO support
Am 21.06.2015 um 00:12 schrieb Stefan Agner: There are three GPIO modes supported by FTDI devices: 1. Asynchronous Bit Bang Mode (used in Sacha's patch) 2. Synchronous Bit Bang Mode (used in Philipp's patch) 3. CBUS Bit Bang Mode (used in Philipp's patch and this patchset) 1. No idea, could be 2. wrong 3. wrong This is more complicated as I remember. The chip (I speak of FT232H here, because it's "my" chip) has quite a lot of options. Reference: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232H.pdf I did not use a bit bang mode. My patches were about synchronous FIFO mode and CBUS control. I'll try to explain. There are eight data lines called ADBUS[7:0] and ten "other" lines called ACBUS[9:0]. When the chip is configured (EEPROM!) for UART mode (default), the RX, TX and modem status lines are assigned to ADBUS[7:0]. ACBUS7 can be used as an USB voltage detect input (and for nothing else in any case as it looks). The other ACBUS lines can be configured for several tasks like TXLED, RXLED, SLEEP, clock output etc. The ACBUS5, ACBUS6, ACBUS8 and ACBUS9 can also individually be configured to I/O mode which the datasheet calls "ACBUS BitBang". These up to four (depending on user's choice) GPIO lines can be accessed from the host. They're usable for extra control to attached hardware. Controlling these CBUS lines was the intent of my CBUS patch. My usblink board (FT232H plus FPGA etc.) makes use of the FT232H's asynchronous and synchronous FIFO modes. The asynchronous FIFO mode has to be selected by EEPROM settings. This works out of the box with the ftdi_sio driver. The driver doesn't notice anything. Just works. Baud rate settings etc. become meaningless, of course :-) If you want to get the full USB 2.0 speed you have to use the synchronous FIFO mode. For this to work the chip has to be eeprom configured to asynchronous FIFO mode and then the driver has to select synchronous FIFO mode. This was subject of my other patch. The chip has some other more or less cool modes but I have no idea if and how they work with the ftdi_sio driver. Two of them are named asynchronous and synchronous BitBang mode. Conclusion: The FTDI chip has different *modes* of operation which can be selected by eeprom and/or software. The mode determines the use of the *ADBUS* and some ACBUS pins. Two of modes are called bit bang modes. ACBUS bit bang is an additional functionality which is *not to be confused* with the chip's operation mode! The confusion comes from things like FTDI_SIO_SET_BITBANG_REQUEST to do anything... I have not forgotten about the comments on my patches a year ago. I just did not yet find the time to do add that GPIO stuff. Two interfaces have to be added to the driver: - One for setting the mode (here: switch to synchronous FIFO) I suggest adding a sysfs property here. - One for the four CBUS bits I *still* suggest adding a sysfs property *and* adding GPIO support as well. I will most probably get back to the stuff in July. Kind regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: Locking issues w/ functionfs gadget and aio?
On Fri, Jun 12, 2015 at 05:51:12PM -0700, John Stultz wrote:
> I'm not super sure what the right fix is, but if do something like the
> following (sorry, whitespace corrupted via copy/paste), I don't seem
> to run into the problem.
Looks sane. Which tree would you prefer it to go through, vfs or usb?
BTW, in either case you'd need Signed-off-by: on that patch...
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index 3507f88..e322818 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -924,7 +924,8 @@ static ssize_t ffs_epfile_write_iter(struct kiocb
> *kiocb, struct iov_iter *from)
>
> kiocb->private = p;
>
> - kiocb_set_cancel_fn(kiocb, ffs_aio_cancel);
> + if (p->aio)
> + kiocb_set_cancel_fn(kiocb, ffs_aio_cancel);
>
> res = ffs_epfile_io(kiocb->ki_filp, p);
> if (res == -EIOCBQUEUED)
> @@ -968,7 +969,8 @@ static ssize_t ffs_epfile_read_iter(struct kiocb
> *kiocb, struct iov_iter *to)
>
> kiocb->private = p;
>
> - kiocb_set_cancel_fn(kiocb, ffs_aio_cancel);
> + if(p->aio)
> + kiocb_set_cancel_fn(kiocb, ffs_aio_cancel);
>
> res = ffs_epfile_io(kiocb->ki_filp, p);
> if (res == -EIOCBQUEUED)
>
>
> Is there a better solution here? I'm not sure I see if the
> is_sync_kiocb(kiocb) check would ever be false from here, so I'm not
> sure if all the p->aio checking is really needed or not.
>
> This issue seems to have been introduced with 70e60d917e91fff
> (gadget/function/f_fs.c: switch to ->{read,write}_iter())
>
> thanks
> -john
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
[Patch v1] ax88179_178a: add reset functionality in reset_resume
>From d178065c9e3cfa8a45ef537fae7412775339beb0 Mon Sep 17 00:00:00 2001
From: Vivek Kumar Bhagat
Date: Thu, 11 Jun 2015 07:23:46 -0700
Subject: [PATCH] ax88179_178a: add reset functionality in reset_resume
Without reset functionality in reset_resume, iperf connection does not
establish after suspend/resume however ping works at the same time.
iperf connection fails with wrong checksum error shown by tcpdump.
reset function inside reset_resume solves above bug. We have verified
this issue on ASIX based ST Lab, Cadyce dongle.
Signed-off-by: Vivek Kumar Bhagat
Signed-off-by: Praveen Kumar
---
drivers/net/usb/ax88179_178a.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c1..00928c0 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1630,6 +1630,18 @@ static int ax88179_stop(struct usbnet *dev)
return 0;
}
+static int ax88179_reset_resume(struct usb_interface *intf)
+{
+ struct usbnet *dev = usb_get_intfdata(intf);
+ int ret;
+
+ ret = ax88179_reset(dev);
+ if (ret < 0)
+ return ret;
+
+ return ax88179_resume(intf);
+}
+
static const struct driver_info ax88179_info = {
.description = "ASIX AX88179 USB 3.0 Gigabit Ethernet",
.bind = ax88179_bind,
@@ -1744,7 +1756,7 @@ static struct usb_driver ax88179_178a_driver = {
.probe = usbnet_probe,
.suspend = ax88179_suspend,
.resume = ax88179_resume,
- .reset_resume = ax88179_resume,
+ .reset_resume = ax88179_reset_resume,
.disconnect = usbnet_disconnect,
.supports_autosuspend = 1,
.disable_hub_initiated_lpm = 1,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
[Patch v1] ax88179_178a: add reset functionality in reset_resume
Without reset functionality in reset_resume, iperf connection does not
establish after suspend/resume however ping works at the same time.
iperf connection fails with wrong checksum error shown by tcpdump.
reset function inside reset_resume solves above bug. We have verified
this issue on ASIX based ST Lab, Cadyce dongle.
Signed-off-by: Vivek Kumar Bhagat
Signed-off-by: Praveen Kumar
---
drivers/net/usb/ax88179_178a.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c1..00928c0 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1630,6 +1630,18 @@ static int ax88179_stop(struct usbnet *dev)
return 0;
}
+static int ax88179_reset_resume(struct usb_interface *intf)
+{
+ struct usbnet *dev = usb_get_intfdata(intf);
+ int ret;
+
+ ret = ax88179_reset(dev);
+ if (ret < 0)
+ return ret;
+
+ return ax88179_resume(intf);
+}
+
static const struct driver_info ax88179_info = {
.description = "ASIX AX88179 USB 3.0 Gigabit Ethernet",
.bind = ax88179_bind,
@@ -1744,7 +1756,7 @@ static struct usb_driver ax88179_178a_driver = {
.probe = usbnet_probe,
.suspend = ax88179_suspend,
.resume = ax88179_resume,
- .reset_resume = ax88179_resume,
+ .reset_resume = ax88179_reset_resume,
.disconnect = usbnet_disconnect,
.supports_autosuspend = 1,
.disable_hub_initiated_lpm = 1,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
