Re: [PATCH v2 4/4] Documentation: ABI: Fix documentation for mass_storage function

[Krzysztof Opasiak]

On 04/09/2015 10:32 AM, Tal Shorer wrote:

On Wed, Apr 8, 2015 at 3:06 PM, Krzysztof Opasiak k.opas...@samsung.com wrote:

Luns in mass storage function are identified using their id.
While creating lun's directory user cannot choose any arbitrary
name other than arabic numeral from 1 to FSG_MAX_LUNS.

Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
  .../ABI/testing/configfs-usb-gadget-mass-storage   |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage 
b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
index 9931fb0..0b54280 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
+++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
@@ -11,10 +11,15 @@ Description:
 are 2..4. Available only if
 CONFIG_USB_GADGET_DEBUG_FILES is set.

-What:  /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
+What:  /config/usb-gadget/gadget/functions/mass_storage.name/lun.id
  Date:  Oct 2013
  KernelVersion: 3.13
  Description:
+   id - arabic numeral from 1 to FSG_MAX_LUNS

I think decimal number or decimal value would be easier to understand.


True. Will fix in v3.

Thanks,

--
Krzysztof Opasiak
Samsung RD 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 4/5] usb: gadget: mass_storage: Ensure that lun ids are contiguous

[Felipe Balbi]

On Wed, Apr 08, 2015 at 01:28:47PM +0200, Krzysztof Opasiak wrote:
 Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com

no commit log

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection

[Robert Baldyga]

On 04/09/2015 11:59 AM, Roger Quadros wrote:
 Hi,
 
 On 09/04/15 12:24, Robert Baldyga wrote:
 Hi Chanwoo,

 On 04/09/2015 11:07 AM, Chanwoo Choi wrote:
 Hi Robert,

 On 04/09/2015 04:57 PM, Robert Baldyga wrote:
 Hi Chanwoo,

 On 04/09/2015 04:12 AM, Chanwoo Choi wrote:
 Hi Robert,


 [snip]

 But, I have one question about case[3]

 If id is low and vbus is high, this patch will update the state of both 
 USB and USB-HOST cable as attached state.
 Is it possible that two different cables (both USB and USB-HOST) are 
 connected to one port simultaneously?


 It's because state of single USB cable connection cannot be completely
 described using single extcon cable. USB cable state has two bits (VBUS
 and ID), so we need to use two cables for single cable connection. We
 use following convention:
 cable USB = VBUS
 cable USB-HOST = !ID.

 I think that extcon provider driver have to update the only one cable state
 of either USB or USB-HOST because USB and USB-HOST feature can not be used
 at the same time through one h/w port.
 
 At least for the kernel users [1] we are treating USB-HOST as !ID and USB as 
 VBUS.
 So it is not an issue for these kernel users if both USB and USB-HOST are 
 attached.
 This is a valid USB state.
 If we don't do so then extcon with 3 cable states is not sufficient to 
 capture the
 entire USB scenario. (we need 4 states for 2 pins).
 
 [1]
 - drivers/usb/phy/phy-omap-otg.c
 - drivers/usb/dwc3/dwc3-omap.c
 
 

 If extcon-usb-gpio.c update two connected event of both USB and USB-HOST 
 cable
 at the same time, the extcon consumer driver can not decide what handle 
 either USB or USB-HOST.


 It can. USB OTG allows for that. Moreover device can be host even if
 ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so
 detected cable type is USB host). Devices would need to have complete
 information about USB cable connection, because OTG state machine needs
 that. As I wrote, current USB cable names are misleading. It would be
 better to have USB-VBUS and USB-ID.
 
 We need to first understand how user space is using USB and USB-HOST 
 events
 and does it cause an issue if both USB and USB-HOST become attached.
 
 What is the ABI explanation for USB and USB-HOST cable states?
 

We can also leave USB and USB-HOST as dummy cable detection states,
like they currently are, and add new USB-VBUS and USB-ID cables without
removing the old ones. It will cause some redundancy, but will make us
sure, that no ABI break can have a place.

Thanks,
Robert Baldyga
--
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: Unable to access USB mass storage device with xhci. okay with ehci

[Hans de Goede]

Hi,

On 09-04-15 15:27, Steve Bangert wrote:

On Wed, 2015-04-08 at 10:56 -0400, Alan Stern wrote:

On Wed, 8 Apr 2015, Steve Bangert wrote:


What i did was not correct, usb-storage.quirks=174c:55aa:u was added to
/etc/default/grub file after GRUB_CMDLINE_LINUX=rhgb quiet, using
the grub-configurator tool
followed by a reboot and i now have a working usb storage device
using xhci. Here's the usbmon trace and the dmesg log is attached.

I also found a comment in the source code file (uas-detect.h see
attached) that states that my device, the ASMedia bridge is not
supported by the uas driver.


The comment does not say that.  It refers to a different model from
yours.  You can tell because the comment says that the non-working
ASM1051 supports 32 streams, whereas your device supports 16.

In fact, as far as I can tell, your device _does_ work with the uas
driver provided max_sectors isn't too high (i.e., = 240, which is the
default value used by usb-storage).  Unfortunately, the uas driver
doesn't provide any way to set max_sectors.

You can test this by adding a line that says:

.max_sectors = 240,

anywhere inside the definition of uas_host_template in the uas.c source
file.


So my next question is there a way to bind usb-storage to this device
and have a working device out of the box without the hassle of adding
a module parameter?


We should ask Hans, since he wrote the comment and code in uas-detect.h
and presumably has a better understanding of the situation.



uas.c was patched (see attached), the quirk line was temporarily removed


Thanks for testing this.


and i now have access to the drive using xhci and uas. usbmon trace is
attached.


What exactly do you mean with i now have access to the drive using xhci and 
uas ?
Do you mean that everything works correctly with xhci + uas when setting
.max_sectors = 240 ?

Alan, any ideas on how to move forward with this, I do not want to limit all
uas devices to .max_sectors = 240, I can whip up a patch to set max_sectors = 
240
on the ASM1053 but not the ASM1153.

Steve, can you send me the output of lsusb -vv for the device in question ?

Regards,

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

Re: [PATCH 1/5] fs: configfs: Fix typo in comment

[Felipe Balbi]

On Wed, Apr 08, 2015 at 01:28:44PM +0200, Krzysztof Opasiak wrote:
 Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
 ---
  fs/configfs/dir.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
 index cf0db00..dee1cb5 100644
 --- a/fs/configfs/dir.c
 +++ b/fs/configfs/dir.c
 @@ -325,7 +325,7 @@ static void configfs_dir_set_ready(struct configfs_dirent 
 *sd)
   * attached and not validated yet.
   * @sd   configfs_dirent of the directory to check
   *
 - * @return   non-zero iff the directory was validated
 + * @return   non-zero if the directory was validated

iff is not a typo, it's short-hand for if, and only if

   *
   * Note: takes configfs_dirent_lock, so the result may change from false to 
 true
   * in two consecutive calls, but never from true to false.
 -- 
 1.7.9.5
 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection

[Robert Baldyga]

Hi Chanwoo,

On 04/09/2015 04:12 AM, Chanwoo Choi wrote:
 Hi Robert,
 
 On 04/02/2015 10:13 PM, Robert Baldyga wrote:
 This patch adds VBUS pin detection support to extcon-usb-gpio driver.
 It allows to use this driver with boards which have both VBUS and ID
 pins, or only one of them.

 Following table of states presents relationship between this signals
 and detected cable type:

  State  |ID   |   VBUS
 
  [1] USB|H|H
  [2] none   |H|L
  [3] USB  USB-HOST |L|H
  [4] USB-HOST   |L|L

 In case we have only one of these signals:
 - VBUS only - we want to distinguish between [1] and [2], so ID is always 1.
 - ID only - we want to distinguish between [1] and [4], so VBUS = ID.

 Signed-off-by: Robert Baldyga r.bald...@samsung.com
 ---
  drivers/extcon/extcon-usb-gpio.c | 169 
 +++
  1 file changed, 119 insertions(+), 50 deletions(-)

 diff --git a/drivers/extcon/extcon-usb-gpio.c 
 b/drivers/extcon/extcon-usb-gpio.c
 index f6aa99d..baf7add 100644
 --- a/drivers/extcon/extcon-usb-gpio.c
 +++ b/drivers/extcon/extcon-usb-gpio.c
 @@ -32,7 +32,9 @@ struct usb_extcon_info {
  struct extcon_dev *edev;
  
  struct gpio_desc *id_gpiod;
 +struct gpio_desc *vbus_gpiod;
  int id_irq;
 +int vbus_irq;
  
  unsigned long debounce_jiffies;
  struct delayed_work wq_detcable;
 @@ -52,40 +54,51 @@ static const char *usb_extcon_cable[] = {
  NULL,
  };
  
 +/*
 + * USB = VBUS and USB-HOST = !ID, so we have:
 + *
 + *  State  |ID   |   VBUS
 + * 
 + *  [1] USB|H|H
 + *  [2] none   |H|L
 + *  [3] USB  USB-HOST |L|H
 + *  [4] USB-HOST   |L|L
 + *
 + * In case we have only one of these signals:
 + * - VBUS only - we want to distinguish between [1] and [2], so ID is 
 always 1.
 + * - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
 + */
 +
  static void usb_extcon_detect_cable(struct work_struct *work)
  {
  int id;
 +int vbus;
  struct usb_extcon_info *info = container_of(to_delayed_work(work),
  struct usb_extcon_info,
  wq_detcable);
  
 -/* check ID and update cable state */
 -id = gpiod_get_value_cansleep(info-id_gpiod);
 -if (id) {
 -/*
 - * ID = 1 means USB HOST cable detached.
 - * As we don't have event for USB peripheral cable attached,
 - * we simulate USB peripheral attach here.
 - */
 +/* check ID and VBUS and update cable state */
 +
 +id = info-id_gpiod ?
 +gpiod_get_value_cansleep(info-id_gpiod) : 1;
 +
 +vbus = info-vbus_gpiod ?
 +gpiod_get_value_cansleep(info-vbus_gpiod) : id;
 +
 +/* at first we clean states which are no longer active */
 +if (id)
  extcon_set_cable_state(info-edev,
 -   usb_extcon_cable[EXTCON_CABLE_USB_HOST],
 -   false);
 +usb_extcon_cable[EXTCON_CABLE_USB_HOST], false);
 +if (!vbus)
  extcon_set_cable_state(info-edev,
 -   usb_extcon_cable[EXTCON_CABLE_USB],
 -   true);
 -} else {
 -/*
 - * ID = 0 means USB HOST cable attached.
 - * As we don't have event for USB peripheral cable detached,
 - * we simulate USB peripheral detach here.
 - */
 +usb_extcon_cable[EXTCON_CABLE_USB], false);
 +
 +if (!id)
  extcon_set_cable_state(info-edev,
 -   usb_extcon_cable[EXTCON_CABLE_USB],
 -   false);
 +usb_extcon_cable[EXTCON_CABLE_USB_HOST], true);
 +if (vbus)
  extcon_set_cable_state(info-edev,
 -   usb_extcon_cable[EXTCON_CABLE_USB_HOST],
 -   true);
 -}
 +usb_extcon_cable[EXTCON_CABLE_USB], true);
  }
 
 Looks good to me of this patch.
 
 But, I have one question about case[3]
 
 If id is low and vbus is high, this patch will update the state of both USB 
 and USB-HOST cable as attached state.
 Is it possible that two different cables (both USB and USB-HOST) are 
 connected to one port simultaneously?
 

