Re: [PATCH 0/2] Allow twl4030_charger to find phy reliably.

2015-03-02 Thread Pavel Machek 
On Tue 2015-02-24 15:01:29, NeilBrown wrote:
 The twl4030_charger is physically paired with the twl4030 USB phy,
 so the drivers need to be able to reliably find each other.
 
 twl4030_charger currently uses usb_get_phy(), which works if there is
 only one phy to choose from, but is not reliable in more complex
 configurations.
 
 These patches add a new interface to allow a phy to be found given a
 device node, and then use that interface in twl4030_charger so that
 it finds its sibling in the devicetree, and gets the phy associated
 with that.

Apart for dt documentation...

Acked-by: Pavel Machek pa...@ucw.cz

 --
 Signature

Smiley

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 20/29] usb: gadget: composite: add req_match method to usb_function

2015-03-02 Thread Bin Liu 
Hi,

On Mon, Feb 23, 2015 at 9:02 AM, Andrzej Pietrasiewicz
andrze...@samsung.com wrote:
 Non-standard requests can encode the actual interface number in a
 non-standard way. For example composite_setup() assumes
 that it is w_index  0xFF, but the printer function encodes the interface
 number in a context-dependet way (either w_index or w_index  8).
 This can lead to such requests being directed to wrong functions.

 This patch adds req_match() method to usb_function. Its purpose is to
 verify that a given request can be handled by a given function.
 If any function within a configuration provides the method and it returns
 true, then it is assumed that the right function is found.

 If a function uses req_match(), it should try as hard as possible to
 determine if the request is meant for it.

 If no functions in a configuration provide req_match or none of them
 returns true, then fall back to the usual approach.

 Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
 ---
  drivers/usb/gadget/composite.c | 7 ++-
  include/linux/usb/composite.h  | 3 +++
  2 files changed, 9 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
 index 9fb9231..07cee80 100644
 --- a/drivers/usb/gadget/composite.c
 +++ b/drivers/usb/gadget/composite.c
 @@ -1758,6 +1758,11 @@ unknown:
  * take such requests too, if that's ever needed:  to work
  * in config 0, etc.
  */
 +   list_for_each_entry(f, cdev-config-functions, list)
 +   if (f-req_match  f-req_match(f, ctrl))
 +   break;

In this loop, if f-req_match is NULL, or f-req_match() returns
false, f becomes non-NULL at the end of the loop, which causes kernel
panic later.

 +   if (f-list != cdev-config-functions)
 +   goto try_fun_setup;

The following change fixes it.

+   list_for_each_entry(f, cdev-config-functions, list)
+   if (f-req_match  f-req_match(f, ctrl))
+   goto try_fun_setup;
+
+   f = NULL;
+

Regards,
-Bin.

 switch (ctrl-bRequestType  USB_RECIP_MASK) {
 case USB_RECIP_INTERFACE:
 if (!cdev-config || intf = MAX_CONFIG_INTERFACES)
 @@ -1775,7 +1780,7 @@ unknown:
 f = NULL;
 break;
 }
 -
 +try_fun_setup:
 if (f  f-setup)
 value = f-setup(f, ctrl);
 else {
 diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
 index 3d87def..51f477a 100644
 --- a/include/linux/usb/composite.h
 +++ b/include/linux/usb/composite.h
 @@ -147,6 +147,7 @@ struct usb_os_desc_table {
   * then only altsetting zero is supported.
   * @disable: (REQUIRED) Indicates the function should be disabled.  Reasons
   * include host resetting or reconfiguring the gadget, and disconnection.
 + * @req_match: Tests if a given class request can be handled by this 
 function.
   * @setup: Used for interface-specific control requests.
   * @suspend: Notifies functions when the host stops sending USB traffic.
   * @resume: Notifies functions when the host restarts USB traffic.
 @@ -211,6 +212,8 @@ struct usb_function {
 int (*get_alt)(struct usb_function *,
 unsigned interface);
 void(*disable)(struct usb_function *);
 +   bool(*req_match)(struct usb_function *,
 +   const struct usb_ctrlrequest *);
 int (*setup)(struct usb_function *,
 const struct usb_ctrlrequest *);
 void(*suspend)(struct usb_function *);
 --
 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
--
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: xhci_hcd : Not enough bandwidth on HS bus for newly activated TT.

2015-03-02 Thread Lu, Baolu 

cc'ed usb mailing list.

On 2015-03-02 21:23, Kenneth Johansson wrote:
I have been running 3.19 prereleases and now 3.19 and have not got the 
bandwidth problem with that kernel version. While it was quite hard to 
get before I think I have run int long enough to say that it no longer 
exist.


so I guess I get it like 5 minutes after I send this ;)

On 2015-03-02 03:37, Lu, Baolu wrote:

Include Kenneth Johansson.

On 2015-03-02 10:33, Lu, Baolu wrote:
I tried to reproduce this issue on an Intel Ivybridge machine. But I 
failed.


Kernel version: 4.0.0-rc1 (built against master branch of Greg's usb 
tree)


USB fabric:
$ sudo lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
|__ Port 5: Dev 3, If 0, Class=Video, Driver=, 480M
|__ Port 5: Dev 3, If 1, Class=Video, Driver=, 480M
|__ Port 6: Dev 4, If 0, Class=Wireless, Driver=, 12M
|__ Port 6: Dev 4, If 1, Class=Wireless, Driver=, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=Human Interface Device, 
Driver=usbhid, 12M

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 2: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 11, If 0, Class=Human Interface Device, 
Driver=usbhid, 1.5M
|__ Port 1: Dev 11, If 1, Class=Human Interface Device, 
Driver=usbhid, 1.5M

|__ Port 2: Dev 12, If 0, Class=Hub, Driver=hub/3p, 12M
|__ Port 1: Dev 13, If 0, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 1: Dev 13, If 1, Class=Human Interface Device, 
Driver=usbhid, 12M
|__ Port 3: Dev 14, If 0, Class=Vendor Specific Class, 
Driver=asix, 480M


Test script:

#!/bin/bash

while [ 1 ]
do
echo devices  /sys/power/pm_test
sleep 5
echo freeze  /sys/power/state
sleep 15
done

I kept this script running for more than 24 hours and didn't see the 
issue described below.


Any hints or suggestions?

Thanks,
Baolu


On 2014-11-10 14:40:13, Mathias Nyman wrote:

On 10.11.2014 12:47, Kenneth Johansson wrote:
So I have a problem that happens with 1-2 weeks interval in that 
the xhci driver confuses itself and thinks that the usb bus is 
overused or something.


The thing is that this is an external usb 2 hub with 7 ports and 
all 7 is used for different devices. I do a suspend/resume once a 
day and thats it.
its the same devices on the hub but the USB driver for some reason 
decides that it no longer can allow the devices on the bus.


1. is there any way to reset the entire usb stack without 
rebooting??  I run 3.16 ubuntu kernel and I think usb is built in 
I at least can see any module named xhci.


2. what can be done to solve this ?? there must be some type of 
resource leak here as a reboot solves the problem and I have 
exactly the same usb devices that I use.


3. I also notice that we max out at about 30 devices and I think 
usb should be able to handle 127.


4. I noticed on a different computer that a usb sound card (5.1) 
was also getting the bandwidth error if I attached it to a usb3 
hub that had only that device, it works if I remove the hub.


5. overall usb3 looks to be a bit unpredictable and if you 
google for this type of errors the advice is to downgrade to usb2. 
that do sound like the wrong thing to do unless the xhci hardware 
is that broken. is it ? or is this the driver that needs fixing.




-
[65633.315419] usb 3-1.4.1: Product: USB Transfer Cable
[65633.315422] usb 3-1.4.1: Manufacturer: Prolific Technology Inc.
[65633.315607] xhci_hcd :00:14.0: Not enough bandwidth on HS 
bus for newly activated TT.

[65633.315612] xhci_hcd :00:14.0: Not enough bandwidth
[65633.315619] usb 3-1.4.1: can't set config #1, error -12
---
[65653.367865] xhci_hcd :00:14.0: Not enough bandwidth on HS 
bus for newly activated TT.

[65653.367867] xhci_hcd :00:14.0: Not enough bandwidth
[65653.367872] usb 3-1.2: can't set config #1, error -12

and so on.
--



The xhci controller has a limit for max devices it can support, 
usually less than 127.
 3.16 kernel and later should report Max number of devices this 
xHCI host supports is %u.\n when you reach the limit.


I've got reports about bandwidth errors before, so far two 
different kinds, one is a context error which happends
while allocating bandwith, and is not really a bandwidth issue. 
Then we also got real bandwith errors in cases

when we really shouldn't ave them.

This is one of the many issues I need to address after resolving 
other current issues (race in reset endpoint, reset device and stop 
endoint).
Might be that it's just the driver

Re: USB ID detection interrupt - non OTG PHY

2015-03-02 Thread Peter Chen 
On Mon, Mar 02, 2015 at 11:47:31AM +0530, Anjana V Kumar wrote:
 Hi Peter,
 
 I will need to configure both the phy and the controller.
 
 Thanks
 Anjana
 
 On Mon, Mar 2, 2015 at 11:24 AM, Peter Chen peter.c...@freescale.com wrote:
 
 
  This is regarding the registering and handling of ID interrupt to swich 
  between
  host and device mode.
 
  My aim is to have OTG functionality for a not-OTG phy.
 
  We wanted to register an ID interrupt which fires of change in ID value. 
  Based
  on this ID value, we need to configure the phy to host or device mode.
 
  Do you really need to configure USB PHY (not usb controller) according to 
  host or device mode?
  If it is, you need to handle your id switch routine at phy's driver, since 
  you need
  to set PHY's register according to id value.
 
  Peter
 

It may be no easy to handle it if you can't handle all things
at controller driver, like handle id and vbus. Have a look
for below thread, some framework are not ready, like DRD library,
George, any updates for that?

https://lkml.org/lkml/2014/12/23/442

-- 

Best Regards,
Peter Chen
--
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: serial: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards.

2015-03-02 Thread Max Mansfield 
This patch integrates Cyber Cortex AV boards with the existing
ftdi_jtag_quirk in order to use serial port 0 with JTAG which is
required by the manufacturers' software.

Steps: 2

[ftdi_sio_ids.h]
1. Defined the device PID

[ftdi_sio.c]
2. Added a macro declaration to the ids array, in order to enable the jtag 
quirk for the device.

Signed-off-by: Max Mansfield max.m.mansfi...@gmail.com
---
 drivers/usb/serial/ftdi_sio.c | 2 ++
 drivers/usb/serial/ftdi_sio_ids.h | 5 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1ebb351..07159e2 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -799,6 +799,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_ELSTER_UNICOM_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_PROPOX_JTAGCABLEII_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_PROPOX_ISPCABLEIII_PID) },
