Re: [PATCH 2/2] arm: shmobile: lager: enable HS-USB

[Yoshihiro Shimoda]

Hello.

(2014/10/07 12:25), Yoshihiro Shimoda wrote:
> Hello.
> 
> (2014/10/06 9:59), Yoshihiro Shimoda wrote:
>> Hello.
>>
>> (2014/10/04 4:50), Sergei Shtylyov wrote:
>>> On 10/02/2014 12:04 PM, Yoshihiro Shimoda wrote:
>>>
< snip >
 +&hsusb {
 +  status = "okay";
 +  renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_LOW>;
>>>
>>> It's certainly active-high.
>>
>> Since the current code has the following, we have to set the active_low...
>> However, the code is unreadable, I think. So, I will modify the code.
>>
>>  /* check GPIO determining if USB function should be enabled */
>>  if (priv->dparam.enable_gpio) {
>>  gpio_request_one(priv->dparam.enable_gpio, GPIOF_IN, NULL);
>>  ret = !gpio_get_value(priv->dparam.enable_gpio);
>>  gpio_free(priv->dparam.enable_gpio);
>>  if (ret) {
>>  dev_warn(&pdev->dev,
>>   "USB function not selected (GPIO %d)\n",
>>   priv->dparam.enable_gpio);
>>  ret = -ENOTSUPP;
>>  goto probe_end_mod_exit;
>>  }
>>  }
> 
> I am confusing about the gpio_get_value()...
> In case of ARM, gpio_get_value() will call gpiod_get_raw_value() finally.
> 
> gpio_get_value() in arch/arm/include/asm/gpio.h
>  --> __gpio_get_value() in include/asm-generic/gpio.h
>   --> gpiod_get_raw_value() in drivers/gpio/gpiolib.c
> 
> The gpiod_get_raw_value() doesn't care of the GPIO_ACTIVE_{HIGH,LOW}.
> So, should I add gpiod_is_active_low() or someting in the renesas_usbhs 
> driver?
> Or, Do I misunderstand something?

I looked at the gpio-keys driver, and then I understand the renesas_usbhs 
driver should
have the gpio flags from of_get_named_gpio_flags().

So, I will try to modify the renesas_usbhs driver.

Best regards,
Yoshihiro Shimoda

> Best regards,
> Yoshihiro Shimoda
> 
>> Best regards,
>> Yoshihiro Shimoda
>>
>>> WBR, Sergei
>>>
--
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 v2] usb: gadget: f_fs: add "zombie" mode

[Robert Baldyga]

Since we can compose gadgets from many functions, there is the problem
related to gadget breakage while FunctionFS daemon being closed. In some
cases it's strongly desired to keep gadget alive for a while, despite
FunctionFS files are closed, to allow another functions to complete
some presumably critical operations.

For this purpose this patch introduces "zombie" mode. It can be enabled
by setting mount option "zombie=1", and results with defering function
closure to the moment of reopening ep0 file or filesystem umount.

When ffs->state == FFS_ZOMBIE:
- function is still binded and visible to host,
- setup requests are automatically stalled,
- all another transfers are refused,
- epfiles, excepting ep0, are deleted from filesystem,
- opening ep0 causes function close, and then FunctionFS is ready for
  descriptors and string write,
- umount of functionfs cause function close.

Signed-off-by: Robert Baldyga 
---

Changelog:

v2:
- delete epfiles, excepting ep0, when FFS is in "zombie" mode,
- add description of FFS_ZOMBIE state,
- minor cleanups.

v1: https://lkml.org/lkml/2014/10/6/128

 drivers/usb/gadget/function/f_fs.c | 38 ++
 drivers/usb/gadget/function/u_fs.h | 22 ++
 2 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 7c6771d..b368b0a 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -162,6 +162,7 @@ struct ffs_desc_helper {
 };
 
 static int  __must_check ffs_epfiles_create(struct ffs_data *ffs);
+static void ffs_epfiles_delete(struct ffs_epfile *epfiles, unsigned count);
 static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count);
 
 static struct dentry *
@@ -606,6 +607,8 @@ static unsigned int ffs_ep0_poll(struct file *file, 
poll_table *wait)
}
case FFS_CLOSING:
break;
+   case FFS_ZOMBIE:
+   break;
}
 
mutex_unlock(&ffs->mutex);
@@ -1152,6 +1155,7 @@ struct ffs_sb_fill_data {
struct ffs_file_perms perms;
umode_t root_mode;
const char *dev_name;
+   bool zombie_mode;
struct ffs_data *ffs_data;
 };
 
@@ -1222,6 +1226,12 @@ static int ffs_fs_parse_opts(struct ffs_sb_fill_data 
*data, char *opts)
 
/* Interpret option */
switch (eq - opts) {
+   case 6:
+   if (!memcmp(opts, "zombie", 6))
+   data->zombie_mode = !!value;
+   else
+   goto invalid;
+   break;
case 5:
if (!memcmp(opts, "rmode", 5))
data->root_mode  = (value & 0555) | S_IFDIR;
@@ -1286,6 +1296,7 @@ ffs_fs_mount(struct file_system_type *t, int flags,
.gid = GLOBAL_ROOT_GID,
},
.root_mode = S_IFDIR | 0500,
+   .zombie_mode = false,
};
struct dentry *rv;
int ret;
@@ -1302,6 +1313,7 @@ ffs_fs_mount(struct file_system_type *t, int flags,
if (unlikely(!ffs))
return ERR_PTR(-ENOMEM);
ffs->file_perms = data.perms;
+   ffs->zombie_mode = data.zombie_mode;
 
ffs->dev_name = kstrdup(dev_name, GFP_KERNEL);
if (unlikely(!ffs->dev_name)) {
@@ -1389,7 +1401,9 @@ static void ffs_data_opened(struct ffs_data *ffs)
ENTER();
 
atomic_inc(&ffs->ref);
-   atomic_inc(&ffs->opened);
+   if (atomic_add_return(1, &ffs->opened) == 1)
+   if (ffs->state == FFS_ZOMBIE)
+   ffs_data_reset(ffs);
 }
 
 static void ffs_data_put(struct ffs_data *ffs)
@@ -1411,8 +1425,17 @@ static void ffs_data_closed(struct ffs_data *ffs)
ENTER();
 
if (atomic_dec_and_test(&ffs->opened)) {
-   ffs->state = FFS_CLOSING;
-   ffs_data_reset(ffs);
+   if (ffs->zombie_mode) {
+   ffs->state = FFS_ZOMBIE;
+   if (ffs->epfiles)
+   ffs_epfiles_delete(ffs->epfiles,
+  ffs->eps_count);
+   if (ffs->setup_state == FFS_SETUP_PENDING)
+   __ffs_ep0_stall(ffs);
+   } else {
+   ffs->state = FFS_CLOSING;
+   ffs_data_reset(ffs);
+   }
}
 
ffs_data_put(ffs);
@@ -1569,7 +1592,7 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
return 0;
 }
 
-static void ffs_epfiles_destroy(struct ffs_epfile *epfiles, unsigned count)
+static void ffs_epfiles_delete(struct ffs_epfile *epfiles, unsigned count)
 {
struct ffs_epfile *epfile = epfiles;
 
@@ -1584,6 +1607,13 @@ static void ffs_epfiles_destroy(struct ffs_epfile 
*epfiles, unsigned count)
  

[PATCH v3] usb: Remove references to non-existent PLAT_S5P symbol

[Sylwester Nawrocki]

The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
("ARM: SAMSUNG: Remove remaining legacy code"). There are still
some references left, fix that by replacing them with ARCH_S5PV210.

Fixes: d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
Reported-by: Paul Bolle 
Acked-by: Jingoo Han 
Cc: [3.17+]
Signed-off-by: Sylwester Nawrocki 
---
Changes since v2:
 - updated the commit description.

 drivers/usb/host/Kconfig |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 82800a7..6f1d48e 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -220,7 +220,7 @@ config USB_EHCI_SH

 config USB_EHCI_EXYNOS
tristate "EHCI support for Samsung S5P/EXYNOS SoC Series"
-   depends on PLAT_S5P || ARCH_EXYNOS
+   depends on ARCH_S5PV210 || ARCH_EXYNOS
help
Enable support for the Samsung Exynos SOC's on-chip EHCI controller.

@@ -527,7 +527,7 @@ config USB_OHCI_SH

 config USB_OHCI_EXYNOS
tristate "OHCI support for Samsung S5P/EXYNOS SoC Series"
-   depends on PLAT_S5P || ARCH_EXYNOS
+   depends on ARCH_S5PV210 || ARCH_EXYNOS
help
 Enable support for the Samsung Exynos SOC's on-chip OHCI controller.

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

[RFC v4] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

[Kiran Kumar Raparthy]

From: Todd Poynor 

usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

Purpose of this is to prevent the system to enter into suspend state from USB
peripheral traffic by hodling a wakeupsource when USB is connected and
enumerated in peripheral mode(say adb).

Temporarily hold a timed wakeup source on USB disconnect events, to allow
the rest of the system to react to the USB disconnection (dropping host
sessions, updating charger status, etc.) prior to re-allowing suspend.

Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Android Kernel Team 
Cc: John Stultz 
Cc: Sumit Semwal 
Cc: Arve Hj�nnev�g 
Cc: Benoit Goby 
Signed-off-by: Todd Poynor 
[kiran: Added context to commit message, squished build fixes
from Benoit Goby and Arve Hj�nnev�g, changed wakelocks usage
to wakeupsource, merged Todd's refactoring logic and simplified
the structures and code and addressed community feedback]
Signed-off-by: Kiran Raparthy 
---
v4:
* Temporarily hold wakeupsource patch integrated into main patch.
* As per feedback,dropped "enabled" module parameter.
* Introduced otgws_otg_usb3_notifications function to handle event
  notifications from usb3 phy.
* Handled wakeupsource initialization,spinlock,registration of notifier block
  per-PHY.
* Updated usb_phy structure.

v3:
* As per the feedback,no global phy pointer used.
* called the one-liner wakeupsource handling calls
  directly instead of indirect functions implemented in v2.
* Removed indirect function get_phy_hook and used usb_get_phy
  to get the phy handle..

v2:
* wakeupsource handling implemeted per-PHY
* Implemented wakeupsource handling calls in phy
* included Todd's refactoring logic.

v1:
* changed to "disabled by default" from "enable by default".
* Kconfig help text modified
* Included better commit text
* otgws_nb moved to otg_wakeupsource_init function
* Introduced get_phy_hook to handle otgws_xceiv per-PHY

RFC:
* Included build fix from Benoit Goby and Arve Hj�nnev�g
* Removed lock->held field in driver as this mechanism is
  provided in wakeupsource driver.
* wakelock(wl) terminology replaced with wakeup_source(ws).

 drivers/usb/phy/Kconfig|   8 +++
 drivers/usb/phy/Makefile   |   1 +
 drivers/usb/phy/otg-wakeupsource.c | 134 +
 include/linux/usb/phy.h|   8 +++
 4 files changed, 151 insertions(+)
 create mode 100644 drivers/usb/phy/otg-wakeupsource.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e253fa0..d9ddd85 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -6,6 +6,14 @@ menu "USB Physical Layer drivers"
 config USB_PHY
def_bool n
 
+config USB_OTG_WAKEUPSOURCE
+   bool "Hold wakeupsource when USB is enumerated in peripheral mode"
+   depends on PM_SLEEP
+   select USB_PHY
+   help
+ Prevent the system going into automatic suspend while
+ it is attached as a USB peripheral by holding a wakeupsource.
+
 #
 # USB Transceiver Drivers
 #
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 24a9133..ca2fbaf 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -3,6 +3,7 @@
 #
 obj-$(CONFIG_USB_PHY)  += phy.o
 obj-$(CONFIG_OF)   += of.o
+obj-$(CONFIG_USB_OTG_WAKEUPSOURCE) += otg-wakeupsource.o
 
 # transceiver drivers, keep the list sorted
 
diff --git a/drivers/usb/phy/otg-wakeupsource.c 
b/drivers/usb/phy/otg-wakeupsource.c
new file mode 100644
index 000..00d3359
--- /dev/null
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -0,0 +1,134 @@
+/*
+ * otg-wakeupsource.c
+ *
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void otgws_handle_event(struct usb_phy *otgws_xceiv, unsigned long 
event)
+{
+   unsigned long irqflags;
+
+   spin_lock_irqsave(&otgws_xceiv->otgws_slock, irqflags);
+
+   switch (event) {
+   case USB_EVENT_VBUS:
+   case USB_EVENT_ENUMERATED:
+   __pm_stay_awake(&otgws_xceiv->wsource);
+   break;
+
+   case USB_EVENT_NONE:
+   case USB_EVENT_ID:
+   case USB_EVENT_CHARGER:
+   __pm_wakeup_event(&otgws_xceiv->wsource,
+   msecs_to_jiffies(TEMPORARY_HOLD_TIME));
+   break;
+
+   default:
+   break;
+   }
+
+   spin_unlock_irqrestore(&otgws_xceiv->otgws_slock

Re: [PATCH 1/6] mfd: viperboard: fix platform-device id collision

[Lee Jones]

On Fri, 26 Sep 2014, Johan Hovold wrote:

> Allow more than one viperboard to be connected by registering with
> PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.
> 
> The subdevices are currently registered with PLATFORM_DEVID_NONE, which
> will cause a name collision on the platform bus when a second viperboard
> is plugged in:

Applied to fixes.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] mfd: rtsx_usb: fix platform device-id collision

[Lee Jones]

On Fri, 26 Sep 2014, Johan Hovold wrote:

> Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
> avoid name collisions on the platform bus.
> 
> This driver currently uses the USB-device address as an id. This makes
> name collisions unlikely, but it could still happen if two devices are
> connected to separate buses and gets assigned the same address.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/mfd/rtsx_usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

This patch is superfluous.

Just wait until the hotpluggable version is applied, then use it.

> diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> index 71f387ce8cbd..78073e4b87e4 100644
> --- a/drivers/mfd/rtsx_usb.c
> +++ b/drivers/mfd/rtsx_usb.c
> @@ -647,7 +647,7 @@ static int rtsx_usb_probe(struct usb_interface *intf,
>   /* initialize USB SG transfer timer */
>   setup_timer(&ucr->sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
>  
> - ret = mfd_add_devices(&intf->dev, usb_dev->devnum, rtsx_usb_cells,
> + ret = mfd_add_devices(&intf->dev, PLATFORM_DEVID_AUTO, rtsx_usb_cells,
>   ARRAY_SIZE(rtsx_usb_cells), NULL, 0, NULL);
>   if (ret)
>   goto out_init_fail;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/6] mfd: core: add helper function to register hotplug devices

[Lee Jones]

On Fri, 26 Sep 2014, Johan Hovold wrote:

> Hot-pluggable multi-function devices should always be registered with
> PLATFORM_DEVID_AUTO to avoid name collisions on the platform bus. This
> helper also hides the memory map and irq parameters, which aren't used
> by hot-pluggable (e.g. USB-based) devices.
> 
> Signed-off-by: Johan Hovold 
> ---
>  include/linux/mfd/core.h | 7 +++
>  1 file changed, 7 insertions(+)

Applied for v3.19.

> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> index f543de91ce19..1e47262a1c63 100644
> --- a/include/linux/mfd/core.h
> +++ b/include/linux/mfd/core.h
> @@ -108,6 +108,13 @@ extern int mfd_add_devices(struct device *parent, int id,
>  struct resource *mem_base,
>  int irq_base, struct irq_domain *irq_domain);
>  
> +static inline int mfd_add_hotplug_devices(struct device *parent,
> + const struct mfd_cell *cells, int n_devs)
> +{
> + return mfd_add_devices(parent, PLATFORM_DEVID_AUTO, cells, n_devs,
> + NULL, 0, NULL);
> +}
> +
>  extern void mfd_remove_devices(struct device *parent);
>  
>  #endif

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/6] mfd: use mfd_add_hotplug_devices helper

[Lee Jones]

On Fri, 26 Sep 2014, Johan Hovold wrote:

> Use mfd_add_hotplug_devices helper to register the subdevices.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/mfd/rtsx_usb.c   | 4 ++--
>  drivers/mfd/viperboard.c | 5 ++---
>  2 files changed, 4 insertions(+), 5 deletions(-)

Applied for v3.19.

> diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> index 78073e4b87e4..5b17339fce7c 100644
> --- a/drivers/mfd/rtsx_usb.c
> +++ b/drivers/mfd/rtsx_usb.c
> @@ -647,8 +647,8 @@ static int rtsx_usb_probe(struct usb_interface *intf,
>   /* initialize USB SG transfer timer */
>   setup_timer(&ucr->sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
>  
> - ret = mfd_add_devices(&intf->dev, PLATFORM_DEVID_AUTO, rtsx_usb_cells,
> - ARRAY_SIZE(rtsx_usb_cells), NULL, 0, NULL);
> + ret = mfd_add_hotplug_devices(&intf->dev, rtsx_usb_cells,
> + ARRAY_SIZE(rtsx_usb_cells));
>   if (ret)
>   goto out_init_fail;
>  
> diff --git a/drivers/mfd/viperboard.c b/drivers/mfd/viperboard.c
> index 3c2b8f9e3c84..be450ebcb52d 100644
> --- a/drivers/mfd/viperboard.c
> +++ b/drivers/mfd/viperboard.c
> @@ -93,9 +93,8 @@ static int vprbrd_probe(struct usb_interface *interface,
>version >> 8, version & 0xff,
>vb->usb_dev->bus->busnum, vb->usb_dev->devnum);
>  
> - ret = mfd_add_devices(&interface->dev, PLATFORM_DEVID_AUTO,
> - vprbrd_devs, ARRAY_SIZE(vprbrd_devs), NULL, 0,
> - NULL);
> + ret = mfd_add_hotplug_devices(&interface->dev, vprbrd_devs,
> + ARRAY_SIZE(vprbrd_devs));
>   if (ret != 0) {
>   dev_err(&interface->dev, "Failed to add mfd devices to core.");
>   goto error;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 5/6] HID: hid-sensor-hub: use mfd_add_hotplug_devices helper

[Lee Jones]

On Fri, 26 Sep 2014, Johan Hovold wrote:

> Use mfd_add_hotplug_devices helper to register the subdevices.
> 
> Compile-only tested.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/hid/hid-sensor-hub.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)

Applied for v3.19 with Jiri's Ack.

> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index 2ac25760a9a9..fbe1a6d2aa53 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -641,9 +641,6 @@ static int sensor_hub_probe(struct hid_device *hdev,
>   goto err_stop_hw;
>   }
>   sd->hid_sensor_hub_client_devs[
> - sd->hid_sensor_client_cnt].id =
> - PLATFORM_DEVID_AUTO;
> - sd->hid_sensor_hub_client_devs[
>   sd->hid_sensor_client_cnt].name = name;
>   sd->hid_sensor_hub_client_devs[
>   sd->hid_sensor_client_cnt].platform_data =
> @@ -659,8 +656,9 @@ static int sensor_hub_probe(struct hid_device *hdev,
>   if (last_hsdev)
>   last_hsdev->end_collection_index = i;
>  
> - ret = mfd_add_devices(&hdev->dev, 0, sd->hid_sensor_hub_client_devs,
> - sd->hid_sensor_client_cnt, NULL, 0, NULL);
> + ret = mfd_add_hotplug_devices(&hdev->dev,
> + sd->hid_sensor_hub_client_devs,
> + sd->hid_sensor_client_cnt);
>   if (ret < 0)
>   goto err_stop_hw;
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 6/6] mfd: core: fix platform-device id generation

[Lee Jones]

On Fri, 26 Sep 2014, Johan Hovold wrote:

> Make sure to always honour multi-function devices registered with
> PLATFORM_DEVID_NONE (-1) or PLATFORM_DEVID_AUTO (-2) as id base. In this
> case it does not make sense to append the cell id to the mfd-id base and
> potentially change the requested behaviour.
> 
> Specifically this will allow multi-function devices to be registered
> with PLATFORM_DEVID_AUTO while still having non-zero cell ids.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/mfd/mfd-core.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Applied for v3.19.

> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 892d343193ad..79f25633d7db 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -87,9 +87,15 @@ static int mfd_add_device(struct device *parent, int id,
>   struct platform_device *pdev;
>   struct device_node *np = NULL;
>   int ret = -ENOMEM;
> + int platform_id;
>   int r;
>  
> - pdev = platform_device_alloc(cell->name, id + cell->id);
> + if (id < 0)
> + platform_id = id;
> + else
> + platform_id = id + cell->id;
> +
> + pdev = platform_device_alloc(cell->name, platform_id);
>   if (!pdev)
>   goto fail_alloc;
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] arm: shmobile: lager: enable HS-USB

[Sergei Shtylyov]

Hello.

On 10/7/2014 4:20 AM, Yoshihiro Shimoda wrote:


Signed-off-by: Yoshihiro Shimoda 
---
   arch/arm/boot/dts/r8a7790-lager.dts |5 +
   1 file changed, 5 insertions(+)



diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 1698591..4badd0a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -445,3 +445,8 @@
};
};
   };
