from:"George Cherian"

Re: JMS56x not working reliably with uas driver

2016-12-27 Thread George Cherian

Hi Alan,

On Tuesday 27 December 2016 08:50 PM, Alan Stern wrote:

On Tue, 27 Dec 2016, Oliver Neukum wrote:

On Thu, 2016-12-22 at 17:44 -0500, Alan Stern wrote:

I don't see how this patch fixes anything. Unless I'm mistaken, it
just avoids the problem by preventing the system from issuing the
command that provokes the error, rather than really fixing the
underlying error.

Please clarify. If a reset leads to a disconnect, isn't that
exactly what we want?

I didn't express myself clearly enough. Yes, if a reset leads to a
disconnect then avoiding the reset will avoid problems.

But the _real_ error here is that xhci-hcd says "ERROR Transfer event
for disabled endpoint or incorrect stream ring" when the disconnect
occurs during reset.

I think there is some misunderstanding of the issues.

"ERROR Transfer event for disabled endpoint or incorrect stream ring" This
particular message is during the connect of the device and not during the disconnect.
To avoid this message the unusual_uas.h patch was sent earlier.

During disconnect of the device I get "scsi host4: uas_post_reset: alloc streams error -19 after reset" and
I dont get the same with the modified patch which Alan suggested,
instead I get a proper disconnect.

That shouldn't happen, no matter what quirks the
device has. It indicates a bug either in uas or in xhci-hcd.

Alan Stern

Regards, -George
--
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: JMS56x not working reliably with uas driver

2016-12-22 Thread George Cherian


Hi Alan,


On Friday 23 December 2016 04:14 AM, Alan Stern wrote:

On Wed, 21 Dec 2016, George Cherian wrote:


Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or
incorrect stream ring
   This was eliminated using the following scissor patch.

-8<
[PATCH] usb: storage: unusual_uas: Add JMicron JMS56x to unusual device

This device gives the following error on detection.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or
incorrect stream ring

The same error is not seen when it is added to unusual_device
list with US_FL_NO_REPORT_OPCODES passed.

Signed-off-by: George Cherian <george.cher...@cavium.com>
---
   drivers/usb/storage/unusual_uas.h | 7 +++
   1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h
b/drivers/usb/storage/unusual_uas.h
index cbea9f3..d292299 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -142,6 +142,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),

+/* Reported-by George Cherian <george.cher...@cavium.com> */
+UNUSUAL_DEV(0x152d, 0x9561, 0x, 0x,
+"JMicron",
+"JMS56x",
+USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+US_FL_NO_REPORT_OPCODES),
+
   /* Reported-by: Hans de Goede <hdego...@redhat.com> */
   UNUSUAL_DEV(0x2109, 0x0711, 0x, 0x,
"VIA",
->8

I don't see how this patch fixes anything.  Unless I'm mistaken, it
just avoids the problem by preventing the system from issuing the
command that provokes the error, rather than really fixing the
underlying error.


2) On disconnect I am seeing the following issue

   scsi host4: uas_post_reset: alloc streams error -19 after reset
   sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes
unusable. Even an lsusb invocation hangs for ever.

This problem looks pretty simple.  uas doesn't check properly to see if
the device was disconnected following a reset.

Try changing the line in uas_post_reset() that says:

if (devinfo->shutdown)

to:

if (devinfo->shutdown ||
devinfo->udev->state == USB_STATE_NOTATTACHED)
Yes this works for me but with a little bit change as follows, But am 
not sure whether we should goto reset_scsi in case of shutdown.

Please advice.

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 5ef014b..24db3fd 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -1072,8 +1072,8 @@ static int uas_post_reset(struct usb_interface *intf)
unsigned long flags;
int err;

-   if (devinfo->shutdown)
-   return 0;
+   if (devinfo->shutdown || devinfo->udev->state == 
USB_STATE_NOTATTACHED)

+   goto reset_scsi;

err = uas_configure_endpoints(devinfo);
if (err) {
@@ -1083,6 +1083,7 @@ static int uas_post_reset(struct usb_interface *intf)
return 1;
}

