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

[Rob Herring]

On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote:
> Some devices need real hard-reset by cutting the power.  During power
> sequence turn off and on the regulator, if it is provided.
> 
> Additionally add support for instantiating the pwrseq-simple device on a
> generic property 'power-sequence'.  The device will attach itself to the
> node containing the property and parse the node's properties like
> reset-gpios, ext-supply etc.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  .../bindings/power/pwrseq/pwrseq-simple.txt| 29 +++-
>  drivers/power/pwrseq/pwrseq_simple.c   | 85 
> +-
>  2 files changed, 107 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt 
> b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> index ce0e76749671..a8c3f13ee83f 100644
> --- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> @@ -1,11 +1,17 @@
> -* The simple MMC power sequence provider
> +* The simple power sequence provider
>  
> -The purpose of the simple MMC power sequence provider is to supports a set of
> +The purpose of the simple power sequence provider is to supports a set of
>  common properties between various SOC designs. It thus enables us to use the
>  same provider for several SOC designs.
>  
> -Required properties:
> -- compatible : contains "mmc-pwrseq-simple".
> +The driver supports two types of bindings:
> +1. Separate node
> +   Required properties:
> +   - compatible : contains "mmc-pwrseq-simple".

Please note that this is not recommended for new users.

> +
> +2. Property for any node
> +   Required properties:
> +   - power-sequence
>  
>  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.

>  
>  Example:
>  
> @@ -24,4 +31,18 @@ Example:
>   reset-gpios = < 12 GPIO_ACTIVE_LOW>;
>   clocks = <_32768_ck>;
>   clock-names = "ext_clock";
> + ext-supply = <>;
>   }
> +
> + usb3503@08 {
> + compatible = "smsc,usb3503";
> + reg = <0x08>;
> +
> + intn-gpios = < 0 GPIO_ACTIVE_HIGH>;
> + connect-gpios = < 4 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
> + initial-mode = <1>;
> +
> + power-sequence;
> + ext-supply = <_reg>;
> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Greg KH]

On Thu, Jun 02, 2016 at 06:32:42PM +, mario_limoncie...@dell.com wrote:
> > And you want to check this for all Dell devices?  Please be model
> > specific, I doubt a bunch of Dell servers wants to run this code...
> > 
> 
> Tracking model specific is really going to turn into a giant list never 
> ending list.
> To drill down more specifically, I can match on chassis too.

Yes, as this is a vendor/platform-specific "quirk", you will have to
update it for each and every individual device you want it enabled as it
is so different from what all other drivers do.

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

Offer

[Pedro Quezada]

You are a recipient to Mr Pedro Quezada Donation of 2M USD. Contact 
(qpedro...@gmail.com) for claims.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rob Herring]

On Wed, Jun 01, 2016 at 12:29:59PM +0800, Wenyou Yang wrote:
> 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 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  |  5 +-
>  drivers/usb/host/ohci-at91.c   | 80 
> +-
>  include/soc/at91/at91_sfr.h| 29 
>  3 files changed, 111 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..3e3e58a 100644
> --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> @@ -3,8 +3,9 @@ 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 SAMA5D2 which can force to suspend.

That may be why you need this now, but that is irrelevant to having a 
chip specific compatible string.

Rob
--
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: musbhsdma: Add space after that ','.

[Bin Liu]

Hi,

On Wed, Jun 01, 2016 at 09:49:35AM -0400, Sandhya Bankar wrote:
> Add space after that ','.
> 
> Signed-off-by: Sandhya Bankar 

Please revise the subject prefix to "usb: musb: musbhsdma: ...".

Regards,
-Bin.
--
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: musb_host: Use sizeof(*qh)instead of sizeof *qh.

[Bin Liu]

Hi,

On Wed, Jun 01, 2016 at 09:40:06AM -0400, Sandhya Bankar wrote:
> Use sizeof(*qh)instead of sizeof *qh.
> 
> Signed-off-by: Sandhya Bankar 

Please revise the subject prefix to "usb: musb: host: ...".

Regards,
-Bin.

