Re: [PATCH 00/16] remove eight obsolete architectures

[afzal mohammed]

Hi,

On Thu, Mar 15, 2018 at 10:56:48AM +0100, Arnd Bergmann wrote:
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:

> > Do we have anything left that still implements NOMMU?

Please don't kill !MMU.

> Yes, plenty.

> I've made an overview of the remaining architectures for my own reference[1].
> The remaining NOMMU architectures are:
> 
> - arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually
> gaining traction

ARMv7-R as well, also seems ARM is coming up with more !MMU's - v8-M,
v8-R. In addition, though only of academic interest, ARM MMU capable
platform's can run !MMU Linux.

afzal

> - arch/sh has an open-source J2 core that was added not that long ago,
> it seems to
>   be the only SH compatible core that anyone is working on.
> - arch/microblaze supports both MMU/NOMMU modes (most use an MMU)
> - arch/m68k supports several NOMMU targets, both the coldfire SoCs and the
>   classic processors
> - c6x has no MMU
--
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: chipidea: move extcon initial state read

[Peter Chen]

 
> 
> Any extcon events between the initial state read and ci_extcon_register are 
> "lost".
> This patch doesn't fix the issue entirely but reduces the chance of the 
> controller
> entering a bad state.

It seems you have already known the rare cases the lost for extcon exents,
why not fix it at this patch?

Peter
> 
> Signed-off-by: Jonathan Marek 
> ---
>   drivers/usb/chipidea/core.c | 35 +++
>   1 file changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index
> 33ae87f..a1fb2fb 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -704,25 +704,9 @@ static int ci_get_platdata(struct device *dev,
>   cable->nb.notifier_call = ci_cable_notifier;
>   cable->edev = ext_vbus;
> 
> - if (!IS_ERR(ext_vbus)) {
> - ret = extcon_get_state(cable->edev, EXTCON_USB);
> - if (ret)
> - cable->connected = true;
> - else
> - cable->connected = false;
> - }
> -
>   cable = >id_extcon;
>   cable->nb.notifier_call = ci_cable_notifier;
>   cable->edev = ext_id;
> -
> - if (!IS_ERR(ext_id)) {
> - ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
> - if (ret)
> - cable->connected = true;
> - else
> - cable->connected = false;
> - }
>   return 0;
>   }
> 
> @@ -892,6 +876,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   {
>   struct device   *dev = >dev;
>   struct ci_hdrc  *ci;
> + struct ci_hdrc_cable *cable;
>   struct resource *res;
>   void __iomem*base;
>   int ret;
> @@ -1009,6 +994,24 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   }
>   }
> 
> + cable = >platdata->vbus_extcon;
> + if (!IS_ERR(cable->edev)) {
> + ret = extcon_get_state(cable->edev, EXTCON_USB);
> + if (ret)
> + cable->connected = true;
> + else
> + cable->connected = false;
> + }
> +
> + cable = >platdata->id_extcon;
> + if (!IS_ERR(cable->edev)) {
> + ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
> + if (ret)
> + cable->connected = true;
> + else
> + cable->connected = false;
> + }
> +
>   if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
>   if (ci->is_otg) {
>   ci->role = ci_otg_role(ci);
> --
> 2.9.3
> 
> On 02/23/2018 10:06 PM, Peter Chen wrote:
> >
> >> Subject: Bugged initial state with Chipidea driver
> >>
> >> Hi,
> >>
> >> In the Chipidea driver the extcon state is read early in the
> >> initialization and notifications for extcon events are only enabled
> >> at the end of the initialization. If the extcon state changes in
> >> between the driver will miss the change in extcon state and be a bad state.
> >
> > Yes, it is the limitation, we need to move ci_extcon_register and
> > update extcon state in chipidea driver before we read ID or VBUS value
> > (through extcon)
> >
> >> Here is what happens in my case:
> >> 1. EXTCON_USB_HOST=1, EXTCON_USB=1
> >
> > Why the two events are both 1 at same time?
> >
> >> 2. USB driver reads initial extcon state 3. EXTCON_USB_HOST=0 4. USB
> >> driver choses initial role 5. USB driver enables extcon notifiers
> >> then the USB driver is stuck in host mode until the EXTCON_USB_HOST
> >> value cycles again, when it should be in gadget mode. This happens
> >> every other boot because my EXTCON_USB_HOST value is unreliable
> >> during init.
> >>
> >> I have implemented a temporary solution for myself but if you propose
> >> a proper solution I can implement it and submit a patch.
> >>
> >
> > Feel free to submit your patch.
> >
> >> Additionally, I guess this could technically happen without extcon,
> >> but it is much less likely.
> >>
> >
> > For non-extcon solution, the register (otgsc) reflect real-time vbus
> > and id value, so it should be without problem you meet.
> >
> > Peter
> >

Re: [PATCH 2/2] usb: dwc3: add clock and resets

[Masami Hiramatsu]

On Thu, 15 Mar 2018 20:39:58 +0900
Masahiro Yamada  wrote:

> dwc3-of-simple.c only handles arbitrary number of clocks and resets.
> They are both generic enough to be put into the dwc3 core.  For simple
> cases, a nested node structure like follows:
> 
>   dwc3-glue {
>   compatible = "foo,dwc3";
>   clocks = ...;
>   resets = ...;
>   ...
> 
>   dwc3 {
>   compatible = "snps,dwc3";
>   ...
>   };
>   }
> 
> would be turned into a single node:
> 
>   dwc3 {
>   compatible = "foo,dwc3", "snps,dwc3";
>   clocks = ...;
>   resets = ...;
>   ...
>   }
> 
> I inserted reset_control_deassert() and clk_enable() before the first
> register access, i.e. dwc3_cache_hwparams().

This looks good to me. 

Reviewed-by: Masami Hiramatsu 

Thanks!

> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt |   2 +
>  drivers/usb/dwc3/core.c| 127 
> -
>  drivers/usb/dwc3/core.h|   5 +
>  3 files changed, 132 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> index 44e8bab..67e9cfb 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -9,12 +9,14 @@ Required properties:
>   - interrupts: Interrupts used by the dwc3 controller.
>  
>  Optional properties:
> + - clocks: list of phandle and clock specifier pairs
>   - usb-phy : array of phandle for the PHY device.  The first element
> in the array is expected to be a handle to the USB2/HS PHY and
> the second element is expected to be a handle to the USB3/SS PHY
>   - phys: from the *Generic PHY* bindings
>   - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy"
>   or "usb3-phy".
> + - resets: list of phandle and reset specifier pairs
>   - 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 e9083a3..f17e4a9 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 
> @@ -240,6 +242,74 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
>   return -ETIMEDOUT;
>  }
>  
> +static int dwc3_core_get_clks(struct dwc3 *dwc)
> +{
> + struct device *dev = dwc->dev;
> + struct device_node *node = dev->of_node;
> + struct clk *clk;
> + int num_clks, i;
> +
> + num_clks = of_count_phandle_with_args(node, "clocks", "#clock-cells");
> + if (num_clks <= 0)
> + return 0;
> +
> + dwc->num_clks = num_clks;
> +
> + dwc->clks = devm_kcalloc(dev, num_clks, sizeof(*dwc->clks), GFP_KERNEL);
> + if (!dwc->clks)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_clks; i++) {
> + clk = of_clk_get(node, i);
> + if (IS_ERR(clk))
> + goto put_clks;
> + dwc->clks[i] = clk;
> + }
> +
> + return 0;
> +
> +put_clks:
> + while (--i >= 0)
> + clk_put(dwc->clks[i]);
> +
> + return PTR_ERR(clk);
> +}
> +
> +static void dwc3_core_put_clks(struct dwc3 *dwc)
> +{
> + int i;
> +
> + for (i = dwc->num_clks - 1; i >= 0; i--)
> + clk_put(dwc->clks[i]);
> +}
> +
> +static int dwc3_core_enable_clks(struct dwc3 *dwc)
> +{
> + int ret, i;
> +
> + for (i = 0; i < dwc->num_clks; i++) {
> + ret = clk_prepare_enable(dwc->clks[i]);
> + if (ret)
> + goto disable_clks;
> + }
> +
> + return 0;
> +
> +disable_clks:
> + while (--i >= 0)
> + clk_disable_unprepare(dwc->clks[i]);
> +
> + return ret;
> +}
> +
> +static void dwc3_core_disable_clks(struct dwc3 *dwc)
> +{
> + int i;
> +
> + for (i = dwc->num_clks - 1; i >= 0; i--)
> + clk_disable_unprepare(dwc->clks[i]);
> +}
> +
>  /*
>   * dwc3_frame_length_adjustment - Adjusts frame length if required
>   * @dwc3: Pointer to our controller context structure
> @@ -641,6 +711,8 @@ 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);
> + dwc3_core_disable_clks(dwc);
> + reset_control_assert(dwc->resets);
>  }
>  
>  static bool dwc3_core_is_valid(struct dwc3 *dwc)
> @@ -1205,6 +1277,22 @@ static int dwc3_probe(struct 

About patchwork for linux-usb

[Peter Chen]

Hi Greg,

At some situations, we may need to save reviewing patches from web, but I can't 
find linux-usb
at https://patchwork.kernel.org/,  any there any patchworks for linux-usb 
mailist at Internet? Thanks.

Peter

 

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

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

[Masami Hiramatsu]

On Thu, 15 Mar 2018 20:39:57 +0900
Masahiro Yamada  wrote:

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

This looks good to me.

Reviewed-by: Masami Hiramatsu 

Thanks,

> Signed-off-by: Masahiro Yamada 
> ---
> 
>  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 f1d838a..e9083a3 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1164,7 +1164,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;
> @@ -1189,20 +1189,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);
>  
> @@ -1269,29 +1268,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
> 


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

[PATCH v5 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Benjamin Herrenschmidt]

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".

This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.

The hub itself has HW provided dedicated EP0 and EP1 (the latter for
hub interrupts). It also has dedicated EP0s for each function. For
other endpoints, there's a pool of 15 "generic" endpoints that are
shared among the ports.

The driver relies on my previous patch adding a "dispose" EP op to
handle EP allocation between ports. EPs are allocated from the shared
pool in the UDC "match_ep" callback and assigned to the UDC instance
(added to the gadget ep_list).

When the composite driver gets unbound, the new hook will allow the UDC
to clean things up and return those EPs to the shared pool.

Signed-off-by: Benjamin Herrenschmidt 
---
v5. - Remove #ifdef's and hard coded values
- Remove module parameters
- Honor maximum speed device-tree property
- Remove useless list_empty test
- Cosmetic/spaces fixes
- Add SPDX licence identifiers

v4. - Fix missing unlock ast_vhub_udc_wakeup() error path
- Make "irq" signed to deal with error from platform_get_irq
- Fix Makefile for module builds
- Fix a missing endian conversion

v3. - Rebased
- Add clk stuff

v2. - Cosmetic fixes
- Properly "allocate" device addresses instead of using a never
  reset counter
- Move .dtsi updates to a different patch
---
 drivers/usb/gadget/udc/Kconfig  |   2 +
 drivers/usb/gadget/udc/Makefile |   1 +
 drivers/usb/gadget/udc/aspeed-vhub/Kconfig  |   7 +
 drivers/usb/gadget/udc/aspeed-vhub/Makefile |   4 +
 drivers/usb/gadget/udc/aspeed-vhub/core.c   | 420 ++
 drivers/usb/gadget/udc/aspeed-vhub/dev.c| 581 +++
 drivers/usb/gadget/udc/aspeed-vhub/ep0.c| 478 
 drivers/usb/gadget/udc/aspeed-vhub/epn.c| 843 
 drivers/usb/gadget/udc/aspeed-vhub/hub.c| 823 +++
 drivers/usb/gadget/udc/aspeed-vhub/vhub.h   | 514 +
 10 files changed, 3673 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Kconfig
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Makefile
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/core.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/dev.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/ep0.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/epn.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/hub.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/vhub.h

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee..b838cae1 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -438,6 +438,8 @@ config USB_GADGET_XILINX
  dynamically linked module called "udc-xilinx" and force all
  gadget drivers to also be dynamically linked.
 
+source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig"
+
 #
 # LAST -- dummy/emulated controller
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index ce865b129fd6..897f648f3cf1 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -39,4 +39,5 @@ obj-$(CONFIG_USB_MV_U3D)  += mv_u3d_core.o
 obj-$(CONFIG_USB_GR_UDC)   += gr_udc.o
 obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
 obj-$(CONFIG_USB_SNP_UDC_PLAT) += snps_udc_plat.o
+obj-$(CONFIG_USB_ASPEED_VHUB)  += aspeed-vhub/
 obj-$(CONFIG_USB_BDC_UDC)  += bdc/
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Kconfig 
b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
new file mode 100644
index ..f0cdf89b8503
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+config USB_ASPEED_VHUB
+   tristate "Aspeed vHub UDC driver"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   help
+ USB peripheral controller for the Aspeed AST2500 family
+ SoCs supporting the "vHub" functionality and USB2.0
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Makefile 
b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
new file mode 100644
index ..9f3add605f8e
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+obj-$(CONFIG_USB_ASPEED_VHUB)  += aspeed-vhub.o
+aspeed-vhub-y  := core.o ep0.o epn.o dev.o hub.o
+
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/core.c 
b/drivers/usb/gadget/udc/aspeed-vhub/core.c
new file mode 100644
index ..1293607f2f19
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/core.c
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * aspeed-vhub -- Driver for Aspeed SoC "vHub" USB gadget
+ *
+ * core.c - Top level support
+ *
+ * 

[PATCH v5 1/2] usb/gadget: Add an EP dispose() callback for EP lifetime tracking

[Benjamin Herrenschmidt]

Some UDC may want to allocate endpoints dynamically, either because
the HW supports an arbitrary large number or because (like the Aspeed
BMC SoCs), the pool of HW endpoints is shared between multiple gadgets.

The allocation side can be done rather easily using the existing
match_ep() UDC hook.

However we have no good place to "free" them.

This implements a "simple" variant of this, which calls an EP dispose
callback on all EPs associated with a gadget when the composite device
gets unbound.

This is required by my upcoming Aspeed vHub driver.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/usb/gadget/composite.c | 8 
 include/linux/usb/gadget.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 77c7ecca816a..ec99c9cfc1a2 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -2172,6 +2172,7 @@ int composite_os_desc_req_prepare(struct 
usb_composite_dev *cdev,
 void composite_dev_cleanup(struct usb_composite_dev *cdev)
 {
struct usb_gadget_string_container *uc, *tmp;
+   struct usb_ep  *ep, *tmp_ep;
 
list_for_each_entry_safe(uc, tmp, >gstrings, list) {
list_del(>list);
@@ -2193,6 +2194,13 @@ void composite_dev_cleanup(struct usb_composite_dev 
*cdev)
}
cdev->next_string_id = 0;
device_remove_file(>gadget->dev, _attr_suspended);
+
+   /* Dispose EPs if the UDC driver tracks lifetime */
+   list_for_each_entry_safe(ep, tmp_ep,
+>gadget->ep_list, ep_list) {
+   if (ep->ops->dispose)
+   ep->ops->dispose(ep);
+   }
 }
 
 static int composite_bind(struct usb_gadget *gadget,
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 66a5cff7ee14..e3424234b23a 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -129,6 +129,7 @@ struct usb_ep_ops {
int (*enable) (struct usb_ep *ep,
const struct usb_endpoint_descriptor *desc);
int (*disable) (struct usb_ep *ep);
+   void (*dispose) (struct usb_ep *ep);
 
struct usb_request *(*alloc_request) (struct usb_ep *ep,
gfp_t gfp_flags);
-- 
2.14.3

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

Re: [PATCH v4 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Benjamin Herrenschmidt]

On Thu, 2018-03-15 at 08:03 +1100, Benjamin Herrenschmidt wrote:
> > > Do you have more comments for the rest of the driver or that's it ?
> > 
> > so far, that's it.
> 
> Ok. I'll re-send.

So I'll resend in a minute, doing a few more tests, however, I've
noticed something which I wont' have time to track down til at
best next week, I wonder if it's normal/expected.

If I just create a mass storage function set to be "removable" and
"cdrom" with no file attached,  and enable it, I get an endless stream
of resets. It looks like the host constantly does USB resets.

I suspect the host is sending SCSI commands that fail and resets
as a result, but that's spamming both logs and is rather ... sub
optimal.

Do we know what's going on ? Is this just TEST_UNIT_READY or some other
media check ? Or are we missing some commands we should actually
implement in the mass storage gadget ?

Cheers,
Ben.

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

Re: [PATCH] net: drivers/net: Remove unnecessary skb_copy_expand OOM messages

[David Miller]

From: Joe Perches 
Date: Mon, 12 Mar 2018 08:07:12 -0700

> skb_copy_expand without __GFP_NOWARN already does a dump_stack
> on OOM so these messages are redundant.
> 
> Signed-off-by: Joe Perches 

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

Re: rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

[Joe Perches]

On Thu, 2018-03-15 at 10:08 -0700, Matthew Wilcox wrote:
> On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote:
> > I have a patchset that creates a vsprintf extension for
> > print_vma_addr and removes all the uses similar to the
> > print_symbol() removal.
> > 
> > This now avoids any possible printk interleaving.
> > 
> > Unfortunately, without some #ifdef in vsprintf, which
> > I would like to avoid, it increases the nommu kernel
> > size by ~500 bytes.
> > 
> > Anyone think this is acceptable?
[]
> This doesn't feel like a huge win since it's only called ~once per
> architecture.  I'd be more excited if it made the printing of the whole
> thing standardised; eg we have a print_fault() function in mm/memory.c
> which takes a suitable set of arguments.

Sure but perhaps that's not feasible as the surrounding output
is per-arch specific.

What could be a standardized fault message here?

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

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Roger Quadros]

On 15/03/18 13:46, Robin Murphy wrote:
> On 12/03/18 10:41, Roger Quadros wrote:
> [...]
> @@ -0,0 +1,75 @@
> +USB Connector
> +=
> +
> +USB connector node represents physical USB connector. It should be
> +a child of USB interface controller.
> +
> +Required properties:
> +- compatible: describes type of the connector, must be one of:
> +    "usb-a-connector",
> +    "usb-b-connector",
> +    "usb-c-connector".
 compatible should be just "usb-connector"

 Type should be a property

 type: type of usb connector "A", "B", "AB", "C"
 AB is for dual-role connectors.
>>>
>>> I have proposed such property (and size also) in my first RFC [1]. Rod
>>> did not like it :)
>>>
>>> [1]: https://marc.info/?l=devicetree=150660411515233=2
>>>
>>
>> This is what Rob says here https://patchwork.kernel.org/patch/9976043/
>> "We did "type" for hdmi-connector, but I think I'd really prefer
>> compatible be used to distinguish as least where it may matter to s/w.
>> In the HDMI case, they all are pretty much the same, just different
>> physical size."
>>
>> So the question is. Does it matter to this particular software implementation
>> if it is type A,B,C connector?
>> If yes, how?
>>
>> Type A will never have any alternate function. It is always dedicated to USB.
> 
> In USB spec terms, at least. In reality there are things like the cool trick 
> Rockchip SoCs do whereby they can expose the debug UART Rx/Tx through the OTG 
> port's D+/D- pins, and that is on a type A connector in many products. I'm 
> guessing that's probably beyond the scope of this binding, though.
> 
>> Also does the size "full", "micro", "mini" matter to software?
> 
> If it means the user can look in sysfs to easily correlate logical ports with 
> physical connectors that's certainly handy (e.g. on something like Odroid-XU 
> where the two USB3 ports are brought out to an A and a micro-AB connector 
> respectively).