+   { USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
+   .driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
{ USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_PID),
.driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
{ USB_DEVICE(OLIMEX_VID, OLIMEX_ARM_USB_OCD_H_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index e52409c..1185fc9 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -38,6 +38,11 @@
 
 #define FTDI_LUMEL_PD12_PID0x6002
 
+
+/* Cyber Cortex AV by Fabulous Silicon (http://fabuloussilicon.com) */
+#define CYBER_CORTEX_AV_PID   0x8698
+
+
 /*
  * Marvell OpenRD Base, Client
  * http://www.open-rd.org
-- 
1.9.1

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

[PATCH net-next 00/14] Use eth_foo_addr instead of memset

2015-03-02 Thread Joe Perches 
Joe Perches (14):
  etherdevice: Add eth_foo_addr CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS code
  ethernet: Use eth_foo_addr instead of memset
  net: usb: Use eth_foo_addr instead of memset
  wireless: Use eth_foo_addr instead of memset
  netconsole: Use eth_foo_addr instead of memset
  xen: Use eth_foo_addr instead of memset
  8021q: Use eth_foo_addr instead of memset
  appletalk: Use eth_foo_addr instead of memset
  atm: Use eth_foo_addr instead of memset
  bluetooth: Use eth_foo_addr instead of memset
  ethernet: Use eth_foo_addr instead of memset
  mac80211: Use eth_foo_addr instead of memset
  wireless: Use eth_foo_addr instead of memset
  l2tp: Use eth_foo_addr instead of memset

 drivers/net/ethernet/amd/pcnet32.c |  2 +-
 .../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c|  2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c   |  6 ++--
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c  |  2 +-
 drivers/net/ethernet/cisco/enic/enic_main.c|  8 +++---
 drivers/net/ethernet/emulex/benet/be_cmds.c|  2 +-
 drivers/net/ethernet/emulex/benet/be_main.c|  2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  |  4 +--
 drivers/net/ethernet/mellanox/mlx4/en_netdev.c |  4 +--
 drivers/net/ethernet/mellanox/mlx4/en_selftest.c   |  2 +-
 drivers/net/ethernet/micrel/ksz884x.c  |  2 +-
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c |  2 +-
 drivers/net/ethernet/qlogic/qlge/qlge_main.c   |  2 +-
 drivers/net/ethernet/smsc/smsc911x.c   |  2 +-
 drivers/net/ethernet/ti/netcp_core.c   |  2 +-
 drivers/net/ethernet/toshiba/ps3_gelic_wireless.c  |  4 +--
 drivers/net/ethernet/xscale/ixp4xx_eth.c   |  2 +-
 drivers/net/netconsole.c   |  5 ++--
 drivers/net/usb/catc.c |  4 +--
 drivers/net/usb/cdc_mbim.c |  2 +-
 drivers/net/usb/lg-vl600.c |  2 +-
 drivers/net/usb/qmi_wwan.c |  2 +-
 drivers/net/wireless/airo.c|  4 +--
 drivers/net/wireless/at76c50x-usb.c|  6 ++--
 drivers/net/wireless/ath/ath10k/mac.c  |  2 +-
 drivers/net/wireless/ath/ath5k/base.c  |  2 +-
 drivers/net/wireless/ath/ath6kl/cfg80211.c |  2 +-
 drivers/net/wireless/ath/ath6kl/main.c |  2 +-
 drivers/net/wireless/ath/ath9k/htc_drv_main.c  |  2 +-
 drivers/net/wireless/ath/ath9k/main.c  |  4 +--
 drivers/net/wireless/atmel.c   | 16 +--
 drivers/net/wireless/b43/main.c|  8 +++---
 drivers/net/wireless/b43legacy/main.c  |  8 +++---
 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 12 
 drivers/net/wireless/brcm80211/brcmfmac/flowring.c |  2 +-
 drivers/net/wireless/brcm80211/brcmfmac/p2p.c  |  2 +-
 drivers/net/wireless/cw1200/sta.c  |  2 +-
 drivers/net/wireless/cw1200/txrx.c |  2 +-
 drivers/net/wireless/hostap/hostap_80211_tx.c  |  4 +--
 drivers/net/wireless/hostap/hostap_ap.c|  8 +++---
 drivers/net/wireless/hostap/hostap_info.c  |  2 +-
 drivers/net/wireless/hostap/hostap_main.c  |  4 +--
 drivers/net/wireless/hostap/hostap_wlan.h  | 33 +++---
 drivers/net/wireless/ipw2x00/ipw2100.c |  8 +++---
 drivers/net/wireless/ipw2x00/ipw2200.c |  6 ++--
 drivers/net/wireless/iwlegacy/common.c |  2 +-
 drivers/net/wireless/iwlwifi/mvm/power.c   |  3 +-
 drivers/net/wireless/libertas/main.c   |  4 +--
 drivers/net/wireless/libertas_tf/main.c|  4 +--
 drivers/net/wireless/mac80211_hwsim.c  |  6 ++--
 drivers/net/wireless/mwifiex/cfg80211.c|  8 +++---
 drivers/net/wireless/mwifiex/init.c|  4 +--
 drivers/net/wireless/mwifiex/sta_event.c   |  2 +-
 drivers/net/wireless/mwifiex/wmm.c |  2 +-
 drivers/net/wireless/mwl8k.c   |  2 +-
 drivers/net/wireless/orinoco/wext.c|  2 +-
 drivers/net/wireless/p54/fwio.c|  2 +-
 drivers/net/wireless/p54/main.c|  8 +++---
 drivers/net/wireless/ray_cs.c  |  2 +-
 drivers/net/wireless/rndis_wlan.c  | 28 +-
 drivers/net/wireless/rtlwifi/core.c|  6 ++--
 drivers/net/wireless/ti/wl1251/main.c  |  4 +--
 drivers/net/wireless/ti/wlcore/cmd.c   |  4 +--
 drivers/net/xen-netback/interface.c|  2 +-
 include/linux/etherdevice.h| 12 +++-
 net/8021q/vlan_dev.c   |  2 +-
 net/appletalk/aarp.c   |  6 ++--
 net/atm/lec.c  |  4 +--
 net/bluetooth/bnep/netdev.c|  2 +-
 net/ethernet/eth.c

[PATCH] udc: gadget: atmel_usba_udc: depend on COMMON_CLK_AT91

2015-03-02 Thread Alexandre Belloni 
Since the addition of the errata handling for at91sam9rl and at91sam9g45, the
atmel_usba_udc depends on the pmc driver being present. Explicitly set that
dependency.

Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
 drivers/usb/gadget/udc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 9a3a6b00391a..b04206fdba11 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -55,7 +55,7 @@ config USB_LPC32XX
 
 config USB_ATMEL_USBA
tristate Atmel USBA
-   depends on AVR32 || ARCH_AT91
+   depends on AVR32 || ARCH_AT91  COMMON_CLK_AT91
help
  USBA is the integrated high-speed USB Device controller on
  the AT32AP700x, some AT91SAM9 and AT91CAP9 processors from Atmel.
-- 
2.1.0

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

Re: [PATCH] usb: serial: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards.

2015-03-02 Thread Johan Hovold 
On Mon, Mar 02, 2015 at 06:38:02PM -0700, Max Mansfield wrote:
 This patch integrates Cyber Cortex AV boards with the existing
 ftdi_jtag_quirk in order to use serial port 0 with JTAG which is
 required by the manufacturers' software.
 
 Steps: 2
 
 [ftdi_sio_ids.h]
 1. Defined the device PID
 
 [ftdi_sio.c]
 2. Added a macro declaration to the ids array, in order to enable the jtag 
 quirk for the device.
 
 Signed-off-by: Max Mansfield max.m.mansfi...@gmail.com

Applied after some minor reformatting.

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

Re: [PATCH 20/29] usb: gadget: composite: add req_match method to usb_function

2015-03-02 Thread Andrzej Pietrasiewicz 

W dniu 02.03.2015 o 23:03, Bin Liu pisze:

Hi,

On Mon, Feb 23, 2015 at 9:02 AM, Andrzej Pietrasiewicz
andrze...@samsung.com wrote:

Non-standard requests can encode the actual interface number in a
non-standard way. For example composite_setup() assumes
that it is w_index  0xFF, but the printer function encodes the interface
number in a context-dependet way (either w_index or w_index  8).
This can lead to such requests being directed to wrong functions.

This patch adds req_match() method to usb_function. Its purpose is to
verify that a given request can be handled by a given function.
If any function within a configuration provides the method and it returns
true, then it is assumed that the right function is found.

If a function uses req_match(), it should try as hard as possible to
determine if the request is meant for it.

If no functions in a configuration provide req_match or none of them
returns true, then fall back to the usual approach.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
  drivers/usb/gadget/composite.c | 7 ++-
  include/linux/usb/composite.h  | 3 +++
  2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 9fb9231..07cee80 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1758,6 +1758,11 @@ unknown:
  * take such requests too, if that's ever needed:  to work
  * in config 0, etc.
  */
+   list_for_each_entry(f, cdev-config-functions, list)
+   if (f-req_match  f-req_match(f, ctrl))
+   break;


In this loop, if f-req_match is NULL, or f-req_match() returns
false, f becomes non-NULL at the end of the loop, which causes kernel
panic later.


+   if (f-list != cdev-config-functions)
+   goto try_fun_setup;


The following change fixes it.

+   list_for_each_entry(f, cdev-config-functions, list)
+   if (f-req_match  f-req_match(f, ctrl))
+   goto try_fun_setup;
+
+   f = NULL;
+


Right. Thanks!

AP

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

[PATCH net-next 03/14] net: usb: Use eth_foo_addr instead of memset

2015-03-02 Thread Joe Perches 
Use the built-in function instead of memset.

Signed-off-by: Joe Perches j...@perches.com
---
 drivers/net/usb/catc.c | 4 ++--
 drivers/net/usb/cdc_mbim.c | 2 +-
 drivers/net/usb/lg-vl600.c | 2 +-
 drivers/net/usb/qmi_wwan.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/usb/catc.c b/drivers/net/usb/catc.c
index 8cfc3bb..4e2b26a 100644
--- a/drivers/net/usb/catc.c
+++ b/drivers/net/usb/catc.c
@@ -641,7 +641,7 @@ static void catc_set_multicast_list(struct net_device 
*netdev)
u8 broadcast[ETH_ALEN];
u8 rx = RxEnable | RxPolarity | RxMultiCast;
 
-   memset(broadcast, 0xff, ETH_ALEN);
+   eth_broadcast_addr(broadcast);
memset(catc-multicast, 0, 64);
 
catc_multicast(broadcast, catc-multicast);
@@ -880,7 +880,7 @@ static int catc_probe(struct usb_interface *intf, const 
struct usb_device_id *id

dev_dbg(dev, Filling the multicast list.\n);
  
-   memset(broadcast, 0xff, ETH_ALEN);
+   eth_broadcast_addr(broadcast);
catc_multicast(broadcast, catc-multicast);
catc_multicast(netdev-dev_addr, catc-multicast);
catc_write_mem(catc, 0xfa80, catc-multicast, 64);
diff --git a/drivers/net/usb/cdc_mbim.c b/drivers/net/usb/cdc_mbim.c
index 96fc8a5..e4b7a47 100644
--- a/drivers/net/usb/cdc_mbim.c
+++ b/drivers/net/usb/cdc_mbim.c
@@ -394,7 +394,7 @@ static struct sk_buff *cdc_mbim_process_dgram(struct usbnet 
*dev, u8 *buf, size_
skb_put(skb, ETH_HLEN);
skb_reset_mac_header(skb);
eth_hdr(skb)-h_proto = proto;
-   memset(eth_hdr(skb)-h_source, 0, ETH_ALEN);
+   eth_zero_addr(eth_hdr(skb)-h_source);
memcpy(eth_hdr(skb)-h_dest, dev-net-dev_addr, ETH_ALEN);
 
/* add datagram */
diff --git a/drivers/net/usb/lg-vl600.c b/drivers/net/usb/lg-vl600.c
index 8f37efd..5714107 100644
--- a/drivers/net/usb/lg-vl600.c
+++ b/drivers/net/usb/lg-vl600.c
@@ -201,7 +201,7 @@ static int vl600_rx_fixup(struct usbnet *dev, struct 
sk_buff *skb)
buf-data[sizeof(*ethhdr) + 0x12],
ETH_ALEN);
} else {
-   memset(ethhdr-h_source, 0, ETH_ALEN);
+   eth_zero_addr(ethhdr-h_source);
memcpy(ethhdr-h_dest, dev-net-dev_addr, ETH_ALEN);
 
/* Inbound IPv6 packets have an IPv4 ethertype (0x800)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 602dc66..f603f36 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -108,7 +108,7 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct 
sk_buff *skb)
skb_push(skb, ETH_HLEN);
skb_reset_mac_header(skb);
eth_hdr(skb)-h_proto = proto;
-   memset(eth_hdr(skb)-h_source, 0, ETH_ALEN);
+   eth_zero_addr(eth_hdr(skb)-h_source);
 fix_dest:
memcpy(eth_hdr(skb)-h_dest, dev-net-dev_addr, ETH_ALEN);
return 1;
-- 
2.1.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] Fixing style warnings.

2015-03-02 Thread cfredric 
Signed-off-by: cfredric chris.p.fredrick...@gmail.com
---
 drivers/usb/core/buffer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 506b969..89f2e77 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -70,7 +70,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
size = pool_max[i];
if (!size)
continue;
-   snprintf(name, sizeof name, buffer-%d, size);
+   snprintf(name, sizeof(name), buffer-%d, size);
hcd-pool[i] = dma_pool_create(name, hcd-self.controller,
size, size, 0);
if (!hcd-pool[i]) {
@@ -95,6 +95,7 @@ void hcd_buffer_destroy(struct usb_hcd *hcd)
 
for (i = 0; i  HCD_BUFFER_POOLS; i++) {
struct dma_pool *pool = hcd-pool[i];
+
if (pool) {
dma_pool_destroy(pool);
hcd-pool[i] = NULL;
-- 
1.9.1

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

Re: [PATCH 20/29] usb: gadget: composite: add req_match method to usb_function

2015-03-02 Thread Andrzej Pietrasiewicz 

W dniu 27.02.2015 o 21:58, Felipe Balbi pisze:

Hi,

On Fri, Feb 27, 2015 at 02:55:25PM -0600, Felipe Balbi wrote:

On Mon, Feb 23, 2015 at 04:02:09PM +0100, Andrzej Pietrasiewicz wrote:

Non-standard requests can encode the actual interface number in a
non-standard way. For example composite_setup() assumes
that it is w_index  0xFF, but the printer function encodes the interface
number in a context-dependet way (either w_index or w_index  8).
This can lead to such requests being directed to wrong functions.

This patch adds req_match() method to usb_function. Its purpose is to
verify that a given request can be handled by a given function.
If any function within a configuration provides the method and it returns
true, then it is assumed that the right function is found.

If a function uses req_match(), it should try as hard as possible to
determine if the request is meant for it.

If no functions in a configuration provide req_match or none of them
returns true, then fall back to the usual approach.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com


this regresses testusb at least on am335x:



I don't have this particular hardware but will try looking into the issue.
As soon as I have some results I will let you know.

AP

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

Re: gadgetfs broken since 7f7f25e8

2015-03-02 Thread Al Viro 
On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:
 On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler hol...@ahsoftware.de wrote:
  Hello.
 
  Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with 3.16) broke
  dynamic changing of file_operations-[read|write].
 
  At least gadgetfs is a victim.
 
  Feel free to ask me off-list for a patch as I don't want to end up in
  annoying discussions on Linux kernel lists anymore.
 
  Alexander Holler
 
 CC'ing Al.

I know.  FWIW, gadgetfs is one of the very few places that tried to pull that
crap off and it had always been seriously racy.  I've posted a partial analysis
about a month ago (20150204190645.gj29...@zeniv.linux.org.uk).

If Alexander (or anybody else) has a patch that really fixes that thing,
I would certainly like to see it.  If not, I'll try to cook something,
but I'm not very familiar with that code.  I really hope that this patch
isn't modify -f_mode to match -f_op change - that's too racy.
We'll obviously need to fix the userland-visible breakage in that one,
but that's not the way to go...
--
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: plusb: Add support for National Instruments host-to-host cable

2015-03-02 Thread David Miller 
From: Ben Shelton ben.shel...@ni.com
Date: Mon, 2 Mar 2015 10:00:14 -0600

 On 02/27, David Miller wrote:
 From: Ben Shelton ben.shel...@ni.com
 Date: Fri, 27 Feb 2015 15:26:32 -0600
 
  On 02/20, David Miller wrote:
  From: Ben Shelton ben.shel...@ni.com
  Date: Mon, 16 Feb 2015 13:47:06 -0600
  
   The National Instruments USB Host-to-Host Cable is based on the Prolific
   PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.
   
   Signed-off-by: Ben Shelton ben.shel...@ni.com
  
  Applied, thanks.
  
  Hi David,
  
  Is this something you think would go into stable as well?
 
 I'm ambivalent.
 
 In that case, could you go ahead and apply it to stable as well?

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

Re: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

2015-03-02 Thread Alan Stern 
On Mon, 2 Mar 2015, Aleksander Morgado wrote:

 I think my patch also lacks the -EREMOTEIO return for the case when 0
 bytes are transferred. I'll try to update it today.

It's not necessary.  The USB core automatically sets the status to 
-EREMOTEIO if the status is equal to 0 and the transfer was short and 
URB_SHORT_NOT_OK was set.  See __usb_hcd_giveback_urb().

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: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

2015-03-02 Thread Mathias Nyman 
On 26.02.2015 20:01, Alan Stern wrote:
 On Thu, 26 Feb 2015, Mathias Nyman wrote:
 
 On 26.02.2015 18:12, Mathias Nyman wrote:
 When a control transfer has a short data stage, the xHCI controller 
 generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, only
 the COMP_SUCCESS event occurs. Therefore, xhci-hcd sets urb-actual_length
 to urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless urb-actual_length was set already by a previous COMP_SHORT_TX event.

 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone is the wrong test, as it is entirely possible for a short transfer to
 have an urb-actual_length = 0.

 This patch changes the xhci driver to set the urb-actual_length in advance
 to the expected value of a successful control transfer.
 The urb-actual_length is then only adjusted in case of short transfers or
 other special events, but not on COMP_SUCCESS events.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
 ---
  drivers/usb/host/xhci-ring.c | 73 
 ++--
  1 file changed, 37 insertions(+), 36 deletions(-)

 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index b46b5b9..0e02e79 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -732,7 +732,11 @@ remove_finished_td:
 /* Clean up the cancelled URB */
 /* Doesn't matter what we pass for status, since the core will
  * just overwrite it (because the URB has been unlinked).
 +* Control urbs have the urb-actual_length pre-set, clear it
 +* as well
  */
 +   if (usb_endpoint_xfer_control(cur_td-urb-ep-desc))
 +   cur_td-urb-actual_length = 0;
 
 Now this would do the wrong thing if some data had been sent or 
 received before the URB was cancelled.

Thats right, this would overwrite any length set in a transfer event
for this TD before canceling the the TD

 
 Does the controller write back information about the number of bytes to
 the data TRB?  Maybe it would be easier to get the values from there
 instead of trying to use the event structures.

Unfortunately it looks like we need to rely on the lengths from the events.

Streams do have a Event Data Transfer Length Accumulator (EDTLA) in the stream
context that xhci writes to when the endpoint is stopped, but this requires that
the host supports a Stopped EDTLA capability, and is only for streams.

I think that maybe Aleksanders suggestion of adding the length_set flag is 
the way to go, atleast that something that we can get to the next rc release,
and it's not as intrusive.

-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

Re: gadgetfs broken since 7f7f25e8

2015-03-02 Thread Alexander Holler 

Am 02.03.2015 um 14:02 schrieb Alexander Holler:

Am 02.03.2015 um 12:39 schrieb Alexander Holler:

Am 02.03.2015 um 11:20 schrieb Al Viro:

On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:

On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler
hol...@ahsoftware.de wrote:

Hello.

Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with
3.16) broke
dynamic changing of file_operations-[read|write].

At least gadgetfs is a victim.


Just for your amusement and as an example:

This bug lead to me to examine and search bugs in the userland piece 
I've tried to use and ended up in around


===
aholler@laptopahbt ~/Source/USBProxy.git/src $ PAGER= git diff 
7d2506648e3404bf7070bae6ab8da4a702ed093c --stat
 doc/gadgetfs_kernel_above_3.15.patch |  50 
+++

 src/Plugins/Hosts/GadgetFS_helpers.c |   4 ++--
 src/Plugins/Hosts/HostProxy_GadgetFS.cpp |  12 
 src/debian/header-check.c|   1 -
 src/lib/CMakeLists.txt   |   2 --
 src/lib/ConfigParser.cpp |   9 +++--
 src/lib/ConfigParser.h   |   2 +-
 src/lib/FDInfo.c |   2 +-
 src/lib/HaltSignal.c |  54 
---

 src/lib/HaltSignal.h |  19 --
 src/lib/Injector.cpp |  23 +-
 src/lib/Injector.h   |  11 +++
 src/lib/Manager.cpp  | 122 
+++---

 src/lib/Manager.h|  15 +++---
 src/lib/PluginManager.cpp|  47 
+---

 src/lib/Proxy.h  |  12 
 src/lib/RelayReader.cpp  |  39 
-

 src/lib/RelayReader.h|   9 ++---
 src/lib/RelayWriter.cpp  |  69 


 src/lib/RelayWriter.h|   8 +---
 src/tools/usb-mitm.cpp   |   2 --
 21 files changed, 223 insertions(+), 289 deletions(-)
 ===

without counting at least a dozen patches I did on that userland piece 
before those which are counted in the above stat. All in order to find 
the bug.


So, you can see, I've already spend some hours before I've dived into 
the kernel to search for the bug. Of course, the problem in the kernel 
is innocent for all the problems I've found in userland which lead me to 
the assumption that the -EINVAL returned from a read() after a poll() is 
because of some problem in userspace (like memory or stack corruption).


Just in case someone thinks I'm lazy because I don't want to rewrite 
gadgetfs and deal with kernel maintainers.


Regards,

Alexander Holler
--
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] xhci: fix reporting of 0-sized URBs in control endpoint

2015-03-02 Thread Aleksander Morgado 
When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb-actual_length to
urb-transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb-actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb-actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb-actual_length = 0.

This patch changes the xhci driver to rely on a new td-urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb-actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado aleksan...@aleksander.es
---

Hey Mathias,

This v5 of the patch takes into account the possibility of needing to return
-EREMOTEIO if URB_SHORT_NOT_OK was requested in the transfer flags.

With this change we no longer check for having a value in urb-actual_length,
instead we just use the new flag and therefore we treat in the same way all
cases where we got a SHORT_TX event (including those were the transfer was 0).

Also changed the length of the comment lines to avoid going off 80chars per
line.

Let me know what you think.

---
 drivers/usb/host/xhci-ring.c | 10 --
 drivers/usb/host/xhci.h  |  3 +++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 88da8d6..73485fa 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1946,7 +1946,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
if (event_trb != ep_ring-dequeue) {
/* The event was for the status stage */
if (event_trb == td-last_trb) {
-   if (td-urb-actual_length != 0) {
+   if (td-urb_length_set) {
/* Don't overwrite a previously set error code
 */
if ((*status == -EINPROGRESS || *status == 0) 
@@ -1960,7 +1960,13 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct 
xhci_td *td,
td-urb-transfer_buffer_length;
}
} else {
-   /* Maybe the event was for the data stage? */
+   /*
+* Maybe the event was for the data stage? If so, update
+* already the actual_length of the URB and flag it as
+* set, so that it is not overwritten in the event for
+* the last TRB.
+*/
+   td-urb_length_set = true;
td-urb-actual_length =
td-urb-transfer_buffer_length -
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len));
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9745147..bd868aa 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1,3 +1,4 @@
+
 /*
  * xHCI host controller driver
  *
@@ -1288,6 +1289,8 @@ struct xhci_td {
struct xhci_segment *start_seg;
union xhci_trb  *first_trb;
union xhci_trb  *last_trb;
+   /* actual_length of the URB has already been set */
+   boolurb_length_set;
 };

 /* xHCI command default timeout value */
--
2.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/1] USB: ch341: set tty baud speed according to tty struct

2015-03-02 Thread Johan Hovold 
On Sun, Mar 01, 2015 at 01:47:22PM -0500, Nicolas PLANEL wrote:
 The ch341_set_baudrate() function initialize the device baud speed
 according to the value on priv-baud_rate. By default the ch341_open() set
 it to a hardcoded value (DEFAULT_BAUD_RATE 9600). Unfortunately, the
 tty_struct is not initialized with the same default value. (usually 56700)
 
 This means that the tty_struct and the device baud rate generator are not
 synchronized after opening the port.
 
 Fixup is done by calling ch341_set_termios() if tty exist.
 Remove unnecessary variable priv-baud_rate setup as it's already done by
 ch341_port_probe().
 Remove unnecessary call to ch341_set_{handshake,baudrate}() in
 ch341_open() as there already called in ch341_configure() and
 ch341_set_termios()
 
 Signed-off-by: Nicolas PLANEL nicolas.pla...@enovance.com

Now applied, thanks for fixing this.

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: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

2015-03-02 Thread Mathias Nyman 
On 26.02.2015 23:59, Aleksander Morgado wrote:
 On Thu, Feb 26, 2015 at 5:12 PM, Mathias Nyman
 mathias.ny...@linux.intel.com wrote:
 When a control transfer has a short data stage, the xHCI controller generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, only
 the COMP_SUCCESS event occurs. Therefore, xhci-hcd sets urb-actual_length
 to urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless urb-actual_length was set already by a previous COMP_SHORT_TX event.

 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone is the wrong test, as it is entirely possible for a short transfer to
 have an urb-actual_length = 0.

 This patch changes the xhci driver to set the urb-actual_length in advance
 to the expected value of a successful control transfer.
 The urb-actual_length is then only adjusted in case of short transfers or
 other special events, but not on COMP_SUCCESS events.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
 ---
  drivers/usb/host/xhci-ring.c | 73 
 ++--
  1 file changed, 37 insertions(+), 36 deletions(-)

 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index b46b5b9..0e02e79 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -732,7 +732,11 @@ remove_finished_td:
 /* Clean up the cancelled URB */
 /* Doesn't matter what we pass for status, since the core 
 will
  * just overwrite it (because the URB has been unlinked).
 +* Control urbs have the urb-actual_length pre-set, clear it
 +* as well
  */
 +   if (usb_endpoint_xfer_control(cur_td-urb-ep-desc))
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, 0);

 /* Stop processing the cancelled list if the watchdog timer 
 is
 @@ -755,6 +759,7 @@ static void xhci_kill_ring_urbs(struct xhci_hcd *xhci, 
 struct xhci_ring *ring)
 list_del_init(cur_td-td_list);
 if (!list_empty(cur_td-cancelled_td_list))
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -792,6 +797,7 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd 
 *xhci,
 cur_td = list_first_entry(ep-cancelled_td_list,
 struct xhci_td, cancelled_td_list);
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -1888,6 +1894,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 int ep_index;
 struct xhci_ep_ctx *ep_ctx;
 u32 trb_comp_code;
 +   bool force_finish_td = false;

 slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event-flags));
 xdev = xhci-devs[slot_id];
 @@ -1906,7 +1913,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 xhci_warn(xhci, WARN: Success on ctrl data TRB 
 without IOC set??\n);
 *status = -ESHUTDOWN;
 -   } else {
 +   } else if (*status == -EINPROGRESS) {
 +   /* only set to 0 if no previous event set it earlier 
 */
 *status = 0;
 }
 break;
 @@ -1918,6 +1926,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 break;
 case COMP_STOP_INVAL:
 case COMP_STOP:
 +   /* we don't continue stopped TDs, so length can be set to 0 
 */
 +   td-urb-actual_length = 0;
 return finish_td(xhci, td, event_trb, event, ep, status, 
 false);
 default:
 if (!xhci_requires_manual_halt_cleanup(xhci,
 @@ -1928,44 +1938,26 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 trb_comp_code, ep_index);
 /* else fall through */
 case COMP_STALL:
 -   /* Did we transfer part of the data (middle) phase? */
 -   if (event_trb != ep_ring-dequeue 
 -   event_trb != td-last_trb)
 -   td-urb-actual_length =
 -   td-urb-transfer_buffer_length -
 -   
 EVENT_TRB_LEN(le32_to_cpu(event-transfer_len));
 -   else
 -

Re: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

2015-03-02 Thread Aleksander Morgado 
On Mon, Mar 2, 2015 at 12:57 PM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:
 On 26.02.2015 23:59, Aleksander Morgado wrote:
 On Thu, Feb 26, 2015 at 5:12 PM, Mathias Nyman
 mathias.ny...@linux.intel.com wrote:
 When a control transfer has a short data stage, the xHCI controller 
 generates
 two transfer events: a COMP_SHORT_TX event that specifies the untransferred
 amount, and a COMP_SUCCESS event. But when the data stage is not short, only
 the COMP_SUCCESS event occurs. Therefore, xhci-hcd sets urb-actual_length
 to urb-transfer_buffer_length while processing the COMP_SUCCESS event,
 unless urb-actual_length was set already by a previous COMP_SHORT_TX event.

 The driver checks this by seeing whether urb-actual_length == 0, but this
 alone is the wrong test, as it is entirely possible for a short transfer to
 have an urb-actual_length = 0.

 This patch changes the xhci driver to set the urb-actual_length in advance
 to the expected value of a successful control transfer.
 The urb-actual_length is then only adjusted in case of short transfers or
 other special events, but not on COMP_SUCCESS events.

 This fixes a bug which affected the HSO plugin, which relies on URBs with
 urb-actual_length == 0 to halt re-submitting the RX URB in the control
 endpoint.

 Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
 ---
  drivers/usb/host/xhci-ring.c | 73 
 ++--
  1 file changed, 37 insertions(+), 36 deletions(-)

 diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
 index b46b5b9..0e02e79 100644
 --- a/drivers/usb/host/xhci-ring.c
 +++ b/drivers/usb/host/xhci-ring.c
 @@ -732,7 +732,11 @@ remove_finished_td:
 /* Clean up the cancelled URB */
 /* Doesn't matter what we pass for status, since the core 
 will
  * just overwrite it (because the URB has been unlinked).
 +* Control urbs have the urb-actual_length pre-set, clear 
 it
 +* as well
  */
 +   if (usb_endpoint_xfer_control(cur_td-urb-ep-desc))
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, 0);

 /* Stop processing the cancelled list if the watchdog timer 
 is
 @@ -755,6 +759,7 @@ static void xhci_kill_ring_urbs(struct xhci_hcd *xhci, 
 struct xhci_ring *ring)
 list_del_init(cur_td-td_list);
 if (!list_empty(cur_td-cancelled_td_list))
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -792,6 +797,7 @@ static void xhci_kill_endpoint_urbs(struct xhci_hcd 
 *xhci,
 cur_td = list_first_entry(ep-cancelled_td_list,
 struct xhci_td, cancelled_td_list);
 list_del_init(cur_td-cancelled_td_list);
 +   cur_td-urb-actual_length = 0;
 xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
 }
  }
 @@ -1888,6 +1894,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 int ep_index;
 struct xhci_ep_ctx *ep_ctx;
 u32 trb_comp_code;
 +   bool force_finish_td = false;

 slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event-flags));
 xdev = xhci-devs[slot_id];
 @@ -1906,7 +1913,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 xhci_warn(xhci, WARN: Success on ctrl data TRB 
 without IOC set??\n);
 *status = -ESHUTDOWN;
 -   } else {
 +   } else if (*status == -EINPROGRESS) {
 +   /* only set to 0 if no previous event set it 
 earlier */
 *status = 0;
 }
 break;
 @@ -1918,6 +1926,8 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 break;
 case COMP_STOP_INVAL:
 case COMP_STOP:
 +   /* we don't continue stopped TDs, so length can be set to 0 
 */
 +   td-urb-actual_length = 0;
 return finish_td(xhci, td, event_trb, event, ep, status, 
 false);
 default:
 if (!xhci_requires_manual_halt_cleanup(xhci,
 @@ -1928,44 +1938,26 @@ static int process_ctrl_td(struct xhci_hcd *xhci, 
 struct xhci_td *td,
 trb_comp_code, ep_index);
 /* else fall through */
 case COMP_STALL:
 -   /* Did we transfer part of the data (middle) phase? */
 -   if (event_trb != ep_ring-dequeue 
 -   event_trb != td-last_trb)
 -   td-urb-actual_length =
 -   td-urb-transfer_buffer_length -
 -

Re: gadgetfs broken since 7f7f25e8

2015-03-02 Thread Alexander Holler 

Am 02.03.2015 um 12:39 schrieb Alexander Holler:

Am 02.03.2015 um 11:20 schrieb Al Viro:

On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:

On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler
hol...@ahsoftware.de wrote:

Hello.

Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with
3.16) broke
dynamic changing of file_operations-[read|write].

At least gadgetfs is a victim.

Feel free to ask me off-list for a patch as I don't want to end up in
annoying discussions on Linux kernel lists anymore.

Alexander Holler


CC'ing Al.


I know.  FWIW, gadgetfs is one of the very few places that tried to
pull that
crap off and it had always been seriously racy.  I've posted a partial
analysis
about a month ago (20150204190645.gj29...@zeniv.linux.org.uk).

If Alexander (or anybody else) has a patch that really fixes that thing,
I would certainly like to see it.  If not, I'll try to cook something,
but I'm not very familiar with that code.  I really hope that this patch
isn't modify -f_mode to match -f_op change - that's too racy.
We'll obviously need to fix the userland-visible breakage in that one,
but that's not the way to go...


I exactly did what you've assumed, I've just fixed f_mode but not the
already existing races which I haven't introduced. So I was right in not
sending a patch as would have been blamed for not rewriting everything
as so often.


Another quick solution would be to just add some dummy ops for 
read/write to those file_operations which are missing it which are only 
returning -EINVAL or some other error which might make sense.


But that still won't fix any existing race occuring while changing the 
the ops.

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

gadgetfs broken since 7f7f25e8

2015-03-02 Thread Alexander Holler 

Hello.

Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with 3.16) 
broke dynamic changing of file_operations-[read|write].


