RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Tuesday, April 26, 2016 11:47 AM
> To: Jun Li 
> Cc: Roger Quadros ; st...@rowland.harvard.edu;
> ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com;
> dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> 
> On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > > +struct usb_otg *usb_otg_register(struct device *dev,
> > > +  struct usb_otg_config *config) {
> > > + struct usb_otg *otg;
> > > + struct otg_wait_data *wait;
> > > + int ret = 0;
> > > +
> > > + if (!dev || !config || !config->fsm_ops)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + /* already in list? */
> > > + mutex_lock(_list_mutex);
> > > + if (usb_otg_get_data(dev)) {
> > > + dev_err(dev, "otg: %s: device already in otg list\n",
> > > + __func__);
> > > + ret = -EINVAL;
> > > + goto unlock;
> > > + }
> > > +
> > > + /* allocate and add to list */
> > > + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > > + if (!otg) {
> > > + ret = -ENOMEM;
> > > + goto unlock;
> > > + }
> > > +
> > > + otg->dev = dev;
> > > + otg->caps = config->otg_caps;
> > > +
> > > + if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > > +  otg->caps->adp_support) && !config->otg_work)
> > > + dev_info(dev, "otg: limiting to dual-role\n");
> >
> > dev_err, this should be an error.
> 
> The condition may be wrong, but it is an information to show that current
> OTG is dual-role.

This should not happen in any correct design, I even doubt if we
should try to continue by "downgrade" it to be duel role, currently
the only example user is dual role, so doing like this can't be
tested by real case, this downgrade is not so easy like we image,
at least for chipidea otg driver, simply replace a queue worker may
not work, as we have much more difference between the 2 configs.

Li Jun
 
> 
> Peter
> >
> > > +
> > > + if (config->otg_work)   /* custom otg_work ? */
> > > + INIT_WORK(>work, config->otg_work);
> > > + else
> > > + INIT_WORK(>work, usb_otg_work);
> > > +
> > > + otg->wq = create_singlethread_workqueue("usb_otg");
> > > + if (!otg->wq) {
> > > + dev_err(dev, "otg: %s: can't create workqueue\n",
> > > + __func__);
> > > + ret = -ENOMEM;
> > > + goto err_wq;
> > > + }
> > > +
> > > + /* set otg ops */
> > > + otg->fsm.ops = config->fsm_ops;
> > > +
> > > + mutex_init(>fsm.lock);
> > > +
> > > + list_add_tail(>list, _list);
> > > + mutex_unlock(_list_mutex);
> > > +
> > > + /* were we in wait list? */
> > > + mutex_lock(_list_mutex);
> > > + wait = usb_otg_get_wait(dev);
> > > + mutex_unlock(_list_mutex);
> > > + if (wait) {
> > > + /* register pending host/gadget and flush from list */
> > > + usb_otg_flush_wait(dev);
> > > + }
> > > +
> > > + return otg;
> > > +
> > > +err_wq:
> > > + kfree(otg);
> > > +unlock:
> > > + mutex_unlock(_list_mutex);
> > > + return ERR_PTR(ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(usb_otg_register);
> > > +
> >
> > --
> > 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
> 
> --
> Best Regards,
> Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Peter Chen]

On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > +struct usb_otg *usb_otg_register(struct device *dev,
> > +struct usb_otg_config *config)
> > +{
> > +   struct usb_otg *otg;
> > +   struct otg_wait_data *wait;
> > +   int ret = 0;
> > +
> > +   if (!dev || !config || !config->fsm_ops)
> > +   return ERR_PTR(-EINVAL);
> > +
> > +   /* already in list? */
> > +   mutex_lock(_list_mutex);
> > +   if (usb_otg_get_data(dev)) {
> > +   dev_err(dev, "otg: %s: device already in otg list\n",
> > +   __func__);
> > +   ret = -EINVAL;
> > +   goto unlock;
> > +   }
> > +
> > +   /* allocate and add to list */
> > +   otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > +   if (!otg) {
> > +   ret = -ENOMEM;
> > +   goto unlock;
> > +   }
> > +
> > +   otg->dev = dev;
> > +   otg->caps = config->otg_caps;
> > +
> > +   if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > +otg->caps->adp_support) && !config->otg_work)
> > +   dev_info(dev, "otg: limiting to dual-role\n");
> 
> dev_err, this should be an error.

The condition may be wrong, but it is an information to show
that current OTG is dual-role.

Peter
> 
> > +
> > +   if (config->otg_work)   /* custom otg_work ? */
> > +   INIT_WORK(>work, config->otg_work);
> > +   else
> > +   INIT_WORK(>work, usb_otg_work);
> > +
> > +   otg->wq = create_singlethread_workqueue("usb_otg");
> > +   if (!otg->wq) {
> > +   dev_err(dev, "otg: %s: can't create workqueue\n",
> > +   __func__);
> > +   ret = -ENOMEM;
> > +   goto err_wq;
> > +   }
> > +
> > +   /* set otg ops */
> > +   otg->fsm.ops = config->fsm_ops;
> > +
> > +   mutex_init(>fsm.lock);
> > +
> > +   list_add_tail(>list, _list);
> > +   mutex_unlock(_list_mutex);
> > +
> > +   /* were we in wait list? */
> > +   mutex_lock(_list_mutex);
> > +   wait = usb_otg_get_wait(dev);
> > +   mutex_unlock(_list_mutex);
> > +   if (wait) {
> > +   /* register pending host/gadget and flush from list */
> > +   usb_otg_flush_wait(dev);
> > +   }
> > +
> > +   return otg;
> > +
> > +err_wq:
> > +   kfree(otg);
> > +unlock:
> > +   mutex_unlock(_list_mutex);
> > +   return ERR_PTR(ret);
> > +}
> > +EXPORT_SYMBOL_GPL(usb_otg_register);
> > +
> 
> --
> 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

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

Re: [PATCH v6 04/10] regulator: fixed: add support for ACPI interface

[Lu Baolu]

Hi Mark,

On 04/26/2016 01:30 AM, Mark Brown wrote:
> On Mon, Apr 25, 2016 at 04:04:50PM +0800, Lu Baolu wrote:
>
>> +ret = device_property_read_string(dev, "gpio-name", _name);
>> +if (!ret) {
>> +gpiod = gpiod_get(dev, gpio_name, GPIOD_ASIS);
>> +if (!IS_ERR(gpiod)) {
> This doesn't look like it's a standard ACPI binding for GPIOs, why are
> we using a property to get the GPIO noame?

The GPIO name might be different in different use cases. For my case,
it is "vbus_en", but other cases should use the different name.

On ACPI compatible platforms, GPIO resources are reported via ACPI
tables and (devm_)gpiod_get() hides the APCI complexity and returns
the gpiod according to "gpio_name".

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

Re: [PATCH v6 03/10] regulator: fixed: add device binding for platform device

[Lu Baolu]

Hi Mark,

On 04/26/2016 12:40 AM, Mark Brown wrote:
> On Mon, Apr 25, 2016 at 04:04:49PM +0800, Lu Baolu wrote:
>
>> This is needed to handle the GPIO connected USB vcc pin found on
>> Intel Baytrail devices.
> In what way is this needed?  The we defualt to using the driver name if
> no platform ID table, AFAICT this is just restating the same string?

You are right. This is not a "needed". It just makes the platform
driver binding explicit. We can ignore it if you don't like it.

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

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Jun Li]

Hi Roger

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Tuesday, April 05, 2016 10:05 PM
> To: st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org; Roger Quadros
> 
> Subject: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> 
> It provides APIs for the following tasks
> 
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
> 
> Provide a dual-role device (DRD) state machine.
> DRD mode is a reduced functionality OTG mode. In this mode we don't
> support SRP, HNP and dynamic role-swap.
> 
> In DRD operation, the controller mode (Host or Peripheral) is decided
> based on the ID pin status. Once a cable plug (Type-A or Type-B) is
> attached the controller selects the state and doesn't change till the
> cable in unplugged and a different cable type is inserted.
> 
> As we don't need most of the complex OTG states and OTG timers we
> implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs 'id' and
> 'b_sess_vld'.
> 
> Signed-off-by: Roger Quadros 
> ---

...

> +/**
> + * Register pending host/gadget and remove entry from wait list  */
> +static void usb_otg_flush_wait(struct device *otg_dev) {
> + struct otg_wait_data *wait;
> + struct otg_hcd *host;
> + struct otg_gcd *gadget;
> +
> + mutex_lock(_list_mutex);
> +
> + wait = usb_otg_get_wait(otg_dev);
> + if (!wait)
> + goto done;
> +
> + dev_dbg(otg_dev, "otg: registering pending host/gadget\n");
> + gadget = >gcd;
> + if (gadget)

If (gadget->gadget)

> + usb_otg_register_gadget(gadget->gadget, gadget->ops);
> +
> + host = >primary_hcd;
> + if (host->hcd)
> + usb_otg_register_hcd(host->hcd, host->irqnum, host->irqflags,
> +  host->ops);
> +
> + host = >shared_hcd;
> + if (host->hcd)
> + usb_otg_register_hcd(host->hcd, host->irqnum, host->irqflags,
> +  host->ops);
> +
> + list_del(>list);
> + kfree(wait);
> +
> +done:
> + mutex_unlock(_list_mutex);
> +}
> +
> +/**
> + * Check if the OTG device is in our OTG list and return
> + * usb_otg data, else NULL.
> + *
> + * otg_list_mutex must be held.
> + */
> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev) {
> + struct usb_otg *otg;
> +
> + if (!otg_dev)
> + return NULL;
> +
> + list_for_each_entry(otg, _list, list) {
> + if (otg->dev == otg_dev)
> + return otg;
> + }
> +
> + return NULL;
> +}

Could you export it to be a public API, we may need access usb_otg
in common host driver for handling of enumeration of otg test device.

...

> +/**
> + * Called when entering a DRD state.
> + * fsm->lock must be held.
> + */
> +static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state
> +new_state) {
> + struct usb_otg *otg = container_of(fsm, struct usb_otg, fsm);
> +
> + if (otg->state == new_state)
> + return;
> +
> + fsm->state_changed = 1;
> + dev_dbg(otg->dev, "otg: set state: %s\n",
> + usb_otg_state_string(new_state));
> + switch (new_state) {
> + case OTG_STATE_B_IDLE:
> + drd_set_protocol(fsm, PROTO_UNDEF);
> + otg_drv_vbus(otg, 0);
> + break;
> + case OTG_STATE_B_PERIPHERAL:
> + drd_set_protocol(fsm, PROTO_GADGET);
> + otg_drv_vbus(otg, 0);
> + break;
> + case OTG_STATE_A_HOST:
> + drd_set_protocol(fsm, PROTO_HOST);
> + otg_drv_vbus(otg, 1);
> + break;
> + case OTG_STATE_UNDEFINED:
> + case OTG_STATE_B_SRP_INIT:
> + case OTG_STATE_B_WAIT_ACON:
> + case OTG_STATE_B_HOST:
> + case OTG_STATE_A_IDLE:
> + case OTG_STATE_A_WAIT_VRISE:
> + case OTG_STATE_A_WAIT_BCON:
> + case OTG_STATE_A_SUSPEND:
> + case OTG_STATE_A_PERIPHERAL:
> + case OTG_STATE_A_WAIT_VFALL:
> + case OTG_STATE_A_VBUS_ERR:

Remove above unused states.

> + default:
> + dev_warn(otg->dev, "%s: otg: invalid state: %s\n",
> +  __func__, usb_otg_state_string(new_state));
> + break;
> + }
> +
> + otg->state = new_state;
> +}
> +
> +/**
> + * DRD state change judgement
> + *
> + * For DRD we're only interested in some of the OTG states
> + * i.e. OTG_STATE_B_IDLE: both peripheral and host are stopped
> + *   OTG_STATE_B_PERIPHERAL: peripheral active
> + *   OTG_STATE_A_HOST: host active
> + * 

Re: [PATCH RFT] usb: chipidea: host: disable io watchdog

[Peter Chen]

On Mon, Apr 25, 2016 at 12:55:42PM +0200, Lucas Stach wrote:
> The Chipidea EHCI core seems to behave sanely and doesn't need
> the IO watchdog. This kills off 10 non-deferrable wakeup events
> per second when the controller is otherwise idle.
> 

What does this 10 wakeup events? From what I see, it is 10 hrtimer
event, does they affect a lot?

Peter

> Signed-off-by: Lucas Stach 
> ---
> I've only tested this on i.MX6 for now and would like to ask people
> on CC to test on their platforms as they also use the chipidea core.
> ---
>  drivers/usb/chipidea/host.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> index 053bac9d983c..96ae69502c86 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -81,12 +81,15 @@ static int ehci_ci_reset(struct usb_hcd *hcd)
>  {
>   struct device *dev = hcd->self.controller;
>   struct ci_hdrc *ci = dev_get_drvdata(dev);
> + struct ehci_hcd *ehci = hcd_to_ehci(hcd);
>   int ret;
>  
>   ret = ehci_setup(hcd);
>   if (ret)
>   return ret;
>  
> + ehci->need_io_watchdog = 0;
> +
>   ci_platform_configure(ci);
>  
>   return ret;

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

Re: [PATCH] usb: ehci-platform: add reset controller number in struct ehci_platform_priv

[Jiancheng Xue]

Hi Alan,

On 2016/4/25 22:43, Alan Stern wrote:
> On Sat, 23 Apr 2016, Jiancheng Xue wrote:
> 
>> Some generic-ehci compatible controllers have more than one reset signal
>> lines, e.g., Synopsys DWC USB2.0 Host-AHB Controller has two resets bus_reset
>> and roothub_reset. Two more resets are added in this patch in order for this
>> kind of controller to use this driver directly.
>>
>> Signed-off-by: Jiancheng Xue 
> 
> 
>> +for (rst = 0; rst < EHCI_MAX_RSTS; rst++) {
>> +priv->rsts[rst] = of_reset_control_get_by_index(
>> +dev->dev.of_node, rst);
>> +if (IS_ERR(priv->rsts[rst])) {
>> +err = PTR_ERR(priv->rsts[rst]);
>> +if (err == -EPROBE_DEFER)
>> +goto err_reset;
>> +priv->rsts[rst] = NULL;
>> +break;
>> +}
>> +
>> +err = reset_control_deassert(priv->rsts[rst]);
>>  if (err)
>> -goto err_put_clks;
>> +goto err_reset;
> 
> If an error occurs here...
> 
Sorry. It's really a problem. I'll modify it in v2 like below:

err = reset_control_deassert(priv->rsts[rst]);
if(err) {
reset_control_put(priv->rsts[rst]);
goto err_reset;
}

>>  }
>>  
>>  if (pdata->big_endian_desc)
>> @@ -300,8 +305,10 @@ 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->rsts[rst]);
>> +reset_control_put(priv->rsts[rst]);
>> +}
> 
> You won't call reset_control_put() for the offending reset line.
> 
See above.

Is it OK except this bug? If so, I'll send out v2 patch.

Thank you very much!

Regards.
Jiancheng


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

Re: [PATCH 5/5] doc: usb: ci-hdrc-usb2: add property usb-charger-detection

[Peter Chen]

On Mon, Apr 25, 2016 at 10:09:20AM +, Jun Li wrote:
> Hi
> 
> > -Original Message-
> > From: Peter Chen [mailto:hzpeterc...@gmail.com]
> > Sent: Monday, April 25, 2016 2:23 PM
> > To: Jun Li 
> > Cc: Peter Chen ; linux-usb@vger.kernel.org;
> > baolin.w...@linaro.org
> > Subject: Re: [PATCH 5/5] doc: usb: ci-hdrc-usb2: add property usb-charger-
> > detection
> > 
> > On Mon, Apr 18, 2016 at 04:17:49PM +0800, Li Jun wrote:
> > > Set this property if your usb module has usb charger detect function
> > > and you want to use it.
> > >
> > > Signed-off-by: Li Jun 
> > > ---
> > >  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > > b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > > index 1084e2b..52d269e 100644
> > > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > > @@ -76,6 +76,8 @@ Optional properties:
> > >needs to make sure it does not send more than 90%
> > >maximum_periodic_data_per_frame. The use case is multiple
> > transactions, but
> > >less frame rate.
> > > +- usb-charger-detection: use usb charger detect function provided by
> > > +usb
> > > +  module; if your usb charger type detection done by PMIC, don't enable
> > this.
> > >
> > 
> > If the user doesn't set it at dts, and detection is done by PMIC, would
> > you show us the flow how it work at chipidea driver?
> 
> This patch set only focus on charger type detection by usb module, so
> PMIC case may not benefit from it.
> 
> 1. If user is sure the charger detection process can't impact the usb
>gadget enumeration, e.g. charger detection is automatically done
>before vbus is detected(like Baolin's case), nothing needs added
>at chipidea driver. Otherwise
> 2. We need a simple sync, wait the PMIC driver gets charger type before
>do gadget connect, this can be done in udc.c via 
> power_supply_get_property()
>like what Baolin does in usb_charger_get_type_by_others() in charger.c.
> 
> I intend to add the handling of case 2 by the real user of it.
> 

Ok.

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

Re: [PATCH v6 02/10] extcon: usb-gpio: add support for ACPI gpio interface

[Lu Baolu]

Hi,

On 04/26/2016 07:51 AM, Chanwoo Choi wrote:
> Hi Lu,
>
> On 2016년 04월 25일 17:04, Lu Baolu wrote:
>> GPIO resource could be retrieved through APCI as well.
>>
>> Signed-off-by: Lu Baolu 
>> Reviewed-by: Felipe Balbi 
>> Acked-by: Chanwoo Choi 
>> ---
>>  drivers/extcon/extcon-usb-gpio.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/extcon/extcon-usb-gpio.c 
>> b/drivers/extcon/extcon-usb-gpio.c
>> index af9c8b0..472c431 100644
>> --- a/drivers/extcon/extcon-usb-gpio.c
>> +++ b/drivers/extcon/extcon-usb-gpio.c
>> @@ -26,6 +26,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #define USB_GPIO_DEBOUNCE_MS20  /* ms */
>>  
>> @@ -91,7 +92,7 @@ static int usb_extcon_probe(struct platform_device *pdev)
>>  struct usb_extcon_info *info;
>>  int ret;
>>  
>> -if (!np)
>> +if (!np && !ACPI_HANDLE(dev))
>>  return -EINVAL;
>>  
>>  info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
>>
> Applied it.
>
> Thanks,
> Chanwoo Choi
>

Thank you.

Best regards,
Baolu

>

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

Re: [PATCH v6 01/10] extcon: usb-gpio: add device binding for platform device

[Lu Baolu]

Hi,

On 04/26/2016 07:51 AM, Chanwoo Choi wrote:
> Hi Lu,
>
> On 2016년 04월 25일 17:04, Lu Baolu wrote:
>> This is needed to handle the GPIO connected USB ID pin found on
>> Intel Baytrail devices.
>>
>> Signed-off-by: Lu Baolu 
>> Reviewed-by: Felipe Balbi 
>> Acked-by: Chanwoo Choi 
>> ---
>>  drivers/extcon/extcon-usb-gpio.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/extcon/extcon-usb-gpio.c 
>> b/drivers/extcon/extcon-usb-gpio.c
>> index 2b2fecf..af9c8b0 100644
>> --- a/drivers/extcon/extcon-usb-gpio.c
>> +++ b/drivers/extcon/extcon-usb-gpio.c
>> @@ -206,6 +206,12 @@ static const struct of_device_id usb_extcon_dt_match[] 
>> = {
>>  };
>>  MODULE_DEVICE_TABLE(of, usb_extcon_dt_match);
>>  
>> +static const struct platform_device_id usb_extcon_platform_ids[] = {
>> +{ .name = "extcon-usb-gpio", },
>> +{ /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(platform, usb_extcon_platform_ids);
>> +
>>  static struct platform_driver usb_extcon_driver = {
>>  .probe  = usb_extcon_probe,
>>  .remove = usb_extcon_remove,
>> @@ -214,6 +220,7 @@ static struct platform_driver usb_extcon_driver = {
>>  .pm = _extcon_pm_ops,
>>  .of_match_table = usb_extcon_dt_match,
>>  },
>> +.id_table = usb_extcon_platform_ids,
>>  };
>>  
>>  module_platform_driver(usb_extcon_driver);
>>
> Applied it.
>
> Thanks,
> Chanwoo Choi

Thank you.

Best regards,
Baolu
>

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

Re: [PATCHv7] usb: dwc2: Add reset control to dwc2

[John Youn]

On 4/25/2016 12:26 PM, dingu...@opensource.altera.com wrote:
> From: Dinh Nguyen 
> 
> Allow for platforms that have a reset controller driver in place to bring
> the USB IP out of reset.
> 
> Signed-off-by: Dinh Nguyen 
> ---
> v7: Use devm_reset_control_get_optional()
> v6: fix 80 line checkpatch warning in dev_err print
> v5: updated error conditions for not finding the reset property
> v4: use dev_dbg() if not a -EPROBE_DEFER
> v3: fix compile error
> v2: move to lowlevel_hw_init()
> ---
>  drivers/usb/dwc2/core.h |  1 +
>  drivers/usb/dwc2/platform.c | 22 ++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 3c58d63..f748132 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -837,6 +837,7 @@ struct dwc2_hsotg {
>   void *priv;
>   int irq;
>   struct clk *clk;
> + struct reset_control *reset;
>  
>   unsigned int queuing_high_bandwidth:1;
>   unsigned int srp_success:1;
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 88629be..d34f169 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -45,6 +45,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -337,6 +338,24 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg 
> *hsotg)
>  {
>   int i, ret;
>  
> + hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
> + if (IS_ERR(hsotg->reset)) {
> + ret = PTR_ERR(hsotg->reset);
> + switch (ret) {
> + case -ENOENT:
> + case -ENOTSUPP:
> + hsotg->reset = NULL;
> + break;
> + default:
> + dev_err(hsotg->dev, "error getting reset control %d\n",
> + ret);
> + return ret;
> + }
> + }
> +
> + if (hsotg->reset)
> + reset_control_deassert(hsotg->reset);
> +
>   /* Set default UTMI width */
>   hsotg->phyif = GUSBCFG_PHYIF16;
>  
> @@ -434,6 +453,9 @@ static int dwc2_driver_remove(struct platform_device *dev)
>   if (hsotg->ll_hw_enabled)
>   dwc2_lowlevel_hw_disable(hsotg);
>  
> + if (hsotg->reset)
> + reset_control_assert(hsotg->reset);
> +
>   return 0;
>  }
>  
> 

Thanks Dinh.

Acked-by: John Youn 


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 v6 09/12] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Monday, April 25, 2016 10:04 PM
> To: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
> 
> Hi,
> 
> On 21/04/16 09:38, Jun Li wrote:
> > Hi,
> >
> > ...
> >>
> >>  /**
> >> + * usb_gadget_start - start the usb gadget controller and connect to
> >> +bus
> >> + * @gadget: the gadget device to start
> >> + *
> >> + * This is external API for use by OTG core.
> >> + *
> >> + * Start the usb device controller and connect to bus (enable pull).
> >> + */
> >> +static int usb_gadget_start(struct usb_gadget *gadget) {
> >> +  int ret;
> >> +  struct usb_udc *udc = NULL;
> >> +
> >> +  dev_dbg(>dev, "%s\n", __func__);
> >> +  mutex_lock(_lock);
> >> +  list_for_each_entry(udc, _list, list)
> >> +  if (udc->gadget == gadget)
> >> +  goto found;
> >> +
> >> +  dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> >> +  __func__);
> >> +  mutex_unlock(_lock);
> >> +  return -EINVAL;
> >> +
> >> +found:
> >> +  ret = usb_gadget_udc_start(udc);
> >> +  if (ret)
> >> +  dev_err(>dev, "USB Device Controller didn't start: %d\n",
> >> +  ret);
> >> +  else
> >> +  usb_udc_connect_control(udc);
> >
> > For drd, it's fine, but for real otg, gadget connect should be done by
> > loc_conn() instead of gadget start.
> 
> It is upto the OTG state machine to call gadget_start() when it needs to
> connect to the bus (i.e. loc_conn()). I see no point in calling gadget
> start before.
> 
> Do you see any issue in doing so?

This is what OTG state machine does:
case OTG_STATE_B_PERIPHERAL:
 otg_chrg_vbus(otg, 0);
 otg_loc_sof(otg, 0);
 otg_set_protocol(fsm, PROTO_GADGET);
 otg_loc_conn(otg, 1);
 break;

You intend to abstract something common in this api when start gadget,
which should be called by otg_set_protocol(fsm, PROTO_GADGET); and
drd_set_protocol(fsm, PROTO_GADGET); right?

So you may move usb_udc_connect_control(IMO usb_gadget_connect()
is better)out of usb_gadget_start(), then for drd:

case OTG_STATE_B_PERIPHERAL:
 drd_set_protocol(fsm, PROTO_GADGET);
 otg_drv_vbus(otg, 0);
 usb_gadget_connect();

Li Jun

> 
> cheers,
> -roger
> 
> >
> >> +
> >> +  mutex_unlock(_lock);
> >> +
> >> +  return ret;
> >> +}
> >> +
> >> +/**
> >> + * usb_gadget_stop - disconnect from bus and stop the usb gadget
> >> + * @gadget: The gadget device we want to stop
> >> + *
> >> + * This is external API for use by OTG core.
> >> + *
> >> + * Disconnect from the bus (disable pull) and stop the
> >> + * gadget controller.
> >> + */
> >> +static int usb_gadget_stop(struct usb_gadget *gadget) {
> >> +  struct usb_udc *udc = NULL;
> >> +
> >> +  dev_dbg(>dev, "%s\n", __func__);
> >> +  mutex_lock(_lock);
> >> +  list_for_each_entry(udc, _list, list)
> >> +  if (udc->gadget == gadget)
> >> +  goto found;
> >> +
> >> +  dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> >> +  __func__);
> >> +  mutex_unlock(_lock);
> >> +  return -EINVAL;
> >> +
> >> +found:
> >> +  usb_gadget_disconnect(udc->gadget);
> >
> > Likewise, gadget disconnect also should be done by loc_conn() instead
> > of gadget stop.
> >
> >> +  udc->driver->disconnect(udc->gadget);
> >> +  usb_gadget_udc_stop(udc);
> >> +  mutex_unlock(_lock);
> >> +
> >> +  return 0;
> >> +}
> >> +
> >
> > Li Jun
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 02/10] extcon: usb-gpio: add support for ACPI gpio interface

