Re: [PATCH 1/3] usb: pci: Remove unnecessary pci_set_drvdata().

[Greg KH]

On Wed, May 11, 2016 at 06:08:15PM +0530, Sandhya Bankar wrote:
> Unnecessary [platform|pci]_set_drvdata() have been removed since the driver 
> core clears the driver data to NULLafter device release or on probe failure. 
> There is no need to manually clear the
> device driver data to NULL.

Please fix your changelog text to be wrapped at 72 columns like it is
supposed to be.

thanks,

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

Re: [PATCH v5 resend 1/2] ehci-platform: Add support for controllers with multiple reset lines

[Greg Kroah-Hartman]

On Thu, Jun 02, 2016 at 05:14:05PM +0200, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> reset lines, the controller will not initialize while the reset for
> its companion is still asserted, which means we need to de-assert
> 2 resets for the controller to work.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Use the new reset_control_[de]assert_shared reset-controller functions
> ---
>  Documentation/devicetree/bindings/usb/usb-ehci.txt |  2 +-
>  drivers/usb/host/ehci-platform.c   | 41 
> --
>  2 files changed, 24 insertions(+), 19 deletions(-)

This patch doesn't apply to my usb-testing branch at all, what went
wrong?

thanks,

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

Re: [PATCH v10 6/7] usb: pci-quirks: add Intel USB drcfg mux device

[Greg Kroah-Hartman]

On Thu, Jun 02, 2016 at 09:37:28AM +0800, Lu Baolu wrote:
> In some Intel platforms, a single usb port is shared between USB host
> and device controllers. The shared port is under control of a switch
> which is defined in the Intel vendor defined extended capability for
> xHCI.
> 
> This patch adds the support to detect and create the platform device
> for the port mux switch.

Why do you need a platform device for this?  You do nothing with this
device, why create it at all?

And why is it a platform device, isn't is really a PCI device?  Why
would you ever find a "platform" device below a PCI device?  Don't abuse
platform devices for things that aren't.  It makes me want to delete
that whole interface more and more...

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

Re: [PATCH v10 1/7] regulator: fixed: add support for ACPI interface

[Greg Kroah-Hartman]

On Thu, Jun 02, 2016 at 09:37:23AM +0800, Lu Baolu wrote:
> Add support to retrieve fixed voltage configure information through
> ACPI interface. This is needed for Intel Bay Trail devices, where a
> GPIO is used to control the USB vbus.
> 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/regulator/fixed.c | 46 ++
>  1 file changed, 46 insertions(+)

Can't do anything with this until I get an ack from the "owners" of this
file.

And what happened to the acks from other Intel developers for this whole
patch series, I don't see that here :(

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

[PATCH v3 2/2] ARM: at91/dt: sama5d2: Use new compatible for ohci node

[Wenyou Yang]

Use compatible "atmel,sama5d2-ohci" to be capable of suspending
ports while sleep to save the power consumption.

Signed-off-by: Wenyou Yang 
---

Changes in v3: None
Changes in v2:
 - Use the new compatible for ohci-node.

 arch/arm/boot/dts/sama5d2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index 78996bd..03d6724 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -232,7 +232,7 @@
};
 
usb1: ohci@0040 {
-   compatible = "atmel,at91rm9200-ohci", "usb-ohci";
+   compatible = "atmel,sama5d2-ohci", "usb-ohci";
reg = <0x0040 0x10>;
interrupts = <41 IRQ_TYPE_LEVEL_HIGH 2>;
clocks = <_clk>, <_clk>, <>;
-- 
2.7.4

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

[PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Wenyou Yang]

In order to the save power consumption, as a workaround, suspend
forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
Interrupt Configuration Register in the SFRs while OHCI USB suspend.

This suspend operation must be done before the USB clock is disabled,
resume after the USB clock is enabled.

Signed-off-by: Wenyou Yang 
---

Changes in v3:
 - Change the compatible description for more precise.

Changes in v2:
 - Add compatible to support forcibly suspend the ports.
 - Add soc/at91/at91_sfr.h to accommodate the defines.
 - Add error checking for .sfr_regmap.
 - Remove unnecessary regmap_read() statement.

 .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
 drivers/usb/host/ohci-at91.c   | 80 +-
 include/soc/at91/at91_sfr.h| 29 
 3 files changed, 112 insertions(+), 3 deletions(-)
 create mode 100644 include/soc/at91/at91_sfr.h

diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt 
b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 5883b73..888deaa 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -3,8 +3,10 @@ Atmel SOC USB controllers
 OHCI
 
 Required properties:
- - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
-   used in host mode.
+ - compatible: Should be one of the following
+  "atmel,at91rm9200-ohci" for USB controllers used in host mode.
+  "atmel,sama5d2-ohci" for USB controllers used in host mode
+  on SAMA5D2 which can force to suspend.
  - reg: Address and length of the register set for the device
  - interrupts: Should contain ehci interrupt
  - clocks: Should reference the peripheral, host and system clocks
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..54e8feb 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -21,8 +21,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include "ohci.h"
 
@@ -45,12 +48,18 @@ struct at91_usbh_data {
u8 overcurrent_changed[AT91_MAX_USBH_PORTS];
 };
 
+struct ohci_at91_caps {
+   bool suspend_ctrl;
+};
+
 struct ohci_at91_priv {
struct clk *iclk;
struct clk *fclk;
struct clk *hclk;
bool clocked;
bool wakeup;/* Saved wake-up state for resume */
+   const struct ohci_at91_caps *caps;
+   struct regmap *sfr_regmap;
 };
 /* interface and function clocks; sometimes also an AHB clock */
 
@@ -132,6 +141,17 @@ static void at91_stop_hc(struct platform_device *pdev)
 
 /*-*/
 
+struct regmap *at91_dt_syscon_sfr(void)
+{
+   struct regmap *regmap;
+
+   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
+   if (IS_ERR(regmap))
+   regmap = NULL;
+
+   return regmap;
+}
+
 static void usb_hcd_at91_remove (struct usb_hcd *, struct platform_device *);
 
 /* configure so an HC device and id are always provided */
@@ -197,6 +217,17 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
goto err;
}
 
+   ohci_at91->caps = (const struct ohci_at91_caps *)
+ of_device_get_match_data(>dev);
+   if (!ohci_at91->caps)
+   return -ENODEV;
+
+   if (ohci_at91->caps->suspend_ctrl) {
+   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
+   if (!ohci_at91->sfr_regmap)
+   dev_warn(dev, "failed to find sfr node\n");
+   }
+
board = hcd->self.controller->platform_data;
ohci = hcd_to_ohci(hcd);
ohci->num_ports = board->ports;
@@ -440,8 +471,17 @@ static irqreturn_t ohci_hcd_at91_overcurrent_irq(int irq, 
void *data)
return IRQ_HANDLED;
 }
 
+static const struct ohci_at91_caps at91rm9200_caps = {
+   .suspend_ctrl = false,
+};
+
+static const struct ohci_at91_caps sama5d2_caps = {
+   .suspend_ctrl = true,
+};
+
 static const struct of_device_id at91_ohci_dt_ids[] = {
-   { .compatible = "atmel,at91rm9200-ohci" },
+   { .compatible = "atmel,at91rm9200-ohci", .data = _caps },
+   { .compatible = "atmel,sama5d2-ohci", .data = _caps },
{ /* sentinel */ }
 };
 
@@ -581,6 +621,38 @@ static int ohci_hcd_at91_drv_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable)
+{
+   u32 regval;
+   int ret;
+
+   if (!regmap)
+   return -EINVAL;
+
+   ret = regmap_read(regmap, SFR_OHCIICR, );
+   if (ret)
+   return ret;
+
+   if (enable)
+   regval &= ~SFR_OHCIICR_USB_SUSPEND;
+   else
+   regval |= SFR_OHCIICR_USB_SUSPEND;
+
+   regmap_write(regmap, SFR_OHCIICR, regval);
+
+   return 0;
+}
+

[PATCH v3 0/2] ARM: ohci-at91: Add support to forcibly suspend ports while sleep

[Wenyou Yang]

To save the power consumption, add a new compatible to support forcibly
suspend the USB PORTA/B/C via OHCI Interrupt Configuration SFR Register.

Changes in v3:
 - Change the compatible description for more precise.

Changes in v2:
 - Add compatible to support forcibly suspend the ports.
 - Add soc/at91/at91_sfr.h to accommodate the defines.
 - Add error checking for .sfr_regmap.
 - Remove unnecessary regmap_read() statement.
 - Use the new compatible for ohci-node.

Wenyou Yang (2):
  usb: ohci-at91: Forcibly suspend ports while USB suspend
  ARM: at91/dt: sama5d2: Use new compatible for ohci node

 .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
 arch/arm/boot/dts/sama5d2.dtsi |  2 +-
 drivers/usb/host/ohci-at91.c   | 80 +-
 include/soc/at91/at91_sfr.h| 29 
 4 files changed, 113 insertions(+), 4 deletions(-)
 create mode 100644 include/soc/at91/at91_sfr.h

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

Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

[Peter Chen]

On Tue, Jun 07, 2016 at 01:22:37PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> >> >> > kbuild test robot  writes:
> >> >> >> tree:   
> >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> >> >> >> testing/next
> >> >> >> head:   89fe2b5ab11cdf6a67d4492d893e70e330aa7060
> >> >> >> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: 
> >> >> >> gadget: move gadget API functions to udc-core
> >> >> >> config: x86_64-randconfig-s1-06061834 (attached as .config)
> >> >> >> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> >> >> >> reproduce:
> >> >> >> git checkout 231b31ca34485552fe27e67dc6d30d06079c7648
> >> >> >> # save the attached .config to linux build tree
> >> >> >> make ARCH=x86_64 
> >> >> >>
> >> >> >> All errors (new ones prefixed by >>):
> >> >> >>
> >> >> >>drivers/built-in.o: In function `nop_set_peripheral':
> >> >>  phy-generic.c:(.text+0x14423f): undefined reference to 
> >> >>  `usb_gadget_vbus_connect'
> >> >> >>drivers/built-in.o: In function `nop_gpio_vbus_thread':
> >> >>  phy-generic.c:(.text+0x144742): undefined reference to 
> >> >>  `usb_gadget_vbus_disconnect'
> >> >> >
> >> >> > oh yeah, I have to fix this. I'll do it now.
> >> >> 
> >> >> In order to fix this, I'll have to add something like below:
> >> >> 
> >> >> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> >> >> index 3644a3500b70..bd67e4ac4b61 100644
> >> >> --- a/drivers/usb/chipidea/Kconfig
> >> >> +++ b/drivers/usb/chipidea/Kconfig
> >> >> @@ -19,6 +19,7 @@ config USB_CHIPIDEA_OF
> >> >>  config USB_CHIPIDEA_PCI
> >> >> tristate
> >> >> depends on PCI
> >> >> +   depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV
> >> >> depends on NOP_USB_XCEIV
> >> >> default USB_CHIPIDEA
> >> >
> >> > Hi Felipe,
> >> >
> >> > It causes any drivers which use symbols from gadget.h needs to build
> >> > USB_GADGET even it only wants to be host function. Any significant
> >> > benefits after moving it to udc-core.c?
> >> 
> >> why is a host-only function calling into the gadget API?
> >> 
> >
> > Well, Just like this case, the chipidea driver can be configured host
> > mode only, but it still uses generic phy.
> 
> then we should allow for PHYs to not depend on the Gadget API, right?

But you know it is not easy. The difficulty for gadget to do that is vbus and
pull dp, these two may be used by other subsystems, eg, vbus may be used
at PHY driver, dual-role switch driver, etc. The pull dp may be used at
USB charger driver, the secondary charger detection needs to pull up dp
for some charger designs.

See current kernel doc, it also says that.

/**
 * usb_gadget_vbus_connect - Notify controller that VBUS is powered
 * @gadget:The device which now has VBUS power.
 * Context: can sleep
 *
 * This call is used by a driver for an external transceiver (or GPIO)
 * that detects a VBUS power session starting.  Common responses include
 * resuming the controller, activating the D+ (or D-) pullup to let the
 * host detect that a USB device is attached, and starting to draw power
 * (8mA or possibly more, especially after SET_CONFIGURATION).
 *
 * Returns zero on success, else negative errno.
 */
static inline int usb_gadget_vbus_connect(struct usb_gadget *gadget)
{
if (!gadget->ops->vbus_session)
return -EOPNOTSUPP;
return gadget->ops->vbus_session(gadget, 1);
}

See current situations:

b29397@linux2:~/work/projects/usb$ find . -name *.c | xargs grep -rn 
"usb_gadget_vbus_connect"
./drivers/phy/phy-twl4030-usb.c:559: * REVISIT 
usb_gadget_vbus_connect(...) as needed, ditto
./drivers/usb/phy/phy-gpio-vbus-usb.c:126:  
usb_gadget_vbus_connect(gpio_vbus->phy.otg->gadget);
./drivers/usb/phy/phy-tahvo.c:89:   
usb_gadget_vbus_connect(tu->phy.otg->gadget);
./drivers/usb/phy/phy-isp1301-omap.c:929:   
usb_gadget_vbus_connect(isp->phy.otg->gadget);
./drivers/usb/phy/phy-isp1301-omap.c:1466:  
usb_gadget_vbus_connect(otg->gadget);
./drivers/usb/phy/phy-generic.c:122:
usb_gadget_vbus_connect(otg->gadget);
./drivers/usb/phy/phy-generic.c:190:usb_gadget_vbus_connect(gadget);
./drivers/usb/phy/phy-msm-usb.c:783:
usb_gadget_vbus_connect(phy->otg->gadget);
./drivers/usb/phy/phy-mv-usb.c:234: 
usb_gadget_vbus_connect(otg->gadget);
./drivers/usb/chipidea/otg.c:133:   
usb_gadget_vbus_connect(>gadget);
./drivers/usb/chipidea/otg.c:138:   
usb_gadget_vbus_connect(>gadget);
./drivers/usb/chipidea/udc.c:1964:  
usb_gadget_vbus_connect(>gadget);
./drivers/usb/chipidea/otg_fsm.c:567:   

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi,
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Tuesday, June 07, 2016 11:05 PM
> To: Roger Quadros ; Lu Baolu ;
> Jun Li ; Peter Chen 
> Cc: Mathias Nyman ; Greg Kroah-Hartman
> ; Lee Jones ; Heikki
> Krogerus ; Liam Girdwood
> ; Mark Brown ; linux-
> u...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> 
> Hi,
> 
> Roger Quadros  writes:
> >> I might be able to find some time to implement a proof of concept
> >> which would allow your platforms to get dual-role with code we
> >> already have, but I need DWC3's OTG support which, I'm assuming, you
> >> already have :-)
> >>
> >> If you wanna try something offline, just ping me ;-) I'll be happy to
> >> help.
> >
> > What you are proposing is a dwc3 only solution. With the otg/dual-role
> > series we are trying to be generic as much as possible.
> 
> Well, if there is a need for that, sure. Take MUSB for instance. It makes
> use of nothing of the sorts, because it doesn't have to.
> 
> > Whether controller drivers want to use it or not is upto the driver
> > maintainers but we should at least ensure that user space ABI if any,
> > is consistent across different implementations.
> 
> Role decisions should not be exposed to userspace unless as debug feature
> (using e.g. DebugFS). That should be done either by the HW or within the
> kernel.

In many cases the role decision is made by usersapce, this also should be
covered.
This patchset also expose it to userspace but I think it isn't for debug:
/sys/bus/platform/devices/.../portmux.N/state

Li Jun
> 
> If we're discussing userspace ABI here, there's something very wrong with
> OTG/DRD layer design.
> 
> >>> How are you switching the port mux between host and peripheral? Only
> >>> by sysfs or do you have a GPIO for ID pin as well?
> >>
> >> depends. Some SoCs have GPIO-controller muxes while some just have
> >> mux's select signals (one for ID, one for VBUS) mapped on xHCI's
> >> address space.
> >>
> >>> What happens to the gadget controller when the port is muxed to the
> >>> host controller?  Is it stopped or it continues to run?
> >>
> >> it continues running, but that's pretty irrelevant for Intel's
> >> dual-role
> >
> > Isn't that unnecessary waste of power? Or you have firmware assisted
> > low power mode?
> 
> that's an implementation detail which brings nothing to this discussion,
> right? :-)
> 
> We can, certainly, put the other side to D3.
> 
> >> setup. We have an actual physical (inside the die, though) mux which
> >> muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only
> >> DWC3.
> >>
> >
> > Probably irrelevant for Intel's dual-role but many platforms that
> > share the port can't have device controller running when port is in
> > host mode and vice versa.
> 
> but that doesn't mean we need an entire new layer added to the kernel
> ;-)
> 
> DWC3 already gives us all the information necessary to make a decision on
> which role we should assume. Just consider your options. Here's how things
> would look like without any OTG/DRD layer:
> 
> -> DWC3 OTG IRQ
>  -> readl(OSTS);
>   -> if (OSTS & BIT(4))
>-> dwc3_host_exit(); __dwc3_gadget_start();
>   -> else
>-> __dwc3_gadget_stop(); dwc3_host_init();
> 
> Can you draw something similar for your proposed OTG/DRD layer?
> 
> I remember there were at least two schedule_work(). IIRC it looked
> something like below:
> 
> -> DWC3 OTG IRQ
>  -> readl(OSTS);
>   -> if (OSTS & BIT(4))
>-> otg_set_mode(PERIPHERAL);
> -> schedule_work();
>  -> otg_ops->stop_host();
>   -> usb_del_hcd();
>  -> otg_ops->start_peripheral();
>   -> usb_gadget_add_udc();
>   -> else
>-> otg_set_mode(HOST);
> -> schedule_work();
>  -> otg_ops->stop_peripheral();
>   -> usb_gadget_del_udc();
>  -> otg_ops->start_host();
>   -> usb_add_hcd();
> 
> I'm probably missing some steps there.
> 
> > So there has to be a central point of control where the respective
> > controllers are started/stopped.
> 
> some implementations might need this, yes. DWC3 and MUSB don't seem to be
> this type of system.
> 
> > That is the other point we are trying to address with the common
> > otg/dual-role code.
> >
> > Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we
> > need to stop the host controller for device mode, right?
> 
> yes, see above. We already have that code.
> 
> > If so then who will deal with start/stop of the controllers then?
> 
> dwc3 itself.
> 
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

[Greg KH]

On Wed, Jun 08, 2016 at 08:49:55AM +0800, Herbert Xu wrote:
> On Tue, Jun 07, 2016 at 03:03:11PM -0700, Greg KH wrote:
> >
> > Ok, but usually drivers/usb/misc/ patches go through my tree :)
> 
> Sorry.  But I do wonder whether this driver should be moved as
> it is just an hwrng device like every other driver under hw_random,
> except for the fact that it happens to be a USB physical device.

That's fine with me, but it uses the usb misc device major number,
unlike other hw_random drivers, so that might get messy.

It's your call...

thanks,

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

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

[Herbert Xu]

On Tue, Jun 07, 2016 at 03:03:11PM -0700, Greg KH wrote:
>
> Ok, but usually drivers/usb/misc/ patches go through my tree :)

Sorry.  But I do wonder whether this driver should be moved as
it is just an hwrng device like every other driver under hw_random,
except for the fact that it happens to be a USB physical device.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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

[balbi-usb:testing/next 64/67] powercap_sys.c:undefined reference to `usb_gadget_vbus_connect'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
testing/next
head:   fc4d1f3f522648d92d0c046beedbc1469979499a
commit: 74e51eb7b5b4f7ab33c099c20def3dce0c699006 [64/67] usb: gadget: move 
gadget API functions to udc-core
config: arm-hisi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 74e51eb7b5b4f7ab33c099c20def3dce0c699006
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `nop_set_peripheral':
>> powercap_sys.c:(.text+0x102df8): undefined reference to 
>> `usb_gadget_vbus_connect'
   drivers/built-in.o: In function `nop_gpio_vbus_thread':
   powercap_sys.c:(.text+0x102e74): undefined reference to 
`usb_gadget_vbus_connect'
>> powercap_sys.c:(.text+0x102ee0): undefined reference to 
>> `usb_gadget_vbus_disconnect'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] usb: xhci: handle uPD720201 and uPD720202 w/o ROM

[Christian Lamparter]

This patch adds a firmware check for the uPD720201K8-711-BAC-A
and uPD720202K8-711-BAA-A variant. Both of these chips are listed
in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
devices which need a firmware in order to work as they do not have
support to load the firmware from an external ROM.

Currently, the xhci-pci driver is unable to initialize the hcd in
this case. Instead it will wait for 30 seconds and cause a timeout
in xhci_handshake() and fails.

[5.116990] xhci_hcd :45:00.0: new USB bus registered ...
[   32.335215] xhci_hcd :45:00.0: can't setup: -110
[   32.340179] xhci_hcd :45:00.0: USB bus 2 deregistered
[   32.345587] xhci_hcd :45:00.0: init :45:00.0 fail, -110
[   32.351496] xhci_hcd: probe of :45:00.0 failed with error -110

Cc: Yoshihiro Shimoda 
Signed-off-by: Christian Lamparter 
---
 drivers/usb/host/xhci-pci.c | 59 +
 1 file changed, 59 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 48672fa..3271a81 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -207,6 +207,55 @@ static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
 static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
 #endif /* CONFIG_ACPI */
 
