date:20160922

Re: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang

Hi,

On 22 September 2016 at 20:53, Felipe Balbi  wrote:
>
>
> Hi,
>
> Baolin Wang  writes:
  static const struct usb_gadget_driver configfs_driver_template = {
   .bind   = configfs_composite_bind,
   .unbind = configfs_composite_unbind,

 +#ifdef CONFIG_USB_CONFIGFS_UEVENT
 + .setup  = configfs_setup,
 + .reset  = configfs_disconnect,
 + .disconnect = configfs_disconnect,
 +#else
   .setup  = composite_setup,
   .reset  = composite_disconnect,
   .disconnect = composite_disconnect,
 +#endif
>
> nope, this is quite wrong.
>
 @@ -1453,6 +1556,10 @@ static struct config_group *gadgets_make(
   gi->composite.gadget_driver.function = kstrdup(name, GFP_KERNEL);
   gi->composite.name = gi->composite.gadget_driver.function;

 +#ifdef CONFIG_USB_CONFIGFS_UEVENT
 + INIT_WORK(>work, configfs_work);
 +#endif
>>>
>>> This is just way too ugly, please make it so there are no #ifdefs in the
>>> .c files.
>>>
>>> Or, as others said, why is this a build option at all, why would you not
>>> always want this enabled if you are relying on it all of the time?
>>
>> Sometimes userspace does not need the notification, it is not all the
>> time. Anyway I will remove the macro if you still insist on that.
>
> what's wrong with the sysfs we already have for this?

If Android system userspace can support udc-core's uevents like Badhri
said, I am fine with that.

-- 
Baolin.wang
Best Regards
--
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: add USBTrdTim to initial value

2016-09-22 Thread John Youn

On 9/21/2016 6:43 PM, Pengcheng Li wrote:
> After dwc2_core_reset，register is to the initial value, and the USBTrdTim
> vale is 0x5. If hsotg->phyif = GUSBCFG_PHYIF8, after the dwc2_writel,the
> value is 0xd.So we need to set the USBTrdTim to 0.

[++ Felipe]


Looks good. But please clean up the subject and message

Subject:

usb: dwc2: Clear GUSBCFG.UsbTrdTim before setting

Description:

The USBTRDTIM field needs to be cleared before setting a new
value. Otherwise it will result in an incorrect value if
phyif == GUSBCFG_PHYIF8.


With that
Acked-by: John Youn 


Thanks,
John


> 
> Signed-off-by: Pengcheng Li 
> ---
>  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 af46adf..9e52e4f 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2531,7 +2531,7 @@ void dwc2_hsotg_core_init_disconnected(struct 
> dwc2_hsotg *hsotg,
>   /* keep other bits untouched (so e.g. forced modes are not lost) */
>   usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
>   usbcfg &= ~(GUSBCFG_TOUTCAL_MASK | GUSBCFG_PHYIF16 | GUSBCFG_SRPCAP |
> - GUSBCFG_HNPCAP);
> + GUSBCFG_HNPCAP | GUSBCFG_USBTRDTIM_MASK);
>  
>   /* set the PLL on, remove the HNP/SRP and set the PHY */
>   val = (hsotg->phyif == GUSBCFG_PHYIF8) ? 9 : 5;
> @@ -3413,7 +3413,7 @@ static void dwc2_hsotg_init(struct dwc2_hsotg *hsotg)
>   /* keep other bits untouched (so e.g. forced modes are not lost) */
>   usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
>   usbcfg &= ~(GUSBCFG_TOUTCAL_MASK | GUSBCFG_PHYIF16 | GUSBCFG_SRPCAP |
> - GUSBCFG_HNPCAP);
> + GUSBCFG_HNPCAP | GUSBCFG_USBTRDTIM_MASK);
>  
>   /* set the PLL on, remove the HNP/SRP and set the PHY */
>   trdtim = (hsotg->phyif == GUSBCFG_PHYIF8) ? 9 : 5;
> 

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

Re: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread yfw


Hi Bin,

On 2016/9/23 4:11, Bin Liu wrote:

+Fengwei Yin per his request.

Thanks a lot for adding me to this thread.



On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:


Hi,

Bin Liu  writes:

[...]


Here's one that actually compiles, sorry about that.


No worries, I was sleeping ;-)

I will test it out early next week. Thanks.


meanwhile, how about some instructions on how to test this out myself?
How are you using g_webcam and what are you running on host side? Got a
nice list of commands there I can use? I think I can get to bottom of
this much quicker if I can reproduce it locally ;-)

I am using similar use case with a different gadget function driver.


On device side:
- first patch g_webcam as in my first email in this thread to enable
  640x480@30fps;
- # modprobe g_webcam streaming_maxpacket=3072
- then run uvc-gadget to feed the YUV frames;
http://git.ideasonboard.org/uvc-gadget.git

- I am using uvc function driver  + configfs.
- maxpacket in configfs was set to 3072.
- uvc-gadget from the same source as Bin.


On host side:
- first check the device ep descriptor, which should be
wMaxPacketSize 0x1400  3x 1024 bytes
- then use luvcview or yavta to capture the video stream

- lsusb give me same wMaxPacketSize.
- I am using example (changed a little bit) from libuvc.

Regards
Yin, Fengwei



Capture the bus trace to check if multiple IN transactions happens in
each SOF.

The data buffer size in the usb_request coming from the uvc driver is
5120 bytes, so there should be 3 IN transactions if the UDC works
correctly.

Regards,
-Bin.


--
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: Strange behavior of CHN bit with dwc3

2016-09-22 Thread yfw


Hi Felipe,

On 2016/9/23 3:47, Felipe Balbi wrote:


Hi,

yfw  writes:

Hi Felipe, Bin,



Hi Felipe,
I am very sorry for the multiple sending. The previous were rejected because of
HTML format because I used gmail web interface.

Hi list,
I tried to enable the high speed, high bandwidth transfer in device mode for iso
type on dwc3 based soc. The platform only supports usb device 2.0.

I set the MaxPacketSize to 0x1400 so the host could allocate 3072 bytes for
uframe. But when I chain three trbs together, the dwc3 behavior is quite weird:

If I set the individual trb as following:
[ 32.495556] trb: ff800080f1b0, trb dump: bpl: 0xec803000,bph: 0x0, size:
0x400, ctrl: 0x469
[ 32.495560] trb: ff800080f1c0, trb dump: bpl: 0xec803400,bph: 0x0, size:
0x400, ctrl: 0x469
[ 32.495564] trb: ff800080f1d0, trb dump: bpl: 0xec803800,bph: 0x0, size:
0x400, ctrl: 0xc69

It's actually not high bandwidth. Just normal ISO transfer. Everything is fine.
I got following msg:
[ 32.495909] dwc3_cleanup_done_reqs: trb: ff800080f1b0,trb->size: 0x0,
trb->ctrl: 0x393dc468, trb_num: 3
[ 32.495915] dwc3_cleanup_done_reqs: trb: ff800080f1c0,trb->size: 0x0,
trb->ctrl: 0x393e0478, trb_num: 3
[ 32.495920] dwc3_cleanup_done_reqs: trb: ff800080f1d0,trb->size: 0x0,
trb->ctrl: 0x393e4c78, trb_num: 3

We could see every trb has size to 0 finally.

But if I set the trb chain as:
[ 42.137322] trb: ff800080f000, trb dump: bpl: 0xe2a8c000,bph: 0x0, size:
0x2000400, ctrl: 0x46d
[ 42.137326] trb: ff800080f010, trb dump: bpl: 0xe2a8c400,bph: 0x0, size:
0x400, ctrl: 0x47d
[ 42.137330] trb: ff800080f020, trb dump: bpl: 0xe2a8c800,bph: 0x0, size:
0x400, ctrl: 0xc79

There are three trbs. The first and second has CHN bit set. The first one has
First-ISO type.
And the PCM1 filed is set to 2 for the first one. The last one has IOC bit set.
I tried to let dwc3
send the first one at DATA2 stage, the second one at DATA1 stage and the third
one at DATA0
stage.

But there result is:
[ 42.137872] dwc3_cleanup_done_reqs: trb: ff800080f000,trb->size: 0x0,
trb->ctrl: 0x2cd7c46c, trb_num: 3
[ 42.137877] dwc3_cleanup_done_reqs: trb: ff800080f010,trb->size: 0x400,
trb->ctrl: 0x47d, trb_num: 3
[ 42.137891] dwc3_cleanup_done_reqs: trb: ff800080f020,trb->size:
0x1800, trb->ctrl: 0x2cd7cc78, trb_num: 3

Only the first one is transferred correctly.

I saw the kernel code is using CHN bit. SO I believe it works fine. But it
doesn't work in my environment. Did I miss some obvious registers? Any
comments/hints are appreciated.



Just saw this thread:
http://marc.info/?t=14743911801=1=2

I am fighting with the similar issue now. The patch from Felipe can't work. I


okay, and what was the outcome of your test? Do you have any sniffer
capture you could share? Did you make sure that PCM1 is set correctly?
What is the problem you notice? which gadget driver are you using?

No, I don't have USB tracer. I tried usbmon. But the information from usbmon
is not straight forward enough.

So dumping trb content in device side is what I am using to debug the problem.
On the host side, I am using the libuvc based app to check each iso packet host
get. I also check the throughput of iso transfer to judge whether the iso high
bandwidth is activated or not.




tried that. Here is the my debugging output:


are you using mainline? If you are, capture dwc3 tracepoints. If you're
not, which kernel are you using?

I am not using the latest kernel. Instead the code base is 3.18 + some usb
patches backported because mainline doesn't support the platform I am using.

I will try whether it's possible to apply the latest dwc3 driver from mainline
to the code base I am using. And use the tracepoints with it.




[   33.780999] trb: ff800080f080, trb dump: bpl: 0xdfb23000, bph: 0x0, size:
0x2000400, ctrl: 0x469
[   33.781004] trb: ff800080f090, trb dump: bpl: 0xdfb23400, bph: 0x0, size:
0x400, ctrl: 0x479
[   33.781007] trb: ff800080f0a0, trb dump: bpl: 0xdfb23800, bph: 0x0, size:
0x400, ctrl: 0xc79

This means the PCM1 is correct. Let me manually decode the info (will switch to
trace point then no manually decode needed):

The size of trb has PCM1 field 0x2000400 means PCM1 is 2 (3-1), 0x400 means the
trb has 1024 data.



[   33.782478] dwc3_cleanup_done_reqs: trb: ff800080f080, trb->size: 0x0,
trb->ctrl: 0x13f64468, trb_num: 3, dep->iso_xfer_num: 3993
[   33.782483] dwc3_cleanup_done_reqs: trb: ff800080f090, trb->size: 0x0,
trb->ctrl: 0x13f68478, trb_num: 3, dep->iso_xfer_num: 3994
[   33.782488] dwc3_cleanup_done_reqs: trb: ff800080f0a0, trb->size: 0x0,
trb->ctrl: 0x13f6cc78, trb_num: 3, dep->iso_xfer_num: 3995

The ctrl of trb has uframe number for iso ep if we read it. So
0x13f64468 has uframe number: 0x13f64468 >> 14 = 20441
0x13f68478 has uframe number: 0x13f68478 >> 14 = 20442
0x13f6cc78 has uframe number: 0x13f6cc78 >> 14 = 20443

which means These three trbs were not transferred in one

[PATCH] usb-serial: translate ezusb_convert

2016-09-22 Thread Jorge Natz