But this logic fails if both connectors are the same type/size.
This is where the label comes in handy. The labels can be unique and end user 
can identify the port using that.

> 
> Robin.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
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: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

[Matthew Wilcox]

On Thu, Mar 15, 2018 at 09:56:46AM -0700, Joe Perches wrote:
> I have a patchset that creates a vsprintf extension for
> print_vma_addr and removes all the uses similar to the
> print_symbol() removal.
> 
> This now avoids any possible printk interleaving.
> 
> Unfortunately, without some #ifdef in vsprintf, which
> I would like to avoid, it increases the nommu kernel
> size by ~500 bytes.
> 
> Anyone think this is acceptable?
> 
> Here's the overall patch, but I have it as a series
> ---
>  Documentation/core-api/printk-formats.rst |  9 +
>  arch/arm64/kernel/traps.c | 13 +++
>  arch/mips/mm/fault.c  | 16 -
>  arch/parisc/mm/fault.c| 15 
>  arch/riscv/kernel/traps.c | 11 +++---
>  arch/s390/mm/fault.c  |  7 ++--
>  arch/sparc/mm/fault_32.c  |  8 ++---
>  arch/sparc/mm/fault_64.c  |  8 ++---
>  arch/tile/kernel/signal.c |  9 ++---
>  arch/um/kernel/trap.c | 13 +++
>  arch/x86/kernel/signal.c  | 10 ++
>  arch/x86/kernel/traps.c   | 18 --
>  arch/x86/mm/fault.c   | 12 +++
>  include/linux/mm.h|  1 -
>  lib/vsprintf.c| 58 
> ++-
>  mm/memory.c   | 33 --
>  16 files changed, 112 insertions(+), 129 deletions(-)

This doesn't feel like a huge win since it's only called ~once per
architecture.  I'd be more excited if it made the printing of the whole
thing standardised; eg we have a print_fault() function in mm/memory.c
which takes a suitable set of arguments.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

rfc: remove print_vma_addr ? (was Re: [PATCH 00/16] remove eight obsolete architectures)

[Joe Perches]

On Thu, 2018-03-15 at 10:48 +0100, Geert Uytterhoeven wrote:
> Hi David,
> 
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:
> > Do we have anything left that still implements NOMMU?
> 
> Sure: arm, c6x, m68k, microblaze, and  sh.

I have a patchset that creates a vsprintf extension for
print_vma_addr and removes all the uses similar to the
print_symbol() removal.

This now avoids any possible printk interleaving.

Unfortunately, without some #ifdef in vsprintf, which
I would like to avoid, it increases the nommu kernel
size by ~500 bytes.

Anyone think this is acceptable?

Here's the overall patch, but I have it as a series
---
 Documentation/core-api/printk-formats.rst |  9 +
 arch/arm64/kernel/traps.c | 13 +++
 arch/mips/mm/fault.c  | 16 -
 arch/parisc/mm/fault.c| 15 
 arch/riscv/kernel/traps.c | 11 +++---
 arch/s390/mm/fault.c  |  7 ++--
 arch/sparc/mm/fault_32.c  |  8 ++---
 arch/sparc/mm/fault_64.c  |  8 ++---
 arch/tile/kernel/signal.c |  9 ++---
 arch/um/kernel/trap.c | 13 +++
 arch/x86/kernel/signal.c  | 10 ++
 arch/x86/kernel/traps.c   | 18 --
 arch/x86/mm/fault.c   | 12 +++
 include/linux/mm.h|  1 -
 lib/vsprintf.c| 58 ++-
 mm/memory.c   | 33 --
 16 files changed, 112 insertions(+), 129 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 934559b3c130..10a91da1bc83 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -157,6 +157,15 @@ DMA address types dma_addr_t
 For printing a dma_addr_t type which can vary based on build options,
 regardless of the width of the CPU data path.
 
+VMA name and address
+
+
+::
+
+   %pav[hexstart+hexsize] or ?[0+0] if unavailable
+
+For any address, print the vma's name and its starting address and size
+
 Passed by reference.
 
 Raw buffer as an escaped string
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 2b478565d774..48edf812ce8b 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -242,13 +242,14 @@ void arm64_force_sig_info(struct siginfo *info, const 
char *str,
if (!show_unhandled_signals_ratelimited())
goto send_sig;
 
-   pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
if (esr)
-   pr_cont("%s, ESR 0x%08x, ", esr_get_class_string(esr), esr);
-
-   pr_cont("%s", str);
-   print_vma_addr(KERN_CONT " in ", regs->pc);
-   pr_cont("\n");
+   pr_info("%s[%d]: unhandled exception: %s, ESR 0x%08x, %s in 
%pav\n",
+   tsk->comm, task_pid_nr(tsk),
+   esr_get_class_string(esr), esr,
+   str, >pc);
+   else
+   pr_info("%s[%d]: unhandled exception: %s in %pav\n",
+   tsk->comm, task_pid_nr(tsk), str, >pc);
__show_regs(regs);
 
 send_sig:
diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 4f8f5bf46977..ce7bf077a0f5 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -213,14 +213,14 @@ static void __kprobes __do_page_fault(struct pt_regs 
*regs, unsigned long write,
tsk->comm,
write ? "write access to" : "read access from",
field, address);
-   pr_info("epc = %0*lx in", field,
-   (unsigned long) regs->cp0_epc);
-   print_vma_addr(KERN_CONT " ", regs->cp0_epc);
-   pr_cont("\n");
-   pr_info("ra  = %0*lx in", field,
-   (unsigned long) regs->regs[31]);
-   print_vma_addr(KERN_CONT " ", regs->regs[31]);
-   pr_cont("\n");
+   pr_info("epc = %0*lx in %pav\n",
+   field,
+   (unsigned long)regs->cp0_epc,
+   >cp0_epc);
+   pr_info("ra  = %0*lx in %pav\n",
+   field,
+   (unsigned long)regs->regs[31],
+   >regs[31]);
}
current->thread.trap_nr = (regs->cp0_cause >> 2) & 0x1f;
info.si_signo = SIGSEGV;
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index e247edbca68e..877cea702714 100644
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -240,17 +240,14 @@ show_signal_msg(struct pt_regs *regs, unsigned long 

Re: [PATCH] usb: chipidea: move extcon initial state read

[Greg KH]

On Thu, Mar 15, 2018 at 11:41:23AM -0400, Jonathan wrote:
> Any extcon events between the initial state read and ci_extcon_register are
> "lost". This patch doesn't fix the issue entirely but reduces the chance of
> the controller entering a bad state.
> 
> Signed-off-by: Jonathan Marek 

This doesn't match your "From:" line in your email :(
--
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: Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Mathias Nyman]

On 15.03.2018 15:28, Chris Chiu wrote:

On Thu, Mar 15, 2018 at 7:46 PM, Mathias Nyman
 wrote:

On 15.03.2018 06:40, Chris Chiu wrote:


Hi,
  I  have a ASUS AIO V222GA and another Acer Desktop XC-830 both
have Intel CPU J5005 and they both hit the same problem. The XHCI
connected USB keyboard/mouse can never wakeup the system from suspend.
It reminds me that similiar thing happens on ApolloLake too which
needs the XHCI_PME_STUCK_QUIRK to get it work. It's also mentioned in

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-spec-update.pdf
page #14 for N-seris intel CPU. And I also find the same problem
description in
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-spec-update.pdf
page #16 for J-series Intel CPU. Seems that they have different
workaround so I can not simply apply XHCI_PME_STUCK_QUIRK to make it
work.

  Anyone can help here?



N-Series
CHP8: USB xHCI Controller May Not Re-Enter D3 State After a USB Wake Event
- needs XHCI_PME_STUCK_QUIRK in driver (sets bit 28 at offset 80a4)

Intel® Pentium® Silver N5000
Intel® Pentium® Silver J5005
Intel® Celeron® N4000 and N4100
Intel® Celeron® J4105 and J4005

USB xHCI Controller May Not Re-enter a D3 State After a USB Wake Even
Need to clear PME_EN bit of of the standard PCI PM_CSR register.
I think Linux does this anyway (clears enabling PME when reaching D0)
So if I remember correct there was no specific workaround needed for this.

what is the PCI ID of your xhci controller? (lspci -nn)


They're both 8086:31a8. So you mean from the workaround description, it should
work w/o any extra code? "Software should clear bit 8 (PME_EN) of PM_CSR" has
been handled somewhere else?



One other possible cause is that xHCI never reaches PCI device D3 suspend
state during system suspend.
xHC can't generate PME# wake event from normal running PCI device D0 state.

PCI code in Linux will check with ACPI about the lowest possible D state
when suspending,
If there is something missing from the xHCI entry in ACPI DSDT table it
might select D0.
as the suspend state, causing wake failure.



Here's the DSDT ASL of the ASUS machine.
https://gist.github.com/mschiu77/8e9c8a0e5a98b70a6dfff45620340bf1


Scope (_SB.PCI0.XHC) has _PS0 method, so Linux will look for a _S3W to get the
lowest possible D state in S3, but_S3W is missing, so Linux pci-acpi code will
probably default to D0