+reset_scsi:
spin_lock_irqsave(shost->host_lock, flags);
scsi_report_bus_reset(shost, 0);
spin_unlock_irqrestore(shost->host_lock, flags);


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: JMS56x not working reliably with uas driver

2016-12-22 Thread George Cherian

:0:0: [sdb] Done: SUCCESS Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK
[  110.257499] sd 4:0:0:0: [sdb] CDB: Read(16) 88 00 00 00 00 00 04 a8 
60 00 00 00 00 80 00 00

[  110.257503] sd 4:0:0:0: [sdb] sd_done: completed 65536 of 65536 bytes
[  110.257506] sd 4:0:0:0: [sdb] 128 sectors total, 65536 bytes done.
[  110.257727] sd 4:0:0:0: [sdb] sd_ioctl: disk=sdb, cmd=0x5331
[  110.257759] sd 4:0:0:0: [sdb] sd_setup_read_write_cmnd: block=0, 
count=128

[  110.257762] sd 4:0:0:0: [sdb] block=0
[  110.257765] sd 4:0:0:0: [sdb] reading 128/128 512 byte blocks.
[  110.257770] sd 4:0:0:0: [sdb] Send: scmd 0x801fcc338a00
[  110.257773] sd 4:0:0:0: [sdb] CDB: Read(16) 88 00 00 00 00 00 00 00 
00 00 00 00 00 80 00 00
[  110.258168] sd 4:0:0:0: [sdb] Done: SUCCESS Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK
[  110.258171] sd 4:0:0:0: [sdb] CDB: Read(16) 88 00 00 00 00 00 00 00 
00 00 00 00 00 80 00 00

[  110.258175] sd 4:0:0:0: [sdb] sd_done: completed 65536 of 65536 bytes
[  110.258179] sd 4:0:0:0: [sdb] 128 sectors total, 65536 bytes done.
[  110.259759] sd 4:0:0:0: Send: scmd 0x801fcc338a00
[  110.259763] sd 4:0:0:0: CDB: Test Unit Ready 00 00 00 00 00 00
[  110.259854] sd 4:0:0:0: Done: SUCCESS Result: hostbyte=DID_OK 
driverbyte=DRIVER_OK

[  110.259858] sd 4:0:0:0: CDB: Test Unit Ready 00 00 00 00 00 00
[  110.259861] sd 4:0:0:0: 0 sectors total, 0 bytes done.
=Connect end 

===Disconnect log =

[  358.581289] scsi host4: uas_post_reset: alloc streams error -19 after 
reset

[  358.588962] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
=


On Thursday 22 December 2016 07:34 AM, George Cherian wrote:

Hi Oliver,

I will try it out and update you!!


Regards,

-George

On Wednesday 21 December 2016 08:09 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 18:17 +0530, George Cherian wrote:

[  843.149653] scsi host5: uas_post_reset: alloc streams error -19
after
reset

That would mean the endpoints are gone. Which is odd.


[  843.157268] sd 5:0:0:0: [sdb] Synchronizing SCSI cache

Could you try the attached patch and do a SCSI log of the enumeration?

Regards
Oliver





--
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: JMS56x not working reliably with uas driver

2016-12-21 Thread George Cherian


Hi Oliver,

I will try it out and update you!!


Regards,

-George

On Wednesday 21 December 2016 08:09 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 18:17 +0530, George Cherian wrote:

[  843.149653] scsi host5: uas_post_reset: alloc streams error -19
after
reset

That would mean the endpoints are gone. Which is odd.


[  843.157268] sd 5:0:0:0: [sdb] Synchronizing SCSI cache

Could you try the attached patch and do a SCSI log of the enumeration?

Regards
Oliver



--
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: JMS56x not working reliably with uas driver

2016-12-21 Thread George Cherian




On 12/21/2016 05:12 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.


Thanks. Do you want to submit it to Greg?
The patch is fine.

Yes please!!!




2) On disconnect I am seeing the following issue

   scsi host4: uas_post_reset: alloc streams error -19 after reset
   sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes
unusable. Even an lsusb invocation hangs for ever.