+
+&hsusb {
+   status = "okay";
+   renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_LOW>;
+};



 Darn, this also misses the PinMux props... I was going to post v2 of these
patches but now would need to add that and retest... :-/



I'm sorry for the my delayed work... I will submit v2 patches today.



By the way, I cannot understand that "this also misses the PinMux props".
According to the original "legacy" code in board-lager.c, it uses gpio5 18:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36be7686caa05334ca8d52df157b373a41d8d9f1


   Right. But there are also USB0 pins.


Best regards,
Yoshihiro Shimoda


WBR, Sergei

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

Re: [PATCH 2/2] arm: shmobile: lager: enable HS-USB

[Sergei Shtylyov]

On 10/7/2014 7:25 AM, Yoshihiro Shimoda wrote:


Signed-off-by: Yoshihiro Shimoda 
---
   arch/arm/boot/dts/r8a7790-lager.dts |5 +
   1 file changed, 5 insertions(+)



diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 1698591..4badd0a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -445,3 +445,8 @@
};
};
   };
+
+&hsusb {
+   status = "okay";
+   renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_LOW>;



 It's certainly active-high.



Since the current code has the following, we have to set the active_low...
However, the code is unreadable, I think. So, I will modify the code.

/* check GPIO determining if USB function should be enabled */
if (priv->dparam.enable_gpio) {
gpio_request_one(priv->dparam.enable_gpio, GPIOF_IN, NULL);
ret = !gpio_get_value(priv->dparam.enable_gpio);
gpio_free(priv->dparam.enable_gpio);
if (ret) {
dev_warn(&pdev->dev,
 "USB function not selected (GPIO %d)\n",
 priv->dparam.enable_gpio);
ret = -ENOTSUPP;
goto probe_end_mod_exit;
}
}



I am confusing about the gpio_get_value()...
In case of ARM, gpio_get_value() will call gpiod_get_raw_value() finally.



gpio_get_value() in arch/arm/include/asm/gpio.h
  --> __gpio_get_value() in include/asm-generic/gpio.h
   --> gpiod_get_raw_value() in drivers/gpio/gpiolib.c



The gpiod_get_raw_value() doesn't care of the GPIO_ACTIVE_{HIGH,LOW}.
So, should I add gpiod_is_active_low() or someting in the renesas_usbhs driver?


   Why do you still think it's active-low?!


Or, Do I misunderstand something?


   Look at the above code again.


Best regards,
Yoshihiro Shimoda


WBR, Sergei

--
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: btusb_intr_complete returns -EPIPE

[Oliver Neukum]

On Tue, 2014-10-07 at 12:14 +0530, Naveen Kumar Parna wrote:
> > +   err = usb_clear_halt(data->udev,
> > +usb_rcvbulkpipe(data->udev,
> > +
> > data->intr_ep->bEndpointAddress));
> 
> EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe()
> instead of usb_rcvbulkpipe() right?

Yes. And I noticed a copy and past error.

> Does the “lsusb –v” gives any clue about the reason for getting -EPIPE?

No. Could you nevertheless test the attached version?

Regards
Oliver

>From b8109554277bde9da4275e7a9ce1ef76b43ebd59 Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Mon, 6 Oct 2014 15:27:54 +0200
Subject: [PATCH] btusb: clear halt if intr in stalls

Use a work queue for clearing a halt.

Signed-off-by: Oliver Neukum 
---
 drivers/bluetooth/btusb.c | 34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 292c38e..716c37a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -273,6 +273,7 @@ struct btusb_data {
 
 	struct work_struct work;
 	struct work_struct waker;
+	struct work_struct intr_in_work;
 
 	struct usb_anchor tx_anchor;
 	struct usb_anchor intr_anchor;
@@ -314,14 +315,15 @@ static void btusb_intr_complete(struct urb *urb)
 	struct hci_dev *hdev = urb->context;
 	struct btusb_data *data = hci_get_drvdata(hdev);
 	int err;
+	int status = urb->status;
 
 	BT_DBG("%s urb %p status %d count %d", hdev->name,
-	urb, urb->status, urb->actual_length);
+	urb, status, urb->actual_length);
 
 	if (!test_bit(HCI_RUNNING, &hdev->flags))
 		return;
 
-	if (urb->status == 0) {
+	if (status == 0) {
 		hdev->stat.byte_rx += urb->actual_length;
 
 		if (hci_recv_fragment(hdev, HCI_EVENT_PKT,
@@ -330,6 +332,10 @@ static void btusb_intr_complete(struct urb *urb)
 			BT_ERR("%s corrupted event packet", hdev->name);
 			hdev->stat.err_rx++;
 		}
+	} else if (status == -EPIPE) {
+		usb_mark_last_busy(data->udev);
+		schedule_work(&data->intr_in_work);
+		return;
 	}
 
 	if (!test_bit(BTUSB_INTR_RUNNING, &data->flags))
@@ -971,6 +977,29 @@ static void btusb_waker(struct work_struct *work)
 	usb_autopm_put_interface(data->intf);
 }
 
+static void clear_halt_intr_in(struct work_struct *work)
+{
+	struct btusb_data *data = container_of(work, struct btusb_data, intr_in_work);
+	int err;
+
+	err = usb_autopm_get_interface(data->intf);
+	if (err < 0)
+		return;
+
+	err = usb_clear_halt(data->udev,
+			 usb_rcvintpipe(data->udev,
+	 data->intr_ep->bEndpointAddress));
+	if (err < 0)
+		return;
+
+	if (!test_bit(BTUSB_INTR_RUNNING, &data->flags))
+		return;
+
+	btusb_submit_intr_urb(data->hdev, GFP_NOIO);
+
+	usb_autopm_put_interface(data->intf);
+}
+
 static int btusb_setup_bcm92035(struct hci_dev *hdev)
 {
 	struct sk_buff *skb;
@@ -1759,6 +1788,7 @@ static int btusb_probe(struct usb_interface *intf,
 
 	INIT_WORK(&data->work, btusb_work);
 	INIT_WORK(&data->waker, btusb_waker);
+	INIT_WORK(&data->intr_in_work, clear_halt_intr_in);
 	spin_lock_init(&data->txlock);
 
 	init_usb_anchor(&data->tx_anchor);
-- 
1.8.4.5

Re: [PATCH v3 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter

[Alexandre Courbot]

On Mon, Oct 6, 2014 at 11:47 PM, Muthu Mani  wrote:
> +
> +static int cy_gpio_direction_input(struct gpio_chip *chip,
> +   unsigned offset)
> +{
> +   return 0;
> +}
> +
> +static int cy_gpio_direction_output(struct gpio_chip *chip,
> +   unsigned offset, int value)
> +{
> +   return 0;
> +}

If that chip is capable of both output and input, shouldn't these
functions be implemented? I think this has already been pointed out in
a previous version but you did not reply.

> +
> +static int cyusbs23x_gpio_probe(struct platform_device *pdev)
> +{
> +   struct cyusbs23x *cyusbs;
> +   struct cyusbs_gpio *cy_gpio;
> +   int ret = 0;
> +
> +   dev_dbg(&pdev->dev, "%s\n", __func__);

> +
> +   cyusbs = dev_get_drvdata(pdev->dev.parent);
> +
> +   cy_gpio = devm_kzalloc(&pdev->dev, sizeof(*cy_gpio), GFP_KERNEL);
> +   if (cy_gpio == NULL)
> +   return -ENOMEM;
> +
> +   cy_gpio->cyusbs = cyusbs;
> +   /* registering gpio */
> +   cy_gpio->gpio.label = dev_name(&pdev->dev);
> +   cy_gpio->gpio.dev = &pdev->dev;
> +   cy_gpio->gpio.owner = THIS_MODULE;
> +   cy_gpio->gpio.base = -1;
> +   cy_gpio->gpio.ngpio = 12; /* total GPIOs */

Isn't there a way to get the number of GPIOs from a reliable source?
If not, please at least use a macro here.
--
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: gadget: f_fs: add "zombie" mode

[Michal Nazarewicz]

On Tue, Oct 07 2014, Robert Baldyga  wrote:
> @@ -1411,8 +1425,17 @@ static void ffs_data_closed(struct ffs_data *ffs)
>   ENTER();
>  
>   if (atomic_dec_and_test(&ffs->opened)) {
> - ffs->state = FFS_CLOSING;
> - ffs_data_reset(ffs);
> + if (ffs->zombie_mode) {
> + ffs->state = FFS_ZOMBIE;
> + if (ffs->epfiles)
> + ffs_epfiles_delete(ffs->epfiles,
> +ffs->eps_count);

This looks suspicious.  Why isn't it:

+   if (ffs->epfiles) {
+   ffs_epfiles_destroy(ffs->epfiles,
+  ffs->eps_count);
+   ffs->epfiles = NULL;
+   }

If ffs->epfiles is not NULLed, call to ffs_data_reset in ffs_data_open
will call ffs_epfiles_destroy which we don't want, do we?

> + if (ffs->setup_state == FFS_SETUP_PENDING)
> + __ffs_ep0_stall(ffs);
> + } else {
> + ffs->state = FFS_CLOSING;
> + ffs_data_reset(ffs);
> + }
>   }
>  
>   ffs_data_put(ffs);

> @@ -93,6 +93,26 @@ enum ffs_state {
>   FFS_ACTIVE,
>  
>   /*
> +  * Function is visible to host, but it's not functional. All
> +  * setup requests are stalled and another transfers are refused.

“and transfers on other endpoints are refused.”

> +  * All epfiles, excepting ep0, are deleted so there is no way

s/excepting/except/

> +  * to perform any operations on them.
> +  *
> +  * This state is set after closing all functionfs files, when
> +  * mount parameter "zombie=1" has been set. Function will remain
> +  * in zombie state until filesystem will be umounted or ep0 will

s/will be umounted/is unmounted/
s/ep0 will be/ep0 is/

> +  * be opened again. In the second case functionfs state will be
> +  * reseted, and it will be ready for descriptors and strings

s/reseted/reset/

> +  * writing.
> +  *
> +  * This is useful only when functionfs is composed to gadget
> +  * with another function which can perform some critical
> +  * operations, and it's strongly desired to have this operations
> +  * completed, even after functionfs files closure.
> +  */
> + FFS_ZOMBIE,
> +
> + /*
>* All endpoints have been closed.  This state is also set if
>* we encounter an unrecoverable error.  The only
>* unrecoverable error is situation when after reading strings

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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 v2 4/4] phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS

[Vivek Gautam]

This PHY controller is also present on Exynos7 platform
in arch-exynos family.
So PHY_EXYNOS5_USBDRD should now depend on ARCH_EXYNOS.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2a436e6..1514e40 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -193,7 +193,7 @@ config PHY_EXYNOS5250_USB2
 
 config PHY_EXYNOS5_USBDRD
tristate "Exynos5 SoC series USB DRD PHY driver"
-   depends on ARCH_EXYNOS5 && OF
+   depends on ARCH_EXYNOS && OF
depends on HAS_IOMEM
depends on USB_DWC3_EXYNOS
select GENERIC_PHY
-- 
1.7.10.4

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

[PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

[Vivek Gautam]

Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.

Signed-off-by: Vivek Gautam 
---
 drivers/usb/dwc3/dwc3-exynos.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 3951a65..7dc6a98 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device   *dev;
 
struct clk  *clk;
+   struct clk  *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
 };
@@ -139,10 +140,21 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   /*
+* Exynos7 has a special gate clock going to this IP,
+* which in earlier SoCs was probably concealed.
+*/
+   exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk");
+   if (IS_ERR(exynos->sclk)) {
+   dev_info(dev, "no sclk specified\n");
+   exynos->sclk = NULL;
+   }
+
exynos->dev = dev;
exynos->clk = clk;
 
clk_prepare_enable(exynos->clk);
+   clk_prepare_enable(exynos->sclk);
 
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
@@ -185,6 +197,7 @@ err4:
 err3:
regulator_disable(exynos->vdd33);
 err2:
+   clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(clk);
return ret;
 }
@@ -197,6 +210,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
 
+   clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(exynos->clk);
 
regulator_disable(exynos->vdd33);
@@ -218,6 +232,7 @@ static int dwc3_exynos_suspend(struct device *dev)
 {
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 
+   clk_disable(exynos->sclk);
clk_disable(exynos->clk);
 
regulator_disable(exynos->vdd33);
@@ -243,6 +258,7 @@ static int dwc3_exynos_resume(struct device *dev)
}
 
clk_enable(exynos->clk);
+   clk_enable(exynos->sclk);
 
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
-- 
1.7.10.4

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

[PATCH v2 0/4] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7

[Vivek Gautam]

Adding required support for clocks and additional VBUS regulators
to enable USB 3.0 support on Exynos7 SoC.

This series depends for ACRH_EXYNOS7 support on following series:
[PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html

The series is based on usb-next branch.

Changes since v1:
 -- Addressed review comments for unnecessary warning messages after
clk_get() fails for dwc3-exynos and phy-exynos5-usbdrd.
 -- Assigned "exynos->sclk" as well as "phy_drd->utmiclk" and
"phy_drd->pipeclk" to NULL in case of clk_get() failure to avoid
unnecessary check for clock.
 -- Modified dependency for symbol PHY_EXYNOS5_USBDRD to depend on
ARCH_EXYNOS which includes both Exynos5 as well as Exynos7.
 -- Dropped [PATCH 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
from v1 of this series, since its not required now.

Vivek Gautam (4):
  dwc3: exynos: Add support for SCLK present on Exynos7
  phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support
  phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
  phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS

 .../devicetree/bindings/phy/samsung-phy.txt|4 ++
 drivers/phy/Kconfig|2 +-
 drivers/phy/phy-exynos5-usbdrd.c   |   52 +++-
 drivers/usb/dwc3/dwc3-exynos.c |   16 ++
 4 files changed, 71 insertions(+), 3 deletions(-)

-- 
1.7.10.4

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

[PATCH v2 2/4] phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support

[Vivek Gautam]

Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
So get the same and control in the phy-exynos5-usbdrd driver.

Signed-off-by: Vivek Gautam 
---
 .../devicetree/bindings/phy/samsung-phy.txt|4 
 drivers/phy/phy-exynos5-usbdrd.c   |   22 
 2 files changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 15e0f2c..c2bc9dc 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -138,6 +138,10 @@ Required properties:
   PHY operations, associated by phy name. It is used to
   determine bit values for clock settings register.
   For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+   - optional clocks: Exynos7 SoC has now following additional
+  gate clocks available:
+  - phy_pipe: for PIPE3 phy
+  - phy_utmi: for UTMI+ phy
 - samsung,pmu-syscon: phandle for PMU system controller interface, used to
  control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 1;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index f756aca..013ee84 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -148,6 +148,8 @@ struct exynos5_usbdrd_phy_drvdata {
  * @dev: pointer to device instance of this platform device
  * @reg_phy: usb phy controller register memory base
  * @clk: phy clock for register access
+ * @pipeclk: clock for pipe3 phy
+ * @utmiclk: clock for utmi+ phy
  * @drv_data: pointer to SoC level driver data structure
  * @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
  * instances each with its 'phy' and 'phy_cfg'.
@@ -161,6 +163,8 @@ struct exynos5_usbdrd_phy {
struct device *dev;
void __iomem *reg_phy;
struct clk *clk;
+   struct clk *pipeclk;
+   struct clk *utmiclk;
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct phy_usb_instance {
struct phy *phy;
@@ -446,6 +450,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
dev_dbg(phy_drd->dev, "Request to power_on usbdrd_phy phy\n");
 
+   clk_prepare_enable(phy_drd->utmiclk);
+   clk_prepare_enable(phy_drd->pipeclk);
clk_prepare_enable(phy_drd->ref_clk);
 
/* Enable VBUS supply */
@@ -464,6 +470,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
 fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
+   clk_disable_unprepare(phy_drd->pipeclk);
+   clk_disable_unprepare(phy_drd->utmiclk);
 
return ret;
 }
@@ -483,6 +491,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
regulator_disable(phy_drd->vbus);
 
clk_disable_unprepare(phy_drd->ref_clk);
+   clk_disable_unprepare(phy_drd->pipeclk);
+   clk_disable_unprepare(phy_drd->utmiclk);
 
return 0;
 }
@@ -582,6 +592,18 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
return PTR_ERR(phy_drd->clk);
}
 
+   phy_drd->pipeclk = devm_clk_get(dev, "phy_pipe");
+   if (IS_ERR(phy_drd->pipeclk)) {
+   dev_info(dev, "PIPE3 phy operational clock not specified\n");
+   phy_drd->pipeclk = NULL;
+   }
+
+   phy_drd->utmiclk = devm_clk_get(dev, "phy_utmi");
+   if (IS_ERR(phy_drd->utmiclk)) {
+   dev_info(dev, "UTMI phy operational clock not specified\n");
+   phy_drd->utmiclk = NULL;
+   }
+
phy_drd->ref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(phy_drd->ref_clk)) {
dev_err(dev, "Failed to get reference clock of usbdrd phy\n");
-- 
1.7.10.4

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

[PATCH v2 3/4] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply

[Vivek Gautam]

Some Exynos SoCs have a separate regulator controlling a
Boost 5V supply which goes as input for VBUS regulator.
So adding a control for the same in driver, to enable
vbus supply on the port.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/phy-exynos5-usbdrd.c |   30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 013ee84..57e8a0a 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -176,6 +176,7 @@ struct exynos5_usbdrd_phy {
u32 extrefclk;
struct clk *ref_clk;
struct regulator *vbus;
+   struct regulator *vbus_boost;
 };
 
 static inline
@@ -455,11 +456,20 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd->ref_clk);
 
/* Enable VBUS supply */
+   if (phy_drd->vbus_boost) {
+   ret = regulator_enable(phy_drd->vbus_boost);
+   if (ret) {
+   dev_err(phy_drd->dev,
+   "Failed to enable VBUS boost supply\n");
+   goto fail_vbus;
+   }
+   }
+
if (phy_drd->vbus) {
ret = regulator_enable(phy_drd->vbus);
if (ret) {
dev_err(phy_drd->dev, "Failed to enable VBUS supply\n");
-   goto fail_vbus;
+   goto fail_vbus_boost;
}
}
 
@@ -468,6 +478,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
return 0;
 
+fail_vbus_boost:
+   if (phy_drd->vbus_boost)
+   regulator_disable(phy_drd->vbus_boost);
+
 fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
clk_disable_unprepare(phy_drd->pipeclk);
@@ -489,6 +503,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Disable VBUS supply */
if (phy_drd->vbus)
regulator_disable(phy_drd->vbus);
+   if (phy_drd->vbus_boost)
+   regulator_disable(phy_drd->vbus_boost);
 
clk_disable_unprepare(phy_drd->ref_clk);
clk_disable_unprepare(phy_drd->pipeclk);
@@ -644,7 +660,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
break;
}
 
-   /* Get Vbus regulator */
+   /* Get Vbus regulators */
phy_drd->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(phy_drd->vbus)) {
ret = PTR_ERR(phy_drd->vbus);
@@ -655,6 +671,16 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
phy_drd->vbus = NULL;
}
 
+   phy_drd->vbus_boost = devm_regulator_get(dev, "vbus-boost");
+   if (IS_ERR(phy_drd->vbus_boost)) {
+   ret = PTR_ERR(phy_drd->vbus_boost);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   dev_warn(dev, "Failed to get VBUS boost supply regulator\n");
+   phy_drd->vbus_boost = NULL;
+   }
+
dev_vdbg(dev, "Creating usbdrd_phy phy\n");
 
for (i = 0; i < EXYNOS5_DRDPHYS_NUM; i++) {
-- 
1.7.10.4

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

Re: [PATCH v2] usb: gadget: f_fs: add "zombie" mode

[Robert Baldyga]

On 10/07/2014 12:07 PM, Michal Nazarewicz wrote:
> On Tue, Oct 07 2014, Robert Baldyga  wrote:
>> @@ -1411,8 +1425,17 @@ static void ffs_data_closed(struct ffs_data *ffs)
>>  ENTER();
>>  
>>  if (atomic_dec_and_test(&ffs->opened)) {
>> -ffs->state = FFS_CLOSING;
>> -ffs_data_reset(ffs);
>> +if (ffs->zombie_mode) {
>> +ffs->state = FFS_ZOMBIE;
>> +if (ffs->epfiles)
>> +ffs_epfiles_delete(ffs->epfiles,
>> +   ffs->eps_count);
> 
> This looks suspicious.  Why isn't it:
> 
> + if (ffs->epfiles) {
> + ffs_epfiles_destroy(ffs->epfiles,
> +ffs->eps_count);
> + ffs->epfiles = NULL;
> + }
> 
> If ffs->epfiles is not NULLed, call to ffs_data_reset in ffs_data_open
> will call ffs_epfiles_destroy which we don't want, do we?
> 

We do. When epfile->dentry == NULL, ffs_epfiles_destroy() will do only
kfree(epfiles). We want to do it.

We don't want to have ffs->epfiles being equal NULL before calling
ffs_func_eps_disable(), which iterates on this table.

Hmm, we could also change ffs_func_eps_disable() to not touch
ffs->epfiles if it's NULL. It seems to be better solution.

>> +if (ffs->setup_state == FFS_SETUP_PENDING)
>> +__ffs_ep0_stall(ffs);
>> +} else {
>> +ffs->state = FFS_CLOSING;
>> +ffs_data_reset(ffs);
>> +}
>>  }
>>  
>>  ffs_data_put(ffs);
> 
>> @@ -93,6 +93,26 @@ enum ffs_state {
>>  FFS_ACTIVE,
>>  
>>  /*
>> + * Function is visible to host, but it's not functional. All
>> + * setup requests are stalled and another transfers are refused.
> 
> “and transfers on other endpoints are refused.”
> 
>> + * All epfiles, excepting ep0, are deleted so there is no way
> 
> s/excepting/except/
> 
>> + * to perform any operations on them.
>> + *
>> + * This state is set after closing all functionfs files, when
>> + * mount parameter "zombie=1" has been set. Function will remain
>> + * in zombie state until filesystem will be umounted or ep0 will
> 
> s/will be umounted/is unmounted/
> s/ep0 will be/ep0 is/
> 
>> + * be opened again. In the second case functionfs state will be
>> + * reseted, and it will be ready for descriptors and strings
> 
> s/reseted/reset/
> 
>> + * writing.
>> + *
>> + * This is useful only when functionfs is composed to gadget
>> + * with another function which can perform some critical
>> + * operations, and it's strongly desired to have this operations
>> + * completed, even after functionfs files closure.
>> + */
>> +FFS_ZOMBIE,
>> +
>> +/*
>>   * All endpoints have been closed.  This state is also set if
>>   * we encounter an unrecoverable error.  The only
>>   * unrecoverable error is situation when after reading strings
> 

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: [PATCH 2/2] arm: shmobile: lager: enable HS-USB

[Yoshihiro Shimoda]

Hello.

(2014/10/07 18:46), Sergei Shtylyov wrote:
> On 10/7/2014 7:25 AM, Yoshihiro Shimoda wrote:
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>arch/arm/boot/dts/r8a7790-lager.dts |5 +
>1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
> b/arch/arm/boot/dts/r8a7790-lager.dts
> index 1698591..4badd0a 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -445,3 +445,8 @@
>};
>};
>};
> +
> +&hsusb {
> +status = "okay";
> +renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_LOW>;
> 
  It's certainly active-high.
> 
>>> Since the current code has the following, we have to set the active_low...
>>> However, the code is unreadable, I think. So, I will modify the code.
>>>
>>> /* check GPIO determining if USB function should be enabled */
>>> if (priv->dparam.enable_gpio) {
>>> gpio_request_one(priv->dparam.enable_gpio, GPIOF_IN, NULL);
>>> ret = !gpio_get_value(priv->dparam.enable_gpio);
>>> gpio_free(priv->dparam.enable_gpio);
>>> if (ret) {
>>> dev_warn(&pdev->dev,
>>>  "USB function not selected (GPIO %d)\n",
>>>  priv->dparam.enable_gpio);
>>> ret = -ENOTSUPP;
>>> goto probe_end_mod_exit;
>>> }
>>> }
> 
>> I am confusing about the gpio_get_value()...
>> In case of ARM, gpio_get_value() will call gpiod_get_raw_value() finally.
> 
>> gpio_get_value() in arch/arm/include/asm/gpio.h
>>   --> __gpio_get_value() in include/asm-generic/gpio.h
>>--> gpiod_get_raw_value() in drivers/gpio/gpiolib.c
> 
>> The gpiod_get_raw_value() doesn't care of the GPIO_ACTIVE_{HIGH,LOW}.
>> So, should I add gpiod_is_active_low() or someting in the renesas_usbhs 
>> driver?
> 
>Why do you still think it's active-low?!
> 
>> Or, Do I misunderstand something?
> 
>Look at the above code again.

Thank you for the comment.
Finally, I understood this. I will not modify the driver and
I just change the "GPIO_ACTIVE_LOW" in the dts file to "GPIO_ACTIVE_HIGH"
because of your previous comment below:

>> 'ret' is non-zero here if gpio_get_value() returned 0, so 0 means "host"
>> and 1 means "gadget", i.e. GPIO is active-high.

Best regards,
Yoshihiro Shimoda

>> Best regards,
>> Yoshihiro Shimoda
> 
> WBR, Sergei
> 
--
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

[PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly

[Oussama Ghorbel]

The USB OTG port does not work since v3.16 on omap platform.
This is a regression introduced by the commit
eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure
 and remove).
This because the call to pm_runtime_enable() function is moved after the
call to devm_phy_create() function, which has side effect since later in
the subsequent calls of devm_phy_create() there is a check with
pm_runtime_enabled() to configure few things.

Signed-off-by: Oussama Ghorbel 
---
 drivers/phy/phy-omap-usb2.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 93d7835..acc13f8 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -262,14 +262,16 @@ static int omap_usb2_probe(struct platform_device *pdev)
otg->phy= &phy->phy;
 
platform_set_drvdata(pdev, phy);
+   pm_runtime_enable(phy->dev);
 
generic_phy = devm_phy_create(phy->dev, NULL, &ops, NULL);
-   if (IS_ERR(generic_phy))
+   if (IS_ERR(generic_phy)) {
+   pm_runtime_disable(phy->dev);
return PTR_ERR(generic_phy);
+   }
 
phy_set_drvdata(generic_phy, phy);
 
-   pm_runtime_enable(phy->dev);
phy_provider = devm_of_phy_provider_register(phy->dev,
of_phy_simple_xlate);
if (IS_ERR(phy_provider)) {
-- 
1.8.3.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 v2 1/2] arm: shmobile: r8a7790: add HS-USB device node

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7790.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 2380fd5..63a75f2 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -600,6 +600,17 @@
status = "disabled";
};
 
+   hsusb: usb@e659 {
+   compatible = "renesas,usbhs-r8a7790";
+   reg = <0 0xe659 0 0x100>;
+   interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
+   renesas,buswait = <4>;
+   phys = <&usb0 1>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
usbphy: usb-phy@e6590100 {
compatible = "renesas,usb-phy-r8a7790";
reg = <0 0xe6590100 0 0x100>;
-- 
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 v2 2/2] arm: shmobile: lager: enable HS-USB

[Yoshihiro Shimoda]

Since this board doesn't have USB ID pin, we assumes the GP5_18 (USB0_PWEN)
is an ID pin because the gpio is high when the SW5 is Pin 3 side.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7790-lager.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 719979e..011254a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -446,3 +446,8 @@
};
};
 };
+
+&hsusb {
+   status = "okay";
+   renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_HIGH>;
+};
-- 
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 v2 0/2] arm: shimobile: add HS-USB device node on r8a7790

[Yoshihiro Shimoda]

 This series is based on Simon's renesas.git branch and
renesas-devel-20141007-v3.17 tag. If we use the generic phy
driver for R-Car Gen2 (drivers/phy/phy-rcar-gen2.c), we can use
the HS-USB on lager.

Changes from v1:
 - Correct typo of git log in patch 1.
 - Change the placement of hsusb node in patch 1.
 - Add git log comment in patch 2.
 - Fix the gpio prop in patch 2.

Yoshihiro Shimoda (2):
  arm: shmobile: r8a7790: add HS-USB device node
  arm: shmobile: lager: enable HS-USB

 arch/arm/boot/dts/r8a7790-lager.dts |5 +
 arch/arm/boot/dts/r8a7790.dtsi  |   11 +++
 2 files changed, 16 insertions(+)

-- 
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 v2 1/3] arm: shmobile: r8a7791: add HS-USB device node

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7791.dtsi |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index d343099..761036c 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -637,6 +637,17 @@
status = "disabled";
};
 
+   hsusb: usb@e659 {
+   compatible = "renesas,usbhs-r8a7791";
+   reg = <0 0xe659 0 0x100>;
+   interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp7_clks R8A7791_CLK_HSUSB>;
+   renesas,buswait = <4>;
+   phys = <&usb0 1>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
usbphy: usb-phy@e6590100 {
compatible = "renesas,usb-phy-r8a7791";
reg = <0 0xe6590100 0 0x100>;
-- 
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 v2 2/3] arm: shmobile: koelsch: enable HS-USB

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 17cfcaa..055f8f8 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -496,3 +496,8 @@
};
};
 };