+static int renesas_check_if_fw_dl_is_needed(struct pci_dev *pdev)
+{
+   int err;
+   u8 fw_state;
+
+   /*
+* Only the uPD720201K8-711-BAC-A or uPD720202K8-711-BAA-A
+* are listed in R19UH0078EJ0500 Rev.5.00 as devices which
+* need a firmware in order to work.
+*
+*  - uPD720202 ES 2.0 sample & CS sample & Mass product, ID is 2.
+*  - uPD720201 ES 2.0 sample whose revision ID is 2.
+*  - uPD720201 ES 2.1 sample & CS sample & Mass product, ID is 3.
+*/
+   if (!((pdev->vendor == PCI_VENDOR_ID_RENESAS) &&
+   ((pdev->device == 0x0015 && pdev->revision == 0x02) ||
+(pdev->device == 0x0014 &&
+ (pdev->revision == 0x02 || pdev->revision == 0x03)
+   return 0;
+
+   /*
+* Test if the firmware was uploaded and is running.
+* As most BIOSes will initialize the device for us.
+*/
+   err = pci_read_config_byte(pdev, 0xf4, _state);
+   if (err)
+   return pcibios_err_to_errno(err);
+
+   /* Check the "Result Code" Bits (6:4) and act accordingly */
+   switch (fw_state & 0x70) {
+   case 0: /* No result yet */
+   dev_err(>dev, "FW is not ready/loaded yet.");
+   return -ENODEV;
+
+   case BIT(4): /* Success, device should be working. */
+   dev_dbg(>dev, "FW is ready.");
+   return 0;
+
+   case BIT(5): /* Error State */
+   dev_err(>dev, "HW is in an error state.");
+   return -ENODEV;
+
+   default: /* All other states are marked as "Reserved states" */
+   dev_err(>dev, "HW is in an invalid state (%x).",
+   (fw_state & 0x70) >> 4);
+   return -EINVAL;
+   }
+}
+
 /* called during probe() after chip reset completes */
 static int xhci_pci_setup(struct usb_hcd *hcd)
 {
@@ -246,6 +295,11 @@ static int xhci_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
struct hc_driver *driver;
struct usb_hcd *hcd;
 
+   /* Check if this device is a RENESAS uPD720201/2 device. */
+   retval = renesas_check_if_fw_dl_is_needed(dev);
+   if (retval)
+   return retval;
+
driver = (struct hc_driver *)id->driver_data;
 
/* Prevent runtime suspending between USB-2 and USB-3 initialization */
@@ -424,6 +478,11 @@ static int xhci_pci_resume(struct usb_hcd *hcd, bool 
hibernated)
if (pdev->vendor == PCI_VENDOR_ID_INTEL)
usb_enable_intel_xhci_ports(pdev);
 
+   /* Check if this device is a RENESAS uPD720201/2 device. */
+   retval = renesas_check_if_fw_dl_is_needed(pdev);
+   if (retval)
+   return retval;
+
if (xhci->quirks & XHCI_SSIC_PORT_UNUSED)
xhci_ssic_port_unused_quirk(hcd, false);
 
-- 
2.8.1

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

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

[Greg KH]

On Tue, Jun 07, 2016 at 06:53:45PM +0800, Herbert Xu wrote:
> On Fri, Jun 03, 2016 at 12:13:06PM +0100, Bob Ham wrote:
> > Two patches to add support for the Araneus Alea I USB RNG to the
> > chaoskey driver.  The first simply includes the Alea I as a device,
> > the second fixes an issue with the timeout on the first read.
> > 
> > Bob Ham (2):
> >   hwrng: chaoskey - Add support for Araneus Alea I USB RNG
> >   hwrng: chaoskey - Fix URB warning due to timeout on Alea
> > 
> >  drivers/usb/misc/Kconfig| 11 ++-
> >  drivers/usb/misc/chaoskey.c | 21 +++--
> >  2 files changed, 25 insertions(+), 7 deletions(-)
> 
> Both applied.  Thanks.

Ok, but usually drivers/usb/misc/ patches go through my tree :)

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

Re: [XHCI: Help needed] One hang issue when using XHCI host driver playing Video for Isochronous transfer

[Greg KH]

On Tue, Jun 07, 2016 at 06:30:56PM +0800, Tang Jianqiang wrote:
> Hi Mathias && Balbi and ALL,
>We hit one hang issue when using DWC3 XHCI host mode to play Video
> for Isochronous transfer.
>Both usb-audio module and XHCI driver output errors.
> Our kernel version is 3.18.x.

That is very old and obsolete, can you try to see if 4.6.1 still has
this same issue?

thanks,

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

Re: [PATCH] USB: core: fix missing include

[kbuild test robot]

Hi,

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.7-rc2 next-20160607]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ben-Dooks/USB-core-fix-missing-include-linux-usb-of-h/20160608-022844
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> drivers/usb/core/of.c:32:21: error: redefinition of 'usb_of_get_child_node'
struct device_node *usb_of_get_child_node(struct device_node *parent,
^
   In file included from drivers/usb/core/of.c:21:0:
   include/linux/usb/of.h:36:35: note: previous definition of 
'usb_of_get_child_node' was here
static inline struct device_node *usb_of_get_child_node
  ^

vim +/usb_of_get_child_node +32 drivers/usb/core/of.c

69bec725 Peter Chen 2016-02-19  26   * @portnum: the port number which device 
is connecting
69bec725 Peter Chen 2016-02-19  27   *
69bec725 Peter Chen 2016-02-19  28   * Find the node from device tree according 
to its port number.
69bec725 Peter Chen 2016-02-19  29   *
69bec725 Peter Chen 2016-02-19  30   * Return: On success, a pointer to the 
device node, %NULL on failure.
69bec725 Peter Chen 2016-02-19  31   */
69bec725 Peter Chen 2016-02-19 @32  struct device_node 
*usb_of_get_child_node(struct device_node *parent,
69bec725 Peter Chen 2016-02-19  33  int 
portnum)
69bec725 Peter Chen 2016-02-19  34  {
69bec725 Peter Chen 2016-02-19  35  struct device_node *node;

:: The code at line 32 was first introduced by commit
:: 69bec725985324e79b1c47ea287815ac4ddb0521 USB: core: let USB device know 
device node

:: TO: Peter Chen <peter.c...@freescale.com>
:: CC: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v6] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Mario Limonciello]

The RTL8153-AD supports a persistent system specific MAC address.
This means a device plugged into two different systems with host side
support will show different (but persistent) MAC addresses.

This information for the system's persistent MAC address is burned in when
the system HW is built and available under \_SB.AMAC in the DSDT at runtime.

This technology is currently implemented in the Dell TB15 and WD15 Type-C
docks.  More information is available here:
http://www.dell.com/support/article/us/en/04/SLN301147

Signed-off-by: Mario Limonciello 
---
Changes from v5:
 * Correct return value if hex2bin succesful but invalid ether addr

 drivers/net/usb/r8152.c | 76 +++--
 1 file changed, 74 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3f9f6ed..fc58669 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Information for net-next */
 #define NETNEXT_VERSION"08"
@@ -455,6 +456,11 @@
 /* SRAM_IMPEDANCE */
 #define RX_DRIVING_MASK0x6000
 
+/* MAC PASSTHRU */
+#define AD_MASK0xfee0
+#define EFUSE  0xcfdb
+#define PASS_THRU_MASK 0x1
+
 enum rtl_register_content {
_1000bps= 0x10,
_100bps = 0x08,
@@ -1030,6 +1036,65 @@ out1:
return ret;
 }
 
+/* Devices containing RTL8153-AD can support a persistent
+ * host system provided MAC address.
+ * Examples of this are Dell TB15 and Dell WD15 docks
+ */
+static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
+{
+   acpi_status status;
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object *obj;
+   int ret = -EINVAL;
+   u32 ocp_data;
+   unsigned char buf[6];
+
+   /* test for -AD variant of RTL8153 */
+   ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
+   if ((ocp_data & AD_MASK) != 0x1000)
+   return -ENODEV;
+
+   /* test for MAC address pass-through bit */
+   ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, EFUSE);
+   if ((ocp_data & PASS_THRU_MASK) != 1)
+   return -ENODEV;
+
+   /* returns _AUXMAC_#AABBCCDDEEFF# */
+   status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );
+   obj = (union acpi_object *)buffer.pointer;
+   if (!ACPI_SUCCESS(status))
+   return -ENODEV;
+   if (obj->type != ACPI_TYPE_BUFFER || obj->string.length != 0x17) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid buffer when reading pass-thru MAC addr: "
+  "(%d, %d)\n",
+  obj->type, obj->string.length);
+   goto amacout;
+   }
+   if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0 ||
+   strncmp(obj->string.pointer + 0x15, "#", 1) != 0) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid header when reading pass-thru MAC addr\n");
+   goto amacout;
+   }
+   ret = hex2bin(buf, obj->string.pointer + 9, 6);
+   if (!(ret == 0 && is_valid_ether_addr(buf))) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid MAC when reading pass-thru MAC addr: "
+  "%d, %pM\n", ret, buf);
+   ret = -EINVAL;
+   goto amacout;
+   }
+   memcpy(sa->sa_data, buf, 6);
+   ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
+   netif_info(tp, probe, tp->netdev,
+  "Using pass-thru MAC addr %pM\n", sa->sa_data);
+
+amacout:
+   kfree(obj);
+   return ret;
+}
+
 static int set_ethernet_addr(struct r8152 *tp)
 {
struct net_device *dev = tp->netdev;
@@ -1038,8 +1103,15 @@ static int set_ethernet_addr(struct r8152 *tp)
 
if (tp->version == RTL_VER_01)
ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
-   else
-   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
+   else {
+   /* if this is not an RTL8153-AD, no eFuse mac pass thru set,
+* or system doesn't provide valid _SB.AMAC this will be
+* be expected to non-zero
+*/
+   ret = vendor_mac_passthru_addr_read(tp, );
+   if (ret < 0)
+   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
+   }
 
if (ret < 0) {
netif_err(tp, probe, dev, "Get ether addr fail\n");
-- 
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] USB: core: fix missing include

[Ben Dooks]

The helper function usb_of_get_child_node() is defined in the
header  but this was not included. Fix the warning
about usb_of_get_child_node() not being declared by adding the
right include. Fixes:

drivers/usb/core/of.c:31:20: warning: symbol 'usb_of_get_child_node' was not 
declared. Should it be static?

Signed-off-by: Ben Dooks 
---
Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: Philipp Zabel 
Cc: Alan Stern 
Cc: Peter Chen 
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
 drivers/usb/core/of.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index 2289700..3de4f88 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 
 /**
  * usb_of_get_child_node - Find the device node match port number
-- 
2.8.1

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

Re: [PATCH v5] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Pali Rohár]

Hi! Another problem which I found now:

On Tuesday 07 June 2016 10:33:47 Mario Limonciello wrote:
> + ret = hex2bin(buf, obj->string.pointer + 9, 6);
> + if (!(ret == 0 && is_valid_ether_addr(buf))) {
> + netif_warn(tp, probe, tp->netdev,
> +"Invalid MAC when reading pass-thru MAC addr: "
> +"%pM\n",
> +buf);
> + goto amacout;
> + }

In case when hex2bin returns zero, but is_valid_ether_addr returns
false, this function returns also zero. And thats wrong, because error
occur.

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

Re: [PATCH] USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails

[Alan Stern]

On Tue, 7 Jun 2016, Michał Pecio wrote:

> > Greg, in principle this should go to -stable.  However, it looks like 
> > this might break some applications that currently sort-of work, even 
> > though they shouldn't.  Therefore we have decided not to mark this 
> > patch for -stable at present.
> 
> This means leaving three longterm branches with a known panic trigger.
> 
> Maybe an explicit check for NULL and LIST_POISON would be a cheap way to
> kill the bug and have it too. These two are the only wrong values those
> pointers can ever get.

If the list pointer contains LIST_POISON then it's already too late; 
we've been accessing memory that was deallocated.  (This shouldn't 
happen, though, because the ED structures are allocated from a coherent 
DMA pool.)

They could contain a different value, though -- stale pointers from an
earlier time when they _were_ on the list.  The best way to protect
against this is to call INIT_LIST_HEAD in ed_alloc() and
list_del_init() in finish_unlinks().  Then you don't even have to check
for invalid values.

And such a patch could be accepted for the mainline kernel, because it 
wouldn't hurt anything.  That will make it easier for the fix to get 
into the -stable kernels.

Alan Stern

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

Re: USB broken on Banana Pi in Linux 4.6

[Greg KH]

On Tue, Jun 07, 2016 at 07:06:00PM +0200, Marc Haber wrote:
> On Fri, Jun 03, 2016 at 08:35:11AM -0700, Greg KH wrote:
> > On Fri, Jun 03, 2016 at 08:53:58AM +0200, Marc Haber wrote:
> > > On Mon, May 30, 2016 at 01:47:12PM -0700, Greg KH wrote:
> > > > On Mon, May 30, 2016 at 09:02:54PM +0200, Marc Haber wrote:
> > > > > Hi,
> > > > > 
> > > > > on my Bananapis, in kernel 4.6 USB does not work. Kernel configuration
> > > > > is USB-wise identical to 4.5 (grepped for differences in (hci|usb)),
> > > > > and in 4.6 there is not even /dev/bus/usb.
> > > > > 
> > > > > In kernel 4.6, the message "ohci-platform: OHCI generic platform
> > > > > driver" is the last one, and "ehci-platform 1c14000.usb: EHCI Host
> > > > > Controller" is the first one that is missing.
> > > > > 
> > > > > Is this already a known issue? Or, does a 4.6 kernel need to be
> > > > > configured differently if you want USB?
> > > > 
> > > > Are you sure you configured in the correct host controller that you
> > > > want?  Have you done a diff of your .config files to see what you
> > > > changed?  How did you create your 4.6 config?
> > > 
> > > I used make oldconfig, and I diffed the configs for (hci|usb), and
> > > there is no difference.
> > 
> > There might be other things than HCI|USB that are the issue here...
> 
> Full config diff attached. Hints are appreciated.

Nothing obvious, can you use 'git bisect' to go from 4.5.0 to 4.6.0 to
find the offending commit?

thanks,

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

Re: [PATCH v3 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Guenter Roeck]

On Tue, Jun 07, 2016 at 04:12:29PM +0200, Heiko Stübner wrote:
> Hi Guenter,
> 
> Am Dienstag, 7. Juni 2016, 06:19:45 schrieb Guenter Roeck:
> > On Tue, Jun 7, 2016 at 2:54 AM, Heiko Stübner  wrote:
> > > Hi Frank,
> > > 
> > > Am Montag, 6. Juni 2016, 17:20:04 schrieb Frank Wang:
> > >> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> > >> than rk3288 and before, and most of phy-related registers are also
> > >> different from the past, so a new phy driver is required necessarily.
> > >> 
> > >> Signed-off-by: Frank Wang 
> > >> ---
> > > 
> > > [...]
> > > 
> > >> +static int rockchip_usb2phy_probe(struct platform_device *pdev)
> > >> +{
> > >> + struct device *dev = >dev;
> > >> + struct device_node *np = dev->of_node;
> > >> + struct device_node *child_np;
> > >> + struct phy_provider *provider;
> > >> + struct rockchip_usb2phy *rphy;
> > >> + const struct of_device_id *match;
> > >> + int index, ret;
> > >> +
> > >> + rphy = devm_kzalloc(dev, sizeof(*rphy), GFP_KERNEL);
> > >> + if (!rphy)
> > >> + return -ENOMEM;
> > >> +
> > >> + match = of_match_device(dev->driver->of_match_table, dev);
> > >> + if (!match || !match->data) {
> > >> + dev_err(dev, "phy configs are not assigned!\n");
> > >> + return -EINVAL;
> > >> + }
> > >> +
> > >> + if (!dev->parent || !dev->parent->of_node)
> > >> + return -EINVAL;
> > >> +
> > >> + rphy->grf = syscon_node_to_regmap(dev->parent->of_node);
> > >> + if (IS_ERR(rphy->grf))
> > >> + return PTR_ERR(rphy->grf);
> > >> +
> > >> + rphy->dev = dev;
> > >> + rphy->phy_cfg = match->data;
> > >> + platform_set_drvdata(pdev, rphy);
> > >> +
> > >> + ret = rockchip_usb2phy_clk480m_register(rphy);
> > >> + if (ret) {
> > >> + dev_err(dev, "failed to register 480m output clock\n");
> > >> + return ret;
> > >> + }
> > >> +
> > >> + rphy->vbus_host = devm_regulator_get_optional(dev, "vbus_host");
> > >> + if (IS_ERR(rphy->vbus_host)) {
> > >> + ret = PTR_ERR(rphy->vbus_host);
> > >> + if (ret == -EPROBE_DEFER)
> > >> + return ret;
> > >> +
> > >> + dev_info(dev, "vbus_host regulator is not assigned!\n");
> > >> + rphy->vbus_host = NULL;
> > >> + } else {
> > >> + ret = regulator_enable(rphy->vbus_host);
> > >> + if (ret)
> > >> + return ret;
> > >> + }
> > >> +
> > >> + index = 0;
> > >> + for_each_available_child_of_node(np, child_np) {
> > >> + struct rockchip_usb2phy_port *rport = >ports[index];
> > >> + struct phy *phy;
> > >> +
> > >> + phy = devm_phy_create(dev, child_np,
> > >> _usb2phy_ops);
> > >> + if (IS_ERR(phy)) {
> > >> + dev_err(dev, "failed to create phy\n");
> > >> + ret = PTR_ERR(phy);
> > >> + goto put_child;
> > >> + }
> > >> +
> > >> + rport->phy = phy;
> > >> +
> > >> + /* initialize otg/host port separately */
> > >> + if (!of_node_cmp(child_np->name, "host-port")) {
> > >> + ret = rockchip_usb2phy_host_port_init(rphy, rport,
> > >> +   child_np);
> > >> + if (ret)
> > >> + goto put_child;
> > >> + }
> > >> +
> > >> + phy_set_drvdata(rport->phy, rport);
> > >> +
> > >> + /* to prevent out of boundary */
> > >> + if (++index >= rphy->phy_cfg->num_ports)
> > >> + break;
> > >> + }
> > >> +
> > >> + provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> > >> + return PTR_ERR_OR_ZERO(provider);
> > >> +
> > >> +put_child:
> > >> + of_node_put(child_np);
> > >> + return ret;
> > >> +}
> > >> +
> > >> +static const struct rockchip_usb2phy_cfg rk3366_phy_cfgs = {
> > >> + .num_ports  = 2,
> > >> + .clkout_ctl = { 0x0724, 15, 15, 1, 0 },
> > >> + .port_cfgs  = {
> > >> + [USB2PHY_PORT_HOST] = {
> > >> + .phy_sus= { 0x0728, 15, 0, 0, 0x1d1 },
> > >> + .ls_det_en  = { 0x0680, 4, 4, 0, 1 },
> > >> + .ls_det_st  = { 0x0690, 4, 4, 0, 1 },
> > >> + .ls_det_clr = { 0x06a0, 4, 4, 0, 1 },
> > >> + .utmi_ls= { 0x049c, 14, 13, 0, 1 },
> > >> + .utmi_hstdet= { 0x049c, 12, 12, 0, 1 }
> > >> + }
> > >> + },
> > >> +};
> > > 
> > > I also realized that the rk3399 has two of those phy-blocks, so I think
> > > we'll need to adapt your data storage mechanism a tiny bit. Maybe
> > > something like the following:
> > > 
> > > In the dts:
> > > 
> > 

Re: USB broken on Banana Pi in Linux 4.6

[Marc Haber]

On Fri, Jun 03, 2016 at 08:35:11AM -0700, Greg KH wrote:
> On Fri, Jun 03, 2016 at 08:53:58AM +0200, Marc Haber wrote:
> > On Mon, May 30, 2016 at 01:47:12PM -0700, Greg KH wrote:
> > > On Mon, May 30, 2016 at 09:02:54PM +0200, Marc Haber wrote:
> > > > Hi,
> > > > 
> > > > on my Bananapis, in kernel 4.6 USB does not work. Kernel configuration
> > > > is USB-wise identical to 4.5 (grepped for differences in (hci|usb)),
> > > > and in 4.6 there is not even /dev/bus/usb.
> > > > 
> > > > In kernel 4.6, the message "ohci-platform: OHCI generic platform
> > > > driver" is the last one, and "ehci-platform 1c14000.usb: EHCI Host
> > > > Controller" is the first one that is missing.
> > > > 
> > > > Is this already a known issue? Or, does a 4.6 kernel need to be
> > > > configured differently if you want USB?
> > > 
> > > Are you sure you configured in the correct host controller that you
> > > want?  Have you done a diff of your .config files to see what you
> > > changed?  How did you create your 4.6 config?
> > 
> > I used make oldconfig, and I diffed the configs for (hci|usb), and
> > there is no difference.
> 
> There might be other things than HCI|USB that are the issue here...