It's because state of single USB cable connection cannot be completely
described using single extcon cable. USB cable state has two bits (VBUS
and ID), so we need to use two cables for single cable connection. We
use following convention:
cable USB = VBUS
cable USB-HOST = !ID.

In fact it would be better to have cables named USB-VBUS and USB-ID
- in this convention it would be more 

Re: [PATCH 3/5] usb: gadget: mass_storage: Store lun_opts in fsg_opts

[Felipe Balbi]

On Wed, Apr 08, 2015 at 01:28:46PM +0200, Krzysztof Opasiak wrote:
 Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com

no commit log

-- 
balbi


signature.asc
Description: Digital signature

Re: Unable to access USB mass storage device with xhci. okay with ehci

[Steve Bangert]

On Thu, 2015-04-09 at 16:49 +0200, Hans de Goede wrote:
 Hi,
 
 On 09-04-15 15:27, Steve Bangert wrote:
  On Wed, 2015-04-08 at 10:56 -0400, Alan Stern wrote:
  On Wed, 8 Apr 2015, Steve Bangert wrote:
 
  What i did was not correct, usb-storage.quirks=174c:55aa:u was added to
  /etc/default/grub file after GRUB_CMDLINE_LINUX=rhgb quiet, using
  the grub-configurator tool
  followed by a reboot and i now have a working usb storage device
  using xhci. Here's the usbmon trace and the dmesg log is attached.
 
  I also found a comment in the source code file (uas-detect.h see
  attached) that states that my device, the ASMedia bridge is not
  supported by the uas driver.
 
  The comment does not say that.  It refers to a different model from
  yours.  You can tell because the comment says that the non-working
  ASM1051 supports 32 streams, whereas your device supports 16.
 
  In fact, as far as I can tell, your device _does_ work with the uas
  driver provided max_sectors isn't too high (i.e., = 240, which is the
  default value used by usb-storage).  Unfortunately, the uas driver
  doesn't provide any way to set max_sectors.
 
  You can test this by adding a line that says:
 
 .max_sectors = 240,
 
  anywhere inside the definition of uas_host_template in the uas.c source
  file.
 
  So my next question is there a way to bind usb-storage to this device
  and have a working device out of the box without the hassle of adding
  a module parameter?
 
  We should ask Hans, since he wrote the comment and code in uas-detect.h
  and presumably has a better understanding of the situation.
 
 
  uas.c was patched (see attached), the quirk line was temporarily removed
 
 Thanks for testing this.
 
  and i now have access to the drive using xhci and uas. usbmon trace is
  attached.
 
 What exactly do you mean with i now have access to the drive using xhci and 
 uas ?
 Do you mean that everything works correctly with xhci + uas when setting
 .max_sectors = 240 ?
 
 Alan, any ideas on how to move forward with this, I do not want to limit all
 uas devices to .max_sectors = 240, I can whip up a patch to set max_sectors = 
 240
 on the ASM1053 but not the ASM1153.
 
 Steve, can you send me the output of lsusb -vv for the device in question ?

Hans, thanks for you assistance with this concern.  Steve

Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051 SATA
3Gb/s bridge
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 9
  idVendor   0x174c ASMedia Technology Inc.
  idProduct  0x55aa ASM1051 SATA 3Gb/s bridge
  bcdDevice1.00
  iManufacturer   2 
  iProduct3 
  iSerial 1 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  121
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower   36mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  15
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  15
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   1
  bNumEndpoints   4
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 98 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  

Re: [PATCH 1/2] usb: Prefer firmware values when determining whether a port is removable

[Matthew Garrett]

On Thu, Apr 9, 2015 at 2:31 AM, Greg KH gre...@linuxfoundation.org wrote:
 Anyway, is this all a Windows 8 requirement?  If so, I'll feel
 comfortable making these changes, otherwise we are at the mercy of the
 bios people to randomly get things right, and we all know how often that
 works...

It's covered by
System.Fundamentals.SystemUSB.XHCIControllersMustHaveEmbeddedInfo - I
guess there's an argument for having the order depend on the
controller, but I suspect that anything with _PLD and _UPC objects
will be fine. The alternative means we're just relying on a different
set of firmware information (ie, did the hardware vendor bother
setting the hub flags), so...


-- 
Matthew Garrett | matthew.garr...@coreos.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

[PATCH 2/2] usb: phy: msm: Manual PHY and LINK controller VBUS change notification

[Ivan T. Ivanov]

VBUS is not routed to USB PHY on recent Qualcomm platforms. USB controller
must see VBUS in order to pull-up DP when setting RS bit. Henc configure
USB PHY and LINK registers sense VBUS and enable manual pullup on D+ line.

Cc: Vamsi Krishna vskri...@codeaurora.org
Cc: Mayank Rana mr...@codeaurora.org
Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
 .../devicetree/bindings/usb/msm-hsusb.txt  |  4 
 drivers/usb/phy/phy-msm-usb.c  | 26 ++
 include/linux/usb/msm_hsusb.h  |  5 +
 include/linux/usb/msm_hsusb_hw.h   |  9 
 4 files changed, 44 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index f26bcfa..bd8d9e7 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -69,6 +69,10 @@ Optional properties:
 (no, min, max) where each value represents either a voltage
 in microvolts or a value corresponding to voltage corner.

+- qcom,manual-pullup: If present, vbus is not routed to USB controller/phy
+and controller driver therefore enables pull-up explicitly
+before starting controller using usbcmd run/stop bit.
+
 - extcon:   phandles to external connector devices. First phandle
 should point to external connector, which provide USB
 cable events, the second should point to external connector
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index d47c3eb..4a928f7 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -245,8 +245,14 @@ static void ulpi_init(struct msm_otg *motg)
 static int msm_phy_notify_disconnect(struct usb_phy *phy,
   enum usb_device_speed speed)
 {
+   struct msm_otg *motg = container_of(phy, struct msm_otg, phy);
int val;

+   if (motg-manual_pullup) {
+   val = ULPI_MISC_A_VBUSVLDEXT | ULPI_MISC_A_VBUSVLDEXTSEL;
+   usb_phy_io_write(phy, val, ULPI_CLR(ULPI_MISC_A));
+   }
+
/*
 * Put the transceiver in non-driving mode. Otherwise host
 * may not detect soft-disconnection.
@@ -431,6 +437,24 @@ static int msm_phy_init(struct usb_phy *phy)
ulpi_write(phy, ulpi_val, ULPI_USB_INT_EN_FALL);
}

+   if (motg-manual_pullup) {
+   val = ULPI_MISC_A_VBUSVLDEXTSEL | ULPI_MISC_A_VBUSVLDEXT;
+   ulpi_write(phy, val, ULPI_SET(ULPI_MISC_A));
+
+   val = readl(USB_GENCONFIG_2);
+   val |= GENCONFIG_2_SESS_VLD_CTRL_EN;
+   writel(val, USB_GENCONFIG_2);
+
+   val = readl(USB_USBCMD);
+   val |= USBCMD_SESS_VLD_CTRL;
+   writel(val, USB_USBCMD);
+
+   val = ulpi_read(phy, ULPI_FUNC_CTRL);
+   val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
+   val |= ULPI_FUNC_CTRL_OPMODE_NORMAL;
+   ulpi_write(phy, val, ULPI_FUNC_CTRL);
+   }
+
if (motg-phy_number)
writel(readl(USB_PHY_CTRL2) | BIT(16), USB_PHY_CTRL2);

@@ -1529,6 +1553,8 @@ static int msm_otg_read_dt(struct platform_device *pdev, 
struct msm_otg *motg)
motg-vdd_levels[VDD_LEVEL_MAX] = tmp[VDD_LEVEL_MAX];
}

+   motg-manual_pullup = of_property_read_bool(node, qcom,manual-pullup);
+
ext_id = ERR_PTR(-ENODEV);
ext_vbus = ERR_PTR(-ENODEV);
if (of_property_read_bool(node, extcon)) {
diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
index 9a38e77..a5edc8d 100644
--- a/include/linux/usb/msm_hsusb.h
+++ b/include/linux/usb/msm_hsusb.h
@@ -153,6 +153,9 @@ struct msm_usb_cable {
  * @chg_type: The type of charger attached.
  * @dcd_retires: The retry count used to track Data contact
  *   detection process.
+ * @manual_pullup: true if VBUS is not routed to USB controller/phy
+ * and controller driver therefore enables pull-up explicitly before
+ * starting controller using usbcmd run/stop bit.
  * @vbus: VBUS signal state trakining, using extcon framework
  * @id: ID signal state trakining, using extcon framework
  */
@@ -185,6 +188,8 @@ struct msm_otg {
struct reset_control *link_rst;
int vdd_levels[3];

+   bool manual_pullup;
+
struct msm_usb_cable vbus;
struct msm_usb_cable id;
 };
diff --git a/include/linux/usb/msm_hsusb_hw.h b/include/linux/usb/msm_hsusb_hw.h
index a29f603..e159b39 100644
--- a/include/linux/usb/msm_hsusb_hw.h
+++ b/include/linux/usb/msm_hsusb_hw.h
@@ -21,6 +21,8 @@

 #define USB_AHBBURST (MSM_USB_BASE + 0x0090)
 #define USB_AHBMODE  (MSM_USB_BASE + 0x0098)
+#define USB_GENCONFIG_2  (MSM_USB_BASE + 0x00a0)
+
 #define USB_CAPLENGTH(MSM_USB_BASE + 0x0100) /* 8 bit */

 #define USB_USBCMD 

Re: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()

[Johan Hovold]

On Wed, Apr 08, 2015 at 05:29:16PM +, Mark Enstone wrote:
 Everyone, thank you for your attention and suggestions.
 
 Johan, perfect, thank you, that did indeed help and has fixed the
 issue I was seeing.
 
 The change replaced dev_err() with dev_dbg() -- thus not logging (by
 default) what was a very noisy flood of messages. Does that simply
 change timing enough such that the USB HCD has time to process the
 disconnect? Or is there something else going on that I'm missing?

I'm afraid it's only working around the real issue, though.

In my setup, adding a really short udelay (e.g. 100 us) rather than the
printk is also enough to trigger the lock up when using just two bulk-in
urbs.

I thought it was the hub-driver work queue that was starved, but in my
current setup I don't even get a completion callback for the external
hub port-status change.

Same issue with two HS hubs of the same type.

Switching to a different hub appears to make the problem go away. But so
does using the same hub with a different HC (ehci-omap). So can't rule
out musb (and dwc2 on RPi?).

I'll try to find some more time to look into this later.

Alan, what are your thoughts on this? 

My setup is

Beaglebone Black musb - HS hub - FS device

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] usb: renesas_usbhs: Revise the binding document about the dma-names