+
+&hsusb {
+   status = "okay";
+   renesas,enable-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+};
-- 
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 v2 0/3] arm: shimobile: add HS-USB device node on r8a7791

[Yoshihiro Shimoda]

 This series is based on Simon's renesas.git branch and
renesas-devel-20141007-v3.17 tag. If we use the generic phy
driver for R-Car Gen2 (drivers/phy/phy-rcar-gen2.c), we can use
the HS-USB on koelsch and henninger.

Changes from v1:
 - Correct typo of git log in patch 1.
 - Change the placement of hsusb node in patch 1.
 - Fix the gpio prop in patch 2.
 - Fix the gpio prop in patch 3.

Yoshihiro Shimoda (3):
  arm: shmobile: r8a7791: add HS-USB device node
  arm: shmobile: koelsch: enable HS-USB
  arm: shmobile: henninger: enable HS-USB

 arch/arm/boot/dts/r8a7791-henninger.dts |5 +
 arch/arm/boot/dts/r8a7791-koelsch.dts   |5 +
 arch/arm/boot/dts/r8a7791.dtsi  |   11 +++
 3 files changed, 21 insertions(+)

-- 
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 v2 3/3] arm: shmobile: henninger: enable HS-USB

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7791-henninger.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-henninger.dts 
b/arch/arm/boot/dts/r8a7791-henninger.dts
index ef2cb92..8fc7802 100644
--- a/arch/arm/boot/dts/r8a7791-henninger.dts
+++ b/arch/arm/boot/dts/r8a7791-henninger.dts
@@ -300,3 +300,8 @@
};
};
 };
+
+&hsusb {
+   status = "okay";
+   renesas,enable-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+};
-- 
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 v2 2/2] arm: shmobile: lager: enable HS-USB

[Sergei Shtylyov]

On 10/7/2014 3:10 PM, Yoshihiro Shimoda wrote:


Since this board doesn't have USB ID pin, we assumes the GP5_18 (USB0_PWEN)
is an ID pin because the gpio is high when the SW5 is Pin 3 side.



Signed-off-by: Yoshihiro Shimoda 
---
  arch/arm/boot/dts/r8a7790-lager.dts |5 +
  1 file changed, 5 insertions(+)



diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 719979e..011254a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -446,3 +446,8 @@
};
};
  };
+
+&hsusb {
+   status = "okay";
+   renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_HIGH>;
+};


   As I said before, this is not enough. We need pinctrl-related props. Same 
is true for other boards.


WBR, Sergei

--
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: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem

[Erik Alapää]

On Sat, Oct 4, 2014 at 12:02 AM, Oliver Neukum  wrote:
>
> I suggest you take an usbmon trace to look for the CDC notification.
>

Hi again, took a while to respond because I have been away on a trip.
I am new at sniffing USB traffic, so forgive me if the below info is
inadequate. I reset the 4G modem with AT+CFUN=4 followed by AT+CFUN=6.
The modem is on bus 3, device id 10, and after reset the new device Id
is 11. Below is a text dump (exported from wireshark) of the first few
USB packets seen when the device pops up after reset (takes ~10
seconds from AT+CFUN=6 is issued).

Two additional things to note:
1. When I do the command that freezes the cdc-wdm control line for
several minutes (AT+CGACT=1,1), I do not see the AT command in the USB
dump as I do with other AT commands like AT+CFUN.

2. In the kernel logs I can see an error message (not caused by
AT+CGACT) that emanates from linux/drivers/usb/class/cdc-wdm.c:
Oct  7 13:43:36 hilbert kernel: [13872.317954] huawei_cdc_ncm 3-3:1.2:
unknown notification 3 received: index 2 len 4

Excerpt from when device pops up after reset with AT+CFUN:
No. Time   SourceDestination
Protocol Length Info
   2995 53.388617000   host  11.0  USB
 64 GET DESCRIPTOR Request DEVICE

Frame 2995: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct  7, 2014 11:52:44.22313 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.22313 seconds
[Time delta from previous captured frame: 0.015917000 seconds]
[Time delta from previous displayed frame: 0.015917000 seconds]
[Time since reference or first frame: 53.388617000 seconds]
Frame Number: 2995
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1...  = Direction: IN (1)
.000  = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: relevant (0)
Data: not present ('<')
URB sec: 1412675564
URB usec: 223130
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 18
Data length [bytes]: 0
[Response in: 2996]
URB setup
bmRequestType: 0x80
1...  = Direction: Device-to-host
.00.  = Type: Standard (0x00)
...0  = Recipient: Device (0x00)
bRequest: GET DESCRIPTOR (6)
Descriptor Index: 0x00
bDescriptorType: DEVICE (1)
Language Id: no language specified (0x)
wLength: 18

No. Time   SourceDestination
Protocol Length Info
   2996 53.388789000   11.0  host  USB
 82 GET DESCRIPTOR Response DEVICE

Frame 2996: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct  7, 2014 11:52:44.223302000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.223302000 seconds
[Time delta from previous captured frame: 0.000172000 seconds]
[Time delta from previous displayed frame: 0.000172000 seconds]
[Time since reference or first frame: 53.388789000 seconds]
Frame Number: 2996
Frame Length: 82 bytes (656 bits)
Capture Length: 82 bytes (656 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_COMPLETE ('C')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1...  = Direction: IN (1)
.000  = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1412675564
URB usec: 223302
URB status: Success (0)
URB length [bytes]: 18
Data length [bytes]: 18
[Request in: 2995]
[Time from request: 0.000172000 seconds]
[bInterfaceClass: Unknown (0x)]
DEVICE DESCRIPTOR
bLength: 18
bDescriptorType: DEVICE (1)
bcdUSB: 0x0200
bDeviceClass: Device (0x00)
bDeviceSubClass: 0
bDeviceProtocol: 0 (Use class code info from Interface Descriptors)
bMaxPacketSize0: 64
idVendor: Huawei Technologies Co., Ltd. (0x12d1)
idProduct: Modem/Networkcard (0x1506)
bcdDevice: 0x0102
iManufacturer: 3
iProduct: 2
iSerialNumber: 0
bNumConfigurations: 1

No. Time   SourceDestination
Protocol Length Info
   2997 53.388816000   host  11.0  USB
 64 GET DESCRIPTOR Request CONFIGURATION

Frame 2997: 64 bytes on wire (512 b

Re: [PATCH v2 2/2] arm: shmobile: lager: enable HS-USB

[Yoshihiro Shimoda]

(2014/10/07 20:42), Sergei Shtylyov wrote:
> On 10/7/2014 3:10 PM, Yoshihiro Shimoda wrote:
> 
>> Since this board doesn't have USB ID pin, we assumes the GP5_18 (USB0_PWEN)
>> is an ID pin because the gpio is high when the SW5 is Pin 3 side.
> 
>> Signed-off-by: Yoshihiro Shimoda 
>> ---
>>   arch/arm/boot/dts/r8a7790-lager.dts |5 +
>>   1 file changed, 5 insertions(+)
> 
>> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
>> b/arch/arm/boot/dts/r8a7790-lager.dts
>> index 719979e..011254a 100644
>> --- a/arch/arm/boot/dts/r8a7790-lager.dts
>> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
>> @@ -446,3 +446,8 @@
>>   };
>>   };
>>   };
>> +
>> +&hsusb {
>> +status = "okay";
>> +renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_HIGH>;
>> +};
> 
>As I said before, this is not enough. We need pinctrl-related props. Same 
> is true for other boards.

Thank you very much for the point again.
Finally I understood what you said before.
I will start studying the pinctrl world.

Best regards,
Yoshihiro Shimoda

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

Re: [PATCH 2/6] mfd: rtsx_usb: fix platform device-id collision

[Johan Hovold]

On Tue, Oct 07, 2014 at 10:22:58AM +0100, Lee Jones wrote:
> On Fri, 26 Sep 2014, Johan Hovold wrote:
> 
> > Hot-pluggable multi-function devices should use PLATFORM_DEVID_AUTO to
> > avoid name collisions on the platform bus.
> > 
> > This driver currently uses the USB-device address as an id. This makes
> > name collisions unlikely, but it could still happen if two devices are
> > connected to separate buses and gets assigned the same address.
> > 
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/mfd/rtsx_usb.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> This patch is superfluous.

Well, it would have documented the fact that there could be probe
failures due to id collisions with current and older kernels.

> Just wait until the hotpluggable version is applied, then use it.

Fine with me. The collisions are quite unlikely anyway.

Thanks,
Johan

> > diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
> > index 71f387ce8cbd..78073e4b87e4 100644
> > --- a/drivers/mfd/rtsx_usb.c
> > +++ b/drivers/mfd/rtsx_usb.c
> > @@ -647,7 +647,7 @@ static int rtsx_usb_probe(struct usb_interface *intf,
> > /* initialize USB SG transfer timer */
> > setup_timer(&ucr->sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
> >  
> > -   ret = mfd_add_devices(&intf->dev, usb_dev->devnum, rtsx_usb_cells,
> > +   ret = mfd_add_devices(&intf->dev, PLATFORM_DEVID_AUTO, rtsx_usb_cells,
> > ARRAY_SIZE(rtsx_usb_cells), NULL, 0, NULL);
> > if (ret)
> > goto out_init_fail;
--
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: btusb_intr_complete returns -EPIPE

[Naveen Kumar Parna]

Thanks for the new patch.



The new patch clears the halt condition. But after submitting the urb
again the INT in endpoint returns EPIPE, this behavior continues
infinitely.



Corresponding kernel log is here:

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311863] hci0 urb
88012f670b40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311988] hci5 urb
8801379d2180 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455464] hci4 urb
88012a4b2e40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455586] hci1 urb
88012a4b2180 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455691] hci2 urb
88012f670480 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455784] hci3 urb
88012f670e40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455853] hci0 urb
880131e5ee40 status -32 count 0

Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455913] hci5 urb
880131e5e780 status -32 count 0

Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690366] hci4 urb
880131e5e780 status -32 count 0

Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690490] hci5 urb
880131e5e300 status -32 count 0

