Re: [PATCH v2 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC

[Felipe Balbi]

Krzysztof Kozlowski  writes:

> On Tue, May 15, 2018 at 2:12 PM, Andrzej Hajda  wrote:
>> OF graph describes USB data lanes between USB-PHY and respective MUIC.
>> Since graph is present and DWC driver can use it to get extcon, obsolete
>> extcon property can be removed.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  .../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> As we discussed for v1 - since this was not split into two, I'll apply
> it once first patch hits mainline.

I just took patch 1 to my tree, fyi

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/2] Convert target drivers to use sbitmap

[Felipe Balbi]

Hi,

Matthew Wilcox  writes:
> From: Matthew Wilcox 
>
> The sbitmap and the percpu_ida perform essentially the same task,
> allocating tags for commands.  Since the sbitmap is more used than
> the percpu_ida, convert the percpu_ida users to the sbitmap API.
>
> Signed-off-by: Matthew Wilcox 
> ---

[...]

>  drivers/usb/gadget/function/f_tcm.c  |  8 +++---

for drivers/usb/gadget/function/f_tcm.c

Acked-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usbip: usbip_host: fix bad unlock balance during stub_probe()

[Greg KH]

On Tue, May 15, 2018 at 05:57:23PM -0600, Shuah Khan (Samsung OSG) wrote:
> stub_probe() calls put_busid_priv() in an error path when device isn't
> found in the busid_table. Fix it by making put_busid_priv() safe to be
> called with null struct bus_id_priv pointer.
> 
> This problem happens when "usbip bind" is run without loading usbip_host
> driver and then running modprobe. The first failed bind attempt unbinds
> the device from the original driver and when usbip_host is modprobed,
> stub_probe() runs and doesn't find the device in its busid table and calls
> put_busid_priv(0 with null bus_id_priv pointer.
> 
> usbip-host 3-10.2: 3-10.2 is not in match_busid table...  skip!
> 
> [  367.359679] =
> [  367.359681] WARNING: bad unlock balance detected!
> [  367.359683] 4.17.0-rc4+ #5 Not tainted
> [  367.359685] -
> [  367.359688] modprobe/2768 is trying to release lock (
> [  367.359689]
> ==
> [  367.359696] BUG: KASAN: null-ptr-deref in
> print_unlock_imbalance_bug+0x99/0x110
> [  367.359699] Read of size 8 at addr 0058 by task
> modprobe/2768

Minor nit, no need to line-wrap this.

> [  367.359705] CPU: 4 PID: 2768 Comm: modprobe Not tainted 4.17.0-rc4+ #5
> 
> Fixes: 22076557b07c ("usbip: usbip_host: fix NULL-ptr deref and
> use-after-free errors") in usb-linus

Nor this, and the extra blank line isn't needed here either.  I'll fix
it up by hand when I queue this up later today, thanks.

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

Renesas uPD720202 USB 3.0

[Christian Brauns]

Hi,

I'm not used to writing bug-reports.

From: https://bbs.archlinux.org/viewtopic.php?id=236806, I got adviced to do 
that.

I have an usb 3 controller laptop expresscard
Renesas Technology Corp. uPD720202 USB 3.0 Host Controller (rev 02)
using that in a Lenovo X220 which does not work with the latest kernels.
In a Lenovo R400 it works.

After some testing, I came to the result, that
it was still working in kernel 4.12.7, and stopped working in kernel 4.12.8.

And with some advice and further testing it produces the same (working) results 
in
kernel 4.12.8 with 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c reverted.

(

git checkout v4.12.8
git revert 0e1f0eaed6c20db41ff61e024b361ee3ec9d686c #revert the noted commit
git cherry-pick 854e55ad289efe7991f0ada85d5846f5afb9 #cherry-pick a commit 
needed to build with gcc 8
git cherry-pick ad343a98e74e85aa91d844310e797f96fee6983b
)

There is a post from someone else regarding this controller at:
https://unix.stackexchange.com/questions/440741/install-usb-3-0-express-card-under-linux-arch-linux-tried-adding-kernel-param
who made a bug report here:
https://bugzilla.kernel.org/show_bug.cgi?id=199627



Best
Christian

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

[PATCH v3 1/2] usb: dwc3: use local copy of resource to fix-up register offset

[Masahiro Yamada]

It is not a good idea to directly modify the resource of a platform
device.  Modify its local copy, and pass it to devm_ioremap_resource()
so that we do not need to restore it in the failure path and the remove
hook.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Masami Hiramatsu 
---

Changes in v3: None
Changes in v2: None

 drivers/usb/dwc3/core.c | 32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a15648d..8e66edd 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1245,7 +1245,7 @@ static void dwc3_check_params(struct dwc3 *dwc)
 static int dwc3_probe(struct platform_device *pdev)
 {
struct device   *dev = >dev;
-   struct resource *res;
+   struct resource *res, dwc_res;
struct dwc3 *dwc;
 
int ret;
@@ -1270,20 +1270,19 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->xhci_resources[0].flags = res->flags;
dwc->xhci_resources[0].name = res->name;
 
-   res->start += DWC3_GLOBALS_REGS_START;
-
/*
 * Request memory region but exclude xHCI regs,
 * since it will be requested by the xhci-plat driver.
 */
-   regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(regs)) {
-   ret = PTR_ERR(regs);
-   goto err0;
-   }
+   dwc_res = *res;
+   dwc_res.start += DWC3_GLOBALS_REGS_START;
+
+   regs = devm_ioremap_resource(dev, _res);
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
 
dwc->regs   = regs;
-   dwc->regs_size  = resource_size(res);
+   dwc->regs_size  = resource_size(_res);
 
dwc3_get_properties(dwc);
 
@@ -1350,29 +1349,14 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
 
-err0:
-   /*
-* restore res->start back to its original value so that, in case the
-* probe is deferred, we don't end up getting error in request the
-* memory region the next time probe is called.
-*/
-   res->start -= DWC3_GLOBALS_REGS_START;
-
return ret;
 }
 
 static int dwc3_remove(struct platform_device *pdev)
 {
struct dwc3 *dwc = platform_get_drvdata(pdev);
-   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
pm_runtime_get_sync(>dev);
-   /*
-* restore res->start back to its original value so that, in case the
-* probe is deferred, we don't end up getting error in request the
-* memory region the next time probe is called.
-*/
-   res->start -= DWC3_GLOBALS_REGS_START;
 
dwc3_debugfs_exit(dwc);
dwc3_core_exit_mode(dwc);
-- 
2.7.4

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

[PATCH v3 0/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

In the current design of DWC3 driver,
the DT typically becomes a nested structure like follows:

  dwc3-glue {
  compatible = "foo,dwc3";
  ...

  dwc3 {
  compatible = "snps,dwc3";
  ...
  };
  }

The current DWC3 core (drivers/usb/dwc3/core.c) can not handle
clocks / resets at all.

The only solution we have now, is to put DWC3 core node under
the glue layer node, then add clocks and resets there.
Actually, dwc3-of-simple.c exists to handle clocks and resets.

As always for digital circuits, DWC3 core IP itself needs clock input.
This is specific to this IP.  So, supporting clocks and resets in
dwc3/core.c makes sense.

In this version, the number of clocks (and names) is specific
to this IP, with clock names taken from Synopsys datasheet.


Masahiro Yamada (2):
  usb: dwc3: use local copy of resource to fix-up register offset
  usb: dwc3: support clocks and resets for DWC3 core

 Documentation/devicetree/bindings/usb/dwc3.txt |  21 +
 drivers/usb/dwc3/core.c| 118 +++--
 drivers/usb/dwc3/core.h|   8 ++
 3 files changed, 122 insertions(+), 25 deletions(-)

-- 
2.7.4

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

[PATCH v3 2/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

Historically, the clocks and resets are handled on the glue layer
side instead of the DWC3 core.  For simple cases, dwc3-of-simple.c
takes care of arbitrary number of clocks and resets.  The DT node
structure typically looks like as follows:

  dwc3-glue {
  compatible = "foo,dwc3";
  clocks = ...;
  resets = ...;
  ...

  dwc3 {
  compatible = "snps,dwc3";
  ...
  };
  }

By supporting the clocks and the reset in the dwc3/core.c, it will
be turned into a single node:

  dwc3 {
  compatible = "foo,dwc3", "snps,dwc3";
  clocks = ...;
  resets = ...;
  ...
  }

This commit adds the binding of clocks and resets specific to this IP.
The number of clocks should generally be the same across SoCs, it is
just some SoCs either tie clocks together or do not provide software
control of some of the clocks.

I took the clock names from the Synopsys datasheet: "ref" (ref_clk),
"bus_early" (bus_clk_early), and "suspend" (suspend_clk).

I found only one reset line in the datasheet, hence the reset-names
property is omitted.

Those clocks are required for new platforms.  Enforcing the new
binding breaks existing platforms since they specify clocks (and
resets) in their glue layer node, but nothing in the core node.
I listed such exceptional cases in the DT binding.  The driver
code has been relaxed to accept no clock.  This change is based
on the discussion [1].

I inserted reset_control_deassert() and clk_bulk_enable() before the
first register access, i.e. dwc3_cache_hwparams().

[1] https://patchwork.kernel.org/patch/10284265/

Signed-off-by: Masahiro Yamada 
Reviewed-by: Rob Herring 
---

Changes in v3:
  - Change 'resets' DT property to optional.

Changes in v2:
  - Make clocks specific to this IP based on Synopsys datasheet
  - Use clk_bulk API
  - Add description to struct header

 Documentation/devicetree/bindings/usb/dwc3.txt | 21 ++
 drivers/usb/dwc3/core.c| 88 +-
 drivers/usb/dwc3/core.h|  8 +++
 3 files changed, 115 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 0dbd308..7f13ebe 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -7,6 +7,26 @@ Required properties:
  - compatible: must be "snps,dwc3"
  - reg : Address and length of the register set for the device
  - interrupts: Interrupts used by the dwc3 controller.
+ - clock-names: should contain "ref", "bus_early", "suspend"
+ - clocks: list of phandle and clock specifier pairs corresponding to
+   entries in the clock-names property.
+
+Exception for clocks:
+  clocks are optional if the parent node (i.e. glue-layer) is compatible to
+  one of the following:
+"amlogic,meson-axg-dwc3"
+"amlogic,meson-gxl-dwc3"
+"cavium,octeon-7130-usb-uctl"
+"qcom,dwc3"
+"samsung,exynos5250-dwusb3"
+"samsung,exynos7-dwusb3"
+"sprd,sc9860-dwc3"
+"st,stih407-dwc3"
+"ti,am437x-dwc3"
+"ti,dwc3"
+"ti,keystone-dwc3"
+"rockchip,rk3399-dwc3"
+"xlnx,zynqmp-dwc3"
 
 Optional properties:
  - usb-phy : array of phandle for the PHY device.  The first element
@@ -15,6 +35,7 @@ Optional properties:
  - phys: from the *Generic PHY* bindings
  - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy"
or "usb3-phy".
+ - resets: a single pair of phandle and reset specifier
  - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable
  - snps,disable_scramble_quirk: true when SW should disable data scrambling.
Only really useful for FPGA builds.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 8e66edd..0380a85 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -8,6 +8,7 @@
  * Sebastian Andrzej Siewior 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -266,6 +268,12 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
return 0;
 }
 
+static const struct clk_bulk_data dwc3_core_clks[] = {
+   { .id = "ref" },
+   { .id = "bus_early" },
+   { .id = "suspend" },
+};
+
 /*
  * dwc3_frame_length_adjustment - Adjusts frame length if required
  * @dwc3: Pointer to our controller context structure
@@ -667,6 +675,9 @@ static void dwc3_core_exit(struct dwc3 *dwc)
usb_phy_set_suspend(dwc->usb3_phy, 1);
phy_power_off(dwc->usb2_generic_phy);
phy_power_off(dwc->usb3_generic_phy);
+   clk_bulk_disable(dwc->num_clks, dwc->clks);
+   clk_bulk_unprepare(dwc->num_clks, dwc->clks);
+   reset_control_assert(dwc->reset);
 }
 
 static bool dwc3_core_is_valid(struct dwc3 *dwc)
@@ -1256,6 +1267,12 @@ static int 

RE: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Andy Duan]

From: Florian Fainelli  Sent: 2018年5月16日 7:56
> A number of drivers have the following pattern:
> 
> if (np)
>   of_mdiobus_register()
> else
>   mdiobus_register()
> 
> which the implementation of of_mdiobus_register() now takes care of.
> Remove that pattern in drivers that strictly adhere to it.
> 
> Signed-off-by: Florian Fainelli 

For drivers/net/ethernet/freescale/fec_main.c:

Reviewed-by: Fugang Duan 
> ---
>  drivers/net/dsa/bcm_sf2.c |  8 ++--
>  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>  drivers/net/ethernet/marvell/mvmdio.c |  5 +
>  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
>  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
>  drivers/net/phy/mdio-gpio.c   |  6 +-
>  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>  drivers/net/usb/lan78xx.c |  7 ++-
>  11 files changed, 20 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c index
> ac621f44237a..02e8982519ce 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch
> *ds)
>   priv->slave_mii_bus->parent = ds->dev->parent;
>   priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
> 
> - if (dn)
> - err = of_mdiobus_register(priv->slave_mii_bus, dn);
> - else
> - err = mdiobus_register(priv->slave_mii_bus);
> -
> - if (err)
> + err = of_mdiobus_register(priv->slave_mii_bus, dn);
> + if (err && dn)
>   of_node_put(dn);
> 
>   return err;
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
> b/drivers/net/dsa/mv88e6xxx/chip.c
> index b23c11d9f4b2..2bb3f03ee1cb 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct
> mv88e6xxx_chip *chip,
>   return err;
>   }
> 
> - if (np)
> - err = of_mdiobus_register(bus, np);
> - else
> - err = mdiobus_register(bus);
> + err = of_mdiobus_register(bus, np);
>   if (err) {
>   dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
>   mv88e6xxx_g2_irq_mdio_free(chip, bus); diff --git
> a/drivers/net/ethernet/cadence/macb_main.c
> b/drivers/net/ethernet/cadence/macb_main.c
> index b4c9268100bb..3e93df5d4e3b 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
>   dev_set_drvdata(>dev->dev, bp->mii_bus);
> 
>   np = bp->pdev->dev.of_node;
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> 
> - if (np) {
> - err = of_mdiobus_register(bp->mii_bus, np);
> - } else {
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> -
> - err = mdiobus_register(bp->mii_bus);
> - }
> -
> + err = of_mdiobus_register(bp->mii_bus, np);
>   if (err)
>   goto err_out_free_mdiobus;
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index d4604bc8eb5b..f3e43db0d6cb 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device
> *pdev)
>   fep->mii_bus->parent = >dev;
> 
>   node = of_get_child_by_name(pdev->dev.of_node, "mdio");
> - if (node) {
> - err = of_mdiobus_register(fep->mii_bus, node);
> + err = of_mdiobus_register(fep->mii_bus, node);
> + if (node)
>   of_node_put(node);
> - } else {
> - err = mdiobus_register(fep->mii_bus);
> - }
> -
>   if (err)
>   goto err_out_free_mdiobus;
> 
> diff --git a/drivers/net/ethernet/marvell/mvmdio.c
> b/drivers/net/ethernet/marvell/mvmdio.c
> index 0495487f7b42..c5dac6bd2be4 100644
> --- a/drivers/net/ethernet/marvell/mvmdio.c
> +++ b/drivers/net/ethernet/marvell/mvmdio.c
> @@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device
> *pdev)
>   goto out_mdio;
>   }
> 
> - if (pdev->dev.of_node)
> - ret = of_mdiobus_register(bus, pdev->dev.of_node);
> - else
> - ret = mdiobus_register(bus);
> + ret = of_mdiobus_register(bus, pdev->dev.of_node);
>   if (ret < 0) {
>   dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
>   goto out_mdio;
> diff --git 

Re: [PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Grygorii Strashko]

On 05/15/2018 06:56 PM, Florian Fainelli wrote:

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
  drivers/net/dsa/bcm_sf2.c |  8 ++--
  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
  drivers/net/ethernet/marvell/mvmdio.c |  5 +
  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
  drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-


for drivers/net/ethernet/ti/davinci_mdio.c:
Reviewed-by: Grygorii Strashko 


  drivers/net/phy/mdio-gpio.c   |  6 +-
  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
  drivers/net/usb/lan78xx.c |  7 ++-
  11 files changed, 20 insertions(+), 61 deletions(-)


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

[PATCH net-next v2 1/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Florian Fainelli]

When the device_node specified is NULL, fall back to mdiobus_register().
We have a number of drivers having a similar pattern which is:

if (np)
of_mdiobus_register()
else
mdiobus_register()

so incorporate that behavior within the core of_mdiobus_register()
function. This is also consistent with the stub version that we defined
when CONFIG_OF=n.

Signed-off-by: Florian Fainelli 
---
 drivers/of/of_mdio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 8c0c92712fc9..d963baf8e53a 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -204,6 +204,9 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
bool scanphys = false;
int addr, rc;
 
+   if (!np)
+   return mdiobus_register(mdio);
+
/* Do not continue if the node is disabled */
if (!of_device_is_available(np))
return -ENODEV;
-- 
2.14.1

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

[PATCH] usbip: usbip_host: fix bad unlock balance during stub_probe()

[Shuah Khan (Samsung OSG)]

stub_probe() calls put_busid_priv() in an error path when device isn't
found in the busid_table. Fix it by making put_busid_priv() safe to be
called with null struct bus_id_priv pointer.

This problem happens when "usbip bind" is run without loading usbip_host
driver and then running modprobe. The first failed bind attempt unbinds
the device from the original driver and when usbip_host is modprobed,
stub_probe() runs and doesn't find the device in its busid table and calls
put_busid_priv(0 with null bus_id_priv pointer.

usbip-host 3-10.2: 3-10.2 is not in match_busid table...  skip!

[  367.359679] =
[  367.359681] WARNING: bad unlock balance detected!
[  367.359683] 4.17.0-rc4+ #5 Not tainted
[  367.359685] -
[  367.359688] modprobe/2768 is trying to release lock (
[  367.359689]
==
[  367.359696] BUG: KASAN: null-ptr-deref in
print_unlock_imbalance_bug+0x99/0x110
[  367.359699] Read of size 8 at addr 0058 by task
modprobe/2768

[  367.359705] CPU: 4 PID: 2768 Comm: modprobe Not tainted 4.17.0-rc4+ #5

Fixes: 22076557b07c ("usbip: usbip_host: fix NULL-ptr deref and
use-after-free errors") in usb-linus

Signed-off-by: Shuah Khan (Samsung OSG) 
---

 drivers/usb/usbip/stub_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/stub_main.c b/drivers/usb/usbip/stub_main.c
index 41c7b9de2a92..bf8a5feb0ee9 100644
--- a/drivers/usb/usbip/stub_main.c
+++ b/drivers/usb/usbip/stub_main.c
@@ -82,7 +82,8 @@ struct bus_id_priv *get_busid_priv(const char *busid)
 
 void put_busid_priv(struct bus_id_priv *bid)
 {
-   spin_unlock(>busid_lock);
+   if (bid)
+   spin_unlock(>busid_lock);
 }
 
 static int add_match_busid(char *busid)
-- 
2.14.1

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

[PATCH net-next v2 0/2] of: mdio: Fall back to mdiobus_register() with NULL device_node

[Florian Fainelli]

Hi all,

This patch series updates of_mdiobus_register() such that when the device_node
argument is NULL, it calls mdiobus_register() directly. This is consistent with
the behavior of of_mdiobus_register() when CONFIG_OF=n.

I only converted the most obvious drivers, there are others that have a much
less obvious behavior and specifically attempt to deal with CONFIG_ACPI.

Changes in v2:

- fixed build error in davincin_mdio.c (Grygorii)
- reworked first patch a bit: commit message, subject and removed useless
  code comment

Florian Fainelli (2):
  of: mdio: Fall back to mdiobus_register() with NULL device_node
  drivers: net: Remove device_node checks with of_mdiobus_register()

 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 drivers/of/of_mdio.c  |  3 +++
 12 files changed, 23 insertions(+), 61 deletions(-)

-- 
2.14.1

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

[PATCH net-next v2 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Florian Fainelli]

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  8 +++-
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 11 files changed, 20 insertions(+), 61 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ac621f44237a..02e8982519ce 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
priv->slave_mii_bus->parent = ds->dev->parent;
priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
 
-   if (dn)
-   err = of_mdiobus_register(priv->slave_mii_bus, dn);
-   else
-   err = mdiobus_register(priv->slave_mii_bus);
-
-   if (err)
+   err = of_mdiobus_register(priv->slave_mii_bus, dn);
+   if (err && dn)
of_node_put(dn);
 
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b23c11d9f4b2..2bb3f03ee1cb 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip 
*chip,
return err;
}
 
-   if (np)
-   err = of_mdiobus_register(bus, np);
-   else
-   err = mdiobus_register(bus);
+   err = of_mdiobus_register(bus, np);
if (err) {
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
mv88e6xxx_g2_irq_mdio_free(chip, bus);
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index b4c9268100bb..3e93df5d4e3b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(>dev->dev, bp->mii_bus);
 
np = bp->pdev->dev.of_node;
+   if (pdata)
+   bp->mii_bus->phy_mask = pdata->phy_mask;
 
-   if (np) {
-   err = of_mdiobus_register(bp->mii_bus, np);
-   } else {
-   if (pdata)
-   bp->mii_bus->phy_mask = pdata->phy_mask;
-
-   err = mdiobus_register(bp->mii_bus);
-   }
-
+   err = of_mdiobus_register(bp->mii_bus, np);
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..f3e43db0d6cb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
*pdev)
fep->mii_bus->parent = >dev;
 
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
-   if (node) {
-   err = of_mdiobus_register(fep->mii_bus, node);
+   err = of_mdiobus_register(fep->mii_bus, node);
+   if (node)
of_node_put(node);
-   } else {
-   err = mdiobus_register(fep->mii_bus);
-   }
-
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
b/drivers/net/ethernet/marvell/mvmdio.c
index 0495487f7b42..c5dac6bd2be4 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
goto out_mdio;
}
 
-   if (pdev->dev.of_node)
-   ret = of_mdiobus_register(bus, pdev->dev.of_node);
-   else
-   ret = mdiobus_register(bus);
+   ret = of_mdiobus_register(bus, pdev->dev.of_node);
if (ret < 0) {
dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
goto out_mdio;
diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 5970d9e5ddf1..8dd41e08a6c6 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3025,15 +3025,10 @@ static int sh_mdio_init(struct sh_eth_private *mdp,
 

Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Florian Fainelli]

On 05/15/2018 03:57 PM, Grygorii Strashko wrote:
> 
> 
> On 05/15/2018 04:59 PM, Florian Fainelli wrote:
>> A number of drivers have the following pattern:
>>
>> if (np)
>> of_mdiobus_register()
>> else
>> mdiobus_register()
>>
>> which the implementation of of_mdiobus_register() now takes care of.
>> Remove that pattern in drivers that strictly adhere to it.
>>
>> Signed-off-by: Florian Fainelli 
>> ---
>>   drivers/net/dsa/bcm_sf2.c |  8 ++--
>>   drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
>>   drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
>>   drivers/net/ethernet/freescale/fec_main.c |  8 ++--
>>   drivers/net/ethernet/marvell/mvmdio.c |  5 +
>>   drivers/net/ethernet/renesas/sh_eth.c | 11 +++
>>   drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
>>   drivers/net/ethernet/ti/davinci_mdio.c    |  6 ++
>>   drivers/net/phy/mdio-gpio.c   |  6 +-
>>   drivers/net/phy/mdio-mscc-miim.c  |  6 +-
>>   drivers/net/usb/lan78xx.c |  7 ++-
>>   11 files changed, 19 insertions(+), 60 deletions(-)
>>
> 
> ...
> 
>>   goto bus_register_fail;
>> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c
>> b/drivers/net/ethernet/ti/davinci_mdio.c
>> index 98a1c97fb95e..e720244e7f71 100644
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -431,10 +431,8 @@ static int davinci_mdio_probe(struct
>> platform_device *pdev)
>>    */
>>   if (dev->of_node && of_get_child_count(dev->of_node)) {
> 
> It causes build error due to "{" above.

Humpf, shame on me for not enabling that driver, thanks for catching this!

> 
>>   data->skip_scan = true;
>> -    ret = of_mdiobus_register(data->bus, dev->of_node);
>> -    } else {
>> -    ret = mdiobus_register(data->bus);
>> -    }
>> +
>> +    ret = of_mdiobus_register(data->bus, dev->of_node);
>>   if (ret)
>>   goto bail_out;
>>   diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c
>> index b501221819e1..4e4c8daf44c3 100644
>> --- a/drivers/net/phy/mdio-gpio.c
>> +++ b/drivers/net/phy/mdio-gpio.c
>> @@ -179,11 +179,7 @@ static int mdio_gpio_probe(struct platform_device
>> *pdev)
> 
> [...]
> 


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

Re: [PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Grygorii Strashko]

On 05/15/2018 04:59 PM, Florian Fainelli wrote:

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
  drivers/net/dsa/bcm_sf2.c |  8 ++--
  drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
  drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
  drivers/net/ethernet/freescale/fec_main.c |  8 ++--
  drivers/net/ethernet/marvell/mvmdio.c |  5 +
  drivers/net/ethernet/renesas/sh_eth.c | 11 +++
  drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
  drivers/net/ethernet/ti/davinci_mdio.c|  6 ++
  drivers/net/phy/mdio-gpio.c   |  6 +-
  drivers/net/phy/mdio-mscc-miim.c  |  6 +-
  drivers/net/usb/lan78xx.c |  7 ++-
  11 files changed, 19 insertions(+), 60 deletions(-)



...


goto bus_register_fail;
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c 
b/drivers/net/ethernet/ti/davinci_mdio.c
index 98a1c97fb95e..e720244e7f71 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -431,10 +431,8 @@ static int davinci_mdio_probe(struct platform_device *pdev)
 */
if (dev->of_node && of_get_child_count(dev->of_node)) {


It causes build error due to "{" above.


data->skip_scan = true;
-   ret = of_mdiobus_register(data->bus, dev->of_node);
-   } else {
-   ret = mdiobus_register(data->bus);
-   }
+
+   ret = of_mdiobus_register(data->bus, dev->of_node);
if (ret)
goto bail_out;
  
diff --git a/drivers/net/phy/mdio-gpio.c b/drivers/net/phy/mdio-gpio.c

index b501221819e1..4e4c8daf44c3 100644
--- a/drivers/net/phy/mdio-gpio.c
+++ b/drivers/net/phy/mdio-gpio.c
@@ -179,11 +179,7 @@ static int mdio_gpio_probe(struct platform_device *pdev)


[...]

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

[PATCH net-next 0/2] of: mdio: Fall back to mdiobus_register() with np is NULL

[Florian Fainelli]

Hi all,

This patch series updates of_mdiobus_register() such that when the device_node
argument is NULL, it calls mdiobus_register() directly. This is consistent with
the behavior of of_mdiobus_register() when CONFIG_OF=n.

I only converted the most obvious drivers, there are others that have a much
less obvious behavior and specifically attempt to deal with CONFIG_ACPI.

Florian Fainelli (2):
  of: mdio: Fall back to mdiobus_register() with np is NULL
  drivers: net: Remove device_node checks with of_mdiobus_register()

 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  6 ++
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 drivers/of/of_mdio.c  |  6 ++
 12 files changed, 25 insertions(+), 60 deletions(-)

-- 
2.14.1

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

[PATCH net-next 2/2] drivers: net: Remove device_node checks with of_mdiobus_register()

[Florian Fainelli]

A number of drivers have the following pattern:

if (np)
of_mdiobus_register()
else
mdiobus_register()

which the implementation of of_mdiobus_register() now takes care of.
Remove that pattern in drivers that strictly adhere to it.

Signed-off-by: Florian Fainelli 
---
 drivers/net/dsa/bcm_sf2.c |  8 ++--
 drivers/net/dsa/mv88e6xxx/chip.c  |  5 +
 drivers/net/ethernet/cadence/macb_main.c  | 12 +++-
 drivers/net/ethernet/freescale/fec_main.c |  8 ++--
 drivers/net/ethernet/marvell/mvmdio.c |  5 +
 drivers/net/ethernet/renesas/sh_eth.c | 11 +++
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |  5 +
 drivers/net/ethernet/ti/davinci_mdio.c|  6 ++
 drivers/net/phy/mdio-gpio.c   |  6 +-
 drivers/net/phy/mdio-mscc-miim.c  |  6 +-
 drivers/net/usb/lan78xx.c |  7 ++-
 11 files changed, 19 insertions(+), 60 deletions(-)

diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ac621f44237a..02e8982519ce 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -450,12 +450,8 @@ static int bcm_sf2_mdio_register(struct dsa_switch *ds)
priv->slave_mii_bus->parent = ds->dev->parent;
priv->slave_mii_bus->phy_mask = ~priv->indir_phy_mask;
 
-   if (dn)
-   err = of_mdiobus_register(priv->slave_mii_bus, dn);
-   else
-   err = mdiobus_register(priv->slave_mii_bus);
-
-   if (err)
+   err = of_mdiobus_register(priv->slave_mii_bus, dn);
+   if (err && dn)
of_node_put(dn);
 
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index b23c11d9f4b2..2bb3f03ee1cb 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2454,10 +2454,7 @@ static int mv88e6xxx_mdio_register(struct mv88e6xxx_chip 
*chip,
return err;
}
 
-   if (np)
-   err = of_mdiobus_register(bus, np);
-   else
-   err = mdiobus_register(bus);
+   err = of_mdiobus_register(bus, np);
if (err) {
dev_err(chip->dev, "Cannot register MDIO bus (%d)\n", err);
mv88e6xxx_g2_irq_mdio_free(chip, bus);
diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index b4c9268100bb..3e93df5d4e3b 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -591,16 +591,10 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(>dev->dev, bp->mii_bus);
 
np = bp->pdev->dev.of_node;
+   if (pdata)
+   bp->mii_bus->phy_mask = pdata->phy_mask;
 
-   if (np) {
-   err = of_mdiobus_register(bp->mii_bus, np);
-   } else {
-   if (pdata)
-   bp->mii_bus->phy_mask = pdata->phy_mask;
-
-   err = mdiobus_register(bp->mii_bus);
-   }
-
+   err = of_mdiobus_register(bp->mii_bus, np);
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c 
b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..f3e43db0d6cb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2052,13 +2052,9 @@ static int fec_enet_mii_init(struct platform_device 
*pdev)
fep->mii_bus->parent = >dev;
 
node = of_get_child_by_name(pdev->dev.of_node, "mdio");
-   if (node) {
-   err = of_mdiobus_register(fep->mii_bus, node);
+   err = of_mdiobus_register(fep->mii_bus, node);
+   if (node)
of_node_put(node);
-   } else {
-   err = mdiobus_register(fep->mii_bus);
-   }
-
if (err)
goto err_out_free_mdiobus;
 
diff --git a/drivers/net/ethernet/marvell/mvmdio.c 
b/drivers/net/ethernet/marvell/mvmdio.c
index 0495487f7b42..c5dac6bd2be4 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -348,10 +348,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
goto out_mdio;
}
 
-   if (pdev->dev.of_node)
-   ret = of_mdiobus_register(bus, pdev->dev.of_node);
-   else
-   ret = mdiobus_register(bus);
+   ret = of_mdiobus_register(bus, pdev->dev.of_node);
if (ret < 0) {
dev_err(>dev, "Cannot register MDIO bus (%d)\n", ret);
goto out_mdio;
diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 5970d9e5ddf1..8dd41e08a6c6 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -3025,15 +3025,10 @@ static int sh_mdio_init(struct sh_eth_private *mdp,
 

[PATCH net-next 1/2] of: mdio: Fall back to mdiobus_register() with np is NULL

[Florian Fainelli]

When the Device Tree node specified is NULL, fall back to
mdiobus_register(). We have a number of drivers having a similar pattern
which is:

if (np)
of_mdiobus_register()
else
mdiobus_register()

so incorporate that behavior within the core of_mdiobus_register()
function. This is also consistent with the stub version that we defined
when CONFIG_OF=n.

Signed-off-by: Florian Fainelli 
---
 drivers/of/of_mdio.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 8c0c92712fc9..2341dbf675bf 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -204,6 +204,12 @@ int of_mdiobus_register(struct mii_bus *mdio, struct 
device_node *np)
bool scanphys = false;
int addr, rc;
 
+   /* If the Device Tree node does not exist, fall back to traditional
+* registration
+*/
+   if (!np)
+   return mdiobus_register(mdio);
+
/* Do not continue if the node is disabled */
if (!of_device_is_available(np))
return -ENODEV;
-- 
2.14.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

Pandaboard OMAP4 MUSB short packet hang on UVC gadget

[Kieran Bingham]

Hi Bin, Felipe,

We have been trying to get a UVC gadget operational on the Pandaboard ES
platform, and we believe we've hit an issue with short packets on the MUSB in
DMA mode.

Using the g_webcam module, I can instantiate a UVC video node, and use the
uvc-gadget helper application [0] to handle the frame generation.

With DMA disabled using CONFIG_MUSB_PIO_ONLY I am able to process frames on the
host using yavta [1]

However when DMA is enabled, only the first frame is transmitted to the host,
and I get an error from the musb_log debug prints which indicate that the
MUSB_TXCSR_TXPKTRDY is not cleared following a short packet.

A capture of the musb_log trace-points [2] shows the following at the end of the
log:

The 'mode' has been set to '0' instead of '1', buffer length is 902 instead of
1024 (expected behaviour for the last packet):
  "ep13-Tx pkt_sz 1024, dma_addr 0xadfbbc00 length 902, mode 0"

And then there is a fault reported:
  "ep13 old packet still ready , txcsr 2003"


The host (linux, running the uvc driver with extra debug prints) reports:

[24517.711147] uvcvideo: decode_data: len: 1022, maxlen 460800
[24517.759117] uvcvideo: decode_data: len: 1022, maxlen 459778
 ...
[24529.375018] uvcvideo: decode_data: len: 1022, maxlen 2944
[24529.399073] uvcvideo: decode_data: len: 1022, maxlen 1922
[24529.427014] uvcvideo: decode_data: len: 900, maxlen 900

And receives no further data following the end of the first frame.


Are there any known issues on the musb-gadget with short-packet handling - or
any other tests I can perform to check this ?

Should I be looking to try to get the txstate() call to re-execute after a delay
(using musb_queue_resume_work() perhaps?) or does this indicate that the
hardware has jammed ? Stopping the pipeline (the yavta capture) and restarting,
will successfully transfer (only) the first frame again.

Any other hints and tips appreciated!


[0] git://git.ideasonboard.org/uvc-gadget.git
[1] git://git.ideasonboard.org/yavta.git
[2] http://paste.ubuntu.com/p/QHrh5XzZv8/

--
Regards

Kieran




signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Mats Karrman]

Hi Heikki,

On 05/15/2018 09:30 AM, Heikki Krogerus wrote:

> Hi Mats,
>
> On Fri, May 11, 2018 at 09:28:04PM +0200, Mats Karrman wrote:
>> On 2018-05-11 13:14, Heikki Krogerus wrote:
>>
>>> On Fri, May 11, 2018 at 11:05:55AM +0200, Mats Karrman wrote:
 On 2018-05-10 19:49, Heikki Krogerus wrote:

> On Thu, May 10, 2018 at 10:04:21AM +0200, Mats Karrman wrote:
>> Hi,
>>
>> On 05/09/2018 02:49 PM, Heikki Krogerus wrote:
>>
>>> On Tue, May 08, 2018 at 09:10:13PM +0200, Mats Karrman wrote:
 Hi,

 On 05/08/2018 04:25 PM, Heikki Krogerus wrote:

> Hi,
>
> On Mon, May 07, 2018 at 11:19:40PM +0200, Mats Karrman wrote:
 Even so, when the mux driver "set" function is called, it will 
 just get the
 mode argument but since the mode (TYPEC_STATE_...) is overlapping 
 for different
 AMs if I understand your proposal correctly, the mux also needs to 
 know what AM
 is active.
 Does this imply that the mux set function signature need to change?
>>> My plan was actually to propose we get rid of the current mux 
>>> handling
>>> (just leave the orientation switch) in favour of the notifications 
>>> I'm
>>> introducing with the type-c bus for the alternate modes. The current
>>> mux handling is definitely not enough, and does not work in every
>>> scenario, like also you pointed out.
>> So, the mux need to subscribe to each svid:mode pair it is 
>> interested in using
>> typec_altmode_register_notifier() and then use those callbacks to 
>> switch the correct
>> signals to the connector. And a driver for an off-the-shelf mux 
>> device could have
>> the translation between svid:mode pairs and mux device specific 
>> control specified by
>> of/acpi properties. Right?
> Yes. That is the plan. Would it work for you?
 I think so. I'll give it a go. When about do you think you'll post the 
 next version
 of your RFC? Or do you have an updated series available somewhere 
 public?
>>> I'll try to put together and post the next version tomorrow.
>>>
>>> My original plan was actually to use just the notifications with the
>>> muxes, but one thing to consider with the notifications is that in
>>> practice we have to increment the ref count for the alt mode devices
>>> when ever something registers a notifier.
>>>
>>> To me that does not feel ideal. The dependency should go the other way
>>> around in case of the muxes. That is why I liked the separate API and
>>> handling for the muxes felt better, as it will do just that. The mux
>>> is then a "service" that the port driver can as for, and if it gets a
>>> handle to a mux, the mux will have its ref count incremented.
>>>
>>> So I think fixing the mux API would perhaps be better after all.
>>> Thoughts?
>> So, we're back to a mux API similar to the current one, where:
>> - the port driver and the mux driver are connected through "graph"
>> - alt mode driver finds its port mux using the typec class mux api
>> - the mux mode setting function arguments now include both svid and mode
>>
>> I like that.
>>
>> One thought that popped up again is if we, somewhere down the line,
>> will see some super device that support many different alternate modes
>> on the same port and therefore will need to have multiple mux devices?
>> However I think the mux api could be extended (later on) to support some
>> aggregate mux device that manages multiple physical devices.
> If we simply had always a mux for every alternate mode, that would not
> be a problem. So the port would have its own mux, and every supported
> alternate mode also had its own. I think that removes the need to deal
> with the svid:mode when using the muxes, as they are already tied to a
> specific alternate modes, right? With a single mux device, for example
> pi3usb30532, the driver just needs to register a mux for the port and
> separate mux for DP, but I don't think that's a huge problem.
 Hmm... As an hypothetical example I have written a driver for another mux
 from TI and according to its data sheet:

 """
 The HD3SS460 is a generic analog differential
 passive switch that can work for any high speed
 interface applications as long as it is biased at a
 common mode voltage range of 0-2V and has
 differential signaling with differential amplitude up to
 1800mVpp
 """

 What I am thinking is that it e.g. would be possible to use this/a mux 
 with USBSS +
 2ch DP + 2ch something else (HDMI?, ThunderBolt?, ???). The problem here is
 that it is a general mux device so the driver 

Re: [PATCH v2 1/1] drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL for usb gadget

[Tiago Brusamarello]

2018-05-15 4:14 GMT-03:00 Felipe Balbi :
>
> Tiago Brusamarello  writes:
>
>> Introduce FSL_USB2_PHY_UTMI_DUAL in gadget driver for setting
>> phy in SOCs with utmi dual phy
>>
>> Signed-off-by: Nikhil Badola 
>> Tested-by: Tiago Brusamarello 
>
> this doesn't apply.

I'll look into it and submit a new version.


-- 

Atenciosamente,
Best Regards,


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

Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port power and data config

[Mats Karrman]

Hi,

On 05/14/2018 11:36 AM, Jun Li wrote:

> Hi
>> -Original Message-
>> From: Mats Karrman [mailto:mats.dev.l...@gmail.com]
>> Sent: 2018年5月12日 3:56
>> To: Jun Li ; robh...@kernel.org; gre...@linuxfoundation.org;
>> heikki.kroge...@linux.intel.com; li...@roeck-us.net
>> Cc: a.ha...@samsung.com; cw00.c...@samsung.com;
>> shufan_...@richtek.com; Peter Chen ;
>> gso...@gmail.com; devicet...@vger.kernel.org; linux-usb@vger.kernel.org;
>> dl-linux-imx 
>> Subject: Re: [PATCH v5 05/14] usb: typec: add API to get typec basic port 
>> power
>> and data config
>>
>> Hi Li Jun,
>>
>> On 2018-05-03 02:24, Li Jun wrote:
>>
>>> This patch adds 3 APIs to get the typec port power and data type, and
>>> preferred power role by its name string.
>>>
>>> Signed-off-by: Li Jun 
>>> ---
>>>   drivers/usb/typec/class.c | 52
>> +++
>>>   include/linux/usb/typec.h |  3 +++
>>>   2 files changed, 55 insertions(+)
>>>
>>> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
>>> index 53df10d..5981e18 100644
>>> --- a/drivers/usb/typec/class.c
>>> +++ b/drivers/usb/typec/class.c
>>> @@ -9,6 +9,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> @@ -802,6 +803,12 @@ static const char * const typec_port_types[] = {
>>> [TYPEC_PORT_DRP] = "dual",
>>>   };
>>>
>>> +static const char * const typec_data_types[] = {
>>> +   [TYPEC_PORT_DFP] = "host",
>>> +   [TYPEC_PORT_UFP] = "device",
>>> +   [TYPEC_PORT_DRD] = "dual",
>>> +};
>>> +
>>>   static const char * const typec_port_types_drp[] = {
>>> [TYPEC_PORT_SRC] = "dual [source] sink",
>>> [TYPEC_PORT_SNK] = "dual source [sink]", @@ -1252,6 +1259,51
>> @@
>>> void typec_set_pwr_opmode(struct typec_port *port,
>>>   }
>>>   EXPORT_SYMBOL_GPL(typec_set_pwr_opmode);
>>>
>>> +/**
>>> + * typec_find_power_type - Get the typec port power type
>> Why is this function called typec_find_power_type() and not
>> typec_find_port_type()?
>> It's called port_type in sysfs, having different names just adds confusion.
>> (Otherwise I agree power_type is a better name but...)
> We have "port type" before the power and data role separation,
> this API name's intention is to reflect the power cap, anyway I
> leave this to be decided by Heikki then.
>>> + * @name: port type string
>>> + *
>>> + * This routine is used to find the typec_port_type by its string name.
>>> + *
>>> + * Returns typec_port_type if success, otherwise negative error code.
>>> + */
>>> +int typec_find_power_type(const char *name) {
>>> +   return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
>>> +   name);
>>> +}
>>> +EXPORT_SYMBOL_GPL(typec_find_power_type);
>>> +
>>> +/**
>>> + * typec_find_preferred_role - Find the typec drp port preferred
>>> +power role
>> Why typec_find_preferred_role()? Could be used for any power_role so why not
>> typec_find_power_role()?
> I am not sure if I catch your point of this comment.
> For preferred role(if support try.sink or try.src) the only allowed power 
> roles are 
> "sink"
> "source"
> But for power role, the allowed type are 
> "sink"
> "source"
> "dual"

Uhm, typing too fast again, I am. A better name would be just typec_find_role().
What I mean is that the function could be used for any situation when
someone wants to map a string to a TYPEC_{SOURCE,SINK} constant so it
is unnecessary to limit its usage to just preferred role.
// Mats

> Thanks
> Li Jun
>> BR // Mats
>>
>>> + * @name: power role string
>>> + *
>>> + * This routine is used to find the typec_role by its string name of
>>> + * preferred power role(Try.SRC or Try.SNK).
>>> + *
>>> + * Returns typec_role if success, otherwise negative error code.
>>> + */
>>> +int typec_find_preferred_role(const char *name) {
>>> +   return match_string(typec_roles, ARRAY_SIZE(typec_roles), name); }
>>> +EXPORT_SYMBOL_GPL(typec_find_preferred_role);
>>> +
>>> +/**
>>> + * typec_find_data_type - Get the typec port data capability
>>> + * @name: data type string
>>> + *
>>> + * This routine is used to find the typec_port_data by its string name.
>>> + *
>>> + * Returns typec_port_data if success, otherwise negative error code.
>>> + */
>>> +int typec_find_data_type(const char *name) {
>>> +   return match_string(typec_data_types, ARRAY_SIZE(typec_data_types),
>>> +   name);
>>> +}
>>> +EXPORT_SYMBOL_GPL(typec_find_data_type);
>>> +
>>>   /* -- */
>>>   /* API for Multiplexer/DeMultiplexer Switches */
>>>
>>> diff --git a/include/linux/usb/typec.h b/include/linux/usb/typec.h
>>> index 672b39b..00c93e7 100644
>>> --- a/include/linux/usb/typec.h
>>> +++ b/include/linux/usb/typec.h
>>> @@ -267,4 +267,7 @@ int typec_set_orientation(struct typec_port *port,
>>>   enum typec_orientation orientation);
>>>   int 

Re: [PATCH] usb: xhci: force all memory allocations to node

[Adam Wallis]

On 5/15/2018 11:07 AM, Greg Kroah-Hartman wrote:
> On Tue, May 15, 2018 at 09:53:57AM -0400, Adam Wallis wrote:
> Does this really do anything?  Given the speed of USB3 at the moment,
> does fixing the memory to the node the PCI device is on show any
> measurable speedups?  Last I remember about NUMA systems, it wasn't
> always a win depending on where the irq came in from, right?
> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

I was getting really inconsistent throughput speeds on a system I was testing
with NUMA nodes. Using an SMMU in identity mode, I was able to track down where
the performance deltas were coming from...Some of the rings were going to the
"wrong" node.

Yes, it's possible to handle your IRQs with CPUs on the wrong NUMA node...but I
would argue that it's always best to have the rings for USB controller X as
close to controller X if possible. Users can then properly constrain IRQs, and
even kernel threads to the right Domain if they so desire.

After setting the IRQ affinity to the right node AND applying this patch, I
started getting much more reliable (and faster) results.

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

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Paul Menzel]

Dear Greg,


As always, thank you for the prompt response.


On 05/15/18 18:00, Greg KH wrote:

On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote:



Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian
Sid/unstable.

```
[…]
[0.440240] usb: port power management may be unreliable
[0.441358] usbcore: registered new interface driver usb-storage
[0.441367] usbcore: registered new interface driver usbserial_generic
[0.441369] usbserial: USB Serial support registered for generic
[0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, got
0x0
[0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
[…]
```

1.  Are the ioremap and ucsi_acpi error related or is a separate report
needed?


The ioremap error is what causes ucsi_acpi to fail the probe call (-12
is "out of memory".)


2.  Do you know the reason for the ucsi_acpi error?


the call to ioremap failed.

Does this device really have a working typec connector?


Just to avoid misunderstandings, no device was connected to the laptop 
during my test.


But, from other boots, the Dell docking station TB16 kind of works with 
it, so I’d say the USB Type-C connector is working.



Does normal USB devices work with it?


Sorry for being ignorant, but could you please tell me what normal USB 
devices are?



Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 1/2] Convert target drivers to use sbitmap

[Jens Axboe]

On 5/15/18 10:11 AM, Jens Axboe wrote:
> On 5/15/18 10:00 AM, Matthew Wilcox wrote:
>> From: Matthew Wilcox 
>>
>> The sbitmap and the percpu_ida perform essentially the same task,
>> allocating tags for commands.  Since the sbitmap is more used than
>> the percpu_ida, convert the percpu_ida users to the sbitmap API.
> 
> It should also be the same performance as percpu_ida in light use, and
> performs much better at > 50% utilization of the tag space. I think
> that's better justification than "more used than".

Had to search long and hard for the perf numbers I did for percpu_ida
on higher utilization, but here it is:

https://lkml.org/lkml/2014/4/22/553

-- 
Jens Axboe

--
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] Convert target drivers to use sbitmap

[Jens Axboe]

On 5/15/18 10:00 AM, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> The sbitmap and the percpu_ida perform essentially the same task,
> allocating tags for commands.  Since the sbitmap is more used than
> the percpu_ida, convert the percpu_ida users to the sbitmap API.

It should also be the same performance as percpu_ida in light use, and
performs much better at > 50% utilization of the tag space. I think
that's better justification than "more used than".

> diff --git a/drivers/target/iscsi/iscsi_target_util.c 
> b/drivers/target/iscsi/iscsi_target_util.c
> index 4435bf374d2d..28bcffae609f 100644
> --- a/drivers/target/iscsi/iscsi_target_util.c
> +++ b/drivers/target/iscsi/iscsi_target_util.c
> @@ -17,7 +17,7 @@
>   
> **/
>  
>  #include 
> -#include 
> +#include 
>  #include  /* ipv6_addr_equal() */
>  #include 
>  #include 
> @@ -147,6 +147,28 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
>   spin_unlock_bh(>r2t_lock);
>  }
>  
> +int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup)
> +{
> + int tag = -1;
> + DEFINE_WAIT(wait);
> + struct sbq_wait_state *ws;
> +
> + if (state == TASK_RUNNING)
> + return tag;
> +
> + ws = _sess->sess_tag_pool.ws[0];
> + for (;;) {
> + prepare_to_wait_exclusive(>wait, , state);
> + if (signal_pending_state(state, current))
> + break;
> + schedule();
> + tag = sbitmap_queue_get(_sess->sess_tag_pool, cpup);
> + }
> +
> + finish_wait(>wait, );
> + return tag;
> +}

Seems like that should be:


ws = _sess->sess_tag_pool.ws[0];
for (;;) {
prepare_to_wait_exclusive(>wait, , state);
if (signal_pending_state(state, current))
break;
tag = sbitmap_queue_get(_sess->sess_tag_pool, cpup);
if (tag != -1)
break;
schedule();
}

finish_wait(>wait, );
return tag;

>  /*
>   * May be called from software interrupt (timer) context for allocating
>   * iSCSI NopINs.
> @@ -155,9 +177,11 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn 
> *conn, int state)
>  {
>   struct iscsi_cmd *cmd;
>   struct se_session *se_sess = conn->sess->se_sess;
> - int size, tag;
> + int size, tag, cpu;
>  
> - tag = percpu_ida_alloc(_sess->sess_tag_pool, state);
> + tag = sbitmap_queue_get(_sess->sess_tag_pool, );
> + if (tag < 0)
> + tag = iscsit_wait_for_tag(se_sess, state, );
>   if (tag < 0)
>   return NULL;

Might make sense to just roll the whole thing into iscsi_get_tag(), that
would be cleaner.

sbitmap should provide a helper for that, but we can do that cleanup
later. That would encapsulate things like the per-cpu caching hint too,
for instance.

Rest looks fine to me.

-- 
Jens Axboe

--
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] Convert target drivers to use sbitmap

[Matthew Wilcox]

From: Matthew Wilcox 

The sbitmap and the percpu_ida perform essentially the same task,
allocating tags for commands.  Since the sbitmap is more used than
the percpu_ida, convert the percpu_ida users to the sbitmap API.

Signed-off-by: Matthew Wilcox 
---
 drivers/scsi/qla2xxx/qla_target.c| 16 ++-
 drivers/target/iscsi/iscsi_target_util.c | 34 +---
 drivers/target/sbp/sbp_target.c  |  8 +++---
 drivers/target/target_core_transport.c   |  5 ++--
 drivers/target/tcm_fc/tfc_cmd.c  | 11 
 drivers/usb/gadget/function/f_tcm.c  |  8 +++---
 drivers/vhost/scsi.c |  9 ---
 drivers/xen/xen-scsiback.c   |  8 +++---
 include/target/iscsi/iscsi_target_core.h |  1 +
 include/target/target_core_base.h|  5 ++--
 10 files changed, 73 insertions(+), 32 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_target.c 
b/drivers/scsi/qla2xxx/qla_target.c
index 025dc2d3f3de..cdf671c2af61 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -3719,7 +3719,8 @@ void qlt_free_cmd(struct qla_tgt_cmd *cmd)
return;
}
cmd->jiffies_at_free = get_jiffies_64();
-   percpu_ida_free(>se_sess->sess_tag_pool, cmd->se_cmd.map_tag);
+   sbitmap_queue_clear(>se_sess->sess_tag_pool, cmd->se_cmd.map_tag,
+   cmd->se_cmd.map_cpu);
 }
 EXPORT_SYMBOL(qlt_free_cmd);
 
@@ -4084,7 +4085,8 @@ static void __qlt_do_work(struct qla_tgt_cmd *cmd)
qlt_send_term_exchange(qpair, NULL, >atio, 1, 0);
 
qlt_decr_num_pend_cmds(vha);
-   percpu_ida_free(>se_sess->sess_tag_pool, cmd->se_cmd.map_tag);
+   sbitmap_queue_clear(>se_sess->sess_tag_pool, cmd->se_cmd.map_tag,
+   cmd->se_cmd.map_cpu);
spin_unlock_irqrestore(qpair->qp_lock_ptr, flags);
 
spin_lock_irqsave(>tgt.sess_lock, flags);
@@ -4215,9 +4217,9 @@ static struct qla_tgt_cmd *qlt_get_tag(scsi_qla_host_t 
*vha,
 {
struct se_session *se_sess = sess->se_sess;
struct qla_tgt_cmd *cmd;
-   int tag;
+   int tag, cpu;
 
-   tag = percpu_ida_alloc(_sess->sess_tag_pool, TASK_RUNNING);
+   tag = sbitmap_queue_get(_sess->sess_tag_pool, );
if (tag < 0)
return NULL;
 
@@ -4230,6 +4232,7 @@ static struct qla_tgt_cmd *qlt_get_tag(scsi_qla_host_t 
*vha,
qlt_incr_num_pend_cmds(vha);
cmd->vha = vha;
cmd->se_cmd.map_tag = tag;
+   cmd->se_cmd.map_cpu = cpu;
cmd->sess = sess;
cmd->loop_id = sess->loop_id;
cmd->conf_compl_supported = sess->conf_compl_supported;
@@ -5212,7 +5215,7 @@ qlt_alloc_qfull_cmd(struct scsi_qla_host *vha,
struct fc_port *sess;
struct se_session *se_sess;
struct qla_tgt_cmd *cmd;
-   int tag;
+   int tag, cpu;
unsigned long flags;
 
if (unlikely(tgt->tgt_stop)) {
@@ -5244,7 +5247,7 @@ qlt_alloc_qfull_cmd(struct scsi_qla_host *vha,
 
se_sess = sess->se_sess;
 
-   tag = percpu_ida_alloc(_sess->sess_tag_pool, TASK_RUNNING);
+   tag = sbitmap_queue_get(_sess->sess_tag_pool, );
if (tag < 0)
return;
 
@@ -5275,6 +5278,7 @@ qlt_alloc_qfull_cmd(struct scsi_qla_host *vha,
cmd->reset_count = ha->base_qpair->chip_reset;
cmd->q_full = 1;
cmd->qpair = ha->base_qpair;
+   cmd->se_cmd.map_cpu = cpu;
 
if (qfull) {
cmd->q_full = 1;
diff --git a/drivers/target/iscsi/iscsi_target_util.c 
b/drivers/target/iscsi/iscsi_target_util.c
index 4435bf374d2d..28bcffae609f 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -17,7 +17,7 @@
  
**/
 
 #include 
-#include 
+#include 
 #include  /* ipv6_addr_equal() */
 #include 
 #include 
@@ -147,6 +147,28 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
spin_unlock_bh(>r2t_lock);
 }
 
+int iscsit_wait_for_tag(struct se_session *se_sess, int state, int *cpup)
+{
+   int tag = -1;
+   DEFINE_WAIT(wait);
+   struct sbq_wait_state *ws;
+
+   if (state == TASK_RUNNING)
+   return tag;
+
+   ws = _sess->sess_tag_pool.ws[0];
+   for (;;) {
+   prepare_to_wait_exclusive(>wait, , state);
+   if (signal_pending_state(state, current))
+   break;
+   schedule();
+   tag = sbitmap_queue_get(_sess->sess_tag_pool, cpup);
+   }
+
+   finish_wait(>wait, );
+   return tag;
+}
+
 /*
  * May be called from software interrupt (timer) context for allocating
  * iSCSI NopINs.
@@ -155,9 +177,11 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn 
*conn, int state)
 {
struct iscsi_cmd *cmd;
struct se_session *se_sess = conn->sess->se_sess;
-   int size, tag;
+   int 

[PATCH 0/2] Use sbitmap instead of percpu_ida

[Matthew Wilcox]

From: Matthew Wilcox 

This is a pretty rough-and-ready conversion of the target drivers
from using percpu_ida to sbitmap.  It compiles; I don't have a target
setup, so it's completely untested.  I haven't tried to do anything
particularly clever here, so it's possible that, for example, the wait
queue in iscsi_target_util could be more clever, like the block layer
uses multiple wait queues to avoid pingpongs.  Or maybe we could figure
out a way to not store the CPU that the ID was allocated on, or perhaps
the options I specified to sbitmap_queue_init() are suboptimal.

Patch 2 isn't interesting; it just deletes the implementation.  Patch 1
will be where all the action is.

Matthew Wilcox (2):
  Convert target drivers to use sbitmap
  Remove percpu_ida

 drivers/scsi/qla2xxx/qla_target.c|  16 +-
 drivers/target/iscsi/iscsi_target_util.c |  34 +-
 drivers/target/sbp/sbp_target.c  |   8 +-
 drivers/target/target_core_transport.c   |   5 +-
 drivers/target/tcm_fc/tfc_cmd.c  |  11 +-
 drivers/usb/gadget/function/f_tcm.c  |   8 +-
 drivers/vhost/scsi.c |   9 +-
 drivers/xen/xen-scsiback.c   |   8 +-
 include/linux/percpu_ida.h   |  83 -
 include/target/iscsi/iscsi_target_core.h |   1 +
 include/target/target_core_base.h|   5 +-
 lib/Makefile |   2 +-
 lib/percpu_ida.c | 391 ---
 13 files changed, 74 insertions(+), 507 deletions(-)
 delete mode 100644 include/linux/percpu_ida.h
 delete mode 100644 lib/percpu_ida.c

-- 
2.17.0

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

[PATCH 2/2] Remove percpu_ida

[Matthew Wilcox]

From: Matthew Wilcox 

With its one user gone, remove the library code.

Signed-off-by: Matthew Wilcox 
---
 include/linux/percpu_ida.h |  83 
 lib/Makefile   |   2 +-
 lib/percpu_ida.c   | 391 -
 3 files changed, 1 insertion(+), 475 deletions(-)
 delete mode 100644 include/linux/percpu_ida.h
 delete mode 100644 lib/percpu_ida.c

diff --git a/include/linux/percpu_ida.h b/include/linux/percpu_ida.h
deleted file mode 100644
index 07d78e4653bc..
--- a/include/linux/percpu_ida.h
+++ /dev/null
@@ -1,83 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __PERCPU_IDA_H__
-#define __PERCPU_IDA_H__
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct percpu_ida_cpu;
-
-struct percpu_ida {
-   /*
-* number of tags available to be allocated, as passed to
-* percpu_ida_init()
-*/
-   unsignednr_tags;
-   unsignedpercpu_max_size;
-   unsignedpercpu_batch_size;
-
-   struct percpu_ida_cpu __percpu  *tag_cpu;
-
-   /*
-* Bitmap of cpus that (may) have tags on their percpu freelists:
-* steal_tags() uses this to decide when to steal tags, and which cpus
-* to try stealing from.
-*
-* It's ok for a freelist to be empty when its bit is set - steal_tags()
-* will just keep looking - but the bitmap _must_ be set whenever a
-* percpu freelist does have tags.
-*/
-   cpumask_t   cpus_have_tags;
-
-   struct {
-   spinlock_t  lock;
-   /*
-* When we go to steal tags from another cpu (see steal_tags()),
-* we want to pick a cpu at random. Cycling through them every
-* time we steal is a bit easier and more or less equivalent:
-*/
-   unsignedcpu_last_stolen;
-
-   /* For sleeping on allocation failure */
-   wait_queue_head_t   wait;
-
-   /*
-* Global freelist - it's a stack where nr_free points to the
-* top
-*/
-   unsignednr_free;
-   unsigned*freelist;
-   } cacheline_aligned_in_smp;
-};
-
-/*
- * Number of tags we move between the percpu freelist and the global freelist 
at
- * a time
- */
-#define IDA_DEFAULT_PCPU_BATCH_MOVE32U
-/* Max size of percpu freelist, */
-#define IDA_DEFAULT_PCPU_SIZE  ((IDA_DEFAULT_PCPU_BATCH_MOVE * 3) / 2)
-
-int percpu_ida_alloc(struct percpu_ida *pool, int state);
-void percpu_ida_free(struct percpu_ida *pool, unsigned tag);
-
-void percpu_ida_destroy(struct percpu_ida *pool);
-int __percpu_ida_init(struct percpu_ida *pool, unsigned long nr_tags,
-   unsigned long max_size, unsigned long batch_size);
-static inline int percpu_ida_init(struct percpu_ida *pool, unsigned long 
nr_tags)
-{
-   return __percpu_ida_init(pool, nr_tags, IDA_DEFAULT_PCPU_SIZE,
-   IDA_DEFAULT_PCPU_BATCH_MOVE);
-}
-
-typedef int (*percpu_ida_cb)(unsigned, void *);
-int percpu_ida_for_each_free(struct percpu_ida *pool, percpu_ida_cb fn,
-   void *data);
-
-unsigned percpu_ida_free_tags(struct percpu_ida *pool, int cpu);
-#endif /* __PERCPU_IDA_H__ */
diff --git a/lib/Makefile b/lib/Makefile
index ce20696d5a92..7626dece1d27 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -39,7 +39,7 @@ obj-y += bcd.o div64.o sort.o parser.o debug_locks.o 
random32.o \
 bust_spinlocks.o kasprintf.o bitmap.o scatterlist.o \
 gcd.o lcm.o list_sort.o uuid.o flex_array.o iov_iter.o clz_ctz.o \
 bsearch.o find_bit.o llist.o memweight.o kfifo.o \
-percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o \
+percpu-refcount.o rhashtable.o reciprocal_div.o \
 once.o refcount.o usercopy.o errseq.o bucket_locks.o
 obj-$(CONFIG_STRING_SELFTEST) += test_string.o
 obj-y += string_helpers.o
diff --git a/lib/percpu_ida.c b/lib/percpu_ida.c
deleted file mode 100644
index 6016f1deb1f5..
--- a/lib/percpu_ida.c
+++ /dev/null
@@ -1,391 +0,0 @@
-/*
- * Percpu IDA library
- *
- * Copyright (C) 2013 Datera, Inc. Kent Overstreet
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2, or (at
- * your option) any later version.
- *
- * 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 
-#include 
-#include 

Re: `ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Greg KH]

On Tue, May 15, 2018 at 04:34:03PM +0200, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian
> Sid/unstable.
> 
> ```
> […]
> [0.440240] usb: port power management may be unreliable
> [0.441358] usbcore: registered new interface driver usb-storage
> [0.441367] usbcore: registered new interface driver usbserial_generic
> [0.441369] usbserial: USB Serial support registered for generic
> [0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, got
> 0x0
> [0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
> […]
> ```
> 
> 1.  Are the ioremap and ucsi_acpi error related or is a separate report
> needed?

The ioremap error is what causes ucsi_acpi to fail the probe call (-12
is "out of memory".)

> 2.  Do you know the reason for the ucsi_acpi error?

the call to ioremap failed.

Does this device really have a working typec connector?  Does normal USB
devices work with it?

thanks,

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

Re: usb: storage: what is the correct sequence for? sd_probe| storage_probe/1/2 and uas_probe | scsi_scan_host

[Alan Stern]

On Tue, 15 May 2018, Tushar Nimkar wrote:

> Everyone,
> 
> Please help me in understanding sd_probe| storage_probe/1/2 and 
> uas_probe | scsi_scan_host :)
> Basically want to know the correct sequence for them? How 
> sd_probe_async() is called (ASYNC_DOMAIN(scsi_sd_probe_domain))?

Very briefly:

The probe routine for usb-storage is storage_probe(), which calls
usb_stor_probe1() and usb_stor_probe2().  Similarly, the probe routine 
for uas is uas_probe().  Each driver's probe routine is called by the 
driver core (drivers/base/dd.c) when a new device of the appropriate 
type is detected.

usb_stor_probe2() starts a workqueue routine, usb_stor_scan_dwork(), 
which calls scsi_scan_host(), whereas uas_probe() calls 
scsi_scan_host() directly.  Either way, scsi_scan_host() usually sets 
up an async worker to carry out the actual scanning.  The scanning is 
started by scsi_scan_target() and the various routines it calls.

When the scanning procedure registers a SCSI device that is a 
disk-drive-like device, the sd driver's sd_probe() routine is called by 
the driver core.  sd_probe() does some of the initial work needed to 
probe the device, and it defers the rest of the work to the async 
worker routine sd_probe_async().

> Is there any document which say it in detail ?

No.  UTSL.  You might concentrate on include/linux/async.h and
kernel/async.c (and you should be able to figure that much out for
yourself without asking the mailing list).

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: xhci: force all memory allocations to node

[Greg Kroah-Hartman]

On Tue, May 15, 2018 at 09:53:57AM -0400, Adam Wallis wrote:
> The xhci driver forces DMA memory to be node aware, however, there are
> several ring-related memory allocations that are not memory node aware.
> This patch resolves those *alloc functions to be allocated on the proper
> memory node.

Does this really do anything?  Given the speed of USB3 at the moment,
does fixing the memory to the node the PCI device is on show any
measurable speedups?  Last I remember about NUMA systems, it wasn't
always a win depending on where the irq came in from, right?

thanks,

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

Re: [PATCH v2 11/11] docs: fix broken references with multiple hints

[Steven Rostedt]

On Wed,  9 May 2018 10:18:54 -0300
Mauro Carvalho Chehab  wrote:


> diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst
> index 7b6b1236ec2e..c292117b83a9 100644
> --- a/Documentation/trace/events.rst
> +++ b/Documentation/trace/events.rst
> @@ -8,7 +8,7 @@ Event Tracing
>  1. Introduction
>  ===
>  
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used
> +Tracepoints (see Documentation/trace/tracepoints.rst) can be used
>  without creating custom kernel modules to register probe functions
>  using the event tracing infrastructure.
>  
> diff --git a/Documentation/trace/tracepoint-analysis.rst 
> b/Documentation/trace/tracepoint-analysis.rst
> index b0c9c21f129d..716326b9f152 100644
> --- a/Documentation/trace/tracepoint-analysis.rst
> +++ b/Documentation/trace/tracepoint-analysis.rst
> @@ -6,7 +6,7 @@ Notes on Analysing Behaviour Using Events and Tracepoints
>  1. Introduction
>  ===
>  
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used without
> +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without
>  creating custom kernel modules to register probe functions using the event
>  tracing infrastructure.
>  

> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index c94f466d57ef..19a690b559ca 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -4,7 +4,7 @@
>  /*
>   * Kernel Tracepoint API.
>   *
> - * See Documentation/trace/tracepoints.txt.
> + * See Documentation/trace/tracepoints.rst.
>   *
>   * Copyright (C) 2008-2014 Mathieu Desnoyers 
>   *

Acked-by: Steven Rostedt (VMware) 

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

usbutils 010 release

[Greg KH]

Hey, a new version of usbutils?  It's not October, what's happening?

Yes, I'm breaking with the "normal" slow release schedule of a new
usbutils release every year or so with a new release today.  The 010
release is now out at kernel.org and github.

There's been a number of new descriptors that are correctly parsed, many
thanks to Michael Drake for that.  Also, the biggest change, and the one
that drove this release, is the conversion of the lsusb.py script to
python3, allowing some distros to finally drop python2 from their list
of requirements.

Other than that, a number of small fixes and updates, and lots of
housekeeping (SPDX and copyright notices everywhere, the repo is now
'reuse lint' clean, and there is a SPDX bill-of-materials file.)

Full details of all changes are in the shortlog below.

The package can be downloaded from kernel.org:
http://www.kernel.org/pub/linux/utils/usb/usbutils/

The source tree for usbutils can be found on both kernel.org and
github.com if you want to fork it and send us changes easier:
http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git
http://github.com/gregkh/usbutils/tree/master

thanks,

greg k-h

---

Aurelien Jarno (2):
  usbreset.c: add missing  include
  Do not create and install usbutils.pc

Greg Kroah-Hartman (32):
  fix dump_videocontrol_interface for unitialized variable usage
  Add correct SPDX license identifiers to all files
  Add SPDX identifiers on files that did not have a specific license.
  wTotalLength should be printed as a hex number
  usbmisc: fix up some strncpy() issues
  lsusb-t: fix up error with readlink()
  lsusb.py.in: add proper SPDX license identifier
  usb-devices: reword the copyright identifier
  LICENSES: move the GPL 2 license to the LICENSES directory
  LICENSES/GPL-3.0.txt: add the file
  lsusb.h: add copyright notice
  lsusb-t: add copyright info
  bom.spdx: Add bill of materials file in SPDX format.
  ChangeLog: remove it.
  AUTHORS: remove file
  do_release: drop file
  NEWS: add SPDX header and comment
  autogen.sh: add SPDX and copyright header
  list.h: add copyright information
  travis-autogen.sh: add SPDX and copyright information.
  INSTALL: remove the file, it's boiler-plate
  configure.ac: add SPDX and copyright
  man pages: add SPDX and copyright information
  Makefile.am: add SPDX and copyright information
  .gitmodules: add SPDX and copyright lines
  lsusb.py.in: fix up Copyright strings
  usbreset.c: add Alan's copyright
  .travis.yml: add correct SPDX and copyright notices
  bom.spdx: update with latest copyright and SPDX identifier additions
  README.md: move the README file to markdown
  README.md: fix fomatting
  bom.spdx: upate with README -> README.md change

Lukas Nykryn (1):
  lsusb.py: convert to python3

Michael Drake (11):
  lsusb: Split subtype mapping out of AudioControl interface handling.
  lsusb: Add declarative definitions for UAC1 and UAC2 descriptors.
  lsusb: Add code to dump descriptor data using descriptor definition.
  lsusb: Switch to descriptor-definition based dump for UAC1 and UAC2.
  lsusb: Add descriptor definitions for UAC3.
  lsusb: Add initial support for USB Audio Device Class 3.
  lsusb: Add descriptor definition for USB3 BOS Configuration Summary.
  lsusb: Dump USB3 BOS Configuration Summary Descriptor.
  lsusb: Squash Wpointer-compare warning.
  lsusb: Remove unused function.
  lsusb: Fix array entry count for variable sized entries.

Robby Workman (1):
  Makefile.am: Include usbreset.c in the release tarball

Torleiv Sundre (1):
  lsusb: Dump UVC Stream based payload descriptor.

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

`ucsi_acpi: probe of USBC000:00 failed with error -12` on Dell XPS 13 9370

[Paul Menzel]

Dear Linux folks,


Linux 4.17-rc5 shows the error below on the Dell XPS 13 9370 with Debian 
Sid/unstable.


```
[…]
[0.440240] usb: port power management may be unreliable
[0.441358] usbcore: registered new interface driver usb-storage
[0.441367] usbcore: registered new interface driver usbserial_generic
[0.441369] usbserial: USB Serial support registered for generic
[0.441383] ioremap error for 0x3f799000-0x3f79a000, requested 0x2, 
got 0x0

[0.441518] ucsi_acpi: probe of USBC000:00 failed with error -12
[…]
```

1.  Are the ioremap and ucsi_acpi error related or is a separate report 
needed?

2.  Do you know the reason for the ucsi_acpi error?


Kind regards,

Paul
[0.00] Linux version 4.17.0-rc5-9-g1150fc87af6f (root@eed5a4f78c51) 
(gcc version 7.3.0 (Debian 7.3.0-19)) #2 SMP Tue May 15 12:47:39 UTC 2018
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.17.0-rc5-9-g1150fc87af6f 
root=UUID=b8b2f3b6-8c20-4c2a-8895-aa2768866674 ro quiet noisapnp 
cryptomgr.notests mem_sleep_default=deep
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
bytes, using 'compacted' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x2d6f7fff] usable
[0.00] BIOS-e820: [mem 0x2d6f8000-0x2d6f8fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x2d6f9000-0x2d6f9fff] reserved
[0.00] BIOS-e820: [mem 0x2d6fa000-0x3ecf4fff] usable
[0.00] BIOS-e820: [mem 0x3ecf5000-0x3f0b2fff] reserved
[0.00] BIOS-e820: [mem 0x3f0b3000-0x3f0f] ACPI data
[0.00] BIOS-e820: [mem 0x3f10-0x3f7b7fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x3f7b8000-0x3ff26fff] reserved
[0.00] BIOS-e820: [mem 0x3ff27000-0x3fffefff] type 20
[0.00] BIOS-e820: [mem 0x3000-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x47ff] reserved
[0.00] BIOS-e820: [mem 0x4800-0x48df] usable
[0.00] BIOS-e820: [mem 0x48e0-0x4f7f] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x0004ae7f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by American Megatrends
[0.00] efi:  ACPI=0x3f0c3000  ACPI 2.0=0x3f0c3000  SMBIOS=0xf  
SMBIOS 3.0=0xf0020  ESRT=0x3fdd9018  MEMATTR=0x3c2bb018 
[0.00] SMBIOS 3.0.0 present.
[0.00] DMI: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.2.1 02/21/2018
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x4ae800 max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 008000 mask 7F8000 uncachable
[0.00]   1 base 006000 mask 7FE000 uncachable
[0.00]   2 base 005000 mask 7FF000 uncachable
[0.00]   3 base 004C00 mask 7FFC00 uncachable
[0.00]   4 base 004B00 mask 7FFF00 uncachable
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: last_pfn = 0x48e00 max_arch_pfn = 

[PATCH] usb: xhci: force all memory allocations to node

[Adam Wallis]

The xhci driver forces DMA memory to be node aware, however, there are
several ring-related memory allocations that are not memory node aware.
This patch resolves those *alloc functions to be allocated on the proper
memory node.

Signed-off-by: Adam Wallis 
---
 drivers/usb/host/xhci-mem.c | 63 +
 1 file changed, 41 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 332420d..4a229f5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -33,8 +33,9 @@ static struct xhci_segment *xhci_segment_alloc(struct 
xhci_hcd *xhci,
struct xhci_segment *seg;
dma_addr_t  dma;
int i;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 
-   seg = kzalloc(sizeof *seg, flags);
+   seg = kzalloc_node(sizeof(*seg), flags, dev_to_node(dev));
if (!seg)
return NULL;
 
@@ -45,7 +46,8 @@ static struct xhci_segment *xhci_segment_alloc(struct 
xhci_hcd *xhci,
}
 
if (max_packet) {
-   seg->bounce_buf = kzalloc(max_packet, flags);
+   seg->bounce_buf = kzalloc_node(max_packet, flags,
+   dev_to_node(dev));
if (!seg->bounce_buf) {
dma_pool_free(xhci->segment_pool, seg->trbs, dma);
kfree(seg);
@@ -363,8 +365,9 @@ struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
 {
struct xhci_ring*ring;
int ret;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 
-   ring = kzalloc(sizeof *(ring), flags);
+   ring = kzalloc_node(sizeof(*ring), flags, dev_to_node(dev));
if (!ring)
return NULL;
 
@@ -458,11 +461,12 @@ struct xhci_container_ctx 
*xhci_alloc_container_ctx(struct xhci_hcd *xhci,
int type, gfp_t flags)
 {
struct xhci_container_ctx *ctx;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 
if ((type != XHCI_CTX_TYPE_DEVICE) && (type != XHCI_CTX_TYPE_INPUT))
return NULL;
 
-   ctx = kzalloc(sizeof(*ctx), flags);
+   ctx = kzalloc_node(sizeof(*ctx), flags, dev_to_node(dev));
if (!ctx)
return NULL;
 
@@ -615,6 +619,7 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct 
xhci_hcd *xhci,
struct xhci_ring *cur_ring;
u64 addr;
int ret;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 
xhci_dbg(xhci, "Allocating %u streams and %u "
"stream context array entries.\n",
@@ -625,7 +630,8 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct 
xhci_hcd *xhci,
}
xhci->cmd_ring_reserved_trbs++;
 
-   stream_info = kzalloc(sizeof(struct xhci_stream_info), mem_flags);
+   stream_info = kzalloc_node(sizeof(*stream_info), mem_flags,
+   dev_to_node(dev));
if (!stream_info)
goto cleanup_trbs;
 
@@ -633,9 +639,11 @@ struct xhci_stream_info *xhci_alloc_stream_info(struct 
xhci_hcd *xhci,
stream_info->num_stream_ctxs = num_stream_ctxs;
 
/* Initialize the array of virtual pointers to stream rings. */
-   stream_info->stream_rings = kzalloc(
-   sizeof(struct xhci_ring *)*num_streams,
-   mem_flags);
+   stream_info->stream_rings = kcalloc_node(
+   num_streams,
+   sizeof(struct xhci_ring *),
+   mem_flags,
+   dev_to_node(dev));
if (!stream_info->stream_rings)
goto cleanup_info;
 