[Mark Rutland]

On Thu, Apr 09, 2015 at 01:17:44AM +0100, Yoshihiro Shimoda wrote:
 Hi Mark,
 
  
  On Wed, Apr 08, 2015 at 11:42:24AM +0100, Yoshihiro Shimoda wrote:
   Since the DT should describe the hardware (not the driver limitation),
   This patch revises the binding document about the dma-names to change
   simple numbering as ch%d instead of txn and rxn.
  
  The naming given in this patch looks more sensible to me.
 
 Thank you for your comment!
 
   Also this patch fixes the actual code of renesas_usbhs driver to handle
   the new dma-names.
  
   Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
   ---
This patch is based on Felipe's usb.bit / testing/next branch.
(commit id = bbc78c07a51f6fd29c227b1220a9016e585358ba)
  
  I take it the existing driver and binding haven't hit mainline, and
  therefore there are no users yet?
 
 That's correct. At the moment, nobody uses the dma-names in the node of
 renesas_usbhs yet.

Given that:

Acked-by: Mark Rutland mark.rutl...@arm.com

Thanks,
Mark.
--
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: chipidea: Use extcon framework for VBUS and ID detection

[Ivan T. Ivanov]

On recent Qualcomm platforms VBUS and ID lines are not routed to
USB PHY LINK controller. Use extcon framework to receive connect
and disconnect ID and VBUS notification.

Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---

Suggestions for better solution are welcome!

 .../devicetree/bindings/usb/ci-hdrc-qcom.txt   |  9 +++
 drivers/usb/chipidea/Kconfig   |  1 +
 drivers/usb/chipidea/ci.h  | 18 +
 drivers/usb/chipidea/core.c| 77 ++
 drivers/usb/chipidea/otg.c | 19 +-
 5 files changed, 123 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
index f2899b5..788da49 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
@@ -7,6 +7,14 @@ Required properties:
 - usb-phy:  phandle for the PHY device
 - dr_mode:  Should be peripheral

+Optional properties:
+- extcon:   phandles to external connector devices. First phandle
+should point to external connector, which provide USB
+cable events, the second should point to external connector
+device, which provide USB-HOST cable events. If one of
+the external connector devices is not required empty 0
+phandle should be specified.
+
 Examples:
gadget@f9a55000 {
compatible = qcom,ci-hdrc;
@@ -14,4 +22,5 @@ Examples:
dr_mode = peripheral;
interrupts = 0 134 0;
usb-phy = usbphy0;
+   extcon = usb_vbus, usb_id;
};
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 77b47d8..a67b67f 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -1,6 +1,7 @@
 config USB_CHIPIDEA
tristate ChipIdea Highspeed Dual Role Controller
depends on ((USB_EHCI_HCD  USB_GADGET) || (USB_EHCI_HCD  
!USB_GADGET) || (!USB_EHCI_HCD  USB_GADGET))  HAS_DMA
+   depends on EXTCON
help
  Say Y here if your system has a dual role high speed USB
  controller based on ChipIdea silicon IP. Currently, only the
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 65913d4..04e7aee 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -13,6 +13,7 @@
 #ifndef __DRIVERS_USB_CHIPIDEA_CI_H
 #define __DRIVERS_USB_CHIPIDEA_CI_H

+#include linux/extcon.h
 #include linux/list.h
 #include linux/irqreturn.h
 #include linux/usb.h
@@ -132,6 +133,18 @@ struct hw_bank {
 };

 /**
+ * struct ci_hdrc - structure for exteternal connector cable state tracking
+ * @state: current state of the line
+ * @nb: hold event notification callback
+ * @conn: used for notification registration
+ */
+struct ci_cable {
+   boolstate;
+   struct notifier_block   nb;
+   struct extcon_specific_cable_nb conn;
+};
+
+/**
  * struct ci_hdrc - chipidea device representation
  * @dev: pointer to parent device
  * @lock: access synchronization
@@ -169,6 +182,8 @@ struct hw_bank {
  * @b_sess_valid_event: indicates there is a vbus event, and handled
  * at ci_otg_work
  * @imx28_write_fix: Freescale imx28 needs swp instruction for writing
+ * @vbus: VBUS signal state trakining, using extcon framework
+ * @id: ID signal state trakining, using extcon framework
  */
 struct ci_hdrc {
struct device   *dev;
@@ -211,6 +226,9 @@ struct ci_hdrc {
boolid_event;
boolb_sess_valid_event;
boolimx28_write_fix;
+
+   struct ci_cable vbus;
+   struct ci_cable id;
 };

 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a57dc88..0f805bd 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -47,6 +47,7 @@
 #include linux/delay.h
 #include linux/device.h
 #include linux/dma-mapping.h
+#include linux/extcon.h
 #include linux/phy/phy.h
 #include linux/platform_device.h
 #include linux/module.h
@@ -646,9 +647,36 @@ static void ci_get_otg_capable(struct ci_hdrc *ci)
dev_dbg(ci-dev, It is OTG capable controller\n);
 }

+static int ci_vbus_notifier(struct notifier_block *nb, unsigned long event,
+void *ptr)
+{
+   struct ci_cable *vbus = container_of(nb, struct ci_cable, nb);
+
+   if (event)
+   vbus-state = true;
+   else
+   vbus-state = false;
+
+   return NOTIFY_DONE;
+}
+
+static int ci_host_notifier(struct notifier_block *nb, unsigned long event,
+  void *ptr)
+{
+   struct ci_cable *id = container_of(nb, struct ci_cable, 

Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection

[Roger Quadros]

Hi,

On 09/04/15 12:24, Robert Baldyga wrote:
 Hi Chanwoo,
 
 On 04/09/2015 11:07 AM, Chanwoo Choi wrote:
 Hi Robert,

 On 04/09/2015 04:57 PM, Robert Baldyga wrote:
 Hi Chanwoo,

 On 04/09/2015 04:12 AM, Chanwoo Choi wrote:
 Hi Robert,


 [snip]

 But, I have one question about case[3]

 If id is low and vbus is high, this patch will update the state of both 
 USB and USB-HOST cable as attached state.
 Is it possible that two different cables (both USB and USB-HOST) are 
 connected to one port simultaneously?


 It's because state of single USB cable connection cannot be completely
 described using single extcon cable. USB cable state has two bits (VBUS
 and ID), so we need to use two cables for single cable connection. We
 use following convention:
 cable USB = VBUS
 cable USB-HOST = !ID.

 I think that extcon provider driver have to update the only one cable state
 of either USB or USB-HOST because USB and USB-HOST feature can not be used
 at the same time through one h/w port.

At least for the kernel users [1] we are treating USB-HOST as !ID and USB as 
VBUS.
So it is not an issue for these kernel users if both USB and USB-HOST are 
attached.
This is a valid USB state.
If we don't do so then extcon with 3 cable states is not sufficient to capture 
the
entire USB scenario. (we need 4 states for 2 pins).

[1]
- drivers/usb/phy/phy-omap-otg.c
- drivers/usb/dwc3/dwc3-omap.c



 If extcon-usb-gpio.c update two connected event of both USB and USB-HOST 
 cable
 at the same time, the extcon consumer driver can not decide what handle 
 either USB or USB-HOST.

 
 It can. USB OTG allows for that. Moreover device can be host even if
 ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so
 detected cable type is USB host). Devices would need to have complete
 information about USB cable connection, because OTG state machine needs
 that. As I wrote, current USB cable names are misleading. It would be
 better to have USB-VBUS and USB-ID.

We need to first understand how user space is using USB and USB-HOST events
and does it cause an issue if both USB and USB-HOST become attached.

What is the ABI explanation for USB and USB-HOST cable states?

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] usb: ehci-msm: Don't ioremap configuration space exclusively

[Alan Stern]

On Thu, 9 Apr 2015, Ivan T. Ivanov wrote:

 This allow same IO space to be shared between HCD and Device
 controller driver. Which can be loaded simultaneously and
 started/stopped on demand by USB OTG PHY driver.

You really should CC the person who wrote the code you are changing.  
This is almost exactly the same as reverting commit 70843f623b58 (usb: 
host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap).

Vivek, what do you think?