Full config diff attached. Hints are appreciated.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--- /boot/config-4.5.4-zgbpi-armmp-lpae 2016-05-13 17:02:25.0 +0200
+++ /boot/config-4.6.0-zgbpi-armmp-lpae 2016-05-16 14:18:06.0 +0200
@@ -3 +3 @@
-# Linux/arm 4.5.4 Kernel Configuration
+# Linux/arm 4.6.0 Kernel Configuration
@@ -173,0 +174,2 @@
+# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
+CONFIG_KALLSYMS_BASE_RELATIVE=y
@@ -183 +185 @@
-# CONFIG_BPF_SYSCALL is not set
+CONFIG_BPF_SYSCALL=y
@@ -368,0 +371 @@
+# CONFIG_ARCH_ARTPEC is not set
@@ -463 +466,2 @@
-# CONFIG_ARM_KERNMEM_PERMS is not set
+CONFIG_DEBUG_RODATA=y
+CONFIG_DEBUG_ALIGN_RODATA=y
@@ -712 +715,0 @@
-CONFIG_INET_LRO=m
@@ -1126 +1128,0 @@
-CONFIG_NETLINK_MMAP=y
@@ -1167,0 +1170 @@
+# CONFIG_BT_LEDS is not set
@@ -1181,0 +1185 @@
+CONFIG_AF_KCM=m
@@ -1207,0 +1212,3 @@
+CONFIG_DST_CACHE=y
+CONFIG_NET_DEVLINK=m
+CONFIG_MAY_USE_DEVLINK=m
@@ -1234 +1241 @@
-CONFIG_REGMAP_SPI=m
+CONFIG_REGMAP_SPI=y
@@ -1236 +1242,0 @@
-CONFIG_REGMAP_IRQ=y
@@ -1246 +1252 @@
-# CONFIG_ARM_CCI500_PMU is not set
+# CONFIG_ARM_CCI5xx_PMU is not set
@@ -1407,0 +1414 @@
+# CONFIG_PANEL is not set
@@ -1440,0 +1448,4 @@
+# VOP Bus Driver
+#
+
+#
@@ -1454,0 +1466,4 @@
+
+#
+# VOP Driver
+#
@@ -1575,0 +1591 @@
+# CONFIG_MACSEC is not set
@@ -1816,0 +1833 @@
+# CONFIG_TOUCHSCREEN_MELFAS_MIP4 is not set
@@ -1829 +1845,0 @@
-# CONFIG_TOUCHSCREEN_TS4800 is not set
@@ -1856 +1871,0 @@
-# CONFIG_INPUT_AXP20X_PEK is not set
@@ -1869,0 +1885 @@
+# CONFIG_RMI4_CORE is not set
@@ -1922 +1937,0 @@
-# CONFIG_SERIAL_8250_INGENIC is not set
@@ -1951,0 +1967 @@
+# CONFIG_SERIAL_MVEBU_UART is not set
@@ -1981,0 +1998 @@
+# CONFIG_I2C_DEMUX_PINCTRL is not set
@@ -2031,0 +2049 @@
+# CONFIG_SPI_AXI_SPI_ENGINE is not set
@@ -2034,0 +2053 @@
+# CONFIG_SPI_DESIGNWARE is not set
@@ -2048 +2066,0 @@
-# CONFIG_SPI_DESIGNWARE is not set
@@ -2097 +2115 @@
-CONFIG_PINCTRL_SUNXI_COMMON=y
+CONFIG_PINCTRL_SUNXI=y
@@ -2109,0 +2128 @@
+CONFIG_PINCTRL_SUN8I_H3_R=y
@@ -2131,0 +2151 @@
+# CONFIG_GPIO_MPC8XXX is not set
@@ -2147,0 +2168 @@
+# CONFIG_GPIO_TPIC2810 is not set
@@ -2159,0 +2181 @@
+# CONFIG_GPIO_PISOSR is not set
@@ -2195 +2216,0 @@
-CONFIG_AXP20X_POWER=y
@@ -2246,0 +2268 @@
+# CONFIG_SENSORS_LTC2990 is not set
@@ -2364 +2385,0 @@
-# CONFIG_TS4800_WATCHDOG is not set
@@ -2366 +2386,0 @@
-# CONFIG_BCM7038_WDT is not set
@@ -2389,0 +2410 @@
+# CONFIG_MFD_ACT8945A is not set
@@ -2397 +2418,2 @@
-CONFIG_MFD_AXP20X=y
+# CONFIG_MFD_AXP20X_I2C is not set
+# CONFIG_MFD_AXP20X_RSB is not set
@@ -2454,0 +2477 @@
+# CONFIG_MFD_TPS65086 is not set
@@ -2460 +2482,0 @@
-# CONFIG_MFD_TPS65912 is not set
@@ -2491 +2512,0 @@
-# CONFIG_REGULATOR_AXP20X is not set
@@ -2566,0 +2588,5 @@
+# ACP (Audio CoProcessor) Configuration
+#
+# CONFIG_DRM_AMD_ACP is not set
+
+#
@@ -2636,0 +2663 @@
+CONFIG_SND_JACK_INPUT_DEV=y
@@ -2702,0 +2730 @@
+# CONFIG_SND_SUN4I_SPDIF is not set
@@ -2732 +2760,2 @@
-# CONFIG_SND_SOC_PCM179X is not set
+# CONFIG_SND_SOC_PCM179X_I2C is not set
+# CONFIG_SND_SOC_PCM179X_SPI is not set
@@ -2736,0 +2766 @@
+# CONFIG_SND_SOC_RT5616 is not set
@@ -2801,0 +2832 @@
+# CONFIG_HID_CMEDIA is not set
@@ -3153,0 +3185 @@
+# CONFIG_LEDS_IS31FL32XX is not set
@@ -3208 +3239,0 @@
-# CONFIG_RTC_DRV_DS3232 is not set
@@ -3216 +3246,0 @@
-# CONFIG_RTC_DRV_PCF2127 is not set
@@ -3218 +3247,0 @@
-# CONFIG_RTC_DRV_PCF8563 is not set
@@ -3219,0 +3249 @@
+# CONFIG_RTC_DRV_PCF8563 is not set
@@ -3242 +3271,0 @@
-# CONFIG_RTC_DRV_MAX6902 is not set
@@ 

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

[Guenter Roeck]

On Mon, Jun 06, 2016 at 04:28:08PM +0300, Heikki Krogerus wrote:
[ ... ]
> 
> I would prefer lower case letters. I don't know the SIDs there are at
> them moment, other then Display Port. Do you know them?
> 
SIDs:
0xff00 - power delivery
0xff01 - displayport
0xff02 - MHL
0xff03 - Thunderbolt 3 (if I recall correctly)

VIDs: Can obviously be anything. I have seen
0x05ac - Apple
0x18d1 - Google

> I don't think we can ever guarantee that in every case we will be able
> to provide a human readable name for the alternate modes if they are
> vendor defined. We will then potentially still have the names in two
> different forms: "usbc0.displayport" and "usbc0.svid:". Is that
> something acceptable to everybody?
> 
> I guess if it's not, then to only way to go forward would be to always
> just use the svid in the name.
> 
I think we should just use the svid.

> > > > Also, do we at some point need to standardize the ABI for the standard
> > > > alternate modes such as DisplayPort (if there are any - again I am not
> > > > there yet) ?
> > > 
> > > I don't have an answer to that.
> > > 
> > Ok, I'll look into it as I proceed with my implementation.
> > 
> > > > 
> > > > Sounds good to me. Many other subsystems do the same, ie create the 
> > > > subsystem
> > > > device(s) during registration with the subsystem, so this is in line 
> > > > with other
> > > > kernel code.
> > > > 
> > > > Should I send you a follow-up patch on top of yours ?
> > > 
> > > Sure. I'm a little bit stuck with an other tasks, so let's keep this
> > > thing rolling.
> > > 
> > See below.
> 
> Thanks. I pushed it to my work branch for this class:
> 
> https://github.com/krohei/linux/commits/typec_class
> 
> There are still a few open questions, but I'm in any case going to
> start polishing the driver. I think the other attributes are more or
> less decided, excluding the alternate modes.
> 
Sounds good.

Thanks,
Guenter
--
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: OHCI: Don't mark EDs as ED_OPER if scheduling fails

[Michał Pecio]

> Greg, in principle this should go to -stable.  However, it looks like 
> this might break some applications that currently sort-of work, even 
> though they shouldn't.  Therefore we have decided not to mark this 
> patch for -stable at present.

This means leaving three longterm branches with a known panic trigger.

Maybe an explicit check for NULL and LIST_POISON would be a cheap way to
kill the bug and have it too. These two are the only wrong values those
pointers can ever get.

Regards,
MP
--
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] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Mario Limonciello]

The RTL8153-AD supports a persistent system specific MAC address.
This means a device plugged into two different systems with host side
support will show different (but persistent) MAC addresses.

This information for the system's persistent MAC address is burned in when
the system HW is built and available under \_SB.AMAC in the DSDT at runtime.

This technology is currently implemented in the Dell TB15 and WD15 Type-C
docks.  More information is available here:
http://www.dell.com/support/article/us/en/04/SLN301147

Signed-off-by: Mario Limonciello 
---
Changes from v4:
 * Correct style for all of Pali's comments
 * Add extra check for trailing # in ACPI request
 * Correct logic test for invalid MAC address to cover hex2bin ret 0,
   but valid_is_ether being invalid

 drivers/net/usb/r8152.c | 77 +++--
 1 file changed, 75 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3f9f6ed..5a04c59 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Information for net-next */
 #define NETNEXT_VERSION"08"
@@ -455,6 +456,11 @@
 /* SRAM_IMPEDANCE */
 #define RX_DRIVING_MASK0x6000
 
+/* MAC PASSTHRU */
+#define AD_MASK0xfee0
+#define EFUSE  0xcfdb
+#define PASS_THRU_MASK 0x1
+
 enum rtl_register_content {
_1000bps= 0x10,
_100bps = 0x08,
@@ -1030,6 +1036,66 @@ out1:
return ret;
 }
 
+/* Devices containing RTL8153-AD can support a persistent
+ * host system provided MAC address.
+ * Examples of this are Dell TB15 and Dell WD15 docks
+ */
+static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
+{
+   acpi_status status;
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object *obj;
+   int ret = -EINVAL;
+   u32 ocp_data;
+   unsigned char buf[6];
+
+   /* test for -AD variant of RTL8153 */
+   ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
+   if ((ocp_data & AD_MASK) != 0x1000)
+   return -ENODEV;
+
+   /* test for MAC address pass-through bit */
+   ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, EFUSE);
+   if ((ocp_data & PASS_THRU_MASK) != 1)
+   return -ENODEV;
+
+   /* returns _AUXMAC_#AABBCCDDEEFF# */
+   status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );
+   obj = (union acpi_object *)buffer.pointer;
+   if (!ACPI_SUCCESS(status))
+   return -ENODEV;
+   if (obj->type != ACPI_TYPE_BUFFER || obj->string.length != 0x17) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid buffer when reading pass-thru MAC addr: "
+  "(%d, %d)\n",
+  obj->type, obj->string.length);
+   goto amacout;
+   }
+   if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0 ||
+   strncmp(obj->string.pointer + 0x15, "#", 1) != 0) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid header when reading pass-thru MAC addr\n");
+   goto amacout;
+   }
+   ret = hex2bin(buf, obj->string.pointer + 9, 6);
+   if (!(ret == 0 && is_valid_ether_addr(buf))) {
+   netif_warn(tp, probe, tp->netdev,
+  "Invalid MAC when reading pass-thru MAC addr: "
+  "%pM\n",
+  buf);
+   goto amacout;
+   }
+   memcpy(sa->sa_data, buf, 6);
+   ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
+   netif_info(tp, probe, tp->netdev,
+  "Using pass-thru MAC addr %pM\n", sa->sa_data);
+   ret = 0;
+
+amacout:
+   kfree(obj);
+   return ret;
+}
+
 static int set_ethernet_addr(struct r8152 *tp)
 {
struct net_device *dev = tp->netdev;
@@ -1038,8 +1104,15 @@ static int set_ethernet_addr(struct r8152 *tp)
 
if (tp->version == RTL_VER_01)
ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
-   else
-   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
+   else {
+   /* if this is not an RTL8153-AD, no eFuse mac pass thru set,
+* or system doesn't provide valid _SB.AMAC this will be
+* be expected to non-zero
+*/
+   ret = vendor_mac_passthru_addr_read(tp, );
+   if (ret < 0)
+   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
+   }
 
if (ret < 0) {
netif_err(tp, probe, dev, "Get ether addr fail\n");
-- 
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

Re: Race condition in usbfs / libusb when using reap-after-disconnect

[Alan Stern]

On Tue, 7 Jun 2016, Hans de Goede wrote:

> Hi,
> 
> On 06-06-16 19:03, Alan Stern wrote:
> > On Mon, 6 Jun 2016, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> On 06-06-16 16:48, Greg Kroah-Hartman wrote:
> >>> On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote:
>  Hi All,
> 
>  While looking at libusb today I ended up looking at the
>  reap-after-disconnect code.
> 
>  What stands out is that libusb expects to be able to
>  reap all outstanding urbs on a device on receiving
>  a POLL_ERR status from poll (on supported kernels).
> 
>  But the usbfs poll implementation will return POLL_ERR
>  as soon as ps->dev->state == USB_STATE_NOTATTACHED,
>  and the kernel usb code sets state = USB_STATE_NOTATTACHED
>  some time before usbdev_remove() gets called and moves
>  all pending urbs to the async_completed list.
> >
> > This means that URBs can't be reaped immediately.  But it will be
> > possible to reap them shortly after libusb gets the POLLERR status,
> > once the khubd work routine has processed the disconnection.
> 
> Ack.
> 
>  So if libusb ends up calling poll between the
>  setting state = USB_STATE_NOTATTACHED and usbdev_remove()
>  being called then it ends up not reaping all urbs
>  since it will stop monitoring the device after
>  the first POLL_ERR.
> 
>  I'll write a libusb fix for this, but I'm wondering if this
>  is something which we also want to fix on the kernel side?
> >
> > We could.  Would it be worthwhile to do so?
> 
> That is exactly the question this mail thread is intended to answer :)
> 
> >>> Would fixing this in the kernel mean that libusb fixes are not needed?
> >>> If so, I would recommend doing this.
> >>
> >> A kernel side fix is non trivial, whereas the libusb fix is trivial
> >> since we also need to deal with kernels which do not support
> >> reaping urbs after disconnect at all.
> >>
> >> Basically the question is, do we consider not being able to
> >> reap all urbs after the first POLL_ERR a kernel bug, or should
> >> userspace keep track of how many urbs it has outstanding and
> >> call the reap ioctl (with some msleep after failure) until it
> >> has reaped all urbs ?
> >
> > We already have POLLOUT to indicate when a completed URB is available
> > for reaping.  Can libusb use that?
> 
> libusb already use that normally, but on a POLLERR it will remove
> the fd from the pollfds since POLLERR will stay set once set, so
> leaving it in pollfds means we will just set there busy-waiting.
> 
> > Strictly speaking, POLLERR just indicates an error condition, of any
> > kind.
> 
> Ack, but the current semantics for how this works with usbfs are
> somewhat sub-optimal from a libusb pov. The fix for this is easy
> since libusb already has code in place to deal with older kernels
> which do not support REAP after disconnect at all and I plan to
> use that (rather then wait if we hit the race), but it does
> make the whole REAP after disconnect function a whole lot
> less useful.

You also will have to handle kernels like the current one, that do
support reap after disconnect but return POLLERR before the URBs are
cancelled.  Given that, how useful would changing the kernel be?

We could alter usbdev_poll so that it returns POLLERR only after
usbdev_remove has been called (say, only when ps->list is empty,
ignoring ps->dev->state).  That would be easy to do, like in the patch
below.  What do you think?

Alan Stern



Index: usb-4.x/drivers/usb/core/devio.c
===
--- usb-4.x.orig/drivers/usb/core/devio.c
+++ usb-4.x/drivers/usb/core/devio.c
@@ -2580,8 +2580,10 @@ static unsigned int usbdev_poll(struct f
poll_wait(file, >wait, wait);
if (file->f_mode & FMODE_WRITE && !list_empty(>async_completed))
mask |= POLLOUT | POLLWRNORM;
-   if (!connected(ps))
-   mask |= POLLERR | POLLHUP;
+   if (list_empty(>list))
+   mask |= POLLERR;
+   else if (!connected(ps))
+   mask |= POLLHUP;
return mask;
 }
 

--
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 v10 2/7] usb: mux: add generic code for dual role port mux

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> I might be able to find some time to implement a proof of concept which
>> would allow your platforms to get dual-role with code we already have,
>> but I need DWC3's OTG support which, I'm assuming, you already have :-)
>> 
>> If you wanna try something offline, just ping me ;-) I'll be happy to
>> help.
>
> What you are proposing is a dwc3 only solution. With the otg/dual-role
> series we are trying to be generic as much as possible.

Well, if there is a need for that, sure. Take MUSB for instance. It
makes use of nothing of the sorts, because it doesn't have to.

> Whether controller drivers want to use it or not is upto the driver
> maintainers but we should at least ensure that user space ABI if any,
> is consistent across different implementations.

Role decisions should not be exposed to userspace unless as debug
feature (using e.g. DebugFS). That should be done either by the HW or
within the kernel.

If we're discussing userspace ABI here, there's something very wrong
with OTG/DRD layer design.

>>> How are you switching the port mux between host and peripheral? Only
>>> by sysfs or do you have a GPIO for ID pin as well?
>> 
>> depends. Some SoCs have GPIO-controller muxes while some just have mux's
>> select signals (one for ID, one for VBUS) mapped on xHCI's address
>> space.
>> 
>>> What happens to the gadget controller when the port is muxed to the
>>> host controller?  Is it stopped or it continues to run?
>> 
>> it continues running, but that's pretty irrelevant for Intel's dual-role
>
> Isn't that unnecessary waste of power? Or you have firmware assisted
> low power mode?

that's an implementation detail which brings nothing to this discussion,
right? :-)

We can, certainly, put the other side to D3.

>> setup. We have an actual physical (inside the die, though) mux which
>> muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only
>> DWC3.
>> 
>
> Probably irrelevant for Intel's dual-role but many platforms that
> share the port can't have device controller running when port is in
> host mode and vice versa.

but that doesn't mean we need an entire new layer added to the kernel
;-)

DWC3 already gives us all the information necessary to make a decision
on which role we should assume. Just consider your options. Here's how
things would look like without any OTG/DRD layer:

-> DWC3 OTG IRQ
 -> readl(OSTS);
  -> if (OSTS & BIT(4))
   -> dwc3_host_exit(); __dwc3_gadget_start();
  -> else
   -> __dwc3_gadget_stop(); dwc3_host_init();

Can you draw something similar for your proposed OTG/DRD layer?

I remember there were at least two schedule_work(). IIRC it looked
something like below:

-> DWC3 OTG IRQ
 -> readl(OSTS);
  -> if (OSTS & BIT(4))
   -> otg_set_mode(PERIPHERAL);
-> schedule_work();
 -> otg_ops->stop_host();
  -> usb_del_hcd();
 -> otg_ops->start_peripheral();
  -> usb_gadget_add_udc();
  -> else
   -> otg_set_mode(HOST);
-> schedule_work();
 -> otg_ops->stop_peripheral();
  -> usb_gadget_del_udc();
 -> otg_ops->start_host();
  -> usb_add_hcd();

I'm probably missing some steps there.

> So there has to be a central point of control where the respective
> controllers are started/stopped.

some implementations might need this, yes. DWC3 and MUSB don't seem to
be this type of system.

> That is the other point we are trying to address with the common
> otg/dual-role code.
>
> Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we need
> to stop the host controller for device mode, right?

yes, see above. We already have that code.

> If so then who will deal with start/stop of the controllers then?

dwc3 itself.

-- 
balbi


signature.asc
Description: PGP signature

RE: Re: Re: Re: [PATCH] usb: core: fix a double free in the usb driver

[Alan Stern]

On Tue, 7 Jun 2016, Chung-Geol Kim wrote:

> =
>  At *remove USB(3.0) Storage 
>  sequence <1> --> <5> ((Problem Case))
> =
>   VOLD
> |
>  (uevent)
> |_
>|<1>   |
>|dwc3_otg_sm_work  |
>|usb_put_hcd   |
>|shared_hcd(kref=2)|
>|__|
> |_ 
>|<2>   |
>|New USB BUS #2|
>|  |
>|shared_hcd(kref=1)|
>|  |
>  --(Link)-bandXX_mutex|
>  | |__|
>  | 
> ___  |
>|<3>| |
>|dwc3_otg_sm_work   | |
>|usb_put_hcd| |
>|primary_hcd(kref=1)| |
>|___| |
> _|_  |
>|<4>| |
>|New USB BUS #1 | |
>|hcd_release| |
>|primary_hcd(kref=0)| |
>|   | |
>|bandXX_mutex(free) |<-
>|___| 
>(( VOLD ))
> __|___
>|<5>   |
>|  SCSI|
>|usb_put_hcd   |
>|shared_hcd(kref=0)|
>|*hcd_release  |
>|bandXX_mutex(free*)|<- double free
>|__|
> 
> =

Okay, now I understand the problem you want to solve.  What we need to
do is make sure the mutex is deallocated when the _last_ hcd is
released, which is not necessarily the same as when the _primary_ hcd
is released.

Can you please test the patch below?

By the way, a good change (if you want to do it) would be to rename the
"shared_hcd" field to "other_hcd" or "peer_hcd".  This is because it
always points to the other hcd in the peer set: In the primary
structure it points to the secondary, and in the secondary structure it
points to the primary.

Alan Stern



Index: usb-4.x/drivers/usb/core/hcd.c
===
--- usb-4.x.orig/drivers/usb/core/hcd.c
+++ usb-4.x/drivers/usb/core/hcd.c
@@ -2588,24 +2588,22 @@ EXPORT_SYMBOL_GPL(usb_create_hcd);
  * Don't deallocate the bandwidth_mutex until the last shared usb_hcd is
  * deallocated.
  *
- * Make sure to only deallocate the bandwidth_mutex when the primary HCD is
- * freed.  When hcd_release() is called for either hcd in a peer set
- * invalidate the peer's ->shared_hcd and ->primary_hcd pointers to
- * block new peering attempts
+ * Make sure to deallocate the bandwidth_mutex only when the last HCD is
+ * freed.  When hcd_release() is called for either hcd in a peer set,
+ * invalidate the peer's ->shared_hcd and ->primary_hcd pointers.
  */
 static void hcd_release(struct kref *kref)
 {
struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref);
 
mutex_lock(_port_peer_mutex);
-   if (usb_hcd_is_primary_hcd(hcd))
-   kfree(hcd->bandwidth_mutex);
if (hcd->shared_hcd) {
struct usb_hcd *peer = hcd->shared_hcd;
 
peer->shared_hcd = NULL;
-   if (peer->primary_hcd == hcd)
-   peer->primary_hcd = NULL;
+   peer->primary_hcd = NULL;
+   } else {
+   kfree(hcd->bandwidth_mutex);
}
mutex_unlock(_port_peer_mutex);
kfree(hcd);