ezusb_convert is a script used to convert an Intel HEX firmware file
into a set of C arrays for use in header files. Increase the
portability of this script by translating it from Perl to a
POSIX shell script. Perl is not was widely installed on UNIX machines as
is a POSIX-conforming shell, therefore portability of this script, and
therefore a small part of the build, should be increased.
Signed-off-by: Jorge Natz 
---
diff -uprN a/drivers/usb/serial/ezusb_convert.pl 
b/drivers/usb/serial/ezusb_convert.pl
--- a/drivers/usb/serial/ezusb_convert.pl2016-05-15 16:43:13.0 -0600
+++ b/drivers/usb/serial/ezusb_convert.pl1969-12-31 17:00:00.0 -0700
@@ -1,50 +0,0 @@
-#! /usr/bin/perl -w
-
-
-# convert an Intel HEX file into a set of C records usable by the firmware
-# loading code in usb-serial.c (or others)
-
-# accepts the .hex file(s) on stdin, a basename (to name the initialized
-# array) as an argument, and prints the .h file to stdout. Typical usage:
-#  perl ezusb_convert.pl foo fw_foo.h
-
-
-my $basename = $ARGV[0];
-die "no base name specified" unless $basename;
-
-while () {
-# ':'  '\r'
-#  len, type, crc are 2-char hex, addr is 4-char hex. type is 00 for
-# normal records, 01 for EOF
-my($lenstring, $addrstring, $typestring, $reststring, $doscrap) =
-  /^:(\w\w)(\w\w\w\w)(\w\w)(\w+)(\r?)$/;
-die "malformed line: $_" unless $reststring;
-last if $typestring eq '01';
-my($len) = hex($lenstring);
-my($addr) = hex($addrstring);
-my(@bytes) = unpack("C*", pack("H".(2*$len), $reststring));
-#pop(@bytes); # last byte is a CRC
-push(@records, [$addr, \@bytes]);
-}
-
-@sorted_records = sort { $a->[0] <=> $b->[0] } @records;
-
-print <<"EOF";
-/*
- * ${basename}_fw.h
- *
- * Generated from ${basename}.s by ezusb_convert.pl
- * This file is presumed to be under the same copyright as the source file
- * from which it was derived.
- */
-
-EOF
-
-print "static const struct ezusb_hex_record ${basename}_firmware[] = {\n";
-foreach $r (@sorted_records) {
-printf("{ 0x%04x,\t%d,\t{", $r->[0], scalar(@{$r->[1]}));
-print join(", ", map {sprintf('0x%02x', $_);} @{$r->[1]});
-print "} },\n";
-}
-print "{ 0x,\t0,\t{0x00} }\n";
-print "};\n";
diff -uprN a/drivers/usb/serial/ezusb_convert.sh 
b/drivers/usb/serial/ezusb_convert.sh
--- a/drivers/usb/serial/ezusb_convert.sh1969-12-31 17:00:00.0 -0700
+++ b/drivers/usb/serial/ezusb_convert.sh2016-08-30 08:01:07.493087802 -0600
@@ -0,0 +1,44 @@
+#!/bin/sh
+
+# convert an Intel HEX file to a two-dimensional C record set
+
+# takes HEX file on stdin, and prints header file on stdout
+# example: ./ezusb_convert.sh foo < foo.hex > foo_fw.h
+
+# Exit on error
+set -e
+
+basename=$1
+if ! [ $basename ]; then
+echo “no base name specified”
+exit
+fi
+
+echo '/*\n * '$basename'_fw.h'
+echo ' *'
+echo ' * Generated from '$basename'.s by ezusb_convert.sh'
+cat << "EOF"
+ * This file is presumed to be under the same copyright as the source file
+ * from which it was derived.
+ */
+
+EOF
+echo 'static const struct ezusb_hex_record '$basename'_firmware[] = {'
+
+for LINE in $(sed -e s'/^[^:].*//' -e s'/^[^0].*//' | sort -k 1.4); do
+if ! [ $(echo $LINE | grep '^:') ]; then
+continue
+fi
+reststring=$(echo ${LINE%??} | cut -c 10- | tr '[:upper:]' '[:lower:]')
+if ! [ $reststring ]; then
+printf "malformed line:%" $reststring
+exit 1
+fi
+charcount=0
+echo -n '{ 0x'$(echo $LINE | head -c 7 | tail -c 4 | tr '[:upper:]' 
'[:lower:]')
+echo -n ','$(printf "%d" 0x$(echo $LINE | head -c 3 | tail -c 2))',
{'
+echo -n $(echo $reststring | sed -e s'/../0x&, /g' -e s'/, $//')
+echo '} },'
+done
+
+echo '{ 0x,\t0,\t{0x00} }\n};'
diff -uprN a/drivers/usb/serial/Makefile-keyspan_pda_fw 
b/drivers/usb/serial/Makefile-keyspan_pda_fw
--- a/drivers/usb/serial/Makefile-keyspan_pda_fw2016-05-15 
16:43:13.0 -0600
+++ b/drivers/usb/serial/Makefile-keyspan_pda_fw2016-08-29 
20:09:39.653038229 -0600
@@ -12,5 +12,5 @@ all: keyspan_pda_fw.h
 as31 -l $<
 mv $*.obj $@
 
-%_fw.h: %.hex ezusb_convert.pl
-perl ezusb_convert.pl $* < $< > $@
+%_fw.h: %.hex ezusb_convert.sh
+./ezusb_convert.sh $* < $< > $@
diff -uprN a/firmware/keyspan_pda/keyspan_pda.S 
b/firmware/keyspan_pda/keyspan_pda.S
--- a/firmware/keyspan_pda/keyspan_pda.S2016-05-15 16:43:13.0 -0600
+++ b/firmware/keyspan_pda/keyspan_pda.S2016-08-29 20:29:35.380974152 -0600
@@ -84,7 +84,7 @@
  *  gcc -x assembler-with-cpp -P -E -o keyspan_pda.asm keyspan_pda.s
  *  as31 -l keyspan_pda.asm
  *  mv keyspan_pda.obj keyspan_pda.hex
- *  perl ezusb_convert.pl keyspan_pda < keyspan_pda.hex > keyspan_pda_fw.h
+ *  ./ezusb_convert.sh keyspan_pda < keyspan_pda.hex > keyspan_pda_fw.h
  * Get as31 from , and hack on it
  * a bit to make it build.
  *
diff -uprN

Re: VL805 USB 3.0 does not see connected devices (only on x86_64) (x86 is ok)

2016-09-22 Thread c400

btw
i've tested a liitle better and the disk is visible, but write errors occurs
after ejecting and inserting it is invisible again

[129416.884960] sd 7:0:0:0: [sdc] 1250263728 512-byte logical blocks:
(640 GB/596 GiB)
[129416.885429] sd 7:0:0:0: [sdc] Write Protect is off
[129416.885434] sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00
[129416.885798] sd 7:0:0:0: [sdc] No Caching mode page found
[129416.885801] sd 7:0:0:0: [sdc] Assuming drive cache: write through
[129416.885806] device: '8:32': device_add
[129416.885820] PM: Adding info for No Bus:8:32
[129416.885831] device: 'sdc': device_add
[129416.885847] PM: Adding info for No Bus:sdc
[129416.897283]  sdc: sdc1
[129416.897291] device: 'sdc1': device_add
[129416.897309] PM: Adding info for No Bus:sdc1
[129416.898828] sd 7:0:0:0: [sdc] Attached SCSI disk
[129479.043607] usb 3-1: reset SuperSpeed USB device number 3 using xhci_hcd
[129483.506009] xhci_hcd :02:00.0: WARNING: Host System Error
[129483.529130] xhci_hcd :02:00.0: Host not halted after 16000 microseconds.
[129483.529146] DMAR: DRHD: handling fault status reg 2
[129483.529149] DMAR: [DMA Read] Request device [02:00.0] fault addr
ffdf1000 [fault reason 06] PTE Read access is not set
[129518.953695] xhci_hcd :02:00.0: xHCI host not responding to
stop endpoint command.
[129518.953702] xhci_hcd :02:00.0: Assuming host is dying, halting host.
[129518.976675] xhci_hcd :02:00.0: Host not halted after 16000 microseconds.
[129518.976686] xhci_hcd :02:00.0: Non-responsive xHCI host is not halting.
[129518.976687] xhci_hcd :02:00.0: Completing active URBs anyway.
[129518.976699] xhci_hcd :02:00.0: HC died; cleaning up
[129519.841735] sd 7:0:0:0: [sdc] tag#0 FAILED Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[129519.841739] sd 7:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 00 5b 72
e0 00 08 00 00
[129519.841741] blk_update_request: I/O error, dev sdc, sector 5993184
[129519.841743] Buffer I/O error on dev sdc1, logical block 5991136,
lost async page write
[129519.841745] Buffer I/O error on dev sdc1, logical block 5991137,
lost async page write
[129519.841747] Buffer I/O error on dev sdc1, logical block 5991138,
lost async page write
[129519.841748] Buffer I/O error on dev sdc1, logical block 5991139,
lost async page write
[129519.841749] Buffer I/O error on dev sdc1, logical block 5991140,
lost async page write
[129519.841750] Buffer I/O error on dev sdc1, logical block 5991141,
lost async page write
[129519.841752] Buffer I/O error on dev sdc1, logical block 5991142,
lost async page write
[129519.841753] Buffer I/O error on dev sdc1, logical block 5991143,
lost async page write
[129519.841758] Buffer I/O error on dev sdc1, logical block 5991144,
lost async page write
[129519.841760] Buffer I/O error on dev sdc1, logical block 5991145,
lost async page write
[129520.841755] sd 7:0:0:0: [sdc] tag#0 FAILED Result:
hostbyte=DID_ERROR driverbyte=DRIVER_OK
[129520.841759] sd 7:0:0:0: [sdc] tag#0 CDB: Write(10) 2a 00 00 5b 7a
e0 00 08 00 00
[129520.841760] blk_update_request: I/O error, dev sdc, sector 5995232
[129530.516824] xhci_hcd :02:00.0: Stopped the command ring
failed, maybe the host is dead
[129530.540017] xhci_hcd :02:00.0: Host not halted after 16000 microseconds.
[129530.540021] xhci_hcd :02:00.0: Abort command ring failed
[129530.540023] xhci_hcd :02:00.0: HC died; cleaning up
[129530.540064] usb 2-1: USB disconnect, device number 2
[129530.540067] device: 'ep_81': device_unregister
[129530.540083] PM: Removing info for No Bus:ep_81
[129530.540099] bus: 'usb': remove device 2-1:1.0
[129530.540108] device: '2-1-port4': device_unregister
[129530.540116] PM: Removing info for No Bus:2-1-port4

2016-09-21 18:08 GMT+03:00 c400 :
> 02:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host
> Controller (rev 01) (prog-if 30 [XHCI])
> Subsystem: VIA Technologies, Inc. VL805 USB 3.0 Host Controller
> Flags: bus master, fast devsel, latency 0, IRQ 41
> Memory at fbb0 (64-bit, non-prefetchable) [size=4K]
> Capabilities: [80] Power Management version 3
> Capabilities: [90] MSI: Enable+ Count=1/4 Maskable- 64bit+
> Capabilities: [c4] Express Endpoint, MSI 00
> Kernel driver in use: xhci_hcd
> Kernel modules: xhci_pci
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: UAS and f_tcm -- is anyone using it?

2016-09-22 Thread John Youn

On 9/22/2016 12:25 AM, Andrzej Pietrasiewicz wrote:
> W dniu 20.09.2016 o 21:19, John Youn pisze:
> 
> 
> 
>> Hi Sebastian, Andrzej,
>>
>> If possible, could you share how you are using it? Such as in what
>> speed, mode, and with what controllers/platforms and hosts?
>>
>> If you have any other tips on usage I would appreciate it.
>>
>> I'm looking into getting it working with our dwc3 controller, maybe
>> also dwc2.
>>
>> Regards,
>> John
>>
>>
>>
> 
> Hi John,
> 
> My concern was converting the function to use configfs,
> this was the last one waiting for this kind of conversion,
> the other ~19 had been already converted at that time.
> 
> With that aim in mind what I did was following function's
> behaviour at the time of conversion, that is, achieve the
> same state with the configfs-composed tcm gadget as with
> the legacy tcm gadget. I am aware that this kind of information
> is not of much use, but at least you know where you are.
> 
> As far as I remember I tested it on Odroid XU3, which uses dwc3.
> 

Ok thanks. It helps to know what I'm dealing with.

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

[PATCH 3/3] usb: musb: da8xx: fix error handling message in probe

2016-09-22 Thread Bin Liu

From: Arnd Bergmann 

We print an error message when platform_device_register_full()
fails, but the initialization of the argument has been removed,
as shown in this warning:

drivers/usb/musb/da8xx.c: In function 'da8xx_probe':
drivers/usb/musb/da8xx.c:521:3: error: 'ret' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

This modifies the function to assign the return code before
checking it, and does uses the same method in the check for
usb_phy_generic_register() as well.

Fixes: 947c49afe41f ("usb: musb: da8xx: Remove mach code")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/da8xx.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 2358f63..210b7e4 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -462,7 +462,6 @@ static int da8xx_probe(struct platform_device *pdev)
 {
struct resource musb_resources[2];
struct musb_hdrc_platform_data  *pdata = dev_get_platdata(>dev);
-   struct platform_device  *musb;
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
struct clk  *clk;
@@ -490,9 +489,10 @@ static int da8xx_probe(struct platform_device *pdev)
pdata->platform_ops = _ops;
 
glue->usb_phy = usb_phy_generic_register();
-   if (IS_ERR(glue->usb_phy)) {
+   ret = PTR_ERR_OR_ZERO(glue->usb_phy);
+   if (ret) {
dev_err(>dev, "failed to register usb_phy\n");
-   return PTR_ERR(glue->usb_phy);
+   return ret;
}
platform_set_drvdata(pdev, glue);
 
@@ -516,14 +516,14 @@ static int da8xx_probe(struct platform_device *pdev)
pinfo.data = pdata;
pinfo.size_data = sizeof(*pdata);
 
-   glue->musb = musb = platform_device_register_full();
-   if (IS_ERR(musb)) {
+   glue->musb = platform_device_register_full();
+   ret = PTR_ERR_OR_ZERO(glue->musb);
+   if (ret) {
dev_err(>dev, "failed to register musb device: %d\n", 
ret);
usb_phy_generic_unregister(glue->usb_phy);
-   return PTR_ERR(musb);
}
 
-   return 0;
+   return ret;
 }
 
 static int da8xx_remove(struct platform_device *pdev)
-- 
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 0/3] musb patches for v4.9-rc1 part2

2016-09-22 Thread Bin Liu

Hi Greg,

This is the second set of musb patches for v4.9-rc. They are fixes for current
linux-next. Please let me know if any change is needed.

Thanks,
-Bin.
---

Arnd Bergmann (1):
  usb: musb: da8xx: fix error handling message in probe

Tony Lindgren (2):
  usb: musb: Fix PM runtime for disconnect after unconfigure
  usb: musb: Fix session based PM for first invalid VBUS

 drivers/usb/musb/da8xx.c   | 14 +++---
 drivers/usb/musb/musb_core.c   | 13 -
 drivers/usb/musb/musb_core.h   |  1 +
 drivers/usb/musb/musb_gadget.c |  3 +++
 4 files changed, 19 insertions(+), 12 deletions(-)

-- 
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 1/3] usb: musb: Fix PM runtime for disconnect after unconfigure

2016-09-22 Thread Bin Liu

From: Tony Lindgren 

If we unconfigure musb as a USB peripheral with cable connected,
and then remove the cable, no interrupts will happen. And musb
thinks we're still connected keeping the device active.

Now with the session bit based PM runtime working for musb, we
can fix this issue by calling musb irq_work. That rechecks the
devctl register and reconfigures PM runtime based on the devctl.

Fixes: 467d5c980709 ("usb: musb: Implement session bit based
runtime PM for musb-core")
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_gadget.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 6d1e975..bff4869 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1964,6 +1964,9 @@ static int musb_gadget_stop(struct usb_gadget *g)
 * that currently misbehaves.
 */
 
+   /* Force check of devctl register for PM runtime */
+   schedule_work(>irq_work);
+
pm_runtime_mark_last_busy(musb->controller);
pm_runtime_put_autosuspend(musb->controller);
 
-- 
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 2/3] usb: musb: Fix session based PM for first invalid VBUS

2016-09-22 Thread Bin Liu

From: Tony Lindgren 

With the session bit based PM runtime working on musb, we've
implemented few quirks to attempt to detect the current state of
the hardware. One of the quirks is for invalid VBUS as peripheral,
but it is not working in all cases.

If we start musb on dm3730 as a peripheral with no cable connected,
we will get the devctl 91 state once and will never idle as there
are not further interrupts from musb. So we need to ignore the first
devctl 91 state as there will be more interrupts if we're connected.

The invalid VBUS state also can happen always when connected to
certain USB hubs. Looks like musb on dm3730 can claim invalid VBUS
with some hubs while 3717-evm and BeagleBone don't. This causes
session as peripheral to fail for dm3730 with some hubs.

This too is fixed by ignoring only the first invalid VBUS. When
connected, we can just look at the session bit as that will clear
automatically when the session ends.

Fixes: 467d5c980709 ("usb: musb: Implement session bit based
runtime PM for musb-core")
Signed-off-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 13 -
 drivers/usb/musb/musb_core.h |  1 +
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0319ea6..27dadc0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1855,11 +1855,13 @@ static void musb_pm_runtime_check_session(struct musb 
*musb)
MUSB_DEVCTL_HR;
switch (devctl & ~s) {
case MUSB_QUIRK_B_INVALID_VBUS_91:
-   if (musb->session)
-   break;
-   musb_dbg(musb, "Allow PM as device with invalid vbus: %02x",
-   devctl);
-   return;
+   if (!musb->session && !musb->quirk_invalid_vbus) {
+   musb->quirk_invalid_vbus = true;
+   musb_dbg(musb,
+"First invalid vbus, assume no session");
+   return;
+   }
+   break;
case MUSB_QUIRK_A_DISCONNECT_19:
if (!musb->session)
break;
@@ -1886,6 +1888,7 @@ static void musb_pm_runtime_check_session(struct musb 
*musb)
error);
} else {
musb_dbg(musb, "Allow PM with no session: %02x", devctl);
+   musb->quirk_invalid_vbus = false;
pm_runtime_mark_last_busy(musb->controller);
pm_runtime_put_autosuspend(musb->controller);
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 65288a5..2cb88a49 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -379,6 +379,7 @@ struct musb {
 
int port_mode;  /* MUSB_PORT_MODE_* */
boolsession;
+   boolquirk_invalid_vbus;
boolis_host;
 
int a_wait_bcon;/* VBUS timeout in msecs */
-- 
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] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Badhri Jagan Sridharan

Hi all,

I do agree that udc-core's uevents can potentially be used here.
I will check the complete list of uevents sent by the udc-core's
usb_gadget_set_state function and see if the userspace is happy to work with it.
Now that Android is starting to use the configfs driver, it might be
much easier.

Android userspace always relies on uevents to notify the users. This is might
be the right opportunity to dig into the uevents fired by the udc-core code
and shift to it.

I will come back with questions/ findings.

Thanks.

On Thu, Sep 22, 2016 at 9:36 AM, Mark Brown  wrote:
>
> On Thu, Sep 22, 2016 at 03:38:30PM +0200, Greg KH wrote:
> > On Thu, Sep 22, 2016 at 08:41:09PM +0800, Baolin Wang wrote:
>
> > > OK. I will talk with Badhri if I can upstream these.
>
> > That's not an issue, you can keep the "From:" line on it, if you got it
> > in a legal way, and then just have your signed off by on it, go read the
> > DCO for the specifics.  I don't know why someone else told you
> > otherwise.
>
> Given the weakness people have in understanding the legal part of
> signoffs it seems very unwise to just trust that they've actually
> got everything clearly lined up and IME when they're missing they've
> often just been removed or sometimes there's a very good reason why the
> original author didn't provide a signoff.  It seems safer for everyone
> to query what's going on and it's been fairly unusual that it's anything
> other than a mistake.
--
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: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Bin Liu

+Fengwei Yin per his request.

On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> 
> [...]
> 
> >> Here's one that actually compiles, sorry about that.
> >
> > No worries, I was sleeping ;-)
> >
> > I will test it out early next week. Thanks.
> 
> meanwhile, how about some instructions on how to test this out myself?
> How are you using g_webcam and what are you running on host side? Got a
> nice list of commands there I can use? I think I can get to bottom of
> this much quicker if I can reproduce it locally ;-)

On device side:
- first patch g_webcam as in my first email in this thread to enable
  640x480@30fps;
- # modprobe g_webcam streaming_maxpacket=3072
- then run uvc-gadget to feed the YUV frames;
http://git.ideasonboard.org/uvc-gadget.git

On host side:
- first check the device ep descriptor, which should be
wMaxPacketSize 0x1400  3x 1024 bytes
- then use luvcview or yavta to capture the video stream

Capture the bus trace to check if multiple IN transactions happens in
each SOF.

The data buffer size in the usb_request coming from the uvc driver is
5120 bytes, so there should be 3 IN transactions if the UDC works
correctly.

Regards,
-Bin.
--
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: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Malcolm Priestley




On 22/09/16 15:25, Oliver Neukum wrote:

On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:


-- Binyamin


I compiled the kernel without BPF and still got an issue (attached)
How can I verify the BPF is not enabled/part of the kernel?

-- Binyamin


Could you test the attached patch?

ieee80211_free_hw frees the priv.

usb_set_intfdata is set to hw_>priv, If vt6656_disconnect is called 
there is a null check.


I think the order is wrong in vt6656_disconnect.

Regards


Malcolm
--
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: Strange behavior of CHN bit with dwc3

2016-09-22 Thread Felipe Balbi


Hi,

yfw  writes:
> Hi Felipe, Bin,
>
>
>> Hi Felipe,
>> I am very sorry for the multiple sending. The previous were rejected because 
>> of
>> HTML format because I used gmail web interface.
>>
>> Hi list,
>> I tried to enable the high speed, high bandwidth transfer in device mode for 
>> iso
>> type on dwc3 based soc. The platform only supports usb device 2.0.
>>
>> I set the MaxPacketSize to 0x1400 so the host could allocate 3072 bytes for
>> uframe. But when I chain three trbs together, the dwc3 behavior is quite 
>> weird:
>>
>> If I set the individual trb as following:
>> [ 32.495556] trb: ff800080f1b0, trb dump: bpl: 0xec803000,bph: 0x0, size:
>> 0x400, ctrl: 0x469
>> [ 32.495560] trb: ff800080f1c0, trb dump: bpl: 0xec803400,bph: 0x0, size:
>> 0x400, ctrl: 0x469
>> [ 32.495564] trb: ff800080f1d0, trb dump: bpl: 0xec803800,bph: 0x0, size:
>> 0x400, ctrl: 0xc69
>>
>> It's actually not high bandwidth. Just normal ISO transfer. Everything is 
>> fine.
>> I got following msg:
>> [ 32.495909] dwc3_cleanup_done_reqs: trb: ff800080f1b0,trb->size: 0x0,
>> trb->ctrl: 0x393dc468, trb_num: 3
>> [ 32.495915] dwc3_cleanup_done_reqs: trb: ff800080f1c0,trb->size: 0x0,
>> trb->ctrl: 0x393e0478, trb_num: 3
>> [ 32.495920] dwc3_cleanup_done_reqs: trb: ff800080f1d0,trb->size: 0x0,
>> trb->ctrl: 0x393e4c78, trb_num: 3
>>
>> We could see every trb has size to 0 finally.
>>
>> But if I set the trb chain as:
>> [ 42.137322] trb: ff800080f000, trb dump: bpl: 0xe2a8c000,bph: 0x0, size:
>> 0x2000400, ctrl: 0x46d
>> [ 42.137326] trb: ff800080f010, trb dump: bpl: 0xe2a8c400,bph: 0x0, size:
>> 0x400, ctrl: 0x47d
>> [ 42.137330] trb: ff800080f020, trb dump: bpl: 0xe2a8c800,bph: 0x0, size:
>> 0x400, ctrl: 0xc79
>>
>> There are three trbs. The first and second has CHN bit set. The first one has
>> First-ISO type.
>> And the PCM1 filed is set to 2 for the first one. The last one has IOC bit 
>> set.
>> I tried to let dwc3
>> send the first one at DATA2 stage, the second one at DATA1 stage and the 
>> third
>> one at DATA0
>> stage.
>>
>> But there result is:
>> [ 42.137872] dwc3_cleanup_done_reqs: trb: ff800080f000,trb->size: 0x0,
>> trb->ctrl: 0x2cd7c46c, trb_num: 3
>> [ 42.137877] dwc3_cleanup_done_reqs: trb: ff800080f010,trb->size: 0x400,
>> trb->ctrl: 0x47d, trb_num: 3
>> [ 42.137891] dwc3_cleanup_done_reqs: trb: ff800080f020,trb->size:
>> 0x1800, trb->ctrl: 0x2cd7cc78, trb_num: 3
>>
>> Only the first one is transferred correctly.
>>
>> I saw the kernel code is using CHN bit. SO I believe it works fine. But it
>> doesn't work in my environment. Did I miss some obvious registers? Any
>> comments/hints are appreciated.
>>
>
> Just saw this thread:
> http://marc.info/?t=14743911801=1=2
>
> I am fighting with the similar issue now. The patch from Felipe can't work. I

