Re: [RFC] usb: coccinelle and checkpatch cleanup

[Geyslan G. Bem]

2015-12-04 18:55 GMT-03:00 Geyslan G. Bem :
> While applying the "scripts/coccinelle/misc/compare_const_fl.cocci" in
> usb/host/ tree I found files that deserve almost a full cleanup (very
> wrong coding style). Eg. drivers/usb/host/ohci-dbg.c
By wrong coding style I meant checkpatch warnings.

I asked since I'm concerned not to break the author log, that I know
it's important.

>
> Can I do a full cleaning or only coccinelle patches?
>
> --
> Regards,
>
> Geyslan G. Bem
> hackingbits.com



-- 
Regards,

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

Re: [PATCH] USB: serial: cp210x: Cleaned up USB access functions.

[Johan Hovold]

On Mon, Nov 30, 2015 at 04:50:38PM -0600, Konstantin Shkolnyy wrote:
> cp210x_get_config and cp210x_set_config were hard to use. They required
> the buffer as an array of 32-bit values even for smaller values, and did
> endian conversions on per-32-bit value basis, which is wrong for some
> cp210x data structures (although not for any that were actually used.)
> This change introduces separate register accessor functions for single
> 8, 16 and 32-bit values, with endian conversion, as well as "block"
> access functions without conversion.
> 
> Signed-off-by: Konstantin Shkolnyy 
> ---
>  drivers/usb/serial/cp210x.c | 314 
> ++--
>  1 file changed, 186 insertions(+), 128 deletions(-)

There's a bit too much going on here at once. Please split this into
multiple patches to facilitate review (e.g. separate get and set, and
possibly also the three widths).

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: Infrastructure for zerocopy I/O

[Alan Stern]

On Sun, 6 Dec 2015, Steinar H. Gunderson wrote:

> >>> You don't really need to do it earlier.  An unnecessary calculation of
> >>> num_sgs won't hurt.
> >> Is it unnecessary? I thought the test was really to force num_sgs==0 for 
> >> the
> >> DMA case, not to save a little arithmetic.
> > Well, if you calculate num_sgs and then force it to 0 anyway, the 
> > calculation was unnecessary, right?
> 
> But the logic never calculates num_sgs if usbm == NULL? The if terminates
> early and num_sgs stays 0.

At this point you don't know whether as->usbm will end up being NULL.

> >> -  num_sgs = DIV_ROUND_UP(uurb->buffer_length, USB_SG_SIZE);
> >> -  if (num_sgs == 1 || num_sgs > ps->dev->bus->sg_tablesize)
> >> -  num_sgs = 0;
> >> +  /* do not use SG buffers when memory mapped segments
> >> +   * are in use
> >> +   */
> >> +  if (as->usbm) {
> >> +  num_sgs = DIV_ROUND_UP(uurb->buffer_length,
> >> +  USB_SG_SIZE);
> >> +  if (num_sgs == 1 ||
> >> +  num_sgs > ps->dev->bus->sg_tablesize) {
> >> +  num_sgs = 0;
> >> +  }
> >> +  }
> > No, no.  Leave this part of the code unchanged.  as hasn't even been
> > allocated yet.
> 
> Good point. I did warn you about the lack of testing... :-)
> 
> By “unchanged”, do you mean unchanged from previous patch or from the
> original? Because this was here all along from Markus' version of the patch.

Unchanged from the original.  After all, your patch gets applied to the
original code, not on top of Markus's patch or any of your earlier
patches.  Therefore anything your patch doesn't touch will remain the
same as the original code, not the same as in Markus's patch.

> > As pointed out repeatedly by the kbuild test robot, this should be
> > IS_ERR, not IS_ERR_VALUE.  Also, you need to set as->usbm back to NULL 
> > before jumping.
> > 
> > At this point, set num_sgs to 0 if as->usbm is non-NULL.
> 
> Didn't you just point out that this would be redundant calculation?

No, I pointed out that the calculation of num_sgs earlier would be 
unnecessary.  But it's also unavoidable, since you don't know at the 
time whether it will turn out to be necessary or not.

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 v5] USB: serial: add Moxa UPORT 11x0 driver

[Mathieu OTHACEHE]

Add a driver which supports :

- UPort 1110  : 1 port RS-232 USB to Serial Hub.
- UPort 1130  : 1 port RS-422/485 USB to Serial Hub.
- UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
- UPort 1150  : 1 port RS-232/422/485 USB to Serial Hub.
- UPort 1150I : 1 port RS-232/422/485 USB to Serial Hub with Isolation.

This driver is based on GPL MOXA driver written by Hen Huang and available
on MOXA website. The original driver was based on io_ti serial driver.

Signed-off-by: Mathieu OTHACEHE 
---

Hi Johan,

Thanks for your patience, here is v5,

Mathieu

Changes in v2:
* Use generic implementation for read/write code
* Use TIOCSRS485/TIOCGRS485 instead of moxa specific ioctl
* Other problems pointed out by Johan review