--
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: http://www.linux-usb.org/gadget/usb.c exambple problem.

[Alan Stern]

On Tue, 7 Jun 2016, Brian Park wrote:

> Hi,
> I need help with getting http://www.linux-usb.org/gadget/usb.c
> working on my Beagle Bone Black based embedded board. I'm using TI
> Processor SDK 2.00.02.11 with their linux kernel
> linux-4.1.18+gitAUTOINC+bbe8cfc1da-gbbe8cfc. My application is based
> on the usb.c example and it worked OK with their SDK1. However, when
> I tried to port it to their SDK2, I ran into issues. TI engineer
> fixed some kernel issue and I no longer have kernel panic. But I'm
> still having trouble receiving data from the host.
> 
> TI engineer is suggesting that usb.c example may be out of data and I
> should ask help from this community. Could someone please help me?
> Here is the forum post that describes the problem.
> http://e2e.ti.com/support/arm/sitara_arm/f/791/t/513540

The up-to-date version of usb.c is now part of the kernel source:

tools/usb/usb.c

Alan Stern

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

Re: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection

[Alan Stern]

On Tue, 7 Jun 2016, Michał Pecio wrote:

> > That's clear enough.
> > 
> > ISO IN 1007 bytes -> 793 us
> > INT IN   32 bytes ->  35 us
> >  --
> >  825 us
> > 
> > The additional requirements are:
> > 
> > ISO IN  48 bytes  ->  45 us -> 870 us total
> > ISO IN 192 bytes  -> 158 us -> 983 us total
> 
> Or how about both, 1028 out of 1000 us total ;)
> 
> T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=12   MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=1130 ProdID=f211 Rev= 2.04
> S:  Product=USB  AUDIO  
> C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
> I:  If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
> I:* If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
> E:  Ad=01(O) Atr=09(Isoc) MxPS= 192 Ivl=1ms
> I:  If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
> I:* If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
> E:  Ad=83(I) Atr=09(Isoc) MxPS=  48 Ivl=1ms
> I:* If#= 3 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
> E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
> I:* If#= 4 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
> E:  Ad=84(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
> 
> T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  7 Spd=12   MxCh= 0
> D:  Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
> P:  Vendor=1110 ProdID=9031 Rev=20.0b
> S:  Product=ADSL-USB Modem
> S:  SerialNumber=00604C8D86AA
> C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=400mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=07 Prot=00 Driver=ueagle-atm
> E:  Ad=84(I) Atr=03(Int.) MxPS=  32 Ivl=1ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=02(O) Atr=03(Int.) MxPS=  64 Ivl=1ms
> I:  If#= 2 Alt= 0 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> I:  If#= 2 Alt= 1 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS= 159 Ivl=1ms
> I:  If#= 2 Alt= 2 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS= 265 Ivl=1ms
> I:  If#= 2 Alt= 3 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS= 424 Ivl=1ms
> I:  If#= 2 Alt= 4 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS= 530 Ivl=1ms
> I:  If#= 2 Alt= 5 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS= 636 Ivl=1ms
> I:  If#= 2 Alt= 6 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS= 795 Ivl=1ms
> I:  If#= 2 Alt= 7 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS= 901 Ivl=1ms
> I:* If#= 2 Alt= 8 #EPs= 1 Cls=0a(data ) Sub=00 Prot=00 Driver=ueagle-atm
> E:  Ad=88(I) Atr=01(Isoc) MxPS=1007 Ivl=1ms
> 
> T:  Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#=  2 Spd=1.5  MxCh= 0
> D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
> P:  Vendor=0461 ProdID=4ebc Rev= 1.04
> S:  Manufacturer=NOVATEK
> S:  Product=Classic USB Keyboard
> C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
> E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
> I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
> E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
> 
> size = 32
>  0 [354]: ed8/8800df655050 (ls dev2 ep1in-int qlen 1 max 8 00083082) 
> ed1/8800df655140 (fs dev7 ep4in-int qlen 1 max 32 00201207) 
> ed1/8800df6551e0 (fs dev7 ep8in-iso qlen 12 max 1007 03ef9407) 
> ed1/8800df655370 (fs dev8 ep1out-iso qlen 13 max 192 00c0) 
> ed1/8800df6553c0 (fs dev8 ep3in-iso qlen 12 max 48 00309188)
>  1 [354]: ed8/8800df6550a0 (ls dev2 ep2in-int qlen 1 max 8 00083102) 
> ed1/8800df655140
>  2 [253]: ed8/8800df655280 (fs dev8 ep2in-int qlen 1 max 8 00081108) 
> ed1/8800df655140
>  3 [253]: ed8/8800df655230 (fs dev8 ep4in-int qlen 1 max 8 00081208) 
> ed1/8800df655140
>  4 [237]: ed1/8800df655140
>  5 [237]: ed1/8800df655140
>  6 [237]: ed1/8800df655140
>  7 [237]: ed1/8800df655140
>  8 [354]: ed8/8800df655050
>  9 [354]: ed8/8800df6550a0
> 10 [253]: ed8/8800df655280
> 11 [253]: ed8/8800df655230
> 12 [237]: ed1/8800df655140
> 13 [237]: ed1/8800df655140
> 14 [237]: ed1/8800df655140
> 15 [237]: ed1/8800df655140
> 16 [354]: ed8/8800df655050
> 17 [354]: ed8/8800df6550a0
> 18 [253]: ed8/8800df655280
> 19 [253]: ed8/8800df655230
> 20 [237]: ed1/8800df655140
> 21 [237]: ed1/8800df655140
> 22 [237]: 

Re: [PATCH] USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails

[Alan Stern]

On Tue, 7 Jun 2016, Michał Pecio wrote:

> Since ed_schedule begins with marking the ED as "operational",
> the ED may be left in such state even if scheduling actually
> fails.
> 
> This allows future submission attempts to smuggle this ED to the
> hardware behind the scheduler's back and without linking it to
> the ohci->eds_in_use list.
> 
> The former causes bandwidth saturation and data loss on isoc
> endpoints, the latter crashes the kernel when attempt is made
> to unlink such ED from this list.
> 
> Fix ed_schedule to update ED state only on successful return.
> 
> Signed-off-by: Michal Pecio 
> ---
>  drivers/usb/host/ohci-q.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c
> index d029bbe..641fed6 100644
> --- a/drivers/usb/host/ohci-q.c
> +++ b/drivers/usb/host/ohci-q.c
> @@ -183,7 +183,6 @@ static int ed_schedule (struct ohci_hcd *ohci, struct ed 
> *ed)
>  {
>   int branch;
>  
> - ed->state = ED_OPER;
>   ed->ed_prev = NULL;
>   ed->ed_next = NULL;
>   ed->hwNextED = 0;
> @@ -259,6 +258,8 @@ static int ed_schedule (struct ohci_hcd *ohci, struct ed 
> *ed)
>   /* the HC may not see the schedule updates yet, but if it does
>* then they'll be properly ordered.
>*/
> +
> + ed->state = ED_OPER;
>   return 0;
>  }

Acked-by: Alan Stern 

Greg, in principle this should go to -stable.  However, it looks like 
this might break some applications that currently sort-of work, even 
though they shouldn't.  Therefore we have decided not to mark this 
patch for -stable at present.

Alan Stern

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

Re: [PATCH v3 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stübner]

Hi Guenter,

Am Dienstag, 7. Juni 2016, 06:19:45 schrieb Guenter Roeck:
> On Tue, Jun 7, 2016 at 2:54 AM, Heiko Stübner  wrote:
> > Hi Frank,
> > 
> > Am Montag, 6. Juni 2016, 17:20:04 schrieb Frank Wang:
> >> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> >> than rk3288 and before, and most of phy-related registers are also
> >> different from the past, so a new phy driver is required necessarily.
> >> 
> >> Signed-off-by: Frank Wang 
> >> ---
> > 
> > [...]
> > 
> >> +static int rockchip_usb2phy_probe(struct platform_device *pdev)
> >> +{
> >> + struct device *dev = >dev;
> >> + struct device_node *np = dev->of_node;
> >> + struct device_node *child_np;
> >> + struct phy_provider *provider;
> >> + struct rockchip_usb2phy *rphy;
> >> + const struct of_device_id *match;
> >> + int index, ret;
> >> +
> >> + rphy = devm_kzalloc(dev, sizeof(*rphy), GFP_KERNEL);
> >> + if (!rphy)
> >> + return -ENOMEM;
> >> +
> >> + match = of_match_device(dev->driver->of_match_table, dev);
> >> + if (!match || !match->data) {
> >> + dev_err(dev, "phy configs are not assigned!\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + if (!dev->parent || !dev->parent->of_node)
> >> + return -EINVAL;
> >> +
> >> + rphy->grf = syscon_node_to_regmap(dev->parent->of_node);
> >> + if (IS_ERR(rphy->grf))
> >> + return PTR_ERR(rphy->grf);
> >> +
> >> + rphy->dev = dev;
> >> + rphy->phy_cfg = match->data;
> >> + platform_set_drvdata(pdev, rphy);
> >> +
> >> + ret = rockchip_usb2phy_clk480m_register(rphy);
> >> + if (ret) {
> >> + dev_err(dev, "failed to register 480m output clock\n");
> >> + return ret;
> >> + }
> >> +
> >> + rphy->vbus_host = devm_regulator_get_optional(dev, "vbus_host");
> >> + if (IS_ERR(rphy->vbus_host)) {
> >> + ret = PTR_ERR(rphy->vbus_host);
> >> + if (ret == -EPROBE_DEFER)
> >> + return ret;
> >> +
> >> + dev_info(dev, "vbus_host regulator is not assigned!\n");
> >> + rphy->vbus_host = NULL;
> >> + } else {
> >> + ret = regulator_enable(rphy->vbus_host);
> >> + if (ret)
> >> + return ret;
> >> + }
> >> +
> >> + index = 0;
> >> + for_each_available_child_of_node(np, child_np) {
> >> + struct rockchip_usb2phy_port *rport = >ports[index];
> >> + struct phy *phy;
> >> +
> >> + phy = devm_phy_create(dev, child_np,
> >> _usb2phy_ops);
> >> + if (IS_ERR(phy)) {
> >> + dev_err(dev, "failed to create phy\n");
> >> + ret = PTR_ERR(phy);
> >> + goto put_child;
> >> + }
> >> +
> >> + rport->phy = phy;
> >> +
> >> + /* initialize otg/host port separately */
> >> + if (!of_node_cmp(child_np->name, "host-port")) {
> >> + ret = rockchip_usb2phy_host_port_init(rphy, rport,
> >> +   child_np);
> >> + if (ret)
> >> + goto put_child;
> >> + }
> >> +
> >> + phy_set_drvdata(rport->phy, rport);
> >> +
> >> + /* to prevent out of boundary */
> >> + if (++index >= rphy->phy_cfg->num_ports)
> >> + break;
> >> + }
> >> +
> >> + provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> >> + return PTR_ERR_OR_ZERO(provider);
> >> +
> >> +put_child:
> >> + of_node_put(child_np);
> >> + return ret;
> >> +}
> >> +
> >> +static const struct rockchip_usb2phy_cfg rk3366_phy_cfgs = {
> >> + .num_ports  = 2,
> >> + .clkout_ctl = { 0x0724, 15, 15, 1, 0 },
> >> + .port_cfgs  = {
> >> + [USB2PHY_PORT_HOST] = {
> >> + .phy_sus= { 0x0728, 15, 0, 0, 0x1d1 },
> >> + .ls_det_en  = { 0x0680, 4, 4, 0, 1 },
> >> + .ls_det_st  = { 0x0690, 4, 4, 0, 1 },
> >> + .ls_det_clr = { 0x06a0, 4, 4, 0, 1 },
> >> + .utmi_ls= { 0x049c, 14, 13, 0, 1 },
> >> + .utmi_hstdet= { 0x049c, 12, 12, 0, 1 }
> >> + }
> >> + },
> >> +};
> > 
> > I also realized that the rk3399 has two of those phy-blocks, so I think
> > we'll need to adapt your data storage mechanism a tiny bit. Maybe
> > something like the following:
> > 
> > In the dts:
> > 
> > grf: syscon@ff77 {
> > 
> >compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd";
> >
> > ...
> >
> >u2phy: usb2-phy@700 {
> >
> >compatible = "rockchip,rk3366-usb2phy";
> >
> > reg = <0x700 0x2c>;
> > 

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

On 07/06/16 16:09, Felipe Balbi wrote:
> 
> Hi,
> 
> (guys, please make sure to break lines at 80-columns)
> 
> Roger Quadros  writes:
>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void 
>> *_evt)
>>int dwc3_gadget_init(struct dwc3 *dwc)
>>{
>>intret;
>> +struct resource *res;
>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>> +
>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>> +if (dwc->irq_gadget <= 0) {
>
> Is it expected to get -EPROBE_DEFER here?

 Probably not as we don't have any chance of deferring probe here. We've 
 already
 probed successfully and are just turning on the gadget mode here.
>>>
>>> In general, you can't say that you've been probed successfully if not
>>> all resources are ready, and irq is a resource :) It's expected that
>>> all resources will be requested in probe, but here you are trying to
>>> get resource outside of probe. As result, it will be perfectly
>>> possible to get -EPROBE_DEFER here if on some HW GPIO IRQ will be
>>> used as peripheral, or host or otg irq (for example), because GPIO
>>> IRQ controller might not be ready at the moment when IRQ resource is
>>> requested.
>>
>> I agree with you.
>>
>> Felipe, are you ok with moving the IRQ resource obtaining code to probe?
> 
> You mean that probe() would setup all gadget_irq, otg_irq and host_irq
> while the other pieces (otg.c, gadget.c and host.c) only use it?
> 
> yeah, that should be fine. No problems.
> 
OK great. I'll fix this up then. Thanks.

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Roger Quadros]

On 07/06/16 16:04, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>>> But you said I must run an unnecessary OTG state machine, even thought it
>>> has nothing to do with my system, only because the two sides of my port
>>> mux device is a host and peripheral controller.
>>
>> We have a minimal dual-role state machine that just looks at ID pin
>> and toggles the port role.
> 
> I don't know if we want to bring all that extra baggage just to write a
> few bits in a single register. Even for DWC3-only dual-role (what
> Synopsys licenses as part of some DWC3 instantiations), the OTG/DRD
> layer is a bit overkill.
> 
> If you take my testing/next, for example, we have everything we need for
> dual-role; except for OTG/DRD IRQ handler. Just look at how we implement
> ->suspend()/->resume() and it's be clear that we're just missing one
> step.
> 
> I might be able to find some time to implement a proof of concept which
> would allow your platforms to get dual-role with code we already have,
> but I need DWC3's OTG support which, I'm assuming, you already have :-)
> 
> If you wanna try something offline, just ping me ;-) I'll be happy to
> help.

What you are proposing is a dwc3 only solution. With the otg/dual-role
series we are trying to be generic as much as possible.
Whether controller drivers want to use it or not is upto the driver maintainers
but we should at least ensure that user space ABI if any, is consistent
across different implementations.

> 
>> How are you switching the port mux between host and peripheral? Only
>> by sysfs or do you have a GPIO for ID pin as well?
> 
> depends. Some SoCs have GPIO-controller muxes while some just have mux's
> select signals (one for ID, one for VBUS) mapped on xHCI's address
> space.
> 
>> What happens to the gadget controller when the port is muxed to the
>> host controller?  Is it stopped or it continues to run?
> 
> it continues running, but that's pretty irrelevant for Intel's dual-role

Isn't that unnecessary waste of power? Or you have firmware assisted
low power mode?

> setup. We have an actual physical (inside the die, though) mux which
> muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only
> DWC3.
> 

Probably irrelevant for Intel's dual-role but many platforms that share
the port can't have device controller running when port is in host mode and 
vice versa. 
So there has to be a central point of control where the respective controllers
are started/stopped.
That is the other point we are trying to address with the common
otg/dual-role code.

Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we need
to stop the host controller for device mode, right?

If so then who will deal with start/stop of the controllers then?

So for Intel port-mux case it seems that OTG/dual-role is overcomplicated
and I wouldn't force you to use it. It is upto Peter to decide how he wants
dual-role users to behave.

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

RE: [PATCH v4] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Hayes Wang]

Mario Limonciello [mailto:mario_limoncie...@dell.com]
[...]
> + ret = hex2bin(buf, obj->string.pointer + 9, 6);
> + if (ret < 0 || !is_valid_ether_addr(buf)) {
> + netif_warn(tp, probe, tp->netdev, "Invalid MAC\n");
> + goto amacout;
> + }

If hex2bin() is success, the ret would be 0.
And you would return 0 when !is_valid_ether_addr(buf) occurs.
I don't think it is what you wants.

Best Regards,
Hayes

--
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 v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Felipe Balbi]

Hi,

(guys, please make sure to break lines at 80-columns)

Roger Quadros  writes:
> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void 
> *_evt)
>int dwc3_gadget_init(struct dwc3 *dwc)
>{
>intret;
> +struct resource *res;
> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
> +
> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
> +if (dwc->irq_gadget <= 0) {

 Is it expected to get -EPROBE_DEFER here?
>>>
>>> Probably not as we don't have any chance of deferring probe here. We've 
>>> already
>>> probed successfully and are just turning on the gadget mode here.
>> 
>> In general, you can't say that you've been probed successfully if not
>> all resources are ready, and irq is a resource :) It's expected that
>> all resources will be requested in probe, but here you are trying to
>> get resource outside of probe. As result, it will be perfectly
>> possible to get -EPROBE_DEFER here if on some HW GPIO IRQ will be
>> used as peripheral, or host or otg irq (for example), because GPIO
>> IRQ controller might not be ready at the moment when IRQ resource is
>> requested.
>
> I agree with you.
>
> Felipe, are you ok with moving the IRQ resource obtaining code to probe?

You mean that probe() would setup all gadget_irq, otg_irq and host_irq
while the other pieces (otg.c, gadget.c and host.c) only use it?

yeah, that should be fine. No problems.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> But you said I must run an unnecessary OTG state machine, even thought it
>> has nothing to do with my system, only because the two sides of my port
>> mux device is a host and peripheral controller.
>
> We have a minimal dual-role state machine that just looks at ID pin
> and toggles the port role.

I don't know if we want to bring all that extra baggage just to write a
few bits in a single register. Even for DWC3-only dual-role (what
Synopsys licenses as part of some DWC3 instantiations), the OTG/DRD
layer is a bit overkill.

If you take my testing/next, for example, we have everything we need for
dual-role; except for OTG/DRD IRQ handler. Just look at how we implement
->suspend()/->resume() and it's be clear that we're just missing one
step.

I might be able to find some time to implement a proof of concept which
would allow your platforms to get dual-role with code we already have,
but I need DWC3's OTG support which, I'm assuming, you already have :-)

If you wanna try something offline, just ping me ;-) I'll be happy to
help.

> How are you switching the port mux between host and peripheral? Only
> by sysfs or do you have a GPIO for ID pin as well?

depends. Some SoCs have GPIO-controller muxes while some just have mux's
select signals (one for ID, one for VBUS) mapped on xHCI's address
space.

> What happens to the gadget controller when the port is muxed to the
> host controller?  Is it stopped or it continues to run?

it continues running, but that's pretty irrelevant for Intel's dual-role
setup. We have an actual physical (inside the die, though) mux which
muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only
DWC3.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Roger Quadros]

On 07/06/16 12:53, Lu Baolu wrote:
> Hi,
> 
> On 06/07/2016 11:03 AM, Jun Li wrote:
>> Hi Roger
>>
>>>  
>>> For Mux devices implementing dual-role, the mux device driver _must_ use
>>> OTG/dual-role core API so that a common ABI is presented to user space for
>>> OTG/dual-role.
>> That's the only point we have concern, do dual role switch through
>> OTG/dual-role core, not do it by itself.
>>
>>> I haven't yet looked at the mux framework but if we take care of the above
>>> point then we are not introducing any redundancy.
>>>
>> Roger, actually this is my worry on OTG core: those dual role switch
>> users just tends to do it simply by itself(straightforward and easy),
>> not through the OTG core(some complicated in first look),
> 
> I'm sorry, but I'm really confused.
> 
> Why do we need to drop "straightforward and easy", but have to run
> an *unnecessary* OTG state machine? Don't you think that will (1) add
> *unnecessary* software complexity; (2) increase *unnecessary* memory
> footprint; and (3) increase the debugging efforts?
> 
>> this is just an example for us to convince people to select a better
>> way:)
> 
> Sure. Let's take my case for an example.
> 
> My system has a third-party port mux, which is not part any USB controllers.
> Also, my system doesn't have any DRD capable devices. I need a
> "straightforward and easy" driver for it. Otherwise, the system could not be
> waken up from system suspend.
> 
> But you said I must run an unnecessary OTG state machine, even thought it
> has nothing to do with my system, only because the two sides of my port
> mux device is a host and peripheral controller.

We have a minimal dual-role state machine that just looks at ID pin and toggles
the port role.

How are you switching the port mux between host and peripheral? Only by sysfs
or do you have a GPIO for ID pin as well?

What happens to the gadget controller when the port is muxed to the host 
controller?
Is it stopped or it continues to run?

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

Re: Nokia N900: musb is in wrong state after boot

[Pali Rohár]