Ouch. That points to a logic error. We should not reset if
a device is gone.
Could you send dmesg of such a case?

here is the dmesg!!
[  203.475382] usb 4-1.3: new SuperSpeed USB device number 3 using xhci_hcd
[  203.496172] usb 4-1.3: New USB device found, idVendor=152d, 
idProduct=9561
[  203.503037] usb 4-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=5

[  203.510352] usb 4-1.3: Product: JMS56x Series
[  203.514698] usb 4-1.3: Manufacturer: JMicron
[  203.518966] usb 4-1.3: SerialNumber: 
[  203.594383] usbcore: registered new interface driver usb-storage
[  203.612425] scsi host4: uas
[  203.615418] usbcore: registered new interface driver uas
[  203.620979] scsi 4:0:0:0: Direct-Access ST4000NM 0033-9ZM170 
 0001 PQ: 0 ANSI: 6

[  203.630240] sd 4:0:0:0: Attached scsi generic sg1 type 0
[  203.630382] sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks: 
(4.00 TB/3.63 TiB)

[  203.631338] sd 4:0:0:0: [sdb] Write Protect is off
[  203.631342] sd 4:0:0:0: [sdb] Mode Sense: 67 00 10 08
[  203.631734] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, supports DPO and FUA
[  203.631899] xhci_hcd :00:11.0: ERROR Transfer event for disabled 
endpoint or incorrect stream ring
[  203.631904] xhci_hcd :00:11.0: @001f610a1c10  
 1b00 03078001 state 14 ep_info 9403

[  203.631906] xhci_hcd :00:11.0: No epring
[  203.674546]  sdb: sdb1
[  203.676639] sd 4:0:0:0: [sdb] Attached SCSI disk
[  213.222913] scsi host4: uas_post_reset: alloc streams error -19 after 
reset

[  213.230548] sd 4:0:0:0: [sdb] Synchronizing SCSI cache

Above is the dmesg without the unusual_uas patch applied.
Do you need me to enable any specific dev_dbg and then the dmesg output?



Regards
Oliver



--
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: JMS56x not working reliably with uas driver

2016-12-21 Thread George Cherian




On 12/21/2016 05:50 PM, Hans de Goede wrote:

Hi,

On 21-12-16 13:07, George Cherian wrote:



On 12/21/2016 05:12 PM, Oliver Neukum wrote:

On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:

Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.


Thanks. Do you want to submit it to Greg?
The patch is fine.

Yes please!!!




2) On disconnect I am seeing the following issue

   scsi host4: uas_post_reset: alloc streams error -19 after reset
   sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes
unusable. Even an lsusb invocation hangs for ever.


Ouch. That points to a logic error. We should not reset if
a device is gone.
Could you send dmesg of such a case?

here is the dmesg!!
[  203.475382] usb 4-1.3: new SuperSpeed USB device number 3 using
xhci_hcd
[  203.496172] usb 4-1.3: New USB device found, idVendor=152d,
idProduct=9561
[  203.503037] usb 4-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=5
[  203.510352] usb 4-1.3: Product: JMS56x Series
[  203.514698] usb 4-1.3: Manufacturer: JMicron
[  203.518966] usb 4-1.3: SerialNumber: 
[  203.594383] usbcore: registered new interface driver usb-storage
[  203.612425] scsi host4: uas
[  203.615418] usbcore: registered new interface driver uas
[  203.620979] scsi 4:0:0:0: Direct-Access ST4000NM 0033-9ZM170
0001 PQ: 0 ANSI: 6
[  203.630240] sd 4:0:0:0: Attached scsi generic sg1 type 0
[  203.630382] sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks:
(4.00 TB/3.63 TiB)
[  203.631338] sd 4:0:0:0: [sdb] Write Protect is off
[  203.631342] sd 4:0:0:0: [sdb] Mode Sense: 67 00 10 08
[  203.631734] sd 4:0:0:0: [sdb] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[  203.631899] xhci_hcd :00:11.0: ERROR Transfer event for
disabled endpoint or incorrect stream ring
[  203.631904] xhci_hcd :00:11.0: @001f610a1c10 
 1b00 03078001 state 14 ep_info 9403
