Re: Q: Does mass storage gadget use DMA ?

2018-02-05 Thread Felipe Balbi 

Hi,

Ran Shalit  writes:
> Hello,
>
> I check code in:
> https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c
> but I see no API usage of DMA, yet it is being mentioned as if it is used.

but it is used. It's just managed by the UDC driver (dwc3, musb,
chipidea, Renesas, etc)

-- 
balbi
--
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: Q: Does mass storage gadget use DMA ?

2018-02-05 Thread Felipe Balbi 

Hi,

Felipe Balbi  writes:
>> I check code in:
>> https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c

ps: v3.3 realy??? You really need to upgrade that :-)

-- 
balbi
--
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: power management problems in ehci-omap

2018-02-05 Thread Andreas Kemnade 
On Sun, 4 Feb 2018 09:43:45 +0100
Michael Nazzareno Trimarchi  wrote:

> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  wrote:
> > On Sun, 4 Feb 2018 00:10:50 +0100
> > Michael Nazzareno Trimarchi  wrote:
> >  
> >> Hi
> >>
> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
> >> wrote:  
> >> > Hi,
> >> >
> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece to 
> >> > analyze
> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
> >> > also rmmod ehci-omap does not let it go down at all.
> >> >
> >> > I expect that removing hardware does the same thing  
> > nonsense sentence from me, was to tired. I would expect that removing the 
> > modules
> > properly powers down the device.  
> >> >
> >> > Also suspend current increases by around 15mA if that module is loaded.
> >> > I tested with having everything disabled which is attached to that usb 
> >> > bus.
> >> >  
> >>
> >> Do you have an LTE connected to the usb?
> >>  
> > Yes, there is a UMTS modem attached, but it was off during the tests.
> > It did not enumerate on the modem.
> >  
> 
> Just to understand if the suspend current drop was connected to the
> suspend of lte modem on your side.
> So you don't have anything connected on usb bus?
>
rechecked with a board with really nothing connected there
Same behaviour

Regards,
Andreas


pgp88x2cyZoxE.pgp
Description: OpenPGP digital signature

Re: [PATCH 00/17] usb: dwc2: improvements

2018-02-05 Thread John Youn 

On 01/19/2018 02:39 AM, Grigor Tovmasyan wrote:

This series contains patches which are already have been sent in
"usb: dwc2: fixes, enhancements and new features" series.

That patch series was too large, and based on community feedbacks decided to
split that series into small pieces. This is a second part.

In this series we included only improvements for dwc2 driver, such as moving
functions or deleting unused parts of code.

Patches 2-3 and 14-17 are logically linked.

All patches were tested on HAPS-DX7 platform.


Changes after first submission:

usb: dwc2: Set AHB burst size to INCR
 
 Because of containing two non-related modifications this patch divided into two patches:

 - "usb: dwc2: Set AHB burst size to INCR"
 - "usb: dwc2: Use AHB burst size parameter"

"usb: dwc2: pci: Fix error handling in dwc2_pci_probe"
 
 Divided into 4 patches:

 - "usb: dwc2: pci: Handle error cleanup in probe"
 - "usb: dwc2: pci: Move devm_kzalloc() before platform_device_add()"
 - "usb: dwc2: pci: Move usb_phy_generic_register()"
 - "usb: dwc2: pci: Replace kzalloc() with devm_kzalloc()"

"usb: dwc2: Update bit polling functionality":
 
 - This patch is a merging of "usb: dwc2: Move polling function to core.c."

   and "usb: dwc2: Use common polling function.".
 - Added dwc2_hsotg_wait_bit_clear() function, because in some cases,
   we should wait for bit would be cleared not set.
  


usb: dwc2: host: Fix transaction errors in host mode

 - Renamed patch name from "usb: dwc2: host: Setting TOUTCAL and USBTRDTIM 
fields in host mode".
 - Removed programming of USBTRDTIM bitfiled, because this field available
   only in Device mode.
 - Added comment with description of TOUTCAL bitfiled in comment.
 - In description added platforms for which this patch fixes transactions 
error.


usb: dwc2: Change TxFIFO and RxFIFO flushing flow

 Rewritten loop for waiting AHB master in IDLE state.





Grigor Tovmasyan (2):
   usb: dwc2: Delete unused functionality
   usb: dwc2: Make dwc2_force_mode() static

Minas Harutyunyan (3):
   usb: dwc2: hcd: Fix host channel halt flow
   usb: dwc2: host: Fix transaction errors in host mode
   usb: dwc2: Change TxFIFO and RxFIFO flushing flow

Razmik Karapetyan (7):
   usb: dwc2: Use AHB burst size parameter
   usb: dwc2: Set AHB burst size to INCR
   usb: dwc2: Update dwc2_handle_incomplete_isoc_in() function
   usb: dwc2: Update dwc2_handle_incomplete_isoc_out() function
   usb: dwc2: Update GINTSTS_GOUTNAKEFF interrupt handling
   usb: dwc2: Rename bit set/clear function names
   usb: dwc2: Remove unnecessary debug prints

Sevak Arakelyan (1):
   usb: dwc2: Update bit polling functionality

Vardan Mikayelyan (4):
   usb: dwc2: pci: Replace kzalloc() with devm_kzalloc()
   usb: dwc2: pci: Move usb_phy_generic_register()
   usb: dwc2: pci: Move devm_kzalloc() before platform_device_add()
   usb: dwc2: pci: Handle error cleanup in probe

  drivers/usb/dwc2/core.c   | 120 +---
  drivers/usb/dwc2/core.h   |  25 ++---
  drivers/usb/dwc2/gadget.c | 116 +++
  drivers/usb/dwc2/hcd.c| 136 +-
  drivers/usb/dwc2/hcd.h|  56 ---
  drivers/usb/dwc2/params.c |   2 +-
  drivers/usb/dwc2/pci.c|  27 +
  7 files changed, 189 insertions(+), 293 deletions(-)



For this series:

Acked-by: John Youn 

John
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] usb: dwc2: minor fixes

2018-02-05 Thread John Youn 