ASUS said the BIOS has no problem on USB wakeup under Windows so I don't think
there's any update. Anything else could be cause for this?


Linux and Windows probably check different DSDT values

You can try to force your xHC to D3 during suspend with a hack:

diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 7815768..da46c52 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -488,6 +488,10 @@ static pci_power_t acpi_pci_choose_state(struct pci_dev 
*pdev)
else
d_max = ACPI_STATE_D3_COLD;
acpi_state = acpi_pm_device_sleep_state(>dev, NULL, d_max);
+
+   if (pdev->device == 0x31a8)
+   acpi_state = ACPI_STATE_D3_HOT;
+
if (acpi_state < 0)
return PCI_POWER_ERROR;
 
and see if usb wake starts to work


-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: [PATCH v3 05/12] usb: typec: add API to get sink and source config

[Mats Karrman]

Hi,

On 2018-03-13 10:34, Li Jun wrote:


This patch add 2 APIs to get sink and source power config from firmware
description in case the port supports PD.

Signed-off-by: Li Jun 
---
  drivers/usb/typec/tcpm.c | 47 +++
  include/linux/usb/tcpm.h |  8 +---
  2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 7500dc0..0bd34c9 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -3595,6 +3596,52 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 
*src_vdo,
return nr_vdo;
  }
  
+int tcpm_get_src_config(struct fwnode_handle *fwnode, struct tcpc_config *tcfg)

+{
+   int ret;
+
+   if (!fwnode)
+   return -EINVAL;
+
+   ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
+NULL, 0);
+   if (ret <= 0)
+   return -EINVAL;
+
+   tcfg->nr_src_pdo = min(ret, PDO_MAX_OBJECTS);
+   return fwnode_property_read_u32_array(fwnode, "source-pdos",
+ tcfg->src_pdo, tcfg->nr_src_pdo);
+}
+EXPORT_SYMBOL_GPL(tcpm_get_src_config);
+
+int tcpm_get_snk_config(struct fwnode_handle *fwnode, struct tcpc_config *tcfg)
+{
+   int ret;
+
+   if (!fwnode)
+   return -EINVAL;
+
+   if ((fwnode_property_read_u32(fwnode, "max-sink-microvolt",
+ >max_snk_mv) < 0) ||
+   (fwnode_property_read_u32(fwnode, "max-sink-microamp",
+ >max_snk_ma) < 0) ||
+   (fwnode_property_read_u32(fwnode, "max-sink-microwatt-hours",
+ >max_snk_mw) < 0) ||
+   (fwnode_property_read_u32(fwnode, "op-sink-microwatt-hours",
+ >operating_snk_mw) < 0))


If DT is changed to use micro instead of milli, these values needs to be 
divided by 1000.

// Mats


+   return -EINVAL;
+
+   ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
+NULL, 0);
+   if (ret <= 0)
+   return -EINVAL;
+
+   tcfg->nr_snk_pdo = min(ret, PDO_MAX_OBJECTS);
+   return fwnode_property_read_u32_array(fwnode, "sink-pdos",
+ tcfg->snk_pdo, tcfg->nr_snk_pdo);
+}
+EXPORT_SYMBOL_GPL(tcpm_get_snk_config);
+
  int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
