Fwd: Antwort: Re: vUDC

[Krzysztof Opasiak]

FYI to the list for next generations;)


 Forwarded Message 
Subject: Antwort: Re: vUDC
Date: Fri, 9 Dec 2016 09:00:04 +0100
From: Elen Niedermeyer 
To: Krzysztof Opasiak 


Hi,

so your script solved my problem. I didn't know that I should start the
daemon with 'usbipd --device' after starting my emulation. I've tried it
with 'usbip -d' and then bind my device with 'usbip bind -b BUSID'. But
there wasn't listet a device by usbip with 'usbip list -l', so I didn't
know what I have to bind.  Mit freundlichen Grüßen
Kind regards,

i.A. Elen Niedermeyer
Duale Studentin Informatik
__

BIOTRONIK SE & Co. KG
Woermannkehre 1
12359 Berlin, Germany

Phone: +49 (0) 30 68905-2459
Fax: +49 (0) 30 68905 2940
Mail: elen.niederme...@biotronik.com

-Krzysztof Opasiak  schrieb: -
An: Shuah Khan , Elen Niedermeyer

Von: Krzysztof Opasiak 
Datum: 08.12.2016 16:11
Kopie: linux-usb@vger.kernel.org, kernelnewb...@nl.linux.org, LKML
, sh...@kernel.org
Betreff: Re: vUDC

Hi,

On 12/08/2016 03:33 PM, Shuah Khan wrote:
> Hi Elen,
> 
> Adding k.opas...@samsung.com
> 
> On Thu, Dec 8, 2016 at 7:07 AM, Elen Niedermeyer
>  wrote:
>> Dear Sir or Madam,
>>
>> I'm trying to run usbip-vudc since a few days. I want to access my emulated 
>> usb devices over usbip.
>> I use Ubuntu 16.04.01 and updated my kernel to version 4.8.0-30. I've 
>> installed linux-tools-4.8.0-30-generic which includes usbip. I enabled the 
>> modules usbip-host and usbip-vudc on the server. Futhermore I use configfs 
>> to emulate the usb devices.
>> So I could start the daemon and my emulation. But I can't detect my emulated 
>> usb device with usbip to bind it.
>> Could you help me to run usbip-vudc? Do I have to install an additional 
>> package? Do I miss a step?
>>
>> Mit freundlichen Grüßen
>> Kind regards,
> 
> Could you please send your dmesg? Also could you run usbipd with
> --debug and usbip with --log option and send the syslog
> 
> Krzysztof,
> 

You setup script should look like this:

Server:
$ modprobe usbip-vudc
# Create your gadget, for example:
$ cd /sys/kernel/config/usb_gadget
$ mkdir g1
$ mkdir g1/functions/acm.ser0
$ mkdir g1/configs/c.1
$ ln -s g1/functions/acm.ser0 g1/configs/c.1
$ echo "0x1234" > g1/idVendor
$ echo "0x5678" > g1/idProduct
$ echo usbip-vudc.0 > UDC
$ usbipd --device

Client:
$ modprobe usbip-vhci
$ usbip attach -r $SERVER_IP -d usbip-vudc.0

Please let me know if your setup script is similar and what exactly is
not working for you.

> Any ideas. Maybe it is time the documentation is updated with vudc details.
> 

Yes I think it's a good idea. I'll try to do this when I have some spare
time.

Best regards,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


www.biotronik.com BIOTRONIK - excellence for life
BIOTRONIK SE & Co. KG Woermannkehre 1, 12359 Berlin, Germany Sitz der
Gesellschaft: Berlin, Registergericht: Berlin HRA 6501
Vertreten durch ihre Komplementärin: BIOTRONIK MT SE Sitz der
Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B
Geschäftsführende Direktoren: Dr. Lothar Krings, Joachim Langer, Dr.
Ralf Lieb, Thomas Simmerer This e-mail and the information it contains
including attachments are confidential and meant only for use by the
intended recipient(s); disclosure or copying is strictly prohibited. If
you are not addressed, but in the possession of this e-mail, please
notify the sender immediately and delete the document.


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

[GIT PULL] USB-serial fixes for v4.10-rc1

[Johan Hovold]

Hi Greg,

Here are some more device ids that could go into v4.10-rc1 unless you
prefer I resend these after rc1 is out. Both commits have been in
linux-next for a couple of days.

Thanks,
Johan


The following changes since commit 3e5de27e940d00d8d504dfb96625fb654f641509:

  Linux 4.9-rc8 (2016-12-04 12:50:51 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.10-rc1-2

for you to fetch changes up to 46490c347df406b3368680dd911620e52dc7bfa4:

  USB: serial: option: add dlink dwm-158 (2016-12-07 13:08:22 +0100)


USB-serial fixes for v4.10-rc1

Here are some new device ids for the option driver.

Signed-off-by: Johan Hovold 


Daniele Palmas (1):
  USB: serial: option: add support for Telit LE922A PIDs 0x1040, 0x1041

Giuseppe Lippolis (1):
  USB: serial: option: add dlink dwm-158

 drivers/usb/serial/option.c | 7 +++
 1 file changed, 7 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] HACK: usb: dwc2: Workaround case where GOTGCTL state is wrong

[Chen Yu]

On 2016/12/9 15:32, John Stultz wrote:
> On Thu, Dec 8, 2016 at 11:09 PM, Chen Yu  wrote:
>> On 2016/12/9 7:29, John Youn wrote:
>>> On 12/8/2016 2:43 PM, John Stultz wrote:
 On Tue, Dec 6, 2016 at 7:52 PM, John Youn  wrote:
> On 12/6/2016 5:48 PM, John Stultz wrote:
>> This patch works around the issue by re-reading the GOTGCTL
>> state to check if the GOTGCTL_CONID_B is still set and if not
>> restarting the change status logic.
>
> This also seems weird. The connector id status shouldn't go back to A,
> assuming you've left the cable unplugged.

 So I suspect this has something to do with the way the USB-A host
 ports on the board are wired up. As removing the usb-b plug seems to
 switch the device back into A mode.

 One quirk with this board is that the USB-A ports on the board do not
 function if anything is in the OTG/B plug (which is frustrating to use
 at times).

>>>
>>> Do you mean there are multiple A-ports on the board hooked up to the
>>> same controller?
>>>
>>> If so, that would go a long way towards explaining things. Because the
>>> hsotg is a single-port OTG controller. If there are multiple A-ports,
>>> that means a hub has to be hard-wired internally to the port. But if
>>> that's the case the OTG function won't work because OTG doesn't work
>>> through a hub. It must go directly to the otg port. So there must be
>>> some external logic kicking-in to switch routing to the OTG port or to
>>> the HUB.
>>>
>>> This would explain this behavior with the ID pin status. Since hooking
>>> up the HUB would make the controller an A-device whereas normally it
>>> would be a B-device.
>>>
 Guodong or Chen Yu understand the hardware details a bit better, and
 might be able to explain more if you need more information.

>>>
>>> Yeah it would be good to get some insight into this from a hardware
>>> point of view.
>>>
>>
>> Actually, I'm not very clear about the hardware details.
>>
>> In simple terms, there are two Type A USB 2.0 host ports and 
>> one microUSB OTG port on the front edge of the board.
>> The two Type A USB 2.0 host ports connect to a high-speed 
>> hub and the hub connect to a USB Switch to which the microUSB OTG port
>> also connect.
>> If the Vbus of the microUSB OTG port was high or the ID of 
>> the microUSB OTG port was low, the Switch will switch the DP and DM of the 
>> SOC
>> to microUSB OTG port. If no cable was inserted to microUSB OTG port, 
>> the Switch will switch the DP and DM of the SOC to the high-speed hub.
>> There is another import point, the ID pin of soc will be 
>> pulled high in both cases:

Sorry, I made a mistake here, the ID pin of soc will be pulled low in both 
cases:

>> 1.no cable is inserted to microUSB OTG port
>> 2.cable is inserted to microUSB OTG port and ID of microUSB 
>> OTG port is low.
>>
>> If my explanation confuse you,  maybe these documents can be helpful.
>>
>> 
>> 1、https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/HardwareDocs/HardwareNotes.md
>>
>> USB Ports
>>
>> There are multiple USB ports on the HiKey board:
>>
>> One microUSB OTG port on the front edge of the board
>> Two Type A USB 2.0 host ports on the front edge of the board
>> One USB 2.0 host port on the high-speed expansion bus
>>
>> 
>> 2、https://github.com/96boards/documentation/tree/master/ConsumerEdition/HiKey/AdditionalDocs
>> Hardware User Guide
> 
> Yea, Page 12 in this pdf seems to explain it:
> https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/AdditionalDocs/HiKey_Hardware_User_Manual_Rev0.2.pdf
> 
> There is a usb switch which enables the micro-usb-b port if a cable is
> present, or switches to using the hub(which has its own limitations
> wrt multi-speed support) for the usb-a ports.
> 
> thanks
> -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
> 
> .
> 

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

[Aidan Thornton]

On Fri, Dec 9, 2016 at 3:26 AM, Russell Senior
 wrote:
> On Thu, Dec 8, 2016 at 10:02 AM, Johan Hovold  wrote:
>> On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote:
>>> > "Johan" == Johan Hovold  writes:
>>>
>>> [...]
>>>
>>> Johan> Ok, and you were using a terminal program such as minicom that
>>> Johan> properly configures the port for say 8-bit words?
>>>
>>> I was using GNU screen, which I don't specifically configure to be
>>> 8-bits, but I retried with minicom and specifically set a different byte
>>> size (non-8) and then set it back to 8, and saw the same 5-bit like
>>> behavior.
>>
>> Ok, try sticking to minicom for any further tests just to be sure.
>>
>>> Johan> [...] But if I configure the port for 5-bit words, I get the
>>> Johan> exact sequence you describe (i.e. the three most-significant bits
>>> Johan> are masked out).
>>>
>>> Johan> So my guess is that either you are not configuring the port
>>> Johan> correctly (and are using the default settings), or the driver
>>> Johan> fails to configure the port (and you are also stuck with the
>>> Johan> default settings).
>>>
>>> Johan> This may be a bit of long shot (or maybe not) but could you try
>>> Johan> the below patch on top of usb-next as well? [...]
>>>
>>> Your patch seems to have fixed it!  Yay!
>>
>> Interesting. I dug through the archives and found a report from Eddi De
>> Pieri which seems to have hit the same issue:
>>
>> 
>> https://lkml.kernel.org/r/CAKdnbx7GTH3K7eGtQ==wh=kb74ea_egpii0h8hxxokljnhh...@mail.gmail.com
>>
>> The weird part is I appear to have the same device, and it works fine
>> without that change.
>>
>> Could you try and just commenting out that register write in a mainline
>> kernel (or my usb-linus branch) to make sure the changes in -next did
>> not cause the issues you still see when connected to a pl2303.
>
> Okay, I built your usb-linus
>
> 46490c347df406b3368680dd911620e52dc7bfa4
>
> with the line:
>
>r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
>
> commented out.  More precisely:
>
> diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
> index f139488..928966a 100644
> --- a/drivers/usb/serial/ch341.c
> +++ b/drivers/usb/serial/ch341.c
> @@ -214,7 +214,7 @@ static int ch341_configure(struct usb_device *dev,
> struct ch341_private *priv)
> if (r < 0)
> goto out;
>
> -   r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
> +   // r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
> if (r < 0)
> goto out;
>
> Loopback works, and also interoperates with pl2303 (through a null
> modem adapter).

Interesting. Don't suppose you could check if usb-next works with this
commented out, please? Hopefully it should because that more or less
matches up with what the manufacturer was doing, and they ought to
know what they're doing.

Johan, feel free to rip this register write out - I tested both with
and without it when submitting those patches and couldn't find any
noticeable difference on the hardware I was using, would have removed
it back then if I'd looked back far enough in the archives to spot
that email. Sorry about that. Only left it there in case removing it
broke some odd hardware revision, but it sounds like leaving it in
breaks some hardware badly (judging from the reported symptoms, baud
rate setting and changing the line control register probably don't
work via either method afterwards).
--
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: [GIT PULL] USB-serial fixes for v4.10-rc1

[Greg Kroah-Hartman]

On Fri, Dec 09, 2016 at 11:00:27AM +0100, Johan Hovold wrote:
> Hi Greg,
> 
> Here are some more device ids that could go into v4.10-rc1 unless you
> prefer I resend these after rc1 is out. Both commits have been in
> linux-next for a couple of days.
> 
> Thanks,
> Johan
> 
> 
> The following changes since commit 3e5de27e940d00d8d504dfb96625fb654f641509:
> 
>   Linux 4.9-rc8 (2016-12-04 12:50:51 -0800)

Hm, I didn't need/want to merge 4.9-rc8 into my tree, as I didn't need
it, so I just took your two patches and cherry-picked them onto my
branch.  Is that ok?

thanks,

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

Re: [GIT PULL] USB-serial fixes for v4.10-rc1

[Johan Hovold]

On Fri, Dec 09, 2016 at 11:45:06AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 09, 2016 at 11:00:27AM +0100, Johan Hovold wrote:
> > Hi Greg,
> > 
> > Here are some more device ids that could go into v4.10-rc1 unless you
> > prefer I resend these after rc1 is out. Both commits have been in
> > linux-next for a couple of days.
> > 
> > Thanks,
> > Johan
> > 
> > 
> > The following changes since commit 3e5de27e940d00d8d504dfb96625fb654f641509:
> > 
> >   Linux 4.9-rc8 (2016-12-04 12:50:51 -0800)
> 
> Hm, I didn't need/want to merge 4.9-rc8 into my tree, as I didn't need
> it, so I just took your two patches and cherry-picked them onto my
> branch.  Is that ok?

Of course, thanks!

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

Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration

[Roger Quadros]

Hi,