On 01/16/2018 04:03 AM, Grigor Tovmasyan wrote:

This series contains patches which are already have been sent in
"usb: dwc2: fixes, enhancements and new features" series.

That patch series was too large, and based on community feedbacks decided to
split that series into small pieces. This is a first one.

In this series we included only minor fixes for dwc2 driver.

All patches were tested on HAPS-DX7 platform.


Changes after first submission:

usb: dwc2: Add safety check in setting of descriptor chain pointer
   
 Updated description of patch.





Gevorg Sahakyan (1):
   usb: dwc2: Remove version check in GSNPSID

Minas Harutyunyan (2):
   usb: dwc2: Add safety check in setting of descriptor chain pointers
   usb: dwc2: Add safety check for STSPHSERCVD intr

Vardan Mikayelyan (3):
   usb: dwc2: Fix dwc2_hsotg_core_init_disconnected()
   usb: dwc2: eliminate irq parameter from dwc2_gadget_init
   usb: dwc2: Force mode optimizations

  drivers/usb/dwc2/core.c | 61 +++--
  drivers/usb/dwc2/core.h | 13 ++
  drivers/usb/dwc2/gadget.c   | 33 +---
  drivers/usb/dwc2/hcd.c  |  6 ++---
  drivers/usb/dwc2/hw.h   |  1 +
  drivers/usb/dwc2/params.c   | 23 ++---
  drivers/usb/dwc2/platform.c | 11 ++--
  7 files changed, 61 insertions(+), 87 deletions(-)




For this series:

Acked-by: John Youn 

John
--
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: dwc2: gadget: Use true and false for boolean values

2018-02-05 Thread John Youn 

On 01/23/2018 07:45 AM, Gustavo A. R. Silva wrote:

Assign true or false to boolean variables instead of an integer value.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
  drivers/usb/dwc2/gadget.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index e4c3ce0..1f684dd 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -116,10 +116,10 @@ static inline void dwc2_gadget_incr_frame_num(struct 
dwc2_hsotg_ep *hs_ep)
  {
hs_ep->target_frame += hs_ep->interval;
if (hs_ep->target_frame > DSTS_SOFFN_LIMIT) {
-   hs_ep->frame_overrun = 1;
+   hs_ep->frame_overrun = true;
hs_ep->target_frame &= DSTS_SOFFN_LIMIT;
} else {
-   hs_ep->frame_overrun = 0;
+   hs_ep->frame_overrun = false;
}
  }
  



+Felipe

Acked-by: John Youn 

Regards,
John
--
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: gadget: f_fs: get the correct address of comp_desc

2018-02-05 Thread Jack Pham 
Hi William,

On Mon, Feb 05, 2018 at 07:33:38PM +0800, William Wu wrote:
> Refer to the USB 3.0 spec '9.6.7 SuperSpeed Endpoint Companion',
> the companion descriptor follows the standard endpoint descriptor.
> This descriptor is only defined for SuperSpeed endpoints. The
> f_fs driver gets the address of the companion descriptor via
> 'ds + USB_DT_ENDPOINT_SIZE', and actually, the ds variable is
> a pointer to the struct usb_endpoint_descriptor, so the offset
> of the companion descriptor which we get is USB_DT_ENDPOINT_SIZE *
> sizeof(struct usb_endpoint_descriptor), the wrong offset is 63
> bytes. This cause out-of-bound with the following error log if
> CONFIG_KASAN and CONFIG_SLUB_DEBUG is enabled on Rockchip RK3399
> Evaluation Board.
> 
> android_work: sent uevent USB_STATE=CONNECTED
> configfs-gadget gadget: super-speed config #1: b
> ==
> BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x230/0x398
> Read of size 1 at addr ffc0ce2d0b10 by task irq/224-dwc3/364

> Memory state around the buggy address:
>  ffc0ce2d0a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffc0ce2d0a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  >ffc0ce2d0b00: 00 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ^
>  ffc0ce2d0b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffc0ce2d0c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==
> Disabling lock debugging due to kernel taint
> android_work: sent uevent USB_STATE=CONFIGURED
> 
> This patch adds struct usb_endpoint_descriptor * -> u8 * type conversion
> for ds variable, then we can get the correct address of comp_desc
> with offset USB_DT_ENDPOINT_SIZE bytes.
> 
> Signed-off-by: William Wu 
> ---
>  drivers/usb/gadget/function/f_fs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_fs.c 
> b/drivers/usb/gadget/function/f_fs.c
> index 6756472..f13ead0 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1882,8 +1882,8 @@ static int ffs_func_eps_enable(struct ffs_function 
> *func)
>   ep->ep->desc = ds;
>  
>   if (needs_comp_desc) {
> - comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
> - USB_DT_ENDPOINT_SIZE);
> + comp_desc = (struct usb_ss_ep_comp_descriptor *)
> +  ((u8 *)ds + USB_DT_ENDPOINT_SIZE);
>   ep->ep->maxburst = comp_desc->bMaxBurst + 1;
>   ep->ep->comp_desc = comp_desc;
>   }

Please see my alternative fix for this. I proposed changing this
function to use config_ep_by_speed() instead.

https://www.spinics.net/lists/linux-usb/msg165149.html

Jack
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: uas: device reset most the time while enumeration- usb3.0

2018-02-05 Thread Tushar Nimkar 
Greg,

I have cherry-picked 9 patches as follows.


d921462 USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID

d7321ce uas: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069

b3568a9 uas: Always apply US_FL_NO_ATA_1X quirk to Seagate devices

66215a3 USB: uas: fix bug in handling of alternate settings

34ce628 scsi: uas: move eh_bus_reset_handler to eh_device_reset_handler

c5afd93 uas: remove can_queue set in host template

75b8da4 USB: uas: add full support for RESPONSE IU

befea02 uas: no gfp argument to uas_submit_urbs()

849b7c6 uas: use the BIT() macro




I will try and update the same if possible to duplicate this on 4.14.14 or 4.15