[  203.631906] xhci_hcd :00:11.0: No epring
[  203.674546]  sdb: sdb1
[  203.676639] sd 4:0:0:0: [sdb] Attached SCSI disk
[  213.222913] scsi host4: uas_post_reset: alloc streams error -19
after reset
[  213.230548] sd 4:0:0:0: [sdb] Synchronizing SCSI cache

Above is the dmesg without the unusual_uas patch applied.
Do you need me to enable any specific dev_dbg and then the dmesg output?


Can you get us a dmesg with the unusual_uas patch applied? Usually once
things go foobar because
of issue-ing a command which the device does not understand, more things
typically come down
as both the device and the host may be in an undefined state then.


Here is the lsusb -t

lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M

lsusb
Bus 003 Device 002: ID 0bda:5401 Realtek Semiconductor Corp. RTL 8153 
USB 3.0 hub with gigabit ethernet

Bus 004 Device 002: ID 0bda:0401 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 004: ID 152d:9561 JMicron Technology Corp. / JMicron USA 
Technology Corp.

lsusb -v
Bus 004 Device 004: ID 152d:9561 JMicron Technology Corp. / JMicron USA 
Technology Corp.

Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor   0x152d JMicron Technology Corp. / JMicron USA 
Technology Corp.

  idProduct  0x9561
  bcdDevice0.01
  iManufacturer   1 JMicron
  iProduct2 JMS56x Series
  iSerial 5 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  121
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4 USB Mass Storage
bmAttributes 0xc0
  Self Powered
MaxPower2mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass

JMS56x not working reliably with uas driver

2016-12-21 Thread George Cherian


Hi Oliver,

I was working with this JMicron device and using the uas driver.
I am seeing the following 2 issues.

1) On connect I see the following messages.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or 
incorrect stream ring

 This was eliminated using the following scissor patch.

-8<
[PATCH] usb: storage: unusual_uas: Add JMicron JMS56x to unusual device

This device gives the following error on detection.
xhci_hcd :00:11.0: ERROR Transfer event for disabled endpoint or 
incorrect stream ring


The same error is not seen when it is added to unusual_device
list with US_FL_NO_REPORT_OPCODES passed.

Signed-off-by: George Cherian <george.cher...@cavium.com>
---
 drivers/usb/storage/unusual_uas.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h 
b/drivers/usb/storage/unusual_uas.h

index cbea9f3..d292299 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -142,6 +142,13 @@ UNUSUAL_DEV(0x152d, 0x0567, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_BROKEN_FUA | US_FL_NO_REPORT_OPCODES),

+/* Reported-by George Cherian <george.cher...@cavium.com> */
+UNUSUAL_DEV(0x152d, 0x9561, 0x, 0x,
+"JMicron",
+"JMS56x",
+USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+US_FL_NO_REPORT_OPCODES),
+
 /* Reported-by: Hans de Goede <hdego...@redhat.com> */
 UNUSUAL_DEV(0x2109, 0x0711, 0x, 0x,
"VIA",
->8

2) On disconnect I am seeing the following issue

 scsi host4: uas_post_reset: alloc streams error -19 after reset
 sd 4:0:0:0: [sdb] Synchronizing SCSI cache

This is more fatal because after these messages the USB port becomes 
unusable. Even an lsusb invocation hangs for ever.


Also please note that the device works fine with usb-storage driver.
I am attaching the usbmon capture of disconnect using uas and 
usb-storage driver.


Any help in this regard is highly appreciated.