On Sunday 29 May 2016 12:38:24 Pali Rohár wrote:
> > From fd67b58e3538c0732750ecad915cde736da099dc Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Pali=20Roh=C3=A1r?= 
> > Date: Sat, 9 Jan 2016 16:57:59 +0100
> > Subject: [PATCH] musb: debugfs: Add support in testmode for forcing host 
> > mode
> >  together with speed
> > 
> > ---
> >  drivers/usb/musb/musb_debugfs.c |   44 
> > +--
> >  1 file changed, 28 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/usb/musb/musb_debugfs.c 
> > b/drivers/usb/musb/musb_debugfs.c
> > index 9b22d94..62c13a2 100644
> > --- a/drivers/usb/musb/musb_debugfs.c
> > +++ b/drivers/usb/musb/musb_debugfs.c
> > @@ -147,28 +147,34 @@ static int musb_test_mode_show(struct seq_file *s, 
> > void *unused)
> >  
> > test = musb_readb(musb->mregs, MUSB_TESTMODE);
> >  
> > -   if (test & MUSB_TEST_FORCE_HOST)
> > +   if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
> > +   seq_printf(s, "force host full-speed\n");
> > +
> > +   else if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
> > +   seq_printf(s, "force host high-speed\n");
> > +
> > +   else if (test & MUSB_TEST_FORCE_HOST)
> > seq_printf(s, "force host\n");
> >  
> > -   if (test & MUSB_TEST_FIFO_ACCESS)
> > +   else if (test & MUSB_TEST_FIFO_ACCESS)
> > seq_printf(s, "fifo access\n");
> >  
> > -   if (test & MUSB_TEST_FORCE_FS)
> > +   else if (test & MUSB_TEST_FORCE_FS)
> > seq_printf(s, "force full-speed\n");
> >  
> > -   if (test & MUSB_TEST_FORCE_HS)
> > +   else if (test & MUSB_TEST_FORCE_HS)
> > seq_printf(s, "force high-speed\n");
> >  
> > -   if (test & MUSB_TEST_PACKET)
> > +   else if (test & MUSB_TEST_PACKET)
> > seq_printf(s, "test packet\n");
> >  
> > -   if (test & MUSB_TEST_K)
> > +   else if (test & MUSB_TEST_K)
> > seq_printf(s, "test K\n");
> >  
> > -   if (test & MUSB_TEST_J)
> > +   else if (test & MUSB_TEST_J)
> > seq_printf(s, "test J\n");
> >  
> > -   if (test & MUSB_TEST_SE0_NAK)
> > +   else if (test & MUSB_TEST_SE0_NAK)
> > seq_printf(s, "test SE0 NAK\n");
> >  
> > return 0;
> > @@ -206,30 +212,36 @@ static ssize_t musb_test_mode_write(struct file *file,
> > if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
> > return -EFAULT;
> >  
> > -   if (strstarts(buf, "force host"))
> > +   if (strstarts(buf, "force host full-speed"))
> > +   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
> > +
> > +   else if (strstarts(buf, "force host high-speed"))
> > +   test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
> > +
> > +   else if (strstarts(buf, "force host"))
> > test = MUSB_TEST_FORCE_HOST;
> >  
> > -   if (strstarts(buf, "fifo access"))
> > +   else if (strstarts(buf, "fifo access"))
> > test = MUSB_TEST_FIFO_ACCESS;
> >  
> > -   if (strstarts(buf, "force full-speed"))
> > +   else if (strstarts(buf, "force full-speed"))
> > test = MUSB_TEST_FORCE_FS;
> >  
> > -   if (strstarts(buf, "force high-speed"))
> > +   else if (strstarts(buf, "force high-speed"))
> > test = MUSB_TEST_FORCE_HS;
> >  
> > -   if (strstarts(buf, "test packet")) {
> > +   else if (strstarts(buf, "test packet")) {
> > test = MUSB_TEST_PACKET;
> > musb_load_testpacket(musb);
> > }
> >  
> > -   if (strstarts(buf, "test K"))
> > +   else if (strstarts(buf, "test K"))
> > test = MUSB_TEST_K;
> >  
> > -   if (strstarts(buf, "test J"))
> > +   else if (strstarts(buf, "test J"))
> > test = MUSB_TEST_J;
> >  
> > -   if (strstarts(buf, "test SE0 NAK"))
> > +   else if (strstarts(buf, "test SE0 NAK"))
> > test = MUSB_TEST_SE0_NAK;
> >  
> > musb_writeb(musb->mregs, MUSB_TESTMODE, test);
> > -- 
> > 1.7.9.5
> > 
> 
> Tony, what do you think about that patch?
> 

Tony, PING

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

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Roger Quadros]

On 07/06/16 12:27, Lu Baolu wrote:
> Hi,
> 
> On 06/07/2016 02:34 PM, Jun Li wrote:
 On 06/07/2016 11:03 AM, Jun Li wrote:
>> Hi Roger
>>

 For Mux devices implementing dual-role, the mux device driver _must_
 use OTG/dual-role core API so that a common ABI is presented to user
 space for OTG/dual-role.
>> That's the only point we have concern, do dual role switch through
>> OTG/dual-role core, not do it by itself.

 That really depends on how do you define "dual role". Can you please
 provide an unambiguous definition of "dual role" used in OTG/dual-role
 framework?
>> Host and peripheral.
>>
> 
> This is definitely ambiguous.
> 
> By reading OTG/dual-role code, my understanding is that "dual-role" is a
> "reduced OTG" which is for DRD devices lacking of some OTG negotiation
> protocols.

DRD means dual role with zero OTG features, which is similar to just host and
peripheral mode.

> 
> We really can't say "it's the scope of OTG/dual-role" whenever it comes to
> "host and peripheral".

What other combination you foresee?

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

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

On 07/06/16 14:49, Grygorii Strashko wrote:
> On 06/07/2016 12:34 PM, Roger Quadros wrote:
>> On 02/06/16 14:52, Grygorii Strashko wrote:
>>> On 06/01/2016 10:46 AM, Roger Quadros wrote:
 Implementations might use different IRQs for
 host, gadget and OTG so use named interrupt resources
 to allow Device tree to specify the 3 interrupts.

 Following are the interrupt names

 Peripheral Interrupt - peripheral
 HOST Interrupt - host
 OTG Interrupt - otg
>>>
>>> or "dwc_usb3"??
>>
>> That is for backward compatibility only. I could explicitly
>> mention it in the next line.
> 
> yes pls, this confuses.
>  Also I don't see how "otg" irq name is used in code.
> 

OK. I'll remove it from the commit message.
>>
>>>

 We still maintain backward compatibility for a single named
 interrupt for all 3 interrupts (e.g. for dwc3-pci) and
 single unnamed interrupt for all 3 interrupts (e.g. old DT).
>>>
>>> bindings
>>
>> OK.
>>>

 Signed-off-by: Roger Quadros 
 ---
 v9: rebased on top of balbi/testing/next

drivers/usb/dwc3/core.c   | 10 --
drivers/usb/dwc3/gadget.c | 20 ++--
drivers/usb/dwc3/host.c   | 19 +++
3 files changed, 37 insertions(+), 12 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index 9c4e1d8d..5cedf3d 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;

 -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 -if (!res) {
 -dev_err(dev, "missing IRQ\n");
 -return -ENODEV;
 -}
 -dwc->xhci_resources[1].start = res->start;
 -dwc->xhci_resources[1].end = res->end;
 -dwc->xhci_resources[1].flags = res->flags;
 -dwc->xhci_resources[1].name = res->name;
 -
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory resource\n");
 diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
 index c37168d..c18c72f 100644
 --- a/drivers/usb/dwc3/gadget.c
 +++ b/drivers/usb/dwc3/gadget.c
 @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
intret = 0;
intirq;

 -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
 +irq = dwc->irq_gadget;
ret = request_threaded_irq(irq, dwc3_interrupt, 
 dwc3_thread_interrupt,
IRQF_SHARED, "dwc3", dwc->ev_buf);
if (ret) {
 @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
irq, ret);
goto err0;
}
 -dwc->irq_gadget = irq;

spin_lock_irqsave(>lock, flags);
if (dwc->gadget_driver) {
 @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void 
 *_evt)
int dwc3_gadget_init(struct dwc3 *dwc)
{
intret;
 +struct resource *res;
 +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
 +
 +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
 +if (dwc->irq_gadget <= 0) {
>>>
>>> Is it expected to get -EPROBE_DEFER here?
>>
>> Probably not as we don't have any chance of deferring probe here. We've 
>> already
>> probed successfully and are just turning on the gadget mode here.
> 
> In general, you can't say that you've been probed successfully if not all 
> resources are ready,
> and irq is a resource :)
> It's expected that all resources will be requested in probe, but here you are 
> trying to get
> resource outside of probe. As result, it will be perfectly possible to get 
> -EPROBE_DEFER here
> if on some HW GPIO IRQ will be used as peripheral, or host or otg irq (for 
> example), because 
> GPIO IRQ controller might not be ready at the moment when IRQ resource is 
> requested.

I agree with you.

Felipe, are you ok with moving the IRQ resource obtaining code to probe?

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

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Grygorii Strashko]

On 06/07/2016 12:34 PM, Roger Quadros wrote:
> On 02/06/16 14:52, Grygorii Strashko wrote:
>> On 06/01/2016 10:46 AM, Roger Quadros wrote:
>>> Implementations might use different IRQs for
>>> host, gadget and OTG so use named interrupt resources
>>> to allow Device tree to specify the 3 interrupts.
>>>
>>> Following are the interrupt names
>>>
>>> Peripheral Interrupt - peripheral
>>> HOST Interrupt - host
>>> OTG Interrupt - otg
>>
>> or "dwc_usb3"??
> 
> That is for backward compatibility only. I could explicitly
> mention it in the next line.

yes pls, this confuses.
 Also I don't see how "otg" irq name is used in code.

> 
>>
>>>
>>> We still maintain backward compatibility for a single named
>>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
>>
>> bindings
> 
> OK.
>>
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>> v9: rebased on top of balbi/testing/next
>>>
>>>drivers/usb/dwc3/core.c   | 10 --
>>>drivers/usb/dwc3/gadget.c | 20 ++--
>>>drivers/usb/dwc3/host.c   | 19 +++
>>>3 files changed, 37 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index 9c4e1d8d..5cedf3d 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>>dwc->mem = mem;
>>>dwc->dev = dev;
>>>
>>> -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>>> -if (!res) {
>>> -dev_err(dev, "missing IRQ\n");
>>> -return -ENODEV;
>>> -}
>>> -dwc->xhci_resources[1].start = res->start;
>>> -dwc->xhci_resources[1].end = res->end;
>>> -dwc->xhci_resources[1].flags = res->flags;
>>> -dwc->xhci_resources[1].name = res->name;
>>> -
>>>res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>if (!res) {
>>>dev_err(dev, "missing memory resource\n");
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index c37168d..c18c72f 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>>intret = 0;
>>>intirq;
>>>
>>> -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
>>> +irq = dwc->irq_gadget;
>>>ret = request_threaded_irq(irq, dwc3_interrupt, 
>>> dwc3_thread_interrupt,
>>>IRQF_SHARED, "dwc3", dwc->ev_buf);
>>>if (ret) {
>>> @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>>irq, ret);
>>>goto err0;
>>>}
>>> -dwc->irq_gadget = irq;
>>>
>>>spin_lock_irqsave(>lock, flags);
>>>if (dwc->gadget_driver) {
>>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void 
>>> *_evt)
>>>int dwc3_gadget_init(struct dwc3 *dwc)
>>>{
>>>intret;
>>> +struct resource *res;
>>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>>> +
>>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>>> +if (dwc->irq_gadget <= 0) {
>>
>> Is it expected to get -EPROBE_DEFER here?
> 
> Probably not as we don't have any chance of deferring probe here. We've 
> already
> probed successfully and are just turning on the gadget mode here.

In general, you can't say that you've been probed successfully if not all 
resources are ready,
and irq is a resource :)
It's expected that all resources will be requested in probe, but here you are 
trying to get
resource outside of probe. As result, it will be perfectly possible to get 
-EPROBE_DEFER here
if on some HW GPIO IRQ will be used as peripheral, or host or otg irq (for 
example), because 
GPIO IRQ controller might not be ready at the moment when IRQ resource is 
requested.

> 
>>
>>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev,
>>> +  "dwc_usb3");
>>> +if (dwc->irq_gadget <= 0) {
>>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>>> +0);
>>
>> It's better to use platform_get_irq().
> 
> OK.
>>
>>> +if (!res) {
>>> +dev_err(dwc->dev, "missing peripheral IRQ\n");
>>> +return -ENODEV;
>>> +}
>>> +dwc->irq_gadget = res->start;
>>> +}
>>> +}
>>>
>>>dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
>>>>ctrl_req_addr, GFP_KERNEL);
>>> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
>>> index c679f63..f2b60a4 100644
>>> --- a/drivers/usb/dwc3/host.c
>>> +++ b/drivers/usb/dwc3/host.c
>>> @@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
>>>struct platform_device*xhci;
>>>struct usb_xhci_pdatapdata;
>>>int   

RE: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets

[Peter Chen]

 

>-Original Message-
>From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org]
>On Behalf Of Krzysztof Opasiak
>Sent: Tuesday, June 07, 2016 3:46 PM
>To: Peter Chen 
>Cc: Krzysztof Opasiak ; ba...@kernel.org; Greg Kroah-
>Hartman ; Andrzej Pietrasiewicz
>; Marek Szyprowski ;
>linux-usb@vger.kernel.org
>Subject: Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and
>legacy gadgets
>
>Hi,
>
>On Tue, Jun 7, 2016 at 3:27 AM, Peter Chen  wrote:
>> On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote:
>>> Currently it is possible to build in some subset of usb functions
>>> *OR* some gadget module. This is limited only by Kconfig not any
>>> functionality.
>>>
>>> This patch removes this limitation. With this patch it is possible to
>>> set up all build combinations:
>>> 1) Multiple gadgets build in
>>
>> If that, what the user will expect if choosing multiple gadgets?
>> Eg, if he chooses g_ncm and g_mass_storage, will he expect his udc has
>> both mass_storage and ncm function, but it is not the fact, only the
>> first gadget function will work.
>>
>
>Not exactly one. You may build in multiple modules and use those multiple 
>modules if
>you have multiple udcs.
>

My concern is:  with your patch, the user may get unexpected results if he 
builds in
multiple gadgets for this single udc. At current code, the user can't do that, 
then he will
not get unexpected results. How do you consider that?

Peter

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

[Herbert Xu]

On Fri, Jun 03, 2016 at 12:13:06PM +0100, Bob Ham wrote:
> Two patches to add support for the Araneus Alea I USB RNG to the
> chaoskey driver.  The first simply includes the Alea I as a device,
> the second fixes an issue with the timeout on the first read.
> 
> Bob Ham (2):
>   hwrng: chaoskey - Add support for Araneus Alea I USB RNG
>   hwrng: chaoskey - Fix URB warning due to timeout on Alea
> 
>  drivers/usb/misc/Kconfig| 11 ++-
>  drivers/usb/misc/chaoskey.c | 21 +++--
>  2 files changed, 25 insertions(+), 7 deletions(-)

Both applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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

[XHCI: Help needed] One hang issue when using XHCI host driver playing Video for Isochronous transfer

[Tang Jianqiang]

Hi Mathias && Balbi and ALL,
   We hit one hang issue when using DWC3 XHCI host mode to play Video
for Isochronous transfer.
   Both usb-audio module and XHCI driver output errors.
Our kernel version is 3.18.x.
   And already include Mathias's commit:

1> xhci: fix off by one error in TRB DMA address boundary check
2> xhci: fix isoc endpoint dequeue from advancing too far on
transaction error

   But still can hit this error.
   Can anyone give some analysis about this error?

Thanks a lot!

   Here is the error log:

[ 1220.518211] usb 1-1: cannot submit urb 0, error -16: unknown error
[ 1220.528974] usb 1-1: cannot submit urb 0, error -16: unknown error
[ 1220.539792] usb 1-1: cannot submit urb 0, error -16: unknown error
[ 1220.550522] usb 1-1: cannot submit urb 0, error -16: unknown error
[ 1220.561233] usb 1-1: cannot submit urb 0, error -16: unknown error
[ 1220.577320] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.588591] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e798f0 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.606387] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.618616] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79900 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.636417] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.648652] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79910 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.666451] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.678690] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79920 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.696487] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.708726] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79930 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.726519] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.738762] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79940 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.756554] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.768786] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79950 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.786586] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.798820] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79960 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.816617] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
[ 1220.828858] xhci-hcd xhci-hcd.0.auto: Looking for event-dma
f7e79970 trb-start f7e79b70 trb-end f7e79b70
seg-start f7e79000 seg-end f7e79ff0
[ 1220.846687] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event TRB DMA
ptr not part of current TD ep_index 5 comp_code 1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails

[Michał Pecio]

Since ed_schedule begins with marking the ED as "operational",
the ED may be left in such state even if scheduling actually
fails.

This allows future submission attempts to smuggle this ED to the
hardware behind the scheduler's back and without linking it to
the ohci->eds_in_use list.

The former causes bandwidth saturation and data loss on isoc
endpoints, the latter crashes the kernel when attempt is made
to unlink such ED from this list.

Fix ed_schedule to update ED state only on successful return.

Signed-off-by: Michal Pecio 
---
 drivers/usb/host/ohci-q.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c
index d029bbe..641fed6 100644
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -183,7 +183,6 @@ static int ed_schedule (struct ohci_hcd *ohci, struct ed 
*ed)
 {
int branch;
 
-   ed->state = ED_OPER;
ed->ed_prev = NULL;
ed->ed_next = NULL;
ed->hwNextED = 0;
@@ -259,6 +258,8 @@ static int ed_schedule (struct ohci_hcd *ohci, struct ed 
*ed)
/* the HC may not see the schedule updates yet, but if it does
 * then they'll be properly ordered.
 */
+
+   ed->state = ED_OPER;
return 0;
 }
 
-- 
2.8.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

[PATCH 1/2] usb: dwc3: pci: add dr-mode for Intel dwc3

[Felipe Balbi]

It's know that Intel's SoCs' dwc3 integration is
peripheral-only since Intel implements its own
portmux for role-swapping. In order to prevent dwc3
from ever registering and XHCI platform_device,
let's just set dr-mode to peripheral-only on Intel
SoCs.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/dwc3-pci.c | 62 +++--
 1 file changed, 37 insertions(+), 25 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 6bc4c2b08ac7..45f5a232d9fb 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -76,33 +76,45 @@ static int dwc3_pci_quirks(struct pci_dev *pdev, struct 
platform_device *dwc3)
return platform_device_add_properties(dwc3, properties);
}
 
-   if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
-   pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
-   struct gpio_desc *gpio;
-
-   acpi_dev_add_driver_gpios(ACPI_COMPANION(>dev),
- acpi_dwc3_byt_gpios);
-
-   /*
-* These GPIOs will turn on the USB2 PHY. Note that we have to
-* put the gpio descriptors again here because the phy driver
-* might want to grab them, too.
-*/
-   gpio = gpiod_get_optional(>dev, "cs", GPIOD_OUT_LOW);
-   if (IS_ERR(gpio))
-   return PTR_ERR(gpio);
-
-   gpiod_set_value_cansleep(gpio, 1);
-   gpiod_put(gpio);
-
-   gpio = gpiod_get_optional(>dev, "reset", GPIOD_OUT_LOW);
-   if (IS_ERR(gpio))
-   return PTR_ERR(gpio);
-
-   if (gpio) {
+   if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
+   int ret;
+
+   struct property_entry properties[] = {
+   PROPERTY_ENTRY_STRING("dr-mode", "peripheral"),
+   { }
+   };
+
+   ret = platform_device_add_properties(dwc3, properties);
+   if (ret < 0)
+   return ret;
+
+   if (pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
+   struct gpio_desc *gpio;
+
+   acpi_dev_add_driver_gpios(ACPI_COMPANION(>dev),
+   acpi_dwc3_byt_gpios);
+
+   /*
+* These GPIOs will turn on the USB2 PHY. Note that we 
have to
+* put the gpio descriptors again here because the phy 
driver
+* might want to grab them, too.
+*/
+   gpio = gpiod_get_optional(>dev, "cs", 
GPIOD_OUT_LOW);
+   if (IS_ERR(gpio))
+   return PTR_ERR(gpio);
+
gpiod_set_value_cansleep(gpio, 1);
gpiod_put(gpio);
-   usleep_range(1, 11000);
+
+   gpio = gpiod_get_optional(>dev, "reset", 
GPIOD_OUT_LOW);
+   if (IS_ERR(gpio))
+   return PTR_ERR(gpio);
+
+   if (gpio) {
+   gpiod_set_value_cansleep(gpio, 1);
+   gpiod_put(gpio);
+   usleep_range(1, 11000);
+   }
}
}
 
-- 
2.8.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

[PATCH 2/2] usb: dwc3: core: fixup dr_mode fallback selection

[Felipe Balbi]

We shouldn't change a host-only dwc3 to gadget-only
if driver is built as gadget-only. Fix that up here.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9c4e1d8d01db..8fceeb1a32a4 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -975,9 +975,13 @@ static int dwc3_probe(struct platform_device *pdev)
goto err0;
}
 
-   if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
+   if (IS_ENABLED(CONFIG_USB_DWC3_HOST) &&
+   (dwc->dr_mode == USB_DR_MODE_OTG ||
+   dwc->dr_mode == USB_DR_MODE_UNKNOWN))
dwc->dr_mode = USB_DR_MODE_HOST;
-   else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
+   else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET) &&
+   (dwc->dr_mode == USB_DR_MODE_OTG ||
+   dwc->dr_mode == USB_DR_MODE_UNKNOWN))
dwc->dr_mode = USB_DR_MODE_PERIPHERAL;
 
if (dwc->dr_mode == USB_DR_MODE_UNKNOWN)
-- 
2.8.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: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

[Felipe Balbi]

Hi,