On Mon, Feb 5, 2018 at 11:40 PM, Greg KH  wrote:
> On Mon, Feb 05, 2018 at 11:34:40PM +0530, Tushar Nimkar wrote:
>> Hi ,
>>
>> I am enabling uas support. And facing the issue as follows.
>>
>> I have observed that when ( Transcend StoreJet TS256GESD400K )
>> connected to my custom board,  it detects first then
>> uas_eh_abort_handler() get call and then reset and enumerates
>> properly.When same device is used with 2.0 HUB their is no such issue.
>>
>>
>> logs-->Super-speed
>>
>>  [  323.912384] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
>> [  323.947103] scsi host1: uas
>> [  323.948153] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
>>   0PQ: 0 ANSI: 6
>> [  323.949825] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
>> (256 GB/238 GiB)
>> [  354.092341] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
>> inflight: CMD IN
>> [  354.092380] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 00 00 40 00
>> [  354.098922] scsi host1: uas_eh_device_reset_handler start
>> [  354.104963] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
>> disabled endpoint or incorrect stream ring
>> [  354.110095] xhci-hcd xhci-hcd.0.auto: @7d41f750 
>>  1b00 01078001
>> [  354.232398] usb 2-1: reset SuperSpeed USB device number 3 using xhci-hcd
>> [  354.253844] scsi host1: uas_eh_device_reset_handler success
>> [  354.263222] sd 1:0:0:0: [sda] Write Protect is off
>> [  354.263461] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [  354.267036] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
>> disabled endpoint or incorrect stream ring
>> [  354.275847] xhci-hcd xhci-hcd.0.auto: @7d41fa00 
>>  1b00 01038001
>> [  354.287566]  sda: sda1 sda2
>> [  354.295407] sd 1:0:0:0: [sda] Attached SCSI disk
>>
>> logs-->checked with 2.0 hub(same device)
>>
>> [  104.292324] usb 3-1: new high-speed USB device number 2 using xhci-hcd
>> [  104.457236] hub 3-1:1.0: USB hub found
>> [  104.457305] hub 3-1:1.0: 4 ports detected
>> [  105.392323] usb 3-1.4: new high-speed USB device number 3 using xhci-hcd
>> [  105.545492] scsi host1: uas
>> [  105.546777] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
>>   0PQ: 0 ANSI: 6
>> [  105.548876] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
>> (256 GB/238 GiB)
>> [  105.556591] sd 1:0:0:0: [sda] Write Protect is off
>> [  105.563321] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [  105.570685]  sda: sda1 sda2
>> [  105.579182] sd 1:0:0:0: [sda] Attached SCSI disk
>>
>>
>>
>> Digging into issue I found that blk_rq_timed_out_timer() gets calls
>> and which calls scsi_time_out() and further uas_eh_abort_handler().
>> [ blk_rq_timed_out_timer() --> blk_rq_check_expired()-->
>> scsi_times_out()-->scsi_abort_command()--> scmd_eh_abort_handler()-->
>> scsi_try_to_abort_cmd ()-->uas_eh_abort_handler() ]
>>
>> Also would like to add whenever we execute read_capacity_16() to read
>> the capacity of the device suddenly we are receiving
>> blk_rq_timed_out_timer() and around 30 sec device will reset and
>> enumerate.
>>
>> Also there are errors from xhci driver too.
>>
>>
>> Kernel : 4.4.60 and uas patches cherry-picked from kernel-4.14.13
>
> 4.4.60 is _really_ old and obsolete and insecure, and by randomly
> cherry-picking patches, we really have no idea what you are running.
>
> Can you duplicate this on 4.14.14?  4.15?
>
> thanks,
>
> greg k-h



-- 
Best Regards,
Tushar R Nimkar
Mob No : +91-9052258800
--
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: uas: device reset most the time while enumeration- usb3.0

2018-02-05 Thread Greg KH 
On Mon, Feb 05, 2018 at 11:34:40PM +0530, Tushar Nimkar wrote:
> Hi ,
> 
> I am enabling uas support. And facing the issue as follows.
> 
> I have observed that when ( Transcend StoreJet TS256GESD400K )
> connected to my custom board,  it detects first then
> uas_eh_abort_handler() get call and then reset and enumerates
> properly.When same device is used with 2.0 HUB their is no such issue.
> 
> 
> logs-->Super-speed
> 
>  [  323.912384] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
> [  323.947103] scsi host1: uas
> [  323.948153] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
>   0PQ: 0 ANSI: 6
> [  323.949825] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
> (256 GB/238 GiB)
> [  354.092341] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
> inflight: CMD IN
> [  354.092380] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 00 00 40 00
> [  354.098922] scsi host1: uas_eh_device_reset_handler start
> [  354.104963] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
> disabled endpoint or incorrect stream ring
> [  354.110095] xhci-hcd xhci-hcd.0.auto: @7d41f750 
>  1b00 01078001
> [  354.232398] usb 2-1: reset SuperSpeed USB device number 3 using xhci-hcd
> [  354.253844] scsi host1: uas_eh_device_reset_handler success
> [  354.263222] sd 1:0:0:0: [sda] Write Protect is off
> [  354.263461] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [  354.267036] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
> disabled endpoint or incorrect stream ring
> [  354.275847] xhci-hcd xhci-hcd.0.auto: @7d41fa00 
>  1b00 01038001
> [  354.287566]  sda: sda1 sda2
> [  354.295407] sd 1:0:0:0: [sda] Attached SCSI disk
> 
> logs-->checked with 2.0 hub(same device)
> 
> [  104.292324] usb 3-1: new high-speed USB device number 2 using xhci-hcd
> [  104.457236] hub 3-1:1.0: USB hub found
> [  104.457305] hub 3-1:1.0: 4 ports detected
> [  105.392323] usb 3-1.4: new high-speed USB device number 3 using xhci-hcd
> [  105.545492] scsi host1: uas
> [  105.546777] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
>   0PQ: 0 ANSI: 6
> [  105.548876] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
> (256 GB/238 GiB)
> [  105.556591] sd 1:0:0:0: [sda] Write Protect is off
> [  105.563321] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [  105.570685]  sda: sda1 sda2
> [  105.579182] sd 1:0:0:0: [sda] Attached SCSI disk
> 
> 
> 
> Digging into issue I found that blk_rq_timed_out_timer() gets calls
> and which calls scsi_time_out() and further uas_eh_abort_handler().
> [ blk_rq_timed_out_timer() --> blk_rq_check_expired()-->
> scsi_times_out()-->scsi_abort_command()--> scmd_eh_abort_handler()-->
> scsi_try_to_abort_cmd ()-->uas_eh_abort_handler() ]
> 
> Also would like to add whenever we execute read_capacity_16() to read
> the capacity of the device suddenly we are receiving
> blk_rq_timed_out_timer() and around 30 sec device will reset and
> enumerate.
> 
> Also there are errors from xhci driver too.
> 
> 
> Kernel : 4.4.60 and uas patches cherry-picked from kernel-4.14.13