okay, and what was the outcome of your test? Do you have any sniffer
capture you could share? Did you make sure that PCM1 is set correctly?
What is the problem you notice? which gadget driver are you using?

> tried that. Here is the my debugging output:

are you using mainline? If you are, capture dwc3 tracepoints. If you're
not, which kernel are you using?

> [   33.780999] trb: ff800080f080, trb dump: bpl: 0xdfb23000, bph: 0x0, 
> size: 
> 0x2000400, ctrl: 0x469
> [   33.781004] trb: ff800080f090, trb dump: bpl: 0xdfb23400, bph: 0x0, 
> size: 
> 0x400, ctrl: 0x479
> [   33.781007] trb: ff800080f0a0, trb dump: bpl: 0xdfb23800, bph: 0x0, 
> size: 
> 0x400, ctrl: 0xc79
>
> [   33.782478] dwc3_cleanup_done_reqs: trb: ff800080f080, trb->size: 0x0, 
> trb->ctrl: 0x13f64468, trb_num: 3, dep->iso_xfer_num: 3993
> [   33.782483] dwc3_cleanup_done_reqs: trb: ff800080f090, trb->size: 0x0, 
> trb->ctrl: 0x13f68478, trb_num: 3, dep->iso_xfer_num: 3994
> [   33.782488] dwc3_cleanup_done_reqs: trb: ff800080f0a0, trb->size: 0x0, 
> trb->ctrl: 0x13f6cc78, trb_num: 3, dep->iso_xfer_num: 3995

sorry but I have no inclination in decoding this when the driver has
very good tracepoint support. Please remove your debugging and capture
trace output:

# mkdir -p /t
# mount -t tracefs none /t
# echo 20480 > /t/buffer_size_kb
# echo 1 > /t/events/dwc3/enable

Now reproduce the issue, then:

# cp /t/trace /path/to/non-volatile/media/

Send me the trace file. You'll probably have to compress it. gzip or xz
should compress it enough.

> We could see the trb present was transferred correctly. But they are not at
> the same uframe stage. The field in trb->ctrl are not same. That means the 
> data
> was transferred at different uframe stage. And the video throughput was not
> increased as well.

I don't have any information on how to reproduce this problem, how can I
be of any help? :-)

Either Bin has some notes on how to use g_webcam so I can reproduce, or
you can tell me more details about your setup.

> I have no new databook (Only have one for v2.50a). So I tested almost all the
> combines I

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

2016-09-22 Thread Wim Osterholt

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> OK. Strange. Please do
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

On kernel-4.7.4 this gives this little output:

[  135.279989] sysrq: SysRq : Changing Loglevel
[  135.280489] sysrq: Loglevel set to 9
[  146.712004] usbcore: registered new interface driver cdc_acm
[  146.712537] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  173.257346] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  173.450326] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  173.450879] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  173.451374] usb 6-1: Product: USB Modem
[  173.451867] usb 6-1: Manufacturer: Conexant
[  173.452360] usb 6-1: SerialNumber: 12345678
[  173.455415] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  173.455995] cdc_acm 6-1:1.0: ttyACM0: USB ACM device
[  173.562316] cdc_acm:acm_ctrl_msg: cdc_acm 6-1:1.0: acm_ctrl_msg - rq 0x20, 
val 0x0, len 0x7, result 7


4.8-rc7 is compiling now..


Regards, Wim.
--
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

CONGRATULATIONS !!!

2016-09-22 Thread Cheveron Texaco



Attention Winner,

Congratulations !!! Your email Address has won you a substantial amount of 1 
Million United States dollars in the just concluded Chevron Texaco 
Promo-Lottery.

You are to contact your claim agent for claims process at Email:   
chevron.claimsagent1...@gmail.com


Best Regards
Ms Stella Newton
--
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: crash by cdc_acm driver in kernels 4.8-rc1/5

2016-09-22 Thread Wim Osterholt

> >Please look up the bConfigurationValue for your device
> >in sysfs.

I didn't explicitly say that this was done under kernel-4.7.4, otherwise
it may have been impossible under 4.8 .

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> OK. Strange. Please do
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

You don't state if this must be done in a safe 4.7.4 or a crashable 4.8.
(if I get that far to retrieve dmesg to a file).

Anyway, echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
results in 'No such file or directory' because there is no 'dynamic_debug'.

The kernel option DYNAMIC_DEBUG was not set.
A new kernel is compiling now..

Groeten, Wim.

--
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] musb: Export musb_root_disconnect for use in modules

2016-09-22 Thread Mark Brown

On Thu, Sep 22, 2016 at 07:28:42PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2016 at 06:15:26PM +0100, Mark Brown wrote:
> > On Thu, Sep 22, 2016 at 08:30:16AM -0500, Bin Liu wrote:

> > > Removed it from my tree, since Greg already picked it.

> > It's not showing in today's -next...

> It probably missed the cut-off, should be there tomorrow.

Ah, excellent thanks!  Down to only one build break in all*config in -next :/


signature.asc
Description: PGP signature

Re: [PATCH v2] musb: Export musb_root_disconnect for use in modules

2016-09-22 Thread Greg Kroah-Hartman

On Thu, Sep 22, 2016 at 06:15:26PM +0100, Mark Brown wrote:
> On Thu, Sep 22, 2016 at 08:30:16AM -0500, Bin Liu wrote:
> > On Wed, Sep 21, 2016 at 03:51:33PM -0500, Bin Liu wrote:
> 
> > > Applied. Thanks.
> 
> > Removed it from my tree, since Greg already picked it.
> 
> It's not showing in today's -next...

It probably missed the cut-off, should be there tomorrow.

--
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] musb: Export musb_root_disconnect for use in modules

2016-09-22 Thread Mark Brown

On Thu, Sep 22, 2016 at 08:30:16AM -0500, Bin Liu wrote:
> On Wed, Sep 21, 2016 at 03:51:33PM -0500, Bin Liu wrote:

> > Applied. Thanks.

> Removed it from my tree, since Greg already picked it.

It's not showing in today's -next...


signature.asc
Description: PGP signature

Re: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Mark Brown

On Thu, Sep 22, 2016 at 03:38:30PM +0200, Greg KH wrote:
> On Thu, Sep 22, 2016 at 08:41:09PM +0800, Baolin Wang wrote:

> > OK. I will talk with Badhri if I can upstream these.

> That's not an issue, you can keep the "From:" line on it, if you got it
> in a legal way, and then just have your signed off by on it, go read the
> DCO for the specifics.  I don't know why someone else told you
> otherwise.

Given the weakness people have in understanding the legal part of
signoffs it seems very unwise to just trust that they've actually
got everything clearly lined up and IME when they're missing they've
often just been removed or sometimes there's a very good reason why the
original author didn't provide a signoff.  It seems safer for everyone
to query what's going on and it's been fairly unusual that it's anything
other than a mistake.

signature.asc
Description: PGP signature

Re: [PATCH v2 2/3] musb: sunxi: Remove custom babble handling

2016-09-22 Thread Bin Liu

Hi,

On Thu, Sep 22, 2016 at 05:03:39PM +0300, Hans de Goede wrote:
> Hi,
> 
> On 09/22/2016 04:54 PM, Bin Liu wrote:
> >Hi,
> >
> >On Thu, Sep 22, 2016 at 02:19:00PM +0300, Hans de Goede wrote:
> >>The musb-core now a days always treats babble errors in host mode
> >
> >I don't think this statement is accurate. You might want to change it to
> >"The musb core already handles babble interrupt" or something else.
> 
> It is accurate if you look in the history at drivers/usb/musb
> commits around 15-03-10 you will see 2 relevant commits:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/musb?id=b4dc38fd45b63e3da2bc98db5d283a15a637a2fa
> 
> "usb: musb: core: simplify musb_recover_work()"
> 
> This commits introduces calling musb_root_disconnect(musb)
> on babble errors, that was not happening before which is why

That is true, but calling musb_root_disconnect() is just one step of the
recovery in musb core, not all.

The statement of "treats babble errors in host mode as disconnects"
implies all the babble handling is just disconnect, which is not
accurate.

BTY, "babble errors in host mode" is also redundant. babble implies
host mode.

Regards,
-Bin.
> I added the custom babble error handling. to the sunxi glue.
> 
> And:
> 
> "usb: musb: core: always try to recover from babble"
> 
> Where the title says it all.
> 
> Take these together and I believe that my commit msg:
> 
> "The musb-core now a days always treats babble errors in host mode
> as disconnects, so there is no need for the sunxi specific handling
> of this anymore."
> 
> Is quite accurate.
> 
> Regards,
> 
> Hans
> 
> 
> >>
> >>Signed-off-by: Hans de Goede 
> >>---
> >>Changes in v2:
> >>-This is a new patch in v2 of this patch series
> >>---
> >> drivers/usb/musb/sunxi.c | 10 --
> >> 1 file changed, 10 deletions(-)
> >>
> >>diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> >>index 1408245..82eba92 100644
> >>--- a/drivers/usb/musb/sunxi.c
> >>+++ b/drivers/usb/musb/sunxi.c
> >>@@ -186,16 +186,6 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
> >>*__hci)
> >>if (musb->int_usb)
> >>writeb(musb->int_usb, musb->mregs + SUNXI_MUSB_INTRUSB);
> >>
> >>-   /*
> >>-* sunxi musb often signals babble on low / full speed device
> >>-* disconnect, without ever raising MUSB_INTR_DISCONNECT, since
> >>-* normally babble never happens treat it as disconnect.
> >>-*/
> >>-   if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {
> >>-   musb->int_usb &= ~MUSB_INTR_BABBLE;
> >>-   musb->int_usb |= MUSB_INTR_DISCONNECT;
> >>-   }
> >>-
> >>if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
> >>/* ep0 FADDR must be 0 when (re)entering peripheral mode */
> >>musb_ep_select(musb->mregs, 0);
> >>--
> >>2.9.3
> >>
> --
> 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
--
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: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum

On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:

> > -- Binyamin
> 
> I compiled the kernel without BPF and still got an issue (attached)
> How can I verify the BPF is not enabled/part of the kernel?
> 
> -- Binyamin

Could you test the attached patch?

Regards
Oliver

From e0f6d09babd9f30d952389ff98a2a25df9a158a5 Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Thu, 22 Sep 2016 16:22:06 +0200
Subject: [PATCH] vt6656: avoid double free

This data structure is fred in disconnect(). It must not
be freed earlier.

Signed-off-by: Oliver Neukum 
---
 drivers/staging/vt6656/wcmd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vt6656/wcmd.c b/drivers/staging/vt6656/wcmd.c
index 95faaeb..17f2723 100644
--- a/drivers/staging/vt6656/wcmd.c
+++ b/drivers/staging/vt6656/wcmd.c
@@ -110,7 +110,6 @@ void vnt_run_command(struct work_struct *work)
 		if (vnt_init(priv)) {
 			/* If fail all ends TODO retry */
 			dev_err(>usb->dev, "failed to start\n");
-			ieee80211_free_hw(priv->hw);
 			return;
 		}
 
-- 
2.6.2

Re: [PATCH] usb: gadget: f_fs: use complete() instead complete_all()

2016-09-22 Thread Michal Nazarewicz

On Thu, Sep 22 2016, Daniel Wagner wrote:
> From: Daniel Wagner 
>
> There is only one waiter for the completion, therefore there
> is no need to use complete_all(). Let's make that clear by
> using complete() instead of complete_all().
>
> The usage pattern of the completion is:
>
> waiter context  waker context
>   reinit_completion()
>   usb_esp_queue()
>   wait_for_completion_interruptible()
>
>   ffs_ep0_complete()
> complete()
>
> Signed-off-by: Daniel Wagner 
> Cc: Felipe Balbi 
> Cc: Michal Nazarewicz 

Acked-by: Michal Nazarewicz 

> Cc: Greg Kroah-Hartman 
> Cc: linux-usb@vger.kernel.org
> ---
>  drivers/usb/gadget/function/f_fs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c 
> b/drivers/usb/gadget/function/f_fs.c
> index 5c8429f..0c29039 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -211,7 +211,7 @@ static void ffs_ep0_complete(struct usb_ep *ep, struct 
> usb_request *req)
>  {
>   struct ffs_data *ffs = req->context;
>  
> - complete_all(>ep0req_completion);
> + complete(>ep0req_completion);
>  }
>  
>  static int __ffs_ep0_queue_wait(struct ffs_data *ffs, char *data, size_t len)
> -- 
> 2.7.4

-- 
Best regards
ミハウ “퓶퓲퓷퓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
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] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

2016-09-22 Thread Alan Stern

On Thu, 22 Sep 2016, Oliver Neukum wrote:

> On Wed, 2016-09-21 at 10:35 -0400, Alan Stern wrote:
> > On Wed, 21 Sep 2016, Oliver Neukum wrote:
> 
> > > Yes, but this is not the point. A heuristic with a timeout makes
> > > sense only if the uses are unpredictable. If you know with a high
> > > degree of probability when the next activity comes, you ought to either
> > > suspend now or not all until the next activity.
> > > 
> > > Likewise the heuristic is appropriate for leaf nodes. You get nothing
> > > from a delay on inner nodes.
> > 
> > Almost true, but not quite.  When an inner node has more than one leaf
> > beneath it, enabling an autosuspend delay for the inner node can make 
> > sense -- particularly if the leaf activities are uncorrelated.
> 
> 
> Well, it is true that an inner node is likelier to be woken up
> depending on the number of children. That is a reason to have a longer
> timeout for an inner node. But it should start when the first node goes
> idle. It makes no sense to start yet another timeout when the last node
> goes idle.
> 
> In terms of mathematics I think we would need to multiply the timeout
> with the square root of busy children and restart it whenever a child
> goes to idle.
> But it seems to me that this is impractical.
> 
> So I would suggest that we are missing an API for drivers to tell the
> core that they become idle for a known period of time and to propagate
> that immediately up if that is the last leaf to become idle.

This seems like over-engineering.  In many cases the driver does not 
know how long the idle period will last.  And it may happen that the 
leaf drivers do not understand the energy tradeoffs involved in 
suspending the ancestor device.

> > > Any storage (generic sense) device
> > > is an inner node. It should suspend immediately after the block
> > > device which is the leaf node.
> > 
> > Yes.  In this case, however, the USB device has two platform devices 
> > beneath it: one for SDMMC and one for MemoryStick cards.
> 
> Indeed, we can hope that the power efficient work queue used will
> join the polling of both devices. Ideally we could model the mutual
> exclusion.

Ulf is going to work on it.

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: Strange behavior of CHN bit with dwc3

2016-09-22 Thread yfw


Hi Felipe, Bin,



Hi Felipe,
I am very sorry for the multiple sending. The previous were rejected because of
HTML format because I used gmail web interface.

Hi list,
I tried to enable the high speed, high bandwidth transfer in device mode for iso
type on dwc3 based soc. The platform only supports usb device 2.0.

I set the MaxPacketSize to 0x1400 so the host could allocate 3072 bytes for
uframe. But when I chain three trbs together, the dwc3 behavior is quite weird:

If I set the individual trb as following:
[ 32.495556] trb: ff800080f1b0, trb dump: bpl: 0xec803000,bph: 0x0, size:
0x400, ctrl: 0x469
[ 32.495560] trb: ff800080f1c0, trb dump: bpl: 0xec803400,bph: 0x0, size:
0x400, ctrl: 0x469
[ 32.495564] trb: ff800080f1d0, trb dump: bpl: 0xec803800,bph: 0x0, size:
0x400, ctrl: 0xc69

It's actually not high bandwidth. Just normal ISO transfer. Everything is fine.
I got following msg:
[ 32.495909] dwc3_cleanup_done_reqs: trb: ff800080f1b0,trb->size: 0x0,
trb->ctrl: 0x393dc468, trb_num: 3
[ 32.495915] dwc3_cleanup_done_reqs: trb: ff800080f1c0,trb->size: 0x0,
trb->ctrl: 0x393e0478, trb_num: 3
[ 32.495920] dwc3_cleanup_done_reqs: trb: ff800080f1d0,trb->size: 0x0,
trb->ctrl: 0x393e4c78, trb_num: 3

We could see every trb has size to 0 finally.