[Chanwoo Choi]

Hi Lu,

On 2016년 04월 25일 17:04, Lu Baolu wrote:
> GPIO resource could be retrieved through APCI as well.
> 
> Signed-off-by: Lu Baolu 
> Reviewed-by: Felipe Balbi 
> Acked-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon-usb-gpio.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon-usb-gpio.c 
> b/drivers/extcon/extcon-usb-gpio.c
> index af9c8b0..472c431 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define USB_GPIO_DEBOUNCE_MS 20  /* ms */
>  
> @@ -91,7 +92,7 @@ static int usb_extcon_probe(struct platform_device *pdev)
>   struct usb_extcon_info *info;
>   int ret;
>  
> - if (!np)
> + if (!np && !ACPI_HANDLE(dev))
>   return -EINVAL;
>  
>   info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
> 

Applied it.

Thanks,
Chanwoo Choi

--
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 v6 01/10] extcon: usb-gpio: add device binding for platform device

[Chanwoo Choi]

Hi Lu,

On 2016년 04월 25일 17:04, Lu Baolu wrote:
> This is needed to handle the GPIO connected USB ID pin found on
> Intel Baytrail devices.
> 
> Signed-off-by: Lu Baolu 
> Reviewed-by: Felipe Balbi 
> Acked-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon-usb-gpio.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/extcon/extcon-usb-gpio.c 
> b/drivers/extcon/extcon-usb-gpio.c
> index 2b2fecf..af9c8b0 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -206,6 +206,12 @@ static const struct of_device_id usb_extcon_dt_match[] = 
> {
>  };
>  MODULE_DEVICE_TABLE(of, usb_extcon_dt_match);
>  
> +static const struct platform_device_id usb_extcon_platform_ids[] = {
> + { .name = "extcon-usb-gpio", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(platform, usb_extcon_platform_ids);
> +
>  static struct platform_driver usb_extcon_driver = {
>   .probe  = usb_extcon_probe,
>   .remove = usb_extcon_remove,
> @@ -214,6 +220,7 @@ static struct platform_driver usb_extcon_driver = {
>   .pm = _extcon_pm_ops,
>   .of_match_table = usb_extcon_dt_match,
>   },
> + .id_table = usb_extcon_platform_ids,
>  };
>  
>  module_platform_driver(usb_extcon_driver);
> 

Applied it.

Thanks,
Chanwoo Choi
--
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/3] usb: musb: jz4740: fix error check of usb_get_phy()

[Bin Liu]

From: Vladimir Zapolskiy 

The usb_get_phy() function returns either a valid pointer to phy or
ERR_PTR() error, check for NULL always fails and may lead to oops on
error path, fix this issue.

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/jz4740.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
index 5e5a8fa..bc88899 100644
--- a/drivers/usb/musb/jz4740.c
+++ b/drivers/usb/musb/jz4740.c
@@ -83,9 +83,9 @@ static int jz4740_musb_init(struct musb *musb)
 {
usb_phy_generic_register();
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
-   if (!musb->xceiv) {
+   if (IS_ERR(musb->xceiv)) {
pr_err("HS UDC: no transceiver configured\n");
-   return -ENODEV;
+   return PTR_ERR(musb->xceiv);
}
 
/* Silicon does not implement ConfigData register.
-- 
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/3] Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb return in bottom half"

[Bin Liu]

This reverts commit 2035772010db634ec8566b658fb1cd87ec47ac77.

Commit 20357720 claims throughput improvement for MSC/UVC, but I
don't see much improvement. Following are the MSC measurement using
dd on AM335x GP EVM.

with BCD_BH:read: 14.9MB/s, write: 20.9MB/s
without BCD_BH: read: 15.2MB/s, write: 21.2MB/s

However with this commit the following regressions have been observed.

1. ASIX usb-ethernet dongle is completely broken on UDP RX.

2. Unpluging a 3G modem, which uses option driver, behind a hub causes
   console log flooding with the following message.

   option_instat_callback: error -71

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 58487a4..2f8ad7f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2735,7 +2735,7 @@ static const struct hc_driver musb_hc_driver = {
.description= "musb-hcd",
.product_desc   = "MUSB HDRC host driver",
.hcd_priv_size  = sizeof(struct musb *),
-   .flags  = HCD_USB2 | HCD_MEMORY | HCD_BH,
+   .flags  = HCD_USB2 | HCD_MEMORY,
 
/* not using irq handler or reset hooks from usbcore, since
 * those must be shared with peripheral code for OTG configs
-- 
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/3] usb: musb: gadget: nuke endpoint before setting its descriptor to NULL

[Bin Liu]

From: Tal Shorer 

Some functions, such as f_sourcesink, rely on an endpoint's desc
field during their requests' complete() callback, so clear it only
_after_ nuking all requests to avoid NULL pointer dereference.

Signed-off-by: Tal Shorer 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_gadget.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 87bd578..152865b 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1164,12 +1164,12 @@ static int musb_gadget_disable(struct usb_ep *ep)
musb_writew(epio, MUSB_RXMAXP, 0);
}
 
-   musb_ep->desc = NULL;
-   musb_ep->end_point.desc = NULL;
-
/* abort all pending DMA and requests */
nuke(musb_ep, -ESHUTDOWN);
 
+   musb_ep->desc = NULL;
+   musb_ep->end_point.desc = NULL;
+
schedule_work(>irq_work);
 
spin_unlock_irqrestore(&(musb->lock), flags);
-- 
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 0/3] musb fixes for v4.6-rc6

[Bin Liu]

Hi Greg,

Here are a few fixes for musb for v4.6-rc6.

Tal's patch fixes a musb teardown bug which is uncovered by a g_zero
change in v4.3. HCD_BH flag does not bring any visible benefit but breaks
a few cases, so revert it. Vladimir's patch fixes pointer error check.

Please let me know if any change is needed.

Thanks,
-Bin.

Bin Liu (1):
  Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb return
in bottom half"

Tal Shorer (1):
  usb: musb: gadget: nuke endpoint before setting its descriptor to NULL

Vladimir Zapolskiy (1):
  usb: musb: jz4740: fix error check of usb_get_phy()

 drivers/usb/musb/jz4740.c  | 4 ++--
 drivers/usb/musb/musb_gadget.c | 6 +++---
 drivers/usb/musb/musb_host.c   | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

-- 
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 528/528] enable PL-2501

[Heiko Bauke]

Signed-off-by: Heiko Bauke 
---
 drivers/net/usb/plusb.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 22e1a9a..104fc10 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -102,7 +102,7 @@ static int pl_reset(struct usbnet *dev)
 }
 
 static const struct driver_infoprolific_info = {
-   .description =  "Prolific PL-2301/PL-2302/PL-25A1",
+   .description =  "Prolific PL-2301/PL-2302/PL-2501/PL-25A1",
.flags =FLAG_POINTTOPOINT | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset =pl_reset,
@@ -129,6 +129,9 @@ static const struct usb_device_id   products [] = {
 
 /* high speed cables */
 {
+   USB_DEVICE(0x067b, 0x2501), /* PL-2501 */
+   .driver_info =  (unsigned long) _info,
+}, {
USB_DEVICE(0x067b, 0x25a1), /* PL-25A1, no eeprom */
.driver_info =  (unsigned long) _info,
 }, {
@@ -158,5 +161,5 @@ static struct usb_driver plusb_driver = {
 module_usb_driver(plusb_driver);
 
 MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/2501/25A1 USB Host to Host Link 
Driver");
 MODULE_LICENSE("GPL");
-- 
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

[PATCHv7] usb: dwc2: Add reset control to dwc2

[dinguyen]

From: Dinh Nguyen 

Allow for platforms that have a reset controller driver in place to bring
the USB IP out of reset.

Signed-off-by: Dinh Nguyen 
---
v7: Use devm_reset_control_get_optional()
v6: fix 80 line checkpatch warning in dev_err print
v5: updated error conditions for not finding the reset property
v4: use dev_dbg() if not a -EPROBE_DEFER
v3: fix compile error
v2: move to lowlevel_hw_init()
---
 drivers/usb/dwc2/core.h |  1 +
 drivers/usb/dwc2/platform.c | 22 ++
 2 files changed, 23 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3c58d63..f748132 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -837,6 +837,7 @@ struct dwc2_hsotg {
void *priv;
int irq;
struct clk *clk;
+   struct reset_control *reset;
 
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 88629be..d34f169 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -337,6 +338,24 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
 {
int i, ret;
 
+   hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
+   if (IS_ERR(hsotg->reset)) {
+   ret = PTR_ERR(hsotg->reset);
+   switch (ret) {
+   case -ENOENT:
+   case -ENOTSUPP:
+   hsotg->reset = NULL;
+   break;
+   default:
+   dev_err(hsotg->dev, "error getting reset control %d\n",
+   ret);
+   return ret;
+   }
+   }
+
+   if (hsotg->reset)
+   reset_control_deassert(hsotg->reset);
+
/* Set default UTMI width */
hsotg->phyif = GUSBCFG_PHYIF16;
 
@@ -434,6 +453,9 @@ static int dwc2_driver_remove(struct platform_device *dev)
if (hsotg->ll_hw_enabled)
dwc2_lowlevel_hw_disable(hsotg);
 
+   if (hsotg->reset)
+   reset_control_assert(hsotg->reset);
+
return 0;
 }
 
-- 
2.6.2

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

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

[Grygorii Strashko]

Now not all DMA paremters configured properly for "xhci-hcd" platform
device which is created manually. For example: dma_pfn_offset, dam_ops
and iommu configuration will not corresponds "dwc3" devices
configuration. As result, this will cause problems like wrong DMA
addresses translation on platforms with LPAE enabled like Keystone 2.

When platform is using DT boot mode the DMA configuration will be
parsed and applied from DT, so, to fix this issue, reuse
of_dma_configure() API and retrieve DMA configuartion for "xhci-hcd"
from DWC3 device node.

Cc: David Fisher 
Cc: Catalin Marinas 
Cc: "Thang Q. Nguyen" 
Cc: Yoshihiro Shimoda 
Signed-off-by: Grygorii Strashko 
---
 drivers/usb/dwc3/host.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..93c8ef9 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 
 #include "core.h"
 
@@ -32,12 +33,7 @@ int dwc3_host_init(struct dwc3 *dwc)
return -ENOMEM;
}
 
-   dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
-
xhci->dev.parent= dwc->dev;
-   xhci->dev.dma_mask  = dwc->dev->dma_mask;
-   xhci->dev.dma_parms = dwc->dev->dma_parms;
-
dwc->xhci = xhci;
 
ret = platform_device_add_resources(xhci, dwc->xhci_resources,
@@ -62,6 +58,15 @@ int dwc3_host_init(struct dwc3 *dwc)
phy_create_lookup(dwc->usb3_generic_phy, "usb3-phy",
  dev_name(>dev));
 
+   if (IS_ENABLED(CONFIG_OF) && dwc->dev->of_node) {
+   of_dma_configure(>dev, dwc->dev->of_node);
+   } else {
+   dma_set_coherent_mask(>dev, dwc->dev->coherent_dma_mask);
+
+   xhci->dev.dma_mask  = dwc->dev->dma_mask;
+   xhci->dev.dma_parms = dwc->dev->dma_parms;
+   }
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc->dev, "failed to register xHCI device\n");
-- 
2.8.1

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

Re: USB gadgets with configfs hang reboot

[Ivaylo Dimitrov]

Hi,

On 18.04.2016 10:55, Felipe Balbi wrote:


Hi,

Ivaylo Dimitrov  writes:

Hi,

On 16.01.2016 12:40, Ivaylo Dimitrov wrote:

Hi,

On 16.01.2016 00:48, Tony Lindgren wrote:

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot
hangs the system. This happens at least with v4.4, and I've reproduced
it with dwc3 and musb so it seems to be generic.



Having configfs is not needed, disabling usb gadgets (#
CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff
hang issue on N900. Also, g_nokia is not a module in the config I use,
so I guess the problem is not related whether gadgets are modular or
not. Unfortunately I was not able to test reboot, as rootfs became
corrupted after the first poweroff :( . So it looks like my theory that
onenand corruption on N900 is because poweroff/reboot hangs is wrong.


(copied from "Re: [PATCH] usb: f_mass_storage: test whether thread is
running before starting another" thread)

Yet another problem with USB gadget, this time with f_acm - if there is
an open /dev/ttyGSn device, it is impossible to reboot/power down the
device.

My investigation shown that there is a process(pnatd) that opens
/dev/ttyGSn devices, so gserial_free_port() hangs on
wait_event(port->close_wait, gs_closed(port)); if I do "cd
/sys/bus/platform/drivers/musb-hdrc && echo musb-hdrc.0.auto > unbind".

Unfortunately I don't have serial debug port connector on my N900, so I
can't capture logs after the reboot command, however, I suspect it hangs
on the same place as with unbind.

That looks weird, as one would expect that close() is called when the
kernel kills user processes on reboot/powerdown.


right, care to enable lockup detection and see if you can get more info
out of it ?



Nothing interesting, besides that screen does not work :(. However, the 
device boots, I can connect through wifi and reboot still hangs. Also, I 
don't see that port->close_wait in /proc/lockdep. Is that expected?


Is there a reason why a process (pnatd in this particular case) doesn't 
get killed on reboot?


Ivo
--
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: [PATCHv6 2/2] usb: dwc2: Add reset control to dwc2

[John Youn]

On 4/25/2016 12:30 AM, Philipp Zabel wrote:
> Hi John,
> 
> Am Freitag, den 22.04.2016, 20:31 -0700 schrieb John Youn:
>> On 4/20/2016 2:31 PM, dingu...@opensource.altera.com wrote:
>>> From: Dinh Nguyen 
>>>
>>> Allow for platforms that have a reset controller driver in place to bring
>>> the USB IP out of reset.
>>>
>>> Signed-off-by: Dinh Nguyen 
>>> ---
>>> v6: fix 80 line checkpatch warning in dev_err print
>>> v5: updated error conditions for not finding the reset property
>>> v4: use dev_dbg() if not a -EPROBE_DEFER
>>> v3: fix compile error
>>> v2: move to lowlevel_hw_init()
>>> ---
>>>  drivers/usb/dwc2/core.h |  1 +
>>>  drivers/usb/dwc2/platform.c | 21 +
>>>  2 files changed, 22 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>>> index 3c58d63..f748132 100644
>>> --- a/drivers/usb/dwc2/core.h
>>> +++ b/drivers/usb/dwc2/core.h
>>> @@ -837,6 +837,7 @@ struct dwc2_hsotg {
>>> void *priv;
>>> int irq;
>>> struct clk *clk;
>>> +   struct reset_control *reset;
>>>  
>>> unsigned int queuing_high_bandwidth:1;
>>> unsigned int srp_success:1;
>>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>>> index 88629be..fa2c097 100644
>>> --- a/drivers/usb/dwc2/platform.c
>>> +++ b/drivers/usb/dwc2/platform.c
>>> @@ -45,6 +45,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #include 
>>>  
>>> @@ -337,6 +338,23 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg 
>>> *hsotg)
>>>  {
>>> int i, ret;
>>>  
>>> +   hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
>>> +   if (IS_ERR(hsotg->reset)) {
>>> +   ret = PTR_ERR(hsotg->reset);
>>> +   switch (ret) {
>>> +   case -ENOENT:
>>> +   hsotg->reset = NULL;
>>> +   break;
>>> +   default:
>>> +   dev_err(hsotg->dev, "error getting reset control %d\n",
>>> +   ret);
>>> +   return ret;
>>> +   }
>>> +   }
>>> +
>>> +   if (hsotg->reset)
>>> +   reset_control_deassert(hsotg->reset);
>>> +
>>> /* Set default UTMI width */
>>> hsotg->phyif = GUSBCFG_PHYIF16;
>>>  
>>> @@ -434,6 +452,9 @@ static int dwc2_driver_remove(struct platform_device 
>>> *dev)
>>> if (hsotg->ll_hw_enabled)
>>> dwc2_lowlevel_hw_disable(hsotg);
>>>  
>>> +   if (hsotg->reset)
>>> +   reset_control_assert(hsotg->reset);
>>> +
>>> return 0;
>>>  }
>>>  
>>>
>>
>> Hi Dinh,
>>
>> On my system, with no reset controller configured, this fails
>> devm_reset_control_get() with -EINVAL, and it also spits out a
>> backtrace.
>>
>> Hi Philipp,
>>
>> I think devm_reset_control_get() should return either NULL or some
>> other error to indicate that the reset controller is not
>> configured. That way we can check it and handle that condition. If we
>> check for -EINVAL, we might miss a legitimate error that is returning
>> -EINVAL.
>>
>> Also I think the WARN_ON(1) should be removed for this case.
>>
>> Any thoughts on this or other suggestions to resolve it?
> 
> It is invalid to call (devm_)reset_control_get if the framework is
> disabled, so that error code is correct. The only reason there are even
> stubs for (devm_)reset_control_get is for compile tests. Either enable
> CONFIG_RESET_CONTROLLER or use (devm_)reset_control_get_optional.
> 

Ok thanks Philipp.

I guess the correct call would be the optional one then.

Dinh,

Could you respin with the necessary changes?

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: [EXT] Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added comments to CRTSCT flag code.

[Konstantin Shkolnyy]

I was planning to define all these bits in a separate future patch.
Would you rather prefer the magic numbers defined before fixing the bugs?
I guess I can do that. Is something like this acceptable?

/* CP210X_GET_FLOW/CP210X_SET_FLOW read/write these 0x10 bytes */
struct cp210x_flow_ctl {
u8  SERIAL_DTR_MASK: 2; /* byte 0 */
u8 : 1;
u8  SERIAL_CTS_HANDSHAKE   : 1;
u8  SERIAL_DSR_HANDSHAKE   : 1;
u8  SERIAL_DCD_HANDSHAKE   : 1;
u8  SERIAL_DSR_SENSITIVITY : 1;
u8 : 1;
u8; /* byte 1 */
u8; /* byte 2 */
u8; /* byte 3 */
u8  SERIAL_AUTO_TRANSMIT   : 1; /* byte 4 */
u8  SERIAL_AUTO_RECEIVE: 1;
u8  SERIAL_ERROR_CHAR  : 1;
u8  SERIAL_NULL_STRIPPING  : 1;
u8  SERIAL_BREAK_CHAR  : 1;
u8 : 1;
u8  SERIAL_RTS_MASK: 2;
u8; /* byte 5 */
u8; /* byte 6 */
u8 : 7; /* byte 7 */
u8  SERIAL_XOFF_CONTINUE   : 1;
__le32  ulXonLimit;
__le32  ulXoffLimit;
} __packed;

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Johan Hovold
> Sent: Monday, April 25, 2016 05:17
> To: Konstantin Shkolnyy
> Cc: jo...@kernel.org; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [EXT] Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added comments
> to CRTSCT flag code.
> 
> On Sun, Apr 24, 2016 at 12:09:21PM -0500, Konstantin Shkolnyy wrote:
> > Documented "magic numbers" used in the CRTSCT flag code in terms of
> > register bit names from the chip specification.
> 
> Documenting these is long overdue. I even started adding defines just to
> be able to review the first patch in the series.
> 
> > Signed-off-by: Konstantin Shkolnyy 
> > ---
> >  drivers/usb/serial/cp210x.c | 38
> ++
> >  1 file changed, 34 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> > index ede5c52..b2321a7 100644
> > --- a/drivers/usb/serial/cp210x.c
> > +++ b/drivers/usb/serial/cp210x.c
> > @@ -790,7 +790,7 @@ static void cp210x_get_termios_port(struct
> usb_serial_port *port,
> >
> > cp210x_read_reg_block(port, CP210X_GET_FLOW, modem_ctl,
> > sizeof(modem_ctl));
> > -   if (modem_ctl[0] & 0x08) {
> > +   if (modem_ctl[0] & 0x08) { /* if SERIAL_CTS_HANDSHAKE */
> 
> But instead of adding comments like this one and below, please add
> proper defines for the various flags and masks. That will make the code
> mostly self-explanatory.
> 
> > dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);
> > cflag |= CRTSCTS;
> > } else {
> > @@ -952,17 +952,47 @@ static void cp210x_set_termios(struct tty_struct
> *tty,
> > __func__, modem_ctl[0], modem_ctl[4],
> modem_ctl[7]);
> >
> > if (cflag & CRTSCTS) {
> > -   modem_ctl[0] &= ~0x7B;
> > +   modem_ctl[0] &= ~0x7B; /* keep reserved D2 and D7
> */
> > +   /*
> > +* D1-D0 SERIAL_DTR_MASK =01b: DTR is held
> active
> > +* D3 SERIAL_CTS_HANDSHAKE   =1: CTS is a
> handshake line
> > +* D4 SERIAL_DSR_HANDSHAKE   =0
> > +* D5 SERIAL_DCD_HANDSHAKE   =0
> > +* D6 SERIAL_DSR_SENSITIVITY =0
> > +*/
> 
> > -   modem_ctl[7] = 0;
> > +   modem_ctl[7] = 0; /* SERIAL_XOFF_CONTINUE = 0 */
> 
> And this would be better as a bit operation as well (as already
> mentioned).
> 
> Thanks,
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/1] usb: lpm: add boot flag to disable lpm

[Alan Stern]

On Mon, 25 Apr 2016, Matthew Giassa wrote:

> 
> Good morning Alan,
> 
> The most recent patch you provided resolved the lockup issue I have been
> encountering. I will carry out full release testing shortly to further
> validate it.
> 
> Would this be something that could be proposed for inclusion in the
> kernel, pending cosmetic changes (ie: `alantest', etc)?

If your testing works out, I will remove the extra debugging code and 
submit the resulting patch for inclusion in the kernel and in the 
-stable release series.  I don't think anybody will object to the 
patch... we'll see.

Alan Stern

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

Re: [PATCH v6 04/10] regulator: fixed: add support for ACPI interface

[Mark Brown]

On Mon, Apr 25, 2016 at 04:04:50PM +0800, Lu Baolu wrote:

> + ret = device_property_read_string(dev, "gpio-name", _name);
> + if (!ret) {
> + gpiod = gpiod_get(dev, gpio_name, GPIOD_ASIS);
> + if (!IS_ERR(gpiod)) {

This doesn't look like it's a standard ACPI binding for GPIOs, why are
we using a property to get the GPIO noame?


signature.asc
Description: PGP signature

Re: [PATCH v1 1/1] usb: gadget: NCM: NULL pointer dereference in eth_start_xmit

[One Thousand Gnomes]

On Mon, 25 Apr 2016 16:25:03 +0100
 wrote:

> From: Jim Baxter 
> 
> "Unable to handle kernel NULL pointer dereference at virtual address
> 0078" is reported with "PC is at eth_start_xmit+0x19c/0x378 [u_ether]"
> 
> The failure scenario is seen when closing the NCM connection while the
> TCP/IPv6 stack is still trying to transmit over NCM.
> 
> Defensive code is missing from commit
> 6d3865f9d41f15ddbcecaa6722871fc0db21d7ab
> "usb: gadget: NCM: Add transmit multi-frame."

This looks inadequate. Surely you also need to hold dev->lock ?

Also it'll also crash at the no zlp test with the same problem.

Alan
--
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/1] usb: lpm: add boot flag to disable lpm

[Matthew Giassa]

Good morning Alan,

The most recent patch you provided resolved the lockup issue I have been
encountering. I will carry out full release testing shortly to further
validate it.

Would this be something that could be proposed for inclusion in the
kernel, pending cosmetic changes (ie: `alantest', etc)?

Thank you.



On Fri, 15 Apr 2016, Matthew Giassa wrote:

> Good afternoon Alan,
> 
> Attached is the requested usbmon output. I started the camera, had a lot
> of config read/write calls complete, and was able to eventually get one
> frame of image data to be saved and rendered.

Obviously something is going on that I don't understand.  Try this 
patch, which has extra debugging output added, in place of the earler 
one.  I won't need to see any usbmon output, just the dmesg log.

(And you don't have to post the entire thing, with hundreds of 
repetitions of the same information over and over again.  Two or three 
iterations will be fine.)

Alan Stern



Index: usb-4.4/include/linux/usb.h
===
--- usb-4.4.orig/include/linux/usb.h
+++ usb-4.4/include/linux/usb.h
@@ -1076,7 +1076,7 @@ struct usbdrv_wrap {
  * for interfaces bound to this driver.
  * @soft_unbind: if set to 1, the USB core will not kill URBs and
disable
  * endpoints before calling the driver's disconnect method.
- * @disable_hub_initiated_lpm: if set to 0, the USB core will not allow
hubs
+ * @disable_hub_initiated_lpm: if set to 1, the USB core will not allow
hubs
  * to initiate lower power link state transitions when an idle timeout
  * occurs.  Device-initiated USB 3.0 link PM will still be allowed.
  *
Index: usb-4.4/drivers/usb/core/driver.c
===
--- usb-4.4.orig/drivers/usb/core/driver.c
+++ usb-4.4/drivers/usb/core/driver.c
@@ -284,7 +284,7 @@ static int usb_probe_interface(struct de
struct usb_device *udev = interface_to_usbdev(intf);
const struct usb_device_id *id;
int error = -ENODEV;
-   int lpm_disable_error;
+   int lpm_disable_error = -ENODEV;
 
dev_dbg(dev, "%s\n", __func__);
 
@@ -336,12 +336,14 @@ static int usb_probe_interface(struct de
 * setting during probe, that should also be fine. 
usb_set_interface()
 * will attempt to disable LPM, and fail if it can't disable it.
 */
-   lpm_disable_error = usb_unlocked_disable_lpm(udev);
-   if (lpm_disable_error && driver->disable_hub_initiated_lpm) {
-   dev_err(>dev, "%s Failed to disable LPM for driver %s\n.",
-   __func__, driver->name);
-   error = lpm_disable_error;
-   goto err;
+   if (driver->disable_hub_initiated_lpm) {
+   lpm_disable_error = usb_unlocked_disable_lpm(udev);
+   if (lpm_disable_error) {
+   dev_err(>dev, "%s Failed to disable LPM for 
driver %s\n.",
+   __func__, driver->name);
+   error = lpm_disable_error;
+   goto err;
+   }
}
 
/* Carry out a deferred switch to altsetting 0 */
@@ -391,7 +393,8 @@ static int usb_unbind_interface(struct d
struct usb_interface *intf = to_usb_interface(dev);
struct usb_host_endpoint *ep, **eps = NULL;
struct usb_device *udev;
-   int i, j, error, r, lpm_disable_error;
+   int i, j, error, r;
+   int lpm_disable_error = -ENODEV;
 
intf->condition = USB_INTERFACE_UNBINDING;
 
@@ -399,12 +402,13 @@ static int usb_unbind_interface(struct d
udev = interface_to_usbdev(intf);
error = usb_autoresume_device(udev);
 
-   /* Hub-initiated LPM policy may change, so attempt to disable LPM
until
+   /* If hub-initiated LPM policy may change, attempt to disable LPM
until
 * the driver is unbound.  If LPM isn't disabled, that's fine because
it
 * wouldn't be enabled unless all the bound interfaces supported
 * hub-initiated LPM.
 */
-   lpm_disable_error = usb_unlocked_disable_lpm(udev);
+   if (driver->disable_hub_initiated_lpm)
+   lpm_disable_error = usb_unlocked_disable_lpm(udev);
 
/*
 * Terminate all URBs for this interface unless the driver
Index: usb-4.4/drivers/usb/core/devio.c
===
--- usb-4.4.orig/drivers/usb/core/devio.c
+++ usb-4.4/drivers/usb/core/devio.c
@@ -612,6 +612,8 @@ struct usb_driver usbfs_driver = {
.resume =   driver_resume,
 };
 
+int alantest;
+
 static int claimintf(struct usb_dev_state *ps, unsigned int ifnum)
 {
struct usb_device *dev = ps->dev;
@@ -627,8 +629,11 @@ static int claimintf(struct usb_dev_stat
intf = usb_ifnum_to_if(dev, ifnum);
if (!intf)
err = 

Re: [PATCH v6 03/10] regulator: fixed: add device binding for platform device

[Mark Brown]

On Mon, Apr 25, 2016 at 04:04:49PM +0800, Lu Baolu wrote:

> This is needed to handle the GPIO connected USB vcc pin found on
> Intel Baytrail devices.

In what way is this needed?  The we defualt to using the driver name if
no platform ID table, AFAICT this is just restating the same string?


signature.asc
Description: PGP signature

[PATCH v1 1/1] usb: gadget: NCM: NULL pointer dereference in eth_start_xmit

[jim_baxter]

From: Jim Baxter 

"Unable to handle kernel NULL pointer dereference at virtual address
0078" is reported with "PC is at eth_start_xmit+0x19c/0x378 [u_ether]"

The failure scenario is seen when closing the NCM connection while the
TCP/IPv6 stack is still trying to transmit over NCM.

Defensive code is missing from commit
6d3865f9d41f15ddbcecaa6722871fc0db21d7ab
"usb: gadget: NCM: Add transmit multi-frame."


Add check for non-NULL dev->port_usb before accessing
dev->port_usb->supports_multi_frame.

Signed-off-by: Mark Craske 
Signed-off-by: Jim Baxter 

---
 drivers/usb/gadget/function/u_ether.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/u_ether.c 
b/drivers/usb/gadget/function/u_ether.c
index 637809e..68f0b7b 100644
--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -556,7 +556,8 @@ static netdev_tx_t eth_start_xmit(struct sk_buff *skb,
/* Multi frame CDC protocols may store the frame for
 * later which is not a dropped frame.
 */
-   if (dev->port_usb->supports_multi_frame)
+   if (dev->port_usb &&
+   dev->port_usb->supports_multi_frame)
goto multiframe;
goto drop;
}
-- 
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] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

[Geert Uytterhoeven]

Hi Shimoda-san,

On Thu, Apr 21, 2016 at 2:57 PM, Geert Uytterhoeven
 wrote:
> On Thu, Apr 21, 2016 at 12:27 PM, Yoshihiro Shimoda
>  wrote:
>>> > [1.565605] xhci-hcd ee00.usb: xHCI Host Controller
>>> > [1.570636] xhci-hcd ee00.usb: new USB bus registered, assigned 
>>> > bus number 5
>>> > [   22.270160] xhci-hcd ee00.usb: can't setup: -110
>>> > [   22.274931] xhci-hcd ee00.usb: USB bus 5 deregistered
>>> > [   22.280158] xhci-hcd: probe of ee00.usb failed with error -110
>>> >
>>> > The timestamp is strange to me. But, logs of R-Car H3 (ES1.0) and
>>> > R-Car H2 were the same.
>>>
>>> yeah, seems like your system timer is counting twice for each tick.
>>
>> Yes, I will investigate this later.
>
> The main clock crystal on Salvator-X is half of the expected value. But
> despite the correct value being in the DTS, there's some timer code that
> doesn't take this into account.

It's fixed by upgrading to bootloader v270:

-Architected cp15 timer(s) running at 16.66MHz (virt).
+Architected cp15 timer(s) running at 8.33MHz (virt).

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v2] hid: Fix boot delay for Creative SB Omni Surround 5.1 with quirk

[Nazar Mokrynskyi]

On 25.04.16 17:42, Jiri Kosina wrote:
> On Mon, 25 Apr 2016, Nazar Mokrynskyi wrote:
>
>> Needed for v2 of the device firmware, otherwise kernel will stuck for few
>> seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
>>
>> Signed-off-by: Nazar Mokrynskyi 
>> ---
>> No changes, just resubmission to ensure absence of undesired line breaks
> Line breaks are OK, but still your mailer converted tabs to space, which 
> equally breaks the application process.
>
> I've fixed that up manually and applied, but please look into 
> reconfiguring your MUA for any future submissions.
>
> Thanks,
>
Thank you, I'll try to fix tabs as well for the next time.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: ehci-platform: add reset controller number in struct ehci_platform_priv

[Alan Stern]

On Sat, 23 Apr 2016, Jiancheng Xue wrote:

> Some generic-ehci compatible controllers have more than one reset signal
> lines, e.g., Synopsys DWC USB2.0 Host-AHB Controller has two resets bus_reset
> and roothub_reset. Two more resets are added in this patch in order for this
> kind of controller to use this driver directly.
> 
> Signed-off-by: Jiancheng Xue 


> + for (rst = 0; rst < EHCI_MAX_RSTS; rst++) {
> + priv->rsts[rst] = of_reset_control_get_by_index(
> + dev->dev.of_node, rst);
> + if (IS_ERR(priv->rsts[rst])) {
> + err = PTR_ERR(priv->rsts[rst]);
> + if (err == -EPROBE_DEFER)
> + goto err_reset;
> + priv->rsts[rst] = NULL;
> + break;
> + }
> +
> + err = reset_control_deassert(priv->rsts[rst]);
>   if (err)
> - goto err_put_clks;
> + goto err_reset;

If an error occurs here...

>   }
>  
>   if (pdata->big_endian_desc)
> @@ -300,8 +305,10 @@ 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->rsts[rst]);
> + reset_control_put(priv->rsts[rst]);
> + }

You won't call reset_control_put() for the offending reset line.

Alan Stern

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

Re: [PATCH v2] hid: Fix boot delay for Creative SB Omni Surround 5.1 with quirk

[Jiri Kosina]

On Mon, 25 Apr 2016, Nazar Mokrynskyi wrote:

> Needed for v2 of the device firmware, otherwise kernel will stuck for few
> seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
> 
> Signed-off-by: Nazar Mokrynskyi 
> ---
> No changes, just resubmission to ensure absence of undesired line breaks

Line breaks are OK, but still your mailer converted tabs to space, which 
equally breaks the application process.

I've fixed that up manually and applied, but please look into 
reconfiguring your MUA for any future submissions.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: [PATCH v4 1/7] mfd: da8xx-cfgchip: New header file for CFGCHIP registers.

[Lee Jones]

On Thu, 14 Apr 2016, David Lechner wrote:

> We will be using a generic syscon device for the TI DA8XX SoC CFGCHIPx
> retisters. This will be used by a number of planned drivers including a
> new USB PHY driver and common clock framework drivers.
> 
> The same defines are removed from the platform_data header file since they
> are now redundant and they didn't really belong there anyway.
> 
> Signed-off-by: David Lechner 
> ---
> 
> v4 changes:
> 
> * dropped individual CFGCHIPn_REG defines in favor of CFGCHIP(n)
> 
> 
>  include/linux/mfd/da8xx-cfgchip.h | 153 
> ++
>  include/linux/platform_data/usb-davinci.h |  22 -

Works for me.

Acked-by: Lee Jones 

Since this is a new file, I'm happy for it to be taken in via another
tree.

>  2 files changed, 153 insertions(+), 22 deletions(-)
>  create mode 100644 include/linux/mfd/da8xx-cfgchip.h
> 
> diff --git a/include/linux/mfd/da8xx-cfgchip.h 
> b/include/linux/mfd/da8xx-cfgchip.h
> new file mode 100644
> index 000..799e575
> --- /dev/null
> +++ b/include/linux/mfd/da8xx-cfgchip.h
> @@ -0,0 +1,153 @@
> +/*
> + * TI DaVinci DA8xx CHIPCFGx registers for syscon consumers.
> + *
> + * Copyright (C) 2016 David Lechner 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __LINUX_MFD_DA8XX_CFGCHIP_H
> +#define __LINUX_MFD_DA8XX_CFGCHIP_H
> +
> +#include 
> +
> +/* register offset (32-bit registers) */
> +#define CFGCHIP(n)   (n * 4)
> +
> +/* CFGCHIP0 (PLL0/EDMA3_0) register bits */
> +#define CFGCHIP0_PLL_MASTER_LOCK BIT(4)
> +#define CFGCHIP0_EDMA30TC1DBS(n) (n << 2)
> +#define CFGCHIP0_EDMA30TC1DBS_MASK   CFGCHIP0_EDMA30TC1DBS(0x3)
> +#define CFGCHIP0_EDMA30TC1DBS_16 CFGCHIP0_EDMA30TC1DBS(0x0)
> +#define CFGCHIP0_EDMA30TC1DBS_32 CFGCHIP0_EDMA30TC1DBS(0x1)
> +#define CFGCHIP0_EDMA30TC1DBS_64 CFGCHIP0_EDMA30TC1DBS(0x2)
> +#define CFGCHIP0_EDMA30TC0DBS(n) (n << 0)
> +#define CFGCHIP0_EDMA30TC0DBS_MASK   CFGCHIP0_EDMA30TC0DBS(0x3)
> +#define CFGCHIP0_EDMA30TC0DBS_16 CFGCHIP0_EDMA30TC0DBS(0x0)
> +#define CFGCHIP0_EDMA30TC0DBS_32 CFGCHIP0_EDMA30TC0DBS(0x1)
> +#define CFGCHIP0_EDMA30TC0DBS_64 CFGCHIP0_EDMA30TC0DBS(0x2)
> +
> +/* CFGCHIP1 (eCAP/HPI/EDMA3_1/eHRPWM TBCLK/McASP0 AMUTEIN) register bits */
> +#define CFGCHIP1_CAP2SRC(n)  (n << 27)
> +#define CFGCHIP1_CAP2SRC_MASKCFGCHIP1_CAP2SRC(0x1f)
> +#define CFGCHIP1_CAP2SRC_ECAP_PINCFGCHIP1_CAP2SRC(0x0)
> +#define CFGCHIP1_CAP2SRC_MCASP0_TX   CFGCHIP1_CAP2SRC(0x1)
> +#define CFGCHIP1_CAP2SRC_MCASP0_RX   CFGCHIP1_CAP2SRC(0x2)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP2SRC(0x7)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_RX  CFGCHIP1_CAP2SRC(0x8)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_TX  CFGCHIP1_CAP2SRC(0x9)
> +#define CFGCHIP1_CAP2SRC_EMAC_C0_MISCCFGCHIP1_CAP2SRC(0xa)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xb)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_RX  CFGCHIP1_CAP2SRC(0xc)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_TX  CFGCHIP1_CAP2SRC(0xd)
> +#define CFGCHIP1_CAP2SRC_EMAC_C1_MISCCFGCHIP1_CAP2SRC(0xe)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX_THRESHOLDCFGCHIP1_CAP2SRC(0xf)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_RX  CFGCHIP1_CAP2SRC(0x10)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_TX  CFGCHIP1_CAP2SRC(0x11)
> +#define CFGCHIP1_CAP2SRC_EMAC_C2_MISCCFGCHIP1_CAP2SRC(0x12)
> +#define CFGCHIP1_CAP1SRC(n)  (n << 22)
> +#define CFGCHIP1_CAP1SRC_MASKCFGCHIP1_CAP1SRC(0x1f)
> +#define CFGCHIP1_CAP1SRC_ECAP_PINCFGCHIP1_CAP1SRC(0x0)
> +#define CFGCHIP1_CAP1SRC_MCASP0_TX   CFGCHIP1_CAP1SRC(0x1)
> +#define CFGCHIP1_CAP1SRC_MCASP0_RX   CFGCHIP1_CAP1SRC(0x2)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX_THRESHOLDCFGCHIP1_CAP1SRC(0x7)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_RX  CFGCHIP1_CAP1SRC(0x8)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_TX  CFGCHIP1_CAP1SRC(0x9)
> +#define CFGCHIP1_CAP1SRC_EMAC_C0_MISCCFGCHIP1_CAP1SRC(0xa)
> +#define CFGCHIP1_CAP1SRC_EMAC_C1_RX_THRESHOLDCFGCHIP1_CAP1SRC(0xb)
> +#define CFGCHIP1_CAP1SRC_EMAC_C1_RX  CFGCHIP1_CAP1SRC(0xc)
> +#define 

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Roger Quadros]

Peter,

On 21/04/16 09:52, Peter Chen wrote:
> On Tue, Apr 05, 2016 at 05:05:12PM +0300, Roger Quadros wrote:
>> It provides APIs for the following tasks
>>
>> - Registering an OTG/dual-role capable controller
>> - Registering Host and Gadget controllers to OTG core
>> - Providing inputs to and kicking the OTG state machine
>>
>> Provide a dual-role device (DRD) state machine.
>> DRD mode is a reduced functionality OTG mode. In this mode
>> we don't support SRP, HNP and dynamic role-swap.
>>
>> In DRD operation, the controller mode (Host or Peripheral)
>> is decided based on the ID pin status. Once a cable plug (Type-A
>> or Type-B) is attached the controller selects the state
>> and doesn't change till the cable in unplugged and a different
>> cable type is inserted.
>>
>> As we don't need most of the complex OTG states and OTG timers
>> we implement a lean DRD state machine in usb-otg.c.
>> The DRD state machine is only interested in 2 hardware inputs
>> 'id' and 'b_sess_vld'.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/common/Makefile  |2 +-
>>  drivers/usb/common/usb-otg.c | 1058 
>> ++
>>  drivers/usb/common/usb-otg.h |   71 +++
>>  drivers/usb/core/Kconfig |2 +-
>>  include/linux/usb/gadget.h   |2 +
>>  include/linux/usb/hcd.h  |1 +
>>  include/linux/usb/otg-fsm.h  |7 +
>>  include/linux/usb/otg.h  |  154 +-
>>  8 files changed, 1292 insertions(+), 5 deletions(-)
>>  create mode 100644 drivers/usb/common/usb-otg.c
>>  create mode 100644 drivers/usb/common/usb-otg.h
>>
>> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
>> index f8f2c88..730d928 100644
>> --- a/drivers/usb/common/Makefile
>> +++ b/drivers/usb/common/Makefile
>> @@ -7,5 +7,5 @@ usb-common-y   += common.o
>>  usb-common-$(CONFIG_USB_LED_TRIG) += led.o
>>  
>>  obj-$(CONFIG_USB_ULPI_BUS)  += ulpi.o
>> -usbotg-y:= usb-otg-fsm.o
>> +usbotg-y:= usb-otg.o usb-otg-fsm.o
>>  obj-$(CONFIG_USB_OTG)   += usbotg.o
>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>> new file mode 100644
>> index 000..41e762a
>> --- /dev/null
>> +++ b/drivers/usb/common/usb-otg.c
>> @@ -0,0 +1,1058 @@
>> +/**
>> + * drivers/usb/common/usb-otg.c - USB OTG core
>> + *
>> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com
>> + * Author: Roger Quadros 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 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.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "usb-otg.h"
>> +
>> +struct otg_gcd {
>> +struct usb_gadget *gadget;
>> +struct otg_gadget_ops *ops;
>> +};
>> +
>> +/* OTG device list */
>> +LIST_HEAD(otg_list);
>> +static DEFINE_MUTEX(otg_list_mutex);
>> +
>> +/* Hosts and Gadgets waiting for OTG controller */
>> +struct otg_wait_data {
>> +struct device *dev; /* OTG controller device */
>> +
>> +struct otg_hcd primary_hcd;
>> +struct otg_hcd shared_hcd;
>> +struct otg_gcd gcd;
>> +struct list_head list;
>> +};
>> +
>> +LIST_HEAD(wait_list);
>> +static DEFINE_MUTEX(wait_list_mutex);
>> +
>> +static int usb_otg_hcd_is_primary_hcd(struct usb_hcd *hcd)
>> +{
>> +if (!hcd->primary_hcd)
>> +return 1;
>> +return hcd == hcd->primary_hcd;
>> +}
> 
> Just find there is already a usb_hcd_is_primary_hcd at hcd.c,
> would you use it directly?

We can't even if we make it public as HCD can be a loadable module
and OTG is always built-in thus leading to undefined reference.

cheers,
-roger

> 
> Peter
>> +
>> +/**
>> + * Check if the OTG device is in our wait list and return
>> + * otg_wait_data, else NULL.
>> + *
>> + * wait_list_mutex must be held.
>> + */
>> +static struct otg_wait_data *usb_otg_get_wait(struct device *otg_dev)
>> +{
>> +struct otg_wait_data *wait;
>> +
>> +if (!otg_dev)
>> +return NULL;
>> +
>> +/* is there an entry for this otg_dev ?*/
>> +list_for_each_entry(wait, _list, list) {
>> +if (wait->dev == otg_dev)
>> +return wait;
>> +}
>> +
>> +return NULL;
>> +}
>> +
>> +/**
>> + * Add the hcd to our wait list
>> + */
>> +static int usb_otg_hcd_wait_add(struct device *otg_dev, struct usb_hcd *hcd,
>> +unsigned int irqnum, unsigned long irqflags,
>> +struct otg_hcd_ops *ops)
>> +{
>> +struct otg_wait_data *wait;
>> +

Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

[Roger Quadros]

Hi,

On 21/04/16 09:38, Jun Li wrote:
> Hi,
> 
> ...
>>
>>  /**
>> + * usb_gadget_start - start the usb gadget controller and connect to
>> +bus
>> + * @gadget: the gadget device to start
>> + *
>> + * This is external API for use by OTG core.
>> + *
>> + * Start the usb device controller and connect to bus (enable pull).
>> + */
>> +static int usb_gadget_start(struct usb_gadget *gadget) {
>> +int ret;
>> +struct usb_udc *udc = NULL;
>> +
>> +dev_dbg(>dev, "%s\n", __func__);
>> +mutex_lock(_lock);
>> +list_for_each_entry(udc, _list, list)
>> +if (udc->gadget == gadget)
>> +goto found;
>> +
>> +dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
>> +__func__);
>> +mutex_unlock(_lock);
>> +return -EINVAL;
>> +
>> +found:
>> +ret = usb_gadget_udc_start(udc);
>> +if (ret)
>> +dev_err(>dev, "USB Device Controller didn't start: %d\n",
>> +ret);
>> +else
>> +usb_udc_connect_control(udc);
> 
> For drd, it's fine, but for real otg, gadget connect should be done
> by loc_conn() instead of gadget start.

It is upto the OTG state machine to call gadget_start() when it needs to
connect to the bus (i.e. loc_conn()). I see no point in calling
gadget start before.

Do you see any issue in doing so?

cheers,
-roger

> 
>> +
>> +mutex_unlock(_lock);
>> +
>> +return ret;
>> +}
>> +
>> +/**
>> + * usb_gadget_stop - disconnect from bus and stop the usb gadget
>> + * @gadget: The gadget device we want to stop
>> + *
>> + * This is external API for use by OTG core.
>> + *
>> + * Disconnect from the bus (disable pull) and stop the
>> + * gadget controller.
>> + */
>> +static int usb_gadget_stop(struct usb_gadget *gadget) {
>> +struct usb_udc *udc = NULL;
>> +
>> +dev_dbg(>dev, "%s\n", __func__);
>> +mutex_lock(_lock);
>> +list_for_each_entry(udc, _list, list)
>> +if (udc->gadget == gadget)
>> +goto found;
>> +
>> +dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
>> +__func__);
>> +mutex_unlock(_lock);
>> +return -EINVAL;
>> +
>> +found:
>> +usb_gadget_disconnect(udc->gadget);
> 
> Likewise, gadget disconnect also should be done by loc_conn()
> instead of gadget stop.
> 
>> +udc->driver->disconnect(udc->gadget);
>> +usb_gadget_udc_stop(udc);
>> +mutex_unlock(_lock);
>> +
>> +return 0;
>> +}
>> +
> 
> Li Jun
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] hid: Fix boot delay for Creative SB Omni Surround 5.1 with quirk

[Nazar Mokrynskyi]

Needed for v2 of the device firmware, otherwise kernel will stuck for few
seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.

Signed-off-by: Nazar Mokrynskyi 
---
No changes, just resubmission to ensure absence of undesired line breaks
---
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/usbhid/hid-quirks.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c6eaff5..0238f01 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -259,6 +259,7 @@
 #define USB_DEVICE_ID_CORSAIR_K900x1b02

 #define USB_VENDOR_ID_CREATIVELABS0x041e
+#define USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_510x322c
 #define USB_DEVICE_ID_PRODIKEYS_PCMIDI0x2801

 #define USB_VENDOR_ID_CVTOUCH0x1ff7
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index ed2f68e..53fc856 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -71,6 +71,7 @@ static const struct hid_blacklist {
 { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK, HID_QUIRK_NOGET 
},
 { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
 { USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, 
HID_QUIRK_ALWAYS_POLL },
+{ USB_VENDOR_ID_CREATIVELABS, USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51, 
HID_QUIRK_NOGET },
 { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
 { USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU, 
HID_QUIRK_MULTI_INPUT },
 { USB_VENDOR_ID_ELAN, HID_ANY_ID, HID_QUIRK_ALWAYS_POLL },
-- 
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] hid: Fix boot delay for Creative SB Omni Surround 5.1 with quirk

[Jiri Kosina]

On Mon, 25 Apr 2016, Nazar Mokrynskyi wrote:

> This is the first time doing contribution to kernel, didn't know
> Thunderbird will break lines, but looks like I've just configured it
> correctly now, so should not happen again.
> 
> I can re-send it if absolutely necessary.

Please do. It'll save me from rather boring hand-editting of the patch, 
and we'll double-check whether your Thunderbird is now properly configured 
as a bonus :)

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Kishon Vijay Abraham I]

Hi,

On Monday 18 April 2016 05:20 PM, Thierry Reding wrote:
> On Wed, Apr 06, 2016 at 07:08:24PM +0200, Thierry Reding wrote:
> [...]
>> I attached what I came up with. It extends the OF PHY provider registry
>> by allowing an additional node to be specified that if specified will
>> serve as the parent for the child lookup (and hence overrides the
>> default node that's taken from the struct device).
>>
>> It is a fairly trivial patch, and you'll notice the bulk of the changes
>> is adding the additional parameter in a number of different places. The
>> only thing I'm not quite happy about is that we start needing to pass a
>> fairly large number of arguments. But perhaps it's still okay.
>>
>> An alternative would be to make struct phy_provider embeddable into
>> driver private structures. That way they could be completely initialized
>> by a driver before being passed to the __of_phy_provider_register()
>> function (much like struct gpio_chip and others). That would be a fairly
>> intrusive change, one that I'd be willing to take on, though I'd like to
>> have Kishon's opinion on this before going ahead.
>>
>> For reference, here's what I'm imagining:
>>
>>  struct foo_phy_provider {
>>  struct phy_provider base;
>>  ...
>>  };
>>
>>  int foo_probe(struct platform_device *pdev)
>>  {
>>  struct foo_phy_provider *priv;
>>  ...
>>
>>  priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
>>  if (!priv)
>>  return -ENOMEM;
>>
>>  priv->base.dev = >dev;
>>  priv->base.of_xlate = foo_of_xlate;
>>
>>  err = devm_of_phy_provider_register(>base);
>>  if (err < 0)
>>  return err;
>>
>>  ...
>>  }
>>
>> And of course adapt the signature of the __of_phy_provider_register()
>> function and remove the allocation from it.
>>
>> Thierry
>>
>> --- >8 ---
>> From 15e5348a1a63837efd00309fdce5cda979498f77 Mon Sep 17 00:00:00 2001
>> From: Thierry Reding 
>> Date: Tue, 5 Apr 2016 17:17:34 +0200
>> Subject: [PATCH] phy: core: Allow children node to be overridden
>>
>> In order to more flexibly support device tree bindings, allow drivers to
>> override the container of the child nodes. By default the device node of
>> the PHY provider is assumed to be the parent for children, but bindings
>> may decide to add additional levels for better organization.
>>
>> Signed-off-by: Thierry Reding 
>> ---
>>  Documentation/phy.txt   | 16 ++--
>>  drivers/phy/phy-core.c  | 27 +--
>>  include/linux/phy/phy.h | 31 +--
>>  3 files changed, 56 insertions(+), 18 deletions(-)
> 
> Hi Kishon,
> 
> I'd like to take this through the Tegra tree along with the remainder of
> the XUSB pad controller and XHCI patches that depend on it. The nice
> thing is that it's fairly unintrusive but gives people an easy way to
> support more flexible bindings by allowing the OF node to be overridden
> when registering the PHY provider.
> 
> Are you okay with the change below? If so, could you provide an
> Acked-by? I can provide a stable branch for you to pull into the PHY
> tree that I'd like to use as a base for the remainder of the series.
> I did a fair amount of compile-testing and upon inspection the API that
> the patch modifies isn't called in many places, everyone uses the
> convenience macros. The stable branch will be helpful in fixing up any
> new users, should any appear during the development cycle.
> 
> Thanks,
> Thierry
> 
>> diff --git a/Documentation/phy.txt b/Documentation/phy.txt
>> index b388c5af9e72..0aa994bd9a91 100644
>> --- a/Documentation/phy.txt
>> +++ b/Documentation/phy.txt
>> @@ -31,16 +31,28 @@ should provide its own implementation of of_xlate. 
>> of_xlate is used only for
>>  dt boot case.
>>  
>>  #define of_phy_provider_register(dev, xlate)\
>> -__of_phy_provider_register((dev), THIS_MODULE, (xlate))
>> +__of_phy_provider_register((dev), NULL, THIS_MODULE, (xlate))
>>  
>>  #define devm_of_phy_provider_register(dev, xlate)   \
>> -__devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))
>> +__devm_of_phy_provider_register((dev), NULL, THIS_MODULE, (xlate))
>>  
>>  of_phy_provider_register and devm_of_phy_provider_register macros can be 
>> used to
>>  register the phy_provider and it takes device and of_xlate as
>>  arguments. For the dt boot case, all PHY providers should use one of the 
>> above
>>  2 macros to register the PHY provider.
>>  
>> +Often the device tree nodes associated with a PHY provider will contain a 
>> set
>> +of children that each represent a single PHY. Some bindings may nest the 
>> child
>> +nodes within extra levels for context and extensibility, in which case the 
>> low
>> +level of_phy_provider_register_full() and 
>> devm_of_phy_provider_register_full()
>> 

[PATCH] usb: dwc3: gadget: give better command return code

[Felipe Balbi]

From: Konrad Leszczynski 

if Start Transfer command fails, let's try a little
harder to figure out why the command failed and give
slightly better return codes. This will be usefulf
or isochronous endpoints, at least, which could
decide to retry a given request.

Signed-off-by: Konrad Leszczynski 
Signed-off-by: Rafal Redzimski 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h   |  4 
 drivers/usb/dwc3/gadget.c | 33 ++---
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index bbbd1789596e..87df6dd20d23 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -970,6 +970,10 @@ struct dwc3_event_depevt {
 #define DEPEVT_STATUS_CONTROL_DATA 1
 #define DEPEVT_STATUS_CONTROL_STATUS   2
 
+/* In response to Start Transfer */
+#define DEPEVT_TRANSFER_NO_RESOURCE1
+#define DEPEVT_TRANSFER_BUS_EXPIRY 2
+
u32 parameters:16;
 } __packed;
 
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6929775bde57..498a79870c8c 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -287,12 +287,39 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
do {
reg = dwc3_readl(dwc->regs, DWC3_DEPCMD(ep));
if (!(reg & DWC3_DEPCMD_CMDACT)) {
+   int cmd_status = DWC3_DEPCMD_STATUS(reg);
+
dwc3_trace(trace_dwc3_gadget,
"Command Complete --> %d",
-   DWC3_DEPCMD_STATUS(reg));
-   if (DWC3_DEPCMD_STATUS(reg))
+   cmd_status);
+
+   switch (cmd_status) {
+   case 0:
+   ret = 0;
+   break;
+   case DEPEVT_TRANSFER_NO_RESOURCE:
+   dwc3_trace(trace_dwc3_gadget, "%s: no resource 
available");
+   ret = -EINVAL;
break;
-   ret = 0;
+   case DEPEVT_TRANSFER_BUS_EXPIRY:
+   /*
+* SW issues START TRANSFER command to
+* isochronous ep with future frame interval. If
+* future interval time has already passed when
+* core receives the command, it will respond
+* with an error status of 'Bus Expiry'.
+*
+* Instead of always returning -EINVAL, let's
+* give a hint to the gadget driver that this is
+* the case by returning -EAGAIN.
+*/
+   dwc3_trace(trace_dwc3_gadget, "%s: bus expiry");
+   ret = -EAGAIN;
+   break;
+   default:
+   dev_WARN(dwc->dev, "UNKNOWN cmd status\n");
+   }
+
break;
}
 
-- 
2.8.1

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

[PATCH v3] usb: core: hub: hub_port_init lock controller instead of bus

[Chris Bainbridge]

The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[8.034843] xhci_hcd :00:14.0: Timeout while waiting for setup device 
command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [] schedule+0x37/0x90
 [] usb_kill_urb+0x8d/0xd0
 [] ? wake_up_atomic_t+0x30/0x30
 [] usb_start_wait_urb+0xbe/0x150
 [] usb_control_msg+0xbc/0xf0
 [] hub_port_init+0x51e/0xb70
 [] hub_event+0x817/0x1570
 [] process_one_work+0x1ff/0x620
 [] ? process_one_work+0x15f/0x620
 [] worker_thread+0x64/0x4b0
 [] ? rescuer_thread+0x390/0x390
 [] kthread+0x105/0x120
 [] ? kthread_create_on_node+0x200/0x200
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [] xhci_setup_device+0x53d/0xa40
 [] xhci_address_device+0xe/0x10
 [] hub_port_init+0x1bf/0xb70
 [] ? trace_hardirqs_on+0xd/0x10
 [] hub_event+0x817/0x1570
 [] process_one_work+0x1ff/0x620
 [] ? process_one_work+0x15f/0x620
 [] worker_thread+0x64/0x4b0
 [] ? rescuer_thread+0x390/0x390
 [] kthread+0x105/0x120
 [] ? kthread_create_on_node+0x200/0x200
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
usb_internal_control_msg
 usb_start_wait_urb
  usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in 
parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge 
---
This is technically the same as the last patch version, but with a reworked
commit message to better explain the cause of the issue.
---
 drivers/usb/core/hcd.c  | 15 +--
 drivers/usb/core/hub.c  |  8 
 include/linux/usb.h |  3 +--
 include/linux/usb/hcd.h |  1 +
 4 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 2ca2cef7f681..980fc5774151 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -994,7 +994,7 @@ static void usb_bus_init (struct usb_bus *bus)
bus->bandwidth_allocated = 0;
bus->bandwidth_int_reqs  = 0;
bus->bandwidth_isoc_reqs = 0;
-   mutex_init(>usb_address0_mutex);
+   mutex_init(>devnum_next_mutex);
 }
 
 /*-*/
@@ -2521,6 +2521,14 @@ struct usb_hcd *usb_create_shared_hcd(const struct 
hc_driver *driver,
return NULL;
}
if (primary_hcd == NULL) {
+   hcd->address0_mutex = kmalloc(sizeof(*hcd->address0_mutex),
+   GFP_KERNEL);
+   if (!hcd->address0_mutex) {
+   kfree(hcd);
+   dev_dbg(dev, "hcd address0 mutex alloc failed\n");
+   return NULL;
+   }
+   mutex_init(hcd->address0_mutex);
hcd->bandwidth_mutex = kmalloc(sizeof(*hcd->bandwidth_mutex),
GFP_KERNEL);
if (!hcd->bandwidth_mutex) {
@@ -2532,6 +2540,7 @@ struct usb_hcd *usb_create_shared_hcd(const struct 
hc_driver *driver,
dev_set_drvdata(dev, hcd);
} else {
mutex_lock(_port_peer_mutex);
+   hcd->address0_mutex = primary_hcd->address0_mutex;
hcd->bandwidth_mutex = primary_hcd->bandwidth_mutex;
hcd->primary_hcd = primary_hcd;
primary_hcd->primary_hcd = primary_hcd;
@@ -2598,8 +2607,10 @@ static void hcd_release(struct kref *kref)
struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref);
 
mutex_lock(_port_peer_mutex);
-   if 

Re: [PATCH] hid: Fix boot delay for Creative SB Omni Surround 5.1 with quirk

[Nazar Mokrynskyi]

On 25.04.16 15:24, Benjamin Tissoires wrote:
> On Apr 25 2016 or thereabouts, Nazar Mokrynskyi wrote:
>> Needed for v2 of the device firmware, otherwise kernel will stuck for few
>> seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
>>
>> Signed-off-by: Nazar Mokrynskyi 
>> ---
> Looks good to me but your mailer might have mangled the lines.
>
> Jiri might be able to apply the patch, but next time, please make sure
> the mailer client does not break lines.
>
> Reviewed-by: Benjamin Tissoires 
>
> Cheers,
> Benjamin
This is the first time doing contribution to kernel, didn't know
Thunderbird will break lines, but looks like I've just configured it
correctly now, so should not happen again.

I can re-send it if absolutely necessary.
>>  drivers/hid/hid-ids.h   | 1 +
>>  drivers/hid/usbhid/hid-quirks.c | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>> index c6eaff5..0238f01 100644
>> --- a/drivers/hid/hid-ids.h
>> +++ b/drivers/hid/hid-ids.h
>> @@ -259,6 +259,7 @@
>>  #define USB_DEVICE_ID_CORSAIR_K900x1b02
>>
>>  #define USB_VENDOR_ID_CREATIVELABS0x041e
>> +#define USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_510x322c
>>  #define USB_DEVICE_ID_PRODIKEYS_PCMIDI0x2801
>>
>>  #define USB_VENDOR_ID_CVTOUCH0x1ff7
>> diff --git a/drivers/hid/usbhid/hid-quirks.c
>> b/drivers/hid/usbhid/hid-quirks.c
>> index ed2f68e..53fc856 100644
>> --- a/drivers/hid/usbhid/hid-quirks.c
>> +++ b/drivers/hid/usbhid/hid-quirks.c
>> @@ -71,6 +71,7 @@ static const struct hid_blacklist {
>>  { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK,
>> HID_QUIRK_NOGET },
>>  { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
>>  { USB_VENDOR_ID_CHICONY,
>> USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
>> +{ USB_VENDOR_ID_CREATIVELABS,
>> USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51, HID_QUIRK_NOGET },
>>  { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
>>  { USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU,
>> HID_QUIRK_MULTI_INPUT },
>>  { USB_VENDOR_ID_ELAN, HID_ANY_ID, HID_QUIRK_ALWAYS_POLL },
>> -- 
>> 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 RESEND 2/5] USB: serial: cp210x: Made sure SERIAL_XOFF_CONTINUE flag is clear.

[Sergei Shtylyov]

Hello.

On 4/24/2016 8:09 PM, Konstantin Shkolnyy wrote:


The CRTCTS flag code intended to clear the SERIAL_XOFF_CONTINUE flag, but


   CRTSCTS? Also, "is" missing before "intended"?


did it inconsistently. This change is non-functional for existing chips
because the driver never set the flag and it's clear by default.


   Sets.


Signed-off-by: Konstantin Shkolnyy 

[...]

MBR, Sergei

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

Re: [PATCH] hid: Fix boot delay for Creative SB Omni Surround 5.1 with quirk

[Benjamin Tissoires]

On Apr 25 2016 or thereabouts, Nazar Mokrynskyi wrote:
> Needed for v2 of the device firmware, otherwise kernel will stuck for few
> seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.
> 
> Signed-off-by: Nazar Mokrynskyi 
> ---

Looks good to me but your mailer might have mangled the lines.

Jiri might be able to apply the patch, but next time, please make sure
the mailer client does not break lines.

Reviewed-by: Benjamin Tissoires 

Cheers,
Benjamin

>  drivers/hid/hid-ids.h   | 1 +
>  drivers/hid/usbhid/hid-quirks.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index c6eaff5..0238f01 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -259,6 +259,7 @@
>  #define USB_DEVICE_ID_CORSAIR_K900x1b02
> 
>  #define USB_VENDOR_ID_CREATIVELABS0x041e
> +#define USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_510x322c
>  #define USB_DEVICE_ID_PRODIKEYS_PCMIDI0x2801
> 
>  #define USB_VENDOR_ID_CVTOUCH0x1ff7
> diff --git a/drivers/hid/usbhid/hid-quirks.c
> b/drivers/hid/usbhid/hid-quirks.c
> index ed2f68e..53fc856 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -71,6 +71,7 @@ static const struct hid_blacklist {
>  { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK,
> HID_QUIRK_NOGET },
>  { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
>  { USB_VENDOR_ID_CHICONY,
> USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
> +{ USB_VENDOR_ID_CREATIVELABS,
> USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51, HID_QUIRK_NOGET },
>  { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
>  { USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU,
> HID_QUIRK_MULTI_INPUT },
>  { USB_VENDOR_ID_ELAN, HID_ANY_ID, HID_QUIRK_ALWAYS_POLL },
> -- 
> 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 RESEND 1/5] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

[Sergei Shtylyov]

Hello.

On 4/24/2016 8:08 PM, Konstantin Shkolnyy wrote:


A bug in the CRTSCT handling caused RTS to alternate between


   CRTSCTS?


CRTSCTS=0 => "RTS transmits active signal" and
CRTSCTS=1 => "RTS receives flow control"
instead of
CRTSCTS=0 => "RTS is statically active" and
CRTSCTS=1 => "RTS receives flow control"

Signed-off-by: Konstantin Shkolnyy 

[...]

MBR, Sergei

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

[PATCH] hid: Fix boot delay for Creative SB Omni Surround 5.1 with quirk

[Nazar Mokrynskyi]

Needed for v2 of the device firmware, otherwise kernel will stuck for few
seconds and throw "usb_submit_urb(ctrl) failed: -1" early on system boot.

Signed-off-by: Nazar Mokrynskyi 
---
 drivers/hid/hid-ids.h   | 1 +
 drivers/hid/usbhid/hid-quirks.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c6eaff5..0238f01 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -259,6 +259,7 @@
 #define USB_DEVICE_ID_CORSAIR_K900x1b02

 #define USB_VENDOR_ID_CREATIVELABS0x041e
+#define USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_510x322c
 #define USB_DEVICE_ID_PRODIKEYS_PCMIDI0x2801

 #define USB_VENDOR_ID_CVTOUCH0x1ff7
diff --git a/drivers/hid/usbhid/hid-quirks.c 
b/drivers/hid/usbhid/hid-quirks.c

index ed2f68e..53fc856 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -71,6 +71,7 @@ static const struct hid_blacklist {
 { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_3AXIS_5BUTTON_STICK, 
HID_QUIRK_NOGET },

 { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
 { USB_VENDOR_ID_CHICONY, 
USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
+{ USB_VENDOR_ID_CREATIVELABS, 
USB_DEVICE_ID_CREATIVE_SB_OMNI_SURROUND_51, HID_QUIRK_NOGET },

 { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
 { USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU, 
HID_QUIRK_MULTI_INPUT },

 { USB_VENDOR_ID_ELAN, HID_ANY_ID, HID_QUIRK_ALWAYS_POLL },
--
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] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

[Felipe Balbi]

Hi,

Jim Lin  writes:
> On 2016年04月22日 19:52, Felipe Balbi wrote:
>> * PGP Signed by an unknown key
>>
>>
>> Hi Jim,
>>
>> Jim Lin  writes:
>>> Android N adds os_desc_compat in v2_descriptor by init_functionfs()
>>> (system/core/adb/usb_linux_client.cpp) to support automatic install
>>> of MTP driver on Windows for USB device mode.
>>>
>>> Current __ffs_data_do_os_desc() of f_fs.c will check reserved1 field
>>> and return -EINVAL.
>>> This results in a second adb_write of usb_linux_client.cpp
>>> (system/core/adb/) which doesn't have ss_descriptors filled.
>>> Then later kernel_panic (composite.c) occurs when ss_descriptors
>>> as a pointer with NULL is being accessed.
>> where exactly in composite.c are we dereferencing a NULL pointer ?
> In set_config
>
> for (; *descriptors; ++descriptors) {
>
>
>
> Here is the link which shows reserved (at offset 1, e.g., Function 
> Section 2) as  1.
> https://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx

thanks

>> Is this happening on set_config() ? If that's the case, why is
>> gadget->speed set to USB_SPEED_SUPER to start with ? Your controller
>> should already have negotiated highspeed which means
>> function_descriptors() should have returned highspeed descriptors, not a
>> NULL superspeed.
>>
>> Care to explain why you haven't negotiated Highspeed ? The only thing I
>> can think of is that you're using a Superspeed-capable peripheral
>> controller (dwc3?) with maximum-speed set to Superspeed, with a
>> Superspeed-capable cable connected to an XHCI PC, but loading a
>> high-speed gadget driver (which you got from Android, written with f_fs)
>> and this gadget doesn't tell composite that its maximum speed is
>> Highspeed, instead of super-speed.
>>
>> We can add a check, sure, to avoid a kernel oops; however, you should
>> really fix up the gadget implementation and/or set dwc3's maximum-speed
>> property accordingly.
>>
>> Can you check if this patch makes your scenario work while still being
>> fully functional ?
>>
>> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
>> index de9ffd60fcfa..3d3cdc5ed20d 100644
>> --- a/drivers/usb/gadget/composite.c
>> +++ b/drivers/usb/gadget/composite.c
>> @@ -66,20 +66,36 @@ function_descriptors(struct usb_function *f,
>>   {
>>  struct usb_descriptor_header **descriptors;
>>   
>> +/*
>> + * NOTE: we try to help gadget drivers which might not be setting
>> + * max_speed appropriately.
>> + */
>> +
>>  switch (speed) {
>>  case USB_SPEED_SUPER_PLUS:
>>  descriptors = f->ssp_descriptors;
>> -break;
>> +if (descriptors)
>> +break;
>> +/* FALLTHROUGH */
>>  case USB_SPEED_SUPER:
>>  descriptors = f->ss_descriptors;
>> -break;
>> +if (descriptors)
>> +break;
>> +/* FALLTHROUGH */
>>  case USB_SPEED_HIGH:
>>  descriptors = f->hs_descriptors;
>> -break;
>> +if (descriptors)
>> +break;
>> +/* FALLTHROUGH */
>>  default:
>>  descriptors = f->fs_descriptors;
>>  }
>>   
>> +/*
>> + * if we can't find any descriptors at all, then this gadget deserves to
>> + * Oops with a NULL pointer dereference
>> + */
>> +
>>  return descriptors;
>>   }
>>   
> After trying your change, no kernel panic, but SuperSpeed device (device 
> mode) is not enumerated by ubuntu 14.04 USB 3.0 host controller as MTP 
> device with USB3.0 cable.

what do you get on dmesg on host side ? Are you running dwc3 ? If you
are, please capture trace logs of the failure:

# mount -t debugfs none /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo 2048 > buffer_size_kb
# echo 1 > events/dwc3/enable

(now connect your cable to host pc)

# cp trace /path/to/non-volatile/storage/trace.txt

Please reply with this trace.txt file and dmesg from host side.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed

[Jim Lin]

On 2016年04月22日 19:52, Felipe Balbi wrote:

* PGP Signed by an unknown key


Hi Jim,

Jim Lin  writes:

Android N adds os_desc_compat in v2_descriptor by init_functionfs()
(system/core/adb/usb_linux_client.cpp) to support automatic install
of MTP driver on Windows for USB device mode.

Current __ffs_data_do_os_desc() of f_fs.c will check reserved1 field
and return -EINVAL.
This results in a second adb_write of usb_linux_client.cpp
(system/core/adb/) which doesn't have ss_descriptors filled.
Then later kernel_panic (composite.c) occurs when ss_descriptors
as a pointer with NULL is being accessed.

where exactly in composite.c are we dereferencing a NULL pointer ?

In set_config

for (; *descriptors; ++descriptors) {



Here is the link which shows reserved (at offset 1, e.g., Function 
Section 2) as  1.

https://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx




Is this happening on set_config() ? If that's the case, why is
gadget->speed set to USB_SPEED_SUPER to start with ? Your controller
should already have negotiated highspeed which means
function_descriptors() should have returned highspeed descriptors, not a
NULL superspeed.

Care to explain why you haven't negotiated Highspeed ? The only thing I
can think of is that you're using a Superspeed-capable peripheral
controller (dwc3?) with maximum-speed set to Superspeed, with a
Superspeed-capable cable connected to an XHCI PC, but loading a
high-speed gadget driver (which you got from Android, written with f_fs)
and this gadget doesn't tell composite that its maximum speed is
Highspeed, instead of super-speed.

We can add a check, sure, to avoid a kernel oops; however, you should
really fix up the gadget implementation and/or set dwc3's maximum-speed
property accordingly.

Can you check if this patch makes your scenario work while still being
fully functional ?

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index de9ffd60fcfa..3d3cdc5ed20d 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -66,20 +66,36 @@ function_descriptors(struct usb_function *f,
  {
struct usb_descriptor_header **descriptors;
  
+	/*

+* NOTE: we try to help gadget drivers which might not be setting
+* max_speed appropriately.
+*/
+
switch (speed) {
case USB_SPEED_SUPER_PLUS:
descriptors = f->ssp_descriptors;
-   break;
+   if (descriptors)
+   break;
+   /* FALLTHROUGH */
case USB_SPEED_SUPER:
descriptors = f->ss_descriptors;
-   break;
+   if (descriptors)
+   break;
+   /* FALLTHROUGH */
case USB_SPEED_HIGH:
descriptors = f->hs_descriptors;
-   break;
+   if (descriptors)
+   break;
+   /* FALLTHROUGH */
default:
descriptors = f->fs_descriptors;
}
  
+	/*

+* if we can't find any descriptors at all, then this gadget deserves to
+* Oops with a NULL pointer dereference
+*/
+
return descriptors;
  }
  
After trying your change, no kernel panic, but SuperSpeed device (device 
mode) is not enumerated by ubuntu 14.04 USB 3.0 host controller as MTP 
device with USB3.0 cable.


--nvpublic
--
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 RFT] usb: chipidea: host: disable io watchdog

[Lucas Stach]

The Chipidea EHCI core seems to behave sanely and doesn't need
the IO watchdog. This kills off 10 non-deferrable wakeup events
per second when the controller is otherwise idle.

Signed-off-by: Lucas Stach 
---
I've only tested this on i.MX6 for now and would like to ask people
on CC to test on their platforms as they also use the chipidea core.
---
 drivers/usb/chipidea/host.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 053bac9d983c..96ae69502c86 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -81,12 +81,15 @@ static int ehci_ci_reset(struct usb_hcd *hcd)
 {
struct device *dev = hcd->self.controller;
struct ci_hdrc *ci = dev_get_drvdata(dev);
+   struct ehci_hcd *ehci = hcd_to_ehci(hcd);
int ret;
 
ret = ehci_setup(hcd);
if (ret)
return ret;
 
+   ehci->need_io_watchdog = 0;
+
ci_platform_configure(ci);
 
return ret;
-- 
2.8.0.rc3

--
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: serial: Use IS_ENABLED() instead of checking for FOO || FOO_MODULE

[Johan Hovold]

On Wed, Apr 20, 2016 at 02:26:58PM -0400, Javier Martinez Canillas wrote:
> The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
> built-in or as a module, use that macro instead of open coding the same.
> 
> Signed-off-by: Javier Martinez Canillas 

Now applied, thanks.

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

Re: [PATCH] USB: ftdi_sio: constify ftdi_sio_quirk structures

[Johan Hovold]

On Sat, Apr 09, 2016 at 01:02:28PM +0200, Julia Lawall wrote:
> The ftdi_sio_quirk structures are never modified, so declare them as const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Now applied, thanks.

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

Re: [PATCH RESEND 4/5] USB: serial: cp210x: Prepared get_termios() for adding error handling

[Johan Hovold]

On Sun, Apr 24, 2016 at 12:09:30PM -0500, Konstantin Shkolnyy wrote:
> Replaced several register write calls with one, to simplify adding error
> handling.
> 
> Signed-off-by: Konstantin Shkolnyy 
> ---
>  drivers/usb/serial/cp210x.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index b2321a7..58cffc9 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -692,6 +692,7 @@ static void cp210x_get_termios_port(struct 
> usb_serial_port *port,

Instead of cleaning up cp210x_get_termios I think you should consider
removing it.

It is used to read the current settings from the device and in case we
have a tty at open, to update the termios settings to match.

Instead you should just make sure that the device settings match
termios (and this is in fact already implemented, but done after
retrieving the settings).

You can also implement the init_termios callback to provide defaults
that match the hardware reset values.

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

Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added comments to CRTSCT flag code.

[Johan Hovold]

On Sun, Apr 24, 2016 at 12:09:21PM -0500, Konstantin Shkolnyy wrote:
> Documented "magic numbers" used in the CRTSCT flag code in terms of
> register bit names from the chip specification.

Documenting these is long overdue. I even started adding defines just to
be able to review the first patch in the series.

> Signed-off-by: Konstantin Shkolnyy 
> ---
>  drivers/usb/serial/cp210x.c | 38 ++
>  1 file changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index ede5c52..b2321a7 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -790,7 +790,7 @@ static void cp210x_get_termios_port(struct 
> usb_serial_port *port,
>  
>   cp210x_read_reg_block(port, CP210X_GET_FLOW, modem_ctl,
>   sizeof(modem_ctl));
> - if (modem_ctl[0] & 0x08) {
> + if (modem_ctl[0] & 0x08) { /* if SERIAL_CTS_HANDSHAKE */

But instead of adding comments like this one and below, please add
proper defines for the various flags and masks. That will make the code
mostly self-explanatory.

>   dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);
>   cflag |= CRTSCTS;
>   } else {
> @@ -952,17 +952,47 @@ static void cp210x_set_termios(struct tty_struct *tty,
>   __func__, modem_ctl[0], modem_ctl[4], modem_ctl[7]);
>  
>   if (cflag & CRTSCTS) {
> - modem_ctl[0] &= ~0x7B;
> + modem_ctl[0] &= ~0x7B; /* keep reserved D2 and D7 */
> + /*
> +  * D1-D0 SERIAL_DTR_MASK =01b: DTR is held active
> +  * D3 SERIAL_CTS_HANDSHAKE   =1: CTS is a handshake line
> +  * D4 SERIAL_DSR_HANDSHAKE   =0
> +  * D5 SERIAL_DCD_HANDSHAKE   =0
> +  * D6 SERIAL_DSR_SENSITIVITY =0
> +  */

> - modem_ctl[7] = 0;
> + modem_ctl[7] = 0; /* SERIAL_XOFF_CONTINUE = 0 */

And this would be better as a bit operation as well (as already
mentioned).

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

Re: [PATCH RESEND 2/5] USB: serial: cp210x: Made sure SERIAL_XOFF_CONTINUE flag is clear.

[Johan Hovold]

On Sun, Apr 24, 2016 at 12:09:10PM -0500, Konstantin Shkolnyy wrote:
> The CRTCTS flag code intended to clear the SERIAL_XOFF_CONTINUE flag, but
> did it inconsistently. This change is non-functional for existing chips
> because the driver never set the flag and it's clear by default.
> 
> Signed-off-by: Konstantin Shkolnyy 
> ---
>  drivers/usb/serial/cp210x.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index de1606f..ede5c52 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -955,7 +955,6 @@ static void cp210x_set_termios(struct tty_struct *tty,
>   modem_ctl[0] &= ~0x7B;
>   modem_ctl[0] |= 0x09;
>   modem_ctl[4] = 0x80;
> - modem_ctl[7] = 0;
>   dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);
>   } else {
>   modem_ctl[0] &= ~0x7B;
> @@ -963,6 +962,7 @@ static void cp210x_set_termios(struct tty_struct *tty,
>   modem_ctl[4] = 0x40;
>   dev_dbg(dev, "%s - flow control = NONE\n", __func__);
>   }
> + modem_ctl[7] = 0;

I'd rather see this done using bit operations and a define (see my
comments on the next patch).

>  
>   dev_dbg(dev, "%s - write modem controls = %02x .. .. .. %02x .. 
> .. %02x\n",
>   __func__, modem_ctl[0], modem_ctl[4], modem_ctl[7]);

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

Re: [PATCH RESEND 1/5] USB: serial: cp210x: Fixed RTS mode setting by the CRTSCTS flag.

[Johan Hovold]

On Sun, Apr 24, 2016 at 12:08:55PM -0500, Konstantin Shkolnyy wrote:
> A bug in the CRTSCT handling caused RTS to alternate between
> CRTSCTS=0 => "RTS transmits active signal" and
> CRTSCTS=1 => "RTS receives flow control"
> instead of
> CRTSCTS=0 => "RTS is statically active" and
> CRTSCTS=1 => "RTS receives flow control"

Perhaps you should mention that this only happens after first having
enabled CRTSCTS.

> Signed-off-by: Konstantin Shkolnyy 
> ---
>  drivers/usb/serial/cp210x.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index c740592..de1606f 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -955,16 +955,12 @@ static void cp210x_set_termios(struct tty_struct *tty,
>   modem_ctl[0] &= ~0x7B;
>   modem_ctl[0] |= 0x09;
>   modem_ctl[4] = 0x80;
> - /* FIXME - why clear reserved bits just read? */
> - modem_ctl[5] = 0;
> - modem_ctl[6] = 0;

This is an unrelated chunk. Perhaps include it when addressing the
XOFF_CONTINUE bit.

>   modem_ctl[7] = 0;
>   dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);
>   } else {
>   modem_ctl[0] &= ~0x7B;
>   modem_ctl[0] |= 0x01;
> - /* FIXME - OR here instead of assignment looks wrong */
> - modem_ctl[4] |= 0x40;
> + modem_ctl[4] = 0x40;
>   dev_dbg(dev, "%s - flow control = NONE\n", __func__);
>   }

Ideally modifying the RTS mask should not clear unrelated flags as break
char insertion. But as we don't use these currently so this would be
fine as a fix for now.

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

RE: [PATCH 5/5] doc: usb: ci-hdrc-usb2: add property usb-charger-detection

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, April 25, 2016 2:23 PM
> To: Jun Li 
> Cc: Peter Chen ; linux-usb@vger.kernel.org;
> baolin.w...@linaro.org
> Subject: Re: [PATCH 5/5] doc: usb: ci-hdrc-usb2: add property usb-charger-
> detection
> 
> On Mon, Apr 18, 2016 at 04:17:49PM +0800, Li Jun wrote:
> > Set this property if your usb module has usb charger detect function
> > and you want to use it.
> >
> > Signed-off-by: Li Jun 
> > ---
> >  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > index 1084e2b..52d269e 100644
> > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> > @@ -76,6 +76,8 @@ Optional properties:
> >needs to make sure it does not send more than 90%
> >maximum_periodic_data_per_frame. The use case is multiple
> transactions, but
> >less frame rate.
> > +- usb-charger-detection: use usb charger detect function provided by
> > +usb
> > +  module; if your usb charger type detection done by PMIC, don't enable
> this.
> >
> 
> If the user doesn't set it at dts, and detection is done by PMIC, would
> you show us the flow how it work at chipidea driver?

This patch set only focus on charger type detection by usb module, so
PMIC case may not benefit from it.

1. If user is sure the charger detection process can't impact the usb
   gadget enumeration, e.g. charger detection is automatically done
   before vbus is detected(like Baolin's case), nothing needs added
   at chipidea driver. Otherwise
2. We need a simple sync, wait the PMIC driver gets charger type before
   do gadget connect, this can be done in udc.c via power_supply_get_property()
   like what Baolin does in usb_charger_get_type_by_others() in charger.c.

I intend to add the handling of case 2 by the real user of it.

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

ftdi_sio: usb_serial_generic_read_bulk_callback - urb stopped: -32

[Beralt Meppelink]

Hello,

I'm experiencing some issues with a FTDI serial-to-usb chip, which
becomes unresponsive (the endpoint is halted) while logging this
message:

ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped:
-32

Some searching [1] [2] revealed that I'm not the only one. Most people
report this occurring on a Raspberry Pi, however in my case it's a Intel
NUC. There seems to be some relationship between bus speed and/or
data-rate, but I have not been able to confirm this myself.

This issue has been bugging me for almost a year now, and keeps
occurring even on kernels as recent as 4.5.1. My current workaround
(using libusb) does the following to get the device in working order
again:

1 - detach kernel driver
2 - claim interface
3 - call libusb_clear_halt()
4 - call libusb_reset_device()
5 - attach kernel driver

This gets the device up and running again. Given the error code above
this might not be an appropriate solution, but this does solve the
problem (without walking to the machine and re-plugging the device). Any
thoughts on how to solve this issue more permanently? I have no idea of
the actual cause.

[1] https://github.com/raspberrypi/linux/issues/1187
[2] http://comments.gmane.org/gmane.linux.usb.general/111217
--
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/5] usb: chipidea: add usb charger detection support

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, April 25, 2016 2:15 PM
> To: Jun Li 
> Cc: Peter Chen ; linux-usb@vger.kernel.org;
> baolin.w...@linaro.org
> Subject: Re: [PATCH 1/5] usb: chipidea: add usb charger detection support
> 
> On Mon, Apr 18, 2016 at 04:17:45PM +0800, Li Jun wrote:
> > Some usb module implementations has functionality of detect usb
> > charger type, it can be used by usb charger framework to report max
> > current drawn from charger in different situations.
> >
> > Signed-off-by: Li Jun 
> > ---
> >  drivers/usb/chipidea/udc.c   | 40
> 
> >  include/linux/usb/chipidea.h |  4 
> >  2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 065f5d9..4d2187e 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1510,6 +1510,37 @@ static const struct usb_ep_ops usb_ep_ops = {
> >
> /*
> *
> >   * GADGET block
> >
> > **
> > ***/
> > +static enum usb_charger_type ci_usb_charger_det(struct usb_charger
> > +*charger) {
> > +   struct ci_hdrc *ci;
> > +   enum usb_charger_type ret = UNKNOWN_TYPE;
> > +
> > +   if (!charger || !charger->gadget)
> > +   return ret;
> > +
> > +   ci = container_of(charger->gadget, struct ci_hdrc, gadget);
> > +   if (ci->vbus_active) {
> > +   if (ci->platdata->usb_charger_det) {
> > +   ret = ci->platdata->usb_charger_det(ci);
> > +   if (ret != UNKNOWN_TYPE)
> > +   return ret;
> > +   }
> > +
> > +   if (ci->platdata->pull_dp_for_charger) {
> > +   hw_device_reset(ci);
> > +   hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > +   }
> > +
> > +   if (ci->platdata->usb_charger_secondary_det)
> > +   ret = ci->platdata->usb_charger_secondary_det(ci);
> > +
> > +   if (ci->platdata->pull_dp_for_charger)
> > +   hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static int ci_udc_vbus_session(struct usb_gadget *_gadget, int
> > is_active)  {
> > struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
> > @@ -1522,6 +1553,9 @@ static int ci_udc_vbus_session(struct usb_gadget
> *_gadget, int is_active)
> > gadget_ready = 1;
> > spin_unlock_irqrestore(>lock, flags);
> >
> > +   if (_gadget->charger && is_active)
> 
> if (_gadget->charger && _gadget->charger->charger_detect && is_active)
> 
> Otherwise there will be a warning message if the user does not define
> ->charger_detect API.

Make sense, I will change this in v2.

> 
> 
> > +   usb_charger_detect_type(_gadget->charger);
> > +
> > if (gadget_ready) {
> > if (is_active) {
> > pm_runtime_get_sync(&_gadget->dev);
> > @@ -1922,6 +1956,9 @@ static int udc_start(struct ci_hdrc *ci)
> > if (retval)
> > goto destroy_eps;
> >
> > +   if (ci->gadget.charger && ci->platdata->usb_charger_det)
> > +   ci->gadget.charger->charger_detect = ci_usb_charger_det;
> > +
> > pm_runtime_no_callbacks(>gadget.dev);
> > pm_runtime_enable(>gadget.dev);
> >
> > @@ -1946,6 +1983,9 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
> > if (!ci->roles[CI_ROLE_GADGET])
> > return;
> >
> > +   if (ci->gadget.charger)
> > +   ci->gadget.charger->charger_detect = NULL;
> > +
> > usb_del_gadget_udc(>gadget);
> >
> > destroy_eps(ci);
> > diff --git a/include/linux/usb/chipidea.h
> > b/include/linux/usb/chipidea.h index 5dd75fa..7fc781d 100644
> > --- a/include/linux/usb/chipidea.h
> > +++ b/include/linux/usb/chipidea.h
> > @@ -55,10 +55,14 @@ struct ci_hdrc_platform_data {
> >  #define CI_HDRC_OVERRIDE_AHB_BURST BIT(9)
> >  #define CI_HDRC_OVERRIDE_TX_BURST  BIT(10)
> >  #define CI_HDRC_OVERRIDE_RX_BURST  BIT(11)
> > +#define CI_HDRC_PULL_DP_FOR_CHARGERBIT(12)
> > enum usb_dr_modedr_mode;
> >  #define CI_HDRC_CONTROLLER_RESET_EVENT 0
> >  #define CI_HDRC_CONTROLLER_STOPPED_EVENT   1
> > void(*notify_event) (struct ci_hdrc *ci, unsigned event);
> > +   enum usb_charger_type (*usb_charger_det)(struct ci_hdrc *ci);
> > +   boolpull_dp_for_charger;
> > +   enum usb_charger_type (*usb_charger_secondary_det)(struct ci_hdrc
> > +*ci);
> 
> Please don't use shortening for "detect", the same for "secondary"
> in your patch 4.

Okay.

> 
> > struct regulator*reg_vbus;
> > struct usb_otg_caps ci_otg_caps;
> > booltpl_support;
> > --
> > 1.9.1
> >
> 
> --
> 
> Best Regards,
> Peter Chen
--
To unsubscribe from this list: send 

RE: [PATCH 4/5] usb: chipidea: imx: add usb charger detection for imx7d

[Jun Li]

Hi,

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, April 25, 2016 2:03 PM
> To: Jun Li 
> Cc: Peter Chen ; linux-usb@vger.kernel.org;
> baolin.w...@linaro.org
> Subject: Re: [PATCH 4/5] usb: chipidea: imx: add usb charger detection for
> imx7d
> 
> On Mon, Apr 18, 2016 at 04:17:48PM +0800, Li Jun wrote:
> > Adds imx7d usb charger detection implementation, which needs pull up
> > DP line before do secondary detection and pull down DP afterwards.
> >
> 
> You can merge patch 3 and patch 4 as one patch.

Okay.

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

RE: [PATCH v2] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven
> Sent: Monday, April 25, 2016 3:58 PM
> 
> Hi Shimoda-san,
> 
> On Mon, Apr 25, 2016 at 4:10 AM, Yoshihiro Shimoda
>  wrote:
> >> From: Rob Herring
> >> Sent: Friday, April 22, 2016 10:29 PM
> >> On Fri, Apr 22, 2016 at 4:36 AM, Felipe Balbi
> >>  wrote:
> >> > Yoshihiro Shimoda  writes:
> >> >> The firmware of R-Car USB 3.0 host controller will control the reset.
> >> >> So, if the xhci driver doesn't do firmware downloading (e.g. kernel
> >> >> configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR
> >> >> is not set), the reset of USB 3.0 host controller doesn't work
> >> >> correctly. Then, the host controller will cause long wait in
> >> >> xhci_reset() because the CMD_RESET bit of op_regs->command is not
> >> >> cleared for 10 seconds.
> >> >>
> >> >> So, this patch modifies the xhci_rcar_init_quirk() in xhci-rcar.h
> >> >> to exit the probe function immediately.
> >> >>
> >> >> Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 
> >> >> and M2 xHCI controllers)
> >> >> Cc:  # v3.17+
> >> >> Signed-off-by: Yoshihiro Shimoda 
> >> >> ---
> >> >>  Changes from v1:
> >> >>   - Revise the commit log.
> >> >> (http://www.spinics.net/lists/stable/msg130007.html)
> >> >>
> >> >>  drivers/usb/host/xhci-rcar.h | 6 +-
> >> >>  1 file changed, 5 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/usb/host/xhci-rcar.h b/drivers/usb/host/xhci-rcar.h
> >> >> index 2941a25..2afed68 100644
> >> >> --- a/drivers/usb/host/xhci-rcar.h
> >> >> +++ b/drivers/usb/host/xhci-rcar.h
> >> >> @@ -24,7 +24,11 @@ static inline void xhci_rcar_start(struct usb_hcd 
> >> >> *hcd)
> >> >>
> >> >>  static inline int xhci_rcar_init_quirk(struct usb_hcd *hcd)
> >> >>  {
> >> >> - return 0;
> >> >> + /*
> >> >> +  * To avoid wait and timeout in xhci_reset() if CONFIG_XHCI_RCAR 
> >> >> is
> >> >> +  * disabled, this function fails.
> >> >> +  */
> >> >> + return -ENODEV;
> >> >
> >> > okay, if I understood correctly the thing is that you have a kernel
> >> > built with XHCI platform support but without XHCI RCAR support. Then, if
> >> > you run this kernel on RCAR board, you see this CMD_RESET problem,
> >> > right?
> 
> [...]
> 
> >> We should fix this in kconfig to always enable the option when RCAR is
> >> enabled IMO.
> >
> > I could fix this in kconfig like the followings:
> >
> > diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> > index f2bc5c3..905d1d2 100644
> > --- a/arch/arm/mach-shmobile/Kconfig
> > +++ b/arch/arm/mach-shmobile/Kconfig
> > @@ -46,6 +46,7 @@ menuconfig ARCH_RENESAS
> > select PINCTRL
> > select ARCH_REQUIRE_GPIOLIB
> > select ZONE_DMA if ARM_LPAE
> > +   select USB_XHCI_RCAR if USB_XHCI_HCD
> >
> >  if ARCH_RENESAS
> >
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index efa77c1..010d2b7 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -105,6 +105,7 @@ config ARCH_RENESAS
> > select PM
> > select PM_GENERIC_DOMAINS
> > select RENESAS_IRQC
> > +   select USB_XHCI_RCAR if USB_XHCI_HCD
> > help
> >   This enables support for the ARMv8 based Renesas SoCs.
> >
> > If this is acceptable, I will send each patch to arm / arm64.
> 
> What about enforcing this in a single place instead, i.e. in
> drivers/usb/host/Kconfig?

Thank you for the suggestion. I could make such a patch.
I prefer this than each arm / arm64 patch.

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3050b18..e9d4dde 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -35,6 +35,7 @@ config USB_XHCI_PCI
 
 config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device"
+   select USB_XHCI_RCAR if ARCH_RENESAS
---help---
  Adds an xHCI host driver for a generic platform device, which
  provides a memory space and an irq.
@@ -63,7 +64,7 @@ config USB_XHCI_MVEBU
 
 config USB_XHCI_RCAR
tristate "xHCI support for Renesas R-Car SoCs"
-   select USB_XHCI_PLATFORM
+   depends on USB_XHCI_PLATFORM
depends on ARCH_RENESAS || COMPILE_TEST
---help---
  Say 'Y' to enable the support for the xHCI host controller

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

[PATCH v6 01/10] extcon: usb-gpio: add device binding for platform device

[Lu Baolu]

This is needed to handle the GPIO connected USB ID pin found on
Intel Baytrail devices.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
Acked-by: Chanwoo Choi 
---
 drivers/extcon/extcon-usb-gpio.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index 2b2fecf..af9c8b0 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -206,6 +206,12 @@ static const struct of_device_id usb_extcon_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, usb_extcon_dt_match);
 
+static const struct platform_device_id usb_extcon_platform_ids[] = {
+   { .name = "extcon-usb-gpio", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, usb_extcon_platform_ids);
+
 static struct platform_driver usb_extcon_driver = {
.probe  = usb_extcon_probe,
.remove = usb_extcon_remove,
@@ -214,6 +220,7 @@ static struct platform_driver usb_extcon_driver = {
.pm = _extcon_pm_ops,
.of_match_table = usb_extcon_dt_match,
},
+   .id_table = usb_extcon_platform_ids,
 };
 
 module_platform_driver(usb_extcon_driver);
-- 
2.1.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 v6 02/10] extcon: usb-gpio: add support for ACPI gpio interface

[Lu Baolu]

GPIO resource could be retrieved through APCI as well.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
Acked-by: Chanwoo Choi 
---
 drivers/extcon/extcon-usb-gpio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index af9c8b0..472c431 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define USB_GPIO_DEBOUNCE_MS   20  /* ms */
 
@@ -91,7 +92,7 @@ static int usb_extcon_probe(struct platform_device *pdev)
struct usb_extcon_info *info;
int ret;
 
-   if (!np)
+   if (!np && !ACPI_HANDLE(dev))
return -EINVAL;
 
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
-- 
2.1.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 v6 03/10] regulator: fixed: add device binding for platform device

[Lu Baolu]

This is needed to handle the GPIO connected USB vcc pin found on
Intel Baytrail devices.

Signed-off-by: Lu Baolu 
---
 drivers/regulator/fixed.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index ff62d69..e6f376f 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -209,12 +209,19 @@ static const struct of_device_id fixed_of_match[] = {
 MODULE_DEVICE_TABLE(of, fixed_of_match);
 #endif
 
+static const struct platform_device_id fixed_platform_ids[] = {
+   { .name = "reg-fixed-voltage", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, fixed_platform_ids);
+
 static struct platform_driver regulator_fixed_voltage_driver = {
.probe  = reg_fixed_voltage_probe,
.driver = {
.name   = "reg-fixed-voltage",
.of_match_table = of_match_ptr(fixed_of_match),
},
+   .id_table = fixed_platform_ids,
 };
 
 static int __init regulator_fixed_voltage_init(void)
-- 
2.1.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 v6 05/10] usb: mux: add generic code for dual role port mux

[Lu Baolu]

Several Intel platforms implement USB dual role by having completely
separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share
a single USB port. There is another external port mux which controls
where the data lines should go. While the USB controllers are part of
the silicon, the port mux design are platform specific.

This patch adds the generic code to handle such usb port mux. It listens
to the USB HOST extcon cable, and switch the port by calling the port
switch ops provided by the individual port mux driver. It also registers
the mux device with sysfs, so that users can control the port mux from
user space.

Some other archs (e.g. Renesas R-Car gen2 SoCs) need an external mux to
swap usb roles as well. This code could be leveraged for those archs
as well.

Signed-off-by: Lu Baolu 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Felipe Balbi 
Reviewed-by: Chanwoo Choi 
[baolu: extcon usage reviewed by Chanwoo Choi]
---
 Documentation/ABI/testing/sysfs-bus-platform |  17 +++
 drivers/usb/Kconfig  |   2 +
 drivers/usb/Makefile |   1 +
 drivers/usb/mux/Kconfig  |  11 ++
 drivers/usb/mux/Makefile |   4 +
 drivers/usb/mux/portmux-core.c   | 217 +++
 include/linux/usb/portmux.h  |  78 ++
 7 files changed, 330 insertions(+)
 create mode 100644 drivers/usb/mux/Kconfig
 create mode 100644 drivers/usb/mux/Makefile
 create mode 100644 drivers/usb/mux/portmux-core.c
 create mode 100644 include/linux/usb/portmux.h

diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
b/Documentation/ABI/testing/sysfs-bus-platform
index 5172a61..f33f0a5 100644
--- a/Documentation/ABI/testing/sysfs-bus-platform
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -18,3 +18,20 @@ Description:
devices to opt-out of driver binding using a driver_override
name such as "none".  Only a single driver may be specified in
the override, there is no support for parsing delimiters.
+
+What:  /sys/bus/platform/devices/.../portmux.N/name
+   /sys/bus/platform/devices/.../portmux.N/state
+Date:  April 2016
+Contact:   Lu Baolu 
+Description:
+   In some platforms, a single USB port is shared between a USB 
host
+   controller and a device controller. A USB mux driver is needed 
to
+   handle the port mux. Read-only attribute "name" shows the name 
of
+   the port mux device. "state" attribute shows and stores the mux
+   state.
+   For read:
+   'peripheral' - mux switched to PERIPHERAL controller;
+   'host'   - mux switched to HOST controller.
+   For write:
+   'peripheral' - mux will be switched to PERIPHERAL controller;
+   'host'   - mux will be switched to HOST controller.
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8ed451d..dbd6620 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -149,6 +149,8 @@ endif # USB
 
 source "drivers/usb/phy/Kconfig"
 
+source "drivers/usb/mux/Kconfig"
+
 source "drivers/usb/gadget/Kconfig"
 
 config USB_LED_TRIG
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..9a92338 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -6,6 +6,7 @@
 
 obj-$(CONFIG_USB)  += core/
 obj-$(CONFIG_USB_SUPPORT)  += phy/
+obj-$(CONFIG_USB_SUPPORT)  += mux/
 
 obj-$(CONFIG_USB_DWC3) += dwc3/
 obj-$(CONFIG_USB_DWC2) += dwc2/
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
new file mode 100644
index 000..d91909f
--- /dev/null
+++ b/drivers/usb/mux/Kconfig
@@ -0,0 +1,11 @@
+#
+# USB port mux driver configuration
+#
+
+menu "USB Port MUX drivers"
+config USB_PORTMUX
+   select EXTCON
+   def_bool n
+   help
+ Generic USB dual role port mux support.
+endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
new file mode 100644
index 000..f85df92
--- /dev/null
+++ b/drivers/usb/mux/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for USB port mux drivers
+#
+obj-$(CONFIG_USB_PORTMUX)  += portmux-core.o
diff --git a/drivers/usb/mux/portmux-core.c b/drivers/usb/mux/portmux-core.c
new file mode 100644
index 000..0e3548b
--- /dev/null
+++ b/drivers/usb/mux/portmux-core.c
@@ -0,0 +1,217 @@
+/**
+ * intel_mux.c - USB Port Mux support
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+

[PATCH v6 04/10] regulator: fixed: add support for ACPI interface

[Lu Baolu]

Add support to retrieve fixed voltage configure information through
ACPI interface. This is needed for Intel Bay Trail devices, where a
GPIO is used to control the USB vbus.

Signed-off-by: Lu Baolu 
---
 drivers/regulator/fixed.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index e6f376f..4d0cc84 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 struct fixed_voltage_data {
struct regulator_desc desc;
@@ -104,6 +107,46 @@ of_get_fixed_voltage_config(struct device *dev,
return config;
 }
 
+/**
+ * acpi_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ * @desc: regulator description
+ *
+ * Populates fixed_voltage_config structure by extracting data through ACPI
+ * interface, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+static struct fixed_voltage_config *
+acpi_get_fixed_voltage_config(struct device *dev,
+ const struct regulator_desc *desc)
+{
+   struct fixed_voltage_config *config;
+   const char *supply_name, *gpio_name;
+   struct gpio_desc *gpiod;
+   int ret;
+
+   config = devm_kzalloc(dev, sizeof(*config), GFP_KERNEL);
+   if (!config)
+   return ERR_PTR(-ENOMEM);
+
+   ret = device_property_read_string(dev, "supply-name", _name);
+   if (!ret)
+   config->supply_name = supply_name;
+
+   ret = device_property_read_string(dev, "gpio-name", _name);
+   if (!ret) {
+   gpiod = gpiod_get(dev, gpio_name, GPIOD_ASIS);
+   if (!IS_ERR(gpiod)) {
+   config->gpio = desc_to_gpio(gpiod);
+   config->enable_high = device_property_read_bool(dev,
+   "enable-active-high");
+   gpiod_put(gpiod);
+   }
+   }
+
+   return config;
+}
+
 static struct regulator_ops fixed_voltage_ops = {
 };
 
@@ -124,6 +167,11 @@ static int reg_fixed_voltage_probe(struct platform_device 
*pdev)
 >desc);
if (IS_ERR(config))
return PTR_ERR(config);
+   } else if (ACPI_HANDLE(>dev)) {
+   config = acpi_get_fixed_voltage_config(>dev,
+  >desc);
+   if (IS_ERR(config))
+   return PTR_ERR(config);
} else {
config = dev_get_platdata(>dev);
}
-- 
2.1.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 v6 06/10] usb: mux: add driver for Intel gpio controlled port mux

[Lu Baolu]

In some Intel platforms, a single usb port is shared between USB host
and device controller. The shared port is under control of GPIO pins.

This patch adds the support for USB GPIO controlled port mux.

[baolu: removed .owner per platform_no_drv_owner.cocci]
Signed-off-by: David Cohen 
Signed-off-by: Lu Baolu 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Felipe Balbi 
---
 drivers/usb/mux/Kconfig  |  11 +++
 drivers/usb/mux/Makefile |   1 +
 drivers/usb/mux/portmux-intel-gpio.c | 149 +++
 3 files changed, 161 insertions(+)
 create mode 100644 drivers/usb/mux/portmux-intel-gpio.c

diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
index d91909f..1dc1f33 100644
--- a/drivers/usb/mux/Kconfig
+++ b/drivers/usb/mux/Kconfig
@@ -8,4 +8,15 @@ config USB_PORTMUX
def_bool n
help
  Generic USB dual role port mux support.
+
+config INTEL_MUX_GPIO
+   tristate "Intel dual role port mux controlled by GPIOs"
+   depends on GPIOLIB
+   depends on REGULATOR
+   depends on X86 && ACPI
+   select USB_PORTMUX
+   help
+ Say Y here to enable support for Intel dual role port mux
+ controlled by GPIOs.
+
 endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
index f85df92..4eb5582 100644
--- a/drivers/usb/mux/Makefile
+++ b/drivers/usb/mux/Makefile
@@ -2,3 +2,4 @@
 # Makefile for USB port mux drivers
 #
 obj-$(CONFIG_USB_PORTMUX)  += portmux-core.o
+obj-$(CONFIG_INTEL_MUX_GPIO)   += portmux-intel-gpio.o
diff --git a/drivers/usb/mux/portmux-intel-gpio.c 
b/drivers/usb/mux/portmux-intel-gpio.c
new file mode 100644
index 000..b07ae2c
--- /dev/null
+++ b/drivers/usb/mux/portmux-intel-gpio.c
@@ -0,0 +1,149 @@
+/*
+ * USB Dual Role Port Mux driver controlled by gpios
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ * Author: David Cohen 
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct vuport {
+   struct portmux_desc desc;
+   struct portmux_dev *pdev;
+   struct regulator *regulator;
+   struct gpio_desc *gpio_usb_mux;
+};
+
+/*
+ * id == 0, HOST connected, USB port should be set to peripheral
+ * id == 1, HOST disconnected, USB port should be set to host
+ *
+ * Peripheral: set USB mux to peripheral and disable VBUS
+ * Host: set USB mux to host and enable VBUS
+ */
+static inline int vuport_set_port(struct device *dev, int id)
+{
+   struct vuport *vup;
+
+   dev_dbg(dev, "USB PORT ID: %s\n", id ? "HOST" : "PERIPHERAL");
+
+   vup = dev_get_drvdata(dev);
+
+   gpiod_set_value_cansleep(vup->gpio_usb_mux, !id);
+
+   if (!id ^ regulator_is_enabled(vup->regulator))
+   return id ? regulator_disable(vup->regulator) :
+   regulator_enable(vup->regulator);
+
+   return 0;
+}
+
+static int vuport_cable_set(struct device *dev)
+{
+   return vuport_set_port(dev, 1);
+}
+
+static int vuport_cable_unset(struct device *dev)
+{
+   return vuport_set_port(dev, 0);
+}
+
+static const struct portmux_ops vuport_ops = {
+   .cable_set_cb = vuport_cable_set,
+   .cable_unset_cb = vuport_cable_unset,
+};
+
+static int vuport_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct vuport *vup;
+
+   vup = devm_kzalloc(dev, sizeof(*vup), GFP_KERNEL);
+   if (!vup)
+   return -ENOMEM;
+
+   vup->regulator = devm_regulator_get_exclusive(dev,
+ "regulator-usb-gpio");
+   if (IS_ERR(vup->regulator))
+   return -EPROBE_DEFER;
+
+   vup->gpio_usb_mux = devm_gpiod_get_optional(dev,
+   "usb_mux", GPIOD_ASIS);
+   if (IS_ERR(vup->gpio_usb_mux))
+   return PTR_ERR(vup->gpio_usb_mux);
+
+   vup->desc.dev = dev;
+   vup->desc.name = "intel-mux-gpio";
+   vup->desc.extcon_name = "extcon-usb-gpio";
+   vup->desc.ops = _ops;
+   vup->desc.initial_state = -1;
+   dev_set_drvdata(dev, vup);
+   vup->pdev = portmux_register(>desc);
+
+   return PTR_ERR_OR_ZERO(vup->pdev);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+   struct vuport *vup;
+
+   vup = platform_get_drvdata(pdev);
+   portmux_unregister(vup->pdev);
+
+   return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+/*
+ * In case a micro A cable was plugged in while device was sleeping,
+ * we missed the interrupt. We need to poll usb id gpio when waking the
+ * driver to detect the missed event.
+ * We use 'complete' callback 

[PATCH v6 07/10] usb: mux: add driver for Intel drcfg controlled port mux

[Lu Baolu]

Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Lu Baolu 
Signed-off-by: Wu Hao 
Reviewed-by: Felipe Balbi 
---
 drivers/usb/mux/Kconfig   |   8 ++
 drivers/usb/mux/Makefile  |   1 +
 drivers/usb/mux/portmux-intel-drcfg.c | 171 ++
 3 files changed, 180 insertions(+)
 create mode 100644 drivers/usb/mux/portmux-intel-drcfg.c

diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
index 1dc1f33..ae3f746 100644
--- a/drivers/usb/mux/Kconfig
+++ b/drivers/usb/mux/Kconfig
@@ -19,4 +19,12 @@ config INTEL_MUX_GPIO
  Say Y here to enable support for Intel dual role port mux
  controlled by GPIOs.
 
+config INTEL_MUX_DRCFG
+   tristate "Intel dual role port mux controlled by register"
+   depends on X86
+   select USB_PORTMUX
+   help
+ Say Y here to enable support for Intel dual role port mux
+ controlled by the Dual Role Configuration Register.
+
 endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
index 4eb5582..0f102b5 100644
--- a/drivers/usb/mux/Makefile
+++ b/drivers/usb/mux/Makefile
@@ -3,3 +3,4 @@
 #
 obj-$(CONFIG_USB_PORTMUX)  += portmux-core.o
 obj-$(CONFIG_INTEL_MUX_GPIO)   += portmux-intel-gpio.o
+obj-$(CONFIG_INTEL_MUX_DRCFG)  += portmux-intel-drcfg.o
diff --git a/drivers/usb/mux/portmux-intel-drcfg.c 
b/drivers/usb/mux/portmux-intel-drcfg.c
new file mode 100644
index 000..0bb6b08
--- /dev/null
+++ b/drivers/usb/mux/portmux-intel-drcfg.c
@@ -0,0 +1,171 @@
+/**
+ * intel-mux-drcfg.c - Driver for Intel USB mux via register
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus 
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INTEL_MUX_CFG0 0x00
+#define INTEL_MUX_CFG1 0x04
+#define CFG0_SW_IDPIN  BIT(20)
+#define CFG0_SW_IDPIN_EN   BIT(21)
+#define CFG0_SW_VBUS_VALID BIT(24)
+#define CFG1_MODE  BIT(29)
+
+struct intel_mux_drcfg {
+   struct portmux_desc desc;
+   struct device *dev;
+   void __iomem *regs;
+   struct portmux_dev *pdev;
+};
+
+static inline int intel_mux_drcfg_switch(struct device *dev, bool host)
+{
+   u32 data;
+   struct intel_mux_drcfg *mux;
+
+   mux = dev_get_drvdata(dev);
+
+   /* Check and set mux to SW controlled mode */
+   data = readl(mux->regs + INTEL_MUX_CFG0);
+   if (!(data & CFG0_SW_IDPIN_EN)) {
+   data |= CFG0_SW_IDPIN_EN;
+   writel(data, mux->regs + INTEL_MUX_CFG0);
+   }
+
+   /*
+* Configure CFG0 to switch the mux and VBUS_VALID bit is
+* required for device mode.
+*/
+   data = readl(mux->regs + INTEL_MUX_CFG0);
+   if (host)
+   data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+   else
+   data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+   writel(data, mux->regs + INTEL_MUX_CFG0);
+
+   return 0;
+}
+
+static int intel_mux_drcfg_cable_set(struct device *dev)
+{
+   dev_dbg(dev, "drcfg mux switch to HOST\n");
+
+   return intel_mux_drcfg_switch(dev, true);
+}
+
+static int intel_mux_drcfg_cable_unset(struct device *dev)
+{
+   dev_dbg(dev, "drcfg mux switch to DEVICE\n");
+
+   return intel_mux_drcfg_switch(dev, false);
+}
+
+static const struct portmux_ops drcfg_ops = {
+   .cable_set_cb = intel_mux_drcfg_cable_set,
+   .cable_unset_cb = intel_mux_drcfg_cable_unset,
+};
+
+static int intel_mux_drcfg_probe(struct platform_device *pdev)
+{
+   struct intel_mux_drcfg *mux;
+   struct device *dev = >dev;
+   const char *extcon_name = NULL;
+   u64 start, size;
+   int ret;
+
+   mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
+   if (!mux)
+   return -ENOMEM;
+
+   ret = device_property_read_u64(dev, "reg-start", );
+   ret |= device_property_read_u64(dev, "reg-size", );
+   if (ret)
+   return -ENODEV;
+
+   ret = device_property_read_string(dev, "extcon-name", _name);
+   if (!ret)
+   mux->desc.extcon_name = extcon_name;
+
+   mux->regs = devm_ioremap_nocache(dev, start, size);
+   if (!mux->regs)
+   return -ENOMEM;
+
+   mux->desc.dev = dev;
+   mux->desc.name = "intel-mux-drcfg";
+   mux->desc.ops = _ops;
+   mux->desc.initial_state =
+   

[PATCH v6 10/10] MAINTAINERS: add maintainer entry for Intel USB dual role mux drivers

[Lu Baolu]

Add a maintainer entry for Intel USB dual role mux drivers and
add myself as a maintainer.

Signed-off-by: Lu Baolu 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 03e00c7..e2609e6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5878,6 +5878,16 @@ S:   Maintained
 F: arch/x86/include/asm/intel_telemetry.h
 F: drivers/platform/x86/intel_telemetry*
 
+INTEL USB DUAL ROLE PORT MUX DRIVERS
+M: Lu Baolu 
+L: linux-usb@vger.kernel.org
+S: Supported
+F: include/linux/usb/intel-mux.h
+F: drivers/usb/mux/intel-mux.c
+F: drivers/usb/mux/intel-mux-gpio.c
+F: drivers/usb/mux/intel-mux-drcfg.c
+F: drivers/mfd/intel-vuport.c
+
 IOC3 ETHERNET DRIVER
 M: Ralf Baechle 
 L: linux-m...@linux-mips.org
-- 
2.1.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 v6 09/10] usb: pci-quirks: add Intel USB drcfg mux device

[Lu Baolu]

In some Intel platforms, a single usb port is shared between USB host
and device controllers. The shared port is under control of a switch
which is defined in the Intel vendor defined extended capability for
xHCI.

This patch adds the support to detect and create the platform device
for the port mux switch.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
---
 drivers/usb/host/pci-quirks.c| 45 ++--
 drivers/usb/host/xhci-ext-caps.h |  2 ++
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 35af362..9bb7aa1 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -16,10 +16,11 @@
 #include 
 #include 
 #include 
+#include 
+
 #include "pci-quirks.h"
 #include "xhci-ext-caps.h"
 
-
 #define UHCI_USBLEGSUP 0xc0/* legacy support */
 #define UHCI_USBCMD0   /* command register */
 #define UHCI_USBINTR   4   /* interrupt register */
@@ -78,6 +79,8 @@
 #define USB_INTEL_USB3_PSSEN   0xD8
 #define USB_INTEL_USB3PRM  0xDC
 
+#define DEVICE_ID_INTEL_BROXTON_P_XHCI 0x5aa8
+
 /*
  * amd_chipset_gen values represent AMD different chipset generations
  */
@@ -956,6 +959,41 @@ void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
 }
 EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
 
+static void create_intel_usb_mux_device(struct pci_dev *xhci_pdev,
+   void __iomem *base)
+{
+   struct platform_device *plat_dev;
+   struct property_set pset;
+   int ret;
+
+   struct property_entry pentry[] = {
+   PROPERTY_ENTRY_U64("reg-start",
+  pci_resource_start(xhci_pdev, 0) + 0x80d8),
+   PROPERTY_ENTRY_U64("reg-size", 8),
+   { },
+   };
+
+   if (!xhci_find_next_ext_cap(base, 0, XHCI_EXT_CAPS_INTEL_USB_MUX))
+   return;
+
+   plat_dev = platform_device_alloc("intel-mux-drcfg",
+PLATFORM_DEVID_NONE);
+   if (!plat_dev)
+   return;
+
+   plat_dev->dev.parent = _pdev->dev;
+   pset.properties = pentry;
+   platform_device_add_properties(plat_dev, );
+
+   ret = platform_device_add(plat_dev);
+   if (ret) {
+   dev_warn(_pdev->dev,
+"failed to create mux device with error %d",
+   ret);
+   platform_device_put(plat_dev);
+   }
+}
+
 /**
  * PCI Quirks for xHCI.
  *
@@ -1022,8 +1060,11 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
 
 hc_init:
-   if (pdev->vendor == PCI_VENDOR_ID_INTEL)
+   if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
usb_enable_intel_xhci_ports(pdev);
+   if (pdev->device == DEVICE_ID_INTEL_BROXTON_P_XHCI)
+   create_intel_usb_mux_device(pdev, base);
+   }
 
op_reg_base = base + XHCI_HC_LENGTH(readl(base));
 
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index e0244fb..e368ccb 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -51,6 +51,8 @@
 #define XHCI_EXT_CAPS_ROUTE5
 /* IDs 6-9 reserved */
 #define XHCI_EXT_CAPS_DEBUG10
+/* Vendor defined 192-255 */
+#define XHCI_EXT_CAPS_INTEL_USB_MUX192
 /* USB Legacy Support Capability - section 7.1.1 */
 #define XHCI_HC_BIOS_OWNED (1 << 16)
 #define XHCI_HC_OS_OWNED   (1 << 24)
-- 
2.1.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 v6 08/10] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lu Baolu]

Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides 1) USB ID
extcon device; 2) USB vbus regulator device; and 3) USB port
switch device. This MFD driver will split these 3 devices for
their respective drivers.

[baolu: removed .owner per platform_no_drv_owner.cocci]
Suggested-by: David Cohen 
Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
---
 drivers/mfd/Kconfig|  8 +
 drivers/mfd/Makefile   |  1 +
 drivers/mfd/intel-vuport.c | 90 ++
 3 files changed, 99 insertions(+)
 create mode 100644 drivers/mfd/intel-vuport.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index eea61e3..7e115ab 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1578,5 +1578,13 @@ config MFD_VEXPRESS_SYSREG
  System Registers are the platform configuration block
  on the ARM Ltd. Versatile Express board.
 
+config MFD_INTEL_VUPORT
+   tristate "Intel virtual USB port controller"
+   select MFD_CORE
+   depends on X86 && ACPI
+   help
+ Say Y here to enable support for Intel's dual role port mux
+ controlled by GPIOs.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5eaa6465d..65b0518 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -203,3 +203,4 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o 
intel_soc_pmic_crc.o
 intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397-core.o
+obj-$(CONFIG_MFD_INTEL_VUPORT) += intel-vuport.o
diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
new file mode 100644
index 000..dbbb6cd
--- /dev/null
+++ b/drivers/mfd/intel-vuport.c
@@ -0,0 +1,90 @@
+/*
+ * MFD driver for Intel virtual USB port
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* ACPI GPIO Mappings */
+static const struct acpi_gpio_params id_gpio = { 0, 0, false };
+static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
+static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
+static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
+   { "id-gpios", _gpio, 1 },
+   { "vbus_en-gpios", _gpio, 1 },
+   { "usb_mux-gpios", _gpio, 1 },
+   { },
+};
+
+static struct property_entry reg_properties[] = {
+   PROPERTY_ENTRY_STRING("supply-name", "regulator-usb-gpio"),
+   PROPERTY_ENTRY_STRING("gpio-name", "vbus_en"),
+   { },
+};
+
+static const struct property_set reg_properties_pset = {
+   .properties = reg_properties,
+};
+
+static const struct mfd_cell intel_vuport_mfd_cells[] = {
+   { .name = "extcon-usb-gpio", },
+   {
+   .name = "reg-fixed-voltage",
+   .pset = _properties_pset,
+   },
+   { .name = "intel-mux-gpio", },
+};
+
+static int vuport_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
+   if (ret)
+   return ret;
+
+   return mfd_add_devices(>dev, PLATFORM_DEVID_NONE,
+   intel_vuport_mfd_cells,
+   ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
+   NULL);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+   mfd_remove_devices(>dev);
+   acpi_dev_remove_driver_gpios(ACPI_COMPANION(>dev));
+
+   return 0;
+}
+
+static struct acpi_device_id vuport_acpi_match[] = {
+   { "INT3496" },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
+
+static struct platform_driver vuport_driver = {
+   .driver = {
+   .name = "intel-vuport",
+   .acpi_match_table = ACPI_PTR(vuport_acpi_match),
+   },
+   .probe = vuport_probe,
+   .remove = vuport_remove,
+};
+
+module_platform_driver(vuport_driver);
+
+MODULE_AUTHOR("Lu Baolu ");
+MODULE_DESCRIPTION("Intel virtual USB port");
+MODULE_LICENSE("GPL v2");
-- 
2.1.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 v6 00/10] usb: add support for Intel dual role port mux

[Lu Baolu]

Intel SOC chips are featured with USB dual role. The host role is
provided by Intel xHCI IP, and the gadget role is provided by IP
from designware. Tablet platform designs always share a single
port for both host and gadget controllers. There is a mux to
switch the port to the right controller according to the cable
type. OS needs to provide the callback to control the mux when
a plug-in event raises. The method to control the mux is platform
dependent. At least three types of implementation can be found
across current devices. 1) GPIO pins; 2) a unit which can be
controlled by memory mapped registers; 3) ACPI ASL code.

This patch series adds supports for Intel dual role port mux.
It includes:
(1) A helper layer on top of extcon for individual mux driver.
It listens to the USB-HOST extcon cable and call the switch
call-back when the cable state changes.
(2) Drivers for GPIO controlled port mux which could be found
on Baytrail devices. A mfd driver is used to split the GPIOs
into a USB gpio extcon device, a fixed regulator for gpio
controlled USB VCC, and a USB mux device. Driver for USB
gpio extcon device is already in upstream Linux. This patch
series includes a driver for GPIO USB mux.
(3) Drivers for USB port mux controlled through memory mapped
registers and the logic to create the mux device. This type
of dual role port mux could be found in Cherry Trail and
Broxton devices.

Lu Baolu (10):
  extcon: usb-gpio: add device binding for platform device
  extcon: usb-gpio: add support for ACPI gpio interface
  regulator: fixed: add device binding for platform device
  regulator: fixed: add support for ACPI interface
  usb: mux: add generic code for dual role port mux
  usb: mux: add driver for Intel gpio controlled port mux
  usb: mux: add driver for Intel drcfg controlled port mux
  mfd: intel_vuport: Add Intel virtual USB port MFD Driver
  usb: pci-quirks: add Intel USB drcfg mux device
  MAINTAINERS: add maintainer entry for Intel USB dual role mux drivers

Change log:

v5->v6:
 Work internally with Felipe to improve the whole patch series.
 Below changes have been made since last version.
 - rework the common code to make it a generic interface for mux devices;
 - split the vbus gpio handling to a fixed regulator device;
 - removed unnecessary filtering for state change;
 - removed unnecessary WARN statement;
 - removed globals in mux drivers;
 - removed unnecessary register polling and waiting in drcfg driver;

v4->v5:
 - Change the extcon interfaces with the new ones suggested by
   2a9de9c0f08d6 (extcon: Use the unique id for external connector
   instead of string)
 - remove patch "usb: pci-quirks: add Intel USB drcfg mux device"
   from this serial due to that it's not driver staff. Will be
   submitted seperately.

v3->v4:
 - Check all patches with "checkpatch.pl --strict", and fix all
   CHECKs;
 - Change sysfs node from "intel_mux" to "port_mux";
 - Refines below confusing functions:
   intel_usb_mux_register() -> intel_usb_mux_bind_cable()
   intel_usb_mux_unregister() -> intel_usb_mux_unbind_cable();
 - Remove unnecessary struct intel_mux_dev.

v2->v3:
 - uvport mfd driver got reviewed by Lee Jones, the following
   changes were made accordingly.
 - seperate uvport driver from the mux drivers in MAINTAINERS file
 - refine the description in Kconfig
 - refine the mfd_cell structure data

v1->v2:
 - move mux driver from drivers/usb/misc to drivers/usb/mux;
 - replace debugfs with sysfs for user level mux control;
 - remove unnecessary register restore if mux registeration failed;
 - Add "Acked-by: Chanwoo Choi " to extcon changes;
 - Make the file names and exported function names more specific;
 - Remove the usb_mux_get_dev() interface;
 - Move "struct intel_usb_mux" from .h to .c file;
 - Fix various kbuild robot warnings.

 Documentation/ABI/testing/sysfs-bus-platform |  17 +++
 MAINTAINERS  |  10 ++
 drivers/extcon/extcon-usb-gpio.c |  10 +-
 drivers/mfd/Kconfig  |   8 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/intel-vuport.c   |  90 +++
 drivers/regulator/fixed.c|  55 +++
 drivers/usb/Kconfig  |   2 +
 drivers/usb/Makefile |   1 +
 drivers/usb/host/pci-quirks.c|  45 +-
 drivers/usb/host/xhci-ext-caps.h |   2 +
 drivers/usb/mux/Kconfig  |  30 
 drivers/usb/mux/Makefile |   6 +
 drivers/usb/mux/portmux-core.c   | 217 +++
 drivers/usb/mux/portmux-intel-drcfg.c| 171 +
 drivers/usb/mux/portmux-intel-gpio.c | 149 ++
 include/linux/usb/portmux.h  |  78 ++
 17 files changed, 889 insertions(+), 3 deletions(-)
 create mode 100644 drivers/mfd/intel-vuport.c
 create 

RE: [PATCH 1/5] usb: chipidea: add usb charger detection support

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, April 25, 2016 11:27 AM
> To: Jun Li 
> Cc: Peter Chen ; linux-usb@vger.kernel.org;
> baolin.w...@linaro.org
> Subject: Re: [PATCH 1/5] usb: chipidea: add usb charger detection support
> 
> On Mon, Apr 18, 2016 at 04:17:45PM +0800, Li Jun wrote:
> > Some usb module implementations has functionality of detect usb
> > charger type, it can be used by usb charger framework to report max
> > current drawn from charger in different situations.
> 
> %s/has/have

Okay

> %s/drawn/draw
> 
> >
> > Signed-off-by: Li Jun 
> > ---
> >  drivers/usb/chipidea/udc.c   | 40
> 
> >  include/linux/usb/chipidea.h |  4 
> >  2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 065f5d9..4d2187e 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -1510,6 +1510,37 @@ static const struct usb_ep_ops usb_ep_ops = {
> >
> /*
> *
> >   * GADGET block
> >
> > **
> > ***/
> > +static enum usb_charger_type ci_usb_charger_det(struct usb_charger
> > +*charger) {
> > +   struct ci_hdrc *ci;
> > +   enum usb_charger_type ret = UNKNOWN_TYPE;
> > +
> > +   if (!charger || !charger->gadget)
> > +   return ret;
> > +
> > +   ci = container_of(charger->gadget, struct ci_hdrc, gadget);
> > +   if (ci->vbus_active) {
> > +   if (ci->platdata->usb_charger_det) {
> > +   ret = ci->platdata->usb_charger_det(ci);
> > +   if (ret != UNKNOWN_TYPE)
> > +   return ret;
> > +   }
> > +
> > +   if (ci->platdata->pull_dp_for_charger) {
> > +   hw_device_reset(ci);
> > +   hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> > +   }
> > +
> > +   if (ci->platdata->usb_charger_secondary_det)
> > +   ret = ci->platdata->usb_charger_secondary_det(ci);
> > +
> > +   if (ci->platdata->pull_dp_for_charger)
> > +   hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static int ci_udc_vbus_session(struct usb_gadget *_gadget, int
> > is_active)  {
> > struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
> > @@ -1522,6 +1553,9 @@ static int ci_udc_vbus_session(struct usb_gadget
> *_gadget, int is_active)
> > gadget_ready = 1;
> > spin_unlock_irqrestore(>lock, flags);
> >
> > +   if (_gadget->charger && is_active)
> > +   usb_charger_detect_type(_gadget->charger);
> > +
> > if (gadget_ready) {
> > if (is_active) {
> > pm_runtime_get_sync(&_gadget->dev);
> > @@ -1922,6 +1956,9 @@ static int udc_start(struct ci_hdrc *ci)
> > if (retval)
> > goto destroy_eps;
> >
> > +   if (ci->gadget.charger && ci->platdata->usb_charger_det)
> > +   ci->gadget.charger->charger_detect = ci_usb_charger_det;
> > +
> > pm_runtime_no_callbacks(>gadget.dev);
> > pm_runtime_enable(>gadget.dev);
> >
> > @@ -1946,6 +1983,9 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
> > if (!ci->roles[CI_ROLE_GADGET])
> > return;
> >
> > +   if (ci->gadget.charger)
> > +   ci->gadget.charger->charger_detect = NULL;
> > +
> > usb_del_gadget_udc(>gadget);
> >
> > destroy_eps(ci);
> > diff --git a/include/linux/usb/chipidea.h
> > b/include/linux/usb/chipidea.h index 5dd75fa..7fc781d 100644
> > --- a/include/linux/usb/chipidea.h
> > +++ b/include/linux/usb/chipidea.h
> > @@ -55,10 +55,14 @@ struct ci_hdrc_platform_data {
> >  #define CI_HDRC_OVERRIDE_AHB_BURST BIT(9)
> >  #define CI_HDRC_OVERRIDE_TX_BURST  BIT(10)
> >  #define CI_HDRC_OVERRIDE_RX_BURST  BIT(11)
> > +#define CI_HDRC_PULL_DP_FOR_CHARGERBIT(12)
> > enum usb_dr_modedr_mode;
> >  #define CI_HDRC_CONTROLLER_RESET_EVENT 0
> >  #define CI_HDRC_CONTROLLER_STOPPED_EVENT   1
> > void(*notify_event) (struct ci_hdrc *ci, unsigned event);
> > +   enum usb_charger_type (*usb_charger_det)(struct ci_hdrc *ci);
> > +   boolpull_dp_for_charger;
> > +   enum usb_charger_type (*usb_charger_secondary_det)(struct ci_hdrc
> > +*ci);
> 
> You may add some comments for above two variables.

Okay, I will add comments for both.

> 
> > struct regulator*reg_vbus;
> > struct usb_otg_caps ci_otg_caps;
> > booltpl_support;
> > --
> > 1.9.1
> >
> 
> --
> 
> 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: [PATCHv6 2/2] usb: dwc2: Add reset control to dwc2

[Philipp Zabel]

Hi John,

Am Freitag, den 22.04.2016, 20:31 -0700 schrieb John Youn:
> On 4/20/2016 2:31 PM, dingu...@opensource.altera.com wrote:
> > From: Dinh Nguyen 
> > 
> > Allow for platforms that have a reset controller driver in place to bring
> > the USB IP out of reset.
> > 
> > Signed-off-by: Dinh Nguyen 
> > ---
> > v6: fix 80 line checkpatch warning in dev_err print
> > v5: updated error conditions for not finding the reset property
> > v4: use dev_dbg() if not a -EPROBE_DEFER
> > v3: fix compile error
> > v2: move to lowlevel_hw_init()
> > ---
> >  drivers/usb/dwc2/core.h |  1 +
> >  drivers/usb/dwc2/platform.c | 21 +
> >  2 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> > index 3c58d63..f748132 100644
> > --- a/drivers/usb/dwc2/core.h
> > +++ b/drivers/usb/dwc2/core.h
> > @@ -837,6 +837,7 @@ struct dwc2_hsotg {
> > void *priv;
> > int irq;
> > struct clk *clk;
> > +   struct reset_control *reset;
> >  
> > unsigned int queuing_high_bandwidth:1;
> > unsigned int srp_success:1;
> > diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> > index 88629be..fa2c097 100644
> > --- a/drivers/usb/dwc2/platform.c
> > +++ b/drivers/usb/dwc2/platform.c
> > @@ -45,6 +45,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> > @@ -337,6 +338,23 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg 
> > *hsotg)
> >  {
> > int i, ret;
> >  
> > +   hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
> > +   if (IS_ERR(hsotg->reset)) {
> > +   ret = PTR_ERR(hsotg->reset);
> > +   switch (ret) {
> > +   case -ENOENT:
> > +   hsotg->reset = NULL;
> > +   break;
> > +   default:
> > +   dev_err(hsotg->dev, "error getting reset control %d\n",
> > +   ret);
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   if (hsotg->reset)
> > +   reset_control_deassert(hsotg->reset);
> > +
> > /* Set default UTMI width */
> > hsotg->phyif = GUSBCFG_PHYIF16;
> >  
> > @@ -434,6 +452,9 @@ static int dwc2_driver_remove(struct platform_device 
> > *dev)
> > if (hsotg->ll_hw_enabled)
> > dwc2_lowlevel_hw_disable(hsotg);
> >  
> > +   if (hsotg->reset)
> > +   reset_control_assert(hsotg->reset);
> > +
> > return 0;
> >  }
> >  
> > 
> 
> Hi Dinh,
> 
> On my system, with no reset controller configured, this fails
> devm_reset_control_get() with -EINVAL, and it also spits out a
> backtrace.
>
> Hi Philipp,
> 
> I think devm_reset_control_get() should return either NULL or some
> other error to indicate that the reset controller is not
> configured. That way we can check it and handle that condition. If we
> check for -EINVAL, we might miss a legitimate error that is returning
> -EINVAL.
> 
> Also I think the WARN_ON(1) should be removed for this case.
> 
> Any thoughts on this or other suggestions to resolve it?

It is invalid to call (devm_)reset_control_get if the framework is
disabled, so that error code is correct. The only reason there are even
stubs for (devm_)reset_control_get is for compile tests. Either enable
CONFIG_RESET_CONTROLLER or use (devm_)reset_control_get_optional.

regards
Philipp

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

Re: [PATCH v2] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

[Geert Uytterhoeven]

Hi Shimoda-san,

On Mon, Apr 25, 2016 at 4:10 AM, Yoshihiro Shimoda
 wrote:
>> From: Rob Herring
>> Sent: Friday, April 22, 2016 10:29 PM
>> On Fri, Apr 22, 2016 at 4:36 AM, Felipe Balbi
>>  wrote:
>> > Yoshihiro Shimoda  writes:
>> >> The firmware of R-Car USB 3.0 host controller will control the reset.
>> >> So, if the xhci driver doesn't do firmware downloading (e.g. kernel
>> >> configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR
>> >> is not set), the reset of USB 3.0 host controller doesn't work
>> >> correctly. Then, the host controller will cause long wait in
>> >> xhci_reset() because the CMD_RESET bit of op_regs->command is not
>> >> cleared for 10 seconds.
>> >>
>> >> So, this patch modifies the xhci_rcar_init_quirk() in xhci-rcar.h
>> >> to exit the probe function immediately.
>> >>
>> >> Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 
>> >> and M2 xHCI controllers)
>> >> Cc:  # v3.17+
>> >> Signed-off-by: Yoshihiro Shimoda 
>> >> ---
>> >>  Changes from v1:
>> >>   - Revise the commit log.
>> >> (http://www.spinics.net/lists/stable/msg130007.html)
>> >>
>> >>  drivers/usb/host/xhci-rcar.h | 6 +-
>> >>  1 file changed, 5 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/usb/host/xhci-rcar.h b/drivers/usb/host/xhci-rcar.h
>> >> index 2941a25..2afed68 100644
>> >> --- a/drivers/usb/host/xhci-rcar.h
>> >> +++ b/drivers/usb/host/xhci-rcar.h
>> >> @@ -24,7 +24,11 @@ static inline void xhci_rcar_start(struct usb_hcd *hcd)
>> >>
>> >>  static inline int xhci_rcar_init_quirk(struct usb_hcd *hcd)
>> >>  {
>> >> - return 0;
>> >> + /*
>> >> +  * To avoid wait and timeout in xhci_reset() if CONFIG_XHCI_RCAR is
>> >> +  * disabled, this function fails.
>> >> +  */
>> >> + return -ENODEV;
>> >
>> > okay, if I understood correctly the thing is that you have a kernel
>> > built with XHCI platform support but without XHCI RCAR support. Then, if
>> > you run this kernel on RCAR board, you see this CMD_RESET problem,
>> > right?

[...]

>> We should fix this in kconfig to always enable the option when RCAR is
>> enabled IMO.
>
> I could fix this in kconfig like the followings:
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index f2bc5c3..905d1d2 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -46,6 +46,7 @@ menuconfig ARCH_RENESAS
> select PINCTRL
> select ARCH_REQUIRE_GPIOLIB
> select ZONE_DMA if ARM_LPAE
> +   select USB_XHCI_RCAR if USB_XHCI_HCD
>
>  if ARCH_RENESAS
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index efa77c1..010d2b7 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -105,6 +105,7 @@ config ARCH_RENESAS
> select PM
> select PM_GENERIC_DOMAINS
> select RENESAS_IRQC
> +   select USB_XHCI_RCAR if USB_XHCI_HCD
> help
>   This enables support for the ARMv8 based Renesas SoCs.
>
> If this is acceptable, I will send each patch to arm / arm64.

What about enforcing this in a single place instead, i.e. in
drivers/usb/host/Kconfig?

Gr{oetje,eeting}s,

Geert

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

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

Re: uas: order 7 page allocation failure in init_tag_map()

[Hans de Goede]

Hi,

On 23-04-16 23:10, Johannes Stezenbach wrote:

Hi,

I bought a new backup disk which turned out to be UAS capable,
but when I plugged it in I got an order 7 page allocation failure.
My hunch is that the .can_queue = 65536 in drivers/usb/storage/uas.c
is much too large.  Maybe 256 would be a pratical value that matches
the capabilities of existing hardware?


This is already fixed upstream (and being backported to the stable series):

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/storage/uas.c?id=55ff8cfbc4e12a7d2187df523938cc671fbebdd1

Regards,

Hans





[1859683.261465] usb 4-2: new SuperSpeed USB device number 8 using xhci_hcd
[1859683.281986] scsi host18: uas
[1859683.282003] kworker/0:2: page allocation failure: order:7, mode:0x208c020
[1859683.282008] CPU: 0 PID: 6888 Comm: kworker/0:2 Not tainted 4.4.6 #1
[1859683.282011] Hardware name: System manufacturer System Product 
Name/P8H77-V, BIOS 1905 10/27/2014
[1859683.282017] Workqueue: usb_hub_wq hub_event
[1859683.282021]  0286 d38f5999 8800751674d0 
813527de
[1859683.282026]   0208c020 880075167570 
81157c56
[1859683.282031]  880075167580 880075167508 81f43840 
00f438b8
[1859683.282036] Call Trace:
[1859683.282045]  [] dump_stack+0x85/0xbe
[1859683.282050]  [] warn_alloc_failed+0x12c/0x156
[1859683.282055]  [] __alloc_pages_nodemask+0x73a/0x8f1
[1859683.282060]  [] ? dev_vprintk_emit+0x1cb/0x1f1
[1859683.282065]  [] alloc_kmem_pages+0x22/0x8a
[1859683.282069]  [] kmalloc_order+0x18/0x46
[1859683.282072]  [] kmalloc_order_trace+0x21/0xe9
[1859683.282077]  [] __kmalloc+0x38/0x22f
[1859683.282081]  [] ? __blk_queue_init_tags+0x2f/0x73
[1859683.282085]  [] init_tag_map+0x54/0xa3
[1859683.282088]  [] __blk_queue_init_tags+0x45/0x73
[1859683.282092]  [] blk_init_tags+0x14/0x16
[1859683.282096]  [] scsi_add_host_with_dma+0xc8/0x2a0
[1859683.282102]  [] uas_probe+0x3aa/0x420 [uas]
[1859683.282107]  [] usb_probe_interface+0x1a6/0x22d
[1859683.282112]  [] driver_probe_device+0x173/0x3a6
[1859683.282116]  [] __device_attach_driver+0x71/0x78
[1859683.282120]  [] ? driver_allows_async_probing+0x31/0x31
[1859683.282124]  [] bus_for_each_drv+0x8a/0xad
[1859683.282128]  [] __device_attach+0xba/0x14f
[1859683.282132]  [] device_initial_probe+0x13/0x15
[1859683.282136]  [] bus_probe_device+0x33/0x9e
[1859683.282140]  [] device_add+0x2e4/0x56e
[1859683.282144]  [] usb_set_configuration+0x689/0x6d9
[1859683.282148]  [] ? debug_smp_processor_id+0x17/0x19
[1859683.282152]  [] generic_probe+0x43/0x73
[1859683.282156]  [] usb_probe_device+0x53/0x66
[1859683.282159]  [] driver_probe_device+0x173/0x3a6
[1859683.282163]  [] __device_attach_driver+0x71/0x78
[1859683.282167]  [] ? driver_allows_async_probing+0x31/0x31
[1859683.282171]  [] bus_for_each_drv+0x8a/0xad
[1859683.282175]  [] __device_attach+0xba/0x14f
[1859683.282179]  [] device_initial_probe+0x13/0x15
[1859683.282183]  [] bus_probe_device+0x33/0x9e
[1859683.282186]  [] device_add+0x2e4/0x56e
[1859683.282191]  [] usb_new_device+0x241/0x38a
[1859683.282194]  [] hub_event+0xcb9/0x10f2
[1859683.282201]  [] process_one_work+0x27f/0x4d7
[1859683.282206]  [] ? put_lock_stats.isra.9+0xe/0x20
[1859683.282209]  [] worker_thread+0x273/0x35b
[1859683.282214]  [] ? rescuer_thread+0x2a7/0x2a7
[1859683.282217]  [] kthread+0xff/0x107
[1859683.28]  [] ? kthread_create_on_node+0x1ea/0x1ea
[1859683.282228]  [] ret_from_fork+0x3f/0x70
[1859683.282231]  [] ? kthread_create_on_node+0x1ea/0x1ea
[1859683.282234] Mem-Info:
[1859683.282241] active_anon:21278 inactive_anon:69854 isolated_anon:0
   active_file:212300 inactive_file:194346 isolated_file:0
   unevictable:2018 dirty:87 writeback:0 unstable:0
   slab_reclaimable:127644 slab_unreclaimable:12137
   mapped:11526 shmem:13394 pagetables:5007 bounce:0
   free:270678 free_pcp:1027 free_cma:0
[1859683.282252] DMA free:14412kB min:32kB low:40kB high:48kB active_anon:180kB 
inactive_anon:468kB active_file:268kB inactive_file:92kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15984kB managed:15900kB 
mlocked:0kB dirty:4kB writeback:0kB mapped:172kB shmem:328kB 
slab_reclaimable:208kB slab_unreclaimable:92kB kernel_stack:0kB pagetables:56kB 
unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB 
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[1859683.282255] lowmem_reserve[]: 0 3162 3597 3597
[1859683.282267] DMA32 free:904468kB min:6728kB low:8408kB high:10092kB 
active_anon:66188kB inactive_anon:237164kB active_file:803244kB 
inactive_file:704168kB unevictable:7024kB isolated(anon):0kB isolated(file):0kB 
present:3334492kB managed:3243208kB mlocked:7024kB dirty:280kB writeback:0kB 
mapped:37116kB shmem:40212kB slab_reclaimable:435236kB 
slab_unreclaimable:37848kB kernel_stack:3968kB pagetables:16696kB unstable:0kB 
bounce:0kB 

Re: devicetree: avoid duplicated matching code (was: Re: [PATCH 1/3] xhci: plat: adapt to unified device property interface)

[Felipe Balbi]

Hi,

Rob Herring  writes:
> On Thu, Apr 21, 2016 at 8:57 AM, Felipe Balbi
>  wrote:
>>
>> Hi,
>>
>> Rob Herring  writes:
>>> On Thu, Apr 21, 2016 at 6:20 AM, Felipe Balbi
>>>  wrote:

 Hi,

 Heikki Krogerus  writes:
> @@ -197,7 +196,7 @@ static int xhci_plat_probe(struct platform_device 
> *pdev)
>   }
>
>   xhci = hcd_to_xhci(hcd);
> - match = of_match_node(usb_xhci_of_match, node);
> + match = of_match_node(usb_xhci_of_match, pdev->dev.of_node);

 Rob, it's weird that OF-based drivers have to redo the same matching
 which was already done by drivers/base/platform.c::platform_match() just
 to get match->data. If we know we matched, couldn't we just cache a
 pointer to match->data in struct device_node.data ? Something like
 below? (completely untested)
>>>
>>> Yes, it is. AIUI, there is some sort of race condition in doing what
>>> you suggest though. IIRC, Grant did that and reverted it if you look
>>> at the git history.
>>
>> looking at drivers/base/platform.c I can't find anything along these
>> lines. Adding Grant.
>>
>> Grant, any memory left of this race ?
>
> https://lkml.org/lkml/2011/5/18/384
>
> tl;dr: matching and probe is not atomic.

cool, thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCHv3] usb: Add driver for UCSI

[Felipe Balbi]

Heikki Krogerus  writes:

> USB Type-C Connector System Software Interface (UCSI) is
> specification that defines the registers and data structures
> that can be used to control USB Type-C ports on a system.
> UCSI is used on several Intel Broxton SoC based platforms.
> Things that UCSI can be used to control include at least USB
> Data Role swapping, Power Role swapping and controlling of
> Alternate Modes on top of providing general details about
> the port and the partners that are attached to it.
>
> The initial purpose of the UCSI driver is to make sure USB
> is in host mode on desktop and server systems that are USB
> dual role capable, and provide UCSI interface.
>
> The goal is to integrate the driver later to an USB Type-C
> framework for Linux kernel, and at the same time add support
> for more extensive USB Type-C port control that UCSI offers,
> for example data role swapping, power role swapping,
> Alternate Mode control etc.
>
> The UCSI specification is public can be obtained from here:
> http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
>
> Signed-off-by: Heikki Krogerus 

Reviewed-by: Felipe Balbi 


-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH v2] usb: host: xhci-rcar: Avoid long wait in xhci_reset()

[Felipe Balbi]

Hi,

Yoshihiro Shimoda  writes:
>> > Yoshihiro Shimoda  writes:
>> >> The firmware of R-Car USB 3.0 host controller will control the reset.
>> >> So, if the xhci driver doesn't do firmware downloading (e.g. kernel
>> >> configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR
>> >> is not set), the reset of USB 3.0 host controller doesn't work
>> >> correctly. Then, the host controller will cause long wait in
>> >> xhci_reset() because the CMD_RESET bit of op_regs->command is not
>> >> cleared for 10 seconds.
>> >>
>> >> So, this patch modifies the xhci_rcar_init_quirk() in xhci-rcar.h
>> >> to exit the probe function immediately.
>> >>
>> >> Fixes: 4ac8918f3a7 (usb: host: xhci-plat: add support for the R-Car H2 
>> >> and M2 xHCI controllers)
>> >> Cc:  # v3.17+
>> >> Signed-off-by: Yoshihiro Shimoda 
>> >> ---
>> >>  Changes from v1:
>> >>   - Revise the commit log.
>> >> (http://www.spinics.net/lists/stable/msg130007.html)
>> >>
>> >>  drivers/usb/host/xhci-rcar.h | 6 +-
>> >>  1 file changed, 5 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/usb/host/xhci-rcar.h b/drivers/usb/host/xhci-rcar.h
>> >> index 2941a25..2afed68 100644
>> >> --- a/drivers/usb/host/xhci-rcar.h
>> >> +++ b/drivers/usb/host/xhci-rcar.h
>> >> @@ -24,7 +24,11 @@ static inline void xhci_rcar_start(struct usb_hcd *hcd)
>> >>
>> >>  static inline int xhci_rcar_init_quirk(struct usb_hcd *hcd)
>> >>  {
>> >> - return 0;
>> >> + /*
>> >> +  * To avoid wait and timeout in xhci_reset() if CONFIG_XHCI_RCAR is
>> >> +  * disabled, this function fails.
>> >> +  */
>> >> + return -ENODEV;
>> >
>> > okay, if I understood correctly the thing is that you have a kernel
>> > built with XHCI platform support but without XHCI RCAR support. Then, if
>> > you run this kernel on RCAR board, you see this CMD_RESET problem,
>> > right?
>> >
>> > Isn't this pointing to the fact that xhci-plat.ko built without RCAR
>> > isn't exactly compatible with RCAR ?
>> >
>> > IOW:
>> >
>> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> > index 676ea458148b..3e39320564ce 100644
>> > --- a/drivers/usb/host/xhci-plat.c
>> > +++ b/drivers/usb/host/xhci-plat.c
>> > @@ -112,6 +112,7 @@ static const struct of_device_id usb_xhci_of_match[] = 
>> > {
>> > }, {
>> > .compatible = "marvell,armada-380-xhci",
>> > .data = _plat_marvell_armada,
>> > +#if IS_ENABLED(CONFIG_USB_XHCI_RCAR)
>> > }, {
>> > .compatible = "renesas,xhci-r8a7790",
>> > .data = _plat_renesas_rcar_gen2,
>> > @@ -130,6 +131,7 @@ static const struct of_device_id usb_xhci_of_match[] = 
>> > {
>> > }, {
>> > .compatible = "renesas,rcar-gen3-xhci",
>> > .data = _plat_renesas_rcar_gen3,
>> > +#endif
>> > },
>> > {},
>> >  };
>> >
>> > Rob, should we limit compatible flags like this ? Without
>> > CONFIG_USB_XHCI_RCAR, this driver won't work on RCAR but, as you can
>> > see, this driver might still work on other non-RCAR platforms.
>> >
>> > What's your take on this ?
>> 
>> We should fix this in kconfig to always enable the option when RCAR is
>> enabled IMO.
>
> I could fix this in kconfig like the followings:
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index f2bc5c3..905d1d2 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -46,6 +46,7 @@ menuconfig ARCH_RENESAS
>   select PINCTRL
>   select ARCH_REQUIRE_GPIOLIB
>   select ZONE_DMA if ARM_LPAE
> + select USB_XHCI_RCAR if USB_XHCI_HCD
>  
>  if ARCH_RENESAS
>  
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index efa77c1..010d2b7 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -105,6 +105,7 @@ config ARCH_RENESAS
>   select PM
>   select PM_GENERIC_DOMAINS
>   select RENESAS_IRQC
> + select USB_XHCI_RCAR if USB_XHCI_HCD
>   help
> This enables support for the ARMv8 based Renesas SoCs.
>
> If this is acceptable, I will send each patch to arm / arm64.

I'm okay with that, not sure what the ARM folks will think ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 5/5] doc: usb: ci-hdrc-usb2: add property usb-charger-detection

[Peter Chen]

On Mon, Apr 18, 2016 at 04:17:49PM +0800, Li Jun wrote:
> Set this property if your usb module has usb charger detect function
> and you want to use it.
> 
> Signed-off-by: Li Jun 
> ---
>  Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
> b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> index 1084e2b..52d269e 100644
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
> @@ -76,6 +76,8 @@ Optional properties:
>needs to make sure it does not send more than 90%
>maximum_periodic_data_per_frame. The use case is multiple transactions, but
>less frame rate.
> +- usb-charger-detection: use usb charger detect function provided by usb
> +  module; if your usb charger type detection done by PMIC, don't enable this.
>  

If the user doesn't set it at dts, and detection is done by PMIC,
would you show us the flow how it work at chipidea driver?

-- 

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

Re: [PATCH 1/5] usb: chipidea: add usb charger detection support

[Peter Chen]

On Mon, Apr 18, 2016 at 04:17:45PM +0800, Li Jun wrote:
> Some usb module implementations has functionality of detect usb charger
> type, it can be used by usb charger framework to report max current drawn
> from charger in different situations.
> 
> Signed-off-by: Li Jun 
> ---
>  drivers/usb/chipidea/udc.c   | 40 
>  include/linux/usb/chipidea.h |  4 
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 065f5d9..4d2187e 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1510,6 +1510,37 @@ static const struct usb_ep_ops usb_ep_ops = {
>  
> /**
>   * GADGET block
>   
> */
> +static enum usb_charger_type ci_usb_charger_det(struct usb_charger *charger)
> +{
> + struct ci_hdrc *ci;
> + enum usb_charger_type ret = UNKNOWN_TYPE;
> +
> + if (!charger || !charger->gadget)
> + return ret;
> +
> + ci = container_of(charger->gadget, struct ci_hdrc, gadget);
> + if (ci->vbus_active) {
> + if (ci->platdata->usb_charger_det) {
> + ret = ci->platdata->usb_charger_det(ci);
> + if (ret != UNKNOWN_TYPE)
> + return ret;
> + }
> +
> + if (ci->platdata->pull_dp_for_charger) {
> + hw_device_reset(ci);
> + hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
> + }
> +
> + if (ci->platdata->usb_charger_secondary_det)
> + ret = ci->platdata->usb_charger_secondary_det(ci);
> +
> + if (ci->platdata->pull_dp_for_charger)
> + hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
> + }
> +
> + return ret;
> +}
> +
>  static int ci_udc_vbus_session(struct usb_gadget *_gadget, int is_active)
>  {
>   struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
> @@ -1522,6 +1553,9 @@ static int ci_udc_vbus_session(struct usb_gadget 
> *_gadget, int is_active)
>   gadget_ready = 1;
>   spin_unlock_irqrestore(>lock, flags);
>  
> + if (_gadget->charger && is_active)

if (_gadget->charger && _gadget->charger->charger_detect && is_active)

Otherwise there will be a warning message if the user does not define
->charger_detect API.


> + usb_charger_detect_type(_gadget->charger);
> +
>   if (gadget_ready) {
>   if (is_active) {
>   pm_runtime_get_sync(&_gadget->dev);
> @@ -1922,6 +1956,9 @@ static int udc_start(struct ci_hdrc *ci)
>   if (retval)
>   goto destroy_eps;
>  
> + if (ci->gadget.charger && ci->platdata->usb_charger_det)
> + ci->gadget.charger->charger_detect = ci_usb_charger_det;
> +
>   pm_runtime_no_callbacks(>gadget.dev);
>   pm_runtime_enable(>gadget.dev);
>  
> @@ -1946,6 +1983,9 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
>   if (!ci->roles[CI_ROLE_GADGET])
>   return;
>  
> + if (ci->gadget.charger)
> + ci->gadget.charger->charger_detect = NULL;
> +
>   usb_del_gadget_udc(>gadget);
>  
>   destroy_eps(ci);
> diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> index 5dd75fa..7fc781d 100644
> --- a/include/linux/usb/chipidea.h
> +++ b/include/linux/usb/chipidea.h
> @@ -55,10 +55,14 @@ struct ci_hdrc_platform_data {
>  #define CI_HDRC_OVERRIDE_AHB_BURST   BIT(9)
>  #define CI_HDRC_OVERRIDE_TX_BURSTBIT(10)
>  #define CI_HDRC_OVERRIDE_RX_BURSTBIT(11)
> +#define CI_HDRC_PULL_DP_FOR_CHARGER  BIT(12)
>   enum usb_dr_modedr_mode;
>  #define CI_HDRC_CONTROLLER_RESET_EVENT   0
>  #define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
>   void(*notify_event) (struct ci_hdrc *ci, unsigned event);
> + enum usb_charger_type (*usb_charger_det)(struct ci_hdrc *ci);
> + boolpull_dp_for_charger;
> + enum usb_charger_type (*usb_charger_secondary_det)(struct ci_hdrc *ci);

Please don't use shortening for "detect", the same for "secondary"
in your patch 4.

>   struct regulator*reg_vbus;
>   struct usb_otg_caps ci_otg_caps;
>   booltpl_support;
> -- 
> 1.9.1
> 

-- 

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

Re: [PATCH 4/5] usb: chipidea: imx: add usb charger detection for imx7d

[Peter Chen]

On Mon, Apr 18, 2016 at 04:17:48PM +0800, Li Jun wrote:
> Adds imx7d usb charger detection implementation, which needs pull up
> DP line before do secondary detection and pull down DP afterwards.
> 

You can merge patch 3 and patch 4 as one patch.

Acked-by: Peter Chen 

> Signed-off-by: Li Jun 
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c |   3 +-
>  drivers/usb/chipidea/usbmisc_imx.c | 157 
> +
>  2 files changed, 159 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 83a59d6..5a6b712 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -67,7 +67,8 @@ static const struct ci_hdrc_imx_platform_flag 
> imx6ul_usb_data = {
>  };
>  
>  static const struct ci_hdrc_imx_platform_flag imx7d_usb_data = {
> - .flags = CI_HDRC_SUPPORTS_RUNTIME_PM,
> + .flags = CI_HDRC_SUPPORTS_RUNTIME_PM |
> + CI_HDRC_PULL_DP_FOR_CHARGER,
>  };
>  
>  static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
> diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
> b/drivers/usb/chipidea/usbmisc_imx.c
> index daa7c02..4f4ae56 100644
> --- a/drivers/usb/chipidea/usbmisc_imx.c
> +++ b/drivers/usb/chipidea/usbmisc_imx.c
> @@ -74,6 +74,11 @@
>  #define VF610_OVER_CUR_DIS   BIT(7)
>  
>  #define MX7D_USBNC_USB_CTRL2 0x4
> +#define MX7D_USBNC_USB_CTRL2_OPMODE_OVERRIDE_EN  BIT(8)
> +#define MX7D_USBNC_USB_CTRL2_OPMODE_OVERRIDE_MASK(BIT(7) | BIT(6))
> +#define MX7D_USBNC_USB_CTRL2_OPMODE(v)   (v << 6)
> +#define MX7D_USBNC_USB_CTRL2_OPMODE_NON_DRIVING  
> MX7D_USBNC_USB_CTRL2_OPMODE(1)
> +
>  #define MX7D_USB_VBUS_WAKEUP_SOURCE_MASK 0x3
>  #define MX7D_USB_VBUS_WAKEUP_SOURCE(v)   (v << 0)
>  #define MX7D_USB_VBUS_WAKEUP_SOURCE_VBUS MX7D_USB_VBUS_WAKEUP_SOURCE(0)
> @@ -81,6 +86,18 @@
>  #define MX7D_USB_VBUS_WAKEUP_SOURCE_BVALID   MX7D_USB_VBUS_WAKEUP_SOURCE(2)
>  #define MX7D_USB_VBUS_WAKEUP_SOURCE_SESS_END MX7D_USB_VBUS_WAKEUP_SOURCE(3)
>  
> +#define MX7D_USB_OTG_PHY_CFG2_CHRG_DCDENBBIT(3)
> +#define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATSRCENB0   BIT(2)
> +#define MX7D_USB_OTG_PHY_CFG2_CHRG_VDATDETENB0   BIT(1)
> +#define MX7D_USB_OTG_PHY_CFG2_CHRG_CHRGSEL   BIT(0)
> +#define MX7D_USB_OTG_PHY_CFG20x34
> +
> +#define MX7D_USB_OTG_PHY_STATUS  0x3c
> +#define MX7D_USB_OTG_PHY_STATUS_CHRGDET  BIT(29)
> +#define MX7D_USB_OTG_PHY_STATUS_VBUS_VLD BIT(3)
> +#define MX7D_USB_OTG_PHY_STATUS_LINE_STATE1  BIT(1)
> +#define MX7D_USB_OTG_PHY_STATUS_LINE_STATE0  BIT(0)
> +
>  struct usbmisc_ops {
>   /* It's called once when probe a usb device */
>   int (*init)(struct imx_usbmisc_data *data);
> @@ -385,6 +402,144 @@ static int usbmisc_imx7d_init(struct imx_usbmisc_data 
> *data)
>   return 0;
>  }
>  
> +static void imx7d_disable_charger_detector(struct imx_usbmisc_data *data)
> +{
> + struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
> + unsigned long flags;
> + u32 val;
> +
> + spin_lock_irqsave(>lock, flags);
> + val = readl(usbmisc->base + MX7D_USB_OTG_PHY_CFG2);
> + val &= ~(MX7D_USB_OTG_PHY_CFG2_CHRG_DCDENB |
> + MX7D_USB_OTG_PHY_CFG2_CHRG_VDATSRCENB0 |
> + MX7D_USB_OTG_PHY_CFG2_CHRG_VDATDETENB0 |
> + MX7D_USB_OTG_PHY_CFG2_CHRG_CHRGSEL);
> + writel(val, usbmisc->base + MX7D_USB_OTG_PHY_CFG2);
> +
> + /* Set OPMODE to be 2'b00 and disable its override */
> + val = readl(usbmisc->base + MX7D_USBNC_USB_CTRL2);
> + val &= ~MX7D_USBNC_USB_CTRL2_OPMODE_OVERRIDE_MASK;
> + writel(val, usbmisc->base + MX7D_USBNC_USB_CTRL2);
> +
> + val = readl(usbmisc->base + MX7D_USBNC_USB_CTRL2);
> + writel(val & ~MX7D_USBNC_USB_CTRL2_OPMODE_OVERRIDE_EN,
> + usbmisc->base + MX7D_USBNC_USB_CTRL2);
> + spin_unlock_irqrestore(>lock, flags);
> +}
> +
> +static int imx7d_charger_data_contact_detect(struct imx_usbmisc_data *data)
> +{
> + struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
> + int i, data_pin_contact_count = 0;
> + unsigned long flags;
> + u32 val;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + /* check if vbus is valid */
> + val = readl(usbmisc->base + MX7D_USB_OTG_PHY_STATUS);
> + if (!(val & MX7D_USB_OTG_PHY_STATUS_VBUS_VLD)) {
> + dev_err(data->dev, "vbus is error\n");
> + spin_unlock_irqrestore(>lock, flags);
> + return -EINVAL;
> + }
> +
> + /*
> +  * - Do not check whether a charger is connected to the USB port
> +  * - Check whether the USB plug has been in contact with each other
> +  */
> + val = readl(usbmisc->base + MX7D_USB_OTG_PHY_CFG2);
> + writel(val | MX7D_USB_OTG_PHY_CFG2_CHRG_DCDENB,
> + usbmisc->base + MX7D_USB_OTG_PHY_CFG2);
> +
> 

[PATCH] usb: dwc3: gadget: give better command return code

[Felipe Balbi]

From: Konrad Leszczynski 

if Start Transfer command fails, let's try a little
harder to figure out why the command failed and give
slightly better return codes. This will be usefulf
or isochronous endpoints, at least, which could
decide to retry a given request.

Signed-off-by: Konrad Leszczynski 
Signed-off-by: Rafal Redzimski 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.h   |  4 
 drivers/usb/dwc3/gadget.c | 33 +
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index bbbd1789596e..87df6dd20d23 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -970,6 +970,10 @@ struct dwc3_event_depevt {
 #define DEPEVT_STATUS_CONTROL_DATA 1
 #define DEPEVT_STATUS_CONTROL_STATUS   2
 
+/* In response to Start Transfer */
+#define DEPEVT_TRANSFER_NO_RESOURCE1
+#define DEPEVT_TRANSFER_BUS_EXPIRY 2
+
u32 parameters:16;
 } __packed;
 
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 6929775bde57..9fcbfaee642a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -287,13 +287,38 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
do {
reg = dwc3_readl(dwc->regs, DWC3_DEPCMD(ep));
if (!(reg & DWC3_DEPCMD_CMDACT)) {
+   int cmd_status = DWC3_DEPCMD_STATUS(reg);
+
dwc3_trace(trace_dwc3_gadget,
"Command Complete --> %d",
-   DWC3_DEPCMD_STATUS(reg));
-   if (DWC3_DEPCMD_STATUS(reg))
+   cmd_status);
+
+   switch (cmd_status) {
+   case 0:
+   ret = 0;
break;
-   ret = 0;
-   break;
+   case DEPEVT_TRANSFER_NO_RESOURCE:
+   dwc3_trace(trace_dwc3_gadget, "%s: no resource 
available");
+   ret = -EINVAL;
+   break;
+   case DEPEVT_TRANSFER_BUS_EXPIRY:
+   /*
+* SW issues START TRANSFER command to
+* isochronous ep with future frame interval. If
+* future interval time has already passed when
+* core receives the command, it will respond
+* with an error status of 'Bus Expiry'.
+*
+* Instead of always returning -EINVAL, let's
+* give a hint to the gadget driver that this is
+* the case by returning -EAGAIN.
+*/
+   dwc3_trace(trace_dwc3_gadget, "%s: bus expiry");
+   ret = -EAGAIN;
+   break;
+   default:
+   dev_WARN(dwc->dev, "UNKNOWN cmd status\n");
+   }
}
 
/*
-- 
2.8.1

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