Changes in v3:
* Drop unused defines
* Fix style problems
* Remove port identification code since this driver is for one-port devices only
* Fix debug messages
* Use a mutex to protect shadow_mc
* Use usb_serial_generic_open and close
* Other problems pointed out by Johan review

Changes in v4:
* mxu1_startup return -ENODEV on purpose if the firmware was downloaded.
It avoids port_probe to fail since the device is reset.

Changes in v5:
* Drop debug messages
* Drop useless fields from mxu1_port and mxu1_device structures
* Return supported bits to userspace in function mxu1_ioctl_set_rs485
* Other problems pointed out by Johan review

 drivers/usb/serial/Kconfig   |   16 +
 drivers/usb/serial/Makefile  |1 +
 drivers/usb/serial/mxu11x0.c | 1069 ++
 3 files changed, 1086 insertions(+)
 create mode 100644 drivers/usb/serial/mxu11x0.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..f612dda 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -475,6 +475,22 @@ config USB_SERIAL_MOS7840
  To compile this driver as a module, choose M here: the
  module will be called mos7840.  If unsure, choose N.
 
+config USB_SERIAL_MXUPORT11
+   tristate "USB Moxa UPORT 11x0 Serial Driver"
+   ---help---
+ Say Y here if you want to use a MOXA UPort 11x0 Serial hub.
+
+ This driver supports:
+
+ - UPort 1110  : 1 port RS-232 USB to Serial Hub.
+ - UPort 1130  : 1 port RS-422/485 USB to Serial Hub.
+ - UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
+ - UPort 1150  : 1 port RS-232/422/485 USB to Serial Hub.
+ - UPort 1150I : 1 port RS-232/422/485 USB to Serial Hub with 
Isolation.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mxu11x0.
+
 config USB_SERIAL_MXUPORT
tristate "USB Moxa UPORT Serial Driver"
---help---
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..f3fa5e5 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_USB_SERIAL_METRO)+= 
metro-usb.o
 obj-$(CONFIG_USB_SERIAL_MOS7720)   += mos7720.o
 obj-$(CONFIG_USB_SERIAL_MOS7840)   += mos7840.o
 obj-$(CONFIG_USB_SERIAL_MXUPORT)   += mxuport.o
+obj-$(CONFIG_USB_SERIAL_MXUPORT11) += mxu11x0.o
 obj-$(CONFIG_USB_SERIAL_NAVMAN)+= navman.o
 obj-$(CONFIG_USB_SERIAL_OMNINET)   += omninet.o
 obj-$(CONFIG_USB_SERIAL_OPTICON)   += opticon.o
diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
new file mode 100644
index 000..db7ed1f
--- /dev/null
+++ b/drivers/usb/serial/mxu11x0.c
@@ -0,0 +1,1069 @@
+/*
+ *
+ * USB Moxa UPORT 11x0 Serial Driver
+ *
+ * Copyright (C) 2007 MOXA Technologies Co., Ltd.
+ * Copyright (C) 2015 Mathieu Othacehe 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *
+ * Supports the following Moxa USB to serial converters:
+ *  UPort 1110,  1 port RS-232 USB to Serial Hub.
+ *  UPort 1130,  1 port RS-422/485 USB to Serial Hub.
+ *  UPort 1130I, 1 port RS-422/485 USB to Serial Hub with isolation
+ *protection.
+ *  UPort 1150,  1 port RS-232/422/485 USB to Serial Hub.
+ *  UPort 1150I, 1 port RS-232/422/485 USB to Serial Hub with isolation
+ *  protection.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Vendor and product ids */
+#define MXU1_VENDOR_ID 0x110a
+#define MXU1_1110_PRODUCT_ID   0x1110
+#define MXU1_1130_PRODUCT_ID   0x1130
+#define MXU1_1150_PRODUCT_ID   0x1150
+#define MXU1_1151_PRODUCT_ID   0x1151
+#define MXU1_1131_PRODUCT_ID   

[PATCH] usb: host: iounmap before return

[Geyslan G. Bem]

This patch fixes a 'quirk_usb_handoff_xhci()' branch return that was not 
unmapping correctly.

Coccinelle: scripts/coccinelle/free/iounmap.cocci

Signed-off-by: Geyslan G. Bem 
---
 drivers/usb/host/pci-quirks.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index f940056..64150dd 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
/* We're reading garbage from the controller */
dev_warn(>dev,
 "xHCI controller failing to respond");
-   return;
+   goto out;
}
 
if (!ext_cap_offset)
@@ -1062,6 +1062,7 @@ hc_init:
 XHCI_MAX_HALT_USEC, val);
}
 
+out:
iounmap(base);
 }
 
-- 
2.6.3

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

[PATCH net-next] net: qmi_wwan: should hold RTNL while changing netdev type

[Bjørn Mork]

The notifier calls were thrown in as a last-minute fix for an
imagined "this device could be part of a bridge" problem. That
revealed a certain lack of locking.  Not to mention testing...

Avoid this splat:

RTNL: assertion failed at net/core/dev.c (1639)
CPU: 0 PID: 4293 Comm: bash Not tainted 4.4.0-rc3+ #358
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
  8800ad253d60 8122f7cf 8800ad253d98
 8800ad253d88 813833ab 0002 880230f48560
 880230a12900 8800ad253da0 813833da 0002
Call Trace:
 [] dump_stack+0x4b/0x63
 [] call_netdevice_notifiers_info+0x3d/0x59
 [] call_netdevice_notifiers+0x13/0x15
 [] raw_ip_store+0x81/0x193 [qmi_wwan]
 [] dev_attr_store+0x20/0x22
 [] sysfs_kf_write+0x49/0x50
 [] kernfs_fop_write+0x10a/0x151
 [] __vfs_write+0x26/0xa5
 [] ? percpu_down_read+0x53/0x7f
 [] ? __sb_start_write+0x5f/0xb0
 [] ? __sb_start_write+0x5f/0xb0
 [] vfs_write+0xa3/0xe7
 [] SyS_write+0x50/0x7e
 [] entry_SYSCALL_64_fastpath+0x12/0x6f

Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 9cc361b06909..fa9e55435f61 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -92,7 +93,7 @@ static ssize_t raw_ip_store(struct device *d,  struct 
device_attribute *attr, co
struct usbnet *dev = netdev_priv(to_net_dev(d));
struct qmi_wwan_state *info = (void *)>data;
bool enable;
-   int err;
+   int ret;
 
if (strtobool(buf, ))
return -EINVAL;
@@ -101,18 +102,22 @@ static ssize_t raw_ip_store(struct device *d,  struct 
device_attribute *attr, co
if (enable == (info->flags & QMI_WWAN_FLAG_RAWIP))
return len;
 
+   if (!rtnl_trylock())
+   return restart_syscall();
+
/* we don't want to modify a running netdev */
if (netif_running(dev->net)) {
netdev_err(dev->net, "Cannot change a running device\n");
-   return -EBUSY;
+   ret = -EBUSY;
+   goto err;
}
 
/* let other drivers deny the change */
-   err = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE, dev->net);
-   err = notifier_to_errno(err);
-   if (err) {
+   ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE, dev->net);
+   ret = notifier_to_errno(ret);
+   if (ret) {
netdev_err(dev->net, "Type change was refused\n");
-   return err;
+   goto err;
}
 
if (enable)
@@ -121,7 +126,10 @@ static ssize_t raw_ip_store(struct device *d,  struct 
device_attribute *attr, co
info->flags &= ~QMI_WWAN_FLAG_RAWIP;
qmi_wwan_netdev_setup(dev->net);
call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev->net);
-   return len;
+   ret = len;
+err:
+   rtnl_unlock();
+   return ret;
 }
 
 static DEVICE_ATTR_RW(raw_ip);
-- 
2.1.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: [PATCHv2 1/2] extcon: add driver for Intel USB mux

[Chanwoo Choi]

Hi,

On 2015년 12월 04일 17:51, Heikki Krogerus wrote:
> Hi,
> 
>> I do never want to add some specific funtcion for only this driver.
>> I think is not appropriate way.
>> - intel_usb_mux_unregister
>> - intel_usb_mux_register
>>
>> The client driver using extcon driver should use the standard extcon API
>> for code consistency. Also, I'll do the more detailed review for this patch.
> 
> The internal mux we are controlling here is physically separate
> device. Ideally we could populate child device for it, but since that
> is not possible because of the resource conflict, we use the library
> approach, which is really not that uncommon.

New added functions for only specific device driver is not library. 

The all device drivers which is included in some framework should
connect to the other device driver through only framework API as following:
  
| EXTCON framework |<>| USB framework |
  - 
||
||
extcon-intel-usb.c pci-quirks.c

But, in this case, added funticon is just direct call function
without any standard API. The below case is never appropriate implementation.

  
| EXTCON framework |  | USB framework |
  - 
||
||
extcon-intel-usb.c <  pci-quirks.c

> 
> I don't think I agree with your point even at general level. The
> control required to handle this mux, even though simple, is enough to
> deserve to be separated from xHCI code. xHCI should not need to care
> about anything else expect does it have the mux, i.e. does it need to
> register it or not. It should not need to care about how it needs to
> be controlled or even what it is. We may decide to create something
> else out of it instead of an extcon device later.
> 
> But in any case, the mux is available on all new Intel platforms, but
> it needs to be controlled by OS only in few "special" cases. We can
> not force xHCI (or pci-quirks.c to be more precise) to be aware of
> these "special" cases. The only way to make it work like that would
> bet by using ifdefs, and we really really don't want that.
> 
> And please also note that, though for now we only expect the mux
> control registers to be part of xHCI MMIO, that is not always the
> case. The control registers are part of the device controller MMIO on
> some platforms. We do not want to duplicate the whole control of the
> mux if/when we need the OS to be in control of it on a platform that
> has those control registers mapped somewhere else then xHCI MMIO,
> 
> So I would say that we have pretty good justification for separating
> the mux control, which means unfortunately custom API in this case.
> 
> But if you would prefer that we put the files somewhere else then
> drivers/extcon/ and include/linux/extcon/ I'm fine with that. If you
> like, we can put it to drivers/usb/host/ as that is where
> pci-quirks.c is. That way I think we can also put the header to
> include/usb/.

