Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Rafał Miłecki]

On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:

On 01/31/2017 05:11 PM, Rafał Miłecki wrote:

On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:

On 01/25/2017 10:03 AM, Rafał Miłecki wrote:

On 21 January 2017 at 22:42, Jacek Anaszewski
 wrote:

On 01/21/2017 05:24 PM, Rafał Miłecki wrote:

On 20 January 2017 at 23:35, Jacek Anaszewski
 wrote:

On 01/20/2017 10:56 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

Some LEDs can be related to particular devices described in DT. This
property allows specifying such relations. E.g. USB LED should
usually
be used to indicate some USB port(s) state.

Signed-off-by: Rafał Miłecki 
---
V2: Replace "usb-ports" with "led-triggers" property which is
more generic and
allows specifying other devices as well.

When bindings patch is related to some followup implementation,
they usually go
through the same tree.

Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds:
Improve examples by
adding some context") from kernel/git/j.anaszewski/linux-leds.git
. Is there any
way to solve this dependency issue? Or should this patch wait
until 3.11 is
released?
---
 Documentation/devicetree/bindings/leds/common.txt | 16

 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index 24b656014089..17632a041196 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -49,6 +49,17 @@ Optional properties for child nodes:
 - panic-indicator : This property specifies that the LED should
be used,
  if at all possible, as a panic indicator.

+- led-triggers : List of devices that should trigger this LED
activity. Some
+  LEDs can be related to a specific device and
should somehow
+  indicate its state. E.g. USB 2.0 LED may react to
device(s) in
+  a USB 2.0 port(s). Another common example is
switch or router
+  with multiple Ethernet ports each of them having
its own LED
+  assigned (assuminled-trigger-usbportg they are not
hardwired).
+  In such cases this property should contain
phandle(s) of
+  related device(s). In many cases LED can be
related to more
+  than one device (e.g. one USB LED vs. multiple USB
ports) so a
+  list of entries can be specified.
+


This implies that it is possible to define multiple triggers for
a LED class device but it is not supported by LED Trigger core.
There is linux,default-trigger property which allows to define one
trigger that will be initially assigned.



With proposed "led-triggers" property one could assign different
trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
device & CPU to a single LED. For reason explained above Linux
couldn't support all of them at once.



I am aware that this is renamed usb-ports property from v1,
that attempts to address Rob's comment, but we can't do that this
way.
Maybe usb-ports property could be documented in led-trigger-usbport's
specific bindings and a reference to it could be added next to the
related entry on the list of the available LED triggers (which is
actually missing) in
Documentation/devicetree/bindings/leds/common.txt.


I'm wondering if we need to care about this Linux limitation and if it
should stop us from adding this flexible DT property. Maybe we could
live with Linux having limitation of supporting one trigger type at a
time?


That's what I meant. Generally I have objections to the generic
property for defining list of allowed triggers. That's why I proposed
to stay by usb-ports property that would be specific to only one
trigger: led-trigger-usbport.

led-trigger-usbport in fact is an entirely new type of LED trigger.
LED triggers is a kernel based source of events. All existing triggers
react only to a single, well defined source of events, whereas
led-trigger-usbport allows to define the scope of events (usb ports)
to notify about. Activity on each port is treated similarly and the LED
class device that listens to the trigger notifications doesn't know
which exact port triggered the notification.

From this POV led-trigger-usbport is kind of facade, which allows
for it to fit well into the LED Trigger design and API, and usb ports
are not identical with LED triggers, but sit rather one level below.
It is led-trigger-usbport which is visible to the LED subsystem, and
not every single usb port.


So e.g. if one assigns 2 USB ports + network device + CPU and
decides to use "usport" trigger driver he'll get LED indicating status
of USB ports only.


How would it be different from the current state? Only in limiting
the scope of triggers available for a LED class device.


It won't differ from the current state. I just wanted to make it clear
Linux trigger drivers may respect only 

Re: [PATCH 4.10-rc3 12/13] net: ath5k: fix build errors when linux/phy*.h is removed from net/dsa.h

[Kalle Valo]

Russell King  writes:

> Fix these errors reported by the 0-day builder by replacing the
> linux/export.h include with linux/module.h.
>
> In file included from include/linux/platform_device.h:14:0,
>  from drivers/net/wireless/ath/ath5k/ahb.c:20:
> include/linux/device.h:1463:1: warning: data definition has no type or 
> storage class
>  module_init(__driver##_init); \
>  ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 
> 'module_driver'
>   module_driver(__platform_driver, platform_driver_register, \
>   ^
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
> 'module_platform_driver'
>  module_platform_driver(ath_ahb_driver);
>  ^~
> include/linux/device.h:1463:1: error: type defaults to 'int' in declaration 
> of 'module_init' [-Werror=implicit-int]
>  module_init(__driver##_init); \
>  ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 
> 'module_driver'
>   module_driver(__platform_driver, platform_driver_register, \
>   ^
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
> 'module_platform_driver'
>  module_platform_driver(ath_ahb_driver);
>  ^~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without 
> types) in function declaration
> In file included from include/linux/platform_device.h:14:0,
>  from drivers/net/wireless/ath/ath5k/ahb.c:20:
> include/linux/device.h:1468:1: warning: data definition has no type or 
> storage class
>  module_exit(__driver##_exit);
>  ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 
> 'module_driver'
>   module_driver(__platform_driver, platform_driver_register, \
>   ^
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
> 'module_platform_driver'
>  module_platform_driver(ath_ahb_driver);
>  ^~
> include/linux/device.h:1468:1: error: type defaults to 'int' in declaration 
> of 'module_exit' [-Werror=implicit-int]
>  module_exit(__driver##_exit);
>  ^
> include/linux/platform_device.h:228:2: note: in expansion of macro 
> 'module_driver'
>   module_driver(__platform_driver, platform_driver_register, \
>   ^
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
> 'module_platform_driver'
>  module_platform_driver(ath_ahb_driver);
>  ^~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without 
> types) in function declaration
> In file included from include/linux/platform_device.h:14:0,
>  from drivers/net/wireless/ath/ath5k/ahb.c:20:
> drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_exit' 
> defined but not used [-Wunused-function]
>  module_platform_driver(ath_ahb_driver);
> ^
> include/linux/device.h:1464:20: note: in definition of macro 'module_driver'
>  static void __exit __driver##_exit(void) \
> ^~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
> 'module_platform_driver'
>  module_platform_driver(ath_ahb_driver);
>  ^~
> drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_init' 
> defined but not used [-Wunused-function]
>  module_platform_driver(ath_ahb_driver);
> ^
> include/linux/device.h:1459:19: note: in definition of macro 'module_driver'
>  static int __init __driver##_init(void) \
>^~~~
> drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
> 'module_platform_driver'
>  module_platform_driver(ath_ahb_driver);
>  ^~
>
> Signed-off-by: Russell King 

Looks good to me:

Acked-by: Kalle Valo 

I assume Dave will take this so I'll drop the patch from my queue.

-- 
Kalle Valo
--
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 1/5] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

[John Youn]

On 1/31/2017 5:26 PM, Bruno Herrera wrote:
> This patch introduces a new parameter to activate USB OTG HS/FS core
> embedded phy transceiver. The STM32F4x9 SoC uses the GGPIO register
> to enable the transceiver.
> Also add the dwc2_set_params function for stm32f4 otg fs.
>
> Signed-off-by: Bruno Herrera 

Acked-by: John Youn 

Regards,
John


> ---
>  drivers/usb/dwc2/core.h   |  5 +
>  drivers/usb/dwc2/hcd.c| 15 ++-
>  drivers/usb/dwc2/hw.h |  2 ++
>  drivers/usb/dwc2/params.c | 19 +++
>  4 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index b9b62f1..252400b 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -423,6 +423,10 @@ enum dwc2_ep0_state {
>   *   needed.
>   *   0 - No (default)
>   *   1 - Yes
> + * @activate_stm_fs_transceiver: Activate internal transceiver using GGPIO
> + *   register.
> + *   0 - Deactivate the transceiver (default)
> + *   1 - Activate the transceiver
>   * @g_dma:  Enables gadget dma usage (default: autodetect).
>   * @g_dma_desc: Enables gadget descriptor DMA (default: autodetect).
>   * @g_rx_fifo_size:  The periodic rx fifo size for the device, in
> @@ -477,6 +481,7 @@ struct dwc2_core_params {
>   bool uframe_sched;
>   bool external_id_pin_ctl;
>   bool hibernation;
> + bool activate_stm_fs_transceiver;
>   u16 max_packet_count;
>   u32 max_transfer_size;
>   u32 ahbcfg;
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index a73722e..b5a70b6 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -121,7 +121,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg 
> *hsotg)
>
>  static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
>  {
> - u32 usbcfg, i2cctl;
> + u32 usbcfg, ggpio, i2cctl;
>   int retval = 0;
>
>   /*
> @@ -145,6 +145,19 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, 
> bool select_phy)
>   return retval;
>   }
>   }
> +
> + if (hsotg->params.activate_stm_fs_transceiver) {
> + ggpio = dwc2_readl(hsotg->regs + GGPIO);
> + if (!(ggpio & GGPIO_STM32_OTG_GCCFG_PWRDWN)) {
> + dev_dbg(hsotg->dev, "Activating transceiver\n");
> + /*
> +  * STM32F4x9 uses the GGPIO register as general
> +  * core configuration register.
> +  */
> + ggpio |= GGPIO_STM32_OTG_GCCFG_PWRDWN;
> + dwc2_writel(ggpio, hsotg->regs + GGPIO);
> + }
> + }
>   }
>
>   /*
> diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
> index bde7248..4592012 100644
> --- a/drivers/usb/dwc2/hw.h
> +++ b/drivers/usb/dwc2/hw.h
> @@ -225,6 +225,8 @@
>
>  #define GPVNDCTL HSOTG_REG(0x0034)
>  #define GGPIOHSOTG_REG(0x0038)
> +#define GGPIO_STM32_OTG_GCCFG_PWRDWN BIT(16)
> +
>  #define GUID HSOTG_REG(0x003c)
>  #define GSNPSID  HSOTG_REG(0x0040)
>  #define GHWCFG1  HSOTG_REG(0x0044)
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 2990c34..9cd8722 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -120,6 +120,22 @@ static void dwc2_set_amcc_params(struct dwc2_hsotg 
> *hsotg)
>   p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
>  }
>
> +static void dwc2_set_stm32f4x9_fsotg_params(struct dwc2_hsotg *hsotg)
> +{
> + struct dwc2_core_params *p = >params;
> +
> + p->otg_cap = DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE;
> + p->speed = DWC2_SPEED_PARAM_FULL;
> + p->host_rx_fifo_size = 128;
> + p->host_nperio_tx_fifo_size = 96;
> + p->host_perio_tx_fifo_size = 96;
> + p->max_packet_count = 256;
> + p->phy_type = DWC2_PHY_TYPE_PARAM_FS;
> + p->i2c_enable = false;
> + p->uframe_sched = false;
> + p->activate_stm_fs_transceiver = true;
> +}
> +
>  const struct of_device_id dwc2_of_match_table[] = {
>   { .compatible = "brcm,bcm2835-usb", .data = dwc2_set_bcm_params },
>   { .compatible = "hisilicon,hi6220-usb", .data = dwc2_set_his_params  },
> @@ -133,6 +149,9 @@ const struct of_device_id dwc2_of_match_table[] = {
>   { .compatible = "amlogic,meson-gxbb-usb",
> .data = dwc2_set_amlogic_params },
>   { .compatible = "amcc,dwc-otg", .data = dwc2_set_amcc_params },
> + { .compatible = "st,stm32f4x9-fsotg",
> +   .data = dwc2_set_stm32f4x9_fsotg_params },
> + { .compatible = "st,stm32f4x9-hsotg" },

Re: [PATCH 4.10-rc3 00/13] net: dsa: remove unnecessary phy.h include

[Florian Fainelli]

On 01/31/2017 11:17 AM, Russell King - ARM Linux wrote:
> Including phy.h and phy_fixed.h into net/dsa.h causes phy*.h to be an
> unnecessary dependency for quite a large amount of the kernel.  There's
> very little which actually requires definitions from phy.h in net/dsa.h
> - the include itself only wants the declaration of a couple of
> structures and IFNAMSIZ.
> 
> Add linux/if.h for IFNAMSIZ, declarations for the structures, phy.h to
> mv88e6xxx.h as it needs it for phy_interface_t, and remove both phy.h
> and phy_fixed.h from net/dsa.h.
> 
> This patch reduces from around 800 files rebuilt to around 40 - even
> with ccache, the time difference is noticable.
> 
> In order to make this change, several drivers need to be updated to
> include necessary headers that they were picking up through this
> include.  This has resulted in a much larger patch series.
> 
> I'm assuming the 0-day builder has had 24 hours with this series, and
> hasn't reported any further issues with it - the last issue was two
> weeks ago (before I became ill) which I fixed over the last weekend.
> 
> I'm hoping this doesn't conflict with what's already in net-next...

For the entire series:

Acked-by: Florian Fainelli 

Thanks a lot for doing that.

> 
>  arch/mips/cavium-octeon/octeon-platform.c | 4 
>  drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 1 +
>  drivers/net/ethernet/broadcom/bgmac.c | 2 ++
>  drivers/net/ethernet/cadence/macb.h   | 2 ++
>  drivers/net/ethernet/cavium/liquidio/lio_main.c   | 1 +
>  drivers/net/ethernet/cavium/liquidio/lio_vf_main.c| 1 +
>  drivers/net/ethernet/cavium/liquidio/octeon_console.c | 1 +
>  drivers/net/ethernet/freescale/fman/fman_memac.c  | 1 +
>  drivers/net/ethernet/marvell/mvneta.c | 1 +
>  drivers/net/ethernet/qualcomm/emac/emac-sgmii.c   | 1 +
>  drivers/net/usb/lan78xx.c | 1 +
>  drivers/net/wireless/ath/ath5k/ahb.c  | 2 +-
>  drivers/target/iscsi/iscsi_target_login.c | 1 +
>  include/net/dsa.h | 6 --
>  net/core/netprio_cgroup.c | 1 +
>  net/sunrpc/xprtrdma/svc_rdma_backchannel.c| 1 +
>  16 files changed, 20 insertions(+), 7 deletions(-)
> 


-- 
Florian
--
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] fs: configfs: make qw_sign attribute symmetric

[Stefan Agner]

Currently qw_sign requires UTF-8 character to set, but returns UTF-16
when read. This isn't obvious when simply using cat since the null
characters are not visible, but hexdump unveils the true string:

  # echo MSFT100 > os_desc/qw_sign
  # hexdump -C os_desc/qw_sign
    4d 00 53 00 46 00 54 00  31 00 30 00 30 00|M.S.F.T.1.0.0.|

Make qw_sign symmetric by returning an UTF-8 string too. Also follow
common convention and add a new line at the end.

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

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 78c44979dde3..ea1a40f5b23d 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -786,9 +786,13 @@ static ssize_t os_desc_b_vendor_code_store(struct 
config_item *item,
 static ssize_t os_desc_qw_sign_show(struct config_item *item, char *page)
 {
struct gadget_info *gi = os_desc_item_to_gadget_info(item);
+   int res;
 
-   memcpy(page, gi->qw_sign, OS_STRING_QW_SIGN_LEN);
-   return OS_STRING_QW_SIGN_LEN;
+   res = utf16s_to_utf8s((wchar_t *) gi->qw_sign, OS_STRING_QW_SIGN_LEN,
+ UTF16_LITTLE_ENDIAN, page, PAGE_SIZE - 1);
+   page[res++] = '\n';
+
+   return res;
 }
 
 static ssize_t os_desc_qw_sign_store(struct config_item *item, const char 
*page,
-- 
2.11.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 2/2] fs: configfs: use hexadecimal values and new line

[Stefan Agner]

Other unsigned properties return hexadecimal values, follow this
convention when printing b_vendor_code too. Also add newlines to
the OS Descriptor support related properties, like other sysfs
files use.

Signed-off-by: Stefan Agner 
---
 drivers/usb/gadget/configfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index ea1a40f5b23d..8e9adcfff748 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -737,7 +737,7 @@ static inline struct gadget_info 
*os_desc_item_to_gadget_info(
 
 static ssize_t os_desc_use_show(struct config_item *item, char *page)
 {
-   return sprintf(page, "%d",
+   return sprintf(page, "%d\n",
os_desc_item_to_gadget_info(item)->use_os_desc);
 }
 
@@ -761,7 +761,7 @@ static ssize_t os_desc_use_store(struct config_item *item, 
const char *page,
 
 static ssize_t os_desc_b_vendor_code_show(struct config_item *item, char *page)
 {
-   return sprintf(page, "%d",
+   return sprintf(page, "0x%02x\n",
os_desc_item_to_gadget_info(item)->b_vendor_code);
 }
 
@@ -903,7 +903,7 @@ static inline struct usb_os_desc_ext_prop
 
 static ssize_t ext_prop_type_show(struct config_item *item, char *page)
 {
-   return sprintf(page, "%d", to_usb_os_desc_ext_prop(item)->type);
+   return sprintf(page, "%d\n", to_usb_os_desc_ext_prop(item)->type);
 }
 
 static ssize_t ext_prop_type_store(struct config_item *item,
-- 
2.11.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 v5 4/5] ARM: dts: stm32: Enable USB HS in FS mode (embedded phy) on stm32f429-disco

[Bruno Herrera]

This patch enables USB HS working in FS mode on stm32f429-disco
with 5V VBUS enable.

Signed-off-by: Bruno Herrera 
---
 arch/arm/boot/dts/stm32f429-disco.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429-disco.dts 
b/arch/arm/boot/dts/stm32f429-disco.dts
index 7d0415e..216782f 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -88,6 +88,14 @@
gpios = < 0 0>;
};
};
+
+   /* This turns on vbus for otg for host mode (dwc2) */
+   vcc5v_otg: vcc5v-otg-regulator {
+   compatible = "regulator-fixed";
+   gpio = < 4 0>;
+   regulator-name = "vcc5_host1";
+   regulator-always-on;
+   };
 };
 
 _hse {
@@ -99,3 +107,11 @@
pinctrl-names = "default";
status = "okay";
 };
+
+_hs {
+   compatible = "st,stm32f4x9-fsotg";
+   dr_mode = "host";
+   pinctrl-0 = <_fs_pins_b>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
2.10.1 (Apple Git-78)

--
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 3/5] ARM: dts: stm32: Enable USB FS on stm32f469-disco

[Bruno Herrera]

This patch enables USB FS on stm32f469-disco with 5V VBUS enable.

Signed-off-by: Bruno Herrera 
---
 arch/arm/boot/dts/stm32f469-disco.dts | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f469-disco.dts 
b/arch/arm/boot/dts/stm32f469-disco.dts
index 8877c00..3e0a83e 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -68,6 +68,15 @@
soc {
dma-ranges = <0xc000 0x0 0x1000>;
};
+
+   /* This turns on vbus for otg for host mode (dwc2) */
+   vcc5v_otg: vcc5v-otg-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 2 0>;
+   regulator-name = "vcc5_host1";
+   regulator-always-on;
+   };
 };
 
  {
@@ -81,3 +90,10 @@
  {
status = "okay";
 };
+
+_fs {
+   dr_mode = "host";
+   pinctrl-0 = <_fs_pins_a>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
2.10.1 (Apple Git-78)

--
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 5/5] dt-bindings: Document the STM32 USB OTG DWC2 core binding

[Bruno Herrera]

This patch adds the documentation for STM32F4x9 USB OTG FS/HS compatible
strings.

Signed-off-by: Bruno Herrera 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/dwc2.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 6c7c2bce..00bea03 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -14,6 +14,10 @@ Required properties:
   - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 
SoCs;
   - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX 
SoCs;
   - snps,dwc2: A generic DWC2 USB controller with default parameters.
+  - "st,stm32f4x9-fsotg": The DWC2 USB FS/HS controller instance in STM32F4x9 
SoCs
+  configured in FS mode;
+  - "st,stm32f4x9-hsotg": The DWC2 USB HS controller instance in STM32F4x9 SoCs
+  configured in HS mode;
 - reg : Should contain 1 register range (address and length)
 - interrupts : Should contain 1 interrupt
 - clocks: clock provider specifier
-- 
2.10.1 (Apple Git-78)

--
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 1/5] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

[Bruno Herrera]

This patch introduces a new parameter to activate USB OTG HS/FS core
embedded phy transceiver. The STM32F4x9 SoC uses the GGPIO register
to enable the transceiver.
Also add the dwc2_set_params function for stm32f4 otg fs.

Signed-off-by: Bruno Herrera 
---
 drivers/usb/dwc2/core.h   |  5 +
 drivers/usb/dwc2/hcd.c| 15 ++-
 drivers/usb/dwc2/hw.h |  2 ++
 drivers/usb/dwc2/params.c | 19 +++
 4 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index b9b62f1..252400b 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -423,6 +423,10 @@ enum dwc2_ep0_state {
  * needed.
  * 0 - No (default)
  * 1 - Yes
+ * @activate_stm_fs_transceiver: Activate internal transceiver using GGPIO
+ * register.
+ * 0 - Deactivate the transceiver (default)
+ * 1 - Activate the transceiver
  * @g_dma:  Enables gadget dma usage (default: autodetect).
  * @g_dma_desc: Enables gadget descriptor DMA (default: autodetect).
  * @g_rx_fifo_size:The periodic rx fifo size for the device, in
@@ -477,6 +481,7 @@ struct dwc2_core_params {
bool uframe_sched;
bool external_id_pin_ctl;
bool hibernation;
+   bool activate_stm_fs_transceiver;
u16 max_packet_count;
u32 max_transfer_size;
u32 ahbcfg;
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a73722e..b5a70b6 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -121,7 +121,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg 
*hsotg)
 
 static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
 {
-   u32 usbcfg, i2cctl;
+   u32 usbcfg, ggpio, i2cctl;
int retval = 0;
 
/*
@@ -145,6 +145,19 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool 
select_phy)
return retval;
}
}
+
+   if (hsotg->params.activate_stm_fs_transceiver) {
+   ggpio = dwc2_readl(hsotg->regs + GGPIO);
+   if (!(ggpio & GGPIO_STM32_OTG_GCCFG_PWRDWN)) {
+   dev_dbg(hsotg->dev, "Activating transceiver\n");
+   /*
+* STM32F4x9 uses the GGPIO register as general
+* core configuration register.
+*/
+   ggpio |= GGPIO_STM32_OTG_GCCFG_PWRDWN;
+   dwc2_writel(ggpio, hsotg->regs + GGPIO);
+   }
+   }
}
 