But if I set the trb chain as:
[ 42.137322] trb: ff800080f000, trb dump: bpl: 0xe2a8c000,bph: 0x0, size:
0x2000400, ctrl: 0x46d
[ 42.137326] trb: ff800080f010, trb dump: bpl: 0xe2a8c400,bph: 0x0, size:
0x400, ctrl: 0x47d
[ 42.137330] trb: ff800080f020, trb dump: bpl: 0xe2a8c800,bph: 0x0, size:
0x400, ctrl: 0xc79

There are three trbs. The first and second has CHN bit set. The first one has
First-ISO type.
And the PCM1 filed is set to 2 for the first one. The last one has IOC bit set.
I tried to let dwc3
send the first one at DATA2 stage, the second one at DATA1 stage and the third
one at DATA0
stage.

But there result is:
[ 42.137872] dwc3_cleanup_done_reqs: trb: ff800080f000,trb->size: 0x0,
trb->ctrl: 0x2cd7c46c, trb_num: 3
[ 42.137877] dwc3_cleanup_done_reqs: trb: ff800080f010,trb->size: 0x400,
trb->ctrl: 0x47d, trb_num: 3
[ 42.137891] dwc3_cleanup_done_reqs: trb: ff800080f020,trb->size:
0x1800, trb->ctrl: 0x2cd7cc78, trb_num: 3

Only the first one is transferred correctly.

I saw the kernel code is using CHN bit. SO I believe it works fine. But it
doesn't work in my environment. Did I miss some obvious registers? Any
comments/hints are appreciated.



Just saw this thread:
http://marc.info/?t=14743911801=1=2

I am fighting with the similar issue now. The patch from Felipe can't work. I
tried that. Here is the my debugging output:
[   33.780999] trb: ff800080f080, trb dump: bpl: 0xdfb23000, bph: 0x0, size: 
0x2000400, ctrl: 0x469
[   33.781004] trb: ff800080f090, trb dump: bpl: 0xdfb23400, bph: 0x0, size: 
0x400, ctrl: 0x479
[   33.781007] trb: ff800080f0a0, trb dump: bpl: 0xdfb23800, bph: 0x0, size: 
0x400, ctrl: 0xc79


[   33.782478] dwc3_cleanup_done_reqs: trb: ff800080f080, trb->size: 0x0, 
trb->ctrl: 0x13f64468, trb_num: 3, dep->iso_xfer_num: 3993
[   33.782483] dwc3_cleanup_done_reqs: trb: ff800080f090, trb->size: 0x0, 
trb->ctrl: 0x13f68478, trb_num: 3, dep->iso_xfer_num: 3994
[   33.782488] dwc3_cleanup_done_reqs: trb: ff800080f0a0, trb->size: 0x0, 
trb->ctrl: 0x13f6cc78, trb_num: 3, dep->iso_xfer_num: 3995


We could see the trb present was transferred correctly. But they are not at
the same uframe stage. The field in trb->ctrl are not same. That means the data
was transferred at different uframe stage. And the video throughput was not
increased as well.


I have no new databook (Only have one for v2.50a). So I tested almost all the
combines I could imagine.

Per my test, the CHN bit matters a lot. If the CHN bit is set, I could get:
[ 42.137872] dwc3_cleanup_done_reqs: trb: ff800080f000,trb->size: 0x0,
trb->ctrl: 0x2cd7c46c, trb_num: 3
[ 42.137877] dwc3_cleanup_done_reqs: trb: ff800080f010,trb->size: 0x400,
trb->ctrl: 0x47d, trb_num: 3
[ 42.137891] dwc3_cleanup_done_reqs: trb: ff800080f020,trb->size:
0x1800, trb->ctrl: 0x2cd7cc78, trb_num: 3

You could see the trb1 and trb3 has same uframe number even the data trb3
present was not transferred.

BTW, I don't subscribe to this mail list. Could you please add me to
http://marc.info/?t=14743911801=1=2
? Thanks a lot.

Regards
Yin, Fengwei



Thanks a lot
Yin, Fengwei

--
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 2/3] musb: sunxi: Remove custom babble handling

2016-09-22 Thread Hans de Goede


Hi,

On 09/22/2016 04:54 PM, Bin Liu wrote:

Hi,

On Thu, Sep 22, 2016 at 02:19:00PM +0300, Hans de Goede wrote:

The musb-core now a days always treats babble errors in host mode


I don't think this statement is accurate. You might want to change it to
"The musb core already handles babble interrupt" or something else.


It is accurate if you look in the history at drivers/usb/musb
commits around 15-03-10 you will see 2 relevant commits:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/musb?id=b4dc38fd45b63e3da2bc98db5d283a15a637a2fa

"usb: musb: core: simplify musb_recover_work()"

This commits introduces calling musb_root_disconnect(musb)
on babble errors, that was not happening before which is why
I added the custom babble error handling. to the sunxi glue.

And:

"usb: musb: core: always try to recover from babble"

Where the title says it all.

Take these together and I believe that my commit msg:

"The musb-core now a days always treats babble errors in host mode
as disconnects, so there is no need for the sunxi specific handling
of this anymore."

Is quite accurate.

Regards,

Hans




Signed-off-by: Hans de Goede 
---
Changes in v2:
-This is a new patch in v2 of this patch series
---
 drivers/usb/musb/sunxi.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 1408245..82eba92 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -186,16 +186,6 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
*__hci)
if (musb->int_usb)
writeb(musb->int_usb, musb->mregs + SUNXI_MUSB_INTRUSB);

-   /*
-* sunxi musb often signals babble on low / full speed device
-* disconnect, without ever raising MUSB_INTR_DISCONNECT, since
-* normally babble never happens treat it as disconnect.
-*/
-   if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {
-   musb->int_usb &= ~MUSB_INTR_BABBLE;
-   musb->int_usb |= MUSB_INTR_DISCONNECT;
-   }
-
if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb->mregs, 0);
--
2.9.3


--
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] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

2016-09-22 Thread Alan Stern

On Thu, 22 Sep 2016, Ulf Hansson wrote:

> >> > > An observation I made, is when the sdmmc device gets runtime resumed
> >> > > (pm_runtime_get_sync()), the parent device (the usb device) may also
> >> > > become runtime resumed (unless it's already). In this sequence, but
> >> > > *only* when actually runtime resuming the usb device, the runtime PM
> >> > > core decides to update the last busy mark for the usb device. Should
> >> > > it really do that?
> >> >
> >> > Yes, that's deliberate.  The whole idea of autosuspend is to prevent
> >> > the device from being runtime-suspended too soon after it was used, and
> >> > the PM core considers runtime-resume to be a form of usage.
> >>
> >> I understand it's deliberate, but I was more question whether we
> >> actually should have the runtime PM core to behaves like this.
> >>
> >> I don't think its behaviour is consistent, as in such case all calls
> >> to __pm_runtime_resume() should trigger the runtime PM core to update
> >> the last busy mark.
> >
> > Not a bad idea...
> 
> Yes, it is. :-)
> 
> Although, I am still concerned about he inconsistent behaviour.
> 
> >
> >> Don't get me wrong, I am *not* suggesting we should do that change, as
> >> it would mean the last busy mark would be updated way too often.
> >
> > The updates aren't very expensive.  Just one atomic write.  It probably
> > takes less time than acquiring the runtime-PM spinlock.
> >
> >> Instead, perhaps it's better to leave the responsibility of updating
> >> the last busy mark to the runtime PM users solely.
> >
> > Maybe, but I think doing it once in the core, like this, can remove the
> > need for a lot of function calls in drivers.
> 
> Unfortunate not. Most updates of the last busy mark happens when a
> device is no longer required to be runtime resumed. As when a driver
> has completed to serve a request and is about to call pm_runtime_put()
> (or similar API).
> 
> So, I still believe doing it in the runtime PM core is just a waste.
> 
> I think it's better to leave the update to the users entirely, it
> would become consistent but also more flexible, as one could easily
> think of situations where you may in some cases want to update the
> last busy mark and in some other not.

You can try making this change if you want.  I'd be afraid of 
regressions.

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 2/3] musb: sunxi: Remove custom babble handling

2016-09-22 Thread Bin Liu

Hi,

On Thu, Sep 22, 2016 at 02:19:00PM +0300, Hans de Goede wrote:
> The musb-core now a days always treats babble errors in host mode

I don't think this statement is accurate. You might want to change it to
"The musb core already handles babble interrupt" or something else.

Regards,
-Bin.

> as disconnects, so there is no need for the sunxi specific handling
> of this anymore.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -This is a new patch in v2 of this patch series
> ---
>  drivers/usb/musb/sunxi.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> index 1408245..82eba92 100644
> --- a/drivers/usb/musb/sunxi.c
> +++ b/drivers/usb/musb/sunxi.c
> @@ -186,16 +186,6 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
> *__hci)
>   if (musb->int_usb)
>   writeb(musb->int_usb, musb->mregs + SUNXI_MUSB_INTRUSB);
>  
> - /*
> -  * sunxi musb often signals babble on low / full speed device
> -  * disconnect, without ever raising MUSB_INTR_DISCONNECT, since
> -  * normally babble never happens treat it as disconnect.
> -  */
> - if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {
> - musb->int_usb &= ~MUSB_INTR_BABBLE;
> - musb->int_usb |= MUSB_INTR_DISCONNECT;
> - }
> -
>   if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>   /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>   musb_ep_select(musb->mregs, 0);
> -- 
> 2.9.3
> 
--
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: use complete() instead complete_all()

2016-09-22 Thread Daniel Wagner

From: Daniel Wagner 

There is only one waiter for the completion, therefore there
is no need to use complete_all(). Let's make that clear by
using complete() instead of complete_all().

The usage pattern of the completion is:

waiter context  waker context
  reinit_completion()
  usb_esp_queue()
  wait_for_completion_interruptible()

ffs_ep0_complete()
  complete()

Signed-off-by: Daniel Wagner 
Cc: Felipe Balbi 
Cc: Michal Nazarewicz 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
---
 drivers/usb/gadget/function/f_fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 5c8429f..0c29039 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -211,7 +211,7 @@ static void ffs_ep0_complete(struct usb_ep *ep, struct 
usb_request *req)
 {
struct ffs_data *ffs = req->context;
 
-   complete_all(>ep0req_completion);
+   complete(>ep0req_completion);
 }
 
 static int __ffs_ep0_queue_wait(struct ffs_data *ffs, char *data, size_t len)
-- 
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Greg KH

On Thu, Sep 22, 2016 at 08:41:09PM +0800, Baolin Wang wrote:
> On 22 September 2016 at 20:23, Greg KH  wrote:
> > On Thu, Sep 22, 2016 at 07:43:59PM +0800, Baolin Wang wrote:
> >> From: Badhri Jagan Sridharan 
> >>
> >> Some USB managament on userspace (like Android system) rely on the uevents
> >> generated by the composition driver to generate user notifications. Thus 
> >> this
> >> patch adds uevents to be generated whenever USB changes its state: 
> >> connected,
> >> disconnected, configured.
> >>
> >> The original code was created by Badhri Jagan Sridharan, and I did some
> >> optimization.
> >>
> >> Signed-off-by: Badhri Jagan Sridharan 
> >
> > You can't just add someone's signed-off-by to a patch, go read what the
> > legal agreement you just made for someone else at a different company
> > (hint, you might get a nasty-gram from a google lawyer...)
> 
> OK. I will talk with Badhri if I can upstream these.

That's not an issue, you can keep the "From:" line on it, if you got it
in a legal way, and then just have your signed off by on it, go read the
DCO for the specifics.  I don't know why someone else told you
otherwise.

If you have _any_ questions about this, go talk to the Linaro lawyers,
they know how to handle this properly.