Oct  7 17:58:47 naveen-OptiPlex-745 kernel: [   22.163163] hci5 urb
88012f541540 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.313996] hci1 urb
880131e5ee40 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314121] hci0 urb
880131e5e900 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314169] hci3 urb
880131e5e3c0 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314213] hci2 urb
880131e5ef00 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314245] hci4 urb
88012f541d80 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314274] hci5 urb
88012f541540 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.319974] hci2 urb
8801384dcb40 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320095] hci0 urb
8801384dc300 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320151] hci4 urb
8801384dc6c0 status -32 count 0

Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320193] hci5 urb
8801384dcf00 status -32 count 0



Thanks,

Naveen

On Tue, Oct 7, 2014 at 3:31 PM, Oliver Neukum  wrote:
> On Tue, 2014-10-07 at 12:14 +0530, Naveen Kumar Parna wrote:
>> > +   err = usb_clear_halt(data->udev,
>> > +usb_rcvbulkpipe(data->udev,
>> > +
>> > data->intr_ep->bEndpointAddress));
>>
>> EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe()
>> instead of usb_rcvbulkpipe() right?
>
> Yes. And I noticed a copy and past error.
>
>> Does the “lsusb –v” gives any clue about the reason for getting -EPIPE?
>
> No. Could you nevertheless test the attached version?
>
> Regards
> Oliver
>
--
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: gadget: f_fs: add "zombie" mode

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 08:33:16AM +0200, Robert Baldyga wrote:
> On 10/07/2014 04:28 AM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
> >> Since we can compose gadgets from many functions, there is the problem
> >> related to gadget breakage while FunctionFS daemon being closed. In some
> >> cases it's strongly desired to keep gadget alive for a while, despite
> >> FunctionFS files are closed, to allow another functions to complete
> >> some presumably critical operations.
> >>
> >> For this purpose this patch introduces "zombie" mode. It can be enabled
> >> by setting mount option "zombie=1", and results with defering function
> >> closure to the moment of reopening ep0 file or filesystem umount.
> >>
> >> When ffs->state == FFS_ZOMBIE:
> >> - function is still binded and visible to host,
> >> - setup requests are automatically stalled,
> >> - all another transfers are refused,
> >> - opening ep0 causes function close, and then FunctionFS is ready for
> >>   descriptors and string write,
> >> - umount of functionfs cause function close.
> >>
> >> Signed-off-by: Robert Baldyga 
> > 
> > Can you further explain how do you trigger this ? Do I understand
> > correctly that you composed a gadget using configfs and that gadget has
> > functionfs + another gadget ?
> > 
> 
> Yes, I compose configfs gadget from functionfs + another gadget, and
> when functionfs daemon closes ep files, entire gadget get disconnected
> from host. FFS function is userspace code so there is no way to know
> when it will close files (it doesn't matter what is the reason of this
> situation, it can be daemon logic, program breakage, process kill or any
> other). So when we have another function in gadget which, for example,
> sends some amount of data, does some software update or implements some
> real-time functionality, we may want to keep the gadget connected
> despite FFS function is no longer functional. We can't just remove one
> of functions from gadget since it has been enumerated, so the only way
> we can do that is to make broken FFS function "zombie". It will be still
> visible to host but it will no longer implement it's functionality.

now that's an explanation. Can you update commit log with some of this
info (once we agree on how to go about fixing this) ?

I'm not sure we should try to fix this. The only case where this could
trigger is if ffs daemon crashes and dies or somebody sends a bogus
signal to kill it.

A function cannot communicate with the host if it isn't functional
and ffs depends on its userland daemon. If daemon is crashing, why not
print a big WARN("closed %s while connected to host\n") ? That seems
like it's as much as we can do from the kernel. Userland should know
that they can't have a buggy ffs daemon.

> > Then what do you need to do the trigger the issue, and what really _is_
> > the issue ? Is gadget disconnecting from host too early ? Do you see a
> > crash ? Memory leak ? Any logs available ? Any steps to reproduce ?
> > 
> 
> You simply compose gadget from, for example, ethernet and functionfs.
> You try to send some huge file through ftp, and in meantime FFS function
> breaks. If FFS hasn't enabled "zombie" mode, entire gadget will be
> disconnected and data transmission will fail. If "zombie" mode is
> enabled, then FFS function after daemon breakage will become "zombie"
> and will be nonfunctional, but ethernet gadget will be still active and
> data transfer will be completed.

yeah, this is the problem I have with the feature. We can't expose a
non-working interface to USB host. If daemon crashes, we have to
disconnect.

> > Quite frankly, I don't really like this "zombie" mode.  I know
> > there's a "The Walking Dead" hype right now, but this is too much.
> > 
> >
> 
> I see, but after all I couldn't find more descriptive name for this feature.

That was a joke :)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 3/3] usb: renesas_usbhs: add support for generic PHY

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 12:43:06PM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for the generic PHY. The generic PHY will be
> used in multiplatform environment.
> 
> Signed-off-by: Yoshihiro Shimoda 

Kishon, does this look ok to you ?

> ---
>  drivers/usb/renesas_usbhs/common.h |1 +
>  drivers/usb/renesas_usbhs/rcar2.c  |   29 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/usb/renesas_usbhs/common.h 
> b/drivers/usb/renesas_usbhs/common.h
> index e0d53c5..c45667f 100644
> --- a/drivers/usb/renesas_usbhs/common.h
> +++ b/drivers/usb/renesas_usbhs/common.h
> @@ -270,6 +270,7 @@ struct usbhs_priv {
>   struct usbhs_fifo_info fifo_info;
>  
>   struct usb_phy *usb_phy;
> + struct phy *phy;
>  };
>  
>  /*
> diff --git a/drivers/usb/renesas_usbhs/rcar2.c 
> b/drivers/usb/renesas_usbhs/rcar2.c
> index 485b889..8fc15c0 100644
> --- a/drivers/usb/renesas_usbhs/rcar2.c
> +++ b/drivers/usb/renesas_usbhs/rcar2.c
> @@ -12,6 +12,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "common.h"
> @@ -21,6 +22,16 @@ static int usbhs_rcar2_hardware_init(struct 
> platform_device *pdev)
>  {
>   struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
>  
> + if (IS_ENABLED(CONFIG_GENERIC_PHY)) {
> + struct phy *phy = phy_get(&pdev->dev, "usb");
> +
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + priv->phy = phy;
> + return 0;
> + }
> +
>   if (IS_ENABLED(CONFIG_USB_PHY)) {
>   struct usb_phy *usb_phy = usb_get_phy_dev(&pdev->dev, 0);
>  
> @@ -38,6 +49,11 @@ static int usbhs_rcar2_hardware_exit(struct 
> platform_device *pdev)
>  {
>   struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
>  
> + if (priv->phy) {
> + phy_put(priv->phy);
> + priv->phy = NULL;
> + }
> +
>   if (priv->usb_phy) {
>   usb_put_phy(priv->usb_phy);
>   priv->usb_phy = NULL;
> @@ -52,6 +68,19 @@ static int usbhs_rcar2_power_ctrl(struct platform_device 
> *pdev,
>   struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
>   int retval = -ENODEV;
>  
> + if (priv->phy) {
> + if (enable) {
> + retval = phy_init(priv->phy);
> +
> + if (!retval)
> + retval = phy_power_on(priv->phy);
> + } else {
> + phy_power_off(priv->phy);
> + phy_exit(priv->phy);
> + retval = 0;
> + }
> + }
> +
>   if (priv->usb_phy) {
>   if (enable) {
>   retval = usb_phy_init(priv->usb_phy);
> -- 
> 1.7.9.5
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

[Felipe Balbi]

On Tue, Oct 07, 2014 at 03:49:33PM +0530, Vivek Gautam wrote:
> Exynos7 also has a separate special gate clock going to the IP
> apart from the usual AHB clock. So add support for the same.
> 
> Signed-off-by: Vivek Gautam 

I'll take this one once -rc1 is tagged. The others have no direct
dependency on this so I'll leave them to Kishon.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC v4] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 02:45:44PM +0530, Kiran Kumar Raparthy wrote:
> diff --git a/drivers/usb/phy/otg-wakeupsource.c 
> b/drivers/usb/phy/otg-wakeupsource.c
> new file mode 100644
> index 000..00d3359
> --- /dev/null
> +++ b/drivers/usb/phy/otg-wakeupsource.c
> @@ -0,0 +1,134 @@
> +/*
> + * otg-wakeupsource.c
> + *
> + * Copyright (C) 2011 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void otgws_handle_event(struct usb_phy *otgws_xceiv, unsigned long 
> event)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&otgws_xceiv->otgws_slock, irqflags);
> +
> + switch (event) {
> + case USB_EVENT_VBUS:

Looks like VBUS should be temporary too.

> + case USB_EVENT_ENUMERATED:
> + __pm_stay_awake(&otgws_xceiv->wsource);
> + break;
> +
> + case USB_EVENT_NONE:
> + case USB_EVENT_ID:
> + case USB_EVENT_CHARGER:
> + __pm_wakeup_event(&otgws_xceiv->wsource,
> + msecs_to_jiffies(TEMPORARY_HOLD_TIME));
> + break;
> +
> + default:
> + break;
> + }
> +
> + spin_unlock_irqrestore(&otgws_xceiv->otgws_slock, irqflags);
> +}
> +
> +static int otgws_otg_usb2_notifications(struct notifier_block *nb,
> + unsigned long event, void *unused)
> +{
> + static struct usb_phy *otgws_xceiv;
> +
> + otgws_xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
> +
> + if (IS_ERR(otgws_xceiv)) {
> + pr_err("%s: No OTG transceiver found\n", __func__);
> + return PTR_ERR(otgws_xceiv);
> + }
> +
> + otgws_handle_event(otgws_xceiv, event);
> +
> + return NOTIFY_OK;
> +}
> +
> +static int otgws_otg_usb3_notifications(struct notifier_block *nb,
> + unsigned long event, void *unused)
> +{
> + static struct usb_phy *otgws_xceiv;
> +
> + otgws_xceiv = usb_get_phy(USB_PHY_TYPE_USB3);
> +
> + if (IS_ERR(otgws_xceiv)) {
> + pr_err("%s: No OTG transceiver found\n", __func__);
> + return PTR_ERR(otgws_xceiv);
> + }
> +
> + otgws_handle_event(otgws_xceiv, event);
> +
> + return NOTIFY_OK;
> +}
> +
> +static int otg_wakeupsource_init(void)
> +{
> + int ret_usb2;
> + int ret_usb3;
> + char wsource_name_usb2[40];
> + char wsource_name_usb3[40];
> + static struct usb_phy *otgws_xceiv_usb2;
> + static struct usb_phy *otgws_xceiv_usb3;
> +
> + otgws_xceiv_usb2 = usb_get_phy(USB_PHY_TYPE_USB2);
> + otgws_xceiv_usb3 = usb_get_phy(USB_PHY_TYPE_USB3);
> +
> + if (IS_ERR(otgws_xceiv_usb2) && IS_ERR(otgws_xceiv_usb3)) {
> + pr_err("%s: No OTG transceiver found\n", __func__);
> + return PTR_ERR(otgws_xceiv_usb2);
> + }
> +
> + spin_lock_init(&otgws_xceiv_usb2->otgws_slock);
> + spin_lock_init(&otgws_xceiv_usb3->otgws_slock);
> +
> + snprintf(wsource_name_usb2, sizeof(wsource_name_usb2), "vbus-%s",
> + dev_name(otgws_xceiv_usb2->dev));
> + wakeup_source_init(&otgws_xceiv_usb2->wsource, wsource_name_usb2);
> +
> + snprintf(wsource_name_usb3, sizeof(wsource_name_usb3), "vbus-%s",
> + dev_name(otgws_xceiv_usb3->dev));
> + wakeup_source_init(&otgws_xceiv_usb3->wsource, wsource_name_usb3);
> +
> + otgws_xceiv_usb2->otgws_nb.notifier_call = otgws_otg_usb2_notifications;
> + ret_usb2 = usb_register_notifier(otgws_xceiv_usb2,
> + &otgws_xceiv_usb2->otgws_nb);
> +
> + otgws_xceiv_usb3->otgws_nb.notifier_call = otgws_otg_usb3_notifications;
> + ret_usb3 = usb_register_notifier(otgws_xceiv_usb3,
> + &otgws_xceiv_usb3->otgws_nb);
> +
> + if (ret_usb2 && ret_usb3) {
> + pr_err("%s: usb_register_notifier on transceiver failed\n",
> +  __func__);
> + wakeup_source_trash(&otgws_xceiv_usb2->wsource);
> + wakeup_source_trash(&otgws_xceiv_usb3->wsource);
> + otgws_xceiv_usb2 = NULL;
> + otgws_xceiv_usb3 = NULL;
> + return ret_usb2 | ret_usb3;
> + }
> +
> + return 0;
> +}
> +
> +late_initcall(otg_wakeupsource_init);

you guys are really not getting what I mean. I asked for this to be
built into the core itself. This means that you shouldn't need to use
notifications nor should you need to call usb_get_phy(). You're part of
the PHY framework.

Re: btusb_intr_complete returns -EPIPE

[Naveen Kumar Parna]

> The new patch clears the halt condition.

I mean usb_clear_halt( ) returned zero.


Thanks,

Naveen

On Tue, Oct 7, 2014 at 7:04 PM, Naveen Kumar Parna  wrote:
> Thanks for the new patch.
>
>
>
> The new patch clears the halt condition. But after submitting the urb
> again the INT in endpoint returns EPIPE, this behavior continues
> infinitely.
>
>
>
> Corresponding kernel log is here:
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311863] hci0 urb
> 88012f670b40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.311988] hci5 urb
> 8801379d2180 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455464] hci4 urb
> 88012a4b2e40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455586] hci1 urb
> 88012a4b2180 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455691] hci2 urb
> 88012f670480 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455784] hci3 urb
> 88012f670e40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455853] hci0 urb
> 880131e5ee40 status -32 count 0
>
> Oct  7 17:58:41 naveen-OptiPlex-745 kernel: [   16.455913] hci5 urb
> 880131e5e780 status -32 count 0
>
> Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690366] hci4 urb
> 880131e5e780 status -32 count 0
>
> Oct  7 17:58:44 naveen-OptiPlex-745 kernel: [   19.690490] hci5 urb
> 880131e5e300 status -32 count 0
>
> Oct  7 17:58:47 naveen-OptiPlex-745 kernel: [   22.163163] hci5 urb
> 88012f541540 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.313996] hci1 urb
> 880131e5ee40 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314121] hci0 urb
> 880131e5e900 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314169] hci3 urb
> 880131e5e3c0 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314213] hci2 urb
> 880131e5ef00 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314245] hci4 urb
> 88012f541d80 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.314274] hci5 urb
> 88012f541540 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.319974] hci2 urb
> 8801384dcb40 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320095] hci0 urb
> 8801384dc300 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320151] hci4 urb
> 8801384dc6c0 status -32 count 0
>
> Oct  7 18:06:01 naveen-OptiPlex-745 kernel: [   45.320193] hci5 urb
> 8801384dcf00 status -32 count 0
>
>
>
> Thanks,
>
> Naveen
>
> On Tue, Oct 7, 2014 at 3:31 PM, Oliver Neukum  wrote:
>> On Tue, 2014-10-07 at 12:14 +0530, Naveen Kumar Parna wrote:
>>> > +   err = usb_clear_halt(data->udev,
>>> > +usb_rcvbulkpipe(data->udev,
>>> > +
>>> > data->intr_ep->bEndpointAddress));
>>>
>>> EPIPE occurred for INT in endpoint, so we should use usb_rcvintpipe()
>>> instead of usb_rcvbulkpipe() right?
>>
>> Yes. And I noticed a copy and past error.
>>
>>> Does the “lsusb –v” gives any clue about the reason for getting -EPIPE?
>>
>> No. Could you nevertheless test the attached version?
>>
>> Regards
>> Oliver
>>
--
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: bugreport: huawei_cdc_ncm control device freezes for 3-5 minutes on connect with E3276 LTE modem

[Erik Alapää]

On Sat, Oct 4, 2014 at 12:02 AM, Oliver Neukum  wrote:
>
> I suggest you take an usbmon trace to look for the CDC notification.
>

Hi again, took a while to respond because I have been away on a trip.
I am new at sniffing USB traffic, so forgive me if the below info is
inadequate. I reset the 4G modem with AT+CFUN=4 followed by AT+CFUN=6.
The modem is on bus 3, device id 10, and after reset the new device Id
is 11. Below is a text dump (exported from wireshark) of the first few
USB packets seen when the device pops up after reset (takes ~10
seconds from AT+CFUN=6 is issued).

Two additional things to note:
1. When I do the command that freezes the cdc-wdm control line for
several minutes (AT+CGACT=1,1), I do not see the AT command in the USB
dump as I do with other AT commands like AT+CFUN.

2. In the kernel logs I can see an error message (not caused by
AT+CGACT) that emanates from linux/drivers/usb/class/cdc-wdm.c:
Oct  7 13:43:36 hilbert kernel: [13872.317954] huawei_cdc_ncm 3-3:1.2:
unknown notification 3 received: index 2 len 4

Excerpt from when device pops up after reset with AT+CFUN:
No. Time   SourceDestination
Protocol Length Info
   2995 53.388617000   host  11.0  USB
 64 GET DESCRIPTOR Request DEVICE

Frame 2995: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct  7, 2014 11:52:44.22313 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.22313 seconds
[Time delta from previous captured frame: 0.015917000 seconds]
[Time delta from previous displayed frame: 0.015917000 seconds]
[Time since reference or first frame: 53.388617000 seconds]
Frame Number: 2995
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1...  = Direction: IN (1)
.000  = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: relevant (0)
Data: not present ('<')
URB sec: 1412675564
URB usec: 223130
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 18
Data length [bytes]: 0
[Response in: 2996]
URB setup
bmRequestType: 0x80
1...  = Direction: Device-to-host
.00.  = Type: Standard (0x00)
...0  = Recipient: Device (0x00)
bRequest: GET DESCRIPTOR (6)
Descriptor Index: 0x00
bDescriptorType: DEVICE (1)
Language Id: no language specified (0x)
wLength: 18

No. Time   SourceDestination
Protocol Length Info
   2996 53.388789000   11.0  host  USB
 82 GET DESCRIPTOR Response DEVICE

Frame 2996: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct  7, 2014 11:52:44.223302000 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1412675564.223302000 seconds
[Time delta from previous captured frame: 0.000172000 seconds]
[Time delta from previous displayed frame: 0.000172000 seconds]
[Time since reference or first frame: 53.388789000 seconds]
Frame Number: 2996
Frame Length: 82 bytes (656 bits)
Capture Length: 82 bytes (656 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb]
USB URB
URB id: 0x8800c7aa2b40
URB type: URB_COMPLETE ('C')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x80, Direction: IN
1...  = Direction: IN (1)
.000  = Endpoint value: 0
Device: 11
URB bus id: 3
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1412675564
URB usec: 223302
URB status: Success (0)
URB length [bytes]: 18
Data length [bytes]: 18
[Request in: 2995]
[Time from request: 0.000172000 seconds]
[bInterfaceClass: Unknown (0x)]
DEVICE DESCRIPTOR
bLength: 18
bDescriptorType: DEVICE (1)
bcdUSB: 0x0200
bDeviceClass: Device (0x00)
bDeviceSubClass: 0
bDeviceProtocol: 0 (Use class code info from Interface Descriptors)
bMaxPacketSize0: 64
idVendor: Huawei Technologies Co., Ltd. (0x12d1)
idProduct: Modem/Networkcard (0x1506)
bcdDevice: 0x0102
iManufacturer: 3
iProduct: 2
iSerialNumber: 0
bNumConfigurations: 1

No. Time   SourceDestination
Protocol Length Info
   2997 53.388816000   host  11.0  USB
 64 GET DESCRIPTOR Request CONFIGURATION

Frame 2997: 64 bytes on wire (512 b

RE: [PATCH] usb: gadget: f_fs: add "zombie" mode

[Krzysztof Opasiak]

Hi,

> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, October 07, 2014 4:07 PM
> To: Robert Baldyga
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org; linux-ker...@vger.kernel.org;
> min...@mina86.com; andrze...@samsung.com; k.opas...@samsung.com
> Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
> 
> Hi,
> 
> On Tue, Oct 07, 2014 at 08:33:16AM +0200, Robert Baldyga wrote:
> > On 10/07/2014 04:28 AM, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
> > >> Since we can compose gadgets from many functions, there is the
> > >> problem related to gadget breakage while FunctionFS daemon
> being
> > >> closed. In some cases it's strongly desired to keep gadget
> alive
> > >> for a while, despite FunctionFS files are closed, to allow
> another
> > >> functions to complete some presumably critical operations.
> > >>
> > >> For this purpose this patch introduces "zombie" mode. It can
> be
> > >> enabled by setting mount option "zombie=1", and results with
> > >> defering function closure to the moment of reopening ep0 file
> or filesystem umount.
> > >>
> > >> When ffs->state == FFS_ZOMBIE:
> > >> - function is still binded and visible to host,
> > >> - setup requests are automatically stalled,
> > >> - all another transfers are refused,
> > >> - opening ep0 causes function close, and then FunctionFS is
> ready for
> > >>   descriptors and string write,
> > >> - umount of functionfs cause function close.
> > >>
> > >> Signed-off-by: Robert Baldyga 
> > >
> > > Can you further explain how do you trigger this ? Do I
> understand
> > > correctly that you composed a gadget using configfs and that
> gadget
> > > has functionfs + another gadget ?
> > >
> >
> > Yes, I compose configfs gadget from functionfs + another gadget,
> and
> > when functionfs daemon closes ep files, entire gadget get
> disconnected
> > from host. FFS function is userspace code so there is no way to
> know
> > when it will close files (it doesn't matter what is the reason of
> this
> > situation, it can be daemon logic, program breakage, process kill
> or
> > any other). So when we have another function in gadget which, for
> > example, sends some amount of data, does some software update or
> > implements some real-time functionality, we may want to keep the
> > gadget connected despite FFS function is no longer functional. We
> > can't just remove one of functions from gadget since it has been
> > enumerated, so the only way we can do that is to make broken FFS
> > function "zombie". It will be still visible to host but it will
> no longer implement it's functionality.
> 
> now that's an explanation. Can you update commit log with some of
> this info (once we agree on how to go about fixing this) ?
> 
> I'm not sure we should try to fix this. The only case where this
> could trigger is if ffs daemon crashes and dies or somebody sends a
> bogus signal to kill it.
> 
> A function cannot communicate with the host if it isn't functional
> and ffs depends on its userland daemon. If daemon is crashing, why
> not print a big WARN("closed %s while connected to host\n") ? That
> seems like it's as much as we can do from the kernel. Userland
> should know that they can't have a buggy ffs daemon.

It's not a problem of buggy ffs daemon. The problem is that there are
some non deterministic mechanisms in userspace like OOM killer. FFS
daemon can be written very well but if we are out of memory it may
become a victim. In this case reliability of whole gadget hurts a lot.

If it's going about WARN(). I'm not enthusiastic about it. Userspace
process dies all the time, that's quite normal;) I don't think that it
is good idea to generate a warning on kernel level when some process
dies. Kernel should be resistant for such situations and know how to
deal with them (maybe user could select exact behavior, but it should be
done on kernel site)

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
k.opas...@samsung.com



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

Re: xhci_hcd can't detect new devices after enabling runtime PM and disabling S3 wake (bug #85701)

[Alan Stern]

On Mon, 6 Oct 2014, Dmitry Nezhevenko wrote:

> > What does the debugging log show if you don't disable wakeup?
> 
> $It looks like same, but later it resumes once again.
> 
> [ 2836.134277] hub 2-0:1.0: state 7 ports 6 chg  evt 
> [ 2836.134340] hub 2-0:1.0: hub_suspend
> [ 2836.134346] usb usb2: bus auto-suspend, wakeup 1
> [ 2838.797692] usb 1-12: usb auto-suspend, wakeup 0
> [ 2839.237510] usb 1-5: usb auto-suspend, wakeup 0
> [ 2839.405473] usb 1-7: usb auto-suspend, wakeup 0
> [ 2839.421487] hub 1-0:1.0: hub_suspend
> [ 2839.421497] usb usb1: bus auto-suspend, wakeup 1
> [ 2839.421586] xhci_hcd :00:14.0: hcd_pci_runtime_suspend: 0
> [ 2839.421622] xhci_hcd :00:14.0: PME# enabled
> [ 2839.453479] xhci_hcd :00:14.0: power state changed by ACPI to D3cold
> [ 2854.647991] xhci_hcd :00:14.0: power state changed by ACPI to D0
> [ 2854.751914] xhci_hcd :00:14.0: PME# disabled
> [ 2854.751928] xhci_hcd :00:14.0: enabling bus mastering
> [ 2854.751989] xhci_hcd :00:14.0: hcd_pci_runtime_resume: 0
> [ 2854.751994] xhci_hcd :00:14.0: hcd_pci_runtime_suspend: -16
> [ 2854.752017] pci_pm_runtime_suspend(): hcd_pci_runtime_suspend+0x0/0x40 
> [usbcore] returns -16
> [ 2854.752019] usb usb1: usb wakeup-resume
> [ 2854.752026] usb usb1: usb auto-resume
> [ 2854.752056] hub 1-0:1.0: hub_resume
> [ 2854.752095] usb usb1-port5: status 0107 change 
> [ 2854.752107] usb usb1-port7: status 0107 change 
> [ 2854.752125] usb usb1-port12: status 0507 change 
> [ 2854.855937] hub 1-0:1.0: state 7 ports 15 chg  evt 
> [ 2854.855951] hub 1-0:1.0: hub_suspend
> [ 2854.855966] usb usb1: bus auto-suspend, wakeup 1
> [ 2854.856002] usb usb1: suspend raced with wakeup event

That's the difference.  It appears to be caused by a bug in xhci-hcd.
Does the patch below fix the problem?

Alan Stern



Index: usb-3.17/drivers/usb/host/xhci-hub.c
===
--- usb-3.17.orig/drivers/usb/host/xhci-hub.c
+++ usb-3.17/drivers/usb/host/xhci-hub.c
@@ -1136,13 +1136,11 @@ int xhci_bus_suspend(struct usb_hcd *hcd
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, &bus_state->bus_suspended);
}
-   /* USB core sets remote wake mask for USB 3.0 hubs,
-* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
-* is enabled, so also enable remote wake here.
+   /* USB core sets remote wake mask for USB 3.0 hubs but
+* not for USB 2.0 hubs (and only if CONFIG_PM_RUNTIME
+* is enabled), so enable remote wake here.
 */