Alan Stern

 Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
 ---
  drivers/usb/host/ehci-msm.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
 index 9db74ca..f059e15 100644
 --- a/drivers/usb/host/ehci-msm.c
 +++ b/drivers/usb/host/ehci-msm.c
 @@ -88,13 +88,17 @@ static int ehci_msm_probe(struct platform_device *pdev)
   }
 
   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 - hcd-regs = devm_ioremap_resource(pdev-dev, res);
 + if (!res)
 + return -ENODEV;
 +
 + hcd-rsrc_start = res-start;
 + hcd-rsrc_len = resource_size(res);
 +
 + hcd-regs = devm_ioremap(pdev-dev, hcd-rsrc_start, hcd-rsrc_len);
   if (IS_ERR(hcd-regs)) {
   ret = PTR_ERR(hcd-regs);
   goto put_hcd;
   }
 - hcd-rsrc_start = res-start;
 - hcd-rsrc_len = resource_size(res);
 
   /*
* OTG driver takes care of PHY initialization, clock management,
 --
 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 v3 2/4] extcon: usb-gpio: add support for VBUS detection

[Chanwoo Choi]

Hi Robert,

On 04/09/2015 04:57 PM, Robert Baldyga wrote:
 Hi Chanwoo,
 
 On 04/09/2015 04:12 AM, Chanwoo Choi wrote:
 Hi Robert,


[snip]

 But, I have one question about case[3]

 If id is low and vbus is high, this patch will update the state of both USB 
 and USB-HOST cable as attached state.
 Is it possible that two different cables (both USB and USB-HOST) are 
 connected to one port simultaneously?

 
 It's because state of single USB cable connection cannot be completely
 described using single extcon cable. USB cable state has two bits (VBUS
 and ID), so we need to use two cables for single cable connection. We
 use following convention:
 cable USB = VBUS
 cable USB-HOST = !ID.

I think that extcon provider driver have to update the only one cable state
of either USB or USB-HOST because USB and USB-HOST feature can not be used
at the same time through one h/w port.

If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable
at the same time, the extcon consumer driver can not decide what handle either 
USB or USB-HOST.

 In fact it would be better to have cables named USB-VBUS and USB-ID
 - in this convention it would be more clear.

Thanks,
Chanwoo Choi

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

Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection

[Robert Baldyga]

Hi Chanwoo,

On 04/09/2015 11:07 AM, Chanwoo Choi wrote:
 Hi Robert,
 
 On 04/09/2015 04:57 PM, Robert Baldyga wrote:
 Hi Chanwoo,

 On 04/09/2015 04:12 AM, Chanwoo Choi wrote:
 Hi Robert,

 
 [snip]
 
 But, I have one question about case[3]

 If id is low and vbus is high, this patch will update the state of both USB 
 and USB-HOST cable as attached state.
 Is it possible that two different cables (both USB and USB-HOST) are 
 connected to one port simultaneously?


 It's because state of single USB cable connection cannot be completely
 described using single extcon cable. USB cable state has two bits (VBUS
 and ID), so we need to use two cables for single cable connection. We
 use following convention:
 cable USB = VBUS
 cable USB-HOST = !ID.
 
 I think that extcon provider driver have to update the only one cable state
 of either USB or USB-HOST because USB and USB-HOST feature can not be used
 at the same time through one h/w port.
 
 If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable
 at the same time, the extcon consumer driver can not decide what handle 
 either USB or USB-HOST.
 

It can. USB OTG allows for that. Moreover device can be host even if
ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so
detected cable type is USB host). Devices would need to have complete
information about USB cable connection, because OTG state machine needs
that. As I wrote, current USB cable names are misleading. It would be
better to have USB-VBUS and USB-ID.

 In fact it would be better to have cables named USB-VBUS and USB-ID
 - in this convention it would be more clear.

Thanks,
Robert Baldyga

--
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: phy: msm: Use extcon framework for VBUS and ID detection

[Ivan T. Ivanov]

On recent Qualcomm platforms VBUS and ID lines are not routed to
USB PHY LINK controller. Use extcon framework to receive connect
and disconnect ID and VBUS notification.

Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
 .../devicetree/bindings/usb/msm-hsusb.txt  |  7 ++
 drivers/usb/phy/Kconfig|  1 +
 drivers/usb/phy/phy-msm-usb.c  | 84 ++
 include/linux/usb/msm_hsusb.h  | 17 +
 4 files changed, 109 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 2826f2a..f26bcfa 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -69,6 +69,13 @@ Optional properties:
 (no, min, max) where each value represents either a voltage
 in microvolts or a value corresponding to voltage corner.

+- extcon:   phandles to external connector devices. First phandle
+should point to external connector, which provide USB
+cable events, the second should point to external connector
+device, which provide USB-HOST cable events. If one of
+the external connector devices is not required empty 0
+phandle should be specified.
+
 Example HSUSB OTG controller device node:

 usb@f9a55000 {
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 52d3d58..ca584ef 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -141,6 +141,7 @@ config USB_MSM_OTG
tristate Qualcomm on-chip USB OTG controller support
depends on (USB || USB_GADGET)  (ARCH_MSM || ARCH_QCOM || 
COMPILE_TEST)
depends on RESET_CONTROLLER
+   depends on EXTCON
select USB_PHY
help
  Enable this to support the USB OTG transceiver on Qualcomm chips. It
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 000fd89..d47c3eb 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1445,9 +1445,42 @@ static const struct of_device_id msm_otg_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, msm_otg_dt_match);

+static int msm_otg_vbus_notifier(struct notifier_block *nb, unsigned long 
event,
+   void *ptr)
+{
+   struct msm_usb_cable *vbus = container_of(nb, struct msm_usb_cable, nb);
+   struct msm_otg *motg = container_of(vbus, struct msm_otg, vbus);
+
+   if (event)
+   set_bit(B_SESS_VLD, motg-inputs);
+   else
+   clear_bit(B_SESS_VLD, motg-inputs);
+
+   schedule_work(motg-sm_work);
+
+   return NOTIFY_DONE;
+}
+
+static int msm_otg_id_notifier(struct notifier_block *nb, unsigned long event,
+   void *ptr)
+{
+   struct msm_usb_cable *id = container_of(nb, struct msm_usb_cable, nb);
+   struct msm_otg *motg = container_of(id, struct msm_otg, id);
+
+   if (event)
+   clear_bit(ID, motg-inputs);
+   else
+   set_bit(ID, motg-inputs);
+
+   schedule_work(motg-sm_work);
+
+   return NOTIFY_DONE;
+}
+
 static int msm_otg_read_dt(struct platform_device *pdev, struct msm_otg *motg)
 {
struct msm_otg_platform_data *pdata;
+   struct extcon_dev *ext_id, *ext_vbus;
const struct of_device_id *id;
struct device_node *node = pdev-dev.of_node;
struct property *prop;
@@ -1496,6 +1529,52 @@ static int msm_otg_read_dt(struct platform_device *pdev, 
struct msm_otg *motg)
motg-vdd_levels[VDD_LEVEL_MAX] = tmp[VDD_LEVEL_MAX];
}

+   ext_id = ERR_PTR(-ENODEV);
+   ext_vbus = ERR_PTR(-ENODEV);
+   if (of_property_read_bool(node, extcon)) {
+
+   /* Each one of them is not mandatory */
+   ext_vbus = extcon_get_edev_by_phandle(pdev-dev, 0);
+   if (IS_ERR(ext_vbus)  PTR_ERR(ext_vbus) != -ENODEV)
+   return PTR_ERR(ext_vbus);
+
+   ext_id = extcon_get_edev_by_phandle(pdev-dev, 1);
+   if (IS_ERR(ext_id)  PTR_ERR(ext_id) != -ENODEV)
+   return PTR_ERR(ext_id);
+   }
+
+   if (!IS_ERR(ext_vbus)) {
+   motg-vbus.nb.notifier_call = msm_otg_vbus_notifier;
+   ret = extcon_register_interest(motg-vbus.conn, ext_vbus-name,
+  USB, motg-vbus.nb);
+   if (ret  0) {
+   dev_err(pdev-dev, register VBUS notifier failed\n);
+   return ret;
+   }
+
+   ret = extcon_get_cable_state(ext_vbus, USB);
+   if (ret)
+   set_bit(B_SESS_VLD, motg-inputs);
+   else
+   clear_bit(B_SESS_VLD, motg-inputs);
+   }
+
+   if (!IS_ERR(ext_id)) {
+   motg-id.nb.notifier_call = 

[PATCH] usb: ehci-msm: Don't ioremap configuration space exclusively

[Ivan T. Ivanov]

This allow same IO space to be shared between HCD and Device
controller driver. Which can be loaded simultaneously and
started/stopped on demand by USB OTG PHY driver.

Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
 drivers/usb/host/ehci-msm.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 9db74ca..f059e15 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -88,13 +88,17 @@ static int ehci_msm_probe(struct platform_device *pdev)
}

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   hcd-regs = devm_ioremap_resource(pdev-dev, res);
+   if (!res)
+   return -ENODEV;
+
+   hcd-rsrc_start = res-start;
+   hcd-rsrc_len = resource_size(res);
+
+   hcd-regs = devm_ioremap(pdev-dev, hcd-rsrc_start, hcd-rsrc_len);
if (IS_ERR(hcd-regs)) {
ret = PTR_ERR(hcd-regs);
goto put_hcd;
}
-   hcd-rsrc_start = res-start;
-   hcd-rsrc_len = resource_size(res);