Regards,
-George
801f5efb8a00 57530621 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57530654 S Ii:4:002:1 -115:128 2 <
801f61285a00 57530677 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57531618 C Ci:4:002:0 0 4 = c1024000
801f61285a00 57531634 S Co:4:002:0 s 23 01 0019 0003  0
801f61285a00 57531992 C Co:4:002:0 0 0
801f61285a00 57532225 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57533010 C Ci:4:002:0 0 4 = c102
801f61285a00 57533022 S Co:4:002:0 s 23 03 001c 0003  0
801f61285a00 57533405 C Co:4:002:0 0 0
801f61285a00 57553165 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57554174 C Ci:4:002:0 0 4 = b102
801f61285a00 57573164 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57574064 C Ci:4:002:0 0 4 = b102
801f61285a00 57593169 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57594214 C Ci:4:002:0 0 4 = b102
801f5efb8a00 57642612 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57642621 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57658612 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57658618 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57674611 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57674617 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57690610 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57690615 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57706609 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57706615 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57722609 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57722614 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57738611 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57738616 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57754610 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57754615 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57770607 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57770612 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57786609 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57786614 S Ii:4:002:1 -115:128 2 <
801f5efb8a00 57802608 C Ii:4:002:1 0:128 1 = 08
801f5efb8a00 57802613 S Ii:4:002:1 -115:128 2 <
801f61285a00 57803198 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57804109 C Ci:4:002:0 0 4 = a0020100
801f61285a00 57804122 S Co:4:002:0 s 23 01 0014 0003  0
801f61285a00 57804539 C Co:4:002:0 0 0
801f61285a00 57804553 S Co:4:002:0 s 23 01 001d 0003  0
801f61285a00 57804876 C Co:4:002:0 0 0
801f61285a00 57804890 S Co:4:002:0 s 23 01 0019 0003  0
801f61285a00 57805185 C Co:4:002:0 0 0
801f61285a00 57805199 S Co:4:002:0 s 23 01 0010 0003  0
801f61285a00 57805735 C Co:4:002:0 0 0
801f61285a00 57805749 S Ci:4:002:0 s a3 00  0003 0004 4 <
801f61285a00 57806491

[PATCH v2] usb: dwc3: dwc3-omap: Fix disable IRQ

2015-02-12 Thread George Cherian

In the wrapper the IRQ disable should be done by writing 1's to the
IRQ*_CLR register. Existing code is broken because it instead writes
zeros to IRQ*_SET register.

Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
dwc3_omap_write_irq0_clr() which do the right thing.

Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver)
Cc: sta...@vger.kernel.org # v3.2+
Signed-off-by: George Cherian george.cher...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 172d64e..52e0c4e 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -205,6 +205,18 @@ static void dwc3_omap_write_irq0_set(struct dwc3_omap 
*omap, u32 value)
omap-irq0_offset, value);
 }
 
+static void dwc3_omap_write_irqmisc_clr(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_CLR_MISC +
+   omap-irqmisc_offset, value);
+}
+
+static void dwc3_omap_write_irq0_clr(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_CLR_0 -
+   omap-irq0_offset, value);
+}
+
 static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
enum omap_dwc3_vbus_id_status status)
 {
@@ -345,9 +357,23 @@ static void dwc3_omap_enable_irqs(struct dwc3_omap *omap)
 
 static void dwc3_omap_disable_irqs(struct dwc3_omap *omap)
 {
+   u32 reg;
+
/* disable all IRQs */
-   dwc3_omap_write_irqmisc_set(omap, 0x00);
-   dwc3_omap_write_irq0_set(omap, 0x00);
+   reg = USBOTGSS_IRQO_COREIRQ_ST;
+   dwc3_omap_write_irq0_clr(omap, reg);
+
+   reg = (USBOTGSS_IRQMISC_OEVT |
+   USBOTGSS_IRQMISC_DRVVBUS_RISE |
+   USBOTGSS_IRQMISC_CHRGVBUS_RISE |
+   USBOTGSS_IRQMISC_DISCHRGVBUS_RISE |
+   USBOTGSS_IRQMISC_IDPULLUP_RISE |
+   USBOTGSS_IRQMISC_DRVVBUS_FALL |
+   USBOTGSS_IRQMISC_CHRGVBUS_FALL |
+   USBOTGSS_IRQMISC_DISCHRGVBUS_FALL |
+   USBOTGSS_IRQMISC_IDPULLUP_FALL);
+
+   dwc3_omap_write_irqmisc_clr(omap, reg);
 }
 
 static u64 dwc3_omap_dma_mask = DMA_BIT_MASK(32);
-- 
1.8.3.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] usb: dwc3: dwc3-omap: Fix disable IRQ