-   if (hcd->self.root_hub->do_remote_wakeup
-   && device_may_wakeup(hcd->self.controller)) {
-
+   if (hcd->self.root_hub->do_remote_wakeup) {
if (t1 & PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 &= ~PORT_WKCONN_E;

--
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: gadget: f_fs: add "zombie" mode

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 05:01:15PM +0200, Krzysztof Opasiak wrote:
> > > > Hi,
> > > >
> > > > On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
> > > >> Since we can compose gadgets from many functions, there is the
> > > >> problem related to gadget breakage while FunctionFS daemon
> > being
> > > >> closed. In some cases it's strongly desired to keep gadget
> > alive
> > > >> for a while, despite FunctionFS files are closed, to allow
> > another
> > > >> functions to complete some presumably critical operations.
> > > >>
> > > >> For this purpose this patch introduces "zombie" mode. It can
> > be
> > > >> enabled by setting mount option "zombie=1", and results with
> > > >> defering function closure to the moment of reopening ep0 file
> > or filesystem umount.
> > > >>
> > > >> When ffs->state == FFS_ZOMBIE:
> > > >> - function is still binded and visible to host,
> > > >> - setup requests are automatically stalled,
> > > >> - all another transfers are refused,
> > > >> - opening ep0 causes function close, and then FunctionFS is
> > ready for
> > > >>   descriptors and string write,
> > > >> - umount of functionfs cause function close.
> > > >>
> > > >> Signed-off-by: Robert Baldyga 
> > > >
> > > > Can you further explain how do you trigger this ? Do I
> > understand
> > > > correctly that you composed a gadget using configfs and that
> > gadget
> > > > has functionfs + another gadget ?
> > > >
> > >
> > > Yes, I compose configfs gadget from functionfs + another gadget,
> > and
> > > when functionfs daemon closes ep files, entire gadget get
> > disconnected
> > > from host. FFS function is userspace code so there is no way to
> > know
> > > when it will close files (it doesn't matter what is the reason of
> > this
> > > situation, it can be daemon logic, program breakage, process kill
> > or
> > > any other). So when we have another function in gadget which, for
> > > example, sends some amount of data, does some software update or
> > > implements some real-time functionality, we may want to keep the
> > > gadget connected despite FFS function is no longer functional. We
> > > can't just remove one of functions from gadget since it has been
> > > enumerated, so the only way we can do that is to make broken FFS
> > > function "zombie". It will be still visible to host but it will
> > no longer implement it's functionality.
> > 
> > now that's an explanation. Can you update commit log with some of
> > this info (once we agree on how to go about fixing this) ?
> > 
> > I'm not sure we should try to fix this. The only case where this
> > could trigger is if ffs daemon crashes and dies or somebody sends a
> > bogus signal to kill it.
> > 
> > A function cannot communicate with the host if it isn't functional
> > and ffs depends on its userland daemon. If daemon is crashing, why
> > not print a big WARN("closed %s while connected to host\n") ? That
> > seems like it's as much as we can do from the kernel. Userland
> > should know that they can't have a buggy ffs daemon.
> 
> It's not a problem of buggy ffs daemon. The problem is that there are
> some non deterministic mechanisms in userspace like OOM killer. FFS
> daemon can be written very well but if we are out of memory it may
> become a victim. In this case reliability of whole gadget hurts a lot.
> 
> If it's going about WARN(). I'm not enthusiastic about it. Userspace
> process dies all the time, that's quite normal;) I don't think that it
> is good idea to generate a warning on kernel level when some process
> dies. Kernel should be resistant for such situations and know how to
> deal with them (maybe user could select exact behavior, but it should be
> done on kernel site)

yeah, and the way to deal with that is disconnecting from the host
because that USB function, can't be functional anymore. I mean, imagine
you try to e.g. unload pictures from your nice DSLR and that DSLR runs
Linux and implements MTP or PTP using FFS. Then ptpd dies and you're
still connected to the host so you can't know that something went wrong,
the camera just stoped sending you data. So you figure: well, it must
just be slow, I'll leave it here and go have a nap. Hours later and
nothing has changed, because ptpd is still missing.

If you disconnect from the host, however, user knows instantaneously
that something went wrong.

I don't think maintaining a "zombie" function is very nice. In fact, the
very reason for adding usb_function_activate/deactivate was exactly to
prevent us from ever connecting to a host with a non-working function.

-- 
balbi


signature.asc
Description: Digital signature

should i send this ASUS cable back

[SGT. Garcia]

hello,

i bought this usb3.0<-->sata2.5 cable while back but as it turns out, i
think, it's blacklisted in uas-detect.h.
relevant parts of the kernel log:

kernel: usb 4-6: new SuperSpeed USB device number 2 using xhci_hcd
kernel: usb 4-6: New USB device found, idVendor=174c, idProduct=55aa
kernel: usb 4-6: New USB device strings: Mfr=2, Product=3, SerialNumber=1
kernel: usb 4-6: Product: ASUS USB3.0 Boost Cable
kernel: usb 4-6: Manufacturer: ASUS
kernel: usb 4-6: SerialNumber: 0123456789ABCDEF0189
kernel: usb 4-6: UAS is blacklisted for this device, using usb-storage instead
kernel: usb 4-6: UAS is blacklisted for this device, using usb-storage instead
kernel: usb-storage 4-6:1.0: USB Mass Storage device detected
kernel: usb-storage 4-6:1.0: Quirks match for vid 174c pid 55aa: 40
kernel: scsi host6: usb-storage 4-6:1.0
kernel: scsi 6:0:0:0: Direct-Access ASMT 2105 0PQ: 0 
ANSI: 6
kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0
kernel: sd 6:0:0:0: [sdb] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
kernel: sd 6:0:0:0: [sdb] Write Protect is off
kernel: sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00
kernel: sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
kernel:  sdb: sdb1 sdb2
kernel: sd 6:0:0:0: [sdb] Attached SCSI disk

i'm attaching the whole boot log from kernel and 'lspci -nn' and 'lsusb -v'
to this too.

my question is, should i sendback/replace this or is it something that's
going to be fixed in the future?


thanks,
SGT. Garcia
-- Logs begin at Tue 2014-10-07 11:04:24 EDT, end at Tue 2014-10-07 11:45:45 
EDT. --
Oct 07 11:04:24 localhost kernel: Initializing cgroup subsys cpuset
Oct 07 11:04:24 localhost kernel: Initializing cgroup subsys cpu
Oct 07 11:04:24 localhost kernel: Initializing cgroup subsys cpuacct
Oct 07 11:04:24 localhost kernel: Linux version 3.17.0-rc7 
(r...@034-mcl081.campus.local.host) (gcc version 4.8.2 (Funtoo 4.8.2-r3) ) #1 
SMP PREEMPT Fri Oct 3 17:47:14 EDT 2014
Oct 07 11:04:24 localhost kernel: Command line: init=/usr/lib/systemd/systemd 
root=/dev/sdb2 rootfstype=btrfs rootflags=subvol=arch/haswell/root rootwait 
radeon.pcie_gen2=1 radeon.hw_i2c=1 raid=noautodetect hugepagesz=1GB hugepages=1 
usbcore.uas=1
Oct 07 11:04:24 localhost kernel: e820: BIOS-provided physical RAM map:
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0x-0x00057fff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0x00058000-0x00058fff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0x00059000-0x0009efff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0x0009f000-0x0009] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0x0010-0xd54bdfff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xd54be000-0xd54c4fff] ACPI NVS
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xd54c5000-0xd58f5fff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xd58f6000-0xd5d6efff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xd5d6f000-0xdaeeafff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdaeeb000-0xdaff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdb00-0xdb760fff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdb761000-0xdb7f] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdb80-0xdbfb0fff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdbfb1000-0xdbff] ACPI data
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdc00-0xdd71cfff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdd71d000-0xdd7f] ACPI NVS
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdd80-0xdee11fff] usable
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xdee12000-0xdeff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xf800-0xfbff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xfec0-0xfec00fff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xfed0-0xfed03fff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xfed1c000-0xfed1] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xfee0-0xfee00fff] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0xff00-0x] reserved
Oct 07 11:04:24 localhost kernel: BIOS-e820: [mem 
0x0001-0x00021dff] usable
Oct 07 11:04:24 localhost kernel: NX (Execute Disable) protection: active
Oct 07 11:04:24 localhost kernel: e820: update [mem 0xd8963018-0xd8982657] 
usable ==> usable
Oct 07 11:04:24 localhost kernel: e820: update [

RE: [PATCH] usb: gadget: f_fs: add "zombie" mode

[Krzysztof Opasiak]

Hi

> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, October 07, 2014 5:28 PM
> To: Krzysztof Opasiak
> Cc: ba...@ti.com; 'Robert Baldyga'; gre...@linuxfoundation.org;
> linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> min...@mina86.com; andrze...@samsung.com
> Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
> 
> Hi,
> 
> On Tue, Oct 07, 2014 at 05:01:15PM +0200, Krzysztof Opasiak wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga
> wrote:
> > > > >> Since we can compose gadgets from many functions, there is
> the
> > > > >> problem related to gadget breakage while FunctionFS daemon
> > > being
> > > > >> closed. In some cases it's strongly desired to keep gadget
> > > alive
> > > > >> for a while, despite FunctionFS files are closed, to allow
> > > another
> > > > >> functions to complete some presumably critical operations.
> > > > >>
> > > > >> For this purpose this patch introduces "zombie" mode. It
> can
> > > be
> > > > >> enabled by setting mount option "zombie=1", and results
> with
> > > > >> defering function closure to the moment of reopening ep0
> file
> > > or filesystem umount.
> > > > >>
> > > > >> When ffs->state == FFS_ZOMBIE:
> > > > >> - function is still binded and visible to host,
> > > > >> - setup requests are automatically stalled,
> > > > >> - all another transfers are refused,
> > > > >> - opening ep0 causes function close, and then FunctionFS
> is
> > > ready for
> > > > >>   descriptors and string write,
> > > > >> - umount of functionfs cause function close.
> > > > >>
> > > > >> Signed-off-by: Robert Baldyga 
> > > > >
> > > > > Can you further explain how do you trigger this ? Do I
> > > understand
> > > > > correctly that you composed a gadget using configfs and
> that
> > > gadget
> > > > > has functionfs + another gadget ?
> > > > >
> > > >
> > > > Yes, I compose configfs gadget from functionfs + another
> gadget,
> > > and
> > > > when functionfs daemon closes ep files, entire gadget get
> > > disconnected
> > > > from host. FFS function is userspace code so there is no way
> to
> > > know
> > > > when it will close files (it doesn't matter what is the
> reason of
> > > this
> > > > situation, it can be daemon logic, program breakage, process
> kill
> > > or
> > > > any other). So when we have another function in gadget which,
> for
> > > > example, sends some amount of data, does some software update
> or
> > > > implements some real-time functionality, we may want to keep
> the
> > > > gadget connected despite FFS function is no longer
> functional. We
> > > > can't just remove one of functions from gadget since it has
> been
> > > > enumerated, so the only way we can do that is to make broken
> FFS
> > > > function "zombie". It will be still visible to host but it
> will
> > > no longer implement it's functionality.
> > >
> > > now that's an explanation. Can you update commit log with some
> of
> > > this info (once we agree on how to go about fixing this) ?
> > >
> > > I'm not sure we should try to fix this. The only case where
> this
> > > could trigger is if ffs daemon crashes and dies or somebody
> sends a
> > > bogus signal to kill it.
> > >
> > > A function cannot communicate with the host if it isn't
> functional
> > > and ffs depends on its userland daemon. If daemon is crashing,
> why
> > > not print a big WARN("closed %s while connected to host\n") ?
> That
> > > seems like it's as much as we can do from the kernel. Userland
> > > should know that they can't have a buggy ffs daemon.
> >
> > It's not a problem of buggy ffs daemon. The problem is that there
> are
> > some non deterministic mechanisms in userspace like OOM killer.
> FFS
> > daemon can be written very well but if we are out of memory it
> may
> > become a victim. In this case reliability of whole gadget hurts a
> lot.
> >
> > If it's going about WARN(). I'm not enthusiastic about it.
> Userspace
> > process dies all the time, that's quite normal;) I don't think
> that it
> > is good idea to generate a warning on kernel level when some
> process
> > dies. Kernel should be resistant for such situations and know how
> to
> > deal with them (maybe user could select exact behavior, but it
> should
> > be done on kernel site)
> 
> yeah, and the way to deal with that is disconnecting from the host
> because that USB function, can't be functional anymore. I mean,
> imagine you try to e.g. unload pictures from your nice DSLR and
> that DSLR runs Linux and implements MTP or PTP using FFS. Then ptpd
> dies and you're still connected to the host so you can't know that
> something went wrong, the camera just stoped sending you data. So
> you figure: well, it must just be slow, I'll leave it here and go
> have a nap. Hours later and nothing has changed, because ptpd is
> still missing.
> 
> If you disconnect from the host, however, user knows
> instantaneously that something went wrong.

Please believe me

Re: [PATCH v6 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter

[Johan Hovold]

On Thu, Sep 25, 2014 at 07:07:32PM +0300, Octavian Purdila wrote:
> From: Laurentiu Palcu 
> 
> This patch adds support for the Diolan DLN-2 I2C master module. Due
> to hardware limitations it does not support SMBUS quick commands.
> 
> Information about the USB protocol interface can be found in the
> Programmer's Reference Manual [1], see section 6.2.2 for the I2C
> master module commands and responses.
> 
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
> 
> Signed-off-by: Laurentiu Palcu 
> Signed-off-by: Octavian Purdila 
> ---

[...]

> +#define DLN2_I2C_MAX_XFER_SIZE   256
> +#define DLN2_I2C_BUF_SIZE(DLN2_I2C_MAX_XFER_SIZE + 16)
> +
> +struct dln2_i2c {
> + struct platform_device *pdev;
> + struct i2c_adapter adapter;
> + u32 freq;
> + u32 min_freq;
> + u32 max_freq;
> + u8 port;
> + /*
> +  * Buffer to hold the packet for read or write transfers. One
> +  * is enough since we can't have multiple transfers in
> +  * parallel on the i2c adapter.
> +  */
> + void *buf;
> +};
> +
> +static int dln2_i2c_enable(struct dln2_i2c *dln2, bool enable)
> +{
> + int ret;
> + u16 cmd;
> +
> + if (enable)
> + cmd = DLN2_I2C_ENABLE;
> + else
> + cmd = DLN2_I2C_DISABLE;
> +
> + ret = dln2_transfer(dln2->pdev, cmd, &dln2->port, sizeof(dln2->port),
> + NULL, NULL);

Don't use the port member of dln2 directly here. Encode the protocol in
the function as you already do for most other messages (and did in
previous versions). You could even declare a

struct {
u8 port;
} tx;

for consistency.

> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int dln2_i2c_set_frequency(struct dln2_i2c *dln2, u32 freq)
> +{
> + int ret;
> + struct tx_data {
> + u8 port;
> + __le32 freq;
> + } __packed tx;
> +
> + tx.port = dln2->port;
> + tx.freq = cpu_to_le32(freq);
> +
> + ret = dln2_transfer(dln2->pdev, DLN2_I2C_SET_FREQUENCY, &tx, sizeof(tx),
> + NULL, NULL);
> + if (ret < 0)
> + return ret;
> +
> + dln2->freq = freq;
> +
> + return 0;
> +}
> +
> +static int dln2_i2c_get_freq(struct dln2_i2c *dln2, u16 cmd, u32 *res)
> +{
> + int ret;
> + __le32 freq;
> + unsigned len = sizeof(freq);
> +
> + ret = dln2_transfer(dln2->pdev, cmd, &dln2->port, sizeof(dln2->port),
> + &freq, &len);

Same here.

> + if (ret < 0)
> + return ret;
> + if (len < sizeof(freq))
> + return -EPROTO;
> +
> + *res = le32_to_cpu(freq);
> +
> + return 0;
> +}
> +

[...]

> +static ssize_t dln2_i2c_freq_show(struct device *dev,
> +   struct device_attribute *attr, char *buf)
> +{
> + struct dln2_i2c *dln2 = dev_get_drvdata(dev);
> +
> + return snprintf(buf, PAGE_SIZE, "%d\n", dln2->freq);
> +}
> +
> +static ssize_t dln2_i2c_freq_store(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> + struct dln2_i2c *dln2 = dev_get_drvdata(dev);
> + unsigned long freq;
> + int ret;
> +
> + if (kstrtoul(buf, 0, &freq) || freq < dln2->min_freq ||
> + freq > dln2->max_freq)
> + return -EINVAL;
> +
> + ret = dln2_i2c_enable(dln2, false);
> + if (ret < 0)
> + return ret;
> +
> + ret = dln2_i2c_set_frequency(dln2, freq);
> + if (ret < 0)
> + return ret;
> +
> + ret = dln2_i2c_enable(dln2, true);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR_RW(dln2_i2c_freq);

You forgot to add the required documentation of the attribute to
Documentation/ABI as requested.

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: gadget: f_fs: add "zombie" mode

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 06:37:26PM +0200, Krzysztof Opasiak wrote:

[snip]

> > yeah, and the way to deal with that is disconnecting from the host
> > because that USB function, can't be functional anymore. I mean,
> > imagine you try to e.g. unload pictures from your nice DSLR and
> > that DSLR runs Linux and implements MTP or PTP using FFS. Then ptpd
> > dies and you're still connected to the host so you can't know that
> > something went wrong, the camera just stoped sending you data. So
> > you figure: well, it must just be slow, I'll leave it here and go
> > have a nap. Hours later and nothing has changed, because ptpd is
> > still missing.
> > 
> > If you disconnect from the host, however, user knows
> > instantaneously that something went wrong.
> 
> Please believe me that I totally agree with you, but I also see Robert's
> point. Let's take ADB as example. Before ADB has been ported to
> FunctionFS it communicated with kernel using dev node provided by ADB
> function driver. With that infrastructure death of daemon didn't cause
> gadget unbind because kernel driver of that function was just stalling
> the endpoints. This allows user to use all other functions of this

I really mixed feelings about that. It's really counter-intuitive to
allow a non-working function to be exposed to the host.

> gadget. In current design ADB uses FunctionFS and for example if daemon
> will be killed by OOM whole gadget get's unbind and user cannot use any
> other function. Don't you think that's a bit of regression?

Why ? Why would you event want to keep the other functions working ?
Since you're running out of memory anyway, you'd just delay the
inevitable. Soon enough you won't be able to transfer files through
mtp/ptp, or enable usb tethering, or any of that.

> I see and understand yours and Roberts point of view. Personally I'm not
> too enthusiastic about using this solution but I see some rationales for
> this and use cases. Summing it up, this patch may be useful in some
> case. Let's allow end user to decide whether to use this mode or not. I
> think that a few people will find this useful.

It can't be only end user, we have to also consider USB certification.
If we go to certification with a non-working function (say adbd crashed
during init or whatever), then we won't pass certification.

I would rather cause the gadget to disconnect so any crashes on adbd can
be fixed and we pass certification, then exposing that non-working
function to the host.

OOM is another situation which we don't really have control over.
There's nothing we can do to prevent an application from malloc(1 << 30)
and cause OOM to go crazy, however arguably that application is wrong
for allocating 1GiB of memory, in any case, you get the point :-)

> > I don't think maintaining a "zombie" function is very nice. In
> > fact, the very reason for adding usb_function_activate/deactivate
> > was exactly to prevent us from ever connecting to a host with a
> > non-working function.
> 
> Here also I agree. Zombie mode should "mock" the function until first
> next enumeration or unbind. It should not be possible to bind gadget
> with function in zombie mode to UDC. Zombie mode should "pretend" only
> as long as gadget is bound and enumerated.

Not really. We shouldn't even coonect to host until adbd is running.
Now, when adbd crashes we fix adbd. If it gets killed due to OOM we
can't even say "ok, we'll buffer USB requests until adbd is restarted"
because, well, we're running out of memory.

So, OOM we can't fix. Soon enough, another daemon (mtpd, ptpd, whatever)
will be killed and another function will be left unusable.

As for adbd/mtpd/ptpd crashes, those need to fixed and kernel should not
have to deal with them in any way.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v6 4/4] gpio: add support for the Diolan DLN-2 USB GPIO driver

[Johan Hovold]

On Thu, Sep 25, 2014 at 07:07:34PM +0300, Octavian Purdila wrote:
> From: Daniel Baluta 
> 
> This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.
> 
> Information about the USB protocol interface can be found in the
> Programmer's Reference Manual [1], see section 2.9 for the GPIO
> module commands and responses.
> 
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
> 
> Signed-off-by: Daniel Baluta 
> Signed-off-by: Octavian Purdila 
> ---

Looks good. I'll provide my reviewed-by tag to the final submission.

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: [PATCHv2] phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly

[Rabin Vincent]

On Tue, Oct 07, 2014 at 12:02:51PM +0100, Oussama Ghorbel wrote:
> The USB OTG port does not work since v3.16 on omap platform.
> This is a regression introduced by the commit
> eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure
>  and remove).
> This because the call to pm_runtime_enable() function is moved after the
> call to devm_phy_create() function, which has side effect since later in
> the subsequent calls of devm_phy_create() there is a check with
> pm_runtime_enabled() to configure few things.
> 
> Signed-off-by: Oussama Ghorbel 

Tested-by: Rabin Vincent 

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

Re: [PATCH v6 1/4] mfd: add support for Diolan DLN-2 devices

[Johan Hovold]

On Mon, Oct 06, 2014 at 03:17:22PM +0300, Octavian Purdila wrote:
> On Fri, Oct 3, 2014 at 8:12 PM, Johan Hovold  wrote:
> >
> > On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
> > > This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
> > > Master Adapter DLN-2. Details about the device can be found here:
> > >
> 
> 
> 
> > > +
> > > + ret = dln2_submit_urb(dln2, dln2->rx_urb[i], GFP_KERNEL);
> > > + if (ret < 0)
> > > + return ret;
> >
> > Is it really worth having this helper only to save a couple of lines on
> > a dev_err? If you do all resubmissions on completion inline in the
> > handler, you only have three places where usb_submit_urb is called.
> >
> 
> I moved the completion in the handler as you suggested. I have kept
> the helper, would you prefer to remove it?

Moved the "completion"? I was suggesting that the URB resubmission
should be done inline the URB completion handler.

[ "Completion" may be a little ambiguous. The URB callback is called an
URB completion handler. Not be confused with the completion structures
you use to wait for responses. ]

It's fine to keep the helper as long as it's clear that the urb has been
"cached" and should not be resubmitted (inline) in the completion
handler in that case.
 
> 
> 
> > > + id = dln2->usb_dev->bus->busnum << 8 | dln2->usb_dev->devnum;
> >
> > After giving this some more thought, I think you should just
> > use PLATFORM_DEVID_AUTO as id. I have submitted a series to fix the
> > other USB MFD drivers and add a convenience helper to register
> > hotpluggable MFDs here:
> >
> 
> OK, I will use PLATFORM_DEVID_AUTO for now. If your series merges
> first and I have to resubmit mine, I will switch to using
> mfd_add_hotplug_devices.

Lee merged the helper function earlier today.

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: gadget: f_fs: add "zombie" mode

[Alan Stern]

On Tue, 7 Oct 2014, Felipe Balbi wrote:

> > Please believe me that I totally agree with you, but I also see Robert's
> > point. Let's take ADB as example. Before ADB has been ported to
> > FunctionFS it communicated with kernel using dev node provided by ADB
> > function driver. With that infrastructure death of daemon didn't cause
> > gadget unbind because kernel driver of that function was just stalling
> > the endpoints. This allows user to use all other functions of this
> 
> I really mixed feelings about that. It's really counter-intuitive to
> allow a non-working function to be exposed to the host.

...

> > Here also I agree. Zombie mode should "mock" the function until first
> > next enumeration or unbind. It should not be possible to bind gadget
> > with function in zombie mode to UDC. Zombie mode should "pretend" only
> > as long as gadget is bound and enumerated.
> 
> Not really. We shouldn't even coonect to host until adbd is running.
> Now, when adbd crashes we fix adbd. If it gets killed due to OOM we
> can't even say "ok, we'll buffer USB requests until adbd is restarted"
> because, well, we're running out of memory.
> 
> So, OOM we can't fix. Soon enough, another daemon (mtpd, ptpd, whatever)
> will be killed and another function will be left unusable.
> 
> As for adbd/mtpd/ptpd crashes, those need to fixed and kernel should not
> have to deal with them in any way.

It seems to me that we should imitate what an ordinary USB device would
do.  If part of the firmware crashes, generally you would expect none
of the endpoints associated with that function to work.  Either they
refuse to accept output from the host or they stall everything.  But
endpoints associated with other parts of the firmware might very well
continue to work okay.

Don't buffer requests.  Either allow the internal FIFOs to fill up or
else reject everything.  Any reasonable host will start getting timeout
expirations and will realize that something is wrong.

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 v6 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter

[Octavian Purdila]

On Tue, Oct 7, 2014 at 7:46 PM, Johan Hovold  wrote:
> On Thu, Sep 25, 2014 at 07:07:32PM +0300, Octavian Purdila wrote:
>> From: Laurentiu Palcu 
>>
>> This patch adds support for the Diolan DLN-2 I2C master module. Due
>> to hardware limitations it does not support SMBUS quick commands.
>>
>> Information about the USB protocol interface can be found in the
>> Programmer's Reference Manual [1], see section 6.2.2 for the I2C
>> master module commands and responses.
>>
>> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
>>
>> Signed-off-by: Laurentiu Palcu 
>> Signed-off-by: Octavian Purdila 
>> ---
>
> [...]
>
>> +#define DLN2_I2C_MAX_XFER_SIZE   256
>> +#define DLN2_I2C_BUF_SIZE(DLN2_I2C_MAX_XFER_SIZE + 16)
>> +
>> +struct dln2_i2c {
>> + struct platform_device *pdev;
>> + struct i2c_adapter adapter;
>> + u32 freq;
>> + u32 min_freq;
>> + u32 max_freq;
>> + u8 port;
>> + /*
>> +  * Buffer to hold the packet for read or write transfers. One
>> +  * is enough since we can't have multiple transfers in
>> +  * parallel on the i2c adapter.
>> +  */
>> + void *buf;
>> +};
>> +
>> +static int dln2_i2c_enable(struct dln2_i2c *dln2, bool enable)
>> +{
>> + int ret;
>> + u16 cmd;
>> +
>> + if (enable)
>> + cmd = DLN2_I2C_ENABLE;
>> + else
>> + cmd = DLN2_I2C_DISABLE;
>> +
>> + ret = dln2_transfer(dln2->pdev, cmd, &dln2->port, sizeof(dln2->port),
>> + NULL, NULL);
>
> Don't use the port member of dln2 directly here. Encode the protocol in
> the function as you already do for most other messages (and did in
> previous versions). You could even declare a
>
> struct {
> u8 port;
> } tx;
>
> for consistency.
>

Yes, I think I did this after Arnd's review on the gpio stuff where I
thought he suggested to remove the structure, when in fact he asked to
remove the __packed attribute. I will revert it back.

>> + if (ret < 0)
>> + return ret;
>> +
>> + return 0;
>> +}
>> +
>> +static int dln2_i2c_set_frequency(struct dln2_i2c *dln2, u32 freq)
>> +{
>> + int ret;
>> + struct tx_data {
>> + u8 port;
>> + __le32 freq;
>> + } __packed tx;
>> +
>> + tx.port = dln2->port;
>> + tx.freq = cpu_to_le32(freq);
>> +
>> + ret = dln2_transfer(dln2->pdev, DLN2_I2C_SET_FREQUENCY, &tx, 
>> sizeof(tx),
>> + NULL, NULL);
>> + if (ret < 0)
>> + return ret;
>> +
>> + dln2->freq = freq;
>> +
>> + return 0;
>> +}
>> +
>> +static int dln2_i2c_get_freq(struct dln2_i2c *dln2, u16 cmd, u32 *res)
>> +{
>> + int ret;
>> + __le32 freq;
>> + unsigned len = sizeof(freq);
>> +
>> + ret = dln2_transfer(dln2->pdev, cmd, &dln2->port, sizeof(dln2->port),
>> + &freq, &len);
>
> Same here.
>

OK.

>> + if (ret < 0)
>> + return ret;
>> + if (len < sizeof(freq))
>> + return -EPROTO;
>> +
>> + *res = le32_to_cpu(freq);
>> +
>> + return 0;
>> +}
>> +
>
> [...]
>
>> +static ssize_t dln2_i2c_freq_show(struct device *dev,
>> +   struct device_attribute *attr, char *buf)
>> +{
>> + struct dln2_i2c *dln2 = dev_get_drvdata(dev);
>> +
>> + return snprintf(buf, PAGE_SIZE, "%d\n", dln2->freq);
>> +}
>> +
>> +static ssize_t dln2_i2c_freq_store(struct device *dev,
>> +struct device_attribute *attr,
>> +const char *buf, size_t count)
>> +{
>> + struct dln2_i2c *dln2 = dev_get_drvdata(dev);
>> + unsigned long freq;
>> + int ret;
>> +
>> + if (kstrtoul(buf, 0, &freq) || freq < dln2->min_freq ||
>> + freq > dln2->max_freq)
>> + return -EINVAL;
>> +
>> + ret = dln2_i2c_enable(dln2, false);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = dln2_i2c_set_frequency(dln2, freq);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = dln2_i2c_enable(dln2, true);
>> +
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(dln2_i2c_freq);
>
> You forgot to add the required documentation of the attribute to
> Documentation/ABI as requested.
>

Hmm, I did add a new entry in Documentation/ABI/ at
testing/sysfs-bus-i2c-busses-dln2. It should be right at the beginning
at the patch.
--
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: gadget: f_fs: add "zombie" mode

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 01:15:32PM -0400, Alan Stern wrote:
> > > Here also I agree. Zombie mode should "mock" the function until first
> > > next enumeration or unbind. It should not be possible to bind gadget
> > > with function in zombie mode to UDC. Zombie mode should "pretend" only
> > > as long as gadget is bound and enumerated.
> > 
> > Not really. We shouldn't even coonect to host until adbd is running.
> > Now, when adbd crashes we fix adbd. If it gets killed due to OOM we
> > can't even say "ok, we'll buffer USB requests until adbd is restarted"
> > because, well, we're running out of memory.
> > 
> > So, OOM we can't fix. Soon enough, another daemon (mtpd, ptpd, whatever)
> > will be killed and another function will be left unusable.
> > 
> > As for adbd/mtpd/ptpd crashes, those need to fixed and kernel should not
> > have to deal with them in any way.
> 
> It seems to me that we should imitate what an ordinary USB device would
> do.  If part of the firmware crashes, generally you would expect none
> of the endpoints associated with that function to work.  Either they
> refuse to accept output from the host or they stall everything.  But
> endpoints associated with other parts of the firmware might very well
> continue to work okay.

dunno, I have never seen a USB device firmware crash and I don't think
anybody deliberately does anything to make sure other parts of the
device work. If it _does_ work, I'd assume it's really by chance.

> Don't buffer requests.  Either allow the internal FIFOs to fill up or
> else reject everything.  Any reasonable host will start getting timeout
> expirations and will realize that something is wrong.

Right, but if we allow this, I can already see folks abusing to connect
to the host early and only when necessary do some trickery to e.g. start
adbd (not saying Android will do this, just using it as an easy
example).

Sure, we can deactivate and only activate when files are opened but is
there any guarantee that when a process receives segfault that we will
have, from FFS point of view, any information to know that the thing
crashed ? I mean, a userland application can register its own handler
for SIGSEGV/SIGKILL, right ? And that handler could very well just call
close() on all file descriptors. Then how do we differentiate a normal
close() from a "oh-crap-I-died" close() ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v6 2/4] i2c: add support for Diolan DLN-2 USB-I2C adapter

[Johan Hovold]

On Tue, Oct 07, 2014 at 08:52:35PM +0300, Octavian Purdila wrote:
> On Tue, Oct 7, 2014 at 7:46 PM, Johan Hovold  wrote:
> > On Thu, Sep 25, 2014 at 07:07:32PM +0300, Octavian Purdila wrote:

> >> +static DEVICE_ATTR_RW(dln2_i2c_freq);
> >
> > You forgot to add the required documentation of the attribute to
> > Documentation/ABI as requested.
> >
> 
> Hmm, I did add a new entry in Documentation/ABI/ at
> testing/sysfs-bus-i2c-busses-dln2. It should be right at the beginning
> at the patch.

Ah, sorry, I missed that. I'll look at it tomorrow.

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 v6 1/4] mfd: add support for Diolan DLN-2 devices