4.4.60 is _really_ old and obsolete and insecure, and by randomly
cherry-picking patches, we really have no idea what you are running.

Can you duplicate this on 4.14.14?  4.15?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

usb: uas: device reset most the time while enumeration- usb3.0

2018-02-05 Thread Tushar Nimkar 
Hi ,

I am enabling uas support. And facing the issue as follows.

I have observed that when ( Transcend StoreJet TS256GESD400K )
connected to my custom board,  it detects first then
uas_eh_abort_handler() get call and then reset and enumerates
properly.When same device is used with 2.0 HUB their is no such issue.


logs-->Super-speed

 [  323.912384] usb 2-1: new SuperSpeed USB device number 3 using xhci-hcd
[  323.947103] scsi host1: uas
[  323.948153] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
  0PQ: 0 ANSI: 6
[  323.949825] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
(256 GB/238 GiB)
[  354.092341] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
inflight: CMD IN
[  354.092380] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 00 00 40 00
[  354.098922] scsi host1: uas_eh_device_reset_handler start
[  354.104963] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
disabled endpoint or incorrect stream ring
[  354.110095] xhci-hcd xhci-hcd.0.auto: @7d41f750 
 1b00 01078001
[  354.232398] usb 2-1: reset SuperSpeed USB device number 3 using xhci-hcd
[  354.253844] scsi host1: uas_eh_device_reset_handler success
[  354.263222] sd 1:0:0:0: [sda] Write Protect is off
[  354.263461] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  354.267036] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
disabled endpoint or incorrect stream ring
[  354.275847] xhci-hcd xhci-hcd.0.auto: @7d41fa00 
 1b00 01038001
[  354.287566]  sda: sda1 sda2
[  354.295407] sd 1:0:0:0: [sda] Attached SCSI disk

logs-->checked with 2.0 hub(same device)

[  104.292324] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[  104.457236] hub 3-1:1.0: USB hub found
[  104.457305] hub 3-1:1.0: 4 ports detected
[  105.392323] usb 3-1.4: new high-speed USB device number 3 using xhci-hcd
[  105.545492] scsi host1: uas
[  105.546777] scsi 1:0:0:0: Direct-Access StoreJet TS256GESD400K
  0PQ: 0 ANSI: 6
[  105.548876] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks:
(256 GB/238 GiB)
[  105.556591] sd 1:0:0:0: [sda] Write Protect is off
[  105.563321] sd 1:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[  105.570685]  sda: sda1 sda2
[  105.579182] sd 1:0:0:0: [sda] Attached SCSI disk



Digging into issue I found that blk_rq_timed_out_timer() gets calls
and which calls scsi_time_out() and further uas_eh_abort_handler().
[ blk_rq_timed_out_timer() --> blk_rq_check_expired()-->
scsi_times_out()-->scsi_abort_command()--> scmd_eh_abort_handler()-->
scsi_try_to_abort_cmd ()-->uas_eh_abort_handler() ]

Also would like to add whenever we execute read_capacity_16() to read
the capacity of the device suddenly we are receiving
blk_rq_timed_out_timer() and around 30 sec device will reset and
enumerate.

Also there are errors from xhci driver too.


Kernel : 4.4.60 and uas patches cherry-picked from kernel-4.14.13

Do we have such issue present in the upstream too?
Please help in solving this issue.Any inputs will be helpful.
Eager to solve this.

Best Regards
Tushar R. Nimkar
--
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 4.4 v2 2/2] usbip: fix 3eee23c3ec14 tcp_socket address still in the status file