> >> Signed-off-by: Baolin Wang 
> >> ---
> >> Changes since v1:
> >>  - Add Badhri's Signed-off-by.
> >> ---
> >>  drivers/usb/gadget/Kconfig|8 +++
> >>  drivers/usb/gadget/configfs.c |  107 
> >> +
> >>  2 files changed, 115 insertions(+)
> >>
> >> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> >> index 2ea3fc3..9f5d0c6 100644
> >> --- a/drivers/usb/gadget/Kconfig
> >> +++ b/drivers/usb/gadget/Kconfig
> >> @@ -223,6 +223,14 @@ config USB_CONFIGFS
> >> appropriate symbolic links.
> >> For more information see Documentation/usb/gadget_configfs.txt.
> >>
> >> +config USB_CONFIGFS_UEVENT
> >> + boolean "Uevent notification of Gadget state"
> >> + depends on USB_CONFIGFS
> >
> >
> >
> >> + help
> >> +   Enable uevent notifications to userspace when the gadget
> >> +   state changes. The gadget can be in any of the following
> >> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"
> >> +
> >>  config USB_CONFIGFS_SERIAL
> >>   bool "Generic serial bulk in/out"
> >>   depends on USB_CONFIGFS
> >> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> >> index 3984787..4c2bc27 100644
> >> --- a/drivers/usb/gadget/configfs.c
> >> +++ b/drivers/usb/gadget/configfs.c
> >> @@ -60,6 +60,11 @@ struct gadget_info {
> >>   bool use_os_desc;
> >>   char b_vendor_code;
> >>   char qw_sign[OS_STRING_QW_SIGN_LEN];
> >> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> >> + bool connected;
> >> + bool sw_connected;
> >> + struct work_struct work;
> >> +#endif
> >>  };
> >>
> >>  static inline struct gadget_info *to_gadget_info(struct config_item *item)
> >> @@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct 
> >> usb_composite_driver *composite,
> >>  int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
> >> struct usb_ep *ep0);
> >>
> >> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> >> +static void configfs_work(struct work_struct *data)
> >> +{
> >> + struct gadget_info *gi = container_of(data, struct gadget_info, 
> >> work);
> >> + struct usb_composite_dev *cdev = >cdev;
> >> + char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
> >> + char *connected[2] = { "USB_STATE=CONNECTED", NULL };
> >> + char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
> >> + /* 0-connected 1-configured 2-disconnected */
> >> + bool status[3] = { false, false, false };
> >> + unsigned long flags;
> >> + bool uevent_sent = false;
> >> +
> >> + spin_lock_irqsave(>lock, flags);
> >> + if (cdev->config && gi->connected)
> >> + status[1] = true;
> >> +
> >> + if (gi->connected != gi->sw_connected) {
> >> + if (gi->connected)
> >> + status[0] = true;
> >> + else
> >> + status[2] = true;
> >> + gi->sw_connected = gi->connected;
> >> + }
> >> + spin_unlock_irqrestore(>lock, flags);
> >> +
> >> + if (status[0]) {
> >> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
> >> + pr_info("%s: sent uevent %s\n", __func__, connected[0]);
> >
> > You are kidding, right?
> >
> >> + uevent_sent = true;
> >> + }
> >> +
> >> + if (status[1]) {
> >> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
> >> + pr_info("%s: sent uevent %s\n", __func__, configured[0]);
> >
> > Come on, please...
> >
> >> + uevent_sent = true;
> >> + }
> >> +
> >> + if (status[2]) {
> >> +

Re: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Bin Liu

On Thu, Sep 22, 2016 at 01:06:46PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi  writes:
> > Felipe Balbi  writes:
> >> Bin Liu  writes:
> >>> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
>  
>  Hi,
>  
>  Bin Liu  writes:
>  > Hi,
>  >
>  > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>  >  high-speed connection.
>  >
>  > First I hacked webcam.c as follows to enable 640x480@30fps mode.
>  >
>  > diff --git a/drivers/usb/gadget/legacy/webcam.c 
>  > b/drivers/usb/gadget/legacy/webcam.c
>  > index 72c976b..9eb315f 100644
>  > --- a/drivers/usb/gadget/legacy/webcam.c
>  > +++ b/drivers/usb/gadget/legacy/webcam.c
>  > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
>  > uvc_frame_yuv_360p = {
>  > .bFrameIndex= 1,
>  > .bmCapabilities = 0,
>  > .wWidth = cpu_to_le16(640),
>  > -   .wHeight= cpu_to_le16(360),
>  > +   .wHeight= cpu_to_le16(480),
>  > .dwMinBitRate   = cpu_to_le32(18432000),
>  > .dwMaxBitRate   = cpu_to_le32(55296000),
>  > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
>  > -   .dwDefaultFrameInterval = cpu_to_le32(66),
>  > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
>  > +   .dwDefaultFrameInterval = cpu_to_le32(33),
>  > .bFrameIntervalType = 3,
>  > -   .dwFrameInterval[0] = cpu_to_le32(66),
>  > -   .dwFrameInterval[1] = cpu_to_le32(100),
>  > -   .dwFrameInterval[2] = cpu_to_le32(500),
>  > +   .dwFrameInterval[0] = cpu_to_le32(33),
>  > +   .dwFrameInterval[1] = cpu_to_le32(66),
>  > +   .dwFrameInterval[2] = cpu_to_le32(100),
>  >  };
>  >
>  > then loaded g_webcam.ko as
>  >
>  > # modprobe g_webcam streaming_maxpacket=3072
>  >
>  > The endpoint descriptor showing on the host is
>  >
>  >   Endpoint Descriptor:
>  > bLength 7
>  > bDescriptorType 5
>  > bEndpointAddress 0x8d  EP 13 IN
>  > bmAttributes5
>  >   Transfer TypeIsochronous
>  >   Synch Type   Asynchronous
>  >   Usage Type   Data
>  > wMaxPacketSize 0x1400  3x 1024 bytes
>  > bInterval   1
>  >
>  > However the usb bus trace shows only one transaction with 1024-bytes 
>  > packet in
>  > every SOF. The host only sends one IN packet in every SOF, I am 
>  > expecting 2~3
>  > 1024-bytes transactions, since this would be required to transfer 
>  > 640x480@30fps
>  > YUV frames in high-speed.
>  >
>  > DId I miss anything in the setup?
>  
>  MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
> >>>
> >>> Happened on both MUSB and DWC3.
> >>>
>  of your bus analyzer? When host sends IN token, are you replying with
> >>>
> >>> The trace screenshot on DWC3 is attached.
> >>>
>  DATA0, DATA1 or DATA2?
> >>>
> >>> Good hint! It is DATA0!
> >>
> >> yeah, should've been DATA2. I'll check if we're missing anything for
> >> High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
> >> DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
> >> about DWC3?
> >
> > I'm assuming DWC3 really breaks. Here's a patch for that:
> >
> > 8<-- cut here 
> > --
> > From 62807011c00055785575bb39d92bfe8836817e2f Mon Sep 17 00:00:00 2001
> > From: Felipe Balbi 
> > Date: Thu, 22 Sep 2016 11:01:01 +0300
> > Subject: [PATCH] usb: dwc3: gadget: set PCM1 field of isochronous-first TRBs
> >
> > In case of High-Speed, High-Bandwidth endpoints, we
> > need to tell DWC3 that we have more than one packet
> > per interval. We do that by setting PCM1 field of
> > Isochronous-First TRB.
> >
> > Signed-off-by: Felipe Balbi 
> > ---
> >  drivers/usb/dwc3/gadget.c | 14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index 602f12254161..106623faf060 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -787,6 +787,9 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
> > unsigned length, unsigned chain, unsigned node)
> >  {
> > struct dwc3_trb *trb;
> > +   struct dwc3 *dwc = dep->dwc;
> > +   struct usb_gadget   *gadget = >gadget;
> > +   enum usb_device_speed   speed

Re: [PATCH v2] musb: Export musb_root_disconnect for use in modules

2016-09-22 Thread Bin Liu

On Wed, Sep 21, 2016 at 03:51:33PM -0500, Bin Liu wrote:
> Hi,
> 
> On Sat, Sep 17, 2016 at 12:08:10PM +0200, Hans de Goede wrote:
> > Export musb_root_disconnect for use in modules, so that musb glue
> > code build as module can use it.
> > 
> > This fixes the buildbot errors for -next in arm64-allmodconfig
> > and arm-allmodconfig.
> > 
> > Fixes: 7cba17ec9adc8cf ("musb: sunxi: Add support for platform_set_mode")
> > Signed-off-by: Hans de Goede 
> 
> Applied. Thanks.

Removed it from my tree, since Greg already picked it.

Regards,
-Bin.
--
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] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

2016-09-22 Thread Oliver Neukum

On Wed, 2016-09-21 at 10:35 -0400, Alan Stern wrote:
> On Wed, 21 Sep 2016, Oliver Neukum wrote:

> > Yes, but this is not the point. A heuristic with a timeout makes
> > sense only if the uses are unpredictable. If you know with a high
> > degree of probability when the next activity comes, you ought to either
> > suspend now or not all until the next activity.
> > 
> > Likewise the heuristic is appropriate for leaf nodes. You get nothing
> > from a delay on inner nodes.
> 
> Almost true, but not quite.  When an inner node has more than one leaf
> beneath it, enabling an autosuspend delay for the inner node can make 
> sense -- particularly if the leaf activities are uncorrelated.

Well, it is true that an inner node is likelier to be woken up
depending on the number of children. That is a reason to have a longer
timeout for an inner node. But it should start when the first node goes
idle. It makes no sense to start yet another timeout when the last node
goes idle.

In terms of mathematics I think we would need to multiply the timeout
with the square root of busy children and restart it whenever a child
goes to idle.
But it seems to me that this is impractical.

So I would suggest that we are missing an API for drivers to tell the
core that they become idle for a known period of time and to propagate
that immediately up if that is the last leaf to become idle.

> > Any storage (generic sense) device
> > is an inner node. It should suspend immediately after the block
> > device which is the leaf node.
> 
> Yes.  In this case, however, the USB device has two platform devices 
> beneath it: one for SDMMC and one for MemoryStick cards.

Indeed, we can hope that the power efficient work queue used will
join the polling of both devices. Ideally we could model the mutual
exclusion.

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

Strange behavior of CHN bit with dwc3

2016-09-22 Thread yfw


Hi Felipe,
I am very sorry for the multiple sending. The previous were rejected because of 
HTML format because I used gmail web interface.


Hi list,
I tried to enable the high speed, high bandwidth transfer in device mode for iso 
type on dwc3 based soc. The platform only supports usb device 2.0.


I set the MaxPacketSize to 0x1400 so the host could allocate 3072 bytes for 
uframe. But when I chain three trbs together, the dwc3 behavior is quite weird:


If I set the individual trb as following:
[ 32.495556] trb: ff800080f1b0, trb dump: bpl: 0xec803000,bph: 0x0, size: 
0x400, ctrl: 0x469
[ 32.495560] trb: ff800080f1c0, trb dump: bpl: 0xec803400,bph: 0x0, size: 
0x400, ctrl: 0x469
[ 32.495564] trb: ff800080f1d0, trb dump: bpl: 0xec803800,bph: 0x0, size: 
0x400, ctrl: 0xc69


It's actually not high bandwidth. Just normal ISO transfer. Everything is fine. 
I got following msg:
[ 32.495909] dwc3_cleanup_done_reqs: trb: ff800080f1b0,trb->size: 0x0, 
trb->ctrl: 0x393dc468, trb_num: 3
[ 32.495915] dwc3_cleanup_done_reqs: trb: ff800080f1c0,trb->size: 0x0, 
trb->ctrl: 0x393e0478, trb_num: 3
[ 32.495920] dwc3_cleanup_done_reqs: trb: ff800080f1d0,trb->size: 0x0, 
trb->ctrl: 0x393e4c78, trb_num: 3


We could see every trb has size to 0 finally.

But if I set the trb chain as:
[ 42.137322] trb: ff800080f000, trb dump: bpl: 0xe2a8c000,bph: 0x0, size: 
0x2000400, ctrl: 0x46d
[ 42.137326] trb: ff800080f010, trb dump: bpl: 0xe2a8c400,bph: 0x0, size: 
0x400, ctrl: 0x47d
[ 42.137330] trb: ff800080f020, trb dump: bpl: 0xe2a8c800,bph: 0x0, size: 
0x400, ctrl: 0xc79


There are three trbs. The first and second has CHN bit set. The first one has 
First-ISO type.
And the PCM1 filed is set to 2 for the first one. The last one has IOC bit set. 
I tried to let dwc3
send the first one at DATA2 stage, the second one at DATA1 stage and the third 
one at DATA0

stage.

But there result is:
[ 42.137872] dwc3_cleanup_done_reqs: trb: ff800080f000,trb->size: 0x0, 
trb->ctrl: 0x2cd7c46c, trb_num: 3
[ 42.137877] dwc3_cleanup_done_reqs: trb: ff800080f010,trb->size: 0x400, 
trb->ctrl: 0x47d, trb_num: 3
[ 42.137891] dwc3_cleanup_done_reqs: trb: ff800080f020,trb->size: 
0x1800, trb->ctrl: 0x2cd7cc78, trb_num: 3


Only the first one is transferred correctly.

I saw the kernel code is using CHN bit. SO I believe it works fine. But it 
doesn't work in my environment. Did I miss some obvious registers? Any 
comments/hints are appreciated.



Thanks a lot
Yin, Fengwei
--
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] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Felipe Balbi



Hi,