[Octavian Purdila]

On Tue, Oct 7, 2014 at 8:10 PM, Johan Hovold  wrote:
> On Mon, Oct 06, 2014 at 03:17:22PM +0300, Octavian Purdila wrote:
>> On Fri, Oct 3, 2014 at 8:12 PM, Johan Hovold  wrote:
>> >
>> > On Thu, Sep 25, 2014 at 07:07:31PM +0300, Octavian Purdila wrote:
>> > > This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
>> > > Master Adapter DLN-2. Details about the device can be found here:
>> > >
>>
>> 
>>
>> > > +
>> > > + ret = dln2_submit_urb(dln2, dln2->rx_urb[i], GFP_KERNEL);
>> > > + if (ret < 0)
>> > > + return ret;
>> >
>> > Is it really worth having this helper only to save a couple of lines on
>> > a dev_err? If you do all resubmissions on completion inline in the
>> > handler, you only have three places where usb_submit_urb is called.
>> >
>>
>> I moved the completion in the handler as you suggested. I have kept
>> the helper, would you prefer to remove it?
>
> Moved the "completion"? I was suggesting that the URB resubmission
> should be done inline the URB completion handler.
>
> [ "Completion" may be a little ambiguous. The URB callback is called an
> URB completion handler. Not be confused with the completion structures
> you use to wait for responses. ]
>