There are the two type of extcon drivers as following:
- provider extcon driver which use the devm_extcon_dev_register() and 
extcon_set_cable_state().
- client extcon driver which use the extcon_register_notifier() and 
extcon_set_cable_state() usually.
The drivers/extcon directory only includes the provider extcon driver.

You make the extcon-intel-usb.c as provider extcon driver.
At the same time, this driver is used for client extcon driver
by using the extcon_register_notifier(). If you want to recevie
the notification from extcon_register_notifier(), the extcon device
should update the state of external connector throught extcon_set_cable_state().
But, this driver don' use the extcon_set_cable_state().

I think that you should divide it according to role.

Again, the usage case of extcon have to consist of both provider extcon driver
and client extcon driver. If there is no provider extcon driver,
client extcon driver don't receive the any notification of external connector
from provider extcon driver.

Thanks,
Chanwoo Choi




--
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-next] net: qmi_wwan: should hold RTNL while changing netdev type

[David Miller]

From: Bjørn Mork 
Date: Sun,  6 Dec 2015 21:25:50 +0100

> The notifier calls were thrown in as a last-minute fix for an
> imagined "this device could be part of a bridge" problem. That
> revealed a certain lack of locking.  Not to mention testing...
> 
> Avoid this splat:
 ...
> Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
> Signed-off-by: Bjørn Mork 

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

Re: [PATCH net-next] net: cdc_ncm: add "ndp_to_end" sysfs attribute

[David Miller]

From: Bjørn Mork 
Date: Sun,  6 Dec 2015 22:47:15 +0100

> Adding a writable sysfs attribute for the "NDP to end"
> quirk flag.
> 
> This makes it easier for end users to test new devices for
> this firmware bug.  We've been lucky so far, but we should
> not depend on reporters capable of rebuilding the driver.
> 
> Cc: Enrico Mioso 
> Signed-off-by: Bjørn Mork 

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

Power off, restart, lid close and "rmmod ehci_pci" result in system hang

[Luca Bonissi]

On two different laptops (HP 250 G3 Intel N2830 - Lenovo B50-30 Intel
N2840) the system hangs while powering down, restart, closing lid and
doing "rmmod ehci_pci" if the modules xhci_pci/xhci_hcd are loaded
before ehci_pci/ehci_hcd.

The problem seems related to Intel processor/chipset: a similar laptop
(Lenovo B50-45) but with AMD E1-6010 processor does not have any problem.

The problem seems to be present in any kernel version (I tested 3.16,
3.17, 3.18, 3.19, 4.0.5, 4.3rc5).

Attached dmesg for both cases ("hang" and "not-hang" kernel modules load
sequence). In "not-hang" case, there are many errors "ehci-pci
:00:1d.0: port 1 reset error -110" during boot, slowing down startup.