2018-02-05 Thread Shuah Khan 
Commit 3eee23c3ec14 ("usbip: prevent vhci_hcd driver from leaking a
socket pointer address") backported the following commit from mailine.
However, backport error caused the tcp_socket address to still leak.

commit 2f2d0088eb93 ("usbip: prevent vhci_hcd driver from leaking a
socket pointer address")

When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the

/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.

Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from
socket pointer address by looking up /proc/net/{tcp,tcp6}.

As this opens a security hole, the fix replaces socket pointer address
with sockfd.

Reported-by: Eric Biggers 
Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/vhci_sysfs.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index 1c7f41a65565..b9432fdec775 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -53,7 +53,7 @@ static ssize_t status_show(struct device *dev, struct 
device_attribute *attr,
 * a security hole, the change is made to use sockfd instead.
 */
out += sprintf(out,
-  "prt sta spd bus dev sockfd local_busid\n");
+  "prt sta spd dev  sockfd local_busid\n");
 
for (i = 0; i < VHCI_NPORTS; i++) {
struct vhci_device *vdev = port_to_vdev(i);
@@ -64,12 +64,11 @@ static ssize_t status_show(struct device *dev, struct 
device_attribute *attr,
if (vdev->ud.status == VDEV_ST_USED) {
out += sprintf(out, "%03u %08x ",
   vdev->speed, vdev->devid);
-   out += sprintf(out, "%16p ", vdev->ud.tcp_socket);
-   out += sprintf(out, "%06u", vdev->ud.sockfd);
+   out += sprintf(out, "%06u ", vdev->ud.sockfd);
out += sprintf(out, "%s", dev_name(>udev->dev));
 
} else
-   out += sprintf(out, "000 000 000 00 0-0");
+   out += sprintf(out, "000  00 0-0");
 
out += sprintf(out, "\n");
spin_unlock(>ud.lock);
-- 
2.14.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 4.4 v2 1/2] usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit

2018-02-05 Thread Shuah Khan 
Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
support")

vhci_hcd clears all the bits port_status bits instead of clearing
just the USB_PORT_STAT_POWER bit when it handles ClearPortFeature:
USB_PORT_FEAT_POWER. This causes vhci_hcd attach to fail in a bad
state, leaving device unusable by the client. The device is still
attached and however client can't use it.

The problem was fixed as part of larger change to add USB3 Super Speed
support.

This patch isolates the one line fix to clear the USB_PORT_STAT_POWER
from the original patch.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/vhci_hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 00d68945548e..2d96bfd34138 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -285,7 +285,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
case USB_PORT_FEAT_POWER:
usbip_dbg_vhci_rh(
" ClearPortFeature: USB_PORT_FEAT_POWER\n");
-   dum->port_status[rhport] = 0;
+   dum->port_status[rhport] &= ~USB_PORT_STAT_POWER;
dum->resuming = 0;
break;
case USB_PORT_FEAT_C_RESET:
-- 
2.14.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 4.4 v2 0/2] Backports for fixes

2018-02-05 Thread Shuah Khan 
The first patch in this series isolates and backports a fix to clear
just the USB_PORT_STAT_POWER. Without this fix, client can't use the
imported device.

The second patch is fix to back-ported commit 3eee23c3ec14. tcp_socket
address still present in the status file. This is my bad. The bug fixed
in the first patch in this series masked this bug. With these two fixes,
client can use the imported devices on 4.4

Eric Biggers also reported the tcp_socket address still in the status
file while I am getting the patch ready. I added him to Reported-by.

Shuah Khan (2):
  usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit
  usbip: fix 3eee23c3ec14 tcp_socket address still in the status file

 drivers/usb/usbip/vhci_hcd.c   | 2 +-
 drivers/usb/usbip/vhci_sysfs.c | 7 +++
 2 files changed, 4 insertions(+), 5 deletions(-)

-- 
2.14.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 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

2018-02-05 Thread Rafael J. Wysocki 

On 2/5/2018 3:14 PM, Bjørn Mork wrote:

"Rafael J. Wysocki"  writes:

On 2/4/2018 9:28 PM, Bjørn Mork wrote:


But I do wonder if the attached (completely untested!!) patch makes
things any better?

I don't think so, the macro is needed too.

Doh! Obviously.  Don't know how I managed to miss that.


I'll queue up a full revert of 662591461c4b9a1e3b.

Still with the additional exception for "ec == first_ec"?



No, just a full revert for now.

The above can be fixed on top of that.

Thanks,
Rafael

--
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: [PATH 0/4] usbip: make vhci_hcd.* objects independent of vhci_hcd.0

2018-02-05 Thread Shuah Khan 
On 01/30/2018 01:36 AM, Salvador Fandino wrote:
> Let me start by explaining the problem that have motivated me to write
> this patches:
> 
> I work on the QVD, a virtual desktop platform for Linux. This software
> runs Linux desktops (i.e. XFCE, KDE) and their applications inside LXC
> containers, and makes then available through the network to remote
> users.
> 
> Supporting USB devices is a common feature customers have been
> requesting us for a long time (in order to use, for instance, remote
> signature pads, bar-code scanners, fingerprint readers, etc.). So, we
> have been working on that feature using the USB/IP layer on the
> kernel.
> 
> Connecting and disconnecting devices and transferring data works
> seamless for the devices listed above. But we also want to make the
> usbip operations private to the container where they are run.  For
> instance, it is unacceptable for our product, that one user could list
> the devices connected by other users or access them.
> 
> We can control how can access every device using cgroups once those
> are attached, but the usbip layer is not providing any mechanism for
> controlling who can attach, detach or list the devices.
> 
> So, we got the idea that in order to enforce that remote usbip devices
> are only visible inside the container where they were imported, we
> could conveniently mount-bind inside every container just one of the
> vhci_hcd directories below /sys/devices/platform. So that it is as if
> every container had a vhci_hcd just for itself (and also, we restrict
> access to the matching USB ports in cgroups).
> 
> Unfortunately, all the vhci_hcd.* devices are controlled through
> attributes in vhci_hcd.0 making our approach fail and so... well, that
> is what this patch series changes. It makes every vhci_hcd device
> controllable through attributes inside its own sysfs directory.
> 
> The first patch, does that in the kernel, and the second and third
> patches change user space, adapting the libusbip and the usbip tools
> code respectively.
> 
> Then there is a fourth patch, that allows to create much more USB
> hubs per machine. It was limited to 64 and we are running thousands of
> containers (every one requiring a hub) per host.
> 
> These changes are not completely backward compatible. In the sysfs
> side, besides moving around the attribute files, now the port numbers
> go from 0 to CONFIG_USBIP_VHCI_HC_PORTS * 2 - 1 and are reused for
> every vhci_hcd device. I could have maintained the absolute numeration
> but I think reusing the numbers is a better and simpler approach.
> 
> I have considered that until very recently, support for vhci_hcd
> devices above the .0 was broken in the uspip tools (see
> 1ac7c8a78be85f84b019d3d2742d1a9f07255cc5 "usbip: fix usbip attach to
> find a port that matches the requested speed") and that has been the
> place where I have set the bar for backward compatibility: usage of
> the tools must remain unchanged for accessing "vhci_hcd.0", but may
> require changes otherwise. The same is true for the library functions
> which now provides new functions for selecting the target vhci_hcd
> device. The old functions now always target "vhci_hcd.0".
> 
> So, for instance, now, "usbip port" by default only shows "vhci_hcd.0"
> ports but "usbip port -a" shows all of them, and, for instance, "usbip
> port -i 4", shows the ports in "vhci_hcd.4".
> 
> Cheers.
> 

I will take a look at these in the next week or so.

thanks,
-- Shuah

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

Q: Does mass storage gadget use DMA ?

2018-02-05 Thread Ran Shalit 
Hello,

I check code in:
https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c
but I see no API usage of DMA, yet it is being mentioned as if it is used.
Is it that DMA used in this driver ? Why can't I find any DMA APIs inside?

Thank you,
Ran
--
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/1] usb: host: ehci: always enable interrupt for qtd completion at test mode

2018-02-05 Thread Alan Stern 
On Mon, 5 Feb 2018, Peter Chen wrote:

> At former code, the SETUP stage does not enable interrupt
> for qtd completion, it relies on IAA watchdog to complete
> interrupt, then the transcation would be considered timeout
> if the flag need_io_watchdog is cleared by platform code.
> 
> In this commit, we always add enable interrupt for qtd completion,
> then the qtd completion can be notified by hardware interrupt.
> 
> Signed-off-by: Peter Chen 
> ---
> Changes for v2:
> - Add flag "QTD_IOC" in parameter for qtd_fill

Acked-by: 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: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

2018-02-05 Thread Bjørn Mork 
"Rafael J. Wysocki"  writes:
> On 2/4/2018 9:28 PM, Bjørn Mork wrote:
>
>> But I do wonder if the attached (completely untested!!) patch makes
>> things any better?
>
> I don't think so, the macro is needed too.

Doh! Obviously.  Don't know how I managed to miss that.

> I'll queue up a full revert of 662591461c4b9a1e3b.

Still with the additional exception for "ec == first_ec"?



Bjørn
--
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: gadget: f_fs: get the correct address of comp_desc

2018-02-05 Thread William Wu 
Refer to the USB 3.0 spec '9.6.7 SuperSpeed Endpoint Companion',
the companion descriptor follows the standard endpoint descriptor.
This descriptor is only defined for SuperSpeed endpoints. The
f_fs driver gets the address of the companion descriptor via
'ds + USB_DT_ENDPOINT_SIZE', and actually, the ds variable is
a pointer to the struct usb_endpoint_descriptor, so the offset
of the companion descriptor which we get is USB_DT_ENDPOINT_SIZE *
sizeof(struct usb_endpoint_descriptor), the wrong offset is 63
bytes. This cause out-of-bound with the following error log if
CONFIG_KASAN and CONFIG_SLUB_DEBUG is enabled on Rockchip RK3399
Evaluation Board.

android_work: sent uevent USB_STATE=CONNECTED
configfs-gadget gadget: super-speed config #1: b
==
BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x230/0x398
Read of size 1 at addr ffc0ce2d0b10 by task irq/224-dwc3/364

CPU: 4 PID: 364 Comm: irq/224-dwc3 Not tainted 4.4.112 #6
Hardware name: Rockchip RK3399 Evaluation Board v3 (Android) (DT)
Call trace:
[] dump_backtrace+0x0/0x244
[] show_stack+0x14/0x1c
[] dump_stack+0xa4/0xcc
[] print_address_description+0xa4/0x308
[] kasan_report+0x258/0x29c
[] __asan_load1+0x44/0x4c
[] ffs_func_set_alt+0x230/0x398
[] composite_setup+0xdcc/0x1ac8
[] android_setup+0x124/0x1a0
[] dwc3_ep0_delegate_req+0x48/0x68
[] dwc3_ep0_interrupt+0x758/0x1174
[] dwc3_thread_interrupt+0x204/0xe68
[] irq_thread_fn+0x44/0x94
[] irq_thread+0x128/0x22c
[] kthread+0x11c/0x130
[] ret_from_fork+0x10/0x30

Allocated by task 1:
[] save_stack_trace_tsk+0x0/0x134
[] save_stack_trace+0x14/0x1c
[] kasan_kmalloc.part.3+0x48/0xf4
[] kasan_kmalloc+0x8c/0xa0
[] __kmalloc+0x208/0x268
[] ffs_func_bind+0x4b4/0x918
[] usb_add_function+0xd8/0x1d4
[] configfs_composite_bind+0x48c/0x570
[] udc_bind_to_driver+0x6c/0x170
[] usb_udc_attach_driver+0xa4/0xd0
[] gadget_dev_desc_UDC_store+0xd4/0x120
[] configfs_write_file+0x1a0/0x1f8
[] __vfs_write+0x64/0x174
[] vfs_write+0xe4/0x1e8
[] SyS_write+0x68/0xc8
[] el0_svc_naked+0x24/0x28

Freed by task 0:
(stack is not available)

The buggy address belongs to the object at ffc0ce2d0900
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 528 bytes inside of
 1024-byte region [ffc0ce2d0900, ffc0ce2d0d00)
The buggy address belongs to the page:
page:ffbdc338b400 count:1 mapcount:-2145648611 mapping:  (null) 
index:0x0
flags: 0x4080(slab|head)
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffc0ce2d0a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffc0ce2d0a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 >ffc0ce2d0b00: 00 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ^
 ffc0ce2d0b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffc0ce2d0c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==
Disabling lock debugging due to kernel taint
android_work: sent uevent USB_STATE=CONFIGURED

This patch adds struct usb_endpoint_descriptor * -> u8 * type conversion
for ds variable, then we can get the correct address of comp_desc
with offset USB_DT_ENDPOINT_SIZE bytes.

Signed-off-by: William Wu 
---
 drivers/usb/gadget/function/f_fs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 6756472..f13ead0 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1882,8 +1882,8 @@ static int ffs_func_eps_enable(struct ffs_function *func)
ep->ep->desc = ds;
 
if (needs_comp_desc) {
-   comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
-   USB_DT_ENDPOINT_SIZE);
+   comp_desc = (struct usb_ss_ep_comp_descriptor *)
+((u8 *)ds + USB_DT_ENDPOINT_SIZE);
ep->ep->maxburst = comp_desc->bMaxBurst + 1;
ep->ep->comp_desc = comp_desc;
}
-- 
2.0.0


--
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 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

2018-02-05 Thread Rafael J. Wysocki 

On 2/4/2018 9:28 PM, Bjørn Mork wrote:

Greg KH  writes:

On Sat, Feb 03, 2018 at 07:25:54PM +0100, Markus Demleitner wrote:


It's 662591461c4b9a1e3b9b159dbf37648a585ebaae.  To my eyes, it even
looks plausible that it's causing the problematic behaviour, but
since I can't say I understand what I'd be doing if I dabbled with
the change, I've refrained from guessing how to fix it.

I'm happy to try patches, though.

Ok, thanks.  I've added the authors of this patch to the email here,
perhaps they have an idea of what is going on?

This thing made me curious enough to dive into code I don't understand,
as I have experienced the annoying crazy fan behaviour in resume a few
times on my X1 Carbon 4th gen.

Maybe I missed something, but it looks like commit

  c3a696b6e8f8 ("ACPI / EC: Use busy polling mode when GPE is not enabled")

introduced suspend/resume busy polling for the "boot EC" unintentionally?

The patch moved acpi_ec_leave_noirq() and acpi_ec_leave_noirq()
functions outside the #ifdef CONFIG_PM_SLEEP, so they could be reused
while installing handlers.  But when doing that the

if (ec == first_ec)

conditions on suspend/resume were silently dropped.  I assume the
intention might have been to move those intto acpi_ec_suspend_noirq()
and acpi_ec_resume_noirq() instead? But that didn't happen AFAICS.

Or did I misunderstand this completely?  Not unlikely given that I have
zero clue about what this code is doing...

But I do wonder if the attached (completely untested!!) patch makes
things any better?


I don't think so, the macro is needed too.

I'll queue up a full revert of 662591461c4b9a1e3b.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v4 0/7] typec: tcpm: Add sink side support for PPS

2018-02-05 Thread Adam Thomson 
On 30 January 2018 13:25, Heikki Krogerus wrote:

> On Tue, Jan 02, 2018 at 03:50:48PM +, Adam Thomson wrote:
> > This patch set adds sink side support for the PPS feature introduced in the
> > USB PD 3.0 specification.
> >
> > The source PPS supply is represented using the Power Supply framework to 
> > provide
> > access and control APIs for dealing with it's operating voltage and current,
> > and switching between a standard PDO and PPS APDO operation. During standard
> PDO
> > operation the voltage and current is read-only, but for APDO PPS these are
> > writable as well to allow for control.
> >
> > It should be noted that the keepalive for PPS is not handled within TCPM. 
> > The
> > expectation is that the external user will be required to ensure re-requests
> > occur regularly to ensure PPS remains and the source does not hard reset.
> 
> Sorry for the late reply. I don't have any major problems with these
> other than with 6/7. The documentation should be for the psy class,
> not tcpm. I'm also not comfortable with the "select POWER_SUPPLY", but
> if Guenter does not think it's a problem, I'm fine with it. I guess we
> can always, for example, introduce stubs for the power_supply*
> functions, and drop the dependency later.
> 
> But as usual with tcpm.c, Guenter needs to give his ACK.
> 
> Oh yes, and Sebastian needs to ACK the power_supply changes or course.

No problem. Thanks for your time reviewing this. Not the smallest patch set so
appreciate the effort spent. Was travelling last week, but should now have a bit
of free time to take a proper look at your comments and get back to you with
some meaningful responses.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

2018-02-05 Thread Andrzej Hajda 
On 05.02.2018 07:08, Rob Herring wrote:
> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
>> These bindings allow to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> v2:
>> - moved connector type(A,B,C) to compatible string (Rob),
>> - renamed size property to type (Rob),
>> - changed type description to be less confusing (Laurent),
>> - removed vendor specific compatibles (implied by graph port number),
> How so? More below...
>
>> - added requirement of connector being a child of IC (Rob),
>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>   by USB Controller in runtime, downside is that device is not able to
>>   report its real capabilities, maybe better would be to make it 
>> optional(?)),
>> - assigned port numbers to data buses (Rob).
>>
>> Regards
>> Andrzej
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  .../bindings/connector/usb-connector.txt   | 48 
>> ++
>>  1 file changed, 48 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> new file mode 100644
>> index ..02020f5d760a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,48 @@
>> +USB Connector
>> +=
>> +
>> +USB connector node represents physical USB connector. It should be
>> +a child of USB interface controller.
>> +
>> +Required properties:
>> +- compatible: describes type of the connector, must be one of:
>> +"usb-a-connector", "usb-b-connector", "usb-c-connector",
> Nit: one per line.
>
>> +
>> +Optional properties:
>> +- label: symbolic name for the connector
>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>> +  non-standard (large) connector sizes: "mini", "micro"
>> +
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the OF graph 
>> bindings
>> +  specified in bindings/graph.txt, unless the bus is between parent node and
>> +  the connector. Since single connector can have multpile data buses every 
>> bus
>> +  has assigned OF graph port number as follows:
>> +0: High Speed (HS), present in all connectors,
>> +1: Super Speed (SS), present in SS capable connectors,
>> +2: Sideband use (SBU), present in USB-C,
>> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
>> micro-USB
> This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
> That makes me think the Samsung connector should have its own compatible 
> string.