Sorry, I meant to say resubmission instead of completion.

> It's fine to keep the helper as long as it's clear that the urb has been
> "cached" and should not be resubmitted (inline) in the completion
> handler in that case.
>

Not sure I follow you here. I kept the helper and I call it from the
completion handler, from free_rx_slot and from dln2_setup_rx_ubs.

>
>> 
>>
>> > > + id = dln2->usb_dev->bus->busnum << 8 | dln2->usb_dev->devnum;
>> >
>> > After giving this some more thought, I think you should just
>> > use PLATFORM_DEVID_AUTO as id. I have submitted a series to fix the
>> > other USB MFD drivers and add a convenience helper to register
>> > hotpluggable MFDs here:
>> >
>>
>> OK, I will use PLATFORM_DEVID_AUTO for now. If your series merges
>> first and I have to resubmit mine, I will switch to using
>> mfd_add_hotplug_devices.
>
> Lee merged the helper function earlier today.
>

Yep, noticed that, I did a rebase earlier.
--
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: gadget: f_fs: add "zombie" mode

[Alan Stern]

On Tue, 7 Oct 2014, Felipe Balbi wrote:

> > It seems to me that we should imitate what an ordinary USB device would
> > do.  If part of the firmware crashes, generally you would expect none
> > of the endpoints associated with that function to work.  Either they
> > refuse to accept output from the host or they stall everything.  But
> > endpoints associated with other parts of the firmware might very well
> > continue to work okay.
> 
> dunno, I have never seen a USB device firmware crash and I don't think
> anybody deliberately does anything to make sure other parts of the
> device work. If it _does_ work, I'd assume it's really by chance.

I've seen it happen lots of times, but only on single-function devices.  
When it somes to multi-function devices, who knows?

Still, with the single-function devices, firmware crashes generally 
don't lead to disconnections.  Sometimes they do, but usually they 
don't.

> > Don't buffer requests.  Either allow the internal FIFOs to fill up or
> > else reject everything.  Any reasonable host will start getting timeout
> > expirations and will realize that something is wrong.
> 
> Right, but if we allow this, I can already see folks abusing to connect
> to the host early and only when necessary do some trickery to e.g. start
> adbd (not saying Android will do this, just using it as an easy
> example).

We can still keep the pullup turned off until all the functions are
ready.  That's a part of normal behavior -- unlike what happens when a
userspace component crashes or is killed.

> Sure, we can deactivate and only activate when files are opened but is
> there any guarantee that when a process receives segfault that we will
> have, from FFS point of view, any information to know that the thing
> crashed ? I mean, a userland application can register its own handler
> for SIGSEGV/SIGKILL, right ? And that handler could very well just call
> close() on all file descriptors. Then how do we differentiate a normal
> close() from a "oh-crap-I-died" close() ?

We can't, so why worry about it?

If a file handle was closed for normal reasons then userspace probably 
in the middle of shutting down the gadget anyway.  If not then the 
user will get what they deserve.

If the file handle was closed for abnormal reasons, we can behave like 
crashed firmware.  Which means, in the end, doing the same thing as in 
the normal-reason case -- i.e., do nothing.  In particular, don't 
disconnect.

If you want to allow for the possibility of orderly shutdown (and maybe 
even possible restart) of a userspace handler, the function library 
should first tell the kernel explicitly to disconnect.  Then function 
components can be changed around completely, and when everything is 
ready, userspace can tell the kernel to connect again.

Alan Stern

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

Re: [PATCH] usb: gadget: f_fs: add "zombie" mode

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 02:42:33PM -0400, Alan Stern wrote:
> > > It seems to me that we should imitate what an ordinary USB device would
> > > do.  If part of the firmware crashes, generally you would expect none
> > > of the endpoints associated with that function to work.  Either they
> > > refuse to accept output from the host or they stall everything.  But
> > > endpoints associated with other parts of the firmware might very well
> > > continue to work okay.
> > 
> > dunno, I have never seen a USB device firmware crash and I don't think
> > anybody deliberately does anything to make sure other parts of the
> > device work. If it _does_ work, I'd assume it's really by chance.
> 
> I've seen it happen lots of times, but only on single-function devices.  
> When it somes to multi-function devices, who knows?
> 
> Still, with the single-function devices, firmware crashes generally 
> don't lead to disconnections.  Sometimes they do, but usually they 
> don't.
> 
> > > Don't buffer requests.  Either allow the internal FIFOs to fill up or
> > > else reject everything.  Any reasonable host will start getting timeout
> > > expirations and will realize that something is wrong.
> > 
> > Right, but if we allow this, I can already see folks abusing to connect
> > to the host early and only when necessary do some trickery to e.g. start
> > adbd (not saying Android will do this, just using it as an easy
> > example).
> 
> We can still keep the pullup turned off until all the functions are
> ready.  That's a part of normal behavior -- unlike what happens when a
> userspace component crashes or is killed.
> 
> > Sure, we can deactivate and only activate when files are opened but is
> > there any guarantee that when a process receives segfault that we will
> > have, from FFS point of view, any information to know that the thing
> > crashed ? I mean, a userland application can register its own handler
> > for SIGSEGV/SIGKILL, right ? And that handler could very well just call
> > close() on all file descriptors. Then how do we differentiate a normal
> > close() from a "oh-crap-I-died" close() ?
> 
> We can't, so why worry about it?

because on close(), I want to disconnect data pullups :-) Everything has
been tore down and there's nothing else to do.

> If a file handle was closed for normal reasons then userspace probably 
> in the middle of shutting down the gadget anyway.  If not then the 
> user will get what they deserve.

yeah, I think the same way about a crashing functionfs daemon :-)

> If the file handle was closed for abnormal reasons, we can behave like 
> crashed firmware.  Which means, in the end, doing the same thing as in 
> the normal-reason case -- i.e., do nothing.  In particular, don't 
> disconnect.
> 
> If you want to allow for the possibility of orderly shutdown (and maybe 
> even possible restart) of a userspace handler, the function library 
> should first tell the kernel explicitly to disconnect.  Then function 
> components can be changed around completely, and when everything is 
> ready, userspace can tell the kernel to connect again.

I still feel iffy about it, but I must say I understand where you're
coming from. It's weird to force a disconnect, sure. I guess we could
accept this with a new option (just not 'zombie', perhaps no_disconnect
:-) but only if we still have the same "delay pullups until daemon is
running" requirement.

/me hides

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 2/2] arm: shmobile: lager: enable HS-USB

[Sergei Shtylyov]

Hello.

On 10/07/2014 04:19 PM, Yoshihiro Shimoda wrote:


Since this board doesn't have USB ID pin, we assumes the GP5_18 (USB0_PWEN)
is an ID pin because the gpio is high when the SW5 is Pin 3 side.



Signed-off-by: Yoshihiro Shimoda 
---
   arch/arm/boot/dts/r8a7790-lager.dts |5 +
   1 file changed, 5 insertions(+)



diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 719979e..011254a 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -446,3 +446,8 @@
   };
   };
   };
+
+&hsusb {
+status = "okay";
+renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_HIGH>;
+};



As I said before, this is not enough. We need pinctrl-related props. Same 
is true for other boards.



Thank you very much for the point again.
Finally I understood what you said before.
I will start studying the pinctrl world.


   Looks like it will be quicker if I post v3 of your patches.

   Unfortunately, there'll be pinctrl-related error messages in the log if 
the internal PCI and HS-USB drivers are enabled together but everything should 
still work.



Best regards,
Yoshihiro Shimoda


WBR, Sergei

--
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: gadget: f_fs: add "zombie" mode

[Alan Stern]

On Tue, 7 Oct 2014, Felipe Balbi wrote:

> > If the file handle was closed for abnormal reasons, we can behave like 
> > crashed firmware.  Which means, in the end, doing the same thing as in 
> > the normal-reason case -- i.e., do nothing.  In particular, don't 
> > disconnect.
> > 
> > If you want to allow for the possibility of orderly shutdown (and maybe 
> > even possible restart) of a userspace handler, the function library 
> > should first tell the kernel explicitly to disconnect.  Then function 
> > components can be changed around completely, and when everything is 
> > ready, userspace can tell the kernel to connect again.
> 
> I still feel iffy about it, but I must say I understand where you're
> coming from. It's weird to force a disconnect, sure. I guess we could

Well, it's not all that weird.  Devices disconnect automatically when
they receive a firmware update, so that they can reconnect with new
descriptors.  Much the same thing should happen if the user wants to
replace one function driver with a different one.

I guess the real idea is to give the user a choice of disconnecting or 
not.  Don't always force the whole device to disconnect when one of the 
function drivers goes away.

> accept this with a new option (just not 'zombie', perhaps no_disconnect
> :-) but only if we still have the same "delay pullups until daemon is
> running" requirement.

Seems reasonable to me.  Or something that can be adjusted while the 
library is running, as opposed to setting an option once when the 
library starts.

> /me hides

I'm out of further ideas.  What do the library designers think?

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

fat32-vfat differences?

[Gene Heskett]

I have some update firmware on a vfat key.  While that system reports the 
key as being plugged in when I do the insertion, when I ask its update 
facility to do an update, the sandisks led blinks a time or 2 & reports it 
can't find the update.

I tried to mountr it as fat32, but linux says it has no knowledge of 
fat32, yet the target system is expecting fat32 only.

Is this something I can fix with a fresh usb key?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
--
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: gadget: f_fs: add "zombie" mode

[Michal Nazarewicz]

> On Tue, 7 Oct 2014, Felipe Balbi wrote:
>> Right, but if we allow this, I can already see folks abusing to
>> connect to the host early and only when necessary do some trickery to
>> e.g. start adbd (not saying Android will do this, just using it as an
>> easy example).

I don't really see that happening.  For the gadget to start all
descriptors need to be known.  Functionfs  will know the descriptors
only once the user space daemon provides them.  Therefore, with the
current features (or even with addition of Robert's feature) there is no
way to let the gadget start without having the daemon running.

On Tue, Oct 07 2014, Alan Stern  wrote:
> We can still keep the pullup turned off until all the functions are
> ready.  That's a part of normal behavior -- unlike what happens when a
> userspace component crashes or is killed.

>> Then how do we differentiate a normal close() from a "oh-crap-I-died"
>> close() ?

> We can't, so why worry about it?

We actually might be able to distinguish those cases with another ioctl
which daemon must issue on the ep0 prior to closing it.  I'm not saying
that we should implement that though.

> If a file handle was closed for normal reasons then userspace probably 
> in the middle of shutting down the gadget anyway.  If not then the 
> user will get what they deserve.
>
> If the file handle was closed for abnormal reasons, we can behave like 
> crashed firmware.  Which means, in the end, doing the same thing as in 
> the normal-reason case -- i.e., do nothing.  In particular, don't 
> disconnect.
>
> If you want to allow for the possibility of orderly shutdown (and maybe 
> even possible restart) of a userspace handler, the function library 
> should first tell the kernel explicitly to disconnect.  Then function 
> components can be changed around completely, and when everything is 
> ready, userspace can tell the kernel to connect again.

I'm wondering if it would be possible to support user-space daemon
restarts with O_APPEND flag.  This is probably looking too far to the
future though.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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/2] Add HS-USB device tree support for R8A7790/Lager board

[Sergei Shtylyov]

Hello.

   Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20141007-v3.17' tag. Here we add the HS-USB device tree support
on the R8A7790/Lager reference board. The patchset requires the USB PHY
driver (already merged by Kishon and Greg) and the generic PHY support patches
for the HS-USB driver posted by Yoshihiro Shimoda in order to work...

[1/2] ARM: shmobile: r8a7790: add HS-USB device node
[2/2] ARM: shmobile: lager: enable HS-USB

WBR, Sergei

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

[PATCH v3 1/2] ARM: shmobile: r8a7790: add HS-USB device node

[Sergei Shtylyov]

From: Yoshihiro Shimoda 

Define the R8A7790 generic part of the HS-USB device node. It is up to the board
file to enable the device.

Signed-off-by: Yoshihiro Shimoda 
[Sergei: fixed summary, added changelog]
Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- uppercased "arm" in the summary;
- added changelog.

 arch/arm/boot/dts/r8a7790.dtsi |   11 +++
 1 file changed, 11 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7790.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7790.dtsi
+++ renesas/arch/arm/boot/dts/r8a7790.dtsi
@@ -600,6 +600,17 @@
status = "disabled";
};
 
+   hsusb: usb@e659 {
+   compatible = "renesas,usbhs-r8a7790";
+   reg = <0 0xe659 0 0x100>;
+   interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
+   renesas,buswait = <4>;
+   phys = <&usb0 1>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
usbphy: usb-phy@e6590100 {
compatible = "renesas,usb-phy-r8a7790";
reg = <0 0xe6590100 0 0x100>;

--
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/2] ARM: shmobile: lager: enable HS-USB

[Sergei Shtylyov]

From: Yoshihiro Shimoda 

Enable HS-USB device for the Lager board, defining the GPIO that the driver
should check when probing. Since this board doesn't have the OTG ID pin, we
assume that GP5_18 (USB0_PWEN) is an ID pin because it is 1 when the SW5 is
in position 2-3 (meaning USB function) and 0 in other positions.

Note that there will be pinctrl-related error messages if both internal PCI
and HS-USB drivers are enabled but they should be just ignored.

Signed-off-by: Yoshihiro Shimoda 
[Sergei: added pin function/group and prop, moved device node, fixed summary,
supplemented changelog]
Signed-off-by: Sergei Shtylyov 

---
Changes in version 3:
- added pin function/group and the pinctrl-related prop;
- moved the HS-USB node to precede the USB PHY node;
- uppercased "arm" in the summary;
- supplemented changelog.

 arch/arm/boot/dts/r8a7790-lager.dts |   12 
 1 file changed, 12 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7790-lager.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7790-lager.dts
+++ renesas/arch/arm/boot/dts/r8a7790-lager.dts
@@ -226,6 +226,11 @@
renesas,function = "usb0";
};
 
+   hsusb_pins: usb0 {
+   renesas,groups = "usb0_ovc_vbus";
+   renesas,function = "usb0";
+   };
+
usb1_pins: usb1 {
renesas,groups = "usb1";
renesas,function = "usb1";
@@ -425,6 +430,13 @@
pinctrl-names = "default";
 };
 
+&hsusb {
+   status = "okay";
+   pinctrl-0 = <&hsusb_pins>;
+   pinctrl-names = "default";
+   renesas,enable-gpio = <&gpio5 18 GPIO_ACTIVE_HIGH>;
+};
+
 &usbphy {
status = "okay";
 };

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

Re: usb_stor_Bulk_max_lun() and scsi_host max_lun field mismatch

[Mark Knibbs]

On Mon, 6 Oct 2014 15:26:41 -0400 (EDT)
Alan Stern  wrote:

> On Mon, 6 Oct 2014, Mark Knibbs wrote:
> 
> > The max_lun field in the scsi_host/us_data structure is the maximum
> > possible LUN value *plus 1*.
> 
> You are confusing two different fields.  The max_lun field in scsi_host 
> is different from the max_lun field in us_data.
> 
> The field in us_data is the maximum possible LUN value, _not_ plus 1.  
> See this code in usb_stor_control_thread():
> 
>   else if (us->srb->device->lun > us->max_lun) {
>   usb_stor_dbg(us, "Bad LUN (%d:%llu)\n",
>us->srb->device->id,
>us->srb->device->lun);
>   us->srb->result = DID_BAD_TARGET << 16;
>   }
> 
> >  It's initially set to 8 by scsi_host_alloc()
> > which is called by usb_stor_probe1().
> 
> scsi_host_alloc() doesn't touch anything in the us_data structure.

Whoops, thanks very much for clearing that up. I got confused with the
identical member names. (While looking into why multiple LUNs don't work
with SCM USB-SCSI converters; I hope to post a patch for that shortly.)


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

Re: [PATCH v3 2/2] ARM: shmobile: lager: enable HS-USB

[Sergei Shtylyov]

On 10/08/2014 12:26 AM, Sergei Shtylyov wrote:


From: Yoshihiro Shimoda 



Enable HS-USB device for the Lager board, defining the GPIO that the driver
should check when probing. Since this board doesn't have the OTG ID pin, we
assume that GP5_18 (USB0_PWEN) is an ID pin because it is 1 when the SW5 is
in position 2-3 (meaning USB function) and 0 in other positions.



Note that there will be pinctrl-related error messages if both internal PCI
and HS-USB drivers are enabled but they should be just ignored.



Signed-off-by: Yoshihiro Shimoda 
[Sergei: added pin function/group and prop, moved device node, fixed summary,
supplemented changelog]
Signed-off-by: Sergei Shtylyov 



---
Changes in version 3:
- added pin function/group and the pinctrl-related prop;
- moved the HS-USB node to precede the USB PHY node;
- uppercased "arm" in the summary;
- supplemented changelog.



  arch/arm/boot/dts/r8a7790-lager.dts |   12 
  1 file changed, 12 insertions(+)



Index: renesas/arch/arm/boot/dts/r8a7790-lager.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7790-lager.dts
+++ renesas/arch/arm/boot/dts/r8a7790-lager.dts
@@ -226,6 +226,11 @@
renesas,function = "usb0";
};