At least gadgetfs is a victim.

Feel free to ask me off-list for a patch as I don't want to end up in 
annoying discussions on Linux kernel lists anymore.


Alexander Holler
--
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 20/29] usb: gadget: composite: add req_match method to usb_function

2015-03-02 Thread Andrzej Pietrasiewicz 

W dniu 27.02.2015 o 21:55, Felipe Balbi pisze:

On Mon, Feb 23, 2015 at 04:02:09PM +0100, Andrzej Pietrasiewicz wrote:

Non-standard requests can encode the actual interface number in a
non-standard way. For example composite_setup() assumes
that it is w_index  0xFF, but the printer function encodes the interface
number in a context-dependet way (either w_index or w_index  8).
This can lead to such requests being directed to wrong functions.

This patch adds req_match() method to usb_function. Its purpose is to
verify that a given request can be handled by a given function.
If any function within a configuration provides the method and it returns
true, then it is assumed that the right function is found.

If a function uses req_match(), it should try as hard as possible to
determine if the request is meant for it.

If no functions in a configuration provide req_match or none of them
returns true, then fall back to the usual approach.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com


this regresses testusb at least on am335x:

test 14: control writes


When I tried it on odroid u3 (with dwc2) at the host side it says:

/dev/bus/usb/002/009 test 14 -- 22 (Invalid argument)