Baolin Wang  writes:
>>>  static const struct usb_gadget_driver configfs_driver_template = {
>>>   .bind   = configfs_composite_bind,
>>>   .unbind = configfs_composite_unbind,
>>>
>>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>>> + .setup  = configfs_setup,
>>> + .reset  = configfs_disconnect,
>>> + .disconnect = configfs_disconnect,
>>> +#else
>>>   .setup  = composite_setup,
>>>   .reset  = composite_disconnect,
>>>   .disconnect = composite_disconnect,
>>> +#endif

nope, this is quite wrong.

>>> @@ -1453,6 +1556,10 @@ static struct config_group *gadgets_make(
>>>   gi->composite.gadget_driver.function = kstrdup(name, GFP_KERNEL);
>>>   gi->composite.name = gi->composite.gadget_driver.function;
>>>
>>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>>> + INIT_WORK(>work, configfs_work);
>>> +#endif
>>
>> This is just way too ugly, please make it so there are no #ifdefs in the
>> .c files.
>>
>> Or, as others said, why is this a build option at all, why would you not
>> always want this enabled if you are relying on it all of the time?
>
> Sometimes userspace does not need the notification, it is not all the
> time. Anyway I will remove the macro if you still insist on that.

what's wrong with the sysfs we already have for this?

-- 
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: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang

On 22 September 2016 at 20:23, Greg KH  wrote:
> On Thu, Sep 22, 2016 at 07:43:59PM +0800, Baolin Wang wrote:
>> From: Badhri Jagan Sridharan 
>>
>> Some USB managament on userspace (like Android system) rely on the uevents
>> generated by the composition driver to generate user notifications. Thus this
>> patch adds uevents to be generated whenever USB changes its state: connected,
>> disconnected, configured.
>>
>> The original code was created by Badhri Jagan Sridharan, and I did some
>> optimization.
>>
>> Signed-off-by: Badhri Jagan Sridharan 
>
> You can't just add someone's signed-off-by to a patch, go read what the
> legal agreement you just made for someone else at a different company
> (hint, you might get a nasty-gram from a google lawyer...)

OK. I will talk with Badhri if I can upstream these.

>
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes since v1:
>>  - Add Badhri's Signed-off-by.
>> ---
>>  drivers/usb/gadget/Kconfig|8 +++
>>  drivers/usb/gadget/configfs.c |  107 
>> +
>>  2 files changed, 115 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index 2ea3fc3..9f5d0c6 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -223,6 +223,14 @@ config USB_CONFIGFS
>> appropriate symbolic links.
>> For more information see Documentation/usb/gadget_configfs.txt.
>>
>> +config USB_CONFIGFS_UEVENT
>> + boolean "Uevent notification of Gadget state"
>> + depends on USB_CONFIGFS
>
>
>
>> + help
>> +   Enable uevent notifications to userspace when the gadget
>> +   state changes. The gadget can be in any of the following
>> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"
>> +
>>  config USB_CONFIGFS_SERIAL
>>   bool "Generic serial bulk in/out"
>>   depends on USB_CONFIGFS
>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
>> index 3984787..4c2bc27 100644
>> --- a/drivers/usb/gadget/configfs.c
>> +++ b/drivers/usb/gadget/configfs.c
>> @@ -60,6 +60,11 @@ struct gadget_info {
>>   bool use_os_desc;
>>   char b_vendor_code;
>>   char qw_sign[OS_STRING_QW_SIGN_LEN];
>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>> + bool connected;
>> + bool sw_connected;
>> + struct work_struct work;
>> +#endif
>>  };
>>
>>  static inline struct gadget_info *to_gadget_info(struct config_item *item)
>> @@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct usb_composite_driver 
>> *composite,
>>  int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
>> struct usb_ep *ep0);
>>
>> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
>> +static void configfs_work(struct work_struct *data)
>> +{
>> + struct gadget_info *gi = container_of(data, struct gadget_info, work);
>> + struct usb_composite_dev *cdev = >cdev;
>> + char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
>> + char *connected[2] = { "USB_STATE=CONNECTED", NULL };
>> + char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
>> + /* 0-connected 1-configured 2-disconnected */
>> + bool status[3] = { false, false, false };
>> + unsigned long flags;
>> + bool uevent_sent = false;
>> +
>> + spin_lock_irqsave(>lock, flags);
>> + if (cdev->config && gi->connected)
>> + status[1] = true;
>> +
>> + if (gi->connected != gi->sw_connected) {
>> + if (gi->connected)
>> + status[0] = true;
>> + else
>> + status[2] = true;
>> + gi->sw_connected = gi->connected;
>> + }
>> + spin_unlock_irqrestore(>lock, flags);
>> +
>> + if (status[0]) {
>> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
>> + pr_info("%s: sent uevent %s\n", __func__, connected[0]);
>
> You are kidding, right?
>
>> + uevent_sent = true;
>> + }
>> +
>> + if (status[1]) {
>> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
>> + pr_info("%s: sent uevent %s\n", __func__, configured[0]);
>
> Come on, please...
>
>> + uevent_sent = true;
>> + }
>> +
>> + if (status[2]) {
>> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, disconnected);
>> + pr_info("%s: sent uevent %s\n", __func__, disconnected[0]);
>
> This is getting funny...
>
>> + uevent_sent = true;
>> + }
>> +
>> + if (!uevent_sent) {
>> + pr_info("%s: did not send uevent (%d %d %p)\n", __func__,
>> + gi->connected, gi->sw_connected, cdev->config);
>
> Nope, not funny anymore.
>
>> + }
>> +}
>> +#endif
>> +
>>  static void purge_configs_funcs(struct gadget_info *gi)
>>  {
>>   struct usb_configuration*c;
>> @@ -1386,13 +1442,60 @@ static void configfs_composite_unbind(struct 
>>

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum

On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:
> On Thu, Sep 22, 2016 at 11:18 AM, Binyamin Sharet  
> wrote:
> > On Thu, Sep 22, 2016 at 11:02 AM, Oliver Neukum  wrote:
> >> On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
> >>> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
> >>> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
> >>> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley 
> >>> >>  wrote:
> >>> >> >
> >>> >> Malcolm, just to make it clear, this bug was not found with an
> >>> >> actual device, but with emulation.
> >>> >
> >>> > It was quite peculiar a bug, though. Could you prepare a test kernel
> >>> > without BPF?
> >>> >
> >>> > Regards
> >>> > Oliver
> >>> >
> >>> >
> >>>
> >>> Oliver,
> >>>
> >>> If this question was directed to me, I will need some clarification
> >>> of what is needed (and also - what's BPF?)
> >>
> >> BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
> >> socket)
> >>
> >> The oops you reproduced was in the BPF. That is rather generic code
> >> without connection to the driver in question. That raises the question
> >> whether you've accidentally triggered a generic bug.
> >> To rule that out a rerun on a kernel compiled without CONFIG_BPF would
> >> be useful. Or you could build an initrd with the BPF modules
> >> blacklisted, so we are sure the test system does not use BPF.
> >>
> >> Regards
> >> Oliver
> >>
> >>
> >>
> >
> > Thanks Oliver, will do.
> >
> > -- Binyamin
> 
> I compiled the kernel without BPF and still got an issue (attached)
> How can I verify the BPF is not enabled/part of the kernel?

Do you have CONFIG_BPF_JIT enabled?

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: [PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Greg KH

On Thu, Sep 22, 2016 at 07:43:59PM +0800, Baolin Wang wrote:
> From: Badhri Jagan Sridharan 
> 
> Some USB managament on userspace (like Android system) rely on the uevents
> generated by the composition driver to generate user notifications. Thus this
> patch adds uevents to be generated whenever USB changes its state: connected,
> disconnected, configured.
> 
> The original code was created by Badhri Jagan Sridharan, and I did some
> optimization.
> 
> Signed-off-by: Badhri Jagan Sridharan 

You can't just add someone's signed-off-by to a patch, go read what the
legal agreement you just made for someone else at a different company
(hint, you might get a nasty-gram from a google lawyer...)

> Signed-off-by: Baolin Wang 
> ---
> Changes since v1:
>  - Add Badhri's Signed-off-by.
> ---
>  drivers/usb/gadget/Kconfig|8 +++
>  drivers/usb/gadget/configfs.c |  107 
> +
>  2 files changed, 115 insertions(+)
> 
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index 2ea3fc3..9f5d0c6 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -223,6 +223,14 @@ config USB_CONFIGFS
> appropriate symbolic links.
> For more information see Documentation/usb/gadget_configfs.txt.
>  
> +config USB_CONFIGFS_UEVENT
> + boolean "Uevent notification of Gadget state"
> + depends on USB_CONFIGFS



> + help
> +   Enable uevent notifications to userspace when the gadget
> +   state changes. The gadget can be in any of the following
> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"
> +
>  config USB_CONFIGFS_SERIAL
>   bool "Generic serial bulk in/out"
>   depends on USB_CONFIGFS
> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> index 3984787..4c2bc27 100644
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -60,6 +60,11 @@ struct gadget_info {
>   bool use_os_desc;
>   char b_vendor_code;
>   char qw_sign[OS_STRING_QW_SIGN_LEN];
> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> + bool connected;
> + bool sw_connected;
> + struct work_struct work;
> +#endif
>  };
>  
>  static inline struct gadget_info *to_gadget_info(struct config_item *item)
> @@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct usb_composite_driver 
> *composite,
>  int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
> struct usb_ep *ep0);
>  
> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> +static void configfs_work(struct work_struct *data)
> +{
> + struct gadget_info *gi = container_of(data, struct gadget_info, work);
> + struct usb_composite_dev *cdev = >cdev;
> + char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
> + char *connected[2] = { "USB_STATE=CONNECTED", NULL };
> + char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
> + /* 0-connected 1-configured 2-disconnected */
> + bool status[3] = { false, false, false };
> + unsigned long flags;
> + bool uevent_sent = false;
> +
> + spin_lock_irqsave(>lock, flags);
> + if (cdev->config && gi->connected)
> + status[1] = true;
> +
> + if (gi->connected != gi->sw_connected) {
> + if (gi->connected)
> + status[0] = true;
> + else
> + status[2] = true;
> + gi->sw_connected = gi->connected;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (status[0]) {
> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
> + pr_info("%s: sent uevent %s\n", __func__, connected[0]);

You are kidding, right?

> + uevent_sent = true;
> + }
> +
> + if (status[1]) {
> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
> + pr_info("%s: sent uevent %s\n", __func__, configured[0]);

Come on, please...

> + uevent_sent = true;
> + }
> +
> + if (status[2]) {
> + kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, disconnected);
> + pr_info("%s: sent uevent %s\n", __func__, disconnected[0]);

This is getting funny...

> + uevent_sent = true;
> + }
> +
> + if (!uevent_sent) {
> + pr_info("%s: did not send uevent (%d %d %p)\n", __func__,
> + gi->connected, gi->sw_connected, cdev->config);

Nope, not funny anymore.

> + }
> +}
> +#endif
> +
>  static void purge_configs_funcs(struct gadget_info *gi)
>  {
>   struct usb_configuration*c;
> @@ -1386,13 +1442,60 @@ static void configfs_composite_unbind(struct 
> usb_gadget *gadget)
>   set_gadget_data(gadget, NULL);
>  }
>  
> +#ifdef CONFIG_USB_CONFIGFS_UEVENT
> +static int configfs_setup(struct usb_gadget *gadget,
> +   const struct usb_ctrlrequest *c)
> +{
> + struct usb_composite_dev *cdev =

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet

On Thu, Sep 22, 2016 at 11:18 AM, Binyamin Sharet  wrote:
> On Thu, Sep 22, 2016 at 11:02 AM, Oliver Neukum  wrote:
>> On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
>>> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
>>> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
>>> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
>>> >> wrote:
>>> >> >
>>> >> Malcolm, just to make it clear, this bug was not found with an
>>> >> actual device, but with emulation.
>>> >
>>> > It was quite peculiar a bug, though. Could you prepare a test kernel
>>> > without BPF?
>>> >
>>> > Regards
>>> > Oliver
>>> >
>>> >
>>>
>>> Oliver,
>>>
>>> If this question was directed to me, I will need some clarification
>>> of what is needed (and also - what's BPF?)
>>
>> BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
>> socket)
>>
>> The oops you reproduced was in the BPF. That is rather generic code
>> without connection to the driver in question. That raises the question
>> whether you've accidentally triggered a generic bug.
>> To rule that out a rerun on a kernel compiled without CONFIG_BPF would
>> be useful. Or you could build an initrd with the BPF modules
>> blacklisted, so we are sure the test system does not use BPF.
>>
>> Regards
>> Oliver
>>
>>
>>
>
> Thanks Oliver, will do.
>
> -- Binyamin

I compiled the kernel without BPF and still got an issue (attached)
How can I verify the BPF is not enabled/part of the kernel?

-- Binyamin
[   70.514366] usb 1-1.2: new full-speed USB device number 6 using ehci-pci
[   70.815709] usb 1-1.2: New USB device found, idVendor=160a, idProduct=3184
[   70.815713] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   70.815715] usb 1-1.2: Product: UMAP2. PID:0x3184
[   70.815717] usb 1-1.2: Manufacturer: UMAP2. VID:0x160a
[   70.815719] usb 1-1.2: SerialNumber: 123456
[   70.995314] vt6656_stage: module is from the staging directory, the quality is unknown, you have been warned.
[   70.995843] usb 1-1.2: VIA Networking Wireless LAN USB Driver Ver. mac80211
[   70.995844] usb 1-1.2: Copyright (c) 2004 VIA Networking Technologies, Inc.
[   71.073733] usb 1-1.2: reset full-speed USB device number 6 using ehci-pci
[   71.316005] usb 1-1.2: Starting mac80211
[   71.316051] usb 1-1.2: VIA Networking Wireless LAN USB Driver Ver. mac80211
[   71.316053] usb 1-1.2: Copyright (c) 2004 VIA Networking Technologies, Inc.
[   71.319384] usb 1-1.2: Direct firmware load for vntwusb.fw failed with error -2
[   71.319389] usb 1-1.2: firmware file vntwusb.fw request failed (-2)
[   71.319396] usb 1-1.2: failed to start
[   71.346203] usb 1-1.2: VIA Networking Wireless LAN USB Driver Ver. mac80211
[   71.346206] usb 1-1.2: Copyright (c) 2004 VIA Networking Technologies, Inc.
[   71.346222] usb 1-1.2: usb_device_reset fail status=-22
[   71.346232] usb 1-1.2: usb_device_reset fail status=-19
[   71.346283] usbcore: registered new interface driver vt6656
[   71.347035] usb 1-1.2: Starting mac80211
[   71.347052] usb 1-1.2: Direct firmware load for vntwusb.fw failed with error -2
[   71.347055] usb 1-1.2: firmware file vntwusb.fw request failed (-2)
[   71.347058] usb 1-1.2: failed to start
[   71.347068] usb 1-1.2: Starting mac80211
[   71.347077] usb 1-1.2: Direct firmware load for vntwusb.fw failed with error -2
[   71.347079] usb 1-1.2: firmware file vntwusb.fw request failed (-2)
[   71.347081] usb 1-1.2: failed to start
[   71.347376] usb 1-1.2: USB disconnect, device number 6
[   71.393522] BUG: unable to handle kernel paging request at be2280a05fe8
[   71.393581] IP: [] find_vmap_area+0x25/0x60
[   71.393613] PGD 13348f067 PUD 133494067 PMD 12d762067 PTE 0
[   71.393648] Oops:  [#1] SMP
[   71.393663] Modules linked in: vt6656_stage(C) rfcomm bnep arc4 iwldvm snd_hda_codec_hdmi intel_powerclamp coretemp snd_hda_codec_conexant mac80211 snd_hda_codec_generic kvm_intel snd_hda_intel kvm snd_hda_codec snd_hda_core uvcvideo btusb irqbypass crct10dif_pclmul btrtl videobuf2_vmalloc crc32_pclmul videobuf2_memops videobuf2_v4l2 btbcm ghash_clmulni_intel snd_hwdep joydev btintel videobuf2_core iwlwifi bluetooth thinkpad_acpi videodev aesni_intel snd_pcm input_leds aes_x86_64 media lrw gf128mul nvram snd_seq_midi glue_helper snd_seq_midi_event cfg80211 snd_rawmidi snd_seq ablk_helper snd_seq_device serio_raw snd_timer cryptd mei_me mei snd intel_ips lpc_ich shpchp soundcore mac_hid parport_pc ppdev lp parport autofs4 i915 psmouse i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
[   71.394087]  ahci drm libahci e1000e ptp pps_core wmi fjes video
[   71.394134] CPU: 2 PID: 23 Comm: kworker/2:0 Tainted: G C  4.8.0-rc2-nobpf+ #14
[   71.394162] Hardware name: LENOVO 4492A56/4492A56, BIOS 6QET44WW (1.14 ) 04/20/2010
[   71.394192] Workqueue: events bpf_prog_free_deferred
[

[PATCH v2] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang

From: Badhri Jagan Sridharan 

Some USB managament on userspace (like Android system) rely on the uevents
generated by the composition driver to generate user notifications. Thus this
patch adds uevents to be generated whenever USB changes its state: connected,
disconnected, configured.

The original code was created by Badhri Jagan Sridharan, and I did some
optimization.

Signed-off-by: Badhri Jagan Sridharan 
Signed-off-by: Baolin Wang 
---
Changes since v1:
 - Add Badhri's Signed-off-by.
---
 drivers/usb/gadget/Kconfig|8 +++
 drivers/usb/gadget/configfs.c |  107 +
 2 files changed, 115 insertions(+)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 2ea3fc3..9f5d0c6 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -223,6 +223,14 @@ config USB_CONFIGFS
  appropriate symbolic links.
  For more information see Documentation/usb/gadget_configfs.txt.
 
+config USB_CONFIGFS_UEVENT
+   boolean "Uevent notification of Gadget state"
+   depends on USB_CONFIGFS
+   help
+ Enable uevent notifications to userspace when the gadget
+ state changes. The gadget can be in any of the following
+ three states: "CONNECTED/DISCONNECTED/CONFIGURED"
+
 config USB_CONFIGFS_SERIAL
bool "Generic serial bulk in/out"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 3984787..4c2bc27 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -60,6 +60,11 @@ struct gadget_info {
bool use_os_desc;
char b_vendor_code;
char qw_sign[OS_STRING_QW_SIGN_LEN];
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+   bool connected;
+   bool sw_connected;
+   struct work_struct work;
+#endif
 };
 
 static inline struct gadget_info *to_gadget_info(struct config_item *item)
@@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct usb_composite_driver 
*composite,
 int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
  struct usb_ep *ep0);
 
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+static void configfs_work(struct work_struct *data)
+{
+   struct gadget_info *gi = container_of(data, struct gadget_info, work);
+   struct usb_composite_dev *cdev = >cdev;
+   char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
+   char *connected[2] = { "USB_STATE=CONNECTED", NULL };
+   char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
+   /* 0-connected 1-configured 2-disconnected */
+   bool status[3] = { false, false, false };
+   unsigned long flags;
+   bool uevent_sent = false;
+
+   spin_lock_irqsave(>lock, flags);
+   if (cdev->config && gi->connected)
+   status[1] = true;
+
+   if (gi->connected != gi->sw_connected) {
+   if (gi->connected)
+   status[0] = true;
+   else
+   status[2] = true;
+   gi->sw_connected = gi->connected;
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (status[0]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
+   pr_info("%s: sent uevent %s\n", __func__, connected[0]);
+   uevent_sent = true;
+   }
+
+   if (status[1]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
+   pr_info("%s: sent uevent %s\n", __func__, configured[0]);
+   uevent_sent = true;
+   }
+
+   if (status[2]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, disconnected);
+   pr_info("%s: sent uevent %s\n", __func__, disconnected[0]);
+   uevent_sent = true;
+   }
+
+   if (!uevent_sent) {
+   pr_info("%s: did not send uevent (%d %d %p)\n", __func__,
+   gi->connected, gi->sw_connected, cdev->config);
+   }
+}
+#endif
+
 static void purge_configs_funcs(struct gadget_info *gi)
 {
struct usb_configuration*c;
@@ -1386,13 +1442,60 @@ static void configfs_composite_unbind(struct usb_gadget 
*gadget)
set_gadget_data(gadget, NULL);
 }
 
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+static int configfs_setup(struct usb_gadget *gadget,
+ const struct usb_ctrlrequest *c)
+{
+   struct usb_composite_dev *cdev = get_gadget_data(gadget);
+   struct gadget_info *gi = container_of(cdev, struct gadget_info, cdev);
+   int value = -EOPNOTSUPP;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   if (!gi->connected) {
+   gi->connected = 1;
+   schedule_work(>work);
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   value = composite_setup(gadget, c);
+
+   spin_lock_irqsave(>lock, flags);
+   if (c->bRequest ==

[PATCH v2 3/3] musb: sunxi: Force session end on babble errors in host-mode

2016-09-22 Thread Hans de Goede

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.

Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control).

This commit adds a sunxi_musb_recover() callback which makes
sunxi_musb_work call phy_set_mode with the current mode, which
will force end the current session.

This fixes the musb controller getting stuck in this state on systems
without Vbus control; and also fixes the need to unplug the usb-b ->
usb-a cable to get out of this state on systems with Vbus control.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use musb_platform_recover callback instead of using DYI code in the
 interrupt handler
-Call phy_set_mode with the current mode instead of adding a new custom
 sunxi phy callback
---
 drivers/usb/musb/sunxi.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 82eba92..d0be0ea 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -380,6 +380,20 @@ static int sunxi_musb_set_mode(struct musb *musb, u8 mode)
return 0;
 }
 
+static int sunxi_musb_recover(struct musb *musb)
+{
+   struct sunxi_glue *glue = dev_get_drvdata(musb->controller->parent);
+
+   /*
+* Schedule a phy_set_mode with the current glue->phy_mode value,
+* this will force end the current session.
+*/
+   set_bit(SUNXI_MUSB_FL_PHY_MODE_PEND, >flags);
+   schedule_work(>work);
+
+   return 0;
+}
+
 /*
  * sunxi musb register layout
  * 0x00 - 0x17 fifo regs, 1 long per fifo
@@ -608,6 +622,7 @@ static const struct musb_platform_ops sunxi_musb_ops = {
.dma_init   = sunxi_musb_dma_controller_create,
.dma_exit   = sunxi_musb_dma_controller_destroy,
.set_mode   = sunxi_musb_set_mode,
+   .recover= sunxi_musb_recover,
.set_vbus   = sunxi_musb_set_vbus,
.pre_root_reset_end = sunxi_musb_pre_root_reset_end,
.post_root_reset_end = sunxi_musb_post_root_reset_end,
-- 
2.9.3

--
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] phy_sun4i_usb: set_mode: Allow using set_mode to force end the current session

2016-09-22 Thread Hans de Goede

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.

Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control).

This commit modifies sun4i_usb_phy_set_mode so that it will force
end the current session when called with the current mode, before this
commit calling set_mode with the current mode was a nop since id_det
would stay the same resulting in the detect_work not doing anything.

This allows the sunxi-musb glue to use sun4i_usb_phy_set_mode to force
end the current session without changing the mode, to fixup the stuck
state after a babble error.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this series replacing the
 "phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function"
 from v1
---
 drivers/phy/phy-sun4i-usb.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 43c0d98..d76538c 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -437,25 +437,32 @@ static int sun4i_usb_phy_set_mode(struct phy *_phy, enum 
phy_mode mode)
 {
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+   enum usb_dr_mode new_mode;
 
if (phy->index != 0)
return -EINVAL;
 
switch (mode) {
case PHY_MODE_USB_HOST:
-   data->dr_mode = USB_DR_MODE_HOST;
+   new_mode = USB_DR_MODE_HOST;
break;
case PHY_MODE_USB_DEVICE:
-   data->dr_mode = USB_DR_MODE_PERIPHERAL;
+   new_mode = USB_DR_MODE_PERIPHERAL;
break;
case PHY_MODE_USB_OTG:
-   data->dr_mode = USB_DR_MODE_OTG;
+   new_mode = USB_DR_MODE_OTG;
break;
default:
return -EINVAL;
}
 
-   dev_info(&_phy->dev, "Changing dr_mode to %d\n", (int)data->dr_mode);
+   if (new_mode != data->dr_mode) {
+   dev_info(&_phy->dev, "Changing dr_mode to %d\n",
+(int)data->dr_mode);
+   data->dr_mode = new_mode;
+   }
+
+   data->id_det = -1; /* Force reprocessing of id */
data->force_session_end = true;
queue_delayed_work(system_wq, >detect, 0);
 
-- 
2.9.3

--
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 2/3] musb: sunxi: Remove custom babble handling

2016-09-22 Thread Hans de Goede

The musb-core now a days always treats babble errors in host mode
as disconnects, so there is no need for the sunxi specific handling
of this anymore.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-This is a new patch in v2 of this patch series
---
 drivers/usb/musb/sunxi.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 1408245..82eba92 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -186,16 +186,6 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
*__hci)
if (musb->int_usb)
writeb(musb->int_usb, musb->mregs + SUNXI_MUSB_INTRUSB);
 
-   /*
-* sunxi musb often signals babble on low / full speed device
-* disconnect, without ever raising MUSB_INTR_DISCONNECT, since
-* normally babble never happens treat it as disconnect.
-*/
-   if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {
-   musb->int_usb &= ~MUSB_INTR_BABBLE;
-   musb->int_usb |= MUSB_INTR_DISCONNECT;
-   }
-
if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb->mregs, 0);
-- 
2.9.3

--
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: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang

On 22 September 2016 at 18:58, Mark Brown  wrote:
> On Thu, Sep 22, 2016 at 06:53:12PM +0800, Baolin Wang wrote:
>> From: Badhri Jagan Sridharan 
>>
>> Some USB managament on userspace (like Android system) rely on the uevents
>> generated by the composition driver to generate user notifications. Thus this
>> patch adds uevents to be generated whenever USB changes its state: connected,
>> disconnected, configured.
>>
>> The original code was created by Badhri Jagan Sridharan, and I did some
>> optimization.
>>
>> CC: Badhri Jagan Sridharan 
>> Signed-off-by: Baolin Wang 
>
> If you're sending a patch someone else wrote you need their
> Signed-off-by - if they didn't provide one you need to talk to them
> about that and get it.

Ah, I missed that. I will add it if there are no objection from Badhr.i

>
>> +config USB_CONFIGFS_UEVENT
>> + boolean "Uevent notification of Gadget state"
>> + depends on USB_CONFIGFS
>> + help
>> +   Enable uevent notifications to userspace when the gadget
>> +   state changes. The gadget can be in any of the following
>> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"
>
> Why not just generate the events unconditionally?

If userspace doesn't need notification, then we can save some time to
do the enumeration without the uevent things.

-- 
Baolin.wang
Best Regards
--
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: Add uevent to notify userspace

2016-09-22 Thread Mark Brown

On Thu, Sep 22, 2016 at 06:53:12PM +0800, Baolin Wang wrote:
> From: Badhri Jagan Sridharan 
> 
> Some USB managament on userspace (like Android system) rely on the uevents
> generated by the composition driver to generate user notifications. Thus this
> patch adds uevents to be generated whenever USB changes its state: connected,
> disconnected, configured.
> 
> The original code was created by Badhri Jagan Sridharan, and I did some
> optimization.
> 
> CC: Badhri Jagan Sridharan 
> Signed-off-by: Baolin Wang 

If you're sending a patch someone else wrote you need their
Signed-off-by - if they didn't provide one you need to talk to them
about that and get it.

> +config USB_CONFIGFS_UEVENT
> + boolean "Uevent notification of Gadget state"
> + depends on USB_CONFIGFS
> + help
> +   Enable uevent notifications to userspace when the gadget
> +   state changes. The gadget can be in any of the following
> +   three states: "CONNECTED/DISCONNECTED/CONFIGURED"

Why not just generate the events unconditionally?


signature.asc
Description: PGP signature

[PATCH] usb: gadget: Add uevent to notify userspace

2016-09-22 Thread Baolin Wang

From: Badhri Jagan Sridharan 

Some USB managament on userspace (like Android system) rely on the uevents
generated by the composition driver to generate user notifications. Thus this
patch adds uevents to be generated whenever USB changes its state: connected,
disconnected, configured.

The original code was created by Badhri Jagan Sridharan, and I did some
optimization.

CC: Badhri Jagan Sridharan 
Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig|8 +++
 drivers/usb/gadget/configfs.c |  107 +
 2 files changed, 115 insertions(+)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 2ea3fc3..9f5d0c6 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -223,6 +223,14 @@ config USB_CONFIGFS
  appropriate symbolic links.
  For more information see Documentation/usb/gadget_configfs.txt.
 
+config USB_CONFIGFS_UEVENT
+   boolean "Uevent notification of Gadget state"
+   depends on USB_CONFIGFS
+   help
+ Enable uevent notifications to userspace when the gadget
+ state changes. The gadget can be in any of the following
+ three states: "CONNECTED/DISCONNECTED/CONFIGURED"
+
 config USB_CONFIGFS_SERIAL
bool "Generic serial bulk in/out"
depends on USB_CONFIGFS
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 3984787..4c2bc27 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -60,6 +60,11 @@ struct gadget_info {
bool use_os_desc;
char b_vendor_code;
char qw_sign[OS_STRING_QW_SIGN_LEN];
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+   bool connected;
+   bool sw_connected;
+   struct work_struct work;
+#endif
 };
 
 static inline struct gadget_info *to_gadget_info(struct config_item *item)
@@ -1197,6 +1202,57 @@ int composite_dev_prepare(struct usb_composite_driver 
*composite,
 int composite_os_desc_req_prepare(struct usb_composite_dev *cdev,
  struct usb_ep *ep0);
 
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+static void configfs_work(struct work_struct *data)
+{
+   struct gadget_info *gi = container_of(data, struct gadget_info, work);
+   struct usb_composite_dev *cdev = >cdev;
+   char *disconnected[2] = { "USB_STATE=DISCONNECTED", NULL };
+   char *connected[2] = { "USB_STATE=CONNECTED", NULL };
+   char *configured[2] = { "USB_STATE=CONFIGURED", NULL };
+   /* 0-connected 1-configured 2-disconnected */
+   bool status[3] = { false, false, false };
+   unsigned long flags;
+   bool uevent_sent = false;
+
+   spin_lock_irqsave(>lock, flags);
+   if (cdev->config && gi->connected)
+   status[1] = true;
+
+   if (gi->connected != gi->sw_connected) {
+   if (gi->connected)
+   status[0] = true;
+   else
+   status[2] = true;
+   gi->sw_connected = gi->connected;
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   if (status[0]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, connected);
+   pr_info("%s: sent uevent %s\n", __func__, connected[0]);
+   uevent_sent = true;
+   }
+
+   if (status[1]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, configured);
+   pr_info("%s: sent uevent %s\n", __func__, configured[0]);
+   uevent_sent = true;
+   }
+
+   if (status[2]) {
+   kobject_uevent_env(>dev->kobj, KOBJ_CHANGE, disconnected);
+   pr_info("%s: sent uevent %s\n", __func__, disconnected[0]);
+   uevent_sent = true;
+   }
+
+   if (!uevent_sent) {
+   pr_info("%s: did not send uevent (%d %d %p)\n", __func__,
+   gi->connected, gi->sw_connected, cdev->config);
+   }
+}
+#endif
+
 static void purge_configs_funcs(struct gadget_info *gi)
 {
struct usb_configuration*c;
@@ -1386,13 +1442,60 @@ static void configfs_composite_unbind(struct usb_gadget 
*gadget)
set_gadget_data(gadget, NULL);
 }
 
+#ifdef CONFIG_USB_CONFIGFS_UEVENT
+static int configfs_setup(struct usb_gadget *gadget,
+ const struct usb_ctrlrequest *c)
+{
+   struct usb_composite_dev *cdev = get_gadget_data(gadget);
+   struct gadget_info *gi = container_of(cdev, struct gadget_info, cdev);
+   int value = -EOPNOTSUPP;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   if (!gi->connected) {
+   gi->connected = 1;
+   schedule_work(>work);
+   }
+   spin_unlock_irqrestore(>lock, flags);
+
+   value = composite_setup(gadget, c);
+
+   spin_lock_irqsave(>lock, flags);
+   if (c->bRequest == USB_REQ_SET_CONFIGURATION && cdev->config)
+   schedule_work(>work);
+

Re: [PATCH] mmc: rtsx_usb_sdmmc: Handle runtime PM while changing led

2016-09-22 Thread Ulf Hansson

On 21 September 2016 at 16:45, Alan Stern  wrote:
> On Wed, 21 Sep 2016, Ulf Hansson wrote:
>
>> > > My concern is also 2s autosuspend timeout which is set for the usb
>> > > device. Somehow I feel we need to be able "share" more information
>> > > between a parent-child relationship, in this case between the sdmmc
>> > > device and the usb device.
>> >
>> > I agree, but it's not clear how this should be done.  One easy solution
>> > would be to turn off USB autosuspend and do all the runtime-PM
>> > management in the sdmmc and memstick drivers.
>>
>> Hmm, this could be a very good option. In the end the sdmmc/memstick
>> drivers knows best about which autosuspend timeout to use.
>
> I tend to agree, and so does Oliver.

Okay.

>
>> > > An observation I made, is when the sdmmc device gets runtime resumed
>> > > (pm_runtime_get_sync()), the parent device (the usb device) may also
>> > > become runtime resumed (unless it's already). In this sequence, but
>> > > *only* when actually runtime resuming the usb device, the runtime PM
>> > > core decides to update the last busy mark for the usb device. Should
>> > > it really do that?
>> >
>> > Yes, that's deliberate.  The whole idea of autosuspend is to prevent
>> > the device from being runtime-suspended too soon after it was used, and
>> > the PM core considers runtime-resume to be a form of usage.
>>
>> I understand it's deliberate, but I was more question whether we
>> actually should have the runtime PM core to behaves like this.
>>
>> I don't think its behaviour is consistent, as in such case all calls
>> to __pm_runtime_resume() should trigger the runtime PM core to update
>> the last busy mark.
>
> Not a bad idea...

Yes, it is. :-)

Although, I am still concerned about he inconsistent behaviour.

>
>> Don't get me wrong, I am *not* suggesting we should do that change, as
>> it would mean the last busy mark would be updated way too often.
>
> The updates aren't very expensive.  Just one atomic write.  It probably
> takes less time than acquiring the runtime-PM spinlock.
>
>> Instead, perhaps it's better to leave the responsibility of updating
>> the last busy mark to the runtime PM users solely.
>
> Maybe, but I think doing it once in the core, like this, can remove the
> need for a lot of function calls in drivers.

Unfortunate not. Most updates of the last busy mark happens when a
device is no longer required to be runtime resumed. As when a driver
has completed to serve a request and is about to call pm_runtime_put()
(or similar API).

So, I still believe doing it in the runtime PM core is just a waste.

I think it's better to leave the update to the users entirely, it
would become consistent but also more flexible, as one could easily
think of situations where you may in some cases want to update the
last busy mark and in some other not.

>
>> > > If we assume that the usb device shouldn't be used with a timeout less
>> > > than 2s, then I think we have two options:
>> > >
>> > > *) As the mmc polling timeout is 1s, there is really no point in
>> > > trying to runtime suspend the usb device, it may just be left runtime
>> > > resumed all the time. Wasting power, of course!
>> >
>> > Or we can decrease the USB autosuspend delay to 100 ms.
>>
>> Yes, something like that makes sense to me.
>>
>> Unless we decide to turn off autosuspend completely for the usb host
>> as you suggested above. Then it would really become clear that the
>> sdmmc/memstick drivers gets the responsible for the autosuspend, which
>> certainly makes most sense.
>
> Yes.

Okay.

I will submit a series with the relevant changes we have come up with
during the discussions. I will keep you posted.

>
>> > > **) Add an interface to allow dynamically changes of the mmc polling
>> > > timeout to better suit the current user.
>> >
>> > Note that the block layer does its own polling for removable media, and
>> > it already has a sysfs interface to control the polling interval (or
>> > disable it entirely).  But I don't know how the MMC stack interacts
>> > with the block layer.
>> >
>> > One awkward point is that the sdmmc and memstick drivers each do their
>> > own polling.  This is a waste.  You can see it in the usbmon trace;
>> > every second there are two query-response interactions.  Even if
>> > there's no good way to reduce the number, we should at least try to
>> > synchronize the polls so that the device doesn't need to be resumed
>> > twice every second.
>>
>> Yes, you are right. I just haven't been able to prioritize doing that
>> change for MMC. Another thing added on my mmc TODO list. :-)
>
> To tell the truth, I'm not sure how you would synchronize the polling
> activities in the sdmmc and memstick drivers.  Move most of it into the
> upper MFD driver?