+   hsusb_pins: usb0 {


   Oops, forgot to rename the node. :-/ Although dtc didn't protest.

WBR, Sergei

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

[GIT PULL] USB driver patches for 3.18-rc1

[Greg KH]

The following changes since commit 452b6361c4d9baf6940adb7b1316e0f386c39799:

  Merge tag 'rdma-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband (2014-09-23 
16:47:34 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-3.18-rc1

for you to fetch changes up to 4ed9a3d48406cad83d38764ee659de25851c:

  USB: host: st: fix typo 'CONFIG_USB_EHCI_HCD_ST' (2014-10-03 14:50:10 -0700)


USB patches for 3.18-rc1

Here's the big USB patchset for 3.18-rc1.  Also in here is the PHY tree,
as it seems to fit well with the USB tree for various reasons...

Anyway, lots of little changes in here, all over the place, full details
in the changelog below.

All have been in the linux-next tree for a while with no issues.

Signed-off-by: Greg Kroah-Hartman 


Al Cooper (1):
  usb: xhci_suspend is not stopping the root hub timer for the shared HCD

Amit Virdi (3):
  usb: gadget: zero: Add support for interrupt EP
  usbtest: Add interrupt EP testcases
  usb: gadget: zero: Fix warning generated by kbuild

Andreas Bomholtz (1):
  USB: cp210x: add support for Seluxit USB dongle

Andreas Larsson (2):
  usb: gadget: udc_core: Use right kobj when calling sysfs_notify
  usb: gadget: gr_udc: Add bounce buffer to handle odd sized OUT requests

Andrew Bresticker (4):
  xhci: Introduce xhci_init_driver()
  xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold
  xhci: Export symbols used by host-controller drivers
  xhci: Allow xHCI drivers to be built as separate modules

Andrzej Pietrasiewicz (24):
  usb: gadget: audio: Use container_of to free audio_dev
  usb: gadget: f_uac2: convert to new function interface with backward 
compatibility
  usb: gadget: audio: convert to new interface of f_uac2
  usb: gadget: f_uac2: remove compatibility layer
  usb: gadget: f_uac2: use usb_gstrings_attach
  usb: gadget: f_uac2: use defined constants as defaults
  usb: gadget: f_uac2: add configfs support
  usb: gadget: f_uac1: add function strings
  usb: gadget: f_uac1: prepare for separate compilation
  usb: gadget: f_uac1: convert to new function interface with backward 
compatibility
  usb: gadget: audio: convert to new interface of f_uac1
  usb: gadget: f_uac1: remove compatibility layer
  usb: gadget: f_uac1: use usb_gstrings_attach
  usb: gadget: f_uac1: use defined constants as defaults
  usb: gadget: f_uac1: add configfs support
  usb: gadget: f_uvc: fix potential memory leak
  usb: gadget: uvc: move module parameters from f_uvc
  usb: gadget: uvc: rename functions to avoid conflicts with host uvc
  usb: gadget: uvc: separately compile some components of f_uvc
  usb: gadget: f_uvc: convert f_uvc to new function interface
  usb: gadget: webcam: convert webcam to new interface of f_uvc
  usb: gadget: f_uvc: remove compatibility layer
  usb: gadget: f_uvc: use usb_gstrings_attach
  usb: dwc2/gadget: Fix comment text

Andy Shevchenko (1):
  USB: storage: use %*ph specifier to dump small buffers

Antoine Tenart (1):
  usb: rename phy to usb_phy in HCD

Arjun Sreedharan (1):
  usb: misc: yurex: remove useless casting of private_data

Arnd Bergmann (2):
  USB: host: st: fix ehci/ohci driver selection
  usb: gadget: uvc: fix up uvcg_v4l2_get_unmapped_area typo

Bartlomiej Zolnierkiewicz (4):
  usb: phy: samsung: remove old USB 2.0 PHY driver
  usb: phy: samsung: remove old USB 3.0 PHY driver
  usb: phy: samsung: remove old common USB PHY code
  usb: renesas_usbhs: fix driver dependencies

Chen Gang (1):
  drivers/usb/host/ehci-xilinx-of.c: Include "linux/of_irq.h" to avoid 
compiling error

Dan Carpenter (1):
  usb: gadget: f_fs: signedness bug in __ffs_func_bind_do_descs()

Daniel Mack (6):
  usb: gadget: f_uac2: restructure some code in afunc_set_alt()
  usb: gadget: f_uac2: add short-hand for 'dev'
  usb: gadget: f_uac2: introduce agdev_to_uac2_opts
  usb: gadget: f_uac2: handle partial dma area wrap
  usb: gadget: f_uac2: send reasonably sized packets
  usb: musb: cppi41: tweak hrtimer values

Dinh Nguyen (2):
  usb: dwc2: Update Kconfig to support dual-role
  usb: dwc2: move "samsung,s3c6400-hsotg" into common platform

Doug Anderson (1):
  usb: dwc2: Read GNPTXFSIZ when in forced HOST mode.

Felipe Balbi (10):
  usb: phy: msm: mark msm_otg_mode_fops static
  usb: dwc3: move all string helper functions to debug.h
  usb: dwc3: debug: add dwc3_gadget_event_type_string
  usb: dwc3: gadget: cmd argument should always be unsigned
  usb: dwc3: add tracepoints to aid debugging
  Merge tag 'v3.17-rc4' into next
  Merge tag 'v3.17-rc5' into next
  usb: musb: dsps: kill OTG timer o

[PATCH] usb: ffs: fix regression when quirk_ep_out_aligned_size flag is set

[David Cohen]

The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the
quirk implemented to align buffer size to maxpacketsize on out endpoint.
As result, functionfs does not work on Intel platforms using dwc3 driver
(i.e. Bay Trail and Merrifield). This patch fixes the issue.

This code is based on a previous Qiuxu's patch.

Signed-off-by: David Cohen 
Signed-off-by: Qiuxu Zhuo 
---

Hi,

Since this is a feature that worked in past, this patch is meant for 3.17
kernel. If/when we pass review and accept it on 3.17, I'll send a version for
stable 3.16 kernel too. It is not required for 3.14, since the regression came
later.

Br, David Cohen

---
 drivers/usb/gadget/function/f_fs.c | 21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 0dc3552d1360..6e2b8063b170 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -648,15 +648,26 @@ static void ffs_user_copy_worker(struct work_struct *work)
if (io_data->read && ret > 0) {
int i;
size_t pos = 0;
+
+   /*
+* Since req->length may be bigger than io_data->len (after
+* being rounded up to maxpacketsize), we may end up with more
+* data then user space has space for.
+*/
+   ret = min_t(int, ret, io_data->len);
+
use_mm(io_data->mm);
for (i = 0; i < io_data->nr_segs; i++) {
+   size_t len = min_t(size_t, ret - pos,
+   io_data->iovec[i].iov_len);
+   if (!len)
+   break;
if (unlikely(copy_to_user(io_data->iovec[i].iov_base,
-&io_data->buf[pos],
-io_data->iovec[i].iov_len))) {
+&io_data->buf[pos], len))) {
ret = -EFAULT;
break;
}
-   pos += io_data->iovec[i].iov_len;
+   pos += len;
}
unuse_mm(io_data->mm);
}
@@ -794,7 +805,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct 
ffs_io_data *io_data)
goto error_lock;
 
req->buf  = data;
-   req->length   = io_data->len;
+   req->length   = data_len;
 
io_data->buf = data;
io_data->ep = ep->ep;
@@ -816,7 +827,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct 
ffs_io_data *io_data)
 
req = ep->req;
req->buf  = data;
-   req->length   = io_data->len;
+   req->length   = data_len;
 
req->context  = &done;
req->complete = ffs_epfile_io_complete;
-- 
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: ffs: fix regression when quirk_ep_out_aligned_size flag is set

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 05:18:06PM -0700, David Cohen wrote:
> The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the

did that commit non-aio or is only aio broken ?

> quirk implemented to align buffer size to maxpacketsize on out endpoint.
> As result, functionfs does not work on Intel platforms using dwc3 driver
> (i.e. Bay Trail and Merrifield). This patch fixes the issue.

and Braswell.

> This code is based on a previous Qiuxu's patch.

How have you tested this ? Do you have a test-case to share ? Then I can
add it to my tests which I have been running on my platforms too (they
include USB20CV and USB30CV where applicable - quite a few fixes coming
soon).

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: ffs: fix regression when quirk_ep_out_aligned_size flag is set

[Felipe Balbi]

Hi again,

On Tue, Oct 07, 2014 at 05:18:06PM -0700, David Cohen wrote:
> The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the
> quirk implemented to align buffer size to maxpacketsize on out endpoint.
> As result, functionfs does not work on Intel platforms using dwc3 driver
> (i.e. Bay Trail and Merrifield). This patch fixes the issue.
> 
> This code is based on a previous Qiuxu's patch.
> 

btw, please resend and add below right here:

Fixes: 2e4c7553cd (usb: gadget: f_fs: add aio support)
Cc:  # v3.16+

> Signed-off-by: David Cohen 
> Signed-off-by: Qiuxu Zhuo 

-- 
balbi


signature.asc
Description: Digital signature

Re: fat32-vfat differences?

[Peter Chen]

On Tue, Oct 07, 2014 at 03:54:03PM -0400, Gene Heskett wrote:
> I have some update firmware on a vfat key.  While that system reports the 
> key as being plugged in when I do the insertion, when I ask its update 
> facility to do an update, the sandisks led blinks a time or 2 & reports it 
> can't find the update.
> 
> I tried to mountr it as fat32, but linux says it has no knowledge of 
> fat32, yet the target system is expecting fat32 only.
> 
> Is this something I can fix with a fresh usb key?

Does your system support vfat filesystem?
Does your usb drive be supported at Windows?

Peter
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
> --
> 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

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

Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

[Vivek Gautam]

On Tue, Oct 7, 2014 at 7:41 PM, Felipe Balbi  wrote:
> On Tue, Oct 07, 2014 at 03:49:33PM +0530, Vivek Gautam wrote:
>> Exynos7 also has a separate special gate clock going to the IP
>> apart from the usual AHB clock. So add support for the same.
>>
>> Signed-off-by: Vivek Gautam 
>
> I'll take this one once -rc1 is tagged. The others have no direct
> dependency on this so I'll leave them to Kishon.

Thanks Felipe !



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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/2] ARM: shmobile: lager: enable HS-USB

[Yoshihiro Shimoda]

Hello.

(2014/10/08 5:26), Sergei Shtylyov wrote:
> From: Yoshihiro Shimoda 
> 
> Enable HS-USB device for the Lager board, defining the GPIO that the driver
> should check when probing. Since this board doesn't have the OTG ID pin, we
> assume that GP5_18 (USB0_PWEN) is an ID pin because it is 1 when the SW5 is
> in position 2-3 (meaning USB function) and 0 in other positions.
> 
< snip >
> Index: renesas/arch/arm/boot/dts/r8a7790-lager.dts
> ===
> --- renesas.orig/arch/arm/boot/dts/r8a7790-lager.dts
> +++ renesas/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -226,6 +226,11 @@
>   renesas,function = "usb0";
>   };
>  
> + hsusb_pins: usb0 {
> + renesas,groups = "usb0_ovc_vbus";

Thank you for the v3 patch.
I tested this, and kernel log said "GP_5_19 already requested".
However, the hsusb on lager uses GP_5_18. Is this correct behavior?

sh-pfc e606.pfc: pin GP_5_19 already requested by ee09.pci; cannot 
claim for e659.usb
sh-pfc e606.pfc: pin-179 (e659.usb) status -22
sh-pfc e606.pfc: could not request pin 179 (GP_5_19) from group 
usb0_ovc_vbus  on device sh-pfc

Best regards,
Yoshihiro Shimoda
--
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] usb: renesas_usbhs: add support for generic PHY

[Kishon Vijay Abraham I]

Hi,

On Tuesday 07 October 2014 07:39 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Oct 07, 2014 at 12:43:06PM +0900, Yoshihiro Shimoda wrote:
>> This patch adds support for the generic PHY. The generic PHY will be
>> used in multiplatform environment.
>>
>> Signed-off-by: Yoshihiro Shimoda 
> 
> Kishon, does this look ok to you ?

yes.. looks alright to me.

Acked-by: Kishon Vijay Abraham I 
> 
>> ---
>>  drivers/usb/renesas_usbhs/common.h |1 +
>>  drivers/usb/renesas_usbhs/rcar2.c  |   29 +
>>  2 files changed, 30 insertions(+)
>>
>> diff --git a/drivers/usb/renesas_usbhs/common.h 
>> b/drivers/usb/renesas_usbhs/common.h
>> index e0d53c5..c45667f 100644
>> --- a/drivers/usb/renesas_usbhs/common.h
>> +++ b/drivers/usb/renesas_usbhs/common.h
>> @@ -270,6 +270,7 @@ struct usbhs_priv {
>>  struct usbhs_fifo_info fifo_info;
>>  
>>  struct usb_phy *usb_phy;
>> +struct phy *phy;
>>  };
>>  
>>  /*
>> diff --git a/drivers/usb/renesas_usbhs/rcar2.c 
>> b/drivers/usb/renesas_usbhs/rcar2.c
>> index 485b889..8fc15c0 100644
>> --- a/drivers/usb/renesas_usbhs/rcar2.c
>> +++ b/drivers/usb/renesas_usbhs/rcar2.c
>> @@ -12,6 +12,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include "common.h"
>> @@ -21,6 +22,16 @@ static int usbhs_rcar2_hardware_init(struct 
>> platform_device *pdev)
>>  {
>>  struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
>>  
>> +if (IS_ENABLED(CONFIG_GENERIC_PHY)) {
>> +struct phy *phy = phy_get(&pdev->dev, "usb");
>> +
>> +if (IS_ERR(phy))
>> +return PTR_ERR(phy);
>> +
>> +priv->phy = phy;
>> +return 0;
>> +}
>> +
>>  if (IS_ENABLED(CONFIG_USB_PHY)) {
>>  struct usb_phy *usb_phy = usb_get_phy_dev(&pdev->dev, 0);
>>  
>> @@ -38,6 +49,11 @@ static int usbhs_rcar2_hardware_exit(struct 
>> platform_device *pdev)
>>  {
>>  struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
>>  
>> +if (priv->phy) {
>> +phy_put(priv->phy);
>> +priv->phy = NULL;
>> +}
>> +
>>  if (priv->usb_phy) {
>>  usb_put_phy(priv->usb_phy);
>>  priv->usb_phy = NULL;
>> @@ -52,6 +68,19 @@ static int usbhs_rcar2_power_ctrl(struct platform_device 
>> *pdev,
>>  struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
>>  int retval = -ENODEV;
>>  
>> +if (priv->phy) {
>> +if (enable) {
>> +retval = phy_init(priv->phy);
>> +
>> +if (!retval)
>> +retval = phy_power_on(priv->phy);
>> +} else {
>> +phy_power_off(priv->phy);
>> +phy_exit(priv->phy);
>> +retval = 0;
>> +}
>> +}
>> +
>>  if (priv->usb_phy) {
>>  if (enable) {
>>  retval = usb_phy_init(priv->usb_phy);
>> -- 
>> 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 1/1] usb: core: notify disconnection when core detects disconnect

[Peter Chen]

It is safe to call notify disconnect when the usb core
thinks the device is disconnected.

This commit also fixes one bug found at below situation:
we have not enabled usb wakeup, we do system suspend when
there is an usb device at the port, after suspend, we plug out
the usb device, then plug in device again. At that time,
the nofity disconnect was not called at current code, as
the controller doesn't know the usb device was disconnected
during the suspend, but USB core knows the port has changed
during that periods.

So to fix this problem, and let the usb core call notify disconnect.

Cc: sta...@vger.kernel.org
Signed-off-by: Peter Chen 
---
 drivers/usb/core/hub.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index d481c99..f3d1671 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4617,8 +4617,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
 
/* Disconnect any existing devices under this port */
if (udev) {
-   if (hcd->phy && !hdev->parent &&
-   !(portstatus & USB_PORT_STAT_CONNECTION))
+   if (hcd->phy && !hdev->parent)
usb_phy_notify_disconnect(hcd->phy, udev->speed);
usb_disconnect(&port_dev->child);
}
-- 
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] ARM: shmobile: r8a7791: add USB3.0 device node

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7791.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index d343099..cdf4b46 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1146,6 +1146,16 @@
status = "disabled";
};
 
+   xhci: usb@ee00 {
+   compatible = "renesas,xhci-r8a7791";
+   reg = <0 0xee00 0 0xc00>;
+   interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp3_clks R8A7791_CLK_SSUSB>;
+   phys = <&usb2 1>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
pci0: pci@ee09 {
compatible = "renesas,pci-r8a7791";
device_type = "pci";
-- 
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 2/2] ARM: shmobile: lager: enable USB3.0

[Yoshihiro Shimoda]

Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0
driver cannot use the phy driver when the EHCI/OHCI ch2 already used it:

phy phy-e6590100.usb-phy.3: phy init failed --> -16
xhci-hcd: probe of ee00.usb failed with error -16

If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind
the USB3.0 driver as the following:

  echo :02:02.0 > /sys/bus/pci/drivers/ehci-pci/unbind
  echo :02:01.0 > /sys/bus/pci/drivers/ohci-pci/unbind
  echo ee00.usb > /sys/bus/platform/drivers/xhci-hcd/bind

Note that there will be pinctrl-related error messages if both
internal PCI and USB3.0 are enabled but they should be just ignored:

sh-pfc e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot 
claim for ee00.usb
sh-pfc e606.pfc: pin-182 (ee00.usb) status -22
ata1: SATA link down (SStatus 0 SControl 300)
sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2  on 
device sh-pfc

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7790-lager.dts |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index 719979e..3f51be1 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -419,6 +419,12 @@
pinctrl-names = "default";
 };
 
+&xhci {
+   status = "okay";
+   pinctrl-0 = <&usb2_pins>;
+   pinctrl-names = "default";
+};
+
 &pci2 {
status = "okay";
pinctrl-0 = <&usb2_pins>;
-- 
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 0/2] ARM: shmobile: add USB3.0 device node on r8a7790

[Yoshihiro Shimoda]

 This series is based on Simon's renesas.git branch and
renesas-devel-20141007-v3.17 tag. If we use the generic phy
driver for R-Car Gen2 (drivers/phy/phy-rcar-gen2.c), we can use
the USB3.0 on lager.

Yoshihiro Shimoda (2):
  ARM: shmobile: r8a7790: add USB3.0 device node
  ARM: shmobile: lager: enable USB3.0

 arch/arm/boot/dts/r8a7790-lager.dts |6 ++
 arch/arm/boot/dts/r8a7790.dtsi  |   10 ++
 2 files changed, 16 insertions(+)

-- 
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] ARM: shmobile: add USB3.0 device node on r8a7791

[Yoshihiro Shimoda]

 This patch is based on Simon's renesas.git branch and
renesas-devel-20141007-v3.17 tag.
Since koelsch and henninger doesn't have a USB3.0 connector,
I submit a patch for r8a7791.dtsi only.

Yoshihiro Shimoda (1):
  ARM: shmobile: r8a7791: add USB3.0 device node

 arch/arm/boot/dts/r8a7791.dtsi |   10 ++
 1 file changed, 10 insertions(+)

-- 
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 1/2] ARM: shmobile: r8a7790: add USB3.0 device node

[Yoshihiro Shimoda]

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm/boot/dts/r8a7790.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 2380fd5..16f8646 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1140,6 +1140,16 @@
status = "disabled";
};
 
+   xhci: usb@ee00 {
+   compatible = "renesas,xhci-r8a7790";
+   reg = <0 0xee00 0 0xc00>;
+   interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&mstp3_clks R8A7790_CLK_SSUSB>;
+   phys = <&usb2 1>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
pci0: pci@ee09 {
compatible = "renesas,pci-r8a7790";
device_type = "pci";
-- 
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] ARM: shmobile: add USB3.0 device node on r8a7791

[Yoshihiro Shimoda]

(2014/10/08 15:24), Yoshihiro Shimoda wrote:
>  This patch is based on Simon's renesas.git branch and
> renesas-devel-20141007-v3.17 tag.
> Since koelsch and henninger doesn't have a USB3.0 connector,
> I submit a patch for r8a7791.dtsi only.
> 
> Yoshihiro Shimoda (1):
>   ARM: shmobile: r8a7791: add USB3.0 device node
> 
>  arch/arm/boot/dts/r8a7791.dtsi |   10 ++
>  1 file changed, 10 insertions(+)
> 

Oops, this patch means [PATCH 0/1]...
Also the "[PATCH] ARM: shmobile: r8a7791: add USB3.0 device node" email means
[PATCH 1/1].

Best regards,
Yoshihiro Shimoda
--
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