@@ -831,6 +839,7 @@ int xhci_alloc_tt_info(struct xhci_hcd *xhci,
struct xhci_tt_bw_info  *tt_info;
unsigned intnum_ports;
int i, j;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
 
if (!tt->multi)
num_ports = 1;
@@ -840,7 +849,8 @@ int xhci_alloc_tt_info(struct xhci_hcd *xhci,
for (i = 0; i < num_ports; i++, tt_info++) {
struct xhci_interval_bw_table *bw_table;
 
-   tt_info = kzalloc(sizeof(*tt_info), mem_flags);
+   tt_info = kzalloc_node(sizeof(*tt_info), mem_flags,
+   dev_to_node(dev));
if (!tt_info)
goto free_tts;
INIT_LIST_HEAD(_info->tt_list);
@@ -1640,7 +1650,8 @@ static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t 
flags)
if (!num_sp)
return 0;
 
-   xhci->scratchpad = kzalloc(sizeof(*xhci->scratchpad), flags);
+   xhci->scratchpad = kzalloc_node(sizeof(*xhci->scratchpad), flags,
+   dev_to_node(dev));
if (!xhci->scratchpad)
goto fail_sp;
 
@@ -1650,7 +1661,8 @@ static int 

Re: [PATCH v2 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC

[Krzysztof Kozlowski]

On Tue, May 15, 2018 at 2:12 PM, Andrzej Hajda  wrote:
> OF graph describes USB data lanes between USB-PHY and respective MUIC.
> Since graph is present and DWC driver can use it to get extcon, obsolete
> extcon property can be removed.
>
> Signed-off-by: Andrzej Hajda 
> ---
>  .../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)

As we discussed for v1 - since this was not split into two, I'll apply
it once first patch hits mainline.

Best regards,
Krzysztof
--
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] USB: dwc3: get extcon device by OF graph bindings

[Andrzej Hajda]

Hi,

This small patchset tries to address issue with broken DT extcon property
in case of USB controller - DWC3. It exposes similar problem as in proposed
USB connector bindings[1] - extcon device is required by devices not always
connected directly to extcon device. Here we have:
DWC3 -> USB-PHY -> MUIC -> USB-connector
   ^
MHL-bridge-^

More details and proposition of generic solution in first patch 

v2:
- rebased on latest linux-next,
- since recently dwc3 fallbacks to ID detection using internal OTG block if
  extcon property is not present, added code allowing to fallback to OTG
  block also in case of graph is not present

[1]: https://marc.info/?i=20180131134435.12216-1-a.hajda%40samsung.com

Regards
Andrzej


Andrzej Hajda (2):
  USB: dwc3: get extcon device by OF graph bindings
  arm64: dts: exynos: add OF graph between USB-PHY and MUIC

 .../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++-
 drivers/usb/dwc3/drd.c| 34 +++
 2 files changed, 46 insertions(+), 7 deletions(-)

-- 
2.17.0

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

[PATCH v2 1/2] USB: dwc3: get extcon device by OF graph bindings

[Andrzej Hajda]

extcon device is used to detect host/device connection. Since extcon
OF property is deprecated, alternative method should be added.
This method uses OF graph bindings to locate extcon.

Signed-off-by: Andrzej Hajda 
---
 drivers/usb/dwc3/drd.c | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index 1d8c557e97e0..270682486f82 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "debug.h"
@@ -439,17 +440,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
 }
 
+struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
+{
+   struct device *dev = dwc->dev;
+   struct device_node *np_phy, *np_conn;
+   struct extcon_dev *edev;
+
+   if (of_property_read_bool(dev->of_node, "extcon"))
+   return extcon_get_edev_by_phandle(dwc->dev, 0);
+
+   np_phy = of_parse_phandle(dev->of_node, "phys", 0);
+   np_conn = of_graph_get_remote_node(np_phy, -1, -1);
+
+   if (np_conn)
+   edev = extcon_find_edev_by_node(np_conn);
+   else
+   edev = NULL;
+
+   of_node_put(np_conn);
+   of_node_put(np_phy);
+
+   return edev;
+}
+
 int dwc3_drd_init(struct dwc3 *dwc)
 {
int ret, irq;
 
-   if (dwc->dev->of_node &&
-   of_property_read_bool(dwc->dev->of_node, "extcon")) {
-   dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
-
-   if (IS_ERR(dwc->edev))
-   return PTR_ERR(dwc->edev);
+   dwc->edev = dwc3_get_extcon(dwc);
+   if (IS_ERR(dwc->edev))
+   return PTR_ERR(dwc->edev);
 
+   if (dwc->edev) {
dwc->edev_nb.notifier_call = dwc3_drd_notifier;
ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
   >edev_nb);
-- 
2.17.0

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

[PATCH v2 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC

[Andrzej Hajda]

OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.

Signed-off-by: Andrzej Hajda 
---
 .../dts/exynos/exynos5433-tm2-common.dtsi | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 03453b822093..042e5894a138 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -868,6 +868,18 @@
};
};
};
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   muic_to_usb: endpoint {
+   remote-endpoint = 
<_to_muic>;
+   };
+   };
+   };
};
 
