Re: [PATCH v2 3/4] mfd: dln2: add start/stop RX URBs helpers
On Tue, Dec 16, 2014 at 05:57:14PM +0200, Octavian Purdila wrote:
This is in preparation for adding suspend / resume support.
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/mfd/dln2.c | 51 +--
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index 6d49685..75358d2 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -587,12 +587,19 @@ static void dln2_free_rx_urbs(struct dln2_dev *dln2)
int i;
for (i = 0; i DLN2_MAX_URBS; i++) {
- usb_kill_urb(dln2-rx_urb[i]);
usb_free_urb(dln2-rx_urb[i]);
kfree(dln2-rx_buf[i]);
}
}
+static void dln2_stop_rx_urbs(struct dln2_dev *dln2)
+{
+ int i;
+
+ for (i = 0; i DLN2_MAX_URBS; i++)
+ usb_kill_urb(dln2-rx_urb[i]);
+}
+
static void dln2_free(struct dln2_dev *dln2)
{
dln2_free_rx_urbs(dln2);
@@ -604,9 +611,7 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
struct usb_host_interface *hostif)
{
int i;
- int ret;
const int rx_max_size = DLN2_RX_BUF_SIZE;
- struct device *dev = dln2-interface-dev;
for (i = 0; i DLN2_MAX_URBS; i++) {
dln2-rx_buf[i] = kmalloc(rx_max_size, GFP_KERNEL);
@@ -621,7 +626,19 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
usb_rcvbulkpipe(dln2-usb_dev, dln2-ep_in),
dln2-rx_buf[i], rx_max_size, dln2_rx, dln2);
You should remove this stray newline as well.
- ret = usb_submit_urb(dln2-rx_urb[i], GFP_KERNEL);
+ }
+
+ return 0;
+}
Otherwise,
Reviewed-by: Johan Hovold jo...@kernel.org
Johan
--
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 4/4] mfd: dln2: add suspend/resume functionality
On Tue, Dec 16, 2014 at 05:57:15PM +0200, Octavian Purdila wrote: Without suspend/resume functionality in the USB driver the USB core will disconnect and reconnect the DLN2 port and because the GPIO framework does not yet support removal of an in-use controller a suspend/resume operation will result in a crash. This patch provides suspend and resume functions for the DLN2 driver so that the above scenario is avoided. Signed-off-by: Octavian Purdila octavian.purd...@intel.com This patch looks good now, but how did you say this device was powered? If powered by vbus you cannot assume that the device maintains it's state over a suspend cycle, something which would complicate matters quite a bit... Thanks, Johan -- 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] x86: Added support for Japanese Surface Type Cover 3
On Tue, 6 Jan 2015, Alan Wu wrote: Based on code for the US Surface Type Cover 3 from commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0 (HID: add support for MS Surface Pro 3 Type Cover): Applied, thanks. -- 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] USB: qcserial/option: make AT URCs work for Sierra Wireless MC73xx
On Tue, Jan 06, 2015 at 10:06:38PM +0100, Reinhard Speyerer wrote: As has been discussed in the thread starting with https://lkml.kernel.org/g/549748e9.d+sijzqu50f1r4lsal043...@arcor.de Sierra Wireless MC73xx devices with USB VID/PID 0x1199:0x68c0 require the option_send_setup() code to be used on the USB interface for the AT port to make unsolicited response codes work correctly. Move these devices from the qcserial driver where they have been added by commit 70a3615fc07c2330ed7c1e922f3c44f4a67c0762 (usb: qcserial: add Sierra Wireless MC73xx) to the option driver and add a MC73xx-specific blacklist to ensure that 1. the sendsetup code is not used for the DIAG/DM and NMEA interfaces 2. the option driver does not attach to the QMI/network interfaces Signed-off-by: Reinhard Speyerer rs...@arcor.de Applied, thanks. Johan -- 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 1/4] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Tue, Dec 16, 2014 at 4:57 PM, Octavian Purdila octavian.purd...@intel.com wrote: As noticed during suspend/resume operations, the IRQ can be unmasked then disabled in suspend and eventually enabled in resume, but without being unmasked. The current implementation does not take into account interactions between mask/unmask and enable/disable interrupts, and thus in the above scenarios the IRQs remain unactive. To fix this we removed the enable/disable operations as they fallback to mask/unmask anyway. We also remove the pending bitmaks as it is already done in irq_data (i.e. IRQS_PENDING). Signed-off-by: Octavian Purdila octavian.purd...@intel.com This patch applied for fixes. Yours, Linus Walleij -- 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] snd-usb-audio: Add support for Akai MPC Element MIDI controller
Paul Bonser wrote:
On 01/06/2015 07:39 AM, Clemens Ladisch wrote:
Paul Bonser wrote:
This device incorrectly reports its bInterfaceClass as 255, when it
should really be 1 (USB_CLASS_AUDIO).
+++ b/sound/usb/quirks-table.h
+{
+ /* Akai MPC Element */
+ USB_DEVICE(0x09e8, 0x0021),
+ .bInterfaceClass = USB_CLASS_AUDIO,
+},
This is not a correct usb_device_id entry.
I based it on an existing entry in the same file:
/* KeithMcMillen Stringport */
{
USB_DEVICE(0x1f38, 0x0001),
.bInterfaceClass = USB_CLASS_AUDIO,
},
It built with no complaints and functioned as expected (showed up as a
MIDI device and sent/recived commands via ALSA MIDI whereas before it
didn't).
The bInterfaceClass value has no effect; these entries happen to work
only by chance.
All entries are supposed to define some quirk(s), like this:
{
/* Akai MPC Element */
USB_DEVICE(0x09e8, 0x0021),
.driver_info = (unsigned long) (const struct snd_usb_audio_quirk) {
.ifnum = 1,
.type = QUIRK_MIDI_STANDARD_INTERFACE
}
},
I should have sent he email to you (since you're the USB MIDI
maintainer), and CCd the linux-ker...@vger.kernel.org and
linux-usb@vger.kernel.org lists?
The only matching entry for sound/usb/quirks-table.h in the MAINTAINERS
file tells you to send to perex, tiwai, and alsa-devel.
Once we've worked out the proper format for this entry, should I re-send
it following that pattern?
Yes.
Regards,
Clemens
--
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 2/2 resend v2] USB: host: Introduce flag to enable use of 64-bit dma_mask for ehci-platform
On Tue, Jan 06, 2015 at 10:49:40AM -0500, Alan Stern wrote: On Tue, 6 Jan 2015, Andreas Herrmann wrote: ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon and usage of ehci-platform ehci dma_mask is now limited to 32 bits (coerced in ehci_platform_probe). Provide a flag in ehci platform data to allow use of 64 bits for dma_mask. Cc: David Daney david.da...@cavium.com Cc: Alex Smith alex.sm...@imgtec.com Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Andreas Herrmann andreas.herrm...@caviumnetworks.com Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Alan Stern st...@rowland.harvard.edu Is something like this also needed for ohci-platform? No, I don't think so. Or are all OHCI implementations restricted to 32-bit DMA masks? AFAIK OHCI supports only 32-bit memory addressing. Alan Stern Andreas -- 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/3] scsi: add ability to adjust module reference for scsi host
While accessing a scsi_device, the use count of the underlying LLDD module
is incremented. The module reference is retrieved through .module field of
struct scsi_host_template.
This mapping between scsi_device and underlying LLDD module works well
except some scsi drivers (ufs and unusual usb storage drivers). These
drivers consist with core driver and actual LLDDs, and scsi_host_template
is defined in the core driver. So the actual LLDDs can be unloaded even if
the scsi_device is being accessed.
This adds .module field in struct Scsi_Host and let the module reference
be retrieved though it instead of struct scsi_host_template. This allows
the actual LLDDs adjust module reference.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: Vinayak Holikatti vinholika...@gmail.com
Cc: Dolev Raviv dra...@codeaurora.org
Cc: Sujit Reddy Thumma sthu...@codeaurora.org
Cc: Subhash Jadavani subha...@codeaurora.org
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Matthew Dharm mdharm-...@one-eyed-alien.net
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
Cc: usb-stor...@lists.one-eyed-alien.net
Cc: linux-s...@vger.kernel.org
---
No change from v1
drivers/scsi/hosts.c | 1 +
drivers/scsi/scsi.c | 4 ++--
include/scsi/scsi_host.h | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 8bb173e..21f1442 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -411,6 +411,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template
*sht, int privsize)
*/
shost-max_cmd_len = 12;
shost-hostt = sht;
+ shost-module = sht-module;
shost-this_id = sht-this_id;
shost-can_queue = sht-can_queue;
shost-sg_tablesize = sht-sg_tablesize;
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index e028854..5905b83 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -988,7 +988,7 @@ int scsi_device_get(struct scsi_device *sdev)
return -ENXIO;
/* We can fail this if we're doing SCSI operations
* from module exit (like cache flush) */
- try_module_get(sdev-host-hostt-module);
+ try_module_get(sdev-host-module);
return 0;
}
@@ -1005,7 +1005,7 @@ EXPORT_SYMBOL(scsi_device_get);
void scsi_device_put(struct scsi_device *sdev)
{
#ifdef CONFIG_MODULE_UNLOAD
- struct module *module = sdev-host-hostt-module;
+ struct module *module = sdev-host-module;
/* The module refcount will be zero if scsi_device_get()
* was called from a module removal routine */
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 019e668..5133f2f 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -617,6 +617,7 @@ struct Scsi_Host {
*/
unsigned short max_cmd_len;
+ struct module *module;
int this_id;
int can_queue;
short cmd_per_lun;
--
1.9.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
[PATCH v2 0/3] scsi: ufs ums-*: fix module reference counting
While accessing a scsi_device, the use count of the underlying LLDD module is incremented. The module reference is retrieved through .module field of struct scsi_host_template. This mapping between scsi_device and underlying LLDD module works well except some scsi drivers (ufs and unusual usb storage drivers). These drivers consist with core driver and actual LLDDs, and scsi_host_template is defined in the core driver. So the actual LLDDs can be unloaded even if the scsi_device is being accessed. This patch series first adds ability to adjust module reference for scsi host by LLDDs and then fixes ufs and unusual usb storage drivers by adjusting module reference after scsi host allocation. * v2: - Pass correct module reference to usb_stor_probe1() instead of touching all ums-* drivers, suggested by Alan Stern Akinobu Mita (3): scsi: add ability to adjust module reference for scsi host scsi: ufs: adjust module reference for scsi host usb: storage: adjust module reference for scsi host drivers/scsi/hosts.c | 1 + drivers/scsi/scsi.c | 4 ++-- drivers/scsi/ufs/ufshcd-pci.c| 1 + drivers/scsi/ufs/ufshcd-pltfrm.c | 1 + drivers/scsi/ufs/ufshcd.c| 1 - drivers/usb/storage/usb.c| 8 +--- drivers/usb/storage/usb.h| 7 +-- include/scsi/scsi_host.h | 1 + 8 files changed, 16 insertions(+), 8 deletions(-) Cc: Vinayak Holikatti vinholika...@gmail.com Cc: Dolev Raviv dra...@codeaurora.org Cc: Sujit Reddy Thumma sthu...@codeaurora.org Cc: Subhash Jadavani subha...@codeaurora.org Cc: Christoph Hellwig h...@lst.de Cc: James E.J. Bottomley jbottom...@parallels.com Cc: Matthew Dharm mdharm-...@one-eyed-alien.net Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-usb@vger.kernel.org Cc: usb-stor...@lists.one-eyed-alien.net Cc: linux-s...@vger.kernel.org -- 1.9.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: [Bug 90941] xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
Hello Gurus, See message of dmesg: [ 5136.529349] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. [ 5136.529351] usb 1-1: hub failed to enable device, error -22 [ 5136.788988] usb 1-1: reset low-speed USB device number 2 using xhci_hcd [ 5136.789008] xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. [ 5136.789011] usb 1-1: hub failed to enable device, error -22 https://bugzilla.kernel.org/show_bug.cgi?id=90941 Many thanks for you work, -- Cristian -- 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 0/5] usb: atmel_usba_udc: Rework errata handling
Hi, The whole series looks good to me, you can add my Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com On 06/01/2015 at 14:46:57 +0100, Boris Brezillon wrote : Hello, Here is a set of patches porting existing at91sam9rl erratum handling to DT and adding new code to handle at91sam9g45/9x5 erratum. It also adds several compatible strings to differentiate those errata. These patches should be backported to 3.17 and 3.18 stable releases but they do not apply cleanly on those stable branches. I'll send a backport of this series once it is merged in mainline. Regards, Boris Changes since v1: - cache INT_ENB value to speedup INT_ENB read operations Boris Brezillon (5): usb: atmel_usba_udc: Rework at91sam9rl errata handling usb: atmel_usba_udc: Add at91sam9g45 and at91sam9x5 errata handling ARM: at91/dt: update udc compatible strings usb: atmel_usba_udc: Mask status with enabled irqs usb: gadget: atmel_usba: Cache INT_ENB register value .../devicetree/bindings/usb/atmel-usb.txt | 5 +- arch/arm/boot/dts/at91sam9g45.dtsi | 2 +- arch/arm/boot/dts/at91sam9x5.dtsi | 2 +- arch/arm/boot/dts/sama5d3.dtsi | 2 +- arch/arm/boot/dts/sama5d4.dtsi | 2 +- drivers/usb/gadget/udc/atmel_usba_udc.c| 146 + drivers/usb/gadget/udc/atmel_usba_udc.h| 9 ++ 7 files changed, 111 insertions(+), 57 deletions(-) -- 1.9.1 -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 3.0 storage keep reconnecting after safely removed
Hi, On 07-01-15 16:19, Alan Stern wrote: On Tue, 6 Jan 2015, Taegil Bae wrote: Hi all, Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90791 My machine is Thinkpad Yoga with Onelink dock attached. Onelink dock is a USB 3.0 dock functioning as a USB 3.0 hub. This has two USB 3.0 ports in front. I connected a USB HDD enclosure to one of those ports. After use, I safely removed the storage device. But immediately that storage is connected. There is no such issue for laptop body's USB 3.0 ports or Onelink dock's USB 2.0 ports. I've tested in GNOME GUI and i3 CUI environment. In GNOME, I used gnome-disk utility. In i3, I echo'ed 1 to that USB 3.0 enclosure device's sysfs entry 'remove'. There is no difference. Using Onelink dock's USB 3.0 port: 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: logical disconnect -- safely remove 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg 0010 evt 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: status 02b0, change , 5.0 Gb/s 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: USB disconnect, device number 4 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: unregistering device 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg evt 0010 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: reset change 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: warm reset change 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: status 0203, change 0031, 5.0 Gb/s 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: debounce total 100ms stable 100ms status 0x203 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: new SuperSpeed USB device number 5 using xhci_hcd -- reconnecting 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: udev 5, busnum 3, minor = 260 1월 05 22:25:51 rapunzel kernel: usb-storage 3-3.4:1.0: USB Mass Storage device detected 1월 05 22:25:51 rapunzel kernel: scsi host5: usb-storage 3-3.4:1.0 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg evt 0010 1월 05 22:25:52 rapunzel kernel: scsi 5:0:0:0: Direct-Access Corsair Force 3 SSD 5.07 PQ: 0 ANSI: 0 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/111 GiB) 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Write Protect is off 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Mode Sense: 03 00 00 00 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] No Caching mode page found 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through 1월 05 22:25:52 rapunzel kernel: sdb: unknown partition table 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Attached SCSI disk 1월 05 22:25:53 rapunzel kernel: BTRFS info (device sdb): disk space caching is enabled 1월 05 22:25:53 rapunzel kernel: BTRFS: bdev /dev/sdb errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 Clearly there's a bug in the SuperSpeed port-state logic in the hub driver. Perhaps Hans can help fix the problems. If not, Mathias (the xhci-hcd maintainer) may look at this after he gets back from vacation. I'm afraid that I already have too much work on my plate, and that I'm not 100% into the code in question, so this will have to wait till Mathias is back. Regards, Hans -- 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: kernel panic with USB3+DVB+ARM
On 06.01.2015 22:00, JPT wrote:
Am 06.01.2015 um 18:38 schrieb Greg KH:
On Tue, Jan 06, 2015 at 11:47:29AM +0100, JPT wrote:
Hi Greg
Am 06.01.2015 um 02:54 schrieb Greg KH:
Is that where the kernel panics show the problem happens? Without them,
there's nothing we can do to help out except randomly guess, sorry.
well. at least xhci is contained in the call stack:
[c02fc948] (crc32_be) from [bf01dbc8] (dvb_dmx_crc32+0x10/0x18
[dvb_core])
[bf01dbc8] (dvb_dmx_crc32 [dvb_core]) from [bf01c7ec]
(dvb_dmx_swfilter_section_copy_dump+0x254/0x268 [dvb_core])
[bf01c7ec] (dvb_dmx_swfilter_section_copy_dump [dvb_core]) from
[bf01cef4] (dvb_dmx_swfilter_packet+0x45c/0x564 [dvb_core])
[bf01cef4] (dvb_dmx_swfilter_packet [dvb_core]) from [bf01d14c]
(dvb_dmx_swfilter+0xf4/0x164 [dvb_core])
[bf01d14c] (dvb_dmx_swfilter [dvb_core]) from [bf03bebc]
(usb_urb_complete+0xbc/0xe4 [dvb_usb])
[bf03bebc] (usb_urb_complete [dvb_usb]) from [c0401e44]
(__usb_hcd_giveback_urb+0x5c/0xe8)
[c0401e44] (__usb_hcd_giveback_urb) from [c042a8d0]
(xhci_irq+0x8d8/0x1e08)
[c042a8d0] (xhci_irq) from [c0048f40]
(handle_irq_event_percpu+0x78/0x140)
[c0048f40] (handle_irq_event_percpu) from [c0049030]
(handle_irq_event+0x28/0x38)
[c0049030] (handle_irq_event) from [c004b1d8]
(handle_simple_irq+0x64/0xa8)
[c004b1d8] (handle_simple_irq) from [c004886c]
(generic_handle_irq+0x2c/0x3c)
[c004886c] (generic_handle_irq) from [c000f608] (handle_IRQ+0x38/0x84)
[c000f608] (handle_IRQ) from [c030bba0]
(armada_370_xp_handle_msi_irq+0x9c/0xa0)
[c030bba0] (armada_370_xp_handle_msi_irq) from [c00084f0]
(armada_370_xp_handle_irq+0x5c/0x60)
[c00084f0] (armada_370_xp_handle_irq) from [c00126c0]
(__irq_svc+0x40/0x54)
It's always the same stack, but different errors:
kernelpanic0.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948
kernelpanic0.log: Internal error: : 409 [#1] ARM
kernelpanic1.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948
kernelpanic1.log: Internal error: : 409 [#1] ARM
kernelpanic2.log: Internal error: Oops: 815 [#1] ARM
kernelpanic3.log: Unhandled prefetch abort: unknown 25 (0x409) at 0xc0301228
kernelpanic3.log: Internal error: : 409 [#1] ARM
kernelpanic4.log: Unhandled prefetch abort: unknown 0 (0x000) at 0xc0301228
kernelpanic4.log: Internal error: : 0 [#1] ARM
I added a printk to dvb_dmx_crc32() (see dvb.log). This probably
introduced more problems, because irq code has to be fast?
During recording through USB2 this code made the system not crash but it
wasn't able to answer any request (SSH, HTTP, login from serial console ...)
Is this info useful?
I attached only one of the kernel panic logs. If you would like to see
the others, please tell me.
I am not sure if the dvb.log tells something of worth at all.
Jan
[ 57.646235] dvb_dmx_crc32(dvb_demux_feed e0d4b13c, src: e0d4b154, len 18
[ 57.688218] dvb_dmx_crc32(dvb_demux_feed e0d4d3b4, src: e0d4d3cc, len 97
[ 57.695163] dvb_dmx_crc32(dvb_demux_feed e0d4a000, src: e0d4a018, len 28
[ 57.702105] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
probably busted
[ 57.709920] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
probably busted
[ 57.717924] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
probably busted
[ 57.725728] xhci_hcd :01:00.0: ERROR Unknown event condition, HC
probably busted
Those messages look kind of important, right? :)
well yes. But I think I did not have them without the printk in
dvb_dmx_crc32().
Perhaps something is wrong with your hardware, you are using the 3.17
kernel release, does this also happen on 3.18?
yes, the captured logs are from:
kernelpanic0.log: 3.17.2-rn104-jpt9
kernelpanic1.log: 3.17.2-rn104-jpt10
kernelpanic2.log: 3.17.2-rn104-jpt10
kernelpanic3.log: 3.18.1-rn104-jpt1
kernelpanic4.log: 3.18.1-rn104-jpt1
Do you have any xhci
patches in your tree for this specific ARM hardware?
No. Not any.
Only patch is
.isoc = {
- .framesperurb = 32,
+ .framesperurb = 8,
.framesize = 2048,
.interval = 1,
}
in drivers/media/usb/dvb-usb/technisat-usb2.c
because else the driver would not have worked because of some
out-of-memory problems. Did not really understand. (where are those
buffers located?)
Unhandled prefetch abort: unknown 25 (0x409) at 0xc02fc948
Internal error: : 409 [#1] ARM
I don't know enough about arm, but this looks like some odd hardware
issue, and not a normal kernel oops report, right?
Well, I don't know. If you say so...
My knowledge dates back to MSDOS and ralph brown's interrupt list ;)
Haven't got any idea about how USB works, nor kernel panics/oops
I don't expect this code to be thoroughly tested on an arm system.
(especially DVB)
So the stack trace doesn't tell you anything useful?!
Is there anything else I can do to find out more?
Do you see the same issues with a 3.19
Re: [PATCH v2 4/4] mfd: dln2: add suspend/resume functionality
On Wed, Jan 7, 2015 at 11:26 PM, Johan Hovold jo...@kernel.org wrote: On Tue, Dec 16, 2014 at 05:57:15PM +0200, Octavian Purdila wrote: Without suspend/resume functionality in the USB driver the USB core will disconnect and reconnect the DLN2 port and because the GPIO framework does not yet support removal of an in-use controller a suspend/resume operation will result in a crash. This patch provides suspend and resume functions for the DLN2 driver so that the above scenario is avoided. Signed-off-by: Octavian Purdila octavian.purd...@intel.com This patch looks good now, but how did you say this device was powered? If powered by vbus you cannot assume that the device maintains it's state over a suspend cycle, something which would complicate matters quite a bit... Yes, the device is powered by VBUS. During my tests, depending on the host and USB port, VBUS is sometimes preserved - and this is the case this patch addresses, and sometimes is not, but in that case because no reset_resume routine is implemented the resume path will go through the disconnect/reconnect process. This second case is not addressed by the patch, as I think in this second case fixing the GPIO framework to support the removal of an in-use device is the best way to go. -- 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 4/4] mfd: dln2: add suspend/resume functionality
On Thu, Jan 08, 2015 at 02:16:15AM +1300, Octavian Purdila wrote: On Wed, Jan 7, 2015 at 11:26 PM, Johan Hovold jo...@kernel.org wrote: On Tue, Dec 16, 2014 at 05:57:15PM +0200, Octavian Purdila wrote: Without suspend/resume functionality in the USB driver the USB core will disconnect and reconnect the DLN2 port and because the GPIO framework does not yet support removal of an in-use controller a suspend/resume operation will result in a crash. This patch provides suspend and resume functions for the DLN2 driver so that the above scenario is avoided. Signed-off-by: Octavian Purdila octavian.purd...@intel.com This patch looks good now, but how did you say this device was powered? If powered by vbus you cannot assume that the device maintains it's state over a suspend cycle, something which would complicate matters quite a bit... Yes, the device is powered by VBUS. During my tests, depending on the host and USB port, VBUS is sometimes preserved - and this is the case this patch addresses, and sometimes is not, but in that case because no reset_resume routine is implemented the resume path will go through the disconnect/reconnect process. Yes, it depends on the host controller and I believe the common case is to drop VBUS. This second case is not addressed by the patch, as I think in this second case fixing the GPIO framework to support the removal of an in-use device is the best way to go. I agree. But please do mention that this case is not handled in the commit message. Thanks, Johan -- 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: [xhci_hcd] USB3 device unplug breaks system suspend
On Tue, 6 Jan 2015, Tobias Jakobi wrote: Just a short note that the issue remains with vanilla 3.18.1. It won't go away until somebody fixes it. You should bring this to the attention of the xhci-hcd maintainer after he returns from vacation. 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: Difference between run time and normal suspend
On Wed, 7 Jan 2015, vichy wrote: I attach usbmon for your reference. But keyboard is still not working on runtime suspend. The usbmon trace resembles what I got during a test some time ago. I don't remember the details; the problem was related to the fact that the keyboard had two HID interfaces. One of them was suspending okay but the other one wasn't, and that prevented the entire keyboard from going into runtime suspend. The same thing is happening to you. The problem turned out to be something like the LED settings. Does the keyboard go into runtime suspend if you turn off all the LEDs (Caps Lock, Num Lock, and so on)? Or if you turn on the ignoreled module parameter for usbhid? An illuminated LED requires more current than a suspended device is allowed to draw from the USB bus. Therefore a bus-powered keyboard cannot be put into runtime suspend if any of its LEDs is turned on. 3. for host part, runtime suspend/resume is only doing port suspend/resume or both host and port going to suspend/resume? Only the port. However, when _all_ the devices attached to the host controlluer go into runtime suspend, the controller itself will also be put into runtime suspend. Would you mind to show me where the program determine controller go into runtime suspend if all devices on it go to suspend? That is handled by the runtime PM core. Look for the comment line: /* Maybe the parent is now able to suspend. */ in rpm_suspend() in drivers/base/power/runtime.c. BTW a. if even controller suspended, does that mean all devices on it will be disconnect and re-enumerated when resume? No. When the controller resumes, the devices should still be connected to it. b. is there any usb sysfs file can let us suspend specific port on root or normal hub? No, there's only the .../power/control file. 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 v2 00/30] usb: updates for dwc2 gadget driver
On 01/07/2015 09:34 AM, Kaukab, Yousaf wrote: Hi, -Original Message- From: Dinh Nguyen [mailto:dingu...@opensource.altera.com] Sent: Wednesday, January 7, 2015 1:01 AM To: Paul Zimmerman; Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; sergei.shtyl...@cogentembedded.com; r.bald...@samsung.com Subject: Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver On 01/06/2015 05:47 PM, Dinh Nguyen wrote: On 01/05/2015 01:16 PM, Paul Zimmerman wrote: Adding Dinh to CC. Robert, Dinh, I would like to have your tested-bys for this series, please. This patch series is producing this error on the SOCFPGA platform. I'll try to bisect to a specific patch. root@socfpga_cyclone5:~# [ 47.929743] dwc2 ffb4.usb: new device is low-speed [ 63.873596] dwc2 ffb4.usb: new device is low-speed [ 64.219220] dwc2 ffb4.usb: new device is low-speed [ 64.421495] dwc2 ffb4.usb: new device is low-speed [ 64.834505] dwc2 ffb4.usb: new device is high-speed [ 69.899695] [ cut here ] [ 69.904315] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:1352 s3c_hsotg_rx_data+0xc0/0xd4() [ 69.913230] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite [ 69.920385] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc1-00090-g4864f14 #4 [ 69.927917] Hardware name: Altera SOCFPGA [ 69.931936] [c0014d24] (unwind_backtrace) from [c001173c] (show_stack+0x10/0x14) [ 69.939654] [c001173c] (show_stack) from [c0461c74] (dump_stack+0x74/0x90) [ 69.946857] [c0461c74] (dump_stack) from [c0021138] (warn_slowpath_common+0x78/0xb4) [ 69.954916] [c0021138] (warn_slowpath_common) from [c0021190] (warn_slowpath_null+0x1c/0x24) [ 69.963669] [c0021190] (warn_slowpath_null) from [c030278c] (s3c_hsotg_rx_data+0xc0/0xd4) [ 69.972162] [c030278c] (s3c_hsotg_rx_data) from [c0304ac0] (s3c_hsotg_irq+0x454/0x520) [ 69.980394] [c0304ac0] (s3c_hsotg_irq) from [c0058c3c] (handle_irq_event_percpu+0x5c/0x1f4) [ 69.989056] [c0058c3c] (handle_irq_event_percpu) from [c0058e18] (handle_irq_event+0x44/0x64) [ 69.997892] [c0058e18] (handle_irq_event) from [c005b8d8] (handle_fasteoi_irq+0xa8/0x180) [ 70.006382] [c005b8d8] (handle_fasteoi_irq) from [c005856c] (generic_handle_irq+0x20/0x30) [ 70.014958] [c005856c] (generic_handle_irq) from [c0058668] (__handle_domain_irq+0x54/0xb4) [ 70.023619] [c0058668] (__handle_domain_irq) from [c0008638] (gic_handle_irq+0x20/0x5c) [ 70.031937] [c0008638] (gic_handle_irq) from [c0012240] (__irq_svc+0x40/0x54) [ 70.039384] Exception stack(0xc0635f60 to 0xc0635fa8) [ 70.044415] 5f60: c0635fb0 c001cee0 c066cca0 c063c498 c046908c c066c4b2 [ 70.052556] 5f80: c066cca0 0001 ef7fccc0 0100 c0635fa8 c000f0fc c000f100 [ 70.060694] 5fa0: 600f0013 [ 70.064174] [c0012240] (__irq_svc) from [c000f100] (arch_cpu_idle+0x30/0x3c) [ 70.071545] [c000f100] (arch_cpu_idle) from [c0050364] (cpu_startup_entry+0x138/0x224) [ 70.079783] [c0050364] (cpu_startup_entry) from [c05ebbb0] (start_kernel+0x304/0x35c) [ 70.087921] ---[ end trace 66b76f6dcbbda3bf ]--- [ 79.911589] dwc2 ffb4.usb: new device is low-speed Dinh It looks like this patch is producing the above error. usb: dwc2: gadget: manage ep0 state in software Manage ep0 state in software to add handling of status OUT stage. Just toggling hsotg-setup in s3c_hsotg_handle_outdone leaves it in wrong state in 2-stage control transfers. Moreover, don't call s3c_hsotg_handle_outdone both from SetupDone and OutDone. Only use one of them, as for a setup packet we get both. Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com Thank you for testing this patchset. I have tested g_mass_storage without dma in my setup and it is working fine. Did you also test with DMA enabled? As I don't see this problem, I need some help in figuring out what's going on. Would it be possible for you to provide me following? 1) Console output after enabling CONFIG_USB_DWC2_DEBUG 2) Function trace echo s3c_* /sys/kernel/debug/tracing/set_ftrace_filter echo function /sys/kernel/debug/tracing/current_tracer 3) Values of following registers GSNPSID, GHWCFG1-GHWCFG4 I'll try to get these out for your shortly. Dinh -- 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 3/3] usb: storage: adjust module reference for scsi host
On Wed, 7 Jan 2015, Akinobu Mita wrote: While accessing a unusual usb storage (ums-alauda, ums-cypress, ...), the module reference count is not incremented. Because these drivers allocate scsi hosts with usb_stor_host_template defined in usb-storage module. So these drivers always can be unloaded. This fixes it by passing correct module reference to usb_stor_probe1() to adjust it after scsi host allocation. Signed-off-by: Akinobu Mita akinobu.m...@gmail.com Cc: Matthew Dharm mdharm-...@one-eyed-alien.net Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Alan Stern st...@rowland.harvard.edu Cc: Christoph Hellwig h...@lst.de Cc: James E.J. Bottomley jbottom...@parallels.com Cc: linux-usb@vger.kernel.org Cc: usb-stor...@lists.one-eyed-alien.net Cc: linux-s...@vger.kernel.org --- * v2: - Pass correct module reference to usb_stor_probe1() instead of touching all ums-* drivers, suggested by Alan Stern Acked-by: Alan Stern st...@rowland.harvard.edu -- 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 0/3] scsi: ufs ums-*: fix module reference counting
On Wed, 7 Jan 2015, Christoph Hellwig wrote: On Wed, Jan 07, 2015 at 11:02:59PM +0900, Akinobu Mita wrote: While accessing a scsi_device, the use count of the underlying LLDD module is incremented. The module reference is retrieved through .module field of struct scsi_host_template. This mapping between scsi_device and underlying LLDD module works well except some scsi drivers (ufs and unusual usb storage drivers). These drivers consist with core driver and actual LLDDs, and scsi_host_template is defined in the core driver. So the actual LLDDs can be unloaded even if the scsi_device is being accessed. Why don't ufs and usb-storage define the host templates in the sub drivers? That's what libata or the mpt fusion driver do. Originally the subdrivers were all part of usb-storage. When they were split out into separate modules, there didn't seem to be any need to copy the host template into each one. (Especially since some of the method pointers in the host template refer to routines in usb-storage itself, not in the subdrivers.) The fact that the .module member was no longer adequate escaped our notice at the 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: USB 3.0 storage keep reconnecting after safely removed
On Tue, 6 Jan 2015, Taegil Bae wrote: Hi all, Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90791 My machine is Thinkpad Yoga with Onelink dock attached. Onelink dock is a USB 3.0 dock functioning as a USB 3.0 hub. This has two USB 3.0 ports in front. I connected a USB HDD enclosure to one of those ports. After use, I safely removed the storage device. But immediately that storage is connected. There is no such issue for laptop body's USB 3.0 ports or Onelink dock's USB 2.0 ports. I've tested in GNOME GUI and i3 CUI environment. In GNOME, I used gnome-disk utility. In i3, I echo'ed 1 to that USB 3.0 enclosure device's sysfs entry 'remove'. There is no difference. Using Onelink dock's USB 3.0 port: 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: logical disconnect -- safely remove 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg 0010 evt 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: status 02b0, change , 5.0 Gb/s 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: USB disconnect, device number 4 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: unregistering device 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg evt 0010 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: reset change 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: warm reset change 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: status 0203, change 0031, 5.0 Gb/s 1월 05 22:25:51 rapunzel kernel: usb 3-3-port4: debounce total 100ms stable 100ms status 0x203 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: new SuperSpeed USB device number 5 using xhci_hcd -- reconnecting 1월 05 22:25:51 rapunzel kernel: usb 3-3.4: udev 5, busnum 3, minor = 260 1월 05 22:25:51 rapunzel kernel: usb-storage 3-3.4:1.0: USB Mass Storage device detected 1월 05 22:25:51 rapunzel kernel: scsi host5: usb-storage 3-3.4:1.0 1월 05 22:25:51 rapunzel kernel: hub 3-3:1.0: state 7 ports 4 chg evt 0010 1월 05 22:25:52 rapunzel kernel: scsi 5:0:0:0: Direct-Access Corsair Force 3 SSD 5.07 PQ: 0 ANSI: 0 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] 234441648 512-byte logical blocks: (120 GB/111 GiB) 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Write Protect is off 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Mode Sense: 03 00 00 00 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] No Caching mode page found 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Assuming drive cache: write through 1월 05 22:25:52 rapunzel kernel: sdb: unknown partition table 1월 05 22:25:52 rapunzel kernel: sd 5:0:0:0: [sdb] Attached SCSI disk 1월 05 22:25:53 rapunzel kernel: BTRFS info (device sdb): disk space caching is enabled 1월 05 22:25:53 rapunzel kernel: BTRFS: bdev /dev/sdb errs: wr 0, rd 1, flush 0, corrupt 0, gen 0 Clearly there's a bug in the SuperSpeed port-state logic in the hub driver. Perhaps Hans can help fix the problems. If not, Mathias (the xhci-hcd maintainer) may look at this after he gets back from vacation. 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: Lockdep problem: v3.18+ (with yesterday's Linus tip - 6f51ee709e4c)
On Thu, 18 Dec 2014, Greg Kroah-Hartman wrote:
On Thu, Dec 18, 2014 at 02:40:48PM -0500, Alan Stern wrote:
On Thu, 18 Dec 2014, Russell King - ARM Linux wrote:
While unplugging a Logitek Keyboard/mouse micro-receiver, I got the
lockdep splat below.
However, I don't fully understand this splat - I see nothing in
flush_work() nor process_one_work() making use of intf-reset_ws -
which seems to be a USB thing. I guess lockdep is being re-used to
validate work stuff, and lock is just plain misleading.
That sounds right. intf-reset_ws is a work_struct for a reset
request.
usb 2-1.1: USB disconnect, device number 3
=
[ INFO: possible recursive locking detected ]
3.18.0+ #1459 Not tainted
-
kworker/0:1/2758 is trying to acquire lock:
((intf-reset_ws)){+.+.+.}, at: [c003ba90] flush_work+0x0/0x264
but task is already holding lock:
((intf-reset_ws)){+.+.+.}, at: [c003ca40]
process_one_work+0x130/0x4b4
I think what happened is that we called cancel_work_sync() for the
reset_ws embedded in one intf structure while running in the workqueue
routine for the reset_ws embedded in a different intf structure.
Assuming this interpretation is correct, I don't see how we can prevent
lockdep from making this mistake. Here's the problem:
An interface driver can queue a request for a reset.
A reset can cause interface drivers to be unbound from their
interfaces.
If an interface driver is unbound, any pending reset request
that it queued has to be cancelled. Otherwise the workqueue
would most likely end up carrying out the reset at a later time
when nobody wants it.
(The code contains explicit protection for the case where the interface
being unbound is the one whose reset request is currently in progress.)
Now perhaps we don't need that last step. We could allow a queued
reset to take place even after the driver that requested it is gone.
Most of the time these reset requests occur in response to I/O errors
when a USB device is unplugged -- as happened in this example -- in
which case it doesn't matter what we do.
So even though it's not entirely pleasant, my inclination is to solve
the problem by getting rid of usb_cancel_queued_reset() in
drivers/usb/core/driver.c.
Comments, anybody?
That seems reasonable to me, unbinding when a reset is happening is
going to be a rare condition, but if we get rid of it, and we try to
queue a reset for a device that is gone, we will just fail the reset,
right? If all should be fine, I have no objection to removing it.
Russell, can you reproduce that lockdep violation whenever you want?
If you can, does the following patch help?
Alan Stern
-
The USB stack provides a mechanism for drivers to request an
asynchronous device reset (usb_queue_reset_device()). The mechanism
uses a work item (reset_ws) embedded in the usb_interface structure
used by the driver, and the reset is carried out by a work queue
routine.
The asynchronous reset can race with driver unbinding. When this
happens, we try to cancel the queued reset before unbinding the
driver, on the theory that the driver won't care about any resets once
it is unbound.
However, thanks to the fact that lockdep now tracks work queue
accesses, this can provoke a lockdep warning in situations where the
device reset causes another interface's driver to be unbound; see
http://marc.info/?l=linux-usbm=141893165203776w=2
for an example. The reason is that the work routine for reset_ws in
one interface calls cancel_queued_work() for the reset_ws in another
interface. Lockdep thinks this might lead to a work routine trying to
cancel itself. The simplest solution is not to cancel queued resets
when unbinding drivers.
This means we now need to acquire a reference to the usb_interface
when queuing a reset_ws work item and to drop the reference when the
work routine finishes. We also need to make sure that the
usb_interface structure doesn't outlive its parent usb_device; this
means acquiring and dropping a reference when the interface is created
and destroyed.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Reported-by: Russell King - ARM Linux li...@arm.linux.org.uk
---
drivers/usb/core/driver.c | 17 -
drivers/usb/core/hub.c | 25 +
drivers/usb/core/message.c | 23 +++
include/linux/usb.h|5 -
4 files changed, 12 insertions(+), 58 deletions(-)
Index: usb-3.19/include/linux/usb.h
===
--- usb-3.19.orig/include/linux/usb.h
+++ usb-3.19/include/linux/usb.h
@@ -127,10 +127,6 @@ enum usb_interface_condition {
* to the sysfs
Re: Lockdep problem: v3.18+ (with yesterday's Linus tip - 6f51ee709e4c)
On Wed, Jan 07, 2015 at 10:42:14AM -0500, Alan Stern wrote: On Thu, 18 Dec 2014, Greg Kroah-Hartman wrote: That seems reasonable to me, unbinding when a reset is happening is going to be a rare condition, but if we get rid of it, and we try to queue a reset for a device that is gone, we will just fail the reset, right? If all should be fine, I have no objection to removing it. Russell, can you reproduce that lockdep violation whenever you want? I can certainly try it - I move the logitek receiver around between about five machines depending on which I'm wanting to use. Obviously, having had the Christmas holidays recently, it hasn't been moved so much. However, at the moment, I'm still not doing much in the way of kernel work due to ongoing illness. If you can, does the following patch help? I'll give it a go once I've worked out how reproducable it is, many thanks for looking into this. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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/30] usb: updates for dwc2 gadget driver
Hi Yousaf, On 01/07/2015 09:47 AM, Kaukab, Yousaf wrote: -Original Message- From: Dinh Nguyen [mailto:dingu...@opensource.altera.com] Sent: Wednesday, January 7, 2015 4:39 PM To: Kaukab, Yousaf; Paul Zimmerman; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; sergei.shtyl...@cogentembedded.com; r.bald...@samsung.com Subject: Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver On 01/07/2015 09:34 AM, Kaukab, Yousaf wrote: Hi, -Original Message- From: Dinh Nguyen [mailto:dingu...@opensource.altera.com] Sent: Wednesday, January 7, 2015 1:01 AM To: Paul Zimmerman; Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; sergei.shtyl...@cogentembedded.com; r.bald...@samsung.com Subject: Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver On 01/06/2015 05:47 PM, Dinh Nguyen wrote: On 01/05/2015 01:16 PM, Paul Zimmerman wrote: Adding Dinh to CC. Robert, Dinh, I would like to have your tested-bys for this series, please. This patch series is producing this error on the SOCFPGA platform. I'll try to bisect to a specific patch. root@socfpga_cyclone5:~# [ 47.929743] dwc2 ffb4.usb: new device is low-speed [ 63.873596] dwc2 ffb4.usb: new device is low-speed [ 64.219220] dwc2 ffb4.usb: new device is low-speed [ 64.421495] dwc2 ffb4.usb: new device is low-speed [ 64.834505] dwc2 ffb4.usb: new device is high-speed [ 69.899695] [ cut here ] [ 69.904315] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:1352 s3c_hsotg_rx_data+0xc0/0xd4() [ 69.913230] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite [ 69.920385] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc1-00090-g4864f14 #4 [ 69.927917] Hardware name: Altera SOCFPGA [ 69.931936] [c0014d24] (unwind_backtrace) from [c001173c] (show_stack+0x10/0x14) [ 69.939654] [c001173c] (show_stack) from [c0461c74] (dump_stack+0x74/0x90) [ 69.946857] [c0461c74] (dump_stack) from [c0021138] (warn_slowpath_common+0x78/0xb4) [ 69.954916] [c0021138] (warn_slowpath_common) from [c0021190] (warn_slowpath_null+0x1c/0x24) [ 69.963669] [c0021190] (warn_slowpath_null) from [c030278c] (s3c_hsotg_rx_data+0xc0/0xd4) [ 69.972162] [c030278c] (s3c_hsotg_rx_data) from [c0304ac0] (s3c_hsotg_irq+0x454/0x520) [ 69.980394] [c0304ac0] (s3c_hsotg_irq) from [c0058c3c] (handle_irq_event_percpu+0x5c/0x1f4) [ 69.989056] [c0058c3c] (handle_irq_event_percpu) from [c0058e18] (handle_irq_event+0x44/0x64) [ 69.997892] [c0058e18] (handle_irq_event) from [c005b8d8] (handle_fasteoi_irq+0xa8/0x180) [ 70.006382] [c005b8d8] (handle_fasteoi_irq) from [c005856c] (generic_handle_irq+0x20/0x30) [ 70.014958] [c005856c] (generic_handle_irq) from [c0058668] (__handle_domain_irq+0x54/0xb4) [ 70.023619] [c0058668] (__handle_domain_irq) from [c0008638] (gic_handle_irq+0x20/0x5c) [ 70.031937] [c0008638] (gic_handle_irq) from [c0012240] (__irq_svc+0x40/0x54) [ 70.039384] Exception stack(0xc0635f60 to 0xc0635fa8) [ 70.044415] 5f60: c0635fb0 c001cee0 c066cca0 c063c498 c046908c c066c4b2 [ 70.052556] 5f80: c066cca0 0001 ef7fccc0 0100 c0635fa8 c000f0fc c000f100 [ 70.060694] 5fa0: 600f0013 [ 70.064174] [c0012240] (__irq_svc) from [c000f100] (arch_cpu_idle+0x30/0x3c) [ 70.071545] [c000f100] (arch_cpu_idle) from [c0050364] (cpu_startup_entry+0x138/0x224) [ 70.079783] [c0050364] (cpu_startup_entry) from [c05ebbb0] (start_kernel+0x304/0x35c) [ 70.087921] ---[ end trace 66b76f6dcbbda3bf ]--- [ 79.911589] dwc2 ffb4.usb: new device is low-speed Dinh It looks like this patch is producing the above error. usb: dwc2: gadget: manage ep0 state in software Manage ep0 state in software to add handling of status OUT stage. Just toggling hsotg-setup in s3c_hsotg_handle_outdone leaves it in wrong state in 2-stage control transfers. Moreover, don't call s3c_hsotg_handle_outdone both from SetupDone and OutDone. Only use one of them, as for a setup packet we get both. Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com Thank you for testing this patchset. I have tested g_mass_storage without dma in my setup and it is working fine. Did you also test with DMA enabled? Yes, it's working as well. No issue. s3c_hsotg_rx_data() should not be called when DMA enabled. That's why I only mentioned without-dma case. As I don't see this problem, I need some help in figuring out what's going on. Would it be possible for you to provide me following? 1) Console output after enabling CONFIG_USB_DWC2_DEBUG 2) Function trace echo s3c_* /sys/kernel/debug/tracing/set_ftrace_filter echo function /sys/kernel/debug/tracing/current_tracer 3) Values of following registers GSNPSID, GHWCFG1-GHWCFG4 I'll try to get these out for your shortly. Thanks! I've also attached a text file
Re: kernel panic with USB3+DVB+ARM
Hi, I got a similar crash now with USB-2.0. Took longer to happen, but did, see attached log. This makes it more likely the problem is located in DVB code not USB. Will try it on my PC now. At least I already get messages like kernel: [680947.641704] technisat-usb2: i2c-error: 60 = 7 If it crashes again, I can complain at Ubuntu ;) Do you see the same issues with a 3.19 rc kernel? Will try. Currently cloning git repo, so I can better track my builds. thanks for your help, Jan USB-2.0 Unhandled prefetch abort: unknown 25 (0x409) at 0xc0301228 Internal error: : 409 [#1] ARM Modules linked in: usblp ir_lirc_codec ir_xmp_decoder lirc_dev ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder rc_technisat_usb2 stv6110x dvb_usb_technisat_usb2 dvb_usb dvb_core stv090x rc_core xhci_pci ehci_orion xhci_hcd ehci_hcd CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.1-rn104-jpt1 #3 task: c082d8b0 ti: c082 task.ti: c082 PC is at crc32_be+0x40/0x168 LR is at 0xc0825ff0 pc : [c0301228]lr : [c0825ff0]psr: 2193 sp : c0821db4 ip : 61696461 fp : 00b0 r10: e0bad6d8 r9 : 009d r8 : 576edc23 r7 : aa9e5f03 r6 : bbaf844b r5 : 05c6391f r4 : c08278e4 r3 : 4e207265 r2 : 0006 r1 : e0bad640 r0 : 6c5c65ac Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 01180019 DAC: 0015 Process swapper (pid: 0, stack limit = 0xc0820238) Stack: (0xc0821db4 to 0xc0822000) 1da0: e0bad62c e08fd30c 0586 1dc0: e0bad62c e0bae62c c0874e40 bf060be4 05bf bf05f808 1de0: 00200200 bf00a8a8 05bf b0c4c907 e0bad62c e0bae62c 0012 1e00: db07cb78 e0832314 c0874e40 bf05ff10 0001 0080 1e20: 0019 e084b6e0 c082804c 0001 0011 01ff 0040 db07ca78 1e40: 2193 0400 e0832000 03d0 00ec c0874e40 c0874e40 bf060168 1e60: cc87b300 0001 db07cce0 cc87b300 e0832000 c0874e40 bf07eebc 1e80: cc87b300 6113 deda28c4 c0820028 c0874e40 c0407ac0 1ea0: deda28c0 c0821eb0 c04087a8 c0821eb0 c0821eb0 c0820028 1ec0: c082fa3c c0874e00 c0021490 4000 0100 c082 1ee0: c0820028 c0021690 0001 0080 c0874e40 c08319a0 c0874e00 000a 1f00: c05d9ffc 00917c73 c08325a0 0020 c0845f74 1f20: 0001 df406000 dfffcc00 c08167d0 c00219b0 c0845f74 c0048fac 1f40: c08c4440 c0821f70 03ff c08c4440 c086957d c0008520 c0040e38 6013 1f60: c0821fa4 c086957d c0012580 c0832550 c0018ffc 1f80: c082 c08280dc c0820038 c086957d c086957d dfffcc00 c08167d0 1fa0: 0100 c0821fb8 c000f728 c0040e38 6013 c07edc98 1fc0: c07ed690 c08167d0 c08746d4 c0828078 1fe0: c08167cc c082e920 4059 561f5811 8070 [c0301228] (crc32_be) from [bf060be4] (dvb_dmx_crc32+0x10/0x18 [dvb_core]) [bf060be4] (dvb_dmx_crc32 [dvb_core]) from [bf05f808] (dvb_dmx_swfilter_section_copy_dump+0x254/0x268 [dvb_core]) [bf05f808] (dvb_dmx_swfilter_section_copy_dump [dvb_core]) from [bf05ff10] (dvb_dmx_swfilter_packet+0x45c/0x564 [dvb_core]) [bf05ff10] (dvb_dmx_swfilter_packet [dvb_core]) from [bf060168] (dvb_dmx_swfilter+0xf4/0x164 [dvb_core]) [bf060168] (dvb_dmx_swfilter [dvb_core]) from [bf07eebc] (usb_urb_complete+0xbc/0xe4 [dvb_usb]) [bf07eebc] (usb_urb_complete [dvb_usb]) from [c0407ac0] (__usb_hcd_giveback_urb+0x5c/0xe8) [c0407ac0] (__usb_hcd_giveback_urb) from [c04087a8] (usb_giveback_urb_bh+0x7c/0xb0) [c04087a8] (usb_giveback_urb_bh) from [c0021490] (tasklet_hi_action+0x68/0xb4) [c0021490] (tasklet_hi_action) from [c0021690] (__do_softirq+0x100/0x208) [c0021690] (__do_softirq) from [c00219b0] (irq_exit+0x74/0xac) [c00219b0] (irq_exit) from [c0048fac] (__handle_domain_irq+0x58/0x98) [c0048fac] (__handle_domain_irq) from [c0008520] (armada_370_xp_handle_irq+0x48/0x60) [c0008520] (armada_370_xp_handle_irq) from [c0012580] (__irq_svc+0x40/0x54) Exception stack(0xc0821f70 to 0xc0821fb8) 1f60: c0832550 c0018ffc 1f80: c082 c08280dc c0820038 c086957d c086957d dfffcc00 c08167d0 1fa0: 0100 c0821fb8 c000f728 c0040e38 6013 [c0012580] (__irq_svc) from [c0040e38] (cpu_startup_entry+0xa8/0xf4) [c0040e38] (cpu_startup_entry) from [c07edc98] (start_kernel+0x3c4/0x3d0) Code: e59a3004 e2599001 e5bac008 e023 (e7e7745c) ---[ end trace 8362b7e534e62fff ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt
RE: [PATCH v2 00/30] usb: updates for dwc2 gadget driver
Hi Dinh, -Original Message- From: Dinh Nguyen [mailto:dingu...@opensource.altera.com] Sent: Wednesday, January 7, 2015 5:26 PM To: Kaukab, Yousaf; Paul Zimmerman; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; sergei.shtyl...@cogentembedded.com; r.bald...@samsung.com Subject: Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver Hi Yousaf, I've also attached a text file of the log. root@socfpga_cyclone5:~# insmod g_mass_storage.ko file=/dev/mmcblk0p1 [ 144.084933] Number of LUNs=8 [ 144.087817] Mass Storage Function, version: 2009/09/11 [ 144.092936] LUN: removable file: (no medium) [ 144.097228] Number of LUNs=1 [ 144.100217] LUN: file: /dev/mmcblk0p1 [ 144.103867] Number of LUNs=1 [ 144.106941] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 144.113874] g_mass_storage gadget: userspace failed to provide iSerialNumber [ 144.120922] g_mass_storage gadget: g_mass_storage ready [ 144.129387] dwc2 ffb4.usb: bound driver g_mass_storage root@socfpga_cyclone5:~# root@socfpga_cyclone5:~# [ 144.353610] dwc2 ffb4.usb: new device is high-speed [ 144.527612] dwc2 ffb4.usb: new device is high-speed [ 149.595802] [ cut here ] [ 149.600420] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:1352 s3c_hsotg_rx_data+0xcc/0x144() [ 149.609423] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite [ 149.616582] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc1-00090-g4864f14 #14 [ 149.624202] Hardware name: Altera SOCFPGA [ 149.628222] [c00165e4] (unwind_backtrace) from [c00124f0] (show_stack+0x20/0x24) [ 149.635941] [c00124f0] (show_stack) from [c04c7374] (dump_stack+0x7c/0x98) [ 149.643147] [c04c7374] (dump_stack) from [c0023ec4] (warn_slowpath_common+0x88/0xc4) [ 149.651208] [c0023ec4] (warn_slowpath_common) from [c0023f2c] (warn_slowpath_null+0x2c/0x34) [ 149.659961] [c0023f2c] (warn_slowpath_null) from [c034ccc4] (s3c_hsotg_rx_data+0xcc/0x144) [ 149.668542] [c034ccc4] (s3c_hsotg_rx_data) from [c034f884] (s3c_hsotg_irq+0x3e0/0x708) [ 149.676777] [c034f884] (s3c_hsotg_irq) from [c0060d30] (handle_irq_event_percpu+0x68/0x204) [ 149.685442] [c0060d30] (handle_irq_event_percpu) from [c0060f20] (handle_irq_event+0x54/0x74) [ 149.694280] [c0060f20] (handle_irq_event) from [c0063e2c] (handle_fasteoi_irq+0xb8/0x190) [ 149.702771] [c0063e2c] (handle_fasteoi_irq) from [c0060548] (generic_handle_irq+0x30/0x40) [ 149.711348] [c0060548] (generic_handle_irq) from [c0060694] (__handle_domain_irq+0x64/0xc4) [ 149.720012] [c0060694] (__handle_domain_irq) from [c00086bc] (gic_handle_irq+0x30/0x6c) [ 149.728333] [c00086bc] (gic_handle_irq) from [c00130c0] (__irq_svc+0x40/0x54) [ 149.735781] Exception stack(0xc06fbf38 to 0xc06fbf80) [ 149.740811] bf20: [ 149.748953] bf40: c06fbf90 c001f600 c0702c60 c0733560 c0702498 c04cf08c c0732d73 413fc090 [ 149.757096] bf60: c0733560 c06fbf8c c06fbf90 c06fbf80 c000f934 c000f938 6013 [ 149.765243] [c00130c0] (__irq_svc) from [c000f938] (arch_cpu_idle+0x40/0x4c) [ 149.772616] [c000f938] (arch_cpu_idle) from [c0057670] (cpu_startup_entry+0x144/0x22c) [ 149.780857] [c0057670] (cpu_startup_entry) from [c04c2bc4] (rest_init+0x70/0x88) [ 149.788581] [c04c2bc4] (rest_init) from [c069bc60] (start_kernel+0x310/0x368) [ 149.796030] ---[ end trace 05bdb288fcc8864d ]--- [ 155.793924] random: nonblocking pool is initialized I don't see any debug messages. Did you enable CONFIG_USB_DWC2_DEBUG? If so, then perhaps you need to set the log level in your console (/proc/sys/kernel/printk)? What about Values of following registers GSNPSID, GHWCFG1-GHWCFG4? Is it possible for you to print them as well? BR, Yousaf -- 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: Difference between run time and normal suspend
hi alan: 2015-01-06 23:54 GMT+08:00 Alan Stern st...@rowland.harvard.edu: On Tue, 6 Jan 2015, vichy wrote: But I cannot see the keyboard go to suspend even I force autosuspend as 0. is there any other way to trigger runtime suspend immediately instead of waiting kernel judge it is idle for a while? There may be other reasons why the keyboard does not get suspended. For example, it may not support remote wakeup. What does lsusb -v show? And what does usbmon show? here is the output of lsusb and usbmon will be attach soon. BTW, 1. is there any other method to trigger runtime suspend instead of waiting device to be idle. such as echo xxx , and it will directly call runtime suspend related function No, there isn't. 2. why remote wake up feature of hid is related to runtime suspend? runtime suspend is kernel use to saving power and suspend/resume actively, right? That's true. But it wouldn't work very well if the keyboard went into runtime suspend and stayed that way even when you tried to type on it! If a keyboard doesn't support remote wakeup then we must not put it into runtime suspend. I attach usbmon for your reference. But keyboard is still not working on runtime suspend. However, I see from the lsusb output that your keyboard _does_ support remote wakeup, so that isn't the reason. 3. for host part, runtime suspend/resume is only doing port suspend/resume or both host and port going to suspend/resume? Only the port. However, when _all_ the devices attached to the host controlluer go into runtime suspend, the controller itself will also be put into runtime suspend. Would you mind to show me where the program determine controller go into runtime suspend if all devices on it go to suspend? BTW a. if even controller suspended, does that mean all devices on it will be disconnect and re-enumerated when resume? b. is there any usb sysfs file can let us suspend specific port on root or normal hub? appreciate your kind help, liteon.keyboard.mon.tar.bz2 Description: BZip2 compressed data
[PATCH v2 3/3] usb: storage: adjust module reference for scsi host
While accessing a unusual usb storage (ums-alauda, ums-cypress, ...),
the module reference count is not incremented. Because these drivers
allocate scsi hosts with usb_stor_host_template defined in usb-storage
module. So these drivers always can be unloaded.
This fixes it by passing correct module reference to usb_stor_probe1() to
adjust it after scsi host allocation.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: Matthew Dharm mdharm-...@one-eyed-alien.net
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: linux-usb@vger.kernel.org
Cc: usb-stor...@lists.one-eyed-alien.net
Cc: linux-s...@vger.kernel.org
---
* v2:
- Pass correct module reference to usb_stor_probe1() instead of touching
all ums-* drivers, suggested by Alan Stern
drivers/usb/storage/usb.c | 8 +---
drivers/usb/storage/usb.h | 7 +--
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index d468d02..3bb2558 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -911,10 +911,11 @@ static unsigned int usb_stor_sg_tablesize(struct
usb_interface *intf)
}
/* First part of general USB mass-storage probing */
-int usb_stor_probe1(struct us_data **pus,
+int __usb_stor_probe1(struct us_data **pus,
struct usb_interface *intf,
const struct usb_device_id *id,
- struct us_unusual_dev *unusual_dev)
+ struct us_unusual_dev *unusual_dev,
+ struct module *owner)
{
struct Scsi_Host *host;
struct us_data *us;
@@ -937,6 +938,7 @@ int usb_stor_probe1(struct us_data **pus,
*/
host-max_cmd_len = 16;
host-sg_tablesize = usb_stor_sg_tablesize(intf);
+ host-module = owner;
*pus = us = host_to_us(host);
mutex_init((us-dev_mutex));
us_set_lock_class(us-dev_mutex, intf);
@@ -969,7 +971,7 @@ BadDevice:
release_everything(us);
return result;
}
-EXPORT_SYMBOL_GPL(usb_stor_probe1);
+EXPORT_SYMBOL_GPL(__usb_stor_probe1);
/* Second part of general USB mass-storage probing */
int usb_stor_probe2(struct us_data *us)
diff --git a/drivers/usb/storage/usb.h b/drivers/usb/storage/usb.h
index 307e339..0cb74ba 100644
--- a/drivers/usb/storage/usb.h
+++ b/drivers/usb/storage/usb.h
@@ -194,10 +194,13 @@ extern int usb_stor_reset_resume(struct usb_interface
*iface);
extern int usb_stor_pre_reset(struct usb_interface *iface);
extern int usb_stor_post_reset(struct usb_interface *iface);
-extern int usb_stor_probe1(struct us_data **pus,
+extern int __usb_stor_probe1(struct us_data **pus,
struct usb_interface *intf,
const struct usb_device_id *id,
- struct us_unusual_dev *unusual_dev);
+ struct us_unusual_dev *unusual_dev,
+ struct module *owner);
+#define usb_stor_probe1(pus, intf, id, unusual_dev) \
+ __usb_stor_probe1(pus, intf, id, unusual_dev, THIS_MODULE)
extern int usb_stor_probe2(struct us_data *us);
extern void usb_stor_disconnect(struct usb_interface *intf);
--
1.9.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: [PATCH v2 00/30] usb: updates for dwc2 gadget driver
Hi, -Original Message- From: Dinh Nguyen [mailto:dingu...@opensource.altera.com] Sent: Wednesday, January 7, 2015 1:01 AM To: Paul Zimmerman; Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; sergei.shtyl...@cogentembedded.com; r.bald...@samsung.com Subject: Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver On 01/06/2015 05:47 PM, Dinh Nguyen wrote: On 01/05/2015 01:16 PM, Paul Zimmerman wrote: Adding Dinh to CC. Robert, Dinh, I would like to have your tested-bys for this series, please. This patch series is producing this error on the SOCFPGA platform. I'll try to bisect to a specific patch. root@socfpga_cyclone5:~# [ 47.929743] dwc2 ffb4.usb: new device is low-speed [ 63.873596] dwc2 ffb4.usb: new device is low-speed [ 64.219220] dwc2 ffb4.usb: new device is low-speed [ 64.421495] dwc2 ffb4.usb: new device is low-speed [ 64.834505] dwc2 ffb4.usb: new device is high-speed [ 69.899695] [ cut here ] [ 69.904315] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:1352 s3c_hsotg_rx_data+0xc0/0xd4() [ 69.913230] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite [ 69.920385] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc1-00090-g4864f14 #4 [ 69.927917] Hardware name: Altera SOCFPGA [ 69.931936] [c0014d24] (unwind_backtrace) from [c001173c] (show_stack+0x10/0x14) [ 69.939654] [c001173c] (show_stack) from [c0461c74] (dump_stack+0x74/0x90) [ 69.946857] [c0461c74] (dump_stack) from [c0021138] (warn_slowpath_common+0x78/0xb4) [ 69.954916] [c0021138] (warn_slowpath_common) from [c0021190] (warn_slowpath_null+0x1c/0x24) [ 69.963669] [c0021190] (warn_slowpath_null) from [c030278c] (s3c_hsotg_rx_data+0xc0/0xd4) [ 69.972162] [c030278c] (s3c_hsotg_rx_data) from [c0304ac0] (s3c_hsotg_irq+0x454/0x520) [ 69.980394] [c0304ac0] (s3c_hsotg_irq) from [c0058c3c] (handle_irq_event_percpu+0x5c/0x1f4) [ 69.989056] [c0058c3c] (handle_irq_event_percpu) from [c0058e18] (handle_irq_event+0x44/0x64) [ 69.997892] [c0058e18] (handle_irq_event) from [c005b8d8] (handle_fasteoi_irq+0xa8/0x180) [ 70.006382] [c005b8d8] (handle_fasteoi_irq) from [c005856c] (generic_handle_irq+0x20/0x30) [ 70.014958] [c005856c] (generic_handle_irq) from [c0058668] (__handle_domain_irq+0x54/0xb4) [ 70.023619] [c0058668] (__handle_domain_irq) from [c0008638] (gic_handle_irq+0x20/0x5c) [ 70.031937] [c0008638] (gic_handle_irq) from [c0012240] (__irq_svc+0x40/0x54) [ 70.039384] Exception stack(0xc0635f60 to 0xc0635fa8) [ 70.044415] 5f60: c0635fb0 c001cee0 c066cca0 c063c498 c046908c c066c4b2 [ 70.052556] 5f80: c066cca0 0001 ef7fccc0 0100 c0635fa8 c000f0fc c000f100 [ 70.060694] 5fa0: 600f0013 [ 70.064174] [c0012240] (__irq_svc) from [c000f100] (arch_cpu_idle+0x30/0x3c) [ 70.071545] [c000f100] (arch_cpu_idle) from [c0050364] (cpu_startup_entry+0x138/0x224) [ 70.079783] [c0050364] (cpu_startup_entry) from [c05ebbb0] (start_kernel+0x304/0x35c) [ 70.087921] ---[ end trace 66b76f6dcbbda3bf ]--- [ 79.911589] dwc2 ffb4.usb: new device is low-speed Dinh It looks like this patch is producing the above error. usb: dwc2: gadget: manage ep0 state in software Manage ep0 state in software to add handling of status OUT stage. Just toggling hsotg-setup in s3c_hsotg_handle_outdone leaves it in wrong state in 2-stage control transfers. Moreover, don't call s3c_hsotg_handle_outdone both from SetupDone and OutDone. Only use one of them, as for a setup packet we get both. Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com Thank you for testing this patchset. I have tested g_mass_storage without dma in my setup and it is working fine. As I don't see this problem, I need some help in figuring out what's going on. Would it be possible for you to provide me following? 1) Console output after enabling CONFIG_USB_DWC2_DEBUG 2) Function trace echo s3c_* /sys/kernel/debug/tracing/set_ftrace_filter echo function /sys/kernel/debug/tracing/current_tracer 3) Values of following registers GSNPSID, GHWCFG1-GHWCFG4 Dinh BR, Yousaf -- 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/30] usb: updates for dwc2 gadget driver
-Original Message- From: Dinh Nguyen [mailto:dingu...@opensource.altera.com] Sent: Wednesday, January 7, 2015 4:39 PM To: Kaukab, Yousaf; Paul Zimmerman; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; sergei.shtyl...@cogentembedded.com; r.bald...@samsung.com Subject: Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver On 01/07/2015 09:34 AM, Kaukab, Yousaf wrote: Hi, -Original Message- From: Dinh Nguyen [mailto:dingu...@opensource.altera.com] Sent: Wednesday, January 7, 2015 1:01 AM To: Paul Zimmerman; Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com Cc: Herrero, Gregory; sergei.shtyl...@cogentembedded.com; r.bald...@samsung.com Subject: Re: [PATCH v2 00/30] usb: updates for dwc2 gadget driver On 01/06/2015 05:47 PM, Dinh Nguyen wrote: On 01/05/2015 01:16 PM, Paul Zimmerman wrote: Adding Dinh to CC. Robert, Dinh, I would like to have your tested-bys for this series, please. This patch series is producing this error on the SOCFPGA platform. I'll try to bisect to a specific patch. root@socfpga_cyclone5:~# [ 47.929743] dwc2 ffb4.usb: new device is low-speed [ 63.873596] dwc2 ffb4.usb: new device is low-speed [ 64.219220] dwc2 ffb4.usb: new device is low-speed [ 64.421495] dwc2 ffb4.usb: new device is low-speed [ 64.834505] dwc2 ffb4.usb: new device is high-speed [ 69.899695] [ cut here ] [ 69.904315] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:1352 s3c_hsotg_rx_data+0xc0/0xd4() [ 69.913230] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite [ 69.920385] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc1-00090-g4864f14 #4 [ 69.927917] Hardware name: Altera SOCFPGA [ 69.931936] [c0014d24] (unwind_backtrace) from [c001173c] (show_stack+0x10/0x14) [ 69.939654] [c001173c] (show_stack) from [c0461c74] (dump_stack+0x74/0x90) [ 69.946857] [c0461c74] (dump_stack) from [c0021138] (warn_slowpath_common+0x78/0xb4) [ 69.954916] [c0021138] (warn_slowpath_common) from [c0021190] (warn_slowpath_null+0x1c/0x24) [ 69.963669] [c0021190] (warn_slowpath_null) from [c030278c] (s3c_hsotg_rx_data+0xc0/0xd4) [ 69.972162] [c030278c] (s3c_hsotg_rx_data) from [c0304ac0] (s3c_hsotg_irq+0x454/0x520) [ 69.980394] [c0304ac0] (s3c_hsotg_irq) from [c0058c3c] (handle_irq_event_percpu+0x5c/0x1f4) [ 69.989056] [c0058c3c] (handle_irq_event_percpu) from [c0058e18] (handle_irq_event+0x44/0x64) [ 69.997892] [c0058e18] (handle_irq_event) from [c005b8d8] (handle_fasteoi_irq+0xa8/0x180) [ 70.006382] [c005b8d8] (handle_fasteoi_irq) from [c005856c] (generic_handle_irq+0x20/0x30) [ 70.014958] [c005856c] (generic_handle_irq) from [c0058668] (__handle_domain_irq+0x54/0xb4) [ 70.023619] [c0058668] (__handle_domain_irq) from [c0008638] (gic_handle_irq+0x20/0x5c) [ 70.031937] [c0008638] (gic_handle_irq) from [c0012240] (__irq_svc+0x40/0x54) [ 70.039384] Exception stack(0xc0635f60 to 0xc0635fa8) [ 70.044415] 5f60: c0635fb0 c001cee0 c066cca0 c063c498 c046908c c066c4b2 [ 70.052556] 5f80: c066cca0 0001 ef7fccc0 0100 c0635fa8 c000f0fc c000f100 [ 70.060694] 5fa0: 600f0013 [ 70.064174] [c0012240] (__irq_svc) from [c000f100] (arch_cpu_idle+0x30/0x3c) [ 70.071545] [c000f100] (arch_cpu_idle) from [c0050364] (cpu_startup_entry+0x138/0x224) [ 70.079783] [c0050364] (cpu_startup_entry) from [c05ebbb0] (start_kernel+0x304/0x35c) [ 70.087921] ---[ end trace 66b76f6dcbbda3bf ]--- [ 79.911589] dwc2 ffb4.usb: new device is low-speed Dinh It looks like this patch is producing the above error. usb: dwc2: gadget: manage ep0 state in software Manage ep0 state in software to add handling of status OUT stage. Just toggling hsotg-setup in s3c_hsotg_handle_outdone leaves it in wrong state in 2-stage control transfers. Moreover, don't call s3c_hsotg_handle_outdone both from SetupDone and OutDone. Only use one of them, as for a setup packet we get both. Signed-off-by: Mian Yousaf Kaukab yousaf.kau...@intel.com Thank you for testing this patchset. I have tested g_mass_storage without dma in my setup and it is working fine. Did you also test with DMA enabled? Yes, it's working as well. No issue. s3c_hsotg_rx_data() should not be called when DMA enabled. That's why I only mentioned without-dma case. As I don't see this problem, I need some help in figuring out what's going on. Would it be possible for you to provide me following? 1) Console output after enabling CONFIG_USB_DWC2_DEBUG 2) Function trace echo s3c_* /sys/kernel/debug/tracing/set_ftrace_filter echo function /sys/kernel/debug/tracing/current_tracer 3) Values of following registers GSNPSID, GHWCFG1-GHWCFG4 I'll try to get these out for your shortly.
Re: [PATCH v2 0/3] scsi: ufs ums-*: fix module reference counting
On Wed, Jan 07, 2015 at 11:02:59PM +0900, Akinobu Mita wrote: While accessing a scsi_device, the use count of the underlying LLDD module is incremented. The module reference is retrieved through .module field of struct scsi_host_template. This mapping between scsi_device and underlying LLDD module works well except some scsi drivers (ufs and unusual usb storage drivers). These drivers consist with core driver and actual LLDDs, and scsi_host_template is defined in the core driver. So the actual LLDDs can be unloaded even if the scsi_device is being accessed. Why don't ufs and usb-storage define the host templates in the sub drivers? That's what libata or the mpt fusion driver do. -- 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 v3] usb: dwc2: add bus suspend/resume for dwc2
On 01/05/2015 09:02 PM, Paul Zimmerman wrote: From: Kever Yang [mailto:kever.y...@rock-chips.com] Sent: Monday, January 05, 2015 5:42 PM Hi Paul, I think you need this patch to fix the problem: usb: dwc2: resume root hub when device detect with suspend state https://patchwork.kernel.org/patch/5325111/ This patch may have fixed hotplug when a device is connected directly to the USB port, but it does not seem to fix a hotplug when a device is connected to a hub. I booted the board up with a device connected to a 4-port hub, the device is detected, unplug the device from a hub, wait 5-sec, re-plug the device into hub. The device is not detected. Thanks, - Kever On 01/06/2015 09:23 AM, Paul Zimmerman wrote: From: Kever Yang [mailto:kever.y...@rock-chips.com] Sent: Wednesday, November 12, 2014 4:42 PM On 11/13/2014 07:22 AM, Doug Anderson wrote: Kever, On Mon, Nov 10, 2014 at 5:09 AM, Kever Yang kever.y...@rock-chips.com wrote: Hcd controller needs bus_suspend/resume, dwc2 controller make root hub generate suspend/resume signal with hprt0 register when work in host mode. After the root hub enter suspend, we can make controller enter low power state with PCGCTL register. We also update the lx_state for hsotg state. This patch has tested on rk3288 with suspend/resume. Signed-off-by: Kever Yang kever.y...@rock-chips.com Acked-by: Paul Zimmerman pa...@synopsys.com --- Changes in v3: - remove CONFIG_PM macro for bus_suspend/resume - add PCGCTL operation for no device connect case Changes in v2: - update commit message - make dwc2 suspend/resume sourcecode work drivers/usb/dwc2/hcd.c | 88 +++--- 1 file changed, 77 insertions(+), 11 deletions(-) I would certainly appreciate confirmation, but my inclination is to NAK this change due to the fact that it regresses functionality. I haven't done any serious review of it, but I've been testing it and it appears to break hotplug. Said another way, I did this: 1. Without this patch, I booted with a USB stick in. It was detected. I unplugged it, waited 5 seconds, and then plugged it back in. The USB stick was redetcted. 2. With this patch, I did the same thing. The USB not redected after plugging it back in. With this patch, the dwc2 hcd/root hub will be auto suspend after device on port is disconnected, and it can't detect the device connect any more, I think that's the problem. I will figure out how to make dwc2 detect the device connect after auto suspend, or disable the auto suspend feature for the dwc2 hcd. Kever, This patch has made it into Linus' kernel as commit 0cf884e819e0, and it breaks disconnect/connect on at least the Altera SOCFPGA platform. I haven't been able to test it on any other platforms. You need to submit a patch to either fix this, or to only enable this feature for the Rock-chip platform. Otherwise the patch has to be reverted. Unfortunately, after applying that patch there is another problem. If I connect a device that causes an overcurrent condition to the root port, then the port is dead after that. No further devices are detected until after I reboot. I tried adding another call to usb_hcd_resume_root_hub() in the if (hprt0 HPRT0_OVRCURRCHG) branch, but then an overcurrent condition causes a continuous stream of these messages: [ 133.348776] dwc2 ffb4.usb: GetPortStatus wIndex=0x0001 flags=0x0022 [ 133.355717] dwc2 ffb4.usb: Overcurrent change detected [ 133.361179] dwc2 ffb4.usb: HPRT0: 0x0002 [ 133.365960] dwc2 ffb4.usb: port_status=0008 [ 133.373236] hub 1-0:1.0: state 7 ports 1 chg evt [ 133.380038] hub 1-0:1.0: hub_suspend [ 133.384237] usb usb1: bus auto-suspend, wakeup 1 [ 133.393631] dwc2 ffb4.usb: DWC OTG HCD HUB STATUS DATA: Root port status changed [ 133.401341] dwc2 ffb4.usb: port_connect_status_change: 0 [ 133.407157] dwc2 ffb4.usb: port_reset_change: 0 [ 133.412186] dwc2 ffb4.usb: port_enable_change: 0 [ 133.417310] dwc2 ffb4.usb: port_suspend_change: 0 [ 133.422519] dwc2 ffb4.usb: port_over_current_change: 1 [ 133.428154] usb usb1: suspend raced with wakeup event [ 133.433191] usb usb1: usb auto-resume [ 133.441522] hub 1-0:1.0: hub_resume [ 133.455505] dwc2 ffb4.usb: GetPortStatus wIndex=0x0001 flags=0x0022 [ 133.462443] dwc2 ffb4.usb: Overcurrent change detected [ 133.467907] dwc2 ffb4.usb: HPRT0: 0x0002 [ 133.472684] dwc2 ffb4.usb: port_status=0008 [ 133.480088] hub 1-0:1.0: state 7 ports 1 chg evt [ 133.485578] hub 1-0:1.0: hub_suspend [ 133.489157] usb usb1: bus auto-suspend, wakeup 1 [ 133.493768] dwc2 ffb4.usb: _dwc2_hcd_suspend() [ 133.498540] dwc2 ffb4.usb: DWC OTG HCD HUB STATUS DATA: Root port status changed [ 133.506257] dwc2 ffb4.usb: port_connect_status_change: 0 [ 133.512065] dwc2