/*
diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
index bde7248..4592012 100644
--- a/drivers/usb/dwc2/hw.h
+++ b/drivers/usb/dwc2/hw.h
@@ -225,6 +225,8 @@
 
 #define GPVNDCTL   HSOTG_REG(0x0034)
 #define GGPIO  HSOTG_REG(0x0038)
+#define GGPIO_STM32_OTG_GCCFG_PWRDWN   BIT(16)
+
 #define GUID   HSOTG_REG(0x003c)
 #define GSNPSIDHSOTG_REG(0x0040)
 #define GHWCFG1HSOTG_REG(0x0044)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 2990c34..9cd8722 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -120,6 +120,22 @@ static void dwc2_set_amcc_params(struct dwc2_hsotg *hsotg)
p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
 }
 
+static void dwc2_set_stm32f4x9_fsotg_params(struct dwc2_hsotg *hsotg)
+{
+   struct dwc2_core_params *p = >params;
+
+   p->otg_cap = DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE;
+   p->speed = DWC2_SPEED_PARAM_FULL;
+   p->host_rx_fifo_size = 128;
+   p->host_nperio_tx_fifo_size = 96;
+   p->host_perio_tx_fifo_size = 96;
+   p->max_packet_count = 256;
+   p->phy_type = DWC2_PHY_TYPE_PARAM_FS;
+   p->i2c_enable = false;
+   p->uframe_sched = false;
+   p->activate_stm_fs_transceiver = true;
+}
+
 const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = dwc2_set_bcm_params },
{ .compatible = "hisilicon,hi6220-usb", .data = dwc2_set_his_params  },
@@ -133,6 +149,9 @@ const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "amlogic,meson-gxbb-usb",
  .data = dwc2_set_amlogic_params },
{ .compatible = "amcc,dwc-otg", .data = dwc2_set_amcc_params },
+   { .compatible = "st,stm32f4x9-fsotg",
+ .data = dwc2_set_stm32f4x9_fsotg_params },
+   { .compatible = "st,stm32f4x9-hsotg" },
{},
 };
 MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
-- 
2.10.1 (Apple Git-78)

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

[PATCH v5 2/5] ARM: dts: stm32: Add USB FS support for STM32F429 MCU

[Bruno Herrera]

This patch adds the USB pins and nodes for USB FS core.

Signed-off-by: Bruno Herrera 
---
 arch/arm/boot/dts/stm32f429.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..9afa455 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -316,6 +316,28 @@
};
};
 
+   usbotg_fs_pins_a: usbotg_fs@0 {
+   pins {
+   pinmux = 
,
+
,
+
;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <2>;
+   };
+   };
+
+   usbotg_fs_pins_b: usbotg_fs@1 {
+   pins {
+   pinmux = 
,
+
,
+
;
+   bias-disable;
+   drive-push-pull;
+   slew-rate = <2>;
+   };
+   };
+
usbotg_hs_pins_a: usbotg_hs@0 {
pins {
pinmux = 
,
@@ -420,6 +442,15 @@
status = "disabled";
};
 
+   usbotg_fs: usb@5000 {
+   compatible = "st,stm32f4x9-fsotg";
+   reg = <0x5000 0x4>;
+   interrupts = <67>;
+   clocks = < 0 39>;
+   clock-names = "otg";
+   status = "disabled";
+   };
+
rng: rng@50060800 {
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
-- 
2.10.1 (Apple Git-78)

--
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 0/5] usb: dwc2: Add support for USB OTG on STM32F4x9

[Bruno Herrera]

The STM32F4x9 MCU family has two DWC2 USB OTG cores on it. One core is
USB OTG FS and other core is USB OTG HS. The USB FS core only works with
its internal phy whilst the USF HS core can work in HS with external ulpi
phy or in FS/LS speed with the embedded FS PHY.

The goal of this patch series is to enable the use of USB OTG FS/HS cores
in FS mode using the internal phy.

Changes since v5:
- Fix checkpatch --strict for usb related files
- Changed struct dwc2_core_params param name from activate_transceiver to
activate_stm_fs_transceiver

Changes since v4:
- Rebase on top of repository https://github.com/synopsys-usb/linux
- Changes var names from STM32F4xx to STM32F4x9

Changes since v3:
- Removed commented lines from patch (sent by mistake)
- Split DTS patch by boards and SOC
- Removed unnecessary pinctrl nodes from DTS files

Changes since v2:
- Rename driver variables to meet the driver standard
- Add compatible string for HS core

Changes since v1:
- Add dwc2_core_params structure for stm32f4 otg fs
- Add compatible string for FS core/mode
- Use GGPIO register to deativate power down of the phy

Bruno Herrera (5):
  usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode
(internal PHY)
  ARM: dts: stm32: Add USB FS support for STM32F429 MCU
  ARM: dts: stm32: Enable USB FS on stm32f469-disco
  ARM: dts: stm32: Enable USB HS in FS mode (embedded phy) on
stm32f429-disco
  dt-bindings: Document the STM32 USB OTG DWC2 core binding

 Documentation/devicetree/bindings/usb/dwc2.txt |  4 
 arch/arm/boot/dts/stm32f429-disco.dts  | 16 +
 arch/arm/boot/dts/stm32f429.dtsi   | 31 ++
 arch/arm/boot/dts/stm32f469-disco.dts  | 16 +
 drivers/usb/dwc2/core.h|  5 +
 drivers/usb/dwc2/hcd.c | 15 -
 drivers/usb/dwc2/hw.h  |  2 ++
 drivers/usb/dwc2/params.c  | 19 
 8 files changed, 107 insertions(+), 1 deletion(-)

-- 
2.10.1 (Apple Git-78)

--
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/8] power: add power sequence library

[Rafael J. Wysocki]

On Tue, Jan 3, 2017 at 7:33 AM, Peter Chen  wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices. The pwrseq
> librares always need to allocate extra instance for compatible
> string match.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover other controls in
> future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> For new power sequence library, it can add its compatible string
> to pwrseq_of_match_table, then the pwrseq core will match it with
> DT's, and choose this library at runtime.
>
> Signed-off-by: Peter Chen 
> Tested-by: Maciej S. Szmigiero 
> Tested-by Joshua Clayton 
> Reviewed-by: Matthias Kaehlcke 
> Tested-by: Matthias Kaehlcke 

Quite honestly, I have a really hard time with trying to follow this
code and the total lack of documentation makes it even harder.  In
particular, the generic power sequence code is not even commented at
all, so it really is hard to say how this is going to work, let alone
deciding whether or not to apply it.

Plus, of course, the USB core changes must be acked by the maintainer
thereof for me to be able to handle the series.

But at this point I basically need you to explain the design to me, please.

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

Re: [PATCH] r8152: Allocate interrupt buffer as part of struct r8152

[Guenter Roeck]

On Tue, Jan 31, 2017 at 02:53:47PM -0500, Alan Stern wrote:
> On Tue, 31 Jan 2017, Guenter Roeck wrote:
> 
> > When unloading the r8152 driver using the 'unbind' sysfs attribute
> > in a system with KASAN enabled, the following error message is seen
> > on a regular basis.
> 
> ...
> 
> > The two-byte allocation in conjunction with code analysis suggests that
> > the interrupt buffer has been overwritten. Added instrumentation in the
> > driver shows that the interrupt handler is called after RTL8152_UNPLUG
> > was set, and that this event is associated with the error message above.
> > This suggests that there are situations where the interrupt buffer is used
> > after it has been freed.
> > 
> > To avoid the problem, allocate the interrupt buffer as part of struct
> > r8152.
> > 
> > Cc: Hayes Wang 
> > Signed-off-by: Guenter Roeck 
> > ---
> > The problem is seen in chromeos-4.4, but there is not reason to believe
> > that it does not occur with the upstream kernel. It is still seen in
> > chromeos-4.4 after all patches from upstream and linux-next have been
> > applied to the driver.
> > 
> > While relatively simple, I am not really convinced that this is the best
> > (or even an acceptable) solution for this problem. I am open to suggestions
> > for a better fix.
> 
> The proper approach is to keep the allocation as it is, but _before_
> deallocating the buffer, make sure that the interrupt buffer won't be
> accessed any more.  This may involve calling usb_kill_urb(), or

usb_kill_urb() is called. I added some more logging. The sequence is
interrupt_handler()
...
usb_kill_urb(intr_urb);
...
kfree(intr_buff);
...
BUG kmalloc-128

which leaves me a bit puzzled; the interrupt handler is called well before
the memory is freed, and it turns out that it is not always called.

I'll do some digging in the usb core.

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: [PATCH] r8152: Allocate interrupt buffer as part of struct r8152

[Guenter Roeck]

On Tue, Jan 31, 2017 at 11:53:31AM -0800, Eric Dumazet wrote:
> On Tue, 2017-01-31 at 11:06 -0800, Guenter Roeck wrote:
> > When unloading the r8152 driver using the 'unbind' sysfs attribute
> > in a system with KASAN enabled, the following error message is seen
> > on a regular basis.
> 
> >  
> >  static int alloc_all_mem(struct r8152 *tp)
> > @@ -1423,10 +1420,6 @@ static int alloc_all_mem(struct r8152 *tp)
> > if (!tp->intr_urb)
> > goto err1;
> >  
> > -   tp->intr_buff = kmalloc(INTBUFSIZE, GFP_KERNEL);
> > -   if (!tp->intr_buff)
> > -   goto err1;
> > -
> > tp->intr_interval = (int)ep_intr->desc.bInterval;
> > usb_fill_int_urb(tp->intr_urb, tp->udev, usb_rcvintpipe(tp->udev, 3),
> >  tp->intr_buff, INTBUFSIZE, intr_callback,
> 
> This might lead to intr_buff being backed by vzalloc() instead of
> kzalloc() (check alloc_netdev_mqs())
> 
> It looks like it could cause a bug.
> 
I also strongly suspect that it just fixes the symptom, but not the root cause
of the problem.

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: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Jacek Anaszewski]

Hi Rafał,

On 01/31/2017 05:11 PM, Rafał Miłecki wrote:
> On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:
>> On 01/25/2017 10:03 AM, Rafał Miłecki wrote:
>>> On 21 January 2017 at 22:42, Jacek Anaszewski
>>>  wrote:
 On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
> On 20 January 2017 at 23:35, Jacek Anaszewski
>  wrote:
>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
>>> From: Rafał Miłecki 
>>>
>>> Some LEDs can be related to particular devices described in DT. This
>>> property allows specifying such relations. E.g. USB LED should
>>> usually
>>> be used to indicate some USB port(s) state.
>>>
>>> Signed-off-by: Rafał Miłecki 
>>> ---
>>> V2: Replace "usb-ports" with "led-triggers" property which is
>>> more generic and
>>> allows specifying other devices as well.
>>>
>>> When bindings patch is related to some followup implementation,
>>> they usually go
>>> through the same tree.
>>>
>>> Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds:
>>> Improve examples by
>>> adding some context") from kernel/git/j.anaszewski/linux-leds.git
>>> . Is there any
>>> way to solve this dependency issue? Or should this patch wait
>>> until 3.11 is
>>> released?
>>> ---
>>>  Documentation/devicetree/bindings/leds/common.txt | 16
>>> 
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/common.txt
>>> b/Documentation/devicetree/bindings/leds/common.txt
>>> index 24b656014089..17632a041196 100644
>>> --- a/Documentation/devicetree/bindings/leds/common.txt
>>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>>> @@ -49,6 +49,17 @@ Optional properties for child nodes:
>>>  - panic-indicator : This property specifies that the LED should
>>> be used,
>>>   if at all possible, as a panic indicator.
>>>
>>> +- led-triggers : List of devices that should trigger this LED
>>> activity. Some
>>> +  LEDs can be related to a specific device and
>>> should somehow
>>> +  indicate its state. E.g. USB 2.0 LED may react to
>>> device(s) in
>>> +  a USB 2.0 port(s). Another common example is
>>> switch or router
>>> +  with multiple Ethernet ports each of them having
>>> its own LED
>>> +  assigned (assuminled-trigger-usbportg they are not
>>> hardwired).
>>> +  In such cases this property should contain
>>> phandle(s) of
>>> +  related device(s). In many cases LED can be
>>> related to more
>>> +  than one device (e.g. one USB LED vs. multiple USB
>>> ports) so a
>>> +  list of entries can be specified.
>>> +
>>
>> This implies that it is possible to define multiple triggers for
>> a LED class device but it is not supported by LED Trigger core.
>> There is linux,default-trigger property which allows to define one
>> trigger that will be initially assigned.

> With proposed "led-triggers" property one could assign different
> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
> device & CPU to a single LED. For reason explained above Linux
> couldn't support all of them at once.
>
>
>> I am aware that this is renamed usb-ports property from v1,
>> that attempts to address Rob's comment, but we can't do that this
>> way.
>> Maybe usb-ports property could be documented in led-trigger-usbport's
>> specific bindings and a reference to it could be added next to the
>> related entry on the list of the available LED triggers (which is
>> actually missing) in
>> Documentation/devicetree/bindings/leds/common.txt.
>
> I'm wondering if we need to care about this Linux limitation and if it
> should stop us from adding this flexible DT property. Maybe we could
> live with Linux having limitation of supporting one trigger type at a
> time?

 That's what I meant. Generally I have objections to the generic
 property for defining list of allowed triggers. That's why I proposed
 to stay by usb-ports property that would be specific to only one
 trigger: led-trigger-usbport.

 led-trigger-usbport in fact is an entirely new type of LED trigger.
 LED triggers is a kernel based source of events. All existing triggers
 react only to a single, well defined source of events, whereas
 led-trigger-usbport allows to define the scope of events (usb ports)
 to notify about. Activity on each port is treated similarly and the LED
 class device that listens to the trigger notifications doesn't know
 which exact port triggered the notification.

 From this 

[PATCH v3 0/2] Work-around for DWC_USB3_NUM_EPS = DWC_USB3_NUM_IN_EPS

[Bryan O'Donoghue]

This is V3 of the previous patchset. This version implements the suggested
change from Felipe to rationalise num_in_eps and num_out_eps down to
num_eps directly. The old mapping of OUT/IN endpoint pairs is maintained to
ensure that fixed-mapped endpoints - as is possible on some FPGA
configurations, will continue to be accommodated while at the same time we
cover the case where DWC3_USB3_NUM_EPS == DWC3_USB3_NUM_IN_EPS.

V2 -> V3:
Rationalise num_in_eps and num_out_eps to num_eps - Felipe
Remove unnecessary function dwc3_gadget_init_hw_endpoints - Bryan

V1 -> V2:
Removed quirk code - Felipe
Reworded commit log - Felipe
Removed DT bindings no long necessary

Bryan O'Donoghue (2):
  usb: dwc3: refactor gadget endpoint count calculation
  usb: dwc3: remove dwc3_gadget_init_hw_endpoints

 drivers/usb/dwc3/core.c|  3 +--
 drivers/usb/dwc3/core.h|  6 ++
 drivers/usb/dwc3/debugfs.c | 15 ++-
 drivers/usb/dwc3/gadget.c  | 47 ++
 4 files changed, 19 insertions(+), 52 deletions(-)

-- 
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 v3 1/2] usb: dwc3: refactor gadget endpoint count calculation

[Bryan O'Donoghue]

- DWC_USB3_NUM indicates the number of Device mode single directional
  endpoints, including OUT and IN endpoint 0.

- DWC_USB3_NUM_IN_EPS indicates the maximum number of Device mode IN
  endpoints active at any time, including control endpoint 0.

It's possible to configure RTL such that DWC_USB3_NUM_EPS is equal to
DWC_USB3_NUM_IN_EPS.

dwc3-core calculates the number of OUT endpoints as DWC_USB3_NUM minus
DWC_USB3_NUM_IN_EPS. If RTL has been configured with DWC_USB3_NUM_IN_EPS
equal to DWC_USB3_NUM then dwc3-core will calculate the number of OUT
endpoints as zero.

For example a from dwc3_core_num_eps() shows:
[1.565000]  /usb0@f01d: found 8 IN and 0 OUT endpoints

This patch refactors the endpoint calculation down to one variable
dwc->num_eps taking care to maintain the current mapping of endpoints for
fixed FPGA configurations as described in Table 4-7 of version 2.60a of the
DWC USB3 databook.

The endpoint mapping will then be EP-OUT, EP-IN etc, up to DWC_USB3_NUM.
If DWC_USB3_NUM is odd then OUT will take the extra endpoint.

Suggested-by: Felipe Balbi 
Signed-off-by: Bryan O'Donoghue 
---
 drivers/usb/dwc3/core.c|  3 +--
 drivers/usb/dwc3/core.h|  6 ++
 drivers/usb/dwc3/debugfs.c | 15 ++-
 drivers/usb/dwc3/gadget.c  | 36 +++-
 4 files changed, 16 insertions(+), 44 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 369bab1..68c9c84 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -397,8 +397,7 @@ static void dwc3_core_num_eps(struct dwc3 *dwc)
 {
struct dwc3_hwparams*parms = >hwparams;
 
-   dwc->num_in_eps = DWC3_NUM_IN_EPS(parms);
-   dwc->num_out_eps = DWC3_NUM_EPS(parms) - dwc->num_in_eps;
+   dwc->num_eps = DWC3_NUM_EPS(parms);
 }
 
 static void dwc3_cache_hwparams(struct dwc3 *dwc)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2b9e4ca..d496ddc 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -799,8 +799,7 @@ struct dwc3_scratchpad_array {
  * @u2pel: parameter from Set SEL request.
  * @u1sel: parameter from Set SEL request.
  * @u1pel: parameter from Set SEL request.
- * @num_out_eps: number of out endpoints
- * @num_in_eps: number of in endpoints
+ * @num_eps: number of endpoints
  * @ep0_next_event: hold the next expected event
  * @ep0state: state of endpoint zero
  * @link_state: link state
@@ -960,8 +959,7 @@ struct dwc3 {
 
u8  speed;
 
-   u8  num_out_eps;
-   u8  num_in_eps;
+   u8  num_eps;
 
struct dwc3_hwparamshwparams;
struct dentry   *root;
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 31926dd..7df4541 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -822,19 +822,8 @@ static void dwc3_debugfs_create_endpoint_dirs(struct dwc3 
*dwc,
 {
int i;
 
-   for (i = 0; i < dwc->num_in_eps; i++) {
-   u8  epnum = (i << 1) | 1;
-   struct dwc3_ep  *dep = dwc->eps[epnum];
-
-   if (!dep)
-   continue;
-
-   dwc3_debugfs_create_endpoint_dir(dep, parent);
-   }
-
-   for (i = 0; i < dwc->num_out_eps; i++) {
-   u8  epnum = (i << 1);
-   struct dwc3_ep  *dep = dwc->eps[epnum];
+   for (i = 0; i < dwc->num_eps; i++) {
+   struct dwc3_ep  *dep = dwc->eps[i];
 
if (!dep)
continue;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 4db97ec..ef86ab6 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1930,14 +1930,13 @@ static const struct usb_gadget_ops dwc3_gadget_ops = {
 
 /* -- 
*/
 