Thanks,
  Luca

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0 (root@hp250) (gcc version 4.8.4 (GCC) ) #5 
SMP PREEMPT Mon Nov 2 17:22:35 CET 2015
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.16.0-generic 
root=/dev/mapper/RICKY-root ro rootflags=subvol=@ noquiet nosplash 
reboot=force,cold
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0006efff] usable
[0.00] BIOS-e820: [mem 0x0006f000-0x0006] ACPI NVS
[0.00] BIOS-e820: [mem 0x0007-0x00087fff] usable
[0.00] BIOS-e820: [mem 0x00088000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1eff] usable
[0.00] BIOS-e820: [mem 0x1f00-0x1f0f] reserved
[0.00] BIOS-e820: [mem 0x1f10-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x200f] reserved
[0.00] BIOS-e820: [mem 0x2010-0x751dafff] usable
[0.00] BIOS-e820: [mem 0x751db000-0x751defff] reserved
[0.00] BIOS-e820: [mem 0x751df000-0x781defff] usable
[0.00] BIOS-e820: [mem 0x781df000-0x7826efff] type 20
[0.00] BIOS-e820: [mem 0x7826f000-0x78aeefff] reserved
[0.00] BIOS-e820: [mem 0x78aef000-0x78beefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x78bef000-0x78c2efff] ACPI data
[0.00] BIOS-e820: [mem 0x78c2f000-0x796f0fff] usable
[0.00] BIOS-e820: [mem 0x796f1000-0x79ff0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79ff1000-0x79ff] usable
[0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xffc0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00017fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by INSYDE Corp.
[0.00] efi:  ACPI 2.0=0x78c2e014  SMBIOS=0x78aee000 
[0.00] efi: mem00: type=3, attr=0xf, 
range=[0x-0x1000) (0MB)
[0.00] efi: mem01: type=7, attr=0xf, 
range=[0x1000-0xe000) (0MB)
[0.00] efi: mem02: type=3, attr=0xf, 
range=[0xe000-0x0001) (0MB)
[0.00] efi: mem03: type=7, attr=0xf, 
range=[0x0001-0x0002e000) (0MB)
[0.00] efi: mem04: type=3, attr=0xf, 
range=[0x0002e000-0x0002f000) (0MB)
[0.00] efi: mem05: type=4, attr=0xf, 
range=[0x0002f000-0x0003) (0MB)
[0.00] efi: mem06: type=3, attr=0xf, 
range=[0x0003-0x0006f000) (0MB)
[0.00] efi: mem07: type=10, attr=0xf, 
range=[0x0006f000-0x0007) (0MB)
[0.00] efi: mem08: type=3, attr=0xf, 
range=[0x0007-0x00088000) (0MB)
[0.00] efi: mem09: type=6, attr=0x800f, 
range=[0x00088000-0x0009f000) (0MB)
[0.00] efi: mem10: type=0, attr=0xf, 
range=[0x0009f000-0x000a) (0MB)
[0.00] efi: mem11: type=7, attr=0xf, 
range=[0x0010-0x00c0) (11MB)
[0.00] efi: mem12: type=3, attr=0xf, 
range=[0x00c0-0x0100) (4MB)
[0.00] efi: mem13: type=2, attr=0xf, 
range=[0x0100-0x02239000) (18MB)
[0.00] efi: mem14: type=7, attr=0xf, 
range=[0x02239000-0x1f00) (461MB)
[0.00] efi: mem15: type=0, attr=0xf, 
range=[0x1f00-0x1f10) (1MB)
[0.00] efi: mem16: type=7, attr=0xf, 
range=[0x1f10-0x2000) (15MB)
[0.00] efi: mem17: type=0, attr=0xf, 
range=[0x2000-0x2010) (1MB)
[0.00] efi: mem18: type=7, attr=0xf, 
range=[0x2010-0x34e7a000) (333MB)
[0.00] efi: mem19: type=2, attr=0xf, 

[PATCH net-next] net: cdc_ncm: add "ndp_to_end" sysfs attribute

[Bjørn Mork]

Adding a writable sysfs attribute for the "NDP to end"
quirk flag.

This makes it easier for end users to test new devices for
this firmware bug.  We've been lucky so far, but we should
not depend on reporters capable of rebuilding the driver.

Cc: Enrico Mioso 
Signed-off-by: Bjørn Mork 
---
 Documentation/ABI/testing/sysfs-class-net-cdc_ncm | 19 ++
 drivers/net/usb/cdc_ncm.c | 43 +++
 2 files changed, 62 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm 
b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
index 5cedf72df358..f7be0e88b139 100644
--- a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -19,6 +19,25 @@ Description:
Set to 0 to pad all frames. Set greater than tx_max to
disable all padding.
 
+What:  /sys/class/net//cdc_ncm/ndp_to_end
+Date:  Dec 2015
+KernelVersion: 4.5
+Contact:   Bjørn Mork 
+Description:
+   Boolean attribute showing the status of the "NDP to
+   end" quirk.  Defaults to 'N', except for devices
+   already known to need it enabled.
+
+   The "NDP to end" quirk makes the driver place the NDP
+   (the packet index table) after the payload.  The NCM
+   specification does not mandate this, but some devices
+   are known to be more restrictive. Write 'Y' to this
+   attribute for temporary testing of a suspect device
+   failing to work with the default driver settings.
+
+   A device entry should be added to the driver if this
+   quirk is found to be required.
+
 What:  /sys/class/net//cdc_ncm/rx_max
 Date:  May 2014
 KernelVersion: 3.16
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 3b1ba8237768..b45e5cae2a6b 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -283,6 +283,48 @@ static DEVICE_ATTR(rx_max, S_IRUGO | S_IWUSR, 
cdc_ncm_show_rx_max, cdc_ncm_store
 static DEVICE_ATTR(tx_max, S_IRUGO | S_IWUSR, cdc_ncm_show_tx_max, 
cdc_ncm_store_tx_max);
 static DEVICE_ATTR(tx_timer_usecs, S_IRUGO | S_IWUSR, 
cdc_ncm_show_tx_timer_usecs, cdc_ncm_store_tx_timer_usecs);
 
+static ssize_t ndp_to_end_show(struct device *d, struct device_attribute 
*attr, char *buf)
+{
+   struct usbnet *dev = netdev_priv(to_net_dev(d));
+   struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
+
+   return sprintf(buf, "%c\n", ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END ? 
'Y' : 'N');
+}
+
+static ssize_t ndp_to_end_store(struct device *d,  struct device_attribute 
*attr, const char *buf, size_t len)
+{
+   struct usbnet *dev = netdev_priv(to_net_dev(d));
+   struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
+   bool enable;
+
+   if (strtobool(buf, ))
+   return -EINVAL;
+
+   /* no change? */
+   if (enable == (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END))
+   return len;
+
+   if (enable && !ctx->delayed_ndp16) {
+   ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL);
+   if (!ctx->delayed_ndp16)
+   return -ENOMEM;
+   }
+
+   /* flush pending data before changing flag */
+   netif_tx_lock_bh(dev->net);
+   usbnet_start_xmit(NULL, dev->net);
+   spin_lock_bh(>mtx);
+   if (enable)
+   ctx->drvflags |= CDC_NCM_FLAG_NDP_TO_END;
+   else
+   ctx->drvflags &= ~CDC_NCM_FLAG_NDP_TO_END;
+   spin_unlock_bh(>mtx);
+   netif_tx_unlock_bh(dev->net);
+
+   return len;
+}
+static DEVICE_ATTR_RW(ndp_to_end);
+
 #define NCM_PARM_ATTR(name, format, tocpu) \
 static ssize_t cdc_ncm_show_##name(struct device *d, struct device_attribute 
*attr, char *buf) \
 { \
@@ -305,6 +347,7 @@ NCM_PARM_ATTR(wNtbOutMaxDatagrams, "%u", le16_to_cpu);
 
 static struct attribute *cdc_ncm_sysfs_attrs[] = {
_attr_min_tx_pkt.attr,
+   _attr_ndp_to_end.attr,
_attr_rx_max.attr,
_attr_tx_max.attr,
_attr_tx_timer_usecs.attr,
-- 
2.1.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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Sun, Dec 06, 2015 at 01:06:08AM +0100, Steinar H. Gunderson wrote:
> I'll try to update your patch with the other suggestions tomorrow. Thanks!

Here we are. Lightly tested, I believe all comments should be addressed.

/* Steinar */

>From 73833276a4f359c35edffc2a741dba57f2e82a12 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" 
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.

Add a new interface for userspace to preallocate memory that can be
used with usbfs. This gives two primary benefits:

 - Zerocopy; data no longer needs to be copied between the userspace
   and the kernel, but can instead be read directly by the driver from
   userspace's buffers. This works for both bulk and isochronous transfers;
   isochronous also no longer need to memset() the buffer to zero to avoid
   leaking kernel data.

 - Once the buffers are allocated, USB transfers can no longer fail due to
   memory fragmentation; previously, long-running programs could run into
   problems finding a large enough contiguous memory chunk, especially on
   embedded systems or at high rates.

Memory is allocated by using mmap() against the usbfs file descriptor,
and similarly deallocated by munmap(). Once memory has been allocated,
using it as pointers to a bulk or isochronous operation means you will
automatically get zerocopy behavior. Note that this also means you cannot
modify outgoing data until the transfer is complete. The same holds for
data on the same cache lines as incoming data; DMA modifying them at the
same time could lead to your changes being overwritten.

Largely based on a patch by Markus Rechberger with some updates. The original
patch can be found at:

  http://sundtek.de/support/devio_mmap_v0.4.diff

Signed-off-by: Steinar H. Gunderson 
Signed-off-by: Markus Rechberger 
---
 drivers/usb/core/devio.c | 202 ---
 1 file changed, 192 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 38ae877c..40f988e 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -69,6 +70,7 @@ struct usb_dev_state {
spinlock_t lock;/* protects the async urb lists */
struct list_head async_pending;
struct list_head async_completed;
+   struct list_head memory_list;
wait_queue_head_t wait; /* wake up if a request completed */
unsigned int discsignr;
struct pid *disc_pid;
@@ -79,6 +81,17 @@ struct usb_dev_state {
u32 disabled_bulk_eps;
 };
 
+struct usb_memory {
+   struct list_head memlist;
+   int vma_use_count;
+   int urb_use_count;
+   u32 size;
+   void *mem;
+   dma_addr_t dma_handle;
+   unsigned long vm_start;
+   struct usb_dev_state *ps;
+};
+
 struct async {
struct list_head asynclist;
struct usb_dev_state *ps;
@@ -89,6 +102,7 @@ struct async {
void __user *userbuffer;
void __user *userurb;
struct urb *urb;
+   struct usb_memory *usbm;
unsigned int mem_usage;
int status;
u32 secid;
@@ -157,6 +171,107 @@ static int connected(struct usb_dev_state *ps)
ps->dev->state != USB_STATE_NOTATTACHED);
 }
 
+static void dec_usb_memory_use_count(struct usb_memory *usbm, int *count)
+{
+   struct usb_dev_state *ps = usbm->ps;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   --*count;
+   if (usbm->urb_use_count == 0 && usbm->vma_use_count == 0) {
+   list_del(>memlist);
+   spin_unlock_irqrestore(>lock, flags);
+
+   usb_free_coherent(ps->dev, usbm->size, usbm->mem,
+   usbm->dma_handle);
+   usbfs_decrease_memory_usage(
+   usbm->size + sizeof(struct usb_memory));
+   kfree(usbm);
+   } else {
+   spin_unlock_irqrestore(>lock, flags);
+   }
+}
+
+static void usbdev_vm_open(struct vm_area_struct *vma)
+{
+   struct usb_memory *usbm = vma->vm_private_data;
+   unsigned long flags;
+
+   spin_lock_irqsave(>ps->lock, flags);
+   ++usbm->vma_use_count;
+   spin_unlock_irqrestore(>ps->lock, flags);
+}
+
+static void usbdev_vm_close(struct vm_area_struct *vma)
+{
+   struct usb_memory *usbm = vma->vm_private_data;
+
+   dec_usb_memory_use_count(usbm, >vma_use_count);
+}
+
+struct vm_operations_struct usbdev_vm_ops = {
+   .open = usbdev_vm_open,
+   .close = usbdev_vm_close
+};
+
+static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
+{
+   struct usb_memory *usbm = NULL;
+   struct usb_dev_state *ps = file->private_data;
+   size_t size = vma->vm_end - vma->vm_start;
+   void *mem;
+   unsigned long flags;
+   dma_addr_t 

Re: [PATCH] usb: phy: Remove unused Renesas R-Car (Gen1) USB PHY driveer

[Simon Horman]

On Fri, Dec 04, 2015 at 05:04:25PM +0100, Geert Uytterhoeven wrote:
> As of commit 3d7608e4c169af03 ("ARM: shmobile: bockw: remove legacy
> board file and config"), the Renesas R-Car (Gen1) USB PHY driver is no
> longer used.
> In theory it could still be used on R-Car Gen1 SoCs, but that would
> require adding DT support to the driver. Instead, a new driver using the
> generic PHY framework should be written, as was done for R-Car Gen2.
> 
> Remove the driver for good.
> 
> Signed-off-by: Geert Uytterhoeven 

There is a typo in the subject, but that aside:

Acked-by: Simon Horman 

--
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/2] usb: musb: core: Fix handling of the phy notifications

[Kishon Vijay Abraham I]

On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote:
> We currently can't unload omap2430 MUSB platform glue driver module and
> this cause issues for fixing the MUSB code further. The reason we can't
> remove omap2430 is because it uses the PHY functions and also exports the
> omap_musb_mailbox function that some PHY drivers are using.
> 
> Let's fix the issue by exporting a more generic musb_mailbox function
> from the MUSB core and allow platform glue layers to register phy_callback
> function as needed.
> 
> And now we can now also get rid of the include/linux/musb-omap.h.
> 
> Cc: Bin Liu 
> Cc: Felipe Balbi 
> Cc: Kishon Vijay Abraham I 
> Cc: NeilBrown 
> Signed-off-by: Tony Lindgren 

Reviewed-by: Kishon Vijay Abraham I 
> 
> ---
> 
> Probably best that Felipe merges this patch via the USB tree after
> comments if that works for Kishon? I have another two fixes for the

That should be okay.

Thanks
Kishon
> phy-twl4030-usb.c coming after this series but they can be merged
> separately and won't conflict with this patch.
> 
> ---
>  drivers/phy/phy-twl4030-usb.c | 32 
>  drivers/usb/musb/musb_core.c  | 21 +
>  drivers/usb/musb/musb_core.h  |  2 ++
>  drivers/usb/musb/omap2430.c   | 27 ++-
>  drivers/usb/phy/phy-twl6030-usb.c | 30 +++---
>  include/linux/usb/musb-omap.h | 30 --
>  include/linux/usb/musb.h  | 15 +++
>  7 files changed, 83 insertions(+), 74 deletions(-)
>  delete mode 100644 include/linux/usb/musb-omap.h
> 
> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
> index 3a707dd..4a3fc6e 100644
> --- a/drivers/phy/phy-twl4030-usb.c
> +++ b/drivers/phy/phy-twl4030-usb.c
> @@ -34,7 +34,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -148,10 +148,10 @@
>   * If VBUS is valid or ID is ground, then we know a
>   * cable is present and we need to be runtime-enabled
>   */
> -static inline bool cable_present(enum omap_musb_vbus_id_status stat)
> +static inline bool cable_present(enum musb_vbus_id_status stat)
>  {
> - return stat == OMAP_MUSB_VBUS_VALID ||
> - stat == OMAP_MUSB_ID_GROUND;
> + return stat == MUSB_VBUS_VALID ||
> + stat == MUSB_ID_GROUND;
>  }
>  
>  struct twl4030_usb {
> @@ -170,7 +170,7 @@ struct twl4030_usb {
>   enum twl4030_usb_mode   usb_mode;
>  
>   int irq;
> - enum omap_musb_vbus_id_status linkstat;
> + enum musb_vbus_id_status linkstat;
>   boolvbus_supplied;
>  
>   struct delayed_work id_workaround_work;
> @@ -276,11 +276,11 @@ static bool twl4030_is_driving_vbus(struct twl4030_usb 
> *twl)
>   return (ret & (ULPI_OTG_DRVVBUS | ULPI_OTG_CHRGVBUS)) ? true : false;
>  }
>  
> -static enum omap_musb_vbus_id_status
> +static enum musb_vbus_id_status
>   twl4030_usb_linkstat(struct twl4030_usb *twl)
>  {
>   int status;
> - enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
> + enum musb_vbus_id_status linkstat = MUSB_UNKNOWN;
>  
>   twl->vbus_supplied = false;
>  
> @@ -306,14 +306,14 @@ static enum omap_musb_vbus_id_status
>   }
>  
>   if (status & BIT(2))
> - linkstat = OMAP_MUSB_ID_GROUND;
> + linkstat = MUSB_ID_GROUND;
>   else if (status & BIT(7))
> - linkstat = OMAP_MUSB_VBUS_VALID;
> + linkstat = MUSB_VBUS_VALID;
>   else
> - linkstat = OMAP_MUSB_VBUS_OFF;
> + linkstat = MUSB_VBUS_OFF;
>   } else {
> - if (twl->linkstat != OMAP_MUSB_UNKNOWN)
> - linkstat = OMAP_MUSB_VBUS_OFF;
> + if (twl->linkstat != MUSB_UNKNOWN)
> + linkstat = MUSB_VBUS_OFF;
>   }
>  
>   dev_dbg(twl->dev, "HW_CONDITIONS 0x%02x/%d; link %d\n",
> @@ -535,7 +535,7 @@ static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, 
> NULL);
>  static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
>  {
>   struct twl4030_usb *twl = _twl;
> - enum omap_musb_vbus_id_status status;
> + enum musb_vbus_id_status status;
>   bool status_changed = false;
>  
>   status = twl4030_usb_linkstat(twl);
> @@ -567,11 +567,11 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl)
>   pm_runtime_mark_last_busy(twl->dev);
>   pm_runtime_put_autosuspend(twl->dev);
>   }
> - omap_musb_mailbox(status);
> + musb_mailbox(status);
>   }
>  
>   /* don't schedule during sleep - irq works right then */
> - if (status == OMAP_MUSB_ID_GROUND && pm_runtime_active(twl->dev)) {
> + if (status == 

Re: [PATCH v6 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 6 December 2015 at 00:27, Sebastian Reichel  wrote:
> Hi,
>
> On Mon, Nov 16, 2015 at 02:33:31PM +0800, Baolin Wang wrote:
>> +static ssize_t cur_limit_show(struct device *dev,
>> +   struct device_attribute *attr,
>> +   char *buf)
>> +{
>> + struct usb_charger *uchger = dev_to_uchger(dev);
>> +
>> + return scnprintf(buf, PAGE_SIZE, "%d %d %d %d\n",
>> +  uchger->cur_limit.sdp_cur_limit,
>> +  uchger->cur_limit.dcp_cur_limit,
>> +  uchger->cur_limit.cdp_cur_limit,
>> +  uchger->cur_limit.aca_cur_limit);
>> +}
>> +
>> +static ssize_t cur_limit_store(struct device *dev,
>> +struct device_attribute *attr,
>> +const char *buf, size_t count)
>> +{
>> + struct usb_charger *uchger = dev_to_uchger(dev);
>> + struct usb_charger_cur_limit cur;
>> + int ret;
>> +
>> + ret = sscanf(buf, "%d %d %d %d",
>> +  _cur_limit, _cur_limit,
>> +  _cur_limit, _cur_limit);
>> + if (ret == 0)
>> + return -EINVAL;
>> +
>> + ret = usb_charger_set_cur_limit(uchger, );
>> + if (ret < 0)
>> + return ret;
>> +
>> + return count;
>> +}
>> +static DEVICE_ATTR_RW(cur_limit);
>
> I think this functionality should be provided with one file per
> type. This makes it easier to parse the values from userspace
> and makes it possible to extend the frameworks functionality
> (e.g. when new types are added in a newer revision of the USB
> standard).
>

That sounds reasonable and I'll change that. Thanks.

> -- Sebastian



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

Re: [PATCH 2/2] usb: musb: Fix unbalanced pm_runtime_enable

[Kishon Vijay Abraham I]

On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote:
> When reloading omap2430 kernel module we get a warning about
> unbalanced pm_runtime_enable. Let's fix this. Note that we
> need to do this after the child musb-core platform_device is
> removed because of pm_runtime_irq_safe being set at the child.
> 
> Cc: Bin Liu 
> Cc: Felipe Balbi 
> Cc: Kishon Vijay Abraham I 
> Cc: NeilBrown 
> Signed-off-by: Tony Lindgren 

Reviewed-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/musb/omap2430.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index bf05f80..c84e0322 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -664,8 +664,11 @@ static int omap2430_remove(struct platform_device *pdev)
>  {
>   struct omap2430_glue*glue = platform_get_drvdata(pdev);
>  
> + pm_runtime_get_sync(glue->dev);
>   cancel_work_sync(>omap_musb_mailbox_work);
>   platform_device_unregister(glue->musb);
> + pm_runtime_put_sync(glue->dev);
> + pm_runtime_disable(glue->dev);
>  
>   return 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