date:20140703

Hi all,

Here's a second version of the probe order issue series. This time I've
added the USB1 resets to the PHYs, thus replacing the really ugly parts
with something slightly better. Old device trees will still probe
successfully, but instead of this bugfix they'll get a dev_warn().

The reset control patch was dropped, as a similar patch from someone
else has landed in linux-next.

For a recap of the issue from the previous series:

Basically, the register area of the 1st USB controller contains some
registers that are global to all of the controllers, but that are also
cleared when reset is asserted to the 1st controller. So if (say) the
3rd controller would be the first one to finish probing successfully,
then the reset that happens during the 1st controller's probe would
result in broken USB. So the before doing anything with the USB HW,
we should reset the 1st controller once, and then never ever reset
it again.

While testing that the 1st USB controller still works without a reset
when the driver is unbound and bound again, I discovered an unbalanced
regulator_disable + clk_disable_unprepare in the PHY code if the EHCI
driver is unbound and rebound. This is fixed in patch 4.

Thanks,
Tuomas.

Tuomas Tynkkynen (4):
  USB: tegra: Add resets & has-utmi-pad-registers flag to the PHY
binding
  ARM: tegra: Add resets & has-utmi-pad-registers flag to all USB PHYs
  USB: EHCI: tegra: Fix probe order issue leading to broken USB
  USB: PHY: tegra: Call tegra_usb_phy_close only on device removal

 .../bindings/usb/nvidia,tegra20-usb-phy.txt|8 +++
 arch/arm/boot/dts/tegra114.dtsi|5 ++
 arch/arm/boot/dts/tegra124.dtsi|7 +++
 arch/arm/boot/dts/tegra20.dtsi |7 +++
 arch/arm/boot/dts/tegra30.dtsi |7 +++
 drivers/usb/host/ehci-tegra.c  |   62 +++-
 drivers/usb/phy/phy-tegra-usb.c|8 +--
 7 files changed, 96 insertions(+), 8 deletions(-)

-- 
1.7.9.5

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

[PATCH v2 3/4] USB: EHCI: tegra: Fix probe order issue leading to broken USB

The Tegra USB complex has a particularly annoying misdesign: some of the
UTMI pad configuration registers are global for all the 3 USB controllers
on the chip, but those registers are located in the first controller's
register space and will be cleared when the reset to the first
controller is asserted. Currently, this means that if the 1st controller
were to finish probing after the 2nd or 3rd controller, USB would not
work at all.

Fix this situation by always resetting the 1st controller before doing
any other setup to any of the controllers, and then never ever reset the
first controller again. As the UTMI registers are related to the PHY,
the PHY driver should probably reset the Tegra controllers instead,
but since old device trees only have reset phandles in the EHCI nodes,
do it here, which means a bit of device tree groveling. Those old DTs
also won't get the reset fix from this commit, so we'll dev_warn() them,
but the driver will still keep probing successfully.

Signed-off-by: Tuomas Tynkkynen 
---
v2 changes: assume we can find the usb1 reset from the PHY DT node,
don't fail if it's not found but just issue a warning
 drivers/usb/host/ehci-tegra.c |   62 +++--
 1 file changed, 59 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 5590567..f495775 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -46,6 +46,7 @@
 #define DRV_NAME "tegra-ehci"
 
 static struct hc_driver __read_mostly tegra_ehci_hc_driver;
+static bool usb1_reset_attempted;
 
 struct tegra_ehci_soc_config {
bool has_hostpc;
@@ -60,6 +61,61 @@ struct tegra_ehci_hcd {
enum tegra_usb_phy_port_speed port_speed;
 };
 
+/*
+ * The 1st USB controller contains some UTMI pad registers that are global for
+ * all the controllers on the chip. Those registers are also cleared when
+ * reset is asserted to the 1st controller. This means that the 1st controller
+ * can only be reset when no other controlled has finished probing. So we'll
+ * reset the 1st controller before doing any other setup on any of the
+ * controllers, and then never again.
+ *
+ * Since this is a PHY issue, the Tegra PHY driver should probably be doing
+ * the resetting of the USB controllers. But to keep compatibility with old
+ * device trees that don't have reset phandles in the PHYs, do it here.
+ * Those old DTs will be vulnerable to total USB breakage if the 1st EHCI
+ * device isn't the first one to finish probing, so warn them.
+ */
+static int tegra_reset_usb_controller(struct platform_device *pdev)
+{
+   struct device_node *phy_np;
+   struct usb_hcd *hcd = platform_get_drvdata(pdev);
+   struct tegra_ehci_hcd *tegra =
+   (struct tegra_ehci_hcd *)hcd_to_ehci(hcd)->priv;
+
+   phy_np = of_parse_phandle(pdev->dev.of_node, "nvidia,phy", 0);
+   if (!phy_np)
+   return -ENOENT;
+
+   if (!usb1_reset_attempted) {
+   struct reset_control *usb1_reset;
+
+   usb1_reset = of_reset_control_get(phy_np, "usb");
+   if (IS_ERR(usb1_reset)) {
+   dev_warn(&pdev->dev,
+"can't get utmi-pads reset from the PHY\n");
+   dev_warn(&pdev->dev,
+"continuing, but please update your DT\n");
+   } else {
+   reset_control_assert(usb1_reset);
+   udelay(1);
+   reset_control_deassert(usb1_reset);
+   }
+
+   reset_control_put(usb1_reset);
+   usb1_reset_attempted = true;
+   }
+
+   if (!of_property_read_bool(phy_np, "nvidia,has-utmi-pad-registers")) {
+   reset_control_assert(tegra->rst);
+   udelay(1);
+   reset_control_deassert(tegra->rst);
+   }
+
+   of_node_put(phy_np);
+
+   return 0;
+}
+
 static int tegra_ehci_internal_port_reset(
struct ehci_hcd *ehci,
u32 __iomem *portsc_reg
@@ -389,9 +445,9 @@ static int tegra_ehci_probe(struct platform_device *pdev)
if (err)
goto cleanup_hcd_create;
 
-   reset_control_assert(tegra->rst);
-   udelay(1);
-   reset_control_deassert(tegra->rst);
+   err = tegra_reset_usb_controller(pdev);
+   if (err)
+   goto cleanup_clk_en;
 
u_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "nvidia,phy", 0);
if (IS_ERR(u_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 v2 4/4] USB: PHY: tegra: Call tegra_usb_phy_close only on device removal

tegra_usb_phy_close() is supposed to undo the effects of
tegra_usb_phy_init(). It is also currently added as the USB PHY shutdown
callback, which is wrong, since tegra_usb_phy_init() is only called
during probing wheras the shutdown callback can get called multiple
times. This then leads to warnings about unbalanced regulator_disable if
the EHCI driver is unbound and bound again at runtime.

Signed-off-by: Tuomas Tynkkynen 
---
v2 changes: none
 drivers/usb/phy/phy-tegra-usb.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index bbe4f8e..72e04a9 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -686,10 +686,8 @@ static int ulpi_phy_power_off(struct tegra_usb_phy *phy)
return gpio_direction_output(phy->reset_gpio, 0);
 }
 
-static void tegra_usb_phy_close(struct usb_phy *x)
+static void tegra_usb_phy_close(struct tegra_usb_phy *phy)
 {
-   struct tegra_usb_phy *phy = container_of(x, struct tegra_usb_phy, 
u_phy);
-
if (!IS_ERR(phy->vbus))
regulator_disable(phy->vbus);
 
@@ -1061,14 +1059,13 @@ static int tegra_usb_phy_probe(struct platform_device 
*pdev)
if (err < 0)
return err;
 
-   tegra_phy->u_phy.shutdown = tegra_usb_phy_close;
tegra_phy->u_phy.set_suspend = tegra_usb_phy_suspend;
 
platform_set_drvdata(pdev, tegra_phy);
 
err = usb_add_phy_dev(&tegra_phy->u_phy);
if (err < 0) {
-   tegra_usb_phy_close(&tegra_phy->u_phy);
+   tegra_usb_phy_close(tegra_phy);
return err;
}
 
@@ -1080,6 +1077,7 @@ static int tegra_usb_phy_remove(struct platform_device 
*pdev)
struct tegra_usb_phy *tegra_phy = platform_get_drvdata(pdev);
 
usb_remove_phy(&tegra_phy->u_phy);
+   tegra_usb_phy_close(tegra_phy);
 
return 0;
 }
-- 
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/4] ARM: tegra: Add resets & has-utmi-pad-registers flag to all USB PHYs

Add new properties to all of the Tegra PHYs that are now required
according to the binding.

In order to stay compatible with old device trees, the USB drivers
will still function without these reset properties but with the old,
potentially buggy behaviour.

Signed-off-by: Tuomas Tynkkynen 
---
v2 changes: new patch, didn't exist in v1
 arch/arm/boot/dts/tegra114.dtsi |5 +
 arch/arm/boot/dts/tegra124.dtsi |7 +++
 arch/arm/boot/dts/tegra20.dtsi  |7 +++
 arch/arm/boot/dts/tegra30.dtsi  |7 +++
 4 files changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 335a1d8..80b8edd 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -672,6 +672,8 @@
 <&tegra_car TEGRA114_CLK_PLL_U>,
 <&tegra_car TEGRA114_CLK_USBD>;
clock-names = "reg", "pll_u", "utmi-pads";
+   resets = <&tegra_car 22>, <&tegra_car 22>;
+   reset-names = "usb", "utmi-pads";
nvidia,hssync-start-delay = <0>;
nvidia,idle-wait-delay = <17>;
nvidia,elastic-limit = <16>;
@@ -682,6 +684,7 @@
nvidia,hssquelch-level = <2>;
nvidia,hsdiscon-level = <5>;
nvidia,xcvr-hsslew = <12>;
+   nvidia,has-utmi-pad-registers;
status = "disabled";
};
 
@@ -705,6 +708,8 @@
 <&tegra_car TEGRA114_CLK_PLL_U>,
 <&tegra_car TEGRA114_CLK_USBD>;
clock-names = "reg", "pll_u", "utmi-pads";
+   resets = <&tegra_car 59>, <&tegra_car 22>;
+   reset-names = "usb", "utmi-pads";
nvidia,hssync-start-delay = <0>;
nvidia,idle-wait-delay = <17>;
nvidia,elastic-limit = <16>;
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index d675186..5b14d79 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -643,6 +643,8 @@
 <&tegra_car TEGRA124_CLK_PLL_U>,
 <&tegra_car TEGRA124_CLK_USBD>;
clock-names = "reg", "pll_u", "utmi-pads";
+   resets = <&tegra_car 22>, <&tegra_car 22>;
+   reset-names = "usb", "utmi-pads";
nvidia,hssync-start-delay = <0>;
nvidia,idle-wait-delay = <17>;
nvidia,elastic-limit = <16>;
@@ -653,6 +655,7 @@
nvidia,hssquelch-level = <2>;
nvidia,hsdiscon-level = <5>;
nvidia,xcvr-hsslew = <12>;
+   nvidia,has-utmi-pad-registers;
status = "disabled";
};
 