unsigned int nr_pdo)
  {
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index e2e2db3..5d361f6 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -76,10 +76,10 @@ enum tcpm_transmit_type {
   * @alt_modes:List of supported alternate modes
   */
  struct tcpc_config {
-   const u32 *src_pdo;
+   u32 *src_pdo;
unsigned int nr_src_pdo;
  
-	const u32 *snk_pdo;

+   u32 *snk_pdo;
unsigned int nr_snk_pdo;
  
  	const u32 *snk_vdo;

@@ -143,7 +143,7 @@ enum tcpc_mux_mode {
   * @mux:  Pointer to multiplexer data
   */
  struct tcpc_dev {
-   const struct tcpc_config *config;
+   struct tcpc_config *config;
struct fwnode_handle *fwnode;
  
  	int (*init)(struct tcpc_dev *dev);

@@ -189,5 +189,7 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
   enum tcpm_transmit_status status);
  void tcpm_pd_hard_reset(struct tcpm_port *port);
  void tcpm_tcpc_reset(struct tcpm_port *port);
+int tcpm_get_src_config(struct fwnode_handle *fwnode, struct tcpc_config 
*tcfg);
+int tcpm_get_snk_config(struct fwnode_handle *fwnode, struct tcpc_config 
*tcfg);
  
  #endif /* __LINUX_USB_TCPM_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

Bluetooth controller falling off USB bus after an hour of continuous BT headset usage

[Dominik 'Rathann' Mierzejewski]

Dear linux-usb list,
I'm having a recurring issue with my on-board Bluetooth controller
falling off USB bus after about an hour of continuous usage:

[91080.440903] usb 2-6: USB disconnect, device number 24
[91080.450545] Bluetooth: hci0: setting interface failed (19)
[91080.685270] usb 2-6: new full-speed USB device number 25 using xhci_hcd
[91080.812297] usb 2-6: New USB device found, idVendor=8087, idProduct=07dc
[91080.812301] usb 2-6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[91082.876329] Bluetooth: hci0: command 0xfc05 tx timeout
[91082.876332] Bluetooth: hci0: Reading Intel version information failed (-110)

Unloading and loading the btusb module helps get it running again:

[91099.099276] usbcore: deregistering interface driver btusb
[91101.678422] usbcore: registered new interface driver btusb
[91101.693151] Bluetooth: hci0: read Intel version: 370710018002030d56
[91101.693154] Bluetooth: hci0: Intel device is already patched. patch num: 56
[91103.580276] Bluetooth: hci0: SCO packet for unknown connection handle 0
[91103.590133] Bluetooth: hci0: SCO packet for unknown connection handle 0
[91103.590137] Bluetooth: hci0: SCO packet for unknown connection handle 0
[91105.537140] input: 50:1A:A5:D7:43:93 as /devices/virtual/input/input28

The last line indicates my BT headset reconnected successfully.

Could you give me any pointers for debugging this? I cannot trigger
this on-demand, but when I'm in a conference call, it occurs within
an hour or two of continuous usage of my BT headset in HFP mode.

I originally reported it against the Bluetooth stack here:
https://bugzilla.kernel.org/show_bug.cgi?id=198803
but I'm not sure if it's an issue with Bluetooth stack or the USB stack.
You can find dmesg and lsusb output attached there.

OS: Fedora 27
kernel: 4.15.7-300.fc27.x86_64
driver: btusb/btintel
device: 8087:07dc

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/12] dt-bindings: usb: add documentation for typec port controller(TCPCI)

[Mats Karrman]

Hi,

On 2018-03-13 10:34, Li Jun wrote:


TCPCI stands for typec port controller interface, its implementation
has full typec port control with power delivery support, it's a
standard i2c slave with GPIO input as irq interface, detail see spec
"Universal Serial Bus Type-C Port Controller Interface Specification
Revision 1.0, Version 1.1"

Signed-off-by: Li Jun 
---
change for v3:
- change compatible string from "usb,tcpci" to be
   "usb-tcpci,chip-specific-string", update example of it.

  .../devicetree/bindings/usb/typec-tcpci.txt| 36 ++
  1 file changed, 36 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt 
b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
new file mode 100644
index 000..fe7d2ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
@@ -0,0 +1,36 @@
+TCPCI(Typec port cotroller interface) binding
+-
+
+Required properties:
+- compatible:   should be "usb-tcpci,chip-specific-string".
+- reg:  the i2c slave address of typec port controller device.
+- interrupt-parent: the phandle to the interrupt controller which provides
+the interrupt.
+- interrupts:   interrupt specification for tcpci alert.
+
+Required sub-node:
+- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
+  of connector node are specified in
+  Documentation/devicetree/bindings/connector/usb-connector.txt
+
+Example:
+
+ptn5110@50 {
+   compatible = "usb-tcpci,ptn5110";
+   reg = <0x50>;
+   interrupt-parent = <>;
+   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+   usb_con: connector {
+   compatible = "usb-c-connector";
+   label = "USB-C";
+   port-type = "dual";
+   try-power-role = "sink"
+   source-pdos = <0x380190c8>;
+   sink-pdos = <0x380190c8 0x3802d0c8>;
+   max-sink-microvolt = <9000>;
+   max-sink-microamp = <2000>;
+   max-sink-microwatt-hours = <18000>;
+   op-sink-microwatt-hours = <9000>;


Values should change with suffix, e.g. 9000mV = 900uV

// Mats


+   };
+};


--
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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Kashyap Chamarthy]

On Thu, Mar 15, 2018 at 04:46:30PM +0100, Kashyap Chamarthy wrote:
> (Sorry, accidentally dropped the lists.  Adding it back & re-posting my
> off-list response.)

(Now add the missing linux-usb@vger.kernel.org list for real.  Not
trimming the full e-mail intentionally as I missed to Cc 'linux-usb'.)

> On Thu, Mar 15, 2018 at 04:05:53PM +0100, Kashyap Chamarthy wrote:
> > On Thu, Mar 15, 2018 at 03:33:46PM +0100, Douglas Gilbert wrote:
> > > On 2018-03-15 02:44 PM, Douglas Gilbert wrote:
> > > > On 2018-03-15 01:45 PM, Martin K. Petersen wrote:
> > > > > 
> > > > > Kashyap,
> > > > > 
> > > > > > /me naively wonders if it has anything to do with accessing it via
> > > > > > Linux.
> > > > > 
> > > > > I'm guessing that the drive doesn't actually support SCSI UNMAP. I 
> > > > > have
> > > > > a T3 that reports all the right things in the bl/lbpv VPD pages but 
> > > > > also
> > > > > has lbpme set to 0.
> > > > > 
> > > > > Interestingly enough, my T3 does appear to be a regular SATA drive
> > > > > behind a USB bridge. Have you tried to issue a DSM TRIM command via 
> > > > > ATA
> > > > > passthrough?
> > > > 
> > > > hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS
> > > > OPTION!!" in its manpage :-)
> > 
> > Hehe, near as I see, that's dangerous only if you have data on the disk.  
> > 
> > This is an empty SSD that I haven't put any data in it, I should remind.
> > :-)  In that case, I'll assume it is "safe" to tinker with the above.
> > 
> > > IOWs, using Mark Lord's example:
> > >hdparm --trim-sector-ranges 1000:4 /dev/sdz
> > > 
> > > That will attempt to trim lba 1000, 1001, 1002 and 1003 on /dev/sdz
> > 
> > Thanks; I should first educate myself more on this before I tinker with
> > the above.  One Ubuntu wiki page claims: "To wipe out contents of an SSD,
> > SATA secure erase is the way to go", 

Never mind about "secure erase", even trying to set password via
`hdparm' for this T5 SSD (still connected via 'Thunderbolt'):

$> hdparm --user-master u --security-set-pass $SECRET /dev/sdc

Fails with the unactionable & useless error:

"SECURITY_SET_PASS: Input/output error"

> > and '--trim-sector-ranges' is only
> > "experimental and for benchmarking purpose".
> > 
> > Just to recap: My goal is to clean (insofar as possible) the SSD of all
> > and any / all pre-loaded programs & re-claim space.
> > 
> > ---
> > 
> > Related: The ATA Secure Erase wiki page claims[*] if you do it (Secure
> > Erase) via USB interface, you might brick the SSD.  I'm using the
> > 'Thunderbolt' interface, and the said wiki page doesn't say anything
> > useful about it.
> > 
> >  
> > [*] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

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

[PATCH] usb: chipidea: move extcon initial state read

[Jonathan]

Any extcon events between the initial state read and ci_extcon_register are
"lost". This patch doesn't fix the issue entirely but reduces the chance of
the controller entering a bad state.

Signed-off-by: Jonathan Marek 
---
 drivers/usb/chipidea/core.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 33ae87f..a1fb2fb 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -704,25 +704,9 @@ static int ci_get_platdata(struct device *dev,
cable->nb.notifier_call = ci_cable_notifier;
cable->edev = ext_vbus;

-   if (!IS_ERR(ext_vbus)) {
-   ret = extcon_get_state(cable->edev, EXTCON_USB);
-   if (ret)
-   cable->connected = true;
-   else
-   cable->connected = false;
-   }
-
cable = >id_extcon;
cable->nb.notifier_call = ci_cable_notifier;
cable->edev = ext_id;
-
-   if (!IS_ERR(ext_id)) {
-   ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
-   if (ret)
-   cable->connected = true;
-   else
-   cable->connected = false;
-   }
return 0;
 }

@@ -892,6 +876,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
 {
struct device   *dev = >dev;
struct ci_hdrc  *ci;
+   struct ci_hdrc_cable *cable;
struct resource *res;
void __iomem*base;
int ret;
@@ -1009,6 +994,24 @@ static int ci_hdrc_probe(struct platform_device *pdev)
}
}

+   cable = >platdata->vbus_extcon;
+   if (!IS_ERR(cable->edev)) {
+   ret = extcon_get_state(cable->edev, EXTCON_USB);
+   if (ret)
+   cable->connected = true;
+   else
+   cable->connected = false;
+   }
+
+   cable = >platdata->id_extcon;
+   if (!IS_ERR(cable->edev)) {
+   ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
+   if (ret)
+   cable->connected = true;
+   else
+   cable->connected = false;
+   }
+
if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
if (ci->is_otg) {
ci->role = ci_otg_role(ci);
--
2.9.3

On 02/23/2018 10:06 PM, Peter Chen wrote:



Subject: Bugged initial state with Chipidea driver

Hi,

In the Chipidea driver the extcon state is read early in the initialization and
notifications for extcon events are only enabled at the end of the 
initialization. If the
extcon state changes in between the driver will miss the change in extcon state 
and
be a bad state.


Yes, it is the limitation, we need to move ci_extcon_register and update extcon 
state in chipidea driver
before we read ID or VBUS value (through extcon)


Here is what happens in my case:
1. EXTCON_USB_HOST=1, EXTCON_USB=1


Why the two events are both 1 at same time?


2. USB driver reads initial extcon state
3. EXTCON_USB_HOST=0
4. USB driver choses initial role
5. USB driver enables extcon notifiers then the USB driver is stuck
in host mode until the EXTCON_USB_HOST value cycles again, when it should be
in gadget mode. This happens every other boot because my EXTCON_USB_HOST
value is unreliable during init.

I have implemented a temporary solution for myself but if you propose a proper
solution I can implement it and submit a patch.



Feel free to submit your patch.


Additionally, I guess this could technically happen without extcon, but it is 
much less
likely.



For non-extcon solution, the register (otgsc) reflect real-time vbus and id 
value, so it
should be without problem you meet.

Peter


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

Re: [PATCH 00/16] remove eight obsolete architectures

[Christoph Hellwig]

On Thu, Mar 15, 2018 at 11:42:25AM +0100, Arnd Bergmann wrote:
> Is anyone producing a chip that includes enough of the Privileged ISA spec
> to have things like system calls, but not the MMU parts?

Various SiFive SOCs seem to support M and U mode, but no S mode or
iommu.  That should be enough for nommu Linux running in M mode if
someone cares enough to actually port it.
--
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 38/47] usb: musb: remove blackfin port

[Arnd Bergmann]

On Wed, Mar 14, 2018 at 6:12 PM, Bin Liu  wrote:
> On Wed, Mar 14, 2018 at 04:35:51PM +0100, Arnd Bergmann wrote:

>> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
>> index 5506a9c03c1f..490990e8b015 100644
>> --- a/drivers/usb/musb/Kconfig
>> +++ b/drivers/usb/musb/Kconfig
>> @@ -18,9 +18,6 @@ config USB_MUSB_HDRC
>
> This config entry has "ADI" in its tristate message:
>
> config USB_MUSB_HDRC
> tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
>
> so we might want to remove it along with the whole parentheses?
>
> -   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
> +   tristate 'Inventra Highspeed Dual Role Controller'

Done.

> Other than this,
>
> Acked-by: Bin Liu 

Thanks!

   Arnd
--
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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Kashyap Chamarthy]

On Thu, Mar 15, 2018 at 08:45:05AM -0400, Martin K. Petersen wrote:
> 
> Kashyap,
> 
> > /me naively wonders if it has anything to do with accessing it via
> > Linux.
> 
> I'm guessing that the drive doesn't actually support SCSI UNMAP. I have
> a T3 that reports all the right things in the bl/lbpv VPD pages but also
> has lbpme set to 0.
> 
> Interestingly enough, my T3 does appear to be a regular SATA drive
> behind a USB bridge. 

I see.  So I ran `hdparm` on my SSD (still attached via the
'Thunderbolt' port), and it does show TRIM support:

$> hdparm -I /dev/sdc | grep TRIM
   *Data Set Management TRIM supported (limit 8 blocks)

(Full output attached to this e-mail as a text file.)

> Have you tried to issue a DSM TRIM command via ATA
> passthrough?

I'm afraid I don't know how to do that (my SCSI / (S)ATA knowledge is
less than zero).  If there's a page where I can educate myself about how
to send the TRIM command via ATA passthrough I'd appreciate it.  (Aside:
>From my looking up, I don't see any ATA equivalent of SCSI's
'sg3_utils'; wonder if there is any.)

Thanks for the response.

-- 
/kashyap
$> hdparm -I /dev/sdc
/dev/sdc:

ATA device, with non-removable media
Model Number:   Samsung Portable SSD T5 
Serial Number:  S3UNNV0K102165T 
Firmware Revision:  MVT41P1Q
Transport:  Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, 
SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0039) 
Supported: 9 8 7 6 5 
Likely used: 9
Configuration:
Logical max current
cylinders   16383   16383
heads   16  16
sectors/track   63  63
--
CHS current addressable sectors:16514064
LBAuser addressable sectors:   268435455
LBA48  user addressable sectors:   976773168
Logical  Sector size:   512 bytes
Physical Sector size:   512 bytes
Logical Sector-0 offset:  0 bytes
device size with M = 1024*1024:  476940 MBytes
device size with M = 1000*1000:  500107 MBytes (500 GB)
cache/buffer size  = unknown
Form Factor: unknown (0x0006]
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1   Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4 
 Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
Enabled Supported:
   *SMART feature set
   *Power Management feature set
   *Write cache
   *Look-ahead
   *WRITE_BUFFER command
   *READ_BUFFER command
   *NOP cmd
   *DOWNLOAD_MICROCODE
SET_MAX security extension
   *48-bit Address feature set
   *Mandatory FLUSH_CACHE
   *FLUSH_CACHE_EXT
   *SMART error logging
   *SMART self-test
   *General Purpose Logging feature set
   *WRITE_{DMA|MULTIPLE}_FUA_EXT
   *64-bit World wide name
Write-Read-Verify feature set
   *WRITE_UNCORRECTABLE_EXT command
   *{READ,WRITE}_DMA_EXT_GPL commands
   *Segmented DOWNLOAD_MICROCODE
   *Gen1 signaling speed (1.5Gb/s)
   *Gen2 signaling speed (3.0Gb/s)
   *Gen3 signaling speed (6.0Gb/s)
   *Native Command Queueing (NCQ)
   *Phy event counters
   *READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
DMA Setup Auto-Activate optimization
   *Device-initiated interface power management
   *Software settings preservation
   *reserved 69[4]
   *DOWNLOAD MICROCODE DMA command
   *SET MAX SETPASSWORD/UNLOCK DMA commands
   *WRITE BUFFER DMA command
   *READ BUFFER DMA command
   *Data Set Management TRIM supported (limit 8 blocks)
Logical Unit WWN Device Identifier: 5002538d
NAA : 5
IEEE OUI: 002538
Unique ID   : d
Checksum: correct

Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Douglas Gilbert]

On 2018-03-15 01:45 PM, Martin K. Petersen wrote:


Kashyap,


/me naively wonders if it has anything to do with accessing it via
Linux.


I'm guessing that the drive doesn't actually support SCSI UNMAP. I have
a T3 that reports all the right things in the bl/lbpv VPD pages but also
has lbpme set to 0.

Interestingly enough, my T3 does appear to be a regular SATA drive
behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA
passthrough?


hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS
OPTION!!" in its manpage :-)

Doug Gilbert

--
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: Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Chris Chiu]

On Thu, Mar 15, 2018 at 7:46 PM, Mathias Nyman
 wrote:
> On 15.03.2018 06:40, Chris Chiu wrote:
>>
>> Hi,
>>  I  have a ASUS AIO V222GA and another Acer Desktop XC-830 both
>> have Intel CPU J5005 and they both hit the same problem. The XHCI
>> connected USB keyboard/mouse can never wakeup the system from suspend.
>> It reminds me that similiar thing happens on ApolloLake too which
>> needs the XHCI_PME_STUCK_QUIRK to get it work. It's also mentioned in
>>
>> https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-spec-update.pdf
>> page #14 for N-seris intel CPU. And I also find the same problem
>> description in
>> https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-spec-update.pdf
>> page #16 for J-series Intel CPU. Seems that they have different
>> workaround so I can not simply apply XHCI_PME_STUCK_QUIRK to make it
>> work.
>>
>>  Anyone can help here?
>>
>
> N-Series
> CHP8: USB xHCI Controller May Not Re-Enter D3 State After a USB Wake Event
> - needs XHCI_PME_STUCK_QUIRK in driver (sets bit 28 at offset 80a4)
>
> Intel® Pentium® Silver N5000
> Intel® Pentium® Silver J5005
> Intel® Celeron® N4000 and N4100
> Intel® Celeron® J4105 and J4005
>
> USB xHCI Controller May Not Re-enter a D3 State After a USB Wake Even
> Need to clear PME_EN bit of of the standard PCI PM_CSR register.
> I think Linux does this anyway (clears enabling PME when reaching D0)
> So if I remember correct there was no specific workaround needed for this.
>
> what is the PCI ID of your xhci controller? (lspci -nn)

They're both 8086:31a8. So you mean from the workaround description, it should
work w/o any extra code? "Software should clear bit 8 (PME_EN) of PM_CSR" has
been handled somewhere else?

>
> One other possible cause is that xHCI never reaches PCI device D3 suspend
> state during system suspend.
> xHC can't generate PME# wake event from normal running PCI device D0 state.
>
> PCI code in Linux will check with ACPI about the lowest possible D state
> when suspending,
> If there is something missing from the xHCI entry in ACPI DSDT table it
> might select D0.
> as the suspend state, causing wake failure.
>

Here's the DSDT ASL of the ASUS machine.
https://gist.github.com/mschiu77/8e9c8a0e5a98b70a6dfff45620340bf1

Don't know if the "lspci -vvv" output for the USB xHCI controller
provide any useful
information. There's "PME(D0-,D1-,D2-,D3hot+,D3cold+)" in the
following lspci log
https://gist.github.com/mschiu77/8cf523f0e564c1fca44398ebeb21b7bc


> Is there a BIOS update available for your ASUS and Acer?
>
> -Mathias

ASUS said the BIOS has no problem on USB wakeup under Windows so I don't think
there's any update. Anything else could be cause for this?
--
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: WARN_ON(irqs_disabled()) in dma_free_attrs?

[Robin Murphy]

On 15/03/18 07:58, Christoph Hellwig wrote:

On Wed, Mar 14, 2018 at 05:43:46PM +, Robin Murphy wrote:

Looking back I don't really understand why we even indirect the "classic"
per-device dma_declare_coherent_memory use case through the DMA API.


It certainly makes sense for devices which can exist in both shared-memory
and device-local-memory configurations, so the driver doesn't have to care
about the details (particularly on mobile SoCs where the 'local' memory
might just be a chunk of system RAM reserved by the bootloader, and it's
just a matter of different use-cases on identical hardware).


Well, the "classic" case for me is memory buffers in the device.  Setting
some memory aside, either in a global pool as now done for arm-nommu
or even per-device as on some ARM SOCs is different indeed.

As far as I can tell the few devices that use 'local' memory always
use that.


I was thinking mostly of GPUs, where the same IP core might be available 
in a discrete PCIe chip with its own GDDR controller and on-board local 
RAM, and also in an APU/SoC-type configuration reliant on the CPU memory 
bus. But I guess in practice those drivers are already well beyond the 
generic DMA API and into complicated explicitly-managed stuff like TTM.



It seems like a pretty different use case to me.  In the USB case we
also have the following additional twist in that it doesn't even need
the mapping to be coherent.


I'm pretty sure it does (in the sense that it needs to ensure the arch code
makes the mapping non-cacheable), otherwise I can't see how the bouncing
could work properly. I think the last bit of the comment above
hcd_alloc_coherent() is a bit misleading.


Well, if it isn't marked non-cacheable we'd have to do dma_cache_sync
operations for it.  Which would probably still be faster than non-cacheable
mappings.


Ah, I see, we crossed wires there - the *current* implementation 
definitely requires a coherent mapping, but in general you're right that 
there are other ways to solve this particular problem which wouldn't. 
This case really wants to be able to overload the streaming map/unmap 
calls to automatically bounce through device-local memory, but I'm sure 
that's not worth the complexity or effort in general :)



So maybe for now the quick fix is to move the sleep check as suggested
earlier in this thread, but in the long run we probably need to do some
major rework of how dma_declare_coherent_memory and friends work.


Maybe; I do think the specific hcd_alloc_coherent() case could still be
fixed within the scope of the existing code, but it's not quite as clean
and straightforward as I first thought, and the practical impact of
tweaking the WARN should be effectively zero despite the theoretical edge
cases it opens up. Do you want me to write it up as a proper patch?


Yes.  Including a proper comment on why the might_sleep is placed there.


OK, will do.


My mid-term plan was to actually remove the gfp flags argument from
the dma alloc routines as is creates more confusion than it helps.
I guess this means we'll at least need to introduce a DMA_ATTR_NON_BLOCK
or similar flag instead then unfortunately.


At least we already have DMA_ATTR_NO_WARN, which could be implemented 
consistently to clean up the existing __GFP_NOWARN users.


Robin.
--
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 11/16] treewide: simplify Kconfig dependencies for removed archs

[Kalle Valo]

Arnd Bergmann  writes:

> A lot of Kconfig symbols have architecture specific dependencies.
> In those cases that depend on architectures we have already removed,
> they can be omitted.
>
> Signed-off-by: Arnd Bergmann 

[...]

>  drivers/net/wireless/cisco/Kconfig   |  2 +-

Acked-by: Kalle Valo 

-- 
Kalle Valo
--
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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Martin K. Petersen]

Kashyap,

> /me naively wonders if it has anything to do with accessing it via
> Linux.

I'm guessing that the drive doesn't actually support SCSI UNMAP. I have
a T3 that reports all the right things in the bl/lbpv VPD pages but also
has lbpme set to 0.

Interestingly enough, my T3 does appear to be a regular SATA drive
behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA
passthrough?

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

Re: [PATCH v3 05/12] usb: typec: add API to get sink and source config

[Heikki Krogerus]

Hi,

A small nitpick. The subject lines seem to be a little bit
inconsistent in this series. This patch for example does not mention
tcpm at all in its subject or even commit message, even though it only
modifies tcpm.c.

Please change the subject lines of all the patches in this series
mainly dealing with tcpm.c for example to:

usb: typec: tcpm: ...


On Tue, Mar 13, 2018 at 05:34:31PM +0800, Li Jun wrote:
> This patch add 2 APIs to get sink and source power config from firmware
> description in case the port supports PD.
> 
> Signed-off-by: Li Jun 
> ---
>  drivers/usb/typec/tcpm.c | 47 +++
>  include/linux/usb/tcpm.h |  8 +---
>  2 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 7500dc0..0bd34c9 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3595,6 +3596,52 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 
> *src_vdo,
>   return nr_vdo;
>  }
>  
> +int tcpm_get_src_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg)
> +{
> + int ret;
> +
> + if (!fwnode)
> + return -EINVAL;
> +
> + ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
> +  NULL, 0);
> + if (ret <= 0)
> + return -EINVAL;
> +
> + tcfg->nr_src_pdo = min(ret, PDO_MAX_OBJECTS);
> + return fwnode_property_read_u32_array(fwnode, "source-pdos",
> +   tcfg->src_pdo, tcfg->nr_src_pdo);
> +}
> +EXPORT_SYMBOL_GPL(tcpm_get_src_config);
> +
> +int tcpm_get_snk_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg)
> +{
> + int ret;
> +
> + if (!fwnode)
> + return -EINVAL;
> +
> + if ((fwnode_property_read_u32(fwnode, "max-sink-microvolt",
> +   >max_snk_mv) < 0) ||
> + (fwnode_property_read_u32(fwnode, "max-sink-microamp",
> +   >max_snk_ma) < 0) ||
> + (fwnode_property_read_u32(fwnode, "max-sink-microwatt-hours",
> +   >max_snk_mw) < 0) ||
> + (fwnode_property_read_u32(fwnode, "op-sink-microwatt-hours",
> +   >operating_snk_mw) < 0))
> + return -EINVAL;
> +
> + ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
> +  NULL, 0);
> + if (ret <= 0)
> + return -EINVAL;
> +
> + tcfg->nr_snk_pdo = min(ret, PDO_MAX_OBJECTS);
> + return fwnode_property_read_u32_array(fwnode, "sink-pdos",
> +   tcfg->snk_pdo, tcfg->nr_snk_pdo);
> +}
> +EXPORT_SYMBOL_GPL(tcpm_get_snk_config);
> +
>  int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
>   unsigned int nr_pdo)
>  {
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
> index e2e2db3..5d361f6 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -76,10 +76,10 @@ enum tcpm_transmit_type {
>   * @alt_modes:   List of supported alternate modes
>   */
>  struct tcpc_config {
> - const u32 *src_pdo;
> + u32 *src_pdo;
>   unsigned int nr_src_pdo;
>  
> - const u32 *snk_pdo;
> + u32 *snk_pdo;
>   unsigned int nr_snk_pdo;
>  
>   const u32 *snk_vdo;
> @@ -143,7 +143,7 @@ enum tcpc_mux_mode {
>   * @mux: Pointer to multiplexer data
>   */
>  struct tcpc_dev {
> - const struct tcpc_config *config;
> + struct tcpc_config *config;
>   struct fwnode_handle *fwnode;
>  
>   int (*init)(struct tcpc_dev *dev);
> @@ -189,5 +189,7 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
>  enum tcpm_transmit_status status);
>  void tcpm_pd_hard_reset(struct tcpm_port *port);
>  void tcpm_tcpc_reset(struct tcpm_port *port);
> +int tcpm_get_src_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg);
> +int tcpm_get_snk_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg);
>  
>  #endif /* __LINUX_USB_TCPM_H */
> -- 
> 2.7.4

-- 
heikki
--
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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Kashyap Chamarthy]

On Thu, Mar 15, 2018 at 12:19:11PM +0100, Douglas Gilbert wrote:
> On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote:
> > On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote:
> > > 
> > > Kashyap,
> > 
> > Hi Martin,
> > 
> > > > Sorry, I didn't give you complete information — with the previous
> > > > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB
> > > > "A Cable".
> > > > 
> > > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop
> > > > (Lenovo T470s), it _does_ show "UAS".   Refer the arrow below:
> > > 
> > > Do you get different sg_readcap -l output when accessing it in UAS mode?
> > > I.e. is lbpme=1?
> > 
> > Afraid, no :-(  I was excited for a brief moment, but it's the same as
> > earlier.  The result with the SSD via 'Thunderbolt':
> > 
> >  $> sudo sg_readcap -l /dev/sdc
> >  Read Capacity results:
> > Protection: prot_en=0, p_type=0, p_i_exponent=0
> > Logical block provisioning: lbpme=0, lbprz=0
> > Last logical block address=976773167 (0x3a38602f), Number of 
> > logical blocks=976773168
> > Logical block length=512 bytes
> > Logical blocks per physical block exponent=0
> > Lowest aligned logical block address=0
> >  Hence:
> > Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB
> > 
> > 
> > /me naively wonders if it has anything to do with accessing it via
> > Linux.
> 
> You can also run 'sg_readcap -l' on a Windows machine to test your theory.
> Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then
> you would do something like:
> sg_readcap -l pd2
> 
> There is no IOS port of sg3_utils.
> 
> I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe
> commands) that tell a storage device something like: "BTW I'm a Linux
> machine running Ubuntu 17.10 on  hardware".
> 
> It is possible that a storage device might recognize an OS by the pattern
> of commands it sends, especially in the device discovery mode.
> 
> So basically your suggestion is a long shot. There might be a "secret"
> setting in a vendor specific command that another OS is aware of.
> For example, according to the 'net this command:
>sg_raw /dev/sr0 EA 00 00 00 00 00 01
> allows owners of Apple USB Superdrives to use them on other OSes.

I see, thanks for the explanation and the specific useful commands.
I'll try to get hold of a friend's Windows computer, as I don't have one
with me.  But your "long shot" comment adjusted my expectations to not
hold my breath.

> *** there are transport_ids used by PERSISTENT RESERVATION commands to
> differentiate one machine from another. But they convey about as
> much information as a random number does. Also that applies to a
> multi-initiator, single target model which isn't the case when we
> are talking about USB/Thunderbolt attachment.
> 

-- 
/kashyap
--
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 1/6] dt-bindings: add bindings for USB physical connector

[Robin Murphy]

On 12/03/18 10:41, Roger Quadros wrote:
[...]

@@ -0,0 +1,75 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector",
+"usb-b-connector",
+"usb-c-connector".

compatible should be just "usb-connector"

Type should be a property

type: type of usb connector "A", "B", "AB", "C"
AB is for dual-role connectors.


I have proposed such property (and size also) in my first RFC [1]. Rod
did not like it :)

[1]: https://marc.info/?l=devicetree=150660411515233=2



This is what Rob says here https://patchwork.kernel.org/patch/9976043/
"We did "type" for hdmi-connector, but I think I'd really prefer
compatible be used to distinguish as least where it may matter to s/w.
In the HDMI case, they all are pretty much the same, just different
physical size."

So the question is. Does it matter to this particular software implementation
if it is type A,B,C connector?
If yes, how?

Type A will never have any alternate function. It is always dedicated to USB.


In USB spec terms, at least. In reality there are things like the cool 
trick Rockchip SoCs do whereby they can expose the debug UART Rx/Tx 
through the OTG port's D+/D- pins, and that is on a type A connector in 
many products. I'm guessing that's probably beyond the scope of this 
binding, though.



Also does the size "full", "micro", "mini" matter to software?


If it means the user can look in sysfs to easily correlate logical ports 
with physical connectors that's certainly handy (e.g. on something like 
Odroid-XU where the two USB3 ports are brought out to an A and a 
micro-AB connector respectively).


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

Re: [PATCH v3 06/12] staging: typec: tcpci: support port config passed via dt

[Heikki Krogerus]

On Tue, Mar 13, 2018 at 05:34:32PM +0800, Li Jun wrote:
> User can define the typec port properties in tcpci node to setup
> the port config.
> 
> Signed-off-by: Li Jun 
> ---
>  drivers/staging/typec/tcpci.c | 63 
> +++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 24ad44f..ba4627f 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -466,6 +466,9 @@ static const struct regmap_config tcpci_regmap_config = {
>  
>  static int tcpci_parse_config(struct tcpci *tcpci)
>  {
> + struct tcpc_config *tcfg;
> + int ret = -EINVAL;
> +
>   tcpci->controls_vbus = true; /* XXX */
>  
>   tcpci->tcpc.fwnode = device_get_named_child_node(tcpci->dev,
> @@ -475,6 +478,66 @@ static int tcpci_parse_config(struct tcpci *tcpci)
>   return -EINVAL;
>   }
>  
> + tcpci->tcpc.config = devm_kzalloc(tcpci->dev, sizeof(*tcfg),
> +   GFP_KERNEL);
> + if (!tcpci->tcpc.config)
> + return -ENOMEM;
> +
> + tcfg = tcpci->tcpc.config;
> +
> + /* USB data support is optional */
> + ret = typec_get_data_type(tcpci->tcpc.fwnode);
> + if (ret < 0)
> + dev_dbg(tcpci->dev, "USB data is not supported.\n");
> + else
> + tcfg->data = ret;
> +
> + /* Get port power type */
> + ret = typec_get_power_type(tcpci->tcpc.fwnode);
> + if (ret < 0) {
> + dev_err(tcpci->dev, "failed to get correct port type.\n");
> + return ret;
> + }
> + tcfg->type = ret;
> +
> + if (tcfg->type == TYPEC_PORT_SNK)
> + goto sink;
> +
> + tcfg->src_pdo = devm_kcalloc(tcpci->dev, PDO_MAX_OBJECTS,
> +  sizeof(*tcfg->src_pdo), GFP_KERNEL);
> + if (!tcfg->src_pdo)
> + return -ENOMEM;
> +
> + /* Get source capability */
> + ret = tcpm_get_src_config(tcpci->tcpc.fwnode, tcfg);
> + if (ret < 0) {
> + dev_err(tcpci->dev, "failed to get source pdo %d\n", ret);
> + return -EINVAL;
> + }
> +
> + if (tcfg->type == TYPEC_PORT_SRC)
> + return 0;
> +
> + /* Get the preferred power role for DRP */
> + ret = typec_get_preferred_role(tcpci->tcpc.fwnode);
> + if (ret < 0) {
> + dev_err(tcpci->dev, "failed to get correct preferred role.\n");
> + return ret;
> + }
> + tcfg->default_role = ret;
> +sink:
> + tcfg->snk_pdo = devm_kcalloc(tcpci->dev, PDO_MAX_OBJECTS,
> +  sizeof(*tcfg->snk_pdo), GFP_KERNEL);
> + if (!tcfg->snk_pdo)
> + return -ENOMEM;
> +
> + /* Get power sink config */
> + ret = tcpm_get_snk_config(tcpci->tcpc.fwnode, tcfg);
> + if (ret < 0) {
> + dev_err(tcpci->dev, "failed to get sink configs %d\n", ret);
> + return -EINVAL;
> + }
> +
>   return 0;
>  }

I think everything here can be done in tcpm.c.

Since you are checking some device properties in tcpm.c in any case
(in tcpm_get_snk_config() and tcpm_get_src_config()), you might as
well check all these there as well.


Br,

-- 
heikki
--
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: Intel GemniLake xHCI connected devices can never wake up the system from suspend

[Mathias Nyman]

On 15.03.2018 06:40, Chris Chiu wrote:

Hi,
 I  have a ASUS AIO V222GA and another Acer Desktop XC-830 both
have Intel CPU J5005 and they both hit the same problem. The XHCI
connected USB keyboard/mouse can never wakeup the system from suspend.
It reminds me that similiar thing happens on ApolloLake too which
needs the XHCI_PME_STUCK_QUIRK to get it work. It's also mentioned in
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-spec-update.pdf
page #14 for N-seris intel CPU. And I also find the same problem
description in 
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-spec-update.pdf
page #16 for J-series Intel CPU. Seems that they have different
workaround so I can not simply apply XHCI_PME_STUCK_QUIRK to make it
work.

 Anyone can help here?



N-Series
CHP8: USB xHCI Controller May Not Re-Enter D3 State After a USB Wake Event
- needs XHCI_PME_STUCK_QUIRK in driver (sets bit 28 at offset 80a4)

Intel® Pentium® Silver N5000
Intel® Pentium® Silver J5005
Intel® Celeron® N4000 and N4100
Intel® Celeron® J4105 and J4005

USB xHCI Controller May Not Re-enter a D3 State After a USB Wake Even
Need to clear PME_EN bit of of the standard PCI PM_CSR register.
I think Linux does this anyway (clears enabling PME when reaching D0)
So if I remember correct there was no specific workaround needed for this.

what is the PCI ID of your xhci controller? (lspci -nn)

One other possible cause is that xHCI never reaches PCI device D3 suspend state 
during system suspend.
xHC can't generate PME# wake event from normal running PCI device D0 state.

PCI code in Linux will check with ACPI about the lowest possible D state when 
suspending,
If there is something missing from the xHCI entry in ACPI DSDT table it might 
select D0.
as the suspend state, causing wake failure.

Is there a BIOS update available for your ASUS and Acer?

-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: Webcams not recognized on a Dell Latitude 5285 laptop

[Sakari Ailus]

Hi Andy and Frédéric,

On Tue, Mar 13, 2018 at 06:11:00PM +0200, Andy Shevchenko wrote:
> On Sun, Mar 11, 2018 at 2:38 PM, FRÉDÉRIC PARRENIN
>  wrote:
> > Dear Oliver and all,
> >
> > So I was expecting linux-4.16 to recognize my webcams, thanks to this new 
> > PCI driver Oliver mentioned.
> > Therefore I installed 4.16-rc4.
> > Unfortunately, there is still no /dev/video* device
> >
> > Any idea what could be done to have these webcams working?
> 
> I guess you need a driver.
> Cc: + Sakari, and thus leaving the complete message uncut.

Or drivers. And a bit more than that actually. Assuming this is IPU3, that
is. If that's the case, the short answer is there's no trivial way to
support webcam-like functionality using this device. The ACPI tables would
tell more details.

Could you send me the ACPI tables, i.e. the file produced by the command:

acpidump -o acpidump.bin

In Debian acpidump is included in acpica-tools package.

Thank you.

-- 
Regards,

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

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

[Masahiro Yamada]

It is not a good idea to modify the resource from the platform device.
Modify its local copy to 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 
---

 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 f1d838a..e9083a3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1164,7 +1164,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;
@@ -1189,20 +1189,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);
 
@@ -1269,29 +1268,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 2/2] usb: dwc3: add clock and resets

[Masahiro Yamada]

dwc3-of-simple.c only handles arbitrary number of clocks and resets.
They are both generic enough to be put into the dwc3 core.  For simple
cases, a nested node structure like follows:

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

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

would be turned into a single node:

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

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

Signed-off-by: Masahiro Yamada 
---

 Documentation/devicetree/bindings/usb/dwc3.txt |   2 +
 drivers/usb/dwc3/core.c| 127 -
 drivers/usb/dwc3/core.h|   5 +
 3 files changed, 132 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 44e8bab..67e9cfb 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -9,12 +9,14 @@ Required properties:
  - interrupts: Interrupts used by the dwc3 controller.
 
 Optional properties:
+ - clocks: list of phandle and clock specifier pairs
  - usb-phy : array of phandle for the PHY device.  The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
  - phys: from the *Generic PHY* bindings
  - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy"
or "usb3-phy".
+ - resets: list of phandle and reset specifier pairs
  - 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 e9083a3..f17e4a9 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 
@@ -240,6 +242,74 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
return -ETIMEDOUT;
 }
 
+static int dwc3_core_get_clks(struct dwc3 *dwc)
+{
+   struct device *dev = dwc->dev;
+   struct device_node *node = dev->of_node;
+   struct clk *clk;
+   int num_clks, i;
+
+   num_clks = of_count_phandle_with_args(node, "clocks", "#clock-cells");
+   if (num_clks <= 0)
+   return 0;
+
+   dwc->num_clks = num_clks;
+
+   dwc->clks = devm_kcalloc(dev, num_clks, sizeof(*dwc->clks), GFP_KERNEL);
+   if (!dwc->clks)
+   return -ENOMEM;
+
+   for (i = 0; i < num_clks; i++) {
+   clk = of_clk_get(node, i);
+   if (IS_ERR(clk))
+   goto put_clks;
+   dwc->clks[i] = clk;
+   }
+
+   return 0;
+
+put_clks:
+   while (--i >= 0)
+   clk_put(dwc->clks[i]);
+
+   return PTR_ERR(clk);
+}
+
+static void dwc3_core_put_clks(struct dwc3 *dwc)
+{
+   int i;
+
+   for (i = dwc->num_clks - 1; i >= 0; i--)
+   clk_put(dwc->clks[i]);
+}
+
+static int dwc3_core_enable_clks(struct dwc3 *dwc)
+{
+   int ret, i;
+
+   for (i = 0; i < dwc->num_clks; i++) {
+   ret = clk_prepare_enable(dwc->clks[i]);
+   if (ret)
+   goto disable_clks;
+   }
+
+   return 0;
+
+disable_clks:
+   while (--i >= 0)
+   clk_disable_unprepare(dwc->clks[i]);
+
+   return ret;
+}
+
+static void dwc3_core_disable_clks(struct dwc3 *dwc)
+{
+   int i;
+
+   for (i = dwc->num_clks - 1; i >= 0; i--)
+   clk_disable_unprepare(dwc->clks[i]);
+}
+
 /*
  * dwc3_frame_length_adjustment - Adjusts frame length if required
  * @dwc3: Pointer to our controller context structure
@@ -641,6 +711,8 @@ 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);
+   dwc3_core_disable_clks(dwc);
+   reset_control_assert(dwc->resets);
 }
 
 static bool dwc3_core_is_valid(struct dwc3 *dwc)
@@ -1205,6 +1277,22 @@ static int dwc3_probe(struct platform_device *pdev)
 
dwc3_get_properties(dwc);
 
+   dwc->resets = devm_reset_control_array_get_optional_shared(dev);
+   if (IS_ERR(dwc->resets))
+   return PTR_ERR(dwc->resets);
+
+   ret = dwc3_core_get_clks(dwc);
+   if (ret)
+   return ret;
+
+   ret = reset_control_deassert(dwc->resets);
+   if (ret)
+   goto put_clks;
+
+   ret = 

Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Douglas Gilbert]

On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote:

On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote:


Kashyap,


Hi Martin,


Sorry, I didn't give you complete information — with the previous
`dmesg` output, I actually attached the SSD (Samsung T5) via regular USB
"A Cable".

Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop
(Lenovo T470s), it _does_ show "UAS".   Refer the arrow below:


Do you get different sg_readcap -l output when accessing it in UAS mode?
I.e. is lbpme=1?


Afraid, no :-(  I was excited for a brief moment, but it's the same as
earlier.  The result with the SSD via 'Thunderbolt':

 $> sudo sg_readcap -l /dev/sdc
 Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last logical block address=976773167 (0x3a38602f), Number of logical 
blocks=976773168
Logical block length=512 bytes
Logical blocks per physical block exponent=0
Lowest aligned logical block address=0
 Hence:
Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB


/me naively wonders if it has anything to do with accessing it via
Linux.


You can also run 'sg_readcap -l' on a Windows machine to test your theory.
Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then
you would do something like:
sg_readcap -l pd2

There is no IOS port of sg3_utils.

I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe
commands) that tell a storage device something like: "BTW I'm a Linux
machine running Ubuntu 17.10 on  hardware".

It is possible that a storage device might recognize an OS by the pattern
of commands it sends, especially in the device discovery mode.

So basically your suggestion is a long shot. There might be a "secret"
setting in a vendor specific command that another OS is aware of.
For example, according to the 'net this command:
   sg_raw /dev/sr0 EA 00 00 00 00 00 01
allows owners of Apple USB Superdrives to use them on other OSes.

Doug Gilbert

*** there are transport_ids used by PERSISTENT RESERVATION commands to
differentiate one machine from another. But they convey about as
much information as a random number does. Also that applies to a
multi-initiator, single target model which isn't the case when we
are talking about USB/Thunderbolt attachment.

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

Re: [PATCH v3 05/12] usb: typec: add API to get sink and source config

[Heikki Krogerus]

On Tue, Mar 13, 2018 at 05:34:31PM +0800, Li Jun wrote:
> This patch add 2 APIs to get sink and source power config from firmware
> description in case the port supports PD.
> 
> Signed-off-by: Li Jun 
> ---
>  drivers/usb/typec/tcpm.c | 47 +++
>  include/linux/usb/tcpm.h |  8 +---
>  2 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
> index 7500dc0..0bd34c9 100644
> --- a/drivers/usb/typec/tcpm.c
> +++ b/drivers/usb/typec/tcpm.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3595,6 +3596,52 @@ static int tcpm_copy_vdos(u32 *dest_vdo, const u32 
> *src_vdo,
>   return nr_vdo;
>  }
>  
> +int tcpm_get_src_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg)
> +{
> + int ret;
> +
> + if (!fwnode)
> + return -EINVAL;
> +
> + ret = fwnode_property_read_u32_array(fwnode, "source-pdos",
> +  NULL, 0);
> + if (ret <= 0)
> + return -EINVAL;
> +
> + tcfg->nr_src_pdo = min(ret, PDO_MAX_OBJECTS);
> + return fwnode_property_read_u32_array(fwnode, "source-pdos",
> +   tcfg->src_pdo, tcfg->nr_src_pdo);
> +}
> +EXPORT_SYMBOL_GPL(tcpm_get_src_config);
> +
> +int tcpm_get_snk_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg)
> +{
> + int ret;
> +
> + if (!fwnode)
> + return -EINVAL;
> +
> + if ((fwnode_property_read_u32(fwnode, "max-sink-microvolt",
> +   >max_snk_mv) < 0) ||
> + (fwnode_property_read_u32(fwnode, "max-sink-microamp",
> +   >max_snk_ma) < 0) ||
> + (fwnode_property_read_u32(fwnode, "max-sink-microwatt-hours",
> +   >max_snk_mw) < 0) ||
> + (fwnode_property_read_u32(fwnode, "op-sink-microwatt-hours",
> +   >operating_snk_mw) < 0))
> + return -EINVAL;
> +
> + ret = fwnode_property_read_u32_array(fwnode, "sink-pdos",
> +  NULL, 0);
> + if (ret <= 0)
> + return -EINVAL;
> +
> + tcfg->nr_snk_pdo = min(ret, PDO_MAX_OBJECTS);
> + return fwnode_property_read_u32_array(fwnode, "sink-pdos",
> +   tcfg->snk_pdo, tcfg->nr_snk_pdo);
> +}
> +EXPORT_SYMBOL_GPL(tcpm_get_snk_config);

tcpm_register_port() can check these. No need to involve the tcpc
drivers.

>  int tcpm_update_source_capabilities(struct tcpm_port *port, const u32 *pdo,
>   unsigned int nr_pdo)
>  {
> diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
> index e2e2db3..5d361f6 100644
> --- a/include/linux/usb/tcpm.h
> +++ b/include/linux/usb/tcpm.h
> @@ -76,10 +76,10 @@ enum tcpm_transmit_type {
>   * @alt_modes:   List of supported alternate modes
>   */
>  struct tcpc_config {
> - const u32 *src_pdo;
> + u32 *src_pdo;
>   unsigned int nr_src_pdo;
>  
> - const u32 *snk_pdo;
> + u32 *snk_pdo;
>   unsigned int nr_snk_pdo;
>  
>   const u32 *snk_vdo;
> @@ -143,7 +143,7 @@ enum tcpc_mux_mode {
>   * @mux: Pointer to multiplexer data
>   */
>  struct tcpc_dev {
> - const struct tcpc_config *config;
> + struct tcpc_config *config;

If you check the properties in tcpm, the above members can continue to
be declared constant for now.

>   struct fwnode_handle *fwnode;
>  
>   int (*init)(struct tcpc_dev *dev);
> @@ -189,5 +189,7 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
>  enum tcpm_transmit_status status);
>  void tcpm_pd_hard_reset(struct tcpm_port *port);
>  void tcpm_tcpc_reset(struct tcpm_port *port);
> +int tcpm_get_src_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg);
> +int tcpm_get_snk_config(struct fwnode_handle *fwnode, struct tcpc_config 
> *tcfg);


Cheers,

-- 
heikki
--
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 1/6] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 12.03.2018 11:41, Roger Quadros wrote:
> Andrezej,
>
> Why don't you have any of the USB maintainers in to/cc?
>
> Greg Kroah-Hartman  (supporter:USB SUBSYSTEM)
> Felipe Balbi  (maintainer:USB GADGET/PERIPHERAL SUBSYSTEM)

Serious omission, sorry for that.

>
> On 12/03/18 09:02, Andrzej Hajda wrote:
>> On 09.03.2018 11:24, Roger Quadros wrote:
>>> Hi,
>>>
>>> On 27/02/18 09:11, Andrzej Hajda wrote:
 These bindings allow to describe most known standard USB connectors
 and it should be possible to extend it if necessary.
 USB connectors, beside USB can be used to route other protocols,
 for example UART, Audio, MHL. In such case every device passing data
 through the connector should have appropriate graph bindings.

 Signed-off-by: Andrzej Hajda 
 ---
 v4:
 - improved 'type' description (Rob),
 - improved description of 2nd example (Rob).
 v3:
 - removed MHL port (samsung connector will have separate bindings),
 - added 2nd example for USB-C,
 - improved formatting.
 v2:
 - moved connector type(A,B,C) to compatible string (Rob),
 - renamed size property to type (Rob),
 - changed type description to be less confusing (Laurent),
 - removed vendor specific compatibles (implied by graph port number),
 - added requirement of connector being a child of IC (Rob),
 - removed max-mode (subtly suggested by Rob, it should be detected anyway
   by USB Controller in runtime, downside is that device is not able to
   report its real capabilities, maybe better would be to make it 
 optional(?)),
 - assigned port numbers to data buses (Rob).

 Regards
 Andrzej
 ---
  .../bindings/connector/usb-connector.txt   | 75 
 ++
  1 file changed, 75 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/connector/usb-connector.txt

 diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
 b/Documentation/devicetree/bindings/connector/usb-connector.txt
 new file mode 100644
 index ..e1463f14af38
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> Should this lie in  bindings/usb/connector?


I guess this is question for DT people. For me both locations are OK.

>
 @@ -0,0 +1,75 @@
 +USB Connector
 +=
 +
 +USB connector node represents physical USB connector. It should be
 +a child of USB interface controller.
 +
 +Required properties:
 +- compatible: describes type of the connector, must be one of:
 +"usb-a-connector",
 +"usb-b-connector",
 +"usb-c-connector".
>>> compatible should be just "usb-connector"
>>>
>>> Type should be a property
>>>
>>> type: type of usb connector "A", "B", "AB", "C"
>>> AB is for dual-role connectors.
>> I have proposed such property (and size also) in my first RFC [1]. Rod
>> did not like it :)
>>
>> [1]: https://marc.info/?l=devicetree=150660411515233=2
>>
> This is what Rob says here https://patchwork.kernel.org/patch/9976043/
> "We did "type" for hdmi-connector, but I think I'd really prefer 
> compatible be used to distinguish as least where it may matter to s/w. 
> In the HDMI case, they all are pretty much the same, just different 
> physical size."
>
> So the question is. Does it matter to this particular software implementation
> if it is type A,B,C connector?
> If yes, how?

IMHO both approaches can work from S/W POV. As I understood it moving
usb type to compatible was rather matter of devicetree guidelines I am
not aware of. Again question to Rob.

>
> Type A will never have any alternate function. It is always dedicated to USB.
>
> Also does the size "full", "micro", "mini" matter to software?
>
>>> micro super-speed and high-speed connectors are different. How do you 
>>> differentiate that?
>> I am aware of it, and property differentiating it was also in my earlier
>> iterations.
>> If there will be need to differentiate such connectors, adding property
>> max-speed or max-mode would do the thing.
> USB controller binding (bindings/usb/generic.txt) has the speed.
> I don't think there is any value for replicating it for the connector. Maybe 
> it could
> be added later if needed.
>
 +
 +Optional properties:
 +- label: symbolic name for the connector,
>>> Why do you need label? We can't maintain consistency as people will put 
>>> creative names there.
>>> Device/bus driver could generate a valid label.
>> It follows convention for other connectors: HDMI, DVI, 
>>
 +- type: size of the connector, should be specified in case of USB-A, USB-B
 +  non-fullsize connectors: "mini", "micro".
>>> type is misleading. Type is usually A/B/C. It should be size here instead.
>> As you can see in discussion for previous iterations it follows
>> convention already 

Re: [PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

On Thu, Mar 15, 2018 at 10:59 AM, Hannes Reinecke  wrote:
> On 03/15/2018 10:42 AM, David Howells wrote:
>> Do we have anything left that still implements NOMMU?
>>
> RISC-V ?
> (evil grin :-)

Is anyone producing a chip that includes enough of the Privileged ISA spec
to have things like system calls, but not the MMU parts?

I thought at least initially the kernel only supports hardware that has a rather
complete feature set.

   Arnd
--
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: DWC2 maintainership change

[Felipe Balbi]

Hi,

"Greg Kroah-Hartman (gre...@linuxfoundation.org)"
 writes:
> On Thu, Mar 15, 2018 at 04:00:25AM +, John Youn wrote:
>> Hi Felipe, Greg,
>> 
>> I won't be able to continue maintainership of dwc2.
>> 
>> Minas Harutyunyan, has been doing most of the communication on
>> linux-usb lately and much of the maintenance and development work. He
>> has excellent knowledge of the controller, having worked with it
>> since its inception many years ago.
>> 
>> I propose that he take over as the new maintainer.
>
> No objection to me, send in a patch.
>
> And thanks for your time being the maintainer, it's much appreciated.

no objections from my side either. Thanks for your contribution

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 00/16] remove eight obsolete architectures

[Hannes Reinecke]

On 03/15/2018 10:42 AM, David Howells wrote:
> Do we have anything left that still implements NOMMU?
> 
RISC-V ?
(evil grin :-)

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Richard Leitner]

On 03/15/2018 10:26 AM, Oliver Neukum wrote:
> Am Mittwoch, den 14.03.2018, 16:44 +0100 schrieb Richard Leitner:
>> On 03/14/2018 04:27 PM, Oliver Neukum wrote:
>>> Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:

>>> Well, but it does not. Removing a redundant definition is a clear
>>> benefit. But you are not removing a definition. You are introducing
>>> a preprocessor constant. Why?
>>> What is its benefit?
>>
>> AFAIK pci_ids.h collects PCI vendor and device IDs in one single 
>> point. As the PCI vendor ID of Netlogic is used in multiple files
>> IMHO it would be a good idea to add it to pci_ids.h and furthermore
>> remove it from arch/mips/include/asm/netlogic/xlp-hal/iomap.h (where
>> it's currently defined).
>>
>> Or am I getting things wrong?
> 
> I think so, yes. We are giving names to constants as a form
> of comment or to change them at multiple places at once and
> consistently.
> 
> So
> 
> #define XYZ_NETDEV_RESET_RETRIES  2
> 
> makes clearly sense. So does
> 
> #define XYZ_MAGIC_VALUE1  0xab4e
> 
> because it tells you that you have a magic value.
> But you will never redefine a PCI vendor ID. In fact you
> must not. And if you have a comparison like
> 
> dev->vID == 0x1234
> 
> if you change this to
> 
> dev->vID == SOME_VENDOR_ID
> 
> what good does this to you? You already knew it was a vendor ID.
> Now you can name it at a glance. So what? If you have a device
> you will have to check whether you have some OEM version. You
> will always go and check the raw number. And if you have a log
> and need to check whether the check will be true, you will have
> a number.
> Using a constant there is nothing but trouble. Yet one more grep.

Thank you for that explanation. But IMHO it was clearer with a
human-readable name in such comparisons...

For example in the following I see at the first glance which
device from which vendor is affected and I don't need any
additional comments or ID databases...
   if (pdev->vendor == PCI_VENDOR_ID_TI &&
   pdev->device == PCI_DEVICE_ID_TI_TUSB73X0)

...but if that's not the preferred way of doing things I'm
perfectly fine with that.

Furthermore to me it sounds you are saying that the complete
pci_ids.h should be thrown over-board?!?

regards;richard.l

--
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 00/16] remove eight obsolete architectures

[Arnd Bergmann]

On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:
> Do we have anything left that still implements NOMMU?

Yes, plenty. I was wondering the same thing, but it seems that the architectures
we remove are almost completely representative of what we support overall,
except that they are all not licensed to 3rd parties, unlike many of the ones we
keep.

I've made an overview of the remaining architectures for my own reference[1].
The remaining NOMMU architectures are:

- arch/arm has ARMv7-M (Cortex-M microcontroller), which is actually
gaining traction
- arch/sh has an open-source J2 core that was added not that long ago,
it seems to
  be the only SH compatible core that anyone is working on.
- arch/microblaze supports both MMU/NOMMU modes (most use an MMU)
- arch/m68k supports several NOMMU targets, both the coldfire SoCs and the
  classic processors
- c6x has no MMU

   Arnd

[1] 
https://docs.google.com/spreadsheets/d/1QxMvW5jpVG2jb4RM9CQQl27-wVpNYOa-_3K2RVKifb0
--
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 00/16] remove eight obsolete architectures

[Geert Uytterhoeven]

Hi David,

On Thu, Mar 15, 2018 at 10:42 AM, David Howells  wrote:
> Do we have anything left that still implements NOMMU?

Sure: arm, c6x, m68k, microblaze, and  sh.

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DWC2 maintainership change

[Greg Kroah-Hartman (gre...@linuxfoundation.org)]

On Thu, Mar 15, 2018 at 04:00:25AM +, John Youn wrote:
> Hi Felipe, Greg,
> 
> I won't be able to continue maintainership of dwc2.
> 
> Minas Harutyunyan, has been doing most of the communication on linux-usb 
> lately and much of the maintenance and development work. He has excellent 
> knowledge of the controller, having worked with it since its inception many 
> years ago.
> 
> I propose that he take over as the new maintainer.

No objection to me, send in a patch.

And thanks for your time being the maintainer, it's much appreciated.

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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD

[Kashyap Chamarthy]

On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote:
> 
> Kashyap,

Hi Martin,

> > Sorry, I didn't give you complete information — with the previous
> > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB
> > "A Cable".  
> >
> > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop
> > (Lenovo T470s), it _does_ show "UAS".   Refer the arrow below:
> 
> Do you get different sg_readcap -l output when accessing it in UAS mode?
> I.e. is lbpme=1?

Afraid, no :-(  I was excited for a brief moment, but it's the same as
earlier.  The result with the SSD via 'Thunderbolt':

$> sudo sg_readcap -l /dev/sdc
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last logical block address=976773167 (0x3a38602f), Number of logical 
blocks=976773168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned logical block address=0
Hence:
   Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB


/me naively wonders if it has anything to do with accessing it via
Linux.

-- 
/kashyap
--
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 00/16] remove eight obsolete architectures

[David Howells]

Do we have anything left that still implements NOMMU?

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

Re: [PATCH 0/2] USB 3.2 initial support

[Oliver Neukum]

Am Donnerstag, den 15.03.2018, 09:33 +0200 schrieb Mathias Nyman:
> On 14.03.2018 12:29, Oliver Neukum wrote:
> > 
> > We should also export all raw data we have. User space can be trusted
> > to get a multiplication right and it is not the kernels job
> > to interpret such data.
> 
> Do I understand correctly that you propose the "speed" sysfs entry
> should only show the lane signaling rate, i.e. 5000 or 1 for USB 3.x.

Yes. Well actually we should call it rate then.
And if you are paranoid split it in tx and rx.

> Adding rx_lanes and tx_lanes and keeping "speed" as lane signaling rate
> is probably the cleanest and most straight forward approach.
> 
> I still would like to add  a "Gen XxY" or "SSIC" to the
> "new/reset SuperSpeed USB device number  using " dev_info string.

Definitely

> It's a quick way of checking if the device works at the expected speed when
> connecting a device.

Indeed. In the journal everything is fair and we definitely want
to tell at glance whether we got the lane count or the rate wrong.

Regards
Oliver

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

Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic

[Oliver Neukum]

Am Mittwoch, den 14.03.2018, 16:44 +0100 schrieb Richard Leitner:
> On 03/14/2018 04:27 PM, Oliver Neukum wrote:
> > Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner:
> > > 
> > Well, but it does not. Removing a redundant definition is a clear
> > benefit. But you are not removing a definition. You are introducing
> > a preprocessor constant. Why?
> > What is its benefit?
> 
> AFAIK pci_ids.h collects PCI vendor and device IDs in one single 
> point. As the PCI vendor ID of Netlogic is used in multiple files
> IMHO it would be a good idea to add it to pci_ids.h and furthermore
> remove it from arch/mips/include/asm/netlogic/xlp-hal/iomap.h (where
> it's currently defined).
> 
> Or am I getting things wrong?

I think so, yes. We are giving names to constants as a form
of comment or to change them at multiple places at once and
consistently.

So

#define XYZ_NETDEV_RESET_RETRIES2

makes clearly sense. So does

#define XYZ_MAGIC_VALUE10xab4e

because it tells you that you have a magic value.
But you will never redefine a PCI vendor ID. In fact you
must not. And if you have a comparison like

dev->vID == 0x1234

if you change this to

dev->vID == SOME_VENDOR_ID

what good does this to you? You already knew it was a vendor ID.
Now you can name it at a glance. So what? If you have a device
you will have to check whether you have some OEM version. You
will always go and check the raw number. And if you have a log
and need to check whether the check will be true, you will have
a number.
Using a constant there is nothing but trouble. Yet one more grep.

Regards
Oliver

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

Re: [PATCH v1 2/2] usb: dwc3: Add Qualcomm DWC3 glue driver

[Manu Gautam]

Hi,


On 3/14/2018 2:20 PM, Felipe Balbi wrote:
> Hi,
>
> Manu Gautam  writes:
>
[snip]
  - Support to replace pip3 clock going to DWC3 with utmi clock
for hardware configuration where SSPHY is not used with DWC3.
>>> Is that SW configurable? Really? In any case seems like this and SESSVLD
>>> valid should be handled using Hans' and Heikki's mux support.
>> Yes, with this we can use dwc3 without using SSPHY. Please point me to
>> those patches. There are only bunch of register writes in glue wrapper to
>> achieve the same.
> https://www.spinics.net/lists/linux-usb/msg160868.html

I looked at the patchset and thinking that adding mux for this may
not be of much help here. Qscratch is part of dwc3 wrapper
and uses same clock domain for its registers. Hence, I can't
have a separate mux driver for same. Will have to register
mux controller from this driver for these and use only in this driver
as I dont expect any other client for same. So, can I proceed with
existing logic?

>
 +static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)
 +{
 +  struct dwc3 *dwc = platform_get_drvdata(qcom->dwc3);
>>> nope! Glue shouldn't touch dwc3 at all.
>> Other than PHY handles, need this to fail runtime suspend if dwc3 hasn't
>> probed yet.
> Will that even happen? You should pm_runtime_forbid() by default,
> anyway and expect it to be enabled via sysfs later, no?

It happens if I enable runtime_pm from probe which is the case right now.
I will disable it from probe as you suggested.
In any case dwc3 uses pm_runtime_forbid and expects it to be enabled from sysfs,
so I dont get any benefit of enabling it from glue driver probe.

Other than this, I need to access 'dwc->xhci' to resume root hub on remote 
wakeup.
That I missed to mention earlier.

>
 +  dwc3_qcom_suspend_hsphy(qcom);
 +
 +  if (dwc->usb2_generic_phy)
 +  phy_pm_runtime_put_sync(dwc->usb2_generic_phy);
 +  if (dwc->usb3_generic_phy)
 +  phy_pm_runtime_put_sync(dwc->usb3_generic_phy);
>>> core.c should do this.
>> Recommended sequence from h/w programming guide is that:
>> 1. PHY autosuspend must be left disabled - 
>> snps,dis_u2_susphy_quirk/dis_enblslpm_quirk
>> 2. During runtime-suspend (say on xhci bus_suspend) , PHY should be suspended
>>     using GUSB2PHYCFG register
> this is something that dwc3 core can do on its own suspend implementation.
>
>> 3. Wait until pwr_event_irq_stat in qscratch reflects PHY transition to L2.
> this is interesting part. Is this register accessible by the PHY driver?
> Seems like that would be the best place to stuff this...

This register is in controller wrapper which PHY driver can't access.
Also clock domain is different.

>
>> 3. USB2 PHY driver can suspend - enable wakeup events and turns off clocks 
>> etc.
> ... together with this.
>
>> 4. dwc3 glue driver can suspend.
>>
>> Since, pwr_event_irq stat can't be checked in core driver, I added this 
>> handling
>> in glue driver. Alternative approach I can think of is to let dwc3 core 
>> suspend
>> PHY using GUSBPHYCFG register on suspend,  add some delay before
>> suspending PHY. Glue driver can check for pwr_event_irq stat and throw a
>> warning if PHY not in L2.
> almost :-) core_suspend fiddles with GUSB2PHYCFG for suspend and calls
> phy_suspend() (or whatever the function is called heh), that will go to
> your phy driver's suspend callback, which checks pwr_event_irq_stat and
> then pm_runtime_put() to schedule ->runtime_suspend() so that can enable
> wakeups and switch off clocks.

Since phy driver can not access pwr_event_irq_stat, should I just use some delay
and assume PHY gets suspended?

>
 +  irq = platform_get_irq_byname(pdev, "dp_hs_phy_irq");
 +  if (irq > 0) {
 +  irq_set_status_flags(irq, IRQ_NOAUTOEN);
>>> why do you need to set this flag?
>> These wakeup_irqs should be enabled only during suspend. With this flag I
>> don't need to disable irq immediately after requesting it.
> oh, okay. You may want to add a comment here :-)
Sure.

-- 
The Qualcomm Innovation Center, 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: WARN_ON(irqs_disabled()) in dma_free_attrs?

[Christoph Hellwig]

On Wed, Mar 14, 2018 at 05:43:46PM +, Robin Murphy wrote:
>> Looking back I don't really understand why we even indirect the "classic"
>> per-device dma_declare_coherent_memory use case through the DMA API.
>
> It certainly makes sense for devices which can exist in both shared-memory 
> and device-local-memory configurations, so the driver doesn't have to care 
> about the details (particularly on mobile SoCs where the 'local' memory 
> might just be a chunk of system RAM reserved by the bootloader, and it's 
> just a matter of different use-cases on identical hardware).

Well, the "classic" case for me is memory buffers in the device.  Setting
some memory aside, either in a global pool as now done for arm-nommu
or even per-device as on some ARM SOCs is different indeed.

As far as I can tell the few devices that use 'local' memory always
use that.

>> It seems like a pretty different use case to me.  In the USB case we
>> also have the following additional twist in that it doesn't even need
>> the mapping to be coherent.
>
> I'm pretty sure it does (in the sense that it needs to ensure the arch code 
> makes the mapping non-cacheable), otherwise I can't see how the bouncing 
> could work properly. I think the last bit of the comment above 
> hcd_alloc_coherent() is a bit misleading.

Well, if it isn't marked non-cacheable we'd have to do dma_cache_sync
operations for it.  Which would probably still be faster than non-cacheable
mappings.

>> So maybe for now the quick fix is to move the sleep check as suggested
>> earlier in this thread, but in the long run we probably need to do some
>> major rework of how dma_declare_coherent_memory and friends work.
>
> Maybe; I do think the specific hcd_alloc_coherent() case could still be 
> fixed within the scope of the existing code, but it's not quite as clean 
> and straightforward as I first thought, and the practical impact of 
> tweaking the WARN should be effectively zero despite the theoretical edge 
> cases it opens up. Do you want me to write it up as a proper patch?

Yes.  Including a proper comment on why the might_sleep is placed there.

My mid-term plan was to actually remove the gfp flags argument from
the dma alloc routines as is creates more confusion than it helps.
I guess this means we'll at least need to introduce a DMA_ATTR_NON_BLOCK
or similar flag instead then unfortunately.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 10/12] staging: typec: tcpci: keep the not connecting cc line open

[李��帆]

Hi Jun,

-Original Message-
From: Jun Li [mailto:jun...@nxp.com]
Sent: Thursday, March 15, 2018 3:00 PM
To: shufan_lee(李��帆); robh...@kernel.org; mark.rutl...@arm.com; 
gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com
Cc: a.ha...@samsung.com; li...@roeck-us.net; yue...@google.com; 
o_leve...@orange.fr; linux-usb@vger.kernel.org; dl-linux-imx
Subject: RE: [PATCH v3 10/12] staging: typec: tcpci: keep the not connecting cc 
line open



> -Original Message-
> From: shufan_lee(李��帆) [mailto:shufan_...@richtek.com]
> Sent: 2018年3月14日 16:59
> To: Jun Li ; robh...@kernel.org; mark.rutl...@arm.com;
> gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com
> Cc: a.ha...@samsung.com; li...@roeck-us.net; yue...@google.com;
> o_leve...@orange.fr; linux-usb@vger.kernel.org; dl-linux-imx
> 
> Subject: RE: [PATCH v3 10/12] staging: typec: tcpci: keep the not
> connecting cc line open
>
> Hi Jun,
>
> -Original Message-
> From: Li Jun [mailto:jun...@nxp.com]
> Sent: Tuesday, March 13, 2018 5:35 PM
> To: robh...@kernel.org; mark.rutl...@arm.com;
> gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com
> Cc: a.ha...@samsung.com; jun...@nxp.com; li...@roeck-us.net;
> yue...@google.com; shufan_lee(李��帆); o_leve...@orange.fr;
> linux-usb@vger.kernel.org; linux-...@nxp.com
> Subject: [PATCH v3 10/12] staging: typec: tcpci: keep the not
> connecting cc line open
>
> While set polarity, we should keep the not connecting cc line to be
> open when attached.
>
> Signed-off-by: Li Jun 
> ---
>  drivers/staging/typec/tcpci.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/typec/tcpci.c
> b/drivers/staging/typec/tcpci.c index
> 9a230c6..6fdb179 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -185,6 +185,7 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
>enum typec_cc_polarity polarity)  {  struct tcpci *tcpci =
> tcpc_to_tcpci(tcpc);
> +unsigned int reg;
>  int ret;
>
>  ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL, @@ -193,7 +194,17
> @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,  if (ret < 0)
> return ret;
>
> -return 0;
> +/* Set the not connected cc line open */ ret =
> +regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, ); if (ret < 0) return
> +ret; if (polarity == TYPEC_POLARITY_CC2) ret =
> +TCPC_ROLE_CTRL_CC1_SHIFT; else ret = TCPC_ROLE_CTRL_CC2_SHIFT; reg |=
> +TCPC_ROLE_CTRL_CC_OPEN << ret; reg &= ~TCPC_ROLE_CTRL_DRP; return
> +regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
>  }
>
>  static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
> --
> 2.7.4
>
>   I applied all of your patches and tested with RT1711H.
>   I met a case as following:
>   1. The state machine starts toggling with RC.CCx = Rp/Rp
>   2. Connect to adapter with an A2C cable
>   3. open/open is received after setting RC.DRP to 0. Because RC.CCx
> is Rp/Rp while setting RC.DRP to 0 and the connected A2C cable is a cable 
> with Rp.
>

What's the RC.CCx value before setting RC.DRP in your case?
It is Rp/Rp, i.e. reg0x1A = 0x4A

I suppose the RC.CCx should be updated accordingly by TCPC (and its firmware), 
RT1711H still keep the starting value after detected a Rp?
Yes, according to TCPCI's spec, upon connection, the TCPC shall resolve to 
either an Rp or Rd and report the CC1/CC2 State in the CC_STATUS register.
It seems like we only need to present correct role and report to CC_STATUS 
register but not necessary to report the role to RC.CCx.
So, RT1711H's firmware only present Rd and report it to reg0x1D(CC_STATUS) but 
not change the value of reg0x1A (RC.CCx).

>   According to TCPCI's specification, Figure 4-20. DRP Initialization
> and Connection Detection, we need to set RC.CCx before setting RC.DRP to 0.
>
>   ConnectionDetermine CC & VCONN
> - Set RC.CC1 & RC.CC2 per decision
> - Set RC.DRP=0
> - Set TCPC_CONTROl.PlugOrientation
> - Set PC.AutoDischargeDisconnect=1 & PC.EnableVconn
>
>   If I understand correctly, we'll need to do the following step
> before setting DRP to 0.

The read out value has the correct RC.CCx in my HW, so another question is: 
without my patch of this and below change, how does your chip can work in this 
case before?
If we don't write RC.DRP to 0 after attached, RC.CCx will not take effect. 
RT1711H will present the correct role that detected by toggling, i.e. the role 
shows in reg0x1D(CC_STATUS).

RC.DRP == 1 and RC.CCx is Rp/Rp but actually your typec chip is presenting Rd? 
(show me the RC value when set polarity without my patch)
Yes, value of Reg0x1A(Role Control) is 0x4A.

Jun Li
>
> @@ -1900,6 +1901,8 @@ static int tcpm_src_attach(struct tcpm_port *port)
> if (port->attached)
> return 0;
>
> +   tcpm_set_cc(port, tcpm_rp_cc(port));
> +
> ret = tcpm_set_polarity(port, polarity);
> if (ret < 0)
> return ret;
> @@ -2014,6 

RE: [PATCH] lan78xx: Connect phy early

[Nisar.Sayed]

Hi Alexander,

Thanks for the patch.

> @@ -2575,13 +2571,7 @@ static int lan78xx_stop(struct net_device *net)
>   if (timer_pending(>stat_monitor))
>   del_timer_sync(>stat_monitor);
> 
> - phy_unregister_fixup_for_uid(PHY_KSZ9031RNX, 0xfff0);
> - phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfff0);
> -
>   phy_stop(net->phydev);
> - phy_disconnect(net->phydev);
> -
> - net->phydev = NULL;
> 
>   clear_bit(EVENT_DEV_OPEN, >flags);
>   netif_stop_queue(net);

Please do add valid "phydev"  check before phy_stop, since "phy_disconnect" 
should be called before "unregister_netdev"

+ if (net->phydev)
phy_stop(net->phydev);

> @@ -3481,6 +3471,11 @@ static void lan78xx_disconnect(struct
> usb_interface *intf)
>   net = dev->net;
>   unregister_netdev(net);
> 
> + phy_unregister_fixup_for_uid(PHY_KSZ9031RNX, 0xfff0);
> + phy_unregister_fixup_for_uid(PHY_LAN8835, 0xfff0);
> +
> + phy_disconnect(net->phydev);
> +
>   cancel_delayed_work_sync(>wq);
> 
>   usb_scuttle_anchored_urbs(>deferred);

Please move "unregister_netdev" after "phy_disconnect", otherwise 
"phy_disconnect" will fail while we disconnect USB.

> @@ -3634,6 +3629,10 @@ static int lan78xx_probe(struct usb_interface
> *intf,
>   pm_runtime_set_autosuspend_delay(>dev,
>DEFAULT_AUTOSUSPEND_DELAY);
> 
> + ret = lan78xx_phy_init(dev);
> + if (ret < 0)
> + return ret;
> +
>   return 0;
> 
>  out3:
> --
> 2.12.3

We should "goto out4" instead of "return" upon "lan78xx_phy_init" fail

+ out4:
+   unregister_netdev(netdev);

In addition to current changes, you might have to take care of the following.

In function "lan78xx_reset_resume"

-  lan78xx_phy_init(dev);
+ phy_start(dev->net->phydev);

Thanks,
Sd.Nisar


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

Re: [PATCH 0/2] USB 3.2 initial support

[Mathias Nyman]

On 14.03.2018 12:29, Oliver Neukum wrote:

Am Dienstag, den 13.03.2018, 19:22 +0200 schrieb Mathias Nyman:


My understanding is that Gen XxY notion is only used for symmetric devices
where tx lanes = rx lanes. Only SSIC devices can be asymmetric.

USB 3.2 spec mentions the (Gen 1x1, 1x2, 2x1 and 2x2) alternatives, nothing 
more.
Nothing about different lane counts on rx and tx related to Gen XxY.


Hi,

normally I would say that we should worry about this only when we need
to, but an API in sysfs is an exception to that rule. We can avoid
pain later if we export lane counts for both directions now
in all cases.


Sounds reasonable, I'll add both rx_lanes and tx_lanes



We should also export all raw data we have. User space can be trusted
to get a multiplication right and it is not the kernels job
to interpret such data.


Do I understand correctly that you propose the "speed" sysfs entry
should only show the lane signaling rate, i.e. 5000 or 1 for USB 3.x.

Adding rx_lanes and tx_lanes and keeping "speed" as lane signaling rate
is probably the cleanest and most straight forward approach.

I still would like to add  a "Gen XxY" or "SSIC" to the
"new/reset SuperSpeed USB device number  using " dev_info string.
It's a quick way of checking if the device works at the expected speed when
connecting a device.

An thoughts about that?

-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: [PATCH v3 10/12] staging: typec: tcpci: keep the not connecting cc line open

[Jun Li]

> -Original Message-
> From: shufan_lee(李��帆) [mailto:shufan_...@richtek.com]
> Sent: 2018年3月14日 16:59
> To: Jun Li ; robh...@kernel.org; mark.rutl...@arm.com;
> gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com
> Cc: a.ha...@samsung.com; li...@roeck-us.net; yue...@google.com;
> o_leve...@orange.fr; linux-usb@vger.kernel.org; dl-linux-imx
> 
> Subject: RE: [PATCH v3 10/12] staging: typec: tcpci: keep the not connecting
> cc line open
> 
> Hi Jun,
> 
> -Original Message-
> From: Li Jun [mailto:jun...@nxp.com]
> Sent: Tuesday, March 13, 2018 5:35 PM
> To: robh...@kernel.org; mark.rutl...@arm.com;
> gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com
> Cc: a.ha...@samsung.com; jun...@nxp.com; li...@roeck-us.net;
> yue...@google.com; shufan_lee(李��帆); o_leve...@orange.fr;
> linux-usb@vger.kernel.org; linux-...@nxp.com
> Subject: [PATCH v3 10/12] staging: typec: tcpci: keep the not connecting cc
> line open
> 
> While set polarity, we should keep the not connecting cc line to be open when
> attached.
> 
> Signed-off-by: Li Jun 
> ---
>  drivers/staging/typec/tcpci.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c 
> index
> 9a230c6..6fdb179 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -185,6 +185,7 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
>enum typec_cc_polarity polarity)  {  struct tcpci *tcpci =
> tcpc_to_tcpci(tcpc);
> +unsigned int reg;
>  int ret;
> 
>  ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL, @@ -193,7 +194,17
> @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,  if (ret < 0)  return
> ret;
> 
> -return 0;
> +/* Set the not connected cc line open */ ret =
> +regmap_read(tcpci->regmap, TCPC_ROLE_CTRL, ); if (ret < 0) return
> +ret; if (polarity == TYPEC_POLARITY_CC2) ret =
> +TCPC_ROLE_CTRL_CC1_SHIFT; else ret = TCPC_ROLE_CTRL_CC2_SHIFT; reg |=
> +TCPC_ROLE_CTRL_CC_OPEN << ret; reg &= ~TCPC_ROLE_CTRL_DRP; return
> +regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
>  }
> 
>  static int tcpci_set_vconn(struct tcpc_dev *tcpc, bool enable)
> --
> 2.7.4
> 
>   I applied all of your patches and tested with RT1711H.
>   I met a case as following:
>   1. The state machine starts toggling with RC.CCx = Rp/Rp
>   2. Connect to adapter with an A2C cable
>   3. open/open is received after setting RC.DRP to 0. Because RC.CCx is Rp/Rp
> while setting RC.DRP to 0 and the connected A2C cable is a cable with Rp.
> 

What's the RC.CCx value before setting RC.DRP in your case?
I suppose the RC.CCx should be updated accordingly by TCPC
(and its firmware), RT1711H still keep the starting value after
detected a Rp?

>   According to TCPCI's specification, Figure 4-20. DRP Initialization and
> Connection Detection, we need to set RC.CCx before setting RC.DRP to 0.
> 
>   ConnectionDetermine CC & VCONN
> - Set RC.CC1 & RC.CC2 per decision
> - Set RC.DRP=0
> - Set TCPC_CONTROl.PlugOrientation
> - Set PC.AutoDischargeDisconnect=1 & PC.EnableVconn
> 
>   If I understand correctly, we'll need to do the following step before 
> setting
> DRP to 0.

The read out value has the correct RC.CCx in my HW, so another
question is: without my patch of this and below change, how does your chip
can work in this case before? RC.DRP == 1 and RC.CCx is Rp/Rp but actually
your typec chip is presenting Rd? (show me the RC value when set polarity
without my patch)

Jun Li
> 
> @@ -1900,6 +1901,8 @@ static int tcpm_src_attach(struct tcpm_port *port)
> if (port->attached)
> return 0;
> 
> +   tcpm_set_cc(port, tcpm_rp_cc(port));
> +
> ret = tcpm_set_polarity(port, polarity);
> if (ret < 0)
> return ret;
> @@ -2014,6 +2017,8 @@ static int tcpm_snk_attach(struct tcpm_port *port)
> if (port->attached)
> return 0;
> 
> +   tcpm_set_cc(port, TYPEC_CC_RD);
> +
> ret = tcpm_set_polarity(port, port->cc2 != TYPEC_CC_OPEN ?
> TYPEC_POLARITY_CC2 :
> TYPEC_POLARITY_CC1);
> if (ret < 0)
> 
> * Email Confidentiality Notice 
> 
> The information contained in this e-mail message (including any attachments)
> may be confidential, proprietary, privileged, or otherwise exempt from
> disclosure under applicable laws. It is intended to be conveyed only to the
> designated recipient(s). Any use, dissemination, distribution, printing, 
> retaining
> or copying of this e-mail (including its attachments) by unintended 
> recipient(s)
> is strictly prohibited and may be unlawful. If you are not an intended 
> recipient
> of this e-mail, or believe that you have received this e-mail in error, please
> notify the sender immediately (by replying to this e-mail), delete any and all
> copies of this e-mail (including any attachments)