/*
 * OTG driver takes care of PHY initialization, clock management,
--
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 1/5] fs: configfs: Fix typo in comment

[Krzysztof Opasiak]

On 04/09/2015 03:46 PM, Felipe Balbi wrote:

On Wed, Apr 08, 2015 at 01:28:44PM +0200, Krzysztof Opasiak wrote:

Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
  fs/configfs/dir.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index cf0db00..dee1cb5 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -325,7 +325,7 @@ static void configfs_dir_set_ready(struct configfs_dirent 
*sd)
   * attached and not validated yet.
   * @sdconfigfs_dirent of the directory to check
   *
- * @return non-zero iff the directory was validated
+ * @return non-zero if the directory was validated


iff is not a typo, it's short-hand for if, and only if



I've already dropped this patch in v2, but thank you for your remark.

Best regards,

--
Krzysztof Opasiak
Samsung RD 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: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()

[Johan Hovold]

On Thu, Apr 09, 2015 at 02:25:08PM -0400, Alan Stern wrote:
 On Thu, 9 Apr 2015, Johan Hovold wrote:

  In my setup, adding a really short udelay (e.g. 100 us) rather than the
  printk is also enough to trigger the lock up when using just two bulk-in
  urbs.
  
  I thought it was the hub-driver work queue that was starved, but in my
  current setup I don't even get a completion callback for the external
  hub port-status change.
 
 Is that the hub driver's interrupt URB?  Or do you mean a control URB 
 requesting the port status?

The hub driver's interrupt URB.

  Same issue with two HS hubs of the same type.
  
  Switching to a different hub appears to make the problem go away. But so
  does using the same hub with a different HC (ehci-omap). So can't rule
  out musb (and dwc2 on RPi?).
  
  I'll try to find some more time to look into this later.
  
  Alan, what are your thoughts on this? 
  
  My setup is
  
  Beaglebone Black musb - HS hub - FS device
 
 It's awfully hard to pin down the cause of a problem when changing 
 either of two components makes the problem go away.
 
 In this case, I'd start with a bus analyzer.  Does the URB in question 
 get transmitted?  Does the hub send back a reply?  This will at least 
 help pin down whether the problem starts in the host controller or in 
 the hub.

I don't have one available at the moment, but I'll try that later.

 I still find it odd that the problem occurs only when the _last_ device
 is unplugged from the hub.

I just tested with a second device connected and that does not seem to
change the behaviour in my setup.

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

dvb-t usb stick terratec problem

[baumber]

Hello,

I have the same bug, mentioned in the bugreport, but with a USB TV-Stick DVB-T 
Terratec Cinergy DT XS Diversity.

https://bugzilla.kernel.org/show_bug.cgi?id=92301

This problem was not in kernel 3.16.x , I use Ubuntu 14.04.x 64bit.

Thank you for your help!

Best regards, Bernhard



Apr  9 18:01:03 stargazer kernel: [   70.017022] usb 3-2.4.1: new high-speed 
USB device number 4 using xhci_hcd
Apr  9 18:01:03 stargazer kernel: [   70.107491] usb 3-2.4.1: New USB device 
found, idVendor=0ccd, idProduct=005a
Apr  9 18:01:03 stargazer kernel: [   70.107494] usb 3-2.4.1: New USB device 
strings: Mfr=1, Product=2, SerialNumber=3
Apr  9 18:01:03 stargazer kernel: [   70.107495] usb 3-2.4.1: Product: Cinergy 
DT XS
Apr  9 18:01:03 stargazer kernel: [   70.107497] usb 3-2.4.1: Manufacturer: 
TerraTec
Apr  9 18:01:03 stargazer kernel: [   70.107498] usb 3-2.4.1: SerialNumber: 
07020100
Apr  9 18:01:03 stargazer mtp-probe: checking bus 3, device 4: 
/sys/devices/pci:00/:00:1c.0/:06:00.0/:07:09.0/:0b:00.0/usb3/3-2/3-2.4/3-2.4.1
Apr  9 18:01:03 stargazer mtp-probe: bus: 3, device: 4 was not an MTP device
Apr  9 18:01:03 stargazer kernel: [   70.139371] dvb-usb: found a 'Terratec 
Cinergy DT XS Diversity' in cold state, will try to load a firmware
Apr  9 18:01:03 stargazer kernel: [   70.139617] dvb-usb: downloading firmware 
from file 'dvb-usb-dib0700-1.20.fw'
Apr  9 18:01:03 stargazer kernel: [   70.543833] dib0700: firmware started 
successfully.
Apr  9 18:01:04 stargazer kernel: [   71.047012] dvb-usb: found a 'Terratec 
Cinergy DT XS Diversity' in warm state.
Apr  9 18:01:04 stargazer kernel: [   71.047309] dvb-usb: will pass the 
complete MPEG2 transport stream to the software demuxer.
Apr  9 18:01:04 stargazer kernel: [   71.047746] DVB: registering new adapter 
(Terratec Cinergy DT XS Diversity)
Apr  9 18:01:04 stargazer kernel: [   71.057441] BUG: unable to handle kernel 
NULL pointer dereference at 0080
Apr  9 18:01:04 stargazer kernel: [   71.057450] IP: [c0ded141] 
dib7000p_attach+0x11/0xa0 [dib7000p]
Apr  9 18:01:04 stargazer kernel: [   71.057457] PGD cd4be067 PUD cd4e4067 PMD 0
Apr  9 18:01:04 stargazer kernel: [   71.057463] Oops: 0002 [#1] SMP
Apr  9 18:01:04 stargazer kernel: [   71.057466] Modules linked in: dib7000p 
dvb_usb_dib0700(+) dib7000m dib0090 dib0070 dib3000mc dibx000_common dvb_usb 
dvb_core rc_core dm_crypt nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter 
ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack 
iptable_filter ip_tables x_tables snd_hda_codec_hdmi snd_usb_audio joydev 
snd_usbmidi_lib gpio_ich mxm_wmi hid_logitech_hidpp snd_hda_codec_via 
snd_hda_codec_generic nvidia(POE) snd_hda_intel kvm_intel snd_hda_controller 
snd_hda_codec kvm snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi 
serio_raw i7core_edac edac_core snd_seq snd_seq_device snd_timer snd drm 
soundcore lpc_ich shpchp rfcomm bnep bluetooth wmi mac_hid binfmt_misc 
parport_pc ppdev coretemp lp parport pata_acpi hid_logitech_dj hid_generic 
usbhid hid psmouse firewire_ohci firewire_core r8169 ahci crc_itu_t 
pata_jmicron mii libahci
Apr  9 18:01:04 stargazer kernel: [   71.057531] CPU: 2 PID: 3496 Comm: 
systemd-udevd Tainted: P   OE  3.19.0-12-generic #12~14.04.1-Ubuntu
Apr  9 18:01:04 stargazer kernel: [   71.057533] Hardware name: System 
manufacturer System Product Name/P7P55D-E PRO, BIOS 170306/26/2012
Apr  9 18:01:04 stargazer kernel: [   71.057535] task: 880036275850 ti: 
8800cd548000 task.ti: 8800cd548000
Apr  9 18:01:04 stargazer kernel: [   71.057537] RIP: 0010:[c0ded141]  
[c0ded141] dib7000p_attach+0x11/0xa0 [dib7000p]
Apr  9 18:01:04 stargazer kernel: [   71.057541] RSP: 0018:8800cd54ba68  
EFLAGS: 00010202
Apr  9 18:01:04 stargazer kernel: [   71.057543] RAX: 0010 RBX: 
8803e0aed278 RCX: 0001
Apr  9 18:01:04 stargazer kernel: [   71.057545] RDX: 0001 RSI: 
c0df4758 RDI: 0010
Apr  9 18:01:04 stargazer kernel: [   71.057546] RBP: 8800cd54ba68 R08: 
810f1470 R09: 88041fc57140
Apr  9 18:01:04 stargazer kernel: [   71.057548] R10: ea000f66a680 R11: 
81088634 R12: 
Apr  9 18:01:04 stargazer kernel: [   71.057549] R13: 0010 R14: 
8803e0aed278 R15: 8803e0aed398
Apr  9 18:01:04 stargazer kernel: [   71.057552] FS:  7f688ee9d880() 
GS:88041fc4() knlGS:
Apr  9 18:01:04 stargazer kernel: [   71.057554] CS:  0010 DS:  ES:  
CR0: 8005003b
Apr  9 18:01:04 stargazer kernel: [   71.057555] CR2: 0080 CR3: 
cd4e7000 CR4: 07e0
Apr  9 18:01:04 stargazer kernel: [   71.057557] Stack:
Apr  9 18:01:04 stargazer kernel: [   71.057558]  8800cd54ba98 
c0e6105b 8803e0aed398 8803e0aed278
Apr  9 18:01:04 stargazer kernel: [   71.057561]  8803e0aed278 
 

Re: [PATCH] usb: renesas_usbhs: Revise the binding document about the dma-names

[Geert Uytterhoeven]

On Wed, Apr 8, 2015 at 12:42 PM, Yoshihiro Shimoda
yoshihiro.shimoda...@renesas.com wrote:
 Since the DT should describe the hardware (not the driver limitation),
 This patch revises the binding document about the dma-names to change
 simple numbering as ch%d instead of txn and rxn.

 Also this patch fixes the actual code of renesas_usbhs driver to handle
 the new dma-names.

 Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com

Acked-by: Geert Uytterhoeven geert+rene...@glider.be

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/4] fs: configfs: Add unlocked version of configfs_depend_item()

[Krzysztof Opasiak]

Sometimes it might be desirable to prohibit removing a directory
in configfs. One example is USB gadget (mass_storage function):
when gadget is already bound, if lun directory is removed,
the gadget must be thrown away, too. A better solution would be
to fail with e.g. -EBUSY.

Currently configfs has configfs_depend/undepend_item() methods
but they cannot be used in configfs callbacks. This commit
adds unlocked version of this methods which can be used
only in configfs callbacks.

Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
 fs/configfs/dir.c|   29 +
 include/linux/configfs.h |9 +
 2 files changed, 38 insertions(+)

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index cf0db00..7875a5e 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1152,6 +1152,35 @@ void configfs_undepend_item(struct configfs_subsystem 
*subsys,
 }
 EXPORT_SYMBOL(configfs_undepend_item);
 
+int configfs_depend_item_unlocked(struct config_item *target)
+{
+   struct configfs_dirent *sd;
+   int ret = -ENOENT;
+
+   spin_lock(configfs_dirent_lock);
+   BUG_ON(!target-ci_dentry);
+
+   sd = target-ci_dentry-d_fsdata;
+   if ((sd-s_type  CONFIGFS_DIR) 
+   ((sd-s_type  CONFIGFS_USET_DROPPING) ||
+(sd-s_type  CONFIGFS_USET_CREATING)))
+   goto out_unlock_dirent_lock;
+
+   sd-s_dependent_count += 1;
+   ret = 0;
+
+out_unlock_dirent_lock:
+   spin_unlock(configfs_dirent_lock);
+   return ret;
+}
+EXPORT_SYMBOL(configfs_depend_item_unlocked);
+
+void configfs_undepend_item_unlocked(struct config_item *target)
+{
+   configfs_undepend_item(NULL, target);
+}
+EXPORT_SYMBOL(configfs_undepend_item_unlocked);
+
 static int configfs_mkdir(struct inode *dir, struct dentry *dentry, umode_t 
mode)
 {
int ret = 0;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 34025df..e9dbf01 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -257,4 +257,13 @@ void configfs_unregister_subsystem(struct 
configfs_subsystem *subsys);
 int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item 
*target);
 void configfs_undepend_item(struct configfs_subsystem *subsys, struct 
config_item *target);
 
+/*
+ * These functions can sleep and can alloc with GFP_KERNEL
+ * NOTE: These should be called only underneath configfs callbacks.
+ * WARNING: These cannot be called on newly created item
+ *(in make_group()/make_item callback)
+ */
+int configfs_depend_item_unlocked(struct config_item *target);
+void configfs_undepend_item_unlocked(struct config_item *target);
+
 #endif /* _CONFIGFS_H_ */