-static int dwc3_gadget_init_hw_endpoints(struct dwc3 *dwc,
-   u8 num, u32 direction)
+static int dwc3_gadget_init_hw_endpoints(struct dwc3 *dwc, u8 num)
 {
struct dwc3_ep  *dep;
-   u8  i;
+   u8  epnum;
+   booldirection = false;
 
-   for (i = 0; i < num; i++) {
-   u8 epnum = (i << 1) | (direction ? 1 : 0);
+   for (epnum = 0; epnum < num; epnum++) {
 
dep = kzalloc(sizeof(*dep), GFP_KERNEL);
if (!dep)
@@ -1945,12 +1944,12 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 
*dwc,
 
dep->dwc = dwc;
dep->number = epnum;
-   dep->direction = !!direction;
+   dep->direction = direction;
dep->regs = dwc->regs + DWC3_DEP_BASE(epnum);
dwc->eps[epnum] = dep;
 
-   snprintf(dep->name, sizeof(dep->name), 

[PATCH v3 2/2] usb: dwc3: remove dwc3_gadget_init_hw_endpoints

[Bryan O'Donoghue]

A previous patch in the series reduces the number of  callsites of
dwc3_gadget_init_hw_endpoints from two to one. This patch removes the
redundant step of wrappering one function in the other, which can be done
by adding a parameter to dwc3_gadget_init_endpoints and moving the
linked-list initialization of dwc->gadet.ep_list.

Signed-off-by: Bryan O'Donoghue 
---
 drivers/usb/dwc3/gadget.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index ef86ab6..574d795 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1930,12 +1930,14 @@ static const struct usb_gadget_ops dwc3_gadget_ops = {
 
 /* -- 
*/
 
-static int dwc3_gadget_init_hw_endpoints(struct dwc3 *dwc, u8 num)
+static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, u8 num)
 {
struct dwc3_ep  *dep;
u8  epnum;
booldirection = false;
 
+   INIT_LIST_HEAD(>gadget.ep_list);
+
for (epnum = 0; epnum < num; epnum++) {
 
dep = kzalloc(sizeof(*dep), GFP_KERNEL);
@@ -2037,13 +2039,6 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 
*dwc, u8 num)
return 0;
 }
 
-static int dwc3_gadget_init_endpoints(struct dwc3 *dwc)
-{
-   INIT_LIST_HEAD(>gadget.ep_list);
-
-   return dwc3_gadget_init_hw_endpoints(dwc, dwc->num_eps);
-}
-
 static void dwc3_gadget_free_endpoints(struct dwc3 *dwc)
 {
struct dwc3_ep  *dep;
@@ -3151,7 +3146,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
 * sure we're starting from a well known location.
 */
 
-   ret = dwc3_gadget_init_endpoints(dwc);
+   ret = dwc3_gadget_init_endpoints(dwc, dwc->num_eps);
if (ret)
goto err6;
 
-- 
2.7.4

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

Re: [PATCH v3 0/2] Work-around for DWC_USB3_NUM_EPS = DWC_USB3_NUM_IN_EPS

[Bryan O'Donoghue]

On 31/01/17 20:58, Bryan O'Donoghue wrote:

This is V3 of the previous patchset. This version implements the suggested
change from Felipe to rationalise num_in_eps and num_out_eps down to
num_eps directly. The old mapping of OUT/IN endpoint pairs is maintained to
ensure that fixed-mapped endpoints - as is possible on some FPGA
configurations, will continue to be accommodated while at the same time we
cover the case where DWC3_USB3_NUM_EPS == DWC3_USB3_NUM_IN_EPS.

V2 -> V3:
Rationalise num_in_eps and num_out_eps to num_eps - Felipe
Remove unnecessary function dwc3_gadget_init_hw_endpoints - Bryan

V1 -> V2:
Removed quirk code - Felipe
Reworded commit log - Felipe
Removed DT bindings no long necessary

Bryan O'Donoghue (2):
  usb: dwc3: refactor gadget endpoint count calculation
  usb: dwc3: remove dwc3_gadget_init_hw_endpoints

 drivers/usb/dwc3/core.c|  3 +--
 drivers/usb/dwc3/core.h|  6 ++
 drivers/usb/dwc3/debugfs.c | 15 ++-
 drivers/usb/dwc3/gadget.c  | 47 ++
 4 files changed, 19 insertions(+), 52 deletions(-)




+john.y...@synopsys.com

Sorry for messing up your email address (again) John - I'm terminally 
bad at spelling Synopsys

--
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 4.10-rc3 08/13] net: emac: fix build errors when linux/phy*.h is removed from net/dsa.h

[Timur Tabi]

On 01/31/2017 01:19 PM, Russell King wrote:

drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:58:12: error: dereferencing 
pointer to incomplete type 'struct phy_device'

Add linux/phy.h to emac-sgmii.c

Signed-off-by: Russell King 
---
 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 1 +


The version of emac-sgmii.c on net-next does not need this fixed.  I already 
removed all references to phy_device in commit "net: qcom/emac: always use 
autonegotiation to configure the SGMII link".


--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

[Heiner Kallweit]

Am 31.01.2017 um 20:23 schrieb Heiner Kallweit:
> Am 31.01.2017 um 19:48 schrieb John Youn:
>> On 1/30/2017 11:13 PM, Heiner Kallweit wrote:
>>> Am 31.01.2017 um 03:32 schrieb John Youn:
 On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
> Supplies for vusb_a and vusb_d are needed only on a minority of systems
> supported by the dwc2 driver (AFAIK systems with Samsung SoCs).
>
> On all other systems this results in these harmless but annoying
> warnings:
>
> c900.usb supply vusb_d not found, using dummy regulator
> c900.usb supply vusb_a not found, using dummy regulator
>
> Introduce a configuration parameter to ignore the supplies on
> systems not needing it.

 You can probably just check for the existence of those bindings. Or
 possibly use devm_regulator_get_optional().

>>> Right, that we could do to silence the warning. But then we would
>>> loose the warning on systems where these supplies are mandatory
>>> (in case somebody adds a system with such a SoC and forgets to define
>>> the supplies in the DT).
>>
>> I don't think the dwc2 driver should be doing that though. It should
>> treat these as optional properties and use them if available, just
>> like it does now for the reset control, phy, clocks, etc. Otherwise
>> you could make the case for adding the same flag for these other
>> components as well.
>>
>> But really, I just don't want to add new parameters, if anything I
>> want to remove more of them.
>>
> I see. Then most likely it's best to switch to
> devm_regulator_get_optional. I'll send a patch for it.
> 
Hmm, I just see that devm_regulator_bulk_get is used. And there's
no bulk function for optional regulators (yet).

> Heiner
> 
>> Regards,
>> John
>>
> 

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

Re: [PATCH] r8152: Allocate interrupt buffer as part of struct r8152

[Alan Stern]

On Tue, 31 Jan 2017, Guenter Roeck wrote:

> When unloading the r8152 driver using the 'unbind' sysfs attribute
> in a system with KASAN enabled, the following error message is seen
> on a regular basis.

...

> The two-byte allocation in conjunction with code analysis suggests that
> the interrupt buffer has been overwritten. Added instrumentation in the
> driver shows that the interrupt handler is called after RTL8152_UNPLUG
> was set, and that this event is associated with the error message above.
> This suggests that there are situations where the interrupt buffer is used
> after it has been freed.
> 
> To avoid the problem, allocate the interrupt buffer as part of struct
> r8152.
> 
> Cc: Hayes Wang 
> Signed-off-by: Guenter Roeck 
> ---
> The problem is seen in chromeos-4.4, but there is not reason to believe
> that it does not occur with the upstream kernel. It is still seen in
> chromeos-4.4 after all patches from upstream and linux-next have been
> applied to the driver.
> 
> While relatively simple, I am not really convinced that this is the best
> (or even an acceptable) solution for this problem. I am open to suggestions
> for a better fix.

The proper approach is to keep the allocation as it is, but _before_
deallocating the buffer, make sure that the interrupt buffer won't be
accessed any more.  This may involve calling usb_kill_urb(), or
synchronize_irq(), or something similar.

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] r8152: Allocate interrupt buffer as part of struct r8152

[Eric Dumazet]

On Tue, 2017-01-31 at 11:06 -0800, Guenter Roeck wrote:
> When unloading the r8152 driver using the 'unbind' sysfs attribute
> in a system with KASAN enabled, the following error message is seen
> on a regular basis.

>  
>  static int alloc_all_mem(struct r8152 *tp)
> @@ -1423,10 +1420,6 @@ static int alloc_all_mem(struct r8152 *tp)
>   if (!tp->intr_urb)
>   goto err1;
>  
> - tp->intr_buff = kmalloc(INTBUFSIZE, GFP_KERNEL);
> - if (!tp->intr_buff)
> - goto err1;
> -
>   tp->intr_interval = (int)ep_intr->desc.bInterval;
>   usb_fill_int_urb(tp->intr_urb, tp->udev, usb_rcvintpipe(tp->udev, 3),
>tp->intr_buff, INTBUFSIZE, intr_callback,

This might lead to intr_buff being backed by vzalloc() instead of
kzalloc() (check alloc_netdev_mqs())

It looks like it could cause a bug.



--
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: linux USB dwc3 not working

[andy_purcell]

Felipe, 

> okay, good. RUN/STOP bit is set. So it still doesn't work? The only thing I 
> can
> think of, is that VBUS_VALID bit in the Mux register isn't set properly. I'm 
> not in
> the office now, but I'll try to get you more info on that.
> 

OK, I have no information about a VBUS_VALID bit or the "Mux" register. 


> In my SKL boards, however, that bit is always enabled. This means that
> DWC3 works, but when I unplug cable, I don't see a disconnect interrupt
> ;-)
> 
> What you really need to make this work properly, is some way of sampling VBUS
> level and, whenever it's above 4.4V, then set VBUS_VALID bit in
> DRCFG0 register. This is the best way to have this always working. Ideally it
> would be hidden by the BIOS, so you wouldn't have to care about it :-s

I hooked up a scope to VBUS. It is 5 volts. 
I have no information about the DRCFG0 register.
Any help here is greatly appreciated... 

Andy Purcell

> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Tuesday, January 31, 2017 12:05 PM
> To: PURCELL,ANDY (K-Loveland,ex1) ; linux-
> u...@vger.kernel.org
> Subject: RE: linux USB dwc3 not working
> 
> 
> Hi Andy,
> 
> andy_purc...@keysight.com writes:
> > 00:14.1 USB controller: Intel Corporation Sunrise Point-H USB Device
> > Controller (OTG) (rev 31)
> 
> okay, this is dwc3. Good
> 
> >> I need to ask you to try a newer kernel. Can you try v4.9.6 or v4.10-rc6?
> >>
> >
> > I am now running Ubuntu 4.10.0-999-generic.
> > Same results - USB device not working, test modes still not working.
> 
> okay
> 
> >> > Using a script, I set up the USB-device to be RNDIS, using functionfs.
> >>
> >> functionfs needs a userspace component, do you have that? Can you try
> >> any other gadget driver like mass storage, for instance? Here's a
> >> quick script for mass storage:
> >>
> >> #!/bin/sh
> >>
> >> dd if=/dev/zero of=/dev/shm/file bs=1M count=1024
> >>
> >> mount -t configfs none /c
> >> mkdir /c/usb_gadget/g1
> >> echo 0x18d1 > /c/usb_gadget/g1/idVendor echo 0xbeef >
> >> /c/usb_gadget/g1/idProduct mkdir
> >> /c/usb_gadget/g1/strings/0x409 echo 123456789012 >
> >> /c/usb_gadget/g1/strings/0x409/serialnumber
> >> echo "Intel Corporation" >
> >> /c/usb_gadget/g1/strings/0x409/manufacturer
> >> echo "Joule" > /c/usb_gadget/g1/strings/0x409/product
> >> mkdir /c/usb_gadget/g1/functions/mass_storage.1
> >> mkdir /c/usb_gadget/g1/configs/b.1
> >> mkdir /c/usb_gadget/g1/configs/b.1/strings/0x409
> >> echo 500 > /c/usb_gadget/g1/configs/b.1/MaxPower
> >> echo /dev/shm/file >
> >> /c/usb_gadget/g1/functions/mass_storage.1/lun.0/file
> >> ln -s /c/usb_gadget/g1/functions/mass_storage.1
> >> /c/usb_gadget/g1/configs/b.1/f1 echo dwc3.0.auto >
> >> /c/usb_gadget/g1/UDC
> >>
> >
> > I run this script, slightly modified, as you suggested.
> > After running this script, I see these 2 lines added to the dmesg output:
> > [   93.096773] Mass Storage Function, version: 2009/09/11
> > [   93.096777] LUN: removable file: (no medium)
> 
> alright, mass storage loaded and available.
> 
> >> > I connect a USB cable from my board to a USB-host.
> >> > My USB analyzer shows nothing happens. No connection, no SETUP
> >> > packets, nothing.
> >>
> >> right, I'm assuming you don't have userspace component for
> >> functionfs, so -
> >> >pullup() is never called.
> >>
> >
> > What is the userspace component for functionfs, given that I am setting up
> mass storage?
> > How do I get it for Ubuntu 4.10.0-999-generic?
> 
> now that you're using mass storage, you don't need anything else ;-)
> 
> >> Can you also get the output of:
> >>
> >> grep DCTL regdump
> >
> > root@apub1:/sys/kernel/debug/dwc3.0.auto# grep DCTL regdump DCTL =
> > 0x80f0
> 
> okay, good. RUN/STOP bit is set. So it still doesn't work? The only thing I 
> can
> think of, is that VBUS_VALID bit in the Mux register isn't set properly. I'm 
> not in
> the office now, but I'll try to get you more info on that.
> 
> In my SKL boards, however, that bit is always enabled. This means that
> DWC3 works, but when I unplug cable, I don't see a disconnect interrupt
> ;-)
> 
> What you really need to make this work properly, is some way of sampling VBUS
> level and, whenever it's above 4.4V, then set VBUS_VALID bit in
> DRCFG0 register. This is the best way to have this always working. Ideally it
> would be hidden by the BIOS, so you wouldn't have to care about it :-s
> 
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/5] usb: dwc2: Add support for STM32F429/439/469 USB OTG HS/FS in FS mode (internal PHY)

[John Youn]

On 1/28/2017 6:21 PM, Bruno Herrera wrote:
> This patch introduces a new parameter to activate USB OTG HS/FS core embedded
> phy transceiver. The STM32F4x9 SoC uses the GGPIO register to enable the 
> transceiver.
> Also add the dwc2_core_params structure for stm32f4 otg fs.
>
> Signed-off-by: Bruno Herrera 
> ---
>  drivers/usb/dwc2/core.h   |  4 
>  drivers/usb/dwc2/hcd.c| 13 -
>  drivers/usb/dwc2/hw.h |  2 ++
>  drivers/usb/dwc2/params.c | 20 
>  4 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index b9b62f1..ed8ce42 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -423,6 +423,9 @@ enum dwc2_ep0_state {
>   *   needed.
>   *   0 - No (default)
>   *   1 - Yes
> + * @activate_transceiver: Activate internal transceiver using GGPIO register.
> + *   0 - Deactivate the transceiver (default)
> + *   1 - Activate the transceiver
>   * @g_dma:  Enables gadget dma usage (default: autodetect).
>   * @g_dma_desc: Enables gadget descriptor DMA (default: autodetect).
>   * @g_rx_fifo_size:  The periodic rx fifo size for the device, in
> @@ -477,6 +480,7 @@ struct dwc2_core_params {
>   bool uframe_sched;
>   bool external_id_pin_ctl;
>   bool hibernation;
> + bool activate_transceiver;

Seeing as this is very specific to the STM FS platform using a GGPIO
register bit that only exists for it, maybe call it something like:

activate_stm_fs_transceiver


>   u16 max_packet_count;
>   u32 max_transfer_size;
>   u32 ahbcfg;
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index a73722e..190a441 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -121,7 +121,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg 
> *hsotg)
>
>  static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
>  {
> - u32 usbcfg, i2cctl;
> + u32 usbcfg, ggpio, i2cctl;
>   int retval = 0;
>
>   /*
> @@ -145,6 +145,17 @@ static int dwc2_fs_phy_init(struct dwc2_hsotg *hsotg, 
> bool select_phy)
>   return retval;
>   }
>   }
> +
> + ggpio = dwc2_readl(hsotg->regs + GGPIO);
> + if (!(ggpio & GGPIO_STM32_OTG_GCCFG_PWRDWN) &&
> + (hsotg->params.activate_transceiver > 0)) {

This is bool so no need to check > 0.

> + dev_dbg(hsotg->dev, "Activating transceiver\n");
> + /* STM32F4x9 uses the GGPIO register as general core

Use '/*' by itself to start multi-line comments.

> +  * configuration register.
> +  */
> + ggpio |= GGPIO_STM32_OTG_GCCFG_PWRDWN;
> + dwc2_writel(ggpio, hsotg->regs + GGPIO);
> + }

Make this whole block conditional on the parameter.

>   }
>
>   /*
> diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
> index bde7248..9b432c1 100644
> --- a/drivers/usb/dwc2/hw.h
> +++ b/drivers/usb/dwc2/hw.h
> @@ -225,6 +225,8 @@
>
>  #define GPVNDCTL HSOTG_REG(0x0034)
>  #define GGPIOHSOTG_REG(0x0038)
> +#define GGPIO_STM32_OTG_GCCFG_PWRDWN (1 << 16)
> +

Use BIT macro

>  #define GUID HSOTG_REG(0x003c)
>  #define GSNPSID  HSOTG_REG(0x0040)
>  #define GHWCFG1  HSOTG_REG(0x0044)
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 2990c34..a35abba 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -120,6 +120,23 @@ static void dwc2_set_amcc_params(struct dwc2_hsotg 
> *hsotg)
>   p->ahbcfg = GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT;
>  }
>
> +static void dwc2_set_stm32f4x9_fsotg_params(struct dwc2_hsotg *hsotg)
> +{
> + struct dwc2_core_params *p = >params;
> +
> + p->otg_cap = DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE;
> + p->speed = DWC2_SPEED_PARAM_FULL;
> + p->host_rx_fifo_size = 128;
> + p->host_nperio_tx_fifo_size = 96;
> + p->host_perio_tx_fifo_size = 96;
> + p->max_packet_count = 256;
> + p->phy_type = DWC2_PHY_TYPE_PARAM_FS;
> + p->i2c_enable = false;
> + p->uframe_sched = false;
> + p->activate_transceiver = true;
> +

Remove newline

[snip]

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

Re: [PATCH 4.10-rc3 01/13] net: sunrpc: fix build errors when linux/phy*.h is removed from net/dsa.h

[Anna Schumaker]

Hi Russell,

On 01/31/2017 02:18 PM, Russell King wrote:
> Removing linux/phy.h from net/dsa.h reveals a build error in the sunrpc
> code:
> 
> net/sunrpc/xprtrdma/svc_rdma_backchannel.c: In function 'xprt_rdma_bc_put':
> net/sunrpc/xprtrdma/svc_rdma_backchannel.c:277:2: error: implicit declaration 
> of function 'module_put' [-Werror=implicit-function-declaration]
> net/sunrpc/xprtrdma/svc_rdma_backchannel.c: In function 'xprt_setup_rdma_bc':
> net/sunrpc/xprtrdma/svc_rdma_backchannel.c:348:7: error: implicit declaration 
> of function 'try_module_get' [-Werror=implicit-function-declaration]
> 
> Fix this by adding linux/module.h to svc_rdma_backchannel.c
> 
> Signed-off-by: Russell King 

This patch looks okay to me:

Acked-by: Anna Schumaker 

> ---
>  net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c 
> b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
> index 288e35c2d8f4..cb1e48e54eb1 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
> @@ -4,6 +4,7 @@
>   * Support for backward direction RPCs on RPC/RDMA (server-side).
>   */
>  
> +#include 
>  #include 
>  #include "xprt_rdma.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: [PATCH 4.10-rc3 09/13] iscsi: fix build errors when linux/phy*.h is removed from net/dsa.h

[Bart Van Assche]

On Tue, 2017-01-31 at 19:19 +, Russell King wrote:
> drivers/target/iscsi/iscsi_target_login.c:1135:7: error: implicit declaration 
> of function 'try_module_get' [-Werror=implicit-function-declaration]
> 
> Add linux/module.h to iscsi_target_login.c.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/target/iscsi/iscsi_target_login.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/target/iscsi/iscsi_target_login.c 
> b/drivers/target/iscsi/iscsi_target_login.c
> index 450f51deb2a2..eab274d17b5c 100644
> --- a/drivers/target/iscsi/iscsi_target_login.c
> +++ b/drivers/target/iscsi/iscsi_target_login.c
> @@ -17,6 +17,7 @@
>   
> **/
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 

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

[PATCH 4.10-rc3 02/13] net: cgroups: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

net/core/netprio_cgroup.c:303:16: error: expected declaration specifiers or 
'...' before string constant
MODULE_LICENSE("GPL v2");
   ^~~~

Add linux/module.h to fix this.

Signed-off-by: Russell King 
---
 net/core/netprio_cgroup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 2ec86fc552df..756637dc7a57 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
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 4.10-rc3 05/13] net: bgmac: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/ethernet/broadcom/bgmac.c:1015:17: error: dereferencing pointer to 
incomplete type 'struct mii_bus'
drivers/net/ethernet/broadcom/bgmac.c:1185:2: error: implicit declaration of 
function 'phy_start' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1198:2: error: implicit declaration of 
function 'phy_stop' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1239:9: error: implicit declaration of 
function 'phy_mii_ioctl' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1389:28: error: 
'phy_ethtool_get_link_ksettings' undeclared here (not in a function)
drivers/net/ethernet/broadcom/bgmac.c:1390:28: error: 
'phy_ethtool_set_link_ksettings' undeclared here (not in a function)
drivers/net/ethernet/broadcom/bgmac.c:1403:13: error: dereferencing pointer to 
incomplete type 'struct phy_device'
drivers/net/ethernet/broadcom/bgmac.c:1417:3: error: implicit declaration of 
function 'phy_print_status' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1424:26: error: storage size of 
'fphy_status' isn't known
drivers/net/ethernet/broadcom/bgmac.c:1424:9: error: variable 'fphy_status' has 
initializer but incomplete type
drivers/net/ethernet/broadcom/bgmac.c:1425:11: warning: excess elements in 
struct initializer
drivers/net/ethernet/broadcom/bgmac.c:1425:3: error: unknown field 'link' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1426:12: note: in expansion of macro 
'SPEED_1000'
drivers/net/ethernet/broadcom/bgmac.c:1426:3: error: unknown field 'speed' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1427:13: note: in expansion of macro 
'DUPLEX_FULL'
drivers/net/ethernet/broadcom/bgmac.c:1427:3: error: unknown field 'duplex' 
specified in initializer
drivers/net/ethernet/broadcom/bgmac.c:1432:12: error: implicit declaration of 
function 'fixed_phy_register' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1432:31: error: 'PHY_POLL' undeclared 
(first use in this function)
drivers/net/ethernet/broadcom/bgmac.c:1438:8: error: implicit declaration of 
function 'phy_connect_direct' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1439:6: error: 'PHY_INTERFACE_MODE_MII' 
undeclared (first use in this function)
drivers/net/ethernet/broadcom/bgmac.c:1521:2: error: implicit declaration of 
function 'phy_disconnect' [-Werror=implicit-function-declaration]
drivers/net/ethernet/broadcom/bgmac.c:1541:15: error: expected declaration 
specifiers or '...' before string constant

Add linux/phy.h to bgmac.c

Signed-off-by: Russell King 
---
 drivers/net/ethernet/broadcom/bgmac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 0e066dc6b8cc..58a2bd3c0458 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "bgmac.h"
 
 static bool bgmac_wait_value(struct bgmac *bgmac, u16 reg, u32 mask,
-- 
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 4.10-rc3 03/13] net: macb: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/ethernet/cadence/macb.h:862:33: sparse: expected ; at end of 
declaration
drivers/net/ethernet/cadence/macb.h:862:33: sparse: Expected } at end of 
struct-union-enum-specifier
drivers/net/ethernet/cadence/macb.h:862:33: sparse: got phy_interface
drivers/net/ethernet/cadence/macb.h:877:1: sparse: Expected ; at the end of 
type declaration
drivers/net/ethernet/cadence/macb.h:877:1: sparse: got }
In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0:
drivers/net/ethernet/cadence/macb.h:862:2: error: unknown type name 
'phy_interface_t'
 phy_interface_t  phy_interface;
 ^~~