regulators {
@@ -1287,12 +1299,17 @@
 
 _dwc3 {
dr_mode = "otg";
-   extcon = <>;
 };
 
 _phy {
vbus-supply = <_reg>;
status = "okay";
+
+   port {
+   usb_to_muic: endpoint {
+   remote-endpoint = <_to_usb>;
+   };
+   };
 };
 
  {
-- 
2.17.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/RFC v3 1/4] base: devcon: add a new API to find the graph

[Yoshihiro Shimoda]

Hi Heikki,

Thank you for the reply!

> From: Heikki Krogerus, Sent: Tuesday, May 15, 2018 5:29 PM
> 
> On Tue, May 15, 2018 at 02:19:14AM +, Yoshihiro Shimoda wrote:
> > Hi Heikki,
> >
> > > From: Heikki Krogerus, Sent: Monday, May 14, 2018 10:28 PM
> > >
> > > On Mon, May 14, 2018 at 06:15:57PM +0900, Yoshihiro Shimoda wrote:

> > > > +struct device *device_connection_find_by_graph(struct device *dev, u32 
> > > > port,
> > > > +  u32 endpoint)
> > > > +{
> > > > +   struct bus_type *bus;
> > > > +   struct fwnode_handle *remote;
> > > > +   struct device *conn;
> > > > +
> > > > +   remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, 
> > > > endpoint);
> > > > +   if (!remote)
> > > > +   return NULL;
> > > > +
> > > > +   for (bus = generic_match_buses[0]; bus; bus++) {
> > > > +   conn = bus_find_device(bus, NULL, remote, 
> > > > generic_graph_match);
> > > > +   if (conn)
> > > > +   return conn;
> > > > +   }
> > > > +
> > > > +   /*
> > > > +* We only get called if a connection was found, tell the 
> > > > caller to
> > > > +* wait for the other device to show up.
> > > > +*/
> > > > +   return ERR_PTR(-EPROBE_DEFER);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
> > >
> > > Why do we need more API for walking through the graph?
> >
> > I thought there is difficult to find if a device has multiple ports or 
> > endpoints.
> > So, I'd like to use port and endpoint number for finding a device.
> >
> > > I'm not sure exactly sure what is going on here, I'll try to study
> > > your patches more when I have time, but the approach looks wrong. That
> > > function looks like a helper, but just not that useful one.
> > >
> > > We really should be able to use the existing functions. In practice
> > > device_connection_find_match() should eventually parse the graph, then
> > > fallback to build-in connections if no graph is found. Otherwise
> > > parsing graph here is not really useful at all.
> >
> > I think using device_connection_find_match() for finding the graph becomes 
> > complicated.
> > The current arguments of the function is the below:
> >
> > void *device_connection_find_match(struct device *dev, const char *con_id,
> >void *data,
> >void *(*match)(struct device_connection *con,
> >   int ep, void *data))
> >
> > If finding the graph, the following arguments will be not used.
> >  - con_id
> >  - *con and ep of "match" arguments.
> >
> > This is because these arguments are for the build-in connections.
> 
> No they're not. You do realize that we can build a temporary struct
> device_connection there and then (in stack) to be supplied for the
> ->match callback.

I understood it.

> > So, should I modify the arguments of the function for finding both
> > the graph and built-in connections somehow?
> 
> I don't see any need for that. We may need to modify struct
> device_connection, but there should not be any need to touch the API.
> 
> Your plan to use port and endpoint number is wrong, as they are just
> indexes, and therefore not reliable. Luckily it should be completely
> unnecessary to use them.
> 
> The way I see this working is that we parse all the endpoints the
> caller device has. If we can't take advantage of the con_id for
> identification (though ideally we can), we just need to call ->match
> with every one of them. The implementation for the ->match callback is
> then responsible of figuring out if the endpoint is the one we are
> looking for or not in that case.

I understood it. But, I need to investigate how to find a device.

> The only problem I see with that is that we may not have a reliable
> way to convert the fwnode pointing to the remote-endpoint parent into
> struct device (if one has already been enumerated) in order to get the
> device name and use it as the second endpoint name in struct
> device_connection. To solve that, we could consider for example just
> adding a new member, fwnode pointer perhaps, to the structure. Or
> perhaps use the endpoint members for something else than device names
> when graph is used, and add a member defining the type of match:
> graph, build-in, etc. There are many things we can consider.

I don't understand why adding such new member(s) can solve that.
Anyway, I will investigate this more...

> I don't know if I'm able to explain what I'm after with this, so if
> you like, I can propose something for this myself. Though that will
> have to wait for few weeks. Right now I'm too busy with other stuff.

Thank you for your proposal! However, I'd like to try to investigate
once more while you are too busy.

Best regards,
Yoshihiro Shimoda

> 
> Thanks,
> 
> --
> heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in

Re: [PATCH v2 11/11] docs: fix broken references with multiple hints

[Bartlomiej Zolnierkiewicz]

On Wednesday, May 09, 2018 10:18:54 AM Mauro Carvalho Chehab wrote:
> The script:
>   ./scripts/documentation-file-ref-check --fix-rst
> 
> Gives multiple hints for broken references on some files.
> Manually use the one that applies for some files.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Bartlomiej Zolnierkiewicz  # for fbdev part

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH v2] usb: dwc2: Fix kernel doc's warnings.