-- 
1.7.9.5

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

[PATCH v3 2/4] usb: gadget: mass_storage: Store lun_opts in fsg_opts

[Krzysztof Opasiak]

Currently lun_opts are stored only in configfs and
accessed using container_of() on config group. This
means that in configfs callbacks we can easily access
only current lun (config_group).

This commit adds an additinal array to fsg_opts which
allows to access not only current lun but also all other
luns using their id.

Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
 drivers/usb/gadget/function/f_mass_storage.c |5 +
 drivers/usb/gadget/function/f_mass_storage.h |1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 811929c..67a67b5 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3372,6 +3372,8 @@ static struct config_group *fsg_lun_make(struct 
config_group *group,
}
opts-lun = fsg_opts-common-luns[num];
opts-lun_id = num;
+   WARN_ON(fsg_opts-lun_opts[num]);
+   fsg_opts-lun_opts[num] = opts;
mutex_unlock(fsg_opts-lock);
 
config_group_init_type_name(opts-group, name, fsg_lun_type);
@@ -3400,6 +3402,7 @@ static void fsg_lun_drop(struct config_group *group, 
struct config_item *item)
 
fsg_common_remove_lun(lun_opts-lun, fsg_opts-common-sysfs);
fsg_opts-common-luns[lun_opts-lun_id] = NULL;
+   fsg_opts-lun_opts[lun_opts-lun_id] = NULL;
lun_opts-lun_id = 0;
mutex_unlock(fsg_opts-lock);
 
@@ -3546,6 +3549,7 @@ static struct usb_function_instance *fsg_alloc_inst(void)
if (!opts)
return ERR_PTR(-ENOMEM);
mutex_init(opts-lock);
+   memset(opts-lun_opts, 0, sizeof(opts-lun_opts));
opts-func_inst.free_func_inst = fsg_free_inst;
opts-common = fsg_common_setup(opts-common);
if (IS_ERR(opts-common)) {
@@ -3569,6 +3573,7 @@ static struct usb_function_instance *fsg_alloc_inst(void)
(const char **)opts-func_inst.group.cg_item.ci_name);
opts-lun0.lun = opts-common-luns[0];
opts-lun0.lun_id = 0;
+   opts-lun_opts[0] = opts-lun0;
config_group_init_type_name(opts-lun0.group, lun.0, fsg_lun_type);
opts-default_groups[0] = opts-lun0.group;
opts-func_inst.group.default_groups = opts-default_groups;
diff --git a/drivers/usb/gadget/function/f_mass_storage.h 
b/drivers/usb/gadget/function/f_mass_storage.h
index b4866fc..0a7c656 100644
--- a/drivers/usb/gadget/function/f_mass_storage.h
+++ b/drivers/usb/gadget/function/f_mass_storage.h
@@ -81,6 +81,7 @@ struct fsg_opts {
struct fsg_common *common;
struct usb_function_instance func_inst;
struct fsg_lun_opts lun0;
+   struct fsg_lun_opts *lun_opts[FSG_MAX_LUNS];
struct config_group *default_groups[2];
bool no_configfs; /* for legacy gadgets */
 
-- 
1.7.9.5

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

[PATCH v3 0/4] Ensure that lun ids are contiguous

[Krzysztof Opasiak]

Dear list,

This series fix configfs interface for mass storage function.
According to mass storage specification[1]:

Logical Unit Numbers on the device shall be numbered contiguously
 starting from LUN 0 to a maximum LUN of 15 (Fh).

Currently configfs interface allows to create LUNs with
arbitrary ids what causes problems with some host side
mass storage drivers.

This patch extends configfs interface with unlocked version
of configfs_depend_item() which should be used only in configfs
callbacks. This allows to protect from
removing lun directory from the middle of id space.

Example:

as is:
$ mkdir mass_storage.name
$ mkdir lun.3
$ mkdir lun.5
$ rmdir lun.3

After this series:
$ mkdir mass_storage.name
$ mkdir lun.3
mkdir: cannot create directory 'lun.3': Invalid argument
$ mkdir lun.1
$ mkdir lun.2
$ rmdir lun.1
rmdir: failed to remove 'lun.1': Device or resource busy
$ rmdir lun.2
$ rmdir lun.1

Footnotes:
1 - http://www.usb.org/developers/docs/devclass_docs/usbmassbulk_10.pdf

--
Best regards,
Krzysztof Opasiak
Samsung RD Institute Poland
Samsung Electronics

---
Changes since v1:
- drop incorrect typo fix
   (iff is not a typo but shorten version of if and only if)

Changes since v2:
- replace BUG_ON() with WARN_ON()
- s/arabic numeral/deciaml value
- add more verbose commit messages
- fix some typos
- move out label in more suitable place

Krzysztof Opasiak (4):
  fs: configfs: Add unlocked version of configfs_depend_item()
  usb: gadget: mass_storage: Store lun_opts in fsg_opts
  usb: gadget: mass_storage: Ensure that lun ids are contiguous
  Documentation: ABI: Fix documentation for mass_storage function

 .../ABI/testing/configfs-usb-gadget-mass-storage   |7 +++-
 drivers/usb/gadget/function/f_mass_storage.c   |   34 +---
 drivers/usb/gadget/function/f_mass_storage.h   |1 +
 fs/configfs/dir.c  |   29 +
 include/linux/configfs.h   |9 ++
 5 files changed, 75 insertions(+), 5 deletions(-)

-- 
1.7.9.5

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

[PATCH v3 4/4] Documentation: ABI: Fix documentation for mass_storage function

[Krzysztof Opasiak]

Luns in mass storage function are identified using their id.
While creating lun's directory user cannot choose any arbitrary
name other than decimal value from 1 to FSG_MAX_LUNS.

Moreover, LUNs ids should be contiguous. This means that user
may remove only lun with max id and can create new lun
only if its id equals to max id + 1.

Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
 .../ABI/testing/configfs-usb-gadget-mass-storage   |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage 
b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
index 9931fb0..2bf085d 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
+++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
@@ -11,10 +11,15 @@ Description:
are 2..4. Available only if
CONFIG_USB_GADGET_DEBUG_FILES is set.
 
-What:  /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
+What:  /config/usb-gadget/gadget/functions/mass_storage.name/lun.id
 Date:  Oct 2013
 KernelVersion: 3.13
 Description:
+   id - decimal value from 1 to FSG_MAX_LUNS
+   (which is 8 by default) - 1. LUNs should be numbered 
contiguously.
+   lun.0 is reserved for default lun which appears while creating
+   mass_storage.name directory and cannot be removed by the user.
+
The attributes:
 
file- The path to the backing file for the LUN.
-- 
1.7.9.5

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

[PATCH v3 3/4] usb: gadget: mass_storage: Ensure that lun ids are contiguous

[Krzysztof Opasiak]

According to mass storage specification:

Logical Unit Numbers on the device shall be numbered
 contiguously starting from LUN 0 to a maximum LUN of 15 (Fh).

This commit fix configfs interface adding this restriction.
Now user can create luns only with contignous ids and
cannot remove lun from the middle of id space.

Example:

as is:
$ mkdir mass_storage.name
$ mkdir lun.3
$ mkdir lun.5
$ rmdir lun.3

After this commit:
$ mkdir mass_storage.name
$ mkdir lun.3
mkdir: cannot create directory 'lun.3': Invalid argument
$ mkdir lun.1
$ mkdir lun.2
$ rmdir lun.1
rmdir: failed to remove 'lun.1': Device or resource busy
$ rmdir lun.2
$ rmdir lun.1

Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
 drivers/usb/gadget/function/f_mass_storage.c |   29 ++
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 67a67b5..f4b2de4 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3355,6 +3355,12 @@ static struct config_group *fsg_lun_make(struct 
config_group *group,
goto out;
}
 
+   if (!fsg_opts-common-luns[num - 1]) {
+   ret = -EINVAL;
+   pr_err(LUN ids should be contiguous\n);
+   goto out;
+   }
+
opts = kzalloc(sizeof(*opts), GFP_KERNEL);
if (!opts) {
ret = -ENOMEM;
@@ -3364,12 +3370,17 @@ static struct config_group *fsg_lun_make(struct 
config_group *group,
memset(config, 0, sizeof(config));
config.removable = true;
 
+   /* ensure that lun ids are contiguous */
+   ret = configfs_depend_item_unlocked((fsg_opts-lun_opts
+ [num - 1]-group.cg_item));
+   if (ret)
+   goto err_free_opts;
+
ret = fsg_common_create_lun(fsg_opts-common, config, num, name,
(const char **)group-cg_item.ci_name);
-   if (ret) {
-   kfree(opts);
-   goto out;
-   }
+   if (ret)
+   goto err_undepend_item;
+
opts-lun = fsg_opts-common-luns[num];
opts-lun_id = num;
WARN_ON(fsg_opts-lun_opts[num]);
@@ -3379,6 +3390,12 @@ static struct config_group *fsg_lun_make(struct 
config_group *group,
config_group_init_type_name(opts-group, name, fsg_lun_type);
 
return opts-group;
+
+err_undepend_item:
+   configfs_undepend_item_unlocked((fsg_opts-lun_opts
+ [num - 1]-group.cg_item));
+err_free_opts:
+   kfree(opts);
 out:
mutex_unlock(fsg_opts-lock);
return ERR_PTR(ret);
@@ -3400,6 +3417,10 @@ static void fsg_lun_drop(struct config_group *group, 
struct config_item *item)
unregister_gadget_item(gadget);
}
 
+   /* Allow to remove next one */
+   configfs_undepend_item_unlocked((fsg_opts-lun_opts
+ [lun_opts-lun_id - 
1]-group.cg_item));
+
fsg_common_remove_lun(lun_opts-lun, fsg_opts-common-sysfs);
fsg_opts-common-luns[lun_opts-lun_id] = NULL;
fsg_opts-lun_opts[lun_opts-lun_id] = NULL;
-- 
1.7.9.5

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

Re: [PATCH 1/2] usb: Prefer firmware values when determining whether a port is removable

[Greg KH]

On Wed, Apr 08, 2015 at 04:36:00PM -0700, Matthew Garrett wrote:
 Windows appears to pay more attention to the ACPI values than any hub
 configuration, so prefer the firmware's opinion on whether a port is
 fixed or removable before falling back to the hub values.
 
 Signed-off-by: Matthew Garrett mj...@coreos.com
 ---
  drivers/usb/core/hub.c | 32 +---
  1 file changed, 17 insertions(+), 15 deletions(-)

I like your trust in firmware :)

Anyway, is this all a Windows 8 requirement?  If so, I'll feel
comfortable making these changes, otherwise we are at the mercy of the
bios people to randomly get things right, and we all know how often that
works...

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: Question: drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback()

[Alan Stern]

On Thu, 9 Apr 2015, Johan Hovold wrote:

 On Wed, Apr 08, 2015 at 05:29:16PM +, Mark Enstone wrote:
  Everyone, thank you for your attention and suggestions.
  
  Johan, perfect, thank you, that did indeed help and has fixed the
  issue I was seeing.
  
  The change replaced dev_err() with dev_dbg() -- thus not logging (by
  default) what was a very noisy flood of messages. Does that simply
  change timing enough such that the USB HCD has time to process the
  disconnect? Or is there something else going on that I'm missing?
 
 I'm afraid it's only working around the real issue, though.
 
 In my setup, adding a really short udelay (e.g. 100 us) rather than the
 printk is also enough to trigger the lock up when using just two bulk-in
 urbs.
 
 I thought it was the hub-driver work queue that was starved, but in my
 current setup I don't even get a completion callback for the external
 hub port-status change.

Is that the hub driver's interrupt URB?  Or do you mean a control URB 
requesting the port status?

 Same issue with two HS hubs of the same type.
 
 Switching to a different hub appears to make the problem go away. But so
 does using the same hub with a different HC (ehci-omap). So can't rule
 out musb (and dwc2 on RPi?).
 
 I'll try to find some more time to look into this later.
 
 Alan, what are your thoughts on this? 
 
 My setup is
   
   Beaglebone Black musb - HS hub - FS device

It's awfully hard to pin down the cause of a problem when changing 
either of two components makes the problem go away.

In this case, I'd start with a bus analyzer.  Does the URB in question 
get transmitted?  Does the hub send back a reply?  This will at least 
help pin down whether the problem starts in the host controller or in 
the hub.

I still find it odd that the problem occurs only when the _last_ device
is unplugged from the hub.

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: Unable to access USB mass storage device with xhci. okay with ehci

[Steve Bangert]

On Thu, 2015-04-09 at 11:07 -0400, Alan Stern wrote:
 On Thu, 9 Apr 2015, Hans de Goede wrote:
 
   uas.c was patched (see attached), the quirk line was temporarily removed
  
  Thanks for testing this.
  
   and i now have access to the drive using xhci and uas. usbmon trace is
   attached.
  
  What exactly do you mean with i now have access to the drive using xhci 
  and uas ?
  Do you mean that everything works correctly with xhci + uas when setting
  .max_sectors = 240 ?
 
 Yes, that's what Steve meant.  Without the .max_sectors = 240 
 restriction, the device froze up when the kernel tried to perform a 
 transfer that was too large (around 190 KB).
 
  Alan, any ideas on how to move forward with this, I do not want to limit all
  uas devices to .max_sectors = 240, I can whip up a patch to set max_sectors 
  = 240
  on the ASM1053 but not the ASM1153.
 
 Some sort of quirk definitely seems like the right thing to do.  Given 
 the peculiarities of this device family, the quirk probably has to be 
 implemented in code (as opposed to a static table à la 
 unusual_devs.h).

 Still, I can imagine the uas-detect.h code setting the
 US_FL_MAX_SECTORS_64 flags bit and then the uas driver calling
 blk_queue_max_hw_sectors() the way we do in
 scsiglue.c:slave_configure().

Alan, would this approach create/implement dynamic max sector values
that might optimize speed/performance of the drive(s) transfer speeds?

The reason i ask is that the performance of the drive seems slow and
there were intermittent hangs during transfers based on my limited use
of the drive so far. Steve

 
 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 4/4] Documentation: ABI: Fix documentation for mass_storage function

[Tal Shorer]

On Wed, Apr 8, 2015 at 3:06 PM, Krzysztof Opasiak k.opas...@samsung.com wrote:
 Luns in mass storage function are identified using their id.
 While creating lun's directory user cannot choose any arbitrary
 name other than arabic numeral from 1 to FSG_MAX_LUNS.

 Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
 ---
  .../ABI/testing/configfs-usb-gadget-mass-storage   |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

 diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage 
 b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
 index 9931fb0..0b54280 100644
 --- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
 +++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
 @@ -11,10 +11,15 @@ Description:
 are 2..4. Available only if
 CONFIG_USB_GADGET_DEBUG_FILES is set.

 -What:  /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
 +What:  /config/usb-gadget/gadget/functions/mass_storage.name/lun.id
  Date:  Oct 2013
  KernelVersion: 3.13
  Description:
 +   id - arabic numeral from 1 to FSG_MAX_LUNS
I think decimal number or decimal value would be easier to understand.
 +   (which is 8 by default) - 1. LUNs should be numbered 
 contiguously.
 +   lun.0 is reserved for default lun which appears while creating
 +   mass_storage.name directory and cannot be removed by the user.
 +
 The attributes:

 file- The path to the backing file for the LUN.
 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/5] usb: xhci: cleanup xhci_hcd allocation