2015-02-12 Thread George Cherian



On 02/12/2015 11:52 PM, Felipe Balbi wrote:

On Thu, Feb 12, 2015 at 11:13:16AM +0530, George Cherian wrote:

In the wrapper the IRQ disable should be done by writing 1's to the
IRQ*_CLR register. Existing code is broken because it instead writes
zeros to IRQ*_SET register.

Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
dwc3_omap_write_irq0_clr() which do the right thing.

Signed-off-by: George Cheriangeorge.cher...@ti.com

please resend with:

Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver)
Cc:sta...@vger.kernel.org  # v3.2+

Done!!
--
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: dwc3: dwc3-omap: Fix disable IRQ

2015-02-11 Thread George Cherian

In the wrapper the IRQ disable should be done by writing 1's to the
IRQ*_CLR register. Existing code is broken because it instead writes
zeros to IRQ*_SET register.

Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
dwc3_omap_write_irq0_clr() which do the right thing.

Signed-off-by: George Cherian george.cher...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 172d64e..52e0c4e 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -205,6 +205,18 @@ static void dwc3_omap_write_irq0_set(struct dwc3_omap 
*omap, u32 value)
omap-irq0_offset, value);
 }
 
+static void dwc3_omap_write_irqmisc_clr(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_CLR_MISC +
+   omap-irqmisc_offset, value);
+}
+
+static void dwc3_omap_write_irq0_clr(struct dwc3_omap *omap, u32 value)
+{
+   dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_CLR_0 -
+   omap-irq0_offset, value);
+}
+
 static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
enum omap_dwc3_vbus_id_status status)
 {
@@ -345,9 +357,23 @@ static void dwc3_omap_enable_irqs(struct dwc3_omap *omap)
 
 static void dwc3_omap_disable_irqs(struct dwc3_omap *omap)
 {
+   u32 reg;
+
/* disable all IRQs */
-   dwc3_omap_write_irqmisc_set(omap, 0x00);
-   dwc3_omap_write_irq0_set(omap, 0x00);
+   reg = USBOTGSS_IRQO_COREIRQ_ST;
+   dwc3_omap_write_irq0_clr(omap, reg);
+
+   reg = (USBOTGSS_IRQMISC_OEVT |
+   USBOTGSS_IRQMISC_DRVVBUS_RISE |
+   USBOTGSS_IRQMISC_CHRGVBUS_RISE |
+   USBOTGSS_IRQMISC_DISCHRGVBUS_RISE |
+   USBOTGSS_IRQMISC_IDPULLUP_RISE |
+   USBOTGSS_IRQMISC_DRVVBUS_FALL |
+   USBOTGSS_IRQMISC_CHRGVBUS_FALL |
+   USBOTGSS_IRQMISC_DISCHRGVBUS_FALL |
+   USBOTGSS_IRQMISC_IDPULLUP_FALL);
+
+   dwc3_omap_write_irqmisc_clr(omap, reg);
 }
 
 static u64 dwc3_omap_dma_mask = DMA_BIT_MASK(32);
-- 
1.8.3.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 2/2] usb: musb: Fix getting a generic phy for musb_dsps

2015-02-08 Thread George Cherian


Hi Tony,
On 02/06/2015 10:53 PM, Tony Lindgren wrote:

* George Cherian george.cher...@ti.com [150206 05:05]:

Hi Tony,

You also need to add similar things in dsps_musb_reset();

Otherwise you might not recover from a BABBLE condition.

Thank I totally missed that, updated patch below.

Do you have some testcase that easily triggers BABBLE
on MUSB?

On a BBB or BBW you can connect a HUB with multiple device connected on HUB.
Then do a repeated Connect and Disconnect of the HUB, This should 
trigger a BABBLE interrupt.

Not all HUB's might not lead you to a BABBLE condition.


Regards,

Tony

8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 4 Feb 2015 06:28:49 -0800
Subject: [PATCH] usb: musb: Fix getting a generic phy for musb_dsps