(run as root at host)

but there is no problem at the device side.

On the same board with dummy hcd the result for test 14 is:

/dev/bus/usb/002/002 test 14 -- 25 (Inappropriate ioctl for device)

(run as root at host)

but no problem with the device.

I'm running tools/usb/testusb with -a option. Do I need some
more preparation to actually run the tests? Perhaps I don't
experience the problem because there is no attempt to
actually trigger composite_setup() call?

On the other hand I'm thinking what could be wrong with the patch
adding req_match? With the patch applied usb_function structure
has one more member, which is (1) checked for not being NULL and,
if non-NULL it is (2) dereferenced in composite_setup(). The problem
you experience might be that (1) succeeds (req_match != NULL) and
then (2) explodes, because the pointer is actually either garbage or
some other data mis-interpreted. The struct usb_function in question
is allocated with kzalloc() in both f_loopback.c:loopback_alloc()
and f_sourcesink.c:source_sink_alloc_func() so there is no way
the pointer is not initialized to NULL, so (1) should fail
in the first place. But if (1) does not fail the member in question
is non-NULL, but how could it become non-NULL if properly initialized?
The only possibilities are: explicit assignment, unintentional memory
overwrite or mismatch between headers with which your modules/and or your
kernel have been built. If you did not add explicit assignment, and
indeed you didn't, explicit assignment is out of the question. Unintentional
memory overwrite might happen with e.g. memcpy() or variants of strcpy(),
but both f_sourcesink.c and f_loopback.c do not contain any  cpy string.
However silly this might sound, would you be able to double check
that you used consistent headers+kernel binary+module binaries?

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