I don't know, you may be right! I will have to think about it.

>
> One point worth mentioning is that if you already know an SDMMC card is
> present then there's no reason to poll for a

Re: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Felipe Balbi


Hi,

Felipe Balbi  writes:
> Felipe Balbi  writes:
>> Bin Liu  writes:
>>> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
 
 Hi,
 
 Bin Liu  writes:
 > Hi,
 >
 > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
 >  high-speed connection.
 >
 > First I hacked webcam.c as follows to enable 640x480@30fps mode.
 >
 > diff --git a/drivers/usb/gadget/legacy/webcam.c 
 > b/drivers/usb/gadget/legacy/webcam.c
 > index 72c976b..9eb315f 100644
 > --- a/drivers/usb/gadget/legacy/webcam.c
 > +++ b/drivers/usb/gadget/legacy/webcam.c
 > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
 > uvc_frame_yuv_360p = {
 > .bFrameIndex= 1,
 > .bmCapabilities = 0,
 > .wWidth = cpu_to_le16(640),
 > -   .wHeight= cpu_to_le16(360),
 > +   .wHeight= cpu_to_le16(480),
 > .dwMinBitRate   = cpu_to_le32(18432000),
 > .dwMaxBitRate   = cpu_to_le32(55296000),
 > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
 > -   .dwDefaultFrameInterval = cpu_to_le32(66),
 > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
 > +   .dwDefaultFrameInterval = cpu_to_le32(33),
 > .bFrameIntervalType = 3,
 > -   .dwFrameInterval[0] = cpu_to_le32(66),
 > -   .dwFrameInterval[1] = cpu_to_le32(100),
 > -   .dwFrameInterval[2] = cpu_to_le32(500),
 > +   .dwFrameInterval[0] = cpu_to_le32(33),
 > +   .dwFrameInterval[1] = cpu_to_le32(66),
 > +   .dwFrameInterval[2] = cpu_to_le32(100),
 >  };
 >
 > then loaded g_webcam.ko as
 >
 > # modprobe g_webcam streaming_maxpacket=3072
 >
 > The endpoint descriptor showing on the host is
 >
 >   Endpoint Descriptor:
 > bLength 7
 > bDescriptorType 5
 > bEndpointAddress 0x8d  EP 13 IN
 > bmAttributes5
 >   Transfer TypeIsochronous
 >   Synch Type   Asynchronous
 >   Usage Type   Data
 > wMaxPacketSize 0x1400  3x 1024 bytes
 > bInterval   1
 >
 > However the usb bus trace shows only one transaction with 1024-bytes 
 > packet in
 > every SOF. The host only sends one IN packet in every SOF, I am 
 > expecting 2~3
 > 1024-bytes transactions, since this would be required to transfer 
 > 640x480@30fps
 > YUV frames in high-speed.
 >
 > DId I miss anything in the setup?
 
 MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
>>>
>>> Happened on both MUSB and DWC3.
>>>
 of your bus analyzer? When host sends IN token, are you replying with
>>>
>>> The trace screenshot on DWC3 is attached.
>>>
 DATA0, DATA1 or DATA2?
>>>
>>> Good hint! It is DATA0!
>>
>> yeah, should've been DATA2. I'll check if we're missing anything for
>> High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
>> DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
>> about DWC3?
>
> I'm assuming DWC3 really breaks. Here's a patch for that:
>
> 8<-- cut here 
> --
> From 62807011c00055785575bb39d92bfe8836817e2f Mon Sep 17 00:00:00 2001
> From: Felipe Balbi 
> Date: Thu, 22 Sep 2016 11:01:01 +0300
> Subject: [PATCH] usb: dwc3: gadget: set PCM1 field of isochronous-first TRBs
>
> In case of High-Speed, High-Bandwidth endpoints, we
> need to tell DWC3 that we have more than one packet
> per interval. We do that by setting PCM1 field of
> Isochronous-First TRB.
>
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/dwc3/gadget.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 602f12254161..106623faf060 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -787,6 +787,9 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
>   unsigned length, unsigned chain, unsigned node)
>  {
>   struct dwc3_trb *trb;
> + struct dwc3 *dwc = dep->dwc;
> + struct usb_gadget   *gadget = >gadget;
> + enum usb_device_speed   speed = speed;

and of course I sent the wrong version :-)

Here's one that actually compiles, sorry about that.

8<-- cut here --
From 44282f6c664b17e6b9dffbc31e72258be84823a4 Mon Sep 17 00:00:00 2001
From: Felipe Balbi

RE: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

2016-09-22 Thread Sriram Dash

>From: Arnd Bergmann [mailto:a...@arndb.de]
>On Wednesday, September 21, 2016 11:43:59 AM CEST Sriram Dash wrote:
>> >From: Arnd Bergmann [mailto:a...@arndb.de] On Wednesday, September
>> >21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>>
>> ==
>> From 8b0dea1513e9e73a11dcfa802ddc71cca11d66f8 Mon Sep 17 00:00:00 2001
>> From: Sriram Dash 
>> Date: Wed, 21 Sep 2016 11:39:30 +0530
>> Subject: [PATCH] usb: xhci: Fix the patch inherit dma configuration
>> from  parent dev
>>
>> Fixes the patch https://patchwork.kernel.org/patch/9319527/
>> ("usb: dwc3: host: inherit dma configuration from parent dev").
>>
>> Signed-off-by: Sriram Dash 
>> ---
>>  drivers/usb/host/xhci-mem.c | 12 ++--
>>  drivers/usb/host/xhci.c | 20 ++--
>>  2 files changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index 6afe323..79608df 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>
>All the changes you did to this file seem fine, I completely missed that part.
>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index
>> 01d96c9..9a1ff09 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c

Yes. Some sanity is required over this patch.