We still have a combination of legacy phys and generic phys in
use so we need to support both types of phy for musb_dsps.c.

Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -457,12 +457,27 @@ static int dsps_musb_init(struct musb *musb)
if (IS_ERR(musb-xceiv))
return PTR_ERR(musb-xceiv);
  
+	musb-phy = devm_phy_get(dev-parent, usb2-phy);

+
/* Returns zero if e.g. not clocked */
rev = dsps_readl(reg_base, wrp-revision);
if (!rev)
return -ENODEV;
  
  	usb_phy_init(musb-xceiv);

+   if (IS_ERR(musb-phy))  {
+   musb-phy = NULL;
+   } else {
+   ret = phy_init(musb-phy);
+   if (ret  0)
+   return ret;
+   ret = phy_power_on(musb-phy);
+   if (ret) {
+   phy_exit(musb-phy);
+   return ret;
+   }
+   }
+
setup_timer(glue-timer, otg_timer, (unsigned long) musb);
  
  	/* Reset the musb */

@@ -502,6 +517,8 @@ static int dsps_musb_exit(struct musb *musb)
  
  	del_timer_sync(glue-timer);

usb_phy_shutdown(musb-xceiv);
+   phy_power_off(musb-phy);
+   phy_exit(musb-phy);
debugfs_remove_recursive(glue-dbgfs_root);
  
  	return 0;

@@ -610,7 +627,7 @@ static int dsps_musb_reset(struct musb *musb)
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
const struct dsps_musb_wrapper *wrp = glue-wrp;
-   int session_restart = 0;
+   int session_restart = 0, error;
  
  	if (glue-sw_babble_enabled)

session_restart = sw_babble_control(musb);
@@ -624,8 +641,14 @@ static int dsps_musb_reset(struct musb *musb)
dsps_writel(musb-ctrl_base, wrp-control, (1  wrp-reset));
usleep_range(100, 200);
usb_phy_shutdown(musb-xceiv);
+   error = phy_power_off(musb-phy);
+   if (error)
+   dev_err(dev, phy shutdown failed: %i\n, error);
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+   error = phy_power_on(musb-phy);
+   if (error)
+   dev_err(dev, phy powerup failed: %i\n, error);
session_restart = 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 2/2] usb: musb: Fix getting a generic phy for musb_dsps

2015-02-06 Thread George Cherian


Hi Tony,

You also need to add similar things in dsps_musb_reset();

Otherwise you might not recover from a BABBLE condition.

On 02/05/2015 10:05 PM, Tony Lindgren wrote:

We still have a combination of legacy phys and generic phys in
use so we need to support both types of phy for musb_dsps.c.

Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
  drivers/usb/musb/musb_dsps.c | 17 +
  1 file changed, 17 insertions(+)

--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -457,12 +457,25 @@ static int dsps_musb_init(struct musb *musb)
if (IS_ERR(musb-xceiv))
return PTR_ERR(musb-xceiv);
  
+	musb-phy = devm_phy_get(dev-parent, usb2-phy);

+
/* Returns zero if e.g. not clocked */
rev = dsps_readl(reg_base, wrp-revision);
if (!rev)
return -ENODEV;
  
  	usb_phy_init(musb-xceiv);

+   if (IS_ERR(musb-phy))  {
+   musb-phy = NULL;
+   } else {
+   ret = phy_init(musb-phy);
+   if (ret  0)
+   return ret;
+   ret = phy_power_on(musb-phy);
+   if (ret)
+   return ret;
+   }
+
setup_timer(glue-timer, otg_timer, (unsigned long) musb);
  
  	/* Reset the musb */

@@ -502,6 +515,10 @@ static int dsps_musb_exit(struct musb *musb)
  
  	del_timer_sync(glue-timer);

usb_phy_shutdown(musb-xceiv);
+   if (musb-phy) {
+   phy_power_off(musb-phy);
+   phy_exit(musb-phy);
+   }
debugfs_remove_recursive(glue-dbgfs_root);
  
  	return 0;

-George

--
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

1 2 3 >

1 - 100 of 238 matches

Mail list logo