[Minas Harutyunyan]

Hi Filipe,

Please pickup this patch to your testing/next.

Thanks,
Minas


On 4/10/2018 9:59 AM, Minas Harutyunyan wrote:
> Hi,
> 
> On 4/3/2018 5:15 PM, Grigor Tovmasyan wrote:
>> Added descriptions for all not described parameters.
>> Fix all kernel doc's warnings.
>>
>> Signed-off-by: Grigor Tovmasyan 
>> ---
>> Changes from version 1:
>>
>> Fix minor kernel-doc style issue.
>>
>> Changes from version 0:
>>
>> Rebased to balbi/next.
>> Fixed new kernel-doc warnings which cames from new patches.
>> ---
>>drivers/usb/dwc2/core.c  |   7 ++
>>drivers/usb/dwc2/core.h  | 166 
>> +++
>>drivers/usb/dwc2/debug.h |   2 +-
>>drivers/usb/dwc2/debugfs.c   |  19 ++---
>>drivers/usb/dwc2/gadget.c|  29 +---
>>drivers/usb/dwc2/hcd.c   |   3 +-
>>drivers/usb/dwc2/hcd.h   |  14 ++--
>>drivers/usb/dwc2/hcd_ddma.c  |   1 +
>>drivers/usb/dwc2/hcd_intr.c  |  12 
>>drivers/usb/dwc2/hcd_queue.c |   5 +-
>>drivers/usb/dwc2/params.c|   8 +++
>>drivers/usb/dwc2/pci.c   |   6 ++
>>12 files changed, 213 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>> index 18a0a1771289..1c36a6a9dd63 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -419,6 +419,8 @@ static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
>>/**
>> * dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
>> * filter is enabled.
>> + *
>> + * @hsotg: Programming view of DWC_otg controller
>> */
>>static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
>>{
>> @@ -564,6 +566,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool 
>> skip_wait)
>> * If a force is done, it requires a IDDIG debounce filter delay if
>> * the filter is configured and enabled. We poll the current mode of
>> * the controller to account for this delay.
>> + *
>> + * @hsotg: Programming view of DWC_otg controller
>> + * @host: Host mode flag
>> */
>>void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>>{
>> @@ -610,6 +615,8 @@ void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
>> * or not because the value of the connector ID status is affected by
>> * the force mode. We only need to call this once during probe if
>> * dr_mode == OTG.
>> + *
>> + * @hsotg: Programming view of DWC_otg controller
>> */
>>static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
>>{
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index d83be5651f87..c2c08cbbc19b 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -164,12 +164,11 @@ struct dwc2_hsotg_req;
>> *   and has yet to be completed (maybe due to data move, or simply
>> *   awaiting an ack from the core all the data has been completed).
>> * @debugfs: File entry for debugfs file for this endpoint.
>> - * @lock: State lock to protect contents of endpoint.
>> * @dir_in: Set to true if this endpoint is of the IN direction, which
>> *  means that it is sending data to the Host.
>> * @index: The index for the endpoint registers.
>> * @mc: Multi Count - number of transactions per microframe
>> - * @interval - Interval for periodic endpoints, in frames or microframes.
>> + * @interval: Interval for periodic endpoints, in frames or microframes.
>> * @name: The name array passed to the USB core.
>> * @halted: Set if the endpoint has been halted.
>> * @periodic: Set if this is a periodic ep, such as Interrupt
>> @@ -182,6 +181,7 @@ struct dwc2_hsotg_req;
>> * @next_desc: index of next free descriptor in the ISOC chain under SW 
>> control.
>> * @total_data: The total number of data bytes done.
>> * @fifo_size: The size of the FIFO (for periodic IN endpoints)
>> + * @fifo_index: For Dedicated FIFO operation, only FIFO0 can be used for 
>> EP0.
>> * @fifo_load: The amount of data loaded into the FIFO (periodic IN)
>> * @last_load: The offset of data for the last start of request.
>> * @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
>> @@ -380,6 +380,9 @@ enum dwc2_ep0_state {
>> *  is FS.
>> *   0 - No (default)
>> *   1 - Yes
>> + * @acg_enable: For enabling Active Clock Gating in the 
>> controller
>> + *   0 - No
>> + *   1 - Yes
>> * @ulpi_fs_ls: Make ULPI phy operate in FS/LS mode only
>> *   0 - No (default)
>> *   1 - Yes
>> @@ -548,7 +551,7 @@ struct dwc2_core_params {
>> *
>> * The values that are not in dwc2_core_params are documented below.
>> *
>> - * @op_mode Mode of Operation
>> + * @op_mode: Mode of Operation
>> *   0 - HNP- and 

Re: [PATCH] usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

[Minas Harutyunyan]

On 4/16/2018 2:16 PM, Grigor Tovmasyan wrote:
> In dwc2_gadget_init() we allocate EP0 request via
> dwc2_hsotg_ep_alloc_request(). After that there are
> usb_add_gadget_udc() call and if it failed, then
> ctrl_req will not be freed and will cause memory leak.
> 
> Reordered function calls in gadget_init: moved up usb_add_gadget_udc()
> before dwc2_hsotg_ep_alloc_request().
> 
> Tested using kmemleak.
> 
> Cc: Stefan Wahren 
> Signed-off-by: Grigor Tovmasyan 
> ---

Acked-by: Minas Harutyunyan 

>   drivers/usb/dwc2/gadget.c | 8 
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6c32bf26e48e..24000bda5c20 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -4679,6 +4679,10 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
>   INIT_LIST_HEAD(>gadget.ep_list);
>   hsotg->gadget.ep0 = >eps_out[0]->ep;
>   
> + ret = usb_add_gadget_udc(dev, >gadget);
> + if (ret)
> + return ret;
> +
>   /* allocate EP0 request */
>   
>   hsotg->ctrl_req = dwc2_hsotg_ep_alloc_request(>eps_out[0]->ep,
> @@ -4698,10 +4702,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
> epnum, 0);
>   }
>   
> - ret = usb_add_gadget_udc(dev, >gadget);
> - if (ret)
> - return ret;
> -
>   dwc2_hsotg_dump(hsotg);
>   
>   return 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: Not enough bandwidth with Magewell XI100DUSB-HDMI

[Michael Tretter]

Hi Mathias,

On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote:
> On 09.04.2018 11:21, Michael Tretter wrote:
> > On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote:  
> >> On 16.02.2018 15:28, Michael Tretter wrote:  
> >>> On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote:  
>  On 19.01.2018 22:12, Philipp Zabel wrote:  
> > On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter
> >  wrote:  
> >> I found the old thread and it sounds exactly like my issue. Different
> >> camera, but same xHCI controller.  
> >
> > I have exactly the same issue with the xHCI controller of my laptop and
> > "Oculus Sensor" USB3 isochronous mostly-UVC cameras:
> >
> > 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI
> > Controller (rev 03) (prog-if 30 [XHCI])
> >Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller
> >Flags: bus master, medium devsel, latency 0, IRQ 44
> >Memory at f222 (64-bit, non-prefetchable) [size=64K]
> >Capabilities: [70] Power Management version 2
> >Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
> >Kernel driver in use: xhci_hcd
> >Kernel modules: xhci_pci
> >
> > T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
> > D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
> > P:  Vendor=2833 ProdID=0211 Rev= 0.00
> > S:  Manufacturer=Oculus VR
> > S:  Product=Rift Sensor
> > S:  SerialNumber=WMTD3034300BCT
> > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA
> > A:  FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00
> > I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo
> > E:  Ad=83(I) Atr=03(Int.) MxPS=  32 Ivl=128ms
> > I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
> > I:  If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
> > E:  Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us
> > I:  If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
> > E:  Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us
> >
> > Any USB2 or USB3 device that I plug in while the first camera is 
> > streaming in
> > altsetting 1 or 2 causes the bandwidth error. The same happens when I 
> > try to
> > change the altsetting on an isochronous endpoint of an already plugged 
> > device.
> > While the camera is in altsetting 0, other devices can be probed and 
> > work.
> > 
> >> For some tests, I changed the xhci_change_max_exit_latency() function
> >> to ignore the requested MEL and set the MEL to 0. Now the USB devices
> >> are detected correctly.  
> >
> > Exactly the same thing helps here, as well. With this hack, streaming 
> > from two
> > of those cameras at the same time works without any apparent problem:
> >
> > --8<--
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index 297536c9fd00..3cb4a60d8822 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -4025,7 +4025,7 @@ static int __maybe_unused
> > xhci_change_max_exit_latency(struct xhci_hcd *xhci,
> >ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
> >slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx);
> >slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT));
> > -   slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency);
> > +   slot_ctx->dev_info2 |= cpu_to_le32(0);
> >slot_ctx->dev_state = 0;
> >
> >xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,  
> > -->8--  
> > 
> 
>  Ok, back after a week on sickleave.
>  I'm getting the magewell capture device and try to reproduce this 
>  myself.  
> >>>
> >>> I don't think that the issue is specific to the magewell capture
> >>> device, but rather should be reproducible with any USB3 device with
> >>> isochronous endpoints.
> >>>
> >>> Anyway, please tell me, if I can somehow help you to get this properly
> >>> fixed.  
> >>
> >> I'm currently looking at device reset issues after suspend, but this is on 
> >> the
> >> todo list.
> >>
> >> I got a magewell device, (haven't unboxed it yet)
> >> Maybe step by step instructions to reproduce it could speed things up.  
> > 
> > Did you have time to unbox and test the Magewell device?
> >   
> 
> This seems to always get postponed due to other work,
> 
> I just tried it out once today on a nearby laptop, gst-launch seems to work
> but couldn't reproduce the bandwidth issue when connecting a second usb 
> device.
> 
> But I haven't really tested it out properly yet.

I just tested with 4.17-rc5 and the behavior remains the same. Is there
anything else I could do to get this fixed?

Michael
--
To unsubscribe from this list: 

Re: [PATCH] usb: dwc2: Add Interpacket Gap(IPG) feature support

[Minas Harutyunyan]

On 5/5/2018 12:18 PM, Grigor Tovmasyan wrote:
> Added GHWCFG4_IPG_ISOC_SUPPORTED and DCFG_IPG_ISOC_SUPPORDED
> bits definitions to enable/disable IPG feature.
> 
> Added ipg_isoc_en core parameter which will indicate IPG support
> enable/disable and initialize it.
> 
> Signed-off-by: Grigor Tovmasyan 
> ---

Acked-by: Minas Harutyunyan 

>   drivers/usb/dwc2/core.h| 11 +++
>   drivers/usb/dwc2/debugfs.c |  1 +
>   drivers/usb/dwc2/gadget.c  |  3 +++
>   drivers/usb/dwc2/hw.h  |  2 ++
>   drivers/usb/dwc2/params.c  |  3 +++
>   5 files changed, 20 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index d83be5651f87..cacc6badfd6f 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -380,6 +380,9 @@ enum dwc2_ep0_state {
>*  is FS.
>*   0 - No (default)
>*   1 - Yes
> + * @ipg_isoc_en Indicates the IPG supports is enabled or disabled.
> + *   0 - Disable (default)
> + *   1 - Enable
>* @ulpi_fs_ls: Make ULPI phy operate in FS/LS mode only
>*   0 - No (default)
>*   1 - Yes
> @@ -511,6 +514,7 @@ struct dwc2_core_params {
>   bool hird_threshold_en;
>   u8 hird_threshold;
>   bool activate_stm_fs_transceiver;
> + bool ipg_isoc_en;
>   u16 max_packet_count;
>   u32 max_transfer_size;
>   u32 ahbcfg;
> @@ -560,6 +564,12 @@ struct dwc2_core_params {
>*   0 - Slave only
>*   1 - External DMA
>*   2 - Internal DMA
> + * @ipg_isoc_en This feature indicates that the controller supports
> + *  the worst-case scenario of Rx followed by Rx
> + *  Interpacket Gap (IPG) (32 bitTimes) as per the utmi
> + *  specification for any token following ISOC OUT token.
> + *   0 - Don't support
> + *   1 - Support
>* @power_optimized Are power optimizations enabled?
>* @num_dev_ep  Number of device endpoints available
>* @num_dev_in_eps  Number of device IN endpoints available
> @@ -622,6 +632,7 @@ struct dwc2_hw_params {
>   unsigned hibernation:1;
>   unsigned utmi_phy_data_width:2;
>   unsigned lpm_mode:1;
> + unsigned ipg_isoc_en:1;
>   u32 snpsid;
>   u32 dev_ep_dirs;
>   u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
> diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c
> index 58c691f882a8..5897333600a7 100644
> --- a/drivers/usb/dwc2/debugfs.c
> +++ b/drivers/usb/dwc2/debugfs.c
> @@ -710,6 +710,7 @@ static int params_show(struct seq_file *seq, void *v)
>   print_param(seq, p, phy_ulpi_ddr);
>   print_param(seq, p, phy_ulpi_ext_vbus);
>   print_param(seq, p, i2c_enable);
> + print_param(seq, p, ipg_isoc_en);
>   print_param(seq, p, ulpi_fs_ls);
>   print_param(seq, p, host_support_fs_ls_low_power);
>   print_param(seq, p, host_ls_low_power_phy_clk);
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6c32bf26e48e..70a7ae84eb53 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3259,6 +3259,9 @@ void dwc2_hsotg_core_init_disconnected(struct 
> dwc2_hsotg *hsotg,
>   dcfg |= DCFG_DEVSPD_HS;
>   }
>   
> + if (hsotg->params.ipg_isoc_en)
> + dcfg |= DCFG_IPG_ISOC_SUPPORDED;
> +
>   dwc2_writel(dcfg,  hsotg->regs + DCFG);
>   
>   /* Clear any pending OTG interrupts */
> diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
> index 38391e48351f..0ca8e7bc7aaf 100644
> --- a/drivers/usb/dwc2/hw.h
> +++ b/drivers/usb/dwc2/hw.h
> @@ -311,6 +311,7 @@
>   #define GHWCFG4_UTMI_PHY_DATA_WIDTH_MASK(0x3 << 14)
>   #define GHWCFG4_UTMI_PHY_DATA_WIDTH_SHIFT   14
>   #define GHWCFG4_ACG_SUPPORTED   BIT(12)
> +#define GHWCFG4_IPG_ISOC_SUPPORTED   BIT(11)
>   #define GHWCFG4_UTMI_PHY_DATA_WIDTH_8   0
>   #define GHWCFG4_UTMI_PHY_DATA_WIDTH_16  1
>   #define GHWCFG4_UTMI_PHY_DATA_WIDTH_8_OR_16 2
> @@ -424,6 +425,7 @@
>   #define DCFG_EPMISCNT_SHIFT 18
>   #define DCFG_EPMISCNT_LIMIT 0x1f
>   #define DCFG_EPMISCNT(_x)   ((_x) << 18)
> +#define DCFG_IPG_ISOC_SUPPORDED  BIT(17)
>   #define DCFG_PERFRINT_MASK  (0x3 << 11)
>   #define DCFG_PERFRINT_SHIFT 11
>   #define DCFG_PERFRINT_LIMIT 0x3
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index f03e41879224..2700f5279285 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -298,6 +298,7 @@ static void dwc2_set_default_params(struct dwc2_hsotg 
> *hsotg)
>   p->besl = true;
>   p->hird_threshold_en = true;
>   p->hird_threshold = 4;
> + 

Re: [PATCH] usb: dwc2: Change reading of current frame number flow.

[Minas Harutyunyan]

On 5/5/2018 5:46 PM, Artur Petrosyan wrote:
> The current frame_number is read from core for both
> device and host modes. Reading of the current frame
> number needs to be performed ASAP due to IRQ latency's.
> This is why, it is moved to common interrupt handler.
> 
> Accordingly updated dwc2_gadget_target_frame_elapsed()
> function which uses stored frame_number instead of
> reading frame number.
> 
> In cases when target frame value is incremented
> the frame_number is required to read again.
> 
> Signed-off-by: Artur Petrosyan 
> ---

Acked-by: Minas Harutyunyan 

>   drivers/usb/dwc2/core.h  |  7 ---
>   drivers/usb/dwc2/core_intr.c |  8 
>   drivers/usb/dwc2/gadget.c| 13 +++--
>   3 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index d83be5651f87..a435db4fe948 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -813,6 +813,9 @@ struct dwc2_hregs_backup {
>* @gadget_enabled  Peripheral mode sub-driver initialization indicator.
>* @ll_hw_enabled   Status of low-level hardware resources.
>* @hibernated: True if core is hibernated
> + * @frame_number:   Frame number read from the core. For both device
> + *   and host modes. The value ranges are from 0
> + *   to HFNUM_MAX_FRNUM.
>* @phy:The otg phy transceiver structure for phy control.
>* @uphy:   The otg phy transceiver structure for old USB phy
>*  control.
> @@ -886,8 +889,6 @@ struct dwc2_hregs_backup {
>* @hs_periodic_bitmap: Bitmap used by the microframe scheduler any time the
>*  host is in high speed mode; low speed schedules are
>*  stored elsewhere since we need one per TT.
> - * @frame_number:   Frame number read from the core at SOF. The value 
> ranges
> - *  from 0 to HFNUM_MAX_FRNUM.
>* @periodic_qh_count:  Count of periodic QHs, if using several eps. Used 
> for
>*  SOF enable/disable.
>* @free_hc_list:   Free host channels in the controller. This is a 
> list of
> @@ -954,6 +955,7 @@ struct dwc2_hsotg {
>   unsigned int gadget_enabled:1;
>   unsigned int ll_hw_enabled:1;
>   unsigned int hibernated:1;
> + u16 frame_number;
>   
>   struct phy *phy;
>   struct usb_phy *uphy;
> @@ -1027,7 +1029,6 @@ struct dwc2_hsotg {
>   u16 periodic_usecs;
>   unsigned long hs_periodic_bitmap[
>   DIV_ROUND_UP(DWC2_HS_SCHEDULE_US, BITS_PER_LONG)];
> - u16 frame_number;
>   u16 periodic_qh_count;
>   bool bus_suspended;
>   bool new_connection;
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index 2982a155734d..cc90b58b6b3c 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -778,6 +778,14 @@ irqreturn_t dwc2_handle_common_intr(int irq, void *dev)
>   goto out;
>   }
>   
> + /* Reading current frame number value in device or host modes. */
> + if (dwc2_is_device_mode(hsotg))
> + hsotg->frame_number = (dwc2_readl(hsotg->regs + DSTS)
> +& DSTS_SOFFN_MASK) >> DSTS_SOFFN_SHIFT;
> + else
> + hsotg->frame_number = (dwc2_readl(hsotg->regs + HFNUM)
> +& HFNUM_FRNUM_MASK) >> HFNUM_FRNUM_SHIFT;
> +
>   gintsts = dwc2_read_common_intr(hsotg);
>   if (gintsts & ~GINTSTS_PRTINT)
>   retval = IRQ_HANDLED;
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6c32bf26e48e..f7343cda3234 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -1235,7 +1235,7 @@ static bool dwc2_gadget_target_frame_elapsed(struct 
> dwc2_hsotg_ep *hs_ep)
>   {
>   struct dwc2_hsotg *hsotg = hs_ep->parent;
>   u32 target_frame = hs_ep->target_frame;
> - u32 current_frame = dwc2_hsotg_read_frameno(hsotg);
> + u32 current_frame = hsotg->frame_number;
>   bool frame_overrun = hs_ep->frame_overrun;
>   
>   if (!frame_overrun && current_frame >= target_frame)
> @@ -1350,8 +1350,15 @@ static int dwc2_hsotg_ep_queue(struct usb_ep *ep, 
> struct usb_request *req,
>   return 0;
>   }
>   
> - while (dwc2_gadget_target_frame_elapsed(hs_ep))
> + /* Update current frame number value. */
> + hs->frame_number = dwc2_hsotg_read_frameno(hs);
> + while (dwc2_gadget_target_frame_elapsed(hs_ep)) {
>   dwc2_gadget_incr_frame_num(hs_ep);
> + /* Update current frame number value once more as it
> +  * changes here.
> +  */
> + hs->frame_number = dwc2_hsotg_read_frameno(hs);
> + }
>   
>  

Re: [PATCH] usb: dwc2: Fix crash in incomplete isoc intr handlers.

[Minas Harutyunyan]

On 5/5/2018 12:30 PM, Artur Petrosyan wrote:
> Crash caused by going out of "eps_out" array range.
> Iteration on "eps_out" changed to less than "num_of_eps".
> 
> Signed-off-by: Artur Petrosyan 
> ---
Acked-by: Minas Harutyunyan 

>   drivers/usb/dwc2/gadget.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 6c32bf26e48e..010cfbca962a 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -3427,7 +3427,7 @@ static void 
> dwc2_gadget_handle_incomplete_isoc_in(struct dwc2_hsotg *hsotg)
>   
>   daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
>   
> - for (idx = 1; idx <= hsotg->num_of_eps; idx++) {
> + for (idx = 1; idx < hsotg->num_of_eps; idx++) {
>   hs_ep = hsotg->eps_in[idx];
>   /* Proceed only unmasked ISOC EPs */
>   if (!hs_ep->isochronous || (BIT(idx) & ~daintmsk))
> @@ -3473,7 +3473,7 @@ static void 
> dwc2_gadget_handle_incomplete_isoc_out(struct dwc2_hsotg *hsotg)
>   daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
>   daintmsk >>= DAINT_OUTEP_SHIFT;
>   
> - for (idx = 1; idx <= hsotg->num_of_eps; idx++) {
> + for (idx = 1; idx < hsotg->num_of_eps; idx++) {
>   hs_ep = hsotg->eps_out[idx];
>   /* Proceed only unmasked ISOC EPs */
>   if (!hs_ep->isochronous || (BIT(idx) & ~daintmsk))
> @@ -3647,7 +3647,7 @@ static irqreturn_t dwc2_hsotg_irq(int irq, void *pw)
>   dwc2_writel(gintmsk, hsotg->regs + GINTMSK);
>   
>   dev_dbg(hsotg->dev, "GOUTNakEff triggered\n");
> - for (idx = 1; idx <= hsotg->num_of_eps; idx++) {
> + for (idx = 1; idx < hsotg->num_of_eps; idx++) {
>   hs_ep = hsotg->eps_out[idx];
>   /* Proceed only unmasked ISOC EPs */
>   if (!hs_ep->isochronous || (BIT(idx) & ~daintmsk))
> 

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

Hello

[Mr.Joel Toure]

Dear Friend,
I am Mr. Joel TOURE,a banker by profession and I work with one of the 
largest bank here as the Group Managing Director/Chief Executive 
Officer.
Meanwhile,I'm seriously in need of a partner then I decide to contact 
you believing that you can partner with me as I have opportunity to 
transfer overdue funds worth Four Million Five Hundred Thousand US 
dollars (US$4,500.000.00) out from my bank and i need a serious and 
Trustworthy partner who can provide a reliable bank account where the 
money can be transfer .
So, if you interested and agree with me then contact me here  ( 
elume...@aol.fr )  and i will give you full details.
Mr. Joel TOURE
+22675329619





--
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 v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Yoshihiro Shimoda]

Hi Simon-san,

> From: Simon Horman, Sent: Tuesday, May 15, 2018 5:04 PM
> 
> On Tue, May 15, 2018 at 08:02:00AM +, Yoshihiro Shimoda wrote:
> > Hi Simon-san,
> >
> > Thank you for your review!
> >
> > > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> > > On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> > 
> > > >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > > >  {
> > > > -   _usb3_set_mode(usb3, host);
> > > > +   if (usb3->role_sw)
> > > > +   usb_role_switch_set_role(usb3->role_sw, host ?
> > > > +USB_ROLE_HOST : 
> > > > USB_ROLE_DEVICE);
> > > > +   else
> > > > +   _usb3_set_mode(usb3, host);
> > > >  }
> > > >
> > > >  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > > > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 
> > > > *usb3, bool host, bool a_dev)
> > > >  {
> > > > unsigned long flags;
> > > >
> > > > -   spin_lock_irqsave(>lock, flags);
> > > > usb3_set_mode(usb3, host);
> > > > +   spin_lock_irqsave(>lock, flags);
> > >
> > > Hi Shimoda-san,
> > >
> > > could you clarify why moving this lock is safe?
> >
> > The usb3_set_mode() is possible to call usb_role_switch_set_role() API
> > and usb_role_switch_set_role() calls mutex_lock().
> > So, this moving this lock (especially avoiding irqsave) needs.
> 
> Thanks, that make sense.
> 
> But usb3_set_mode() may also call _usb3_set_mode().
> It is safe to call _usb3_set_mode() without holding the lock?

Thank you for the pointed out. I am thinking it is possible to be
unsafe without holding the lock. So, I'd like to improve this patch somehow
(for example: Add new usb role switch APIs without mutex).

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/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Simon Horman]

On Tue, May 15, 2018 at 08:02:00AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> Thank you for your review!
> 
> > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> > On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> 
> > >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > >  {
> > > - _usb3_set_mode(usb3, host);
> > > + if (usb3->role_sw)
> > > + usb_role_switch_set_role(usb3->role_sw, host ?
> > > +  USB_ROLE_HOST : USB_ROLE_DEVICE);
> > > + else
> > > + _usb3_set_mode(usb3, host);
> > >  }
> > >
> > >  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 
> > > *usb3, bool host, bool a_dev)
> > >  {
> > >   unsigned long flags;
> > >
> > > - spin_lock_irqsave(>lock, flags);
> > >   usb3_set_mode(usb3, host);
> > > + spin_lock_irqsave(>lock, flags);
> > 
> > Hi Shimoda-san,
> > 
> > could you clarify why moving this lock is safe?
> 
> The usb3_set_mode() is possible to call usb_role_switch_set_role() API
> and usb_role_switch_set_role() calls mutex_lock().
> So, this moving this lock (especially avoiding irqsave) needs.

Thanks, that make sense.

But usb3_set_mode() may also call _usb3_set_mode().
It is safe to call _usb3_set_mode() without holding the lock?

> Best regards,
> Yoshihiro Shimoda
> 
> > >   usb3_vbus_out(usb3, a_dev);
> > >   /* for A-Peripheral or forced B-device mode */
> > >   if ((!host && a_dev) ||
> > > --
> > > 1.9.1
> > >
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Yoshihiro Shimoda]

Hi Simon-san,

Thank you for your review!

> From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:

> >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> >  {
> > -   _usb3_set_mode(usb3, host);
> > +   if (usb3->role_sw)
> > +   usb_role_switch_set_role(usb3->role_sw, host ?
> > +USB_ROLE_HOST : USB_ROLE_DEVICE);
> > +   else
> > +   _usb3_set_mode(usb3, host);
> >  }
> >
> >  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> > bool host, bool a_dev)
> >  {
> > unsigned long flags;
> >
> > -   spin_lock_irqsave(>lock, flags);
> > usb3_set_mode(usb3, host);
> > +   spin_lock_irqsave(>lock, flags);
> 
> Hi Shimoda-san,
> 
> could you clarify why moving this lock is safe?

The usb3_set_mode() is possible to call usb_role_switch_set_role() API
and usb_role_switch_set_role() calls mutex_lock().
So, this moving this lock (especially avoiding irqsave) needs.

Best regards,
Yoshihiro Shimoda

> > usb3_vbus_out(usb3, a_dev);
> > /* for A-Peripheral or forced B-device mode */
> > if ((!host && a_dev) ||
> > --
> > 1.9.1
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

[Simon Horman]

On Tue, May 15, 2018 at 07:49:44AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> Thank you for your review!
> 
> > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:35 PM
> > 
> > On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> > > This patch fixes an issue that reconnection is possible to fail
> > > because unexpected state handling happens by the irqs. To fix the issue,
> > > the driver disables the controller's irqs when disconnected.
> > >
> > > Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> > > USB3.0 peripheral controller")
> > > Cc:  # v4.5+
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >
> > > Remarks:
> > >  - A new file in v2
> > >
> > >  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > index 0e70163..5caf78b 100644
> > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 
> > > *usb3)
> > >   usb3_usb2_pullup(usb3, 0);
> > >   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
> > >   usb3_reset_epc(usb3);
> > > + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> > > +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> > > +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> > > +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> > > +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);
> > 
> > Hi Shimoda-san,
> > 
> > is it intentional that USB_INT_1_VBUS_CNG is not disabled above?
> 
> Yes, because the USB_INT_1_VBUS_CNG is enabled in usb3_init_epc_registers() 
> below.

Thanks for the clarification,

Reviewed-by: Simon Horman 

> 
> > > + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> > > + usb3_init_epc_registers(usb3);
> 
> Best regards,
> Yoshihiro Shimoda
> 
> > >   if (usb3->driver)
> > >   usb3->driver->disconnect(>gadget);
> > > --
> > > 1.9.1
> > >
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

[Simon Horman]

On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> This patch uses usb role switch API if the register suceeeded.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index c878449..bfb5803 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -657,7 +657,11 @@ static void _usb3_set_mode(struct renesas_usb3 *usb3, 
> bool host)
>  
>  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
>  {
> - _usb3_set_mode(usb3, host);
> + if (usb3->role_sw)
> + usb_role_switch_set_role(usb3->role_sw, host ?
> +  USB_ROLE_HOST : USB_ROLE_DEVICE);
> + else
> + _usb3_set_mode(usb3, host);
>  }
>  
>  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> bool host, bool a_dev)
>  {
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
>   usb3_set_mode(usb3, host);
> + spin_lock_irqsave(>lock, flags);

Hi Shimoda-san,

could you clarify why moving this lock is safe?

>   usb3_vbus_out(usb3, a_dev);
>   /* for A-Peripheral or forced B-device mode */
>   if ((!host && a_dev) ||
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

[Yoshihiro Shimoda]

Hi Simon-san,

Thank you for your review!

> From: Simon Horman, Sent: Tuesday, May 15, 2018 4:35 PM
> 
> On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> > This patch fixes an issue that reconnection is possible to fail
> > because unexpected state handling happens by the irqs. To fix the issue,
> > the driver disables the controller's irqs when disconnected.
> >
> > Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> > USB3.0 peripheral controller")
> > Cc:  # v4.5+
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >
> > Remarks:
> >  - A new file in v2
> >
> >  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > b/drivers/usb/gadget/udc/renesas_usb3.c
> > index 0e70163..5caf78b 100644
> > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 *usb3)
> > usb3_usb2_pullup(usb3, 0);
> > usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
> > usb3_reset_epc(usb3);
> > +   usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> > +  USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> > +  USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> > +  USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> > +  USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);
> 
> Hi Shimoda-san,
> 
> is it intentional that USB_INT_1_VBUS_CNG is not disabled above?

Yes, because the USB_INT_1_VBUS_CNG is enabled in usb3_init_epc_registers() 
below.

> > +   usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> > +   usb3_init_epc_registers(usb3);

Best regards,
Yoshihiro Shimoda

> > if (usb3->driver)
> > usb3->driver->disconnect(>gadget);
> > --
> > 1.9.1
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] usb: dwc2: Move dwc2_readl/writel functions after hsotg structure

[Minas Harutyunyan]

Hi Filipe,

On 5/15/2018 11:19 AM, Felipe Balbi wrote:
> Gevorg Sahakya  writes:
> 
>> From: Gevorg Sahakyan 
>>
>> Moved dwc2_readl/writel functions after hsotg declaration for
>> adding hsotg structure to dwc2_readl/writel function prototypes.
>>
>> Signed-off-by: Gevorg Sahakyan 
>> Signed-off-by: Gevorg Sahakya 
> 
> Why two signed-off-by for the same person?
> 

Second signed-off added wrongly. Should Gevorg re-submit the patch with 
1 signed-off?

Thanks,
Minas
--
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 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

[Simon Horman]

On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that reconnection is possible to fail
> because unexpected state handling happens by the irqs. To fix the issue,
> the driver disables the controller's irqs when disconnected.
> 
> Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> USB3.0 peripheral controller")
> Cc:  # v4.5+
> Signed-off-by: Yoshihiro Shimoda 
> ---
> 
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 0e70163..5caf78b 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 *usb3)
>   usb3_usb2_pullup(usb3, 0);
>   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
>   usb3_reset_epc(usb3);
> + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);

Hi Shimoda-san,

is it intentional that USB_INT_1_VBUS_CNG is not disabled above?

> + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> + usb3_init_epc_registers(usb3);
>  
>   if (usb3->driver)
>   usb3->driver->disconnect(>gadget);
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings

[Krzysztof Kozlowski]

On Tue, May 15, 2018 at 9:26 AM, Felipe Balbi  wrote:
> Andrzej Hajda  writes:
>
>> extcon device is used to detect host/device connection. Since extcon
>> OF property is deprecated, alternative method should be added.
>> This method uses OF graph bindings to locate extcon.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> Hi all,
>>
>> This patch implements alternative method to get extcon from DWC3.
>> The code works but is hacky, as DWC3 must traverse different DT nodes
>> to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
>> platforms can have different paths.
>> I would be glad if it can be merged as is for now, but additional work
>> must be done to make it generic.
>> I guess on DT binding side it is OK. So the problem should be addressed
>> in the code.
>> My rough idea is to implement kind of extcon aliases/forwarder mechanism,
>> ie. USB-PHY will expect on its output remote port extcon, and it should 
>> register
>> extcon-forwarder pointing to this extcon. This way DWC3 can look for the 
>> extcon
>> on its PHY phandle, and it will receive via forwarding mechanism extcon
>> exposed by MUIC.
>> As I said this is rough idea for discussion, other propositions are welcome.
>>
>> Regards
>> Andrzej
>
> I need someone from devicetree to review and ack patch2 before I can
> apply them. Either way, this doesn't apply:

The DTS patch will go through arm-soc tree, I'll take it. The DTS
patches are independent from drivers and shall not usually go through
regular trees.

Best regards,
Krzysztof
--
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 5/6] usb: gadget: udc: renesas_usb3: should fail if devm_phy_get() returns error

[Simon Horman]

On Tue, Apr 10, 2018 at 02:38:53PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver ignores errors other than
> the non-existence of the device, f.e. a memory allocation failure
> in devm_phy_get(). So, this patch replaces devm_phy_get() with
> devm_phy_optional_get().
> 
> Reported-by: Simon Horman 
> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic 
> phy")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 233bc04..0e70163 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2636,9 +2636,11 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>* This is optional. So, if this driver cannot get a phy,
>* this driver will not handle a phy anymore.
>*/
> - usb3->phy = devm_phy_get(>dev, "usb");
> - if (IS_ERR(usb3->phy))
> - usb3->phy = NULL;
> + usb3->phy = devm_phy_optional_get(>dev, "usb");
> + if (IS_ERR(usb3->phy)) {
> + ret = PTR_ERR(usb3->phy);
> + goto err_add_udc;
> + }
>  
>   pm_runtime_enable(>dev);
>   ret = usb_add_gadget_udc(>dev, >gadget);
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: Enabling USB (auto)suspend for xHCI controllers incurs random device failures since kernel 4.15

[Mathias Nyman]

Hi


I didn't get any feedback about the suggested patch.


If you talk about this one https://marc.info/?l=linux-usb=15252835690
2325=2 then unfortunately I missed it.

Mathias, please confirm, is this patch I need to check on Dell 5855?



Ah, no, it's a different one:

https://marc.info/?l=linux-usb=152544392822763=2
also found in my for-usb-linus branch:

git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git for-usb-linus
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=for-usb-linus

-Mathias

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

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Heikki Krogerus]

Hi Mats,

On Fri, May 11, 2018 at 09:28:04PM +0200, Mats Karrman wrote:
> On 2018-05-11 13:14, Heikki Krogerus wrote:
> 
> > On Fri, May 11, 2018 at 11:05:55AM +0200, Mats Karrman wrote:
> > > On 2018-05-10 19:49, Heikki Krogerus wrote:
> > > 
> > > > On Thu, May 10, 2018 at 10:04:21AM +0200, Mats Karrman wrote:
> > > > > Hi,
> > > > > 
> > > > > On 05/09/2018 02:49 PM, Heikki Krogerus wrote:
> > > > > 
> > > > > > On Tue, May 08, 2018 at 09:10:13PM +0200, Mats Karrman wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 05/08/2018 04:25 PM, Heikki Krogerus wrote:
> > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Mon, May 07, 2018 at 11:19:40PM +0200, Mats Karrman wrote:
> > > > > > > > > > > Even so, when the mux driver "set" function is called, it 
> > > > > > > > > > > will just get the
> > > > > > > > > > > mode argument but since the mode (TYPEC_STATE_...) is 
> > > > > > > > > > > overlapping for different
> > > > > > > > > > > AMs if I understand your proposal correctly, the mux also 
> > > > > > > > > > > needs to know what AM
> > > > > > > > > > > is active.
> > > > > > > > > > > Does this imply that the mux set function signature need 
> > > > > > > > > > > to change?
> > > > > > > > > > My plan was actually to propose we get rid of the current 
> > > > > > > > > > mux handling
> > > > > > > > > > (just leave the orientation switch) in favour of the 
> > > > > > > > > > notifications I'm
> > > > > > > > > > introducing with the type-c bus for the alternate modes. 
> > > > > > > > > > The current
> > > > > > > > > > mux handling is definitely not enough, and does not work in 
> > > > > > > > > > every
> > > > > > > > > > scenario, like also you pointed out.
> > > > > > > > > So, the mux need to subscribe to each svid:mode pair it is 
> > > > > > > > > interested in using
> > > > > > > > > typec_altmode_register_notifier() and then use those 
> > > > > > > > > callbacks to switch the correct
> > > > > > > > > signals to the connector. And a driver for an off-the-shelf 
> > > > > > > > > mux device could have
> > > > > > > > > the translation between svid:mode pairs and mux device 
> > > > > > > > > specific control specified by
> > > > > > > > > of/acpi properties. Right?
> > > > > > > > Yes. That is the plan. Would it work for you?
> > > > > > > I think so. I'll give it a go. When about do you think you'll 
> > > > > > > post the next version
> > > > > > > of your RFC? Or do you have an updated series available somewhere 
> > > > > > > public?
> > > > > > I'll try to put together and post the next version tomorrow.
> > > > > > 
> > > > > > My original plan was actually to use just the notifications with the
> > > > > > muxes, but one thing to consider with the notifications is that in
> > > > > > practice we have to increment the ref count for the alt mode devices
> > > > > > when ever something registers a notifier.
> > > > > > 
> > > > > > To me that does not feel ideal. The dependency should go the other 
> > > > > > way
> > > > > > around in case of the muxes. That is why I liked the separate API 
> > > > > > and
> > > > > > handling for the muxes felt better, as it will do just that. The mux
> > > > > > is then a "service" that the port driver can as for, and if it gets 
> > > > > > a
> > > > > > handle to a mux, the mux will have its ref count incremented.
> > > > > > 
> > > > > > So I think fixing the mux API would perhaps be better after all.
> > > > > > Thoughts?
> > > > > So, we're back to a mux API similar to the current one, where:
> > > > > - the port driver and the mux driver are connected through "graph"
> > > > > - alt mode driver finds its port mux using the typec class mux api
> > > > > - the mux mode setting function arguments now include both svid and 
> > > > > mode
> > > > > 
> > > > > I like that.
> > > > > 
> > > > > One thought that popped up again is if we, somewhere down the line,
> > > > > will see some super device that support many different alternate modes
> > > > > on the same port and therefore will need to have multiple mux devices?
> > > > > However I think the mux api could be extended (later on) to support 
> > > > > some
> > > > > aggregate mux device that manages multiple physical devices.
> > > > If we simply had always a mux for every alternate mode, that would not
> > > > be a problem. So the port would have its own mux, and every supported
> > > > alternate mode also had its own. I think that removes the need to deal
> > > > with the svid:mode when using the muxes, as they are already tied to a
> > > > specific alternate modes, right? With a single mux device, for example
> > > > pi3usb30532, the driver just needs to register a mux for the port and
> > > > separate mux for DP, but I don't think that's a huge problem.
> > > Hmm... As an hypothetical example I have written a driver for another mux
> > > from TI and according to its data sheet:
> > > 
> > > """
> > > The HD3SS460 is a generic analog differential
> > > passive switch 

usb: storage: what is the correct sequence for? sd_probe| storage_probe/1/2 and uas_probe | scsi_scan_host

[Tushar Nimkar]

Everyone,

Please help me in understanding sd_probe| storage_probe/1/2 and 
uas_probe | scsi_scan_host :)
Basically want to know the correct sequence for them? How 
sd_probe_async() is called (ASYNC_DOMAIN(scsi_sd_probe_domain))?

Is there any document which say it in detail ?

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


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

Re: [PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings

[Felipe Balbi]

Andrzej Hajda  writes:

> extcon device is used to detect host/device connection. Since extcon
> OF property is deprecated, alternative method should be added.
> This method uses OF graph bindings to locate extcon.
>
> Signed-off-by: Andrzej Hajda 
> ---
> Hi all,
>
> This patch implements alternative method to get extcon from DWC3.
> The code works but is hacky, as DWC3 must traverse different DT nodes
> to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
> platforms can have different paths.
> I would be glad if it can be merged as is for now, but additional work
> must be done to make it generic.
> I guess on DT binding side it is OK. So the problem should be addressed
> in the code.
> My rough idea is to implement kind of extcon aliases/forwarder mechanism,
> ie. USB-PHY will expect on its output remote port extcon, and it should 
> register
> extcon-forwarder pointing to this extcon. This way DWC3 can look for the 
> extcon
> on its PHY phandle, and it will receive via forwarding mechanism extcon
> exposed by MUIC.
> As I said this is rough idea for discussion, other propositions are welcome.
>
> Regards
> Andrzej

I need someone from devicetree to review and ack patch2 before I can
apply them. Either way, this doesn't apply:

checking file drivers/usb/dwc3/drd.c
Hunk #1 FAILED at 8.
Hunk #2 FAILED at 38.
2 out of 2 hunks FAILED

-- 
balbi


signature.asc
Description: PGP signature

Re: dwc2 device testing with Service Interval plus LPM

[Felipe Balbi]

Hi,

Grigor Tovmasyan  writes:
> On 5/11/2018 2:42 PM, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Grigor Tovmasyan  writes:
>> 
>>> Hi all,
>>>
>>> I want to test a new feature of HSOTG core: Service Interval + LPM support 
>>> in device mode.
>>> What I need to use from host side to be able generate appropriate ISOC IN 
>>> traffic?
>> 
>> Audio class, camera class, g_zero isoc tests...
>>
> Currently I couldn't find host side driver with Service Interval support.
> Did xHCI driver support Service Interval? if yes how can I enable it?

Mathias, any idea??

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: gadget: composite: fill bcdUSB as 0x0320 for SuperSpeed or higher speeds

[Felipe Balbi]

Hi,

Chunfeng Yun  writes:
> On Wed, 2018-05-09 at 14:33 +0300, Felipe Balbi wrote:
>> Hi,
>> 
>> Chunfeng Yun  writes:
>> > The USB3CV version 2.1.80 (March 26, 2018) requires all devices
>> > ( gen1, gen2, single lane, dual lane) to return the value of 0x0320
>> > in the bcdUSB field
>> 
>> this sounds really odd. What happens when I get a USB 3.1 compliant
>> device off-the-shelf and run it through USB3CV? will it fail now?
> Yes, it will fail, the last version requires it 0x0310
>> 
>> Care to share a screenshot or the raw html of the test result?
> A screenshot is attached

really odd. But I'll apply the patch.

thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/4] usb: dwc2: Move dwc2_readl/writel functions after hsotg structure

[Felipe Balbi]

Gevorg Sahakya  writes:

> From: Gevorg Sahakyan 
>
> Moved dwc2_readl/writel functions after hsotg declaration for
> adding hsotg structure to dwc2_readl/writel function prototypes.
>
> Signed-off-by: Gevorg Sahakyan 
> Signed-off-by: Gevorg Sahakya 

Why two signed-off-by for the same person?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 1/1] drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL for usb gadget

[Felipe Balbi]

Tiago Brusamarello  writes:

> Introduce FSL_USB2_PHY_UTMI_DUAL in gadget driver for setting
> phy in SOCs with utmi dual phy
>
> Signed-off-by: Nikhil Badola 
> Tested-by: Tiago Brusamarello 

this doesn't apply. 

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