Peter Chen  writes:
>> >> > kbuild test robot  writes:
>> >> >> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
>> >> >> testing/next
>> >> >> head:   89fe2b5ab11cdf6a67d4492d893e70e330aa7060
>> >> >> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: 
>> >> >> move gadget API functions to udc-core
>> >> >> config: x86_64-randconfig-s1-06061834 (attached as .config)
>> >> >> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>> >> >> reproduce:
>> >> >> git checkout 231b31ca34485552fe27e67dc6d30d06079c7648
>> >> >> # save the attached .config to linux build tree
>> >> >> make ARCH=x86_64 
>> >> >>
>> >> >> All errors (new ones prefixed by >>):
>> >> >>
>> >> >>drivers/built-in.o: In function `nop_set_peripheral':
>> >>  phy-generic.c:(.text+0x14423f): undefined reference to 
>> >>  `usb_gadget_vbus_connect'
>> >> >>drivers/built-in.o: In function `nop_gpio_vbus_thread':
>> >>  phy-generic.c:(.text+0x144742): undefined reference to 
>> >>  `usb_gadget_vbus_disconnect'
>> >> >
>> >> > oh yeah, I have to fix this. I'll do it now.
>> >> 
>> >> In order to fix this, I'll have to add something like below:
>> >> 
>> >> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
>> >> index 3644a3500b70..bd67e4ac4b61 100644
>> >> --- a/drivers/usb/chipidea/Kconfig
>> >> +++ b/drivers/usb/chipidea/Kconfig
>> >> @@ -19,6 +19,7 @@ config USB_CHIPIDEA_OF
>> >>  config USB_CHIPIDEA_PCI
>> >>   tristate
>> >>   depends on PCI
>> >> + depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV
>> >>   depends on NOP_USB_XCEIV
>> >>   default USB_CHIPIDEA
>> >
>> > Hi Felipe,
>> >
>> > It causes any drivers which use symbols from gadget.h needs to build
>> > USB_GADGET even it only wants to be host function. Any significant
>> > benefits after moving it to udc-core.c?
>> 
>> why is a host-only function calling into the gadget API?
>> 
>
> Well, Just like this case, the chipidea driver can be configured host
> mode only, but it still uses generic phy.

then we should allow for PHYs to not depend on the Gadget API, right?

> Besides, we have some common code which handles vbus status, this code
> will be built even at host-only mode, but will not be called since the
> runtime condition is not satisfied, eg, dr_mode, device role at
> register.

driver shouldn't depend on the gadget API if it's not built with Gadget
support. Look at dwc3 for instance. All gadget API-related code is
stashed in ep0.c and gadget.c, but those only get built if the driver
was built with gadget support:

Kconfig
===

8<

choice
bool "DWC3 Mode Selection"
default USB_DWC3_DUAL_ROLE if (USB && USB_GADGET)
default USB_DWC3_HOST if (USB && !USB_GADGET)
default USB_DWC3_GADGET if (!USB && USB_GADGET)

config USB_DWC3_HOST
bool "Host only mode"
depends on USB=y || USB=USB_DWC3
help
  Select this when you want to use DWC3 in host mode only,
  thereby the gadget feature will be regressed.

config USB_DWC3_GADGET
bool "Gadget only mode"
depends on USB_GADGET=y || USB_GADGET=USB_DWC3
help
  Select this when you want to use DWC3 in gadget mode only,
  thereby the host feature will be regressed.

config USB_DWC3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_DWC3) && (USB_GADGET=y || 
USB_GADGET=USB_DWC3))
help
  This is the default mode of working of DWC3 controller where
  both host and gadget features are enabled.

endchoice

8<


Makefile


8<

ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y  += gadget.o ep0.o
endif

8<

In any case, here's a better version of this patch:

commit 9062bc60311d0a4bbe84e2aa3ec7c2cba06356e4
Author: Felipe Balbi 
Date:   Tue May 31 13:07:47 2016 +0300

usb: gadget: move gadget API functions to udc-core

instead of defining all functions as static inlines,
let's move them to udc-core and export them with
EXPORT_SYMBOL_GPL, that way we can make sure that
only GPL drivers will use them.

As a side effect, it'll be nicer to add tracepoints
to the gadget API.

While at that, also fix Kconfig dependencies to
avoid randconfig build failures.

Signed-off-by: Felipe Balbi 

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 6e8300d6a737..d2f28bb6dbda 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ 

Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

[Joao Pinto]

Hi,
Just to add my tested-by to the patch sent by Grygorii Strashko on 03/31/2016
(https://lkml.org/lkml/2016/3/31/609).

The patch was tested on a v4.6 kernel, running in a Juno r1 development board,
being the USB 3.0 Host prototyped in a FPGA.

Tested-by: Joao Pinto 

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

Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets

[Krzysztof Opasiak]

Hi,

On Tue, Jun 7, 2016 at 11:06 AM, Peter Chen  wrote:
>
>
>>-Original Message-
>>From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org]
>>On Behalf Of Krzysztof Opasiak
>>Sent: Tuesday, June 07, 2016 3:46 PM
>>To: Peter Chen 
>>Cc: Krzysztof Opasiak ; ba...@kernel.org; Greg Kroah-
>>Hartman ; Andrzej Pietrasiewicz
>>; Marek Szyprowski ;
>>linux-usb@vger.kernel.org
>>Subject: Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and
>>legacy gadgets
>>
>>Hi,
>>
>>On Tue, Jun 7, 2016 at 3:27 AM, Peter Chen  wrote:
>>> On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote:
 Currently it is possible to build in some subset of usb functions
 *OR* some gadget module. This is limited only by Kconfig not any
 functionality.

 This patch removes this limitation. With this patch it is possible to
 set up all build combinations:
 1) Multiple gadgets build in
>>>
>>> If that, what the user will expect if choosing multiple gadgets?
>>> Eg, if he chooses g_ncm and g_mass_storage, will he expect his udc has
>>> both mass_storage and ncm function, but it is not the fact, only the
>>> first gadget function will work.
>>>
>>
>>Not exactly one. You may build in multiple modules and use those multiple 
>>modules if
>>you have multiple udcs.
>>
>
> My concern is:  with your patch, the user may get unexpected results if he 
> builds in
> multiple gadgets for this single udc. At current code, the user can't do 
> that, then he will
> not get unexpected results. How do you consider that?
>

That's true but even without this patch user may build multiple
gadgets as a modules.

Even more, after commit (855ed04 "usb: gadget: udc-core: independent
registration of
gadgets and gadget drivers") it is possible to load multiple gadget
modules even if we have one UDC.

So why would you like to disallow building in multiple gadgets if user
can build them as a modules and simply load?

If you concern about order of probing and binding to udc, I think that
we can add udc module param to all legacy gadgets so user can specify
in kernel cmd line where each gadget should be bound.

--
Best regards,
Krzysztof Opasiak
--
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: Race condition in usbfs / libusb when using reap-after-disconnect

[Hans de Goede]

Hi,

On 06-06-16 19:03, Alan Stern wrote:

On Mon, 6 Jun 2016, Hans de Goede wrote:


Hi,

On 06-06-16 16:48, Greg Kroah-Hartman wrote:

On Mon, Jun 06, 2016 at 01:44:23PM +0200, Hans de Goede wrote:

Hi All,

While looking at libusb today I ended up looking at the
reap-after-disconnect code.

What stands out is that libusb expects to be able to
reap all outstanding urbs on a device on receiving
a POLL_ERR status from poll (on supported kernels).

But the usbfs poll implementation will return POLL_ERR
as soon as ps->dev->state == USB_STATE_NOTATTACHED,
and the kernel usb code sets state = USB_STATE_NOTATTACHED
some time before usbdev_remove() gets called and moves
all pending urbs to the async_completed list.


This means that URBs can't be reaped immediately.  But it will be
possible to reap them shortly after libusb gets the POLLERR status,
once the khubd work routine has processed the disconnection.


Ack.


So if libusb ends up calling poll between the
setting state = USB_STATE_NOTATTACHED and usbdev_remove()
being called then it ends up not reaping all urbs
since it will stop monitoring the device after
the first POLL_ERR.

I'll write a libusb fix for this, but I'm wondering if this
is something which we also want to fix on the kernel side?


We could.  Would it be worthwhile to do so?


That is exactly the question this mail thread is intended to answer :)


Would fixing this in the kernel mean that libusb fixes are not needed?
If so, I would recommend doing this.


A kernel side fix is non trivial, whereas the libusb fix is trivial
since we also need to deal with kernels which do not support
reaping urbs after disconnect at all.

Basically the question is, do we consider not being able to
reap all urbs after the first POLL_ERR a kernel bug, or should
userspace keep track of how many urbs it has outstanding and
call the reap ioctl (with some msleep after failure) until it
has reaped all urbs ?


We already have POLLOUT to indicate when a completed URB is available
for reaping.  Can libusb use that?


libusb already use that normally, but on a POLLERR it will remove
the fd from the pollfds since POLLERR will stay set once set, so
leaving it in pollfds means we will just set there busy-waiting.


Strictly speaking, POLLERR just indicates an error condition, of any
kind.


Ack, but the current semantics for how this works with usbfs are
somewhat sub-optimal from a libusb pov. The fix for this is easy
since libusb already has code in place to deal with older kernels
which do not support REAP after disconnect at all and I plan to
use that (rather then wait if we hit the race), but it does
make the whole REAP after disconnect function a whole lot
less useful.

Regards,

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

Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

[Peter Chen]

On Tue, Jun 07, 2016 at 12:36:13PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen  writes:
> > On Mon, Jun 06, 2016 at 04:16:17PM +0300, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Felipe Balbi  writes:
> >> > [ Unknown signature status ]
> >> >
> >> > Hi,
> >> >
> >> > kbuild test robot  writes:
> >> >> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> >> >> testing/next
> >> >> head:   89fe2b5ab11cdf6a67d4492d893e70e330aa7060
> >> >> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: 
> >> >> move gadget API functions to udc-core
> >> >> config: x86_64-randconfig-s1-06061834 (attached as .config)
> >> >> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> >> >> reproduce:
> >> >> git checkout 231b31ca34485552fe27e67dc6d30d06079c7648
> >> >> # save the attached .config to linux build tree
> >> >> make ARCH=x86_64 
> >> >>
> >> >> All errors (new ones prefixed by >>):
> >> >>
> >> >>drivers/built-in.o: In function `nop_set_peripheral':
> >>  phy-generic.c:(.text+0x14423f): undefined reference to 
> >>  `usb_gadget_vbus_connect'
> >> >>drivers/built-in.o: In function `nop_gpio_vbus_thread':
> >>  phy-generic.c:(.text+0x144742): undefined reference to 
> >>  `usb_gadget_vbus_disconnect'
> >> >
> >> > oh yeah, I have to fix this. I'll do it now.
> >> 
> >> In order to fix this, I'll have to add something like below:
> >> 
> >> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> >> index 3644a3500b70..bd67e4ac4b61 100644
> >> --- a/drivers/usb/chipidea/Kconfig
> >> +++ b/drivers/usb/chipidea/Kconfig
> >> @@ -19,6 +19,7 @@ config USB_CHIPIDEA_OF
> >>  config USB_CHIPIDEA_PCI
> >>tristate
> >>depends on PCI
> >> +  depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV
> >>depends on NOP_USB_XCEIV
> >>default USB_CHIPIDEA
> >
> > Hi Felipe,
> >
> > It causes any drivers which use symbols from gadget.h needs to build
> > USB_GADGET even it only wants to be host function. Any significant
> > benefits after moving it to udc-core.c?
> 
> why is a host-only function calling into the gadget API?
> 

Well, Just like this case, the chipidea driver can be configured host
mode only, but it still uses generic phy.

Besides, we have some common code which handles vbus status, this code
will be built even at host-only mode, but will not be called since the
runtime condition is not satisfied, eg, dr_mode, device role at
register.

-- 

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

Re: [PATCH v3 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Heiko Stübner]

Hi Frank,

Am Montag, 6. Juni 2016, 17:20:04 schrieb Frank Wang:
> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> than rk3288 and before, and most of phy-related registers are also
> different from the past, so a new phy driver is required necessarily.
> 
> Signed-off-by: Frank Wang 
> ---

[...]

> +static int rockchip_usb2phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *child_np;
> + struct phy_provider *provider;
> + struct rockchip_usb2phy *rphy;
> + const struct of_device_id *match;
> + int index, ret;
> +
> + rphy = devm_kzalloc(dev, sizeof(*rphy), GFP_KERNEL);
> + if (!rphy)
> + return -ENOMEM;
> +
> + match = of_match_device(dev->driver->of_match_table, dev);
> + if (!match || !match->data) {
> + dev_err(dev, "phy configs are not assigned!\n");
> + return -EINVAL;
> + }
> +
> + if (!dev->parent || !dev->parent->of_node)
> + return -EINVAL;
> +
> + rphy->grf = syscon_node_to_regmap(dev->parent->of_node);
> + if (IS_ERR(rphy->grf))
> + return PTR_ERR(rphy->grf);
> +
> + rphy->dev = dev;
> + rphy->phy_cfg = match->data;
> + platform_set_drvdata(pdev, rphy);
> +
> + ret = rockchip_usb2phy_clk480m_register(rphy);
> + if (ret) {
> + dev_err(dev, "failed to register 480m output clock\n");
> + return ret;
> + }
> +
> + rphy->vbus_host = devm_regulator_get_optional(dev, "vbus_host");
> + if (IS_ERR(rphy->vbus_host)) {
> + ret = PTR_ERR(rphy->vbus_host);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + dev_info(dev, "vbus_host regulator is not assigned!\n");
> + rphy->vbus_host = NULL;
> + } else {
> + ret = regulator_enable(rphy->vbus_host);
> + if (ret)
> + return ret;
> + }
> +
> + index = 0;
> + for_each_available_child_of_node(np, child_np) {
> + struct rockchip_usb2phy_port *rport = >ports[index];
> + struct phy *phy;
> +
> + phy = devm_phy_create(dev, child_np, _usb2phy_ops);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create phy\n");
> + ret = PTR_ERR(phy);
> + goto put_child;
> + }
> +
> + rport->phy = phy;
> +
> + /* initialize otg/host port separately */
> + if (!of_node_cmp(child_np->name, "host-port")) {
> + ret = rockchip_usb2phy_host_port_init(rphy, rport,
> +   child_np);
> + if (ret)
> + goto put_child;
> + }
> +
> + phy_set_drvdata(rport->phy, rport);
> +
> + /* to prevent out of boundary */
> + if (++index >= rphy->phy_cfg->num_ports)
> + break;
> + }
> +
> + provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> + return PTR_ERR_OR_ZERO(provider);
> +
> +put_child:
> + of_node_put(child_np);
> + return ret;
> +}
> +
> +static const struct rockchip_usb2phy_cfg rk3366_phy_cfgs = {
> + .num_ports  = 2,
> + .clkout_ctl = { 0x0724, 15, 15, 1, 0 },
> + .port_cfgs  = {
> + [USB2PHY_PORT_HOST] = {
> + .phy_sus= { 0x0728, 15, 0, 0, 0x1d1 },
> + .ls_det_en  = { 0x0680, 4, 4, 0, 1 },
> + .ls_det_st  = { 0x0690, 4, 4, 0, 1 },
> + .ls_det_clr = { 0x06a0, 4, 4, 0, 1 },
> + .utmi_ls= { 0x049c, 14, 13, 0, 1 },
> + .utmi_hstdet= { 0x049c, 12, 12, 0, 1 }
> + }
> + },
> +};

I also realized that the rk3399 has two of those phy-blocks, so I think we'll 
need to adapt your data storage mechanism a tiny bit. Maybe something like
the following:

In the dts:

grf: syscon@ff77 {
   compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd";
...
   u2phy: usb2-phy@700 {
   compatible = "rockchip,rk3366-usb2phy";
reg = <0x700 0x2c>;
...
   };
};

In the driver

static const struct rockchip_usb2phy_cfg rk3366_phy_cfgs[] = {
{
.reg = 0x700,
.num_ports  = 2,
.clkout_ctl = { 0x0724, 15, 15, 1, 0 },
.port_cfgs  = {
[USB2PHY_PORT_HOST] = {
.phy_sus= { 0x0728, 15, 0, 0, 0x1d1 },
...
}
},
},
};

and in _probe then simply use the correct array entry matching the dts reg 
property.

On the rk3399 this would 

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Lu Baolu]

Hi,

On 06/07/2016 11:03 AM, Jun Li wrote:
> Hi Roger
>
>>  
>> For Mux devices implementing dual-role, the mux device driver _must_ use
>> OTG/dual-role core API so that a common ABI is presented to user space for
>> OTG/dual-role.
> That's the only point we have concern, do dual role switch through
> OTG/dual-role core, not do it by itself.
>
>> I haven't yet looked at the mux framework but if we take care of the above
>> point then we are not introducing any redundancy.
>>
> Roger, actually this is my worry on OTG core: those dual role switch
> users just tends to do it simply by itself(straightforward and easy),
> not through the OTG core(some complicated in first look),

I'm sorry, but I'm really confused.

Why do we need to drop "straightforward and easy", but have to run
an *unnecessary* OTG state machine? Don't you think that will (1) add
*unnecessary* software complexity; (2) increase *unnecessary* memory
footprint; and (3) increase the debugging efforts?

> this is just an example for us to convince people to select a better
> way:)

Sure. Let's take my case for an example.

My system has a third-party port mux, which is not part any USB controllers.
Also, my system doesn't have any DRD capable devices. I need a
"straightforward and easy" driver for it. Otherwise, the system could not be
waken up from system suspend.

But you said I must run an unnecessary OTG state machine, even thought it
has nothing to do with my system, only because the two sides of my port
mux device is a host and peripheral controller.

Why?

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

Re: [PATCH 23/62] usb: dwc3: implement runtime PM

[Felipe Balbi]

Hi,

Roger Quadros  writes:
>> Roger Quadros  writes:
>>> On 30/05/16 14:35, Felipe Balbi wrote:
 this patch implements the most basic pm_runtime
 support for dwc3. Whenever USB cable is dettached,
 then we will allow core to runtime_suspend.

 Runtime suspending will involve completely tearing
 down event buffers and require a full soft-reset of
 the IP.

 Note that a further optimization could be
 implemented once we decide to support hibernation,
 which is to allow runtime_suspend with cable
 connected when bus is in U3. That's subject to a
 separate patch, however.

 Tested-by: Baolin Wang 
 Signed-off-by: Felipe Balbi 
>>>
>>> We've discussed this offline but for the record, this patch
>>> breaks DWC3 on OMAP platforms. At least on dra7-evm I could see
>>> both USB host and gadget breaking.
>>>
>>> I will try to implement the runtime resume hooks for dwc3-omap
>>> and let you know if we can make it work.
>> 
>> cool, thanks :-)
>> 
>
> On testing branch commit [1], dwc3 breaks after
> system suspend/resume on dra7-evm.
>
> [1] - cd45299a0f3a41f25729a523aecc0f3e6ad14d43

got some logs there, somewhere? :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: http://www.linux-usb.org/gadget/usb.c exambple problem.

[Felipe Balbi]

Hi,

Brian Park  writes:
> I need help with getting http://www.linux-usb.org/gadget/usb.c working
> on my Beagle Bone Black based embedded board. I'm using TI Processor
> SDK 2.00.02.11 with their linux kernel
> linux-4.1.18+gitAUTOINC+bbe8cfc1da-gbbe8cfc. My application is based

if you're using TI's SDK, this forum can't do anything for you. You
_must_ ask for help from TI.

Good luck

-- 
balbi


signature.asc
Description: PGP signature