>> @@ -231,7 +231,7 @@ static int xhci_free_msi(struct xhci_hcd *xhci)
>> static int xhci_setup_msi(struct xhci_hcd *xhci)  {
>>  int ret;
>> -struct pci_dev  *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
>> +struct pci_dev  *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.sysdev);
>>
>>  ret = pci_enable_msi(pdev);
>>  if (ret) {
>
>This one is interesting as I stumbled over some code comment mentioning that 
>for
>dwc3-pci, we don't support MSI. I think with this change, we /can/ actually 
>support
>MSI, but this could be a separate patch and we'd have to test it on dwc3-pci
>hardware. Same for most of this file.
>
>> @@ -745,7 +745,7 @@ void xhci_shutdown(struct usb_hcd *hcd)
>>  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>>
>>  if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
>> -usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
>> +usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
>>
>>  spin_lock_irq(>lock);
>>  xhci_halt(xhci);
>
>This seems obviously correct, but I don't yet see why it currently works. We
>probably don't call this function on dwc3.
>
>>  #ifdef CONFIG_PM
>> @@ -3605,7 +3605,7 @@ void xhci_free_dev(struct usb_hcd *hcd, struct
>usb_device *udev)
>>   * if no devices remain.
>>   */
>>  if (xhci->quirks & XHCI_RESET_ON_RESUME)
>> -pm_runtime_put_noidle(hcd->self.controller);
>> +pm_runtime_put_noidle(hcd->self.sysdev);
>>  #endif
>>
>>  ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
>
>I suspect this one is wrong, based on what Felipe explained earlier:
>the power management should propagate down from the child to the parent
>device.
>
>Someone who understands this better than I do should look at it.
>
>> @@ -3745,7 +3745,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct
>usb_device *udev)
>>   * suspend if there is a device attached.
>>   */
>>  if (xhci->quirks & XHCI_RESET_ON_RESUME)
>> -pm_runtime_get_noresume(hcd->self.controller);
>> +pm_runtime_get_noresume(hcd->self.sysdev);
>>  #endif
>>
>>
>
>Same here.
>
>> @@ -4834,7 +4834,7 @@ int xhci_get_frame(struct usb_hcd *hcd)  int
>> xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)  {
>>  struct xhci_hcd *xhci;
>> -struct device   *dev = hcd->self.controller;
>> +struct device   *dev = hcd->self.sysdev;
>>  int retval;
>
>
>This one calls
>
>get_quirks(dev, xhci);
>
>not sure whether this should be called with self.controller or self.sysdev, we 
>should
>audit every one of the callers here to be sure:
>
>drivers/usb/host/xhci-mtk.c:return xhci_gen_setup(hcd, xhci_mtk_quirks);
>drivers/usb/host/xhci-pci.c:retval = xhci_gen_setup(hcd, xhci_pci_quirks);
>drivers/usb/host/xhci-plat.c:   return xhci_gen_setup(hcd, xhci_plat_quirks);
>drivers/usb/host/xhci-rcar.c:* xhci_gen_setup().
>drivers/usb/host/xhci-tegra.c:  return xhci_gen_setup(hcd, tegra_xhci_quirks);
>
>   Arnd
--
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: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet

On Thu, Sep 22, 2016 at 11:02 AM, Oliver Neukum  wrote:
> On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
>> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
>> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
>> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
>> >> wrote:
>> >> >
>> >> Malcolm, just to make it clear, this bug was not found with an
>> >> actual device, but with emulation.
>> >
>> > It was quite peculiar a bug, though. Could you prepare a test kernel
>> > without BPF?
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>> Oliver,
>>
>> If this question was directed to me, I will need some clarification
>> of what is needed (and also - what's BPF?)
>
> BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
> socket)
>
> The oops you reproduced was in the BPF. That is rather generic code
> without connection to the driver in question. That raises the question
> whether you've accidentally triggered a generic bug.
> To rule that out a rerun on a kernel compiled without CONFIG_BPF would
> be useful. Or you could build an initrd with the BPF modules
> blacklisted, so we are sure the test system does not use BPF.
>
> Regards
> Oliver
>
>
>

Thanks Oliver, will do.

-- Binyamin
--
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: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Felipe Balbi


Hi,

Felipe Balbi  writes:
> Bin Liu  writes:
>> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
>>> 
>>> Hi,
>>> 
>>> Bin Liu  writes:
>>> > Hi,
>>> >
>>> > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>>> >  high-speed connection.
>>> >
>>> > First I hacked webcam.c as follows to enable 640x480@30fps mode.
>>> >
>>> > diff --git a/drivers/usb/gadget/legacy/webcam.c 
>>> > b/drivers/usb/gadget/legacy/webcam.c
>>> > index 72c976b..9eb315f 100644
>>> > --- a/drivers/usb/gadget/legacy/webcam.c
>>> > +++ b/drivers/usb/gadget/legacy/webcam.c
>>> > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
>>> > uvc_frame_yuv_360p = {
>>> > .bFrameIndex= 1,
>>> > .bmCapabilities = 0,
>>> > .wWidth = cpu_to_le16(640),
>>> > -   .wHeight= cpu_to_le16(360),
>>> > +   .wHeight= cpu_to_le16(480),
>>> > .dwMinBitRate   = cpu_to_le32(18432000),
>>> > .dwMaxBitRate   = cpu_to_le32(55296000),
>>> > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
>>> > -   .dwDefaultFrameInterval = cpu_to_le32(66),
>>> > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
>>> > +   .dwDefaultFrameInterval = cpu_to_le32(33),
>>> > .bFrameIntervalType = 3,
>>> > -   .dwFrameInterval[0] = cpu_to_le32(66),
>>> > -   .dwFrameInterval[1] = cpu_to_le32(100),
>>> > -   .dwFrameInterval[2] = cpu_to_le32(500),
>>> > +   .dwFrameInterval[0] = cpu_to_le32(33),
>>> > +   .dwFrameInterval[1] = cpu_to_le32(66),
>>> > +   .dwFrameInterval[2] = cpu_to_le32(100),
>>> >  };
>>> >
>>> > then loaded g_webcam.ko as
>>> >
>>> > # modprobe g_webcam streaming_maxpacket=3072
>>> >
>>> > The endpoint descriptor showing on the host is
>>> >
>>> >   Endpoint Descriptor:
>>> > bLength 7
>>> > bDescriptorType 5
>>> > bEndpointAddress 0x8d  EP 13 IN
>>> > bmAttributes5
>>> >   Transfer TypeIsochronous
>>> >   Synch Type   Asynchronous
>>> >   Usage Type   Data
>>> > wMaxPacketSize 0x1400  3x 1024 bytes
>>> > bInterval   1
>>> >
>>> > However the usb bus trace shows only one transaction with 1024-bytes 
>>> > packet in
>>> > every SOF. The host only sends one IN packet in every SOF, I am expecting 
>>> > 2~3
>>> > 1024-bytes transactions, since this would be required to transfer 
>>> > 640x480@30fps
>>> > YUV frames in high-speed.
>>> >
>>> > DId I miss anything in the setup?
>>> 
>>> MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
>>
>> Happened on both MUSB and DWC3.
>>
>>> of your bus analyzer? When host sends IN token, are you replying with
>>
>> The trace screenshot on DWC3 is attached.
>>
>>> DATA0, DATA1 or DATA2?
>>
>> Good hint! It is DATA0!
>
> yeah, should've been DATA2. I'll check if we're missing anything for
> High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
> DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
> about DWC3?

I'm assuming DWC3 really breaks. Here's a patch for that:

8<-- cut here --
From 62807011c00055785575bb39d92bfe8836817e2f Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Thu, 22 Sep 2016 11:01:01 +0300
Subject: [PATCH] usb: dwc3: gadget: set PCM1 field of isochronous-first TRBs

In case of High-Speed, High-Bandwidth endpoints, we
need to tell DWC3 that we have more than one packet
per interval. We do that by setting PCM1 field of
Isochronous-First TRB.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 602f12254161..106623faf060 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -787,6 +787,9 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
unsigned length, unsigned chain, unsigned node)
 {
struct dwc3_trb *trb;
+   struct dwc3 *dwc = dep->dwc;
+   struct usb_gadget   *gadget = >gadget;
+   enum usb_device_speed   speed = speed;
 
dwc3_trace(trace_dwc3_gadget, "%s: req %p dma %08llx length %d%s",
dep->name, req, (unsigned long long) dma,
@@ -813,10 +816,17 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep,
break;
 
case USB_ENDPOINT_XFER_ISOC:
-   if (!node)
+   if (!node) {
trb->ctrl = DWC3_TRBCTL_ISOCHRONOUS_FIRST;
-   else
+
+   if (speed ==

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum

On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
> >> wrote:
> >> >
> >> Malcolm, just to make it clear, this bug was not found with an
> >> actual device, but with emulation.
> >
> > It was quite peculiar a bug, though. Could you prepare a test kernel
> > without BPF?
> >
> > Regards
> > Oliver
> >
> >
> 
> Oliver,
> 
> If this question was directed to me, I will need some clarification
> of what is needed (and also - what's BPF?)

BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
socket)

The oops you reproduced was in the BPF. That is rather generic code
without connection to the driver in question. That raises the question
whether you've accidentally triggered a generic bug.
To rule that out a rerun on a kernel compiled without CONFIG_BPF would
be useful. Or you could build an initrd with the BPF modules
blacklisted, so we are sure the test system does not use BPF.

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: [PATCH 2/2] musb: sunxi: Force session end on babble errors in host-mode

2016-09-22 Thread Hans de Goede


Hi,

On 09/22/2016 05:33 AM, Bin Liu wrote:

Hi,

On Sun, Sep 18, 2016 at 06:50:18PM +0200, Hans de Goede wrote:

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.

Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control).

This commit calls sun4i_usb_phy_force_session_end() on babble errors
in host-mode, fixing the musb controller being stuck in this state
on systems without Vbus control; and also fixes the need to unplug
the usb-b -> usb-a cable to get out of this state on systems with
Vbus control.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/sunxi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 1408245..5079d90 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -192,8 +192,18 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
*__hci)
 * normally babble never happens treat it as disconnect.
 */
if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {


musb_interrupt() handle BABBLE in host mode, and has a glue hook
musb_platform_recover() in musb_recover_from_babble().

Maybe you can use it?


Ah yes, I looked at this at the past, but that was before the babble
recover rework by Felipe Balbi which got commited on 2015-03-10.

With this rework the sunxi code should indeed be able to use the core
recovery, and we can use the musb_platform_recover() to force a
session end.

And thinking more about you're other remark, I do think I can
actually modify the sun4i phy_set_mode callback so that it can
be used for this.

I'll post a v2 with these changes soon-ish.

Regards,

Hans



+   struct sunxi_glue *glue =
+   dev_get_drvdata(musb->controller->parent);
+
+   dev_warn(musb->controller->parent, "babble, treating as 
disconnect\n");
+
musb->int_usb &= ~MUSB_INTR_BABBLE;
musb->int_usb |= MUSB_INTR_DISCONNECT;
+   /*
+* Fix the musb controller sometimes getting stuck in
+* bdevice state after a babble error.
+*/
+   sun4i_usb_phy_force_session_end(glue->phy);


As I commented in PATCH 1/2, can you somehow reuse
sun4i_usb_phy_set_mode() instead?


}

if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
--
2.9.3


Regards,
-Bin.


--
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: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet

On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
> On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
>> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
>> wrote:
>> >
>> Malcolm, just to make it clear, this bug was not found with an
>> actual device, but with emulation.
>
> It was quite peculiar a bug, though. Could you prepare a test kernel
> without BPF?
>
> Regards
> Oliver
>
>

Oliver,

If this question was directed to me, I will need some clarification
of what is needed (and also - what's BPF?)

Thanks.
--
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: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum

On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
> wrote:
> > 
> Malcolm, just to make it clear, this bug was not found with an
> actual device, but with emulation.

It was quite peculiar a bug, though. Could you prepare a test kernel
without BPF?

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: g_webcam Isoch high bandwidth transfer

2016-09-22 Thread Felipe Balbi


Hi,

Bin Liu  writes:
> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Bin Liu  writes:
>> > Hi,
>> >
>> > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>> >  high-speed connection.
>> >
>> > First I hacked webcam.c as follows to enable 640x480@30fps mode.
>> >
>> > diff --git a/drivers/usb/gadget/legacy/webcam.c 
>> > b/drivers/usb/gadget/legacy/webcam.c
>> > index 72c976b..9eb315f 100644
>> > --- a/drivers/usb/gadget/legacy/webcam.c
>> > +++ b/drivers/usb/gadget/legacy/webcam.c
>> > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
>> > uvc_frame_yuv_360p = {
>> > .bFrameIndex= 1,
>> > .bmCapabilities = 0,
>> > .wWidth = cpu_to_le16(640),
>> > -   .wHeight= cpu_to_le16(360),
>> > +   .wHeight= cpu_to_le16(480),
>> > .dwMinBitRate   = cpu_to_le32(18432000),
>> > .dwMaxBitRate   = cpu_to_le32(55296000),
>> > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
>> > -   .dwDefaultFrameInterval = cpu_to_le32(66),
>> > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
>> > +   .dwDefaultFrameInterval = cpu_to_le32(33),
>> > .bFrameIntervalType = 3,
>> > -   .dwFrameInterval[0] = cpu_to_le32(66),
>> > -   .dwFrameInterval[1] = cpu_to_le32(100),
>> > -   .dwFrameInterval[2] = cpu_to_le32(500),
>> > +   .dwFrameInterval[0] = cpu_to_le32(33),
>> > +   .dwFrameInterval[1] = cpu_to_le32(66),
>> > +   .dwFrameInterval[2] = cpu_to_le32(100),
>> >  };
>> >
>> > then loaded g_webcam.ko as
>> >
>> > # modprobe g_webcam streaming_maxpacket=3072
>> >
>> > The endpoint descriptor showing on the host is
>> >
>> >   Endpoint Descriptor:
>> > bLength 7
>> > bDescriptorType 5
>> > bEndpointAddress 0x8d  EP 13 IN
>> > bmAttributes5
>> >   Transfer TypeIsochronous
>> >   Synch Type   Asynchronous
>> >   Usage Type   Data
>> > wMaxPacketSize 0x1400  3x 1024 bytes
>> > bInterval   1
>> >
>> > However the usb bus trace shows only one transaction with 1024-bytes 
>> > packet in
>> > every SOF. The host only sends one IN packet in every SOF, I am expecting 
>> > 2~3
>> > 1024-bytes transactions, since this would be required to transfer 
>> > 640x480@30fps
>> > YUV frames in high-speed.
>> >
>> > DId I miss anything in the setup?
>> 
>> MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
>
> Happened on both MUSB and DWC3.
>
>> of your bus analyzer? When host sends IN token, are you replying with
>
> The trace screenshot on DWC3 is attached.
>
>> DATA0, DATA1 or DATA2?
>
> Good hint! It is DATA0!

yeah, should've been DATA2. I'll check if we're missing anything for
High Bandwidth Iso on DWC3. Can you confirm if it works of tails on
DWC3? On your follow-up mail you mentioned it's a bug in MUSB. What
about DWC3?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/2] phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function

2016-09-22 Thread Hans de Goede


Hi,

On 09/22/2016 05:28 AM, Bin Liu wrote:

Hi,

On Wed, Sep 21, 2016 at 11:05:33AM +0300, Hans de Goede wrote:

Hi,

On 09/20/2016 07:45 AM, Kishon Vijay Abraham I wrote:

Hi,

On Sunday 18 September 2016 10:20 PM, Hans de Goede wrote:

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.

Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control). The phy-sun4i-usb code already has code to force a session
end for devices without Vbus control.

This commit adds a sun4i_usb_phy_force_session_end() function exporting
this functionality to the sunxi-musb glue, so that it can force a session
end to fixup the stuck state after a babble error.

Signed-off-by: Hans de Goede 
---
drivers/phy/phy-sun4i-usb.c   | 11 +++
include/linux/phy/phy-sun4i-usb.h |  7 +++
2 files changed, 18 insertions(+)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 43c0d98..06f4e11a 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -470,6 +470,17 @@ void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, 
bool enabled)
}
EXPORT_SYMBOL_GPL(sun4i_usb_phy_set_squelch_detect);

+void sun4i_usb_phy_force_session_end(struct phy *_phy)
+{
+   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+
+   data->id_det = -1;
+   data->force_session_end = true;
+   queue_delayed_work(system_wq, >detect, 0);
+}
+EXPORT_SYMBOL_GPL(sun4i_usb_phy_force_session_end);


Er.. one more export symbol :-(


Yes unfortunately we need one more to work around sunxi musb / phy bugs.


Instead, can you somehow reuse sun4i_usb_phy_set_mode()?


That was my first thought too, and I looked into this, but it did not
work out.

Regards,

Hans



Regards,
-Bin.




+
static const struct phy_ops sun4i_usb_phy_ops = {
.init   = sun4i_usb_phy_init,
.exit   = sun4i_usb_phy_exit,
diff --git a/include/linux/phy/phy-sun4i-usb.h 
b/include/linux/phy/phy-sun4i-usb.h
index 50aed92..3bb773f 100644
--- a/include/linux/phy/phy-sun4i-usb.h
+++ b/include/linux/phy/phy-sun4i-usb.h
@@ -23,4 +23,11 @@
 */
void sun4i_usb_phy_set_squelch_detect(struct phy *phy, bool enabled);

+/**
+ * sun4i_usb_force_session_end() - Force the current session to end
+ *by reporting VBus low for 200+ ms
+ * @phy: reference to a sun4i usb phy
+ */
+void sun4i_usb_phy_force_session_end(struct phy *phy);


Should we include a static inline function if sun4i phy is not defined?


No, we're also not doing that for the already exported
sun4i_usb_phy_set_squelch_detect()

And it is not necessary since the only caller is drivers/usb/musb/sunxi.c,
and drivers/usb/musb/Kconfig has:

config USB_MUSB_SUNXI
tristate "Allwinner (sunxi)"
depends on PHY_SUN4I_USB

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: UAS and f_tcm -- is anyone using it?

2016-09-22 Thread Andrzej Pietrasiewicz


W dniu 20.09.2016 o 21:19, John Youn pisze:




Hi Sebastian, Andrzej,

If possible, could you share how you are using it? Such as in what
speed, mode, and with what controllers/platforms and hosts?

If you have any other tips on usage I would appreciate it.

I'm looking into getting it working with our dwc3 controller, maybe
also dwc2.

Regards,
John





Hi John,

My concern was converting the function to use configfs,
this was the last one waiting for this kind of conversion,
the other ~19 had been already converted at that time.

With that aim in mind what I did was following function's
behaviour at the time of conversion, that is, achieve the
same state with the configfs-composed tcm gadget as with
the legacy tcm gadget. I am aware that this kind of information
is not of much use, but at least you know where you are.

As far as I remember I tested it on Odroid XU3, which uses dwc3.

Regards,

AP
--
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: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet

On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  wrote:
> On 21/09/16 17:44, Greg KH wrote:
>>
>> On Wed, Sep 21, 2016 at 06:34:03PM +0200, Oliver Neukum wrote:
>>>
>>> On Thu, 2016-08-18 at 13:50 +0300, Binyamin Sharet wrote:

 On 08/18/2016 01:31 PM, Oliver Neukum wrote:
>
> On Wed, 2016-08-17 at 14:34 +0300, Binyamin Sharet wrote:
>>>
>>> After connecting such a device, NULL pointer dereference in the
>>
>> kernel.
>>>
>>> You may need to connect another device or two after this one to
>>
>> trigger
>>>
>>> the oops.
>>>
>>> Binyamin Sharet
>>> Cisco, STARE-C
>>>
>>> << Attached:  160a_3184_dmesg_1.log >>
>>> << Attached:  160a_3184_dmesg_2.log >>
>>
>> kernel: 4.8-rc2
>> result: reproduced
>>>
>>> [..]
>
>
 Attached.

>>>
>>> Hi,
>>>
>>> this fell through the cracks somehow. Does anybody know how
>>> these devices should be to work with the driver?
>>
>>
>> Which device was this?  I'm slowly working on a patchset to move this
>> type of checking to the USB core to hopefully prevent this type of thing
>> from have to be added to each USB driver individually.
>
>
> It's the VT6656.
>
> The problem cannot be reproduced here on the Raspberry PI 2.
>
> Looking at those logs it looks like the device reset during firmware
> downloading.
>
> Is the PSU for PI up to job?
>
> The device is power hungry, I am using a 2.4A @5v power supply.
>
> Regards
>
>
> Malcolm
>
> --
> 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

Malcolm, just to make it clear, this bug was not found with an
actual device, but with emulation.

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

61 matches

Mail list logo