@@ -677,6 +680,8 @@
 <&tegra_car TEGRA124_CLK_PLL_U>,
 <&tegra_car TEGRA124_CLK_USBD>;
clock-names = "reg", "pll_u", "utmi-pads";
+   resets = <&tegra_car 58>, <&tegra_car 22>;
+   reset-names = "usb", "utmi-pads";
nvidia,hssync-start-delay = <0>;
nvidia,idle-wait-delay = <17>;
nvidia,elastic-limit = <16>;
@@ -711,6 +716,8 @@
 <&tegra_car TEGRA124_CLK_PLL_U>,
 <&tegra_car TEGRA124_CLK_USBD>;
clock-names = "reg", "pll_u", "utmi-pads";
+   resets = <&tegra_car 59>, <&tegra_car 22>;
+   reset-names = "usb", "utmi-pads";
nvidia,hssync-start-delay = <0>;
nvidia,idle-wait-delay = <17>;
nvidia,elastic-limit = <16>;
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 243d84c..1908f69 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -645,6 +645,8 @@
 <&tegra_car TEGRA20_CLK_CLK_M>,
 <&tegra_car TEGRA20_CLK_USBD>;
clock-names = "reg", "pll_u", "timer", "utmi-pads";
+   resets = <&tegra_car 22>, <&tegra_car 22>;
+   reset-names = "usb", "utmi-pads";
nvidia,has-legacy-mode;
nvidia,hssync-start-delay = <9>;
nvidia,idle-wait-delay = <17>;
@@ -653,6 +655,7 @@
nvidia,xcvr-setup = <9>;
nvidia,xcvr-lsfslew = <1>;
nvidia,xcvr-lsrslew = <1>;
+   nvidia,has-utmi-pad-registers;
status = "disabled";
};
 
@@ -676,6 +679,8 @@
 <&tegra_car TEGRA20_CLK_PLL_U>,
 <&tegra_car TEGRA20_CLK_CDEV2>;
clock-names = "reg", "pll_u", "ulpi-link";
+   resets = <&tegra_car 58>, <&tegra_car 22>;
+   reset-names = "usb", "utmi-pads";
status = "disabled";
};
 
@@ -700,6 +705,8 @@
 <&tegra_car TEGRA20_CLK_CLK_M>,
 <&tegra_car TEGRA2

[PATCH v2 1/4] USB: tegra: Add resets & has-utmi-pad-registers flag to the PHY binding

When Tegra was converted to use the standard reset bindings, the PHY was
forgotten, probably because all the resetting of the USB blocks were
done in the EHCI driver. What also went unnoticed is that resetting the
1st on-chip USB module also wipes some of the UTMI pad configuration
registers that are also used by the other USB blocks. So this fact needs
to be described in the device tree, and the driver modified not to reset
the 1st module at inappropriate times.

In order to stay compatible with old device trees, the USB drivers will
still function without these properties but with the old,
potentially buggy behaviour.

Signed-off-by: Tuomas Tynkkynen 
---
v2 changes: new patch, didn't exist in v1
 .../bindings/usb/nvidia,tegra20-usb-phy.txt|8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt 
b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
index ba797d3..c9205fb 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
@@ -20,6 +20,12 @@ Required properties :
  Present if phy_type == utmi.
- ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2).
  Present if phy_type == ulpi, and ULPI link mode is in use.
+ - resets : Must contain an entry for each entry in reset-names.
+   See ../reset/reset.txt for details.
+ - reset-names : Must include the following entries:
+   - usb: The PHY's own reset signal.
+   - utmi-pads: The reset of the PHY containing the chip-wide UTMI pad control
+ registers. Required even if phy_type == ulpi.
 
 Required properties for phy_type == ulpi:
   - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
@@ -56,6 +62,8 @@ Optional properties:
   host means this is a host controller
   peripheral means it is device controller
   otg means it can operate as either ("on the go")
+  - nvidia,has-utmi-pad-registers : boolean indicates whether this controller
+contains the UTMI pad control registers common to all USB controllers.
 
 VBUS control (required for dr_mode == otg, optional for dr_mode == host):
   - vbus-supply: regulator for VBUS
-- 
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

[GIT PULL] USB driver fixes for 3.16-rc4

2014-07-03 Thread Greg KH

The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:

  Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-3.16-rc4

for you to fetch changes up to e4adcff09ca39ecbcc4851d40d0f0a5458e7b77a:

  usb: chipidea: udc: delete td from req's td list at ep_dequeue (2014-07-01 
23:06:02 -0700)


USB bugfixes for 3.16-rc4

Here's a round of USB bugfixes, quirk additions, and new device ids for
3.16-rc4.  Nothing major in here at all, just a bunch of tiny changes.
All have been in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Alan Stern (1):
  usb-storage/SCSI: Add broken_fua blacklist flag

Andreas Larsson (1):
  usb: gadget: gr_udc: Fix check for invalid number of microframes

Andrzej Pietrasiewicz (2):
  usb: gadget: OS descriptors configfs cleanup
  usb: gadget: OS descriptors: provide interface directory names

Bjørn Mork (1):
  usb: option: add/modify Olivetti Olicard modems

Dan Carpenter (1):
  usb: gadget: f_rndis: fix an error code on allocation failure

Ezequiel Garcia (1):
  usb: musb: Fix panic upon musb_am335x module removal

Felipe Balbi (1):
  Revert "tools: ffs-test: convert to new descriptor format fixing 
compilation error"

George Cherian (3):
  usb: dwc3: dwc3-omap: Fix the crash on module removal
  usb: dwc3: dwc3-omap: Disable/Enable only wrapper interrupts in 
prepare/complete
  usb: musb: core: Handle Babble condition only in HOST mode

Greg Kroah-Hartman (3):
  Merge tag 'fixes-for-v3.16-rc2' of git://git.kernel.org/.../balbi/usb 
into usb-linus
  Merge tag 'usb-serial-3.16-rc3' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus
  Merge tag 'fixes-for-v3.16-rc4' of git://git.kernel.org/.../balbi/usb 
into usb-linus

Jeff Westfahl (1):
  usb: gadget: u_ether: synchronize with transmit when stopping queue

Johan Hovold (3):
  MAINTAINERS: drop two usb-serial subdriver entries
  USB: ftdi_sio: fix null deref at port probe
  MAINTAINERS: update e-mail address

Kuninori Morimoto (1):
  usb: renesas: gadget: fixup: complete STATUS stage after receiving

Linus Walleij (1):
  usb: musb: ux500: don't propagate the OF node

Lothar Waßmann (1):
  usb: musb: dsps: fix the base address for accessing the mode register

Lu Baolu (1):
  xhci: clear root port wake on bits if controller isn't wake-up capable

Marcus Nutzinger (1):
  usb: gadget: gadgetfs: correct dev state

Mathias Nyman (2):
  xhci: Use correct SLOT ID when handling a reset device command
  xhci: correct burst count field for isoc transfers on 1.0 xhci hosts

Michal Nazarewicz (4):
  tools: ffs-test: convert to new descriptor format fixing compilation error
  usb: gadget: f_fs: fix NULL pointer dereference when there are no strings
  usb: gadget: f_fs: resurect usb_functionfs_descs_head structure
  tools: ffs-test: fix header values endianess

Oliver Neukum (1):
  USB: option: add device ID for SpeedUp SU9800 usb 3g modem

Peter Chen (1):
  usb: chipidea: udc: delete td from req's td list at ep_dequeue

Srinivas Kandagatla (2):
  usb: phy: msm: Do not do runtime pm if the phy is not idle
  usb: Kconfig: make EHCI_MSM selectable for QCOM SOCs

Thomas Gleixner (1):
  usb: musb: Ensure that cppi41 timer gets armed on premature DMA TX irq

Wang, Yu (1):
  xhci: Fix runtime suspended xhci from blocking system suspend.

Zhuang Jin Can (1):
  usb: dwc3: gadget: check link trb after free_slot is increased

 MAINTAINERS | 14 +-
 drivers/scsi/sd.c   |  5 -
 drivers/usb/chipidea/udc.c  |  7 +++
 drivers/usb/dwc3/Kconfig|  1 +
 drivers/usb/dwc3/dwc3-omap.c| 17 ++---
 drivers/usb/dwc3/gadget.c   |  8 
 drivers/usb/gadget/configfs.c   | 37 +++--
 drivers/usb/gadget/configfs.h   |  1 +
 drivers/usb/gadget/f_fs.c   | 12 +++-
 drivers/usb/gadget/f_rndis.c|  6 --
 drivers/usb/gadget/gr_udc.c |  5 +++--
 drivers/usb/gadget/inode.c  |  7 ++-
 drivers/usb/gadget/u_ether.c|  3 +++
 drivers/usb/host/Kconfig|  2 +-
 drivers/usb/host/xhci-hub.c |  5 -
 drivers/usb/host/xhci-ring.c|  9 ++---
 drivers/usb/host/xhci.c | 10 +++---
 drivers/usb/musb/musb_am335x.c  | 23 ++-
 drivers/usb/musb/musb_core.c|  2 +-
 drivers/usb/musb/musb_cppi41.c  |  2 +-
 drivers/usb/musb/musb_dsps.c|  9 -
 drivers/usb/musb/ux500.c|  1 -
 drivers/usb/phy/phy-msm-usb.c   |  4 +++-
 drivers/usb/renesas_usbhs/fifo.c|  8 
 dri

Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs

2014-07-03 Thread Sergei Shtylyov


Hello.

On 06/25/2014 12:44 PM, Vivek Gautam wrote:


diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
  u32 port_status_u0;
   /* Compliance Mode Timer Triggered every 2 seconds */
   #define COMP_MODE_RCVRY_MSECS 2000
+   /* phys for the controller */
+   struct phy  *phy2_gen;
+   struct phy  *phy3_gen;
   };



I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.



Indeed.


   Actually, I haven't given enough thought to this...


There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.



There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that).



That member has type 'struct usb_phy *' while here we have 'struct phy *'
-- feel the difference.
I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',



So the 'struct phy *' available in the usb_hcd is requested in usb_add_hcd().
This is requested with the constant string 'usb' :
struct phy *phy = phy_get(hcd->self.controller, "usb");



This can get the phy with string 'usb' only if, either the host
controller has a device node wherein the phys are given.


   Yes, that was the plan. Currently, the PHY driver for which this was 
written can be probed from the device tree only.



Even in this case one can't give same constant string for two
different phys, UTMI+ and PIPE3 phy, isn't it ?


   Yes, you're right. I didn't really consider the case of some host needing 
2 distinct PHY.