Re: gadgetfs broken since 7f7f25e8

2015-03-02 Thread Alexander Holler 

Am 02.03.2015 um 11:20 schrieb Al Viro:

On Mon, Mar 02, 2015 at 10:13:27AM +0100, Richard Weinberger wrote:

On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler hol...@ahsoftware.de wrote:

Hello.

Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with 3.16) broke
dynamic changing of file_operations-[read|write].

At least gadgetfs is a victim.

Feel free to ask me off-list for a patch as I don't want to end up in
annoying discussions on Linux kernel lists anymore.

Alexander Holler


CC'ing Al.


I know.  FWIW, gadgetfs is one of the very few places that tried to pull that
crap off and it had always been seriously racy.  I've posted a partial analysis
about a month ago (20150204190645.gj29...@zeniv.linux.org.uk).

If Alexander (or anybody else) has a patch that really fixes that thing,
I would certainly like to see it.  If not, I'll try to cook something,
but I'm not very familiar with that code.  I really hope that this patch
isn't modify -f_mode to match -f_op change - that's too racy.
We'll obviously need to fix the userland-visible breakage in that one,
but that's not the way to go...


I exactly did what you've assumed, I've just fixed f_mode but not the 
already existing races which I haven't introduced. So I was right in not 
sending a patch as would have been blamed for not rewriting everything 
as so often.