Re: [balbi-usb:testing/next 64/67] phy-generic.c:undefined reference to `usb_gadget_vbus_connect'

[Felipe Balbi]

Hi,

Peter Chen  writes:
> On Mon, Jun 06, 2016 at 04:16:17PM +0300, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> Felipe Balbi  writes:
>> > [ Unknown signature status ]
>> >
>> > Hi,
>> >
>> > kbuild test robot  writes:
>> >> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
>> >> testing/next
>> >> head:   89fe2b5ab11cdf6a67d4492d893e70e330aa7060
>> >> commit: 231b31ca34485552fe27e67dc6d30d06079c7648 [64/67] usb: gadget: 
>> >> move gadget API functions to udc-core
>> >> config: x86_64-randconfig-s1-06061834 (attached as .config)
>> >> compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
>> >> reproduce:
>> >> git checkout 231b31ca34485552fe27e67dc6d30d06079c7648
>> >> # save the attached .config to linux build tree
>> >> make ARCH=x86_64 
>> >>
>> >> All errors (new ones prefixed by >>):
>> >>
>> >>drivers/built-in.o: In function `nop_set_peripheral':
>>  phy-generic.c:(.text+0x14423f): undefined reference to 
>>  `usb_gadget_vbus_connect'
>> >>drivers/built-in.o: In function `nop_gpio_vbus_thread':
>>  phy-generic.c:(.text+0x144742): undefined reference to 
>>  `usb_gadget_vbus_disconnect'
>> >
>> > oh yeah, I have to fix this. I'll do it now.
>> 
>> In order to fix this, I'll have to add something like below:
>> 
>> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
>> index 3644a3500b70..bd67e4ac4b61 100644
>> --- a/drivers/usb/chipidea/Kconfig
>> +++ b/drivers/usb/chipidea/Kconfig
>> @@ -19,6 +19,7 @@ config USB_CHIPIDEA_OF
>>  config USB_CHIPIDEA_PCI
>>  tristate
>>  depends on PCI
>> +depends on USB_GADGET=y || USB_GADGET=NOP_USB_XCEIV
>>  depends on NOP_USB_XCEIV
>>  default USB_CHIPIDEA
>
> Hi Felipe,
>
> It causes any drivers which use symbols from gadget.h needs to build
> USB_GADGET even it only wants to be host function. Any significant
> benefits after moving it to udc-core.c?

why is a host-only function calling into the gadget API?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

On 02/06/16 14:52, Grygorii Strashko wrote:
> On 06/01/2016 10:46 AM, Roger Quadros wrote:
>> Implementations might use different IRQs for
>> host, gadget and OTG so use named interrupt resources
>> to allow Device tree to specify the 3 interrupts.
>>
>> Following are the interrupt names
>>
>> Peripheral Interrupt - peripheral
>> HOST Interrupt - host
>> OTG Interrupt - otg
> 
> or "dwc_usb3"??

That is for backward compatibility only. I could explicitly
mention it in the next line.

> 
>>
>> We still maintain backward compatibility for a single named
>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
> 
> bindings

OK.
> 
>>
>> Signed-off-by: Roger Quadros 
>> ---
>> v9: rebased on top of balbi/testing/next
>>
>>   drivers/usb/dwc3/core.c   | 10 --
>>   drivers/usb/dwc3/gadget.c | 20 ++--
>>   drivers/usb/dwc3/host.c   | 19 +++
>>   3 files changed, 37 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 9c4e1d8d..5cedf3d 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -843,16 +843,6 @@ static int dwc3_probe(struct platform_device *pdev)
>>   dwc->mem = mem;
>>   dwc->dev = dev;
>>
>> -res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> -if (!res) {
>> -dev_err(dev, "missing IRQ\n");
>> -return -ENODEV;
>> -}
>> -dwc->xhci_resources[1].start = res->start;
>> -dwc->xhci_resources[1].end = res->end;
>> -dwc->xhci_resources[1].flags = res->flags;
>> -dwc->xhci_resources[1].name = res->name;
>> -
>>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>   if (!res) {
>>   dev_err(dev, "missing memory resource\n");
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index c37168d..c18c72f 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1726,7 +1726,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>   intret = 0;
>>   intirq;
>>
>> -irq = platform_get_irq(to_platform_device(dwc->dev), 0);
>> +irq = dwc->irq_gadget;
>>   ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
>>   IRQF_SHARED, "dwc3", dwc->ev_buf);
>>   if (ret) {
>> @@ -1734,7 +1734,6 @@ static int dwc3_gadget_start(struct usb_gadget *g,
>>   irq, ret);
>>   goto err0;
>>   }
>> -dwc->irq_gadget = irq;
>>
>>   spin_lock_irqsave(>lock, flags);
>>   if (dwc->gadget_driver) {
>> @@ -2853,6 +2852,23 @@ static irqreturn_t dwc3_interrupt(int irq, void *_evt)
>>   int dwc3_gadget_init(struct dwc3 *dwc)
>>   {
>>   intret;
>> +struct resource *res;
>> +struct platform_device *dwc3_pdev = to_platform_device(dwc->dev);
>> +
>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev, "peripheral");
>> +if (dwc->irq_gadget <= 0) {
> 
> Is it expected to get -EPROBE_DEFER here?

Probably not as we don't have any chance of deferring probe here. We've already
probed successfully and are just turning on the gadget mode here.

> 
>> +dwc->irq_gadget = platform_get_irq_byname(dwc3_pdev,
>> +  "dwc_usb3");
>> +if (dwc->irq_gadget <= 0) {
>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>> +0);
> 
> It's better to use platform_get_irq().

OK.
> 
>> +if (!res) {
>> +dev_err(dwc->dev, "missing peripheral IRQ\n");
>> +return -ENODEV;
>> +}
>> +dwc->irq_gadget = res->start;
>> +}
>> +}
>>
>>   dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
>>   >ctrl_req_addr, GFP_KERNEL);
>> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
>> index c679f63..f2b60a4 100644
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -25,6 +25,25 @@ int dwc3_host_init(struct dwc3 *dwc)
>>   struct platform_device*xhci;
>>   struct usb_xhci_pdatapdata;
>>   intret;
>> +struct resource*res;
>> +struct platform_device*dwc3_pdev = to_platform_device(dwc->dev);
>> +
>> +res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ, "host");
>> +if (!res) {
>> +res = platform_get_resource_byname(dwc3_pdev, IORESOURCE_IRQ,
>> +   "dwc_usb3");
>> +if (!res) {
>> +res = platform_get_resource(dwc3_pdev, IORESOURCE_IRQ,
>> +0);
>> +if (!res)
> 
>> +return -ENOMEM;
>> +}
>> +}
> 
> Is it expected to have more than one IRQ here?

No.
> 
> if not - it will better to use platform_get_irq[_byname]().

OK.
> 
> 
>> +
>> +dwc->xhci_resources[1].start = res->start;
>> +

Re: [PATCH v9 5/5] usb: dwc3: core: cleanup IRQ resources

[Roger Quadros]

Felipe,

On 01/06/16 11:06, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> Implementations might use different IRQs for
>> host, gadget and OTG so use named interrupt resources
>> to allow Device tree to specify the 3 interrupts.
>>
>> Following are the interrupt names
>>
>> Peripheral Interrupt - peripheral
>> HOST Interrupt - host
>> OTG Interrupt - otg
>>
>> We still maintain backward compatibility for a single named
>> interrupt for all 3 interrupts (e.g. for dwc3-pci) and
>> single unnamed interrupt for all 3 interrupts (e.g. old DT).
>>
>> Signed-off-by: Roger Quadros 
>> ---
>> v9: rebased on top of balbi/testing/next
> 
> breaks dwc3:
> 
> [  222.776504] dwc3 dwc3.0.auto: failed to request irq #-6 --> -22
> 
> please test
> 

I couldn't reproduce the failure at my end.
Could it be specific to your setup?

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

[Krzysztof Kozlowski]

On 06/03/2016 04:02 AM, Rob Herring wrote:
>>  Optional properties:
>>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are 
>> asserted
>> @@ -16,6 +22,7 @@ Optional properties:
>>See ../clocks/clock-bindings.txt for details.
>>  - clock-names : Must include the following entry:
>>"ext_clock" (External clock provided to the card).
>> +- ext-supply : External regulator supply
> 
> What happens when there are 2 supplies?
> 
> I'd prefer the name not be genericish and use the real supply names. 
> Then the power seq code should just turn on all supplies it finds. If 
> the order or timing to turn on matters, then sorry, no generic sequence.

I think the generic part for regulators might be a problem. Regulator
API requires a name for the supply... it cannot get "something" or
"everything".

The driver could attach itself to any kind of node (where power-sequence
property exists) so the supply name depends on the bindings of device
(not bindings of power sequence driver).

The power sequence driver could however iterate over child properties
and get the names of all supplies. It is a little bit ugly...

Best regards,
Krzysztof

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

Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Lu Baolu]

Hi,

On 06/07/2016 02:34 PM, Jun Li wrote:
>> > On 06/07/2016 11:03 AM, Jun Li wrote:
>>> > > Hi Roger
>>> > >
 > >>
 > >> For Mux devices implementing dual-role, the mux device driver _must_
 > >> use OTG/dual-role core API so that a common ABI is presented to user
 > >> space for OTG/dual-role.
>>> > > That's the only point we have concern, do dual role switch through
>>> > > OTG/dual-role core, not do it by itself.
>> > 
>> > That really depends on how do you define "dual role". Can you please
>> > provide an unambiguous definition of "dual role" used in OTG/dual-role
>> > framework?
> Host and peripheral.
>

This is definitely ambiguous.

By reading OTG/dual-role code, my understanding is that "dual-role" is a
"reduced OTG" which is for DRD devices lacking of some OTG negotiation
protocols.

We really can't say "it's the scope of OTG/dual-role" whenever it comes to
"host and peripheral".

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

Re: [STLinux Kernel] [PATCH 0/7] reset: Consumers to explicitly request 'exclusive' or 'shared' lines

[Lee Jones]

On Tue, 07 Jun 2016, Lee Jones wrote:

> On Tue, 07 Jun 2016, Peter Griffin wrote:
> 
> > Hi,
> > 
> > On Mon, 06 Jun 2016, Lee Jones wrote:
> > 
> > > Phasing out generic reset line requests enables us to make some better
> > > decisions on when and how to (de)assert said lines.  If an 'exclusive'
> > > line is requested, we know a device *requires* a reset and that it's
> > > preferable to act upon a request right away.  However, if a 'shared'
> > > reset line is requested, we can reasonably assume sure that placing a
> > > device into reset isn't a hard requirement, but probably a measure to
> > > save power and is thus able to cope with not being asserted if another
> > > device is still in use.
> > > 
> > > In order allow gentle adoption and not to forcing all consumers to
> > > move to the API immediately, causing administration headache between
> > > subsystems, this patch adds some temporary stand-in shim-calls.  This
> > > will ease the burden at merge time and allow subsystems to migrate over
> > > to the new API in a more realistic time-frame.
> > 
> > Is the intention that this series will be taken into the next -rc?
> > 
> > As the introduction of shared resets in reset subsystem has caused 
> > regressions
> > on STi platforms.
> 
> Yes, which is why it has a Fixes: tag.

Ah wait.  I thought this was the shared-memory patch.

More haste, less speed and all that.

I guess it should really go into the -rcs, yes.  Since Hans' patch
actually breaks a lot of devices.  I'm pretty surprised a patch
capable of this much damage was actually accepted to be honest.  A
better approach would have been to issue a warning, but keep the
semantics the same for at least a couple of releases.  However, I
guess the damage has been done now, so let's do what we can do fix
it.

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

Re: [PATCH 23/62] usb: dwc3: implement runtime PM

[Roger Quadros]

Felipe,

On 30/05/16 15:42, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> On 30/05/16 14:35, Felipe Balbi wrote:
>>> this patch implements the most basic pm_runtime
>>> support for dwc3. Whenever USB cable is dettached,
>>> then we will allow core to runtime_suspend.
>>>
>>> Runtime suspending will involve completely tearing
>>> down event buffers and require a full soft-reset of
>>> the IP.
>>>
>>> Note that a further optimization could be
>>> implemented once we decide to support hibernation,
>>> which is to allow runtime_suspend with cable
>>> connected when bus is in U3. That's subject to a
>>> separate patch, however.
>>>
>>> Tested-by: Baolin Wang 
>>> Signed-off-by: Felipe Balbi 
>>
>> We've discussed this offline but for the record, this patch
>> breaks DWC3 on OMAP platforms. At least on dra7-evm I could see
>> both USB host and gadget breaking.
>>
>> I will try to implement the runtime resume hooks for dwc3-omap
>> and let you know if we can make it work.
> 
> cool, thanks :-)
> 

On testing branch commit [1], dwc3 breaks after
system suspend/resume on dra7-evm.

[1] - cd45299a0f3a41f25729a523aecc0f3e6ad14d43

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

[PATCH v4 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Frank Wang]

Signed-off-by: Frank Wang 
---

Changes in v4:
 - Used 'phy-supply' instead of 'vbus_*-supply'.

Changes in v3:
 - Added 'clocks' and 'clock-names' optional properties.
 - Specified 'otg-port' and 'host-port' as the sub-node name.

Changes in v2:
 - Changed vbus_host optional property from gpio to regulator.
 - Specified vbus_otg-supply optional property.
 - Specified otg_id and otg_bvalid property.

 .../bindings/phy/phy-rockchip-inno-usb2.txt|   62 
 1 file changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
new file mode 100644
index 000..3465980
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -0,0 +1,62 @@
+ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
+
+Required properties (phy (parent) node):
+ - compatible : should be one of the listed compatibles:
+   * "rockchip,rk3366-usb2phy"
+   * "rockchip,rk3399-usb2phy"
+ - #clock-cells : should be 0.
+ - clock-output-names : specify the 480m output clock name.
+
+Optional properties:
+ - clocks : phandle + phy specifier pair, for the input clock of phy.
+ - clock-names : input clock name of phy, must be "phyclk".
+
+Required nodes : a sub-node is required for each port the phy provides.
+The sub-node name is used to identify host or otg port,
+and shall be the following entries:
+   * "otg-port" : the name of otg port.
+   * "host-port" : the name of host port.
+
+Required properties (port (child) node):
+ - #phy-cells : must be 0. See ./phy-bindings.txt for details.
+ - interrupts : specify an interrupt for each entry in interrupt-names.
+ - interrupt-names : a list which shall be the following entries:
+   * "otg_id" : for the otg id interrupt.
+   * "otg_bvalid" : for the otg vbus interrupt.
+   * "linestate" : for the host/otg linestate interrupt.
+
+Optional properties:
+ - phy-supply : phandle to a regulator that provides power to VBUS.
+   See ./phy-bindings.txt for details.
+
+Example:
+
+grf: syscon@ff77 {
+   compatible = "rockchip,rk3366-grf", "syscon", "simple-mfd";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+...
+
+   u2phy: usb2-phy {
+   compatible = "rockchip,rk3366-usb2phy";
+   #clock-cells = <0>;
+   clock-output-names = "sclk_otgphy0_480m";
+
+   u2phy_otg: otg-port {
+   #phy-cells = <0>;
+   interrupts = ,
+,
+;
+   interrupt-names = "otg_id", "otg_bvalid", "linestate";
+   status = "okay";
+   };
+
+   u2phy_host: host-port {
+   #phy-cells = <0>;
+   interrupts = ;
+   interrupt-names = "linestate";
+   status = "okay";
+   };
+   };
+};
-- 
1.7.9.5


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

[PATCH v4 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Frank Wang]

The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
than rk3288 and before, and most of phy-related registers are also
different from the past, so a new phy driver is required necessarily.

Signed-off-by: Frank Wang 
---

Changes in v4:
 - Removed some processes related to 'vbus_host-supply'.

Changes in v3:
 - Resolved the mapping defect between fixed value in driver and the property
   in devicetree.
 - Optimized 480m output clock register function.
 - Code cleanup.

Changes in v2:
 - Changed vbus_host operation from gpio to regulator in *_probe.
 - Improved the fault treatment relate to 480m clock register.
 - Cleaned up some meaningless codes in *_clk480m_disable.
 - made more clear the comment of *_sm_work.

 drivers/phy/Kconfig  |7 +
 drivers/phy/Makefile |1 +
 drivers/phy/phy-rockchip-inno-usb2.c |  614 ++
 3 files changed, 622 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b869b98..29ef15c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_INNO_USB2
+   tristate "Rockchip INNO USB2PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Support for Rockchip USB2.0 PHY with Innosilicon IP block.
+
 config PHY_ROCKCHIP_EMMC
tristate "Rockchip EMMC PHY Driver"
depends on ARCH_ROCKCHIP && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9c3e73c..4963fbc 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
b/drivers/phy/phy-rockchip-inno-usb2.c
new file mode 100644
index 000..d2eb26f
--- /dev/null
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -0,0 +1,614 @@
+/*
+ * Rockchip USB2.0 PHY with Innosilicon IP block driver
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BIT_WRITEABLE_SHIFT16
+#define SCHEDULE_DELAY (60 * HZ)
+
+enum rockchip_usb2phy_port_id {
+   USB2PHY_PORT_OTG,
+   USB2PHY_PORT_HOST,
+   USB2PHY_NUM_PORTS,
+};
+
+enum rockchip_usb2phy_host_state {
+   PHY_STATE_HS_ONLINE = 0,
+   PHY_STATE_DISCONNECT= 1,
+   PHY_STATE_HS_CONNECT= 2,
+   PHY_STATE_FS_CONNECT= 4,
+};
+
+struct usb2phy_reg {
+   unsigned intoffset;
+   unsigned intbitend;
+   unsigned intbitstart;
+   unsigned intdisable;
+   unsigned intenable;
+};
+
+/**
+ * struct rockchip_usb2phy_port_cfg: usb-phy port configuration.
+ * @phy_sus: phy suspend register.
+ * @ls_det_en: linestate detection enable register.
+ * @ls_det_st: linestate detection state register.
+ * @ls_det_clr: linestate detection clear register.
+ * @utmi_ls: utmi linestate state register.
+ * @utmi_hstdet: utmi host disconnect register.
+ */
+struct rockchip_usb2phy_port_cfg {
+   struct usb2phy_reg  phy_sus;
+   struct usb2phy_reg  ls_det_en;
+   struct usb2phy_reg  ls_det_st;
+   struct usb2phy_reg  ls_det_clr;
+   struct usb2phy_reg  utmi_ls;
+   struct usb2phy_reg  utmi_hstdet;
+};
+
+/**
+ * struct rockchip_usb2phy_cfg: usb-phy configuration.
+ * @num_ports: specify how many ports that the phy has.
+ * @clkout_ctl: keep on/turn off output clk of phy.
+ */
+struct rockchip_usb2phy_cfg {
+   unsigned intnum_ports;
+   struct usb2phy_reg  clkout_ctl;
+   const struct rockchip_usb2phy_port_cfg  port_cfgs[USB2PHY_NUM_PORTS];
+};
+
+/**
+ * struct rockchip_usb2phy_port: usb-phy 

[PATCH v4 0/2] Add a new Rockchip usb2 phy driver

[Frank Wang]

The newer SoCs (rk3366, rk3399) of Rock-chip take a different usb-phy
IP block than rk3288 and before, and most of phy-related registers are
also different from the past, so a new phy driver is required necessarily.

These series patches add phy-rockchip-inno-usb2.c and the corresponding
documentation.

Changes in v4:
 - Used 'phy-supply' instead of 'vbus_*-supply'.

Changes in v3:
 - Supplemented some hardware-description into the devicetree bindings.
 - Resolved the mapping defect between fixed value in driver and the property
   in devicetree.
 - Code cleanup.

Changes in v2:
 - Specified more hardware-description into the devicetree bindings.
 - Optimized some process of driver.

Frank Wang (2):
  Documentation: bindings: add DT documentation for Rockchip USB2PHY
  phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

 .../bindings/phy/phy-rockchip-inno-usb2.txt|   62 ++
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-rockchip-inno-usb2.c   |  614 
 4 files changed, 684 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
 create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c

-- 
1.7.9.5


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

Re: [STLinux Kernel] [PATCH 0/7] reset: Consumers to explicitly request 'exclusive' or 'shared' lines

[Lee Jones]

On Tue, 07 Jun 2016, Peter Griffin wrote:

> Hi,
> 
> On Mon, 06 Jun 2016, Lee Jones wrote:
> 
> > Phasing out generic reset line requests enables us to make some better
> > decisions on when and how to (de)assert said lines.  If an 'exclusive'
> > line is requested, we know a device *requires* a reset and that it's
> > preferable to act upon a request right away.  However, if a 'shared'
> > reset line is requested, we can reasonably assume sure that placing a
> > device into reset isn't a hard requirement, but probably a measure to
> > save power and is thus able to cope with not being asserted if another
> > device is still in use.
> > 
> > In order allow gentle adoption and not to forcing all consumers to
> > move to the API immediately, causing administration headache between
> > subsystems, this patch adds some temporary stand-in shim-calls.  This
> > will ease the burden at merge time and allow subsystems to migrate over
> > to the new API in a more realistic time-frame.
> 
> Is the intention that this series will be taken into the next -rc?
> 
> As the introduction of shared resets in reset subsystem has caused regressions
> on STi platforms.

Yes, which is why it has a Fixes: tag.

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

Re: [PATCH 8/10] phy: phy-stih407-usb: Inform the reset framework that our reset line may be shared

[Kishon Vijay Abraham I]

On Monday 06 June 2016 10:38 PM, Lee Jones wrote:
> On the STiH410 B2120 development board the ports on the Generic PHY
> share their reset lines with each other.  New functionality in the
> reset subsystems forces consumers to be explicit when requesting
> shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 

Acked-by: Kishon Vijay Abraham I 
> ---
>  drivers/phy/phy-stih407-usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/phy-stih407-usb.c b/drivers/phy/phy-stih407-usb.c
> index 1d5ae5f..b1f44ab 100644
> --- a/drivers/phy/phy-stih407-usb.c
> +++ b/drivers/phy/phy-stih407-usb.c
> @@ -105,13 +105,13 @@ static int stih407_usb2_picophy_probe(struct 
> platform_device *pdev)
>   phy_dev->dev = dev;
>   dev_set_drvdata(dev, phy_dev);
>  
> - phy_dev->rstc = devm_reset_control_get(dev, "global");
> + phy_dev->rstc = devm_reset_control_get_shared(dev, "global");
>   if (IS_ERR(phy_dev->rstc)) {
>   dev_err(dev, "failed to ctrl picoPHY reset\n");
>   return PTR_ERR(phy_dev->rstc);
>   }
>  
> - phy_dev->rstport = devm_reset_control_get(dev, "port");
> + phy_dev->rstport = devm_reset_control_get_exclusive(dev, "port");
>   if (IS_ERR(phy_dev->rstport)) {
>   dev_err(dev, "failed to ctrl picoPHY reset\n");
>   return PTR_ERR(phy_dev->rstport);
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] phy: miphy28lp: Inform the reset framework that our reset line may be shared

[Kishon Vijay Abraham I]

On Monday 06 June 2016 09:26 PM, Lee Jones wrote:
> On the STiH410 B2120 development board the MiPHY28lp shares its reset
> line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
> (DRD).  New functionality in the reset subsystems forces consumers to
> be explicit when requesting shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 

Acked-by: Kishon Vijay Abraham I 
> ---
>  drivers/phy/phy-miphy28lp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-miphy28lp.c b/drivers/phy/phy-miphy28lp.c
> index 3acd2a1..213e2e1 100644
> --- a/drivers/phy/phy-miphy28lp.c
> +++ b/drivers/phy/phy-miphy28lp.c
> @@ -1143,7 +1143,8 @@ static int miphy28lp_probe_resets(struct device_node 
> *node,
>   struct miphy28lp_dev *miphy_dev = miphy_phy->phydev;
>   int err;
>  
> - miphy_phy->miphy_rst = of_reset_control_get(node, "miphy-sw-rst");
> + miphy_phy->miphy_rst =
> + of_reset_control_get_shared(node, "miphy-sw-rst");
>  
>   if (IS_ERR(miphy_phy->miphy_rst)) {
>   dev_err(miphy_dev->dev,
> 
--
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: [STLinux Kernel] [PATCH 0/7] reset: Consumers to explicitly request 'exclusive' or 'shared' lines

[Peter Griffin]

Hi,

On Mon, 06 Jun 2016, Lee Jones wrote:

> Phasing out generic reset line requests enables us to make some better
> decisions on when and how to (de)assert said lines.  If an 'exclusive'
> line is requested, we know a device *requires* a reset and that it's
> preferable to act upon a request right away.  However, if a 'shared'
> reset line is requested, we can reasonably assume sure that placing a
> device into reset isn't a hard requirement, but probably a measure to
> save power and is thus able to cope with not being asserted if another
> device is still in use.
> 
> In order allow gentle adoption and not to forcing all consumers to
> move to the API immediately, causing administration headache between
> subsystems, this patch adds some temporary stand-in shim-calls.  This
> will ease the burden at merge time and allow subsystems to migrate over
> to the new API in a more realistic time-frame.

Is the intention that this series will be taken into the next -rc?

As the introduction of shared resets in reset subsystem has caused regressions
on STi platforms.

regards,

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: [STLinux Kernel] [PATCH 9/10] usb: host: ehci-st: Inform the reset framework that our reset line may be shared

[Peter Griffin]

On Mon, 06 Jun 2016, Lee Jones wrote:

> On the STiH410 B2120 development board the ST EHCI IP shares its reset
> line with the OHCI IP.  New functionality in the reset subsystems forces
> consumers to be explicit when requesting shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/usb/host/ehci-st.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Peter Griffin 

--
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: [STLinux Kernel] [PATCH 7/7] usb: dwc3: st: Inform the reset framework that our reset line may be shared

[Peter Griffin]

Hi Lee,

On Mon, 06 Jun 2016, Lee Jones wrote:

> On the STiH410 B2120 development board the MiPHY28lp shares its reset
> line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
> (DRD).  New functionality in the reset subsystems forces consumers to
> be explicit when requesting shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/usb/dwc3/dwc3-st.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Acked-by: Peter Griffin 

--
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: [STLinux Kernel] [PATCH 6/7] phy: miphy28lp: Inform the reset framework that our reset line may be shared

[Peter Griffin]

On Mon, 06 Jun 2016, Lee Jones wrote:

> On the STiH410 B2120 development board the MiPHY28lp shares its reset
> line with the Synopsys DWC3 SuperSpeed (SS) USB 3.0 Dual-Role-Device
> (DRD).  New functionality in the reset subsystems forces consumers to
> be explicit when requesting shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/phy/phy-miphy28lp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Acked-by: Peter Griffin 

--
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: [STLinux Kernel] [PATCH 8/10] phy: phy-stih407-usb: Inform the reset framework that our reset line may be shared

[Peter Griffin]

On Mon, 06 Jun 2016, Lee Jones wrote:

> On the STiH410 B2120 development board the ports on the Generic PHY
> share their reset lines with each other.  New functionality in the
> reset subsystems forces consumers to be explicit when requesting
> shared/exclusive reset lines.
> 
> Signed-off-by: Lee Jones 

Acked-by: Peter Griffin 

--
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 PATCHv2] usb: USB Type-C Connector Class

[Heikki Krogerus]

On Mon, Jun 06, 2016 at 03:35:35PM +0200, Oliver Neukum wrote:
> On Mon, 2016-06-06 at 16:28 +0300, Heikki Krogerus wrote:
> 
> > I would prefer lower case letters. I don't know the SIDs there are at
> > them moment, other then Display Port. Do you know them?
> > 
> > I don't think we can ever guarantee that in every case we will be able
> > to provide a human readable name for the alternate modes if they are
> > vendor defined. We will then potentially still have the names in two
> > different forms: "usbc0.displayport" and "usbc0.svid:". Is that
> > something acceptable to everybody?
> > 
> > I guess if it's not, then to only way to go forward would be to always
> > just use the svid in the name.
> 
> Yes, that is better. It makes more sense to use the number.
> We'd get into versioning problems if we use names.

OK, so we'll always use the svid in the name.

Thanks,

-- 
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 v3 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Frank Wang]

Hi Kishon & Heiko,

On 2016/6/7 15:45, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 07 June 2016 09:01 AM, Frank Wang wrote:

Hi Heiko,

On 2016/6/7 10:59, Frank Wang wrote:

Hi Heiko & Mark,

On 2016/6/6 20:33, Heiko Stübner wrote:

Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:

On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:

Signed-off-by: Frank Wang 
---

Changes in v3:
   - Added 'clocks' and 'clock-names' optional properties.
   - Specified 'otg-port' and 'host-port' as the sub-node name.

Changes in v2:
   - Changed vbus_host optional property from gpio to regulator.
   - Specified vbus_otg-supply optional property.
   - Specified otg_id and otg_bvalid property.
 .../bindings/phy/phy-rockchip-inno-usb2.txt| 60
    1 file changed, 60 insertions(+)
   create mode 100644
Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt>
diff --git
a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new
file mode 100644
index 000..0b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -0,0 +1,60 @@
+ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
+
+Required properties (phy (parent) node):
+ - compatible : should be one of the listed compatibles:
+* "rockchip,rk3366-usb2phy"
+* "rockchip,rk3399-usb2phy"
+ - #clock-cells : should be 0.
+ - clock-output-names : specify the 480m output clock name.
+
+Optional properties:
+ - clocks : phandle + phy specifier pair, for the input clock of phy.
+ - clock-names : input clock name of phy, must be "phyclk".
+ - vbus_host-supply : phandle to a regulator that supplies host vbus.
+ - vbus_otg-supply : phandle to a regulator that supplies otg vbus.

Nit: s/_/-/ here.

Something I only stumbled over yesterday for the first time on my rk3288-
popmetal: The phy subnodes seem to be able to use a generic phy-supply
property from inside the phy-core itself, see:

https://github.com/mmind/linux-rockchip/commit/93739f521fc65f44524b00c9aaf6db46bca94e02#diff-ddf3e45ebb753d6debf57022003a1a57R597


for my WIP code for that other board.


Ah, good comments! I will try later, if it is practicable, I shall correct it
into the next patches (patch v4).


I am sorry to tell you that seems unworkable, because we have two sub-nodes
(phy-ports) in one parent-node (phy),
what is more, the 'phy-supply' property can only put into parent-node, I
believe it can not be differentiated types of ports.

'phy-supply' is a property of the phy node and not the 'phy-provider' node. So
IMO this should work. What problem do you see?


Sorry, I think I must have made a wrong phandle of phy-port name in 
*.dts before.

Yes, It works now, thanks for your reminding.

@Heiko,
I have just received your another mail, thanks again for your detail 
explanation.


I will correct it in the next patches (patch v4).

BR.
Frank

--
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 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Heiko Stübner]

Hi Frank,

Am Dienstag, 7. Juni 2016, 11:31:59 schrieb Frank Wang:
> On 2016/6/7 10:59, Frank Wang wrote:
> > On 2016/6/6 20:33, Heiko Stübner wrote:
> >> Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:
> >>> On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
>  Signed-off-by: Frank Wang 
>  ---
>  
>  Changes in v3:
>    - Added 'clocks' and 'clock-names' optional properties.
>    - Specified 'otg-port' and 'host-port' as the sub-node name.
>  
>  Changes in v2:
>    - Changed vbus_host optional property from gpio to regulator.
>    - Specified vbus_otg-supply optional property.
>    - Specified otg_id and otg_bvalid property.
>    
>  .../bindings/phy/phy-rockchip-inno-usb2.txt| 60
>    
>     1 file changed, 60 insertions(+)
>    create mode 100644
>  
>  Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt>
>  diff --git
>  a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
>  b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new
>  file mode 100644
>  index 000..0b4
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
>  @@ -0,0 +1,60 @@
>  +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
>  +
>  +Required properties (phy (parent) node):
>  + - compatible : should be one of the listed compatibles:
>  +* "rockchip,rk3366-usb2phy"
>  +* "rockchip,rk3399-usb2phy"
>  + - #clock-cells : should be 0.
>  + - clock-output-names : specify the 480m output clock name.
>  +
>  +Optional properties:
>  + - clocks : phandle + phy specifier pair, for the input clock of phy.
>  + - clock-names : input clock name of phy, must be "phyclk".
>  + - vbus_host-supply : phandle to a regulator that supplies host vbus.
>  + - vbus_otg-supply : phandle to a regulator that supplies otg vbus.
> >>> 
> >>> Nit: s/_/-/ here.
> >> 
> >> Something I only stumbled over yesterday for the first time on my
> >> rk3288-
> >> popmetal: The phy subnodes seem to be able to use a generic phy-supply
> >> property from inside the phy-core itself, see:
> >> 
> >> https://github.com/mmind/linux-rockchip/commit/93739f521fc65f44524b00c9aa
> >> f6db46bca94e02#diff-ddf3e45ebb753d6debf57022003a1a57R597
> >> 
> >> 
> >> for my WIP code for that other board.
> > 
> > Ah, good comments! I will try later, if it is practicable, I shall
> > correct it into the next patches (patch v4).
> 
> I am sorry to tell you that seems unworkable, because we have two
> sub-nodes (phy-ports) in one parent-node (phy),
> what is more, the 'phy-supply' property can only put into parent-node, I
> believe it can not be differentiated types of ports.
> I mean vbus for host and otg are separately.

I would disagree ;-)

If you look in phy-core.c phy_create(), you can see that the struct phy that
gets created, contains its own struct device instance, which then gets the
phys of_node (the host+otg subnodes in this context) attached to it.

The regulator_get_optional then runs on this struct device, thus making lookup
on the subnode. And that works just nicely on my rk3288-popmetal, with its 3
phy subnodes and debugfs/regulator/regulator_summary prints that nicely:

 vcc_sys  0   12  0  5000mV 0mA  5000mV  5000mV 
vcc_host_5v   11  0  5000mV 0mA  5000mV  5000mV 
   phy-phy.20mV 0mV
vcc_otg_5v11  0  5000mV 0mA  5000mV  5000mV 
   phy-phy.00mV 0mV
vcc_sata_5v   21  0  5000mV 0mA  5000mV  5000mV 
   phy-phy.10mV 0mV


Heiko

--
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] r8152: Add support for setting pass through MAC address on RTL8153-AD

[Pali Rohár]

Hi! Below are my comments, all about coding style.

On Monday 06 June 2016 12:19:29 Mario Limonciello wrote:
> The RTL8153-AD supports a persistent system specific MAC address.
> This means a device plugged into two different systems with host side
> support will show different (but persistent) MAC addresses.
> 
> This information for the system's persistent MAC address is burned in when
> the system HW is built and available under _SB\AMAC in the DSDT at runtime.

For consistency it would be great to use same ACPI name in whole patch: 
\_SB.AMAC

> This technology is currently implemented in the Dell TB15 and WD15 Type-C
> docks.  More information is available here:
> http://www.dell.com/support/article/us/en/04/SLN301147
> 
> Signed-off-by: Mario Limonciello 
> ---
> Changes from v3:
>  * Add additional comments about functions and what they're doing
>  * Adjust warning calls to use netif instead
>  * Rename function
> 
>  drivers/net/usb/r8152.c | 70 
> +++--
>  1 file changed, 68 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 3f9f6ed..b2339d3 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Information for net-next */
>  #define NETNEXT_VERSION  "08"
> @@ -455,6 +456,11 @@
>  /* SRAM_IMPEDANCE */
>  #define RX_DRIVING_MASK  0x6000
>  
> +/* MAC PASSTHRU */
> +#define AD_MASK  0xfee0
> +#define EFUSE0xcfdb
> +#define PASS_THRU_MASK   0x1
> +
>  enum rtl_register_content {
>   _1000bps= 0x10,
>   _100bps = 0x08,
> @@ -1030,6 +1036,59 @@ out1:
>   return ret;
>  }
>  
> +/* Devices containing RTL8153-AD can support a persistent
> + * host system provided MAC address.
> + * Examples of this are Dell TB15 and Dell WD15 docks
> + */
> +static int get_vendor_mac_passthru_addr(struct r8152 *tp, struct sockaddr 
> *sa)
> +{
> + acpi_status status;
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + union acpi_object *obj;
> + int ret = -EINVAL;
> + u32 ocp_data;
> + unsigned char buf[6];
> +
> + /* test for -AD variant of RTL8153 */
> + ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
> + if ((ocp_data & AD_MASK) != 0x1000)
> + return -ENODEV;
> +
> + /* test for MAC address pass-through bit */
> + ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, EFUSE);
> + if ((ocp_data & PASS_THRU_MASK) != 1)
> + return -ENODEV;
> +
> + /* returns _AUXMAC_#AABBCCDDEEFF# */
> + status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );

What about?

if (!ACPI_SUCCESS(status))
return -ENODEV;

You will save one level of indentation.

> + obj = (union acpi_object *)buffer.pointer;
> + if (ACPI_SUCCESS(status)) {
> + if (obj->type != ACPI_TYPE_BUFFER ||
> + obj->string.length != 0x17) {
> + netif_warn(tp, probe, tp->netdev, "Invalid buffer\n");

I would suggest more specific warning messages. These are very general
and if I would see them in dmesg log I would have no idea what that
means.

> + goto amacout;
> + }
> + if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0) {
> + netif_warn(tp, probe, tp->netdev, "Invalid header\n");
> + goto amacout;
> + }

If your specification state that last character is '#' then I think you
should check it too.

> + ret = hex2bin(buf, obj->string.pointer + 9, 6);
> + if (ret < 0 || !is_valid_ether_addr(buf)) {
> + netif_warn(tp, probe, tp->netdev, "Invalid MAC\n");
> + goto amacout;
> + }
> + memcpy(sa->sa_data, buf, 6);
> + ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
> + netif_info(tp, probe, tp->netdev,
> +"Using pass-through MAC addr %pM\n", sa->sa_data);
> + ret = 0;
> + }
> +
> +amacout:
> + kfree(obj);
> + return ret;
> +}
> +
>  static int set_ethernet_addr(struct r8152 *tp)
>  {
>   struct net_device *dev = tp->netdev;
> @@ -1038,8 +1097,15 @@ static int set_ethernet_addr(struct r8152 *tp)
>  
>   if (tp->version == RTL_VER_01)
>   ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
> - else
> - ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
> + else {
> + /* if this is not an RTL8153-AD, no eFuse mac pass thru set,
> +  * or system doesn't provide valid _SB.AMAC this will be
> +  * be expected to non-zero
> +  */
> + ret = get_vendor_mac_passthru_addr(tp, );

You do not "get" (return) any mac address. Personally I 

Re: [PATCH v3 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

[Kishon Vijay Abraham I]

Hi,

On Tuesday 07 June 2016 09:01 AM, Frank Wang wrote:
> Hi Heiko,
> 
> On 2016/6/7 10:59, Frank Wang wrote:
>> Hi Heiko & Mark,
>>
>> On 2016/6/6 20:33, Heiko Stübner wrote:
>>> Am Montag, 6. Juni 2016, 12:27:54 schrieb Mark Rutland:
 On Mon, Jun 06, 2016 at 05:20:03PM +0800, Frank Wang wrote:
> Signed-off-by: Frank Wang 
> ---
>
> Changes in v3:
>   - Added 'clocks' and 'clock-names' optional properties.
>   - Specified 'otg-port' and 'host-port' as the sub-node name.
>
> Changes in v2:
>   - Changed vbus_host optional property from gpio to regulator.
>   - Specified vbus_otg-supply optional property.
>   - Specified otg_id and otg_bvalid property.
> .../bindings/phy/phy-rockchip-inno-usb2.txt| 60
>    1 file changed, 60 insertions(+)
>   create mode 100644
> Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt>
> diff --git
> a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
> b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt new
> file mode 100644
> index 000..0b4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
> @@ -0,0 +1,60 @@
> +ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
> +
> +Required properties (phy (parent) node):
> + - compatible : should be one of the listed compatibles:
> +* "rockchip,rk3366-usb2phy"
> +* "rockchip,rk3399-usb2phy"
> + - #clock-cells : should be 0.
> + - clock-output-names : specify the 480m output clock name.
> +
> +Optional properties:
> + - clocks : phandle + phy specifier pair, for the input clock of phy.
> + - clock-names : input clock name of phy, must be "phyclk".
> + - vbus_host-supply : phandle to a regulator that supplies host vbus.
> + - vbus_otg-supply : phandle to a regulator that supplies otg vbus.
 Nit: s/_/-/ here.
>>> Something I only stumbled over yesterday for the first time on my rk3288-
>>> popmetal: The phy subnodes seem to be able to use a generic phy-supply
>>> property from inside the phy-core itself, see:
>>>
>>> https://github.com/mmind/linux-rockchip/commit/93739f521fc65f44524b00c9aaf6db46bca94e02#diff-ddf3e45ebb753d6debf57022003a1a57R597
>>>
>>>
>>> for my WIP code for that other board.
>>>
>>
>> Ah, good comments! I will try later, if it is practicable, I shall correct it
>> into the next patches (patch v4).
>>
> 
> I am sorry to tell you that seems unworkable, because we have two sub-nodes
> (phy-ports) in one parent-node (phy),
> what is more, the 'phy-supply' property can only put into parent-node, I
> believe it can not be differentiated types of ports.

'phy-supply' is a property of the phy node and not the 'phy-provider' node. So
IMO this should work. What problem do you see?

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

Re: [RFC][PATCH] usb: gadget: Allow to build both USB functions and legacy gadgets

[Krzysztof Opasiak]

Hi,

On Tue, Jun 7, 2016 at 3:27 AM, Peter Chen  wrote:
> On Mon, Jun 06, 2016 at 09:40:33PM +0200, Krzysztof Opasiak wrote:
>> Currently it is possible to build in some subset of usb functions
>> *OR* some gadget module. This is limited only by Kconfig not
>> any functionality.
>>
>> This patch removes this limitation. With this patch it is possible
>> to set up all build combinations:
>> 1) Multiple gadgets build in
>
> If that, what the user will expect if choosing multiple gadgets?
> Eg, if he chooses g_ncm and g_mass_storage, will he expect
> his udc has both mass_storage and ncm function, but it is
> not the fact, only the first gadget function will work.
>

Not exactly one. You may build in multiple modules and use those
multiple modules if you have multiple udcs.

--
Best regards,
Krzysztof Opasiak
--
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 v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi Baolu

> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, June 07, 2016 2:27 PM
> To: Jun Li ; Roger Quadros ; Peter Chen
> 
> Cc: felipe.ba...@linux.intel.com; Mathias Nyman ;
> Greg Kroah-Hartman ; Lee Jones
> ; Heikki Krogerus ;
> Liam Girdwood ; Mark Brown ;
> linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> Hi Jun,
> 
> On 06/07/2016 11:03 AM, Jun Li wrote:
> > Hi Roger
> >
> >>
> >> For Mux devices implementing dual-role, the mux device driver _must_
> >> use OTG/dual-role core API so that a common ABI is presented to user
> >> space for OTG/dual-role.
> > That's the only point we have concern, do dual role switch through
> > OTG/dual-role core, not do it by itself.
> 
> That really depends on how do you define "dual role". Can you please
> provide an unambiguous definition of "dual role" used in OTG/dual-role
> framework?

Host and peripheral.

> 
> Best regards,
> Lu Baolu
> 
> >
> >> I haven't yet looked at the mux framework but if we take care of the
> >> above point then we are not introducing any redundancy.
> >>
> > Roger, actually this is my worry on OTG core: those dual role switch
> > users just tends to do it simply by itself(straightforward and easy),
> > not through the OTG core(some complicated in first look), this is just
> > an example for us to convince people to select a better
> > way:)
> >
> > Li Jun
> >

--
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 v10 2/7] usb: mux: add generic code for dual role port mux

[Lu Baolu]

Hi Jun,

On 06/07/2016 11:03 AM, Jun Li wrote:
> Hi Roger
>
>>  
>> For Mux devices implementing dual-role, the mux device driver _must_ use
>> OTG/dual-role core API so that a common ABI is presented to user space for
>> OTG/dual-role.
> That's the only point we have concern, do dual role switch through
> OTG/dual-role core, not do it by itself.

That really depends on how do you define "dual role". Can you please
provide an unambiguous definition of "dual role" used in OTG/dual-role
framework?

Best regards,
Lu Baolu

>
>> I haven't yet looked at the mux framework but if we take care of the above
>> point then we are not introducing any redundancy.
>>
> Roger, actually this is my worry on OTG core: those dual role switch
> users just tends to do it simply by itself(straightforward and easy),
> not through the OTG core(some complicated in first look),
> this is just an example for us to convince people to select a better
> way:)
>
> Li Jun
>

--
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 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)

[Krzysztof Kozlowski]

On 06/06/2016 10:43 PM, Heiko Stübner wrote:
> Hi,
> 
> Am Mittwoch, 1. Juni 2016, 10:02:09 schrieb Krzysztof Kozlowski:
>> My third approach for a USB power sequence which fixes usb3503+lan
>> on Odroid U3 board if it was initialized by bootloader
>> (e.g. for TFTP boot).
> 
> I was just tackling a similar bringup problem regarding an embedded usb hub 
> and usb-sata bridge and stumbled upon this series.
> 
> While on my (rockchip-)boards it's always "just" a reset pin that needs 
> handling, this series looks like it would solve exactly that problem in a 
> very 
> nice way.
> 
> So while I cannot provide any meaningful insight right now, it would be cool 
> if you could keep me in the loop, as I'm really looking forward to this 
> series 
> progressing.
> 

Sure, good to know that this problem affects more people. I do not feel
such alone anymore. ;)

Best regards,
Krzysztof

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