Or, the other way can be when host gets a lookup table to look into to
find the relevant phys, something like
Heikki has suggested:
usb: dwc3: host: convey the PHYs to xhci
(https://lkml.org/lkml/2014/6/5/585) and related patch series.


   Well, AFAIK the look-up table method is already provided by the current 
PHY core for non-DT use cases; this doesn't seem to have changed with that 
patch set, does it?



So if we use this second approach, we would need to override the
'phy_get()' that has been done in usb_add_hcd()
in xhci_plat_probe(), and then use them in later operations.


   I guess it'd probably be simpler to ignore the 'gen_phy' member of 'struct 
usb_hcd' in your case (if it gets eventually added).


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 0/2] USB: make HCD specific allocations non-atomically

On Thu, 3 Jul 2014, Vladimir Zapolskiy wrote:

> This change makes two more one-time per HCD allocations to be done
> from non-atomic DMA pool, the main purpose of the change is to save
> some bits of space in coherent atomic DMA pool, which is 256KB by
> default on ARM platform.
> 
> Vladimir Zapolskiy (2):
>   USB: OHCI: don't allocate HCCA atomically
>   USB: UHCI: don't allocate frame list atomically
> 
>  drivers/usb/host/ohci-hcd.c |2 +-
>  drivers/usb/host/uhci-hcd.c |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

For both patches,

Acked-by: Alan Stern 

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

[PATCH 2/2] USB: UHCI: don't allocate frame list atomically

uhci_start() is executed one time during usb_add_hcd() call and by
default UHCI frame list is allocated from atomic DMA pool.

Do non-atomic allocation of uhci->frame and free some space in
coherent atomic DMA pool.

Cc: Alan Stern 
Cc: Greg Kroah-Hartman 
Signed-off-by: Vladimir Zapolskiy 
---
 drivers/usb/host/uhci-hcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 27f35e8..a7de8e8 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -591,7 +591,7 @@ static int uhci_start(struct usb_hcd *hcd)
 
uhci->frame = dma_alloc_coherent(uhci_dev(uhci),
UHCI_NUMFRAMES * sizeof(*uhci->frame),
-   &uhci->frame_dma_handle, 0);
+   &uhci->frame_dma_handle, GFP_KERNEL);
if (!uhci->frame) {
dev_err(uhci_dev(uhci),
"unable to allocate consistent memory for frame 
list\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 1/2] USB: OHCI: don't allocate HCCA atomically

OHCI HCCA memory region is allocated from atomic DMA pool one time
during usb_add_hcd() and deallocated by usb_remove_hcd().

Do non-atomic allocation of OHCI HCCA and free some space in
coherent atomic DMA pool.

Cc: Alan Stern 
Cc: Greg Kroah-Hartman 
Signed-off-by: Vladimir Zapolskiy 
---
 drivers/usb/host/ohci-hcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index f98d03f..682d65b 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -559,7 +559,7 @@ static int ohci_init (struct ohci_hcd *ohci)
return 0;
 
ohci->hcca = dma_alloc_coherent (hcd->self.controller,
-   sizeof *ohci->hcca, &ohci->hcca_dma, 0);
+   sizeof(*ohci->hcca), &ohci->hcca_dma, GFP_KERNEL);
if (!ohci->hcca)
return -ENOMEM;
 
-- 
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 0/2] USB: make HCD specific allocations non-atomically

This change makes two more one-time per HCD allocations to be done
from non-atomic DMA pool, the main purpose of the change is to save
some bits of space in coherent atomic DMA pool, which is 256KB by
default on ARM platform.

Vladimir Zapolskiy (2):
  USB: OHCI: don't allocate HCCA atomically
  USB: UHCI: don't allocate frame list atomically

 drivers/usb/host/ohci-hcd.c |2 +-
 drivers/usb/host/uhci-hcd.c |2 +-
 2 files changed, 2 insertions(+), 2 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

Re: [PATCH] USB: EHCI: don't allocate hardware periodic table atomically by default


On 03.07.2014 19:38, Alan Stern wrote:

On Thu, 3 Jul 2014, Vladimir Zapolskiy wrote:


ehci_mem_init() is executed one time during ehci_init() and by default
all memory allocations but ehci->periodic are done not atomically,
GFP_KERNEL is passed as flags parameter.

Do similar allocation for ehci->periodic and free some space in
coherent atomic DMA pool by default.

Cc: Alan Stern
Cc: Greg Kroah-Hartman
Signed-off-by: Vladimir Zapolskiy

---
  drivers/usb/host/ehci-mem.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index c0fb6a8..b6205fa 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -209,7 +209,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
ehci->periodic = (__le32 *)
dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
ehci->periodic_size * sizeof(__le32),
-   &ehci->periodic_dma, 0);
+   &ehci->periodic_dma, flags);
if (ehci->periodic == NULL) {
goto fail;
}


Acked-by: Alan Stern

Please make the same change in ohci-hcd.c and uhci-hcd.c.


Thank you for review, I'm on the way to send two more changes according 
to your ask.


With best wishes,
Vladimir
--
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 v6] HID: gt683r: move mode attribute to led-class devices

2014-07-03 Thread Janne Kanniainen

2014-07-03 21:17 GMT+03:00 Bryan Wu :
> On Thu, Jul 3, 2014 at 10:40 AM, Johan Hovold  wrote:
>> On Thu, Jul 03, 2014 at 08:17:09PM +0300, Janne Kanniainen wrote:
>>> Move led_mode attribute from HID device to led-class devices and rename
>>> it msi_mode. This will also fix race condition by using
>>
>> There's a typo here (s/msi_mode/mode) but perhaps Bryan can just fix
>> that up before applying?
>>
>>> attribute-groups.
>>>
>>> Signed-off-by: Janne Kanniainen 
>>
>> Reviewed-by: Johan Hovold 
>>
>> Otherwise both patches (v6) are ready to be merged, Bryan.
>>
>> Thanks, Janne!
>>
>
> No problem. I fixed the typo and merged it.
>
> Thanks,
> -Bryan

Thanks again to both of you!

Janne
--
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 v6] HID: gt683r: move mode attribute to led-class devices

2014-07-03 Thread Bryan Wu

On Thu, Jul 3, 2014 at 10:40 AM, Johan Hovold  wrote:
> On Thu, Jul 03, 2014 at 08:17:09PM +0300, Janne Kanniainen wrote:
>> Move led_mode attribute from HID device to led-class devices and rename
>> it msi_mode. This will also fix race condition by using
>
> There's a typo here (s/msi_mode/mode) but perhaps Bryan can just fix
> that up before applying?
>
>> attribute-groups.
>>
>> Signed-off-by: Janne Kanniainen 
>
> Reviewed-by: Johan Hovold 
>
> Otherwise both patches (v6) are ready to be merged, Bryan.
>
> Thanks, Janne!
>

No problem. I fixed the typo and merged it.

Thanks,
-Bryan