--
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: gadgetfs broken since 7f7f25e8

2015-03-02 Thread Richard Weinberger 
On Mon, Mar 2, 2015 at 9:28 AM, Alexander Holler hol...@ahsoftware.de wrote:
 Hello.

 Commit 7f7f25e82d54870df24d415a7007fbd327da027b (introduced with 3.16) broke
 dynamic changing of file_operations-[read|write].

 At least gadgetfs is a victim.

 Feel free to ask me off-list for a patch as I don't want to end up in
 annoying discussions on Linux kernel lists anymore.

 Alexander Holler

CC'ing Al.

-- 
Thanks,
//richard
--
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 0/2] ARM: at91: dt: at91sam9n12ek: enable udp device

2015-03-02 Thread Bo Shen 

Hi Nicolas,

On 02/10/2015 09:55 AM, Bo Shen wrote:

This patch series enable usb device support on at91sam9n12ek board.

Changes in v2:
   - Base on next-20150209 (so, remove the modification of udc driver).
   - Add pinctrl for usb1 vbus sense.

Bo Shen (2):
   ARM: at91: dt: at91sam9n12: add udp device node
   ARM: at91: dt: at91sam9n12ek: enable udp


Any comments for this patch series? (aka ping?)


  arch/arm/boot/dts/at91sam9n12.dtsi  |  9 +
  arch/arm/boot/dts/at91sam9n12ek.dts | 14 ++
  2 files changed, 23 insertions(+)