--
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] drivers/usb/phy/phy-generic.c:190: 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:   327475d7f63aa161bdc3bf7f9d693d9aafcd4518
commit: bcf4420283d1338b39773be8b487563c90986959 [64/67] usb: gadget: move 
gadget API functions to udc-core
config: arm-mvebu_v7_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 bcf4420283d1338b39773be8b487563c90986959
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: the balbi-usb/testing/next HEAD 327475d7f63aa161bdc3bf7f9d693d9aafcd4518 
builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `nop_set_peripheral':
>> drivers/usb/phy/phy-generic.c:190: undefined reference to 
>> `usb_gadget_vbus_connect'
   drivers/built-in.o: In function `nop_gpio_vbus_thread':
   drivers/usb/phy/phy-generic.c:122: undefined reference to 
`usb_gadget_vbus_connect'
>> drivers/usb/phy/phy-generic.c:133: undefined reference to 
>> `usb_gadget_vbus_disconnect'

vim +190 drivers/usb/phy/phy-generic.c

7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
127 atomic_notifier_call_chain(>phy.notifier, status,
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
128otg->gadget);
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
129 } else {
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
130 nop_set_vbus_draw(nop, 0);
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
131  
2eafe93b9 drivers/usb/phy/phy-generic.c   Maarten ter Huurne2016-02-28  
132 if (otg->gadget)
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06 
@133 usb_gadget_vbus_disconnect(otg->gadget);
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
134 status = USB_EVENT_NONE;
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
135 otg->state = OTG_STATE_B_IDLE;
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
136 nop->phy.last_event = status;
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
137  
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
138 atomic_notifier_call_chain(>phy.notifier, status,
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
139otg->gadget);
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
140 }
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
141 return IRQ_HANDLED;
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
142  }
7acc9973e drivers/usb/phy/phy-generic.c   Robert Jarzmik2014-12-06  
143  
53b6fc28e drivers/usb/phy/phy-generic.c   Sebastian Andrzej Siewior 2013-07-30  
144  int usb_gen_phy_init(struct usb_phy *phy)
2319fb88e drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
145  {
4525beeb9 drivers/usb/phy/phy-generic.c   Felipe Balbi  2014-04-16  
146 struct usb_phy_generic *nop = dev_get_drvdata(phy->dev);
2319fb88e drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
147  
58f735fe4 drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
148 if (!IS_ERR(nop->vcc)) {
58f735fe4 drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
149 if (regulator_enable(nop->vcc))
58f735fe4 drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
150 dev_err(phy->dev, "Failed to enable power\n");
58f735fe4 drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
151 }
58f735fe4 drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
152  
2319fb88e drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
153 if (!IS_ERR(nop->clk))
4d175f340 drivers/usb/phy/phy-generic.c   Mark Brown2013-08-11  
154 clk_prepare_enable(nop->clk);
2319fb88e drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
155  
168bdb88c drivers/usb/phy/phy-generic.c   Fabio Estevam 2015-02-03  
156 nop_reset(nop);
ad63ebfc3 drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
157  
2319fb88e drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
158 return 0;
2319fb88e drivers/usb/otg/nop-usb-xceiv.c Roger Quadros 2013-03-12  
159  }
53b6fc28e 

[PATCH 3/7] usb: musb: dsps: use musb register read/write wrappers instead

[Bin Liu]

musb core already exports the register read/write wrappers, so clean up
the duplication in dsps glue.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 112 +--
 1 file changed, 44 insertions(+), 68 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index eeb7d9e..2537179 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -52,30 +52,6 @@
 static const struct of_device_id musb_dsps_of_match[];
 
 /**
- * avoid using musb_readx()/musb_writex() as glue layer should not be
- * dependent on musb core layer symbols.
- */
-static inline u8 dsps_readb(const void __iomem *addr, unsigned offset)
-{
-   return __raw_readb(addr + offset);
-}
-
-static inline u32 dsps_readl(const void __iomem *addr, unsigned offset)
-{
-   return __raw_readl(addr + offset);
-}
-
-static inline void dsps_writeb(void __iomem *addr, unsigned offset, u8 data)
-{
-   __raw_writeb(data, addr + offset);
-}
-
-static inline void dsps_writel(void __iomem *addr, unsigned offset, u32 data)
-{
-   __raw_writel(data, addr + offset);
-}
-
-/**
  * DSPS musb wrapper register offset.
  * FIXME: This should be expanded to have all the wrapper registers from TI 
DSPS
  * musb ips.
@@ -223,8 +199,8 @@ static void dsps_musb_enable(struct musb *musb)
   ((musb->epmask & wrp->rxep_mask) << wrp->rxep_shift);
coremask = (wrp->usb_bitmap & ~MUSB_INTR_SOF);
 
-   dsps_writel(reg_base, wrp->epintr_set, epmask);
-   dsps_writel(reg_base, wrp->coreintr_set, coremask);
+   musb_writel(reg_base, wrp->epintr_set, epmask);
+   musb_writel(reg_base, wrp->coreintr_set, coremask);
/* start polling for ID change in dual-role idle mode */
if (musb->xceiv->otg->state == OTG_STATE_B_IDLE &&
musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
@@ -244,10 +220,10 @@ static void dsps_musb_disable(struct musb *musb)
const struct dsps_musb_wrapper *wrp = glue->wrp;
void __iomem *reg_base = musb->ctrl_base;
 
-   dsps_writel(reg_base, wrp->coreintr_clear, wrp->usb_bitmap);
-   dsps_writel(reg_base, wrp->epintr_clear,
+   musb_writel(reg_base, wrp->coreintr_clear, wrp->usb_bitmap);
+   musb_writel(reg_base, wrp->epintr_clear,
 wrp->txep_bitmap | wrp->rxep_bitmap);
-   dsps_writeb(musb->mregs, MUSB_DEVCTL, 0);
+   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
 }
 
 static void otg_timer(unsigned long _musb)
@@ -265,14 +241,14 @@ static void otg_timer(unsigned long _musb)
 * We poll because DSPS IP's won't expose several OTG-critical
 * status change events (from the transceiver) otherwise.
 */
-   devctl = dsps_readb(mregs, MUSB_DEVCTL);
+   devctl = musb_readb(mregs, MUSB_DEVCTL);
dev_dbg(musb->controller, "Poll devctl %02x (%s)\n", devctl,
usb_otg_state_string(musb->xceiv->otg->state));
 
spin_lock_irqsave(>lock, flags);
switch (musb->xceiv->otg->state) {
case OTG_STATE_A_WAIT_BCON:
-   dsps_writeb(musb->mregs, MUSB_DEVCTL, 0);
+   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
skip_session = 1;
/* fall */
 
@@ -286,13 +262,13 @@ static void otg_timer(unsigned long _musb)
MUSB_HST_MODE(musb);
}
if (!(devctl & MUSB_DEVCTL_SESSION) && !skip_session)
-   dsps_writeb(mregs, MUSB_DEVCTL, MUSB_DEVCTL_SESSION);
+   musb_writeb(mregs, MUSB_DEVCTL, MUSB_DEVCTL_SESSION);
mod_timer(>timer, jiffies +
msecs_to_jiffies(wrp->poll_timeout));
break;
case OTG_STATE_A_WAIT_VFALL:
musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
-   dsps_writel(musb->ctrl_base, wrp->coreintr_set,
+   musb_writel(musb->ctrl_base, wrp->coreintr_set,
MUSB_INTR_VBUSERROR << wrp->usb_shift);
break;
default:
@@ -315,29 +291,29 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
spin_lock_irqsave(>lock, flags);
 
/* Get endpoint interrupts */
-   epintr = dsps_readl(reg_base, wrp->epintr_status);
+   epintr = musb_readl(reg_base, wrp->epintr_status);
musb->int_rx = (epintr & wrp->rxep_bitmap) >> wrp->rxep_shift;
musb->int_tx = (epintr & wrp->txep_bitmap) >> wrp->txep_shift;
 
if (epintr)
-   dsps_writel(reg_base, wrp->epintr_status, epintr);
+   musb_writel(reg_base, wrp->epintr_status, epintr);
 
/* Get usb core interrupts */
-   usbintr = dsps_readl(reg_base, wrp->coreintr_status);
+   usbintr = musb_readl(reg_base, wrp->coreintr_status);
if (!usbintr && !epintr)
goto out;
 
musb->int_usb = (usbintr & wrp->usb_bitmap) >> 

[PATCH 6/7] usb: musb: host: add urb tracepoints

[Bin Liu]

Add urb tracepoints for host mode.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c  | 34 ++-
 drivers/usb/musb/musb_trace.h | 63 +++
 2 files changed, 71 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index c696944..644fce82 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -44,6 +44,7 @@
 
 #include "musb_core.h"
 #include "musb_host.h"
+#include "musb_trace.h"
 
 /* MUSB HOST status 22-mar-2006
  *
@@ -225,8 +226,6 @@ musb_start_urb(struct musb *musb, int is_in, struct musb_qh 
*qh)
void*buf = urb->transfer_buffer;
u32 offset = 0;
struct musb_hw_ep   *hw_ep = qh->hw_ep;
-   unsignedpipe = urb->pipe;
-   u8  address = usb_pipedevice(pipe);
int epnum = hw_ep->epnum;
 
/* initialize software qh state */
@@ -254,16 +253,7 @@ musb_start_urb(struct musb *musb, int is_in, struct 
musb_qh *qh)
len = urb->transfer_buffer_length - urb->actual_length;
}
 
-   musb_dbg(musb, "qh %p urb %p dev%d ep%d%s%s, hw_ep %d, %p/%d",
-   qh, urb, address, qh->epnum,
-   is_in ? "in" : "out",
-   ({char *s; switch (qh->type) {
-   case USB_ENDPOINT_XFER_CONTROL: s = ""; break;
-   case USB_ENDPOINT_XFER_BULK:s = "-bulk"; break;
-   case USB_ENDPOINT_XFER_ISOC:s = "-iso"; break;
-   default:s = "-intr"; break;
-   } s; }),
-   epnum, buf + offset, len);
+   trace_musb_urb_start(musb, urb);
 
/* Configure endpoint */
musb_ep_set_qh(hw_ep, is_in, qh);
@@ -314,13 +304,7 @@ static void musb_giveback(struct musb *musb, struct urb 
*urb, int status)
 __releases(musb->lock)
 __acquires(musb->lock)
 {
-   musb_dbg(musb, "complete %p %pF (%d), dev%d ep%d%s, %d/%d",
-   urb, urb->complete, status,
-   usb_pipedevice(urb->pipe),
-   usb_pipeendpoint(urb->pipe),
-   usb_pipein(urb->pipe) ? "in" : "out",
-   urb->actual_length, urb->transfer_buffer_length
-   );
+   trace_musb_urb_gb(musb, urb);
 
usb_hcd_unlink_urb_from_ep(musb->hcd, urb);
spin_unlock(>lock);
@@ -1293,6 +1277,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
 
pipe = urb->pipe;
dma = is_dma_capable() ? hw_ep->tx_channel : NULL;
+   trace_musb_urb_tx(musb, urb);
musb_dbg(musb, "OUT/TX%d end, csr %04x%s", epnum, tx_csr,
dma ? ", dma" : "");
 
@@ -1849,9 +1834,7 @@ void musb_host_rx(struct musb *musb, u8 epnum)
 
pipe = urb->pipe;
 
-   musb_dbg(musb, "<== hw %d rxcsr %04x, urb actual %d (+dma %zu)",
-   epnum, rx_csr, urb->actual_length,
-   dma ? dma->actual_len : 0);
+   trace_musb_urb_rx(musb, urb);
 
/* check for errors, concurrent stall & unlink is not really
 * handled yet! */
@@ -2201,6 +2184,8 @@ static int musb_urb_enqueue(
if (!is_host_active(musb) || !musb->is_active)
return -ENODEV;
 
+   trace_musb_urb_enq(musb, urb);
+
spin_lock_irqsave(>lock, flags);
ret = usb_hcd_link_urb_to_ep(hcd, urb);
qh = ret ? NULL : hep->hcpriv;
@@ -2437,10 +2422,7 @@ static int musb_urb_dequeue(struct usb_hcd *hcd, struct 
urb *urb, int status)
int is_in  = usb_pipein(urb->pipe);
int ret;
 
-   musb_dbg(musb, "urb=%p, dev%d ep%d%s", urb,
-   usb_pipedevice(urb->pipe),
-   usb_pipeendpoint(urb->pipe),
-   is_in ? "in" : "out");
+   trace_musb_urb_deq(musb, urb);
 
spin_lock_irqsave(>lock, flags);
ret = usb_hcd_check_unlink_urb(hcd, urb, status);
diff --git a/drivers/usb/musb/musb_trace.h b/drivers/usb/musb/musb_trace.h
index 7bed990..500dc4c 100644
--- a/drivers/usb/musb/musb_trace.h
+++ b/drivers/usb/musb/musb_trace.h
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include "musb_core.h"
 
 #define MUSB_MSG_MAX   500
@@ -149,6 +150,68 @@ TRACE_EVENT(musb_isr,
)
 );
 
+DECLARE_EVENT_CLASS(musb_urb,
+   TP_PROTO(struct musb *musb, struct urb *urb),
+   TP_ARGS(musb, urb),
+   TP_STRUCT__entry(
+   __string(name, dev_name(musb->controller))
+   __field(struct urb *, urb)
+   __field(unsigned int, pipe)
+   __field(int, status)
+   __field(unsigned int, flag)
+   __field(u32, buf_len)
+   __field(u32, actual_len)
+   ),
+   TP_fast_assign(
+   

[PATCH 7/7] usb: musb: gadget: add usb-request tracepoints

[Bin Liu]

Add usb_request tracepoints for gadget mode.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_gadget.c | 35 ---
 drivers/usb/musb/musb_trace.h  | 78 +-
 2 files changed, 91 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index d679d5c..0265ed5 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -44,6 +44,7 @@
 #include 
 
 #include "musb_core.h"
+#include "musb_trace.h"
 
 
 /* --- */
@@ -167,15 +168,7 @@ __acquires(ep->musb->lock)
if (!dma_mapping_error(>g.dev, request->dma))
unmap_dma_buffer(req, musb);
 
-   if (request->status == 0)
-   musb_dbg(musb, "%s done request %p,  %d/",
-   ep->end_point.name, request,
-   req->request.actual, req->request.length);
-   else
-   musb_dbg(musb, "%s request %p, %d/%d fault %d",
-   ep->end_point.name, request,
-   req->request.actual, req->request.length,
-   request->status);
+   trace_musb_req_gb(req);
usb_gadget_giveback_request(>ep->end_point, >request);
spin_lock(>lock);
ep->busy = busy;
@@ -449,6 +442,7 @@ void musb_g_tx(struct musb *musb, u8 epnum)
req = next_request(musb_ep);
request = >request;
 
+   trace_musb_req_tx(req);
csr = musb_readw(epio, MUSB_TXCSR);
musb_dbg(musb, "<== %s, txcsr %04x", musb_ep->end_point.name, csr);
 
@@ -847,6 +841,7 @@ void musb_g_rx(struct musb *musb, u8 epnum)
if (!req)
return;
 
+   trace_musb_req_rx(req);
request = >request;
 
csr = musb_readw(epio, MUSB_RXCSR);
@@ -892,11 +887,6 @@ void musb_g_rx(struct musb *musb, u8 epnum)
 
request->actual += musb_ep->dma->actual_len;
 
-   musb_dbg(musb, "RXCSR%d %04x, dma off, %04x, len %zu, req %p",
-   epnum, csr,
-   musb_readw(epio, MUSB_RXCSR),
-   musb_ep->dma->actual_len, request);
-
 #if defined(CONFIG_USB_INVENTRA_DMA) || defined(CONFIG_USB_TUSB_OMAP_DMA) || \
defined(CONFIG_USB_UX500_DMA)
/* Autoclear doesn't clear RxPktRdy for short packets */
@@ -1197,6 +1187,7 @@ struct usb_request *musb_alloc_request(struct usb_ep *ep, 
gfp_t gfp_flags)
request->epnum = musb_ep->current_epnum;
request->ep = musb_ep;
 
+   trace_musb_req_alloc(request);
return >request;
 }
 
@@ -1206,7 +1197,10 @@ struct usb_request *musb_alloc_request(struct usb_ep 
*ep, gfp_t gfp_flags)
  */
 void musb_free_request(struct usb_ep *ep, struct usb_request *req)
 {
-   kfree(to_musb_request(req));
+   struct musb_request *request = to_musb_request(req);
+
+   trace_musb_req_free(request);
+   kfree(request);
 }
 
 static LIST_HEAD(buffers);
@@ -1223,10 +1217,7 @@ struct free_record {
  */
 void musb_ep_restart(struct musb *musb, struct musb_request *req)
 {
-   musb_dbg(musb, "<== %s request %p len %u on hw_ep%d",
-   req->tx ? "TX/IN" : "RX/OUT",
-   >request, req->request.length, req->epnum);
-
+   trace_musb_req_start(req);
musb_ep_select(musb->mregs, req->epnum);
if (req->tx)
txstate(musb, req);
@@ -1257,7 +1248,7 @@ static int musb_gadget_queue(struct usb_ep *ep, struct 
usb_request *req,
if (request->ep != musb_ep)
return -EINVAL;
 
-   musb_dbg(musb, "<== to %s request=%p", ep->name, req);
+   trace_musb_req_enq(request);
 
/* request is mine now... */
request->request.actual = 0;
@@ -1299,9 +1290,11 @@ static int musb_gadget_dequeue(struct usb_ep *ep, struct 
usb_request *request)
int status = 0;
struct musb *musb = musb_ep->musb;
 
-   if (!ep || !request || to_musb_request(request)->ep != musb_ep)
+   if (!ep || !request || req->ep != musb_ep)
return -EINVAL;
 
+   trace_musb_req_deq(req);
+
spin_lock_irqsave(>lock, flags);
 
list_for_each_entry(r, _ep->req_list, list) {
diff --git a/drivers/usb/musb/musb_trace.h b/drivers/usb/musb/musb_trace.h
index 500dc4c..e880543 100644
--- a/drivers/usb/musb/musb_trace.h
+++ b/drivers/usb/musb/musb_trace.h
@@ -178,7 +178,7 @@ DECLARE_EVENT_CLASS(musb_urb,
usb_pipeendpoint(__entry->pipe),
usb_pipein(__entry->pipe) ? "in" : "out",
__entry->status, __entry->flag,
-   __entry->buf_len, __entry->actual_len
+   __entry->actual_len, __entry->buf_len
)
 );
 
@@ -212,6 +212,82 @@ DEFINE_EVENT(musb_urb, musb_urb_deq,
TP_ARGS(musb, urb)
 );
 

[PATCH 0/7] usb: musb: add tracepoints support for debugging

[Bin Liu]

Hi,

I have added tracepoints in musb in my local tree since a year+ ago, mainly 
used to dump register access logs for my debugging. Now I extended it to cover 
more debug cases, tracing urb, usb_request, and also converted dev_dbg() to 
tracepoints.

Please review them and let me know your comments and recommendations.

Regards,
-Bin.
---

Bin Liu (7):
  usb: musb: add tracepoints support for debugging
  usb: musb: switch dev_dbg to tracepoints
  usb: musb: dsps: use musb register read/write wrappers instead
  usb: musb: add tracepoints for register access
  usb: musb: add tracepints to dump interrupt events
  usb: musb: host: add urb tracepoints
  usb: musb: gadget: add usb-request tracepoints

 drivers/usb/musb/Makefile  |   5 +-
 drivers/usb/musb/cppi_dma.c|  36 ++---
 drivers/usb/musb/musb_core.c   |  77 +-
 drivers/usb/musb/musb_cppi41.c |   8 +-
 drivers/usb/musb/musb_debug.h  |   2 +
 drivers/usb/musb/musb_dsps.c   | 112 ++
 drivers/usb/musb/musb_gadget.c | 119 +++
 drivers/usb/musb/musb_gadget_ep0.c |  22 +--
 drivers/usb/musb/musb_host.c   | 130 +++-
 drivers/usb/musb/musb_trace.c  |  33 
 drivers/usb/musb/musb_trace.h  | 301 +
 drivers/usb/musb/musb_virthub.c|  24 ++-
 drivers/usb/musb/musbhsdma.c   |  10 +-
 13 files changed, 584 insertions(+), 295 deletions(-)
 create mode 100644 drivers/usb/musb/musb_trace.c
 create mode 100644 drivers/usb/musb/musb_trace.h

-- 
1.9.1

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

[PATCH 1/7] usb: musb: add tracepoints support for debugging

[Bin Liu]

To avoid printk() overhead while debugging, this patch implements the
foundation of tracepoints logging for musb driver to make debug
easier.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/Makefile |  5 +++-
 drivers/usb/musb/musb_debug.h |  2 ++
 drivers/usb/musb/musb_trace.c | 33 +++
 drivers/usb/musb/musb_trace.h | 53 +++
 4 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/musb/musb_trace.c
 create mode 100644 drivers/usb/musb/musb_trace.h

diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index f95befe..689d42a 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -2,9 +2,12 @@
 # for USB OTG silicon based on Mentor Graphics INVENTRA designs
 #
 
+# define_trace.h needs to know how to find our header
+CFLAGS_musb_trace.o:= -I$(src)
+
 obj-$(CONFIG_USB_MUSB_HDRC) += musb_hdrc.o
 
-musb_hdrc-y := musb_core.o
+musb_hdrc-y := musb_core.o musb_trace.o
 
 musb_hdrc-$(CONFIG_USB_MUSB_HOST)$(CONFIG_USB_MUSB_DUAL_ROLE) += 
musb_virthub.o musb_host.o
 musb_hdrc-$(CONFIG_USB_MUSB_GADGET)$(CONFIG_USB_MUSB_DUAL_ROLE) += 
musb_gadget_ep0.o musb_gadget.o
diff --git a/drivers/usb/musb/musb_debug.h b/drivers/usb/musb/musb_debug.h
index 27ba8f7..9a78877a 100644
--- a/drivers/usb/musb/musb_debug.h
+++ b/drivers/usb/musb/musb_debug.h
@@ -42,6 +42,8 @@
 #define INFO(fmt, args...) yprintk(KERN_INFO, fmt, ## args)
 #define ERR(fmt, args...) yprintk(KERN_ERR, fmt, ## args)
 
+void musb_dbg(struct musb *musb, const char *fmt, ...);
+
 #ifdef CONFIG_DEBUG_FS
 int musb_init_debugfs(struct musb *musb);
 void musb_exit_debugfs(struct musb *musb);
diff --git a/drivers/usb/musb/musb_trace.c b/drivers/usb/musb/musb_trace.c
new file mode 100644
index 000..70973d9
--- /dev/null
+++ b/drivers/usb/musb/musb_trace.c
@@ -0,0 +1,33 @@
+/*
+ * musb_trace.c - MUSB Controller Trace Support
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Bin Liu 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#define CREATE_TRACE_POINTS
+#include "musb_trace.h"
+
+void musb_dbg(struct musb *musb, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, fmt);
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   trace_musb_log(musb, );
+
+   va_end(args);
+}
diff --git a/drivers/usb/musb/musb_trace.h b/drivers/usb/musb/musb_trace.h
new file mode 100644
index 000..d4de3b3
--- /dev/null
+++ b/drivers/usb/musb/musb_trace.h
@@ -0,0 +1,53 @@
+/*
+ * musb_trace.h - MUSB Controller Trace Support
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Bin Liu 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM musb
+
+#if !defined(__MUSB_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define __MUSB_TRACE_H
+
+#include 
+#include 
+
+#define MUSB_MSG_MAX   500
+
+TRACE_EVENT(musb_log,
+   TP_PROTO(struct musb *musb, struct va_format *vaf),
+   TP_ARGS(musb, vaf),
+   TP_STRUCT__entry(
+   __string(name, dev_name(musb->controller))
+   __dynamic_array(char, msg, MUSB_MSG_MAX)
+   ),
+   TP_fast_assign(
+   __assign_str(name, dev_name(musb->controller));
+   vsnprintf(__get_str(msg), MUSB_MSG_MAX, vaf->fmt, *vaf->va);
+   ),
+   TP_printk("%s: %s", __get_str(name), __get_str(msg))
+);
+
+#endif /* __MUSB_TRACE_H */
+
+/* this part has to be here */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE musb_trace
+
+#include 
-- 
1.9.1

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

[PATCH 5/7] usb: musb: add tracepints to dump interrupt events

[Bin Liu]

This adds tracepoints to dump musb interrupt events.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c  |  4 +---
 drivers/usb/musb/musb_trace.h | 22 ++
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 910ef11..269b7da 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1607,9 +1607,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
 
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
 
-   dev_dbg(musb->controller, "** IRQ %s usb%04x tx%04x rx%04x\n",
-   is_host_active(musb) ? "host" : "peripheral",
-   musb->int_usb, musb->int_tx, musb->int_rx);
+   trace_musb_isr(musb);
 
/**
 * According to Mentor Graphics' documentation, flowchart on page 98,
diff --git a/drivers/usb/musb/musb_trace.h b/drivers/usb/musb/musb_trace.h
index 0e4cd70..7bed990 100644
--- a/drivers/usb/musb/musb_trace.h
+++ b/drivers/usb/musb/musb_trace.h
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include "musb_core.h"
 
 #define MUSB_MSG_MAX   500
 
@@ -127,6 +128,27 @@ DEFINE_EVENT(musb_regl, musb_writel,
TP_ARGS(caller, addr, offset, data)
 );
 
+TRACE_EVENT(musb_isr,
+   TP_PROTO(struct musb *musb),
+   TP_ARGS(musb),
+   TP_STRUCT__entry(
+   __string(name, dev_name(musb->controller))
+   __field(u8, int_usb)
+   __field(u16, int_tx)
+   __field(u16, int_rx)
+   ),
+   TP_fast_assign(
+   __assign_str(name, dev_name(musb->controller));
+   __entry->int_usb = musb->int_usb;
+   __entry->int_tx = musb->int_tx;
+   __entry->int_rx = musb->int_rx;
+   ),
+   TP_printk("%s: usb %02x, tx %04x, rx %04x",
+   __get_str(name), __entry->int_usb,
+   __entry->int_tx, __entry->int_rx
+   )
+);
+
 #endif /* __MUSB_TRACE_H */
 
 /* this part has to be here */
-- 
1.9.1

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

[PATCH 2/7] usb: musb: switch dev_dbg to tracepoints

[Bin Liu]

Switch dev_dbg() to tracepoint debug musb_dbg().

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/cppi_dma.c|  36 ++---
 drivers/usb/musb/musb_core.c   |  57 ++--
 drivers/usb/musb/musb_cppi41.c |   8 +--
 drivers/usb/musb/musb_gadget.c |  94 -
 drivers/usb/musb/musb_gadget_ep0.c |  22 
 drivers/usb/musb/musb_host.c   | 104 ++---
 drivers/usb/musb/musb_virthub.c|  24 -
 drivers/usb/musb/musbhsdma.c   |  10 ++--
 8 files changed, 173 insertions(+), 182 deletions(-)

diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index cc13410..70c7f9b 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -232,7 +232,7 @@ static void cppi_controller_stop(struct cppi *controller)
musb_writel(tibase, DAVINCI_RXCPPI_INTCLR_REG,
DAVINCI_DMA_ALL_CHANNELS_ENABLE);
 
-   dev_dbg(musb->controller, "Tearing down RX and TX Channels\n");
+   musb_dbg(musb, "Tearing down RX and TX Channels");
for (i = 0; i < ARRAY_SIZE(controller->tx); i++) {
/* FIXME restructure of txdma to use bds like rxdma */
controller->tx[i].last_processed = NULL;
@@ -297,13 +297,13 @@ cppi_channel_allocate(struct dma_controller *c,
 */
if (transmit) {
if (index >= ARRAY_SIZE(controller->tx)) {
-   dev_dbg(musb->controller, "no %cX%d CPPI channel\n", 
'T', index);
+   musb_dbg(musb, "no %cX%d CPPI channel", 'T', index);
return NULL;
}
cppi_ch = controller->tx + index;
} else {
if (index >= ARRAY_SIZE(controller->rx)) {
-   dev_dbg(musb->controller, "no %cX%d CPPI channel\n", 
'R', index);
+   musb_dbg(musb, "no %cX%d CPPI channel", 'R', index);
return NULL;
}
cppi_ch = controller->rx + index;
@@ -314,13 +314,13 @@ cppi_channel_allocate(struct dma_controller *c,
 * with the other DMA engine too
 */
if (cppi_ch->hw_ep)
-   dev_dbg(musb->controller, "re-allocating DMA%d %cX channel 
%p\n",
+   musb_dbg(musb, "re-allocating DMA%d %cX channel %p",
index, transmit ? 'T' : 'R', cppi_ch);
cppi_ch->hw_ep = ep;
cppi_ch->channel.status = MUSB_DMA_STATUS_FREE;
cppi_ch->channel.max_len = 0x7fff;
 
-   dev_dbg(musb->controller, "Allocate CPPI%d %cX\n", index, transmit ? 
'T' : 'R');
+   musb_dbg(musb, "Allocate CPPI%d %cX", index, transmit ? 'T' : 'R');
return _ch->channel;
 }
 
@@ -590,7 +590,7 @@ cppi_next_tx_segment(struct musb *musb, struct cppi_channel 
*tx)
length = min(n_bds * maxpacket, length);
}
 
-   dev_dbg(musb->controller, "TX DMA%d, pktSz %d %s bds %d dma 0x%llx len 
%u\n",
+   musb_dbg(musb, "TX DMA%d, pktSz %d %s bds %d dma 0x%llx len %u",
tx->index,
maxpacket,
rndis ? "rndis" : "transparent",
@@ -647,7 +647,7 @@ cppi_next_tx_segment(struct musb *musb, struct cppi_channel 
*tx)
bd->hw_options |= CPPI_ZERO_SET;
}
 
-   dev_dbg(musb->controller, "TXBD %p: nxt %08x buf %08x len %04x 
opt %08x\n",
+   musb_dbg(musb, "TXBD %p: nxt %08x buf %08x len %04x opt %08x",
bd, bd->hw_next, bd->hw_bufp,
bd->hw_off_len, bd->hw_options);
 
@@ -813,8 +813,8 @@ cppi_next_rx_segment(struct musb *musb, struct cppi_channel 
*rx, int onepacket)
 
length = min(n_bds * maxpacket, length);
 
-   dev_dbg(musb->controller, "RX DMA%d seg, maxp %d %s bds %d (cnt %d) "
-   "dma 0x%llx len %u %u/%u\n",
+   musb_dbg(musb, "RX DMA%d seg, maxp %d %s bds %d (cnt %d) "
+   "dma 0x%llx len %u %u/%u",
rx->index, maxpacket,
onepacket
? (is_rndis ? "rndis" : "onepacket")
@@ -924,7 +924,7 @@ cppi_next_rx_segment(struct musb *musb, struct cppi_channel 
*rx, int onepacket)
DAVINCI_RXCPPI_BUFCNT0_REG + (rx->index * 4))
& 0x;
if (i < (2 + n_bds)) {
-   dev_dbg(musb->controller, "bufcnt%d underrun - %d (for %d)\n",
+   musb_dbg(musb, "bufcnt%d underrun - %d (for %d)",
rx->index, i, n_bds);
musb_writel(tibase,
DAVINCI_RXCPPI_BUFCNT0_REG + (rx->index * 4),
@@ -973,7 +973,7 @@ static int cppi_channel_program(struct dma_channel *ch,
/* WARN_ON(1); */
break;
case MUSB_DMA_STATUS_UNKNOWN:
-   

[PATCH 4/7] usb: musb: add tracepoints for register access

[Bin Liu]

This adds tracepoints to musb register read/write wrappers to get
trace log for register access.

The default tacepoint log prefix here would be musb_readX/writeX(), which
is not much helpful. So here the tracepoints use __buildin_return_address(0)
to print the caller funciton name to provide more context of the
register access.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c  | 16 ++--
 drivers/usb/musb/musb_trace.h | 87 +++
 2 files changed, 100 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 214757e..910ef11 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -102,6 +102,7 @@
 #include 
 
 #include "musb_core.h"
+#include "musb_trace.h"
 
 #define TA_WAIT_BCON(m) max_t(int, (m)->a_wait_bcon, OTG_TIME_A_WAIT_BCON)
 
@@ -258,31 +259,40 @@ static u32 musb_default_busctl_offset(u8 epnum, u16 
offset)
 
 static u8 musb_default_readb(const void __iomem *addr, unsigned offset)
 {
-   return __raw_readb(addr + offset);
+   u8 data =  __raw_readb(addr + offset);
+   trace_musb_readb(__builtin_return_address(0), addr, offset, data);
+   return data;
 }
 
 static void musb_default_writeb(void __iomem *addr, unsigned offset, u8 data)
 {
+   trace_musb_writeb(__builtin_return_address(0), addr, offset, data);
__raw_writeb(data, addr + offset);
 }
 
 static u16 musb_default_readw(const void __iomem *addr, unsigned offset)
 {
-   return __raw_readw(addr + offset);
+   u16 data = __raw_readw(addr + offset);
+   trace_musb_readw(__builtin_return_address(0), addr, offset, data);
+   return data;
 }
 
 static void musb_default_writew(void __iomem *addr, unsigned offset, u16 data)
 {
+   trace_musb_writew(__builtin_return_address(0), addr, offset, data);
__raw_writew(data, addr + offset);
 }
 
 static u32 musb_default_readl(const void __iomem *addr, unsigned offset)
 {
-   return __raw_readl(addr + offset);
+   u32 data = __raw_readl(addr + offset);
+   trace_musb_readl(__builtin_return_address(0), addr, offset, data);
+   return data;
 }
 
 static void musb_default_writel(void __iomem *addr, unsigned offset, u32 data)
 {
+   trace_musb_writel(__builtin_return_address(0), addr, offset, data);
__raw_writel(data, addr + offset);
 }
 
diff --git a/drivers/usb/musb/musb_trace.h b/drivers/usb/musb/musb_trace.h
index d4de3b3..0e4cd70 100644
--- a/drivers/usb/musb/musb_trace.h
+++ b/drivers/usb/musb/musb_trace.h
@@ -40,6 +40,93 @@ TRACE_EVENT(musb_log,
TP_printk("%s: %s", __get_str(name), __get_str(msg))
 );
 
+DECLARE_EVENT_CLASS(musb_regb,
+   TP_PROTO(void *caller, const void *addr, unsigned offset, u8 data),
+   TP_ARGS(caller, addr, offset, data),
+   TP_STRUCT__entry(
+   __field(void *, caller)
+   __field(const void *, addr)
+   __field(unsigned, offset)
+   __field(u8, data)
+   ),
+   TP_fast_assign(
+   __entry->caller = caller;
+   __entry->addr = addr;
+   __entry->offset = offset;
+   __entry->data = data;
+   ),
+   TP_printk("%pS: %p + %04x: %02x",
+   __entry->caller, __entry->addr, __entry->offset, __entry->data)
+);
+
+DEFINE_EVENT(musb_regb, musb_readb,
+   TP_PROTO(void *caller, const void *addr, unsigned offset, u8 data),
+   TP_ARGS(caller, addr, offset, data)
+);
+
+DEFINE_EVENT(musb_regb, musb_writeb,
+   TP_PROTO(void *caller, const void *addr, unsigned offset, u8 data),
+   TP_ARGS(caller, addr, offset, data)
+);
+
+DECLARE_EVENT_CLASS(musb_regw,
+   TP_PROTO(void *caller, const void *addr, unsigned offset, u16 data),
+   TP_ARGS(caller, addr, offset, data),
+   TP_STRUCT__entry(
+   __field(void *, caller)
+   __field(const void *, addr)
+   __field(unsigned, offset)
+   __field(u16, data)
+   ),
+   TP_fast_assign(
+   __entry->caller = caller;
+   __entry->addr = addr;
+   __entry->offset = offset;
+   __entry->data = data;
+   ),
+   TP_printk("%pS: %p + %04x: %04x",
+   __entry->caller, __entry->addr, __entry->offset, __entry->data)
+);
+
+DEFINE_EVENT(musb_regw, musb_readw,
+   TP_PROTO(void *caller, const void *addr, unsigned offset, u16 data),
+   TP_ARGS(caller, addr, offset, data)
+);
+
+DEFINE_EVENT(musb_regw, musb_writew,
+   TP_PROTO(void *caller, const void *addr, unsigned offset, u16 data),
+   TP_ARGS(caller, addr, offset, data)
+);
+
+DECLARE_EVENT_CLASS(musb_regl,
+   TP_PROTO(void *caller, const void *addr, unsigned offset, u32 data),
+   TP_ARGS(caller, addr, offset, data),
+   TP_STRUCT__entry(
+   __field(void *, caller)
+   __field(const void *, addr)
+   __field(unsigned, offset)
+

RE: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

> I have some other questions which answers should we know:
> 
> 1) Is that AUX MAC address implemented only in customized windows Dell
> driver? Or also in "upstream" windows Realtek driver and all users of
> Realtek hw can install it (or update via next driver update)?
> 

I don't have the information on this.  Realtek will have to comment here as this
part is a black box to me.  I'm asking my internal colleagues about this too.

> 2) Can you share pseudo code or description of algorithm which decide
> MAC address for newly connected r8152 device on windows? This could help
> us to decide if something similar/same cannot be implemented also on
> linux (either in kernel or userspace). What I would like to know are
> those situations when you connect more r8152 devices (some Dell and some
> non-Dell).
> 

This is another thing I don't have the information for right now.
I can install Windows on a laptop, install the Realtek driver and experiment,
but it would be better to get this directly from Realtek if at all possible.

> > I do have a way to query if a dock is plugged in via SMM, but I doubt
> > that's what Realtek is using on the Windows side.
> 
> So there is some way to check if Dell dock is plugged, right? But what
> happen if you connect Dell dock and also non-Dell r8152 device? Can you
> distinguish which device is Dell and which non-Dell?

Yes, when querying if a Dell dock is plugged in, a "location" and "count" 
parameter is returned.  I'd have to figure out how to translate that into
what the Linux kernel sees.  Actually the information for how to do this 
is already public too.  It's in a pull request for Dock FW updating in the 
fwupd project.

https://github.com/hughsie/fwupd/pull/49/files#diff-81b55c87ce1542a18b0a4b2b228b9129R189

> 
> Anyway, I think that by SMM you mean dell smbios API call. Cannot you
> guys in Dell release documentation of all smbios calls to community?

Well dell SMBIOS API call really means to use dcdbas kernel module which
does SMM..

> Time to time you release some small parts in libsmbios project which
> then we can use for implementing useful parts in kernel (e.g. LED driver
> for controlling keyboard backlight). But there are couple of
> undocumented APIs and maybe some can also help with this problem...
> 

Releasing different bits of our SMBIOS document requires approvals.
We can't just release the whole thing as there are lots of interfaces that
aren't intended for the OS to be using.  They're used only by Dell tools.

For example we just had approval for information about querying TPM
and dock information and those are present in the fwupd pull request
for dock and TPM FW updates you see above.

If you have some API's in particular you would like more information on,
I'm happy to have internal discussion to see if we can release information
on those.

> > I'd leave that as
> > a second to last resort (last resort being move back to userspace
> > again).
> >
> > > What you definitely should not do is to change the mac for some
> > > arbitrary "first" device.  Then you are better off with the
> > > userspace proposal where you and your users have some chance to
> > > implement a sensible policy based on e.g. usb port numbers.
> >
> > OK, if I can't come up with a way to key on the device being a Dell
> > dock I'll scrap this entirely kernel approach.
> 
> E.g. PCI devices have ordinary PCI device & vendor IDs, but have Dell
> specific subsystem IDs. And via subsystem IDs we can distinguish between
> Intel graphics card on Dell laptop and on non-Dell laptop.
> 
> Does not you have some special/modified firmware in those Dell realtek
> docks (and ability to check from OS some registers)?

I think so.  Otherwise there would be all the same concerns you have outlined
with generic devices.  Like I said this part is currently a black box to me.  
I hope Realtek can publicly comment on this, or I can get some information 
from my colleagues.

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Andrew Lunn]

On Thu, Jun 02, 2016 at 07:04:32PM +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Andrew Lunn [mailto:and...@lunn.ch]
> > Sent: Thursday, June 2, 2016 2:03 PM
> > To: Limonciello, Mario 
> > Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> > ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> > u...@vger.kernel.org; pali.ro...@gmail.com; anthony.w...@canonical.com
> > Subject: Re: [PATCH v2] r8152: Add support for setting MAC to system's
> > Auxiliary MAC address
> > 
> > > > And you want to check this for all Dell devices?  Please be model
> > > > specific, I doubt a bunch of Dell servers wants to run this code...
> > > >
> > >
> > > Tracking model specific is really going to turn into a giant list never 
> > > ending
> > list.
> > > To drill down more specifically, I can match on chassis too.
> > 
> > Does Dell happen to use its own USB Vendor ID for the USB device in
> > the dock? You could go at this problem from the other direction if it
> > does have a unique vendor ID.
> > 
> >  Andrew
> 
> Unfortunately it's not a Dell specific VID/PID.  I'm asking around to find out
> if there is something else identifiable about this dock's NIC (maybe that 
> r8152 
> can query).

lsusb -v

I assume there is a USB hub in the dock, maybe that has a Dell VID?
Going one level up the USB tree hierarchy should not be too hard.

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

RE: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, June 2, 2016 2:03 PM
> To: Limonciello, Mario 
> Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; pali.ro...@gmail.com; anthony.w...@canonical.com
> Subject: Re: [PATCH v2] r8152: Add support for setting MAC to system's
> Auxiliary MAC address
> 
> > > And you want to check this for all Dell devices?  Please be model
> > > specific, I doubt a bunch of Dell servers wants to run this code...
> > >
> >
> > Tracking model specific is really going to turn into a giant list never 
> > ending
> list.
> > To drill down more specifically, I can match on chassis too.
> 
> Does Dell happen to use its own USB Vendor ID for the USB device in
> the dock? You could go at this problem from the other direction if it
> does have a unique vendor ID.
> 
>  Andrew

Unfortunately it's not a Dell specific VID/PID.  I'm asking around to find out
if there is something else identifiable about this dock's NIC (maybe that r8152 
can query).
--
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] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Pali Rohár]

On Thursday 02 June 2016 20:28:33 mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Bjørn Mork [mailto:bj...@mork.no]
> > Sent: Thursday, June 2, 2016 1:04 PM
> > To: Limonciello, Mario 
> > Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> > ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> > u...@vger.kernel.org; pali.ro...@gmail.com;
> > anthony.w...@canonical.com Subject: Re: [PATCH] r8152: Add support
> > for setting MAC to system's Auxiliary MAC address
> > 
> >  writes:
> > >> > 2) Track whether this is the first or second USB NIC plugged
> > >> > in.  Only
> > 
> > offer it
> > 
> > >> on the first NIC detected by r8152.  When the second NIC is
> > >> plugged in
> > 
> > don't
> > 
> > >> match from ACPI.
> > >> 
> > >> > There would be a question of what to do if the first NIC is
> > >> > removed and
> > >> 
> > >> added back if it should get the persistent system MAC or not.
> > >> 
> > >> > I'd say yes, just make sure that only one NIC can have it at a
> > >> > time.
> > >> 
> > >> You are going to get things very complex very quickly if you try
> > >> to do this.
> > > 
> > > It's really not that hard, track a module wide static variable
> > > whether the feature is in use.  Track in each device whether the
> > > feature was in use.  If it in use, don't assign the next device
> > > plugged in via the ACPI string.  If a device is removed that has
> > > the feature activated, change the module wide static variable.
> > 
> > Having the mac address jump around in an arbitrary way like this is
> > going to confuse the hell out of your users.  Consider what happens
> > if the user docks a laptop with an r8152 usb dongle already
> > plugged in... How are you going to explain that the dock gets some
> > other mac address in this case? How are you going to explain the
> > difference between using an r8152 based dongle and some other
> > ethernet usb dongle with your systems?
> 
> Yeah I understand the concern.  I agree that would be very confusing
> to a user.  This does need to match only on Dell docks then.
> 
> > Make it behave consistently if you're going to add this.  Which can
> > be done by specifically matching the Dell dock (doesn't it have an
> > unique Dell device ID?) and ignoring any other r8152 device.  You
> > could also choose to set the same mac for all r8152 devices. 
> > Which is fine, but will probably confuse many users.
> 
> Unfortunately there is no Dell specific VID/PID.  I checked a no-name
> dongle that used r8152 and it was the same (0bda:8153).  Maybe Hayes
> Wang can check with his Windows driver colleagues if there was
> anything else to key off when this was implemented on the Windows
> Realtek driver.  If there is something else to key off of, I'm not
> aware what it is.  I'll check with some of my colleagues too.

I have some other questions which answers should we know:

1) Is that AUX MAC address implemented only in customized windows Dell 
driver? Or also in "upstream" windows Realtek driver and all users of 
Realtek hw can install it (or update via next driver update)?

2) Can you share pseudo code or description of algorithm which decide 
MAC address for newly connected r8152 device on windows? This could help 
us to decide if something similar/same cannot be implemented also on 
linux (either in kernel or userspace). What I would like to know are 
those situations when you connect more r8152 devices (some Dell and some 
non-Dell).

> I do have a way to query if a dock is plugged in via SMM, but I doubt
> that's what Realtek is using on the Windows side.

So there is some way to check if Dell dock is plugged, right? But what 
happen if you connect Dell dock and also non-Dell r8152 device? Can you 
distinguish which device is Dell and which non-Dell?

Anyway, I think that by SMM you mean dell smbios API call. Cannot you 
guys in Dell release documentation of all smbios calls to community? 
Time to time you release some small parts in libsmbios project which 
then we can use for implementing useful parts in kernel (e.g. LED driver 
for controlling keyboard backlight). But there are couple of 
undocumented APIs and maybe some can also help with this problem... 

> I'd leave that as
> a second to last resort (last resort being move back to userspace
> again).
> 
> > What you definitely should not do is to change the mac for some
> > arbitrary "first" device.  Then you are better off with the
> > userspace proposal where you and your users have some chance to
> > implement a sensible policy based on e.g. usb port numbers.
> 
> OK, if I can't come up with a way to key on the device being a Dell
> dock I'll scrap this entirely kernel approach.

E.g. PCI devices have ordinary PCI device & vendor IDs, but have Dell 
specific subsystem IDs. And via subsystem IDs we can distinguish between 
Intel graphics card on Dell laptop and on non-Dell laptop.

Does not you have some 

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Andrew Lunn]

> > And you want to check this for all Dell devices?  Please be model
> > specific, I doubt a bunch of Dell servers wants to run this code...
> > 
> 
> Tracking model specific is really going to turn into a giant list never 
> ending list.
> To drill down more specifically, I can match on chassis too.

Does Dell happen to use its own USB Vendor ID for the USB device in
the dock? You could go at this problem from the other direction if it
does have a unique vendor ID.

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

Re: [PATCH 1/2] usb: dwc3: gadget: set xfer resource per endpoint

[John Youn]

On 6/2/2016 5:26 AM, Felipe Balbi wrote:
> 
> hi,
> 
> Felipe Balbi  writes:
>>> This reverts back to the original buggy behavior. This will fail when
>>> a SET_INTERFACE occurs multiple times.
>>>
>>> You can run testusb to see the failure:
>>> testusb -t 9 -c 5000 -s 2048 -a
>>
>> I came up with something else for this. It's still unstable and I need
>> to debug further to figure out where we're wrong. But it seems to me
>> that we're following databook down to the last comma with patch
>> below. Note that we're partially reverting your original changes and
>> adding some extra knowledge about current configuration and interface,
>> then we only reassign transfer resources if those change. Care to have a
>> look?
> 
> here's a version that passes testusb and normal enumeration with g_zero
> and g_mass_storage. After some experimenting, it seems like we should
> always MODIFY resource allocation, unless we're doing a SetConfiguration
> to the same configuration that is already chosen or a SetInterface to
> the same interface/alt-setting pair that's already being used. This is
> working for me. Can you test on your end too?

Hi Felipe,

You might be treading down a path we've already visited here :)

It looks like this patch will still fail the case with multiple
interfaces, with one or more having alt-settings. You will end up in a
situation where multiple endpoints are assigned the same transfer
resource which will cause failures.

Unfortunately I don't have an easy test outside of our test
environment that exposes this.

You could try creating a composite device. Interface #1 having a
single alt setting, interface #2 with multiple alt-settings. Start
traffic to both interfaces, then start setting different alt-settings
on interface #2.

The problem is the databook does not cover this condition. The
documentation will be fixed in 3.20a.

Ravi Babu originally reported this and you can see discussion in this
thread:

http://marc.info/?l=linux-usb=145396682025403=2

Regards,
John
--
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] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Pali Rohár]

On Thursday 02 June 2016 20:04:02 Bjørn Mork wrote:
>  writes:
> >> > 2) Track whether this is the first or second USB NIC plugged in.
> >> >  Only offer it
> >> 
> >> on the first NIC detected by r8152.  When the second NIC is
> >> plugged in don't match from ACPI.
> >> 
> >> > There would be a question of what to do if the first NIC is
> >> > removed and
> >> 
> >> added back if it should get the persistent system MAC or not.
> >> 
> >> > I'd say yes, just make sure that only one NIC can have it at a
> >> > time.
> >> 
> >> You are going to get things very complex very quickly if you try
> >> to do this.
> > 
> > It's really not that hard, track a module wide static variable
> > whether the feature is in use.  Track in each device whether the
> > feature was in use.  If it in use, don't assign the next device
> > plugged in via the ACPI string.  If a device is removed that has
> > the feature activated, change the module wide static variable.
> 
> Having the mac address jump around in an arbitrary way like this is
> going to confuse the hell out of your users.  Consider what happens
> if the user docks a laptop with an r8152 usb dongle already plugged
> in... How are you going to explain that the dock gets some other mac
> address in this case? How are you going to explain the difference
> between using an r8152 based dongle and some other ethernet usb
> dongle with your systems?
> 
> Make it behave consistently if you're going to add this.  Which can
> be done by specifically matching the Dell dock (doesn't it have an
> unique Dell device ID?) and ignoring any other r8152 device.  You
> could also choose to set the same mac for all r8152 devices.  Which
> is fine, but will probably confuse many users.
> 
> What you definitely should not do is to change the mac for some
> arbitrary "first" device.  Then you are better off with the userspace
> proposal where you and your users have some chance to implement a
> sensible policy based on e.g. usb port numbers.

This is exactly what I wanted to write, but you were faster :-)

You can connect more Dell docks (with r8152 devices) and more non-Dell 
r8152 devices in random order into Dell laptop. In any case dependent on 
connect and disconnect order, devices always must have exactly same MAC 
addresses. Otherwise there will be problems! It confuse users and also 
admins of networks...

So if kernel approach is chosen then I think there are only two solution 
those satisfy above conditions:

First one is:
* all non-Dell devices have own MAC address
* all Dell devices have (one, same) AUX MAC address

Second one is:
* all devices (Dell and also non-Dell) have own address
* AUX MAC address is never used

So what do you (netdev maintainers) think about it?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

RE: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, June 2, 2016 12:48 PM
> To: Limonciello, Mario 
> Cc: hayesw...@realtek.com; LKML ; Netdev
> ; Linux USB ;
> pali.ro...@gmail.com; anthony.w...@canonical.com
> Subject: Re: [PATCH v2] r8152: Add support for setting MAC to system's
> Auxiliary MAC address
> 
> On Thu, Jun 02, 2016 at 11:58:07AM -0500, Mario Limonciello wrote:
> > Dell systems with Type-C ports have support for a persistent system
> > specific MAC address when used with Dell Type-C docks and dongles.
> > This means a dock plugged into two different systems will show different
> > (but persistent) MAC addresses.  Dell Type-C docks and dongles use the
> > r8152 driver.
> >
> > This information for the system's persistent MAC address is burned in
> when
> > the HW is built and available under _SB\AMAC in the DSDT at runtime.
> >
> > More information about the technology is available here:
> > http://www.dell.com/support/article/us/en/04/SLN301147
> >
> > Signed-off-by: Mario Limonciello 
> > ---
> >  drivers/net/usb/r8152.c | 53
> +
> >  1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> > index 3f9f6ed..6dea542 100644
> > --- a/drivers/net/usb/r8152.c
> > +++ b/drivers/net/usb/r8152.c
> > @@ -26,6 +26,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  /* Information for net-next */
> >  #define NETNEXT_VERSION"08"
> > @@ -500,6 +502,7 @@ enum rtl8152_flags {
> > SELECTIVE_SUSPEND,
> > PHY_RESET,
> > SCHEDULE_NAPI,
> > +   MAC_PASSTHRU = 0,
> 
> Does setting that to 0 really work?  You just did this for two enum
> values, what is the compiler supposed to do?

Very silly of me.  I was rushing to send a v2.  
I'm surprised this worked.  Shouldn't be assigned to anything.

> 
> >  };
> >
> >  /* Define these values to match your device */
> > @@ -653,6 +656,7 @@ enum tx_csum_stat {
> >   */
> >  static const int multicast_filter_limit = 32;
> >  static unsigned int agg_buf_sz = 16384;
> > +static bool mac_passthru_active;
> 
> very generic name for a platform-specific feature :(

Once this is broken up into an x86 platform provided method I'll rename this 
to platform_mac_active (or something similar).

> 
> 
> >
> >  #define RTL_LIMITED_TSO_SIZE   (agg_buf_sz - sizeof(struct tx_desc) -
> \
> >  VLAN_ETH_HLEN - VLAN_HLEN)
> > @@ -1030,6 +1034,49 @@ out1:
> > return ret;
> >  }
> >
> > +static int get_auxiliary_addr(struct r8152 *tp, struct sockaddr *sa)
> 
> What about the platform mac address api that was pointed out?

I mentioned this in the cover letter - I haven't gotten a chance to move it 
over there yet.
I sent v2 before I did so that you can see what I've been doing as it was 
relevant to your
other comments.

> 
> > +{
> > +   acpi_status status;
> > +   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> > +   union acpi_object *obj;
> > +   int ret = -1;
> > +   unsigned char buf[6];
> > +
> > +   if (!dmi_name_in_vendors("Dell Inc.") || mac_passthru_active)
> > +   return -1;
> 
> Don't make up random error values, please use "real" ones.

OK.

> 
> And you want to check this for all Dell devices?  Please be model
> specific, I doubt a bunch of Dell servers wants to run this code...
> 

Tracking model specific is really going to turn into a giant list never ending 
list.
To drill down more specifically, I can match on chassis too.

> > +
> > +   /* returns _AUXMAC_#AABBCCDDEEFF# */
> > +   status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );
> > +   obj = (union acpi_object *)buffer.pointer;
> > +   if (ACPI_SUCCESS(status)) {
> > +   if (obj->type != ACPI_TYPE_BUFFER ||
> > +   obj->string.length != 0x17) {
> > +   pr_warn("r8152: get_auxiliary_addr: Invalid buffer");
> > +   goto amacout;
> > +   }
> > +   if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0) {
> > +   pr_warn("r8152: get_auxiliary_addr: Invalid header");
> > +   goto amacout;
> > +   }
> > +   ret = hex2bin(buf, obj->string.pointer + 9, 6);
> > +   if (ret < 0) {
> > +   pr_warn("r8152: get_auxiliary_addr: Invalid MAC");
> > +   goto amacout;
> > +   }
> > +   memcpy(sa->sa_data, buf, 6);
> > +   ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
> > +   netdev_info(tp->netdev, "Using system MAC address
> %pM\n",
> > +   sa->sa_data);
> > +   set_bit(MAC_PASSTHRU, >flags);
> > +   mac_passthru_active = true;
> > +   ret = 1;
> 
> 1 is not a "all is good" return value.

OK will switch 

RE: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

> -Original Message-
> From: Bjørn Mork [mailto:bj...@mork.no]
> Sent: Thursday, June 2, 2016 1:04 PM
> To: Limonciello, Mario 
> Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; pali.ro...@gmail.com; anthony.w...@canonical.com
> Subject: Re: [PATCH] r8152: Add support for setting MAC to system's
> Auxiliary MAC address
> 
>  writes:
> 
> >> > 2) Track whether this is the first or second USB NIC plugged in.  Only
> offer it
> >> on the first NIC detected by r8152.  When the second NIC is plugged in
> don't
> >> match from ACPI.
> >> > There would be a question of what to do if the first NIC is removed and
> >> added back if it should get the persistent system MAC or not.
> >> > I'd say yes, just make sure that only one NIC can have it at a time.
> >>
> >> You are going to get things very complex very quickly if you try to do 
> >> this.
> >
> > It's really not that hard, track a module wide static variable whether
> > the feature is in use.  Track in each device whether the feature was
> > in use.  If it in use, don't assign the next device plugged in via the
> > ACPI string.  If a device is removed that has the feature activated,
> > change the module wide static variable.
> 
> Having the mac address jump around in an arbitrary way like this is
> going to confuse the hell out of your users.  Consider what happens if
> the user docks a laptop with an r8152 usb dongle already plugged in...
> How are you going to explain that the dock gets some other mac address
> in this case? How are you going to explain the difference between using
> an r8152 based dongle and some other ethernet usb dongle with your
> systems?

Yeah I understand the concern.  I agree that would be very confusing
to a user.  This does need to match only on Dell docks then.

> 
> Make it behave consistently if you're going to add this.  Which can be
> done by specifically matching the Dell dock (doesn't it have an unique
> Dell device ID?) and ignoring any other r8152 device.  You could also
> choose to set the same mac for all r8152 devices.  Which is fine, but
> will probably confuse many users.

Unfortunately there is no Dell specific VID/PID.  I checked a no-name dongle
that used r8152 and it was the same (0bda:8153).  Maybe Hayes Wang can 
check with his Windows driver colleagues if there was anything else to key
off when this was implemented on the Windows Realtek driver.  If there 
is something else to key off of, I'm not aware what it is.  I'll check with 
some of my colleagues too.

I do have a way to query if a dock is plugged in via SMM, but I doubt that's
what Realtek is using on the Windows side.  I'd leave that as a second to
last resort (last resort being move back to userspace again).

> 
> What you definitely should not do is to change the mac for some
> arbitrary "first" device.  Then you are better off with the userspace
> proposal where you and your users have some chance to implement a
> sensible policy based on e.g. usb port numbers.

OK, if I can't come up with a way to key on the device being a Dell dock 
I'll scrap this entirely kernel approach.

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: [PATCH 1/2] usb: dwc3: gadget: set xfer resource per endpoint

[John Youn]

On 6/1/2016 11:38 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> John Youn  writes:
 However, I'm not aware of any issue with END_TRANSFER, could you let
 me know how to reproduce it?
>>>
>>> it's a rare and difficult bug to reproduce. If you take my testing/next
>>> (I didn't check if it happens with v4.7-rc1) - $subject and keep large
>>> mass storage transfers going on, eventually you'll see mass storage
>>> hang. After some 30s, host side will timeout and cancel all URBs and
>>> issue a bus reset. This will, in turn, cause the gadget driver to issue
>>> END_TRANSFER to a possible in-flight transfer.
>>>
>>> After Reset completion, the gadget will reenumerate and, when gadget
>>> driver queues to a bulk EP, StartTransfer will return "No Resource". The
>>> reason for that is that END_TRANSFER deallocates the resource, according
>>> to section 6.3.5.2 of 2.60a databook.
>   ^^^
>   section 6.3.2.5.2
> 

That section is only saying the resource is used by the endpoint
during the transfer, then it is "released", meaning it is not used,
upon EndTransfer or XferComplete. Theoretically another endpoint could
use that resource if it is unused. But if it is in-use by another
endpoint, it will return an error upon StartTransfer.

The assignment of resources to endpoints is not affected by the
EndTransfer or XferComplete.

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

Re: [PATCH 1/4] USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block

[Bin Liu]

Hi,

On Thu, Jun 02, 2016 at 07:31:03PM +0200, Hans de Goede wrote:
> Some SoCs have a single phy-hw-block with multiple phys, this is
> modelled by a single phy dts node, so we end up with multiple
> controller nodes with a phys property pointing to the phy-node
> of the otg-phy.
> 
> Only one of these controllers typically is an otg controller, yet we

Is it guaranteed that only one of them will be otg? 

> were checking the first controller who uses a phy from the block and
> then end up looking for a dr_mode property in e.g. the ehci controller.
> 
> Instead of looking for nodes with a phy property, look for nodes
> with a dr_mode property, so that we actually access the dr_mode property
> in a node which has it.

Quote from Documentation/devicetree/bindings/usb/generic.txt:
"- dr_mode: ...
In case this attribute isn't
passed via DT, USB DRD controllers should default to
OTG."

So it is not mandatory to define dr_mode in DT, then you wouldn't be
able to find the controller in such case.

Regards,
-Bin.

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

Re: [PATCH 1/2] usb: dwc3: gadget: set xfer resource per endpoint

[John Youn]

On 6/1/2016 11:38 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> John Youn  writes:
 However, I'm not aware of any issue with END_TRANSFER, could you let
 me know how to reproduce it?
>>>
>>> it's a rare and difficult bug to reproduce. If you take my testing/next
>>> (I didn't check if it happens with v4.7-rc1) - $subject and keep large
>>> mass storage transfers going on, eventually you'll see mass storage
>>> hang. After some 30s, host side will timeout and cancel all URBs and
>>> issue a bus reset. This will, in turn, cause the gadget driver to issue
>>> END_TRANSFER to a possible in-flight transfer.
>>>
>>> After Reset completion, the gadget will reenumerate and, when gadget
>>> driver queues to a bulk EP, StartTransfer will return "No Resource". The
>>> reason for that is that END_TRANSFER deallocates the resource, according
>>> to section 6.3.5.2 of 2.60a databook.
>   ^^^
>   section 6.3.2.5.2
> 

That section is only saying the resource is used by the endpoint
during the transfer, then it is "released", meaning it is not used,
upon EndTransfer or XferComplete. Theoretically another endpoint could
use that resource if it is unused. But if it is in-use by another
endpoint, it will return an error upon StartTransfer.

The assignment of resources to endpoints is not affected by the
EndTransfer or XferComplete.

Regards,
John
--
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] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Bjørn Mork]

 writes:

>> > 2) Track whether this is the first or second USB NIC plugged in.  Only 
>> > offer it
>> on the first NIC detected by r8152.  When the second NIC is plugged in don't
>> match from ACPI.
>> > There would be a question of what to do if the first NIC is removed and
>> added back if it should get the persistent system MAC or not.
>> > I'd say yes, just make sure that only one NIC can have it at a time.
>> 
>> You are going to get things very complex very quickly if you try to do this.
>
> It's really not that hard, track a module wide static variable whether
> the feature is in use.  Track in each device whether the feature was
> in use.  If it in use, don't assign the next device plugged in via the
> ACPI string.  If a device is removed that has the feature activated,
> change the module wide static variable.

Having the mac address jump around in an arbitrary way like this is
going to confuse the hell out of your users.  Consider what happens if
the user docks a laptop with an r8152 usb dongle already plugged in...
How are you going to explain that the dock gets some other mac address
in this case? How are you going to explain the difference between using
an r8152 based dongle and some other ethernet usb dongle with your
systems?

Make it behave consistently if you're going to add this.  Which can be
done by specifically matching the Dell dock (doesn't it have an unique
Dell device ID?) and ignoring any other r8152 device.  You could also
choose to set the same mac for all r8152 devices.  Which is fine, but
will probably confuse many users.

What you definitely should not do is to change the mac for some
arbitrary "first" device.  Then you are better off with the userspace
proposal where you and your users have some chance to implement a
sensible policy based on e.g. usb port numbers.



Bjørn
--
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: usbip: fix null pointer dereference

[Sudip Mukherjee]

We have been dereferencing udc before checking it. Lets use it after it
has been checked.

Signed-off-by: Sudip Mukherjee 
---
 drivers/usb/usbip/vudc_sysfs.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/usbip/vudc_sysfs.c b/drivers/usb/usbip/vudc_sysfs.c
index 99397fa..0ba6a06 100644
--- a/drivers/usb/usbip/vudc_sysfs.c
+++ b/drivers/usb/usbip/vudc_sysfs.c
@@ -35,14 +35,17 @@
 int get_gadget_descs(struct vudc *udc)
 {
struct vrequest *usb_req;
-   struct vep *ep0 = to_vep(udc->gadget.ep0);
-   struct usb_device_descriptor *ddesc = >dev_desc;
+   struct vep *ep0;
+   struct usb_device_descriptor *ddesc;
struct usb_ctrlrequest req;
int ret;
 
if (!udc || !udc->driver || !udc->pullup)
return -EINVAL;
 
+   ep0 = to_vep(udc->gadget.ep0);
+   ddesc = >dev_desc;
+
req.bRequestType = USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE;
req.bRequest = USB_REQ_GET_DESCRIPTOR;
req.wValue = cpu_to_le16(USB_DT_DEVICE << 8);
-- 
1.9.1

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

Re: [PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Greg KH]

On Thu, Jun 02, 2016 at 11:58:07AM -0500, Mario Limonciello wrote:
> Dell systems with Type-C ports have support for a persistent system
> specific MAC address when used with Dell Type-C docks and dongles.
> This means a dock plugged into two different systems will show different
> (but persistent) MAC addresses.  Dell Type-C docks and dongles use the
> r8152 driver.
> 
> This information for the system's persistent MAC address is burned in when
> the HW is built and available under _SB\AMAC in the DSDT at runtime.
> 
> More information about the technology is available here:
> http://www.dell.com/support/article/us/en/04/SLN301147
> 
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/net/usb/r8152.c | 53 
> +
>  1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 3f9f6ed..6dea542 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -26,6 +26,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  /* Information for net-next */
>  #define NETNEXT_VERSION  "08"
> @@ -500,6 +502,7 @@ enum rtl8152_flags {
>   SELECTIVE_SUSPEND,
>   PHY_RESET,
>   SCHEDULE_NAPI,
> + MAC_PASSTHRU = 0,

Does setting that to 0 really work?  You just did this for two enum
values, what is the compiler supposed to do?

>  };
>  
>  /* Define these values to match your device */
> @@ -653,6 +656,7 @@ enum tx_csum_stat {
>   */
>  static const int multicast_filter_limit = 32;
>  static unsigned int agg_buf_sz = 16384;
> +static bool mac_passthru_active;

very generic name for a platform-specific feature :(


>  
>  #define RTL_LIMITED_TSO_SIZE (agg_buf_sz - sizeof(struct tx_desc) - \
>VLAN_ETH_HLEN - VLAN_HLEN)
> @@ -1030,6 +1034,49 @@ out1:
>   return ret;
>  }
>  
> +static int get_auxiliary_addr(struct r8152 *tp, struct sockaddr *sa)

What about the platform mac address api that was pointed out?

> +{
> + acpi_status status;
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + union acpi_object *obj;
> + int ret = -1;
> + unsigned char buf[6];
> +
> + if (!dmi_name_in_vendors("Dell Inc.") || mac_passthru_active)
> + return -1;

Don't make up random error values, please use "real" ones.

And you want to check this for all Dell devices?  Please be model
specific, I doubt a bunch of Dell servers wants to run this code...

> +
> + /* returns _AUXMAC_#AABBCCDDEEFF# */
> + status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );
> + obj = (union acpi_object *)buffer.pointer;
> + if (ACPI_SUCCESS(status)) {
> + if (obj->type != ACPI_TYPE_BUFFER ||
> + obj->string.length != 0x17) {
> + pr_warn("r8152: get_auxiliary_addr: Invalid buffer");
> + goto amacout;
> + }
> + if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0) {
> + pr_warn("r8152: get_auxiliary_addr: Invalid header");
> + goto amacout;
> + }
> + ret = hex2bin(buf, obj->string.pointer + 9, 6);
> + if (ret < 0) {
> + pr_warn("r8152: get_auxiliary_addr: Invalid MAC");
> + goto amacout;
> + }
> + memcpy(sa->sa_data, buf, 6);
> + ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
> + netdev_info(tp->netdev, "Using system MAC address %pM\n",
> + sa->sa_data);
> + set_bit(MAC_PASSTHRU, >flags);
> + mac_passthru_active = true;
> + ret = 1;

1 is not a "all is good" return value.

> + }
> +
> +amacout:
> + kfree(obj);
> + return ret;
> +}
> +
>  static int set_ethernet_addr(struct r8152 *tp)
>  {
>   struct net_device *dev = tp->netdev;
> @@ -1041,6 +1088,10 @@ static int set_ethernet_addr(struct r8152 *tp)
>   else
>   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
>  
> + /* if system provides auxiliary MAC address */
> + if (get_auxiliary_addr(tp, ))
> + ret = 0;

ret = my_dell_specific_function();

But again, I don't like this, but I'm not the network subsystem
maintainer, I'll defer to them as to if this is something they want in
individual drivers...

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

[PATCH 3/4] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

[Hans de Goede]

The A31 companion pmic (axp221) does not generate vbus change interrupts
when the board is driving vbus, so we must poll when using the pmic for
vbus-det _and_ we're driving vbus.

Signed-off-by: Hans de Goede 
---
 drivers/phy/phy-sun4i-usb.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 1ea71f5..2247cf2 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -95,6 +95,7 @@
 
 enum sun4i_usb_phy_type {
sun4i_a10_phy,
+   sun6i_a31_phy,
sun8i_a33_phy,
sun8i_h3_phy,
 };
@@ -125,7 +126,6 @@ struct sun4i_usb_phy_data {
/* phy0 / otg related variables */
struct extcon_dev *extcon;
bool phy0_init;
-   bool phy0_poll;
struct gpio_desc *id_det_gpio;
struct gpio_desc *vbus_det_gpio;
struct power_supply *vbus_power_supply;
@@ -353,6 +353,24 @@ static bool sun4i_usb_phy0_have_vbus_det(struct 
sun4i_usb_phy_data *data)
return data->vbus_det_gpio || data->vbus_power_supply;
 }
 
+static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data)
+{
+   if ((data->id_det_gpio && data->id_det_irq < 0) ||
+   (data->vbus_det_gpio && data->vbus_det_irq < 0))
+   return true;
+
+   /*
+* The A31 companion pmic (axp221) does not generate vbus change
+* interrupts when the board is driving vbus, so we must poll
+* when using the pmic for vbus-det _and_ we're driving vbus.
+*/
+   if (data->cfg->type == sun6i_a31_phy &&
+   data->vbus_power_supply && data->phys[0].regulator_on)
+   return true;
+
+   return false;
+}
+
 static int sun4i_usb_phy_power_on(struct phy *_phy)
 {
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
@@ -374,7 +392,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy->regulator_on = true;
 
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
-   if (phy->index == 0 && data->vbus_det_gpio && data->phy0_poll)
+   if (phy->index == 0 && sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, DEBOUNCE_TIME);
 
return 0;
@@ -395,7 +413,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
 * phy0 vbus typically slowly discharges, sometimes this causes the
 * Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
 */
-   if (phy->index == 0 && data->vbus_det_gpio && !data->phy0_poll)
+   if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
mod_delayed_work(system_wq, >detect, POLL_TIME);
 
return 0;
@@ -481,7 +499,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
if (vbus_notify)
extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
 
-   if (data->phy0_poll)
+   if (sun4i_usb_phy0_poll(data))
queue_delayed_work(system_wq, >detect, POLL_TIME);
 }
 
@@ -666,11 +684,6 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
}
 
data->id_det_irq = gpiod_to_irq(data->id_det_gpio);
-   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
-   if ((data->id_det_gpio && data->id_det_irq < 0) ||
-   (data->vbus_det_gpio && data->vbus_det_irq < 0))
-   data->phy0_poll = true;
-
if (data->id_det_irq >= 0) {
ret = devm_request_irq(dev, data->id_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -682,6 +695,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
}
}
 
+   data->vbus_det_irq = gpiod_to_irq(data->vbus_det_gpio);
if (data->vbus_det_irq >= 0) {
ret = devm_request_irq(dev, data->vbus_det_irq,
sun4i_usb_phy0_id_vbus_det_irq,
@@ -733,7 +747,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.num_phys = 3,
-   .type = sun4i_a10_phy,
+   .type = sun6i_a31_phy,
.disc_thresh = 3,
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
-- 
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 1/4] USB: Fix of_usb_get_dr_mode_by_phy with a shared phy block

[Hans de Goede]

Some SoCs have a single phy-hw-block with multiple phys, this is
modelled by a single phy dts node, so we end up with multiple
controller nodes with a phys property pointing to the phy-node
of the otg-phy.

Only one of these controllers typically is an otg controller, yet we
were checking the first controller who uses a phy from the block and
then end up looking for a dr_mode property in e.g. the ehci controller.

Instead of looking for nodes with a phy property, look for nodes
with a dr_mode property, so that we actually access the dr_mode property
in a node which has it.

Signed-off-by: Hans de Goede 
---
 drivers/usb/common/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index e3d0161..9806433 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -145,7 +145,7 @@ enum usb_dr_mode of_usb_get_dr_mode_by_phy(struct 
device_node *phy_np)
int err;
 
do {
-   controller = of_find_node_with_property(controller, "phys");
+   controller = of_find_node_with_property(controller, "dr_mode");
index = 0;
do {
phy = of_parse_phandle(controller, "phys", index);
-- 
2.7.4

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

[PATCH 2/4] phy-sun4i-usb: Add support for peripheral-only mode

[Hans de Goede]

Use the new of_usb_get_dr_mode_by_phy() function to get the dr_mode
from the musb controller node instead of assuming that having an id_det
gpio means otg mode, and not having one means host mode.

Implement peripheral-only mode by adding a sun4i_usb_phy0_get_id_det
helper which looks at the dr_mode, always registering our extcon and
always monitoring vbus.

If dr_mode is not specified in the dts, do not register phy0 as we then
do not know how to treat it. This is actually a good thing as this means
we will not be registering phy0 on devices where the otg controller is
not enabled in the devicetree.

Signed-off-by: Hans de Goede 
---
 drivers/phy/phy-sun4i-usb.c | 62 ++---
 1 file changed, 42 insertions(+), 20 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index bae54f7..1ea71f5 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define REG_ISCR   0x00
@@ -109,6 +110,7 @@ struct sun4i_usb_phy_cfg {
 struct sun4i_usb_phy_data {
void __iomem *base;
const struct sun4i_usb_phy_cfg *cfg;
+   enum usb_dr_mode dr_mode;
struct mutex mutex;
struct sun4i_usb_phy {
struct phy *phy;
@@ -119,6 +121,7 @@ struct sun4i_usb_phy_data {
bool regulator_on;
int index;
} phys[MAX_PHYS];
+   int first_phy;
/* phy0 / otg related variables */
struct extcon_dev *extcon;
bool phy0_init;
@@ -285,16 +288,10 @@ static int sun4i_usb_phy_init(struct phy *_phy)
sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_DPDM_PULLUP_EN);
sun4i_usb_phy0_update_iscr(_phy, 0, ISCR_ID_PULLUP_EN);
 
-   if (data->id_det_gpio) {
-   /* OTG mode, force ISCR and cable state updates */
-   data->id_det = -1;
-   data->vbus_det = -1;
-   queue_delayed_work(system_wq, >detect, 0);
-   } else {
-   /* Host only mode */
-   sun4i_usb_phy0_set_id_detect(_phy, 0);
-   sun4i_usb_phy0_set_vbus_detect(_phy, 1);
-   }
+   /* Force ISCR and cable state updates */
+   data->id_det = -1;
+   data->vbus_det = -1;
+   queue_delayed_work(system_wq, >detect, 0);
}
 
return 0;
@@ -319,6 +316,19 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
return 0;
 }
 
+static int sun4i_usb_phy0_get_id_det(struct sun4i_usb_phy_data *data)
+{
+   switch (data->dr_mode) {
+   case USB_DR_MODE_OTG:
+   return gpiod_get_value_cansleep(data->id_det_gpio);
+   case USB_DR_MODE_HOST:
+   return 0;
+   case USB_DR_MODE_PERIPHERAL:
+   default:
+   return 1;
+   }
+}
+
 static int sun4i_usb_phy0_get_vbus_det(struct sun4i_usb_phy_data *data)
 {
if (data->vbus_det_gpio)
@@ -414,7 +424,10 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct 
work_struct *work)
struct phy *phy0 = data->phys[0].phy;
int id_det, vbus_det, id_notify = 0, vbus_notify = 0;
 
-   id_det = gpiod_get_value_cansleep(data->id_det_gpio);
+   if (phy0 == NULL)
+   return;
+
+   id_det = sun4i_usb_phy0_get_id_det(data);
vbus_det = sun4i_usb_phy0_get_vbus_det(data);
 
mutex_lock(>mutex);
@@ -501,7 +514,8 @@ static struct phy *sun4i_usb_phy_xlate(struct device *dev,
 {
struct sun4i_usb_phy_data *data = dev_get_drvdata(dev);
 
-   if (args->args[0] >= data->cfg->num_phys)
+   if (args->args[0] < data->first_phy ||
+   args->args[0] >= data->cfg->num_phys)
return ERR_PTR(-ENODEV);
 
return data->phys[args->args[0]].phy;
@@ -575,13 +589,17 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
return -EPROBE_DEFER;
}
 
-   /* vbus_det without id_det makes no sense, and is not supported */
-   if (sun4i_usb_phy0_have_vbus_det(data) && !data->id_det_gpio) {
-   dev_err(dev, "usb0_id_det missing or invalid\n");
-   return -ENODEV;
-   }
-
-   if (data->id_det_gpio) {
+   data->dr_mode = of_usb_get_dr_mode_by_phy(np);
+   switch (data->dr_mode) {
+   case USB_DR_MODE_OTG:
+   /* otg without id_det makes no sense, and is not supported */
+   if (!data->id_det_gpio) {
+   dev_err(dev, "usb0_id_det missing or invalid\n");
+   return -ENODEV;
+   }
+   /* fall through */
+   case USB_DR_MODE_HOST:
+   case USB_DR_MODE_PERIPHERAL:
data->extcon = devm_extcon_dev_allocate(dev,
sun4i_usb_phy0_cable);

[PATCH 4/4] musb: sunxi: Simplify dr_mode handling

[Hans de Goede]

phy-sun4i-usb now has proper dr_mode handling, it always registers an
extcon, and sends a notify with the mode (even when in peripheral- /
host-only mode) at least once.

So we can simply the sunxi musb glue by always registering its extcon
notifier and relying on sunxi_musb_work() to enable vbus when in
host-only mode.

This also enables host- and peripheral-only mode with vbus monitoring.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/sunxi.c | 68 ++--
 1 file changed, 25 insertions(+), 43 deletions(-)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index e7d4617..b88a2f6 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -255,12 +255,10 @@ static int sunxi_musb_init(struct musb *musb)
writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0);
 
/* Register notifier before calling phy_init() */
-   if (musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE) {
-   ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
-   if (ret)
-   goto error_reset_assert;
-   }
+   ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST,
+  >host_nb);
+   if (ret)
+   goto error_reset_assert;
 
ret = phy_init(glue->phy);
if (ret)
@@ -274,9 +272,8 @@ static int sunxi_musb_init(struct musb *musb)
return 0;
 
 error_unregister_notifier:
-   if (musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
+   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
+  >host_nb);
 error_reset_assert:
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
@@ -300,9 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
 
phy_exit(glue->phy);
 
-   if (musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
-   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
-  >host_nb);
+   extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
+  >host_nb);
 
if (test_bit(SUNXI_MUSB_FL_HAS_RESET, >flags))
reset_control_assert(glue->rst);
@@ -314,25 +310,6 @@ static int sunxi_musb_exit(struct musb *musb)
return 0;
 }
 
-static int sunxi_set_mode(struct musb *musb, u8 mode)
-{
-   struct sunxi_glue *glue = dev_get_drvdata(musb->controller->parent);
-   int ret;
-
-   if (mode == MUSB_HOST) {
-   ret = phy_power_on(glue->phy);
-   if (ret)
-   return ret;
-
-   set_bit(SUNXI_MUSB_FL_PHY_ON, >flags);
-   /* Stop musb work from turning vbus off again */
-   set_bit(SUNXI_MUSB_FL_VBUS_ON, >flags);
-   musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
-   }
-
-   return 0;
-}
-
 static void sunxi_musb_enable(struct musb *musb)
 {
struct sunxi_glue *glue = dev_get_drvdata(musb->controller->parent);
@@ -579,7 +556,6 @@ static const struct musb_platform_ops sunxi_musb_ops = {
.exit   = sunxi_musb_exit,
.enable = sunxi_musb_enable,
.disable= sunxi_musb_disable,
-   .set_mode   = sunxi_set_mode,
.fifo_offset= sunxi_musb_fifo_offset,
.ep_offset  = sunxi_musb_ep_offset,
.busctl_offset  = sunxi_musb_busctl_offset,
@@ -635,10 +611,6 @@ static int sunxi_musb_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
-   if (!glue)
-   return -ENOMEM;
-
memset(, 0, sizeof(pdata));
switch (usb_get_dr_mode(>dev)) {
 #if defined CONFIG_USB_MUSB_DUAL_ROLE || defined CONFIG_USB_MUSB_HOST
@@ -646,15 +618,13 @@ static int sunxi_musb_probe(struct platform_device *pdev)
pdata.mode = MUSB_PORT_MODE_HOST;
break;
 #endif
+#if defined CONFIG_USB_MUSB_DUAL_ROLE || defined CONFIG_USB_MUSB_GADGET
+   case USB_DR_MODE_PERIPHERAL:
+   pdata.mode = MUSB_PORT_MODE_GADGET;
+   break;
+#endif
 #ifdef CONFIG_USB_MUSB_DUAL_ROLE
case USB_DR_MODE_OTG:
-   glue->extcon = extcon_get_edev_by_phandle(>dev, 0);
-   if (IS_ERR(glue->extcon)) {
-   if (PTR_ERR(glue->extcon) == -EPROBE_DEFER)
-   return -EPROBE_DEFER;
-   dev_err(>dev, "Invalid or missing extcon\n");
-   return PTR_ERR(glue->extcon);
-   }
pdata.mode = MUSB_PORT_MODE_DUAL_ROLE;
break;
 #endif
@@ -665,6 +635,10 @@ static int 

[PATCH v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario Limonciello]

This adjusts a lot of concerns that have been raised on LKML.

Changes from v1:
 * Lots of error checking around bad ACPI data
 * Only activate on Dell system vendor DMI string
 * Use hex2bin instead of inventing a wheel
 * Copy MAC to both dev_addr and sa_data
 * Track and set only for one NIC at a time
 * If MAC lookup failed (bad ACPI data or bad return) fall back
   to regular r8152 MAC setting routine.

This has been tested with TB15, WD15 docks and Dell P/N 96NP5 dongle.
It's also been tested with two devices that use r8152 simultaneously.

Remaining discussion points:
 * Greg KH had asked this to only on machines that are known to have
   \\_SB.AMAC
 - I would rather avoid doing this because the list will just grow every
   year.  I've added lots of error checking and restricted this to Dell.
 * There was also a request to move this to an x86
   arch_get_platform_mac_address() implementation.  
 - I haven't yet done this.  If this is the right approach.
   I would like to know the proper place in arch/x86 to put this code.
   My initial thought was a new file in arch/x86/platform/intel

Mario Limonciello (1):
  r8152: Add support for setting MAC to system's Auxiliary MAC address

 drivers/net/usb/r8152.c | 53 +
 1 file changed, 53 insertions(+)

-- 
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 v2] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario Limonciello]

Dell systems with Type-C ports have support for a persistent system
specific MAC address when used with Dell Type-C docks and dongles.
This means a dock plugged into two different systems will show different
(but persistent) MAC addresses.  Dell Type-C docks and dongles use the
r8152 driver.

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

More information about the technology is available here:
http://www.dell.com/support/article/us/en/04/SLN301147

Signed-off-by: Mario Limonciello 
---
 drivers/net/usb/r8152.c | 53 +
 1 file changed, 53 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3f9f6ed..6dea542 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* Information for net-next */
 #define NETNEXT_VERSION"08"
@@ -500,6 +502,7 @@ enum rtl8152_flags {
SELECTIVE_SUSPEND,
PHY_RESET,
SCHEDULE_NAPI,
+   MAC_PASSTHRU = 0,
 };
 
 /* Define these values to match your device */
@@ -653,6 +656,7 @@ enum tx_csum_stat {
  */
 static const int multicast_filter_limit = 32;
 static unsigned int agg_buf_sz = 16384;
+static bool mac_passthru_active;
 
 #define RTL_LIMITED_TSO_SIZE   (agg_buf_sz - sizeof(struct tx_desc) - \
 VLAN_ETH_HLEN - VLAN_HLEN)
@@ -1030,6 +1034,49 @@ out1:
return ret;
 }
 
+static int get_auxiliary_addr(struct r8152 *tp, struct sockaddr *sa)
+{
+   acpi_status status;
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object *obj;
+   int ret = -1;
+   unsigned char buf[6];
+
+   if (!dmi_name_in_vendors("Dell Inc.") || mac_passthru_active)
+   return -1;
+
+   /* returns _AUXMAC_#AABBCCDDEEFF# */
+   status = acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );
+   obj = (union acpi_object *)buffer.pointer;
+   if (ACPI_SUCCESS(status)) {
+   if (obj->type != ACPI_TYPE_BUFFER ||
+   obj->string.length != 0x17) {
+   pr_warn("r8152: get_auxiliary_addr: Invalid buffer");
+   goto amacout;
+   }
+   if (strncmp(obj->string.pointer, "_AUXMAC_#", 9) != 0) {
+   pr_warn("r8152: get_auxiliary_addr: Invalid header");
+   goto amacout;
+   }
+   ret = hex2bin(buf, obj->string.pointer + 9, 6);
+   if (ret < 0) {
+   pr_warn("r8152: get_auxiliary_addr: Invalid MAC");
+   goto amacout;
+   }
+   memcpy(sa->sa_data, buf, 6);
+   ether_addr_copy(tp->netdev->dev_addr, sa->sa_data);
+   netdev_info(tp->netdev, "Using system MAC address %pM\n",
+   sa->sa_data);
+   set_bit(MAC_PASSTHRU, >flags);
+   mac_passthru_active = true;
+   ret = 1;
+   }
+
+amacout:
+   kfree(obj);
+   return ret;
+}
+
 static int set_ethernet_addr(struct r8152 *tp)
 {
struct net_device *dev = tp->netdev;
@@ -1041,6 +1088,10 @@ static int set_ethernet_addr(struct r8152 *tp)
else
ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
 
+   /* if system provides auxiliary MAC address */
+   if (get_auxiliary_addr(tp, ))
+   ret = 0;
+
if (ret < 0) {
netif_err(tp, probe, dev, "Get ether addr fail\n");
} else if (!is_valid_ether_addr(sa.sa_data)) {
@@ -4268,6 +4319,8 @@ static void rtl8152_disconnect(struct usb_interface *intf)
if (udev->state == USB_STATE_NOTATTACHED)
set_bit(RTL8152_UNPLUG, >flags);
 
+   if (test_bit(MAC_PASSTHRU, >flags))
+   mac_passthru_active = false;
netif_napi_del(>napi);
unregister_netdev(tp->netdev);
tp->rtl_ops.unload(tp);
-- 
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: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

Some of my comments are getting stale with what I've done in response to all 
these emails.
Let me send a v2 that we can better iterate on, a few comments below though.

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Thursday, June 2, 2016 11:09 AM
> To: Limonciello, Mario 
> Cc: hayesw...@realtek.com; linux-ker...@vger.kernel.org;
> net...@vger.kernel.org; linux-usb@vger.kernel.org; pali.ro...@gmail.com;
> anthony.w...@canonical.com
> Subject: Re: [PATCH] r8152: Add support for setting MAC to system's
> Auxiliary MAC address
> 
> On Thu, Jun 02, 2016 at 03:46:41PM +, mario_limoncie...@dell.com
> wrote:
> > > >
> > > > This isn't something part of ACPI - it's been added specifically for a
> > > > selection of Dell machines.
> > >
> > > Ah, but isn't ACPI supposed to be a "standard"?  :)
> > >
> >
> > Heh.
> > It's also possible to get this from an SMM routine.  Lesser of two evils to
> fetch the information this way, right? :)
> 
> Yes, but again, please only do this for machines you _know_ this value
> will be present on.  Otherwise you will end up with problems.

I'm going to send a V2, I'd like to know where and how this could still break. 
I am having a hard time grasping this.  

> 
> > > And please wrap your email lines, there is a "standard" for that...
> >
> > I'm unfortunately not limited to an evil mail client at my workplace since 
> > our
> mail server migration.   My apologies, I've got it set to wrap at 76 
> characters
> and I'm trying to make it as LKML friendly as possible.
> 
> It's not working as you can see here :(

Ugh, sorry.  Stupid outlook.  It seems to only be doing it on replies.
I'll manually just chop the lines when they're around that size until I've got a
better solution.

> 
> > > > I would rather not hardcode to the specific DMI model strings of those
> > > > Dell machines as it's certainly going to be a feature that expands to
> > > > more machines.  Since it is Dell specific though, if you would rather
> > > > me just match to the sys vendor Dell Inc., that seems like a pretty
> > > > good compromise to me.
> > >
> > > You need to only do this on machines you "know" have this set to a
> correct
> > > value, otherwise if some other random BIOS happens to set that field to
> > > some random value, you will have problems.
> >
> > Pali had recommended in another message to check the buffer header.  I
> was intending to do this along with check ACPI buffer output type, and
> output size in the next revision I submitted.  By switching to hex2bin, I'll 
> also
> validate that the string has correct values (0-F or 0-f).  If somehow all of 
> that
> fails, the set_ethernet_addr  checks if the address is valid.  If it's 
> invalid it will
> generate a random one.
> 
> Why generate a random one and not just use the one that the network
> controler already provides?

That's how the flow works in r8152 already and I'm not overriding it.
Again, I'll send V2 and you'll see what I did.

> >
> > It's really not that hard, track a module wide static variable whether the
> feature is in use.  Track in each device whether the feature was in use.  If 
> it in
> use, don't assign the next device plugged in via the ACPI string.  If a 
> device is
> removed that has the feature activated, change the module wide static
> variable.
> 
> Ok, let's see the code before I say anymore about this.
> 
> > > What's wrong with a "simple" script to set the mac address from
> userspace if
> > > the user wants something like this?  Provide it as a system package and
> then
> > > no kernel changes are needed at all.  Much easier to support on your end
> > > (you don't have to maintain this odd kernel code for
> > > 10+ years), the default behavior is as Linux users expect, and your
> > > limited number of people who want this crazy behaviour can install your
> > > script if they want it.
> > >
> >
> > This was my original approach.  It involved a network manager script,
> network manager code changes to support this, and exposing this
> somewhere in a platform module (like dell-laptop).  I was told I'm better off
> doing it directly in the network module, so here I am.
> 
> Why not a small systemd unit file for this that sets things up when the
> device is found in the system?  Why mess with network manager and a
> platform kernel driver at all?  That seems very complex for such a
> simple operation where the kernel doesn't need to be involved at all,
> especially for such a "niche" product.
> 
> See this link:
>   https://wiki.archlinux.org/index.php/MAC_address_spoofing#Auto
> matically
> 

The ACPI subsystem doesn't create a sysfs node for a random buffer under _SB.
I don't think the ACPI guys would be crazy about this either.

So you need a platform kernel driver to pull this out of ACPI (or SMM) and 
expose
into userspace somewhere in the first place.  I was putting it into a random 
sysfs
attribute when I did my first attempts 

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

[Guenter Roeck]

On Thu, Jun 02, 2016 at 01:18:53PM +0300, Heikki Krogerus wrote:
> On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote:
> > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > > Just noticed that the "active" file is for now read only, but it needs
> > > > to be changed to writable. That file will of course provide means for
> > > > the userspace to Exit and Enter modes. But please note that the
> > > > responsibility of the dependencies between the modes, say, if a plug
> > > > needs to be in one mode or the other in order for the partner to enter
> > > > some specific mode, will fall on the Alternate Mode specific drivers
> > > > once we have the altmode bus. I remember there were concerns about
> > > > this in the original thread.
> > > 
> > > There's one thing we haven't touched upon yet. And I cannot really find
> > > an answer in the spec.
> > > 
> > > What do we do if we return from S4 or S3? I think we need to restore
> > > the ALternate Mode because our display may be running over that
> > > Alternate Mode.
> > > If we want to support USB persist we also need to restore data role
> > > after S4.
> > > 
> > I don't have an answer ... but another interesting question.
> > 
> > How do we distinguish between alternate modes supported by a host vs.
> > alternate modes supported by a sink ? typec_capability includes a pointer
> > to alternate modes supportedf by the connector, but it is not clear if
> > those are alternate modes supported as host, or alternate modes supported
> > as device, or alternate modes supported by both.
> > 
> > This doesn't matter much if only a fixed role is supported, but it does 
> > matter
> > for dual role ports. A laptop will typically only support DisplayPort as 
> > host,
> > for example.
> 
> The DP alternate mode spec actually separates the display role from
> Type-C role. A laptop most likely would only support the modes for
> display host roles, but if the port was DRP port then it would still
> do so in both Type-C roles.
> 
> So basically, even if the display was Type-C host, it would still work
> as a display when attached to the laptop.
> 
> > Any idea ?
> 
> I'm actually not sure this is a problem.
> 
Yes, this was a bad example, since the DisplayPort mode vdo includes a flag
indicating if the port supports source, sink, or both.

Let's use a different example:
Google devices (such as power adapters) have mode '1' for firmware upgrades.
Obviously hosts will support that, but what should the host advertise if it
is configured as sink ?

Maybe this is just my personal confusion, and there is no real problem.
It might as well be that the Google mode VDO _should_ include a flag
indicating if the port supports updating the partner, and/or if it supports
being updated. For now I'll just assume that this is the case.

Something else, which goes back into the symlink question. If I create the
alternate mode devices before calling typec_register_port(), the devices won't
have a parent and don't show up in the class directory. You previously solved
that with the symlink. I am trying to solve it in my current code by calling
typec_register_altmodes() from typec_register_port() - primarily because I
don't really want to duplicate all the device creation code in my driver.

In my test case, this gives me
/sys/class/type-c/usbc0/
usbc0.svid:18d1
usbc0.svid:18d1/mode0
usbc0.svid:18d1/mode0/vdo
usbc0.svid:18d1/mode0/description
usbc0.svid:18d1/mode0/active
...
usbc0.svid:ff01
usbc0.svid:ff01/mode0/vdo
usbc0.svid:ff01/mode0/description
usbc0.svid:ff01/mode0/active

in addition to
/sys/class/type-c/usbc0/
usbc0-partner/usbc0-partner.svid:05ac
usbc0-partner/usbc0-partner.svid:05ac/mode0
usbc0-partner/usbc0-partner.svid:05ac/mode0/vdo
usbc0-partner/usbc0-partner.svid:05ac/mode0/description
usbc0-partner/usbc0-partner.svid:05ac/mode0/active
usbc0-partner/usbc0-partner.svid:05ac/mode1
usbc0-partner/usbc0-partner.svid:05ac/mode1/vdo
usbc0-partner/usbc0-partner.svid:05ac/mode1/description
usbc0-partner/usbc0-partner.svid:05ac/mode1/active
...
usbc0-partner/usbc0-partner.svid:ff01
usbc0-partner/usbc0-partner.svid:ff01/mode0
usbc0-partner/usbc0-partner.svid:ff01/mode0/vdo
usbc0-partner/usbc0-partner.svid:ff01/mode0/description
usbc0-partner/usbc0-partner.svid:ff01/mode0/active

(when connecting the Apple adapter), which is exactly what I would expect to 
see.

Is this sensible ? Do we have a reason for expecting the alternate mode
_devices_ to be created (without parent) when calling typec_register_port() ?

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  

Re: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Greg KH]

On Thu, Jun 02, 2016 at 03:46:41PM +, mario_limoncie...@dell.com wrote:
> > >
> > > This isn't something part of ACPI - it's been added specifically for a
> > > selection of Dell machines.
> > 
> > Ah, but isn't ACPI supposed to be a "standard"?  :)
> > 
> 
> Heh.
> It's also possible to get this from an SMM routine.  Lesser of two evils to 
> fetch the information this way, right? :)

Yes, but again, please only do this for machines you _know_ this value
will be present on.  Otherwise you will end up with problems.

> > And please wrap your email lines, there is a "standard" for that...
> 
> I'm unfortunately not limited to an evil mail client at my workplace since 
> our mail server migration.   My apologies, I've got it set to wrap at 76 
> characters and I'm trying to make it as LKML friendly as possible.

It's not working as you can see here :(

> > > I would rather not hardcode to the specific DMI model strings of those
> > > Dell machines as it's certainly going to be a feature that expands to
> > > more machines.  Since it is Dell specific though, if you would rather
> > > me just match to the sys vendor Dell Inc., that seems like a pretty
> > > good compromise to me.
> > 
> > You need to only do this on machines you "know" have this set to a correct
> > value, otherwise if some other random BIOS happens to set that field to
> > some random value, you will have problems.
> 
> Pali had recommended in another message to check the buffer header.  I was 
> intending to do this along with check ACPI buffer output type, and output 
> size in the next revision I submitted.  By switching to hex2bin, I'll also 
> validate that the string has correct values (0-F or 0-f).  If somehow all of 
> that fails, the set_ethernet_addr  checks if the address is valid.  If it's 
> invalid it will generate a random one.

Why generate a random one and not just use the one that the network
controler already provides?

And yes, you better error check the heck out of this before you set it.

> > > With E-docks they were really just extensions of the pins for the
> > > already onboard NIC of the system.  When you docked in an E-dock you
> > > inherently would use the same MAC everywhere you went.  If you had two
> > > cubes your network admin would see your same MAC in both.
> > >
> > > With TBT docks and this patch not present docking in different places
> > > will give you the MAC of the dock rather than something persistent
> > > that your network admin could identify.  Solving this was something
> > > that was explicitly asked for in case studies during conceptualization
> > > of these docks and is a feature present in the Realtek Windows driver.
> > 
> > But you are dealing with different "devices" here, thunderbolt is a PCI
> > device, not a "pin pass-through", and to treat it differently like you want 
> > to is
> > going to cause confusion as well.
> 
> Is it not also going to be confusing if someone boots Windows and Linux on 
> the same laptop and has a different behavior with their dock's MAC address?  
> I'm trying to get parity here for organizations that are supporting both 
> Windows and Linux for their employees.

Those few orginizations can use a userspace script for this :)

> > > In addition to limiting to Dell DMI system vendor string how about I do 
> > > two
> > more things about this:
> > >
> > > 1) Add a module parameter to disable this behavior altogether in r8152 if
> > it's not desired by the user or admin (but leave it on by default).
> > 
> > No module parameters, this isn't the 1990's anymore, and you aren't going to
> > be modifying module config files for everyone, are you?
> > 
> > And this seems like a "default" that should be turned off anyway, as it goes
> > against the model of all of our other network devices in Linux.
> > 
> > > 2) Track whether this is the first or second USB NIC plugged in.  Only 
> > > offer it
> > on the first NIC detected by r8152.  When the second NIC is plugged in don't
> > match from ACPI.
> > > There would be a question of what to do if the first NIC is removed and
> > added back if it should get the persistent system MAC or not.
> > > I'd say yes, just make sure that only one NIC can have it at a time.
> > 
> > You are going to get things very complex very quickly if you try to do this.
> 
> It's really not that hard, track a module wide static variable whether the 
> feature is in use.  Track in each device whether the feature was in use.  If 
> it in use, don't assign the next device plugged in via the ACPI string.  If a 
> device is removed that has the feature activated, change the module wide 
> static variable.

Ok, let's see the code before I say anymore about this.

> > What's wrong with a "simple" script to set the mac address from userspace if
> > the user wants something like this?  Provide it as a system package and then
> > no kernel changes are needed at all.  Much easier to support on your end
> > (you don't have to maintain this odd kernel 

Re: [PATCH 1/1] Force feedback for Fanatec Clubsport wheel

[Greg KH]

On Thu, Jun 02, 2016 at 05:00:55PM +0200, Florian Fischer wrote:
> Hi!
> 
> I am trying to add support for force feedback for the "Fanatec Clubsport
> Wheel Base V2". (More information at
> http://www.fanatec.com/eu-de/wheel-bases/clubsport-wheel-base-v2-eu-eu.html
> )
> It is a configurable racing wheel for enthusiasts.
> 
> Using a simple hack (by handling it somewhat like a Logitech G27, see
> patch below) I managed to get constant force effects working.
> However, the wheel only ever moves towards the right (no matter which
> effect direction or value is specified). Also (less important), the
> spring centering isn't turned off automatically like it is for Logitech
> wheels.
> >From looking at the kernel source, I get the impression that there's no
> real standard for HID force feedback... so is there anything I can try
> except USB debugging (which I can't) and contacting the manufacturer
> (who seem to have no interest in supporting Linux)?

You might want to send this to the linux-input mailing list, as that's
where these files are maintained.  If you use scripts/get_maintainer.pl
you will get a list of maintainers and mailing lists that are relevant.

Hope this helps,

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] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

> >
> > This isn't something part of ACPI - it's been added specifically for a
> > selection of Dell machines.
> 
> Ah, but isn't ACPI supposed to be a "standard"?  :)
> 

Heh.
It's also possible to get this from an SMM routine.  Lesser of two evils to 
fetch the information this way, right? :)

> And please wrap your email lines, there is a "standard" for that...

I'm unfortunately not limited to an evil mail client at my workplace since our 
mail server migration.   My apologies, I've got it set to wrap at 76 characters 
and I'm trying to make it as LKML friendly as possible.

> 
> > I would rather not hardcode to the specific DMI model strings of those
> > Dell machines as it's certainly going to be a feature that expands to
> > more machines.  Since it is Dell specific though, if you would rather
> > me just match to the sys vendor Dell Inc., that seems like a pretty
> > good compromise to me.
> 
> You need to only do this on machines you "know" have this set to a correct
> value, otherwise if some other random BIOS happens to set that field to
> some random value, you will have problems.

Pali had recommended in another message to check the buffer header.  I was 
intending to do this along with check ACPI buffer output type, and output size 
in the next revision I submitted.  By switching to hex2bin, I'll also validate 
that the string has correct values (0-F or 0-f).  If somehow all of that fails, 
the set_ethernet_addr  checks if the address is valid.  If it's invalid it will 
generate a random one.

> 
> > > And finally, this seems odd overall given that a MAC address should
> > > be associated with the specific network device, not the overall system.
> >
> > The whole reasoning behind this is to bring the behavior that E-Docks
> > had to TBT docks.
> 
> What is "TBT"?

Thunderbolt

> 
> > With E-docks they were really just extensions of the pins for the
> > already onboard NIC of the system.  When you docked in an E-dock you
> > inherently would use the same MAC everywhere you went.  If you had two
> > cubes your network admin would see your same MAC in both.
> >
> > With TBT docks and this patch not present docking in different places
> > will give you the MAC of the dock rather than something persistent
> > that your network admin could identify.  Solving this was something
> > that was explicitly asked for in case studies during conceptualization
> > of these docks and is a feature present in the Realtek Windows driver.
> 
> But you are dealing with different "devices" here, thunderbolt is a PCI
> device, not a "pin pass-through", and to treat it differently like you want 
> to is
> going to cause confusion as well.

Is it not also going to be confusing if someone boots Windows and Linux on the 
same laptop and has a different behavior with their dock's MAC address?  I'm 
trying to get parity here for organizations that are supporting both Windows 
and Linux for their employees.

> > In addition to limiting to Dell DMI system vendor string how about I do two
> more things about this:
> >
> > 1) Add a module parameter to disable this behavior altogether in r8152 if
> it's not desired by the user or admin (but leave it on by default).
> 
> No module parameters, this isn't the 1990's anymore, and you aren't going to
> be modifying module config files for everyone, are you?
> 
> And this seems like a "default" that should be turned off anyway, as it goes
> against the model of all of our other network devices in Linux.
> 
> > 2) Track whether this is the first or second USB NIC plugged in.  Only 
> > offer it
> on the first NIC detected by r8152.  When the second NIC is plugged in don't
> match from ACPI.
> > There would be a question of what to do if the first NIC is removed and
> added back if it should get the persistent system MAC or not.
> > I'd say yes, just make sure that only one NIC can have it at a time.
> 
> You are going to get things very complex very quickly if you try to do this.

It's really not that hard, track a module wide static variable whether the 
feature is in use.  Track in each device whether the feature was in use.  If it 
in use, don't assign the next device plugged in via the ACPI string.  If a 
device is removed that has the feature activated, change the module wide static 
variable.

> 
> What's wrong with a "simple" script to set the mac address from userspace if
> the user wants something like this?  Provide it as a system package and then
> no kernel changes are needed at all.  Much easier to support on your end
> (you don't have to maintain this odd kernel code for
> 10+ years), the default behavior is as Linux users expect, and your
> limited number of people who want this crazy behaviour can install your
> script if they want it.
> 

This was my original approach.  It involved a network manager script, network 
manager code changes to support this, and exposing this somewhere in a platform 
module (like dell-laptop).  I was told I'm better off doing it directly 

Re: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Greg KH]

On Thu, Jun 02, 2016 at 02:10:37AM +, mario_limoncie...@dell.com wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Wednesday, June 1, 2016 6:06 PM
> > To: Limonciello, Mario 
> > Cc: hayesw...@realtek.com; LKML ; Netdev
> > ; Linux USB ;
> > pali.ro...@gmail.com; anthony.w...@canonical.com
> > Subject: Re: [PATCH] r8152: Add support for setting MAC to system's 
> > Auxiliary
> > MAC address
> > 
> > On Wed, Jun 01, 2016 at 04:50:44PM -0500, Mario Limonciello wrote:
> > > Dell systems with Type-C ports have support for a persistent system
> > > specific MAC address when used with Dell Type-C docks and dongles.
> > > This means a dock plugged into two different systems will show
> > > different (but persistent) MAC addresses.  Dell Type-C docks and
> > > dongles use the
> > > r8152 driver.
> > >
> > > This information for the system's persistent MAC address is burned in
> > > when the HW is built and avilable under _SB\AMAC in the DSDT at runtime.
> > >
> > > More information about the technology is available here:
> > > http://www.dell.com/support/article/us/en/04/SLN301147
> > >
> > > Signed-off-by: Mario Limonciello 
> > > ---
> > >  drivers/net/usb/Kconfig |  1 +
> > >  drivers/net/usb/r8152.c | 37 +
> > >  2 files changed, 38 insertions(+)
> > >
> > > diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index
> > > cdde590..c320930 100644
> > > --- a/drivers/net/usb/Kconfig
> > > +++ b/drivers/net/usb/Kconfig
> > > @@ -98,6 +98,7 @@ config USB_RTL8150
> > >  config USB_RTL8152
> > >   tristate "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
> > >   select MII
> > > + depends on ACPI
> > >   help
> > > This option adds support for Realtek RTL8152 based USB 2.0
> > > 10/100 Ethernet adapters and RTL8153 based USB 3.0 10/100/1000
> > > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index
> > > 3f9f6ed..62af3b4 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"
> > > @@ -1030,6 +1031,39 @@ out1:
> > >   return ret;
> > >  }
> > >
> > > +static u8 amac_ascii_to_hex(int c)
> > > +{
> > > + if (c <= 0x39)
> > > + return (u8)(c - 0x30);
> > > + else if (c <= 0x46)
> > > + return (u8)(c - 0x37);
> > > + return (u8)(c - 0x57);
> > > +}
> > 
> > We really don't have such a function somewhere in the kernel already?
> > 
> > And why 'int', isn't "c" really a u8?
> > 
> > > +static void set_auxiliary_addr(struct sockaddr *sa) {
> > > + acpi_status status;
> > > + acpi_handle handle;
> > > + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> > > + union acpi_object *obj;
> > > + int i;
> > > + char *ptr;
> > > +
> > > + acpi_get_handle(NULL, "\\_SB", );
> > > + status = acpi_evaluate_object(handle, "AMAC", NULL, );
> > 
> > Is this field in the ACPI standard, or should this only be "trusted" on a 
> > limited
> > number of machines (i.e. with Dell DMI strings?)
> > 
> 
> This isn't something part of ACPI - it's been added specifically for a
> selection of Dell machines.  

Ah, but isn't ACPI supposed to be a "standard"?  :)

And please wrap your email lines, there is a "standard" for that...

> I would rather not hardcode to the specific DMI model strings of those
> Dell machines as it's certainly going to be a feature that expands to
> more machines.  Since it is Dell specific though, if you would rather
> me just match to the sys vendor Dell Inc., that seems like a pretty
> good compromise to me.

You need to only do this on machines you "know" have this set to a
correct value, otherwise if some other random BIOS happens to set that
field to some random value, you will have problems.

> > And finally, this seems odd overall given that a MAC address should be
> > associated with the specific network device, not the overall system.
> 
> The whole reasoning behind this is to bring the behavior that E-Docks
> had to TBT docks.

What is "TBT"?

> With E-docks they were really just extensions of the pins for the
> already onboard NIC of the system.  When you docked in an E-dock you
> inherently would use the same MAC everywhere you went.  If you had two
> cubes your network admin would see your same MAC in both.
> 
> With TBT docks and this patch not present docking in different places
> will give you the MAC of the dock rather than something persistent
> that your network admin could identify.  Solving this was something
> that was explicitly asked for in case studies during conceptualization
> of these docks and is a feature present in the Realtek Windows driver.

But you are dealing with different "devices" here, 

[PATCH v5 resend 0/2] ?hci-platform: Add support for controllers with more then one reset line

[Hans de Goede]

Here is a resend of my last version of the patch set to support usb
controllers which have multiple resets.

The shared reset controller support this depends on has landed in 4.7-rc1,
so this patch-set should be ready for merging now.

Changes in v2:
-Switch to now shared reset_[de]assert functions

Changes in v3:
-Adjust for changes to shared-reset reset-controller functions

Changes in v4:
-Fix Ugly continuation line
-Add Acked-by: Alan Stern  xxx>

Changes in v5:
-No changes, resend for merging into 4.7

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

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

[Hans de Goede]

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

diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt 
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index a12d601..0701812 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -18,7 +18,7 @@ Optional properties:
  - clocks : a list of phandle + clock specifier pairs
  - phys : phandle + phy specifier pair
  - phy-names : "usb"
- - resets : phandle + reset specifier pair
+ - resets : a list of phandle + reset specifier pairs
 
 Example (Sequoia 440EPx):
 ehci@e300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 1757ebb..f4c708f 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -39,11 +39,12 @@
 
 #define DRIVER_DESC "EHCI generic platform driver"
 #define EHCI_MAX_CLKS 3
+#define EHCI_MAX_RESETS 2
 #define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
 
 struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
-   struct reset_control *rst;
+   struct reset_control *resets[EHCI_MAX_RESETS];
struct phy **phys;
int num_phys;
bool reset_on_resume;
@@ -149,7 +150,7 @@ static int ehci_platform_probe(struct platform_device *dev)
struct usb_ehci_pdata *pdata = dev_get_platdata(>dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
-   int err, irq, phy_num, clk = 0;
+   int err, irq, phy_num, clk = 0, rst = 0;
 
if (usb_disabled())
return -ENODEV;
@@ -232,18 +233,22 @@ static int ehci_platform_probe(struct platform_device 
*dev)
break;
}
}
-   }
 
-   priv->rst = devm_reset_control_get_optional(>dev, NULL);
-   if (IS_ERR(priv->rst)) {
-   err = PTR_ERR(priv->rst);
-   if (err == -EPROBE_DEFER)
-   goto err_put_clks;
-   priv->rst = NULL;
-   } else {
-   err = reset_control_deassert(priv->rst);
-   if (err)
-   goto err_put_clks;
+   for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
+   priv->resets[rst] =
+   devm_reset_control_get_shared_by_index(
+   >dev, rst);
+   if (IS_ERR(priv->resets[rst])) {
+   err = PTR_ERR(priv->resets[rst]);
+   if (err == -EPROBE_DEFER)
+   goto err_reset;
+   priv->resets[rst] = NULL;
+   break;
+   }
+   err = reset_control_deassert(priv->resets[rst]);
+   if (err)
+   goto err_reset;
+   }
}
 
if (pdata->big_endian_desc)
@@ -300,8 +305,8 @@ err_power:
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   while (--rst >= 0)
+   reset_control_assert(priv->resets[rst]);
 err_put_clks:
while (--clk >= 0)
clk_put(priv->clks[clk]);
@@ -319,15 +324,15 @@ static int ehci_platform_remove(struct platform_device 
*dev)
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ehci_pdata *pdata = dev_get_platdata(>dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
-   int clk;
+   int clk, rst;
 
usb_remove_hcd(hcd);
 
if (pdata->power_off)
pdata->power_off(dev);
 
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   for (rst = 0; rst < EHCI_MAX_RESETS && priv->resets[rst]; rst++)
+   reset_control_assert(priv->resets[rst]);
 
for (clk = 0; clk < EHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[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 v5 resend 2/2] ohci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

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: Hans de Goede 
---
Changes in v2:
-New patch in v2 of this patch-set, to complement the identical patch for
 the ehci-platform code
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt |  2 +-
 drivers/usb/host/ohci-platform.c   | 43 --
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 19233b7..9df4569 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -14,7 +14,7 @@ Optional properties:
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
 - phy-names : "usb"
-- resets : phandle + reset specifier pair
+- resets : a list of phandle + reset specifier pairs
 
 Example:
 
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index ae1c988..898b740 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -33,11 +33,12 @@
 
 #define DRIVER_DESC "OHCI generic platform driver"
 #define OHCI_MAX_CLKS 3
+#define OHCI_MAX_RESETS 2
 #define hcd_to_ohci_priv(h) ((struct ohci_platform_priv *)hcd_to_ohci(h)->priv)
 
 struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
-   struct reset_control *rst;
+   struct reset_control *resets[OHCI_MAX_RESETS];
struct phy **phys;
int num_phys;
 };
@@ -117,7 +118,7 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_ohci_pdata *pdata = dev_get_platdata(>dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
-   int err, irq, phy_num, clk = 0;
+   int err, irq, phy_num, clk = 0, rst = 0;
 
if (usb_disabled())
return -ENODEV;
@@ -195,19 +196,21 @@ static int ohci_platform_probe(struct platform_device 
*dev)
break;
}
}
-
-   }
-
-   priv->rst = devm_reset_control_get_optional(>dev, NULL);
-   if (IS_ERR(priv->rst)) {
-   err = PTR_ERR(priv->rst);
-   if (err == -EPROBE_DEFER)
-   goto err_put_clks;
-   priv->rst = NULL;
-   } else {
-   err = reset_control_deassert(priv->rst);
-   if (err)
-   goto err_put_clks;
+   for (rst = 0; rst < OHCI_MAX_RESETS; rst++) {
+   priv->resets[rst] =
+   devm_reset_control_get_shared_by_index(
+   >dev, rst);
+   if (IS_ERR(priv->resets[rst])) {
+   err = PTR_ERR(priv->resets[rst]);
+   if (err == -EPROBE_DEFER)
+   goto err_reset;
+   priv->resets[rst] = NULL;
+   break;
+   }
+   err = reset_control_deassert(priv->resets[rst]);
+   if (err)
+   goto err_reset;
+   }
}
 
if (pdata->big_endian_desc)
@@ -265,8 +268,8 @@ err_power:
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   while (--rst >= 0)
+   reset_control_assert(priv->resets[rst]);
 err_put_clks:
while (--clk >= 0)
clk_put(priv->clks[clk]);
@@ -284,15 +287,15 @@ static int ohci_platform_remove(struct platform_device 
*dev)
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(>dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
-   int clk;
+   int clk, rst;
 
usb_remove_hcd(hcd);
 
if (pdata->power_off)
pdata->power_off(dev);
 
-   if (priv->rst)
-   reset_control_assert(priv->rst);
+   for (rst = 0; rst < OHCI_MAX_RESETS && priv->resets[rst]; rst++)
+   reset_control_assert(priv->resets[rst]);
 
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++)
clk_put(priv->clks[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

RE: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Thursday, June 2, 2016 10:01 AM
> To: Limonciello, Mario 
> Cc: pali.ro...@gmail.com; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; anthony.w...@canonical.com
> Subject: Re: [PATCH] r8152: Add support for setting MAC to system's
> Auxiliary MAC address
> 
> > >
> > > > +   pr_info("r8152: Using system auxiliary MAC address");
> > >
> > > It would be great to write also mac address into that pr_info
> 
> And since there could be multiple r8152 in the system, it would be good to
> indicate which of them is having its MAC changed. So
> netdev_info() or dev_info().
> 
>   Andrew

Thanks, will do that in next submission too.
--
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] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Andrew Lunn]

> > 
> > > + pr_info("r8152: Using system auxiliary MAC address");
> > 
> > It would be great to write also mac address into that pr_info

And since there could be multiple r8152 in the system, it would be
good to indicate which of them is having its MAC changed. So
netdev_info() or dev_info().

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

[PATCH 1/1] Force feedback for Fanatec Clubsport wheel

[Florian Fischer]

Hi!

I am trying to add support for force feedback for the "Fanatec Clubsport
Wheel Base V2". (More information at
http://www.fanatec.com/eu-de/wheel-bases/clubsport-wheel-base-v2-eu-eu.html
)
It is a configurable racing wheel for enthusiasts.

Using a simple hack (by handling it somewhat like a Logitech G27, see
patch below) I managed to get constant force effects working.
However, the wheel only ever moves towards the right (no matter which
effect direction or value is specified). Also (less important), the
spring centering isn't turned off automatically like it is for Logitech
wheels.
>From looking at the kernel source, I get the impression that there's no
real standard for HID force feedback... so is there anything I can try
except USB debugging (which I can't) and contacting the manufacturer
(who seem to have no interest in supporting Linux)?

Best regards,
  Florian


-- 
Dipl.-Inform. Florian Fischer
Würzburger Institut für Verkehrswissenschaften GmbH (WIVW)
Robert-Bosch-Str. 497209 Veitshöchheim
Tel:   0931-78009105   Fax:   0931-78009150
E-Mail: fisc...@wivw.deHomepage: www.wivw.de
Handelsregister HRB 6430 Sitz Würzburg
Umsatzsteuer ID: DE 198235088
Geschäftsführung: Dr. Armin Kaussner, Alexandra Neukum
--- original/linux-4.4.6/drivers/hid/hid-lg.c   2016-03-16 16:43:17.0 
+0100
+++ linux-4.4.6/drivers/hid/hid-lg.c2016-06-02 14:55:27.405330126 +0200
@@ -818,6 +818,9 @@
.driver_data = LG_RDESC_REL_ABS },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_SPACETRAVELLER),
.driver_data = LG_RDESC_REL_ABS },
+   // FF TEST
+   { HID_USB_DEVICE(USB_VENDOR_ID_ENDOR, 
USB_DEVICE_ID_ENDOR_CLUBSPORT_WHEEL),
+   .driver_data = LG_FF4 }, 
{ }
 };
 
--- original/linux-4.4.6/drivers/hid/hid-lg4ff.c2016-03-16 
16:43:17.0 +0100
+++ linux-4.4.6/drivers/hid/hid-lg4ff.c 2016-06-02 14:55:36.357330101 +0200
@@ -146,7 +146,8 @@
{USB_DEVICE_ID_LOGITECH_G27_WHEEL,   lg4ff_wheel_effects, 40, 900, 
lg4ff_set_range_g25},
{USB_DEVICE_ID_LOGITECH_G29_WHEEL,   lg4ff_wheel_effects, 40, 900, 
lg4ff_set_range_g25},
{USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2, lg4ff_wheel_effects, 40, 270, 
NULL},
-   {USB_DEVICE_ID_LOGITECH_WII_WHEEL,   lg4ff_wheel_effects, 40, 270, NULL}
+   {USB_DEVICE_ID_LOGITECH_WII_WHEEL,   lg4ff_wheel_effects, 40, 270, 
NULL},
+   {USB_DEVICE_ID_ENDOR_CLUBSPORT_WHEEL, lg4ff_wheel_effects, 40, 900, 
NULL} 
 };
 
 static const struct lg4ff_multimode_wheel lg4ff_multimode_wheels[] = {

RE: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

Thanks for the check.  Some small comments below, and I'll address in next 
submission.

> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Thursday, June 2, 2016 2:47 AM
> To: Limonciello, Mario 
> Cc: hayesw...@realtek.com; LKML ; Netdev
> ; Linux USB ;
> anthony.w...@canonical.com
> Subject: Re: [PATCH] r8152: Add support for setting MAC to system's
> Auxiliary MAC address
> 
> Hi! As ACPI bytecode is untrusted for me and also for running kernel, we
> should not expect that it does not contain any bugs or other problems.
> So I would propose these checks to prevent something wrong...

OK

> 
> On Wednesday 01 June 2016 16:50:44 Mario Limonciello wrote:
> > +static void set_auxiliary_addr(struct sockaddr *sa) {
> > +   acpi_status status;
> > +   acpi_handle handle;
> > +   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> > +   union acpi_object *obj;
> > +   int i;
> > +   char *ptr;
> > +
> > +   acpi_get_handle(NULL, "\\_SB", );
> 
> Check return value of acpi_get_handle
> 
> > +   status = acpi_evaluate_object(handle, "AMAC", NULL, );
> 
> This is question for ACPI devs, it is not possible to call directly?
> 
>   acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );

I tried this and it works for me.  I'll take out the stuff related to making a 
handle in the next version.

> 
> And what happen if we try to evaluate objects which do not exist? Does not
> it show some warning or error in dmesg about non existent object?
> Such errors should be silent here.
> 

I tried this with an object I knew didn't exist (like \\_SB.AMACx) and there 
was no warning or error about non existent objects.

> > +   obj = (union acpi_object *)buffer.pointer;
> 
> Check buffer.type

OK.

> 
> > +   if (ACPI_SUCCESS(status) && (obj->string.length == 0x17)) {
> > +   /* returns _AUXMAC_#AABBCCDDEEFF#
> > +* this pulls out _AUXMAC# from start and # from end
> > +*/
> > +   ptr = obj->string.pointer + 9;
> 
> Verify that string really contains that _AUXMAX# prefix. This is really 
> obscure
> and nonstandard format for specifying MAC address and in my opinion it
> should be properly checked. Nonstandard formats can be changed in future
> and we could have problems.

OK.

> 
> > +   pr_info("r8152: Using system auxiliary MAC address");
> 
> It would be great to write also mac address into that pr_info

I was originally doing this before I submitted the patch for debugging but 
didn't think there was value since it could easily be looked up.  I'll add that 
back in.

> 
> > +   for (i = 0; i < 6; i++, ptr += 2)
> > +   sa->sa_data[i] = amac_ascii_to_hex(*ptr) << 4 |
> > +amac_ascii_to_hex(*(ptr + 1));
> > +   }
> 
> In case of some acpi check fails throw warning (or error).

OK.

> 
> And there is memory leak, you allocated buffer with
> ACPI_ALLOCATE_BUFFER but you did not free it.

Alright I'll make sure to cleanup properly.

> 
> > +}
> 
> And my last question is: Are really all Dell docks comes with this one realtek
> chip? I'm pessimist in this, because I see how other components (like HDD
> vendor, touchpad type, smardcard chips, motherboards, display panels, wifi
> chips) can be different in two laptops of same Dell model.

Indeed some of those things you mention in laptops are multiple sources or 
multiple options.  I can tell you that all the docks that are enabled with this 
technology (TB15, WD15, and type-C LAN dongle PN# 96NP5) are only using the 
r8152 driver.  There is always opportunity to change this in a future 
generation of docks or dongles.  Another reply had talked about moving this to 
a platform lookup and then using that platform lookup in r8152.  I think that's 
a good approach that future proofs choosing another vendor for future docks to 
prevent extra code duplication.  Of course this can also be bolted onto any 
other USB Ethernet dongle.  If there was desire to do this with other dongles 
it could be easily added.
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

[PATCH v8] input: tablet: add Pegasus Notetaker tablet driver

[Martin Kepplinger]

This adds a driver for the Pegasus Notetaker Pen. When connected,
this uses the Pen as an input tablet.

This device was sold in various different brandings, for example
 "Pegasus Mobile Notetaker M210",
 "Genie e-note The Notetaker",
 "Staedtler Digital ballpoint pen 990 01",
 "IRISnotes Express" or
 "NEWLink Digital Note Taker".

Here's an example, so that you know what we are talking about:
http://www.genie-online.de/genie-e-note-2/

https://pegatech.blogspot.com/ seems to be a remaining official resource.

This device can also transfer saved (offline recorded handwritten) data and
there are userspace programs that do this, see https://launchpad.net/m210
(Well, alternatively there are really fast scanners out there :)

It's *really* fun to use as an input tablet though! So let's support this
for everybody.

Signed-off-by: Martin Kepplinger 
---

This only includes Dmitry's suggestions to v7. Thanks a lot for your
improvements! Tested again and I'm fine with this.

revision history

v8 set device mode in open(), not probe()
v7 add usb_driver power management
v6 minor cleanup (thanks Dmitry)
v5 fix various bugs (thanks Oliver and Dmitry)
v4 use normal work queue instead of a kernel thread (thanks to Oliver Neukum)
v3 fix reporting low pen battery and add USB list to CC
v2 minor cleanup (remove unnecessary variables)
v1 initial release


 drivers/input/tablet/Kconfig |  15 ++
 drivers/input/tablet/Makefile|   1 +
 drivers/input/tablet/pegasus_notetaker.c | 412 +++
 3 files changed, 428 insertions(+)
 create mode 100644 drivers/input/tablet/pegasus_notetaker.c

diff --git a/drivers/input/tablet/Kconfig b/drivers/input/tablet/Kconfig
index 623bb9e..a2b9f97 100644
--- a/drivers/input/tablet/Kconfig
+++ b/drivers/input/tablet/Kconfig
@@ -73,6 +73,21 @@ config TABLET_USB_KBTAB
  To compile this driver as a module, choose M here: the
  module will be called kbtab.
 
+config TABLET_USB_PEGASUS
+   tristate "Pegasus Mobile Notetaker Pen input tablet support"
+   depends on USB_ARCH_HAS_HCD
+   select USB
+   help
+ Say Y here if you want to use the Pegasus Mobile Notetaker,
+ also known as:
+ Genie e-note The Notetaker,
+ Staedtler Digital ballpoint pen 990 01,
+ IRISnotes Express or
+ NEWLink Digital Note Taker.
+
+ To compile this driver as a module, choose M here: the
+ module will be called pegasus_notetaker.
+
 config TABLET_SERIAL_WACOM4
tristate "Wacom protocol 4 serial tablet support"
select SERIO
diff --git a/drivers/input/tablet/Makefile b/drivers/input/tablet/Makefile
index 2e13010..200fc4e 100644
--- a/drivers/input/tablet/Makefile
+++ b/drivers/input/tablet/Makefile
@@ -8,4 +8,5 @@ obj-$(CONFIG_TABLET_USB_AIPTEK) += aiptek.o
 obj-$(CONFIG_TABLET_USB_GTCO)  += gtco.o
 obj-$(CONFIG_TABLET_USB_HANWANG) += hanwang.o
 obj-$(CONFIG_TABLET_USB_KBTAB) += kbtab.o
+obj-$(CONFIG_TABLET_USB_PEGASUS) += pegasus_notetaker.o
 obj-$(CONFIG_TABLET_SERIAL_WACOM4) += wacom_serial4.o
diff --git a/drivers/input/tablet/pegasus_notetaker.c 
b/drivers/input/tablet/pegasus_notetaker.c
new file mode 100644
index 000..83aa583
--- /dev/null
+++ b/drivers/input/tablet/pegasus_notetaker.c
@@ -0,0 +1,412 @@
+/*
+ * Pegasus Mobile Notetaker Pen input tablet driver
+ *
+ * Copyright (c) 2016 Martin Kepplinger 
+ */
+
+/*
+ * request packet (control endpoint):
+ * |-|
+ * | Report ID | Nr of bytes | command   |
+ * | (1 byte)  | (1 byte)| (n bytes) |
+ * |-|
+ * | 0x02  | n   |   |
+ * |-|
+ *
+ * data packet after set xy mode command, 0x80 0xb5 0x02 0x01
+ * and pen is in range:
+ *
+ * bytebyte name   value (bits)
+ * 
+ * 0   status  0 1 0 0 0 0 X X
+ * 1   color   0 0 0 0 H 0 S T
+ * 2   X low
+ * 3   X high
+ * 4   Y low
+ * 5   Y high
+ *
+ * X X battery state:
+ * no state reported   0x00
+ * battery low 0x01
+ * battery good0x02
+ *
+ * H   Hovering
+ * S   Switch 1 (pen button)
+ * T   Tip
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* USB HID defines */
+#define USB_REQ_GET_REPORT 0x01
+#define USB_REQ_SET_REPORT 0x09
+
+#define USB_VENDOR_ID_PEGASUSTECH  0x0e20
+#define USB_DEVICE_ID_PEGASUS_NOTETAKER_EN100  0x0101
+
+/* device specific defines */
+#define NOTETAKER_REPORT_ID0x02
+#define NOTETAKER_SET_CMD  0x80
+#define NOTETAKER_SET_MODE 0xb5
+
+#define NOTETAKER_LED_MOUSE 0x02
+#define PEN_MODE_XY 0x01
+
+#define SPECIAL_COMMAND0x80
+#define BUTTON_PRESSED 0xb5
+#define COMMAND_VERSION

RE: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Mario_Limonciello]

> -Original Message-
> From: Bjørn Mork [mailto:bj...@mork.no]
> Sent: Thursday, June 2, 2016 3:11 AM
> To: Limonciello, Mario 
> Cc: gre...@linuxfoundation.org; hayesw...@realtek.com; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; pali.ro...@gmail.com; anthony.w...@canonical.com
> Subject: Re: [PATCH] r8152: Add support for setting MAC to system's
> Auxiliary MAC address
> 
>  writes:
> 
> >> > +static u8 amac_ascii_to_hex(int c) {
> >> > +if (c <= 0x39)
> >> > +return (u8)(c - 0x30);
> >> > +else if (c <= 0x46)
> >> > +return (u8)(c - 0x37);
> >> > +return (u8)(c - 0x57);
> >> > +}
> >>
> >
> > Sorry forgot to address this.
> >
> >> We really don't have such a function somewhere in the kernel already?
> >
> > There is a function in acpi/acpica/uthex.c that does this, but it
> > doesn't seem to be used by anything outside of acpica so far.  Would it be
> OK style wise to #include " ../../acpi/acpica/acutils.h" from r8152.c?
> 
> Makes me wonder where you looked  You have hex_to_bin() and
> hex2bin() in include/linux/kernel.h
> 


Thank you, I completely missed that.  I wasn't looking for literals in my 
grepping.  I'll use this instead.

> You could look at usbnet_get_ethernet_addr() for an example of how to do
> this properly.  It's pretty close to this driver in the tree, and should be a
> natural starting point before reinventing the wheel...
> 

OK will do.

[PATCH v4 3/5] usb: dwc3: add phyif_utmi_quirk

[William Wu]

Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can be configured
during coreconsultant. But for some specific usb
cores(e.g. rk3399 soc dwc3), the default PHYIf
configuration value is fault, so we need to
reconfigure it by software.

And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
must be set to the corresponding value according to
the UTMI+ PHY interface.

Signed-off-by: William Wu 
---
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)

Changes in v3:
- None

Changes in v2:
- add a quirk for phyif_utmi (balbi)

 Documentation/devicetree/bindings/usb/dwc3.txt |  4 
 drivers/usb/dwc3/core.c| 19 +++
 drivers/usb/dwc3/core.h| 12 
 3 files changed, 35 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 1ada121..34d13a5 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -42,6 +42,10 @@ Optional properties:
  - snps,dis_u2_freeclk_exists_quirk: when set, clear the u2_freeclk_exists
in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
a free-running PHY clock.
+ - snps,phyif_utmi_quirk: when set core will set phyif UTMI+ interface.
+ - snps,phyif_utmi: the value to configure the core to support a UTMI+ PHY
+   with an 8- or 16-bit interface. Value 0 select 8-bit
+   interface, value 1 select 16-bit interface.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f4b18b2..30fe400 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -408,6 +408,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
 static int dwc3_phy_setup(struct dwc3 *dwc)
 {
u32 reg;
+   u32 usbtrdtim;
int ret;
 
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
@@ -503,6 +504,15 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u2_freeclk_exists_quirk)
reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
 
+   if (dwc->phyif_utmi_quirk) {
+   reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
+  DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
+   usbtrdtim = dwc->phyif_utmi ? USBTRDTIM_UTMI_16_BIT :
+   USBTRDTIM_UTMI_8_BIT;
+   reg |= DWC3_GUSB2PHYCFG_PHYIF(dwc->phyif_utmi) |
+  DWC3_GUSB2PHYCFG_USBTRDTIM(usbtrdtim);
+   }
+
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
 
return 0;
@@ -830,6 +840,7 @@ static int dwc3_probe(struct platform_device *pdev)
struct resource *res;
struct dwc3 *dwc;
u8  lpm_nyet_threshold;
+   u8  phyif_utmi;
u8  tx_de_emphasis;
u8  hird_threshold;
 
@@ -886,6 +897,9 @@ static int dwc3_probe(struct platform_device *pdev)
/* default to highest possible threshold */
lpm_nyet_threshold = 0xff;
 
+   /* default to UTMI+ 8-bit interface */
+   phyif_utmi = 0;
+
/* default to -3.5dB de-emphasis */
tx_de_emphasis = 1;
 
@@ -935,6 +949,10 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,dis_rxdet_inp3_quirk");
dwc->dis_u2_freeclk_exists_quirk = device_property_read_bool(dev,
"snps,dis_u2_freeclk_exists_quirk");
+   dwc->phyif_utmi_quirk = device_property_read_bool(dev,
+   "snps,phyif_utmi_quirk");
+   device_property_read_u8(dev, "snps,phyif_utmi",
+   _utmi);
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
@@ -946,6 +964,7 @@ static int dwc3_probe(struct platform_device *pdev)
 >fladj);
 
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
+   dwc->phyif_utmi = phyif_utmi;
dwc->tx_de_emphasis = tx_de_emphasis;
 
dwc->hird_threshold = hird_threshold
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index bcd1aa2..510a6f1 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -203,6 +203,12 @@
 #define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
 #define DWC3_GUSB2PHYCFG_ULPI_UTMI (1 << 4)
 #define DWC3_GUSB2PHYCFG_ENBLSLPM  (1 << 8)
+#define DWC3_GUSB2PHYCFG_PHYIF(n)  (n << 3)
+#define DWC3_GUSB2PHYCFG_PHYIF_MASKDWC3_GUSB2PHYCFG_PHYIF(1)
+#define 

[PATCH v4 0/5] support rockchip dwc3 driver

[William Wu]

This series add support for rockchip dwc3 driver,
and add additional optional properties for specific
platforms (e.g., rockchip rk3399 platform).

William Wu (5):
  usb: dwc3: of-simple: add compatible for rockchip
  usb: dwc3: add dis_u2_freeclk_exists_quirk
  usb: dwc3: add phyif_utmi_quirk
  usb: dwc3: add dis_del_phy_power_chg_quirk
  usb: dwc3: rockchip: add devicetree bindings documentation

 Documentation/devicetree/bindings/usb/dwc3.txt |  9 +
 .../devicetree/bindings/usb/rockchip,dwc3.txt  | 46 ++
 drivers/usb/dwc3/core.c| 29 ++
 drivers/usb/dwc3/core.h| 20 ++
 drivers/usb/dwc3/dwc3-of-simple.c  |  1 +
 5 files changed, 105 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt

-- 
1.9.1


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

[PATCH v4 1/5] usb: dwc3: of-simple: add compatible for rockchip

[William Wu]

Rockchip platform merely enable usb3 clocks and
populate its children. So we can use this generic
glue layer to support Rockchip dwc3.

Signed-off-by: William Wu 
---
Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- sort the list of_dwc3_simple_match (Doug)

 drivers/usb/dwc3/dwc3-of-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index 9743353..6da9656 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -161,6 +161,7 @@ static const struct dev_pm_ops dwc3_of_simple_dev_pm_ops = {
 
 static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "qcom,dwc3" },
+   { .compatible = "rockchip,dwc3" },
{ .compatible = "xlnx,zynqmp-dwc3" },
{ /* Sentinel */ }
 };
-- 
1.9.1


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

[PATCH v4 4/5] usb: dwc3: add dis_del_phy_power_chg_quirk

[William Wu]

Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit,
which specifies whether disable delay PHY power change
from P0 to P1/P2/P3 when link state changing from U0
to U1/U2/U3 respectively.

Signed-off-by: William Wu 
---
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)

Changes in v3:
- None

Changes in v2:
- None

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

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 34d13a5..bd5bef0 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -42,6 +42,8 @@ Optional properties:
  - snps,dis_u2_freeclk_exists_quirk: when set, clear the u2_freeclk_exists
in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
a free-running PHY clock.
+ - snps,dis_del_phy_power_chg_quirk: when set core will change PHY power
+   from P0 to P1/P2/P3 without delay.
  - snps,phyif_utmi_quirk: when set core will set phyif UTMI+ interface.
  - snps,phyif_utmi: the value to configure the core to support a UTMI+ PHY
with an 8- or 16-bit interface. Value 0 select 8-bit
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 30fe400..65b1b9f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -449,6 +449,9 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u3_susphy_quirk)
reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
 
+   if (dwc->dis_del_phy_power_chg_quirk)
+   reg &= ~DWC3_GUSB3PIPECTL_DEPOCHANGE;
+
dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
 
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
@@ -949,6 +952,8 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,dis_rxdet_inp3_quirk");
dwc->dis_u2_freeclk_exists_quirk = device_property_read_bool(dev,
"snps,dis_u2_freeclk_exists_quirk");
+   dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
+   "snps,dis_del_phy_power_chg_quirk");
dwc->phyif_utmi_quirk = device_property_read_bool(dev,
"snps,phyif_utmi_quirk");
device_property_read_u8(dev, "snps,phyif_utmi",
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 510a6f1..9481827 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -808,6 +808,8 @@ struct dwc3_scratchpad_array {
  * @dis_u2_freeclk_exists_quirk : set if we clear u2_freeclk_exists
  * in GUSB2PHYCFG, specify that USB2 PHY doesn't
  * provide a free-running PHY clock.
+ * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
+ * change quirk.
  * @phyif_utmi_quirk: set if we enable phyif UTMI+ quirk
  * @phyif_utmi: UTMI+ PHY interface value
  * 0   - 8 bits
@@ -956,6 +958,7 @@ struct dwc3 {
unsigneddis_enblslpm_quirk:1;
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
+   unsigneddis_del_phy_power_chg_quirk:1;
 
unsignedphyif_utmi_quirk:1;
unsignedphyif_utmi:1;
-- 
1.9.1


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

[PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

[William Wu]

This patch adds the devicetree documentation required for Rockchip
USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.

It supports DRD mode, and could operate in device mode (SS, HS, FS)
and host mode (SS, HS, FS, LS).

Signed-off-by: William Wu 
---
Changes in v4:
- modify commit log, and add phy documentation location (Sergei)

Changes in v3:
- add dwc3 address (balbi)

Changes in v2:
- add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (balbi, Brian)

 .../devicetree/bindings/usb/rockchip,dwc3.txt  | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt

diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt 
b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
new file mode 100644
index 000..0edf013
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
@@ -0,0 +1,46 @@
+Rockchip SuperSpeed DWC3 USB SoC controller
+
+Required properties:
+- compatible:  should contain "rockchip,dwc3"
+- clocks:  A list of phandle + clock-specifier pairs for the
+   clocks listed in clock-names
+- clock-names: Should contain the following:
+  "clk_usb3otg0_ref"   Controller reference clk
+  "clk_usb3otg0_suspend"Controller suspend clk, can use 24 MHz or 32 KHz
+  "aclk_usb3"  Master/Core clock, have to be >= 62.5 MHz for SS 
operation
+
+
+Optional clocks:
+  "aclk_usb3otg0"  Aclk for specific usb controller clock.
+  "aclk_usb3_rksoc_axi_perf"  USB AXI perf clock.  Not present on all 
platforms.
+  "aclk_usb3_grf"  USB grf clock.  Not present on all platforms.
+
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Phy documentation is provided in the following places:
+Documentation/devicetree/bindings/phy/rockchip,dwc3-usb-phy.txt
+
+Example device nodes:
+
+   usbdrd3_0: usb@fe80 {
+   compatible = "rockchip,dwc3";
+   clocks = < SCLK_USB3OTG0_REF>, < SCLK_USB3OTG0_SUSPEND>,
+< ACLK_USB3>, < ACLK_USB3OTG0>,
+< ACLK_USB3_RKSOC_AXI_PERF>, < ACLK_USB3_GRF>;
+   clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
+ "aclk_usb3", "aclk_usb3otg0",
+ "aclk_usb3_rksoc_axi_perf", "aclk_usb3_grf";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+   usbdrd_dwc3_0: dwc3@fe80 {
+   compatible = "snps,dwc3";
+   reg = <0x0 0xfe80 0x0 0x10>;
+   interrupts = ;
+   dr_mode = "otg";
+   status = "disabled";
+   };
+   };
-- 
1.9.1


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

[PATCH v4 2/5] usb: dwc3: add dis_u2_freeclk_exists_quirk

[William Wu]

Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit,
which specifies whether the USB2.0 PHY provides a free-running
PHY clock, which is active when the clock control input is active.

Signed-off-by: William Wu 
---
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)

Changes in v3:
- None

Changes in v2:
- None

 Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++
 drivers/usb/dwc3/core.c| 5 +
 drivers/usb/dwc3/core.h| 5 +
 3 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7d7ce08..1ada121 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -39,6 +39,9 @@ Optional properties:
disabling the suspend signal to the PHY.
  - snps,dis_rxdet_inp3_quirk: when set core will disable receiver detection
in PHY P3 power state.
+ - snps,dis_u2_freeclk_exists_quirk: when set, clear the u2_freeclk_exists
+   in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
+   a free-running PHY clock.
  - snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
  - snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9c4e1d8d..f4b18b2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -500,6 +500,9 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_enblslpm_quirk)
reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
 
+   if (dwc->dis_u2_freeclk_exists_quirk)
+   reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
+
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
 
return 0;
@@ -930,6 +933,8 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,dis_enblslpm_quirk");
dwc->dis_rxdet_inp3_quirk = device_property_read_bool(dev,
"snps,dis_rxdet_inp3_quirk");
+   dwc->dis_u2_freeclk_exists_quirk = device_property_read_bool(dev,
+   "snps,dis_u2_freeclk_exists_quirk");
 
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4a5453c..bcd1aa2 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -199,6 +199,7 @@
 
 /* Global USB2 PHY Configuration Register */
 #define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
+#define DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS (1 << 30)
 #define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
 #define DWC3_GUSB2PHYCFG_ULPI_UTMI (1 << 4)
 #define DWC3_GUSB2PHYCFG_ENBLSLPM  (1 << 8)
@@ -798,6 +799,9 @@ struct dwc3_scratchpad_array {
  * @dis_u2_susphy_quirk: set if we disable usb2 suspend phy
  * @dis_enblslpm_quirk: set if we clear enblslpm in GUSB2PHYCFG,
  *  disabling the suspend signal to the PHY.
+ * @dis_u2_freeclk_exists_quirk : set if we clear u2_freeclk_exists
+ * in GUSB2PHYCFG, specify that USB2 PHY doesn't
+ * provide a free-running PHY clock.
  * @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
  * @tx_de_emphasis: Tx de-emphasis value
  * 0   - -6dB de-emphasis
@@ -941,6 +945,7 @@ struct dwc3 {
unsigneddis_u2_susphy_quirk:1;
unsigneddis_enblslpm_quirk:1;
unsigneddis_rxdet_inp3_quirk:1;
+   unsigneddis_u2_freeclk_exists_quirk:1;
 
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
-- 
1.9.1


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

Re: [PATCH 1/2] usb: dwc3: gadget: set xfer resource per endpoint

[Felipe Balbi]

hi,

Felipe Balbi  writes:
>> This reverts back to the original buggy behavior. This will fail when
>> a SET_INTERFACE occurs multiple times.
>>
>> You can run testusb to see the failure:
>> testusb -t 9 -c 5000 -s 2048 -a
>
> I came up with something else for this. It's still unstable and I need
> to debug further to figure out where we're wrong. But it seems to me
> that we're following databook down to the last comma with patch
> below. Note that we're partially reverting your original changes and
> adding some extra knowledge about current configuration and interface,
> then we only reassign transfer resources if those change. Care to have a
> look?

here's a version that passes testusb and normal enumeration with g_zero
and g_mass_storage. After some experimenting, it seems like we should
always MODIFY resource allocation, unless we're doing a SetConfiguration
to the same configuration that is already chosen or a SetInterface to
the same interface/alt-setting pair that's already being used. This is
working for me. Can you test on your end too?

8<-
From 327475d7f63aa161bdc3bf7f9d693d9aafcd4518 Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Thu, 2 Jun 2016 12:47:13 +0300
Subject: [PATCH] usb: dwc3: gadget: fix endpoint resource allocation

There were still corner cases which current code
wouldn't cover. This new commit tries to cover them
all by partially reverting commit c450960187f4
("usb: dwc3: Fix assignment of EP transfer
resources") and implementing a new way which follows
Synopsys Databook correctly.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h   |  8 +
 drivers/usb/dwc3/ep0.c| 41 ++-
 drivers/usb/dwc3/gadget.c | 84 ++-
 3 files changed, 80 insertions(+), 53 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4a5453c36099..8fb6361d719d 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -768,6 +768,9 @@ struct dwc3_scratchpad_array {
  * @test_mode_nr: test feature selector
  * @lpm_nyet_threshold: LPM NYET response threshold
  * @hird_threshold: HIRD threshold
+ * @current_configuration: current configuration number
+ * @current_alt_setting: current alternate setting
+ * @current_interface: current interface number
  * @hsphy_interface: "utmi" or "ulpi"
  * @connected: true when we're connected to a host, false otherwise
  * @delayed_status: true when gadget driver asks for delayed status
@@ -913,6 +916,10 @@ struct dwc3 {
u8  lpm_nyet_threshold;
u8  hird_threshold;
 
+   u16 current_configuration;
+   u16 current_alt_setting;
+   u16 current_interface;
+
const char  *hsphy_interface;
 
unsignedconnected:1;
@@ -926,6 +933,7 @@ struct dwc3 {
unsignedpending_events:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
+   unsignedstart_config_issued:1;
unsignedthree_stage_setup:1;
unsignedusb3_lpm_capable:1;
 
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index fe79d771dee4..ff07122db8d3 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -576,6 +576,10 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
/* if the cfg matches and the cfg is non zero */
if (cfg && (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
 
+   if (dwc->current_configuration != cfg)
+   dwc->start_config_issued = false;
+   dwc->current_configuration = cfg;
+
/*
 * only change state if set_config has already
 * been processed. If gadget driver returns
@@ -598,9 +602,11 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 
case USB_STATE_CONFIGURED:
ret = dwc3_ep0_delegate_req(dwc, ctrl);
-   if (!cfg && !ret)
+   if (!cfg && !ret) {
usb_gadget_set_state(>gadget,
USB_STATE_ADDRESS);
+   dwc->current_configuration = 0;
+   }
break;
default:
ret = -EINVAL;
@@ -710,6 +716,35 @@ static int dwc3_ep0_set_isoch_delay(struct dwc3 *dwc, 
struct usb_ctrlrequest *ct
return 0;
 }
 
+static int dwc3_ep0_set_interface(struct dwc3 *dwc,
+   struct usb_ctrlrequest *ctrl)
+{
+   int ret;
+   u16 intf;
+   u16 alt;
+
+   intf = le16_to_cpu(ctrl->wIndex);
+

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

[Grygorii Strashko]

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



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



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,
int ret = 0;
int irq;

-   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)
  {
int ret;
+   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?


+   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().


+   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_pdata   pdata;
int ret;
+   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?

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



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

xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
if (!xhci) {

Re: [PATCH] hwrng: alea - Add support for Araneus Alea I USB RNG

[Bob Ham]

On Thu, 2016-06-02 at 12:43 +0200, Clemens Ladisch wrote:
> Bob Ham wrote:
> > Adds support for the Araneus Alea I USB hardware Random Number
> > Generator.  This RNG creates entropy at a high rate, about 100kb/s.
> >
> > Signed-off-by: Bob Ham 
> > ---
> >
> > +++ b/drivers/char/hw_random/alea.c
> 
> Why didn't you just add the device ID to chaoskey.c?
> (Because that one is hidden in drivers/usb/misc? ;-)

Argh!  Because that one is hidden in drivers/usb/misc!  Pfft :-)

Thanks.

-- 
Bob Ham 
Software Engineer
Collabora


Open First
Collabora is hiring!
Please check out our latest opportunities here:
http://bit.ly/Collabora-Careers



--
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 v8 13/14] usb: gadget: udc: adapt to OTG core

[Roger Quadros]

On 01/06/16 10:38, Peter Chen wrote:
> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>> @@ -530,6 +683,8 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
>>  }
>>  mutex_unlock(_lock);
>>  
>> +mutex_unlock(_lock);
>> +
> 
> Here, you have one more mutex_unlock.

Will fix it. Thanks.

>>  kobject_uevent(>dev.kobj, KOBJ_REMOVE);
>>  flush_work(>work);
>>  device_unregister(>dev);
>> @@ -539,6 +694,13 @@ EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>>  
>>  /* 
>> - */
>>  
>> +struct otg_gadget_ops otg_gadget_intf = {
>> +.start = usb_gadget_start,
>> +.stop = usb_gadget_stop,
>> +.connect_control = usb_gadget_connect_control,
>> +};
>> +
>> +/* udc_lock must be held */
>>  static int udc_bind_to_driver(struct usb_udc *udc, struct usb_gadget_driver 
>> *driver)
>>  {
>>  int ret;
>> @@ -553,12 +715,20 @@ static int udc_bind_to_driver(struct usb_udc *udc, 
>> struct usb_gadget_driver *dri
>>  ret = driver->bind(udc->gadget, driver);
>>  if (ret)
>>  goto err1;
>> -ret = usb_gadget_udc_start(udc);
>> -if (ret) {
>> -driver->unbind(udc->gadget);
>> -goto err1;
>> +
>> +/* If OTG, the otg core starts the UDC when needed */
>> +if (udc->gadget->otg_dev) {
>> +mutex_unlock(_lock);
>> +usb_otg_register_gadget(udc->gadget, _gadget_intf);
>> +mutex_lock(_lock);
>> +} else {
>> +ret = usb_gadget_udc_start(udc);
>> +if (ret) {
>> +driver->unbind(udc->gadget);
>> +goto err1;
>> +}
>> +usb_udc_connect_control(udc);
>>  }
>> -usb_udc_connect_control(udc);
>>  
>>  kobject_uevent(>dev.kobj, KOBJ_CHANGE);
>>  return 0;
>> @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct device 
>> *dev,
>>  return -EOPNOTSUPP;
>>  }
>>  
>> +/* In OTG mode we don't support softconnect, but b_bus_req */
>> +if (udc->gadget->otg_dev) {
>> +dev_err(dev, "soft-connect not supported in OTG mode\n");
>> +return -EOPNOTSUPP;
>> +}
>> +
>>  if (sysfs_streq(buf, "connect")) {
>>  usb_gadget_udc_start(udc);
>> -usb_gadget_connect(udc->gadget);
>> +usb_udc_connect_control(udc);
>>  } else if (sysfs_streq(buf, "disconnect")) {
>>  usb_gadget_disconnect(udc->gadget);
>>  udc->driver->disconnect(udc->gadget);
>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> index 3ecfddd..79d654f 100644
>> --- a/include/linux/usb/gadget.h
>> +++ b/include/linux/usb/gadget.h
>> @@ -1162,6 +1162,10 @@ extern int usb_add_gadget_udc(struct device *parent, 
>> struct usb_gadget *gadget);
>>  extern void usb_del_gadget_udc(struct usb_gadget *gadget);
>>  extern char *usb_get_gadget_udc_name(void);
>>  
>> +extern int usb_otg_add_gadget_udc(struct device *parent,
>> +  struct usb_gadget *gadget,
>> +  struct device *otg_dev);
>> +
>>  
>> /*-*/
>>  
>>  /* utility to simplify dealing with string descriptors */
>> -- 
>> 2.7.4
>>

--
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] hwrng: alea - Add support for Araneus Alea I USB RNG

[Clemens Ladisch]

Bob Ham wrote:
> Adds support for the Araneus Alea I USB hardware Random Number
> Generator.  This RNG creates entropy at a high rate, about 100kb/s.
>
> Signed-off-by: Bob Ham 
> ---
>
> +++ b/drivers/char/hw_random/alea.c

Why didn't you just add the device ID to chaoskey.c?
(Because that one is hidden in drivers/usb/misc? ;-)


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

Re: [PATCH 1/2] usb: dwc3: gadget: set xfer resource per endpoint

[Felipe Balbi]

hi,

John Youn  writes:
> On 5/30/2016 7:19 AM, Felipe Balbi wrote:
>> Instead of looping through all endpoints when
>> enabling ep0, let's allow for each endpoint to set
>> its own xfer resource. This solves an issue which
>> happens when we issue END_TRANSFER due to a reset
>> interrupt. Endpoints will be left without a xfer
>> resource to use.
>> 
>> Signed-off-by: Felipe Balbi 
>> ---
>>  drivers/usb/dwc3/gadget.c | 25 -
>>  1 file changed, 8 insertions(+), 17 deletions(-)
>> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 3d0745dece0c..6f5a4feef8af 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -410,30 +410,21 @@ static int dwc3_gadget_start_config(struct dwc3 *dwc, 
>> struct dwc3_ep *dep)
>>  {
>>  struct dwc3_gadget_ep_cmd_params params;
>>  u32 cmd;
>> -int i;
>>  int ret;
>>  
>> -if (dep->number)
>> -return 0;
>> -
>> -memset(, 0x00, sizeof(params));
>> -cmd = DWC3_DEPCMD_DEPSTARTCFG;
>> -
>> -ret = dwc3_send_gadget_ep_cmd(dep, cmd, );
>> -if (ret)
>> -return ret;
>> +if (dep->number == 0) {
>> +memset(, 0x00, sizeof(params));
>> +cmd = DWC3_DEPCMD_DEPSTARTCFG;
>>  
>> -for (i = 0; i < DWC3_ENDPOINTS_NUM; i++) {
>> -struct dwc3_ep *dep = dwc->eps[i];
>> -
>> -if (!dep)
>> -continue;
>> -
>> -ret = dwc3_gadget_set_xfer_resource(dwc, dep);
>> +ret = dwc3_send_gadget_ep_cmd(dep, cmd, );
>>  if (ret)
>>  return ret;
>>  }
>>  
>> +ret = dwc3_gadget_set_xfer_resource(dwc, dep);
>> +if (ret)
>> +return ret;
>> +
>>  return 0;
>>  }
>>  
>> 
>
> Hi Felipe,
>
> This reverts back to the original buggy behavior. This will fail when
> a SET_INTERFACE occurs multiple times.
>
> You can run testusb to see the failure:
> testusb -t 9 -c 5000 -s 2048 -a

I came up with something else for this. It's still unstable and I need
to debug further to figure out where we're wrong. But it seems to me
that we're following databook down to the last comma with patch
below. Note that we're partially reverting your original changes and
adding some extra knowledge about current configuration and interface,
then we only reassign transfer resources if those change. Care to have a
look?

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4a5453c36099..33897f863ec3 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -768,6 +768,8 @@ struct dwc3_scratchpad_array {
  * @test_mode_nr: test feature selector
  * @lpm_nyet_threshold: LPM NYET response threshold
  * @hird_threshold: HIRD threshold
+ * @current_configuration: current configuration number
+ * @current_interface: current interface number
  * @hsphy_interface: "utmi" or "ulpi"
  * @connected: true when we're connected to a host, false otherwise
  * @delayed_status: true when gadget driver asks for delayed status
@@ -913,6 +915,9 @@ struct dwc3 {
u8  lpm_nyet_threshold;
u8  hird_threshold;
 
+   u16 current_configuration;
+   u8  current_interface;
+
const char  *hsphy_interface;
 
unsignedconnected:1;
@@ -926,6 +931,7 @@ struct dwc3 {
unsignedpending_events:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
+   unsignedstart_config_issued:1;
unsignedthree_stage_setup:1;
unsignedusb3_lpm_capable:1;
 
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index fe79d771dee4..492da0bd88c6 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -576,6 +576,10 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
/* if the cfg matches and the cfg is non zero */
if (cfg && (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
 
+   if (dwc->current_configuration != cfg)
+   dwc->start_config_issued = false;
+   dwc->current_configuration = cfg;
+
/*
 * only change state if set_config has already
 * been processed. If gadget driver returns
@@ -598,9 +602,11 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 
case USB_STATE_CONFIGURED:
ret = dwc3_ep0_delegate_req(dwc, ctrl);
-   if (!cfg && !ret)
+   if (!cfg && !ret) {
usb_gadget_set_state(>gadget,
USB_STATE_ADDRESS);
+  

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

[Heikki Krogerus]

On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote:
> On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > Just noticed that the "active" file is for now read only, but it needs
> > > to be changed to writable. That file will of course provide means for
> > > the userspace to Exit and Enter modes. But please note that the
> > > responsibility of the dependencies between the modes, say, if a plug
> > > needs to be in one mode or the other in order for the partner to enter
> > > some specific mode, will fall on the Alternate Mode specific drivers
> > > once we have the altmode bus. I remember there were concerns about
> > > this in the original thread.
> > 
> > There's one thing we haven't touched upon yet. And I cannot really find
> > an answer in the spec.
> > 
> > What do we do if we return from S4 or S3? I think we need to restore
> > the ALternate Mode because our display may be running over that
> > Alternate Mode.
> > If we want to support USB persist we also need to restore data role
> > after S4.
> > 
> I don't have an answer ... but another interesting question.
> 
> How do we distinguish between alternate modes supported by a host vs.
> alternate modes supported by a sink ? typec_capability includes a pointer
> to alternate modes supportedf by the connector, but it is not clear if
> those are alternate modes supported as host, or alternate modes supported
> as device, or alternate modes supported by both.
> 
> This doesn't matter much if only a fixed role is supported, but it does matter
> for dual role ports. A laptop will typically only support DisplayPort as host,
> for example.

The DP alternate mode spec actually separates the display role from
Type-C role. A laptop most likely would only support the modes for
display host roles, but if the port was DRP port then it would still
do so in both Type-C roles.

So basically, even if the display was Type-C host, it would still work
as a display when attached to the laptop.

> Any idea ?

I'm actually not sure this is a problem.


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

[Heikki Krogerus]

On Thu, Jun 02, 2016 at 08:30:57AM +0200, Oliver Neukum wrote:
> On Wed, 2016-06-01 at 16:29 -0700, Guenter Roeck wrote:
> > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > > Just noticed that the "active" file is for now read only, but it needs
> > > > to be changed to writable. That file will of course provide means for
> > > > the userspace to Exit and Enter modes. But please note that the
> > > > responsibility of the dependencies between the modes, say, if a plug
> > > > needs to be in one mode or the other in order for the partner to enter
> > > > some specific mode, will fall on the Alternate Mode specific drivers
> > > > once we have the altmode bus. I remember there were concerns about
> > > > this in the original thread.
> > > 
> > > There's one thing we haven't touched upon yet. And I cannot really find
> > > an answer in the spec.
> > > 
> > > What do we do if we return from S4 or S3? I think we need to restore
> > > the ALternate Mode because our display may be running over that
> > > Alternate Mode.
> > > If we want to support USB persist we also need to restore data role
> > > after S4.
> > > 
> > I don't have an answer ... but another interesting question.
> > 
> > How do we distinguish between alternate modes supported by a host vs.
> > alternate modes supported by a sink ? typec_capability includes a pointer
> > to alternate modes supportedf by the connector, but it is not clear if
> > those are alternate modes supported as host, or alternate modes supported
> > as device, or alternate modes supported by both.
> 
> I was under the impression that this applies to the current role.
> 
> > This doesn't matter much if only a fixed role is supported, but it does 
> > matter
> > for dual role ports. A laptop will typically only support DisplayPort as 
> > host,
> > for example.
> > 
> > Any idea ?
> 
> I would state the obvious that we need separate directories for that.
> And how do we express captive cables?

That means we can not present the alternate modes the ports support as
devices, as then we would have potentially two devices presenting the
same mode. Wish we could make those symlinks.. But perhaps we don't
need to present the port alternate modes as devices in any case.

But there is an other problem. The alternate modes a port can
support as host or device may be defined by the platform, but it can
also be dictated by the alternate mode spec itself. Knowing about the
platform is a problem for the port driver, but knowing about the
individual alternate modes is not. Those will be problems for the
alternate mode drivers in the end.

So the moment a port driver is expected to create the attributes (or
populate the devices) that will present the alternate modes it
supports, this thing will not always be clear to it.

I'm now wondering should we make it responsibility for the port
drivers to generate those attributes that present the alternate modes
they support after all?


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

[PATCH] hwrng: alea - Add support for Araneus Alea I USB RNG

[Bob Ham]

Adds support for the Araneus Alea I USB hardware Random Number
Generator.  This RNG creates entropy at a high rate, about 100kb/s.

Signed-off-by: Bob Ham 
---

Just a note about the name of the module, I haven't append "-rng" to
the name, like every other module in hw_random, because those modules
contain drivers for the RNG part of some more complex device. By
contrast, the Alea is solely an RNG so adding "-rng" to the name seems
redundant.


 drivers/char/hw_random/Kconfig  |  13 ++
 drivers/char/hw_random/Makefile |   1 +
 drivers/char/hw_random/alea.c   | 370 
 3 files changed, 384 insertions(+)
 create mode 100644 drivers/char/hw_random/alea.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index ac51149..b3f5a89 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -396,6 +396,19 @@ config HW_RANDOM_PIC32
 
  If unsure, say Y.
 
+config HW_RANDOM_ALEA
+   tristate "Araneus Alea I USB Random Number Generator support"
+   depends on HW_RANDOM && USB
+   default n
+   ---help---
+ This driver provides kernel-side support for the Araneus
+ Alea I USB hardware Random Number Generator.
+
+ To compile this driver as a module, choose M here. the
+ module will be called alea.
+
+ If unsure, say N.
+
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 63022b4..3709906 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
 obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
 obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
 obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
+obj-$(CONFIG_HW_RANDOM_ALEA) += alea.o
diff --git a/drivers/char/hw_random/alea.c b/drivers/char/hw_random/alea.c
new file mode 100644
index 000..50909da
--- /dev/null
+++ b/drivers/char/hw_random/alea.c
@@ -0,0 +1,370 @@
+/*
+ * Copyright (C) 2016 Collabora Ltd
+ * Written by Bob Ham 
+ *
+ * An HWRNG driver to pull data from an Araneus Alea I
+ *
+ * derived from:
+ *
+ * USB Skeleton driver - 2.2
+ *
+ * Copyright (C) 2001-2004 Greg Kroah-Hartman (g...@kroah.com)
+ *
+ * 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, version 2.
+ *
+ * This driver is based on the 2.6.3 version of drivers/usb/usb-skeleton.c
+ * but has been rewritten to be easier to read and use.
+ *
+ */
+
+/*
+ * The Alea I is a really simple device.  There is one bulk read
+ * endpoint.  It spits out data in 64-byte chunks.  Each chunk
+ * contains entropy.  Simple.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define MODULE_NAME "alea"
+
+#define ARANEUS_VENDOR_ID  0x12d8
+#define ARANEUS_ALEA_I_PRODUCT_ID  0x0001
+
+/* table of devices that work with this driver */
+static const struct usb_device_id alea_table[] = {
+   { USB_DEVICE(ARANEUS_VENDOR_ID, ARANEUS_ALEA_I_PRODUCT_ID) },
+   { } /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE (usb, alea_table);
+
+
+/* Structure to hold all of our device specific stuff */
+struct alea {
+   struct usb_device   *udev;  /* the usb device for 
this device */
+   struct usb_interface*interface; /* the interface for 
this device */
+   struct urb  *bulk_in_urb;   /* the urb to read data 
with */
+   unsigned char   *bulk_in_buffer;/* the buffer to 
receive data */
+   size_t  bulk_in_size;   /* the size of the 
receive buffer */
+   size_t  bulk_in_filled; /* number of bytes in 
the buffer */
+   __u8bulk_in_endpointAddr;   /* the address of the 
bulk in endpoint */
+   int errors; /* the last request 
tanked */
+   boolongoing_read;   /* a read is going on */
+   spinlock_t  err_lock;   /* lock for errors */
+   struct kref kref;
+   struct mutexio_mutex;   /* synchronize I/O with 
disconnect */
+   wait_queue_head_t   bulk_in_wait;   /* to wait for an 
ongoing read */
+   char*rng_name;  /* name for the hwrng 
subsystem */
+   struct hwrngrng;/* the hwrng info */
+};
+#define kref_to_alea(d) container_of(d, struct alea, kref)
+#define rng_to_alea(d) container_of(d, struct alea, rng)
+
+static struct usb_driver alea_driver;
+
+static void alea_delete(struct kref *kref)
+{
+   struct alea *dev = 

Re: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Bjørn Mork]

 writes:

>> > +static u8 amac_ascii_to_hex(int c)
>> > +{
>> > +  if (c <= 0x39)
>> > +  return (u8)(c - 0x30);
>> > +  else if (c <= 0x46)
>> > +  return (u8)(c - 0x37);
>> > +  return (u8)(c - 0x57);
>> > +}
>> 
>
> Sorry forgot to address this.  
>
>> We really don't have such a function somewhere in the kernel already?
>
> There is a function in acpi/acpica/uthex.c that does this, but it doesn't 
> seem to be used by anything outside of acpica so far.  Would it be OK style 
> wise to 
> #include " ../../acpi/acpica/acutils.h" from r8152.c?  

Makes me wonder where you looked  You have hex_to_bin() and
hex2bin() in include/linux/kernel.h

You could look at usbnet_get_ethernet_addr() for an example of how to do
this properly.  It's pretty close to this driver in the tree, and should
be a natural starting point before reinventing the wheel...



Bjørn
--
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 12/12] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3

[Peter Chen]

On Thu, Jun 02, 2016 at 09:26:57AM +0200, Krzysztof Kozlowski wrote:
> On 06/01/2016 01:59 PM, Peter Chen wrote:
> > On Wed, Jun 01, 2016 at 10:02:21AM +0200, Krzysztof Kozlowski wrote:
> >> On Odroid U3 (Exynos4412-based) board if USB was initialized by
> >> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
> >> and LAN (smsc95xx) after after successful probing were not visible in the
> >> system ("lsusb").
> >>
> >> In such case the devices had to be fully reset before configuring.
> >> Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
> >> in usb3503 HUB are not sufficient. Instead full reset has to be done by
> >> disabling and enabling regulator.
> >>
> >> Signed-off-by: Krzysztof Kozlowski 
> >> ---
> >>  arch/arm/boot/dts/exynos4412-odroidu3.dts | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
> >> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> >> index 31cdc036fda4..23e30e4609df 100644
> >> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> >> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> >> @@ -99,11 +99,15 @@
> >>clock-names = "refclk";
> >>clocks = <_system_controller 0>;
> >>refclk-frequency = <2400>;
> >> +
> >> +  power-sequence;
> >> +  ext-supply = <_reg>;
> >>  };
> >>  
> >>   {
> >>port@1 {
> >>status = "okay";
> >> +  usb-pwrseq = <>;
> >>};
> >>port@2 {
> >>status = "okay";
> >> -- 
> >> 1.9.1
> >>
> > 
> > The hub is under the port1, you may need to describe it
> > under the port@1, see below:
> > Documentation/devicetree/bindings/usb/usb-device.txt
> 
> My configuration is a little bit different than yours.
> 
> In my case I have a USB hub (usb3503) which is also a a i2c device
> because it has to be configured through I2C.
> 
> I can add the power-sequence properties to the I2C node or as you
> pointed under port using the vendor-product-id compatible. In the first
> option: not many USB changes are needed. It works for me, at least as a
> proof of concept.
> 
> The second solution: currently it does not work because the USB device
> does not get enumerated before the power sequence begins. It would be
> great if you could implement this on USB side.

Well, not matter which solution, the USB device can't be enumerated
without power sequence. For the #2 solution, it just handles all
gpios under dts before the enumeration at USB code.

> 
> > 
> > If I get Rob's comments correctly, you may need to consider 
> > below MMC and USB device tree description together, it seems
> > hard for USB to use pwrseq driver, sorry for confusing you.
> > 
> > If rob can accept below USB device description, we have to
> > do it under USB. In future, if there is some suitable framework,
> > we can move it.
> > 
> > 1. MMC device:
> > usdhc3_pwrseq: usdhc3_pwrseq {
> > compatible = "mmc-pwrseq-simple";
> > reset-gpios = < 5 GPIO_ACTIVE_LOW>,   /* WL_REG_ON */
> >   < 7 GPIO_ACTIVE_LOW>,   /* WL_HOSTWAKE 
> > */
> >   < 25 GPIO_ACTIVE_LOW>,  /* BT_REG_ON */
> >   < 27 GPIO_ACTIVE_LOW>,  /* BT_HOSTWAKE 
> > */
> >   < 4 GPIO_ACTIVE_LOW>,   /* BT_WAKE */
> >   < 6 GPIO_ACTIVE_LOW>;   /* BT_RST_N */
> > };
> > 
> >  {
> > pinctrl-names = "default", "state_100mhz", "state_200mhz";
> > pinctrl-0 = <_usdhc3>;
> > pinctrl-1 = <_usdhc3_100mhz>;
> > pinctrl-2 = <_usdhc3_200mhz>;
> > bus-width = <4>;
> > non-removable;
> > keep-power-in-suspend;
> > wakeup-source;
> > mmc-pwrseq = <_pwrseq>;
> > status = "okay";
> > };
> > 
> > 2. USB device 
> > 
> >  {
> > vbus-supply = <_usb_otg1_vbus>;
> > pinctrl-names = "default";
> > pinctrl-0 = <_usb_otg1_id>;
> > status = "okay";
> > 
> > #address-cells = <1>;
> > #size-cells = <0>;
> > hub: genesys@1 {
> > compatible = "usb5e3,608";
> > reg = <1>;
> > reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> > reset-duration-us = <10>;
> > clocks = < IMX6SX_CLK_CKO>;
> > };
> 
> Yes, that looks like what Rob wanted... Do you plan to work on it? The
> power sequence is needed before device is enumerated.
> 

Ok, I will work on it.

-- 

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

[Heikki Krogerus]

On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > Just noticed that the "active" file is for now read only, but it needs
> > to be changed to writable. That file will of course provide means for
> > the userspace to Exit and Enter modes. But please note that the
> > responsibility of the dependencies between the modes, say, if a plug
> > needs to be in one mode or the other in order for the partner to enter
> > some specific mode, will fall on the Alternate Mode specific drivers
> > once we have the altmode bus. I remember there were concerns about
> > this in the original thread.
> 
> There's one thing we haven't touched upon yet. And I cannot really find
> an answer in the spec.
> 
> What do we do if we return from S4 or S3? I think we need to restore
> the ALternate Mode because our display may be running over that
> Alternate Mode.
> If we want to support USB persist we also need to restore data role
> after S4.

It would make sense.. What are all the things we need to consider with
that? An example, how do we know if the attached device has changed,
etc.

I'll try to put somekind of suspend and resume hooks to the API, but
this needs some thinking.

Does this have an effect on the interface, meaning would this be
something we could potentially add later? We need to document the
expected behaviour from the beginning, i.e. the roles and the modes
should be restored when resuming, in any case I think.


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

[Oliver Neukum]

On Wed, 2016-06-01 at 23:37 -0700, Guenter Roeck wrote:
> On 06/01/2016 11:24 PM, Oliver Neukum wrote:
> > On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
> >> The class code would not explicitly learn about the reset,
> >> but it would be informed about the exited modes.
> >
> > That has drawbacks
> >
> 
> Playing devils advocate a bit here
> 
> > - it doesn't tell you what caused the mode to be left (if you
> >UFP, it may be the regular command)
> 
> Does it matter ?

Potentially yes. Should you restore the last state when the mode
is reentered? If it caused the other side to reset, probably not.

> > - it is a race against your own command
> 
> It is my understanding that races have to be resolved by the drivers,
> since the typec code does not do any locking. This is quite similar
> to handling, say, a request to change the vconn source or to change
> the power role. Am I missing something ?

Yes. There is a fundamental race between Exit Mode and reset if you
only report leaving a mode. Drivers can do nothing to prevent it
unless reporting resets by themselves.

> > - it does not work if you are in basic USB mode
> >
> Would alternate modes be active in that case ?

No and that is the point. A reset happens, presumably because the
other side saw an error condition and we just blindly continue
because no Alternate Mode was left and our user space remains
uninformed.

Regards
Oliver


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

Re: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Pali Rohár]

Hi! As ACPI bytecode is untrusted for me and also for running kernel, we
should not expect that it does not contain any bugs or other problems.
So I would propose these checks to prevent something wrong...

On Wednesday 01 June 2016 16:50:44 Mario Limonciello wrote:
> +static void set_auxiliary_addr(struct sockaddr *sa)
> +{
> + acpi_status status;
> + acpi_handle handle;
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + union acpi_object *obj;
> + int i;
> + char *ptr;
> +
> + acpi_get_handle(NULL, "\\_SB", );

Check return value of acpi_get_handle

> + status = acpi_evaluate_object(handle, "AMAC", NULL, );

This is question for ACPI devs, it is not possible to call directly?

  acpi_evaluate_object(NULL, "\\_SB.AMAC", NULL, );

And what happen if we try to evaluate objects which do not exist? Does
not it show some warning or error in dmesg about non existent object?
Such errors should be silent here.

> + obj = (union acpi_object *)buffer.pointer;

Check buffer.type

> + if (ACPI_SUCCESS(status) && (obj->string.length == 0x17)) {
> + /* returns _AUXMAC_#AABBCCDDEEFF#
> +  * this pulls out _AUXMAC# from start and # from end
> +  */
> + ptr = obj->string.pointer + 9;

Verify that string really contains that _AUXMAX# prefix. This is really
obscure and nonstandard format for specifying MAC address and in my
opinion it should be properly checked. Nonstandard formats can be
changed in future and we could have problems.

> + pr_info("r8152: Using system auxiliary MAC address");

It would be great to write also mac address into that pr_info

> + for (i = 0; i < 6; i++, ptr += 2)
> + sa->sa_data[i] = amac_ascii_to_hex(*ptr) << 4 |
> +  amac_ascii_to_hex(*(ptr + 1));
> + }

In case of some acpi check fails throw warning (or error).

And there is memory leak, you allocated buffer with ACPI_ALLOCATE_BUFFER
but you did not free it.

> +}

And my last question is: Are really all Dell docks comes with this one
realtek chip? I'm pessimist in this, because I see how other components
(like HDD vendor, touchpad type, smardcard chips, motherboards, display
panels, wifi chips) can be different in two laptops of same Dell model.

-- 
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] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Bjørn Mork]

Greg KH  writes:

> And finally, this seems odd overall given that a MAC address should be
> associated with the specific network device, not the overall system.

Definitely.

I wonder if this isn't a perfect candidate for an x86
arch_get_platform_mac_address() implementation?  Then you could just use
the eth_platform_get_mac_address() helper in the driver and avoid any
platform specific code there.  Which will automagically make it work as
expected on a Sparc too :)

This will also make your job next year much easier, when the hardeware
guys decided to replace the chip and you need to implement the exact
same code in some other driver...

See https://patchwork.ozlabs.org/patch/564100/ for a detailed
discussion of this interface.


Bjørn
--
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 12/12] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3

[Krzysztof Kozlowski]

On 06/01/2016 01:59 PM, Peter Chen wrote:
> On Wed, Jun 01, 2016 at 10:02:21AM +0200, Krzysztof Kozlowski wrote:
>> On Odroid U3 (Exynos4412-based) board if USB was initialized by
>> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
>> and LAN (smsc95xx) after after successful probing were not visible in the
>> system ("lsusb").
>>
>> In such case the devices had to be fully reset before configuring.
>> Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
>> in usb3503 HUB are not sufficient. Instead full reset has to be done by
>> disabling and enabling regulator.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  arch/arm/boot/dts/exynos4412-odroidu3.dts | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
>> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> index 31cdc036fda4..23e30e4609df 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> @@ -99,11 +99,15 @@
>>  clock-names = "refclk";
>>  clocks = <_system_controller 0>;
>>  refclk-frequency = <2400>;
>> +
>> +power-sequence;
>> +ext-supply = <_reg>;
>>  };
>>  
>>   {
>>  port@1 {
>>  status = "okay";
>> +usb-pwrseq = <>;
>>  };
>>  port@2 {
>>  status = "okay";
>> -- 
>> 1.9.1
>>
> 
> The hub is under the port1, you may need to describe it
> under the port@1, see below:
> Documentation/devicetree/bindings/usb/usb-device.txt

My configuration is a little bit different than yours.

In my case I have a USB hub (usb3503) which is also a a i2c device
because it has to be configured through I2C.

I can add the power-sequence properties to the I2C node or as you
pointed under port using the vendor-product-id compatible. In the first
option: not many USB changes are needed. It works for me, at least as a
proof of concept.

The second solution: currently it does not work because the USB device
does not get enumerated before the power sequence begins. It would be
great if you could implement this on USB side.

> 
> If I get Rob's comments correctly, you may need to consider 
> below MMC and USB device tree description together, it seems
> hard for USB to use pwrseq driver, sorry for confusing you.
> 
> If rob can accept below USB device description, we have to
> do it under USB. In future, if there is some suitable framework,
> we can move it.
> 
> 1. MMC device:
>   usdhc3_pwrseq: usdhc3_pwrseq {
>   compatible = "mmc-pwrseq-simple";
>   reset-gpios = < 5 GPIO_ACTIVE_LOW>,   /* WL_REG_ON */
> < 7 GPIO_ACTIVE_LOW>,   /* WL_HOSTWAKE 
> */
> < 25 GPIO_ACTIVE_LOW>,  /* BT_REG_ON */
> < 27 GPIO_ACTIVE_LOW>,  /* BT_HOSTWAKE 
> */
> < 4 GPIO_ACTIVE_LOW>,   /* BT_WAKE */
> < 6 GPIO_ACTIVE_LOW>;   /* BT_RST_N */
>   };
> 
>  {
>   pinctrl-names = "default", "state_100mhz", "state_200mhz";
>   pinctrl-0 = <_usdhc3>;
>   pinctrl-1 = <_usdhc3_100mhz>;
>   pinctrl-2 = <_usdhc3_200mhz>;
>   bus-width = <4>;
>   non-removable;
>   keep-power-in-suspend;
>   wakeup-source;
>   mmc-pwrseq = <_pwrseq>;
>   status = "okay";
> };
> 
> 2. USB device 
> 
>  {
>   vbus-supply = <_usb_otg1_vbus>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_usb_otg1_id>;
>   status = "okay";
> 
>   #address-cells = <1>;
>   #size-cells = <0>;
>   hub: genesys@1 {
>   compatible = "usb5e3,608";
>   reg = <1>;
>   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
>   reset-duration-us = <10>;
>   clocks = < IMX6SX_CLK_CKO>;
>   };

Yes, that looks like what Rob wanted... Do you plan to work on it? The
power sequence is needed before device is enumerated.

BTW, if you would like to play with the patchset, it is here:
repo:   https://github.com/krzk/linux
branch: for-next/odroid-u3-usb3503-lan-boot-fixes-v3

Best regards,
Krzysztof

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

[PATCH v2 0/2] 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 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|   55 ++
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-rockchip-inno-usb2.c   |  604 
 4 files changed, 667 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

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

[Frank Wang]

Signed-off-by: Frank Wang 
---

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|   55 
 1 file changed, 55 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..132e707
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt
@@ -0,0 +1,55 @@
+ROCKCHIP USB2.0 PHY WITH INNO IP BLOCK
+
+Required properties (phy (parent) node):
+ - compatible : should contain:
+   * "rockchip,rk3366-usb2phy"
+   * "rockchip,rk3399-usb2phy"
+ - #clock-cells : should be 0.
+ - clock-names : specify the 480m output clk name.
+
+Optional properties:
+ - vbus_host-supply : phandle to a regulator that supplies host vbus.
+ - vbus_otg-supply : phandle to a regulator that supplies otg vbus.
+
+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.
+
+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 or otg linestate interrupt.
+
+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 v2 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 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 |  604 ++
 3 files changed, 612 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..eca46ff
--- /dev/null
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -0,0 +1,604 @@
+/*
+ * 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.
+ *
+ * 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;
+};
+
+/**
+ * struct rockchip_usb2phy_port: usb-phy port data.
+ * @port_id: flag for otg port or host port.
+ * @suspended: phy suspended flag.
+ * @ls_irq: IRQ number assigned for linestate detection.
+ * @mutex: for register updating in sm_work.
+ * @sm_work: OTG state machine work.
+ * @phy_cfg: port register configuration, assigned by driver data.
+ */

Re: [PATCH 1/1] usb: Add SMSC/Microchip USB2514 HUB support.

[Felipe Balbi]

Hi,

Nathael Pajani  writes:
> From: Nathael Pajani 
> Date: Wed, 1 Jun 2016 20:35:50 +0200
> Subject: [PATCH 1/1] usb: Add SMSC/Microchip USB2514 HUB support.
>
> Add SMSC/Microchip USB2514 HUB support.
> Hub configuration made through I2C from host instead of external EEPROM.
> Signed-off-by: Nathael Pajani 

you need to run your patch through scripts/checkpatch.pl and fix all the
errors and warnings that spits out.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 60/62] usb: dwc3: gadget: disable XFER_NOT_READY

[Felipe Balbi]

John Youn  writes:
> On 5/30/2016 4:46 AM, Felipe Balbi wrote:
>> We don't need this IRQ anymore.
>> 
>> Signed-off-by: Felipe Balbi 
>> ---
>>  drivers/usb/dwc3/gadget.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 7a0c787cecdd..613dde9fb538 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -463,8 +463,10 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, 
>> struct dwc3_ep *dep,
>>  params.param2 |= dep->saved_state;
>>  }
>>  
>> -params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN
>> -| DWC3_DEPCFG_XFER_NOT_READY_EN;
>> +params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN;
>> +
>> +if (dep->number <= 1)
>> +params.param1 |= DWC3_DEPCFG_XFER_NOT_READY_EN;
>>  
>>  if (usb_ss_max_streams(comp_desc) && usb_endpoint_xfer_bulk(desc)) {
>>  params.param1 |= DWC3_DEPCFG_STREAM_CAPABLE
>> 
>
> Still needed for ISOC too.

indeed. Here's updated version:

8<
commit 8edf6e7f68878d31fda351981acac01097712f49
Author: Felipe Balbi 
Date:   Mon May 30 13:40:00 2016 +0300

usb: dwc3: gadget: disable XFER_NOT_READY

We don't need this IRQ anymore for interrupt or bulk
endpoints.

Signed-off-by: Felipe Balbi 

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index d16290457a8d..8673874de191 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -463,8 +463,10 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, 
struct dwc3_ep *dep,
params.param2 |= dep->saved_state;
}
 
-   params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN
-   | DWC3_DEPCFG_XFER_NOT_READY_EN;
+   params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN;
+
+   if (dep->number <= 1 || usb_endpoint_xfer_isoc(desc))
+   params.param1 |= DWC3_DEPCFG_XFER_NOT_READY_EN;
 
if (usb_ss_max_streams(comp_desc) && usb_endpoint_xfer_bulk(desc)) {
params.param1 |= DWC3_DEPCFG_STREAM_CAPABLE


-- 
balbi


signature.asc
Description: PGP signature

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

[Guenter Roeck]

On 06/01/2016 11:24 PM, Oliver Neukum wrote:

On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:

The class code would not explicitly learn about the reset,
but it would be informed about the exited modes.


That has drawbacks



Playing devils advocate a bit here


- it doesn't tell you what caused the mode to be left (if you
   UFP, it may be the regular command)


Does it matter ?


- it is a race against your own command


It is my understanding that races have to be resolved by the drivers,
since the typec code does not do any locking. This is quite similar
to handling, say, a request to change the vconn source or to change
the power role. Am I missing something ?


- it does not work if you are in basic USB mode


Would alternate modes be active in that case ?

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 1/2] usb: dwc3: gadget: set xfer resource per endpoint

[Felipe Balbi]

Hi,

John Youn  writes:
>>> However, I'm not aware of any issue with END_TRANSFER, could you let
>>> me know how to reproduce it?
>> 
>> it's a rare and difficult bug to reproduce. If you take my testing/next
>> (I didn't check if it happens with v4.7-rc1) - $subject and keep large
>> mass storage transfers going on, eventually you'll see mass storage
>> hang. After some 30s, host side will timeout and cancel all URBs and
>> issue a bus reset. This will, in turn, cause the gadget driver to issue
>> END_TRANSFER to a possible in-flight transfer.
>> 
>> After Reset completion, the gadget will reenumerate and, when gadget
>> driver queues to a bulk EP, StartTransfer will return "No Resource". The
>> reason for that is that END_TRANSFER deallocates the resource, according
>> to section 6.3.5.2 of 2.60a databook.
  ^^^
  section 6.3.2.5.2

> Do you know if the END_TRANSFER completes successfully? It could be

oh yeah, it completes just fine

> that the END_TRANFER failed and it continues to tie up the resource.
>
> I'll ask around to see if there is any other possibilities as well.

thanks

-- 
balbi


signature.asc
Description: PGP signature

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

[Oliver Neukum]

On Wed, 2016-06-01 at 16:29 -0700, Guenter Roeck wrote:
> On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > Just noticed that the "active" file is for now read only, but it needs
> > > to be changed to writable. That file will of course provide means for
> > > the userspace to Exit and Enter modes. But please note that the
> > > responsibility of the dependencies between the modes, say, if a plug
> > > needs to be in one mode or the other in order for the partner to enter
> > > some specific mode, will fall on the Alternate Mode specific drivers
> > > once we have the altmode bus. I remember there were concerns about
> > > this in the original thread.
> > 
> > There's one thing we haven't touched upon yet. And I cannot really find
> > an answer in the spec.
> > 
> > What do we do if we return from S4 or S3? I think we need to restore
> > the ALternate Mode because our display may be running over that
> > Alternate Mode.
> > If we want to support USB persist we also need to restore data role
> > after S4.
> > 
> I don't have an answer ... but another interesting question.
> 
> How do we distinguish between alternate modes supported by a host vs.
> alternate modes supported by a sink ? typec_capability includes a pointer
> to alternate modes supportedf by the connector, but it is not clear if
> those are alternate modes supported as host, or alternate modes supported
> as device, or alternate modes supported by both.

I was under the impression that this applies to the current role.

> This doesn't matter much if only a fixed role is supported, but it does matter
> for dual role ports. A laptop will typically only support DisplayPort as host,
> for example.
> 
> Any idea ?

I would state the obvious that we need separate directories for that.
And how do we express captive cables?

Regards
Oliver


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

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

[Oliver Neukum]

On Wed, 2016-06-01 at 06:34 -0700, Guenter Roeck wrote:
> The class code would not explicitly learn about the reset,
> but it would be informed about the exited modes.

That has drawbacks

- it doesn't tell you what caused the mode to be left (if you
  UFP, it may be the regular command)
- it is a race against your own command
- it does not work if you are in basic USB mode

Regards
Oliver


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

RE: [PATCH] r8152: Add support for setting MAC to system's Auxiliary MAC address

[Hayes Wang]

Mario Limonciello [mailto:mario_limoncie...@dell.com]
[...]
>  static int set_ethernet_addr(struct r8152 *tp)
>  {
>   struct net_device *dev = tp->netdev;
> @@ -1041,6 +1075,9 @@ static int set_ethernet_addr(struct r8152 *tp)
>   else
>   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
> 
> + /* if system provides auxiliary MAC address */
> + set_auxiliary_addr();
> +
>   if (ret < 0) {
>   netif_err(tp, probe, dev, "Get ether addr fail\n");
>   } else if (!is_valid_ether_addr(sa.sa_data)) {

When tp->version == RTL_VER_01, you would have different MAC address
between SW and HW. You may use the MAC address from ACPI for dev_addr.
However, the device uses another one, because you don't set it to the device.

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 1/2] usb: dwc3: gadget: set xfer resource per endpoint

[John Youn]

On 5/31/2016 11:52 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> John Youn  writes:
>> On 5/30/2016 7:19 AM, Felipe Balbi wrote:
>>> Instead of looping through all endpoints when
>>> enabling ep0, let's allow for each endpoint to set
>>> its own xfer resource. This solves an issue which
>>> happens when we issue END_TRANSFER due to a reset
>>> interrupt. Endpoints will be left without a xfer
>>> resource to use.
>>>
>>> Signed-off-by: Felipe Balbi 
>>> ---
>>>  drivers/usb/dwc3/gadget.c | 25 -
>>>  1 file changed, 8 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 3d0745dece0c..6f5a4feef8af 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -410,30 +410,21 @@ static int dwc3_gadget_start_config(struct dwc3 *dwc, 
>>> struct dwc3_ep *dep)
>>>  {
>>> struct dwc3_gadget_ep_cmd_params params;
>>> u32 cmd;
>>> -   int i;
>>> int ret;
>>>  
>>> -   if (dep->number)
>>> -   return 0;
>>> -
>>> -   memset(, 0x00, sizeof(params));
>>> -   cmd = DWC3_DEPCMD_DEPSTARTCFG;
>>> -
>>> -   ret = dwc3_send_gadget_ep_cmd(dep, cmd, );
>>> -   if (ret)
>>> -   return ret;
>>> +   if (dep->number == 0) {
>>> +   memset(, 0x00, sizeof(params));
>>> +   cmd = DWC3_DEPCMD_DEPSTARTCFG;
>>>  
>>> -   for (i = 0; i < DWC3_ENDPOINTS_NUM; i++) {
>>> -   struct dwc3_ep *dep = dwc->eps[i];
>>> -
>>> -   if (!dep)
>>> -   continue;
>>> -
>>> -   ret = dwc3_gadget_set_xfer_resource(dwc, dep);
>>> +   ret = dwc3_send_gadget_ep_cmd(dep, cmd, );
>>> if (ret)
>>> return ret;
>>> }
>>>  
>>> +   ret = dwc3_gadget_set_xfer_resource(dwc, dep);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> return 0;
>>>  }
>>>  
>>>
>>
>> Hi Felipe,
>>
>> This reverts back to the original buggy behavior. This will fail when
>> a SET_INTERFACE occurs multiple times.
> 
> h I forgot about that. Good point.
> 
>> You can run testusb to see the failure:
>> testusb -t 9 -c 5000 -s 2048 -a
> 
> I'll test this one today
> 
>> We've actually found a problem with the current code as well. There is
>> both a documentation problem and a controller problem which we will
>> fix in an upcoming release.
> 
> Oh, I can't wait to see :-) If you want help testing anything, let me
> know.
> 
>> However, I'm not aware of any issue with END_TRANSFER, could you let
>> me know how to reproduce it?
> 
> it's a rare and difficult bug to reproduce. If you take my testing/next
> (I didn't check if it happens with v4.7-rc1) - $subject and keep large
> mass storage transfers going on, eventually you'll see mass storage
> hang. After some 30s, host side will timeout and cancel all URBs and
> issue a bus reset. This will, in turn, cause the gadget driver to issue
> END_TRANSFER to a possible in-flight transfer.
> 
> After Reset completion, the gadget will reenumerate and, when gadget
> driver queues to a bulk EP, StartTransfer will return "No Resource". The
> reason for that is that END_TRANSFER deallocates the resource, according
> to section 6.3.5.2 of 2.60a databook.

By the way I don't see this section in the 2.60a databook. Can you
check again?

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