[PATCH] usb: phy: samsung: fix sparse warning
Fix the following sparse warning:
drivers/usb/phy/phy-samsung-usb2.c:50:26: sparse: incorrect type in argument 1
(different address spaces)
drivers/usb/phy/phy-samsung-usb2.c:50:26:expected void const volatile
[noderef] asn:2*addr
drivers/usb/phy/phy-samsung-usb2.c:50:26:got void *
Cc: Vivek Gautam gautam.vi...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/phy/phy-samsung-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-samsung-usb2.c
b/drivers/usb/phy/phy-samsung-usb2.c
index dce9681..45ffe03 100644
--- a/drivers/usb/phy/phy-samsung-usb2.c
+++ b/drivers/usb/phy/phy-samsung-usb2.c
@@ -43,7 +43,7 @@ static int samsung_usbphy_set_host(struct usb_otg *otg,
struct usb_bus *host)
return 0;
}
-static bool exynos5_phyhost_is_on(void *regs)
+static bool exynos5_phyhost_is_on(void __iomem *regs)
{
u32 reg;
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/21] USB: fixes for 3.9-final
Here's an updated series of fixes for 3.9-final. The first four patches and the mos7840 broken-TIOCMIWAIT-patch are unchanged from previous postings, and the remaining patches fix two use-after-free in all usb-serial TIOCMIWAIT implementations: the private wait-queue along with any other data may be gone when waking up after a disconnect. I decided to fix the use-after-free separately from the issue of processes not waking up at disconnect, which I'm holding back until 3.10. Thanks, Johan Johan Hovold (21): USB: cdc-acm: fix device unregistration USB: garmin_gps: fix memory leak on disconnect USB: io_ti: fix get_icount for two port adapters USB: serial: fix interface refcounting USB: serial: add modem-status-change wait queue USB: ark3116: fix use-after-free in TIOCMIWAIT USB: ch341: fix use-after-free in TIOCMIWAIT USB: cypress_m8: fix use-after-free in TIOCMIWAIT USB: f81232: fix use-after-free in TIOCMIWAIT USB: ftdi_sio: fix use-after-free in TIOCMIWAIT USB: io_edgeport: fix use-after-free in TIOCMIWAIT USB: io_ti: fix use-after-free in TIOCMIWAIT USB: mct_u232: fix use-after-free in TIOCMIWAIT USB: mos7840: fix broken TIOCMIWAIT USB: mos7840: fix use-after-free in TIOCMIWAIT USB: oti6858: fix use-after-free in TIOCMIWAIT USB: pl2303: fix use-after-free in TIOCMIWAIT USB: quatech2: fix use-after-free in TIOCMIWAIT USB: spcp8x5: fix use-after-free in TIOCMIWAIT USB: ssu100: fix use-after-free in TIOCMIWAIT USB: ti_usb_3410_5052: fix use-after-free in TIOCMIWAIT drivers/usb/class/cdc-acm.c | 3 ++- drivers/usb/serial/ark3116.c | 10 ++ drivers/usb/serial/ch341.c| 11 ++- drivers/usb/serial/cypress_m8.c | 14 -- drivers/usb/serial/f81232.c | 9 + drivers/usb/serial/ftdi_sio.c | 19 --- drivers/usb/serial/garmin_gps.c | 7 +-- drivers/usb/serial/io_edgeport.c | 12 +++- drivers/usb/serial/io_ti.c| 13 +++-- drivers/usb/serial/mct_u232.c | 13 +++-- drivers/usb/serial/mos7840.c | 16 ++-- drivers/usb/serial/oti6858.c | 10 ++ drivers/usb/serial/pl2303.c | 11 ++- drivers/usb/serial/quatech2.c | 12 +++- drivers/usb/serial/spcp8x5.c | 9 + drivers/usb/serial/ssu100.c | 12 +++- drivers/usb/serial/ti_usb_3410_5052.c | 10 ++ drivers/usb/serial/usb-serial.c | 3 ++- include/linux/usb/serial.h| 2 ++ 19 files changed, 108 insertions(+), 88 deletions(-) -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/21] USB: spcp8x5: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/spcp8x5.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/spcp8x5.c b/drivers/usb/serial/spcp8x5.c
index 91ff8e3..549ef68 100644
--- a/drivers/usb/serial/spcp8x5.c
+++ b/drivers/usb/serial/spcp8x5.c
@@ -149,7 +149,6 @@ enum spcp8x5_type {
struct spcp8x5_private {
spinlock_t lock;
enum spcp8x5_type type;
- wait_queue_head_t delta_msr_wait;
u8 line_control;
u8 line_status;
};
@@ -179,7 +178,6 @@ static int spcp8x5_port_probe(struct usb_serial_port *port)
return -ENOMEM;
spin_lock_init(priv-lock);
- init_waitqueue_head(priv-delta_msr_wait);
priv-type = type;
usb_set_serial_port_data(port , priv);
@@ -475,7 +473,7 @@ static void spcp8x5_process_read_urb(struct urb *urb)
priv-line_status = ~UART_STATE_TRANSIENT_MASK;
spin_unlock_irqrestore(priv-lock, flags);
/* wake up the wait for termios */
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
if (!urb-actual_length)
return;
@@ -526,12 +524,15 @@ static int spcp8x5_wait_modem_info(struct usb_serial_port
*port,
while (1) {
/* wake up in bulk read */
- interruptible_sleep_on(priv-delta_msr_wait);
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(priv-lock, flags);
status = priv-line_status;
spin_unlock_irqrestore(priv-lock, flags);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/21] USB: mos7840: fix broken TIOCMIWAIT
Make sure waiting processes are woken on modem-status changes. Currently processes are only woken on termios changes regardless of whether the modem status has changed. Cc: stable sta...@vger.kernel.org Signed-off-by: Johan Hovold jhov...@gmail.com --- drivers/usb/serial/mos7840.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c index 809fb32..1b83b01 100644 --- a/drivers/usb/serial/mos7840.c +++ b/drivers/usb/serial/mos7840.c @@ -423,6 +423,9 @@ static void mos7840_handle_new_msr(struct moschip_port *port, __u8 new_msr) icount-rng++; smp_wmb(); } + + mos7840_port-delta_msr_cond = 1; + wake_up_interruptible(mos7840_port-delta_msr_wait); } } @@ -2017,8 +2020,6 @@ static void mos7840_change_port_settings(struct tty_struct *tty, mos7840_port-read_urb_busy = false; } } - wake_up(mos7840_port-delta_msr_wait); - mos7840_port-delta_msr_cond = 1; dev_dbg(port-dev, %s - mos7840_port-shadowLCR is End %x\n, __func__, mos7840_port-shadowLCR); } -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/21] USB: cdc-acm: fix device unregistration
Unregister tty device in disconnect as is required by the USB stack. By deferring unregistration to when the last tty reference is dropped, the parent interface device can get unregistered before the child resulting in broken hotplug events being generated when the tty is finally closed: KERNEL[2290.798128] remove /devices/pci:00/:00:1d.7/usb2/2-1/2-1:3.1 (usb) KERNEL[2290.804589] remove /devices/pci:00/:00:1d.7/usb2/2-1 (usb) KERNEL[2294.554799] remove /2-1:3.1/tty/ttyACM0 (tty) The driver must deal with tty callbacks after disconnect by checking the disconnected flag. Specifically, further opens must be prevented and this is already implemented. Cc: stable sta...@vger.kernel.org Cc: Oliver Neukum oneu...@suse.de Acked-by: Oliver Neukum oneu...@suse.de Signed-off-by: Johan Hovold jhov...@gmail.com --- drivers/usb/class/cdc-acm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index 8ac25ad..e18e9a8 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -593,7 +593,6 @@ static void acm_port_destruct(struct tty_port *port) dev_dbg(acm-control-dev, %s\n, __func__); - tty_unregister_device(acm_tty_driver, acm-minor); acm_release_minor(acm); usb_put_intf(acm-control); kfree(acm-country_codes); @@ -1411,6 +1410,8 @@ static void acm_disconnect(struct usb_interface *intf) stop_data_traffic(acm); + tty_unregister_device(acm_tty_driver, acm-minor); + usb_free_urb(acm-ctrlurb); for (i = 0; i ACM_NW; i++) usb_free_urb(acm-wb[i].urb); -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/21] USB: io_ti: fix get_icount for two port adapters
Add missing get_icount field to two-port driver.
The two-port driver was not updated when switching to the new icount
interface in commit 0bca1b913aff (tty: Convert the USB drivers to the
new icount interface).
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/io_ti.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index c237766..d7d3c0e 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2649,6 +2649,7 @@ static struct usb_serial_driver edgeport_2port_device = {
.set_termios= edge_set_termios,
.tiocmget = edge_tiocmget,
.tiocmset = edge_tiocmset,
+ .get_icount = edge_get_icount,
.write = edge_write,
.write_room = edge_write_room,
.chars_in_buffer= edge_chars_in_buffer,
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/21] USB: ch341: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/ch341.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index d255f66..07d4650 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -80,7 +80,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
struct ch341_private {
spinlock_t lock; /* access lock */
- wait_queue_head_t delta_msr_wait; /* wait queue for modem status */
unsigned baud_rate; /* set baud rate */
u8 line_control; /* set line control value RTS/DTR */
u8 line_status; /* active status of modem control inputs */
@@ -252,7 +251,6 @@ static int ch341_port_probe(struct usb_serial_port *port)
return -ENOMEM;
spin_lock_init(priv-lock);
- init_waitqueue_head(priv-delta_msr_wait);
priv-baud_rate = DEFAULT_BAUD_RATE;
priv-line_control = CH341_BIT_RTS | CH341_BIT_DTR;
@@ -298,7 +296,7 @@ static void ch341_dtr_rts(struct usb_serial_port *port, int
on)
priv-line_control = ~(CH341_BIT_RTS | CH341_BIT_DTR);
spin_unlock_irqrestore(priv-lock, flags);
ch341_set_handshake(port-serial-dev, priv-line_control);
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
}
static void ch341_close(struct usb_serial_port *port)
@@ -491,7 +489,7 @@ static void ch341_read_int_callback(struct urb *urb)
tty_kref_put(tty);
}
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
}
exit:
@@ -517,11 +515,14 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
spin_unlock_irqrestore(priv-lock, flags);
while (!multi_change) {
- interruptible_sleep_on(priv-delta_msr_wait);
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(priv-lock, flags);
status = priv-line_status;
multi_change = priv-multi_status_change;
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/21] USB: io_ti: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/io_ti.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index d7d3c0e..172 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -87,9 +87,6 @@ struct edgeport_port {
int close_pending;
int lsr_event;
struct async_icount icount;
- wait_queue_head_t delta_msr_wait; /* for handling sleeping while
- waiting for msr change to
- happen */
struct edgeport_serial *edge_serial;
struct usb_serial_port *port;
__u8 bUartMode; /* Port type, 0: RS232, etc. */
@@ -1459,7 +1456,7 @@ static void handle_new_msr(struct edgeport_port
*edge_port, __u8 msr)
icount-dcd++;
if (msr EDGEPORT_MSR_DELTA_RI)
icount-rng++;
- wake_up_interruptible(edge_port-delta_msr_wait);
+ wake_up_interruptible(edge_port-port-delta_msr_wait);
}
/* Save the new modem status */
@@ -1754,7 +1751,6 @@ static int edge_open(struct tty_struct *tty, struct
usb_serial_port *port)
dev = port-serial-dev;
memset((edge_port-icount), 0x00, sizeof(edge_port-icount));
- init_waitqueue_head(edge_port-delta_msr_wait);
/* turn off loopback */
status = ti_do_config(edge_port, UMPC_SET_CLR_LOOPBACK, 0);
@@ -2434,10 +2430,14 @@ static int edge_ioctl(struct tty_struct *tty,
dev_dbg(port-dev, %s - TIOCMIWAIT\n, __func__);
cprev = edge_port-icount;
while (1) {
- interruptible_sleep_on(edge_port-delta_msr_wait);
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+
+ if (port-serial-disconnected)
+ return -EIO;
+
cnow = edge_port-icount;
if (cnow.rng == cprev.rng cnow.dsr == cprev.dsr
cnow.dcd == cprev.dcd cnow.cts == cprev.cts)
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/21] USB: serial: add modem-status-change wait queue
Add modem-status-change wait queue to struct usb_serial_port that
subdrivers can use to implement TIOCMIWAIT.
Currently subdrivers use a private wait queue which may have been
released when waking up after device disconnected.
Note that we're adding a new wait queue rather than reusing the tty-port
one as we do not want to get woken up at hangup (yet).
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
include/linux/usb/serial.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index ef9be7e..1819b59 100644
--- a/include/linux/usb/serial.h
+++ b/include/linux/usb/serial.h
@@ -66,6 +66,7 @@
* port.
* @flags: usb serial port flags
* @write_wait: a wait_queue_head_t used by the port.
+ * @delta_msr_wait: modem-status-change wait queue
* @work: work queue entry for the line discipline waking up.
* @throttled: nonzero if the read urb is inactive to throttle the device
* @throttle_req: nonzero if the tty wants to throttle us
@@ -112,6 +113,7 @@ struct usb_serial_port {
unsigned long flags;
wait_queue_head_t write_wait;
+ wait_queue_head_t delta_msr_wait;
struct work_struct work;
charthrottled;
charthrottle_req;
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/21] USB: f81232: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/f81232.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index b1b2dc6..a172ad5 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -47,7 +47,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
struct f81232_private {
spinlock_t lock;
- wait_queue_head_t delta_msr_wait;
u8 line_control;
u8 line_status;
};
@@ -111,7 +110,7 @@ static void f81232_process_read_urb(struct urb *urb)
line_status = priv-line_status;
priv-line_status = ~UART_STATE_TRANSIENT_MASK;
spin_unlock_irqrestore(priv-lock, flags);
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
if (!urb-actual_length)
return;
@@ -256,11 +255,14 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
spin_unlock_irqrestore(priv-lock, flags);
while (1) {
- interruptible_sleep_on(priv-delta_msr_wait);
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(priv-lock, flags);
status = priv-line_status;
spin_unlock_irqrestore(priv-lock, flags);
@@ -322,7 +324,6 @@ static int f81232_port_probe(struct usb_serial_port *port)
return -ENOMEM;
spin_lock_init(priv-lock);
- init_waitqueue_head(priv-delta_msr_wait);
usb_set_serial_port_data(port, priv);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/21] USB: garmin_gps: fix memory leak on disconnect
Remove bogus disconnect test introduced by 95bef012e (USB: more serial drivers writing after disconnect) which prevented queued data from being freed on disconnect. The possible IO it was supposed to prevent is long gone. Cc: stable sta...@vger.kernel.org Signed-off-by: Johan Hovold jhov...@gmail.com --- drivers/usb/serial/garmin_gps.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/usb/serial/garmin_gps.c b/drivers/usb/serial/garmin_gps.c index 1a07b12..81caf56 100644 --- a/drivers/usb/serial/garmin_gps.c +++ b/drivers/usb/serial/garmin_gps.c @@ -956,10 +956,7 @@ static void garmin_close(struct usb_serial_port *port) if (!serial) return; - mutex_lock(port-serial-disc_mutex); - - if (!port-serial-disconnected) - garmin_clear(garmin_data_p); + garmin_clear(garmin_data_p); /* shutdown our urbs */ usb_kill_urb(port-read_urb); @@ -968,8 +965,6 @@ static void garmin_close(struct usb_serial_port *port) /* keep reset state so we know that we must start a new session */ if (garmin_data_p-state != STATE_RESET) garmin_data_p-state = STATE_DISCONNECTED; - - mutex_unlock(port-serial-disc_mutex); } -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/21] USB: oti6858: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/oti6858.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/oti6858.c b/drivers/usb/serial/oti6858.c
index a958fd4..87c71cc 100644
--- a/drivers/usb/serial/oti6858.c
+++ b/drivers/usb/serial/oti6858.c
@@ -188,7 +188,6 @@ struct oti6858_private {
u8 setup_done;
struct delayed_work delayed_setup_work;
- wait_queue_head_t intr_wait;
struct usb_serial_port *port; /* USB port with which associated */
};
@@ -339,7 +338,6 @@ static int oti6858_port_probe(struct usb_serial_port *port)
return -ENOMEM;
spin_lock_init(priv-lock);
- init_waitqueue_head(priv-intr_wait);
priv-port = port;
INIT_DELAYED_WORK(priv-delayed_setup_work, setup_line);
INIT_DELAYED_WORK(priv-delayed_write_work, send_data);
@@ -664,11 +662,15 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
spin_unlock_irqrestore(priv-lock, flags);
while (1) {
- wait_event_interruptible(priv-intr_wait,
+ wait_event_interruptible(port-delta_msr_wait,
+ port-serial-disconnected ||
priv-status.pin_state != prev);
if (signal_pending(current))
return -ERESTARTSYS;
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(priv-lock, flags);
status = priv-status.pin_state PIN_MASK;
spin_unlock_irqrestore(priv-lock, flags);
@@ -763,7 +765,7 @@ static void oti6858_read_int_callback(struct urb *urb)
if (!priv-transient) {
if (xs-pin_state != priv-status.pin_state)
- wake_up_interruptible(priv-intr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
memcpy(priv-status, xs, OTI6858_CTRL_PKT_SIZE);
}
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/21] USB: cypress_m8: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Also remove bogus test for private data pointer being NULL as it is
never assigned in the loop.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/cypress_m8.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/cypress_m8.c b/drivers/usb/serial/cypress_m8.c
index 8efa19d..ba7352e 100644
--- a/drivers/usb/serial/cypress_m8.c
+++ b/drivers/usb/serial/cypress_m8.c
@@ -111,7 +111,6 @@ struct cypress_private {
int baud_rate; /* stores current baud rate in
integer form */
int isthrottled; /* if throttled, discard reads */
- wait_queue_head_t delta_msr_wait; /* used for TIOCMIWAIT */
char prev_status, diff_status; /* used for TIOCMIWAIT */
/* we pass a pointer to this as the argument sent to
cypress_set_termios old_termios */
@@ -449,7 +448,6 @@ static int cypress_generic_port_probe(struct
usb_serial_port *port)
kfree(priv);
return -ENOMEM;
}
- init_waitqueue_head(priv-delta_msr_wait);
usb_reset_configuration(serial-dev);
@@ -868,12 +866,16 @@ static int cypress_ioctl(struct tty_struct *tty,
switch (cmd) {
/* This code comes from drivers/char/serial.c and ftdi_sio.c */
case TIOCMIWAIT:
- while (priv != NULL) {
- interruptible_sleep_on(priv-delta_msr_wait);
+ for (;;) {
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
- else {
+
+ if (port-serial-disconnected)
+ return -EIO;
+
+ {
char diff = priv-diff_status;
if (diff == 0)
return -EIO; /* no change = error */
@@ -1187,7 +1189,7 @@ static void cypress_read_int_callback(struct urb *urb)
if (priv-current_status != priv-prev_status) {
priv-diff_status |= priv-current_status ^
priv-prev_status;
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
priv-prev_status = priv-current_status;
}
spin_unlock_irqrestore(priv-lock, flags);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/21] USB: ark3116: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/ark3116.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c
index cbd904b..4775f82 100644
--- a/drivers/usb/serial/ark3116.c
+++ b/drivers/usb/serial/ark3116.c
@@ -62,7 +62,6 @@ static int is_irda(struct usb_serial *serial)
}
struct ark3116_private {
- wait_queue_head_t delta_msr_wait;
struct async_icount icount;
int irda; /* 1 for irda device */
@@ -146,7 +145,6 @@ static int ark3116_port_probe(struct usb_serial_port *port)
if (!priv)
return -ENOMEM;
- init_waitqueue_head(priv-delta_msr_wait);
mutex_init(priv-hw_lock);
spin_lock_init(priv-status_lock);
@@ -456,10 +454,14 @@ static int ark3116_ioctl(struct tty_struct *tty,
case TIOCMIWAIT:
for (;;) {
struct async_icount prev = priv-icount;
- interruptible_sleep_on(priv-delta_msr_wait);
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+
+ if (port-serial-disconnected)
+ return -EIO;
+
if ((prev.rng == priv-icount.rng)
(prev.dsr == priv-icount.dsr)
(prev.dcd == priv-icount.dcd)
@@ -580,7 +582,7 @@ static void ark3116_update_msr(struct usb_serial_port
*port, __u8 msr)
priv-icount.dcd++;
if (msr UART_MSR_TERI)
priv-icount.rng++;
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
}
}
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/21] USB: serial: fix interface refcounting
Make sure the interface is not released before our serial device. Note that drivers are still not allowed to access the interface in any way that may interfere with another driver that may have gotten bound to the same interface after disconnect returns. Cc: stable sta...@vger.kernel.org Signed-off-by: Johan Hovold jhov...@gmail.com --- drivers/usb/serial/usb-serial.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c index a19ed74..2e70efa 100644 --- a/drivers/usb/serial/usb-serial.c +++ b/drivers/usb/serial/usb-serial.c @@ -151,6 +151,7 @@ static void destroy_serial(struct kref *kref) } } + usb_put_intf(serial-interface); usb_put_dev(serial-dev); kfree(serial); } @@ -620,7 +621,7 @@ static struct usb_serial *create_serial(struct usb_device *dev, } serial-dev = usb_get_dev(dev); serial-type = driver; - serial-interface = interface; + serial-interface = usb_get_intf(interface); kref_init(serial-kref); mutex_init(serial-disc_mutex); serial-minor = SERIAL_TTY_NO_MINOR; -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] usb: host: ehci-tegra: fix PHY error handling
On Mon, Mar 18, 2013 at 09:25:34AM -0600, Stephen Warren wrote: On 03/18/2013 02:02 AM, Felipe Balbi wrote: Hi, On Fri, Mar 15, 2013 at 03:12:08PM -0600, Stephen Warren wrote: On 03/15/2013 03:12 AM, Felipe Balbi wrote: PHY layer no longer returns NULL, we must switch from IS_ERR_OR_NULL() to IS_ERR(). This change will definitely conflict with some Tegra EHCI/USB-PHY changes that Venu plans to submit very soon, for 3.10. This is relevant but this is such a small change that, even if it conflicts, resolution will be trivial. Well, Venu's changes re-organize exactly the code you're modifying. Wouldn't it be simpler to simply take all the Tegra USB patches through the PHY tree and avoid any conflicts at all? alright, I will take all patches, so please create a very small immutable branch which I can merge then I'll take all other patches. Let's just try to avoid this sort of situation whenever possible. cheers -- balbi signature.asc Description: Digital signature
[PATCH 21/21] USB: ti_usb_3410_5052: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/ti_usb_3410_5052.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index 39cb9b8..73deb02 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -74,7 +74,6 @@ struct ti_port {
int tp_flags;
int tp_closing_wait;/* in .01 secs */
struct async_icount tp_icount;
- wait_queue_head_t tp_msr_wait;/* wait for msr change */
wait_queue_head_t tp_write_wait;
struct ti_device*tp_tdev;
struct usb_serial_port *tp_port;
@@ -432,7 +431,6 @@ static int ti_port_probe(struct usb_serial_port *port)
else
tport-tp_uart_base_addr = TI_UART2_BASE_ADDR;
tport-tp_closing_wait = closing_wait;
- init_waitqueue_head(tport-tp_msr_wait);
init_waitqueue_head(tport-tp_write_wait);
if (kfifo_alloc(tport-write_fifo, TI_WRITE_BUF_SIZE, GFP_KERNEL)) {
kfree(tport);
@@ -784,9 +782,13 @@ static int ti_ioctl(struct tty_struct *tty,
dev_dbg(port-dev, %s - TIOCMIWAIT\n, __func__);
cprev = tport-tp_icount;
while (1) {
- interruptible_sleep_on(tport-tp_msr_wait);
+ interruptible_sleep_on(port-delta_msr_wait);
if (signal_pending(current))
return -ERESTARTSYS;
+
+ if (port-serial-disconnected)
+ return -EIO;
+
cnow = tport-tp_icount;
if (cnow.rng == cprev.rng cnow.dsr == cprev.dsr
cnow.dcd == cprev.dcd cnow.cts == cprev.cts)
@@ -1392,7 +1394,7 @@ static void ti_handle_new_msr(struct ti_port *tport, __u8
msr)
icount-dcd++;
if (msr TI_MSR_DELTA_RI)
icount-rng++;
- wake_up_interruptible(tport-tp_msr_wait);
+ wake_up_interruptible(tport-tp_port-delta_msr_wait);
spin_unlock_irqrestore(tport-tp_lock, flags);
}
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/21] USB: quatech2: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/quatech2.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index d643a4d..75f125d 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -128,7 +128,6 @@ struct qt2_port_private {
u8 shadowLSR;
u8 shadowMSR;
- wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
struct async_icount icount;
struct usb_serial_port *port;
@@ -506,8 +505,9 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
spin_unlock_irqrestore(priv-lock, flags);
while (1) {
- wait_event_interruptible(priv-delta_msr_wait,
-((priv-icount.rng != prev.rng) ||
+ wait_event_interruptible(port-delta_msr_wait,
+(port-serial-disconnected ||
+ (priv-icount.rng != prev.rng) ||
(priv-icount.dsr != prev.dsr) ||
(priv-icount.dcd != prev.dcd) ||
(priv-icount.cts != prev.cts)));
@@ -515,6 +515,9 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
if (signal_pending(current))
return -ERESTARTSYS;
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(priv-lock, flags);
cur = priv-icount;
spin_unlock_irqrestore(priv-lock, flags);
@@ -827,7 +830,6 @@ static int qt2_port_probe(struct usb_serial_port *port)
spin_lock_init(port_priv-lock);
spin_lock_init(port_priv-urb_lock);
- init_waitqueue_head(port_priv-delta_msr_wait);
port_priv-port = port;
port_priv-write_urb = usb_alloc_urb(0, GFP_KERNEL);
@@ -970,7 +972,7 @@ static void qt2_update_msr(struct usb_serial_port *port,
unsigned char *ch)
if (newMSR UART_MSR_TERI)
port_priv-icount.rng++;
- wake_up_interruptible(port_priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
}
}
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/21] USB: ftdi_sio: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
When switching to tty ports, some lifetime assumptions were changed.
Specifically, close can now be called before the final tty reference is
dropped as part of hangup at device disconnect. Even with the ftdi
private-data refcounting this means that the port private data can be
freed while a process is sleeping on modem-status changes and thus
cannot be relied on to detect disconnects when woken up.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/ftdi_sio.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index edd162d..d4809d5 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -69,9 +69,7 @@ struct ftdi_private {
int flags; /* some ASYNC_ flags are supported */
unsigned long last_dtr_rts; /* saved modem control outputs */
struct async_icount icount;
- wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
char prev_status;/* Used for TIOCMIWAIT */
- bool dev_gone;/* Used to abort TIOCMIWAIT */
char transmit_empty;/* If transmitter is empty or not */
__u16 interface;/* FT2232C, FT2232H or FT4232H port interface
(0 for FT232/245) */
@@ -1691,10 +1689,8 @@ static int ftdi_sio_port_probe(struct usb_serial_port
*port)
kref_init(priv-kref);
mutex_init(priv-cfg_lock);
- init_waitqueue_head(priv-delta_msr_wait);
priv-flags = ASYNC_LOW_LATENCY;
- priv-dev_gone = false;
if (quirk quirk-port_probe)
quirk-port_probe(priv);
@@ -1840,8 +1836,7 @@ static int ftdi_sio_port_remove(struct usb_serial_port
*port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
- priv-dev_gone = true;
- wake_up_interruptible_all(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
remove_sysfs_attrs(port);
@@ -1989,7 +1984,7 @@ static int ftdi_process_packet(struct usb_serial_port
*port,
if (diff_status FTDI_RS0_RLSD)
priv-icount.dcd++;
- wake_up_interruptible_all(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
priv-prev_status = status;
}
@@ -2440,11 +2435,15 @@ static int ftdi_ioctl(struct tty_struct *tty,
*/
case TIOCMIWAIT:
cprev = priv-icount;
- while (!priv-dev_gone) {
- interruptible_sleep_on(priv-delta_msr_wait);
+ for (;;) {
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+
+ if (port-serial-disconnected)
+ return -EIO;
+
cnow = priv-icount;
if (((arg TIOCM_RNG) (cnow.rng != cprev.rng)) ||
((arg TIOCM_DSR) (cnow.dsr != cprev.dsr)) ||
@@ -2454,8 +2453,6 @@ static int ftdi_ioctl(struct tty_struct *tty,
}
cprev = cnow;
}
- return -EIO;
- break;
case TIOCSERGETLSR:
return get_lsr_info(port, (struct serial_struct __user *)arg);
break;
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/21] USB: mct_u232: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mct_u232.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c
index a64d420..06d5a60 100644
--- a/drivers/usb/serial/mct_u232.c
+++ b/drivers/usb/serial/mct_u232.c
@@ -114,8 +114,6 @@ struct mct_u232_private {
unsigned charlast_msr; /* Modem Status Register */
unsigned int rx_flags; /* Throttling flags */
struct async_icount icount;
- wait_queue_head_tmsr_wait; /* for handling sleeping while waiting
- for msr change to happen */
};
#define THROTTLED 0x01
@@ -409,7 +407,6 @@ static int mct_u232_port_probe(struct usb_serial_port *port)
return -ENOMEM;
spin_lock_init(priv-lock);
- init_waitqueue_head(priv-msr_wait);
usb_set_serial_port_data(port, priv);
@@ -601,7 +598,7 @@ static void mct_u232_read_int_callback(struct urb *urb)
tty_kref_put(tty);
}
#endif
- wake_up_interruptible(priv-msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
spin_unlock_irqrestore(priv-lock, flags);
exit:
retval = usb_submit_urb(urb, GFP_ATOMIC);
@@ -810,13 +807,17 @@ static int mct_u232_ioctl(struct tty_struct *tty,
cprev = mct_u232_port-icount;
spin_unlock_irqrestore(mct_u232_port-lock, flags);
for ( ; ; ) {
- prepare_to_wait(mct_u232_port-msr_wait,
+ prepare_to_wait(port-delta_msr_wait,
wait, TASK_INTERRUPTIBLE);
schedule();
- finish_wait(mct_u232_port-msr_wait, wait);
+ finish_wait(port-delta_msr_wait, wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(mct_u232_port-lock, flags);
cnow = mct_u232_port-icount;
spin_unlock_irqrestore(mct_u232_port-lock, flags);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/21] USB: pl2303: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/pl2303.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 54adc91..3b10018 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -139,7 +139,6 @@ struct pl2303_serial_private {
struct pl2303_private {
spinlock_t lock;
- wait_queue_head_t delta_msr_wait;
u8 line_control;
u8 line_status;
};
@@ -233,7 +232,6 @@ static int pl2303_port_probe(struct usb_serial_port *port)
return -ENOMEM;
spin_lock_init(priv-lock);
- init_waitqueue_head(priv-delta_msr_wait);
usb_set_serial_port_data(port, priv);
@@ -607,11 +605,14 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
spin_unlock_irqrestore(priv-lock, flags);
while (1) {
- interruptible_sleep_on(priv-delta_msr_wait);
+ interruptible_sleep_on(port-delta_msr_wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(priv-lock, flags);
status = priv-line_status;
spin_unlock_irqrestore(priv-lock, flags);
@@ -719,7 +720,7 @@ static void pl2303_update_line_status(struct
usb_serial_port *port,
spin_unlock_irqrestore(priv-lock, flags);
if (priv-line_status UART_BREAK_ERROR)
usb_serial_handle_break(port);
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
tty = tty_port_tty_get(port-port);
if (!tty)
@@ -783,7 +784,7 @@ static void pl2303_process_read_urb(struct urb *urb)
line_status = priv-line_status;
priv-line_status = ~UART_STATE_TRANSIENT_MASK;
spin_unlock_irqrestore(priv-lock, flags);
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
if (!urb-actual_length)
return;
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/21] USB: io_edgeport: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/io_edgeport.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
index b00e5cb..efd8b97 100644
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -110,7 +110,6 @@ struct edgeport_port {
wait_queue_head_t wait_chase; /* for handling
sleeping while waiting for chase to finish */
wait_queue_head_t wait_open; /* for handling
sleeping while waiting for open to finish */
wait_queue_head_t wait_command; /* for handling
sleeping while waiting for command to finish */
- wait_queue_head_t delta_msr_wait; /* for handling
sleeping while waiting for msr change to happen */
struct async_icount icount;
struct usb_serial_port *port; /* loop back to the
owner of this object */
@@ -884,7 +883,6 @@ static int edge_open(struct tty_struct *tty, struct
usb_serial_port *port)
/* initialize our wait queues */
init_waitqueue_head(edge_port-wait_open);
init_waitqueue_head(edge_port-wait_chase);
- init_waitqueue_head(edge_port-delta_msr_wait);
init_waitqueue_head(edge_port-wait_command);
/* initialize our icount structure */
@@ -1669,13 +1667,17 @@ static int edge_ioctl(struct tty_struct *tty,
dev_dbg(port-dev, %s (%d) TIOCMIWAIT\n, __func__,
port-number);
cprev = edge_port-icount;
while (1) {
- prepare_to_wait(edge_port-delta_msr_wait,
+ prepare_to_wait(port-delta_msr_wait,
wait, TASK_INTERRUPTIBLE);
schedule();
- finish_wait(edge_port-delta_msr_wait, wait);
+ finish_wait(port-delta_msr_wait, wait);
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+
+ if (port-serial-disconnected)
+ return -EIO;
+
cnow = edge_port-icount;
if (cnow.rng == cprev.rng cnow.dsr == cprev.dsr
cnow.dcd == cprev.dcd cnow.cts == cprev.cts)
@@ -2051,7 +2053,7 @@ static void handle_new_msr(struct edgeport_port
*edge_port, __u8 newMsr)
icount-dcd++;
if (newMsr EDGEPORT_MSR_DELTA_RI)
icount-rng++;
- wake_up_interruptible(edge_port-delta_msr_wait);
+ wake_up_interruptible(edge_port-port-delta_msr_wait);
}
/* Save the new modem status */
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/21] USB: mos7840: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mos7840.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 1b83b01..b8051fa 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -219,7 +219,6 @@ struct moschip_port {
char open;
char open_ports;
wait_queue_head_t wait_chase; /* for handling sleeping while waiting
for chase to finish */
- wait_queue_head_t delta_msr_wait; /* for handling sleeping while
waiting for msr change to happen */
int delta_msr_cond;
struct async_icount icount;
struct usb_serial_port *port; /* loop back to the owner of this
object */
@@ -425,7 +424,7 @@ static void mos7840_handle_new_msr(struct moschip_port
*port, __u8 new_msr)
}
mos7840_port-delta_msr_cond = 1;
- wake_up_interruptible(mos7840_port-delta_msr_wait);
+ wake_up_interruptible(port-port-delta_msr_wait);
}
}
@@ -1130,7 +1129,6 @@ static int mos7840_open(struct tty_struct *tty, struct
usb_serial_port *port)
/* initialize our wait queues */
init_waitqueue_head(mos7840_port-wait_chase);
- init_waitqueue_head(mos7840_port-delta_msr_wait);
/* initialize our icount structure */
memset((mos7840_port-icount), 0x00, sizeof(mos7840_port-icount));
@@ -2220,13 +2218,18 @@ static int mos7840_ioctl(struct tty_struct *tty,
while (1) {
/*
interruptible_sleep_on(mos7840_port-delta_msr_wait); */
mos7840_port-delta_msr_cond = 0;
- wait_event_interruptible(mos7840_port-delta_msr_wait,
-(mos7840_port-
+ wait_event_interruptible(port-delta_msr_wait,
+(port-serial-disconnected ||
+ mos7840_port-
delta_msr_cond == 1));
/* see if a signal did it */
if (signal_pending(current))
return -ERESTARTSYS;
+
+ if (port-serial-disconnected)
+ return -EIO;
+
cnow = mos7840_port-icount;
smp_rmb();
if (cnow.rng == cprev.rng cnow.dsr == cprev.dsr
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/21] USB: ssu100: fix use-after-free in TIOCMIWAIT
Use the port wait queue and make sure to check the serial disconnected
flag before accessing private port data after waking up.
This is is needed as the private port data (including the wait queue
itself) can be gone when waking up after a disconnect.
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/ssu100.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ssu100.c b/drivers/usb/serial/ssu100.c
index b57cf84..4b2a197 100644
--- a/drivers/usb/serial/ssu100.c
+++ b/drivers/usb/serial/ssu100.c
@@ -61,7 +61,6 @@ struct ssu100_port_private {
spinlock_t status_lock;
u8 shadowLSR;
u8 shadowMSR;
- wait_queue_head_t delta_msr_wait; /* Used for TIOCMIWAIT */
struct async_icount icount;
};
@@ -355,8 +354,9 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
spin_unlock_irqrestore(priv-status_lock, flags);
while (1) {
- wait_event_interruptible(priv-delta_msr_wait,
-((priv-icount.rng != prev.rng) ||
+ wait_event_interruptible(port-delta_msr_wait,
+(port-serial-disconnected ||
+ (priv-icount.rng != prev.rng) ||
(priv-icount.dsr != prev.dsr) ||
(priv-icount.dcd != prev.dcd) ||
(priv-icount.cts != prev.cts)));
@@ -364,6 +364,9 @@ static int wait_modem_info(struct usb_serial_port *port,
unsigned int arg)
if (signal_pending(current))
return -ERESTARTSYS;
+ if (port-serial-disconnected)
+ return -EIO;
+
spin_lock_irqsave(priv-status_lock, flags);
cur = priv-icount;
spin_unlock_irqrestore(priv-status_lock, flags);
@@ -445,7 +448,6 @@ static int ssu100_port_probe(struct usb_serial_port *port)
return -ENOMEM;
spin_lock_init(priv-status_lock);
- init_waitqueue_head(priv-delta_msr_wait);
usb_set_serial_port_data(port, priv);
@@ -537,7 +539,7 @@ static void ssu100_update_msr(struct usb_serial_port *port,
u8 msr)
priv-icount.dcd++;
if (msr UART_MSR_TERI)
priv-icount.rng++;
- wake_up_interruptible(priv-delta_msr_wait);
+ wake_up_interruptible(port-delta_msr_wait);
}
}
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 1/2] usb: add find_raw_port_number callback to struct hc_driver()
xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw port number which is reflected in the xhci
extended capabilities table. This patch is to add find_raw_port_number
callback to struct hc_driver(), fill it with xhci_find_raw_port_number()
which will return raw port number and add a wrap usb_hcd_find_raw_port_number().
Otherwise, refactor xhci_find_real_port_number(). Using
xhci_find_raw_port_number() to get real index in the HW port status
registers instead of scanning through the xHCI roothub port array.
This can help to speed up.
All addresses in xhci-usb2_ports and xhci-usb3_ports array are
kown good ports and don't include following bad ports in the extended
capabilities talbe.
(1) root port that doesn't have an entry
(2) root port with unknown speed
(3) root port that is listed twice and with different speeds.
So xhci_find_raw_port_number() will only return port num of good ones
and never touch bad ports above.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
This patchset is based on usb-next tree commit 3f3b55bf
usb: ehci-s5p: Use devm for requesting ehci_vbus_gpio.
Change since v1:
Don't export usb_hcd_find_raw_port_number() symbol since there is no
its user outside of usb core.
Change since v2:
combine patch usb: add find_raw_port_number callback to struct
hc_driver() with this patch.
Change since v3:
add more changlog to prove this patch will not break previous function
drivers/usb/core/hcd.c |8
drivers/usb/host/xhci-mem.c | 36
drivers/usb/host/xhci-pci.c |1 +
drivers/usb/host/xhci.c | 22 ++
drivers/usb/host/xhci.h |1 +
include/linux/usb/hcd.h |2 ++
6 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 99b34a3..f9ec44c 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2412,6 +2412,14 @@ int usb_hcd_is_primary_hcd(struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(usb_hcd_is_primary_hcd);
+int usb_hcd_find_raw_port_number(struct usb_hcd *hcd, int port1)
+{
+ if (!hcd-driver-find_raw_port_number)
+ return port1;
+
+ return hcd-driver-find_raw_port_number(hcd, port1);
+}
+
static int usb_hcd_request_irqs(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags)
{
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 35616ff..6dc238c 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1022,44 +1022,24 @@ void xhci_copy_ep0_dequeue_into_input_ctx(struct
xhci_hcd *xhci,
* is attached to (or the roothub port its ancestor hub is attached to). All
we
* know is the index of that port under either the USB 2.0 or the USB 3.0
* roothub, but that doesn't give us the real index into the HW port status
- * registers. Scan through the xHCI roothub port array, looking for the Nth
- * entry of the correct port speed. Return the port number of that entry.
+ * registers. Call xhci_find_raw_port_number() to get real index.
*/
static u32 xhci_find_real_port_number(struct xhci_hcd *xhci,
struct usb_device *udev)
{
struct usb_device *top_dev;
- unsigned int num_similar_speed_ports;
- unsigned int faked_port_num;
- int i;
+ struct usb_hcd *hcd;
+
+ if (udev-speed == USB_SPEED_SUPER)
+ hcd = xhci-shared_hcd;
+ else
+ hcd = xhci-main_hcd;
for (top_dev = udev; top_dev-parent top_dev-parent-parent;
top_dev = top_dev-parent)
/* Found device below root hub */;
- faked_port_num = top_dev-portnum;
- for (i = 0, num_similar_speed_ports = 0;
- i HCS_MAX_PORTS(xhci-hcs_params1); i++) {
- u8 port_speed = xhci-port_array[i];
-
- /*
-* Skip ports that don't have known speeds, or have duplicate
-* Extended Capabilities port speed entries.
-*/
- if (port_speed == 0 || port_speed == DUPLICATE_ENTRY)
- continue;
- /*
-* USB 3.0 ports are always under a USB 3.0 hub. USB 2.0 and
-* 1.1 ports are under the USB 2.0 hub. If the port speed
-* matches the device speed, it's a similar speed port.
-*/
- if ((port_speed == 0x03) == (udev-speed == USB_SPEED_SUPER))
- num_similar_speed_ports++;
- if (num_similar_speed_ports == faked_port_num)
- /* Roothub ports are numbered from 1 to N */
- return i+1;
-
[PATCH V4 2/2] usb/acpi: binding xhci root hub usb port with ACPI
This patch is to bind xhci root hub usb port with its acpi node.
The port num in the acpi table matches with the sequence in the xhci
extended capabilities table. So call usb_hcd_find_raw_port_number() to
transfer hub port num into raw port number which associates with
the sequence in the xhci extended capabilities table before binding.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
Change since v3:
add a temprorary variable to recard raw port num and get ACPI
handle rahter than overwrite port num with raw port num. This is
to avoid passing raw port num as port num to usb_acpi_check_port_connect_type().
drivers/usb/core/usb-acpi.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index b6f4bad..255c144 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -15,6 +15,7 @@
#include linux/kernel.h
#include linux/acpi.h
#include linux/pci.h
+#include linux/usb/hcd.h
#include acpi/acpi_bus.h
#include usb.h
@@ -188,8 +189,13 @@ static int usb_acpi_find_device(struct device *dev,
acpi_handle *handle)
* connected to.
*/
if (!udev-parent) {
- *handle = acpi_get_child(DEVICE_ACPI_HANDLE(udev-dev),
+ struct usb_hcd *hcd = bus_to_hcd(udev-bus);
+ int raw_port_num;
+
+ raw_port_num = usb_hcd_find_raw_port_number(hcd,
port_num);
+ *handle = acpi_get_child(DEVICE_ACPI_HANDLE(udev-dev),
+ raw_port_num);
if (!*handle)
return -ENODEV;
} else {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))
On Mon, 18 Mar 2013, Chris Wilson wrote:
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 5)
void
intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
- I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
+ if (HAS_GMBUS_IRQ(dev))
+ I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
There should not be any harm in always clearing GMBUS4, it exists on all
platforms.
}
static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool
enable)
@@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo-data = bus;
}
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 4)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
@@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
+ if (!HAS_GMBUS_IRQ(dev_priv-dev)) {
+ int ret;
+ ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
+ (GMBUS_SATOER | gmbus2_status),
+ 50);
This should couple up to the normal return code that chooses the
appropriate return value based on gmbus2.
How about just using:
if (!HAS_GMBUS_IRQ(dev_priv-dev)) gmbus4_irq_en = 0;
and the existing wait loop?
I explicitly wanted to avoid touching GMBUS4 register, as the real cause
of the failure is not clear.
But, as Yinghai Lu points out, the problem is most likely caused by
interrupt disabling not working properly (see his very good point
regarding DisINTx+ and INTx+ discrepancy), so zeroing the register out
should work and it indeed does in my case, hence the (tested) patch
below.
I think it's a 3.9-rc material, and I am all open to debug this further
for 3.10 so that the race is closed and gmbus irqs can be used on Gen4
platform properly.
From: Jiri Kosina jkos...@suse.cz
Subject: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips
Commit 28c70f162 (drm/i915: use the gmbus irq for waits) switched to
using GMBUS irqs instead of GPIO bit-banging for chipset generations 4
and above.
It turns out though that on many systems this leads to spurious interrupts
being generated, long after the register write to disable the IRQs has been
issued.
Flushing of the register writes by POSTING_READ() directly after the register
write doesn't work either.
Disable using of GMBUS IRQs on Gen4 systems before the root cause is found and
revert back to old behavior.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
drivers/gpu/drm/i915/intel_i2c.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index acf8aec..9934724 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -203,7 +203,7 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo-data = bus;
}
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 4)
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 5)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
@@ -214,6 +214,8 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
+ if (!HAS_GMBUS_IRQ(dev_priv-dev))
+ gmbus4_irq_en = 0;
/* Important: The hw handles only the first bit, so set only one! Since
* we also need to check for NAKs besides the hw ready/idle signal, we
* need to wake up periodically and check that ourselves. */
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses))
On Tue, Mar 19, 2013 at 09:56:57AM +0100, Jiri Kosina wrote:
On Mon, 18 Mar 2013, Chris Wilson wrote:
+#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 5)
void
intel_i2c_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
I915_WRITE(dev_priv-gpio_mmio_base + GMBUS0, 0);
- I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
+ if (HAS_GMBUS_IRQ(dev))
+ I915_WRITE(dev_priv-gpio_mmio_base + GMBUS4, 0);
There should not be any harm in always clearing GMBUS4, it exists on all
platforms.
}
static void intel_i2c_quirk_set(struct drm_i915_private *dev_priv, bool
enable)
@@ -203,7 +205,6 @@ intel_gpio_setup(struct intel_gmbus *bus, u32 pin)
algo-data = bus;
}
-#define HAS_GMBUS_IRQ(dev) (INTEL_INFO(dev)-gen = 4)
static int
gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
u32 gmbus2_status,
@@ -214,6 +215,13 @@ gmbus_wait_hw_status(struct drm_i915_private
*dev_priv,
u32 gmbus2 = 0;
DEFINE_WAIT(wait);
+ if (!HAS_GMBUS_IRQ(dev_priv-dev)) {
+ int ret;
+ ret = wait_for((gmbus2 = I915_READ(GMBUS2 + reg_offset))
+ (GMBUS_SATOER | gmbus2_status),
+ 50);
This should couple up to the normal return code that chooses the
appropriate return value based on gmbus2.
How about just using:
if (!HAS_GMBUS_IRQ(dev_priv-dev)) gmbus4_irq_en = 0;
and the existing wait loop?
I explicitly wanted to avoid touching GMBUS4 register, as the real cause
of the failure is not clear.
But, as Yinghai Lu points out, the problem is most likely caused by
interrupt disabling not working properly (see his very good point
regarding DisINTx+ and INTx+ discrepancy), so zeroing the register out
should work and it indeed does in my case, hence the (tested) patch
below.
I think it's a 3.9-rc material, and I am all open to debug this further
for 3.10 so that the race is closed and gmbus irqs can be used on Gen4
platform properly.
Agreed. Using the IRQ for GMBUS is just a performance feature that can
be deferred until after we determine the root cause - and hope that the
failure is somehow peculiar to GMBUS.
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: samsung-usb2: Fix sparse warning
Fixing the following sparse warning:
sparse warnings: (new ones prefixed by )
drivers/usb/phy/phy-samsung-usb2.c:50:26: sparse: incorrect type in argument
1 (different address spaces)
drivers/usb/phy/phy-samsung-usb2.c:50:26:expected void const volatile
[noderef] asn:2*addr
drivers/usb/phy/phy-samsung-usb2.c:50:26:got void *
drivers/usb/phy/phy-samsung-usb2.c:73:35: sparse: incorrect type in argument
1 (different address spaces)
drivers/usb/phy/phy-samsung-usb2.c:73:35:expected void *regs
drivers/usb/phy/phy-samsung-usb2.c:73:35:got void [noderef] asn:2*regs
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
CC: Fengguang Wu fengguang...@intel.com
CC: Christopher Li spa...@chrisli.org
CC: Felipe Balbi ba...@ti.com
---
Based on 'next' branch of Felipe's usb tree.
Tested using make C=2 drivers/usb/phy/phy-samsung-usb2.o
Hi Felipe,
Sorry to bug you for this small change, i think this got unnoticed in the
last cycle too. Fixing it now.
Thanks
Vivek
drivers/usb/phy/phy-samsung-usb2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/phy/phy-samsung-usb2.c
b/drivers/usb/phy/phy-samsung-usb2.c
index dce9681..45ffe03 100644
--- a/drivers/usb/phy/phy-samsung-usb2.c
+++ b/drivers/usb/phy/phy-samsung-usb2.c
@@ -43,7 +43,7 @@ static int samsung_usbphy_set_host(struct usb_otg *otg,
struct usb_bus *host)
return 0;
}
-static bool exynos5_phyhost_is_on(void *regs)
+static bool exynos5_phyhost_is_on(void __iomem *regs)
{
u32 reg;
--
1.7.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb host: Faraday FUSBH200 HCD driver.
Hi, On Mon, Mar 18, 2013 at 10:16 PM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 18 Mar 2013, Felipe Balbi wrote: On Mon, Mar 18, 2013 at 06:06:18PM +0800, Yuan-Hsin Chen wrote: Hi, I tried to modify fusbh200 hcd driver following ehci-platform.c. However, the register definition of fusbh200 is partially incompatible to ehci. For fusbh200, only the elements between command and async_next in struct ehci_regs are consistent with ehci which means What about the port_status registers? They're not between command and async_next. If they aren't consistent with EHCI, it makes things a lot more complicated. fusbh200 has only one port_status register with different offset, 0x30, and the position of some bits are different from EHCI. it would cause copious modification and duplication of ehci hcd driver. For example, there is no configured_flag register in fusbh200 controller, yet, ehci hcd driver accesses configured_flag in function ehci_run which would cause compile errors. Therefore, maybe my first patch which refers to oxu210hp-hcd is a better solution? why don't you just add a quirk flag to ehci struct so that it knows it shouldn't access CONFIGFLAG register when that's non-existent ? Also, usbmode_ex, hostpc, and txfill_tuning other than configured_flag are non-existent in fusbh200. They are used in both ehci-hcd.c and ehci-hub.c for several times. There are only 5 uses of configured_flag in ehci-hcd.c, so it should be easy to wrap that around a flag check. Two of those uses turn configured_flag on and two of them turn it off. However, one of the uses tests its value (the first one in ehci_resume). How would that be handled if configured_flag doesn't exist? Alan, would you have a better idea ? Looks like this is a non-standard EHCI implementation. Yes, it does. If all we need is to protect four or five accesses with a quirk flag, that's okay with me. Thanks for your time. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv2 0/1] usb: f_rndis: Avoid to use ERROR macro if cdev can be null
Hi, This is patch version 2. Besides review I hope to get some feed-back on what the preferred solution is. Background: When going through our patches to be mainlined I stumbled on this one which we have fixed in many different ways internally. The problem is a NULL pointer dereference that can be triggered by disconnecting the USB cable at a specific time. Before submitting the final patch I would like to hear which solution you'd prefer. As I see it there are four different ways to fix the problem: 1) Remove the ERROR() call completely. 2) Add an if-statement on cdev in rndis_response_complete() and use pr_err() or ERROR(). 3) Globally update the ERROR() macro to handle the case where cdev is null. 4) Use the attached patch (RFC PATCHv2 1/1) where ERROR() is simply replaced with pr_err(). Thanks! -Oskar Truls Bengtsson (1): usb: f_rndis: Avoid to use ERROR macro if cdev can be null drivers/usb/gadget/f_rndis.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) -- 1.7.8.6 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCHv2 1/1] usb: f_rndis: Avoid to use ERROR macro if cdev can be null
From: Truls Bengtsson truls.bengts...@sonymobile.com
The udc_irq service runs the isr_tr_complete_handler which in turn
nukes the endpoints, including a call to rndis_response_complete,
if appropriate. If the rndis_msg_parser fails here, an error will
be printed using a dev_err call (through the ERROR() macro).
However, if the usb cable was just disconnected the device (cdev)
might not be available and will be null. Since the dev_err macro will
dereference the cdev pointer we get a null pointer exception.
Reviewed-by: Radovan Lekanovic radovan.lekano...@sonymobile.com
Signed-off-by: Truls Bengtsson truls.bengts...@sonymobile.com
Signed-off-by: Oskar Andero oskar.and...@sonymobile.com
---
drivers/usb/gadget/f_rndis.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index 71beeb8..cc9c49c 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -447,14 +447,13 @@ static void rndis_response_complete(struct usb_ep *ep,
struct usb_request *req)
static void rndis_command_complete(struct usb_ep *ep, struct usb_request *req)
{
struct f_rndis *rndis = req-context;
- struct usb_composite_dev*cdev = rndis-port.func.config-cdev;
int status;
/* received RNDIS command from USB_CDC_SEND_ENCAPSULATED_COMMAND */
// spin_lock(dev-lock);
status = rndis_msg_parser(rndis-config, (u8 *) req-buf);
if (status 0)
- ERROR(cdev, RNDIS command error %d, %d/%d\n,
+ pr_err(RNDIS command error %d, %d/%d\n,
status, req-actual, req-length);
// spin_unlock(dev-lock);
}
--
1.7.8.6
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] usb: chipidea: udc: add the define TD_COUNT and fix all users
On Tue, Mar 19, 2013 at 09:34:54AM +0800, Peter Chen wrote:
On Mon, Mar 18, 2013 at 03:28:26PM +0100, Michael Grzeschik wrote:
On Fri, Mar 08, 2013 at 05:54:37PM +0200, Alexander Shishkin wrote:
Michael Grzeschik m.grzesc...@pengutronix.de writes:
A static count of transfer descriptors was used everywhere in the driver
with the fixed number 4. This patch adds a define, named TD_COUNT, and
replaces all users of this value. This way its possible to have only one
parameter to change and limit the amount of tds per transfer.
I think Svetoslav made exactly the same patch in his patchset, but I
think this patchset will go first.
I did not find any patch comparable by Svetoslav. But, that patch
is superseeded by that hunk in my current branch anyway, as every TD can
maintain five DMA buffers:
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 09bc6ea..c961e3b 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -688,8 +688,8 @@ static int _ep_queue(struct usb_ep *ep, struct
usb_request *req)
goto done;
}
- if (req-length 4 * CI13XXX_PAGE_SIZE) {
- req-length = 4 * CI13XXX_PAGE_SIZE;
+ if (req-length 5 * CI13XXX_PAGE_SIZE) {
+ req-length = 5 * CI13XXX_PAGE_SIZE;
retval = -EMSGSIZE;
dev_warn(mEp-ci-dev, request length truncated\n);
}
No, 4 is ok. There are 5 buffer Pointers are dTD, but the Buffer Point 0
may not 4K aligned. Eg, if the reg-length is 18KB, and the buf DMA address
is 1K aligned, it needs two dTDs.
The first dTD only uses: 1KB, 4KB, 4KB, 4KB, 4KB as 5 buffers space.
When the first pointer is not aligned, then all other buffer pointers
will also not be. Because the payload will very likeley contiguous.
If the hardware limitation is to have 4K aligned buffer pointers in the
dma addresses, than this fix should be handled different than that.
So this limitation of 4 is a bogus workaround, and my attached hunk is
still valid.
Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 1/1] usb: f_rndis: Avoid to use ERROR macro if cdev can be null
On Tue, Mar 19 2013, oskar.and...@sonymobile.com wrote:
The udc_irq service runs the isr_tr_complete_handler which in turn
nukes the endpoints, including a call to rndis_response_complete,
if appropriate. If the rndis_msg_parser fails here, an error will
be printed using a dev_err call (through the ERROR() macro).
However, if the usb cable was just disconnected the device (cdev)
might not be available and will be null. Since the dev_err macro will
dereference the cdev pointer we get a null pointer exception.
Reviewed-by: Radovan Lekanovic radovan.lekano...@sonymobile.com
Signed-off-by: Truls Bengtsson truls.bengts...@sonymobile.com
Signed-off-by: Oskar Andero oskar.and...@sonymobile.com
Acked-by: Michal Nazarewicz min...@mina86.com
I think this is the best solution. Adding if statements around it would
just add noise.
---
drivers/usb/gadget/f_rndis.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index 71beeb8..cc9c49c 100644
--- a/drivers/usb/gadget/f_rndis.c
+++ b/drivers/usb/gadget/f_rndis.c
@@ -447,14 +447,13 @@ static void rndis_response_complete(struct usb_ep *ep,
struct usb_request *req)
static void rndis_command_complete(struct usb_ep *ep, struct usb_request
*req)
{
struct f_rndis *rndis = req-context;
- struct usb_composite_dev*cdev = rndis-port.func.config-cdev;
int status;
/* received RNDIS command from USB_CDC_SEND_ENCAPSULATED_COMMAND */
// spin_lock(dev-lock);
status = rndis_msg_parser(rndis-config, (u8 *) req-buf);
if (status 0)
- ERROR(cdev, RNDIS command error %d, %d/%d\n,
+ pr_err(RNDIS command error %d, %d/%d\n,
status, req-actual, req-length);
// spin_unlock(dev-lock);
}
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--
pgp0Fsmnd5MWs.pgp
Description: PGP signature
Re: [PATCH 0/5] usb: musb: am335x support
Daniel == Daniel Mack zon...@gmail.com writes: Hi, I know this patch reintroduces bits that have been intentionally removed before, in particular by 032ec49f53 (usb: musb: drop useless board_mode usage), but I don't know how this usb driver is supposed to work in host mode without taking the configured port mode into account. If anyone can explain to me which information I'm missing here, I can happily test a patch. For now, this works for me. Daniel Hmm, nobody, really? Am I the only one who's running the musb Daniel driver in host-only mode? Sorry, I'll be needing host mode as well, but am currently stuck working on non-am335x stuff - So I'm definately interested in getting it to work, but don't have free cycles to look into it right now. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB: simplify clock lookup for mv ehci/otg/udc
While going over the suggested changes for the ehci-mv separation patch,
we noticed that the driver uses a variable number of clock names it gets
passed from the platform code, which is highly unusual behavior and adds
a lot of extra complexity.
Even though there is a comment in the mv_udc driver stating that some SoCs
require multiple clocks, none of the code in the upstream kernel provides
more than one, and even if an out of tree SoC port needs multiple clocks,
it is still wrong to pass them them through platform data, since they are
a property of the device, not a property of the platform.
This patch attempts to clean up the situation by turning the one clock
that is passed into the ehci/udc/otg devices into an anomymous one and
removing the clkname array from the platform data. Another simplification
is to always call clk_prepare_enable/clk_disable_unprepare directly,
since that is a valid operation on a NULL clk pointer if the platform
has not attacked a clk to the device.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
Haojian, does this look reasonable to you?
arch/arm/mach-mmp/aspenite.c | 5 -
arch/arm/mach-mmp/clock-pxa168.c | 2 +-
arch/arm/mach-mmp/clock-pxa910.c | 4 +++-
arch/arm/mach-mmp/ttc_dkb.c | 6 --
drivers/usb/gadget/mv_udc.h | 4 +---
drivers/usb/gadget/mv_udc_core.c | 37 +
drivers/usb/host/ehci-mv.c | 43
++-
drivers/usb/otg/mv_otg.c | 38
+-
drivers/usb/otg/mv_otg.h | 3 +--
include/linux/platform_data/mv_usb.h | 1 -
10 files changed, 34 insertions(+), 109 deletions(-)
diff --git a/arch/arm/mach-mmp/aspenite.c b/arch/arm/mach-mmp/aspenite.c
index 9f64d56..988bd80 100644
--- a/arch/arm/mach-mmp/aspenite.c
+++ b/arch/arm/mach-mmp/aspenite.c
@@ -223,13 +223,8 @@ static struct pxa27x_keypad_platform_data
aspenite_keypad_info __initdata = {
};
#if defined(CONFIG_USB_EHCI_MV)
-static char *pxa168_sph_clock_name[] = {
- [0] = PXA168-USBCLK,
-};
-
static struct mv_usb_platform_data pxa168_sph_pdata = {
.clknum = 1,
- .clkname= pxa168_sph_clock_name,
.mode = MV_USB_MODE_HOST,
.phy_init = pxa_usb_phy_init,
.phy_deinit = pxa_usb_phy_deinit,
diff --git a/arch/arm/mach-mmp/clock-pxa168.c b/arch/arm/mach-mmp/clock-pxa168.c
index 5e6c18c..9edc50e 100644
--- a/arch/arm/mach-mmp/clock-pxa168.c
+++ b/arch/arm/mach-mmp/clock-pxa168.c
@@ -81,7 +81,7 @@ static struct clk_lookup pxa168_clkregs[] = {
INIT_CLKREG(clk_gpio, pxa-gpio, NULL),
INIT_CLKREG(clk_keypad, pxa27x-keypad, NULL),
INIT_CLKREG(clk_eth, pxa168-eth, MFUCLK),
- INIT_CLKREG(clk_usb, NULL, PXA168-USBCLK),
+ INIT_CLKREG(clk_usb, pxa-sph, NULL);
INIT_CLKREG(clk_rtc, sa1100-rtc, NULL),
};
diff --git a/arch/arm/mach-mmp/clock-pxa910.c b/arch/arm/mach-mmp/clock-pxa910.c
index 933ea71..6849155 100644
--- a/arch/arm/mach-mmp/clock-pxa910.c
+++ b/arch/arm/mach-mmp/clock-pxa910.c
@@ -57,7 +57,9 @@ static struct clk_lookup pxa910_clkregs[] = {
INIT_CLKREG(clk_pwm4, pxa910-pwm.3, NULL),
INIT_CLKREG(clk_nand, pxa3xx-nand, NULL),
INIT_CLKREG(clk_gpio, pxa-gpio, NULL),
- INIT_CLKREG(clk_u2o, NULL, U2OCLK),
+ INIT_CLKREG(clk_u2o, pxa-u2oehci, NULL),
+ INIT_CLKREG(clk_u2o, mv-udc, NULL),
+ INIT_CLKREG(clk_u2o, mv-otg, NULL),
INIT_CLKREG(clk_rtc, sa1100-rtc, NULL),
};
diff --git a/arch/arm/mach-mmp/ttc_dkb.c b/arch/arm/mach-mmp/ttc_dkb.c
index 22a9058..39a7ad5 100644
--- a/arch/arm/mach-mmp/ttc_dkb.c
+++ b/arch/arm/mach-mmp/ttc_dkb.c
@@ -161,14 +161,8 @@ static struct i2c_board_info ttc_dkb_i2c_info[] = {
#ifdef CONFIG_USB_SUPPORT
#if defined(CONFIG_USB_MV_UDC) || defined(CONFIG_USB_EHCI_MV_U2O)
-
-static char *pxa910_usb_clock_name[] = {
- [0] = U2OCLK,
-};
-
static struct mv_usb_platform_data ttc_usb_pdata = {
.clknum = 1,
- .clkname= pxa910_usb_clock_name,
.vbus = NULL,
.mode = MV_USB_MODE_OTG,
.otg_force_a_bus_req = 1,
diff --git a/drivers/usb/gadget/mv_udc.h b/drivers/usb/gadget/mv_udc.h
index 9073436..fa87981 100644
--- a/drivers/usb/gadget/mv_udc.h
+++ b/drivers/usb/gadget/mv_udc.h
@@ -221,9 +221,7 @@ struct mv_udc {
struct mv_usb_platform_data *pdata;
- /* some SOC has mutiple clock sources for USB*/
- unsigned intclknum;
- struct clk *clk[0];
+ struct clk *clk;
};
/* endpoint data structure */
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index c8cf959..8c4d4d2 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gadget/mv_udc_core.c
@@ -1004,22 +1004,6 @@ static struct usb_ep_ops mv_ep_ops = {
.fifo_flush = mv_ep_fifo_flush, /* flush fifo */
};
[PATCH 2/2] ARM: dts: omap4-panda: Provide PHY clock information
The USB PHY needs AUXCLK3 to operate. Provide this information in the device tree. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4-panda.dts |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts index cfc7683..2cd369b 100644 --- a/arch/arm/boot/dts/omap4-panda.dts +++ b/arch/arm/boot/dts/omap4-panda.dts @@ -85,6 +85,8 @@ compatible = usb-nop-xceiv; reset-supply = hsusb1_reset; vcc-supply = hsusb1_power; + clocks = aux_clks 3; + clock-names = main_clk; clock-frequency = 1920; }; }; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/2] Device tree support for OMAP4 SCRM clocks
On 03/19/2013 04:26 PM, Roger Quadros wrote: Hi, Based on the discussion in [1], I've implemented device tree provider for the AUXCLKs on OMAP4. [1] - https://lkml.org/lkml/2013/3/12/241 cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/2] Device tree support for OMAP4 SCRM clocks
Hi, Based on the discussion in [1], I've implemented device tree provider for the AUXCLKs on OMAP4. Please let me know if there are any issues. This is important to get USB Host support working on Panda with device tree boot on 3.10. Roger Quadros (2): ARM: OMAP4: clock: Add device tree support for AUXCLKs ARM: dts: omap4-panda: Provide PHY clock information .../devicetree/bindings/clock/omap4-clock.txt | 32 ++ arch/arm/boot/dts/omap4-panda.dts |2 + arch/arm/boot/dts/omap4.dtsi |5 +++ arch/arm/mach-omap2/board-generic.c|2 +- arch/arm/mach-omap2/cclock44xx_data.c | 35 arch/arm/mach-omap2/clock44xx.h|1 + arch/arm/mach-omap2/common.h |9 + arch/arm/mach-omap2/io.c |6 +++ 8 files changed, 91 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
On 03/19/2013 04:26 PM, Roger Quadros wrote:
Register a device tree clock provider for AUX clocks
on the OMAP4 SoC. Also provide the binding information.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/omap4-clock.txt | 32 ++
arch/arm/boot/dts/omap4.dtsi |5 +++
arch/arm/mach-omap2/board-generic.c|2 +-
arch/arm/mach-omap2/cclock44xx_data.c | 35
arch/arm/mach-omap2/clock44xx.h|1 +
arch/arm/mach-omap2/common.h |9 +
arch/arm/mach-omap2/io.c |6 +++
7 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/omap4-clock.txt
b/Documentation/devicetree/bindings/clock/omap4-clock.txt
new file mode 100644
index 000..9d5448b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt
@@ -0,0 +1,32 @@
+* Clock bindings for Texas Instruments OMAP4 SCRM clocks
+
+Required properties:
+- compatible: Should be ti,omap4-scrm
+- #clock-cells: Should be 1
+
+The clock consumer should specify the desired clock by having the clock
+ID in its clocks phandle cell. The following is a full list of SCRM
+clocks and IDs.
+
+ Clock ID
+ --
+ auxclk0_ck 0
+ auxclk1_ck 1
+ auxclk1_ck 1
+ auxclk1_ck 1
+ auxclk1_ck 1
Argh! should be 2,3,4,5
+
+Example:
+
+aux_clks: scrmclks {
+ compatible = ti,omap4-scrm;
+ #clock-cells = 1;
+};
+
+hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ clocks = aux_clks 3;
+ clock-names = main_clk;
+ clock-frequency = 1920;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index b7db1a2..97de56c 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -101,6 +101,11 @@
ti,hwmods = counter_32k;
};
+ aux_clks: scrmclks {
+ compatible = ti,omap4-scrm;
+ #clock-cells = 1;
+ };
+
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..23f2064 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -158,7 +158,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
- .init_time = omap4_local_timer_init,
+ .init_time = omap4_init_time,
.dt_compat = omap4_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..bfc46c1 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/of.h
#include soc.h
#include iomap.h
@@ -1663,6 +1664,40 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, cpufreq_ck, dpll_mpu_ck, CK_443X),
};
+static struct clk *scrm_clks[] = {
+ auxclk0_ck,
+ auxclk1_ck,
+ auxclk2_ck,
+ auxclk3_ck,
+ auxclk4_ck,
+ auxclk5_ck,
+};
+
+static struct clk_onecell_data scrm_data;
+
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, ti,omap4-scrm);
+ if (np) {
+ scrm_data.clks = scrm_clks;
+ scrm_data.clk_num = ARRAY_SIZE(scrm_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, scrm_data);
+ }
+
+ return 0;
+}
+
+#else
+
+int __init omap4_clk_init_dt(void)
+{
+ return 0;
+}
+#endif /* CONFIG_OF */
+
int __init omap4xxx_clk_init(void)
{
u32 cpu_clkflg;
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 287a46f..6395f63 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -16,5 +16,6 @@
#define OMAP4430_REGM4XEN_MULT 4
int omap4xxx_clk_init(void);
+int omap4_clk_init_dt(void);
#endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0a6b9c7..1941d1c 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -98,6 +98,7 @@ void am35xx_init_early(void);
void ti81xx_init_early(void);
void
Re: USB: simplify clock lookup for mv ehci/otg/udc
Hi, On Tue, Mar 19, 2013 at 02:44:46PM +0100, Arnd Bergmann wrote: While going over the suggested changes for the ehci-mv separation patch, we noticed that the driver uses a variable number of clock names it gets passed from the platform code, which is highly unusual behavior and adds a lot of extra complexity. Even though there is a comment in the mv_udc driver stating that some SoCs require multiple clocks, none of the code in the upstream kernel provides more than one, and even if an out of tree SoC port needs multiple clocks, it is still wrong to pass them them through platform data, since they are a property of the device, not a property of the platform. This patch attempts to clean up the situation by turning the one clock that is passed into the ehci/udc/otg devices into an anomymous one and removing the clkname array from the platform data. Another simplification is to always call clk_prepare_enable/clk_disable_unprepare directly, since that is a valid operation on a NULL clk pointer if the platform has not attacked a clk to the device. Signed-off-by: Arnd Bergmann a...@arndb.de needs to be rebased on my -next branch. Also, it would be really good if dependencies between drivers and arch code would be cut to a minimum. -- balbi signature.asc Description: Digital signature
Re: UHCI/EHCI interrupt storm after resume from S3
On 3/18/2013 1:35 PM, Greg KH wrote: On Mon, Mar 18, 2013 at 01:30:47PM -0700, Waskiewicz Jr, Peter P wrote: I have an Atom-based machine (N450) with an ICH8 running Ubuntu LTS 12.04.2. This has the latest updates installed, kernel 3.5.0-23.35. I put the machine into S3, then woke it from the network. After resume, the uhci_hcd and ehci_hcd devices (sharing an interrupt) start flooding interrupts. This continues until the USB driver is reloaded, or I reboot. Is this a known issue? I'm willing to assist debugging, I just wanted to ask if people have seen this yet before I dig into it. If it comes down to building linux-next via git, that's fine, it'll just take about 4 hours on this box to do it. Let me know if there's any additional data folks want to see. Can you see if this happens with the latest 3.8.3 kernel release? If you are stuck using Ubuntu kernels, you need to get support from Canonical, there's nothing we can do with their kernel packages, sorry. I cannot reproduce this problem with 3.8.3 on the same box. I'll open a bug with Canonical. Sorry for the noise, but thanks for the quick reply nonetheless. Cheers, -PJ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: Make USB persist default configurable
On Mon, 18 Mar 2013, Greg Kroah-Hartman wrote: On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote: Why can't you just revert this in userspace? Isn't that easier than doing a kernel patch and providing an option that we need to now maintain for pretty much forever? I could solve it in userspace, but that really feels like a hacky workaround and not a long term solution. It would mean that every new device starts with persist enabled and stays that way for a few milliseconds (maybe up to seconds if it's connected on boot), until userspace gets around to disable it again... opening the possibility for very weird race conditions and bugs with drivers/devices that don't work with persist. What drivers/devices don't work with persist? We need to know that now, otherwise all other distros and users have problems, right? This default is a policy that really resides in the kernel, it has changed in the past, and since there is no definitive better choice for all cases I thought making it configurable is the right thing to do. Too many options can be a bad thing. I think Alan made this a always on option, so I'd like to get his opinion on it. Alan? Originally the persist attribute defaulted to off. Linus disliked this (at least, he disliked it for mass-storage devices) and so at his request the default was changed to on. There didn't seem to be any reason to treat other devices differently from mass-storage devices; consequently the default is now on for everything. Julius's commit message mentions the disadvantage of persist: Resume times can be increased. But it doesn't mention the chief advantage: Filesystems stored on USB devices are much less likely to be lost across suspends. The races mentioned above don't seem to be very dangerous. How likely is it that the system will be suspended within a few milliseconds of probing a new USB device? As for buggy devices and drivers that can't handle persist, we have better ways of dealing with them. Buggy devices can get a quirk flag (USB_QUIRK_RESET). Buggy drivers should be fixed. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: Make USB persist default configurable
On Tue, Mar 19, 2013 at 7:56 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 18 Mar 2013, Greg Kroah-Hartman wrote: On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote: Why can't you just revert this in userspace? Isn't that easier than doing a kernel patch and providing an option that we need to now maintain for pretty much forever? I could solve it in userspace, but that really feels like a hacky workaround and not a long term solution. It would mean that every new device starts with persist enabled and stays that way for a few milliseconds (maybe up to seconds if it's connected on boot), until userspace gets around to disable it again... opening the possibility for very weird race conditions and bugs with drivers/devices that don't work with persist. What drivers/devices don't work with persist? We need to know that now, otherwise all other distros and users have problems, right? This default is a policy that really resides in the kernel, it has changed in the past, and since there is no definitive better choice for all cases I thought making it configurable is the right thing to do. Too many options can be a bad thing. I think Alan made this a always on option, so I'd like to get his opinion on it. Alan? Originally the persist attribute defaulted to off. Linus disliked this (at least, he disliked it for mass-storage devices) and so at his request the default was changed to on. There didn't seem to be any reason to treat other devices differently from mass-storage devices; consequently the default is now on for everything. Julius's commit message mentions the disadvantage of persist: Resume times can be increased. But it doesn't mention the chief advantage: Filesystems stored on USB devices are much less likely to be lost across suspends. The races mentioned above don't seem to be very dangerous. How likely is it that the system will be suspended within a few milliseconds of probing a new USB device? For laptops, if the suspend/resume is triggered by the lid open/close detection, this is somewhat likely and bit us in the past : the classical use case I have encountered is a back-to-back suspend triggered by the user opening the lid then closing it again in the next 2 or 3 seconds because he has changed is mind (damn user...), might be also triggered by lid hall sensor missing proper debouncing (but in that case, the mechanical time constant is often shorter than the latency of resuming USB devices). As for buggy devices and drivers that can't handle persist, we have better ways of dealing with them. Buggy devices can get a quirk flag (USB_QUIRK_RESET). Buggy drivers should be fixed. Alan Stern -- Vincent -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses
On Tue, Mar 19, 2013 at 10:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: How about just using: if (!HAS_GMBUS_IRQ(dev_priv-dev)) gmbus4_irq_en = 0; and the existing wait loop? I explicitly wanted to avoid touching GMBUS4 register, as the real cause of the failure is not clear. But, as Yinghai Lu points out, the problem is most likely caused by interrupt disabling not working properly (see his very good point regarding DisINTx+ and INTx+ discrepancy), so zeroing the register out should work and it indeed does in my case, hence the (tested) patch below. I think it's a 3.9-rc material, and I am all open to debug this further for 3.10 so that the race is closed and gmbus irqs can be used on Gen4 platform properly. Agreed. Using the IRQ for GMBUS is just a performance feature that can be deferred until after we determine the root cause - and hope that the failure is somehow peculiar to GMBUS. Ok, I've merged this patch. But some further investigation points at a much more severe dragon hiding here: The MSI interrupt for the intel gfx is commonly in the 40+ range, but the interrupt vector with the spurious interrupts is 16. Which is the irq of the intel gfx when MSI is disabled! So it looks like gmbus on the intel gfx is capable of generating non-MSI interrupts in parallel to the MSI interrupts (since apparently gmbus still works, so we get the interrupts we expect). I have no idea how that could happen. Hence adding a bunch of people with more clue than me. For reference below the updated commit message. Cheers, Daniel Author: Jiri Kosina jkos...@suse.cz Date: Tue Mar 19 09:56:57 2013 +0100 drm/i915: stop using GMBUS IRQs on Gen4 chips Commit 28c70f162 (drm/i915: use the gmbus irq for waits) switched to using GMBUS irqs instead of GPIO bit-banging for chipset generations 4 and above. It turns out though that on many systems this leads to spurious interrupts being generated, long after the register write to disable the IRQs has been issued. Typically this results in the spurious interrupt source getting disabled: [9.636345] irq 16: nobody cared (try booting with the irqpoll option) [9.637915] Pid: 4157, comm: ifup Tainted: GF 3.9.0-rc2-00341-g0863702 #422 [9.639484] Call Trace: [9.640731] IRQ [8109b40d] __report_bad_irq+0x1d/0xc7 [9.640731] [8109b7db] note_interrupt+0x15b/0x1e8 [9.640731] [810999f7] handle_irq_event_percpu+0x1bf/0x214 [9.640731] [81099a88] handle_irq_event+0x3c/0x5c [9.640731] [8109c139] handle_fasteoi_irq+0x7a/0xb0 [9.640731] [8100400e] handle_irq+0x1a/0x24 [9.640731] [81003d17] do_IRQ+0x48/0xaf [9.640731] [8142f1ea] common_interrupt+0x6a/0x6a [9.640731] EOI [8142f952] ? system_call_fastpath+0x16/0x1b [9.640731] handlers: [9.640731] [a000d771] usb_hcd_irq [usbcore] [9.640731] [a0306189] yenta_interrupt [yenta_socket] [9.640731] Disabling IRQ #16 The really curious thing is now that irq 16 is _not_ the interrupt for the i915 driver when using MSI, but it _is_ the interrupt when not using MSI. So by all indications it seems like gmbus is able to generate a legacy (shared) interrupt in MSI mode on some configurations. I've tried to reproduce this and the differentiating thing seems to be that on unaffected systems no other device uses irq 16 (which seems to be the non-MSI intel gfx interrupt on all gm45). I have no idea how that even can happen. To avoid tempting this elephant into a rage, just disable gmbus interrupt support on gen 4. v2: Improve the commit message with exact details of what's going on. Also add a comment in the code to warn against this particular elephant in the room. Signed-off-by: Jiri Kosina jkos...@suse.cz (v1) Acked-by: Chris Wilson ch...@chris-wilson.co.uk (v1) References: https://lkml.org/lkml/2013/3/8/325 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Daniel Vetter wrote: For reference below the updated commit message. Cheers, Daniel Author: Jiri Kosina jkos...@suse.cz Date: Tue Mar 19 09:56:57 2013 +0100 drm/i915: stop using GMBUS IRQs on Gen4 chips Commit 28c70f162 (drm/i915: use the gmbus irq for waits) switched to using GMBUS irqs instead of GPIO bit-banging for chipset generations 4 and above. It turns out though that on many systems this leads to spurious interrupts being generated, long after the register write to disable the IRQs has been issued. Typically this results in the spurious interrupt source getting disabled: [9.636345] irq 16: nobody cared (try booting with the irqpoll option) [9.637915] Pid: 4157, comm: ifup Tainted: GF 3.9.0-rc2-00341-g0863702 #422 [9.639484] Call Trace: [9.640731] IRQ [8109b40d] __report_bad_irq+0x1d/0xc7 [9.640731] [8109b7db] note_interrupt+0x15b/0x1e8 [9.640731] [810999f7] handle_irq_event_percpu+0x1bf/0x214 [9.640731] [81099a88] handle_irq_event+0x3c/0x5c [9.640731] [8109c139] handle_fasteoi_irq+0x7a/0xb0 [9.640731] [8100400e] handle_irq+0x1a/0x24 [9.640731] [81003d17] do_IRQ+0x48/0xaf [9.640731] [8142f1ea] common_interrupt+0x6a/0x6a [9.640731] EOI [8142f952] ? system_call_fastpath+0x16/0x1b [9.640731] handlers: [9.640731] [a000d771] usb_hcd_irq [usbcore] [9.640731] [a0306189] yenta_interrupt [yenta_socket] [9.640731] Disabling IRQ #16 The really curious thing is now that irq 16 is _not_ the interrupt for the i915 driver when using MSI, but it _is_ the interrupt when not using MSI. So by all indications it seems like gmbus is able to generate a legacy (shared) interrupt in MSI mode on some configurations. I've tried to reproduce this and the differentiating thing seems to be that on unaffected systems no other device uses irq 16 (which seems to be the non-MSI intel gfx interrupt on all gm45). That might be misleading. It's possible that the erroneous IRQs _are_ being issued but you're simply not aware of them. If the kernel thinks that no device is using IRQ 16 then it will leave that IRQ disabled. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb host: Faraday FUSBH200 HCD driver.
On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote: What about the port_status registers? They're not between command and async_next. If they aren't consistent with EHCI, it makes things a lot more complicated. fusbh200 has only one port_status register with different offset, 0x30, and the position of some bits are different from EHCI. That's pretty nasty. Integrating that with the standard EHCI driver would be considerably more difficult. Why was the FUSBH200 designed in this strange way? Why doesn't it use the standard EHCI register layout? Were the engineers at Faraday deliberately trying to make life harder for driver writers? Also, usbmode_ex, hostpc, and txfill_tuning other than configured_flag are non-existent in fusbh200. They are used in both ehci-hcd.c and ehci-hub.c for several times. They are used only if the hardware supports them, that is, only if the ehci-has_hostpc flag is set. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Testing for hardware bug in EHCI controllers
On Tue, 19 Mar 2013, Noone Nowhere wrote: That depends on where the bug is. If it is in the stick then testing a different brand of flash drive would help. Does it need an unusual dev entry to limit max sectors? It is the first USB stick that arrived here back in 2003(?) and uses SLC flash!! We do not think we can find SLC USB stick any more. We will test affected hosts with a much newer USB stick. I don't know what your old USB stick needs. If it does have an unusual_devs entry to limit max_sectors then the test program probably won't work with it. The test program does a bunch of error checking but practically no error recovery. If almost any tiny little thing goes wrong, the program exits. You might think that nothing else should go wrong -- but the fact is that errors do happen. Is the controller supposed to do such error recovery or the OS? The OS. As far as should is concerned you are completely right as A50M still breaks with the 2 patches applied on 3.8.3 despite that we use a 16 times larger USB stick. Breakage though occurs at the program output only: [ 215.244713] usb-storage 4-3:1.0: disconnect by usbfs [ 229.774169] ehci-pci :00:12.2: shutdown urb 88005111f9c0 ep1in-bulk 600x 100 200 300 400 500 URB timed out; bug may be present Wrong URB completed , is the bug curred or no? Probably it is cured. But something is still wrong, even though it may be unrelated. We are puzzled with this laptop, why does the program detect the bug only on this one? Remember, the program doesn't _detect_ the bug. The kernel patch that goes along with the program does the detection. The program only tries to _trigger_ the bug. It surely has the bug but it breaks on its own way or breaks because of additional errata(linux has already a USB workaround for isochronous transfers when ASPM is used on this chip). If any sort of usbmon dump is needed, provide instructions and we can test it at once. Instructions for usbmon are in the kernel source file Documentation/usb/usbmon.txt. As said we have docs and we shall read its errata. If nothing usefull is found, we can try to poke with the controller settings. Since we mentioned ASPM, before you ask it is disabled for all devices by ACPI FADT table. That's what I would like to do. But nobody knows what vendor/device/revision values should be in the blacklist. We should not harry up and give some time for more reports. Tonight we will test an ICH-4M and we can buy ATI IXP mainboards for testing within this week if a table can be made. Also it is possible to buy an ALi controller. We also have a HUMAX DVB-S2 with an external USB port and we would love to poke with it provided that we can save all the settings from telnet. It must be using the bcma-hcd driver and we are looking forward to test it. Okay. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: USB device registered on OHCI instead of EHCI
On Mon, 18 Mar 2013, Bruce Guenter wrote: On Mon, Mar 11, 2013 at 02:48:50PM -0400, Alan Stern wrote: Okay; if it happens again, collect the information and we'll go on from there. Well, it's happened again, but it's obviously not a boot issue. Something happens after boot that is causing some errors. Complete dmesg attached. Either the EHCI controller, the USB connection, or the device itself is unreliable. The log shows a large number of resets at various times. Search for lines matching usb 2-3: reset high-speed USB device number 2 using ehci-pci and you'll see. Finally, at timestamp 20673 a series of reset attempts ended in failure. That's when the device was re-detected on the OHCI controller. If you want to find out what caused those resets, capture a usbmon trace for bus 2. It may provide a clue. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB-related build errors on Tegra in next-20130319
Felipe, I see the following Kconfig warnings in next-20130319: warning: (ARCH_TEGRA_2x_SOC ARCH_TEGRA_3x_SOC) selects USB_ULPI which has unmet direct dependencies (USB_SUPPORT USB_PHY ARM) warning: (ARCH_TEGRA_2x_SOC ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT which has unmet direct dependencies (USB_SUPPORT USB_PHY USB_ULPI) include/config/auto.conf:624:warning: override: ARCH_MULTIPLATFORM changes choice state warning: (ARCH_TEGRA_2x_SOC ARCH_TEGRA_3x_SOC) selects USB_ULPI which has unmet direct dependencies (USB_SUPPORT USB_PHY ARM) warning: (ARCH_TEGRA_2x_SOC ARCH_TEGRA_3x_SOC) selects USB_ULPI_VIEWPORT which has unmet direct dependencies (USB_SUPPORT USB_PHY USB_ULPI) Which I believe are the cause of the following build errors: drivers/built-in.o: In function `controller_resume': drivers/usb/host/ehci-tegra.c:556: undefined reference to `tegra_usb_phy_preresume' drivers/usb/host/ehci-tegra.c:479: undefined reference to `tegra_ehci_phy_restore_start' drivers/usb/host/ehci-tegra.c:551: undefined reference to `tegra_ehci_phy_restore_end' drivers/usb/host/ehci-tegra.c:546: undefined reference to `tegra_ehci_phy_restore_end' drivers/built-in.o: In function `tegra_ehci_probe': drivers/usb/host/ehci-tegra.c:734: undefined reference to `tegra_usb_phy_open' drivers/built-in.o: In function `tegra_ehci_hub_control': drivers/usb/host/ehci-tegra.c:162: undefined reference to `tegra_usb_phy_postresume' drivers/usb/host/ehci-tegra.c:215: undefined reference to `tegra_usb_phy_preresume' make: *** [vmlinux] Error 1 I pointed out at least the Kconfig problems when you posted the PHY error handling cleanup series, so I'm not sure why those patches were applied. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Mouse Disconnect Kernel-3.7/3.8
This message is a repost. I did not include the complete original message in my initial reply, and I am doing so now. On Mon, 11 Mar 2013, Frank Peters wrote: When I boot my x64 Linux system to the console a continuous series of USB disconnect/reconnect messages appears in the kernel log. The disconnect/reconnect messages concern the USB mouse: usb 1-1.3: USB disconnect, device number N usb 1-1.3: new low-speed USB device number N+1 using ehci-pci input: Microsoft Microsoft Basic Optical Mouse v2.0 as /devices/pci:00/:00:1a.0 usb1/1-1/1-1.3/1-1.3:1.0/input/input5 hid-generic 0003:045E:00CB.0006: input: USB HID v1.11 Mouse [Microsoft Microsoft Basic Optical Mouse v2.0 ] on usb-:00:1a.0-1.3/input0 These USB disconnect/reconnect messages will repeat roughly every 40 seconds with the device number N increasing to N+1 each time. The interesting thing about this behavior is that I can stop the messages, and presumably the disconnects, by starting the General Purpose Mouse (gpm) server: gpm -m /dev/input/mice -t imps2 If I then terminate the gpm server, the USB disconnect/reconnect messages will start to occur once again. The USB disconnects also stop when I start the graphical X server. It would seem that if nothing is grabbing the USB mouse (i.e. gpm or X) then the kernel somehow automatically disconnects it. My system has the USB built in to the kernel (no modules). The motherboard I use is Intel DP55KG which has the P55 Express chipset to control the USB. I've seen this behavior on the current kernel-3.8.x and also on the previous kernel-3.7. I have not tested anything earlier. Please CC to frank.pet...@comcast.net as I am not subscribed to the list. [ adding linux-usb@ to CC ] Do you have USB autosuspend enabled on that device? The CONFIG_USB_SUSPEND, which controls USB autosuspend, is not available to me during kernel configuration because I do not enable Run-time PM core functionality (PM_RUNTIME). Based on this, I would assume that USB autosuspend is not enabled. Frank Peters -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, Mar 19, 2013 at 4:38 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 19 Mar 2013, Daniel Vetter wrote: For reference below the updated commit message. Cheers, Daniel Author: Jiri Kosina jkos...@suse.cz Date: Tue Mar 19 09:56:57 2013 +0100 drm/i915: stop using GMBUS IRQs on Gen4 chips Commit 28c70f162 (drm/i915: use the gmbus irq for waits) switched to using GMBUS irqs instead of GPIO bit-banging for chipset generations 4 and above. It turns out though that on many systems this leads to spurious interrupts being generated, long after the register write to disable the IRQs has been issued. Typically this results in the spurious interrupt source getting disabled: [9.636345] irq 16: nobody cared (try booting with the irqpoll option) [9.637915] Pid: 4157, comm: ifup Tainted: GF 3.9.0-rc2-00341-g0863702 #422 [9.639484] Call Trace: [9.640731] IRQ [8109b40d] __report_bad_irq+0x1d/0xc7 [9.640731] [8109b7db] note_interrupt+0x15b/0x1e8 [9.640731] [810999f7] handle_irq_event_percpu+0x1bf/0x214 [9.640731] [81099a88] handle_irq_event+0x3c/0x5c [9.640731] [8109c139] handle_fasteoi_irq+0x7a/0xb0 [9.640731] [8100400e] handle_irq+0x1a/0x24 [9.640731] [81003d17] do_IRQ+0x48/0xaf [9.640731] [8142f1ea] common_interrupt+0x6a/0x6a [9.640731] EOI [8142f952] ? system_call_fastpath+0x16/0x1b [9.640731] handlers: [9.640731] [a000d771] usb_hcd_irq [usbcore] [9.640731] [a0306189] yenta_interrupt [yenta_socket] [9.640731] Disabling IRQ #16 The really curious thing is now that irq 16 is _not_ the interrupt for the i915 driver when using MSI, but it _is_ the interrupt when not using MSI. So by all indications it seems like gmbus is able to generate a legacy (shared) interrupt in MSI mode on some configurations. I've tried to reproduce this and the differentiating thing seems to be that on unaffected systems no other device uses irq 16 (which seems to be the non-MSI intel gfx interrupt on all gm45). That might be misleading. It's possible that the erroneous IRQs _are_ being issued but you're simply not aware of them. If the kernel thinks that no device is using IRQ 16 then it will leave that IRQ disabled. I guess I should have phrased it more precisely, but that's exactly what I expect is happening on my machine: I don't have anything on irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence the irq is completely disabled. Which obviously makes it impossible for me to reproduce the issue. To test that theory, is there a quick way to force-enable a given interrupt, short of just hacking up a 2nd dummy irq handler in my driver? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: Make USB persist default configurable
Yes, okay, that's true. If a new USB device is plugged in while the lid is shut, and then the lid is opened very briefly, it's possible that the system could suspend again before the new device's persist attribute is updated. Does that case really matter? The device isn't likely to be in use at that point. It does matter if the device will be used after the next resume, because that one would use the persist code. If there was a driver problem it would fail, and if it was a USB stick that is swapped with a different one of the same model, you could get file system corruption. I agree with you that buggy drivers should get fixed (and we are trying to do that as well), but at the same time we want to be able to have a system that can keep its policies at all times. We get a lot of USB problems (especially around suspend/resume), and we don't want to need to worry every time about which code path we hit and whether one of those race conditions could have something to do with it. I'm convinced that having this in the kernel is the cleanest solution for us, and I just thought it might be useful to standardize a mechanism for that (I don't really see the maintenance burden in that config option either, as the persist mechanism itself does not look like it was going to go away anytime soon). -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, 19 Mar 2013, Daniel Vetter wrote: That might be misleading. It's possible that the erroneous IRQs _are_ being issued but you're simply not aware of them. If the kernel thinks that no device is using IRQ 16 then it will leave that IRQ disabled. I guess I should have phrased it more precisely, but that's exactly what I expect is happening on my machine: I don't have anything on irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence the irq is completely disabled. Which obviously makes it impossible for me to reproduce the issue. To test that theory, is there a quick way to force-enable a given interrupt, short of just hacking up a 2nd dummy irq handler in my driver? I don't know of any way. In fact, I have been thinking of writing a test driver module, with a module parameter telling it which IRQ number to register for. It seems like the sort of thing that would be useful to have, from time to time. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: xhci: fix build warning
On Tue, Mar 19, 2013 at 09:45:38AM +0800, Peter Chen wrote:
On Mon, Mar 18, 2013 at 08:48:15AM -0700, Sarah Sharp wrote:
You moved the check for out-of-range port_id further down in the code,
and it really needs to be before the line above. Otherwise the host
could give us a garbage port number and the kernel will do an
out-of-bounds array access.
How about below version:
drivers/usb/host/xhci-ring.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8828754..ec26819 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1599,14 +1599,20 @@ static void handle_port_status(struct xhci_hcd *xhci,
max_ports = HCS_MAX_PORTS(xhci-hcs_params1);
if ((port_id = 0) || (port_id max_ports)) {
xhci_warn(xhci, Invalid port id %d\n, port_id);
- bogus_port_status = true;
- goto cleanup;
+ inc_deq(xhci, xhci-event_ring);
+ return;
Sure, this looks sane, since the cleanup label just does the same thing.
Please resubmit this patch formally, and we'll get it into usb-linus.
}
/* Figure out which usb_hcd this port is attached to:
* is it a USB 3.0 port or a USB 2.0/1.1 port?
*/
major_revision = xhci-port_array[port_id - 1];
+
+ /* Find the right roothub. */
+ hcd = xhci_to_hcd(xhci);
+ if ((major_revision == 0x03) != (hcd-speed == HCD_USB3))
+ hcd = xhci-shared_hcd;
+
if (major_revision == 0) {
xhci_warn(xhci, Event for port %u not in
Extended Capabilities, ignoring.\n,
@@ -1629,10 +1635,6 @@ static void handle_port_status(struct xhci_hcd *xhci,
* into the index into the ports on the correct split roothub, and the
* correct bus_state structure.
*/
- /* Find the right roothub. */
- hcd = xhci_to_hcd(xhci);
- if ((major_revision == 0x03) != (hcd-speed == HCD_USB3))
- hcd = xhci-shared_hcd;
bus_state = xhci-bus_state[hcd_index(hcd)];
if (hcd-speed == HCD_USB3)
port_array = xhci-usb3_ports;
--
Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/23] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10
Hi Felipe, * Roger Quadros rog...@ti.com [130315 08:20]: Hi Tony, These patches provide the SoC side code required to support the changes in the OMAP USB Host drivers done in [1], [2] [3]. Device tree support is added for Beagleboard and Panda. NOTE: The first patch needs to be shared between the OMAP tree and Felipe's USB tree. Do you want to put the platform_data header changes alone into some immutable branch or want me to do it? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reboot/shutdown failure due to USB: EHCI: work around silicon bug in Intel's EHCI
On 03/19/2013 12:34 PM, Alan Stern wrote: On Mon, 18 Mar 2013, Stephen Warren wrote: Alan, In v3.9-rc3, I find that reboot and shutdown hang on Tegra. I bisected it to commit 6402c79 USB: EHCI: work around silicon bug in Intel's EHCI controllers, and confirmed that running v3.9-rc3 with just that one patch reverted does solve the problem. Do you have any idea what the problem might be, or is there anything I can do to help debug this? Thanks. Is there any way to find out where the hangup occurs? For example, can you get anything from Alt-SysRq-W? Failing that, can you put some printk statements in drivers/usb/host/ehci-hcd.c, in the ehci_halt(), ehci_silence_controller(), and ehci_shutdown() routines? (Although I suspect this may not help because the hangup occurs somewhere else...) Yes, sysrq seems to work over the serial console:-) * Will now restart *** break sent *** [ 180.765213] SysRq : Show Blocked State [ 180.768963] taskPC stack pid father [ 180.774182] khubd D c0517678 021 2 0x [ 180.780559] [c0517678] (__schedule+0x348/0x6dc) from [c02ebc90] (usb_kill_urb+0x88/0xd4) [ 180.788984] [c02ebc90] (usb_kill_urb+0x88/0xd4) from [c02ecb70] (usb_start_wait_urb+0xa4/0x13c) [ 180.798012] [c02ecb70] (usb_start_wait_urb+0xa4/0x13c) from [c02ecd98] (usb_control_msg+0x98/0xcc) [ 180.807301] [c02ecd98] (usb_control_msg+0x98/0xcc) from [c02e4394] (hub_port_init+0x5e0/0x9d0) [ 180.816242] [c02e4394] (hub_port_init+0x5e0/0x9d0) from [c02e6640] (hub_port_connect_change+0x1f4/0x970) [ 180.826050] [c02e6640] (hub_port_connect_change+0x1f4/0x970) from [c02e70fc] (hub_events+0x340/0x8c4) [ 180.835598] [c02e70fc] (hub_events+0x340/0x8c4) from [c02e76a8] (hub_thread+0x28/0x1b8) [ 180.843941] [c02e76a8] (hub_thread+0x28/0x1b8) from [c0041268] (kthread+0xa4/0xb0) [ 180.851851] [c0041268] (kthread+0xa4/0xb0) from [c000ed98] (ret_from_fork+0x14/0x3c) [ 180.859929] udevd D c0517678 0 167 1 0x0001 [ 180.866285] [c0517678] (__schedule+0x348/0x6dc) from [c0517df0] (schedule_preempt_disabled+0x24/0x34) [ 180.875834] [c0517df0] (schedule_preempt_disabled+0x24/0x34) from [c05167f8] (__mutex_lock_slowpath+0x15c/0x354) [ 180.886336] [c05167f8] (__mutex_lock_slowpath+0x15c/0x354) from [c05169fc] (mutex_lock+0xc/0x24) [ 180.895455] [c05169fc] (mutex_lock+0xc/0x24) from [c02f1fd0] (show_manufacturer+0x18/0x40) [ 180.904059] [c02f1fd0] (show_manufacturer+0x18/0x40) from [c027fe18] (dev_attr_show+0x1c/0x48) [ 180.913007] [c027fe18] (dev_attr_show+0x1c/0x48) from [c01191c0] (sysfs_read_file+0x90/0x16c) [ 180.921870] [c01191c0] (sysfs_read_file+0x90/0x16c) from [c00c8418] (vfs_read+0x98/0x13c) [ 180.930379] [c00c8418] (vfs_read+0x98/0x13c) from [c00c84f8] (SyS_read+0x3c/0x70) [ 180.938196] [c00c84f8] (SyS_read+0x3c/0x70) from [c000ed00] (ret_fast_syscall+0x0/0x30) [ 180.946527] reboot D c0517678 0 877876 0x [ 180.952883] [c0517678] (__schedule+0x348/0x6dc) from [c0517df0] (schedule_preempt_disabled+0x24/0x34) [ 180.962432] [c0517df0] (schedule_preempt_disabled+0x24/0x34) from [c05167f8] (__mutex_lock_slowpath+0x15c/0x354) [ 180.972934] [c05167f8] (__mutex_lock_slowpath+0x15c/0x354) from [c05169fc] (mutex_lock+0xc/0x24) [ 180.982050] [c05169fc] (mutex_lock+0xc/0x24) from [c02813c4] (device_shutdown+0xc8/0x188) [ 180.990566] [c02813c4] (device_shutdown+0xc8/0x188) from [c00364b4] (kernel_restart_prepare+0x34/0x3c) [ 181.000202] [c00364b4] (kernel_restart_prepare+0x34/0x3c) from [c00364c8] (kernel_restart+0xc/0x4c) [ 181.009578] [c00364c8] (kernel_restart+0xc/0x4c) from [c00366bc] (SyS_reboot+0x1ac/0x1d8) [ 181.018086] [c00366bc] (SyS_reboot+0x1ac/0x1d8) from [c000ed00] (ret_fast_syscall+0x0/0x30) I assume you only want the back-traces, not the reset of the sysrq spew? BTW, I have also occasionally noticed some either hung task or RCU spew related to usb_kill_urb at other times (i.e. when not rebooting), IIRC (which I may not; I may be remembering what happens if I just leave the reboot hung for a few minutes, as shown below): [ 240.670335] INFO: task khubd:21 blocked for more than 120 seconds. [ 240.676516] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.684336] khubd D c0517678 021 2 0x [ 240.690706] [c0517678] (__schedule+0x348/0x6dc) from [c02ebc90] (usb_kill_urb+0x88/0xd4) [ 240.699140] [c02ebc90] (usb_kill_urb+0x88/0xd4) from [c02ecb70] (usb_start_wait_urb+0xa4/0x13c) [ 240.708181] [c02ecb70] (usb_start_wait_urb+0xa4/0x13c) from [c02ecd98] (usb_control_msg+0x98/0xcc) [ 240.717481] [c02ecd98] (usb_control_msg+0x98/0xcc) from [c02e4394] (hub_port_init+0x5e0/0x9d0) [ 240.726433] [c02e4394] (hub_port_init+0x5e0/0x9d0) from [c02e6640] (hub_port_connect_change+0x1f4/0x970) [ 240.736251] [c02e6640]
Re: [PATCH 5/11] USB: EHCI: changes related to qh_refresh()
On Mon, 18 Mar 2013, Greg KH wrote: This patch fails to apply to my usb-next branch, after the 4 previous patches were applied: checking file drivers/usb/host/ehci-q.c Hunk #2 FAILED at 123. Hunk #3 succeeded at 545 (offset -8 lines). Hunk #4 succeeded at 557 (offset -8 lines). Hunk #5 succeeded at 945 (offset -8 lines). 1 out of 5 hunks FAILED checking file drivers/usb/host/ehci-sched.c Any ideas? I can't apply the rest of them, so can you fix this up and just resend this, and the remaining patches? The problem is that I do my development in a work branch that includes both of your usb-linus and usb-next branches, merged together. Or if you want to put it another way, I do my development in a single branch that includes -stable and -current material as well as stuff for -next. It seems foolish not to do this, since the -next patches will eventually have to merge into a kernel that includes the others -- not to mention that some of the -next work _depends_ on the other changes. In particular, this patch was based on a kernel that already has commit feca7746d5d9 applied -- that commit is in your usb-linus branch but not usb-next. That explains why you couldn't apply this patch; it touches some of the same code as feca7746d5d9. How should we handle this? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 2/2] usb/acpi: binding xhci root hub usb port with ACPI
Ok, this looks sane, and our Intel testers report it doesn't oops like
v2. The patch description on the first patch is better as well.
Tianyu, I know this introduces a new API to the host controller driver
structure, and we would normally queue these two patches for 3.10.
However, I know a lot of the port power off code went into 3.9. If we
don't have these patches in 3.9, what will be the impact? Will we say,
misassign a power resource from a particular port, or mismark a USB port
connection type? Is there any user-level impact if we don't have these
in 3.9?
If these patches should go into 3.9, should they also be backported to
3.8 and 3.7? Commit d557542421da643358201664903e67fd01dfca1a
usb/acpi: Bind ACPI node to USB port, not usb_device. was first
introduced in 3.7, and it looks like the sysfs files to turn on and off
ports were added in 3.7 as well. Without these two patches, will
that sysfs interface work correctly?
Sarah Sharp
On Tue, Mar 19, 2013 at 04:48:13PM +0800, Lan Tianyu wrote:
This patch is to bind xhci root hub usb port with its acpi node.
The port num in the acpi table matches with the sequence in the xhci
extended capabilities table. So call usb_hcd_find_raw_port_number() to
transfer hub port num into raw port number which associates with
the sequence in the xhci extended capabilities table before binding.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
Change since v3:
add a temprorary variable to recard raw port num and get ACPI
handle rahter than overwrite port num with raw port num. This is
to avoid passing raw port num as port num to
usb_acpi_check_port_connect_type().
drivers/usb/core/usb-acpi.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index b6f4bad..255c144 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -15,6 +15,7 @@
#include linux/kernel.h
#include linux/acpi.h
#include linux/pci.h
+#include linux/usb/hcd.h
#include acpi/acpi_bus.h
#include usb.h
@@ -188,8 +189,13 @@ static int usb_acpi_find_device(struct device *dev,
acpi_handle *handle)
* connected to.
*/
if (!udev-parent) {
- *handle = acpi_get_child(DEVICE_ACPI_HANDLE(udev-dev),
+ struct usb_hcd *hcd = bus_to_hcd(udev-bus);
+ int raw_port_num;
+
+ raw_port_num = usb_hcd_find_raw_port_number(hcd,
port_num);
+ *handle = acpi_get_child(DEVICE_ACPI_HANDLE(udev-dev),
+ raw_port_num);
if (!*handle)
return -ENODEV;
} else {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo
On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: I guess I should have phrased it more precisely, but that's exactly what I expect is happening on my machine: I don't have anything on irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence the irq is completely disabled. Which obviously makes it impossible for me to reproduce the issue. To test that theory, is there a quick way to force-enable a given interrupt, short of just hacking up a 2nd dummy irq handler in my driver? You may try to add another request_irq() after i915_load_modeset_init==drm_irq_install. That could install one dummy action for ioapic irq for i915. Also you may need to add one quirk that does not disable intx during msi enabling like: DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2e22, quirk_msi_intx_disable_bug); Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mismatch in TRB_LEN bit mask for Transfer Event TRBs
On Thu, Mar 07, 2013 at 03:38:46PM +0530, Vivek Gautam wrote: Hi Sarah, While going through the code for Handling Transfer Events (drivers/usb/host/xhci-ring.c), i hit upon this problem. As defined in drivers/usb/host/xhci.h /* Normal TRB fields */ /* transfer_len bitmasks - bits 0:16 */ #define TRB_LEN(p) ((p) 0x1) And the same macro i could see being used while Handling Trasfer events handle_tx_event(), and further in process_ctrl_td(), process_isoc_td(), and process_bulk_intr_td(). However, as per XHCI specs (Rev 1.0, 5/21/10) section 6.4.2.1 for Transfer event TRBs, the transfer length is bits 0:23 thereby something like below could be valid: /* Transfer event TRB length bit mask */ /* bits 0:23 */ #defineEVENT_TRB_LEN(p)((p) 0xff) This difference is confusing somewhat. I hope the current code must be pretty much fine, and there could be something that i might be stupidly missing. Nope, you've caught an honest-to-goodness bug. :) Would you like to submit a patch to fix this? It should be pretty easy to look at the context in xhci-ring.c and figure out whether the function is queueing a TRB (and thus should use the TRB_LEN macro) or handling a event TRB (and should be using the new EVENT_TRB_LEN macro). Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] usb: phy: tegra: Add error handling clean up.
On 03/18/2013 06:29 AM, Venu Byravarasu wrote: Check return values from all GPIO APIs and handle errors accordingly. Remove clk_disable_unprepare which is no more needed. Patches 6 and 7 each fail checkpatch with WARNING: line over 80 characters. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] USB: PHY: Tegra: registering TEGRA USB PHY as platform driver
On 03/18/2013 06:29 AM, Venu Byravarasu wrote: As part of this series, apart from patch containing changes to register TEGRA USB PHY driver as platform driver, prepared below patches: 1. Re-arranging adding new DT properties. 2. Getting various params from DT properties added. 3. code clean up. Venu, I'm curious whether these patches were tested at all. I have found at least two significant problems with trivial testing: 1) reboot or shutdown -h now both cause the following crash, with or without any USB devices plugged in (or ever having been plugged in): [ 355.836288] Unable to handle kernel NULL pointer dereference at virtual address 0028 [ 355.847961] pgd = ed62 [ 355.854093] [0028] *pgd= ... [ 356.146728] [c02e5978] (tegra_ehci_hcd_shutdown+0x18/0x2c) from [c0279edc] (platform_drv_shutdown+0x18/0x1c) [ 356.160379] [c0279edc] (platform_drv_shutdown+0x18/0x1c) from [c027703c] (device_shutdown+0x34/0x188) [ 356.173464] [c027703c] (device_shutdown+0x34/0x188) from [c0034650] (kernel_restart_prepare+0x34/0x3c) [ 356.186668] [c0034650] (kernel_restart_prepare+0x34/0x3c) from [c0034664] (kernel_restart+0xc/0x4c) [ 356.199637] [c0034664] (kernel_restart+0xc/0x4c) from [c0034858] (sys_reboot+0x1ac/0x1d8) [ 356.211704] [c0034858] (sys_reboot+0x1ac/0x1d8) from [c000e2c0] (ret_fast_syscall+0x0/0x30) [ 356.223965] Code: ebfe4b27 e5903000 e24300e8 e5133044 (e5933028) [ 356.233896] ---[ end trace 088d89482b4af176 ]--- 2) The first time enumeration USB devices is attempted on a port fails. For devices that are plugged in at boot, this means that to get them working, they must be unplugged and re-plugged after boot. For devices that are not plugged in at boot, this means they must be plugged, unplugged, and then plugged in again. This is obviously problematic in and of itself. This is especially true for boards like Harmony that have a built-in USB hub and network chip. I didn't actually test this, but I assume that they cannot be made to work at all with this patch series, since they cannot be unplugged. The failed enumeration is accompanied by the following message: [2.451530] hub 3-0:1.0: unable to enumerate USB device on port 1 Both of these problems reproduce on at least boards Ventana and Seaboard(Springbank), although I assume that all boards are affected. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: phy: tegra: Get PHY mode using DT
On 03/18/2013 06:29 AM, Venu Byravarasu wrote:
Added a new PHY mode to support OTG.
Obtained Tegra USB PHY mode using DT property.
diff --git a/drivers/usb/phy/tegra_usb_phy.c b/drivers/usb/phy/tegra_usb_phy.c
@@ -713,6 +712,16 @@ struct tegra_usb_phy *tegra_usb_phy_open(struct device
*dev, int instance,
else
phy-is_ulpi_phy = true;
+ err = of_property_match_string(np, dr_mode, otg);
+ if (err 0) {
+ err = of_property_match_string(np, dr_mode, gadget);
+ if (err 0)
The binding says the 3 legal values for this property are host,
peripheral, or otg. This agrees with the usage in
Documentation/devicetree/bindings/usb/fsl-usb.txt and
drivers/usb/host/fsl-mph-dr-of.c. So, gadget is not something the code
should be checking for.
I'm sure I pointed this out before.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regarding compiling kernel-2.6.38.6-1 with PLX USB338x Linux driver modules on fedora 15
On Tue, Mar 19, 2013 at 10:58:26AM +0100, humanshu bhatia wrote: Hello Sebastian, Hi humanshu, I have compiled linux-2.6.38.6.tar.bz2 on fedora 15. make menuconfig (Selecting PLX support and gadget zero option ) make rpm But after including latest PLX_USB338x_Linux_Driver_v_1_3_1: gadget and include files as given by vendor in this kernel make menuconfig (Selecting PLX support and gadget zero option ) make rpm That PLX driver is not part of the standard kernel and I've never seen the source nor what it does to the kernel. During compilation I face below errors: drivers/usb/core/hcd.c: In function 'register_root_hub': drivers/usb/core/hcd.c:986:3: error: implicit declaration of function 'HCD_DEAD' [-Werror=implicit-function-declaration] drivers/usb/core/hcd.c: In function 'usb_hcd_link_urb_to_ep': drivers/usb/core/hcd.c:1092:2: error: implicit declaration of function 'HCD_RH_RUNNING' [-Werror=implicit-function-declaration] drivers/usb/core/hcd.c: In function 'hcd_bus_suspend': drivers/usb/core/hcd.c:1938:13: error: 'HCD_FLAG_RH_RUNNING' undeclared (first use in this function) drivers/usb/core/hcd.c:1938:13: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/core/hcd.c: In function 'hcd_bus_resume': drivers/usb/core/hcd.c:1986:12: error: 'HCD_FLAG_RH_RUNNING' undeclared (first use in this function) drivers/usb/core/hcd.c: In function 'usb_hc_died': drivers/usb/core/hcd.c:2134:12: error: 'HCD_FLAG_RH_RUNNING' undeclared (first use in this function) drivers/usb/core/hcd.c:2135:10: error: 'HCD_FLAG_DEAD' undeclared (first use in this function) drivers/usb/core/hcd.c: In function 'usb_add_hcd': drivers/usb/core/hcd.c:2282:10: error: 'HCD_FLAG_RH_RUNNING' undeclared (first use in this function) drivers/usb/core/hcd.c: In function 'usb_remove_hcd': drivers/usb/core/hcd.c:2404:12: error: 'HCD_FLAG_RH_RUNNING' undeclared (first use in this function) cc1: some warnings being treated as errors make[5]: *** [drivers/usb/core/hcd.o] Error 1 make[4]: *** [drivers/usb/core] Error 2 make[3]: *** [drivers/usb] Error 2 make[2]: *** [drivers] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.Ok7Rxz (%build) This looks strange. If you enable USB in kernel it should compile without the errors you have here. I would assume that the PLX driver is touching the files and it does work with v2.6.38 but some other kernel and now you see the errors. Now I compiled the kernel without including latest PLX_USB338x_Linux_Driver_v_1_3_1: gadget and include files. So now after compilation I get required rpm file : # ls /root/rpmbuild/SRPMS/ kernel-2.6.38.6-1.src.rpm I think the issue is with the headers but I do not know where to define these headers. Please tell me how to resolve above errors. Either you ask the vendor which kernel works with your PLX driver or you try to make it with your current kernel by fixing the errors that pop up. Or you try different hardware :) Thanks Regards, Humanshu Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UHCI/EHCI interrupt storm after resume from S3
On 3/18/2013 1:35 PM, Greg KH wrote: On Mon, Mar 18, 2013 at 01:30:47PM -0700, Waskiewicz Jr, Peter P wrote: I have an Atom-based machine (N450) with an ICH8 running Ubuntu LTS 12.04.2. This has the latest updates installed, kernel 3.5.0-23.35. I put the machine into S3, then woke it from the network. After resume, the uhci_hcd and ehci_hcd devices (sharing an interrupt) start flooding interrupts. This continues until the USB driver is reloaded, or I reboot. Is this a known issue? I'm willing to assist debugging, I just wanted to ask if people have seen this yet before I dig into it. If it comes down to building linux-next via git, that's fine, it'll just take about 4 hours on this box to do it. Let me know if there's any additional data folks want to see. Can you see if this happens with the latest 3.8.3 kernel release? If you are stuck using Ubuntu kernels, you need to get support from Canonical, there's nothing we can do with their kernel packages, sorry. Ok, I take back my previous mail that it's ok with 3.8.3. The bug is still there, albeit it's intermittent. After 4-5 suspend/resumes on this box, the ehci_hcd and uhci_hcd (shared fasteoi interrupt) are flooding interrupts. More information: USB controller: Intel ICH8, PCI ID 0x2830 - 0x2836 BIOS: AMI version 080015 Processor: Atom D510 Any other info I can provide if requested. Anything anyone would like me to try, just let me know. Cheers, -PJ -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 03/10] xhci: Handle command stalls.
On Fri, Mar 08, 2013 at 09:15:07PM -0500, Alan Stern wrote: On Fri, 8 Mar 2013, Sarah Sharp wrote: On Fri, Mar 08, 2013 at 11:14:38AM -0500, Alan Stern wrote: On Thu, 7 Mar 2013, Sarah Sharp wrote: You might want to go farther than this. I haven't read the driver code enough to be sure how you have this organized, but it seems logical that you shouldn't set a command's expiration time until that command begins executing. Suppose the ring contains commands A and B and you set B's expiration time while A is still running. Then A could continue running until B's time is almost up. When B does start, the watchdog timer will expire before B has a chance to do anything. Yes, it's true. With this patch, the watchdog timer will re-queue itself, of course. No; it will see that B is the currently executing command and either cancel B or conclude that the host is dead. Just like the behavior without this patch, except that the window of opportunity is smaller. Well, yes, I'm not sure if it's possible to completely eliminate that small window of opportunity. Even if only the currently executing command were timed, the host could start processing it at just the moment that the timer fired. We just give the host exactly the same amount of slack if we only time the currently executing command. I do agree that it's inefficient to have multiple timers running when we could only have one timer running. By not setting a command's expiration time until that command begins running, you remove the need for the check added by this patch. It will not be possible for the command's watchdog timer to expire before the command becomes the one currently executing. In general, all the commands wait (interruptibly) on a completion, with a 5 second timeout. However, the Stop Endpoint command doesn't have a completion, since it's part of the asynchronous call to cancel an URB. The Stop Endpoint command is the only one with a watchdog timer. I started out with an idea to yours, of having a global command list. Commands would be queued to the FIFO, submitted to the command ring, and then their submitters would call wait_for_completion_interruptible (without a timeout), or simply return, in the case of the Stop Endpoint command. The watchdog timer routine would be gutted to be a global command queue manager that timed the currently executing command, and would cancel it if necessary. In the end, I decided it would be better for the stable kernels to keep to the simpler (if less efficient) solution. But I would like to do the right thing later on. Would it be simpler to keep the existing implementation, but start the timer for a Stop Endpoint command in the completion handler for the previous command? (But then what happens if there are two Stop Endpoint commands in a row?) It depends on if the canceled URB is on the same endpoint, or different endpoints. Each endpoint has a separate timer. If a Stop Endpoint is in flight for the same endpoint, the driver doesn't start the timer again, it just increments the number of in-flight Stop Endpoint commands for that endpoint. Two Stop Endpoint commands could be queued for different endpoints. If I were to add the code to only start the timer for the Stop Endpoint command in the completion handler for the previous command, I would probably just move to only timing the currently executing command. I'll look into it and see how much code is. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reboot/shutdown failure due to USB: EHCI: work around silicon bug in Intel's EHCI
On 03/19/2013 02:07 PM, Alan Stern wrote: On Tue, 19 Mar 2013, Stephen Warren wrote: Yes, sysrq seems to work over the serial console:-) * Will now restart *** break sent *** [ 180.765213] SysRq : Show Blocked State [ 180.768963] taskPC stack pid father [ 180.774182] khubd D c0517678 021 2 0x [ 180.780559] [c0517678] (__schedule+0x348/0x6dc) from [c02ebc90] (usb_kill_urb+0x88/0xd4) [ 180.788984] [c02ebc90] (usb_kill_urb+0x88/0xd4) from [c02ecb70] (usb_start_wait_urb+0xa4/0x13c) [ 180.798012] [c02ecb70] (usb_start_wait_urb+0xa4/0x13c) from [c02ecd98] (usb_control_msg+0x98/0xcc) [ 180.807301] [c02ecd98] (usb_control_msg+0x98/0xcc) from [c02e4394] (hub_port_init+0x5e0/0x9d0) [ 180.816242] [c02e4394] (hub_port_init+0x5e0/0x9d0) from [c02e6640] (hub_port_connect_change+0x1f4/0x970) [ 180.826050] [c02e6640] (hub_port_connect_change+0x1f4/0x970) from [c02e70fc] (hub_events+0x340/0x8c4) [ 180.835598] [c02e70fc] (hub_events+0x340/0x8c4) from [c02e76a8] (hub_thread+0x28/0x1b8) [ 180.843941] [c02e76a8] (hub_thread+0x28/0x1b8) from [c0041268] (kthread+0xa4/0xb0) I assume you only want the back-traces, not the reset of the sysrq spew? Yes. It looks like khubd is your problem. BTW, I have also occasionally noticed some either hung task or RCU spew related to usb_kill_urb at other times (i.e. when not rebooting), IIRC (which I may not; I may be remembering what happens if I just leave the reboot hung for a few minutes, as shown below): [ 240.670335] INFO: task khubd:21 blocked for more than 120 seconds. [ 240.676516] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.684336] khubd D c0517678 021 2 0x Right. It's another symptom of the same thing. This problem occurs well before shutdown -- something is causing khubd to hang and that messes up everything else. A dmesg log with CONFIG_USB_DEBUG enabled would be helpful. We ought to be able to tell where khubd is getting stuck. Hmmm. Enabling CONFIG_USB_DEBUG appears to mask the problem. I assume this is some kind of timing/race condition, unless there's some code with required side-effects hiding under ifdef CONFIG_USB_DEBUG somehow? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reboot/shutdown failure due to USB: EHCI: work around silicon bug in Intel's EHCI
On 03/19/2013 04:48 PM, Stephen Warren wrote: On 03/19/2013 02:07 PM, Alan Stern wrote: ... A dmesg log with CONFIG_USB_DEBUG enabled would be helpful. We ought to be able to tell where khubd is getting stuck. Hmmm. Enabling CONFIG_USB_DEBUG appears to mask the problem. I assume this is some kind of timing/race condition, unless there's some code with required side-effects hiding under ifdef CONFIG_USB_DEBUG somehow? Some further information: I added some printks, which are hopefully obvious from the text below, and in the failing case, I see: [1.291277] single_unlink_async: qh ee31bc40 qh_state set to UNLINK_WAIT [1.297960] start_iaa_cycle: qh ee31bc40 qh_state changing UNLINK_WAIT - UNLINK ... [6.452331] ehci_urb_dequeue: qh ee31bc40 attempting dequeue (qh_stated 2) This is with CONFIG_USB_DEBUG disabled. That seems to happen to the very first (and only) URB(?) ever issued. If I enable CONFIG_USB_DEBUG, then I see the more expected: [1.540410] single_unlink_async: qh ee0c0300 qh_state set to UNLINK_WAIT [1.547094] start_iaa_cycle: qh ee0c0300 qh_state changing UNLINK_WAIT - UNLINK [1.554487] start_iaa_cycle: qh ee0c0300 qh_state was UNLINK; processing followed by a whole slew of subsequent URBs being submitted and processed. Perhaps the issue is that start_iaa_cycle() (or whatever triggers it) only happens when there's an URB in state UNLINK, but not when there's only one in state UNLINK_WAIT, so that it only happens once rather than the required twice? I'm not sure why a timing difference would affect this though, unless there's some loop in the IAA processing that happens to do both the UNLINK_WAIT-UNLINK change, and the processing of the URB in the UNLINK state in one invocation sometimes, but not others? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Regression] process hangs due to USB: EHCI: work around silicon bug in Intels EHCI controllers
The named commit (6402c796d3) causes a process to hang indefinitely in usb_kill_urb(). Reverting it fixes the problem. The bug also prevents suspend/shutdown/reboot from completing, presumably due to the hanging process. (Cc'ing Stephen Warren because I only found his report after I bisected it myself. Do you also see a blocked process?) This is the hanging process on my system: [ 240.364085] INFO: task colord-sane:3619 blocked for more than 120 seconds. [ 240.364090] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 240.364093] colord-sane D 1388 0 3619 3602 0x [ 240.364099] 8801255cd818 0046 0296 81c11400 [ 240.364105] 8801255cd7c8 880127488000 8801255cdfd8 8801255cdfd8 [ 240.364112] 00013600 880127488000 8801255cd828 8801234536c0 [ 240.364118] Call Trace: [ 240.364127] [81685af0] schedule+0x65/0x67 [ 240.364132] [8141a235] usb_kill_urb+0xb5/0xd3 [ 240.364138] [8109713a] ? bit_waitqueue+0x7a/0x7a [ 240.364143] [8141aa37] usb_start_wait_urb+0xb2/0x173 [ 240.364148] [8141ad21] usb_control_msg+0xd0/0x102 [ 240.364152] [8141ae07] ? usb_get_status+0x3d/0xb0 [ 240.364158] [8114fb80] ? kmem_cache_alloc_trace+0x4b/0xc9 [ 240.364163] [81686ce2] ? _raw_spin_unlock_irqrestore+0x3f/0x6e [ 240.364167] [8141ae4e] usb_get_status+0x84/0xb0 [ 240.364172] [81686d03] ? _raw_spin_unlock_irqrestore+0x60/0x6e [ 240.364177] [8141474c] usb_port_resume+0x37c/0x5b4 [ 240.364183] [810c372a] ? mark_held_locks+0x55/0x99 [ 240.364187] [81686d3e] ? _raw_spin_unlock_irq+0x2d/0x5a [ 240.364193] [81424794] generic_resume+0x1c/0x1e [ 240.364197] [8141cd94] usb_resume_both+0x94/0x106 [ 240.364202] [8141defb] ? usb_runtime_suspend+0x5d/0x5d [ 240.364206] [8141df15] usb_runtime_resume+0x1a/0x1c [ 240.364211] [813a85bd] __rpm_callback+0x34/0x5b [ 240.364216] [813a863a] rpm_callback+0x56/0x79 [ 240.364220] [813a960b] rpm_resume+0x38a/0x4a7 [ 240.364225] [816867a8] ? _raw_spin_lock_irqsave+0x51/0x5c [ 240.364230] [813a9921] ? __pm_runtime_resume+0x5d/0x88 [ 240.364234] [813a992f] __pm_runtime_resume+0x6b/0x88 [ 240.364239] [8141d7ad] usb_autoresume_device+0x20/0x3f [ 240.364244] [814244f3] usbdev_open+0xc7/0x245 [ 240.364249] [8115d14c] chrdev_open+0x130/0x15b [ 240.364254] [8109d115] ? lg_local_unlock+0x3f/0x5e [ 240.364259] [8115d01c] ? cdev_put+0x26/0x26 [ 240.364264] [81158182] do_dentry_open.isra.17+0x16b/0x211 [ 240.364268] [81158249] finish_open+0x21/0x2d [ 240.364273] [81164e3e] do_last.isra.59+0x7dc/0x962 [ 240.364278] [81162c32] ? inode_permission+0x45/0x47 [ 240.364282] [81162cf6] ? link_path_walk+0xc2/0x43e [ 240.364287] [81165089] path_openat.isra.60+0xc5/0x304 [ 240.364292] [811655c7] do_filp_open+0x38/0x86 [ 240.364297] [8116f05a] ? spin_unlock+0x9/0xb [ 240.364302] [8116fcab] ? __alloc_fd+0xf3/0x104 [ 240.364307] [81158eb6] do_sys_open+0x6c/0xf9 [ 240.364311] [81158f64] sys_open+0x21/0x23 [ 240.364316] [8168d286] system_call_fastpath+0x1a/0x1f [ 240.364319] INFO: lockdep is turned off. I tested my USB hardware with Alan's patch/program and it is susceptible to the bug the problematic commit tries to work around, my hardware is: 00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin C routed to IRQ 18 Region 0: Memory at fe8ffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] Vendor Specific Information: Len=06 ? Kernel driver in use: ehci-pci -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] usb: chipidea: udc: add the define TD_COUNT and fix all users
On Tue, Mar 19, 2013 at 01:02:59PM +0100, Michael Grzeschik wrote:
On Tue, Mar 19, 2013 at 09:34:54AM +0800, Peter Chen wrote:
On Mon, Mar 18, 2013 at 03:28:26PM +0100, Michael Grzeschik wrote:
On Fri, Mar 08, 2013 at 05:54:37PM +0200, Alexander Shishkin wrote:
Michael Grzeschik m.grzesc...@pengutronix.de writes:
A static count of transfer descriptors was used everywhere in the
driver
with the fixed number 4. This patch adds a define, named TD_COUNT, and
replaces all users of this value. This way its possible to have only
one
parameter to change and limit the amount of tds per transfer.
I think Svetoslav made exactly the same patch in his patchset, but I
think this patchset will go first.
I did not find any patch comparable by Svetoslav. But, that patch
is superseeded by that hunk in my current branch anyway, as every TD can
maintain five DMA buffers:
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 09bc6ea..c961e3b 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -688,8 +688,8 @@ static int _ep_queue(struct usb_ep *ep, struct
usb_request *req)
goto done;
}
- if (req-length 4 * CI13XXX_PAGE_SIZE) {
- req-length = 4 *
CI13XXX_PAGE_SIZE;
+ if (req-length 5 * CI13XXX_PAGE_SIZE) {
+ req-length = 5 *
CI13XXX_PAGE_SIZE;
retval = -EMSGSIZE;
dev_warn(mEp-ci-dev, request length truncated\n);
}
No, 4 is ok. There are 5 buffer Pointers are dTD, but the Buffer Point 0
may not 4K aligned. Eg, if the reg-length is 18KB, and the buf DMA address
is 1K aligned, it needs two dTDs.
The first dTD only uses: 1KB, 4KB, 4KB, 4KB, 4KB as 5 buffers space.
When the first pointer is not aligned, then all other buffer pointers
will also not be.
Please have a look of dTD descriptor at spec, the pointer 0 can be
not 4k-aligned (the size is address - address 4KB), but other
buffer pointers are 4k-aligned required.
Because the payload will very likeley contiguous.
If the hardware limitation is to have 4K aligned buffer pointers in the
dma addresses, than this fix should be handled different than that.
hardware no 4K aligned buffer limitation.
So this limitation of 4 is a bogus workaround, and my attached hunk is
still valid.
Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Regression] process hangs due to USB: EHCI: work around silicon bug in Intels EHCI controllers
On 03/19/2013 06:03 PM, Andreas Bombe wrote: The named commit (6402c796d3) causes a process to hang indefinitely in usb_kill_urb(). Reverting it fixes the problem. The bug also prevents suspend/shutdown/reboot from completing, presumably due to the hanging process. (Cc'ing Stephen Warren because I only found his report after I bisected it myself. Do you also see a blocked process?) Yes, I believe the symptoms we're both seeing are identical. This is the hanging process on my system: [ 240.364085] INFO: task colord-sane:3619 blocked for more than 120 seconds. ... [ 240.364118] Call Trace: [ 240.364127] [81685af0] schedule+0x65/0x67 [ 240.364132] [8141a235] usb_kill_urb+0xb5/0xd3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] usb: xhci: fix build warning
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: In
function ‘handle_port_status’:
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580:
warning: ‘hcd’ may be used uninitialized in this function
Signed-off-by: Peter Chen peter.c...@freescale.com
---
Changes for v1:
- Put the code which get the hcd together
drivers/usb/host/xhci-ring.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8828754..ec26819 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1599,14 +1599,20 @@ static void handle_port_status(struct xhci_hcd *xhci,
max_ports = HCS_MAX_PORTS(xhci-hcs_params1);
if ((port_id = 0) || (port_id max_ports)) {
xhci_warn(xhci, Invalid port id %d\n, port_id);
- bogus_port_status = true;
- goto cleanup;
+ inc_deq(xhci, xhci-event_ring);
+ return;
}
/* Figure out which usb_hcd this port is attached to:
* is it a USB 3.0 port or a USB 2.0/1.1 port?
*/
major_revision = xhci-port_array[port_id - 1];
+
+ /* Find the right roothub. */
+ hcd = xhci_to_hcd(xhci);
+ if ((major_revision == 0x03) != (hcd-speed == HCD_USB3))
+ hcd = xhci-shared_hcd;
+
if (major_revision == 0) {
xhci_warn(xhci, Event for port %u not in
Extended Capabilities, ignoring.\n,
@@ -1629,10 +1635,6 @@ static void handle_port_status(struct xhci_hcd *xhci,
* into the index into the ports on the correct split roothub, and the
* correct bus_state structure.
*/
- /* Find the right roothub. */
- hcd = xhci_to_hcd(xhci);
- if ((major_revision == 0x03) != (hcd-speed == HCD_USB3))
- hcd = xhci-shared_hcd;
bus_state = xhci-bus_state[hcd_index(hcd)];
if (hcd-speed == HCD_USB3)
port_array = xhci-usb3_ports;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 2/2] usb/acpi: binding xhci root hub usb port with ACPI
On 2013年03月20日 03:06, Sarah Sharp wrote:
Ok, this looks sane, and our Intel testers report it doesn't oops like
v2. The patch description on the first patch is better as well.
Tianyu, I know this introduces a new API to the host controller driver
structure, and we would normally queue these two patches for 3.10.
However, I know a lot of the port power off code went into 3.9. If we
don't have these patches in 3.9, what will be the impact? Will we say,
misassign a power resource from a particular port, or mismark a USB port
connection type? Is there any user-level impact if we don't have these
in 3.9?
If these patches should go into 3.9, should they also be backported to
3.8 and 3.7? Commit d557542421da643358201664903e67fd01dfca1a
usb/acpi: Bind ACPI node to USB port, not usb_device. was first
introduced in 3.7, and it looks like the sysfs files to turn on and off
ports were added in 3.7 as well. Without these two patches, will
that sysfs interface work correctly?
I think there is an impact for usb3.0 paired ports. So it's better to
backport these patchs to 3.7, 3.8, 3.9 if possible. These patches also
depend on the commit 1033f9041d ACPI: Allow ACPI binding with USB-3.0
hub. I'd like to take the job if I could do.
BTW, the sysfs files to turn on and off ports has been reverted by Greg
in v3.7.
Sarah Sharp
On Tue, Mar 19, 2013 at 04:48:13PM +0800, Lan Tianyu wrote:
This patch is to bind xhci root hub usb port with its acpi node.
The port num in the acpi table matches with the sequence in the xhci
extended capabilities table. So call usb_hcd_find_raw_port_number() to
transfer hub port num into raw port number which associates with
the sequence in the xhci extended capabilities table before binding.
Signed-off-by: Lan Tianyu tianyu@intel.com
---
Change since v3:
add a temprorary variable to recard raw port num and get ACPI
handle rahter than overwrite port num with raw port num. This is
to avoid passing raw port num as port num to
usb_acpi_check_port_connect_type().
drivers/usb/core/usb-acpi.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index b6f4bad..255c144 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -15,6 +15,7 @@
#include linux/kernel.h
#include linux/acpi.h
#include linux/pci.h
+#include linux/usb/hcd.h
#include acpi/acpi_bus.h
#include usb.h
@@ -188,8 +189,13 @@ static int usb_acpi_find_device(struct device *dev,
acpi_handle *handle)
* connected to.
*/
if (!udev-parent) {
-*handle = acpi_get_child(DEVICE_ACPI_HANDLE(udev-dev),
+struct usb_hcd *hcd = bus_to_hcd(udev-bus);
+int raw_port_num;
+
+raw_port_num = usb_hcd_find_raw_port_number(hcd,
port_num);
+*handle = acpi_get_child(DEVICE_ACPI_HANDLE(udev-dev),
+raw_port_num);
if (!*handle)
return -ENODEV;
} else {
--
1.7.9.5
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mismatch in TRB_LEN bit mask for Transfer Event TRBs
Hi, On Wed, Mar 20, 2013 at 12:51 AM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Thu, Mar 07, 2013 at 03:38:46PM +0530, Vivek Gautam wrote: Hi Sarah, While going through the code for Handling Transfer Events (drivers/usb/host/xhci-ring.c), i hit upon this problem. As defined in drivers/usb/host/xhci.h /* Normal TRB fields */ /* transfer_len bitmasks - bits 0:16 */ #define TRB_LEN(p) ((p) 0x1) And the same macro i could see being used while Handling Trasfer events handle_tx_event(), and further in process_ctrl_td(), process_isoc_td(), and process_bulk_intr_td(). However, as per XHCI specs (Rev 1.0, 5/21/10) section 6.4.2.1 for Transfer event TRBs, the transfer length is bits 0:23 thereby something like below could be valid: /* Transfer event TRB length bit mask */ /* bits 0:23 */ #defineEVENT_TRB_LEN(p)((p) 0xff) This difference is confusing somewhat. I hope the current code must be pretty much fine, and there could be something that i might be stupidly missing. Nope, you've caught an honest-to-goodness bug. :) Hmm. Would you like to submit a patch to fix this? It should be pretty easy to look at the context in xhci-ring.c and figure out whether the function is queueing a TRB (and thus should use the TRB_LEN macro) or handling a event TRB (and should be using the new EVENT_TRB_LEN macro). Sure, will send a patch for this. Sarah Sharp -- Thanks Regards Vivek -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: core: Use 'unsigned int' for indexes
From: Fabio Estevam fabio.este...@freescale.com
Use 'unsigned int' for indexes, in order to fix the following build warnings
with W=1 option:
drivers/usb/core/usb.c: In function 'usb_find_alt_setting':
drivers/usb/core/usb.c:89:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
drivers/usb/core/usb.c: In function 'usb_altnum_to_altsetting':
drivers/usb/core/usb.c:159:16: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/usb/core/usb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index f81b925..98248d7 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -75,7 +75,7 @@ struct usb_host_interface *usb_find_alt_setting(
unsigned int alt_num)
{
struct usb_interface_cache *intf_cache = NULL;
- int i;
+ unsigned int i;
for (i = 0; i config-desc.bNumInterfaces; i++) {
if (config-intf_cache[i]-altsetting[0].desc.bInterfaceNumber
@@ -154,7 +154,7 @@ struct usb_host_interface *usb_altnum_to_altsetting(
const struct usb_interface *intf,
unsigned int altnum)
{
- int i;
+ unsigned int i;
for (i = 0; i intf-num_altsetting; i++) {
if (intf-altsetting[i].desc.bAlternateSetting == altnum)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb host: Faraday FUSBH200 HCD driver.
On Tue, Mar 19, 2013 at 11:48 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 19 Mar 2013, Yuan-Hsin Chen wrote: What about the port_status registers? They're not between command and async_next. If they aren't consistent with EHCI, it makes things a lot more complicated. fusbh200 has only one port_status register with different offset, 0x30, and the position of some bits are different from EHCI. That's pretty nasty. Integrating that with the standard EHCI driver would be considerably more difficult. Why was the FUSBH200 designed in this strange way? Why doesn't it use the standard EHCI register layout? Were the engineers at Faraday deliberately trying to make life harder for driver writers? Since FUSBH200 was designed more than eight years ago, the engineers responsible for FUSBH200 are no longer working for Faraday. I have the same question as you, but no one here could answer it. The strange register layout and other implementation incompatible with EHCI are the reasons why the FUSBH200 driver was not tried to submit to mainline in the past. Also, usbmode_ex, hostpc, and txfill_tuning other than configured_flag are non-existent in fusbh200. They are used in both ehci-hcd.c and ehci-hub.c for several times. They are used only if the hardware supports them, that is, only if the ehci-has_hostpc flag is set. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