[Roger Quadros]

Hi,

On 07/04/15 17:23, Mathias Nyman wrote:
 Hi
 
 On 02.04.2015 15:23, Roger Quadros wrote:
 HCD core allocates memory for HCD private data in
 usb_create_[shared_]hcd() so make use of that
 mechanism to allocate the struct xhci_hcd.

 Introduce struct xhci_driver_overrides to provide
 the size of HCD private data and hc_driver operation
 overrides. As of now we only need to override the
 reset and start methods.

 Signed-off-by: Roger Quadros rog...@ti.com
 
 I'm not sure I fully understand the what's going on, or what the
 intention of this patch is.

The main intention is to have both primary and shared HCDs allocated
before calling usb_add_hcd() for the primary hcd.
This is so that at the first usb_add_hcd() the OTG core knows the HCD topology
(i.e. whether it uses a shared HCD or not).

From the OTG perspective we have to prevent the actual usb_add_hcd() till the
OTG state machine says so.
This means that xhci_gen_setup() won't be necessarily called immediately and
so we need to allocate for xhci somewhere else.

 
 So currently xhci driver manages the allocation and freeing of
 the xhci_hcd structure. We store a pointer to the xhci_hcd structure in
 the content of both the primary and shared usb_hcds structures hcd_priv
 field.
 
 With this patch xhci would be part of the usb_hcd structure,
 starting at hcd_priv[0]. (Like EHCI I think) It allocates enough space to 
 include
 the xhci_hcd in both the primary and shared usb_hcd, but always only use the 
 one
 in the primary hcd.

precisely.

 I'm not sure what to do with the space allocated for the shared hcd's
 hcd_priv field.

we just ignore the space allocated for the shared hcd.

 
 This also means that xhci goes away together with the primary hcd. It's 
 possible
 this has some impact as the xhci driver expects xhci to always exists.

Can you please point out where this impact is.

I've been testing add/remove HCD extensively and didn't observe any issues 
after applying
these 5 patches. Well there is one issue that comes up but it has nothing to do 
with xhci
not being allocated. It has more to do with command being queued after the HCD 
has gone away
and so getting stuck forever without timing out.

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: Unable to access USB mass storage device with xhci. okay with ehci

[Alan Stern]

On Thu, 9 Apr 2015, Steve Bangert wrote:

  Still, I can imagine the uas-detect.h code setting the
  US_FL_MAX_SECTORS_64 flags bit and then the uas driver calling
  blk_queue_max_hw_sectors() the way we do in
  scsiglue.c:slave_configure().
 
 Alan, would this approach create/implement dynamic max sector values
 that might optimize speed/performance of the drive(s) transfer speeds?

There already _is_ dynamic max_sector support in the kernel.  Look at

/sys/block/sdX/queue/max_sectors_kb

(where X is the drive letter for your disk).  I don't know how much
additional performance you'll get out of it, but you can experiment
with a few values.  The disk drive probably will fail with any value
much larger than 128, though -- try it and see.

The problem is that you can't set this value before the disk is 
plugged in, and afterward it's already too late.  That's why the 
initial value has to be set up by the driver.

 The reason i ask is that the performance of the drive seems slow and
 there were intermittent hangs during transfers based on my limited use
 of the drive so far. Steve

Does this happen with both the uas and usb-storage drivers or only with 
one of them?

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: Unable to access USB mass storage device with xhci. okay with ehci

[Alan Stern]

On Thu, 9 Apr 2015, Hans de Goede wrote:

  uas.c was patched (see attached), the quirk line was temporarily removed
 
 Thanks for testing this.
 
  and i now have access to the drive using xhci and uas. usbmon trace is
  attached.
 
 What exactly do you mean with i now have access to the drive using xhci and 
 uas ?
 Do you mean that everything works correctly with xhci + uas when setting
 .max_sectors = 240 ?

Yes, that's what Steve meant.  Without the .max_sectors = 240 
restriction, the device froze up when the kernel tried to perform a 
transfer that was too large (around 190 KB).

 Alan, any ideas on how to move forward with this, I do not want to limit all
 uas devices to .max_sectors = 240, I can whip up a patch to set max_sectors = 
 240
 on the ASM1053 but not the ASM1153.

Some sort of quirk definitely seems like the right thing to do.  Given 
the peculiarities of this device family, the quirk probably has to be 
implemented in code (as opposed to a static table à la 
unusual_devs.h).