Add linux/phy.h to macb.h

Signed-off-by: Russell King 
---
 drivers/net/ethernet/cadence/macb.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/cadence/macb.h 
b/drivers/net/ethernet/cadence/macb.h
index d67adad67be1..383da8cf5f6d 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -10,6 +10,8 @@
 #ifndef _MACB_H
 #define _MACB_H
 
+#include 
+
 #define MACB_GREGS_NBR 16
 #define MACB_GREGS_VERSION 2
 #define MACB_MAX_QUEUES 8
-- 
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 4.10-rc3 07/13] net: mvneta: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/ethernet/marvell/mvneta.c:2694:26: error: storage size of 'status' 
isn't known
drivers/net/ethernet/marvell/mvneta.c:2695:26: error: storage size of 'changed' 
isn't known
drivers/net/ethernet/marvell/mvneta.c:2695:9: error: variable 'changed' has 
initializer but incomplete type
drivers/net/ethernet/marvell/mvneta.c:2709:2: error: implicit declaration of 
function 'fixed_phy_update_state' [-Werror=implicit-function-declaration]

Add linux/phy_fixed.h to mvneta.c

Signed-off-by: Russell King 
---
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index e05e22705cf7..eb0eb3e62ca0 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
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 4.10-rc3 01/13] net: sunrpc: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

Removing linux/phy.h from net/dsa.h reveals a build error in the sunrpc
code:

net/sunrpc/xprtrdma/svc_rdma_backchannel.c: In function 'xprt_rdma_bc_put':
net/sunrpc/xprtrdma/svc_rdma_backchannel.c:277:2: error: implicit declaration 
of function 'module_put' [-Werror=implicit-function-declaration]
net/sunrpc/xprtrdma/svc_rdma_backchannel.c: In function 'xprt_setup_rdma_bc':
net/sunrpc/xprtrdma/svc_rdma_backchannel.c:348:7: error: implicit declaration 
of function 'try_module_get' [-Werror=implicit-function-declaration]

Fix this by adding linux/module.h to svc_rdma_backchannel.c

Signed-off-by: Russell King 
---
 net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c 
b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
index 288e35c2d8f4..cb1e48e54eb1 100644
--- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
+++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c
@@ -4,6 +4,7 @@
  * Support for backward direction RPCs on RPC/RDMA (server-side).
  */
 
+#include 
 #include 
 #include "xprt_rdma.h"
 
-- 
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 4.10-rc3 04/13] net: lan78xx: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/usb/lan78xx.c:394:33: sparse: expected ; at end of declaration
drivers/net/usb/lan78xx.c:394:33: sparse: Expected } at end of 
struct-union-enum-specifier
drivers/net/usb/lan78xx.c:394:33: sparse: got interface
drivers/net/usb/lan78xx.c:403:1: sparse: Expected ; at the end of type 
declaration
drivers/net/usb/lan78xx.c:403:1: sparse: got }

Add linux/phy.h to lan78xx.c

Signed-off-by: Russell King 
---
 drivers/net/usb/lan78xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 08f8703e4d54..9889a70ff4f6 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "lan78xx.h"
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
-- 
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 4.10-rc3 09/13] iscsi: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/target/iscsi/iscsi_target_login.c:1135:7: error: implicit declaration 
of function 'try_module_get' [-Werror=implicit-function-declaration]

Add linux/module.h to iscsi_target_login.c.

Signed-off-by: Russell King 
---
 drivers/target/iscsi/iscsi_target_login.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/target/iscsi/iscsi_target_login.c 
b/drivers/target/iscsi/iscsi_target_login.c
index 450f51deb2a2..eab274d17b5c 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -17,6 +17,7 @@
  
**/
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
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 4.10-rc3 10/13] MIPS: Octeon: Remove unnecessary MODULE_*()

[Russell King]

octeon-platform.c can not be built as a module for two reasons:

(a) the Makefile doesn't allow it:
obj-y := cpu.o setup.o octeon-platform.o octeon-irq.o csrc-octeon.o

(b) the multiple *_initcall() statements, each of which are translated
to a module_init() call when attempting a module build, become
aliases to init_module().  Having more than one alias will cause a
build error.

Hence, rather than adding a linux/module.h include, remove the redundant
MODULE_*() from this file.

Acked-by: David Daney 
Signed-off-by: Russell King 
---
 arch/mips/cavium-octeon/octeon-platform.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/mips/cavium-octeon/octeon-platform.c 
b/arch/mips/cavium-octeon/octeon-platform.c
index 37a932d9148c..8297ce714c5e 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -1060,7 +1060,3 @@ static int __init octeon_publish_devices(void)
return of_platform_bus_probe(NULL, octeon_ids, NULL);
 }
 arch_initcall(octeon_publish_devices);
-
-MODULE_AUTHOR("David Daney ");
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("Platform driver for Octeon SOC");
-- 
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 4.10-rc3 06/13] net: fman: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/ethernet/freescale/fman/fman_memac.c:519:21: error: dereferencing 
pointer to incomplete type 'struct fixed_phy_status'

Add linux/phy_fixed.h to fman_memac.c

Signed-off-by: Russell King 
---
 drivers/net/ethernet/freescale/fman/fman_memac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c 
b/drivers/net/ethernet/freescale/fman/fman_memac.c
index 71a5ded9d1de..cd6a53eaf161 100644
--- a/drivers/net/ethernet/freescale/fman/fman_memac.c
+++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* PCS registers */
-- 
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 4.10-rc3 08/13] net: emac: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/ethernet/qualcomm/emac/emac-sgmii.c:58:12: error: dereferencing 
pointer to incomplete type 'struct phy_device'

Add linux/phy.h to emac-sgmii.c

Signed-off-by: Russell King 
---
 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c 
b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index bf722a9bb09d..5e31fb7e4ab8 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "emac.h"
 #include "emac-mac.h"
 #include "emac-sgmii.h"
-- 
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 4.10-rc3 11/13] net: liquidio: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: expected 
declaration specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: type defaults to 
'int' in declaration of 'MODULE_AUTHOR'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:30: error: function 
declaration isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: expected 
declaration specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: type defaults to 
'int' in declaration of 'MODULE_DESCRIPTION'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:31: error: function 
declaration isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: expected 
declaration specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: type defaults to 
'int' in declaration of 'MODULE_LICENSE'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:32: error: function 
declaration isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: expected 
declaration specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: type defaults to 
'int' in declaration of 'MODULE_VERSION'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:33: error: function 
declaration isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:36: error: expected ')' 
before 'int'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:37: error: expected ')' 
before string constant
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: data 
definition has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: error: type defaults to 
'int' in declaration of 'MODULE_DEVICE_TABLE'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:325: warning: parameter 
names (without types) in function declaration
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: data 
definition has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: error: type defaults 
to 'int' in declaration of 'module_init'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3250: warning: parameter 
names (without types) in function declaration
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: data 
definition has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: error: type defaults 
to 'int' in declaration of 'module_exit'
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c:3251: warning: parameter 
names (without types) in function declaration
drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: expected declaration 
specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_main.c:36: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: type defaults to 
'int' in declaration of 'MODULE_AUTHOR'
drivers/net/ethernet/cavium/liquidio/lio_main.c:36: error: function declaration 
isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: expected declaration 
specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_main.c:37: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: type defaults to 
'int' in declaration of 'MODULE_DESCRIPTION'
drivers/net/ethernet/cavium/liquidio/lio_main.c:37: error: function declaration 
isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: expected declaration 
specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_main.c:38: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: type defaults to 
'int' in declaration of 'MODULE_LICENSE'
drivers/net/ethernet/cavium/liquidio/lio_main.c:38: error: function declaration 
isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: expected declaration 
specifiers or '...' before string constant
drivers/net/ethernet/cavium/liquidio/lio_main.c:39: warning: data definition 
has no type or storage class
drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: type defaults to 
'int' in declaration of 'MODULE_VERSION'
drivers/net/ethernet/cavium/liquidio/lio_main.c:39: error: function declaration 
isn't a prototype
drivers/net/ethernet/cavium/liquidio/lio_main.c:40: error: expected declaration 
specifiers or '...' 

[PATCH 4.10-rc3 13/13] net: dsa: remove unnecessary phy*.h includes

[Russell King]

Including phy.h and phy_fixed.h into net/dsa.h causes phy*.h to be an
unnecessary dependency for quite a large amount of the kernel.  There's
very little which actually requires definitions from phy.h in net/dsa.h
- the include itself only wants the declaration of a couple of
structures and IFNAMSIZ.

Add linux/if.h for IFNAMSIZ, declarations for the structures, phy.h to
mv88e6xxx.h as it needs it for phy_interface_t, and remove both phy.h
and phy_fixed.h from net/dsa.h.

This patch reduces from around 800 files rebuilt to around 40 - even
with ccache, the time difference is noticable.

Tested-by: Vivien Didelot 
Reviewed-by: Florian Fainelli 
Signed-off-by: Russell King 
---
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 1 +
 include/net/dsa.h | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h 
b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
index af54baea47cf..3a949095068a 100644
--- a/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx/mv88e6xxx.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifndef UINT64_MAX
 #define UINT64_MAX (u64)(~((u64)0))
diff --git a/include/net/dsa.h b/include/net/dsa.h
index b122196d5a1f..887b2f98f9ea 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -11,15 +11,17 @@
 #ifndef __LINUX_NET_DSA_H
 #define __LINUX_NET_DSA_H
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 
+struct phy_device;
+struct fixed_phy_status;
+
 enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE = 0,
DSA_TAG_PROTO_DSA,
-- 
2.7.4

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

Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

[Heiner Kallweit]

Am 31.01.2017 um 19:48 schrieb John Youn:
> On 1/30/2017 11:13 PM, Heiner Kallweit wrote:
>> Am 31.01.2017 um 03:32 schrieb John Youn:
>>> On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
 Supplies for vusb_a and vusb_d are needed only on a minority of systems
 supported by the dwc2 driver (AFAIK systems with Samsung SoCs).

 On all other systems this results in these harmless but annoying
 warnings:

 c900.usb supply vusb_d not found, using dummy regulator
 c900.usb supply vusb_a not found, using dummy regulator

 Introduce a configuration parameter to ignore the supplies on
 systems not needing it.
>>>
>>> You can probably just check for the existence of those bindings. Or
>>> possibly use devm_regulator_get_optional().
>>>
>> Right, that we could do to silence the warning. But then we would
>> loose the warning on systems where these supplies are mandatory
>> (in case somebody adds a system with such a SoC and forgets to define
>> the supplies in the DT).
> 
> I don't think the dwc2 driver should be doing that though. It should
> treat these as optional properties and use them if available, just
> like it does now for the reset control, phy, clocks, etc. Otherwise
> you could make the case for adding the same flag for these other
> components as well.
> 
> But really, I just don't want to add new parameters, if anything I
> want to remove more of them.
> 
I see. Then most likely it's best to switch to
devm_regulator_get_optional. I'll send a patch for it.

Heiner

> Regards,
> John
> 

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

[PATCH 4.10-rc3 12/13] net: ath5k: fix build errors when linux/phy*.h is removed from net/dsa.h

[Russell King]

Fix these errors reported by the 0-day builder by replacing the
linux/export.h include with linux/module.h.

In file included from include/linux/platform_device.h:14:0,
 from drivers/net/wireless/ath/ath5k/ahb.c:20:
include/linux/device.h:1463:1: warning: data definition has no type or storage 
class
 module_init(__driver##_init); \
 ^
include/linux/platform_device.h:228:2: note: in expansion of macro 
'module_driver'
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
'module_platform_driver'
 module_platform_driver(ath_ahb_driver);
 ^~
include/linux/device.h:1463:1: error: type defaults to 'int' in declaration of 
'module_init' [-Werror=implicit-int]
 module_init(__driver##_init); \
 ^
include/linux/platform_device.h:228:2: note: in expansion of macro 
'module_driver'
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
'module_platform_driver'
 module_platform_driver(ath_ahb_driver);
 ^~
drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without 
types) in function declaration
In file included from include/linux/platform_device.h:14:0,
 from drivers/net/wireless/ath/ath5k/ahb.c:20:
include/linux/device.h:1468:1: warning: data definition has no type or storage 
class
 module_exit(__driver##_exit);
 ^
include/linux/platform_device.h:228:2: note: in expansion of macro 
'module_driver'
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
'module_platform_driver'
 module_platform_driver(ath_ahb_driver);
 ^~
include/linux/device.h:1468:1: error: type defaults to 'int' in declaration of 
'module_exit' [-Werror=implicit-int]
 module_exit(__driver##_exit);
 ^
include/linux/platform_device.h:228:2: note: in expansion of macro 
'module_driver'
  module_driver(__platform_driver, platform_driver_register, \
  ^
drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
'module_platform_driver'
 module_platform_driver(ath_ahb_driver);
 ^~
drivers/net/wireless/ath/ath5k/ahb.c:233:1: warning: parameter names (without 
types) in function declaration
In file included from include/linux/platform_device.h:14:0,
 from drivers/net/wireless/ath/ath5k/ahb.c:20:
drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_exit' 
defined but not used [-Wunused-function]
 module_platform_driver(ath_ahb_driver);
^
include/linux/device.h:1464:20: note: in definition of macro 'module_driver'
 static void __exit __driver##_exit(void) \
^~~~
drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
'module_platform_driver'
 module_platform_driver(ath_ahb_driver);
 ^~
drivers/net/wireless/ath/ath5k/ahb.c:233:24: warning: 'ath_ahb_driver_init' 
defined but not used [-Wunused-function]
 module_platform_driver(ath_ahb_driver);
^
include/linux/device.h:1459:19: note: in definition of macro 'module_driver'
 static int __init __driver##_init(void) \
   ^~~~
drivers/net/wireless/ath/ath5k/ahb.c:233:1: note: in expansion of macro 
'module_platform_driver'
 module_platform_driver(ath_ahb_driver);
 ^~

Signed-off-by: Russell King 
---
 drivers/net/wireless/ath/ath5k/ahb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath5k/ahb.c 
b/drivers/net/wireless/ath/ath5k/ahb.c
index 2ca88b593e4c..c0794f5988b3 100644
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ b/drivers/net/wireless/ath/ath5k/ahb.c
@@ -16,10 +16,10 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "ath5k.h"
 #include "debug.h"
-- 
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 4.10-rc3 00/13] net: dsa: remove unnecessary phy.h include

[Russell King - ARM Linux]

Including phy.h and phy_fixed.h into net/dsa.h causes phy*.h to be an
unnecessary dependency for quite a large amount of the kernel.  There's
very little which actually requires definitions from phy.h in net/dsa.h
- the include itself only wants the declaration of a couple of
structures and IFNAMSIZ.

Add linux/if.h for IFNAMSIZ, declarations for the structures, phy.h to
mv88e6xxx.h as it needs it for phy_interface_t, and remove both phy.h
and phy_fixed.h from net/dsa.h.

This patch reduces from around 800 files rebuilt to around 40 - even
with ccache, the time difference is noticable.

In order to make this change, several drivers need to be updated to
include necessary headers that they were picking up through this
include.  This has resulted in a much larger patch series.

I'm assuming the 0-day builder has had 24 hours with this series, and
hasn't reported any further issues with it - the last issue was two
weeks ago (before I became ill) which I fixed over the last weekend.

I'm hoping this doesn't conflict with what's already in net-next...

 arch/mips/cavium-octeon/octeon-platform.c | 4 
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h | 1 +
 drivers/net/ethernet/broadcom/bgmac.c | 2 ++
 drivers/net/ethernet/cadence/macb.h   | 2 ++
 drivers/net/ethernet/cavium/liquidio/lio_main.c   | 1 +
 drivers/net/ethernet/cavium/liquidio/lio_vf_main.c| 1 +
 drivers/net/ethernet/cavium/liquidio/octeon_console.c | 1 +
 drivers/net/ethernet/freescale/fman/fman_memac.c  | 1 +
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 drivers/net/ethernet/qualcomm/emac/emac-sgmii.c   | 1 +
 drivers/net/usb/lan78xx.c | 1 +
 drivers/net/wireless/ath/ath5k/ahb.c  | 2 +-
 drivers/target/iscsi/iscsi_target_login.c | 1 +
 include/net/dsa.h | 6 --
 net/core/netprio_cgroup.c | 1 +
 net/sunrpc/xprtrdma/svc_rdma_backchannel.c| 1 +
 16 files changed, 20 insertions(+), 7 deletions(-)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] r8152: Allocate interrupt buffer as part of struct r8152

[Guenter Roeck]

When unloading the r8152 driver using the 'unbind' sysfs attribute
in a system with KASAN enabled, the following error message is seen
on a regular basis.

BUG kmalloc-128 (Not tainted): Poison overwritten
-
INFO: 0xffc0a9522a00-0xffc0a9522a01. First byte 0xee instead of 0x6b
INFO: Allocated in rtl8152_open+0x318/0x5dc [r8152] age=69847 cpu=4 pid=1345
init: mtpd main process (2372) terminated with status 253
init: mtpd main process ended, respawning
alloc_debug_processing+0x124/0x178
___slab_alloc.constprop.59+0x530/0x65c
__slab_alloc.isra.56.constprop.58+0x48/0x74
kmem_cache_alloc_trace+0xd8/0x34c
rtl8152_open+0x318/0x5dc [r8152]
__dev_open+0xcc/0x140
__dev_change_flags+0xc8/0x1a8
dev_change_flags+0x50/0xa0
do_setlink+0x440/0xcd4
rtnl_newlink+0x414/0x7cc
rtnetlink_rcv_msg+0x238/0x268
netlink_rcv_skb+0xa4/0x128
rtnetlink_rcv+0x2c/0x3c
netlink_unicast+0x1e8/0x2e0
netlink_sendmsg+0x4c0/0x4e4
sock_sendmsg+0x70/0x8c
INFO: Freed in free_all_mem+0x10c/0x12c [r8152] age=271 cpu=2 pid=5992
free_debug_processing+0x278/0x37c
__slab_free+0x84/0x440
kfree+0x2d4/0x37c
free_all_mem+0x10c/0x12c [r8152]
rtl8152_close+0xf4/0x10c [r8152]
__dev_close_many+0xe0/0x118
dev_close_many+0xb8/0x174
rollback_registered_many+0x19c/0x3fc
unregister_netdevice_queue+0xe4/0x188
unregister_netdev+0x28/0x38
rtl8152_disconnect+0x7c/0xb0 [r8152]
usb_unbind_interface+0xd8/0x2cc
__device_release_driver+0x10c/0x1a8
device_release_driver+0x30/0x44
bus_remove_device+0x1e0/0x208
device_del+0x21c/0x2cc
INFO: Slab 0xffbdc2a5c880 objects=16 used=14 fp=0xffc0a9523400 
flags=0x4080
INFO: Object 0xffc0a9522a00 @offset=2560 fp=0xffc0a9522200

Bytes b4 ffc0a95229f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  

Object ffc0a9522a00: ee 30 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  
.0kk
Object ffc0a9522a10: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object ffc0a9522a20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object ffc0a9522a30: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object ffc0a9522a40: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object ffc0a9522a50: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object ffc0a9522a60: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  

Object ffc0a9522a70: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  
kkk.
Redzone ffc0a9522a80: bb bb bb bb bb bb bb bb  

Padding ffc0a9522bc0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  


The two-byte allocation in conjunction with code analysis suggests that
the interrupt buffer has been overwritten. Added instrumentation in the
driver shows that the interrupt handler is called after RTL8152_UNPLUG
was set, and that this event is associated with the error message above.
This suggests that there are situations where the interrupt buffer is used
after it has been freed.

To avoid the problem, allocate the interrupt buffer as part of struct
r8152.

Cc: Hayes Wang 
Signed-off-by: Guenter Roeck 
---
The problem is seen in chromeos-4.4, but there is not reason to believe
that it does not occur with the upstream kernel. It is still seen in
chromeos-4.4 after all patches from upstream and linux-next have been
applied to the driver.

While relatively simple, I am not really convinced that this is the best
(or even an acceptable) solution for this problem. I am open to suggestions
for a better fix.

 drivers/net/usb/r8152.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ad42295356dd..afbfa728b48e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -641,7 +641,7 @@ struct r8152 {
u32 coalesce;
u16 ocp_base;
u16 speed;
-   u8 *intr_buff;
+   u8 intr_buff[INTBUFSIZE] cacheline_aligned;
u8 version;
u8 duplex;
u8 autoneg;
@@ -1342,9 +1342,6 @@ static void free_all_mem(struct r8152 *tp)
 
usb_free_urb(tp->intr_urb);
tp->intr_urb = NULL;
-
-   kfree(tp->intr_buff);
-   tp->intr_buff = NULL;
 }
 
 static int alloc_all_mem(struct r8152 *tp)
@@ -1423,10 +1420,6 @@ static int alloc_all_mem(struct r8152 *tp)
if (!tp->intr_urb)
goto err1;
 
-   tp->intr_buff = kmalloc(INTBUFSIZE, GFP_KERNEL);
-   if (!tp->intr_buff)
-   goto err1;
-
tp->intr_interval = (int)ep_intr->desc.bInterval;
usb_fill_int_urb(tp->intr_urb, tp->udev, usb_rcvintpipe(tp->udev, 3),
 tp->intr_buff, INTBUFSIZE, intr_callback,
-- 
2.7.4

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

Re: [PATCH] usb: dwc2: remove deprecated comment in definition of struct dwc2_core_params

[John Youn]

On 1/31/2017 10:55 AM, John Youn wrote:
> On 1/28/2017 1:42 PM, Heiner Kallweit wrote:
>> Since commit 0a7d0d7fa820 "usb: dwc2: Remove dwc2_set_all_params function"
>> this comment isn't applicable any longer.
>>
>> Signed-off-by: Heiner Kallweit 
>> ---
>>  drivers/usb/dwc2/core.h | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index 570a8004..a708e4fa 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -461,10 +461,6 @@ enum dwc2_ep0_state {
>>   * default described above.
>>   */
>>  struct dwc2_core_params {
>> -/*
>> - * Don't add any non-int members here, this will break
>> - * dwc2_set_all_params!
>> - */
>>  int otg_cap;
>>  #define DWC2_CAP_PARAM_HNP_SRP_CAPABLE  0
>>  #define DWC2_CAP_PARAM_SRP_ONLY_CAPABLE 1
>>
>
> Acked-by: John Youn 
>
> John
>

Actually this is already removed and queued for 4.11.

Please disregard.

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

RE: linux USB dwc3 not working

[Felipe Balbi]

Hi Andy,

andy_purc...@keysight.com writes:
> 00:14.1 USB controller: Intel Corporation Sunrise Point-H USB Device 
> Controller (OTG) (rev 31)

okay, this is dwc3. Good

>> I need to ask you to try a newer kernel. Can you try v4.9.6 or v4.10-rc6?
>> 
>
> I am now running Ubuntu 4.10.0-999-generic. 
> Same results - USB device not working, test modes still not working.  

okay

>> > Using a script, I set up the USB-device to be RNDIS, using functionfs.
>> 
>> functionfs needs a userspace component, do you have that? Can you try any
>> other gadget driver like mass storage, for instance? Here's a quick script 
>> for
>> mass storage:
>> 
>> #!/bin/sh
>> 
>> dd if=/dev/zero of=/dev/shm/file bs=1M count=1024
>> 
>> mount -t configfs none /c
>> mkdir /c/usb_gadget/g1
>> echo 0x18d1 > /c/usb_gadget/g1/idVendor
>> echo 0xbeef > /c/usb_gadget/g1/idProduct mkdir
>> /c/usb_gadget/g1/strings/0x409 echo 123456789012 >
>> /c/usb_gadget/g1/strings/0x409/serialnumber
>> echo "Intel Corporation" > /c/usb_gadget/g1/strings/0x409/manufacturer
>> echo "Joule" > /c/usb_gadget/g1/strings/0x409/product
>> mkdir /c/usb_gadget/g1/functions/mass_storage.1
>> mkdir /c/usb_gadget/g1/configs/b.1
>> mkdir /c/usb_gadget/g1/configs/b.1/strings/0x409
>> echo 500 > /c/usb_gadget/g1/configs/b.1/MaxPower
>> echo /dev/shm/file > /c/usb_gadget/g1/functions/mass_storage.1/lun.0/file
>> ln -s /c/usb_gadget/g1/functions/mass_storage.1
>> /c/usb_gadget/g1/configs/b.1/f1 echo dwc3.0.auto > /c/usb_gadget/g1/UDC
>> 
>
> I run this script, slightly modified, as you suggested. 
> After running this script, I see these 2 lines added to the dmesg output: 
> [   93.096773] Mass Storage Function, version: 2009/09/11
> [   93.096777] LUN: removable file: (no medium)

alright, mass storage loaded and available.

>> > I connect a USB cable from my board to a USB-host.
>> > My USB analyzer shows nothing happens. No connection, no SETUP
>> > packets, nothing.
>> 
>> right, I'm assuming you don't have userspace component for functionfs, so -
>> >pullup() is never called.
>> 
>
> What is the userspace component for functionfs, given that I am setting up 
> mass storage? 
> How do I get it for Ubuntu 4.10.0-999-generic? 

now that you're using mass storage, you don't need anything else ;-)

>> Can you also get the output of:
>> 
>> grep DCTL regdump
>
> root@apub1:/sys/kernel/debug/dwc3.0.auto# grep DCTL regdump 
> DCTL = 0x80f0

okay, good. RUN/STOP bit is set. So it still doesn't work? The only
thing I can think of, is that VBUS_VALID bit in the Mux register isn't
set properly. I'm not in the office now, but I'll try to get you more
info on that.

In my SKL boards, however, that bit is always enabled. This means that
DWC3 works, but when I unplug cable, I don't see a disconnect interrupt
;-)

What you really need to make this work properly, is some way of sampling
VBUS level and, whenever it's above 4.4V, then set VBUS_VALID bit in
DRCFG0 register. This is the best way to have this always
working. Ideally it would be hidden by the BIOS, so you wouldn't have to
care about it :-s

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

Re: [PATCH] usb: dwc2: remove deprecated comment in definition of struct dwc2_core_params

[John Youn]

On 1/28/2017 1:42 PM, Heiner Kallweit wrote:
> Since commit 0a7d0d7fa820 "usb: dwc2: Remove dwc2_set_all_params function"
> this comment isn't applicable any longer.
>
> Signed-off-by: Heiner Kallweit 
> ---
>  drivers/usb/dwc2/core.h | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 570a8004..a708e4fa 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -461,10 +461,6 @@ enum dwc2_ep0_state {
>   * default described above.
>   */
>  struct dwc2_core_params {
> - /*
> -  * Don't add any non-int members here, this will break
> -  * dwc2_set_all_params!
> -  */
>   int otg_cap;
>  #define DWC2_CAP_PARAM_HNP_SRP_CAPABLE   0
>  #define DWC2_CAP_PARAM_SRP_ONLY_CAPABLE  1
>

Acked-by: John Youn 

John

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

Re: [PATCH] usb: dwc2: introduce config parameter to ignore supplies vusb_a and vusb_d

[John Youn]

On 1/30/2017 11:13 PM, Heiner Kallweit wrote:
> Am 31.01.2017 um 03:32 schrieb John Youn:
>> On 1/28/2017 2:06 PM, Heiner Kallweit wrote:
>>> Supplies for vusb_a and vusb_d are needed only on a minority of systems
>>> supported by the dwc2 driver (AFAIK systems with Samsung SoCs).
>>>
>>> On all other systems this results in these harmless but annoying
>>> warnings:
>>>
>>> c900.usb supply vusb_d not found, using dummy regulator
>>> c900.usb supply vusb_a not found, using dummy regulator
>>>
>>> Introduce a configuration parameter to ignore the supplies on
>>> systems not needing it.
>>
>> You can probably just check for the existence of those bindings. Or
>> possibly use devm_regulator_get_optional().
>>
> Right, that we could do to silence the warning. But then we would
> loose the warning on systems where these supplies are mandatory
> (in case somebody adds a system with such a SoC and forgets to define
> the supplies in the DT).

I don't think the dwc2 driver should be doing that though. It should
treat these as optional properties and use them if available, just
like it does now for the reset control, phy, clocks, etc. Otherwise
you could make the case for adding the same flag for these other
components as well.

But really, I just don't want to add new parameters, if anything I
want to remove more of them.

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

RE: linux USB dwc3 not working

[andy_purcell]

Hello Felipe, 

See responses below. 

> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Tuesday, January 31, 2017 5:10 AM
> To: PURCELL,ANDY (K-Loveland,ex1) ; linux-
> u...@vger.kernel.org
> Subject: Re: linux USB dwc3 not working
> 
> 
> Hi Andy,
> 
> andy_purc...@keysight.com writes:
> > Hello,
> >
> > I am starting work on a board that has the Intel Skylake chipset,
> > which has hardware for doing USB-device.
> 
> Not all SKLs have dwc3 enabled. Can you provide the output of lspci?

00:00.0 Host bridge: Intel Corporation Sky Lake Host Bridge/DRAM Registers (rev 
07)
00:01.0 PCI bridge: Intel Corporation Sky Lake PCIe Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Sky Lake Integrated 
Graphics (rev 06)
00:08.0 System peripheral: Intel Corporation Sky Lake Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI 
Controller (rev 31)
00:14.1 USB controller: Intel Corporation Sunrise Point-H USB Device Controller 
(OTG) (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal 
subsystem (rev 31)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-H LPSS 
I2C Controller #0 (rev 31)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-H LPSS 
I2C Controller #1 (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI 
#1 (rev 31)
00:16.3 Serial controller: Intel Corporation Sunrise Point-H KT Redirection 
(rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller 
[AHCI mode] (rev 31)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #11 
(rev f1)
00:1d.3 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #12 
(rev f1)
00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-H LPSS 
UART #0 (rev 31)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM 
(rev 31)
02:00.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)
03:02.0 PCI bridge: PLX Technology, Inc. Device 3380 (rev ab)

> 
> I need to ask you to try a newer kernel. Can you try v4.9.6 or v4.10-rc6?
> 

I am now running Ubuntu 4.10.0-999-generic. 
Same results - USB device not working, test modes still not working.  

> > Using a script, I set up the USB-device to be RNDIS, using functionfs.
> 
> functionfs needs a userspace component, do you have that? Can you try any
> other gadget driver like mass storage, for instance? Here's a quick script for
> mass storage:
> 
> #!/bin/sh
> 
> dd if=/dev/zero of=/dev/shm/file bs=1M count=1024
> 
> mount -t configfs none /c
> mkdir /c/usb_gadget/g1
> echo 0x18d1 > /c/usb_gadget/g1/idVendor
> echo 0xbeef > /c/usb_gadget/g1/idProduct mkdir
> /c/usb_gadget/g1/strings/0x409 echo 123456789012 >
> /c/usb_gadget/g1/strings/0x409/serialnumber
> echo "Intel Corporation" > /c/usb_gadget/g1/strings/0x409/manufacturer
> echo "Joule" > /c/usb_gadget/g1/strings/0x409/product
> mkdir /c/usb_gadget/g1/functions/mass_storage.1
> mkdir /c/usb_gadget/g1/configs/b.1
> mkdir /c/usb_gadget/g1/configs/b.1/strings/0x409
> echo 500 > /c/usb_gadget/g1/configs/b.1/MaxPower
> echo /dev/shm/file > /c/usb_gadget/g1/functions/mass_storage.1/lun.0/file
> ln -s /c/usb_gadget/g1/functions/mass_storage.1
> /c/usb_gadget/g1/configs/b.1/f1 echo dwc3.0.auto > /c/usb_gadget/g1/UDC
> 

I run this script, slightly modified, as you suggested. 
After running this script, I see these 2 lines added to the dmesg output: 
[   93.096773] Mass Storage Function, version: 2009/09/11
[   93.096777] LUN: removable file: (no medium)

> > I connect a USB cable from my board to a USB-host.
> > My USB analyzer shows nothing happens. No connection, no SETUP
> > packets, nothing.
> 
> right, I'm assuming you don't have userspace component for functionfs, so -
> >pullup() is never called.
> 

What is the userspace component for functionfs, given that I am setting up mass 
storage? 
How do I get it for Ubuntu 4.10.0-999-generic? 


> 
> Can you also get the output of:
> 
> grep DCTL regdump
> 

root@apub1:/sys/kernel/debug/dwc3.0.auto# grep DCTL regdump 
DCTL = 0x80f0


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

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Rafał Miłecki]

On 01/25/2017 10:04 PM, Jacek Anaszewski wrote:

On 01/25/2017 10:03 AM, Rafał Miłecki wrote:

On 21 January 2017 at 22:42, Jacek Anaszewski
 wrote:

On 01/21/2017 05:24 PM, Rafał Miłecki wrote:

On 20 January 2017 at 23:35, Jacek Anaszewski
 wrote:

On 01/20/2017 10:56 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

Some LEDs can be related to particular devices described in DT. This
property allows specifying such relations. E.g. USB LED should usually
be used to indicate some USB port(s) state.

Signed-off-by: Rafał Miłecki 
---
V2: Replace "usb-ports" with "led-triggers" property which is more generic and
allows specifying other devices as well.

When bindings patch is related to some followup implementation, they usually go
through the same tree.

Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve examples by
adding some context") from kernel/git/j.anaszewski/linux-leds.git . Is there any
way to solve this dependency issue? Or should this patch wait until 3.11 is
released?
---
 Documentation/devicetree/bindings/leds/common.txt | 16 
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index 24b656014089..17632a041196 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -49,6 +49,17 @@ Optional properties for child nodes:
 - panic-indicator : This property specifies that the LED should be used,
  if at all possible, as a panic indicator.

+- led-triggers : List of devices that should trigger this LED activity. Some
+  LEDs can be related to a specific device and should somehow
+  indicate its state. E.g. USB 2.0 LED may react to device(s) in
+  a USB 2.0 port(s). Another common example is switch or router
+  with multiple Ethernet ports each of them having its own LED
+  assigned (assuminled-trigger-usbportg they are not hardwired).
+  In such cases this property should contain phandle(s) of
+  related device(s). In many cases LED can be related to more
+  than one device (e.g. one USB LED vs. multiple USB ports) so a
+  list of entries can be specified.
+


This implies that it is possible to define multiple triggers for
a LED class device but it is not supported by LED Trigger core.
There is linux,default-trigger property which allows to define one
trigger that will be initially assigned.



With proposed "led-triggers" property one could assign different
trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
device & CPU to a single LED. For reason explained above Linux
couldn't support all of them at once.



I am aware that this is renamed usb-ports property from v1,
that attempts to address Rob's comment, but we can't do that this way.
Maybe usb-ports property could be documented in led-trigger-usbport's
specific bindings and a reference to it could be added next to the
related entry on the list of the available LED triggers (which is
actually missing) in Documentation/devicetree/bindings/leds/common.txt.


I'm wondering if we need to care about this Linux limitation and if it
should stop us from adding this flexible DT property. Maybe we could
live with Linux having limitation of supporting one trigger type at a
time?


That's what I meant. Generally I have objections to the generic
property for defining list of allowed triggers. That's why I proposed
to stay by usb-ports property that would be specific to only one
trigger: led-trigger-usbport.

led-trigger-usbport in fact is an entirely new type of LED trigger.
LED triggers is a kernel based source of events. All existing triggers
react only to a single, well defined source of events, whereas
led-trigger-usbport allows to define the scope of events (usb ports)
to notify about. Activity on each port is treated similarly and the LED
class device that listens to the trigger notifications doesn't know
which exact port triggered the notification.

From this POV led-trigger-usbport is kind of facade, which allows
for it to fit well into the LED Trigger design and API, and usb ports
are not identical with LED triggers, but sit rather one level below.
It is led-trigger-usbport which is visible to the LED subsystem, and
not every single usb port.


So e.g. if one assigns 2 USB ports + network device + CPU and
decides to use "usport" trigger driver he'll get LED indicating status
of USB ports only.


How would it be different from the current state? Only in limiting
the scope of triggers available for a LED class device.


It won't differ from the current state. I just wanted to make it clear
Linux trigger drivers may respect only selected "led-triggers" values
(phandles). Like "usbport" respecting USB port phandles but 

Re: [PATCH 2/3] USB: serial: digi_acceleport: fix incomplete rx sanity check

[Johan Hovold]

On Tue, Jan 31, 2017 at 05:55:17PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 31, 2017 at 05:46:02PM +0100, Johan Hovold wrote:
> > On Tue, Jan 31, 2017 at 05:41:52PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 31, 2017 at 05:17:28PM +0100, Johan Hovold wrote:
> > > > Make sure the received data has the required headers before parsing it.
> > > > 
> > > > Also drop the redundant urb-status check, which has already been handled
> > > > by the caller.
> > > > 
> > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > > Signed-off-by: Johan Hovold 
> > > > ---
> > > >  drivers/usb/serial/digi_acceleport.c | 38 
> > > > ++--
> > > >  1 file changed, 23 insertions(+), 15 deletions(-)
> > > > 
> > > > diff --git a/drivers/usb/serial/digi_acceleport.c 
> > > > b/drivers/usb/serial/digi_acceleport.c
> > > > index 3b610f1e3f7c..eb433922598c 100644
> > > > --- a/drivers/usb/serial/digi_acceleport.c
> > > > +++ b/drivers/usb/serial/digi_acceleport.c
> > > > @@ -1398,25 +1398,30 @@ static int digi_read_inb_callback(struct urb 
> > > > *urb)
> > > >  {
> > > > struct usb_serial_port *port = urb->context;
> > > > struct digi_port *priv = usb_get_serial_port_data(port);
> > > > -   int opcode = ((unsigned char *)urb->transfer_buffer)[0];
> > > > -   int len = ((unsigned char *)urb->transfer_buffer)[1];
> > > > -   int port_status = ((unsigned char *)urb->transfer_buffer)[2];
> > > > -   unsigned char *data = ((unsigned char *)urb->transfer_buffer) + 
> > > > 3;
> > > > +   unsigned char *buf = urb->transfer_buffer;
> > > > +   int opcode;
> > > > +   int len;
> > > > +   int port_status;
> > > > +   unsigned char *data;
> > > > int flag, throttled;
> > > > -   int status = urb->status;
> > > > -
> > > > -   /* do not process callbacks on closed ports */
> > > > -   /* but do continue the read chain */
> > > > -   if (urb->status == -ENOENT)
> > > > -   return 0;
> > > >  
> > > > /* short/multiple packet check */
> > > > +   if (urb->actual_length < 2) {
> > > > +   dev_warn(>dev, "short packet received\n");
> > > > +   return -1;
> > > 
> > > Again, real error number?  -EINVAL?  -EIO?
> > > 
> > > > +   }
> > > > +
> > > > +   opcode = buf[0];
> > > > +   len = buf[1];
> > > > +
> > > > if (urb->actual_length != len + 2) {
> > > > -   dev_err(>dev, "%s: INCOMPLETE OR MULTIPLE PACKET, 
> > > > "
> > > > -   "status=%d, port=%d, opcode=%d, len=%d, "
> > > > -   "actual_length=%d, status=%d\n", __func__, 
> > > > status,
> > > > -   priv->dp_port_num, opcode, len, 
> > > > urb->actual_length,
> > > > -   port_status);
> > > > +   dev_err(>dev, "malformed packet received: 
> > > > port=%d, opcode=%d, len=%d, actual_length=%u\n",
> > > > +   priv->dp_port_num, opcode, len, 
> > > > urb->actual_length);
> > > > +   return -1;
> > > 
> > > Same here and elsewhere in this patch.
> > 
> > As the OOB function in the previous patch, this one is also documented
> > as returning -1 on sanity-check failures so I'm not changing that
> > behaviour now.
> > 
> > Also note that the return value is only checked against zero and never
> > used for anything else currently.
> 
> Ok, nevermind, my fault.
> 
> Reviewed-by: Greg Kroah-Hartman 

Thanks for reviewing these. Applying for -next.

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

[PATCH] usb: gadget: f_hid: fix: Don't access hidg->req without spinlock held

[Krzysztof Opasiak]

hidg->req should be accessed only with write_spinlock held as it is
set to NULL when we get disabled by host.

Signed-off-by: Krzysztof Opasiak 
---
 drivers/usb/gadget/function/f_hid.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 89b48bcc377a..5eea44823ca0 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -367,7 +367,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
__user *buffer,
count  = min_t(unsigned, count, hidg->report_length);
 
spin_unlock_irqrestore(>write_spinlock, flags);
-   status = copy_from_user(hidg->req->buf, buffer, count);
+   status = copy_from_user(req->buf, buffer, count);
 
if (status != 0) {
ERROR(hidg->func.config->cdev,
@@ -378,9 +378,9 @@ static ssize_t f_hidg_write(struct file *file, const char 
__user *buffer,
 
spin_lock_irqsave(>write_spinlock, flags);
 
-   /* we our function has been disabled by host */
+   /* when our function has been disabled by host */
if (!hidg->req) {
-   free_ep_req(hidg->in_ep, hidg->req);
+   free_ep_req(hidg->in_ep, req);
/*
 * TODO
 * Should we fail with error here?
@@ -394,7 +394,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
__user *buffer,
req->complete = f_hidg_req_complete;
req->context  = hidg;
 
-   status = usb_ep_queue(hidg->in_ep, hidg->req, GFP_ATOMIC);
+   status = usb_ep_queue(hidg->in_ep, req, GFP_ATOMIC);
if (status < 0) {
ERROR(hidg->func.config->cdev,
"usb_ep_queue error on int endpoint %zd\n", status);
-- 
2.9.3

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

Re: [PATCH 2/3] USB: serial: digi_acceleport: fix incomplete rx sanity check

[Greg KH]

On Tue, Jan 31, 2017 at 05:46:02PM +0100, Johan Hovold wrote:
> On Tue, Jan 31, 2017 at 05:41:52PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 31, 2017 at 05:17:28PM +0100, Johan Hovold wrote:
> > > Make sure the received data has the required headers before parsing it.
> > > 
> > > Also drop the redundant urb-status check, which has already been handled
> > > by the caller.
> > > 
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Signed-off-by: Johan Hovold 
> > > ---
> > >  drivers/usb/serial/digi_acceleport.c | 38 
> > > ++--
> > >  1 file changed, 23 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/usb/serial/digi_acceleport.c 
> > > b/drivers/usb/serial/digi_acceleport.c
> > > index 3b610f1e3f7c..eb433922598c 100644
> > > --- a/drivers/usb/serial/digi_acceleport.c
> > > +++ b/drivers/usb/serial/digi_acceleport.c
> > > @@ -1398,25 +1398,30 @@ static int digi_read_inb_callback(struct urb *urb)
> > >  {
> > >   struct usb_serial_port *port = urb->context;
> > >   struct digi_port *priv = usb_get_serial_port_data(port);
> > > - int opcode = ((unsigned char *)urb->transfer_buffer)[0];
> > > - int len = ((unsigned char *)urb->transfer_buffer)[1];
> > > - int port_status = ((unsigned char *)urb->transfer_buffer)[2];
> > > - unsigned char *data = ((unsigned char *)urb->transfer_buffer) + 3;
> > > + unsigned char *buf = urb->transfer_buffer;
> > > + int opcode;
> > > + int len;
> > > + int port_status;
> > > + unsigned char *data;
> > >   int flag, throttled;
> > > - int status = urb->status;
> > > -
> > > - /* do not process callbacks on closed ports */
> > > - /* but do continue the read chain */
> > > - if (urb->status == -ENOENT)
> > > - return 0;
> > >  
> > >   /* short/multiple packet check */
> > > + if (urb->actual_length < 2) {
> > > + dev_warn(>dev, "short packet received\n");
> > > + return -1;
> > 
> > Again, real error number?  -EINVAL?  -EIO?
> > 
> > > + }
> > > +
> > > + opcode = buf[0];
> > > + len = buf[1];
> > > +
> > >   if (urb->actual_length != len + 2) {
> > > - dev_err(>dev, "%s: INCOMPLETE OR MULTIPLE PACKET, "
> > > - "status=%d, port=%d, opcode=%d, len=%d, "
> > > - "actual_length=%d, status=%d\n", __func__, status,
> > > - priv->dp_port_num, opcode, len, urb->actual_length,
> > > - port_status);
> > > + dev_err(>dev, "malformed packet received: port=%d, 
> > > opcode=%d, len=%d, actual_length=%u\n",
> > > + priv->dp_port_num, opcode, len, urb->actual_length);
> > > + return -1;
> > 
> > Same here and elsewhere in this patch.
> 
> As the OOB function in the previous patch, this one is also documented
> as returning -1 on sanity-check failures so I'm not changing that
> behaviour now.
> 
> Also note that the return value is only checked against zero and never
> used for anything else currently.

Ok, nevermind, my fault.

Reviewed-by: Greg Kroah-Hartman 
--
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/3] USB: serial: digi_acceleport: fix OOB data sanity check

[Greg KH]

On Tue, Jan 31, 2017 at 05:42:39PM +0100, Johan Hovold wrote:
> On Tue, Jan 31, 2017 at 05:38:58PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 31, 2017 at 05:17:27PM +0100, Johan Hovold wrote:
> > > Make sure to check for short transfers to avoid underflow in a loop
> > > condition when parsing the receive buffer.
> > > 
> > > Also fix an off-by-one error in the incomplete sanity check which could
> > > lead to invalid data being parsed.
> > > 
> > > Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Cc: stable    # v2.6.30
> > > Signed-off-by: Johan Hovold 
> > > ---
> > >  drivers/usb/serial/digi_acceleport.c | 14 +-
> > >  1 file changed, 9 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/usb/serial/digi_acceleport.c 
> > > b/drivers/usb/serial/digi_acceleport.c
> > > index 6a1df9e824ca..3b610f1e3f7c 100644
> > > --- a/drivers/usb/serial/digi_acceleport.c
> > > +++ b/drivers/usb/serial/digi_acceleport.c
> > > @@ -1482,16 +1482,20 @@ static int digi_read_oob_callback(struct urb *urb)
> > >   struct usb_serial *serial = port->serial;
> > >   struct tty_struct *tty;
> > >   struct digi_port *priv = usb_get_serial_port_data(port);
> > > + unsigned char *buf = urb->transfer_buffer;
> > >   int opcode, line, status, val;
> > >   int i;
> > >   unsigned int rts;
> > >  
> > > + if (urb->actual_length < 4)
> > > + return -1;
> > 
> > A real error number perhaps?
> 
> Yeah, that was my inclination too, but the function is documented as
> returning -1 when the sanity checks fail so I stuck to that for now:

Ah, crappy code, sorry about that :(

nevermind...

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: [PATCH 2/3] USB: serial: digi_acceleport: fix incomplete rx sanity check

[Johan Hovold]

On Tue, Jan 31, 2017 at 05:41:52PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 31, 2017 at 05:17:28PM +0100, Johan Hovold wrote:
> > Make sure the received data has the required headers before parsing it.
> > 
> > Also drop the redundant urb-status check, which has already been handled
> > by the caller.
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/usb/serial/digi_acceleport.c | 38 
> > ++--
> >  1 file changed, 23 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/usb/serial/digi_acceleport.c 
> > b/drivers/usb/serial/digi_acceleport.c
> > index 3b610f1e3f7c..eb433922598c 100644
> > --- a/drivers/usb/serial/digi_acceleport.c
> > +++ b/drivers/usb/serial/digi_acceleport.c
> > @@ -1398,25 +1398,30 @@ static int digi_read_inb_callback(struct urb *urb)
> >  {
> > struct usb_serial_port *port = urb->context;
> > struct digi_port *priv = usb_get_serial_port_data(port);
> > -   int opcode = ((unsigned char *)urb->transfer_buffer)[0];
> > -   int len = ((unsigned char *)urb->transfer_buffer)[1];
> > -   int port_status = ((unsigned char *)urb->transfer_buffer)[2];
> > -   unsigned char *data = ((unsigned char *)urb->transfer_buffer) + 3;
> > +   unsigned char *buf = urb->transfer_buffer;
> > +   int opcode;
> > +   int len;
> > +   int port_status;
> > +   unsigned char *data;
> > int flag, throttled;
> > -   int status = urb->status;
> > -
> > -   /* do not process callbacks on closed ports */
> > -   /* but do continue the read chain */
> > -   if (urb->status == -ENOENT)
> > -   return 0;
> >  
> > /* short/multiple packet check */
> > +   if (urb->actual_length < 2) {
> > +   dev_warn(>dev, "short packet received\n");
> > +   return -1;
> 
> Again, real error number?  -EINVAL?  -EIO?
> 
> > +   }
> > +
> > +   opcode = buf[0];
> > +   len = buf[1];
> > +
> > if (urb->actual_length != len + 2) {
> > -   dev_err(>dev, "%s: INCOMPLETE OR MULTIPLE PACKET, "
> > -   "status=%d, port=%d, opcode=%d, len=%d, "
> > -   "actual_length=%d, status=%d\n", __func__, status,
> > -   priv->dp_port_num, opcode, len, urb->actual_length,
> > -   port_status);
> > +   dev_err(>dev, "malformed packet received: port=%d, 
> > opcode=%d, len=%d, actual_length=%u\n",
> > +   priv->dp_port_num, opcode, len, urb->actual_length);
> > +   return -1;
> 
> Same here and elsewhere in this patch.

As the OOB function in the previous patch, this one is also documented
as returning -1 on sanity-check failures so I'm not changing that
behaviour now.

Also note that the return value is only checked against zero and never
used for anything else currently.

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 1/3] USB: serial: digi_acceleport: fix OOB data sanity check

[Johan Hovold]

On Tue, Jan 31, 2017 at 05:38:58PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 31, 2017 at 05:17:27PM +0100, Johan Hovold wrote:
> > Make sure to check for short transfers to avoid underflow in a loop
> > condition when parsing the receive buffer.
> > 
> > Also fix an off-by-one error in the incomplete sanity check which could
> > lead to invalid data being parsed.
> > 
> > Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Cc: stable  # v2.6.30
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/usb/serial/digi_acceleport.c | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/usb/serial/digi_acceleport.c 
> > b/drivers/usb/serial/digi_acceleport.c
> > index 6a1df9e824ca..3b610f1e3f7c 100644
> > --- a/drivers/usb/serial/digi_acceleport.c
> > +++ b/drivers/usb/serial/digi_acceleport.c
> > @@ -1482,16 +1482,20 @@ static int digi_read_oob_callback(struct urb *urb)
> > struct usb_serial *serial = port->serial;
> > struct tty_struct *tty;
> > struct digi_port *priv = usb_get_serial_port_data(port);
> > +   unsigned char *buf = urb->transfer_buffer;
> > int opcode, line, status, val;
> > int i;
> > unsigned int rts;
> >  
> > +   if (urb->actual_length < 4)
> > +   return -1;
> 
> A real error number perhaps?

Yeah, that was my inclination too, but the function is documented as
returning -1 when the sanity checks fail so I stuck to that for now:

/*
 *  Digi Read OOB Callback
 *
 *  Digi Read OOB Callback handles reads on the out of band port.
 *  When called we know port and port->private are not NULL and
 *  the port->serial is valid.  It returns 0 if successful, and
 *  -1 if the sanity checks failed.
 */

> > +
> > /* handle each oob command */
> > -   for (i = 0; i < urb->actual_length - 3;) {
> > -   opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> > -   line = ((unsigned char *)urb->transfer_buffer)[i++];
> > -   status = ((unsigned char *)urb->transfer_buffer)[i++];
> > -   val = ((unsigned char *)urb->transfer_buffer)[i++];
> > +   for (i = 0; i < urb->actual_length - 4; i += 4) {
> > +   opcode = buf[i];
> > +   line = buf[i + 1];
> > +   status = buf[i + 2];
> > +   val = buf[i + 3];
> 
> Other than that nit, looks good, thanks for fixing my really old bugs :)
> 
> Reviewed-by: Greg Kroah-Hartman 

Thanks for the review.

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 2/3] USB: serial: digi_acceleport: fix incomplete rx sanity check

[Greg KH]

On Tue, Jan 31, 2017 at 05:17:28PM +0100, Johan Hovold wrote:
> Make sure the received data has the required headers before parsing it.
> 
> Also drop the redundant urb-status check, which has already been handled
> by the caller.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/digi_acceleport.c | 38 
> ++--
>  1 file changed, 23 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/usb/serial/digi_acceleport.c 
> b/drivers/usb/serial/digi_acceleport.c
> index 3b610f1e3f7c..eb433922598c 100644
> --- a/drivers/usb/serial/digi_acceleport.c
> +++ b/drivers/usb/serial/digi_acceleport.c
> @@ -1398,25 +1398,30 @@ static int digi_read_inb_callback(struct urb *urb)
>  {
>   struct usb_serial_port *port = urb->context;
>   struct digi_port *priv = usb_get_serial_port_data(port);
> - int opcode = ((unsigned char *)urb->transfer_buffer)[0];
> - int len = ((unsigned char *)urb->transfer_buffer)[1];
> - int port_status = ((unsigned char *)urb->transfer_buffer)[2];
> - unsigned char *data = ((unsigned char *)urb->transfer_buffer) + 3;
> + unsigned char *buf = urb->transfer_buffer;
> + int opcode;
> + int len;
> + int port_status;
> + unsigned char *data;
>   int flag, throttled;
> - int status = urb->status;
> -
> - /* do not process callbacks on closed ports */
> - /* but do continue the read chain */
> - if (urb->status == -ENOENT)
> - return 0;
>  
>   /* short/multiple packet check */
> + if (urb->actual_length < 2) {
> + dev_warn(>dev, "short packet received\n");
> + return -1;

Again, real error number?  -EINVAL?  -EIO?

> + }
> +
> + opcode = buf[0];
> + len = buf[1];
> +
>   if (urb->actual_length != len + 2) {
> - dev_err(>dev, "%s: INCOMPLETE OR MULTIPLE PACKET, "
> - "status=%d, port=%d, opcode=%d, len=%d, "
> - "actual_length=%d, status=%d\n", __func__, status,
> - priv->dp_port_num, opcode, len, urb->actual_length,
> - port_status);
> + dev_err(>dev, "malformed packet received: port=%d, 
> opcode=%d, len=%d, actual_length=%u\n",
> + priv->dp_port_num, opcode, len, urb->actual_length);
> + return -1;

Same here and elsewhere in this patch.

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: [PATCH] Subject: usb/serial/pl2303 add ATEN device ID

[Johan Hovold]

On Mon, Jan 30, 2017 at 07:26:40PM +0100, Marcel J.E. Mol wrote:
> 
> Seems that ATEN serial-to-usb devices using pl2303 exist with
> different device ids. This patch adds a missing device ID so it
> is recognised by the driver.
> 
> Signed-off-by: Marcel J.E. Mol 
> ---

Thanks for the patch. I dropped that stray "Subject: " from the commit
summary and changed it to

"USB: serial: pl2303: add ATEN device ID"

before applying.

When replying to this one the first time I noticed that you'd also
gotten the linux-usb mailing list address wrong. Fixed up and resent
with full context now.

Johan

>  drivers/usb/serial/pl2303.c | 2 ++
>  drivers/usb/serial/pl2303.h | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index 46fca6b..8e61975 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -49,7 +49,8 @@ static const struct usb_device_id id_table[] = {
>   { USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID) },
>   { USB_DEVICE(IODATA_VENDOR_ID, IODATA_PRODUCT_ID_RSAQ5) },
>   { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID) },
> + { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
>   { USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
>   { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
>   { USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID_UCSGT) },
>   { USB_DEVICE(ITEGNO_VENDOR_ID, ITEGNO_PRODUCT_ID) },
> diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
> index e3b7af8..09d9be8 100644
> --- a/drivers/usb/serial/pl2303.h
> +++ b/drivers/usb/serial/pl2303.h
> @@ -27,6 +27,7 @@
>  #define ATEN_VENDOR_ID   0x0557
>  #define ATEN_VENDOR_ID2  0x0547
>  #define ATEN_PRODUCT_ID  0x2008
> +#define ATEN_PRODUCT_ID2 0x2118
>  
>  #define IODATA_VENDOR_ID 0x04bb
>  #define IODATA_PRODUCT_ID0x0a03
--
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 3/3] USB: serial: keyspan_pda: fix receive sanity checks

[Greg KH]

On Tue, Jan 31, 2017 at 05:17:29PM +0100, Johan Hovold wrote:
> Make sure to check for short transfers before parsing the receive buffer
> to avoid acting on stale data.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/keyspan_pda.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/serial/keyspan_pda.c 
> b/drivers/usb/serial/keyspan_pda.c
> index 83523fcf6fb9..d2dab2a341b8 100644
> --- a/drivers/usb/serial/keyspan_pda.c
> +++ b/drivers/usb/serial/keyspan_pda.c
> @@ -139,6 +139,7 @@ static void keyspan_pda_rx_interrupt(struct urb *urb)
>  {
>   struct usb_serial_port *port = urb->context;
>   unsigned char *data = urb->transfer_buffer;
> + unsigned int len = urb->actual_length;
>   int retval;
>   int status = urb->status;
>   struct keyspan_pda_private *priv;
> @@ -159,18 +160,26 @@ static void keyspan_pda_rx_interrupt(struct urb *urb)
>   goto exit;
>   }
>  
> + if (len < 1) {
> + dev_warn(>dev, "short message received\n");
> + goto exit;
> + }
> +
>   /* see if the message is data or a status interrupt */
>   switch (data[0]) {
>   case 0:
>/* rest of message is rx data */
> - if (urb->actual_length) {
> - tty_insert_flip_string(>port, data + 1,
> - urb->actual_length - 1);
> - tty_flip_buffer_push(>port);
> - }
> + if (len < 2)
> + break;
> + tty_insert_flip_string(>port, data + 1, len - 1);
> + tty_flip_buffer_push(>port);
>   break;
>   case 1:
>   /* status interrupt */
> + if (len < 3) {
> + dev_warn(>dev, "short interrupt message 
> received\n");
> + break;
> + }
>   dev_dbg(>dev, "rx int, d1=%d, d2=%d\n", data[1], data[2]);
>   switch (data[1]) {
>   case 1: /* modemline change */
> -- 
> 2.10.2

Reviewed-by: Greg Kroah-Hartman 
--
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: gadget: function: f_fs: pass companion descriptor along

[Krzysztof Opasiak]

On 01/31/2017 04:56 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Krzysztof Opasiak  writes:
>> On 01/31/2017 02:08 PM, Felipe Balbi wrote:
>>> If we're dealing with SuperSpeed endpoints, we need
>>> to make sure to pass along the companion descriptor
>>> and initialize fields needed by the Gadget
>>> API. Eventually, f_fs.c should be converted to use
>>> config_ep_by_speed() like all other functions,
>>> though.
>>>
>>> Cc: 
>>> Signed-off-by: Felipe Balbi 
>>> ---
>>>
>>> Will be sent in a pull request during v4.11-rc
>>>
>>>  drivers/usb/gadget/function/f_fs.c | 15 +--
>>>  1 file changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/function/f_fs.c 
>>> b/drivers/usb/gadget/function/f_fs.c
>>> index 87fccf611b69..86aba2ebb3ef 100644
>>> --- a/drivers/usb/gadget/function/f_fs.c
>>> +++ b/drivers/usb/gadget/function/f_fs.c
>>> @@ -1833,11 +1833,14 @@ static int ffs_func_eps_enable(struct ffs_function 
>>> *func)
>>> spin_lock_irqsave(>ffs->eps_lock, flags);
>>> while(count--) {
>>> struct usb_endpoint_descriptor *ds;
>>> +   struct usb_ss_ep_comp_descriptor *comp_desc = NULL;
>>> +   int needs_comp_desc = false;
>>> int desc_idx;
>>>  
>>> -   if (ffs->gadget->speed == USB_SPEED_SUPER)
>>> +   if (ffs->gadget->speed == USB_SPEED_SUPER) {
>>> desc_idx = 2;
>>> -   else if (ffs->gadget->speed == USB_SPEED_HIGH)
>>> +   needs_comp_desc = true;
>>> +   } else if (ffs->gadget->speed == USB_SPEED_HIGH)
>>> desc_idx = 1;
>>> else
>>> desc_idx = 0;
>>> @@ -1854,6 +1857,14 @@ static int ffs_func_eps_enable(struct ffs_function 
>>> *func)
>>>  
>>> ep->ep->driver_data = ep;
>>> ep->ep->desc = ds;
>>> +
>>> +   comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
>>> +   USB_DT_ENDPOINT_SIZE);
>>> +   ep->ep->maxburst = comp_desc->bMaxBurst + 1;
>>> +
>>> +   if (needs_comp_desc)
>>> +   ep->ep->comp_desc = comp_desc;
>>> +
>>
>> Please correct me if I'm wrong but wouldn't we read rubbish here if user
>> provided us SS ep descriptor without companion descriptor?
> 
> companion desc is required for SS endpoints, it's also required that
> they follow EP desc. If user doesn't write it, don't they deserve the
> errors they'll have?
> 

But do we deserve to access potentially unallocated memory inside kernel
each time when some malicious application requests this?;)

In my humble opinion user should get -EINVAL or sth like this from
write(desc, sizeof(desc)) instead of some random data in companion
descriptor.

Cheers,
-- 
Krzysztof Opasiak
Samsung R 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 1/3] USB: serial: digi_acceleport: fix OOB data sanity check

[Greg KH]

On Tue, Jan 31, 2017 at 05:17:27PM +0100, Johan Hovold wrote:
> Make sure to check for short transfers to avoid underflow in a loop
> condition when parsing the receive buffer.
> 
> Also fix an off-by-one error in the incomplete sanity check which could
> lead to invalid data being parsed.
> 
> Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable    # v2.6.30
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/digi_acceleport.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/serial/digi_acceleport.c 
> b/drivers/usb/serial/digi_acceleport.c
> index 6a1df9e824ca..3b610f1e3f7c 100644
> --- a/drivers/usb/serial/digi_acceleport.c
> +++ b/drivers/usb/serial/digi_acceleport.c
> @@ -1482,16 +1482,20 @@ static int digi_read_oob_callback(struct urb *urb)
>   struct usb_serial *serial = port->serial;
>   struct tty_struct *tty;
>   struct digi_port *priv = usb_get_serial_port_data(port);
> + unsigned char *buf = urb->transfer_buffer;
>   int opcode, line, status, val;
>   int i;
>   unsigned int rts;
>  
> + if (urb->actual_length < 4)
> + return -1;

A real error number perhaps?

> +
>   /* handle each oob command */
> - for (i = 0; i < urb->actual_length - 3;) {
> - opcode = ((unsigned char *)urb->transfer_buffer)[i++];
> - line = ((unsigned char *)urb->transfer_buffer)[i++];
> - status = ((unsigned char *)urb->transfer_buffer)[i++];
> - val = ((unsigned char *)urb->transfer_buffer)[i++];
> + for (i = 0; i < urb->actual_length - 4; i += 4) {
> + opcode = buf[i];
> + line = buf[i + 1];
> + status = buf[i + 2];
> + val = buf[i + 3];

Other than that nit, looks good, thanks for fixing my really old bugs :)

Reviewed-by: Greg Kroah-Hartman 

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

[PATCH 3/3] USB: serial: keyspan_pda: fix receive sanity checks

[Johan Hovold]

Make sure to check for short transfers before parsing the receive buffer
to avoid acting on stale data.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/keyspan_pda.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/serial/keyspan_pda.c b/drivers/usb/serial/keyspan_pda.c
index 83523fcf6fb9..d2dab2a341b8 100644
--- a/drivers/usb/serial/keyspan_pda.c
+++ b/drivers/usb/serial/keyspan_pda.c
@@ -139,6 +139,7 @@ static void keyspan_pda_rx_interrupt(struct urb *urb)
 {
struct usb_serial_port *port = urb->context;
unsigned char *data = urb->transfer_buffer;
+   unsigned int len = urb->actual_length;
int retval;
int status = urb->status;
struct keyspan_pda_private *priv;
@@ -159,18 +160,26 @@ static void keyspan_pda_rx_interrupt(struct urb *urb)
goto exit;
}
 
+   if (len < 1) {
+   dev_warn(>dev, "short message received\n");
+   goto exit;
+   }
+
/* see if the message is data or a status interrupt */
switch (data[0]) {
case 0:
 /* rest of message is rx data */
-   if (urb->actual_length) {
-   tty_insert_flip_string(>port, data + 1,
-   urb->actual_length - 1);
-   tty_flip_buffer_push(>port);
-   }
+   if (len < 2)
+   break;
+   tty_insert_flip_string(>port, data + 1, len - 1);
+   tty_flip_buffer_push(>port);
break;
case 1:
/* status interrupt */
+   if (len < 3) {
+   dev_warn(>dev, "short interrupt message 
received\n");
+   break;
+   }
dev_dbg(>dev, "rx int, d1=%d, d2=%d\n", data[1], data[2]);
switch (data[1]) {
case 1: /* modemline change */
-- 
2.10.2

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

[PATCH 1/3] USB: serial: digi_acceleport: fix OOB data sanity check

[Johan Hovold]

Make sure to check for short transfers to avoid underflow in a loop
condition when parsing the receive buffer.

Also fix an off-by-one error in the incomplete sanity check which could
lead to invalid data being parsed.

Fixes: 8c209e6782ca ("USB: make actual_length in struct urb field u32")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable  # v2.6.30
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/digi_acceleport.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/serial/digi_acceleport.c 
b/drivers/usb/serial/digi_acceleport.c
index 6a1df9e824ca..3b610f1e3f7c 100644
--- a/drivers/usb/serial/digi_acceleport.c
+++ b/drivers/usb/serial/digi_acceleport.c
@@ -1482,16 +1482,20 @@ static int digi_read_oob_callback(struct urb *urb)
struct usb_serial *serial = port->serial;
struct tty_struct *tty;
struct digi_port *priv = usb_get_serial_port_data(port);
+   unsigned char *buf = urb->transfer_buffer;
int opcode, line, status, val;
int i;
unsigned int rts;
 
+   if (urb->actual_length < 4)
+   return -1;
+
/* handle each oob command */
-   for (i = 0; i < urb->actual_length - 3;) {
-   opcode = ((unsigned char *)urb->transfer_buffer)[i++];
-   line = ((unsigned char *)urb->transfer_buffer)[i++];
-   status = ((unsigned char *)urb->transfer_buffer)[i++];
-   val = ((unsigned char *)urb->transfer_buffer)[i++];
+   for (i = 0; i < urb->actual_length - 4; i += 4) {
+   opcode = buf[i];
+   line = buf[i + 1];
+   status = buf[i + 2];
+   val = buf[i + 3];
 
dev_dbg(>dev, "digi_read_oob_callback: opcode=%d, 
line=%d, status=%d, val=%d\n",
opcode, line, status, val);
-- 
2.10.2

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

[PATCH 2/3] USB: serial: digi_acceleport: fix incomplete rx sanity check

[Johan Hovold]

Make sure the received data has the required headers before parsing it.

Also drop the redundant urb-status check, which has already been handled
by the caller.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/digi_acceleport.c | 38 ++--
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/serial/digi_acceleport.c 
b/drivers/usb/serial/digi_acceleport.c
index 3b610f1e3f7c..eb433922598c 100644
--- a/drivers/usb/serial/digi_acceleport.c
+++ b/drivers/usb/serial/digi_acceleport.c
@@ -1398,25 +1398,30 @@ static int digi_read_inb_callback(struct urb *urb)
 {
struct usb_serial_port *port = urb->context;
struct digi_port *priv = usb_get_serial_port_data(port);
-   int opcode = ((unsigned char *)urb->transfer_buffer)[0];
-   int len = ((unsigned char *)urb->transfer_buffer)[1];
-   int port_status = ((unsigned char *)urb->transfer_buffer)[2];
-   unsigned char *data = ((unsigned char *)urb->transfer_buffer) + 3;
+   unsigned char *buf = urb->transfer_buffer;
+   int opcode;
+   int len;
+   int port_status;
+   unsigned char *data;
int flag, throttled;
-   int status = urb->status;
-
-   /* do not process callbacks on closed ports */
-   /* but do continue the read chain */
-   if (urb->status == -ENOENT)
-   return 0;
 
/* short/multiple packet check */
+   if (urb->actual_length < 2) {
+   dev_warn(>dev, "short packet received\n");
+   return -1;
+   }
+
+   opcode = buf[0];
+   len = buf[1];
+
if (urb->actual_length != len + 2) {
-   dev_err(>dev, "%s: INCOMPLETE OR MULTIPLE PACKET, "
-   "status=%d, port=%d, opcode=%d, len=%d, "
-   "actual_length=%d, status=%d\n", __func__, status,
-   priv->dp_port_num, opcode, len, urb->actual_length,
-   port_status);
+   dev_err(>dev, "malformed packet received: port=%d, 
opcode=%d, len=%d, actual_length=%u\n",
+   priv->dp_port_num, opcode, len, urb->actual_length);
+   return -1;
+   }
+
+   if (opcode == DIGI_CMD_RECEIVE_DATA && len < 1) {
+   dev_err(>dev, "malformed data packet received\n");
return -1;
}
 
@@ -1430,6 +1435,9 @@ static int digi_read_inb_callback(struct urb *urb)
 
/* receive data */
if (opcode == DIGI_CMD_RECEIVE_DATA) {
+   port_status = buf[2];
+   data = [3];
+
/* get flag from port_status */
flag = 0;
 
-- 
2.10.2

--
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/3] USB: serial: ark3116: fix endpoint-check return value

[Johan Hovold]

On Tue, Jan 31, 2017 at 03:35:54PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 31, 2017 at 11:51:07AM +0100, Johan Hovold wrote:
> > Return -ENODEV rather than -EINVAL on probe errors due to a missing
> > endpoint.
> > 
> > Also clean up the endpoint sanity check somewhat and use the interface
> > device for logging a more compact error in case an expected endpoint is
> > missing.
> > 
> > Signed-off-by: Johan Hovold 
> 
> Reviewed-by: Greg Kroah-Hartman 

Thanks for the review. Series now applied.

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 2/2] usb: gadget: function: f_fs: pass companion descriptor along

[Felipe Balbi]

Hi,

Krzysztof Opasiak  writes:
> On 01/31/2017 02:08 PM, Felipe Balbi wrote:
>> If we're dealing with SuperSpeed endpoints, we need
>> to make sure to pass along the companion descriptor
>> and initialize fields needed by the Gadget
>> API. Eventually, f_fs.c should be converted to use
>> config_ep_by_speed() like all other functions,
>> though.
>> 
>> Cc: 
>> Signed-off-by: Felipe Balbi 
>> ---
>> 
>> Will be sent in a pull request during v4.11-rc
>> 
>>  drivers/usb/gadget/function/f_fs.c | 15 +--
>>  1 file changed, 13 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/usb/gadget/function/f_fs.c 
>> b/drivers/usb/gadget/function/f_fs.c
>> index 87fccf611b69..86aba2ebb3ef 100644
>> --- a/drivers/usb/gadget/function/f_fs.c
>> +++ b/drivers/usb/gadget/function/f_fs.c
>> @@ -1833,11 +1833,14 @@ static int ffs_func_eps_enable(struct ffs_function 
>> *func)
>>  spin_lock_irqsave(>ffs->eps_lock, flags);
>>  while(count--) {
>>  struct usb_endpoint_descriptor *ds;
>> +struct usb_ss_ep_comp_descriptor *comp_desc = NULL;
>> +int needs_comp_desc = false;
>>  int desc_idx;
>>  
>> -if (ffs->gadget->speed == USB_SPEED_SUPER)
>> +if (ffs->gadget->speed == USB_SPEED_SUPER) {
>>  desc_idx = 2;
>> -else if (ffs->gadget->speed == USB_SPEED_HIGH)
>> +needs_comp_desc = true;
>> +} else if (ffs->gadget->speed == USB_SPEED_HIGH)
>>  desc_idx = 1;
>>  else
>>  desc_idx = 0;
>> @@ -1854,6 +1857,14 @@ static int ffs_func_eps_enable(struct ffs_function 
>> *func)
>>  
>>  ep->ep->driver_data = ep;
>>  ep->ep->desc = ds;
>> +
>> +comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
>> +USB_DT_ENDPOINT_SIZE);
>> +ep->ep->maxburst = comp_desc->bMaxBurst + 1;
>> +
>> +if (needs_comp_desc)
>> +ep->ep->comp_desc = comp_desc;
>> +
>
> Please correct me if I'm wrong but wouldn't we read rubbish here if user
> provided us SS ep descriptor without companion descriptor?

companion desc is required for SS endpoints, it's also required that
they follow EP desc. If user doesn't write it, don't they deserve the
errors they'll have?

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

Re: [PATCH 2/2] usb: gadget: function: f_fs: pass companion descriptor along

[Krzysztof Opasiak]

On 01/31/2017 02:08 PM, Felipe Balbi wrote:
> If we're dealing with SuperSpeed endpoints, we need
> to make sure to pass along the companion descriptor
> and initialize fields needed by the Gadget
> API. Eventually, f_fs.c should be converted to use
> config_ep_by_speed() like all other functions,
> though.
> 
> Cc: 
> Signed-off-by: Felipe Balbi 
> ---
> 
> Will be sent in a pull request during v4.11-rc
> 
>  drivers/usb/gadget/function/f_fs.c | 15 +--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_fs.c 
> b/drivers/usb/gadget/function/f_fs.c
> index 87fccf611b69..86aba2ebb3ef 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -1833,11 +1833,14 @@ static int ffs_func_eps_enable(struct ffs_function 
> *func)
>   spin_lock_irqsave(>ffs->eps_lock, flags);
>   while(count--) {
>   struct usb_endpoint_descriptor *ds;
> + struct usb_ss_ep_comp_descriptor *comp_desc = NULL;
> + int needs_comp_desc = false;
>   int desc_idx;
>  
> - if (ffs->gadget->speed == USB_SPEED_SUPER)
> + if (ffs->gadget->speed == USB_SPEED_SUPER) {
>   desc_idx = 2;
> - else if (ffs->gadget->speed == USB_SPEED_HIGH)
> + needs_comp_desc = true;
> + } else if (ffs->gadget->speed == USB_SPEED_HIGH)
>   desc_idx = 1;
>   else
>   desc_idx = 0;
> @@ -1854,6 +1857,14 @@ static int ffs_func_eps_enable(struct ffs_function 
> *func)
>  
>   ep->ep->driver_data = ep;
>   ep->ep->desc = ds;
> +
> + comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
> + USB_DT_ENDPOINT_SIZE);
> + ep->ep->maxburst = comp_desc->bMaxBurst + 1;
> +
> + if (needs_comp_desc)
> + ep->ep->comp_desc = comp_desc;
> +

Please correct me if I'm wrong but wouldn't we read rubbish here if user
provided us SS ep descriptor without companion descriptor?


Best regards,
-- 
Krzysztof Opasiak
Samsung R 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

Using functionfs results in use-after-free reported by kasan

[Fabian Vogt]

Hi everyone,

I'm using usb functionfs for fuzzing host hardware here and so far found
two issues on the gadget side (which it wasn't intended for, but any
found bug counts!).

The first one turned out to be fixed by
08f37148b6a915a6996c7dbef87769b9efee2dba 'usb: gadget: f_fs: Fix iterations on 
endpoints.'
recently while the second issue still appears reliably after every use of ffs.

The dmesg output below is with configfs, but it's also reproducible with g_ffs:

modprobe g_ffs idVendor=1234 functions=hid
mkdir -p /tmp/ffs
mount -t functionfs hid /tmp/ffs
cat ep0descs ep0strs > /tmp/ffs/ep0
umount /tmp/ffs
rmmod g_ffs

(the contents of ep0{descs,strs} do not matter as long as they are valid)

So far I see this in 100% of all runs on x86_64 and aarch64.

[ 1690.458191] file system registered
[ 1690.491261] read descriptors
[ 1690.495972] read strings
[ 1738.763997] ffs_data_put(): freeing
[ 1738.768707] 
==
[ 1738.769973] BUG: KASAN: use-after-free in ffs_free_inst+0xe3/0x160 
[usb_f_fs] at addr 88006af3d168
[ 1738.771421] Write of size 8 by task usbredir2phys/1495
[ 1738.772246] CPU: 0 PID: 1495 Comm: usbredir2phys Not tainted 
4.10.0-rc6-default #27
[ 1738.773444] Call Trace:
[ 1738.773858]  dump_stack+0x63/0x8f
[ 1738.774396]  kasan_object_err+0x21/0x70
[ 1738.775013]  kasan_report_error+0x1c9/0x4e0
[ 1738.775683]  ? __rcu_read_unlock+0x6d/0x90
[ 1738.776345]  kasan_report+0x39/0x40
[ 1738.776915]  ? ffs_free_inst+0xe3/0x160 [usb_f_fs]
[ 1738.777685]  __asan_store8+0x61/0x70
[ 1738.778271]  ffs_free_inst+0xe3/0x160 [usb_f_fs]
[ 1738.779020]  usb_put_function_instance+0x4b/0x60 [libcomposite]
[ 1738.779965]  ffs_attr_release+0xe/0x10 [usb_f_fs]
[ 1738.780725]  config_item_release+0x9b/0x110 [configfs]
[ 1738.781545]  config_item_put+0x23/0x30 [configfs]
[ 1738.782373]  configfs_rmdir+0x2fa/0x4e0 [configfs]
[ 1738.783141]  ? configfs_unregister_subsystem+0x1b0/0x1b0 [configfs]
[ 1738.784130]  ? may_delete+0x1bd/0x240
[ 1738.784719]  vfs_rmdir+0x109/0x1c0
[ 1738.785268]  do_rmdir+0x35b/0x370
[ 1738.785816]  ? user_path_create+0x40/0x40
[ 1738.786479]  ? syscall_trace_enter+0x27d/0x520
[ 1738.787202]  ? exit_to_usermode_loop+0xd0/0xd0
[ 1738.787923]  ? __audit_syscall_exit+0x3fe/0x4a0
[ 1738.788659]  ? SyS_mkdir+0x1a0/0x1a0
[ 1738.789238]  SyS_rmdir+0x16/0x20
[ 1738.789783]  do_syscall_64+0xe0/0x180
[ 1738.790399]  entry_SYSCALL64_slow_path+0x25/0x25
[ 1738.791136] RIP: 0033:0x7fcb48fccf17
[ 1738.791712] RSP: 002b:7fffbc0c3d88 EFLAGS: 0246 ORIG_RAX: 
0054
[ 1738.792908] RAX: ffda RBX: 7fffbc0c3d90 RCX: 7fcb48fccf17
[ 1738.794299] RDX: 0038 RSI: 7fcb49f6b774 RDI: 7fffbc0c3d90
[ 1738.795439] RBP:  R08: 02514660 R09: 0038
[ 1738.796567] R10: 0073 R11: 0246 R12: 02513c20
[ 1738.797789] R13: 0001 R14: 02514030 R15: 
[ 1738.798925] Object at 88006af3d0c0, in cache kmalloc-512 size: 512
[ 1738.799949] Allocated:
[ 1738.800334] PID = 1498
[ 1738.800715]  
[ 1738.800722] [] save_stack_trace+0x1b/0x20
[ 1738.801886]  
[ 1738.801893] [] save_stack+0x46/0xd0
[ 1738.802961]  
[ 1738.802968] [] kasan_kmalloc+0xad/0xe0
[ 1738.804076]  
[ 1738.804083] [] kmem_cache_alloc_trace+0xd5/0x5f0
[ 1738.805334]  
[ 1738.805346] [] ffs_fs_mount+0x20a/0x6a0 [usb_f_fs]
[ 1738.806656]  
[ 1738.806665] [] mount_fs+0x5e/0x1a0
[ 1738.807720]  
[ 1738.807729] [] vfs_kern_mount+0x6b/0x1c0
[ 1738.808877]  
[ 1738.808883] [] do_mount+0x30d/0x1590
[ 1738.809991]  
[ 1738.809997] [] SyS_mount+0x83/0xd0
[ 1738.811049]  
[ 1738.811055] [] do_syscall_64+0xe0/0x180
[ 1738.812178]  
[ 1738.812185] [] return_from_SYSCALL_64+0x0/0x6a
[ 1738.813399] Freed:
[ 1738.813754] PID = 1559
[ 1738.814141]  
[ 1738.814146] [] save_stack_trace+0x1b/0x20
[ 1738.815301]  
[ 1738.815307] [] save_stack+0x46/0xd0
[ 1738.816498]  
[ 1738.816503] [] kasan_slab_free+0x72/0xc0
[ 1738.817659]  
[ 1738.817665] [] kfree+0x82/0x110
[ 1738.818725]  
[ 1738.818736] [] ffs_data_put+0x82/0x90 [usb_f_fs]
[ 1738.819997]  
[ 1738.820009] [] ffs_data_closed+0xff/0x110 [usb_f_fs]
[ 1738.821369]  
[ 1738.821380] [] ffs_fs_kill_sb+0x4f/0x70 [usb_f_fs]
[ 1738.822668]  
[ 1738.822675] [] deactivate_locked_super+0x59/0x90
[ 1738.824056]  
[ 1738.824063] [] deactivate_super+0x6a/0x70
[ 1738.825227]  
[ 1738.825234] [] cleanup_mnt+0x61/0xb0
[ 1738.826338]  
[ 1738.826345] [] __cleanup_mnt+0x12/0x20
[ 1738.827453]  
[ 1738.827460] [] task_work_run+0xa0/0xc0
[ 1738.828564]  
[ 1738.828570] [] exit_to_usermode_loop+0xc5/0xd0
[ 1738.829818]  
[ 1738.829824] [] do_syscall_64+0x174/0x180
[ 1738.830961]  
[ 1738.830968] [] return_from_SYSCALL_64+0x0/0x6a
[ 1738.832196] Memory state around the buggy address:
[ 1738.832967]  88006af3d000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 
fc
[ 1738.834143]  88006af3d080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb 

Re: [PATCH 1/3] USB: serial: ark3116: fix endpoint-check return value

[Greg KH]

On Tue, Jan 31, 2017 at 11:51:07AM +0100, Johan Hovold wrote:
> Return -ENODEV rather than -EINVAL on probe errors due to a missing
> endpoint.
> 
> Also clean up the endpoint sanity check somewhat and use the interface
> device for logging a more compact error in case an expected endpoint is
> missing.
> 
> Signed-off-by: Johan Hovold 


Reviewed-by: Greg Kroah-Hartman 
--
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/3] USB: serial: ark3116: remove redundant interrupt-urb check

[Greg KH]

On Tue, Jan 31, 2017 at 11:51:08AM +0100, Johan Hovold wrote:
> Remove redundant check of num_interrupt_in which has already been
> verified in probe (killing a NULL-urb would also have been fine).
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/ark3116.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Greg Kroah-Hartman 

--
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 3/3] USB: serial: ark3116: use port device for info and error messages

[Greg KH]

On Tue, Jan 31, 2017 at 11:51:09AM +0100, Johan Hovold wrote:
> Use the port device rather than usb device in info and error messages.
> 
> This makes sure that driver and tty port is included in the messages,
> while also making them more uniform.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/ark3116.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)
> 

Reviewed-by: Greg Kroah-Hartman 

--
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: wait for end transfer to complete before disable irq

[Tomasz Medrek]

From: Chuansheng Liu 

Currently, in "for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++)",
it is waiting the DWC3_EP_END_TRANSFER_PENDING flag to be 0 which is
cleared in dwc3_endpoint_interrupt(). However, before that,the dwc3 irq
was disabled which reasult this flag will not be cleared.

This patch moves "for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++)"
ahead of "dwc3_gadget_disable_irq(dwc)" to fix this case.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Zhen Han 
---
 drivers/usb/dwc3/gadget.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 725b13a..d87825f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1845,8 +1845,6 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
if (pm_runtime_suspended(dwc->dev))
goto out;
 
-   __dwc3_gadget_stop(dwc);
-
for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
struct dwc3_ep  *dep = dwc->eps[epnum];
 
@@ -1861,6 +1859,8 @@ static int dwc3_gadget_stop(struct usb_gadget *g)
dwc->lock);
}
 
+   __dwc3_gadget_stop(dwc);
+
 out:
dwc->gadget_driver  = NULL;
spin_unlock_irqrestore(>lock, flags);
-- 
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: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

On 31/01/17 14:03, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
 -DALEPENA = 0x000f
 +DALEPENA = 0x
>>>
>>> Thanks for the hints.
>>>
>>> This problem is because reason dwc3_gadget_run_stop() is timing out
>>> during the suspend sequence and so dwc3_disconnect_gadget() and
>>> __dwc3_gadget_stop() are not being called.
>>
>> I see
>>
>>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>>> and happily continues suspending the machine.
>>>
>>> If I force dwc3_gadget_run_stop() to return 0 then everything works 
>>> fine.
>>>
>>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>>
>> no idea. It should always get set when run_stop is cleared. Can you
>> check if suspending with cable detached has any difference?
>
> After cable detach, it still timed out the next suspend. But on
> subsequent suspends there were no timeouts. (I didn't plug the cable
> back at all)
>
> This behaviour is on dra7. I will test the behaviour on am43x as well.

 wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
 testing that is, indeed, a good idea.
>>
>> Tried on am437x which is 2.40a but same timeout problem there as well.
>>
>>>
>>> What if your platform just takes longer to halt?
>>>
>>> Can you try below?
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 4db97ecae885..d2e405793b1f 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct 
>>> usb_gadget *g,
>>>  static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
>>>  {
>>> u32 reg;
>>> -   u32 timeout = 500;
>>> +   u32 timeout = 50;
>>>  
>>> if (pm_runtime_suspended(dwc->dev))
>>> return 0;
>>>
>>>
>>
>> Tried this but it doesn't resolve the issue.
> 
> Interesting. I have no idea what to try now. How about checking if that
> susphy quirk flags help? Maybe your platform can't accept PHY being
> suspended, or something.
> 

The susphy quirks are already enabled for both dra7 and am43 platforms.
I too don't have any clues as to what's going on. :(

-- 
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: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Mathias Nyman]

On 16.01.2017 12:56, Baolin Wang wrote:

Hi Mathias,


Hi

Sorry about the long review delay
CC Alan in case my pm assumptions need to be corrected



On 13 December 2016 at 15:49, Baolin Wang  wrote:

Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
Also call pm_runtime_get_noresume() in probe() function in case the parent
device doesn't call suspend/resume callback by runtime PM now.

Signed-off-by: Baolin Wang 
---
Changes since v4:
  - No updates.

Changes since v3:
  - Fix kbuild error.

Changes since v2:
  - Add pm_runtime_get_noresume() in probe() function.
  - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() function.

Changes since v1:
  - No updates.
---


Do you have any comments about this patch? Thanks.


  drivers/usb/host/xhci-plat.c |   41 -
  1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..5805c6a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 if (ret)
 goto dealloc_usb2_hcd;

+   pm_runtime_get_noresume(>dev);
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+
 return 0;




To me this looks like we are not really enabling runtime pm for xhci, we 
increment the
usage count in probe, and keep it until remove is called.

This would normally prevent parent dwc3 from runtime suspending, but I see that 
in patch 2/2 adds
pm_suspend_ignore_children(dev, true) to dwc3, and, that dwc3 actually controls 
xhci runtime
pm by calling pm_runtime_get/put for xhci in its own dwc3 
runtime_suspend/resume callbacks.

Looks a bit upside down to me, what's the reason for this?

what prevents calling pm_runtime_put_* before leaving probe in xhci and let pm 
code handle
the runtime suspend and parent/child relationships?

-Mathias

--
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: function: f_fs: pass companion descriptor along

[Felipe Balbi]

If we're dealing with SuperSpeed endpoints, we need
to make sure to pass along the companion descriptor
and initialize fields needed by the Gadget
API. Eventually, f_fs.c should be converted to use
config_ep_by_speed() like all other functions,
though.

Cc: 
Signed-off-by: Felipe Balbi 
---

Will be sent in a pull request during v4.11-rc

 drivers/usb/gadget/function/f_fs.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 87fccf611b69..86aba2ebb3ef 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1833,11 +1833,14 @@ static int ffs_func_eps_enable(struct ffs_function 
*func)
spin_lock_irqsave(>ffs->eps_lock, flags);
while(count--) {
struct usb_endpoint_descriptor *ds;
+   struct usb_ss_ep_comp_descriptor *comp_desc = NULL;
+   int needs_comp_desc = false;
int desc_idx;
 
-   if (ffs->gadget->speed == USB_SPEED_SUPER)
+   if (ffs->gadget->speed == USB_SPEED_SUPER) {
desc_idx = 2;
-   else if (ffs->gadget->speed == USB_SPEED_HIGH)
+   needs_comp_desc = true;
+   } else if (ffs->gadget->speed == USB_SPEED_HIGH)
desc_idx = 1;
else
desc_idx = 0;
@@ -1854,6 +1857,14 @@ static int ffs_func_eps_enable(struct ffs_function *func)
 
ep->ep->driver_data = ep;
ep->ep->desc = ds;
+
+   comp_desc = (struct usb_ss_ep_comp_descriptor *)(ds +
+   USB_DT_ENDPOINT_SIZE);
+   ep->ep->maxburst = comp_desc->bMaxBurst + 1;
+
+   if (needs_comp_desc)
+   ep->ep->comp_desc = comp_desc;
+
ret = usb_ep_enable(ep->ep);
if (likely(!ret)) {
epfile->ep = ep;
-- 
2.11.0.295.gd7dffce1ce

--
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] usb: dwc3: gadget: make Set Endpoint Configuration macros safe

[Felipe Balbi]

Some gadget drivers are bad, bad boys. We notice
that ADB was passing bad Burst Size which caused top
bits of param0 to be overwritten which confused DWC3
when running this command.

In order to avoid future issues, we're going to make
sure values passed by macros are always safe for the
controller. Note that ADB still needs a fix to *not*
pass bad values.

Cc:  # v3.2+
Reported-by: Mohamed Abbas 
Sugested-by: Adam Andruszak 
Signed-off-by: Felipe Balbi 
---

Will be sent in a pull request during v4.11-rc

 drivers/usb/dwc3/gadget.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
index 3129bcf74d7d..265e223ab645 100644
--- a/drivers/usb/dwc3/gadget.h
+++ b/drivers/usb/dwc3/gadget.h
@@ -28,23 +28,23 @@ struct dwc3;
 #define gadget_to_dwc(g)   (container_of(g, struct dwc3, gadget))
 
 /* DEPCFG parameter 1 */
-#define DWC3_DEPCFG_INT_NUM(n) ((n) << 0)
+#define DWC3_DEPCFG_INT_NUM(n) (((n) & 0x1f) << 0)
 #define DWC3_DEPCFG_XFER_COMPLETE_EN   (1 << 8)
 #define DWC3_DEPCFG_XFER_IN_PROGRESS_EN(1 << 9)
 #define DWC3_DEPCFG_XFER_NOT_READY_EN  (1 << 10)
 #define DWC3_DEPCFG_FIFO_ERROR_EN  (1 << 11)
 #define DWC3_DEPCFG_STREAM_EVENT_EN(1 << 13)
-#define DWC3_DEPCFG_BINTERVAL_M1(n)((n) << 16)
+#define DWC3_DEPCFG_BINTERVAL_M1(n)(((n) & 0xff) << 16)
 #define DWC3_DEPCFG_STREAM_CAPABLE (1 << 24)
-#define DWC3_DEPCFG_EP_NUMBER(n)   ((n) << 25)
+#define DWC3_DEPCFG_EP_NUMBER(n)   (((n) & 0x1f) << 25)
 #define DWC3_DEPCFG_BULK_BASED (1 << 30)
 #define DWC3_DEPCFG_FIFO_BASED (1 << 31)
 
 /* DEPCFG parameter 0 */
-#define DWC3_DEPCFG_EP_TYPE(n) ((n) << 1)
-#define DWC3_DEPCFG_MAX_PACKET_SIZE(n) ((n) << 3)
-#define DWC3_DEPCFG_FIFO_NUMBER(n) ((n) << 17)
-#define DWC3_DEPCFG_BURST_SIZE(n)  ((n) << 22)
+#define DWC3_DEPCFG_EP_TYPE(n) (((n) & 0x3) << 1)
+#define DWC3_DEPCFG_MAX_PACKET_SIZE(n) (((n) & 0x7ff) << 3)
+#define DWC3_DEPCFG_FIFO_NUMBER(n) (((n) & 0x1f) << 17)
+#define DWC3_DEPCFG_BURST_SIZE(n)  (((n) & 0xf) << 22)
 #define DWC3_DEPCFG_DATA_SEQ_NUM(n)((n) << 26)
 /* This applies for core versions earlier than 1.94a */
 #define DWC3_DEPCFG_IGN_SEQ_NUM(1 << 31)
-- 
2.11.0.295.gd7dffce1ce

--
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: linux USB dwc3 not working

[Felipe Balbi]

Hi Andy,

andy_purc...@keysight.com writes:
> Hello,
>
> I am starting work on a board that has the Intel Skylake chipset,
> which has hardware for doing USB-device.

Not all SKLs have dwc3 enabled. Can you provide the output of lspci?

> The Intel chipset USB-device hardware is the Synopsys DesignWare
> Controller 3, aka "dwc3".
>
> The Linux source tree has code for dwc3, so I thought to try running
> Linux on this board.
>
> The USB-device function is hard-wired on my board to be USB-device.
> Cannot be OTG. Cannot be USB-host.

fair enough

> I boot Ubuntu Desktop 16.04, kernel = 4.4.0-59, to test the USB-device 
> function.

I need to ask you to try a newer kernel. Can you try v4.9.6 or v4.10-rc6?

> Using a script, I set up the USB-device to be RNDIS, using functionfs.

functionfs needs a userspace component, do you have that? Can you try
any other gadget driver like mass storage, for instance? Here's a quick
script for mass storage:

#!/bin/sh

dd if=/dev/zero of=/dev/shm/file bs=1M count=1024

mount -t configfs none /c
mkdir /c/usb_gadget/g1
echo 0x18d1 > /c/usb_gadget/g1/idVendor
echo 0xbeef > /c/usb_gadget/g1/idProduct
mkdir /c/usb_gadget/g1/strings/0x409
echo 123456789012 > /c/usb_gadget/g1/strings/0x409/serialnumber
echo "Intel Corporation" > /c/usb_gadget/g1/strings/0x409/manufacturer
echo "Joule" > /c/usb_gadget/g1/strings/0x409/product
mkdir /c/usb_gadget/g1/functions/mass_storage.1
mkdir /c/usb_gadget/g1/configs/b.1
mkdir /c/usb_gadget/g1/configs/b.1/strings/0x409
echo 500 > /c/usb_gadget/g1/configs/b.1/MaxPower
echo /dev/shm/file > /c/usb_gadget/g1/functions/mass_storage.1/lun.0/file
ln -s /c/usb_gadget/g1/functions/mass_storage.1  /c/usb_gadget/g1/configs/b.1/f1
echo dwc3.0.auto > /c/usb_gadget/g1/UDC

> I connect a USB cable from my board to a USB-host. 
> My USB analyzer shows nothing happens. No connection, no SETUP
> packets, nothing.

right, I'm assuming you don't have userspace component for functionfs,
so ->pullup() is never called.

> To troubleshoot, I try turning on some test modes, using the Linux debugfs 
> interface.
> The debugfs interface is in this directory: 
>   /sys/kernel/debug/dwc3.0.auto 
> I see link_state, mode, regdump, testmode files. 

Can you also get the output of:

grep DCTL regdump

> * echo "test_j" > testmode
>   I see D+ go high, D- stays low. 
> * echo "test_k" > testmode
>   No change on D+
>   No change on D- 
>   This is not correct. 
> * echo "test_se0_nak" > testmode
>   No changes. 
> * echo "test_packet" 
>   D+ goes low, D- remains low. 
>
> OK, so here are my questions. 
>
> 1)Should I expect Ubuntu 16.04 dwc3 code to work? 
>   (uname -a shows kernel level is 4.4.0-59)  
>   I ask, because kernel.org shows recent changes in dwc3 code. 

if you enabled the driver, it should work, yes. Now we just need to make
you have all the other pieces.

> 2)The Linux dwc3 code appears to be written to work with several 
> different USB phy's. 
>   I see dwc3-exynos.c, dwc3-keystone.c, dwc3-omap.c, dwc3-pci.c, 
> dwc3-of-simple.c, etc. 
>   The schematic for my board shows there is no external USB2 phy and no 
> external USB3 phy.

you don't need to worry about that AFAICT :-)

>   For my board, the phy's are internal to the Skylake chipset.
>   a.  Should the Linux dwc3 code work without an external phy?
>   b.  Is there some configuration I need to do for my board?

most likely, no. BIOS is likely handling that for you.

-- 
balbi


signature.asc
Description: PGP signature

Re: dwc3 gadget breaks on system suspend/resume

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>>> -DALEPENA = 0x000f
>>> +DALEPENA = 0x
>>
>> Thanks for the hints.
>>
>> This problem is because reason dwc3_gadget_run_stop() is timing out
>> during the suspend sequence and so dwc3_disconnect_gadget() and
>> __dwc3_gadget_stop() are not being called.
>
> I see
>
>> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
>> and happily continues suspending the machine.
>>
>> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>>
>> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?
>
> no idea. It should always get set when run_stop is cleared. Can you
> check if suspending with cable detached has any difference?

 After cable detach, it still timed out the next suspend. But on
 subsequent suspends there were no timeouts. (I didn't plug the cable
 back at all)

 This behaviour is on dra7. I will test the behaviour on am43x as well.
>>>
>>> wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
>>> testing that is, indeed, a good idea.
>
> Tried on am437x which is 2.40a but same timeout problem there as well.
>
>> 
>> What if your platform just takes longer to halt?
>> 
>> Can you try below?
>> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 4db97ecae885..d2e405793b1f 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct 
>> usb_gadget *g,
>>  static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
>>  {
>> u32 reg;
>> -   u32 timeout = 500;
>> +   u32 timeout = 50;
>>  
>> if (pm_runtime_suspended(dwc->dev))
>> return 0;
>> 
>> 
>
> Tried this but it doesn't resolve the issue.

Interesting. I have no idea what to try now. How about checking if that
susphy quirk flags help? Maybe your platform can't accept PHY being
suspended, or something.

-- 
balbi


signature.asc
Description: PGP signature

Re: dwc3 gadget breaks on system suspend/resume

[Roger Quadros]

Hi,

On 30/01/17 15:47, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi  writes:
>> Roger Quadros  writes:
 Roger Quadros  writes:
>> (hmm, I didn't receive your reply in my intel inbox, only
>> gmail. Odd. Replying to myself here, but it should be on your reply,
>> rater).
>>
>> Felipe Balbi  writes:
 The previous commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 is fine.
>>>
>>> okay. Then let's try to figure out what's going on. A diff of regdump
>>> before and after suspend/resume might start to give some clue about
>>> what's going on. DWC3 tracepoints should help too. Care to get those?
>>> BTW, is this dwc3 as host or peripheral?
>>
>> You don't have any endpoints enabled:
>>
>> -DALEPENA = 0x000f
>> +DALEPENA = 0x
>
> Thanks for the hints.
>
> This problem is because reason dwc3_gadget_run_stop() is timing out
> during the suspend sequence and so dwc3_disconnect_gadget() and
> __dwc3_gadget_stop() are not being called.

 I see

> dwc3_suspend() does not consider dwc3_gadget_suspend()'s return value
> and happily continues suspending the machine.
>
> If I force dwc3_gadget_run_stop() to return 0 then everything works fine.
>
> Any ideas why DWC3_DSTS_DEVCTRLHLT is not getting set?

 no idea. It should always get set when run_stop is cleared. Can you
 check if suspending with cable detached has any difference?
>>>
>>> After cable detach, it still timed out the next suspend. But on
>>> subsequent suspends there were no timeouts. (I didn't plug the cable
>>> back at all)
>>>
>>> This behaviour is on dra7. I will test the behaviour on am43x as well.
>>
>> wonder if there's something odd with 2.02a. AM437x is 2.40a IIRC,
>> testing that is, indeed, a good idea.

Tried on am437x which is 2.40a but same timeout problem there as well.

> 
> What if your platform just takes longer to halt?
> 
> Can you try below?
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 4db97ecae885..d2e405793b1f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1586,7 +1586,7 @@ static int dwc3_gadget_set_selfpowered(struct 
> usb_gadget *g,
>  static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
>  {
> u32 reg;
> -   u32 timeout = 500;
> +   u32 timeout = 50;
>  
> if (pm_runtime_suspended(dwc->dev))
> return 0;
> 
> 

Tried this but it doesn't resolve the issue.

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

[PATCH 1/3] USB: serial: ark3116: fix endpoint-check return value

[Johan Hovold]

Return -ENODEV rather than -EINVAL on probe errors due to a missing
endpoint.

Also clean up the endpoint sanity check somewhat and use the interface
device for logging a more compact error in case an expected endpoint is
missing.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/ark3116.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c
index 754fc3e41005..d0fcff20ca7e 100644
--- a/drivers/usb/serial/ark3116.c
+++ b/drivers/usb/serial/ark3116.c
@@ -125,17 +125,11 @@ static inline int calc_divisor(int bps)
 static int ark3116_attach(struct usb_serial *serial)
 {
/* make sure we have our end-points */
-   if ((serial->num_bulk_in == 0) ||
-   (serial->num_bulk_out == 0) ||
-   (serial->num_interrupt_in == 0)) {
-   dev_err(>dev->dev,
-   "%s - missing endpoint - "
-   "bulk in: %d, bulk out: %d, int in %d\n",
-   KBUILD_MODNAME,
-   serial->num_bulk_in,
-   serial->num_bulk_out,
-   serial->num_interrupt_in);
-   return -EINVAL;
+   if (serial->num_bulk_in == 0 ||
+   serial->num_bulk_out == 0 ||
+   serial->num_interrupt_in == 0) {
+   dev_err(>interface->dev, "missing endpoint\n");
+   return -ENODEV;
}
 
return 0;
-- 
2.10.2

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

[PATCH 2/3] USB: serial: ark3116: remove redundant interrupt-urb check

[Johan Hovold]

Remove redundant check of num_interrupt_in which has already been
verified in probe (killing a NULL-urb would also have been fine).

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/ark3116.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c
index d0fcff20ca7e..e3f6a4e2e2ad 100644
--- a/drivers/usb/serial/ark3116.c
+++ b/drivers/usb/serial/ark3116.c
@@ -347,8 +347,8 @@ static void ark3116_close(struct usb_serial_port *port)
ark3116_write_reg(serial, UART_IER, 0);
 
usb_serial_generic_close(port);
-   if (serial->num_interrupt_in)
-   usb_kill_urb(port->interrupt_in_urb);
+
+   usb_kill_urb(port->interrupt_in_urb);
 }
 
 static int ark3116_open(struct tty_struct *tty, struct usb_serial_port *port)
-- 
2.10.2

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

[PATCH 3/3] USB: serial: ark3116: use port device for info and error messages

[Johan Hovold]

Use the port device rather than usb device in info and error messages.

This makes sure that driver and tty port is included in the messages,
while also making them more uniform.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/ark3116.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/serial/ark3116.c b/drivers/usb/serial/ark3116.c
index e3f6a4e2e2ad..2779e59c30f1 100644
--- a/drivers/usb/serial/ark3116.c
+++ b/drivers/usb/serial/ark3116.c
@@ -187,10 +187,8 @@ static int ark3116_port_probe(struct usb_serial_port *port)
if (priv->irda)
ark3116_write_reg(serial, 0x9, 0);
 
-   dev_info(>dev->dev,
-   "%s using %s mode\n",
-   KBUILD_MODNAME,
-   priv->irda ? "IrDA" : "RS232");
+   dev_info(>dev, "using %s mode\n", priv->irda ? "IrDA" : "RS232");
+
return 0;
 }
 
@@ -326,9 +324,8 @@ static void ark3116_set_termios(struct tty_struct *tty,
 
/* check for software flow control */
if (I_IXOFF(tty) || I_IXON(tty)) {
-   dev_warn(>dev->dev,
-"%s: don't know how to do software flow control\n",
-KBUILD_MODNAME);
+   dev_warn(>dev,
+   "software flow control not implemented\n");
}
 
/* Don't rewrite B0 */
@@ -616,9 +613,8 @@ static void ark3116_read_int_callback(struct urb *urb)
 
result = usb_submit_urb(urb, GFP_ATOMIC);
if (result)
-   dev_err(>dev->dev,
-   "%s - Error %d submitting interrupt urb\n",
-   __func__, result);
+   dev_err(>dev, "failed to resubmit interrupt urb: %d\n",
+   result);
 }
 
 
-- 
2.10.2

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

[bug report] usb: gadget: f_hid: fix: Move IN request allocation to set_alt()

[Dan Carpenter]

Hello Krzysztof Opasiak,

This is a semi-automatic email about new static checker warnings.

The patch 749494b6bdbb: "usb: gadget: f_hid: fix: Move IN request 
allocation to set_alt()" from Jan 24, 2017, leads to the following 
Smatch complaint:

drivers/usb/gadget/function/f_hid.c:382 f_hidg_write()
 warn: variable dereferenced before check 'hidg->req' (see line 370)

drivers/usb/gadget/function/f_hid.c
   369  spin_unlock_irqrestore(>write_spinlock, flags);
   370  status = copy_from_user(hidg->req->buf, buffer, count);
^^
Dereference.

   371  
   372  if (status != 0) {
   373  ERROR(hidg->func.config->cdev,
   374  "copy_from_user error\n");
   375  status = -EINVAL;
   376  goto release_write_pending;
   377  }
   378  
   379  spin_lock_irqsave(>write_spinlock, flags);
   380  
   381  /* we our function has been disabled by host */
   382  if (!hidg->req) {
 ^
Check too late.

   383  free_ep_req(hidg->in_ep, hidg->req);
 ^
This is also a dereference.

   384  /*

regards,
dan carpenter
--
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