On 17/11/16 13:43, Sriram Dash wrote:
> From: Arnd Bergmann 
> 
> For xhci-hcd platform device, all the DMA parameters are not
> configured properly, notably dma ops for dwc3 devices. So, set
> the dma for xhci from sysdev. sysdev is pointing to device that
> is known to the system firmware or hardware.
> 
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Sriram Dash 
> Tested-by: Baolin Wang 
> ---
> Changes in v5:
>   - No update
> 
> Changes in v4:
>   - No update
> 
> Changes in v3:
>   - No update
> 
> Changes in v2:
>   - Separate out xhci driver changes apart
> 
>  drivers/usb/host/xhci-mem.c  | 12 ++--
>  drivers/usb/host/xhci-plat.c | 33 ++---
>  drivers/usb/host/xhci.c  | 15 +++
>  3 files changed, 43 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index 48a26d378..eb32de9 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -586,7 +586,7 @@ static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
>   unsigned int num_stream_ctxs,
>   struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
>  {
> - struct device *dev = xhci_to_hcd(xhci)->self.controller;
> + struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
>   size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
>  
>   if (size > MEDIUM_STREAM_ARRAY_SIZE)
> @@ -614,7 +614,7 @@ static struct xhci_stream_ctx 
> *xhci_alloc_stream_ctx(struct xhci_hcd *xhci,
>   unsigned int num_stream_ctxs, dma_addr_t *dma,
>   gfp_t mem_flags)
>  {
> - struct device *dev = xhci_to_hcd(xhci)->self.controller;
> + struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
>   size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
>  
>   if (size > MEDIUM_STREAM_ARRAY_SIZE)
> @@ -1644,7 +1644,7 @@ void xhci_slot_copy(struct xhci_hcd *xhci,
>  static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
>  {
>   int i;
> - struct device *dev = xhci_to_hcd(xhci)->self.controller;
> + struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
>   int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2);
>  
>   xhci_dbg_trace(xhci, trace_xhci_dbg_init,
> @@ -1716,7 +1716,7 @@ static void scratchpad_free(struct xhci_hcd *xhci)
>  {
>   int num_sp;
>   int i;
> - struct device *dev = xhci_to_hcd(xhci)->self.controller;
> + struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
>  
>   if (!xhci->scratchpad)
>   return;
> @@ -1792,7 +1792,7 @@ void xhci_free_command(struct xhci_hcd *xhci,
>  
>  void xhci_mem_cleanup(struct xhci_hcd *xhci)
>  {
> - struct device   *dev = xhci_to_hcd(xhci)->self.controller;
> + struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
>   int size;
>   int i, j, num_ports;
>  
> @@ -2334,7 +2334,7 @@ static int xhci_setup_port_arrays(struct xhci_hcd 
> *xhci, gfp_t flags)
>  int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
>  {
>   dma_addr_t  dma;
> - struct device   *dev = xhci_to_hcd(xhci)->self.controller;
> + struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
>   unsigned intval, val2;
>   u64 val_64;
>   struct xhci_segment *seg;
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index ed56bf9..beb95c8 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -139,6 +140,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  {
>   const struct of_device_id *match;
>   const struct hc_driver  *driver;
> + struct device   *sysdev;
>   struct xhci_hcd *xhci;
>   struct resource *res;
>   struct usb_hcd  *hcd;
> @@ -155,22 +157,39 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (irq < 0)
>   return -ENODEV;
>  
> + /*
> +  * sysdev must point to a device that is known to the system firmware
> +  * or PCI hardware. We handle these three cases here:
> +  * 1. xhci_plat comes from firmware
> +  * 2. xhci_plat is child of a device from firmware (dwc3-plat)
> +  * 3. xhci_plat is grandchild of a pci device (dwc3-pci)
> +  */
> + sysdev = &pdev->dev;
> + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node)
> + sysdev = sysdev->parent;
> +#ifdef CONFIG_PCI
> + else if (sysdev->parent && sysdev->parent->parent &&
> +  sysdev->parent->parent->bus == &pci_bus_type)
> + sysdev = sysdev->parent->parent;
> +#endif
> +
>   /* Try to set 64-bit DMA first */
> - if (WARN_ON(!pdev->dev.dma_mask))
> + if (WARN_ON(!sysdev->dma_mask))
>   /* Platform did not initialize dma_mask */
> - ret = dma_coerce_mask_and_coherent(&pdev->d

[hid:for-4.10/i2c-hid 6/7] drivers/hid/i2c-hid/i2c-hid.c:1048:23: error: implicit declaration of function 'devm_regulator_get'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git 
for-4.10/i2c-hid
head:   de3c99488609284e454cf2b4420a789038a4cfa8
commit: ead0687fe304a66a24e3d809d1070684f3abee71 [6/7] HID: i2c-hid: support 
regulator power on/off
config: x86_64-randconfig-x015-201649 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout ead0687fe304a66a24e3d809d1070684f3abee71
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/hid/i2c-hid/i2c-hid.c: In function 'i2c_hid_probe':
>> drivers/hid/i2c-hid/i2c-hid.c:1048:23: error: implicit declaration of 
>> function 'devm_regulator_get' [-Werror=implicit-function-declaration]
 ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd");
  ^~
>> drivers/hid/i2c-hid/i2c-hid.c:1048:21: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
 ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd");
^
>> drivers/hid/i2c-hid/i2c-hid.c:1057:8: error: implicit declaration of 
>> function 'regulator_enable' [-Werror=implicit-function-declaration]
 ret = regulator_enable(ihid->pdata.supply);
   ^~~~
>> drivers/hid/i2c-hid/i2c-hid.c:1139:2: error: implicit declaration of 
>> function 'regulator_disable' [-Werror=implicit-function-declaration]
 regulator_disable(ihid->pdata.supply);
 ^
   cc1: some warnings being treated as errors

vim +/devm_regulator_get +1048 drivers/hid/i2c-hid/i2c-hid.c

  1042  goto err;
  1043  }
  1044  } else {
  1045  ihid->pdata = *platform_data;
  1046  }
  1047  
> 1048  ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd");
  1049  if (IS_ERR(ihid->pdata.supply)) {
  1050  ret = PTR_ERR(ihid->pdata.supply);
  1051  if (ret != -EPROBE_DEFER)
  1052  dev_err(&client->dev, "Failed to get regulator: 
%d\n",
  1053  ret);
  1054  return ret;
  1055  }
  1056   
> 1057  ret = regulator_enable(ihid->pdata.supply);
  1058  if (ret < 0) {
  1059  dev_err(&client->dev, "Failed to enable regulator: 
%d\n",
  1060  ret);
  1061  goto err;
  1062  }
  1063  if (ihid->pdata.init_delay_ms)
  1064  msleep(ihid->pdata.init_delay_ms);
  1065  
  1066  i2c_set_clientdata(client, ihid);
  1067  
  1068  ihid->client = client;
  1069  
  1070  hidRegister = ihid->pdata.hid_descriptor_address;
  1071  ihid->wHIDDescRegister = cpu_to_le16(hidRegister);
  1072  
  1073  init_waitqueue_head(&ihid->wait);
  1074  mutex_init(&ihid->reset_lock);
  1075  
  1076  /* we need to allocate the command buffer without knowing the 
maximum
  1077   * size of the reports. Let's use HID_MIN_BUFFER_SIZE, then we 
do the
  1078   * real computation later. */
  1079  ret = i2c_hid_alloc_buffers(ihid, HID_MIN_BUFFER_SIZE);
  1080  if (ret < 0)
  1081  goto err_regulator;
  1082  
  1083  pm_runtime_get_noresume(&client->dev);
  1084  pm_runtime_set_active(&client->dev);
  1085  pm_runtime_enable(&client->dev);
  1086  device_enable_async_suspend(&client->dev);
  1087  
  1088  ret = i2c_hid_fetch_hid_descriptor(ihid);
  1089  if (ret < 0)
  1090  goto err_pm;
  1091  
  1092  ret = i2c_hid_init_irq(client);
  1093  if (ret < 0)
  1094  goto err_pm;
  1095  
  1096  hid = hid_allocate_device();
  1097  if (IS_ERR(hid)) {
  1098  ret = PTR_ERR(hid);
  1099  goto err_irq;
  1100  }
  1101  
  1102  ihid->hid = hid;
  1103  
  1104  hid->driver_data = client;
  1105  hid->ll_driver = &i2c_hid_ll_driver;
  1106  hid->dev.parent = &client->dev;
  1107  hid->bus = BUS_I2C;
  1108  hid->version = le16_to_cpu(ihid->hdesc.bcdVersion);
  1109  hid->vendor = le16_to_cpu(ihid->hdesc.wVendorID);
  1110  hid->product = le16_to_cpu(ihid->hdesc.wProductID);
    
  1112  snprintf(hid->name, sizeof(hid->name), "%s %04hX:%04hX",
  1113   client->name, hid->vendor, hid->product);
  1114  strlcpy(hid->phys, dev_name(&client->dev), sizeof(hid->phys));
  1115  
  1116  ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
  1117  
  1118  ret = hid_add_device(hid);
  1119  if (ret) {
  1120  if (ret != -ENODEV)
  1121  hid_err(client, "can't add hid device: %d\n", 
ret);
  1122  goto e

Re: [hid:for-4.10/i2c-hid 6/7] drivers/hid/i2c-hid/i2c-hid.c:1048:23: error: implicit declaration of function 'devm_regulator_get'

[Jiri Kosina]

On Fri, 9 Dec 2016, kbuild test robot wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git 
> for-4.10/i2c-hid
> head:   de3c99488609284e454cf2b4420a789038a4cfa8
> commit: ead0687fe304a66a24e3d809d1070684f3abee71 [6/7] HID: i2c-hid: support 
> regulator power on/off
> config: x86_64-randconfig-x015-201649 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> git checkout ead0687fe304a66a24e3d809d1070684f3abee71
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All error/warnings (new ones prefixed by >>):
> 
>drivers/hid/i2c-hid/i2c-hid.c: In function 'i2c_hid_probe':
> >> drivers/hid/i2c-hid/i2c-hid.c:1048:23: error: implicit declaration of 
> >> function 'devm_regulator_get' [-Werror=implicit-function-declaration]
>  ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd");
>   ^~
> >> drivers/hid/i2c-hid/i2c-hid.c:1048:21: warning: assignment makes pointer 
> >> from integer without a cast [-Wint-conversion]
>  ihid->pdata.supply = devm_regulator_get(&client->dev, "vdd");
> ^
> >> drivers/hid/i2c-hid/i2c-hid.c:1057:8: error: implicit declaration of 
> >> function 'regulator_enable' [-Werror=implicit-function-declaration]
>  ret = regulator_enable(ihid->pdata.supply);
>^~~~
> >> drivers/hid/i2c-hid/i2c-hid.c:1139:2: error: implicit declaration of 
> >> function 'regulator_disable' [-Werror=implicit-function-declaration]
>  regulator_disable(ihid->pdata.supply);
>  ^

Mea culpa, I've omitted this hunk while I was resolving a patch 
application conflict into for-4.10/i2c-hid branch. Fix now pushed out as 
d4c9be331.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: [PATCH 1/1 v2] input: usbhid: fix improper return value

[Jiri Kosina]

On Mon, 5 Dec 2016, Pan Bian wrote:

> Function hid_post_reset() should return negative error codes on
> failures. However, in its implementation, it incorrectly returns 1.
> This patch fixes the bug, returning proper error codes on failures.

Applied to for-4.10/upstream. Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: ch341

[Johan Hovold]

On Thu, Dec 08, 2016 at 07:26:26PM -0800, Russell Senior wrote:
> On Thu, Dec 8, 2016 at 10:02 AM, Johan Hovold  wrote:
> > On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote:
> >> > "Johan" == Johan Hovold  writes:
> >>
> >> [...]
> >>
> >> Johan> Ok, and you were using a terminal program such as minicom that
> >> Johan> properly configures the port for say 8-bit words?
> >>
> >> I was using GNU screen, which I don't specifically configure to be
> >> 8-bits, but I retried with minicom and specifically set a different byte
> >> size (non-8) and then set it back to 8, and saw the same 5-bit like
> >> behavior.
> >
> > Ok, try sticking to minicom for any further tests just to be sure.
> >
> >> Johan> [...] But if I configure the port for 5-bit words, I get the
> >> Johan> exact sequence you describe (i.e. the three most-significant bits
> >> Johan> are masked out).
> >>
> >> Johan> So my guess is that either you are not configuring the port
> >> Johan> correctly (and are using the default settings), or the driver
> >> Johan> fails to configure the port (and you are also stuck with the
> >> Johan> default settings).
> >>
> >> Johan> This may be a bit of long shot (or maybe not) but could you try
> >> Johan> the below patch on top of usb-next as well? [...]
> >>
> >> Your patch seems to have fixed it!  Yay!
> >
> > Interesting. I dug through the archives and found a report from Eddi De
> > Pieri which seems to have hit the same issue:
> >
> > 
> > https://lkml.kernel.org/r/CAKdnbx7GTH3K7eGtQ==wh=kb74ea_egpii0h8hxxokljnhh...@mail.gmail.com
> >
> > The weird part is I appear to have the same device, and it works fine
> > without that change.
> >
> > Could you try and just commenting out that register write in a mainline
> > kernel (or my usb-linus branch) to make sure the changes in -next did
> > not cause the issues you still see when connected to a pl2303.
> 
> Okay, I built your usb-linus
> 
> 46490c347df406b3368680dd911620e52dc7bfa4
> 
> with the line:
> 
>r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
> 
> commented out.  More precisely:

> Loopback works, and also interoperates with pl2303 (through a null
> modem adapter).

Interesting indeed. The changes in usb-next enabled support for some
other devices which previously did not work, but hopefully we can find a
combination that works for all (unless we can reliably determine the
device-type during probe).

Can you try the below patch on top of my usb-next branch?

I fear that your device does not support the new way of the setting the
divisor, but let's see if this works first.

Also, when the above change makes usb-linus works, does changing the
word size appear to work after probe?

Thanks,
Johan


>From 611dd2ded0b914442d5256dfb401522e477b9d0c Mon Sep 17 00:00:00 2001
From: Johan Hovold 
Date: Fri, 9 Dec 2016 13:45:59 +0100
Subject: [PATCH v2] USB: serial: ch341: change initial LCR settings

Change the initial LCR setting to 8N1 and enable rx and tx.

This should have not effect as the LCR is again later updated at open,
but let's try anyway since we have gotten reports about ch341-devices
that appear to be stuck with 5-bit words.

Not-Yet-Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/ch341.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/usb/serial/ch341.c b/drivers/usb/serial/ch341.c
index 2597b83a8ae2..75bb039a7f61 100644
--- a/drivers/usb/serial/ch341.c
+++ b/drivers/usb/serial/ch341.c
@@ -223,16 +223,12 @@ static int ch341_configure(struct usb_device *dev, struct 
ch341_private *priv)
if (r < 0)
goto out;
 
-   r = ch341_control_out(dev, CH341_REQ_WRITE_REG, 0x2518, 0x0050);
-   if (r < 0)
-   goto out;
-
/* expect 0xff 0xee */
r = ch341_get_status(dev, priv);
if (r < 0)
goto out;
 
-   r = ch341_init_set_baudrate(dev, priv, 0);
+   r = ch341_init_set_baudrate(dev, priv, 0xc3);
if (r < 0)
goto out;
 
-- 
2.7.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: ch341

[Johan Hovold]

On Fri, Dec 09, 2016 at 10:21:32AM +, Aidan Thornton wrote:
> On Fri, Dec 9, 2016 at 3:26 AM, Russell Senior
>  wrote:
> > On Thu, Dec 8, 2016 at 10:02 AM, Johan Hovold  wrote:
> >> On Thu, Dec 08, 2016 at 04:41:44AM -0800, Russell Senior wrote:
> >>> > "Johan" == Johan Hovold  writes:

> >>> Johan> [...] But if I configure the port for 5-bit words, I get the
> >>> Johan> exact sequence you describe (i.e. the three most-significant bits
> >>> Johan> are masked out).
> >>>
> >>> Johan> So my guess is that either you are not configuring the port
> >>> Johan> correctly (and are using the default settings), or the driver
> >>> Johan> fails to configure the port (and you are also stuck with the
> >>> Johan> default settings).
> >>>
> >>> Johan> This may be a bit of long shot (or maybe not) but could you try
> >>> Johan> the below patch on top of usb-next as well? [...]
> >>>
> >>> Your patch seems to have fixed it!  Yay!
> >>
> >> Interesting. I dug through the archives and found a report from Eddi De
> >> Pieri which seems to have hit the same issue:
> >>
> >> 
> >> https://lkml.kernel.org/r/CAKdnbx7GTH3K7eGtQ==wh=kb74ea_egpii0h8hxxokljnhh...@mail.gmail.com
> >>
> >> The weird part is I appear to have the same device, and it works fine
> >> without that change.
> >>
> >> Could you try and just commenting out that register write in a mainline
> >> kernel (or my usb-linus branch) to make sure the changes in -next did
> >> not cause the issues you still see when connected to a pl2303.
> >
> > Okay, I built your usb-linus
> >
> > 46490c347df406b3368680dd911620e52dc7bfa4
> >
> > with the line:
> >
> >r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
> >
> > commented out.  More precisely:

> > Loopback works, and also interoperates with pl2303 (through a null
> > modem adapter).
> 
> Interesting. Don't suppose you could check if usb-next works with this
> commented out, please? Hopefully it should because that more or less
> matches up with what the manufacturer was doing, and they ought to
> know what they're doing.

Unless we're dealing with some counterfeit device here...

> Johan, feel free to rip this register write out - I tested both with
> and without it when submitting those patches and couldn't find any
> noticeable difference on the hardware I was using, would have removed
> it back then if I'd looked back far enough in the archives to spot
> that email. Sorry about that. Only left it there in case removing it
> broke some odd hardware revision, but it sounds like leaving it in
> breaks some hardware badly (judging from the reported symptoms, baud
> rate setting and changing the line control register probably don't
> work via either method afterwards).

No worries, this game is frustrating, but we need to try to find an
initialisation sequence that works for all or most device types while
trying to be conservative in the changes we make not cause any
regressions.

I now have a CH340G and CH341A and can do some basic testing, while
Russel seem to have some variant of CH340 that behaves differently. With
this test coverage I think we should be able to find some sequence that
works.

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

[Mark Lord]

On 16-12-08 10:23 PM, Hayes Wang wrote:
> Mark Lord 
> 
> I find an issue about autosuspend, and it may result in the same
> problem with you. I don't sure if this is helpful to you, because
> it only occurs when enabling the autosuspend.

Thanks.  I am using ASIX adapters now.

I did try the latest 4.9-rc8, and 4.8.12 kernels with the r8152 dongle 
yesterday,
in hope that perhaps the many EHCI fixes from those kernels might help out.

The dongle was unusable with those newer kernels.
Most of the time it failed with "Get ether addr fail\n" at startup.

On the occasions where it got past that point, it often failed
the DHCP negotiation, but this looks more like a bug elsewhere in
the kernel, possibly racing against initialization of the random
number generators.  Adding a 2-second sleep the the r8151 probe
function made this error mostly go away.

Cheers
-- 
Mark Lord
--
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: Emulating USB devices from userspace

[Andrey Konovalov]

On Fri, Dec 9, 2016 at 8:20 AM, Greg Kroah-Hartman
 wrote:
> On Fri, Dec 09, 2016 at 12:38:23AM +0100, Andrey Konovalov wrote:
>> Hi,
>>
>> I'm working on a way to extend syzkaller [1] to support fuzzing of the
>> USB subsystem. The idea is to be able to emulate various USB devices
>> and fuzz communication between the emulated device and the kernel. I'm
>> looking for a way to emulate devices from userspace. Similar to how
>> tuntap allows to create virtual network interfaces and emit ethernet
>> traffic by writing to /dev/net/tun.
>>
>> While googling for some information on this I found mentions of
>> gadgetfs and functionfs. As far as I understand, they allow to turn a
>> USB host into a gadget and provide a way to communicate with another
>> host from a userspace application running on the gadget machine.
>
> Not quite.  They are to drive a USB "gadget" device (i.e. the thing you
> plug into a USB host, like a keyboard).  You use that if you are running
> Linux inside of that keyboard.  Or inside your phone, it uses this
> interface when talking to your laptop.
>
>> There's also usbfs, which allows to communicate with a usb gadget
>> directly from a userspace application.
>
> usbfs is to talk to a USB gadget through the host controller, so you can
> use it to fuzz a USB gadget driver, if a host driver is not already
> bound to the device.
>
>> Am I right, that none of the above actually fit my needs?
>
> No, it should fit your needs just fine.  Use the dummy USB gadget
> controller driver to set up the USB gadget device, and control it that
> way.  It is how many people develop their USB gadget drivers directly on
> a non-gadget system (like a desktop.)

Hi Greg,

OK, it's starting to make some sense.
Dummy actually means loopback, correct?

Right now whenever I mount gadgetfs I see a dummy_udc file. This
basically means that I have gadgetfs set up in a loopback mode (since
I have CONFIG_USB_DUMMY_HCD=y). Now I can write USB device description
to dummy_udc and the kernel will find an appropriate driver and
loopback the communication with this driver to the exposed epN files.
Is my understanding of this correct?

>
>> Is there some way to emulate USB devices from a userspace application
>> via some kernel interface?
>
> Yes, use functionfs.

As I understand, the way to write gadget drivers with functionfs is to
describe something that's called a function by mounting functionfs and
writing to the files it provides. Then you need to use configfs to
actually compose these functions into a device.

Is this correct?

What does a function stands for in this context? A USB configuration?

How do I enable loopback with functionfs?

Are there any advantages of using functionfs over gadgetfs for fuzzing?

Thanks!

>
> have fun!
>
> greg k-h
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to syzkaller+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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: Emulating USB devices from userspace

[Felipe Balbi]

Hi,

Andrey Konovalov  writes:
> On Fri, Dec 9, 2016 at 8:20 AM, Greg Kroah-Hartman
>  wrote:
>> On Fri, Dec 09, 2016 at 12:38:23AM +0100, Andrey Konovalov wrote:
>>> Hi,
>>>
>>> I'm working on a way to extend syzkaller [1] to support fuzzing of the
>>> USB subsystem. The idea is to be able to emulate various USB devices
>>> and fuzz communication between the emulated device and the kernel. I'm
>>> looking for a way to emulate devices from userspace. Similar to how
>>> tuntap allows to create virtual network interfaces and emit ethernet
>>> traffic by writing to /dev/net/tun.
>>>
>>> While googling for some information on this I found mentions of
>>> gadgetfs and functionfs. As far as I understand, they allow to turn a
>>> USB host into a gadget and provide a way to communicate with another
>>> host from a userspace application running on the gadget machine.
>>
>> Not quite.  They are to drive a USB "gadget" device (i.e. the thing you
>> plug into a USB host, like a keyboard).  You use that if you are running
>> Linux inside of that keyboard.  Or inside your phone, it uses this
>> interface when talking to your laptop.
>>
>>> There's also usbfs, which allows to communicate with a usb gadget
>>> directly from a userspace application.
>>
>> usbfs is to talk to a USB gadget through the host controller, so you can
>> use it to fuzz a USB gadget driver, if a host driver is not already
>> bound to the device.
>>
>>> Am I right, that none of the above actually fit my needs?
>>
>> No, it should fit your needs just fine.  Use the dummy USB gadget
>> controller driver to set up the USB gadget device, and control it that
>> way.  It is how many people develop their USB gadget drivers directly on
>> a non-gadget system (like a desktop.)
>
> Hi Greg,
>
> OK, it's starting to make some sense.
> Dummy actually means loopback, correct?

not really, no. Dummy is a SW-only implementation of a virtual host
controller always attached to a virtual peripheral controller.

> Right now whenever I mount gadgetfs I see a dummy_udc file. This
> basically means that I have gadgetfs set up in a loopback mode (since
> I have CONFIG_USB_DUMMY_HCD=y). Now I can write USB device description
> to dummy_udc and the kernel will find an appropriate driver and
> loopback the communication with this driver to the exposed epN files.
> Is my understanding of this correct?

kinda, yeah.

>>> Is there some way to emulate USB devices from a userspace application
>>> via some kernel interface?
>>
>> Yes, use functionfs.
>
> As I understand, the way to write gadget drivers with functionfs is to
> describe something that's called a function by mounting functionfs and
> writing to the files it provides. Then you need to use configfs to
> actually compose these functions into a device.
>
> Is this correct?

right

> What does a function stands for in this context? A USB configuration?

USB CDC ACM, USB Mass Storage, USB NCM, etc. A class.

> How do I enable loopback with functionfs?

you don't need functionfs for g_zero's loopback. just load g_zero

> Are there any advantages of using functionfs over gadgetfs for fuzzing?

nope, from your point of view, you can use either.

-- 
balbi


signature.asc
Description: PGP signature

Re: Fwd: Antwort: Re: vUDC

[Shuah Khan]

Hi Krzysztof,

On 12/09/2016 01:43 AM, Krzysztof Opasiak wrote:
> FYI to the list for next generations;)
> 
> 
>  Forwarded Message 
> Subject: Antwort: Re: vUDC
> Date: Fri, 9 Dec 2016 09:00:04 +0100
> From: Elen Niedermeyer 
> To: Krzysztof Opasiak 
> 
> 
> Hi,
> 
> so your script solved my problem. I didn't know that I should start the
> daemon with 'usbipd --device' after starting my emulation. I've tried it
> with 'usbip -d' and then bind my device with 'usbip bind -b BUSID'. But
> there wasn't listet a device by usbip with 'usbip list -l', so I didn't
> know what I have to bind.  Mit freundlichen Grüßen
> Kind regards,
> 
> i.A. Elen Niedermeyer
> Duale Studentin Informatik
> __
> 
> BIOTRONIK SE & Co. KG
> Woermannkehre 1
> 12359 Berlin, Germany
> 
> Phone: +49 (0) 30 68905-2459
> Fax: +49 (0) 30 68905 2940
> Mail: elen.niederme...@biotronik.com
> 
> -Krzysztof Opasiak  schrieb: -
> An: Shuah Khan , Elen Niedermeyer
> 
> Von: Krzysztof Opasiak 
> Datum: 08.12.2016 16:11
> Kopie: linux-usb@vger.kernel.org, kernelnewb...@nl.linux.org, LKML
> , sh...@kernel.org
> Betreff: Re: vUDC
> 
> Hi,
> 
> On 12/08/2016 03:33 PM, Shuah Khan wrote:
>> Hi Elen,
>>
>> Adding k.opas...@samsung.com
>>
>> On Thu, Dec 8, 2016 at 7:07 AM, Elen Niedermeyer
>>  wrote:
>>> Dear Sir or Madam,
>>>
>>> I'm trying to run usbip-vudc since a few days. I want to access my emulated 
>>> usb devices over usbip.
>>> I use Ubuntu 16.04.01 and updated my kernel to version 4.8.0-30. I've 
>>> installed linux-tools-4.8.0-30-generic which includes usbip. I enabled the 
>>> modules usbip-host and usbip-vudc on the server. Futhermore I use configfs 
>>> to emulate the usb devices.
>>> So I could start the daemon and my emulation. But I can't detect my 
>>> emulated usb device with usbip to bind it.
>>> Could you help me to run usbip-vudc? Do I have to install an additional 
>>> package? Do I miss a step?
>>>
>>> Mit freundlichen Grüßen
>>> Kind regards,
>>
>> Could you please send your dmesg? Also could you run usbipd with
>> --debug and usbip with --log option and send the syslog
>>
>> Krzysztof,
>>
> 
> You setup script should look like this:
> 
> Server:
> $ modprobe usbip-vudc
> # Create your gadget, for example:
> $ cd /sys/kernel/config/usb_gadget
> $ mkdir g1
> $ mkdir g1/functions/acm.ser0
> $ mkdir g1/configs/c.1
> $ ln -s g1/functions/acm.ser0 g1/configs/c.1
> $ echo "0x1234" > g1/idVendor
> $ echo "0x5678" > g1/idProduct
> $ echo usbip-vudc.0 > UDC
> $ usbipd --device
> 
> Client:
> $ modprobe usbip-vhci
> $ usbip attach -r $SERVER_IP -d usbip-vudc.0
> 
> Please let me know if your setup script is similar and what exactly is

I would be good to create server_sample.sh and client_sample.sh and add
them to tools/usb/usbip - users can customize them.

What do you think? Is this something you have time for?

thanks,
-- Shuah

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

Re: [v1] usb:gadget:legacy:nokia :- Check for NULL in nokia_bind_config

[Michal Nazarewicz]

On Thu, Dec 08 2016, Arvind Yadav wrote:
> Here, f_acm,f_ecm and f_msg needs to be checked for being NULL
> in nokia_bind_config() before calling usb_add_function(),
> otherwise kernel can run into a NULL-pointer dereference.
>
> f_phonet, f_obex1 and f_obex2 need to be checked for NULL
> in nokia_bind_config() to print proper debug information.
>
> Signed-off-by: Arvind Yadav 

Is this something you’ve encountered?  As far as I can see, NULL is
never returned from usb_get_function.  It’s always an error pointer.

In fact, if usb_get_function returns NULL, then the null pointer
dereference happens *inside* of the function so checking it outside is
too late.

If we even want to worry about it, this needs to be done in functions.c:

--- >8 -
>From 083a31c827b9e931a0e2d1d0b121fdfeccea7ace Mon Sep 17 00:00:00 2001
From: Michal Nazarewicz 
Date: Fri, 9 Dec 2016 15:56:44 +0100
Subject: [PATCH] =?UTF-8?q?usb:=20function:=20make=20sure=20usb=5Fget=5Ffu?=
 =?UTF-8?q?nction*=20functions=20don=E2=80=99t=20returen=20NULL?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The interface for usb_get_function and usb_get_function_instance is
that they return a pointer or an error pointer.  In other words, they
never return NULL.  For that to work, they rely on alloc_func and
alloc_inst callbacks respectively to never return NULL either.  Indeed,
if those callbacks ever return NULL, a null pointer dereference will
happen.

Be defensive about it and check in those functions whether the callbacks
(incorrectly) returned NULL and interpret it as ENOMEM error pointer
instead.

Signed-off-by: Michal Nazarewicz 
---
 drivers/usb/gadget/functions.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/functions.c b/drivers/usb/gadget/functions.c
index b13f839..4a1f1fb 100644
--- a/drivers/usb/gadget/functions.c
+++ b/drivers/usb/gadget/functions.c
@@ -27,12 +27,12 @@ static struct usb_function_instance 
*try_get_usb_function_instance(const char *n
fi = fd->alloc_inst();
if (IS_ERR(fi))
module_put(fd->mod);
-   else
+   else if (fi)  /* This should always be true but be defensive. */
fi->fd = fd;
break;
}
mutex_unlock(&func_lock);
-   return fi;
+   return fi ? fi : ERR_PTR(-ENOMEM);
 }
 
 struct usb_function_instance *usb_get_function_instance(const char *name)
@@ -43,6 +43,8 @@ struct usb_function_instance *usb_get_function_instance(const 
char *name)
fi = try_get_usb_function_instance(name);
if (!IS_ERR(fi))
return fi;
+   else if (!fi)  /* We should never be here but be defensive about it. */
+   return ERR_PTR(-ENOMEM);
ret = PTR_ERR(fi);
if (ret != -ENOENT)
return fi;
@@ -60,6 +62,8 @@ struct usb_function *usb_get_function(struct 
usb_function_instance *fi)
f = fi->fd->alloc_func(fi);
if (IS_ERR(f))
return f;
+   else if (!f)  /* We should never be here but be defensive about it. */
+   return ERR_PTR(-ENOMEM);
f->fi = fi;
return f;
 }
-- 
2.8.0.rc3.226.g39d4020
--- >8 -

However, I don’t think it is necessary and it only complicates code.

> ---
>  drivers/usb/gadget/legacy/nokia.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/gadget/legacy/nokia.c 
> b/drivers/usb/gadget/legacy/nokia.c
> index b1e535f..d3ba286 100644
> --- a/drivers/usb/gadget/legacy/nokia.c
> +++ b/drivers/usb/gadget/legacy/nokia.c
> @@ -159,36 +159,36 @@ static int nokia_bind_config(struct usb_configuration 
> *c)
>  
>   if (!IS_ERR(fi_phonet)) {
>   f_phonet = usb_get_function(fi_phonet);
> - if (IS_ERR(f_phonet))
> + if (IS_ERR_OR_NULL(f_phonet))
>   pr_debug("could not get phonet function\n");
>   }
>  
>   if (!IS_ERR(fi_obex1)) {
>   f_obex1 = usb_get_function(fi_obex1);
> - if (IS_ERR(f_obex1))
> + if (IS_ERR_OR_NULL(f_obex1))
>   pr_debug("could not get obex function 0\n");
>   }
>  
>   if (!IS_ERR(fi_obex2)) {
>   f_obex2 = usb_get_function(fi_obex2);
> - if (IS_ERR(f_obex2))
> + if (IS_ERR_OR_NULL(f_obex2))
>   pr_debug("could not get obex function 1\n");
>   }
>  
>   f_acm = usb_get_function(fi_acm);
> - if (IS_ERR(f_acm)) {
> + if (IS_ERR_OR_NULL(f_acm)) {
>   status = PTR_ERR(f_acm);
>   goto err_get_acm;
>   }
>  
>   f_ecm = usb_get_function(fi_ecm);
> - if (IS_ERR(f_ecm)) {
> + if (IS_ERR_OR_NULL(f_ecm)) {
>   status = PTR_ERR(f_ecm);
>  

Re: ch341

[Russell Senior]

>> Okay, I built your usb-linus
>>
>> 46490c347df406b3368680dd911620e52dc7bfa4
>>
>> with the line:
>>
>>r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
>>
>> commented out.  More precisely:
>
>> Loopback works, and also interoperates with pl2303 (through a null
>> modem adapter).
>
> Interesting indeed. The changes in usb-next enabled support for some
> other devices which previously did not work, but hopefully we can find a
> combination that works for all (unless we can reliably determine the
> device-type during probe).
>
> Can you try the below patch on top of my usb-next branch?

With your patch on top of usb-next loopback works (with minicom) but
does not interoperate with pl2303.  I also tried without the baudrate
change, but didn't see a difference.

PS: this testing goes much quicker when I figured out how to rebuild
just the module in question and then rmmod/insmod it. ;-)  I'm
building on an old Core 2 Duo Lenovo ThinkPad W500, a full kernel
build takes about an hour.
--
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: ch341

[Russell Senior]

> Also, when the above change makes usb-linus works, does changing the
> word size appear to work after probe?

I'm not sure what changing the word size is supposed to do.  The
usb-linus + previous patch in loopback seems to work with minicom
regardless of wordsize.  More so even than I would guess at 5N1: a ->
a, A -> A.  Trying to talk with a pl2303, 8N1 on both sides works.
7E1 works sending from ch341 to pl2303, but not pl2303 to ch341 (text
is garbled on reception). 6N1 is garbled in both directions, but
differently.


Russell
--
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: ch341

[Karl Palsson]

Can you actually trust that pl2303 module? They're not exactly
known for being trouble free, and have often been cloned in the
past as well, with varyings levels of success. Do you have a
cp210x or ft23x at all?

This is one of the great pitfalls of loopback testing, it doesn't
test that anything really does what it says, just that it does
whatever it does consistently.

Sincerely,
Karl P


Russell Senior  wrote:
> > Also, when the above change makes usb-linus works, does changing the
> > word size appear to work after probe?
> 
> I'm not sure what changing the word size is supposed to do. The
> usb-linus + previous patch in loopback seems to work with
> minicom regardless of wordsize. More so even than I would guess
> at 5N1: a -> a, A -> A. Trying to talk with a pl2303, 8N1 on
> both sides works. 7E1 works sending from ch341 to pl2303, but
> not pl2303 to ch341 (text is garbled on reception). 6N1 is
> garbled in both directions, but differently.
> 
> 
> Russell

signature.asc
Description: OpenPGP Digital Signature

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Roger Quadros]

Hi Tony,

On 08/12/16 05:21, Tony Lindgren wrote:
> Somehow starting with v4.9-rc7 there have been imprecise
> external aborts on omap5-uevm dwc3 controller. I have not been
> able to bisect what exactly triggered this as it does not always
> happen. It seems that something changed with probing that
> now exposes the issue:
> 
> Unhandled fault: imprecise external abort (0x1406) at 0x
> ...
> PC is at dwc3_omap_interrupt_thread+0x20/0x80
> LR is at irq_thread_fn+0x1c/0x54
> ...
> [] (dwc3_omap_interrupt_thread) from []
> (irq_thread_fn+0x1c/0x54)
> [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0)
> [] (irq_thread) from [] (kthread+0xdc/0xf4)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> ...
> 
> Unable to handle kernel paging request at virtual address ffec
> ...
> Internal error: Oops: 37 [#2] SMP ARM
> PC is at kthread_data+0x4/0xc
> LR is at irq_thread_dtor+0x28/0xd0
> ...
> [] (kthread_data) from [] (irq_thread_dtor+0x28/0xd0)
> [] (irq_thread_dtor) from [] (task_work_run+0xb8/0xdc)
> [] (task_work_run) from [] (do_exit+0x314/0xa20)
> [] (do_exit) from [] (die+0x410/0x474)
> [] (die) from [] (do_DataAbort+0xb4/0xb8)
> [] (do_DataAbort) from [] (__dabt_svc+0x58/0x80)
> Exception stack(0xee777ec8 to 0xee777f10)
> 7ec0:   014d ee6e6f10 0034 fc020034 ee6e6f10 ee1eec00
> 7ee0:   ee6ec640 c038a4bc    ee777f18
> 7f00: c038a4d8 c0989fa8 6013 
> [] (__dabt_svc) from [] 
> (dwc3_omap_interrupt_thread+0x20/0x80)
> [] (dwc3_omap_interrupt_thread) from [] 
> (irq_thread_fn+0x1c/0x54)
> [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0)
> [] (irq_thread) from [] (kthread+0xdc/0xf4)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> 
> Fix the issue by making sure the dwc3 interrupts are disabled
> before we call devm_request_threaded_irq().
> 
> Note that there does not seem to be issues with the dwc3 wrapper
> accessing these registers even before the dwc3 core is probed.
> If some of these registers are specific to the dwc3 core, we can
> have IRQ disabled with irq_set_status_flags(omap->irq, IRQ_NOAUTOEN)
> on start-up instead of accessing the dwc3 registers.
> 
> Reported-by: Kevin Hilman 
> Cc: Roger Quadros 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/usb/dwc3/dwc3-omap.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -511,6 +511,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>   /* check the DMA Status */
>   reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>  
> + dwc3_omap_disable_irqs(omap);
> +
>   ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>   dwc3_omap_interrupt_thread, IRQF_SHARED,
>   "dwc3-omap", omap);
> 

I'm not able to see this issue on my omap5-uevm or dra7-evm on v4.9-rc8.
What u-boot are you using? Are you using usb gadget in u-boot?

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

Re: Emulating USB devices from userspace

[Alan Stern]

On Fri, 9 Dec 2016, Felipe Balbi wrote:

> Hi,
> 
> Andrey Konovalov  writes:
> > On Fri, Dec 9, 2016 at 8:20 AM, Greg Kroah-Hartman
> >  wrote:
> >> On Fri, Dec 09, 2016 at 12:38:23AM +0100, Andrey Konovalov wrote:
> >>> Hi,
> >>>
> >>> I'm working on a way to extend syzkaller [1] to support fuzzing of the
> >>> USB subsystem. The idea is to be able to emulate various USB devices
> >>> and fuzz communication between the emulated device and the kernel. I'm
> >>> looking for a way to emulate devices from userspace. Similar to how
> >>> tuntap allows to create virtual network interfaces and emit ethernet
> >>> traffic by writing to /dev/net/tun.
> >>>
> >>> While googling for some information on this I found mentions of
> >>> gadgetfs and functionfs. As far as I understand, they allow to turn a
> >>> USB host into a gadget and provide a way to communicate with another
> >>> host from a userspace application running on the gadget machine.
> >>
> >> Not quite.  They are to drive a USB "gadget" device (i.e. the thing you
> >> plug into a USB host, like a keyboard).  You use that if you are running
> >> Linux inside of that keyboard.  Or inside your phone, it uses this
> >> interface when talking to your laptop.
> >>
> >>> There's also usbfs, which allows to communicate with a usb gadget
> >>> directly from a userspace application.
> >>
> >> usbfs is to talk to a USB gadget through the host controller, so you can
> >> use it to fuzz a USB gadget driver, if a host driver is not already
> >> bound to the device.
> >>
> >>> Am I right, that none of the above actually fit my needs?
> >>
> >> No, it should fit your needs just fine.  Use the dummy USB gadget
> >> controller driver to set up the USB gadget device, and control it that
> >> way.  It is how many people develop their USB gadget drivers directly on
> >> a non-gadget system (like a desktop.)
> >
> > Hi Greg,
> >
> > OK, it's starting to make some sense.
> > Dummy actually means loopback, correct?
> 
> not really, no. Dummy is a SW-only implementation of a virtual host
> controller always attached to a virtual peripheral controller.

It is a loopback, in the sense that data sent by the virtual host
controller is received by the virtual peripheral controller on the same
physical machine, and vice versa.  It's a lot like having a USB
peripheral controller, such as a net2280 PCI card, in your computer and
connecting it with a normal USB cable to one of the computer's USB host
ports.

dummy-hcd was written as a development tool.  It provides a way to test
gadget drivers without the need for setting up a separate computer to
be the gadget device and without the need for any special
USB-peripheral hardware.

On the other hand, dummy-hcd is not perfect.  Its biggest weakness is
that it does not support isochronous transactions.

> > Right now whenever I mount gadgetfs I see a dummy_udc file. This
> > basically means that I have gadgetfs set up in a loopback mode (since
> > I have CONFIG_USB_DUMMY_HCD=y). Now I can write USB device description
> > to dummy_udc and the kernel will find an appropriate driver and
> > loopback the communication with this driver to the exposed epN files.
> > Is my understanding of this correct?
> 
> kinda, yeah.
> 
> >>> Is there some way to emulate USB devices from a userspace application
> >>> via some kernel interface?
> >>
> >> Yes, use functionfs.
> >
> > As I understand, the way to write gadget drivers with functionfs is to
> > describe something that's called a function by mounting functionfs and
> > writing to the files it provides. Then you need to use configfs to
> > actually compose these functions into a device.
> >
> > Is this correct?
> 
> right
> 
> > What does a function stands for in this context? A USB configuration?
> 
> USB CDC ACM, USB Mass Storage, USB NCM, etc. A class.
> 
> > How do I enable loopback with functionfs?
> 
> you don't need functionfs for g_zero's loopback. just load g_zero

You may not be using the word "loopback" in the same way.  g_zero (a 
gadget driver) provides a loopback mode, in which any data sent by the 
host to the gadget gets echoed back, over a different endpoint, from 
the gadget to the host.  Earlier, Andrey used described dummy-hcd as 
providing a loopback connection, in which the USB gadget and the USB 
host are the same physical computer.

functionfs can be used with dummy-hcd, just as gadgetfs can.

> > Are there any advantages of using functionfs over gadgetfs for fuzzing?
> 
> nope, from your point of view, you can use either.

There may be one difference: gadgetfs only supports one configuration.  
I haven't worked with functionfs, but doesn't it support multiple 
configurations?

Alan Stern

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

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Tony Lindgren]

* Roger Quadros  [161209 08:09]:
> Hi Tony,
> 
> On 08/12/16 05:21, Tony Lindgren wrote:
> > Somehow starting with v4.9-rc7 there have been imprecise
> > external aborts on omap5-uevm dwc3 controller. I have not been
> > able to bisect what exactly triggered this as it does not always
> > happen. It seems that something changed with probing that
> > now exposes the issue:
> > 
> > Unhandled fault: imprecise external abort (0x1406) at 0x
> > ...
> > PC is at dwc3_omap_interrupt_thread+0x20/0x80
> > LR is at irq_thread_fn+0x1c/0x54
> > ...
> > [] (dwc3_omap_interrupt_thread) from []
> > (irq_thread_fn+0x1c/0x54)
> > [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0)
> > [] (irq_thread) from [] (kthread+0xdc/0xf4)
> > [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> > ...
> > 
> > Unable to handle kernel paging request at virtual address ffec
> > ...
> > Internal error: Oops: 37 [#2] SMP ARM
> > PC is at kthread_data+0x4/0xc
> > LR is at irq_thread_dtor+0x28/0xd0
> > ...
> > [] (kthread_data) from [] (irq_thread_dtor+0x28/0xd0)
> > [] (irq_thread_dtor) from [] (task_work_run+0xb8/0xdc)
> > [] (task_work_run) from [] (do_exit+0x314/0xa20)
> > [] (do_exit) from [] (die+0x410/0x474)
> > [] (die) from [] (do_DataAbort+0xb4/0xb8)
> > [] (do_DataAbort) from [] (__dabt_svc+0x58/0x80)
> > Exception stack(0xee777ec8 to 0xee777f10)
> > 7ec0:   014d ee6e6f10 0034 fc020034 ee6e6f10 
> > ee1eec00
> > 7ee0:   ee6ec640 c038a4bc    
> > ee777f18
> > 7f00: c038a4d8 c0989fa8 6013 
> > [] (__dabt_svc) from [] 
> > (dwc3_omap_interrupt_thread+0x20/0x80)
> > [] (dwc3_omap_interrupt_thread) from [] 
> > (irq_thread_fn+0x1c/0x54)
> > [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1f0)
> > [] (irq_thread) from [] (kthread+0xdc/0xf4)
> > [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> > 
> > Fix the issue by making sure the dwc3 interrupts are disabled
> > before we call devm_request_threaded_irq().
> > 
> > Note that there does not seem to be issues with the dwc3 wrapper
> > accessing these registers even before the dwc3 core is probed.
> > If some of these registers are specific to the dwc3 core, we can
> > have IRQ disabled with irq_set_status_flags(omap->irq, IRQ_NOAUTOEN)
> > on start-up instead of accessing the dwc3 registers.
> > 
> > Reported-by: Kevin Hilman 
> > Cc: Roger Quadros 
> > Signed-off-by: Tony Lindgren 
> > ---
> >  drivers/usb/dwc3/dwc3-omap.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> > --- a/drivers/usb/dwc3/dwc3-omap.c
> > +++ b/drivers/usb/dwc3/dwc3-omap.c
> > @@ -511,6 +511,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
> > /* check the DMA Status */
> > reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
> >  
> > +   dwc3_omap_disable_irqs(omap);
> > +
> > ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
> > dwc3_omap_interrupt_thread, IRQF_SHARED,
> > "dwc3-omap", omap);
> > 
> 
> I'm not able to see this issue on my omap5-uevm or dra7-evm on v4.9-rc8.
> What u-boot are you using? Are you using usb gadget in u-boot?

Seems to be a bit hard to reproduce, see for example "v4.9-rc8-74-gea5a9eff96fe"
at kernelci.org for "mainline" failed jobs:

https://kernelci.org/job/mainline/

Regards,

Tony

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

[PATCH] tools: usb: usbip: Add simple script to show how to setup vUDC

[Krzysztof Opasiak]

Add some simple script which creates a USB gadget using ConfigFS
and then exports it using vUDC.

This may be useful for people who just started playing with
USB/IP and vUDC as it shows exact steps how to setup all stuff.

Signed-off-by: Krzysztof Opasiak 
---
 tools/usb/usbip/vudc/vudc_server_example.sh | 100 
 1 file changed, 100 insertions(+)
 create mode 100755 tools/usb/usbip/vudc/vudc_server_example.sh

diff --git a/tools/usb/usbip/vudc/vudc_server_example.sh 
b/tools/usb/usbip/vudc/vudc_server_example.sh
new file mode 100755
index ..59c5130f85b3
--- /dev/null
+++ b/tools/usb/usbip/vudc/vudc_server_example.sh
@@ -0,0 +1,100 @@
+#!/bin/bash
+
+
+# This is free and unencumbered software released into the public domain.
+#
+# Anyone is free to copy, modify, publish, use, compile, sell, or
+# distribute this software, either in source code form or as a compiled
+# binary, for any purpose, commercial or non-commercial, and by any
+# means.
+#
+# In jurisdictions that recognize copyright laws, the author or authors
+# of this software dedicate any and all copyright interest in the
+# software to the public domain. We make this dedication for the benefit
+# of the public at large and to the detriment of our heirs and
+# successors. We intend this dedication to be an overt act of
+# relinquishment in perpetuity of all present and future rights to this
+# software under copyright law.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+# OTHER DEALINGS IN THE SOFTWARE.
+#
+# For more information, please refer to 
+
+
+
+# This is a sample script which shows how to use vUDC with ConfigFS gadgets
+
+
+# Stop script on error
+set -e
+
+
+# Create your USB gadget
+# You may use bare ConfigFS interface (as below)
+# or libusbgx or gt toool
+# Instead of ConfigFS gadgets you may use any of legacy gadgets.
+
+CONFIGFS_MOUNT_POINT="/sys/kernel/config"
+GADGET_NAME="g1"
+ID_VENDOR="0x1d6b"
+ID_PRODUCT="0x0104"
+
+cd ${CONFIGFS_MOUNT_POINT}/usb_gadget
+# Create a new USB gadget
+mkdir ${GADGET_NAME}
+cd ${GADGET_NAME}
+
+# This gadget contains one function - ACM (serial port over USB)
+FUNC_DIR="functions/acm.ser0"
+mkdir ${FUNC_DIR}
+
+# Just one configuration
+mkdir configs/c.1
+ln -s ${FUNC_DIR} configs/c.1
+
+# Set our gadget identity
+echo ${ID_VENDOR} > idVendor
+echo ${ID_PRODUCT} > idProduct
+
+
+# Load vudc-module if vudc is not available
+# You may change value of num param to get more than one vUDC instance
+
+[[ -d /sys/class/udc/usbip-vudc.0 ]] || modprobe usbip-vudc num=1
+
+
+# Bind gadget to our vUDC
+# By default we bind to first one but you may change this if you would like
+# to use more than one instance
+
+echo "usbip-vudc.0" > UDC
+
+
+# Let's now run our usbip daemon in a USB device mode
+
+usbipd --device &
+
+
+# Now your USB gadget is available using USB/IP protocol.
+# To check this you may try to list available devices:
+#
+# $ usbip list -r $SERVER_IP
+# Exportable USB devices
+# ==
+# usbipd: info: request 0x8005(6): complete
+#  - 127.0.0.1
+# usbip-vudc.0: Linux Foundation : unknown product (1d6b:0104)
+#: /sys/devices/platform/usbip-vudc.0
+#: (Defined at Interface level) (00/00/00)
+#
+# To attach this device to your server you may use:
+#
+# $ usbip attach -r $SERVER_IP -d usbip-vudc.0
+#
+
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@v

Re: Fwd: Antwort: Re: vUDC

[Krzysztof Opasiak]

On 12/09/2016 03:43 PM, Shuah Khan wrote:
> Hi Krzysztof,
> 
> On 12/09/2016 01:43 AM, Krzysztof Opasiak wrote:
>> FYI to the list for next generations;)
>>
>>
>>  Forwarded Message 
>> Subject: Antwort: Re: vUDC
>> Date: Fri, 9 Dec 2016 09:00:04 +0100
>> From: Elen Niedermeyer 
>> To: Krzysztof Opasiak 
>>
>>
>> Hi,
>>
>> so your script solved my problem. I didn't know that I should start the
>> daemon with 'usbipd --device' after starting my emulation. I've tried it
>> with 'usbip -d' and then bind my device with 'usbip bind -b BUSID'. But
>> there wasn't listet a device by usbip with 'usbip list -l', so I didn't
>> know what I have to bind.  Mit freundlichen Grüßen
>> Kind regards,
>>
>> i.A. Elen Niedermeyer
>> Duale Studentin Informatik
>> __
>>
>> BIOTRONIK SE & Co. KG
>> Woermannkehre 1
>> 12359 Berlin, Germany
>>
>> Phone: +49 (0) 30 68905-2459
>> Fax: +49 (0) 30 68905 2940
>> Mail: elen.niederme...@biotronik.com
>>
>> -Krzysztof Opasiak  schrieb: -
>> An: Shuah Khan , Elen Niedermeyer
>> 
>> Von: Krzysztof Opasiak 
>> Datum: 08.12.2016 16:11
>> Kopie: linux-usb@vger.kernel.org, kernelnewb...@nl.linux.org, LKML
>> , sh...@kernel.org
>> Betreff: Re: vUDC
>>
>> Hi,
>>
>> On 12/08/2016 03:33 PM, Shuah Khan wrote:
>>> Hi Elen,
>>>
>>> Adding k.opas...@samsung.com
>>>
>>> On Thu, Dec 8, 2016 at 7:07 AM, Elen Niedermeyer
>>>  wrote:
 Dear Sir or Madam,

 I'm trying to run usbip-vudc since a few days. I want to access my 
 emulated usb devices over usbip.
 I use Ubuntu 16.04.01 and updated my kernel to version 4.8.0-30. I've 
 installed linux-tools-4.8.0-30-generic which includes usbip. I enabled the 
 modules usbip-host and usbip-vudc on the server. Futhermore I use configfs 
 to emulate the usb devices.
 So I could start the daemon and my emulation. But I can't detect my 
 emulated usb device with usbip to bind it.
 Could you help me to run usbip-vudc? Do I have to install an additional 
 package? Do I miss a step?

 Mit freundlichen Grüßen
 Kind regards,
>>>
>>> Could you please send your dmesg? Also could you run usbipd with
>>> --debug and usbip with --log option and send the syslog
>>>
>>> Krzysztof,
>>>
>>
>> You setup script should look like this:
>>
>> Server:
>> $ modprobe usbip-vudc
>> # Create your gadget, for example:
>> $ cd /sys/kernel/config/usb_gadget
>> $ mkdir g1
>> $ mkdir g1/functions/acm.ser0
>> $ mkdir g1/configs/c.1
>> $ ln -s g1/functions/acm.ser0 g1/configs/c.1
>> $ echo "0x1234" > g1/idVendor
>> $ echo "0x5678" > g1/idProduct
>> $ echo usbip-vudc.0 > UDC
>> $ usbipd --device
>>
>> Client:
>> $ modprobe usbip-vhci
>> $ usbip attach -r $SERVER_IP -d usbip-vudc.0
>>
>> Please let me know if your setup script is similar and what exactly is
> 
> I would be good to create server_sample.sh and client_sample.sh and add
> them to tools/usb/usbip - users can customize them.
> 
> What do you think? Is this something you have time for?
> 

I have just created one. Patch is on the list[1].

Footnotes:
1 - http://marc.info/?l=linux-usb&m=148130330315109&w=2

Cheers,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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] tools: usb: usbip: Add simple script to show how to setup vUDC

[Krzysztof Opasiak]

On 12/09/2016 06:07 PM, Krzysztof Opasiak wrote:
> Add some simple script which creates a USB gadget using ConfigFS
> and then exports it using vUDC.
> 
> This may be useful for people who just started playing with
> USB/IP and vUDC as it shows exact steps how to setup all stuff.
> 
> Signed-off-by: Krzysztof Opasiak 
> ---
>  tools/usb/usbip/vudc/vudc_server_example.sh | 100 
> 
>  1 file changed, 100 insertions(+)
>  create mode 100755 tools/usb/usbip/vudc/vudc_server_example.sh
> 
> diff --git a/tools/usb/usbip/vudc/vudc_server_example.sh 
> b/tools/usb/usbip/vudc/vudc_server_example.sh
> new file mode 100755
> index ..59c5130f85b3
> --- /dev/null
> +++ b/tools/usb/usbip/vudc/vudc_server_example.sh
> @@ -0,0 +1,100 @@
> +#!/bin/bash
> +
> +
> +# This is free and unencumbered software released into the public domain.
> +#
> +# Anyone is free to copy, modify, publish, use, compile, sell, or
> +# distribute this software, either in source code form or as a compiled
> +# binary, for any purpose, commercial or non-commercial, and by any
> +# means.
> +#
> +# In jurisdictions that recognize copyright laws, the author or authors
> +# of this software dedicate any and all copyright interest in the
> +# software to the public domain. We make this dedication for the benefit
> +# of the public at large and to the detriment of our heirs and
> +# successors. We intend this dedication to be an overt act of
> +# relinquishment in perpetuity of all present and future rights to this
> +# software under copyright law.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
> +# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> +# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> +# OTHER DEALINGS IN THE SOFTWARE.
> +#
> +# For more information, please refer to 
> +
> +
> +
> +# This is a sample script which shows how to use vUDC with ConfigFS gadgets
> +
> +
> +# Stop script on error
> +set -e
> +
> +
> +# Create your USB gadget
> +# You may use bare ConfigFS interface (as below)
> +# or libusbgx or gt toool
> +# Instead of ConfigFS gadgets you may use any of legacy gadgets.
> +
> +CONFIGFS_MOUNT_POINT="/sys/kernel/config"
> +GADGET_NAME="g1"
> +ID_VENDOR="0x1d6b"
> +ID_PRODUCT="0x0104"
> +
> +cd ${CONFIGFS_MOUNT_POINT}/usb_gadget
> +# Create a new USB gadget
> +mkdir ${GADGET_NAME}
> +cd ${GADGET_NAME}
> +
> +# This gadget contains one function - ACM (serial port over USB)
> +FUNC_DIR="functions/acm.ser0"
> +mkdir ${FUNC_DIR}
> +
> +# Just one configuration
> +mkdir configs/c.1
> +ln -s ${FUNC_DIR} configs/c.1
> +
> +# Set our gadget identity
> +echo ${ID_VENDOR} > idVendor
> +echo ${ID_PRODUCT} > idProduct
> +
> +
> +# Load vudc-module if vudc is not available
> +# You may change value of num param to get more than one vUDC instance
> +
> +[[ -d /sys/class/udc/usbip-vudc.0 ]] || modprobe usbip-vudc num=1
> +
> +
> +# Bind gadget to our vUDC
> +# By default we bind to first one but you may change this if you would like
> +# to use more than one instance
> +
> +echo "usbip-vudc.0" > UDC
> +
> +
> +# Let's now run our usbip daemon in a USB device mode
> +
> +usbipd --device &
> +
> +
> +# Now your USB gadget is available using USB/IP protocol.
> +# To check this you may try to list available devices:
> +#
> +# $ usbip list -r $SERVER_IP
> +# Exportable USB devices
> +# ==
> +# usbipd: info: request 0x8005(6): complete
> +#  - 127.0.0.1
> +# usbip-vudc.0: Linux Foundation : unknown product (1d6b:0104)
> +#: /sys/devices/platform/usbip-vudc.0
> +#: (Defined at Interface level) (00/00/00)
> +#
> +# To attach this device to

[PATCH v2] tools: usb: usbip: Add simple script to show how to setup vUDC

[Krzysztof Opasiak]

Add some simple script which creates a USB gadget using ConfigFS
and then exports it using vUDC.

This may be useful for people who just started playing with
USB/IP and vUDC as it shows exact steps how to setup all stuff.

Signed-off-by: Krzysztof Opasiak 
---
Changes since v1:
- Fix terminology mistake (server instead of client)
---
 tools/usb/usbip/vudc/vudc_server_example.sh | 100 
 1 file changed, 100 insertions(+)
 create mode 100755 tools/usb/usbip/vudc/vudc_server_example.sh

diff --git a/tools/usb/usbip/vudc/vudc_server_example.sh 
b/tools/usb/usbip/vudc/vudc_server_example.sh
new file mode 100755
index ..9bd1fd58d592
--- /dev/null
+++ b/tools/usb/usbip/vudc/vudc_server_example.sh
@@ -0,0 +1,100 @@
+#!/bin/bash
+
+
+# This is free and unencumbered software released into the public domain.
+#
+# Anyone is free to copy, modify, publish, use, compile, sell, or
+# distribute this software, either in source code form or as a compiled
+# binary, for any purpose, commercial or non-commercial, and by any
+# means.
+#
+# In jurisdictions that recognize copyright laws, the author or authors
+# of this software dedicate any and all copyright interest in the
+# software to the public domain. We make this dedication for the benefit
+# of the public at large and to the detriment of our heirs and
+# successors. We intend this dedication to be an overt act of
+# relinquishment in perpetuity of all present and future rights to this
+# software under copyright law.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+# OTHER DEALINGS IN THE SOFTWARE.
+#
+# For more information, please refer to 
+
+
+
+# This is a sample script which shows how to use vUDC with ConfigFS gadgets
+
+
+# Stop script on error
+set -e
+
+
+# Create your USB gadget
+# You may use bare ConfigFS interface (as below)
+# or libusbgx or gt toool
+# Instead of ConfigFS gadgets you may use any of legacy gadgets.
+
+CONFIGFS_MOUNT_POINT="/sys/kernel/config"
+GADGET_NAME="g1"
+ID_VENDOR="0x1d6b"
+ID_PRODUCT="0x0104"
+
+cd ${CONFIGFS_MOUNT_POINT}/usb_gadget
+# Create a new USB gadget
+mkdir ${GADGET_NAME}
+cd ${GADGET_NAME}
+
+# This gadget contains one function - ACM (serial port over USB)
+FUNC_DIR="functions/acm.ser0"
+mkdir ${FUNC_DIR}
+
+# Just one configuration
+mkdir configs/c.1
+ln -s ${FUNC_DIR} configs/c.1
+
+# Set our gadget identity
+echo ${ID_VENDOR} > idVendor
+echo ${ID_PRODUCT} > idProduct
+
+
+# Load vudc-module if vudc is not available
+# You may change value of num param to get more than one vUDC instance
+
+[[ -d /sys/class/udc/usbip-vudc.0 ]] || modprobe usbip-vudc num=1
+
+
+# Bind gadget to our vUDC
+# By default we bind to first one but you may change this if you would like
+# to use more than one instance
+
+echo "usbip-vudc.0" > UDC
+
+
+# Let's now run our usbip daemon in a USB device mode
+
+usbipd --device &
+
+
+# Now your USB gadget is available using USB/IP protocol.
+# To check this you may try to list available devices:
+#
+# $ usbip list -r $SERVER_IP
+# Exportable USB devices
+# ==
+# usbipd: info: request 0x8005(6): complete
+#  - 127.0.0.1
+# usbip-vudc.0: Linux Foundation : unknown product (1d6b:0104)
+#: /sys/devices/platform/usbip-vudc.0
+#: (Defined at Interface level) (00/00/00)
+#
+# To attach this device to your client you may use:
+#
+# $ usbip attach -r $SERVER_IP -d usbip-vudc.0
+#
+
-- 
2.9.3

--
To unsubscribe from this list: se

Re: [PATCH] usb: dwc3: omap: Fix imprecise external abort and oops on boot

[Grygorii Strashko]

On 12/08/2016 05:55 PM, Tony Lindgren wrote:
> * Grygorii Strashko  [161208 15:38]:
>> On 12/08/2016 04:57 PM, Tony Lindgren wrote:
>>> Seems to work based on few boot tests. Probably both should be applied,
>>> my original patch to prevent spurious interrupts before things are
>>> initialized,
>>
>> you patch - do you mean disable irq  or clean up
>> irq status regs before requesting irq? for me, more logical is to
>> clean up irq status regs.
> 
> What I originally posted in this thread, clear irq registers
> before requesting irq.
> 
>> this to disable interrupts before pm_runtime_suspend()
>>> on exit path:
>>>
>>> Tested-by: Tony Lindgren 
>>
>> So, you wanna me to send this as patch or wish to squash in yours?
>> (I'll be able to do this only tomorrow)
> 
> I think this should be a separate patch for the exit path.
> 

Actually, It seems correct solution will be to switch back from
devm_request_threaded_irq() to just request_threaded_irq(), because
similar problem can happen with dwc3_omap_remove() - there are no guarantee
that there will be no IRQ handler running when dwc3_omap_remove()
is executed and dwc3_omap_disable_irqs() will not help with that.


-- 
regards,
-grygorii
--
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/2] dt-bindings: usb: add DT binding for s3c2410 USB device controller

[Sergio Prado]

Adds the device tree bindings description for Samsung S3C2410 and
compatible USB device controller.

Signed-off-by: Sergio Prado 
---
 .../devicetree/bindings/usb/s3c2410-usb.txt| 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt 
b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
index e45b38ce2986..4d3f9894c2d4 100644
--- a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
+++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
@@ -20,3 +20,31 @@ usb0: ohci@4900 {
clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
clock-names = "usb-bus-host", "usb-host";
 };
+
+Samsung S3C2410 and compatible USB device controller
+
+Required properties:
+ - compatible: Should be one of the following
+  "samsung,s3c2410-udc"
+  "samsung,s3c2440-udc"
+ - reg: address and length of the controller memory mapped region
+ - interrupts: interrupt number for the USB device controller
+ - clocks: Should reference the bus and host clocks
+ - clock-names: Should contain two strings
+   "usb-bus-gadget" for the USB bus clock
+   "usb-device" for the USB device clock
+
+Optional properties:
+ - samsung,vbus-gpio: If present, specifies a gpio that needs to be
+   activated for the bus to be powered.
+ - samsung,pullup-gpio: If present, specifies a gpio to control the
+   USB D+ pullup.
+
+usb1: udc@5200 {
+   compatible = "samsung,s3c2440-udc";
+   reg = <0x5200 0x10>;
+   interrupts = <0 0 25 3>;
+   clocks = <&clocks UCLK>, <&clocks HCLK_USBD>;
+   clock-names = "usb-bus-gadget", "usb-device";
+   samsung,pullup-gpio = <&gpc 5 GPIO_ACTIVE_HIGH>;
+};
-- 
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/2] usb: gadget: s3c2410: allow probing from device tree

[Sergio Prado]

Allows configuring Samsung's s3c2410 and compatible USB device
controller using a devicetree.

Signed-off-by: Sergio Prado 
---
 drivers/usb/gadget/udc/s3c2410_udc.c | 142 +--
 drivers/usb/gadget/udc/s3c2410_udc.h |   4 +
 2 files changed, 123 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c 
b/drivers/usb/gadget/udc/s3c2410_udc.c
index 4643a01262b4..e3b5a0e6646e 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -55,6 +58,18 @@
 #define DRIVER_AUTHOR  "Herbert Pötzl , " \
"Arnaud Patard "
 
+struct s3c2410_udc_drv_data {
+   int ep_fifo_size;
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2410_drv_data = {
+   .ep_fifo_size = EP_FIFO_SIZE,
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2440_drv_data = {
+   .ep_fifo_size = S3C2440_EP_FIFO_SIZE,
+};
+
 static const char  gadget_name[] = "s3c2410_udc";
 static const char  driver_desc[] = DRIVER_DESC;
 
@@ -62,8 +77,6 @@
 static struct clk  *udc_clock;
 static struct clk  *usb_bus_clock;
 static void __iomem*base_addr;
-static u64 rsrc_start;
-static u64 rsrc_len;
 static struct dentry   *s3c2410_udc_debugfs_root;
 
 static inline u32 udc_read(u32 reg)
@@ -997,7 +1010,7 @@ static irqreturn_t s3c2410_udc_irq(int dummy, void *_dev)
}
}
 
-   dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", IRQ_USBD);
+   dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", dev->irq);
 
/* Restore old index */
udc_write(idx, S3C2410_UDC_INDEX_REG);
@@ -1757,6 +1770,49 @@ static int s3c2410_udc_stop(struct usb_gadget *g)
 
 };
 
+static int s3c2410_udc_probe_dt(struct s3c2410_udc *udc)
+{
+   const struct s3c2410_udc_drv_data *drvdata;
+   struct platform_device *pdev = udc->pdev;
+   struct s3c2410_udc_mach_info *pdata;
+   int gpio;
+
+   drvdata = of_device_get_match_data(&pdev->dev);
+
+   if (drvdata)
+   udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+   pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,vbus-gpio", 0);
+   if (gpio_is_valid(gpio))
+   pdata->vbus_pin = gpio;
+
+   gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,pullup-gpio", 0);
+   if (gpio_is_valid(gpio))
+   pdata->pullup_pin = gpio;
+
+   pdev->dev.platform_data = pdata;
+
+   return 0;
+}
+
+static int s3c2410_udc_probe_pdata(struct s3c2410_udc *udc)
+{
+   const struct s3c2410_udc_drv_data *drvdata;
+   struct platform_device *pdev = udc->pdev;
+
+   drvdata = (struct s3c2410_udc_drv_data *)
+   platform_get_device_id(pdev)->driver_data;
+
+   if (drvdata)
+   udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+   return 0;
+}
+
 /*
  * probe - binds to the platform device
  */
@@ -1769,6 +1825,16 @@ static int s3c2410_udc_probe(struct platform_device 
*pdev)
 
dev_dbg(dev, "%s()\n", __func__);
 
+   udc->pdev = pdev;
+
+   if (pdev->dev.of_node)
+   retval = s3c2410_udc_probe_dt(udc);
+   else
+   retval = s3c2410_udc_probe_pdata(udc);
+
+   if (retval)
+   return retval;
+
usb_bus_clock = clk_get(NULL, "usb-bus-gadget");
if (IS_ERR(usb_bus_clock)) {
dev_err(dev, "failed to get usb bus clock source\n");
@@ -1789,24 +1855,27 @@ static int s3c2410_udc_probe(struct platform_device 
*pdev)
 
dev_dbg(dev, "got and enabled clocks\n");
 
-   if (strncmp(pdev->name, "s3c2440", 7) == 0) {
-   dev_info(dev, "S3C2440: increasing FIFO to 128 bytes\n");
-   memory.ep[1].fifo_size = S3C2440_EP_FIFO_SIZE;
-   memory.ep[2].fifo_size = S3C2440_EP_FIFO_SIZE;
-   memory.ep[3].fifo_size = S3C2440_EP_FIFO_SIZE;
-   memory.ep[4].fifo_size = S3C2440_EP_FIFO_SIZE;
+   if (udc->ep_fifo_size) {
+   dev_info(dev, "setting FIFO to %d bytes\n", udc->ep_fifo_size);
+   memory.ep[1].fifo_size = udc->ep_fifo_size;
+   memory.ep[2].fifo_size = udc->ep_fifo_size;
+   memory.ep[3].fifo_size = udc->ep_fifo_size;
+   memory.ep[4].fifo_size = udc->ep_fifo_size;
}
 
spin_lock_init(&udc->lock);
udc_info = dev_get_platdata(&pdev->dev);
 
-   rsrc_start = S3C2410_PA_USBDEV;
-   rsrc_len   = S3C24XX_SZ_USBDEV;
+   udc->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!udc->mem) {
+   dev_err(dev, "failed to get I/O memory region\n");
+   return -ENOENT;
+   

[PATCH 0/2] usb: gadget: s3c2410: add device tree support

[Sergio Prado]

This series adds support for configuring Samsung's s3c2410 and
compatible USB device controller via devicetree.

Tested on FriendlyARM mini2440, based on s3c2440 SoC.

Sergio Prado (2):
  dt-bindings: usb: add DT binding for s3c2410 USB device controller
  usb: gadget: s3c2410: allow probing from device tree

 .../devicetree/bindings/usb/s3c2410-usb.txt|  28 
 drivers/usb/gadget/udc/s3c2410_udc.c   | 142 +
 drivers/usb/gadget/udc/s3c2410_udc.h   |   4 +
 3 files changed, 151 insertions(+), 23 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

Re: usb/gadget: use-after-free in gadgetfs_setup

[Alan Stern]

On Fri, 9 Dec 2016, Andrey Konovalov wrote:

> On Wed, Dec 7, 2016 at 8:15 PM, Alan Stern  wrote:
> > On Wed, 7 Dec 2016, Andrey Konovalov wrote:
> >
> >> > And in any case, is there any way you can post the series of system
> >> > calls that syzkaller makes so we can tell what went wrong?
> >>
> >> I've attached a reproducer for a use-after-free in gadgetfs_setup().
> >> You need to enable KASAN to see the reports.
> >
> > Okay, that helps.  I see the problem: dev->hs_config ends up containing
> > a stale pointer in dev_config().  The patch below ought to fix that;
> > please verify that it really does.
> 
> Hi Alan,
> 
> Have been fuzzing with your patch, haven't seen any more reports.
> 
> Thanks!

Okay, good.  I'll submit the two patches.

Can you also provide reproducers for the "GPF in
usb_gadget_unregister_driver" and the "warning in dummy_free_request"  
tests?

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

[PATCH 1/1] Increase USB transfer limit

[Mateusz Berezecki]

This patch promotes a variable keeping track of USB transfer memory
usage to a wider data type, allowing higher bandwidth transfers from a
large number of USB devices connected to a single host.

Signed-off-by: Mateusz Berezecki 
---
 drivers/usb/core/devio.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 4016dae..ca4c8581 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -134,20 +134,20 @@ enum snoop_when {
 #define USB_DEVICE_DEV MKDEV(USB_DEVICE_MAJOR, 0)
 
 /* Limit on the total amount of memory we can allocate for transfers */
-static unsigned usbfs_memory_mb = 16;
-module_param(usbfs_memory_mb, uint, 0644);
+static u64 usbfs_memory_mb = 16;
+module_param(usbfs_memory_mb, ullong, 0644);
 MODULE_PARM_DESC(usbfs_memory_mb,
"maximum MB allowed for usbfs buffers (0 = no limit)");
 
-/* Hard limit, necessary to avoid arithmetic overflow */
-#define USBFS_XFER_MAX (UINT_MAX / 2 - 100)
+/* Hard limit */
+#define USBFS_XFER_MAX (1ull << 32)
 
-static atomic_t usbfs_memory_usage;/* Total memory currently allocated */
+static atomic64_t usbfs_memory_usage;  /* Total memory currently allocated */
 
 /* Check whether it's okay to allocate more memory for a transfer */
-static int usbfs_increase_memory_usage(unsigned amount)
+static int usbfs_increase_memory_usage(u64 amount)
 {
-   unsigned lim;
+   u64 lim;
 
/*
 * Convert usbfs_memory_mb to bytes, avoiding overflows.
@@ -159,17 +159,17 @@ static int usbfs_increase_memory_usage(unsigned amount)
else
lim <<= 20;
 
-   atomic_add(amount, &usbfs_memory_usage);
-   if (atomic_read(&usbfs_memory_usage) <= lim)
+   atomic64_add(amount, &usbfs_memory_usage);
+   if (atomic64_read(&usbfs_memory_usage) <= lim)
return 0;
-   atomic_sub(amount, &usbfs_memory_usage);
+   atomic64_sub(amount, &usbfs_memory_usage);
return -ENOMEM;
 }
 
 /* Memory for a transfer is being deallocated */
-static void usbfs_decrease_memory_usage(unsigned amount)
+static void usbfs_decrease_memory_usage(u64 amount)
 {
-   atomic_sub(amount, &usbfs_memory_usage);
+   atomic64_sub(amount, &usbfs_memory_usage);
 }
 
 static int connected(struct usb_dev_state *ps)
-- 
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

[PATCH] USB: gadgetfs: fix use-after-free bug

[Alan Stern]

Andrey Konovalov reports that fuzz testing with syzkaller causes a
KASAN use-after-free bug report in gadgetfs:

BUG: KASAN: use-after-free in gadgetfs_setup+0x208a/0x20e0 at addr 
88003dfe5bf2
Read of size 2 by task syz-executor0/22994
CPU: 3 PID: 22994 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006df06a18 81f96aba e0528500 11000dbe0cd6
 ed000dbe0cce 88006df068f0 41b58ab3 8598b4c8
 81f96828 11000dbe0ccd 88006df06708 88006df06748
Call Trace:
  [  201.343209]  [< inline >] __dump_stack lib/dump_stack.c:15
  [  201.343209]  [] dump_stack+0x292/0x398 
lib/dump_stack.c:51
 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [< inline >] print_address_description mm/kasan/report.c:197
 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [< inline >] kasan_report mm/kasan/report.c:306
 [] __asan_report_load_n_noabort+0x3a/0x40 
mm/kasan/report.c:337
 [< inline >] config_buf drivers/usb/gadget/legacy/inode.c:1298
 [] gadgetfs_setup+0x208a/0x20e0 
drivers/usb/gadget/legacy/inode.c:1368
 [] dummy_timer+0x11f0/0x36d0 
drivers/usb/gadget/udc/dummy_hcd.c:1858
 [] call_timer_fn+0x241/0x800 kernel/time/timer.c:1308
 [< inline >] expire_timers kernel/time/timer.c:1348
 [] __run_timers+0xa06/0xec0 kernel/time/timer.c:1641
 [] run_timer_softirq+0x21/0x80 kernel/time/timer.c:1654
 [] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284

The cause of the bug is subtle.  The dev_config() routine gets called
twice by the fuzzer.  The first time, the user data contains both a
full-speed configuration descriptor and a high-speed config
descriptor, causing dev->hs_config to be set.  But it also contains an
invalid device descriptor, so the buffer containing the descriptors is
deallocated and dev_config() returns an error.

The second time dev_config() is called, the user data contains only a
full-speed config descriptor.  But dev->hs_config still has the stale
pointer remaining from the first call, causing the routine to think
that there is a valid high-speed config.  Later on, when the driver
dereferences the stale pointer to copy that descriptor, we get a
use-after-free access.

The fix is simple: Clear dev->hs_config if the passed-in data does not
contain a high-speed config descriptor.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
CC: 

---


[as1817]


 drivers/usb/gadget/legacy/inode.c |2 ++
 1 file changed, 2 insertions(+)

Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
===
--- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
+++ usb-4.x/drivers/usb/gadget/legacy/inode.c
@@ -1799,6 +1799,8 @@ dev_config (struct file *fd, const char
goto fail;
kbuf += total;
length -= total;
+   } else {
+   dev->hs_config = NULL;
}
 
/* could support multiple configs, using another encoding! */

--
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: gadgetfs: fix unbounded memory allocation bug

[Alan Stern]

Andrey Konovalov reports that fuzz testing with syzkaller causes a
KASAN warning in gadgetfs:

BUG: KASAN: slab-out-of-bounds in dev_config+0x86f/0x1190 at addr 
88003c47e160
Write of size 65537 by task syz-executor0/6356
CPU: 3 PID: 6356 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88003c107ad8 81f96aba 3dc11ef0 110007820eee
 ed0007820ee6 88003dc11f00 41b58ab3 8598b4c8
 81f96828 813fb4a0 88003b6eadc0 88003c107738
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] kasan_object_err+0x1c/0x70 mm/kasan/report.c:159
 [< inline >] print_address_description mm/kasan/report.c:197
 [] kasan_report_error+0x1f0/0x4e0 mm/kasan/report.c:286
 [] kasan_report+0x35/0x40 mm/kasan/report.c:306
 [< inline >] check_memory_region_inline mm/kasan/kasan.c:308
 [] check_memory_region+0x139/0x190 mm/kasan/kasan.c:315
 [] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:326
 [< inline >] copy_from_user arch/x86/include/asm/uaccess.h:689
 [< inline >] ep0_write drivers/usb/gadget/legacy/inode.c:1135
 [] dev_config+0x86f/0x1190 
drivers/usb/gadget/legacy/inode.c:1759
 [] __vfs_write+0x5d5/0x760 fs/read_write.c:510
 [] vfs_write+0x170/0x4e0 fs/read_write.c:560
 [< inline >] SYSC_write fs/read_write.c:607
 [] SyS_write+0xfb/0x230 fs/read_write.c:599
 [] entry_SYSCALL_64_fastpath+0x1f/0xc2

Indeed, there is a comment saying that the value of len is restricted
to a 16-bit integer, but the code doesn't actually do this.

This patch fixes the warning.  It replaces the comment with a
computation that forces the amount of data copied from the user in
ep0_write() to be no larger than the wLength size for the control
transfer, which is a 16-bit quantity.

Signed-off-by: Alan Stern 
Reported-by: Andrey Konovalov 
Tested-by: Andrey Konovalov 
CC: 

---


[as1816]


 drivers/usb/gadget/legacy/inode.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
===
--- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
+++ usb-4.x/drivers/usb/gadget/legacy/inode.c
@@ -1126,7 +1126,7 @@ ep0_write (struct file *fd, const char _
/* data and/or status stage for control request */
} else if (dev->state == STATE_DEV_SETUP) {
 
-   /* IN DATA+STATUS caller makes len <= wLength */
+   len = min_t(size_t, len, dev->setup_wLength);
if (dev->setup_in) {
retval = setup_req (dev->gadget->ep0, dev->req, len);
if (retval == 0) {

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

[PATCH] USB: gadgetfs: fix checks of wTotalLength in config descriptors

[Alan Stern]

Andrey Konovalov's fuzz testing of gadgetfs showed that we should
improve the driver's checks for valid configuration descriptors passed
in by the user.  In particular, the driver needs to verify that the
wTotalLength value in the descriptor is not too short (smaller
than USB_DT_CONFIG_SIZE).  And the check for whether wTotalLength is
too large has to be changed, because the driver assumes there is
always enough room remaining in the buffer to hold a device descriptor
(at least USB_DT_DEVICE_SIZE bytes).

This patch adds the additional check and fixes the existing check.  It
may do a little more than strictly necessary, but one extra check
won't hurt.

Signed-off-by: Alan Stern 
CC: Andrey Konovalov 
CC: 

---


[as1818]


 drivers/usb/gadget/legacy/inode.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
===
--- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
+++ usb-4.x/drivers/usb/gadget/legacy/inode.c
@@ -1734,10 +1734,12 @@ static struct usb_gadget_driver gadgetfs
  * such as configuration notifications.
  */
 
-static int is_valid_config (struct usb_config_descriptor *config)
+static int is_valid_config(struct usb_config_descriptor *config,
+   unsigned int total)
 {
return config->bDescriptorType == USB_DT_CONFIG
&& config->bLength == USB_DT_CONFIG_SIZE
+   && total >= USB_DT_CONFIG_SIZE
&& config->bConfigurationValue != 0
&& (config->bmAttributes & USB_CONFIG_ATT_ONE) != 0
&& (config->bmAttributes & USB_CONFIG_ATT_WAKEUP) == 0;
@@ -1786,7 +1788,8 @@ dev_config (struct file *fd, const char
/* full or low speed config */
dev->config = (void *) kbuf;
total = le16_to_cpu(dev->config->wTotalLength);
-   if (!is_valid_config (dev->config) || total >= length)
+   if (!is_valid_config(dev->config, total) ||
+   total > length - USB_DT_DEVICE_SIZE)
goto fail;
kbuf += total;
length -= total;
@@ -1795,7 +1798,8 @@ dev_config (struct file *fd, const char
if (kbuf [1] == USB_DT_CONFIG) {
dev->hs_config = (void *) kbuf;
total = le16_to_cpu(dev->hs_config->wTotalLength);
-   if (!is_valid_config (dev->hs_config) || total >= length)
+   if (!is_valid_config(dev->hs_config, total) ||
+   total > length - USB_DT_DEVICE_SIZE)
goto fail;
kbuf += total;
length -= total;

--
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: gadgetfs: remove unnecessary assignment

[Alan Stern]

The dev_config() routine in gadgetfs has a check that
dev->dev->bNumConfigurations is equal to 1, and then contains a
redundant line of code setting the value to 1.  This patch removes the
unnecessary assignment.

Signed-off-by: Alan Stern 

---


[as1819]


 drivers/usb/gadget/legacy/inode.c |1 -
 1 file changed, 1 deletion(-)

Index: usb-4.x/drivers/usb/gadget/legacy/inode.c
===
--- usb-4.x.orig/drivers/usb/gadget/legacy/inode.c
+++ usb-4.x/drivers/usb/gadget/legacy/inode.c
@@ -1817,7 +1817,6 @@ dev_config (struct file *fd, const char
|| dev->dev->bDescriptorType != USB_DT_DEVICE
|| dev->dev->bNumConfigurations != 1)
goto fail;
-   dev->dev->bNumConfigurations = 1;
dev->dev->bcdUSB = cpu_to_le16 (0x0200);
 
/* triggers gadgetfs_bind(); then we can enumerate. */

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

Re: [PATCH 1/1] Increase USB transfer limit

[Alan Stern]

On Fri, 9 Dec 2016, Mateusz Berezecki wrote:

> This patch promotes a variable keeping track of USB transfer memory
> usage to a wider data type, allowing higher bandwidth transfers from a
> large number of USB devices connected to a single host.
> 
> Signed-off-by: Mateusz Berezecki 
> ---
>  drivers/usb/core/devio.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 4016dae..ca4c8581 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -134,20 +134,20 @@ enum snoop_when {
>  #define USB_DEVICE_DEV   MKDEV(USB_DEVICE_MAJOR, 0)
>  
>  /* Limit on the total amount of memory we can allocate for transfers */
> -static unsigned usbfs_memory_mb = 16;
> -module_param(usbfs_memory_mb, uint, 0644);
> +static u64 usbfs_memory_mb = 16;
> +module_param(usbfs_memory_mb, ullong, 0644);
>  MODULE_PARM_DESC(usbfs_memory_mb,
>   "maximum MB allowed for usbfs buffers (0 = no limit)");

This parameter can remain a 32-bit quantity, since it gives the memory 
limit in MB.

> -/* Hard limit, necessary to avoid arithmetic overflow */
> -#define USBFS_XFER_MAX   (UINT_MAX / 2 - 100)
> +/* Hard limit */
> +#define USBFS_XFER_MAX   (1ull << 32)

Only 4 GB?  Why not allow a lot higher?  This only doubles the existing
hard limit, roughly.  In theory this could be as large as (1ull << 52)
-- that's about 4 billion MB, or if you prefer, 4 million GB.

The rest of the patch looks okay.

Alan Stern

> -static atomic_t usbfs_memory_usage;  /* Total memory currently allocated */
> +static atomic64_t usbfs_memory_usage;/* Total memory currently 
> allocated */
>  
>  /* Check whether it's okay to allocate more memory for a transfer */
> -static int usbfs_increase_memory_usage(unsigned amount)
> +static int usbfs_increase_memory_usage(u64 amount)
>  {
> - unsigned lim;
> + u64 lim;
>  
>   /*
>* Convert usbfs_memory_mb to bytes, avoiding overflows.
> @@ -159,17 +159,17 @@ static int usbfs_increase_memory_usage(unsigned amount)
>   else
>   lim <<= 20;
>  
> - atomic_add(amount, &usbfs_memory_usage);
> - if (atomic_read(&usbfs_memory_usage) <= lim)
> + atomic64_add(amount, &usbfs_memory_usage);
> + if (atomic64_read(&usbfs_memory_usage) <= lim)
>   return 0;
> - atomic_sub(amount, &usbfs_memory_usage);
> + atomic64_sub(amount, &usbfs_memory_usage);
>   return -ENOMEM;
>  }
>  
>  /* Memory for a transfer is being deallocated */
> -static void usbfs_decrease_memory_usage(unsigned amount)
> +static void usbfs_decrease_memory_usage(u64 amount)
>  {
> - atomic_sub(amount, &usbfs_memory_usage);
> + atomic64_sub(amount, &usbfs_memory_usage);
>  }
>  
>  static int connected(struct usb_dev_state *ps)

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

Re: [PATCH 1/1] Increase USB transfer limit

[Mateusz Berezecki]

On 9 Dec 2016, at 12:37, Alan Stern wrote:


On Fri, 9 Dec 2016, Mateusz Berezecki wrote:


This patch promotes a variable keeping track of USB transfer memory
usage to a wider data type, allowing higher bandwidth transfers from 
a

large number of USB devices connected to a single host.

Signed-off-by: Mateusz Berezecki 
---
 drivers/usb/core/devio.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 4016dae..ca4c8581 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -134,20 +134,20 @@ enum snoop_when {
 #define USB_DEVICE_DEV MKDEV(USB_DEVICE_MAJOR, 0)

 /* Limit on the total amount of memory we can allocate for transfers 
*/

-static unsigned usbfs_memory_mb = 16;
-module_param(usbfs_memory_mb, uint, 0644);
+static u64 usbfs_memory_mb = 16;
+module_param(usbfs_memory_mb, ullong, 0644);
 MODULE_PARM_DESC(usbfs_memory_mb,
"maximum MB allowed for usbfs buffers (0 = no limit)");


This parameter can remain a 32-bit quantity, since it gives the memory
limit in MB.


Good call.




-/* Hard limit, necessary to avoid arithmetic overflow */
-#define USBFS_XFER_MAX (UINT_MAX / 2 - 100)
+/* Hard limit */
+#define USBFS_XFER_MAX (1ull << 32)


Only 4 GB?  Why not allow a lot higher?  This only doubles the 
existing

hard limit, roughly.  In theory this could be as large as (1ull << 52)
-- that's about 4 billion MB, or if you prefer, 4 million GB.


Agreed. I’ll revise and re-submit.

Thanks!



The rest of the patch looks okay.

Alan Stern

-static atomic_t usbfs_memory_usage;	/* Total memory currently 
allocated */
+static atomic64_t usbfs_memory_usage;	/* Total memory currently 
allocated */


 /* Check whether it's okay to allocate more memory for a transfer */
-static int usbfs_increase_memory_usage(unsigned amount)
+static int usbfs_increase_memory_usage(u64 amount)
 {
-   unsigned lim;
+   u64 lim;

/*
 * Convert usbfs_memory_mb to bytes, avoiding overflows.
@@ -159,17 +159,17 @@ static int usbfs_increase_memory_usage(unsigned 
amount)

else
lim <<= 20;

-   atomic_add(amount, &usbfs_memory_usage);
-   if (atomic_read(&usbfs_memory_usage) <= lim)
+   atomic64_add(amount, &usbfs_memory_usage);
+   if (atomic64_read(&usbfs_memory_usage) <= lim)
return 0;
-   atomic_sub(amount, &usbfs_memory_usage);
+   atomic64_sub(amount, &usbfs_memory_usage);
return -ENOMEM;
 }

 /* Memory for a transfer is being deallocated */
-static void usbfs_decrease_memory_usage(unsigned amount)
+static void usbfs_decrease_memory_usage(u64 amount)
 {
-   atomic_sub(amount, &usbfs_memory_usage);
+   atomic64_sub(amount, &usbfs_memory_usage);
 }

 static int connected(struct usb_dev_state *ps)

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

[PATCH] usb: dwc3: omap: remove devm_request_threaded_irq

[Grygorii Strashko]

Switch back from devm_request_threaded_irq() to request_threaded_irq() to
avoid races between interrupt handler execution and PM runtime in error
handling code path in probe and in dwc3_omap_remove():

in probe:
...
 err1:
pm_runtime_put_sync(dev);
^^ PM runtime can race with IRQ handler when deferred probing happening
   due to extcon
pm_runtime_disable(dev);

return ret;

in dwc3_omap_remove:
...
dwc3_omap_disable_irqs(omap);
^^ IRQs are disabled in HW, but handler may still run
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
^^ PM runtime can race with IRQ handler
pm_runtime_disable(&pdev->dev);

return 0;

So, OMAP DWC3 IRQ need to be disabled end freed before calling
pm_runtime_put() in probe and in dwc3_omap_remove().

Signed-off-by: Grygorii Strashko 
---
Hi Tony,

This is reworked patch, so might be it need to be re-tested.

 drivers/usb/dwc3/dwc3-omap.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 29e80cc..79d74f6 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -511,18 +511,18 @@ static int dwc3_omap_probe(struct platform_device *pdev)
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
 
-   ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
-   dwc3_omap_interrupt_thread, IRQF_SHARED,
-   "dwc3-omap", omap);
+   ret = request_threaded_irq(omap->irq, dwc3_omap_interrupt,
+  dwc3_omap_interrupt_thread, IRQF_SHARED,
+  "dwc3-omap", omap);
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
omap->irq, ret);
-   goto err1;
+   goto err11;
}
 
ret = dwc3_omap_extcon_register(omap);
if (ret < 0)
-   goto err1;
+   goto err11;
 
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
@@ -538,6 +538,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
 
+err11:
+   free_irq(omap->irq, omap);
 err1:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
@@ -552,6 +554,7 @@ static int dwc3_omap_remove(struct platform_device *pdev)
extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
dwc3_omap_disable_irqs(omap);
+   free_irq(omap->irq, omap);
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
-- 
2.10.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/1] Increase USB transfer limit

[Mateusz Berezecki]

Promote a variable keeping track of USB transfer memory usage to a
wider data type and allow for higher bandwidth transfers from a large
number of USB devices connected to a single host.

Signed-off-by: Mateusz Berezecki 
---
 drivers/usb/core/devio.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 4016dae..f13b401 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -134,20 +134,20 @@ enum snoop_when {
 #define USB_DEVICE_DEV MKDEV(USB_DEVICE_MAJOR, 0)
 
 /* Limit on the total amount of memory we can allocate for transfers */
-static unsigned usbfs_memory_mb = 16;
+static u32 usbfs_memory_mb = 16;
 module_param(usbfs_memory_mb, uint, 0644);
 MODULE_PARM_DESC(usbfs_memory_mb,
"maximum MB allowed for usbfs buffers (0 = no limit)");
 
-/* Hard limit, necessary to avoid arithmetic overflow */
-#define USBFS_XFER_MAX (UINT_MAX / 2 - 100)
+/* Hard limit */
+#define USBFS_XFER_MAX (1ull << 52)
 
-static atomic_t usbfs_memory_usage;/* Total memory currently allocated */
+static atomic64_t usbfs_memory_usage;  /* Total memory currently allocated */
 
 /* Check whether it's okay to allocate more memory for a transfer */
-static int usbfs_increase_memory_usage(unsigned amount)
+static int usbfs_increase_memory_usage(u64 amount)
 {
-   unsigned lim;
+   u64 lim;
 
/*
 * Convert usbfs_memory_mb to bytes, avoiding overflows.
@@ -159,17 +159,17 @@ static int usbfs_increase_memory_usage(unsigned amount)
else
lim <<= 20;
 
-   atomic_add(amount, &usbfs_memory_usage);
-   if (atomic_read(&usbfs_memory_usage) <= lim)
+   atomic64_add(amount, &usbfs_memory_usage);
+   if (atomic64_read(&usbfs_memory_usage) <= lim)
return 0;
-   atomic_sub(amount, &usbfs_memory_usage);
+   atomic64_sub(amount, &usbfs_memory_usage);
return -ENOMEM;
 }
 
 /* Memory for a transfer is being deallocated */
-static void usbfs_decrease_memory_usage(unsigned amount)
+static void usbfs_decrease_memory_usage(u64 amount)
 {
-   atomic_sub(amount, &usbfs_memory_usage);
+   atomic64_sub(amount, &usbfs_memory_usage);
 }
 
 static int connected(struct usb_dev_state *ps)
-- 
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: [RFT PATCH 1/1] xhci: free xhci virtual devices with leaf nodes first

[Guenter Roeck]

On Wed, Nov 30, 2016 at 01:41:24PM +0200, Mathias Nyman wrote:
> On 28.11.2016 22:24, Guenter Roeck wrote:
> >On Wed, Nov 23, 2016 at 02:24:27PM +0200, Mathias Nyman wrote:
> >>the tt_info provided by a HS hub might be in use to by a child device
> >>Make sure we free the devices in the correct order.
> >>
> >>This is needed in special cases such as when xhci controller is
> >>reset when resuming from hibernate, and all virt_devices are freed.
> >>
> >>Also free the virt_devices starting from max slot_id as children
> >>more commonly have higher slot_id than parent.
> >>
> >>CC: 
> >>Signed-off-by: Mathias Nyman 
> >>
> >>---
> >>
> >>Guenter Roeck, does this work for you?
> >>
> >Yes, it does.
> >
> >Tested-by: Guenter Roeck 
> >
> >Thanks,
> >Guenter
> >
> 
> Thanks, I'll send it forward with proper Reported-by and Tested-by tags
> after 4.10-rc1
> 
Do you have this patch sitting in some branch, by any chance ?
I would like to pick it up if possible. 

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

Re: usb:xhci: support disable usb2 LPM Remote Wakeup

[Rob Herring]

On Sun, Dec 04, 2016 at 07:42:01PM +0700, Thang Q. Nguyen wrote:
> From: Thang Nguyen 
> 
> As per USB 2.0 link power management addendum ECN, table 1-2, page 4,
> device or host initiated via resume signaling; device-initiated resumes
> can be optionally enabled/disabled by software. This patch adds support
> to control enabling the USB2 RWE feature via DT/ACPI attribute.
> 
> Signed-off-by: Vu Nguyen 
> Signed-off-by: Thang Nguyen 
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>  drivers/usb/host/xhci-plat.c   | 3 +++
>  drivers/usb/host/xhci.c| 5 -
>  drivers/usb/host/xhci.h| 1 +
>  4 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 966885c..9b4cd14 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -25,6 +25,7 @@ Required properties:
>  
>  Optional properties:
>- clocks: reference to a clock
> +  - usb2-rwe-disable: disable USB2 LPM Remote Wakeup capable

Remote wakeup has been around since USB 1.0 days. Does this need to be 
USB2 or XHCI specific?

>- usb3-lpm-capable: determines if platform is USB3 LPM capable
>  
>  Example:
--
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] tools: usb: usbip: Add simple script to show how to setup vUDC

[Shuah Khan]

Hi Krzysztof,

Thanks for getting to this so quickly. Couple of comments below:

On 12/09/2016 10:15 AM, Krzysztof Opasiak wrote:
> Add some simple script which creates a USB gadget using ConfigFS
> and then exports it using vUDC.
> 
> This may be useful for people who just started playing with
> USB/IP and vUDC as it shows exact steps how to setup all stuff.
> 
> Signed-off-by: Krzysztof Opasiak 
> ---
> Changes since v1:
> - Fix terminology mistake (server instead of client)
> ---
>  tools/usb/usbip/vudc/vudc_server_example.sh | 100 
> 
>  1 file changed, 100 insertions(+)
>  create mode 100755 tools/usb/usbip/vudc/vudc_server_example.sh

Looks like it also includes client side, would it make sense to not name is 
server
and call it vudc_export_example.sh?

> 
> diff --git a/tools/usb/usbip/vudc/vudc_server_example.sh 
> b/tools/usb/usbip/vudc/vudc_server_example.sh
> new file mode 100755
> index ..9bd1fd58d592
> --- /dev/null
> +++ b/tools/usb/usbip/vudc/vudc_server_example.sh
> @@ -0,0 +1,100 @@
> +#!/bin/bash
> +
> +
> +# This is free and unencumbered software released into the public domain.
> +#
> +# Anyone is free to copy, modify, publish, use, compile, sell, or
> +# distribute this software, either in source code form or as a compiled
> +# binary, for any purpose, commercial or non-commercial, and by any
> +# means.
> +#
> +# In jurisdictions that recognize copyright laws, the author or authors
> +# of this software dedicate any and all copyright interest in the
> +# software to the public domain. We make this dedication for the benefit
> +# of the public at large and to the detriment of our heirs and
> +# successors. We intend this dedication to be an overt act of
> +# relinquishment in perpetuity of all present and future rights to this
> +# software under copyright law.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
> +# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> +# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> +# OTHER DEALINGS IN THE SOFTWARE.
> +#
> +# For more information, please refer to 
> +

This is the first file under usbip with a different license. Why did you chose
this over GPL that is what is in all oter source files in this module?

Greg! Do you have any recommendation on this?

> +
> +
> +# This is a sample script which shows how to use vUDC with ConfigFS gadgets
> +
> +
> +# Stop script on error
> +set -e
> +
> +
> +# Create your USB gadget
> +# You may use bare ConfigFS interface (as below)
> +# or libusbgx or gt toool
> +# Instead of ConfigFS gadgets you may use any of legacy gadgets.
> +
> +CONFIGFS_MOUNT_POINT="/sys/kernel/config"
> +GADGET_NAME="g1"
> +ID_VENDOR="0x1d6b"
> +ID_PRODUCT="0x0104"
> +
> +cd ${CONFIGFS_MOUNT_POINT}/usb_gadget
> +# Create a new USB gadget
> +mkdir ${GADGET_NAME}
> +cd ${GADGET_NAME}
> +
> +# This gadget contains one function - ACM (serial port over USB)
> +FUNC_DIR="functions/acm.ser0"
> +mkdir ${FUNC_DIR}
> +
> +# Just one configuration
> +mkdir configs/c.1
> +ln -s ${FUNC_DIR} configs/c.1
> +
> +# Set our gadget identity
> +echo ${ID_VENDOR} > idVendor
> +echo ${ID_PRODUCT} > idProduct
> +
> +
> +# Load vudc-module if vudc is not available
> +# You may change value of num param to get more than one vUDC instance
> +
> +[[ -d /sys/class/udc/usbip-vudc.0 ]] || modprobe usbip-vudc num=1
> +
> +
> +# Bind gadget to our vUDC
> +# By default we bind to first one but you may change this if you would like
> +# to use more than one instance
> +
> +echo "usbip-vudc.0" > UDC
> +
> +
> +# Let's now run our usbip daemon in a USB device mode
> +
> +usbipd --device &
> +
> +
> +# No

Re: [PATCH 1/1] Increase USB transfer limit

[Alan Stern]

On Fri, 9 Dec 2016, Mateusz Berezecki wrote:

> Promote a variable keeping track of USB transfer memory usage to a
> wider data type and allow for higher bandwidth transfers from a large
> number of USB devices connected to a single host.
> 
> Signed-off-by: Mateusz Berezecki 
> ---
>  drivers/usb/core/devio.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 4016dae..f13b401 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -134,20 +134,20 @@ enum snoop_when {
>  #define USB_DEVICE_DEV   MKDEV(USB_DEVICE_MAJOR, 0)
>  
>  /* Limit on the total amount of memory we can allocate for transfers */
> -static unsigned usbfs_memory_mb = 16;
> +static u32 usbfs_memory_mb = 16;
>  module_param(usbfs_memory_mb, uint, 0644);
>  MODULE_PARM_DESC(usbfs_memory_mb,
>   "maximum MB allowed for usbfs buffers (0 = no limit)");
>  
> -/* Hard limit, necessary to avoid arithmetic overflow */
> -#define USBFS_XFER_MAX   (UINT_MAX / 2 - 100)
> +/* Hard limit */
> +#define USBFS_XFER_MAX   (1ull << 52)

I should have realized this before -- my fault.  Since usbfs_memory_mb
is a u32 value, it can never be >= 2^32 MB.  Consequently, the total
memory limit can never be >= 2^52 bytes, so there's no need for
USBFS_XFER_MAX at all!

The only reason it's there now is, like the comment says, with 32-bit 
values the user could cause an arithmetic overflow.  With 64-bit values 
that isn't possible.

So you might as well just get rid of it entirely.

Alan Stern

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

Re: [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq

[Tony Lindgren]

* Grygorii Strashko  [161209 12:55]:
> Switch back from devm_request_threaded_irq() to request_threaded_irq() to
> avoid races between interrupt handler execution and PM runtime in error
> handling code path in probe and in dwc3_omap_remove():

Can't you just call disable_irq() on the exit path instead of removing
devm?

Regards,

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

Re: ch341

[Russell Senior]

Hi Karl,

The pl2303 has always worked in 8N1 mode for me, talking to serial
devices.  That's all I can say with certainty.

On Fri, Dec 9, 2016 at 8:00 AM, Karl Palsson  wrote:
>
> Can you actually trust that pl2303 module? They're not exactly
> known for being trouble free, and have often been cloned in the
> past as well, with varyings levels of success. Do you have a
> cp210x or ft23x at all?
>
> This is one of the great pitfalls of loopback testing, it doesn't
> test that anything really does what it says, just that it does
> whatever it does consistently.
>
> Sincerely,
> Karl P
>
>
> Russell Senior  wrote:
>> > Also, when the above change makes usb-linus works, does changing the
>> > word size appear to work after probe?
>>
>> I'm not sure what changing the word size is supposed to do. The
>> usb-linus + previous patch in loopback seems to work with
>> minicom regardless of wordsize. More so even than I would guess
>> at 5N1: a -> a, A -> A. Trying to talk with a pl2303, 8N1 on
>> both sides works. 7E1 works sending from ch341 to pl2303, but
>> not pl2303 to ch341 (text is garbled on reception). 6N1 is
>> garbled in both directions, but differently.
>>
>>
>> Russell
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq

[Grygorii Strashko]

On 12/09/2016 03:59 PM, Tony Lindgren wrote:

* Grygorii Strashko  [161209 12:55]:

Switch back from devm_request_threaded_irq() to request_threaded_irq() to
avoid races between interrupt handler execution and PM runtime in error
handling code path in probe and in dwc3_omap_remove():


Can't you just call disable_irq() on the exit path instead of removing
devm?



I can. But what will be the benefit from using devm then?

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

Re: [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq

[Tony Lindgren]

* Grygorii Strashko  [161209 14:46]:
> 
> 
> On 12/09/2016 03:59 PM, Tony Lindgren wrote:
> > * Grygorii Strashko  [161209 12:55]:
> > > Switch back from devm_request_threaded_irq() to request_threaded_irq() to
> > > avoid races between interrupt handler execution and PM runtime in error
> > > handling code path in probe and in dwc3_omap_remove():
> > 
> > Can't you just call disable_irq() on the exit path instead of removing
> > devm?
> > 
> 
> I can. But what will be the benefit from using devm then?

Hmm good point. Probably the least number of code would be to just
do NOAUTOEN before devm_request_irq(), then only do enable_irq()
just before returning from the probe. After all, we don't really
want the irq running until the probe is done.

I think that would leave out the extra handling from the error
path?

Regards,

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

Re: [PATCH 1/1] Increase USB transfer limit

[Mateusz Berezecki]

On 9 Dec 2016, at 13:50, Alan Stern wrote:


On Fri, 9 Dec 2016, Mateusz Berezecki wrote:

 /* Limit on the total amount of memory we can allocate for transfers 
*/

-static unsigned usbfs_memory_mb = 16;
+static u32 usbfs_memory_mb = 16;
 module_param(usbfs_memory_mb, uint, 0644);
 MODULE_PARM_DESC(usbfs_memory_mb,
"maximum MB allowed for usbfs buffers (0 = no limit)");

-/* Hard limit, necessary to avoid arithmetic overflow */
-#define USBFS_XFER_MAX (UINT_MAX / 2 - 100)
+/* Hard limit */
+#define USBFS_XFER_MAX (1ull << 52)


I should have realized this before -- my fault.  Since usbfs_memory_mb
is a u32 value, it can never be >= 2^32 MB.  Consequently, the total
memory limit can never be >= 2^52 bytes, so there's no need for
USBFS_XFER_MAX at all!

The only reason it's there now is, like the comment says, with 32-bit
values the user could cause an arithmetic overflow.  With 64-bit 
values

that isn't possible.

So you might as well just get rid of it entirely.


That’s what I thought initially as well, but in the proc_bulk() 
function, there is this piece :


static int proc_bulk(struct usb_dev_state *ps, void __user *arg)
{
[...]
struct usbdevfs_bulktransfer bulk;
unsigned int tmo, len1, pipe;

[...]

if (copy_from_user(&bulk, arg, sizeof(bulk)))
return -EFAULT;

[...]

if (!usb_maxpacket(dev, pipe, !(bulk.ep & USB_DIR_IN)))
return -EINVAL;
len1 = bulk.len;
if (len1 >= USBFS_XFER_MAX)
return -EINVAL;
ret = usbfs_increase_memory_usage(len1 + sizeof(struct urb));
if (ret)
return ret;
tbuf = kmalloc(len1, GFP_KERNEL);

Does this potentially open up some sort of resource-exhaustion 
vulnerability?

Specifically, the part where bulk is copied in from userspace,
and the len1 = bulk.len . Next without checking for some bounds,
we’d just add up that value to the memory counter.

Should the limit stay, perhaps?

Mateusz



Alan Stern

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

Re: [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq

[Grygorii Strashko]

On 12/09/2016 05:04 PM, Tony Lindgren wrote:
> * Grygorii Strashko  [161209 14:46]:
>>
>>
>> On 12/09/2016 03:59 PM, Tony Lindgren wrote:
>>> * Grygorii Strashko  [161209 12:55]:
 Switch back from devm_request_threaded_irq() to request_threaded_irq() to
 avoid races between interrupt handler execution and PM runtime in error
 handling code path in probe and in dwc3_omap_remove():
>>>
>>> Can't you just call disable_irq() on the exit path instead of removing
>>> devm?
>>>
>>
>> I can. But what will be the benefit from using devm then?
> 
> Hmm good point. Probably the least number of code would be to just
> do NOAUTOEN before devm_request_irq(), then only do enable_irq()
> just before returning from the probe. After all, we don't really
> want the irq running until the probe is done.
> 
> I think that would leave out the extra handling from the error
> path?
> 

Good question here is - do we need this irq to be enabled for sub-device
probing from of_platform_populate()? ;)  

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

Re: [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq

[Tony Lindgren]

* Grygorii Strashko  [161209 15:32]:
> 
> 
> On 12/09/2016 05:04 PM, Tony Lindgren wrote:
> > * Grygorii Strashko  [161209 14:46]:
> >>
> >>
> >> On 12/09/2016 03:59 PM, Tony Lindgren wrote:
> >>> * Grygorii Strashko  [161209 12:55]:
>  Switch back from devm_request_threaded_irq() to request_threaded_irq() to
>  avoid races between interrupt handler execution and PM runtime in error
>  handling code path in probe and in dwc3_omap_remove():
> >>>
> >>> Can't you just call disable_irq() on the exit path instead of removing
> >>> devm?
> >>>
> >>
> >> I can. But what will be the benefit from using devm then?
> > 
> > Hmm good point. Probably the least number of code would be to just
> > do NOAUTOEN before devm_request_irq(), then only do enable_irq()
> > just before returning from the probe. After all, we don't really
> > want the irq running until the probe is done.
> > 
> > I think that would leave out the extra handling from the error
> > path?
> > 
> 
> Good question here is - do we need this irq to be enabled for sub-device
> probing from of_platform_populate()? ;)  

No!

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

Re: [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq

[Grygorii Strashko]

On 12/09/2016 05:37 PM, Tony Lindgren wrote:

* Grygorii Strashko  [161209 15:32]:



On 12/09/2016 05:04 PM, Tony Lindgren wrote:

* Grygorii Strashko  [161209 14:46]:



On 12/09/2016 03:59 PM, Tony Lindgren wrote:

* Grygorii Strashko  [161209 12:55]:

Switch back from devm_request_threaded_irq() to request_threaded_irq() to
avoid races between interrupt handler execution and PM runtime in error
handling code path in probe and in dwc3_omap_remove():


Can't you just call disable_irq() on the exit path instead of removing
devm?



I can. But what will be the benefit from using devm then?


Hmm good point. Probably the least number of code would be to just
do NOAUTOEN before devm_request_irq(), then only do enable_irq()
just before returning from the probe. After all, we don't really
want the irq running until the probe is done.

I think that would leave out the extra handling from the error
path?



Good question here is - do we need this irq to be enabled for sub-device
probing from of_platform_populate()? ;)


No!


Ok, then it should work this way.

--
regards,
-grygorii
--
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

Should xhci_irq() call usb_hc_died()?

[Bjorn Helgaas]

Hi Mathias,

ehci_irq(), ohci_irq(), fotg210_irq(), and oxu210_hcd_irq() contain code
equivalent to this:

  status = ehci_readl(...);
  if (status == ~(u32) 0) {
...
usb_hc_died(hcd);
...
return IRQ_HANDLED;
  }

xhci_irq() has a similar check, but does not call usb_hc_died():

  status = readl(...);
  if (status = 0x) {
...
return IRQ_HANDLED;
  }

Should xhci_irq() also call usb_hc_died()?  Maybe there's some reason
for it to be different than the others, but it wasn't obvious to this
casual observer :)

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