Do you mean, sth like:
    connector {
            compatible = "samsung,usb-connector-11pin";
            label = "micro-USB";
            ports {
                    #address-cells = <1>;
                    #size-cells = <0>;

                    port@3 {
                            reg = <3>;
                            musb_con_mhl_in: endpoint {
                                    remote-endpoint = <_out>;
                            };
                    };
    };

Or should I add "usb-b-connector" extra compatible and "type" property?
I slightly prefer my approach(less different bindings), but I am also OK
with the above.

>
> Can we go ahead and define the video modes of Type-C? Normally, if 2 
> data streams are mutually exclusive, then they are a single port with 2 
> endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
> port 3 is always video. We can still know what is mutually exclusive 
> based on the compatible. 

I am sorry, I do not understand what you mean. Port 3 is present only in
11-pin Samsung micro-USB, USB Type-C has only ports 0, 1, 2.
Here is list of possible ports depending on connector type:
- USB 2.0: HS
- 11-pin Samsung micro-USB: HS,MHL
- USB 3.x type A,B: HS,SS
- USB-C: HS,SS,SBU

All ports have separate lines, so they can work simultaneously.

And regarding MHL on standard micro-USB connector. MHL and MUIC will
share HS port, but there will be mux somewhere before connector:
- in MUIC, in this case MUIC will be the parent of the connector, and
there will be graph from MHL to MUIC to describe MHL link,
- in MHL, in this case MHL will be the parent of the connector, and
graph between MUIC and MHL to describe HS link,
- dedicated mux to MUIC and MHL, controlled by gpio pin, it could be
handled by MUIC's external-mux gpio property for example, or (probably)
less hacky by separate node for mux,
or as additional property in the connector (who should be the parent of
the connector

Re: power management problems in ehci-omap

2018-02-05 Thread Andreas Kemnade 
On Sun, 4 Feb 2018 11:55:02 +0100
Michael Nazzareno Trimarchi  wrote:

> Hi Andreas
> 
> On Sun, Feb 4, 2018 at 11:50 AM, Andreas Kemnade  wrote:
> > Hi,
> >
> > On Sun, 4 Feb 2018 09:43:45 +0100
> > Michael Nazzareno Trimarchi  wrote:
> >  
> >> Hi Andreas
> >>
> >> On Sun, Feb 4, 2018 at 9:38 AM, Andreas Kemnade  
> >> wrote:  
> >> > On Sun, 4 Feb 2018 00:10:50 +0100
> >> > Michael Nazzareno Trimarchi  wrote:
> >> >  
> >> >> Hi
> >> >>
> >> >> On Sun, Feb 4, 2018 at 12:03 AM, Andreas Kemnade  
> >> >> wrote:  
> >> >> > Hi,
> >> >> >
> >> >> > I booted a 4.15 kernel without udev and loaded modules piece by piece 
> >> >> > to analyze
> >> >> > pm problems. modprobe ehci-omap increases current by around 35mA and
> >> >> > also rmmod ehci-omap does not let it go down at all.
> >> >> >
> >> >> > I expect that removing hardware does the same thing  
> >> > nonsense sentence from me, was to tired. I would expect that removing 
> >> > the modules
> >> > properly powers down the device.  
> >> >> >
> >> >> > Also suspend current increases by around 15mA if that module is 
> >> >> > loaded.
> >> >> > I tested with having everything disabled which is attached to that 
> >> >> > usb bus.
> >> >> >  
> >> >>
> >> >> Do you have an LTE connected to the usb?
> >> >>  
> >> > Yes, there is a UMTS modem attached, but it was off during the tests.
> >> > It did not enumerate on the modem.
> >> >  
> >>
> >> Just to understand if the suspend current drop was connected to the
> >> suspend of lte modem on your side.
> >> So you don't have anything connected on usb bus?
> >>  
> > Suspend current is increased when the ehci-omap module is loaded
> > in comparison to the state. I tested with the modem disabled, so there
> > is nothing on the bus. Increased suspend current is one thing,
> > current_before_modprobe_ehci_omap != current_after_rmmod_ehci_omap.
> >
> > I am testing with init=some_testscript.sh, so no userspace
> > is doing strange things. No module autoload or something.
> >  

Ok, there is some heavy EBCAK involved. I just did an
echo rmmod
without a real rmmod. But the suspend thing is still valid.

Sorry for the confusion.

To avoid further confusion I have uploaded these two scripts
I have given to the kernel.
http://misc.andi.de1.cc/measure4.sh

output from that:
no modules: cur: 61047 delta: 61047
before: 423462
after: 421326
average 25632 uA over 300 seconds
 cur: 60333 delta: -714
+ehci-omap cur: 93712 delta: 33379
-ehci-omap cur: 60511 delta: -33201
before: 420792
after: 418656
average 25632 uA over 300 seconds


http://misc.andi.de1.cc/measure5.sh
output from that:

no modules: cur: 61225 delta: 61225
before: 427734
after: 425598
average 25717 uA over 299 seconds
 cur: 59797 delta: -1428
+ehci-omap cur: 93712 delta: 33915
before: 425242
after: 421860
average 40719 uA over 299 seconds

The 40mA is too high. We have had measurements below 30mA even with
modem enabled with some pre-dt setup (Kernel 3.7)

Regards,
Andreas


pgpRVX4H8D9yA.pgp
Description: OpenPGP digital signature

[PATCH] usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path

2018-02-05 Thread Yoshihiro Shimoda 
This fixes an issue that a gadget driver (usb_f_fs) is possible to
stop rx transactions after the usb-dmac is used because the following
functions missed to set/check the "running" flag.
 - usbhsf_dma_prepare_pop_with_usb_dmac()
 - usbhsf_dma_pop_done_with_usb_dmac()

So, if next transaction uses pio, the usbhsf_prepare_pop() can not
start the transaction because the "running" flag is 0.

Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some 
usbhs_pkt_handle")
Cc:  # v3.19+
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/fifo.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 2d24ef3..b295e20 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -989,6 +989,10 @@ static int usbhsf_dma_prepare_pop_with_usb_dmac(struct 
usbhs_pkt *pkt,
if ((uintptr_t)pkt->buf & (USBHS_USB_DMAC_XFER_SIZE - 1))
goto usbhsf_pio_prepare_pop;
 
+   /* return at this time if the pipe is running */
+   if (usbhs_pipe_is_running(pipe))
+   return 0;
+
usbhs_pipe_config_change_bfre(pipe, 1);
 
ret = usbhsf_fifo_select(pipe, fifo, 0);
@@ -1179,6 +1183,7 @@ static int usbhsf_dma_pop_done_with_usb_dmac(struct 
usbhs_pkt *pkt,
usbhsf_fifo_clear(pipe, fifo);
pkt->actual = usbhs_dma_calc_received_size(pkt, chan, rcv_len);
 
+   usbhs_pipe_running(pipe, 0);
usbhsf_dma_stop(pipe, fifo);
usbhsf_dma_unmap(pkt);
usbhsf_fifo_unselect(pipe, pipe->fifo);
-- 
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