>> ---
>>
>> Changes in v3:
>>   - Style fixes
>>   - Rename sysfs-class-hid-driver-gt683r to 
>> sysfs-class-leds-driver-gt683r
>>
>> Changes in v4:
>>   - Rename sysfs-class-leds-driver-gt683r to sysfs-class-leds-gt683r
>>   - Change "What: " to /sys/class/leds//gt683r/mode
>>   - Change .name from gt683r_led to gt683r
>>
>> Changes in v5:
>>   - Move mode attribute to gt683r/mode
>>
>> Changes in v6:
>>   - Fix subject and commit message
>>
>>  .../ABI/testing/sysfs-class-hid-driver-gt683r  | 14 -
>>  Documentation/ABI/testing/sysfs-class-leds-gt683r  | 16 ++
>>  drivers/hid/hid-gt683r.c   | 36 
>> ++
>>  3 files changed, 40 insertions(+), 26 deletions(-)
>>  delete mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
>>  create mode 100644 Documentation/ABI/testing/sysfs-class-leds-gt683r
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r 
>> b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
>> deleted file mode 100644
>> index 317e9d5..000
>> --- a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
>> +++ /dev/null
>> @@ -1,14 +0,0 @@
>> -What:/sys/class/hidraw//device/leds_mode
>> -Date:Jun 2014
>> -KernelVersion:   3.17
>> -Contact: Janne Kanniainen 
>> -Description:
>> - Set the mode of LEDs
>> -
>> - 0 - normal
>> - 1 - audio
>> - 2 - breathing
>> -
>> - Normal: LEDs are fully on when enabled
>> - Audio:  LEDs brightness depends on sound level
>> - Breathing: LEDs brightness varies at human breathing rate
>> \ No newline at end of file
>> diff --git a/Documentation/ABI/testing/sysfs-class-leds-gt683r 
>> b/Documentation/ABI/testing/sysfs-class-leds-gt683r
>> new file mode 100644
>> index 000..e4fae60
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r
>> @@ -0,0 +1,16 @@
>> +What:/sys/class/leds//gt683r/mode
>> +Date:Jun 2014
>> +KernelVersion:   3.17
>> +Contact: Janne Kanniainen 
>> +Description:
>> + Set the mode of LEDs. You should notice that changing the mode
>> + of one LED will update the mode of its two sibling devices as
>> + well.
>> +
>> + 0 - normal
>> + 1 - audio
>> + 2 - breathing
>> +
>> + Normal: LEDs are fully on when enabled
>> + Audio:  LEDs brightness depends on sound level
>> + Breathing: LEDs brightness varies at human breathing rate
>> \ No newline at end of file
>> diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
>> index 073bd80..0d6f135 100644
>> --- a/drivers/hid/hid-gt683r.c
>> +++ b/drivers/hid/hid-gt683r.c
>> @@ -84,12 +84,13 @@ static void gt683r_brightness_set(struct led_classdev 
>> *led_cdev,
>>   }
>>  }
>>
>> -static ssize_t leds_mode_show(struct device *dev,
>> +static ssize_t mode_show(struct device *dev,
>>   struct device_attribute *attr,
>>   char *buf)
>>  {
>>   u8 sysfs_mode;
>> - struct hid_device *hdev = container_of(dev, struct hid_device, dev);
>> + struct hid_device *hdev = container_of(dev->parent,
>> + struct hid_device, dev);
>>   struct gt683r_led *led = hid_get_drvdata(hdev);
>>
>>   if (led->mode == GT683R_LED_NORMAL)
>> @@ -102,12 +103,13 @@ static ssize_t leds_mode_show(struct device *dev,
>>   return scnprintf(buf, PAGE_SIZE, "%u\n", sysfs_mode);
>>  }
>>
>> -static ssize_t leds_mode_store(struct device *dev,
>> +static ssize_t mode_store(struct device *dev,
>>   struct device_attribute *attr,
>>   const char *buf, size_t count)
>>  {
>>   u8 sysfs_mode;
>> - struct hid_device *hdev = container_of(dev, struct hid_device, dev);
>> + struct hid_device *hdev = container_of(dev->parent,
>> + struct hid_device, dev);
>>   struct gt683r_led *led = hid_get_drvdata(hdev);
>>
>>
>> @@ -212,7 +214,22 @@ fail:
>>   mutex_unlock(&led->lock);
>>  }
>>
>> -static DEVICE_ATTR_RW(leds_mode);
>> +static DEVICE_ATTR_RW(mode);
>> +
>> +static struct attribute *gt683r_led_attrs[] = {
>> +

[PATCH 1/1] usb: gadget: f_uac2: Fix pcm sample size selection

2014-07-03 Thread Sebastian Reimers

The pcm playback and capture sample size format was fixed
SNDRV_PCM_FMTBIT_S16_LE.

This patch respects also 16, 24 and 32 bit p_ssize and c_ssize values.

Signed-off-by: Sebastian Reimers 
---
 drivers/usb/gadget/f_uac2.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_uac2.c b/drivers/usb/gadget/f_uac2.c
index 6261db4a..3ed89ec 100644
--- a/drivers/usb/gadget/f_uac2.c
+++ b/drivers/usb/gadget/f_uac2.c
@@ -348,14 +348,34 @@ static int uac2_pcm_open(struct snd_pcm_substream 
*substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
spin_lock_init(&uac2->p_prm.lock);
runtime->hw.rate_min = p_srate;
-   runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE; /* ! p_ssize ! */
+   switch (p_ssize) {
+   case 3:
+   runtime->hw.formats = SNDRV_PCM_FMTBIT_S24_3LE;
+   break;
+   case 4:
+   runtime->hw.formats = SNDRV_PCM_FMTBIT_S32_LE;
+   break;
+   default:
+   runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+   break;
+   }
runtime->hw.channels_min = num_channels(p_chmask);
runtime->hw.period_bytes_min = 2 * uac2->p_prm.max_psize
/ runtime->hw.periods_min;
} else {
spin_lock_init(&uac2->c_prm.lock);
runtime->hw.rate_min = c_srate;
-   runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE; /* ! c_ssize ! */
+   switch (c_ssize) {
+   case 3:
+   runtime->hw.formats = SNDRV_PCM_FMTBIT_S24_3LE;
+   break;
+   case 4:
+   runtime->hw.formats = SNDRV_PCM_FMTBIT_S32_LE;
+   break;
+   default:
+   runtime->hw.formats = SNDRV_PCM_FMTBIT_S16_LE;
+   break;
+   }
runtime->hw.channels_min = num_channels(c_chmask);
runtime->hw.period_bytes_min = 2 * uac2->c_prm.max_psize
/ runtime->hw.periods_min;
-- 
2.0.1

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

Re: [PATCH 1/2 v6] HID: gt683r: fix race condition

2014-07-03 Thread Bryan Wu

On Thu, Jul 3, 2014 at 10:34 AM, Johan Hovold  wrote:
> On Thu, Jul 03, 2014 at 08:17:08PM +0300, Janne Kanniainen wrote:
>> This will fix race condition noticed by Oliver Neukum. Sysfs files are
>> created before mutex and work are initialized.
>>
>> Signed-off-by: Janne Kanniainen 
>
> Reviewed-by: Johan Hovold 
>

Good, merged to my tree.
-Bryan

>> ---
>>  drivers/hid/hid-gt683r.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
>> index 077f7a1..073bd80 100644
>> --- a/drivers/hid/hid-gt683r.c
>> +++ b/drivers/hid/hid-gt683r.c
>> @@ -227,6 +227,9 @@ static int gt683r_led_probe(struct hid_device *hdev,
>>   if (!led)
>>   return -ENOMEM;
>>
>> + mutex_init(&led->lock);
>> + INIT_WORK(&led->work, gt683r_led_work);
>> +
>>   led->mode = GT683R_LED_NORMAL;
>>   led->hdev = hdev;
>>   hid_set_drvdata(hdev, led);
>> @@ -271,9 +274,6 @@ static int gt683r_led_probe(struct hid_device *hdev,
>>   goto fail;
>>   }
>>
>> - mutex_init(&led->lock);
>> - INIT_WORK(&led->work, gt683r_led_work);
>> -
>>   return 0;
>>
>>  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: Chipidea gadget unplug/disconnect event

2014-07-03 Thread Michael Grzeschik

Hi Fabio,

On Thu, Jul 03, 2014 at 02:04:07PM -0300, Fabio Estevam wrote:
> Hi Michael,
> 
> On Thu, Jul 3, 2014 at 1:06 PM, Michael Grzeschik  wrote:
> 
> > I validated this with two different imx25 boards and realized,
> > that we have this external vbus divider errata for that SoC.
> >
> > Errata: ENGcm09152
> >
> > Its likely that the issue is related to this problem as the vbus was
> > not connected to anything different, than the SoC in that case.
> 
> Does it help if you pass the 'external-vbus-divider' property like shown 
> below?
> 
> &usbotg {
> phy_type = "utmi";
> dr_mode = "otg";
> external-vbus-divider;
> status = "okay";
> };


No it does not. :( Actually it makes things worse!

The property disables the internal divider setup completely. Therefor
the vbus does not even fall down to ~2.6V on unplugging. Instead it
stays at ~3.1V. With that even the plug event will not be detected.

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 v6] HID: gt683r: move mode attribute to led-class devices

2014-07-03 Thread Johan Hovold

On Thu, Jul 03, 2014 at 08:17:09PM +0300, Janne Kanniainen wrote:
> Move led_mode attribute from HID device to led-class devices and rename
> it msi_mode. This will also fix race condition by using

There's a typo here (s/msi_mode/mode) but perhaps Bryan can just fix
that up before applying?

> attribute-groups.
> 
> Signed-off-by: Janne Kanniainen 

Reviewed-by: Johan Hovold 

Otherwise both patches (v6) are ready to be merged, Bryan.

Thanks, Janne!

Johan

> ---
> 
> Changes in v3:
>   - Style fixes
>   - Rename sysfs-class-hid-driver-gt683r to sysfs-class-leds-driver-gt683r
> 
> Changes in v4:
>   - Rename sysfs-class-leds-driver-gt683r to sysfs-class-leds-gt683r
>   - Change "What: " to /sys/class/leds//gt683r/mode
>   - Change .name from gt683r_led to gt683r
> 
> Changes in v5:
>   - Move mode attribute to gt683r/mode
> 
> Changes in v6:
>   - Fix subject and commit message
> 
>  .../ABI/testing/sysfs-class-hid-driver-gt683r  | 14 -
>  Documentation/ABI/testing/sysfs-class-leds-gt683r  | 16 ++
>  drivers/hid/hid-gt683r.c   | 36 
> ++
>  3 files changed, 40 insertions(+), 26 deletions(-)
>  delete mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
>  create mode 100644 Documentation/ABI/testing/sysfs-class-leds-gt683r
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r 
> b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> deleted file mode 100644
> index 317e9d5..000
> --- a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -What:/sys/class/hidraw//device/leds_mode
> -Date:Jun 2014
> -KernelVersion:   3.17
> -Contact: Janne Kanniainen 
> -Description:
> - Set the mode of LEDs
> -
> - 0 - normal
> - 1 - audio
> - 2 - breathing
> -
> - Normal: LEDs are fully on when enabled
> - Audio:  LEDs brightness depends on sound level
> - Breathing: LEDs brightness varies at human breathing rate
> \ No newline at end of file
> diff --git a/Documentation/ABI/testing/sysfs-class-leds-gt683r 
> b/Documentation/ABI/testing/sysfs-class-leds-gt683r
> new file mode 100644
> index 000..e4fae60
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r
> @@ -0,0 +1,16 @@
> +What:/sys/class/leds//gt683r/mode
> +Date:Jun 2014
> +KernelVersion:   3.17
> +Contact: Janne Kanniainen 
> +Description:
> + Set the mode of LEDs. You should notice that changing the mode
> + of one LED will update the mode of its two sibling devices as
> + well.
> +
> + 0 - normal
> + 1 - audio
> + 2 - breathing
> +
> + Normal: LEDs are fully on when enabled
> + Audio:  LEDs brightness depends on sound level
> + Breathing: LEDs brightness varies at human breathing rate
> \ No newline at end of file
> diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
> index 073bd80..0d6f135 100644
> --- a/drivers/hid/hid-gt683r.c
> +++ b/drivers/hid/hid-gt683r.c
> @@ -84,12 +84,13 @@ static void gt683r_brightness_set(struct led_classdev 
> *led_cdev,
>   }
>  }
>  
> -static ssize_t leds_mode_show(struct device *dev,
> +static ssize_t mode_show(struct device *dev,
>   struct device_attribute *attr,
>   char *buf)
>  {
>   u8 sysfs_mode;
> - struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> + struct hid_device *hdev = container_of(dev->parent,
> + struct hid_device, dev);
>   struct gt683r_led *led = hid_get_drvdata(hdev);
>  
>   if (led->mode == GT683R_LED_NORMAL)
> @@ -102,12 +103,13 @@ static ssize_t leds_mode_show(struct device *dev,
>   return scnprintf(buf, PAGE_SIZE, "%u\n", sysfs_mode);
>  }
>  
> -static ssize_t leds_mode_store(struct device *dev,
> +static ssize_t mode_store(struct device *dev,
>   struct device_attribute *attr,
>   const char *buf, size_t count)
>  {
>   u8 sysfs_mode;
> - struct hid_device *hdev = container_of(dev, struct hid_device, dev);
> + struct hid_device *hdev = container_of(dev->parent,
> + struct hid_device, dev);
>   struct gt683r_led *led = hid_get_drvdata(hdev);
>  
>  
> @@ -212,7 +214,22 @@ fail:
>   mutex_unlock(&led->lock);
>  }
>  
> -static DEVICE_ATTR_RW(leds_mode);
> +static DEVICE_ATTR_RW(mode);
> +
> +static struct attribute *gt683r_led_attrs[] = {
> + &dev_attr_mode.attr,
> + NULL
> +};
> +
> +static const struct attribute_group gt683r_led_group = {
> + .name = "gt683r",
> + .attrs = gt683r_led_attrs,
> +};
> +
> +static const struct attribute_group *gt683r_led_groups[]

Re: [PATCH 1/2 v6] HID: gt683r: fix race condition

2014-07-03 Thread Johan Hovold

On Thu, Jul 03, 2014 at 08:17:08PM +0300, Janne Kanniainen wrote:
> This will fix race condition noticed by Oliver Neukum. Sysfs files are
> created before mutex and work are initialized.
> 
> Signed-off-by: Janne Kanniainen 

Reviewed-by: Johan Hovold 

> ---
>  drivers/hid/hid-gt683r.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
> index 077f7a1..073bd80 100644
> --- a/drivers/hid/hid-gt683r.c
> +++ b/drivers/hid/hid-gt683r.c
> @@ -227,6 +227,9 @@ static int gt683r_led_probe(struct hid_device *hdev,
>   if (!led)
>   return -ENOMEM;
>  
> + mutex_init(&led->lock);
> + INIT_WORK(&led->work, gt683r_led_work);
> +
>   led->mode = GT683R_LED_NORMAL;
>   led->hdev = hdev;
>   hid_set_drvdata(hdev, led);
> @@ -271,9 +274,6 @@ static int gt683r_led_probe(struct hid_device *hdev,
>   goto fail;
>   }
>  
> - mutex_init(&led->lock);
> - INIT_WORK(&led->work, gt683r_led_work);
> -
>   return 0;
>  
>  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

[PATCH 2/2 v6] HID: gt683r: move mode attribute to led-class devices

2014-07-03 Thread Janne Kanniainen

Move led_mode attribute from HID device to led-class devices and rename
it msi_mode. This will also fix race condition by using
attribute-groups.

Signed-off-by: Janne Kanniainen 
---

Changes in v3:
- Style fixes
- Rename sysfs-class-hid-driver-gt683r to sysfs-class-leds-driver-gt683r

Changes in v4:
- Rename sysfs-class-leds-driver-gt683r to sysfs-class-leds-gt683r
- Change "What: " to /sys/class/leds//gt683r/mode
- Change .name from gt683r_led to gt683r

Changes in v5:
- Move mode attribute to gt683r/mode

Changes in v6:
- Fix subject and commit message

 .../ABI/testing/sysfs-class-hid-driver-gt683r  | 14 -
 Documentation/ABI/testing/sysfs-class-leds-gt683r  | 16 ++
 drivers/hid/hid-gt683r.c   | 36 ++
 3 files changed, 40 insertions(+), 26 deletions(-)
 delete mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
 create mode 100644 Documentation/ABI/testing/sysfs-class-leds-gt683r

diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r 
b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
deleted file mode 100644
index 317e9d5..000
--- a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
+++ /dev/null
@@ -1,14 +0,0 @@
-What:  /sys/class/hidraw//device/leds_mode
-Date:  Jun 2014
-KernelVersion: 3.17
-Contact:   Janne Kanniainen 
-Description:
-   Set the mode of LEDs
-
-   0 - normal
-   1 - audio
-   2 - breathing
-
-   Normal: LEDs are fully on when enabled
-   Audio:  LEDs brightness depends on sound level
-   Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-class-leds-gt683r 
b/Documentation/ABI/testing/sysfs-class-leds-gt683r
new file mode 100644
index 000..e4fae60
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r
@@ -0,0 +1,16 @@
+What:  /sys/class/leds//gt683r/mode
+Date:  Jun 2014
+KernelVersion: 3.17
+Contact:   Janne Kanniainen 
+Description:
+   Set the mode of LEDs. You should notice that changing the mode
+   of one LED will update the mode of its two sibling devices as
+   well.
+
+   0 - normal
+   1 - audio
+   2 - breathing
+
+   Normal: LEDs are fully on when enabled
+   Audio:  LEDs brightness depends on sound level
+   Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file
diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
index 073bd80..0d6f135 100644
--- a/drivers/hid/hid-gt683r.c
+++ b/drivers/hid/hid-gt683r.c
@@ -84,12 +84,13 @@ static void gt683r_brightness_set(struct led_classdev 
*led_cdev,
}
 }
 
-static ssize_t leds_mode_show(struct device *dev,
+static ssize_t mode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
 {
u8 sysfs_mode;
-   struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+   struct hid_device *hdev = container_of(dev->parent,
+   struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
 
if (led->mode == GT683R_LED_NORMAL)
@@ -102,12 +103,13 @@ static ssize_t leds_mode_show(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%u\n", sysfs_mode);
 }
 
-static ssize_t leds_mode_store(struct device *dev,
+static ssize_t mode_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
 {
u8 sysfs_mode;
-   struct hid_device *hdev = container_of(dev, struct hid_device, dev);
+   struct hid_device *hdev = container_of(dev->parent,
+   struct hid_device, dev);
struct gt683r_led *led = hid_get_drvdata(hdev);
 
 
@@ -212,7 +214,22 @@ fail:
mutex_unlock(&led->lock);
 }
 
-static DEVICE_ATTR_RW(leds_mode);
+static DEVICE_ATTR_RW(mode);
+
+static struct attribute *gt683r_led_attrs[] = {
+   &dev_attr_mode.attr,
+   NULL
+};
+
+static const struct attribute_group gt683r_led_group = {
+   .name = "gt683r",
+   .attrs = gt683r_led_attrs,
+};
+
+static const struct attribute_group *gt683r_led_groups[] = {
+   >683r_led_group,
+   NULL
+};
 
 static int gt683r_led_probe(struct hid_device *hdev,
const struct hid_device_id *id)
@@ -261,6 +278,8 @@ static int gt683r_led_probe(struct hid_device *hdev,
led->led_devs[i].name = name;
led->led_devs[i].max_brightness = 1;
led->led_devs[i].brightness_set = gt683r_brightness_set;
+   led->led_devs[i].groups = gt683r_led_groups;
+

[PATCH 1/2 v6] HID: gt683r: fix race condition

2014-07-03 Thread Janne Kanniainen

This will fix race condition noticed by Oliver Neukum. Sysfs files are
created before mutex and work are initialized.

Signed-off-by: Janne Kanniainen 
---
 drivers/hid/hid-gt683r.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
index 077f7a1..073bd80 100644
--- a/drivers/hid/hid-gt683r.c
+++ b/drivers/hid/hid-gt683r.c
@@ -227,6 +227,9 @@ static int gt683r_led_probe(struct hid_device *hdev,
if (!led)
return -ENOMEM;
 
+   mutex_init(&led->lock);
+   INIT_WORK(&led->work, gt683r_led_work);
+
led->mode = GT683R_LED_NORMAL;
led->hdev = hdev;
hid_set_drvdata(hdev, led);
@@ -271,9 +274,6 @@ static int gt683r_led_probe(struct hid_device *hdev,
goto fail;
}
 
-   mutex_init(&led->lock);
-   INIT_WORK(&led->work, gt683r_led_work);
-
return 0;
 
 fail:
-- 
1.9.2

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

Re: Chipidea gadget unplug/disconnect event

2014-07-03 Thread Fabio Estevam

Hi Michael,

On Thu, Jul 3, 2014 at 1:06 PM, Michael Grzeschik  wrote:

> I validated this with two different imx25 boards and realized,
> that we have this external vbus divider errata for that SoC.
>
> Errata: ENGcm09152
>
> Its likely that the issue is related to this problem as the vbus was
> not connected to anything different, than the SoC in that case.

Does it help if you pass the 'external-vbus-divider' property like shown below?

&usbotg {
phy_type = "utmi";
dr_mode = "otg";
external-vbus-divider;
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: Possible bug in xhci-ring.c

2014-07-03 Thread Maciej Puzio

Julius, I finally managed to generate some sensible (I hope) logs.
The kernel is 3.2.60-rc3 with modifications as you requested.

http://pastebin.com/6as4beZ3
This is an excerpt from syslog, showing messages logged immediately
after a USB3 device (Areca ARC-5040) was plugged in. The OS was booted
without any device plugged to USB3 ports, and booted seemingly normally.
After the device was plugged in, similar messages as in the above file
were logged 38 times, with ~30 second intervals. This was interspersed
with various timeout messages. After ~18 minutes, device was recognized
and filesystem mounted. Unfortunately the size of the full syslog file
(from boot to FS mount) is 6 MB, and greatly exceeds pastebin limits.
However, compressed file is significantly smaller. Can you indicate how
would you like to receive it? (pbput to pastebin.com, email attachment,
any other way?)

http://pastebin.com/B431CEbp
File xhci-ring.c with debug calls for your reference.

One more thing: I have run into difficulty coaxing xhci_dbg to log
anything by setting defines as you suggested. Instead I replaced
definitions of xhci_dbg, xhci_info, xhci_err and xhci_warn in the
following manner:
#define xhci_dbg(xhci, fmt, args...) \
do { printk(KERN_ALERT "XHCI %s: " fmt, __FUNCTION__, ## args); } while(0)

Some additional thoughts:

> The piece of code you pointed out only affects single-segment
> transfer rings. I think the kernel generally switched to using
> multi-segment transfer rings for everything in commit 2fdcd47b69
> "xHCI: Allocate 2 segments for transfer ring", which explains why
> the problem doesn't affect kernels after 3.2

Does this mean that in kernels after 3.2 the problematic code line
(that toggles new_cycle_state) is never executed, i.e. dead code?

> [...] in the old code, it [state->new_deq_ptr] refers to the
> actual, final "new dequeue pointer" (the TRB that the ring will be
> set to start at with the Set TR Dequeue Pointer command), which
> should be one after cur->last_trb.

Looking at the debug output, this appears to be happening in the new
version as well, at least in this particular case.

I will be on vacation for the rest of this week and the next one.
I will try to answer emails, but unfortunately testing will have to
wait until July 14th, when I am back.

Thanks a lot
Maciej Puzio
--
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] phy: omap-usb2: Balance pm_runtime_enable() on probe failure

On 07/03/2014 04:31 PM, Kishon Vijay Abraham I wrote:
> Hi Roger,
> 
> On Wednesday 02 July 2014 05:33 PM, Roger Quadros wrote:
>> If probe fails then we need to call pm_runtime_disable() to balance
>> out the previous pm_runtime_enable() call. Else it will cause
>> unbalanced pm_runtime_enable() call in the succeding probe call.
>>
>> This anomaly was observed when the call to devm_phy_create() failed
>> with -EPROBE_DEFER.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/phy/phy-omap-usb2.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
>> index 7007c11..c6f9809 100644
>> --- a/drivers/phy/phy-omap-usb2.c
>> +++ b/drivers/phy/phy-omap-usb2.c
>> @@ -265,15 +265,19 @@ static int omap_usb2_probe(struct platform_device 
>> *pdev)
>>  pm_runtime_enable(phy->dev);
>>  
>>  generic_phy = devm_phy_create(phy->dev, &ops, NULL);
>> -if (IS_ERR(generic_phy))
>> +if (IS_ERR(generic_phy)) {
>> +pm_runtime_disable(phy->dev);
>>  return PTR_ERR(generic_phy);
>> +}
> 
> Maybe we can move pm_runtime_enable to just before phy_provider_register?

OK. will try that.

>>  
>>  phy_set_drvdata(generic_phy, phy);
>>  
>>  phy_provider = devm_of_phy_provider_register(phy->dev,
>>  of_phy_simple_xlate);
>> -if (IS_ERR(phy_provider))
>> +if (IS_ERR(phy_provider)) {
>> +pm_runtime_disable(phy->dev);
>>  return PTR_ERR(phy_provider);
>> +}
> 
> Noticed pm_runtime_disable was missing in omap_usb2_remove too. Would be good
> to fix it here.
> 

Fine, I'll add it there.

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

Re: [PATCH] USB: EHCI: don't allocate hardware periodic table atomically by default

On Thu, 3 Jul 2014, Vladimir Zapolskiy wrote:

> ehci_mem_init() is executed one time during ehci_init() and by default
> all memory allocations but ehci->periodic are done not atomically,
> GFP_KERNEL is passed as flags parameter.
> 
> Do similar allocation for ehci->periodic and free some space in
> coherent atomic DMA pool by default.
> 
> Cc: Alan Stern 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Vladimir Zapolskiy 
> 
> ---
>  drivers/usb/host/ehci-mem.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
> index c0fb6a8..b6205fa 100644
> --- a/drivers/usb/host/ehci-mem.c
> +++ b/drivers/usb/host/ehci-mem.c
> @@ -209,7 +209,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
> flags)
>   ehci->periodic = (__le32 *)
>   dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
>   ehci->periodic_size * sizeof(__le32),
> - &ehci->periodic_dma, 0);
> + &ehci->periodic_dma, flags);
>   if (ehci->periodic == NULL) {
>   goto fail;
>   }

Acked-by: Alan Stern 

Please make the same change in ohci-hcd.c and uhci-hcd.c.

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: Chipidea gadget unplug/disconnect event

2014-07-03 Thread Michael Grzeschik

On Thu, Jul 03, 2014 at 01:19:21AM +, Peter Chen wrote:
>  
> > 
> > Is it possible to get the chipidea to generate an event on udc unplugging?
> > 
> 
> Yes, it has already implemented at ci_usc_vbus_session.
> 
> > I see the code path in ci_udc_vbus_session of udc.c to trigger such an
> > event, but unfortunately it was never possible to run into that code.
> > 
> > The function ci_otg_work in otg.c is prepared to do that in case the irq
> > got triggered by OTGSC_BSVIS bit change.
> > 
> > This is true for plugging, but never happened to be called on unplugging.
> > Is there anything missing to get this working? Or is this completely
> > impossible by the core? I was already fiddling around with the other irq
> > cases OTGSC_*IE, but never got anything useful.
> 
> Once the vbus lower than B_SESSION_VALID, it will trigger (set OTGSC_BSVIS 
> too)
> BSV interrupt.

By theory! ;)

> Check your vbus after unplugging please.

Today I measured the voltage level on vbus and it still had ~2.6V while
being not connected to anything.

> > I am working on the imx25 otg capable SoC.

I validated this with two different imx25 boards and realized,
that we have this external vbus divider errata for that SoC.

Errata: ENGcm09152

Its likely that the issue is related to this problem as the vbus was
not connected to anything different, than the SoC in that case.

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: EHCI: don't allocate hardware periodic table atomically by default

ehci_mem_init() is executed one time during ehci_init() and by default
all memory allocations but ehci->periodic are done not atomically,
GFP_KERNEL is passed as flags parameter.

Do similar allocation for ehci->periodic and free some space in
coherent atomic DMA pool by default.

Cc: Alan Stern 
Cc: Greg Kroah-Hartman 
Signed-off-by: Vladimir Zapolskiy 

---
 drivers/usb/host/ehci-mem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
index c0fb6a8..b6205fa 100644
--- a/drivers/usb/host/ehci-mem.c
+++ b/drivers/usb/host/ehci-mem.c
@@ -209,7 +209,7 @@ static int ehci_mem_init (struct ehci_hcd *ehci, gfp_t 
flags)
ehci->periodic = (__le32 *)
dma_alloc_coherent (ehci_to_hcd(ehci)->self.controller,
ehci->periodic_size * sizeof(__le32),
-   &ehci->periodic_dma, 0);
+   &ehci->periodic_dma, flags);
if (ehci->periodic == NULL) {
goto fail;
}
-- 
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 0/6] usb: gadget: Delete __init marker for probe

2014-07-03 Thread Felipe Balbi

On Tue, Jul 01, 2014 at 04:50:21AM +, Peter Chen wrote:
>  
> > On Sun, May 18, 2014 at 03:19:01PM +0800, Peter Chen wrote:
> > > The probe function may be probed deferal and called after .init
> > > section has freed.
> > >
> > > Peter Chen (6):
> > >   usb: gadget: atmel_usba_udc: delete __init marker for probe
> > >   usb: gadget: fsl_udc_core: delete __init marker for probe
> > >   usb: gadget: lpc32xx: delete __init marker for probe
> > >   usb: gadget: m66592-udc: delete __init marker for probe
> > >   usb: gadget: fusb300_udc: delete __init marker for probe
> > >   usb: gadget: r8a66597-udc: delete __init marker for probe
> > >
> > >  drivers/usb/gadget/atmel_usba_udc.c |2 +-
> > >  drivers/usb/gadget/fsl_udc_core.c   |6 +++---
> > >  drivers/usb/gadget/fusb300_udc.c|2 +-
> > >  drivers/usb/gadget/lpc32xx_udc.c|2 +-
> > >  drivers/usb/gadget/m66592-udc.c |2 +-
> > >  drivers/usb/gadget/r8a66597-udc.c   |4 ++--
> > >  6 files changed, 9 insertions(+), 9 deletions(-)
> > >
> > > --
> > > 1.7.8
> > >
> > 
> > Hi Felipe,
> > 
> > How about the this patch set?
> > 
> > --
>  
> ping again...

in my testing/next

-- 
balbi


signature.asc
Description: Digital signature

Re: USB keyboard on T100TA dock blocks system entering S3 when remote wakeup is enabled

On Thu, 3 Jul 2014, Lu, Baolu wrote:

> Hi,
> 
> I am using an ASUS T100TA with dock attached. I installed Ubuntu Linux 
> on eMMC and customized the kernel.
> 
> I started from "echo mem > /sys/power/state". Kernel starts its 
> processes to put the system into suspend mode. Before kernel executes to 
> xhci_bus_suspend(), xHC USB 2 root hub port (where keyboard on dock 
> connected) reports a port resume event. In response of this event, xHCI 
> roothub driver sets the corresponding bit in bus_state->resuming_ports 
> and intent to clear it when hcd->rh_timer expires 20ms later.
> 
> handle_port_status():
> 
>  xhci_dbg(xhci, "resume HS port %d\n", port_id);
>  bus_state->resume_done[faked_port_index] = 
> jiffies +
>  msecs_to_jiffies(20);
>  set_bit(faked_port_index, 
> &bus_state->resuming_ports);
>  mod_timer(&hcd->rh_timer,
> bus_state->resume_done[faked_port_index]);
> 
> When system executes to xhci_bus_suspend(), it checks 
> bus_state->resuming_ports. It stops here since bus_state->resuming_ports 
> has been set.
> 
> xhci_bus_suspend():
> 
>  if (hcd->self.root_hub->do_remote_wakeup) {
>  if (bus_state->resuming_ports) {
>  spin_unlock_irqrestore(&xhci->lock, flags);
>  xhci_dbg(xhci, "%s: suspend failed because "
>  "a port is resuming\n", 
> __func__);
>  return -EBUSY;
>  }
>  }
> 
> This failure can always be reproduced when I use the keyboard on T100TA 
> dock. But it doesn't show up with an external USB keyboard. Does anybody 
> have any hints for me?

It's possible that commit d6236f6d1d88 in the usb-linus branch of Greg 
KH's USB git tree may be relevant here.  It's a long shot, though.

Basically, it sounds like a bug in the dock hardware.

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][RFC] USB: zerocopy support for usbfs

On Thu, 3 Jul 2014, Stefan Klug wrote:

> >> Questions/Notes:
> >> - I'm quite unhappy with the added member async::is_user_mem. Is there a
> >> better place
> >> where I could store this information?
> > No, async is the right place.  Why are you unhappy about it?
> A whole byte for this flag felt a bit like an overkill, but I'm fine 
> with that.

It's not a big deal.  Besides, the structure has to be padded to at 
least 4-byte alignment anyway.

> >> - I had a look at some other drivers using the get_user_pages ->
> >> sg_set_page -> page_cache_release
> >> technique and didn't see any special code to handle corner cases.
> >> Are there corner cases? - Like usb controllers not supporting the
> >> whole memory etc. ?
> > Indeed yes.  The page addresses have to be checked against the DMA
> > mask.  Also, many host controllers cannot handle arbitrary alignment.
> > It would be best to require that the buffer start at a page boundary.
> 
> Is there any way to check if the host controller supports arbitrary 
> alignment?

No.  Besides, if there were and you made use of it then users would
find that zerocopy worked correctly on some computers and did not work
(i.e., fell back to copying) mysteriously on others.  Not a good
situation.

> If I read the xhci spec correctly arbitrary alignment is explicitly 
> permitted.

Not all host controllers are xHCI.

>  In my use case
> the user allocates large amounts of memory, which is passed down to 
> submiturb in smaller chunks.

The user could allocate a little more memory than needed, so that the 
start of each transfer buffer could be rounded up to a page boundary 
within the memory region.

> So asking the kernel for aligned memory for every chunk would force me 
> to recombine to urbs on the user side,
> adding another copy operation.

Not necessarily.  See above.

> So I would vote for a solution where the 
> user can allocate the memory and pass it down
> without restrictions.
> The system should fallback to copying in kernel space, if the buffer is 
> not supported by the
> host-controller (but this is only the case for USB 2 and 1, right?).

Well, it's the case for non-xHCI.  Your choice of words is ambiguous,
because xHCI supports USB-1 and USB-2 as well as USB-3.

> > Using a global module parameter to control the use of zerocopy (for
> > anything other than debugging or testing) is a bad idea.  If you think
> > people will have a reason for avoiding zerocopy then you should make it
> > possible to decide for each URB, by adding a new flag to struct
> > usbdevfs_urb.
> 
> I'd like to leave the parameter in for debugging purposes mostly, at 
> least as long as this is not stable.

Then add a comment and an explanation in the patch description that the 
module parameter is meant for debugging.

> And it is a security measure. If anything goes wrong with zerocopy (are 
> there buggy host-controllers out there?),
> the user is able to disable it on a system wide basis.

Yes, there are buggy host controllers.  But I don't see how disabling 
zerocopy would improve security.  Buggy hardware can mess things up 
even if zerocopy isn't used.

> > People will want to use zerocopy with isochronous transfers as well as
> > bulk.  Implementing that isn't going to be quite so easy; it will be
> > necessary for the user to set up a memory mapping.  In fact, once
> > that's done the same mechanism could be used for bulk transfers too.
> >
> Yes you are right. I'll look into that. Is this a either both or nothing 
> decision?

It doesn't have to be.  If both mechanisms are present, users could get 
the benefit of zerocopy without the need for setting up a memory 
mapping.

Some patches along this line were posted last fall by Markus 
Rechberger.  See

http://marc.info/?l=linux-usb&m=138046339714340&w=2

and the following messages in that thread.

> As I don't use isochronous transfers at all, it will be quite difficult 
> for me to correctly test that.

That is a problem.  By far the most common uses for isochronous are
audio and video, and customizing user programs for those applications
isn't easy.

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 5/6] phy: omap-usb2: Balance pm_runtime_enable() on probe failure

2014-07-03 Thread Kishon Vijay Abraham I

Hi Roger,

On Wednesday 02 July 2014 05:33 PM, Roger Quadros wrote:
> If probe fails then we need to call pm_runtime_disable() to balance
> out the previous pm_runtime_enable() call. Else it will cause
> unbalanced pm_runtime_enable() call in the succeding probe call.
> 
> This anomaly was observed when the call to devm_phy_create() failed
> with -EPROBE_DEFER.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/phy/phy-omap-usb2.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
> index 7007c11..c6f9809 100644
> --- a/drivers/phy/phy-omap-usb2.c
> +++ b/drivers/phy/phy-omap-usb2.c
> @@ -265,15 +265,19 @@ static int omap_usb2_probe(struct platform_device *pdev)
>   pm_runtime_enable(phy->dev);
>  
>   generic_phy = devm_phy_create(phy->dev, &ops, NULL);
> - if (IS_ERR(generic_phy))
> + if (IS_ERR(generic_phy)) {
> + pm_runtime_disable(phy->dev);
>   return PTR_ERR(generic_phy);
> + }

Maybe we can move pm_runtime_enable to just before phy_provider_register?
>  
>   phy_set_drvdata(generic_phy, phy);
>  
>   phy_provider = devm_of_phy_provider_register(phy->dev,
>   of_phy_simple_xlate);
> - if (IS_ERR(phy_provider))
> + if (IS_ERR(phy_provider)) {
> + pm_runtime_disable(phy->dev);
>   return PTR_ERR(phy_provider);
> + }

Noticed pm_runtime_disable was missing in omap_usb2_remove too. Would be good
to fix it here.

Cheers
Kishon
--
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: Problem with Mobile Broadband on ubuntu

2014-07-03 Thread Oliver Neukum

On Thu, 2014-07-03 at 18:19 +0530, arun wrote:
> Hello,
> I am on Ubuntu 12.04, and am trying to install a USB dongle with a
> 3-g simcard. I have D-link 156 dongle.
> 
> I do the following 2:
> - dpkg -i .deb
> - usb_modeswitch ...
> 
> after this, i am not able to locate the driver in Network Manager.
> 
> If i do dmesg, it says:
> usbserial_generic 1-1.3:1.5: Tell linux-usb@vger.kernel.org to add
> your device to a proper driver.

Please post at least lsusb -v

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

Problem with Mobile Broadband on ubuntu

2014-07-03 Thread arun

Hello,
I am on Ubuntu 12.04, and am trying to install a USB dongle with a
3-g simcard. I have D-link 156 dongle.

I do the following 2:
- dpkg -i .deb
- usb_modeswitch ...

after this, i am not able to locate the driver in Network Manager.

If i do dmesg, it says:
usbserial_generic 1-1.3:1.5: Tell linux-usb@vger.kernel.org to add
your device to a proper driver.

hence emailing you.

Thanks,
Arun
--
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: usbfs could not found

2014-07-03 Thread Peter Stuge

Hi Niyazi,

Niyazi Sırt wrote:
> I had kernel-3.4.52, libusb-0.1.12 and usbutils-0.71
> on my centos and lsusb command was working properly.
> After I upgraded kernel-3.14.9 and also upgraded
> libusb-static-1.0.9, libusb-1.0.9, libusb-devel-1.0.9
> and usbutils-006 rpm packages, lsusb command stopped
> working and I started getting an output like this:
>
> libusb: 0.00 error [op_init] could not find usbfs
> unable to initialize libusb: -99

Ouch. Sorry to hear about that.


> I know that there is no CONFIG_USB_DEVICEFS parameter
> in kernel parameters newer than 3.5 kernels. So what
> should I do? Should I compile the kernel with new
> parameters or write codes for libusb-1.0. Can you
> offer a solution?

What is your hotplug/udev situation like?

udevd is supposed to create /dev/bus/usb/*/* which libusb-1.0.9 finds.

Maybe your centos udev is too old to create those?


> Note: I have compiled kernel-3.14.9 so I put kernel
> parameters about usb config below:

This looks fine, although there are some unneccessary modules.


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

usbfs could not found

2014-07-03 Thread Niyazi Sırt


Hi,

I had kernel-3.4.52, libusb-0.1.12 and usbutils-0.71
on my centos and lsusb command was working properly.
After I upgraded kernel-3.14.9 and also upgraded
libusb-static-1.0.9, libusb-1.0.9, libusb-devel-1.0.9
and usbutils-006 rpm packages, lsusb command stopped
working and I started getting an output like this:

libusb: 0.00 error [op_init] could not find usbfs
unable to initialize libusb: -99

I know that there is no CONFIG_USB_DEVICEFS parameter
in kernel parameters newer than 3.5 kernels. So what
should I do? Should I compile the kernel with new
parameters or write codes for libusb-1.0. Can you
offer a solution?

Note: I have compiled kernel-3.14.9 so I put kernel
parameters about usb config below:

$ cat .config | grep -i usb | grep -v \#
CONFIG_BT_HCIBFUSB=m
CONFIG_CAIF_USB=m
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_AX88179_178A=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_CDC_NCM=m
CONFIG_USB_NET_HUAWEI_CDC_NCM=m
CONFIG_USB_NET_CDC_MBIM=m
CONFIG_USB_NET_DM9601=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_ZD1201=m
CONFIG_USBPCWATCHDOG=m
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
CONFIG_USB_HID=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_DEFAULT_PERSIST=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_OTG=y
CONFIG_USB_OTG_WHITELIST=y
CONFIG_USB_MON=y
CONFIG_USB_WUSB_CBAF=m
CONFIG_USB_WUSB_CBAF_DEBUG=y
CONFIG_USB_XHCI_HCD=m
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=m
CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_FUSBH200_HCD=m
CONFIG_USB_FOTG210_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_HCD_PCI=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_CS=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_WDM=m
CONFIG_USB_TMC=m
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_WWAN=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_LED=m
CONFIG_USB_IDMOUSE=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
CONFIG_USB_TEST=m
CONFIG_USB_EZUSB_FX2=m
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_DEBUG_FILES=y
CONFIG_USB_GADGET_DEBUG_FS=y
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
CONFIG_USB_FOTG210_UDC=m
CONFIG_USB_GR_UDC=m
CONFIG_USB_R8A66597=m
CONFIG_USB_NET2280=m
CONFIG_USB_DUMMY_HCD=m
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_F_ACM=m
CONFIG_USB_F_SS_LB=m
CONFIG_USB_U_SERIAL=m
CONFIG_USB_U_ETHER=m
CONFIG_USB_F_SERIAL=m
CONFIG_USB_F_OBEX=m
CONFIG_USB_F_NCM=m
CONFIG_USB_F_ECM=m
CONFIG_USB_F_EEM=m
CONFIG_USB_F_SUBSET=m
CONFIG_USB_F_RNDIS=m
CONFIG_USB_F_MASS_STORAGE=m
CONFIG_USB_F_FS=m
CONFIG_USB_CONFIGFS=m
CONFIG_USB_CONFIGFS_SERIAL=y
CONFIG_USB_CONFIGFS_ACM=y
CONFIG_USB_CONFIGFS_OBEX=y
CONFIG_USB_CONFIGFS_NCM=y
CONFIG_USB_CONFIGFS_ECM=y
CONFIG_USB_CONFIGFS_ECM_SUBSET=y
CONFIG_USB_CON

Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss

2014-07-03 Thread Sekhar Nori

On Wednesday 02 July 2014 04:56 PM, Roger Quadros wrote:
> Sekhar,
> 
> On 06/18/2014 02:19 PM, Rajendra Nayak wrote:
>> On Wednesday 18 June 2014 04:40 PM, Roger Quadros wrote:
>>> + Nishant and Rajendra for review.
>>>
>>> On 05/05/2014 12:54 PM, Roger Quadros wrote:
 Add the sysconfig class bits for the Super Speed USB
 controllers

 CC: Paul Walmsley 
 Signed-off-by: Roger Quadros 
>>
>> verified against TRM version vP, looks good to me.
>> Reviewed-by: Rajendra Nayak 
> 
> Could you please give your Tested-by tag for this? Then we can take this into 
> 3.16-rc.

Boot tested on my DRA7x EVM.

Boot log here: http://paste.ubuntu.com/7741337/

Tested-by: Sekhar Nori 

Thanks,
Sekhar
--
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

USB keyboard on T100TA dock blocks system entering S3 when remote wakeup is enabled

2014-07-03 Thread Lu, Baolu


Hi,

I am using an ASUS T100TA with dock attached. I installed Ubuntu Linux 
on eMMC and customized the kernel.


I started from "echo mem > /sys/power/state". Kernel starts its 
processes to put the system into suspend mode. Before kernel executes to 
xhci_bus_suspend(), xHC USB 2 root hub port (where keyboard on dock 
connected) reports a port resume event. In response of this event, xHCI 
roothub driver sets the corresponding bit in bus_state->resuming_ports 
and intent to clear it when hcd->rh_timer expires 20ms later.


handle_port_status():

xhci_dbg(xhci, "resume HS port %d\n", port_id);
bus_state->resume_done[faked_port_index] = 
jiffies +

msecs_to_jiffies(20);
set_bit(faked_port_index, 
&bus_state->resuming_ports);

mod_timer(&hcd->rh_timer,
bus_state->resume_done[faked_port_index]);

When system executes to xhci_bus_suspend(), it checks 
bus_state->resuming_ports. It stops here since bus_state->resuming_ports 
has been set.


xhci_bus_suspend():

if (hcd->self.root_hub->do_remote_wakeup) {
if (bus_state->resuming_ports) {
spin_unlock_irqrestore(&xhci->lock, flags);
xhci_dbg(xhci, "%s: suspend failed because "
"a port is resuming\n", 
__func__);

return -EBUSY;
}
}

This failure can always be reproduced when I use the keyboard on T100TA 
dock. But it doesn't show up with an external USB keyboard. Does anybody 
have any hints for me?


Regards,
-baolu
--
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/6] phy: core: Support regulator supply for PHY power

From: Roger Quadros 

Some PHYs can be powered by an external power regulator.
e.g. USB_HS PHY on DRA7 SoC. Make the PHY core support a
power regulator.

Signed-off-by: Roger Quadros 
---
 drivers/phy/phy-core.c  | 27 +++
 include/linux/phy/phy.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 49c4465..2add59c 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static struct class *phy_class;
 static DEFINE_MUTEX(phy_provider_mutex);
@@ -226,6 +227,12 @@ int phy_power_on(struct phy *phy)
if (!phy)
return 0;
 
+   if (phy->pwr) {
+   ret = regulator_enable(phy->pwr);
+   if (ret)
+   return ret;
+   }
+
ret = phy_pm_runtime_get_sync(phy);
if (ret < 0 && ret != -ENOTSUPP)
return ret;
@@ -247,6 +254,8 @@ int phy_power_on(struct phy *phy)
 out:
mutex_unlock(&phy->mutex);
phy_pm_runtime_put_sync(phy);
+   if (phy->pwr)
+   regulator_disable(phy->pwr);
 
return ret;
 }
@@ -272,6 +281,9 @@ int phy_power_off(struct phy *phy)
mutex_unlock(&phy->mutex);
phy_pm_runtime_put(phy);
 
+   if (phy->pwr)
+   regulator_disable(phy->pwr);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(phy_power_off);
@@ -588,6 +600,16 @@ struct phy *phy_create(struct device *dev, const struct 
phy_ops *ops,
goto free_phy;
}
 
+   /* phy-supply */
+   phy->pwr = regulator_get_optional(dev, "phy");
+   if (IS_ERR(phy->pwr)) {
+   if (PTR_ERR(phy->pwr) == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   goto free_ida;
+   }
+   phy->pwr = NULL;
+   }
+
device_initialize(&phy->dev);
mutex_init(&phy->mutex);
 
@@ -617,6 +639,9 @@ put_dev:
put_device(&phy->dev);  /* calls phy_release() which frees resources */
return ERR_PTR(ret);
 
+free_ida:
+   ida_simple_remove(&phy_ida, phy->id);
+
 free_phy:
kfree(phy);
return ERR_PTR(ret);
@@ -664,6 +689,7 @@ EXPORT_SYMBOL_GPL(devm_phy_create);
 void phy_destroy(struct phy *phy)
 {
pm_runtime_disable(&phy->dev);
+   regulator_put(phy->pwr);
device_unregister(&phy->dev);
 }
 EXPORT_SYMBOL_GPL(phy_destroy);
@@ -800,6 +826,7 @@ static void phy_release(struct device *dev)
 
phy = to_phy(dev);
dev_vdbg(dev, "releasing '%s'\n", dev_name(dev));
+   regulator_put(phy->pwr);
ida_simple_remove(&phy_ida, phy->id);
kfree(phy);
 }
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2760744..9a86945 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct phy;
 
@@ -65,6 +66,7 @@ struct phy {
int init_count;
int power_count;
struct phy_attrsattrs;
+   struct regulator*pwr;
 };
 
 /**
-- 
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/6] ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on

From: Roger Quadros 

After clarification from the hardware team it was found that
this 1.8V PHY supply can't be switched OFF when SoC is Active.

Since the PHY IPs don't contain isolation logic built in the design to
allow the power rail to be switched off, there is a very high risk
of IP reliability and additional leakage paths which can result in
additional power consumption.

The only scenario where this rail can be switched off is part of Power on
reset sequencing, but it needs to be kept always-on during operation.

This patch is required for proper functionality of USB, SATA
and PCIe on DRA7-evm.

CC: Rajendra Nayak 
CC: Tero Kristo 
Signed-off-by: Roger Quadros 
---
 arch/arm/boot/dts/dra7-evm.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..8308954 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -240,6 +240,7 @@
regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-always-on;
regulator-boot-on;
};
 
-- 
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

Re:Re:Re: Re: Re:Re: move ZTE CDMA device pid from zte_ev.c back to option.c and modify a parameter in zte_ev.ko

2014-07-03 Thread 刘磊


Dear johan&Williams
As we discuss about the question of zte_ev.c, are you  sure how to modify.
Looking forward to your reply. thanks.


lei.liu


At 2014-06-25 04:35:28, "刘磊"  wrote:
>
>
>At 2014-06-24 09:46:01, "Johan Hovold"  wrote:
>>On Tue, Jun 24, 2014 at 08:43:36PM +0800, 刘磊 wrote:
>>> At 2014-06-23 10:49:14, "Johan Hovold"  wrote:
>>> >On Mon, Jun 23, 2014 at 09:42:08AM -0500, Dan Williams wrote:
>>> >> On Mon, 2014-06-23 at 18:15 +0800, 刘磊 wrote:
>>
>>> >> > i don't know why create the file of zte_ev.c that is not
>>> >> > necessary. i suggest we can move all the pid from zte_ev.c to
>>> >> > option.c.
>>> >> 
>>> >> The file is derived from the zte_ev.c that was distributed by ZTE
>>> >> themselves in the "ztemtApp" software for 0xffeb -> 0x, 0x3917,
>>> >> 0x6000, and 0x9008, which include the AC8700, AC8710, MG880, AC2726,
>>> >> AC8710_V3, AC2716, and a bunch of other CDMA devices.  They were
>>> >> originally driven by option, but users were having problems with that
>>> >> and I think people thought that maybe the "official" ZTE drivers would
>>> >> work better.
>>> >> 
>>> >> I would like to move them to option if we can, and get rid of zte_ev.c,
>>> >> but to do that we must understand what zte_ev.c was actually trying to
>>> >> do so that we ensure that option can do it too.
>>> >
>>> >I fully agree. If these ZTE devices still work with the two patches I
>>> >sent, they could probably still work without the remaining
>>> >SET_LINE_CODING (9600 8N1), and in that case there really isn't any
>>> >difference to the option driver (control-message wise).
>>> 
>>> the pid in zte_ev.c beloging to the various subsidiaries of ZTE. 
>>> Now i can confirm the id of fffe,,fffed,fffeb can work fine in 
>>> option.c. 
>>> the id from fff9 to fffb and ffee belonging other subsidiaries, we
>>> asked and they did not create the file of zte_ev.c. 
>>> and the other id of 0x05C6 may belong to Qualcomm, I don't think it
>>> add by Qualcomm.
>>
>>It sounds like it's time to drop zte_ev and move all PIDs back to
>>option. The magic setup packets turned out to not do anything magic (and
>>still failed to get it right, with respect to the interface argument),
>>while everything appears to work fine, or rather better (e.g. DTR/RTS),
>>with the generic option driver.
>>
>>If someone wants to do an effective revert of commit 73228a0538a7 ("USB:
>>option,zte_ev: move most ZTE CDMA devices to zte_ev") (i.e. make sure to
>>restore PID defines and quirks) and then move the remaining PIDs added
>>by 799ee9243d89 ("USB: serial: add zte_ev.c driver") before removing the
>>driver, I'll take those patches.
>>
>>Anyone against?
>
>commit 799ee9243d89 ("USB: serial: add zte_ev.c driver") 
>i had see the commit, the file of zte_ev.c is modify according to the drive of 
>our company, 
>the drive was used in the old linux version when the pid was not add in 
>option.c.
>
>commit 73228a0538a7 ("USB:option,zte_ev: move most ZTE CDMA devices to zte_ev")
>the commit had been add the rest of the pid to zte_ev.c, the pid moved into 
>zte_ev.c  is the same as our company early driver.
>
>
>>
>>Thanks,
>>Johan

RE: [PATCH][RFC] USB: zerocopy support for usbfs

2014-07-03 Thread David Laight

From: Stefan Klug
...
> Is there any way to check if the host controller supports arbitrary
> alignment?
> If I read the xhci spec correctly arbitrary alignment is explicitly
> permitted.

Not entirely.
The xhci spec has a few limits on the alignment of transfer buffer.
They seem to be designed to make life difficult for the kernel!
1) Transfer buffers cannot be longer than 64k.
2) Transfer buffers cannot cross 64k address boundaries.
3) The end of a ring segment must occur on a USB packet boundary.

The current xhci driver doesn't implement check 3 - which causes
certain devices to fail (notable the ax88179_178a usb3 ethernet).

David

Re: [PATCH 2/2 v5] HID: leds: move led_mode attribute to led-class devices in MSI GT683R driver

2014-07-03 Thread Johan Hovold

On Wed, Jul 02, 2014 at 08:37:59PM +0300, Janne Kanniainen wrote:
> Move led_mode attribute from HID device to led-class devices. This will also 
> fix race condition by using attribute-groups.
> 
> Signed-off-by: Janne Kanniainen 

Looks good now. Thanks!

Perhaps you can resend both patches as a series (call both v6) so it's
easy to figure which version that is to be applied.

I also noticed that your subject line is a bit long (will end up as the
commit summary). Using for example

HID: gt683r: move mode attribute to led-class devices

would make it more concise.

Oh, and your commit message lacks line breaks (around 72 cols). You
could fix that as well.

Thanks again,
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][RFC] USB: zerocopy support for usbfs

2014-07-03 Thread Stefan Klug

On 02.07.2014 21:38, Alan Stern wrote:

On Wed, 2 Jul 2014, Oliver Neukum wrote:

Stefan Klug
Software Developer

Basler AG
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 4102 463 582
Fax +49 4102 463 46 582

stefan.k...@baslerweb.com

www.baslerweb.com

Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) · John P. Jennings · Arndt Bake ·
Hardy Mehl
Aufsichtsratsvorsitzender: Norbert Basler
Basler AG · Amtsgericht Lübeck HRB 4090 · Ust-IdNr.: DE 135 098 121 · Steuer-Nr.: 30 292 04497 · WEEE-Reg.-Nr. DE 83888045

On Wed, 2014-07-02 at 17:53 +0200, Stefan Klug wrote:

Implementation details:
The patch only touches drivers/usb/core/devio.c.
In procy_do_submiturb(), it is checked if zerocopy is allowed. This is
currently a rough
check which compares the number of required pages to
ps->dev->bus->sg_tablesize.

It seems to me that the check is per call, so using
multiple calls one could still pin unlimited amounts
of memory.

usbfs keeps track of the total amount of pinned memory and enforces an
overall limit. It will be necessary to add the size of the transfer
buffer to that total.
Leaving the zerocopy transfers out of this limit was intentional. I
thought this is user-memory so we shouldn't add it to the overall limit
as it is not allocated by usbfs.
But I didn't think of the pinning problem. So yes, I can add it to the
overall limit.

I don't know if there is more to check there.
Then the user memory provided inside the usbdevfs_urb structure is
pinned to
physical memory using get_user_pages_fast().
All the user pages are added to the scatter-gather list and the logic
continues as before.

How do you enforce the cache coherency rules?

There is no way to do this. If the user program accesses memory when
it shouldn't, the transfer might not work right.

So this one is fine, right?

Also you don't have a fall back if get_user_pages_fast()
returns less than requested. It seems to me that than you
ought to fall back buffered IO.

Agreed.

Good point. I'll add the fallback to the next iteration.
--
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] phy: core: Support regulator supply for PHY power