Still, I can imagine the uas-detect.h code setting the
US_FL_MAX_SECTORS_64 flags bit and then the uas driver calling
blk_queue_max_hw_sectors() the way we do in
scsiglue.c:slave_configure().

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: [GIT PULL] USB resume timeout rework for v4.1

[Grégory Herrero]

Hi Felipe,

Following patch: usb: dwc2: hcd: use new USB_RESUME_TIMEOUT is not correct.
The delay is currently done before the controller drives the resume timeout.
Attached patch fix this issue.

2015-04-07 22:49 GMT+00:00 Felipe Balbi ba...@ti.com:
 Hi Greg,

 As promised, here's a pull request with only the resume timeout
 patches. I've rebased and retested them with my available platforms.

 Let me know if you want anything to be changed.

 cheers

 The following changes since commit 3e457371f436e89ce9239674828f9729a36b2595:

   usb: musb: Fix fifo reads for dm816x with musb_dsps (2015-03-24 11:36:38 
 -0500)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
 tags/usb-for-v4.1-part2

 for you to fetch changes up to bbc78c07a51f6fd29c227b1220a9016e585358ba:

   usb: core: hub: use new USB_RESUME_TIMEOUT (2015-04-07 12:58:36 -0500)

 
 usb: generic resume timeout for v4.1

 This part 2 pull request contains only the patches
 which make sure everybody on linux uses the same
 resume timeout value.

 Signed-off-by: Felipe Balbi ba...@ti.com

 
 Felipe Balbi (14):
   usb: define a generic USB_RESUME_TIMEOUT macro
   usb: host: xhci: use new USB_RESUME_TIMEOUT
   usb: host: ehci: use new USB_RESUME_TIMEOUT
   usb: host: uhci: use new USB_RESUME_TIMEOUT
   usb: musb: use new USB_RESUME_TIMEOUT
   usb: host: isp116x: use new USB_RESUME_TIMEOUT
   usb: host: fotg210: use new USB_RESUME_TIMEOUT
   usb: host: fusbh200: use new USB_RESUME_TIMEOUT
   usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
   usb: host: r8a66597: use new USB_RESUME_TIMEOUT
   usb: host: sl811: use new USB_RESUME_TIMEOUT
   usb: dwc2: hcd: use new USB_RESUME_TIMEOUT
   usb: isp1760: hcd: use new USB_RESUME_TIMEOUT
   usb: core: hub: use new USB_RESUME_TIMEOUT

  drivers/usb/core/hub.c|  4 ++--
  drivers/usb/dwc2/hcd.c|  2 +-
  drivers/usb/host/ehci-hcd.c   | 10 +-
  drivers/usb/host/ehci-hub.c   |  9 ++---
  drivers/usb/host/fotg210-hcd.c|  2 +-
  drivers/usb/host/fusbh200-hcd.c   |  3 +--
  drivers/usb/host/isp116x-hcd.c|  2 +-
  drivers/usb/host/oxu210hp-hcd.c   |  7 ---
  drivers/usb/host/r8a66597-hcd.c   |  2 +-
  drivers/usb/host/sl811-hcd.c  |  2 +-
  drivers/usb/host/uhci-hub.c   |  5 +++--
  drivers/usb/host/xhci-ring.c  |  2 +-
  drivers/usb/isp1760/isp1760-hcd.c |  2 +-
  drivers/usb/musb/musb_core.c  |  7 ---
  drivers/usb/musb/musb_virthub.c   |  2 +-
  include/linux/usb.h   | 26 ++
  16 files changed, 59 insertions(+), 28 deletions(-)
 --
 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
From d4996890e535d0582cc845bbeaa75ad4de693d92 Mon Sep 17 00:00:00 2001
From: Gregory Herrero gregory.herr...@intel.com
Date: Fri, 3 Apr 2015 10:53:25 +0200
Subject: [PATCH] usb: dwc2: host: sleep USB_RESUME_TIMEOUT during resume

msleep(USB_RESUME_TIMEOUT) must be done when the controller drives
the resume. This is true after HPRT0_RES is written.
Moreover, restore the delay after controller power is up.

Signed-off-by: Gregory Herrero gregory.herr...@intel.com
---
 drivers/usb/dwc2/hcd.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index fdf40a0..4b6f4ab 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1534,13 +1534,13 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
 			dev_dbg(hsotg-dev,
 ClearPortFeature USB_PORT_FEAT_SUSPEND\n);
 			writel(0, hsotg-regs + PCGCTL);
-			msleep(USB_RESUME_TIMEOUT);
+			usleep_range(2, 4);
 
 			hprt0 = dwc2_read_hprt0(hsotg);
 			hprt0 |= HPRT0_RES;
 			writel(hprt0, hsotg-regs + HPRT0);
 			hprt0 = ~HPRT0_SUSP;
-			usleep_range(10, 15);
+			msleep(USB_RESUME_TIMEOUT);
 
 			hprt0 = ~HPRT0_RES;
 			writel(hprt0, hsotg-regs + HPRT0);
-- 
1.7.10.4

Re: [GIT PULL] USB resume timeout rework for v4.1

[Felipe Balbi]

On Thu, Apr 09, 2015 at 10:17:08AM +, Grégory Herrero wrote:
 Hi Felipe,
 
 Following patch: usb: dwc2: hcd: use new USB_RESUME_TIMEOUT is not correct.
 The delay is currently done before the controller drives the resume timeout.
 Attached patch fix this issue.
 
 2015-04-07 22:49 GMT+00:00 Felipe Balbi ba...@ti.com:
  Hi Greg,
 
  As promised, here's a pull request with only the resume timeout
  patches. I've rebased and retested them with my available platforms.
 
  Let me know if you want anything to be changed.
 
  cheers
 
  The following changes since commit 3e457371f436e89ce9239674828f9729a36b2595:
 
usb: musb: Fix fifo reads for dm816x with musb_dsps (2015-03-24 11:36:38 
  -0500)
 
  are available in the git repository at:
 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
  tags/usb-for-v4.1-part2
 
  for you to fetch changes up to bbc78c07a51f6fd29c227b1220a9016e585358ba:
 
usb: core: hub: use new USB_RESUME_TIMEOUT (2015-04-07 12:58:36 -0500)
 
  
  usb: generic resume timeout for v4.1
 
  This part 2 pull request contains only the patches
  which make sure everybody on linux uses the same
  resume timeout value.
 
  Signed-off-by: Felipe Balbi ba...@ti.com
 
  
  Felipe Balbi (14):
usb: define a generic USB_RESUME_TIMEOUT macro
usb: host: xhci: use new USB_RESUME_TIMEOUT
usb: host: ehci: use new USB_RESUME_TIMEOUT
usb: host: uhci: use new USB_RESUME_TIMEOUT
usb: musb: use new USB_RESUME_TIMEOUT
usb: host: isp116x: use new USB_RESUME_TIMEOUT
usb: host: fotg210: use new USB_RESUME_TIMEOUT
usb: host: fusbh200: use new USB_RESUME_TIMEOUT
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
usb: host: r8a66597: use new USB_RESUME_TIMEOUT
usb: host: sl811: use new USB_RESUME_TIMEOUT
usb: dwc2: hcd: use new USB_RESUME_TIMEOUT
usb: isp1760: hcd: use new USB_RESUME_TIMEOUT
usb: core: hub: use new USB_RESUME_TIMEOUT
 
   drivers/usb/core/hub.c|  4 ++--
   drivers/usb/dwc2/hcd.c|  2 +-
   drivers/usb/host/ehci-hcd.c   | 10 +-
   drivers/usb/host/ehci-hub.c   |  9 ++---
   drivers/usb/host/fotg210-hcd.c|  2 +-
   drivers/usb/host/fusbh200-hcd.c   |  3 +--
   drivers/usb/host/isp116x-hcd.c|  2 +-
   drivers/usb/host/oxu210hp-hcd.c   |  7 ---
   drivers/usb/host/r8a66597-hcd.c   |  2 +-
   drivers/usb/host/sl811-hcd.c  |  2 +-
   drivers/usb/host/uhci-hub.c   |  5 +++--
   drivers/usb/host/xhci-ring.c  |  2 +-
   drivers/usb/isp1760/isp1760-hcd.c |  2 +-
   drivers/usb/musb/musb_core.c  |  7 ---
   drivers/usb/musb/musb_virthub.c   |  2 +-
   include/linux/usb.h   | 26 ++
   16 files changed, 59 insertions(+), 28 deletions(-)
  --
  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

 From d4996890e535d0582cc845bbeaa75ad4de693d92 Mon Sep 17 00:00:00 2001
 From: Gregory Herrero gregory.herr...@intel.com
 Date: Fri, 3 Apr 2015 10:53:25 +0200
 Subject: [PATCH] usb: dwc2: host: sleep USB_RESUME_TIMEOUT during resume
 
 msleep(USB_RESUME_TIMEOUT) must be done when the controller drives
 the resume. This is true after HPRT0_RES is written.
 Moreover, restore the delay after controller power is up.
 
 Signed-off-by: Gregory Herrero gregory.herr...@intel.com
 ---
  drivers/usb/dwc2/hcd.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
 index fdf40a0..4b6f4ab 100644
 --- a/drivers/usb/dwc2/hcd.c
 +++ b/drivers/usb/dwc2/hcd.c
 @@ -1534,13 +1534,13 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg 
 *hsotg, u16 typereq,
   dev_dbg(hsotg-dev,
   ClearPortFeature USB_PORT_FEAT_SUSPEND\n);
   writel(0, hsotg-regs + PCGCTL);
 - msleep(USB_RESUME_TIMEOUT);
 + usleep_range(2, 4);
  
   hprt0 = dwc2_read_hprt0(hsotg);
   hprt0 |= HPRT0_RES;
   writel(hprt0, hsotg-regs + HPRT0);
   hprt0 = ~HPRT0_SUSP;
 - usleep_range(10, 15);
 + msleep(USB_RESUME_TIMEOUT);
  
   hprt0 = ~HPRT0_RES;
   writel(hprt0, hsotg-regs + HPRT0);

Greg, I can fold this into original patch, but then I guess it becomes
too late to get this into this merge window. Your call, should I resend
a pull request, or will you take this extra hunk as a separate patch ?

-- 
balbi


signature.asc
Description: Digital signature