Best Regards,
Bo Shen
--
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: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend

2015-03-02 Thread David Vrabel 
On 26/02/15 13:35, Juergen Gross wrote:
 Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
 domU to communicate with a USB device assigned to that domU. The
 communication is all done via the pvUSB backend in a driver domain
 (usually Dom0) which is owner of the physical device.

Why do we need a kernel usb backend instead of a user-space one using
libusb?

 Changes from the original version are:
 - port to upstream kernel
 - put all code in just one source file

?? I'm not sure that was an improvement.  The resulting single file is
too large IMO.

 - move module to appropriate location in kernel tree

drivers/xen/ is the correct location for this driver.

(I've not given the driver a detailed review yet.)

David
--
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: plusb: Add support for National Instruments host-to-host cable

2015-03-02 Thread Ben Shelton 
On 02/27, David Miller wrote:
 From: Ben Shelton ben.shel...@ni.com
 Date: Fri, 27 Feb 2015 15:26:32 -0600
 
  On 02/20, David Miller wrote:
  From: Ben Shelton ben.shel...@ni.com
  Date: Mon, 16 Feb 2015 13:47:06 -0600
  
   The National Instruments USB Host-to-Host Cable is based on the Prolific
   PL-25A1 chipset.  Add its VID/PID so the plusb driver will recognize it.
   
   Signed-off-by: Ben Shelton ben.shel...@ni.com
  
  Applied, thanks.
  
  Hi David,
  
  Is this something you think would go into stable as well?
 
 I'm ambivalent.

In that case, could you go ahead and apply it to stable as well?

Thanks,
Ben
--
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 00/22] usb: musb: the big MUSB patch bomb

2015-03-02 Thread Bin Liu 
Felipe,

On Fri, Feb 27, 2015 at 3:45 PM, Felipe Balbi ba...@ti.com wrote:
 On Fri, Feb 27, 2015 at 03:22:11PM -0600, Bin Liu wrote:
 Felipe,

 On Thu, Feb 26, 2015 at 2:53 PM, Felipe Balbi ba...@ti.com wrote:
  Hi folks,
 
  this is v3 of my patchset which has been in discussion with
  Bin Liu (hey, thanks).

 Thanks for clean this up. Dropping reset from the babble handling has
 been on my TODO for a long time, but never got a chance to do it.

 
  patches have been tested with AM335x BBB using g_zero and
  g_mass_storage.
 
  My BBB, for whatever reason, always causes babble when I
  connect the peripheral port to the host port on the same
  board. So that was a great platform for testing this patchset.
 
  I can see that after babble recovery runs, we drop the session,
  tell usbcore about it and restart the session, which causes
  g_zero to enumerate. If, after that, I drop g_zero and plug
  a mass storage pendrive or load g_mass_storage on the peripheral
  port, everything works fine.

 I tested it on AM335x GP EVM, babble recovery seems working fine.

 Please feel free to add me to 'Tested-by', or 'Reviewed-by', or
 'Signed-off-by', or whatever on patch #16, 17, 19, and 22. I really
 don't know the meaning among them in kernel anyway...

 well, since you tested the whole series, I'll add Tested-by to the
 entire series, thanks.

Ok. Thanks.
-Bin.


 --
 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 20/29] usb: gadget: composite: add req_match method to usb_function

2015-03-02 Thread Bin Liu 
Hi,

On Mon, Mar 2, 2015 at 2:38 AM, Andrzej Pietrasiewicz
andrze...@samsung.com wrote:
 W dniu 27.02.2015 o 21:58, Felipe Balbi pisze:

 Hi,

 On Fri, Feb 27, 2015 at 02:55:25PM -0600, Felipe Balbi wrote:

 On Mon, Feb 23, 2015 at 04:02:09PM +0100, Andrzej Pietrasiewicz wrote:

 Non-standard requests can encode the actual interface number in a
 non-standard way. For example composite_setup() assumes
 that it is w_index  0xFF, but the printer function encodes the
 interface
 number in a context-dependet way (either w_index or w_index  8).
 This can lead to such requests being directed to wrong functions.

 This patch adds req_match() method to usb_function. Its purpose is to
 verify that a given request can be handled by a given function.
 If any function within a configuration provides the method and it
 returns
 true, then it is assumed that the right function is found.

 If a function uses req_match(), it should try as hard as possible to
 determine if the request is meant for it.

 If no functions in a configuration provide req_match or none of them
 returns true, then fall back to the usual approach.

 Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com


 this regresses testusb at least on am335x:


 I don't have this particular hardware but will try looking into the issue.
 As soon as I have some results I will let you know.

I am unable to explain what I found below. Toolchain related?

I added the following change to the driver.

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 07cee80..3b0e5da 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1781,6 +1781,7 @@ unknown:
break;
}
 try_fun_setup:
+   dev_err(NULL, f %p, -setup %p\n, f, f-setup);
if (f  f-setup)
value = f-setup(f, ctrl);
else {

Then, got the following kernel crash log.

[   59.365832] (NULL device *): f bf0116ac, -setup 00400403
[   59.371515] Unable to handle kernel paging request at virtual
address 00400402

So the problem is f-setup pointer is not word aligned.

The following patch seems make the issue disappeared.

diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 51f477a..dde3184 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -212,10 +212,10 @@ struct usb_function {
int (*get_alt)(struct usb_function *,
unsigned interface);
void(*disable)(struct usb_function *);
-   bool(*req_match)(struct usb_function *,
-   const struct usb_ctrlrequest *);
int (*setup)(struct usb_function *,
const struct usb_ctrlrequest *);
+   bool(*req_match)(struct usb_function *,
+   const struct usb_ctrlrequest *);
void(*suspend)(struct usb_function *);
void(*resume)(struct usb_function *);

Regards,
-Bin.


 AP


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

Re: [PATCH v2] usb/isp1760: set IRQ flags properly

2015-03-02 Thread laurent . pinchart 
Hi Valentin,

Thank  you for the patch.

On Sun Mar 01 2015 17:54:32 GMT+0200 (EET), Valentin Rothberg wrote:
 The IRQF_DISABLED is a NOOP and scheduled to be removed.  According to
 commit e58aa3d2d0cc (genirq: Run irq handlers with interrupts
 disabled) running IRQ handlers with interrupts enabled can cause stack
 overflows when the interrupt line of the issuing device is still active.
 
 This patch removes using this deprecated flag and additionally removes
 redundantly setting IRQF_SHARED for isp1760_udc_register().
 
 Signed-off-by: Valentin Rothberg valentin.rothb...@lip6.fr

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
 v2: Reverted change that removed IRQF_SHARED in the call of
 isp1760_hcd_register().
 ---
  drivers/usb/isp1760/isp1760-core.c | 3 +--
  drivers/usb/isp1760/isp1760-udc.c  | 4 ++--
  2 files changed, 3 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/usb/isp1760/isp1760-core.c 
 b/drivers/usb/isp1760/isp1760-core.c
 index b982755..bfa402c 100644
 --- a/drivers/usb/isp1760/isp1760-core.c
 +++ b/drivers/usb/isp1760/isp1760-core.c
 @@ -151,8 +151,7 @@ int isp1760_register(struct resource *mem, int irq, 
 unsigned long irqflags,
   }
  
   if (IS_ENABLED(CONFIG_USB_ISP1761_UDC)  !udc_disabled) {
 - ret = isp1760_udc_register(isp, irq, irqflags | IRQF_SHARED |
 -IRQF_DISABLED);
 + ret = isp1760_udc_register(isp, irq, irqflags);
   if (ret  0) {
   isp1760_hcd_unregister(isp-hcd);
   return ret;
 diff --git a/drivers/usb/isp1760/isp1760-udc.c 
 b/drivers/usb/isp1760/isp1760-udc.c
 index 9612d79..0b46ff0 100644
 --- a/drivers/usb/isp1760/isp1760-udc.c
 +++ b/drivers/usb/isp1760/isp1760-udc.c
 @@ -1451,8 +1451,8 @@ int isp1760_udc_register(struct isp1760_device *isp, 
 int irq,
  
   sprintf(udc-irqname, %s (udc), devname);
  
 - ret = request_irq(irq, isp1760_udc_irq, IRQF_SHARED | IRQF_DISABLED |
 -   irqflags, udc-irqname, udc);
 + ret = request_irq(irq, isp1760_udc_irq, IRQF_SHARED | irqflags,
 +   udc-irqname, udc);
   if (ret  0)
   goto error;
  
 -- 
 1.9.1
 
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h����G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�

Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko

2015-03-02 Thread Alan Stern 
On Fri, 27 Feb 2015, Christian Böhme wrote:

 Alan Stern stern@... writes:
 
   Specifically, HID_QUIRK_IGNORE_MOUSE existed in 2.6.27
   and was dealt with in drivers/hid/usbhid/hid-core.c:730,
   thereby somehow fixing things.  But those lines (and
   the symbol) disappeared after 2.6.27.  Why were they
   removed?
  
  They weren't removed.  The symbol was changed to APPLE_IGNORE_MOUSE and 
  the implementation was moved to drivers/hid/hid-apple.c.  To get the 
  benefit, you have to enable CONFIG_HID_APPLE.
 …
  It should have been working all along if your kernel configuration was 
  correct.
 
 $ uname -r
 3.16.0-4-amd64
 $ grep CONFIG_HID_APPLE /boot/config-3.16.0-4-amd64 
 CONFIG_HID_APPLE=m
 CONFIG_HID_APPLEIR=m
 $ lsmod | grep hid_apple
 hid_appleir12724  0 
 hid_apple  12596  0 
 hid   102264  4 hid_generic,usbhid,hid_appleir,hid_apple
 $ lsusb -d 05ac:0231
 Bus 005 Device 020: ID 05ac:0231 Apple, Inc. Internal Keyboard/Trackpad \
 (MacBook Pro 4,1) (ISO)

Which matches the APPLE_WELLSPRING2_ISO entry in the device list.

 Now, APPLE_IGNORE_MOUSE only appears in drivers/hid/hid-apple.c:28, where
 it is #define'd but never referenced, making it hard for me to see the
 connection.

True enough.  The hid-apple.c driver was separated out in commit
8c19a51591d0 (HID: move apple quirks), at which time the
APPLE_IGNORE_MOUSE quirk was indeed used in the source code.

However, the quirk was removed in commit b4d8e4736c94 (HID: fix 
hidbus/appletouch device binding regression).  For some reason that 
commit failed to remove the APPLE_IGNORE_MOUSE #define, though.

 However, while looking for uses of USB_DEVICE_ID_APPLE_WELLSPRING2_ISO,
 I found hid_mouse_ignore_list defined in drivers/hid/hid-core.c:2358 and
 referenced after the switch statement in drivers/hid/hid-core.c:2482 as an
 argument to hid_match_id(), which is executed only if the device's type in
 question is of HID_TYPE_USBMOUSE.

Yes, that is the replacement code added by commit b4d8e4736c94.

  If I had to venture a guess here I'd say
 that that is never the case.

I agree.  The problem is that the HID core now tests for hdev-type ==
HID_TYPE_USBMOUSE, but it doesn't test for bInterfaceProtocol ==
USB_INTERFACE_PROTOCOL_MOUSE like the older code did.

This issue should be reported to the author of that second commit
(CC'ed).

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: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

2015-03-02 Thread Alan Stern 
On Mon, 2 Mar 2015, Aleksander Morgado wrote:

 On Mon, Mar 2, 2015 at 4:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
  On Mon, 2 Mar 2015, Aleksander Morgado wrote:
 
  I think my patch also lacks the -EREMOTEIO return for the case when 0
  bytes are transferred. I'll try to update it today.
 
  It's not necessary.  The USB core automatically sets the status to
  -EREMOTEIO if the status is equal to 0 and the transfer was short and
  URB_SHORT_NOT_OK was set.  See __usb_hcd_giveback_urb()
 
 There are actually several places in xhci-ring.c where that check is
 done in order to return -EREMOTEIO; does that mean that all of them
 are redundant? e.g. not only the ones in process_ctrl_td() but also in
 finish_td().

Yes, they are redundant.

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: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

2015-03-02 Thread Aleksander Morgado 
On Mon, Mar 2, 2015 at 4:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 2 Mar 2015, Aleksander Morgado wrote:

 I think my patch also lacks the -EREMOTEIO return for the case when 0
 bytes are transferred. I'll try to update it today.

 It's not necessary.  The USB core automatically sets the status to
 -EREMOTEIO if the status is equal to 0 and the transfer was short and
 URB_SHORT_NOT_OK was set.  See __usb_hcd_giveback_urb()

There are actually several places in xhci-ring.c where that check is
done in order to return -EREMOTEIO; does that mean that all of them
are redundant? e.g. not only the ones in process_ctrl_td() but also in
finish_td().

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

Re: [RFC PATCH] xhci: fix reporting of 0-sized URBs in control endpoints

2015-03-02 Thread Alan Stern 
On Mon, 2 Mar 2015, Aleksander Morgado wrote:

 On Mon, Mar 2, 2015 at 6:10 PM, Alan Stern st...@rowland.harvard.edu wrote:
  On Mon, Mar 2, 2015 at 4:02 PM, Alan Stern st...@rowland.harvard.edu 
  wrote:
   On Mon, 2 Mar 2015, Aleksander Morgado wrote:
  
   I think my patch also lacks the -EREMOTEIO return for the case when 0
   bytes are transferred. I'll try to update it today.
  
   It's not necessary.  The USB core automatically sets the status to
   -EREMOTEIO if the status is equal to 0 and the transfer was short and
   URB_SHORT_NOT_OK was set.  See __usb_hcd_giveback_urb()
 
  There are actually several places in xhci-ring.c where that check is
  done in order to return -EREMOTEIO; does that mean that all of them
  are redundant? e.g. not only the ones in process_ctrl_td() but also in
  finish_td().
 
  Yes, they are redundant.
 
 I guess my v5 of the patch is still ok; right?

I didn't notice anything wrong with it.

 I can prepare a new
 patch to remove all the redundant -EREMOTEIO returns later.

Alan Stern

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

Re: [PATCH v2 3/3] ARM: mvebu: armada-385-ap: Enable USB3 port

2015-03-02 Thread Gregory CLEMENT 
Hi Maxime,

On 19/01/2015 14:01, Maxime Ripard wrote:
 The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
 VBUS line. Enable the needed drivers to support this.
 

it seems that this patch was not applied yet. Patch 1 is now in
linux-next and should be part of 4.0-rc. But what about patch 2?

Thanks,

Gregory


 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 ---
  arch/arm/boot/dts/armada-385-db-ap.dts | 28 
  1 file changed, 28 insertions(+)
 
 diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts 
 b/arch/arm/boot/dts/armada-385-db-ap.dts
 index 3a51531eb37b..b891b4c897f5 100644
 --- a/arch/arm/boot/dts/armada-385-db-ap.dts
 +++ b/arch/arm/boot/dts/armada-385-db-ap.dts
 @@ -98,6 +98,13 @@
   status = okay;
   };
  
 + pinctrl@18000 {
 + xhci0_vbus_pins: xhci0-vbus-pins {
 + marvell,pins = mpp44;
 + marvell,function = gpio;
 + };
 + };
 +
   ethernet@3 {
   status = okay;
   phy = phy2;
 @@ -122,6 +129,11 @@
   phy = phy0;
   phy-mode = rgmii-id;
   };
 +
 + usb3@f {
 + status = okay;
 + usb-phy = usb3_phy;
 + };
   };
  
   pcie-controller {
 @@ -147,4 +159,20 @@
   };
   };
   };
 +
 + usb3_phy: usb3_phy {
 + compatible = usb-nop-xceiv;
 + vcc-supply = reg_xhci0_vbus;
 + };
 +
 + reg_xhci0_vbus: xhci0-vbus {
 + compatible = regulator-fixed;
 + pinctrl-names = default;
 + pinctrl-0 = xhci0_vbus_pins;
 + regulator-name = xhci0-vbus;
 + regulator-min-microvolt = 500;
 + regulator-max-microvolt = 500;
 + enable-active-high;
 + gpio = gpio1 12 GPIO_ACTIVE_HIGH;
 + };
  };
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html