RE: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t

[Reshetova, Elena]

> On 03/08/2017 08:49 AM, Reshetova, Elena wrote:
> >> On 03/06/2017 09:21 AM, Elena Reshetova wrote:
> >>> refcount_t type and corresponding API should be
> >>> used instead of atomic_t when the variable is used as
> >>> a reference counter. This allows to avoid accidental
> >>> refcounter overflows that might lead to use-after-free
> >>> situations.
> >>>
> >>> Signed-off-by: Elena Reshetova 
> >>> Signed-off-by: Hans Liljestrand 
> >>> Signed-off-by: Kees Cook 
> >>> Signed-off-by: David Windsor 
> >>> ---
> >>>  drivers/xen/gntdev.c | 11 ++-
> >>>  1 file changed, 6 insertions(+), 5 deletions(-)
> >> Reviewed-by: Boris Ostrovsky 
> > Is there a tree that can take this change? Turns out it is better to 
> > propagate
> changes via separate trees and only leftovers can be taken via Greg's tree.
> >
> 
> Sure, we can take it via Xen tree for rc3.

Thank you very much!

Best Regards,
Elena.

> 
> -boris

RE: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t

[Reshetova, Elena]

> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> 
> This looks OK to me.
> 
> Acked-by: Chris Leech 

Thank you for review! Do you have a tree that can take this change? 

Best Regards,
Elena.

> 
> > ---
> >  drivers/scsi/libiscsi.c| 8 
> >  drivers/scsi/qedi/qedi_iscsi.c | 2 +-
> >  include/scsi/libiscsi.h| 3 ++-
> >  3 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> > index 834d121..7eb1d2c 100644
> > --- a/drivers/scsi/libiscsi.c
> > +++ b/drivers/scsi/libiscsi.c
> > @@ -516,13 +516,13 @@ static void iscsi_free_task(struct iscsi_task *task)
> >
> >  void __iscsi_get_task(struct iscsi_task *task)
> >  {
> > -   atomic_inc(>refcount);
> > +   refcount_inc(>refcount);
> >  }
> >  EXPORT_SYMBOL_GPL(__iscsi_get_task);
> >
> >  void __iscsi_put_task(struct iscsi_task *task)
> >  {
> > -   if (atomic_dec_and_test(>refcount))
> > +   if (refcount_dec_and_test(>refcount))
> > iscsi_free_task(task);
> >  }
> >  EXPORT_SYMBOL_GPL(__iscsi_put_task);
> > @@ -744,7 +744,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct
> iscsi_hdr *hdr,
> >  * released by the lld when it has transmitted the task for
> >  * pdus we do not expect a response for.
> >  */
> > -   atomic_set(>refcount, 1);
> > +   refcount_set(>refcount, 1);
> > task->conn = conn;
> > task->sc = NULL;
> > INIT_LIST_HEAD(>running);
> > @@ -1616,7 +1616,7 @@ static inline struct iscsi_task 
> > *iscsi_alloc_task(struct
> iscsi_conn *conn,
> > sc->SCp.phase = conn->session->age;
> > sc->SCp.ptr = (char *) task;
> >
> > -   atomic_set(>refcount, 1);
> > +   refcount_set(>refcount, 1);
> > task->state = ISCSI_TASK_PENDING;
> > task->conn = conn;
> > task->sc = sc;
> > diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
> > index b9f79d3..3895bd5 100644
> > --- a/drivers/scsi/qedi/qedi_iscsi.c
> > +++ b/drivers/scsi/qedi/qedi_iscsi.c
> > @@ -1372,7 +1372,7 @@ static void qedi_cleanup_task(struct iscsi_task *task)
> >  {
> > if (!task->sc || task->state == ISCSI_TASK_PENDING) {
> > QEDI_INFO(NULL, QEDI_LOG_IO, "Returning
> ref_cnt=%d\n",
> > - atomic_read(>refcount));
> > + refcount_read(>refcount));
> > return;
> > }
> >
> > diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
> > index b0e275d..24d74b5 100644
> > --- a/include/scsi/libiscsi.h
> > +++ b/include/scsi/libiscsi.h
> > @@ -29,6 +29,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -139,7 +140,7 @@ struct iscsi_task {
> >
> > /* state set/tested under session->lock */
> > int state;
> > -   atomic_trefcount;
> > +   refcount_t  refcount;
> > struct list_headrunning;/* running cmd list */
> > void*dd_data;   /*
> driver/transport data */
> >  };
> > --
> > 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 1/3] usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()

[Roger Quadros]

Felipe,

On 15/02/17 13:38, Roger Quadros wrote:
> We need to break from all cases if we want to treat
> each one of them separately.
> 
> Reported-by: Gustavo A. R. Silva 
> Fixes: d2728fb3e01f ("usb: dwc3: omap: Pass VBUS and ID events transparently")
> Cc:  #v4.8+
> Signed-off-by: Roger Quadros 

Can you please pick this one for v4.11-rc? Thanks.

> ---
>  drivers/usb/dwc3/dwc3-omap.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index eb1b9cb..35b6351 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -250,6 +250,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
>   val = dwc3_omap_read_utmi_ctrl(omap);
>   val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG;
>   dwc3_omap_write_utmi_ctrl(omap, val);
> + break;
>  
>   case OMAP_DWC3_VBUS_OFF:
>   val = dwc3_omap_read_utmi_ctrl(omap);
> 

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

Re: [PATCH v5 04/19] net: e100: Replace PCI pool old API

[Peter Senna Tschudin]

On Wed, Mar 08, 2017 at 02:40:25PM -0800, Jeff Kirsher wrote:
> On Wed, 2017-03-08 at 17:19 +0100, Romain Perier wrote:
> > The PCI pool API is deprecated. This commit replaces the PCI pool old
> > API by the appropriate function with the DMA pool API.
> > 
> > Signed-off-by: Romain Perier 
> > Acked-by: Peter Senna Tschudin 
> > Tested-by: Peter Senna Tschudin 
> > ---
> >  drivers/net/ethernet/intel/e100.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> Acked-by: Jeff Kirsher 
> 
> My only concern is:
> - what hardware did this get tested with?  Since this affects all e100
> parts, it would be hard to believe that all the affected hardware was
> used in testing.

This was tested by compilation only(See
https://lkml.org/lkml/2017/2/8/661). However this series removes macro
definitions of the old pci_pool interface and replace call sites by what
the macra was calling.

Here are the macros that this series removes from include/pci.h:

#define pci_pool dma_pool
#define pci_pool_create(name, pdev, size, align, allocation) \
dma_pool_create(name, >dev, size, align, allocation)
#define pci_pool_destroy(pool) dma_pool_destroy(pool)
#define pci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, flags, handle)
#define pci_pool_zalloc(pool, flags, handle) \
dma_pool_zalloc(pool, flags, handle)
#define pci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr, add

So this should not affect run 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

[PATCH] usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers

[Guenter Roeck]

Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of
PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
xhci controllers which can result in excessive timeouts, to the point where
the system reports a deadlock.

The same problem is seen with hot pluggable xhci controllers using the
xhci-plat driver, such as the driver used for Type-C ports on rk3399.
Similar to hot-pluggable PCI controllers, the driver for this chip
removes the xhci controller from the system when the Type-C cable is
disconnected.

The solution for PCI devices works just as well for non-PCI devices
and avoids the problem.

Signed-off-by: Guenter Roeck 
---
 drivers/usb/host/xhci-plat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6d33b42ffcf5..bd02a6cd8e2c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -286,6 +286,8 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   xhci->xhc_state |= XHCI_STATE_REMOVING;
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
 
-- 
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi,

On 9 March 2017 at 09:50, Jun Li  wrote:
> Hi,
>
>> -Original Message-
>> From: Baolin Wang [mailto:baolin.w...@linaro.org]
>> Sent: Tuesday, March 07, 2017 5:39 PM
>> To: NeilBrown 
>> Cc: Felipe Balbi ; Greg KH ;
>> Sebastian Reichel ; Dmitry Eremin-Solenikov
>> ; David Woodhouse ;
>> r...@kernel.org; Jun Li ; Marek Szyprowski
>> ; Ruslan Bilovol ;
>> Peter Chen ; Alan Stern
>> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
>> ; Lee Jones ;
>> Mark Brown ; John Stultz ;
>> Charles Keepax ;
>> patc...@opensource.wolfsonmicro.com; Linux PM list > p...@vger.kernel.org>; USB ; device-
>> mainlin...@lists.linuxfoundation.org; LKML 
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 3 March 2017 at 10:23, NeilBrown  wrote:
>> > On Mon, Feb 20 2017, Baolin Wang wrote:
>> >
>> >> Currently the Linux kernel does not provide any standard integration
>> >> of this feature that integrates the USB subsystem with the system
>> >> power regulation provided by PMICs meaning that either vendors must
>> >> add this in their kernels or USB gadget devices based on Linux (such
>> >> as mobile phones) may not behave as they should. Thus provide a
>> standard framework for doing this in kernel.
>> >>
>> >> Now introduce one user with wm831x_power to support and test the usb
>> charger.
>> >> Another user introduced to support charger detection by Jun Li:
>> >> https://www.spinics.net/lists/linux-usb/msg139425.html
>> >> Moreover there may be other potential users will use it in future.
>> >>
>> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
>> >> and usb phy driver, now all were merged. (Thanks for Neil's
>> >> suggestion)
>> >> (1) Have fixed the inconsistencies with USB connector types in extcon
>> >> subsystem by following links:
>> >> https://lkml.org/lkml/2016/12/21/13
>> >> https://lkml.org/lkml/2016/12/21/15
>> >> https://lkml.org/lkml/2016/12/21/79
>> >> https://lkml.org/lkml/2017/1/3/13
>> >>
>> >> (2) Instead of using 'set_power' callback in phy drivers, we will
>> >> introduce USB charger to set PMIC current drawn from USB
>> >> configuration, moreover some 'set_power' callbacks did not implement
>> >> anything to set PMIC current, thus remove them by following links:
>> >> https://lkml.org/lkml/2017/1/18/436
>> >> https://lkml.org/lkml/2017/1/18/439
>> >> https://lkml.org/lkml/2017/1/18/438
>> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
>> >> still used 'set_power' callback to set current, we can remove them in
>> >> future. (I have no platform with enabling these two phy drivers, so I
>> >> can not test them if I converted 'set_power' callback to USB
>> >> charger.)
>> >>
>> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
>> >> patchset, and I expalined each issue and may be need discuss again:
>> >> (1) Change all usb phys to register an extcon and to send appropriate
>> notifications.
>> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
>> >> phy-omap-otg.c and
>> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
>> >> change all usb phys to register an extcon, since there are no extcon
>> >> device to register for these different phy drivers.
>> >
>> > You don't have to change every driver.  You just need to make it easy
>> > and obvious how to change drivers in a consistent coherent way.
>> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
>> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
>> > send notification on that extcon (if it is non-NULL).
>> > e.g. usb_phy_vbus_on() could send an extcon notification.
>> >
>> > Then any phy driver which adds support for setting phy->extcon_dev
>> > appropriately, immediately gets the relevant notifications sent.
>>
>> OK. We can make these extcon related code into phy common part.
>>
>
> Will generic phy need add extcon as well?

Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
be common code.

>
>> >
>> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
>> >> register an extcon, but also for the drivers which can detect USB
>> >> charger type, it may be USB controller driver, USB type-c driver,
>> >> pmic driver, and these drivers may not have an extcon device since
>> >> the internal part can finish the vbus detect.
>> >
>> > Whichever part can detect vbus, the driver for that part must be able
>> > to find the extcon and trigger a 

Re: [PATCH] lvs: fix race condition in disconnect handling

[Greg KH]

On Mon, Feb 20, 2017 at 03:38:42PM +0100, Oliver Neukum wrote:
> There is a small window during which the an URB may
> remain active after disconnect has returned. If in that case
> already freed memory may be accessed and executed.
> 
> The fix is to poison the URB befotre the work is flushed.
> 
> Signed-off-by: Oliver Neukum 
> ---
>  drivers/usb/misc/lvstest.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
> index 7717651..e5d2500 100644
> --- a/drivers/usb/misc/lvstest.c
> +++ b/drivers/usb/misc/lvstest.c
> @@ -429,6 +429,8 @@ static void lvs_rh_disconnect(struct usb_interface *intf)
>   struct lvs_rh *lvs = usb_get_intfdata(intf);
>  
>   sysfs_remove_group(>dev.kobj, _attr_group);
> + usb_poison_urb(lvs->urb); /* used in scheduled work */
> + (lvs->urb);

Is that second line really needed?

--
To unsubscribe from this list: send the line "unsubscribe 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: [solution] usb: gadget: uvc: configfs: fails to enumerate in HOST

[Petr Cvek]

Dne 8.3.2017 v 11:46 Ganesh Biradar napsal(a):
> Hi Petr,
> 
> I saw your patch and at the same time I saw Laurent suggestion.
> 
> I have tried both patches both are working but I'm going with Laurent 
> suggestion
> 
> UVC_ATTR(f_uvc_opts_, cname, cname).
> 

That's OK, they are equivalent (as I explained in my reply to Laurent 
suggestion).

> I'm going with unofficial uvc-gadget.
> 
> Before I can test usb uvc gadget  not enumerating.

And there was recently reverted patch [1]. But if you are really using 4.4 then 
it should be fine with you.

[1] https://www.spinics.net/lists/linux-usb/msg154179.html

> 
> Regards,
> Ganesh Biradar
> 

Cheers,
Petr

--
To unsubscribe from this list: send the line "unsubscribe 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: hub: Fix error loop seen after hub communication errors

[Guenter Roeck]

While stress testing a usb controller using a bind/unbind looop, the
following error loop was observed.

usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
usb 7-1.2: hub failed to enable device, error -108
usb 7-1-port2: cannot disable (err = -22)
usb 7-1-port2: couldn't allocate usb_device
usb 7-1-port2: cannot disable (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = 
-22)

This continues forever. After adding tracebacks into the code,
the call sequence leading to this is found to be as follows.

[] hub_activate+0x368/0x7b8
[] hub_resume+0x2c/0x3c
[] usb_resume_interface.isra.6+0x128/0x158
[] usb_suspend_both+0x1e8/0x288
[] usb_runtime_suspend+0x3c/0x98
[] __rpm_callback+0x48/0x7c
[] rpm_callback+0xa8/0xd4
[] rpm_suspend+0x84/0x758
[] rpm_idle+0x2c8/0x498
[] __pm_runtime_idle+0x60/0xac
[] usb_autopm_put_interface+0x6c/0x7c
[] hub_event+0x10ac/0x12ac
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40

kick_hub_wq() is called from hub_activate() even after failures to
communicate with the hub. This results in an endless sequence of
hub event -> hub activate -> wq trigger -> hub event -> ...
To break the loop, only trigger the hub event queue if communication
with the hub is successful.

Signed-off-by: Guenter Roeck 
---
 drivers/usb/core/hub.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5286bf67869a..f22ab428b310 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1197,7 +1197,8 @@ static void hub_activate(struct usb_hub *hub, enum 
hub_activation_type type)
>leds, LED_CYCLE_PERIOD);
 
/* Scan all ports that need attention */
-   kick_hub_wq(hub);
+   if (!status)
+   kick_hub_wq(hub);
 
if (type == HUB_INIT2 || type == HUB_INIT3) {
/* Allow autosuspend if it was suppressed */
-- 
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 v17 2/3] usb: USB Type-C connector class

[Peter Chen]

On Wed, Mar 08, 2017 at 06:44:47AM -0800, Guenter Roeck wrote:
> On 03/07/2017 10:50 PM, Peter Chen wrote:
> >
> You mean type-C trigger an ACPI event, and this ACPI event can notify
> related USB controller driver doing role switch?
> >>>
> >>>No (firmware programs the dual-role hw/registers), but never mind.
> >>>That could be the case.
> >>>
> If it is correct, there is a notifier between type-C and USB
> controller driver, how to define this notifier for non-ACPI platform?
> >>>
> >>>Once there is a platform with Type-C like that, the problem needs to
> >>>be solved. However..
> >>>
> >I'm not commenting on Roger's dual role patch series, but I don't
> >really think it should be mixed with Type-C. USB Type-C and USB
> >Power Delivery define their own ways of handling the roles, and they
> >are not limited to the data role only. Things like OTG for example
> >will, and actually can not be supported. With Type-C we will have
> >competing state machines compared to OTG. The dual-role framework
> >may be useful on systems that provide more traditional connectors,
> >which possibly have the ID-pin like micro-AB, and possibly also
> >support OTG. It can also be something that exist in parallel with the 
> >Type-C
> >>class, but there just can not be any dependencies between the two.
> >
> 
> Yes, there are two independent things. But if the kernel doesn't have
> a notifier between type-C message sender (type-c class) and message
> receiver (like USB controller driver for role switch or other drivers
> for alternate mode message), we had to find some ways at userspace.
> >>>
> >>>..what ever the solution is, it really can't rely on user space.
> >>>
> >>
> >>... and, at least for our application, using extcon for the necessary 
> >>notifications works
> >>just fine.
> >>
> >
> >I see, that means you have a hardware signal to notify role switch.
> >
> 
> In our case the Type-C protocol manager (including alternate mode handling)
> is implemented in an EC. The EC signals the extcon-cros_ec driver, which
> in turn signals the phy driver as well as the DP driver. The Type-C class
> is orthogonal; extcon-cros_ec will also register with the Type-C class code
> once that is upstream.
> 
> As mentioned earlier, using extcon for signaling was the most convenient means
> for us to pass events around. I am more than open to change it to a bus,
> if that can be made to work - we'd have to keep in mind though that this code
> already works without Type-C infrastructure and is for the most part already
> upstream (the rk3399 code it ties into is upstream, and extcon-cros_ec has 
> been
> submitted as https://patchwork.kernel.org/patch/9583045/).
> 

I am clear your implementation now, thank, Guenter.

> As for to how to handle alternate mode if the Type-C protocol manager
> (TCPM) is implemented in the kernel - I have not yet implemented it yet,
> but my thinking goes along the line described by Heikki in his last e-mail.
> 
> Note that we also have a kernel driver for FUSB302 which ties into my tcpm
> driver. I'll have to check if that is public yet and if I or someone
> else can publish it if there is interest.
> 
> Guenter
> 

-- 

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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Tuesday, March 07, 2017 5:39 PM
> To: NeilBrown 
> Cc: Felipe Balbi ; Greg KH ;
> Sebastian Reichel ; Dmitry Eremin-Solenikov
> ; David Woodhouse ;
> r...@kernel.org; Jun Li ; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 3 March 2017 at 10:23, NeilBrown  wrote:
> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >
> >> Currently the Linux kernel does not provide any standard integration
> >> of this feature that integrates the USB subsystem with the system
> >> power regulation provided by PMICs meaning that either vendors must
> >> add this in their kernels or USB gadget devices based on Linux (such
> >> as mobile phones) may not behave as they should. Thus provide a
> standard framework for doing this in kernel.
> >>
> >> Now introduce one user with wm831x_power to support and test the usb
> charger.
> >> Another user introduced to support charger detection by Jun Li:
> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> Moreover there may be other potential users will use it in future.
> >>
> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
> >> and usb phy driver, now all were merged. (Thanks for Neil's
> >> suggestion)
> >> (1) Have fixed the inconsistencies with USB connector types in extcon
> >> subsystem by following links:
> >> https://lkml.org/lkml/2016/12/21/13
> >> https://lkml.org/lkml/2016/12/21/15
> >> https://lkml.org/lkml/2016/12/21/79
> >> https://lkml.org/lkml/2017/1/3/13
> >>
> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> introduce USB charger to set PMIC current drawn from USB
> >> configuration, moreover some 'set_power' callbacks did not implement
> >> anything to set PMIC current, thus remove them by following links:
> >> https://lkml.org/lkml/2017/1/18/436
> >> https://lkml.org/lkml/2017/1/18/439
> >> https://lkml.org/lkml/2017/1/18/438
> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
> >> still used 'set_power' callback to set current, we can remove them in
> >> future. (I have no platform with enabling these two phy drivers, so I
> >> can not test them if I converted 'set_power' callback to USB
> >> charger.)
> >>
> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> patchset, and I expalined each issue and may be need discuss again:
> >> (1) Change all usb phys to register an extcon and to send appropriate
> notifications.
> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> phy-omap-otg.c and
> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> change all usb phys to register an extcon, since there are no extcon
> >> device to register for these different phy drivers.
> >
> > You don't have to change every driver.  You just need to make it easy
> > and obvious how to change drivers in a consistent coherent way.
> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
> > send notification on that extcon (if it is non-NULL).
> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >
> > Then any phy driver which adds support for setting phy->extcon_dev
> > appropriately, immediately gets the relevant notifications sent.
> 
> OK. We can make these extcon related code into phy common part.
>   

Will generic phy need add extcon as well?

> >
> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
> >> register an extcon, but also for the drivers which can detect USB
> >> charger type, it may be USB controller driver, USB type-c driver,
> >> pmic driver, and these drivers may not have an extcon device since
> >> the internal part can finish the vbus detect.
> >
> > Whichever part can detect vbus, the driver for that part must be able
> > to find the extcon and trigger a notification.
> > Maybe one part can detect VBUS, another can measure the resistance on
> > ID and a third can work through the state machine to determine if D+
> > and D- are shorted together.
> > Somehow these three need to work together to 

[PATCH] e-mail update in drivers/usb/storage/unusual_devs.h

[Phillip Potter]

Updates the e-mail address of Phillip Potter, updater of the Nokia 6288 entry in
drivers/usb/storage/unusual_devs.h

Signed-off-by: Phillip Potter 
---
--- a/drivers/usb/storage/unusual_devs.h2017-03-08 21:47:45.878007300 
+
+++ b/drivers/usb/storage/unusual_devs.h2017-03-08 22:05:53.659147400 
+
@@ -176,7 +176,7 @@ UNUSUAL_DEV(  0x0420, 0x0001, 0x0100, 0x

 /*
  * Reported by Andrew Nayenko 
- * Updated for new firmware by Phillip Potter 
+ * Updated for new firmware by Phillip Potter 
  */
 UNUSUAL_DEV(  0x0421, 0x0019, 0x0592, 0x0610,
"Nokia",
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 04/19] net: e100: Replace PCI pool old API

[Jeff Kirsher]

On Wed, 2017-03-08 at 17:19 +0100, Romain Perier wrote:
> The PCI pool API is deprecated. This commit replaces the PCI pool old
> API by the appropriate function with the DMA pool API.
> 
> Signed-off-by: Romain Perier 
> Acked-by: Peter Senna Tschudin 
> Tested-by: Peter Senna Tschudin 
> ---
>  drivers/net/ethernet/intel/e100.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Acked-by: Jeff Kirsher 

My only concern is:
- what hardware did this get tested with?  Since this affects all e100
parts, it would be hard to believe that all the affected hardware was
used in testing.

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

Re: [PATCH] e-mail address change in drivers/usb/storage/unusual_devs.h

[Phillip Potter]

Dear Alan,

Apologies. I will make the necessary changes and resubmit.

Regards,
Phil Potter

On 08/03/2017 20:04, Alan Stern wrote:

On Wed, 8 Mar 2017, Phillip Potter wrote:


Dear all,

Just submitting a very minor patch to update my e-mail address in this file - I 
sent
a patch years ago to update the listed firmware version to make newer versions 
of the
Nokia 6288 mountable as mass storage devices. I hope my patch is in the right 
format,
I've tried to pay attention to the docs - sorry if not. Thanks.

Regards,
Phil Potter


The format isn't quite right.  Remember, whatever you put at the start
of the email will be part of the permanent log, so it shouldn't be in
the form of a normal mail message -- it should be in the form of a
Changelog entry.  Look at some of the other patch submissions in the
mailing list archives to get an idea.



Signed-off-by: Phillip Potter 


There needs to be a line containing nothing but --- here, to separate
the ChangeLog entry from the patch itself.

For more details, see Documentation/submitting-patches.txt.  Also,
patches for the usb-storage driver should be CC'ed to Greg KH
.

Alan Stern


--- a/drivers/usb/storage/unusual_devs.h2017-03-07 18:05:22.674952200 
+
+++ b/drivers/usb/storage/unusual_devs.h2017-03-07 18:17:26.37417 
+
@@ -176,7 +176,7 @@ UNUSUAL_DEV(  0x0420, 0x0001, 0x0100, 0x

  /*
   * Reported by Andrew Nayenko 
- * Updated for new firmware by Phillip Potter 
+ * Updated for new firmware by Phillip Potter 
   */
  UNUSUAL_DEV(  0x0421, 0x0019, 0x0592, 0x0610,
 "Nokia",






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

Requeste to add Quectel EC21 in USB:serial:qcserial

[Balazs Harmath]

Hi guys,

I’w working with a Quectel EC21 modem and i ran into an issue that the qcserial 
driver is not getting installed for it. 
Previously i was working with the Quectel EC20 which was working properly but 
the cell carrier requested LTE Cat 1 modem so that’s why the switch to EC21.

Can you add the product ID for the Quectel EC21 in the qcserial.c ?

Thanks,
Bali

Below info for Quectel EC21

root@raspberrypi:~# uname -a
Linux raspberrypi 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l 
GNU/Linux


output for dmesg:

[7.575835] usb 1-1.4: new high-speed USB device number 7 using dwc_otg
[7.715808] usb 1-1.4: New USB device found, idVendor=2c7c, idProduct=0121
[7.715819] usb 1-1.4: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[7.715824] usb 1-1.4: Product: Android
[7.715827] usb 1-1.4: Manufacturer: Android
[7.728580] usbcore: registered new interface driver cdc_wdm
[7.735897] qmi_wwan 1-1.4:1.4: cdc-wdm0: USB WDM device
[7.737829] qmi_wwan 1-1.4:1.4 wwan0: register 'qmi_wwan' at 
usb-3f98.usb-1.4, WWAN/QMI device, ce:db:66:0e:df:26

output for lsusb -t:

root@raspberrypi:~# lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, 
Driver=smsc95xx, 480M
|__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 
12M
|__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 4: Dev 7, If 1, Class=Vendor Specific Class, Driver=, 480M
|__ Port 4: Dev 7, If 4, Class=Vendor Specific Class, Driver=qmi_wwan, 
480M
|__ Port 4: Dev 7, If 2, Class=Vendor Specific Class, Driver=, 480M
|__ Port 4: Dev 7, If 0, Class=Vendor Specific Class, Driver=, 480M
|__ Port 4: Dev 7, If 3, Class=Vendor Specific Class, Driver=, 480M

output for lsmod:

root@raspberrypi:~# lsmod
Module  Size  Used by
qmi_wwan   13643  0 
cdc_wdm12196  1 qmi_wwan
cfg80211  542899  0 
rfkill 20851  1 cfg80211
sg 20761  0 
mcp251x10203  0 
can_dev13682  1 mcp251x
ftdi_sio   32899  0 
usbserial  29943  1 ftdi_sio
i2c_bcm2835 7081  0 
spi_bcm2835 7596  0 
bcm2835_gpiomem 3940  0 
uio_pdrv_genirq 3923  0 
fixed   3285  0 
uio10204  1 uio_pdrv_genirq
rtc_ds1307 13908  0 
hwmon  10552  1 rtc_ds1307
i2c_dev 6913  0 
i2c_bcm2708 5994  0 
fuse   99603  1 
ipv6  406215  38 



lsusb -v on EC21:

root@raspberrypi:~# lsusb -v

Bus 001 Device 007: ID 2c7c:0121  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x2c7c 
  idProduct  0x0121 
  bcdDevice3.18
  iManufacturer   1 (error)
  iProduct2 (error)
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  209
bNumInterfaces  5
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints  

Re: [PATCH 1/3] usb: orion-echi: Add support for the Armada 3700

[Thomas Petazzoni]

Hello,

On Wed,  8 Mar 2017 17:24:21 +0100, Gregory CLEMENT wrote:

> Signed-off-by: jinghua 

I think you need a full first name + last name for this Signed-off-by.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Diego Viola]

Hi Greg,

On Wed, Mar 8, 2017 at 5:15 PM, Greg KH  wrote:
> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote:
>> It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS,
>> it works fine with ehci_hcd or USB 2.0.
>>
>> The way I reproduce the problem is with this command:
>>
>> $ i3lock && systemctl suspend
>>
>> This is what I see on the screen when it hangs:
>>
>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg
>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg
>>
>> Some logs:
>>
>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt
>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt
>>
>> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH.
>>
>> I also tried Linux 4.10.1 and I could reproduce this problem there as well.
>>
>> Please let me know if I could provide more info.
>
> Has any previous kernel ever worked properly before?  If so, any chance
> you can use 'git bisect' to find the offending commit?

I'm not sure, this is my work machine and I've only started using it
recently (since about a month ago or so).

I will try older kernels and see if I get any different results, I
will report back in any case.

>
> And are you sure you have updated your bios to the latest version?

Yes.

>
> thanks,
>
> greg k-h

Thanks,
Diego
--
To unsubscribe from this list: send the line "unsubscribe 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: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Greg KH]

On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote:
> It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS,
> it works fine with ehci_hcd or USB 2.0.
> 
> The way I reproduce the problem is with this command:
> 
> $ i3lock && systemctl suspend
> 
> This is what I see on the screen when it hangs:
> 
> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg
> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg
> 
> Some logs:
> 
> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt
> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt
> 
> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH.
> 
> I also tried Linux 4.10.1 and I could reproduce this problem there as well.
> 
> Please let me know if I could provide more info.

Has any previous kernel ever worked properly before?  If so, any chance
you can use 'git bisect' to find the offending commit?

And are you sure you have updated your bios to the latest version?

thanks,

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

Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Diego Viola]

On Wed, Mar 8, 2017 at 3:49 PM, Diego Viola  wrote:
> It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS,
> it works fine with ehci_hcd or USB 2.0.
>
> The way I reproduce the problem is with this command:
>
> $ i3lock && systemctl suspend
>
> This is what I see on the screen when it hangs:
>
> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg
> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg
>
> Some logs:
>
> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt
> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt
>
> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH.
>
> I also tried Linux 4.10.1 and I could reproduce this problem there as well.
>
> Please let me know if I could provide more info.
>
> Thanks,
> Diego

I've created a bug report here.

https://bugzilla.kernel.org/show_bug.cgi?id=194819

Diego
--
To unsubscribe from this list: send the line "unsubscribe 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] e-mail address change in drivers/usb/storage/unusual_devs.h

[Alan Stern]

On Wed, 8 Mar 2017, Phillip Potter wrote:

> Dear all,
> 
> Just submitting a very minor patch to update my e-mail address in this file - 
> I sent
> a patch years ago to update the listed firmware version to make newer 
> versions of the
> Nokia 6288 mountable as mass storage devices. I hope my patch is in the right 
> format,
> I've tried to pay attention to the docs - sorry if not. Thanks.
> 
> Regards,
> Phil Potter

The format isn't quite right.  Remember, whatever you put at the start
of the email will be part of the permanent log, so it shouldn't be in
the form of a normal mail message -- it should be in the form of a
Changelog entry.  Look at some of the other patch submissions in the
mailing list archives to get an idea.

> 
> Signed-off-by: Phillip Potter 

There needs to be a line containing nothing but --- here, to separate 
the ChangeLog entry from the patch itself.

For more details, see Documentation/submitting-patches.txt.  Also, 
patches for the usb-storage driver should be CC'ed to Greg KH 
.

Alan Stern

> --- a/drivers/usb/storage/unusual_devs.h2017-03-07 18:05:22.674952200 
> +
> +++ b/drivers/usb/storage/unusual_devs.h2017-03-07 18:17:26.37417 
> +
> @@ -176,7 +176,7 @@ UNUSUAL_DEV(  0x0420, 0x0001, 0x0100, 0x
> 
>   /*
>* Reported by Andrew Nayenko 
> - * Updated for new firmware by Phillip Potter 
> + * Updated for new firmware by Phillip Potter 
>*/
>   UNUSUAL_DEV(  0x0421, 0x0019, 0x0592, 0x0610,
>  "Nokia",
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe 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: gadget: uvc: configfs: fails to enumerate in HOST

[Ganesh Biradar]

Hi Felipe,

I'm using TI latest vision sdk which has support for 4.4 kernel. i'm
not getting much help from TI e2e that's why i am asking here. can't
try v4.10 or any other kernel as it has dependencies with respect to
SDK.

regards,
grbesd1

On Wed, Mar 8, 2017 at 2:54 PM, Felipe Balbi
 wrote:
>
> Hi,
>
> Ganesh Biradar  writes:
>> Hello experts,
>>
>> I'm working on a project which uses TI OMAP Plus platform. i'm trying
>> to implement uvc gadget through configfs.
>>
>> kernel: 4.4
>
> please try v4.10 or v4.11-rc1, or ask for support through TI's support
> channel ;-)
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb: gadget: uvc: configfs: fails to enumerate in HOST

[Bin Liu]

On Wed, Mar 08, 2017 at 11:24:16PM +0530, Ganesh Biradar wrote:
> Hi Bin,
> 
> Just wanted to clarify,
> 
> I have created already a thread(more then 2 weeks ago) which was
> based on dual configuration support(mass storage and uvc
> device(g_webcam)). in which i asked question based on 3.14 kernel
> but confgifs support for uvc was added in 4.0 kernel. so i updated
> to latest 4.4 kernel. regarding configfs support i have asked last
> week, as today i got response from e2e expert that they have not

Okay, I am not familiar with the SoC you use and don't know which TI
business unit supports this device. 

> tested uvc for the sdk. It was TI e2e guys suggested to raise
> question on configfs in linux community.

The linux community can only support you if you can reproduce the issue
with the latest mainline kernel.

> 
> Regarding the post you mention that i have created is second thread
> in TI e2e linux community dedicated to configfs. first thread is in
> dedicated TI SOC forum.

Okay I only noticed your e2e post on TI linux community which I
subscribed, not the one on the SoC forum.

> 
> Regarding TI E2E, they provided good help i never deny that. but i
> was looking for some insightful from linux-usb community members
> just to reason out what could be the issue.
> 
> regarding uvc-gadget application, i have run that too but i have not
> got anything at HOST side.

If you proved other gadget works, likely you don't have any hardware
problems, this could be software issue. But I cannot comment much since
I am not familiar with this SoC and the SDK/kernel you use, here are
some of my pointers.

- Try with g_webcam.ko driver instead configfs to see it makes any
  difference, I personally haven't tried configfs for webcam gadget yet;
- Use scope to probe the DP/DM for the pullup to ensure the device
  notifies for the attach;
- Finally debug the dwc3 gadget driver to see where the enumeration
  failed.

Good luck,
-Bin.

> 
> 
> On Wednesday 08 March 2017 07:33 PM, Bin Liu wrote:
> >On Wed, Mar 08, 2017 at 01:59:50PM +0200, Felipe Balbi wrote:
> >>Hi,
> >>
> >>(no top-posting, please)
> >>
> >>Ganesh Biradar  writes:
> >>>Hi Felipe,
> >>>
> >>>I'm using TI latest vision sdk which has support for 4.4 kernel. i'm
> >>>not getting much help from TI e2e that's why i am asking here. can't
> >I don't think it is fair, you posted on TI e2e a few hours after started this
> >thread, then complain not getting much help from TI e2e at here?
> >
> >But anyway, after all your configfs steps, have you run a userspace
> >application, such as uvc-gadget [1], to feed the video stream?
> >
> >[1] git://git.ideasonboard.org/uvc-gadget.git
> >
> >Regards,
> >-Bin.
> >
> >>>try v4.10 or any other kernel as it has dependencies with respect to
> >>>SDK.
> >>sorry, but you need to ask TI for help.
> >>
> >>-- 
> >>balbi
> >
> regards,
> Ganesh
--
To unsubscribe from this list: send the line "unsubscribe 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: gadget: uvc: configfs: fails to enumerate in HOST

[Ganesh Biradar]

Hi Bin,

Just wanted to clarify,

I have created already a thread(more then 2 weeks ago) which was based 
on dual configuration support(mass storage and uvc device(g_webcam)). in 
which i asked question based on 3.14 kernel but confgifs support for uvc 
was added in 4.0 kernel. so i updated to latest 4.4 kernel. regarding 
configfs support i have asked last week, as today i got response from 
e2e expert that they have not tested uvc for the sdk. It was TI e2e guys 
suggested to raise question on configfs in linux community.


Regarding the post you mention that i have created is second thread in 
TI e2e linux community dedicated to configfs. first thread is in 
dedicated TI SOC forum.


Regarding TI E2E, they provided good help i never deny that. but i was 
looking for some insightful from linux-usb community members just to 
reason out what could be the issue.


regarding uvc-gadget application, i have run that too but i have not got 
anything at HOST side.



On Wednesday 08 March 2017 07:33 PM, Bin Liu wrote:

On Wed, Mar 08, 2017 at 01:59:50PM +0200, Felipe Balbi wrote:

Hi,

(no top-posting, please)

Ganesh Biradar  writes:

Hi Felipe,

I'm using TI latest vision sdk which has support for 4.4 kernel. i'm
not getting much help from TI e2e that's why i am asking here. can't

I don't think it is fair, you posted on TI e2e a few hours after started this
thread, then complain not getting much help from TI e2e at here?

But anyway, after all your configfs steps, have you run a userspace
application, such as uvc-gadget [1], to feed the video stream?

[1] git://git.ideasonboard.org/uvc-gadget.git

Regards,
-Bin.


try v4.10 or any other kernel as it has dependencies with respect to
SDK.

sorry, but you need to ask TI for help.

--
balbi



regards,
Ganesh
--
To unsubscribe from this list: send the line "unsubscribe 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: hub: Fix crash after failure to read BOS descriptor

[Guenter Roeck]

If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
Nevertheless, it is dereferenced unconditionally in
hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
This results in a crash.

usb 5-1: unable to get BOS descriptor
...
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = ffc00165f000
[0008] *pgd=0174f003, *pud=0174f003,
*pmd=01750003, *pte=00e801751713
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: GB 4.4.52 #480
Hardware name: Google Kevin (DT)
Workqueue: events driver_set_config_work
task: ffc0c369 ti: ffc0ae9a8000 task.ti: ffc0ae9a8000
PC is at hub_port_init+0xc3c/0xd10
LR is at hub_port_init+0xc3c/0xd10
...
Call trace:
[] hub_port_init+0xc3c/0xd10
[] usb_reset_and_verify_device+0x15c/0x82c
[] usb_reset_device+0xe4/0x298
[] rtl8152_probe+0x84/0x9b0 [r8152]
[] usb_probe_interface+0x244/0x2f8
[] driver_probe_device+0x180/0x3b4
[] __device_attach_driver+0xb4/0xe0
[] bus_for_each_drv+0xb4/0xe4
[] __device_attach+0xd0/0x158
[] device_initial_probe+0x24/0x30
[] bus_probe_device+0x50/0xe4
[] device_add+0x414/0x738
[] usb_set_configuration+0x89c/0x914
[] driver_set_config_work+0xc0/0xf0
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40

Since we don't know anything about LPM capabilities without BOS descriptor,
don't attempt to enable LPM if it is not available.

Fixes: 890dae886721 ("xhci: Enable LPM support only for hardwired ...")
Cc: Mathias Nyman 
Signed-off-by: Guenter Roeck 
---
 drivers/usb/core/hub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f0dd08198d74..5286bf67869a 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4275,7 +4275,7 @@ static void hub_set_initial_usb2_lpm_policy(struct 
usb_device *udev)
struct usb_hub *hub = usb_hub_to_struct_hub(udev->parent);
int connect_type = USB_PORT_CONNECT_TYPE_UNKNOWN;
 
-   if (!udev->usb2_hw_lpm_capable)
+   if (!udev->usb2_hw_lpm_capable || !udev->bos)
return;
 
if (hub)
-- 
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: musb: dsps: fix iounmap in error and exit paths

[Bin Liu]

On Wed, Mar 08, 2017 at 08:02:59PM +0100, Johan Hovold wrote:
> On Wed, Mar 08, 2017 at 10:24:31AM -0600, Bin Liu wrote:
> > Cleanly iounmap the pointer in error and exit paths.
> > 
> > Signed-off-by: Bin Liu 
> > ---
> >  drivers/usb/musb/musb_dsps.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> > index 7c047c4a2565..c84f32d0dd4d 100644
> > --- a/drivers/usb/musb/musb_dsps.c
> > +++ b/drivers/usb/musb/musb_dsps.c
> > @@ -933,7 +933,7 @@ static int dsps_probe(struct platform_device *pdev)
> > if (usb_get_dr_mode(>dev) == USB_DR_MODE_PERIPHERAL) {
> > ret = dsps_setup_optional_vbus_irq(pdev, glue);
> > if (ret)
> > -   return ret;
> > +   goto err1;
> > }
> >  
> > platform_set_drvdata(pdev, glue);
> > @@ -946,6 +946,8 @@ static int dsps_probe(struct platform_device *pdev)
> >  
> >  err:
> > pm_runtime_disable(>dev);
> > +err1:
> 
> I suggest you use
> 
>   err_iounmap:
>   
> here instead (as per the coding standard too).

It's better, thanks.

Regards,
-Bin.

> 
> > +   iounmap(glue->usbss_base);
> > return ret;
> >  }
> 
> 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: musb: dsps: fix iounmap in error and exit paths

[Johan Hovold]

On Wed, Mar 08, 2017 at 10:24:31AM -0600, Bin Liu wrote:
> Cleanly iounmap the pointer in error and exit paths.
> 
> Signed-off-by: Bin Liu 
> ---
>  drivers/usb/musb/musb_dsps.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 7c047c4a2565..c84f32d0dd4d 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -933,7 +933,7 @@ static int dsps_probe(struct platform_device *pdev)
>   if (usb_get_dr_mode(>dev) == USB_DR_MODE_PERIPHERAL) {
>   ret = dsps_setup_optional_vbus_irq(pdev, glue);
>   if (ret)
> - return ret;
> + goto err1;
>   }
>  
>   platform_set_drvdata(pdev, glue);
> @@ -946,6 +946,8 @@ static int dsps_probe(struct platform_device *pdev)
>  
>  err:
>   pm_runtime_disable(>dev);
> +err1:

I suggest you use

err_iounmap:

here instead (as per the coding standard too).

> + iounmap(glue->usbss_base);
>   return ret;
>  }

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

[PATCH] usb: musb: fix possible spinlock deadlock

[Bin Liu]

The DSPS glue calls del_timer_sync() in its musb_platform_disable()
implementation, which requires the caller to not hold a lock. But
musb_remove() calls musb_platform_disable() will musb->lock held. This
could causes spinlock deadlock.

So change musb_remove() to call musb_platform_disable() without holds
musb->lock. This doesn't impact the musb_platform_disable implementation
in other glue drivers.

root@am335x-evm:~# modprobe -r musb-dsps
[  126.134879] musb-hdrc musb-hdrc.1: remove, state 1
[  126.140465] usb usb2: USB disconnect, device number 1
[  126.146178] usb 2-1: USB disconnect, device number 2
[  126.416985] musb-hdrc musb-hdrc.1: USB bus 2 deregistered
[  126.423943]
[  126.425525] ==
[  126.431997] [ INFO: possible circular locking dependency detected ]
[  126.438564] 4.11.0-rc1-3-g1557f13bca04-dirty #77 Not tainted
[  126.444852] ---
[  126.451414] modprobe/778 is trying to acquire lock:
[  126.456523]  (((>timer))){+.-...}, at: [] 
del_timer_sync+0x0/0xd0
[  126.464403]
[  126.464403] but task is already holding lock:
[  126.470511]  (&(>lock)->rlock){-.-...}, at: [] 
musb_remove+0x50/0x1
30 [musb_hdrc]
[  126.479965]
[  126.479965] which lock already depends on the new lock.
[  126.479965]
[  126.488531]
[  126.488531] the existing dependency chain (in reverse order) is:
[  126.496368]
[  126.496368] -> #1 (&(>lock)->rlock){-.-...}:
[  126.502968]otg_timer+0x80/0xec [musb_dsps]
[  126.507990]call_timer_fn+0xb4/0x390
[  126.512372]expire_timers+0xf0/0x1fc
[  126.516754]run_timer_softirq+0x80/0x178
[  126.521511]__do_softirq+0xc4/0x554
[  126.525802]irq_exit+0xe8/0x158
[  126.529735]__handle_domain_irq+0x58/0xb8
[  126.534583]__irq_usr+0x54/0x80
[  126.538507]
[  126.538507] -> #0 (((>timer))){+.-...}:
[  126.544636]del_timer_sync+0x40/0xd0
[  126.549066]musb_remove+0x6c/0x130 [musb_hdrc]
[  126.554370]platform_drv_remove+0x24/0x3c
[  126.559206]device_release_driver_internal+0x14c/0x1e0
[  126.565225]bus_remove_device+0xd8/0x108
[  126.569970]device_del+0x1e4/0x308
[  126.574170]platform_device_del+0x24/0x8c
[  126.579006]platform_device_unregister+0xc/0x20
[  126.584394]dsps_remove+0x14/0x30 [musb_dsps]
[  126.589595]platform_drv_remove+0x24/0x3c
[  126.594432]device_release_driver_internal+0x14c/0x1e0
[  126.600450]driver_detach+0x38/0x6c
[  126.604740]bus_remove_driver+0x4c/0xa0
[  126.609407]SyS_delete_module+0x11c/0x1e4
[  126.614252]__sys_trace_return+0x0/0x10

Fixes: ea2f35c01d5ea ("usb: musb: Fix sleeping function called from invalid 
context for hdrc glue")
Cc:  #4.9+
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index d8bae6ca8904..0c3664ab705e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2490,8 +2490,8 @@ static int musb_remove(struct platform_device *pdev)
musb_host_cleanup(musb);
musb_gadget_cleanup(musb);
 
-   spin_lock_irqsave(>lock, flags);
musb_platform_disable(musb);
+   spin_lock_irqsave(>lock, flags);
musb_disable_interrupts(musb);
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
spin_unlock_irqrestore(>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

Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Diego Viola]

It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS,
it works fine with ehci_hcd or USB 2.0.

The way I reproduce the problem is with this command:

$ i3lock && systemctl suspend

This is what I see on the screen when it hangs:

https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg
https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg

Some logs:

https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt
https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt

I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH.

I also tried Linux 4.10.1 and I could reproduce this problem there as well.

Please let me know if I could provide more info.

Thanks,
Diego
--
To unsubscribe from this list: send the line "unsubscribe 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 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t

[Chris Leech]

On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
> 
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 

This looks OK to me.

Acked-by: Chris Leech 

> ---
>  drivers/scsi/libiscsi.c| 8 
>  drivers/scsi/qedi/qedi_iscsi.c | 2 +-
>  include/scsi/libiscsi.h| 3 ++-
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 834d121..7eb1d2c 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -516,13 +516,13 @@ static void iscsi_free_task(struct iscsi_task *task)
>  
>  void __iscsi_get_task(struct iscsi_task *task)
>  {
> - atomic_inc(>refcount);
> + refcount_inc(>refcount);
>  }
>  EXPORT_SYMBOL_GPL(__iscsi_get_task);
>  
>  void __iscsi_put_task(struct iscsi_task *task)
>  {
> - if (atomic_dec_and_test(>refcount))
> + if (refcount_dec_and_test(>refcount))
>   iscsi_free_task(task);
>  }
>  EXPORT_SYMBOL_GPL(__iscsi_put_task);
> @@ -744,7 +744,7 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
> iscsi_hdr *hdr,
>* released by the lld when it has transmitted the task for
>* pdus we do not expect a response for.
>*/
> - atomic_set(>refcount, 1);
> + refcount_set(>refcount, 1);
>   task->conn = conn;
>   task->sc = NULL;
>   INIT_LIST_HEAD(>running);
> @@ -1616,7 +1616,7 @@ static inline struct iscsi_task 
> *iscsi_alloc_task(struct iscsi_conn *conn,
>   sc->SCp.phase = conn->session->age;
>   sc->SCp.ptr = (char *) task;
>  
> - atomic_set(>refcount, 1);
> + refcount_set(>refcount, 1);
>   task->state = ISCSI_TASK_PENDING;
>   task->conn = conn;
>   task->sc = sc;
> diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
> index b9f79d3..3895bd5 100644
> --- a/drivers/scsi/qedi/qedi_iscsi.c
> +++ b/drivers/scsi/qedi/qedi_iscsi.c
> @@ -1372,7 +1372,7 @@ static void qedi_cleanup_task(struct iscsi_task *task)
>  {
>   if (!task->sc || task->state == ISCSI_TASK_PENDING) {
>   QEDI_INFO(NULL, QEDI_LOG_IO, "Returning ref_cnt=%d\n",
> -   atomic_read(>refcount));
> +   refcount_read(>refcount));
>   return;
>   }
>  
> diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
> index b0e275d..24d74b5 100644
> --- a/include/scsi/libiscsi.h
> +++ b/include/scsi/libiscsi.h
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -139,7 +140,7 @@ struct iscsi_task {
>  
>   /* state set/tested under session->lock */
>   int state;
> - atomic_trefcount;
> + refcount_t  refcount;
>   struct list_headrunning;/* running cmd list */
>   void*dd_data;   /* driver/transport data */
>  };
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: musb: dsps: fix iounmap in error and exit paths

[Bin Liu]

Cleanly iounmap the pointer in error and exit paths.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 7c047c4a2565..c84f32d0dd4d 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -933,7 +933,7 @@ static int dsps_probe(struct platform_device *pdev)
if (usb_get_dr_mode(>dev) == USB_DR_MODE_PERIPHERAL) {
ret = dsps_setup_optional_vbus_irq(pdev, glue);
if (ret)
-   return ret;
+   goto err1;
}
 
platform_set_drvdata(pdev, glue);
@@ -946,6 +946,8 @@ static int dsps_probe(struct platform_device *pdev)
 
 err:
pm_runtime_disable(>dev);
+err1:
+   iounmap(glue->usbss_base);
return ret;
 }
 
@@ -956,6 +958,7 @@ static int dsps_remove(struct platform_device *pdev)
platform_device_unregister(glue->musb);
 
pm_runtime_disable(>dev);
+   iounmap(glue->usbss_base);
 
return 0;
 }
-- 
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: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Tue, Mar 07, 2017 at 04:35:37AM +, Ajay Kaher wrote:
>  
>  
>  
> > On Fri, 3 Mar 2017, Ajay Kaher wrote:
> > 
> > > > usb_class->kref is not accessible outside the file.c
> > > > as usb_class is _static_ inside the file.c and
> > > > pointer of usb_class->kref is not passed anywhere.
> > > > 
> > > > Hence as you wanted, there are no references of usb_class->kref
> > > > other than taken by init_usb_class() and released by 
> > >destroy_usb_class().
> > > 
> > > Verified the code again, I hope my last comments clarifed the things
> > > which came in your mind and helps you to accept the patch :)
> >  
> > Your main point is that usb_class->kref is accessed from only two
> > points, both of which are protected by the new mutex.  This means there
> > is no reason for the value to be a struct kref at all.  You should
> > change it to an int (and change its name).  Leaving it as a kref will
> > make readers wonder why it needs to be updated atomically.
> 
> At many places in Linux kernel, instances of Kref have been used within
> Mutex, SpinLock and don’t have any side effect.
> 
> Making to int and handle (i.e. get/put) it within file.c seems
> not good as we have Kref. Instead, we can have non_atomic version of kref.
> We can discuss about non_atomic kref in another thread, if you are interested.
> 
> > Also, why does destroy_usb_class() have that "if (usb_class) "test? 
> > Isn't it true that usb_class can never be NULL there?
> 
> Removed in Patch v4.
> 
> thanks,
> ajay kaher
>  
>   
> Signed-off-by: Ajay Kaher
>  

Can you resend this in a format that I can apply it in?  I suggest
reading Documentation/SubmittingPatches.  If you have any questions
about the correct format, please let me know.

Also add Alan's ack to it.

thanks,

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

Re: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t

[Boris Ostrovsky]

On 03/08/2017 08:49 AM, Reshetova, Elena wrote:
>> On 03/06/2017 09:21 AM, Elena Reshetova wrote:
>>> refcount_t type and corresponding API should be
>>> used instead of atomic_t when the variable is used as
>>> a reference counter. This allows to avoid accidental
>>> refcounter overflows that might lead to use-after-free
>>> situations.
>>>
>>> Signed-off-by: Elena Reshetova 
>>> Signed-off-by: Hans Liljestrand 
>>> Signed-off-by: Kees Cook 
>>> Signed-off-by: David Windsor 
>>> ---
>>>  drivers/xen/gntdev.c | 11 ++-
>>>  1 file changed, 6 insertions(+), 5 deletions(-)
>> Reviewed-by: Boris Ostrovsky 
> Is there a tree that can take this change? Turns out it is better to 
> propagate changes via separate trees and only leftovers can be taken via 
> Greg's tree.  
>

Sure, we can take it via Xen tree for rc3.

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

Re: [PATCH 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

[Andrew Lunn]

On Wed, Mar 08, 2017 at 05:24:22PM +0100, Gregory CLEMENT wrote:
> The mvebu ARM64 SoCs no more select PLAT_ORION but some of them as the
> Armada 37xx use the EHCI orion controller. This patch allow to build
> the driver when ARCH_MVEBU is selected.

The mvebu ARM64 SoCs no longer selects PLAT_ORION.  However Armada
37xx use the Orion EHCI controller. This patch allows the Orion EHCI
driver to be built when ARCH_MVEBU is selected.

> Signed-off-by: Gregory CLEMENT 
> ---
>  drivers/usb/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 407d947b34ea..870c42d89298 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -188,7 +188,7 @@ config USB_EHCI_HCD_OMAP
>  
>  config USB_EHCI_HCD_ORION
>   tristate  "Support for Marvell EBU on-chip EHCI USB controller"
> - depends on USB_EHCI_HCD && PLAT_ORION
> + depends on USB_EHCI_HCD && PLAT_ORION || ARCH_MVEBU

I don't know the Kconfig language too well. Should this be:

> + depends on USB_EHCI_HCD && (PLAT_ORION || ARCH_MVEBU)

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

Re: [PATCH 1/3] usb: orion-echi: Add support for the Armada 3700

[Andrew Lunn]

Hi Gregory

> - Add a new compatoble string for the Armada 3700 SoCs

compatible

> 
> - add sbuscfg support for orion usb controller driver. For the SoCs
>   without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
>   register to guarantee the AHB master's burst would not overrun or
>   underrun the FIFO.
> 
> - the sbuscfg register has to be set after the usb controller reset,
>   otherwise the value would be overridden to 0. In order to do this, the
>   reset callback is registered.
> 
> [gregory.clem...@free-electrons.com: - reword commit and comments
>- fix checkpatch warning]
> Signed-off-by: jinghua 
> Signed-off-by: Gregory CLEMENT 
> ---
>  .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
>  drivers/usb/host/ehci-orion.c  | 39 
> ++
>  2 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt 
> b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> index 17c3bc858b86..9dfffc9dffec 100644
> --- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
> +++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> @@ -1,7 +1,9 @@
>  * EHCI controller, Orion Marvell variants
>  
>  Required properties:
> -- compatible: must be "marvell,orion-ehci"
> +- compatible: could be one of the following

must, not could.

> + "marvell,orion-ehci"
> + "marvell,armada-3700-ehci"
>  - reg: physical base address of the controller and length of memory mapped
>region.
>  - interrupts: The EHCI interrupt
> diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> index ee8d5faa0194..cf778e166b90 100644
> --- a/drivers/usb/host/ehci-orion.c
> +++ b/drivers/usb/host/ehci-orion.c
> @@ -47,6 +47,21 @@
>  #define USB_PHY_IVREF_CTRL   0x440
>  #define USB_PHY_TST_GRP_CTRL 0x450
>  
> +#define USB_SBUSCFG  0x90
> +#define  USB_SBUSCFG_BAWR0x6
> +#define  USB_SBUSCFG_BARD0x3
> +#define  USB_SBUSCFG_AHBBRST 0x0

These three are all shifts. So i would suggest adding _SHIFT to the
end.

> +
> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
> +#define USB_SBUSCFG_BAWR_ALIGN_128B  0x3
> +#define USB_SBUSCFG_BARD_ALIGN_128B  0x3
> +/* AHBBRST = 3  : Align AHB Burst to INCR16 (64 bytes) */
> +#define USB_SBUSCFG_AHBBRST_INCR16   0x3

You can then apply the shift here.

> +
> +#define USB_SBUSCFG_DEF_VAL ((USB_SBUSCFG_BAWR_ALIGN_128B << 
> USB_SBUSCFG_BAWR) \
> +  | (USB_SBUSCFG_BARD_ALIGN_128B << USB_SBUSCFG_BARD) \
> +  | (USB_SBUSCFG_AHBBRST_INCR16 << USB_SBUSCFG_AHBBRST))

and this is then shorted.

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

Re: [PATCH] usb: musb: fix possible spinlock deadlock

[Tony Lindgren]

* Bin Liu  [170308 08:26]:
> The DSPS glue calls del_timer_sync() in its musb_platform_disable()
> implementation, which requires the caller to not hold a lock. But
> musb_remove() calls musb_platform_disable() will musb->lock held. This
> could causes spinlock deadlock.
> 
> So change musb_remove() to call musb_platform_disable() without holds
> musb->lock. This doesn't impact the musb_platform_disable implementation
> in other glue drivers.
> 
> root@am335x-evm:~# modprobe -r musb-dsps
> [  126.134879] musb-hdrc musb-hdrc.1: remove, state 1
> [  126.140465] usb usb2: USB disconnect, device number 1
> [  126.146178] usb 2-1: USB disconnect, device number 2
> [  126.416985] musb-hdrc musb-hdrc.1: USB bus 2 deregistered
> [  126.423943]
> [  126.425525] ==
> [  126.431997] [ INFO: possible circular locking dependency detected ]
> [  126.438564] 4.11.0-rc1-3-g1557f13bca04-dirty #77 Not tainted
> [  126.444852] ---
> [  126.451414] modprobe/778 is trying to acquire lock:
> [  126.456523]  (((>timer))){+.-...}, at: [] 
> del_timer_sync+0x0/0xd0
> [  126.464403]
> [  126.464403] but task is already holding lock:
> [  126.470511]  (&(>lock)->rlock){-.-...}, at: [] 
> musb_remove+0x50/0x1
> 30 [musb_hdrc]
> [  126.479965]
> [  126.479965] which lock already depends on the new lock.
> [  126.479965]
> [  126.488531]
> [  126.488531] the existing dependency chain (in reverse order) is:
> [  126.496368]
> [  126.496368] -> #1 (&(>lock)->rlock){-.-...}:
> [  126.502968]otg_timer+0x80/0xec [musb_dsps]
> [  126.507990]call_timer_fn+0xb4/0x390
> [  126.512372]expire_timers+0xf0/0x1fc
> [  126.516754]run_timer_softirq+0x80/0x178
> [  126.521511]__do_softirq+0xc4/0x554
> [  126.525802]irq_exit+0xe8/0x158
> [  126.529735]__handle_domain_irq+0x58/0xb8
> [  126.534583]__irq_usr+0x54/0x80
> [  126.538507]
> [  126.538507] -> #0 (((>timer))){+.-...}:
> [  126.544636]del_timer_sync+0x40/0xd0
> [  126.549066]musb_remove+0x6c/0x130 [musb_hdrc]
> [  126.554370]platform_drv_remove+0x24/0x3c
> [  126.559206]device_release_driver_internal+0x14c/0x1e0
> [  126.565225]bus_remove_device+0xd8/0x108
> [  126.569970]device_del+0x1e4/0x308
> [  126.574170]platform_device_del+0x24/0x8c
> [  126.579006]platform_device_unregister+0xc/0x20
> [  126.584394]dsps_remove+0x14/0x30 [musb_dsps]
> [  126.589595]platform_drv_remove+0x24/0x3c
> [  126.594432]device_release_driver_internal+0x14c/0x1e0
> [  126.600450]driver_detach+0x38/0x6c
> [  126.604740]bus_remove_driver+0x4c/0xa0
> [  126.609407]SyS_delete_module+0x11c/0x1e4
> [  126.614252]__sys_trace_return+0x0/0x10
> 
> Fixes: ea2f35c01d5ea ("usb: musb: Fix sleeping function called from invalid 
> context for hdrc glue")
> Cc:  #4.9+
> Signed-off-by: Bin Liu 

Acked-by: Tony Lindgren 

> ---
>  drivers/usb/musb/musb_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index d8bae6ca8904..0c3664ab705e 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -2490,8 +2490,8 @@ static int musb_remove(struct platform_device *pdev)
>   musb_host_cleanup(musb);
>   musb_gadget_cleanup(musb);
>  
> - spin_lock_irqsave(>lock, flags);
>   musb_platform_disable(musb);
> + spin_lock_irqsave(>lock, flags);
>   musb_disable_interrupts(musb);
>   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
>   spin_unlock_irqrestore(>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

Re: [PATCH 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

[Gregory CLEMENT]

Hi Andrew,
 
 On mer., mars 08 2017, Andrew Lunn  wrote:

> On Wed, Mar 08, 2017 at 05:24:22PM +0100, Gregory CLEMENT wrote:
>> The mvebu ARM64 SoCs no more select PLAT_ORION but some of them as the
>> Armada 37xx use the EHCI orion controller. This patch allow to build
>> the driver when ARCH_MVEBU is selected.
>
> The mvebu ARM64 SoCs no longer selects PLAT_ORION.  However Armada
> 37xx use the Orion EHCI controller. This patch allows the Orion EHCI
> driver to be built when ARCH_MVEBU is selected.

Thanks for this enhancement!

>
>> Signed-off-by: Gregory CLEMENT 
>> ---
>>  drivers/usb/host/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
>> index 407d947b34ea..870c42d89298 100644
>> --- a/drivers/usb/host/Kconfig
>> +++ b/drivers/usb/host/Kconfig
>> @@ -188,7 +188,7 @@ config USB_EHCI_HCD_OMAP
>>  
>>  config USB_EHCI_HCD_ORION
>>  tristate  "Support for Marvell EBU on-chip EHCI USB controller"
>> -depends on USB_EHCI_HCD && PLAT_ORION
>> +depends on USB_EHCI_HCD && PLAT_ORION || ARCH_MVEBU
>
> I don't know the Kconfig language too well. Should this be:
>
>> +depends on USB_EHCI_HCD && (PLAT_ORION || ARCH_MVEBU)

Your version seems better.

Thanks,

Gregory

>
>   Andrew
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] usb: orion-echi: Add support for the Armada 3700

[Gregory CLEMENT]

Hi Andrew,
 
 On mer., mars 08 2017, Andrew Lunn  wrote:

> Hi Gregory
[...]

Thanks for your comments I will fix the typos and the wording.



>> +#define USB_SBUSCFG 0x90
>> +#define USB_SBUSCFG_BAWR0x6
>> +#define USB_SBUSCFG_BARD0x3
>> +#define USB_SBUSCFG_AHBBRST 0x0
>
> These three are all shifts. So i would suggest adding _SHIFT to the
> end.

Actually I removed it to fit in the 80 character...

>
>> +
>> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes 
>> */
>> +#define USB_SBUSCFG_BAWR_ALIGN_128B 0x3
>> +#define USB_SBUSCFG_BARD_ALIGN_128B 0x3
>> +/* AHBBRST = 3 : Align AHB Burst to INCR16 (64 bytes) */
>> +#define USB_SBUSCFG_AHBBRST_INCR16  0x3
>
> You can then apply the shift here.

... but I didn't think to this trick. 

>
>> +
>> +#define USB_SBUSCFG_DEF_VAL ((USB_SBUSCFG_BAWR_ALIGN_128B << 
>> USB_SBUSCFG_BAWR) \
>> + | (USB_SBUSCFG_BARD_ALIGN_128B << USB_SBUSCFG_BARD) \
>> + | (USB_SBUSCFG_AHBBRST_INCR16 << USB_SBUSCFG_AHBBRST))
>
> and this is then shorted.

So I will do it in the v2.

Thanks

Gregory

>
> Andrew

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] e-mail address change in drivers/usb/storage/unusual_devs.h

[Phillip Potter]

Dear all,

Just submitting a very minor patch to update my e-mail address in this file - I 
sent
a patch years ago to update the listed firmware version to make newer versions 
of the
Nokia 6288 mountable as mass storage devices. I hope my patch is in the right 
format,
I've tried to pay attention to the docs - sorry if not. Thanks.

Regards,
Phil Potter

Signed-off-by: Phillip Potter 
--- a/drivers/usb/storage/unusual_devs.h2017-03-07 18:05:22.674952200 
+
+++ b/drivers/usb/storage/unusual_devs.h2017-03-07 18:17:26.37417 
+
@@ -176,7 +176,7 @@ UNUSUAL_DEV(  0x0420, 0x0001, 0x0100, 0x

 /*
  * Reported by Andrew Nayenko 
- * Updated for new firmware by Phillip Potter 
+ * Updated for new firmware by Phillip Potter 
  */
 UNUSUAL_DEV(  0x0421, 0x0019, 0x0592, 0x0610,
"Nokia",
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 04/19] net: e100: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/net/ethernet/intel/e100.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c 
b/drivers/net/ethernet/intel/e100.c
index 2b7323d..d1002c2 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -607,7 +607,7 @@ struct nic {
struct mem *mem;
dma_addr_t dma_addr;
 
-   struct pci_pool *cbs_pool;
+   struct dma_pool *cbs_pool;
dma_addr_t cbs_dma_addr;
u8 adaptive_ifs;
u8 tx_threshold;
@@ -1892,7 +1892,7 @@ static void e100_clean_cbs(struct nic *nic)
nic->cb_to_clean = nic->cb_to_clean->next;
nic->cbs_avail++;
}
-   pci_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
+   dma_pool_free(nic->cbs_pool, nic->cbs, nic->cbs_dma_addr);
nic->cbs = NULL;
nic->cbs_avail = 0;
}
@@ -1910,7 +1910,7 @@ static int e100_alloc_cbs(struct nic *nic)
nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL;
nic->cbs_avail = 0;
 
-   nic->cbs = pci_pool_alloc(nic->cbs_pool, GFP_KERNEL,
+   nic->cbs = dma_pool_alloc(nic->cbs_pool, GFP_KERNEL,
  >cbs_dma_addr);
if (!nic->cbs)
return -ENOMEM;
@@ -2958,8 +2958,8 @@ static int e100_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
netif_err(nic, probe, nic->netdev, "Cannot register net device, 
aborting\n");
goto err_out_free;
}
-   nic->cbs_pool = pci_pool_create(netdev->name,
-  nic->pdev,
+   nic->cbs_pool = dma_pool_create(netdev->name,
+  >pdev->dev,
   nic->params.cbs.max * sizeof(struct cb),
   sizeof(u32),
   0);
@@ -2999,7 +2999,7 @@ static void e100_remove(struct pci_dev *pdev)
unregister_netdev(netdev);
e100_free(nic);
pci_iounmap(pdev, nic->csr);
-   pci_pool_destroy(nic->cbs_pool);
+   dma_pool_destroy(nic->cbs_pool);
free_netdev(netdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3

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

[PATCH v5 02/19] dmaengine: pch_dma: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/dma/pch_dma.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
index f9028e9..afd8f27 100644
--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -123,7 +123,7 @@ struct pch_dma_chan {
 struct pch_dma {
struct dma_device   dma;
void __iomem *membase;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
struct pch_dma_regs regs;
struct pch_dma_desc_regs ch_regs[MAX_CHAN_NR];
struct pch_dma_chan channels[MAX_CHAN_NR];
@@ -437,7 +437,7 @@ static struct pch_dma_desc *pdc_alloc_desc(struct dma_chan 
*chan, gfp_t flags)
struct pch_dma *pd = to_pd(chan->device);
dma_addr_t addr;
 
-   desc = pci_pool_zalloc(pd->pool, flags, );
+   desc = dma_pool_zalloc(pd->pool, flags, );
if (desc) {
INIT_LIST_HEAD(>tx_list);
dma_async_tx_descriptor_init(>txd, chan);
@@ -549,7 +549,7 @@ static void pd_free_chan_resources(struct dma_chan *chan)
spin_unlock_irq(_chan->lock);
 
list_for_each_entry_safe(desc, _d, _list, desc_node)
-   pci_pool_free(pd->pool, desc, desc->txd.phys);
+   dma_pool_free(pd->pool, desc, desc->txd.phys);
 
pdc_enable_irq(chan, 0);
 }
@@ -880,7 +880,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
goto err_iounmap;
}
 
-   pd->pool = pci_pool_create("pch_dma_desc_pool", pdev,
+   pd->pool = dma_pool_create("pch_dma_desc_pool", >dev,
   sizeof(struct pch_dma_desc), 4, 0);
if (!pd->pool) {
dev_err(>dev, "Failed to alloc DMA descriptors\n");
@@ -931,7 +931,7 @@ static int pch_dma_probe(struct pci_dev *pdev,
return 0;
 
 err_free_pool:
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
 err_free_irq:
free_irq(pdev->irq, pd);
 err_iounmap:
@@ -963,7 +963,7 @@ static void pch_dma_remove(struct pci_dev *pdev)
tasklet_kill(_chan->tasklet);
}
 
-   pci_pool_destroy(pd->pool);
+   dma_pool_destroy(pd->pool);
pci_iounmap(pdev, pd->membase);
pci_release_regions(pdev);
pci_disable_device(pdev);
-- 
2.9.3

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

[PATCH v5 03/19] IB/mthca: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/infiniband/hw/mthca/mthca_av.c  | 10 +-
 drivers/infiniband/hw/mthca/mthca_cmd.c |  8 
 drivers/infiniband/hw/mthca/mthca_dev.h |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/infiniband/hw/mthca/mthca_av.c 
b/drivers/infiniband/hw/mthca/mthca_av.c
index c9f0f36..9d041b6 100644
--- a/drivers/infiniband/hw/mthca/mthca_av.c
+++ b/drivers/infiniband/hw/mthca/mthca_av.c
@@ -186,7 +186,7 @@ int mthca_create_ah(struct mthca_dev *dev,
 
 on_hca_fail:
if (ah->type == MTHCA_AH_PCI_POOL) {
-   ah->av = pci_pool_zalloc(dev->av_table.pool,
+   ah->av = dma_pool_zalloc(dev->av_table.pool,
 GFP_ATOMIC, >avdma);
if (!ah->av)
return -ENOMEM;
@@ -245,7 +245,7 @@ int mthca_destroy_ah(struct mthca_dev *dev, struct mthca_ah 
*ah)
break;
 
case MTHCA_AH_PCI_POOL:
-   pci_pool_free(dev->av_table.pool, ah->av, ah->avdma);
+   dma_pool_free(dev->av_table.pool, ah->av, ah->avdma);
break;
 
case MTHCA_AH_KMALLOC:
@@ -333,7 +333,7 @@ int mthca_init_av_table(struct mthca_dev *dev)
if (err)
return err;
 
-   dev->av_table.pool = pci_pool_create("mthca_av", dev->pdev,
+   dev->av_table.pool = dma_pool_create("mthca_av", >pdev->dev,
 MTHCA_AV_SIZE,
 MTHCA_AV_SIZE, 0);
if (!dev->av_table.pool)
@@ -353,7 +353,7 @@ int mthca_init_av_table(struct mthca_dev *dev)
return 0;
 
  out_free_pool:
-   pci_pool_destroy(dev->av_table.pool);
+   dma_pool_destroy(dev->av_table.pool);
 
  out_free_alloc:
mthca_alloc_cleanup(>av_table.alloc);
@@ -367,6 +367,6 @@ void mthca_cleanup_av_table(struct mthca_dev *dev)
 
if (dev->av_table.av_map)
iounmap(dev->av_table.av_map);
-   pci_pool_destroy(dev->av_table.pool);
+   dma_pool_destroy(dev->av_table.pool);
mthca_alloc_cleanup(>av_table.alloc);
 }
diff --git a/drivers/infiniband/hw/mthca/mthca_cmd.c 
b/drivers/infiniband/hw/mthca/mthca_cmd.c
index c7f49bb..7f219c8 100644
--- a/drivers/infiniband/hw/mthca/mthca_cmd.c
+++ b/drivers/infiniband/hw/mthca/mthca_cmd.c
@@ -530,7 +530,7 @@ int mthca_cmd_init(struct mthca_dev *dev)
return -ENOMEM;
}
 
-   dev->cmd.pool = pci_pool_create("mthca_cmd", dev->pdev,
+   dev->cmd.pool = dma_pool_create("mthca_cmd", >pdev->dev,
MTHCA_MAILBOX_SIZE,
MTHCA_MAILBOX_SIZE, 0);
if (!dev->cmd.pool) {
@@ -543,7 +543,7 @@ int mthca_cmd_init(struct mthca_dev *dev)
 
 void mthca_cmd_cleanup(struct mthca_dev *dev)
 {
-   pci_pool_destroy(dev->cmd.pool);
+   dma_pool_destroy(dev->cmd.pool);
iounmap(dev->hcr);
if (dev->cmd.flags & MTHCA_CMD_POST_DOORBELLS)
iounmap(dev->cmd.dbell_map);
@@ -613,7 +613,7 @@ struct mthca_mailbox *mthca_alloc_mailbox(struct mthca_dev 
*dev,
if (!mailbox)
return ERR_PTR(-ENOMEM);
 
-   mailbox->buf = pci_pool_alloc(dev->cmd.pool, gfp_mask, >dma);
+   mailbox->buf = dma_pool_alloc(dev->cmd.pool, gfp_mask, >dma);
if (!mailbox->buf) {
kfree(mailbox);
return ERR_PTR(-ENOMEM);
@@ -627,7 +627,7 @@ void mthca_free_mailbox(struct mthca_dev *dev, struct 
mthca_mailbox *mailbox)
if (!mailbox)
return;
 
-   pci_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
+   dma_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
kfree(mailbox);
 }
 
diff --git a/drivers/infiniband/hw/mthca/mthca_dev.h 
b/drivers/infiniband/hw/mthca/mthca_dev.h
index 4393a02..8c3f6ed 100644
--- a/drivers/infiniband/hw/mthca/mthca_dev.h
+++ b/drivers/infiniband/hw/mthca/mthca_dev.h
@@ -118,7 +118,7 @@ enum {
 };
 
 struct mthca_cmd {
-   struct pci_pool  *pool;
+   struct dma_pool  *pool;
struct mutex  hcr_mutex;
struct semaphore  poll_sem;
struct semaphore  event_sem;
@@ -263,7 +263,7 @@ struct mthca_qp_table {
 };
 
 struct mthca_av_table {
-   struct pci_pool   *pool;
+   struct dma_pool   *pool;
intnum_ddr_avs;
u64ddr_av_base;
void __iomem  *av_map;
-- 
2.9.3

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

[PATCH v5 00/19] Replace PCI pool by DMA pool API

[Romain Perier]

The current PCI pool API are simple macro functions direct expanded to
the appropriate dma pool functions. The prototypes are almost the same
and semantically, they are very similar. I propose to use the DMA pool
API directly and get rid of the old API.

This set of patches, replaces the old API by the dma pool API
and remove the defines.

Changes in v5:
- Re-worded the cover letter (remove sentence about checkpatch.pl)
- Rebased series onto next-20170308
- Fix typos in commit message
- Added Acked-by Tags

Changes in v4:
- Rebased series onto next-20170301
- Removed patch 20/20: checks done by checkpath.pl, no longer required.
  Thanks to Peter and Joe for their feedbacks.
- Added Reviewed-by tags

Changes in v3:
- Rebased series onto next-20170224
- Fix checkpath.pl reports for patch 11/20 and patch 12/20
- Remove prefix RFC
Changes in v2:
- Introduced patch 18/20
- Fixed cosmetic changes: spaces before brace, live over 80 characters
- Removed some of the check for NULL pointers before calling dma_pool_destroy
- Improved the regexp in checkpatch for pci_pool, thanks to Joe Perches
- Added Tested-by and Acked-by tags

Romain Perier (19):
  block: DAC960: Replace PCI pool old API
  dmaengine: pch_dma: Replace PCI pool old API
  IB/mthca: Replace PCI pool old API
  net: e100: Replace PCI pool old API
  mlx4: Replace PCI pool old API
  mlx5: Replace PCI pool old API
  wireless: ipw2200: Replace PCI pool old API
  scsi: be2iscsi: Replace PCI pool old API
  scsi: csiostor: Replace PCI pool old API
  scsi: lpfc: Replace PCI pool old API
  scsi: megaraid: Replace PCI pool old API
  scsi: mpt3sas: Replace PCI pool old API
  scsi: mvsas: Replace PCI pool old API
  scsi: pmcraid: Replace PCI pool old API
  usb: gadget: amd5536udc: Replace PCI pool old API
  usb: gadget: net2280: Replace PCI pool old API
  usb: gadget: pch_udc: Replace PCI pool old API
  usb: host: Remove remaining pci_pool in comments
  PCI: Remove PCI pool macro functions

 drivers/block/DAC960.c|  36 -
 drivers/block/DAC960.h|   4 +-
 drivers/dma/pch_dma.c |  12 +--
 drivers/infiniband/hw/mthca/mthca_av.c|  10 +--
 drivers/infiniband/hw/mthca/mthca_cmd.c   |   8 +-
 drivers/infiniband/hw/mthca/mthca_dev.h   |   4 +-
 drivers/net/ethernet/intel/e100.c |  12 +--
 drivers/net/ethernet/mellanox/mlx4/cmd.c  |  10 +--
 drivers/net/ethernet/mellanox/mlx4/mlx4.h |   2 +-
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c |  11 +--
 drivers/net/wireless/intel/ipw2x00/ipw2200.c  |  13 ++--
 drivers/scsi/be2iscsi/be_iscsi.c  |   6 +-
 drivers/scsi/be2iscsi/be_main.c   |   6 +-
 drivers/scsi/be2iscsi/be_main.h   |   2 +-
 drivers/scsi/csiostor/csio_hw.h   |   2 +-
 drivers/scsi/csiostor/csio_init.c |  11 +--
 drivers/scsi/csiostor/csio_scsi.c |   6 +-
 drivers/scsi/lpfc/lpfc.h  |  14 ++--
 drivers/scsi/lpfc/lpfc_init.c |  16 ++--
 drivers/scsi/lpfc/lpfc_mem.c  | 106 +-
 drivers/scsi/lpfc/lpfc_nvme.c |   6 +-
 drivers/scsi/lpfc/lpfc_nvmet.c|   4 +-
 drivers/scsi/lpfc/lpfc_scsi.c |  12 +--
 drivers/scsi/megaraid/megaraid_mbox.c |  33 
 drivers/scsi/megaraid/megaraid_mm.c   |  32 
 drivers/scsi/megaraid/megaraid_sas_base.c |  29 +++
 drivers/scsi/megaraid/megaraid_sas_fusion.c   |  66 
 drivers/scsi/mpt3sas/mpt3sas_base.c   |  73 +-
 drivers/scsi/mvsas/mv_init.c  |   6 +-
 drivers/scsi/mvsas/mv_sas.c   |   6 +-
 drivers/scsi/pmcraid.c|  10 +--
 drivers/scsi/pmcraid.h|   2 +-
 drivers/usb/gadget/udc/amd5536udc.c   |   8 +-
 drivers/usb/gadget/udc/amd5536udc.h   |   4 +-
 drivers/usb/gadget/udc/net2280.c  |  12 +--
 drivers/usb/gadget/udc/net2280.h  |   2 +-
 drivers/usb/gadget/udc/pch_udc.c  |  31 
 drivers/usb/host/ehci-hcd.c   |   2 +-
 drivers/usb/host/fotg210-hcd.c|   2 +-
 drivers/usb/host/oxu210hp-hcd.c   |   2 +-
 include/linux/mlx5/driver.h   |   2 +-
 include/linux/pci.h   |   9 ---
 42 files changed, 311 insertions(+), 333 deletions(-)

-- 
2.9.3

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

[PATCH v5 01/19] block: DAC960: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/block/DAC960.c | 36 ++--
 drivers/block/DAC960.h |  4 ++--
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/block/DAC960.c b/drivers/block/DAC960.c
index 26a51be..2b221cc 100644
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@ -268,17 +268,17 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
   void *AllocationPointer = NULL;
   void *ScatterGatherCPU = NULL;
   dma_addr_t ScatterGatherDMA;
-  struct pci_pool *ScatterGatherPool;
+  struct dma_pool *ScatterGatherPool;
   void *RequestSenseCPU = NULL;
   dma_addr_t RequestSenseDMA;
-  struct pci_pool *RequestSensePool = NULL;
+  struct dma_pool *RequestSensePool = NULL;
 
   if (Controller->FirmwareType == DAC960_V1_Controller)
 {
   CommandAllocationLength = offsetof(DAC960_Command_T, V1.EndMarker);
   CommandAllocationGroupSize = DAC960_V1_CommandAllocationGroupSize;
-  ScatterGatherPool = pci_pool_create("DAC960_V1_ScatterGather",
-   Controller->PCIDevice,
+  ScatterGatherPool = dma_pool_create("DAC960_V1_ScatterGather",
+   >PCIDevice->dev,
DAC960_V1_ScatterGatherLimit * sizeof(DAC960_V1_ScatterGatherSegment_T),
sizeof(DAC960_V1_ScatterGatherSegment_T), 0);
   if (ScatterGatherPool == NULL)
@@ -290,18 +290,18 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
 {
   CommandAllocationLength = offsetof(DAC960_Command_T, V2.EndMarker);
   CommandAllocationGroupSize = DAC960_V2_CommandAllocationGroupSize;
-  ScatterGatherPool = pci_pool_create("DAC960_V2_ScatterGather",
-   Controller->PCIDevice,
+  ScatterGatherPool = dma_pool_create("DAC960_V2_ScatterGather",
+   >PCIDevice->dev,
DAC960_V2_ScatterGatherLimit * sizeof(DAC960_V2_ScatterGatherSegment_T),
sizeof(DAC960_V2_ScatterGatherSegment_T), 0);
   if (ScatterGatherPool == NULL)
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION (SG)");
-  RequestSensePool = pci_pool_create("DAC960_V2_RequestSense",
-   Controller->PCIDevice, sizeof(DAC960_SCSI_RequestSense_T),
+  RequestSensePool = dma_pool_create("DAC960_V2_RequestSense",
+   >PCIDevice->dev, sizeof(DAC960_SCSI_RequestSense_T),
sizeof(int), 0);
   if (RequestSensePool == NULL) {
-   pci_pool_destroy(ScatterGatherPool);
+   dma_pool_destroy(ScatterGatherPool);
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION (SG)");
   }
@@ -335,16 +335,16 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
   Command->Next = Controller->FreeCommands;
   Controller->FreeCommands = Command;
   Controller->Commands[CommandIdentifier-1] = Command;
-  ScatterGatherCPU = pci_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
+  ScatterGatherCPU = dma_pool_alloc(ScatterGatherPool, GFP_ATOMIC,
);
   if (ScatterGatherCPU == NULL)
  return DAC960_Failure(Controller, "AUXILIARY STRUCTURE CREATION");
 
   if (RequestSensePool != NULL) {
- RequestSenseCPU = pci_pool_alloc(RequestSensePool, GFP_ATOMIC,
+ RequestSenseCPU = dma_pool_alloc(RequestSensePool, GFP_ATOMIC,
);
  if (RequestSenseCPU == NULL) {
-pci_pool_free(ScatterGatherPool, ScatterGatherCPU,
+dma_pool_free(ScatterGatherPool, ScatterGatherCPU,
 ScatterGatherDMA);
return DAC960_Failure(Controller,
"AUXILIARY STRUCTURE CREATION");
@@ -379,8 +379,8 @@ static bool 
DAC960_CreateAuxiliaryStructures(DAC960_Controller_T *Controller)
 static void DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T *Controller)
 {
   int i;
-  struct pci_pool *ScatterGatherPool = Controller->ScatterGatherPool;
-  struct pci_pool *RequestSensePool = NULL;
+  struct dma_pool *ScatterGatherPool = Controller->ScatterGatherPool;
+  struct dma_pool *RequestSensePool = NULL;
   void *ScatterGatherCPU;
   dma_addr_t ScatterGatherDMA;
   void *RequestSenseCPU;
@@ -411,9 +411,9 @@ static void 
DAC960_DestroyAuxiliaryStructures(DAC960_Controller_T *Controller)
  RequestSenseDMA = Command->V2.RequestSenseDMA;
   }
   if (ScatterGatherCPU != NULL)
-  pci_pool_free(ScatterGatherPool, ScatterGatherCPU, ScatterGatherDMA);
+  dma_pool_free(ScatterGatherPool, ScatterGatherCPU, ScatterGatherDMA);

[PATCH v5 06/19] mlx5: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 11 ++-
 include/linux/mlx5/driver.h   |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c 
b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
index caa837e..6eef344 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
@@ -1061,7 +1061,7 @@ static struct mlx5_cmd_mailbox *alloc_cmd_box(struct 
mlx5_core_dev *dev,
if (!mailbox)
return ERR_PTR(-ENOMEM);
 
-   mailbox->buf = pci_pool_zalloc(dev->cmd.pool, flags,
+   mailbox->buf = dma_pool_zalloc(dev->cmd.pool, flags,
   >dma);
if (!mailbox->buf) {
mlx5_core_dbg(dev, "failed allocation\n");
@@ -1076,7 +1076,7 @@ static struct mlx5_cmd_mailbox *alloc_cmd_box(struct 
mlx5_core_dev *dev,
 static void free_cmd_box(struct mlx5_core_dev *dev,
 struct mlx5_cmd_mailbox *mailbox)
 {
-   pci_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
+   dma_pool_free(dev->cmd.pool, mailbox->buf, mailbox->dma);
kfree(mailbox);
 }
 
@@ -1696,7 +1696,8 @@ int mlx5_cmd_init(struct mlx5_core_dev *dev)
return -EINVAL;
}
 
-   cmd->pool = pci_pool_create("mlx5_cmd", dev->pdev, size, align, 0);
+   cmd->pool = dma_pool_create("mlx5_cmd", >pdev->dev, size, align,
+   0);
if (!cmd->pool)
return -ENOMEM;
 
@@ -1786,7 +1787,7 @@ int mlx5_cmd_init(struct mlx5_core_dev *dev)
free_cmd_page(dev, cmd);
 
 err_free_pool:
-   pci_pool_destroy(cmd->pool);
+   dma_pool_destroy(cmd->pool);
 
return err;
 }
@@ -1800,6 +1801,6 @@ void mlx5_cmd_cleanup(struct mlx5_core_dev *dev)
destroy_workqueue(cmd->wq);
destroy_msg_cache(dev);
free_cmd_page(dev, cmd);
-   pci_pool_destroy(cmd->pool);
+   dma_pool_destroy(cmd->pool);
 }
 EXPORT_SYMBOL(mlx5_cmd_cleanup);
diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
index 48d8b66..0e33e65 100644
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -284,7 +284,7 @@ struct mlx5_cmd {
struct semaphore pages_sem;
int mode;
struct mlx5_cmd_work_ent *ent_arr[MLX5_MAX_COMMANDS];
-   struct pci_pool *pool;
+   struct dma_pool *pool;
struct mlx5_cmd_debug dbg;
struct cmd_msg_cache cache[MLX5_NUM_COMMAND_CACHES];
int checksum_disabled;
-- 
2.9.3

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

[PATCH v5 05/19] mlx4: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/net/ethernet/mellanox/mlx4/cmd.c  | 10 +-
 drivers/net/ethernet/mellanox/mlx4/mlx4.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/cmd.c 
b/drivers/net/ethernet/mellanox/mlx4/cmd.c
index e8c1051..fb69604 100644
--- a/drivers/net/ethernet/mellanox/mlx4/cmd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/cmd.c
@@ -2516,8 +2516,8 @@ int mlx4_cmd_init(struct mlx4_dev *dev)
}
 
if (!priv->cmd.pool) {
-   priv->cmd.pool = pci_pool_create("mlx4_cmd",
-dev->persist->pdev,
+   priv->cmd.pool = dma_pool_create("mlx4_cmd",
+>persist->pdev->dev,
 MLX4_MAILBOX_SIZE,
 MLX4_MAILBOX_SIZE, 0);
if (!priv->cmd.pool)
@@ -2588,7 +2588,7 @@ void mlx4_cmd_cleanup(struct mlx4_dev *dev, int 
cleanup_mask)
struct mlx4_priv *priv = mlx4_priv(dev);
 
if (priv->cmd.pool && (cleanup_mask & MLX4_CMD_CLEANUP_POOL)) {
-   pci_pool_destroy(priv->cmd.pool);
+   dma_pool_destroy(priv->cmd.pool);
priv->cmd.pool = NULL;
}
 
@@ -2680,7 +2680,7 @@ struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct 
mlx4_dev *dev)
if (!mailbox)
return ERR_PTR(-ENOMEM);
 
-   mailbox->buf = pci_pool_zalloc(mlx4_priv(dev)->cmd.pool, GFP_KERNEL,
+   mailbox->buf = dma_pool_zalloc(mlx4_priv(dev)->cmd.pool, GFP_KERNEL,
   >dma);
if (!mailbox->buf) {
kfree(mailbox);
@@ -2697,7 +2697,7 @@ void mlx4_free_cmd_mailbox(struct mlx4_dev *dev,
if (!mailbox)
return;
 
-   pci_pool_free(mlx4_priv(dev)->cmd.pool, mailbox->buf, mailbox->dma);
+   dma_pool_free(mlx4_priv(dev)->cmd.pool, mailbox->buf, mailbox->dma);
kfree(mailbox);
 }
 EXPORT_SYMBOL_GPL(mlx4_free_cmd_mailbox);
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h 
b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
index b4f1bc5..69c8764 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
@@ -628,7 +628,7 @@ struct mlx4_mgm {
 };
 
 struct mlx4_cmd {
-   struct pci_pool*pool;
+   struct dma_pool*pool;
void __iomem   *hcr;
struct mutexslave_cmd_mutex;
struct semaphorepoll_sem;
-- 
2.9.3

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

[PATCH 0/3] Add EHCI support for Armada 37xx

[Gregory CLEMENT]

Hi,

The EHCI controller in the Armada 37xx SoCs is the one used on many
other mvebu SoCs such as the orion5x, the kirkwood, or the
armada. However, for Armada 37xx an extra initialization step is
needed: this is the purpose of the first patch.

The second patch allows to build the driver for the ARM64 Armada SoCs.

The last one enables the EHCI in the device tree.

Thanks,

Gregory

Gregory CLEMENT (2):
  usb: host: Allow to build ehci orion with mvebu SoCs
  ARM64: dts: marvell: armada-37xx: Add USB2 node

jinghua (1):
  usb: orion-echi: Add support for the Armada 3700

 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  6 
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   |  7 
 drivers/usb/host/Kconfig   |  2 +-
 drivers/usb/host/ehci-orion.c  | 39 ++
 5 files changed, 56 insertions(+), 2 deletions(-)

-- 
2.11.0

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

[PATCH v5 07/19] wireless: ipw2200: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 5ef3c5c..93dfe47 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -3211,7 +3211,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
struct fw_chunk *chunk;
int total_nr = 0;
int i;
-   struct pci_pool *pool;
+   struct dma_pool *pool;
void **virts;
dma_addr_t *phys;
 
@@ -3228,9 +3228,10 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
kfree(virts);
return -ENOMEM;
}
-   pool = pci_pool_create("ipw2200", priv->pci_dev, CB_MAX_LENGTH, 0, 0);
+   pool = dma_pool_create("ipw2200", >pci_dev->dev, CB_MAX_LENGTH, 0,
+  0);
if (!pool) {
-   IPW_ERROR("pci_pool_create failed\n");
+   IPW_ERROR("dma_pool_create failed\n");
kfree(phys);
kfree(virts);
return -ENOMEM;
@@ -3255,7 +3256,7 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
 
nr = (chunk_len + CB_MAX_LENGTH - 1) / CB_MAX_LENGTH;
for (i = 0; i < nr; i++) {
-   virts[total_nr] = pci_pool_alloc(pool, GFP_KERNEL,
+   virts[total_nr] = dma_pool_alloc(pool, GFP_KERNEL,
 [total_nr]);
if (!virts[total_nr]) {
ret = -ENOMEM;
@@ -3299,9 +3300,9 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * 
data, size_t len)
}
  out:
for (i = 0; i < total_nr; i++)
-   pci_pool_free(pool, virts[i], phys[i]);
+   dma_pool_free(pool, virts[i], phys[i]);
 
-   pci_pool_destroy(pool);
+   dma_pool_destroy(pool);
kfree(phys);
kfree(virts);
 
-- 
2.9.3

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

[PATCH 3/3] ARM64: dts: marvell: armada-37xx: Add USB2 node

[Gregory CLEMENT]

Armada 37xx SoC embedded an EHCI controller. This patch adds the device
tree node enabling its support.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 6 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 864936acc316..aa39339b6582 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -134,6 +134,12 @@
status = "okay";
 };
 
+/* CON27 */
+ {
+   status = "okay";
+};
+
+
  {
status = "okay";
phy0: ethernet-phy@0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 4c7ff32acb97..25ae5ccaf1bf 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -204,6 +204,13 @@
status = "disabled";
};
 
+   usb2: usb@5e000 {
+   compatible = "marvell,armada-3700-ehci";
+   reg = <0x5e000 0x2000>;
+   interrupts = ;
+   status = "disabled";
+   };
+
xor@60900 {
compatible = "marvell,armada-3700-xor";
reg = <0x60900 0x100
-- 
2.11.0

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

[PATCH 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

[Gregory CLEMENT]

The mvebu ARM64 SoCs no more select PLAT_ORION but some of them as the
Armada 37xx use the EHCI orion controller. This patch allow to build
the driver when ARCH_MVEBU is selected.

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 407d947b34ea..870c42d89298 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,7 +188,7 @@ config USB_EHCI_HCD_OMAP
 
 config USB_EHCI_HCD_ORION
tristate  "Support for Marvell EBU on-chip EHCI USB controller"
-   depends on USB_EHCI_HCD && PLAT_ORION
+   depends on USB_EHCI_HCD && PLAT_ORION || ARCH_MVEBU
default y
---help---
  Enables support for the on-chip EHCI controller on Marvell's
-- 
2.11.0

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

[PATCH 1/3] usb: orion-echi: Add support for the Armada 3700

[Gregory CLEMENT]

From: jinghua 

- Add a new compatoble string for the Armada 3700 SoCs

- add sbuscfg support for orion usb controller driver. For the SoCs
  without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
  register to guarantee the AHB master's burst would not overrun or
  underrun the FIFO.

- the sbuscfg register has to be set after the usb controller reset,
  otherwise the value would be overridden to 0. In order to do this, the
  reset callback is registered.

[gregory.clem...@free-electrons.com: - reword commit and comments
 - fix checkpatch warning]
Signed-off-by: jinghua 
Signed-off-by: Gregory CLEMENT 
---
 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 drivers/usb/host/ehci-orion.c  | 39 ++
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt 
b/Documentation/devicetree/bindings/usb/ehci-orion.txt
index 17c3bc858b86..9dfffc9dffec 100644
--- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
@@ -1,7 +1,9 @@
 * EHCI controller, Orion Marvell variants
 
 Required properties:
-- compatible: must be "marvell,orion-ehci"
+- compatible: could be one of the following
+   "marvell,orion-ehci"
+   "marvell,armada-3700-ehci"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: The EHCI interrupt
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index ee8d5faa0194..cf778e166b90 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -47,6 +47,21 @@
 #define USB_PHY_IVREF_CTRL 0x440
 #define USB_PHY_TST_GRP_CTRL   0x450
 
+#define USB_SBUSCFG0x90
+#defineUSB_SBUSCFG_BAWR0x6
+#defineUSB_SBUSCFG_BARD0x3
+#defineUSB_SBUSCFG_AHBBRST 0x0
+
+/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
+#define USB_SBUSCFG_BAWR_ALIGN_128B0x3
+#define USB_SBUSCFG_BARD_ALIGN_128B0x3
+/* AHBBRST = 3: Align AHB Burst to INCR16 (64 bytes) */
+#define USB_SBUSCFG_AHBBRST_INCR16 0x3
+
+#define USB_SBUSCFG_DEF_VAL ((USB_SBUSCFG_BAWR_ALIGN_128B << USB_SBUSCFG_BAWR) 
\
+| (USB_SBUSCFG_BARD_ALIGN_128B << USB_SBUSCFG_BARD) \
+| (USB_SBUSCFG_AHBBRST_INCR16 << USB_SBUSCFG_AHBBRST))
+
 #define DRIVER_DESC "EHCI orion driver"
 
 #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
@@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
}
 }
 
+static int ehci_orion_drv_reset(struct usb_hcd *hcd)
+{
+   struct device *dev = hcd->self.controller;
+   int retval;
+
+   retval = ehci_setup(hcd);
+   if (retval)
+   dev_err(dev, "ehci_setup failed %d\n", retval);
+
+   /*
+* For SoC without hlock, need to program sbuscfg value to guarantee
+* AHB master's burst would not overrun or underrun FIFO.
+*
+* sbuscfg reg has to be set after usb controller reset, otherwise
+* the value would be override to 0.
+*/
+   if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
+   wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
+
+   return retval;
+}
+
 static const struct ehci_driver_overrides orion_overrides __initconst = {
.extra_priv_size =  sizeof(struct orion_ehci_hcd),
+   .reset = ehci_orion_drv_reset,
 };
 
 static int ehci_orion_drv_probe(struct platform_device *pdev)
@@ -310,6 +348,7 @@ static int ehci_orion_drv_remove(struct platform_device 
*pdev)
 
 static const struct of_device_id ehci_orion_dt_ids[] = {
{ .compatible = "marvell,orion-ehci", },
+   { .compatible = "marvell,armada-3700-ehci", },
{},
 };
 MODULE_DEVICE_TABLE(of, ehci_orion_dt_ids);
-- 
2.11.0

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

[PATCH v2 0/5] USB: serial: ftdi_sio: latency timer and other stuff

[Ian Abbott]

Some patches to skip accessing the FTDI latency timer on chips that
don't support it, detect "BM" chips with iSerialNumber bug, validate
written device attribute values, and allow hex and octal "event_char"
values.

This is v2 of the patch series, incorporating changes suggested by
Johan.  The original patch 5 has been folded into v2 patches 3 and 4
with minor changes.

1) USB: serial: ftdi_sio: don't access latency timer on old chips
2) USB: serial: ftdi_sio: detect BM chip with iSerialNumber bug
3) USB: serial: ftdi_sio: only allow valid latency timer values
4) USB: serial: ftdi_sio: only allow valid event_char values
5) USB: serial: ftdi_sio: allow other bases for "event_char"

 drivers/usb/serial/ftdi_sio.c | 52 ---
 1 file changed, 44 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe 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 4/5] USB: serial: ftdi_sio: only allow valid event_char values

[Ian Abbott]

The "event_char" device attribute value, when written, is interpreted as
an enable bit in bit 8, and an "event character" in bits 7 to 0.

Return an error -EINVAL for out-of-range values.  Use kstrtouint() to
parse the integer instead of the obsolete simple_strtoul().

Signed-off-by: Ian Abbott 
---
v2:
- As suggested by Johan Hovold, combine with the use of kstrtouint()
from v1 patch 5.
---
 drivers/usb/serial/ftdi_sio.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index da396122ec83..0f3f7bfe9294 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1737,9 +1737,12 @@ static ssize_t store_event_char(struct device *dev,
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
struct usb_device *udev = port->serial->dev;
-   int v = simple_strtoul(valbuf, NULL, 10);
+   unsigned int v;
int rv;
 
+   if (kstrtouint(valbuf, 10, ) || v >= 0x200)
+   return -EINVAL;
+
dev_dbg(>dev, "%s: setting event char = %i\n", __func__, v);
 
rv = usb_control_msg(udev,
-- 
2.11.0

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

[PATCH v2 3/5] USB: serial: ftdi_sio: only allow valid latency timer values

[Ian Abbott]

Valid latency timer values are between 1 ms and 255 ms in 1 ms steps.
The store function for the "latency_timer" device attribute currently
allows any value, although only the lower 16 bits will be sent to the
device, and the device only stores the lower 8 bits.  The hardware
appears to accept the (invalid) value 0 and treats it the same as 1
(resulting in a latency of 1 ms).

Change the latency_timer_store() function to accept only the values 0 to
255, returning an error -EINVAL for out-of-range values.  Call
kstrtou8() to parse the integer instead of the obsolete
simple_strtoul().

Signed-off-by: Ian Abbott 
---
v2:
- As suggested by Johan Hovold, accept 0 as valid, and combine with the
use of kstrtouint() from v1 patch 5, except that I replaced it with
kstrtou8() instead to avoid having to do a separate range check.
---
 drivers/usb/serial/ftdi_sio.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index be2c77380320..da396122ec83 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1715,9 +1715,12 @@ static ssize_t latency_timer_store(struct device *dev,
 {
struct usb_serial_port *port = to_usb_serial_port(dev);
struct ftdi_private *priv = usb_get_serial_port_data(port);
-   int v = simple_strtoul(valbuf, NULL, 10);
+   u8 v;
int rv;
 
+   if (kstrtou8(valbuf, 10, ))
+   return -EINVAL;
+
priv->latency = v;
rv = write_latency_timer(port);
if (rv < 0)
-- 
2.11.0

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

[PATCH v2 1/5] USB: serial: ftdi_sio: don't access latency timer on old chips

[Ian Abbott]

The latency timer was introduced with the FT232BM and FT245BM chips.  Do
not bother attempting to read or write it for older chip versions.

Signed-off-by: Ian Abbott 
---
v2:
- No change.
---
 drivers/usb/serial/ftdi_sio.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index c540de15aad2..72314734dfd0 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1406,6 +1406,9 @@ static int write_latency_timer(struct usb_serial_port 
*port)
int rv;
int l = priv->latency;
 
+   if (priv->chip_type == SIO || priv->chip_type == FT8U232AM)
+   return -EINVAL;
+
if (priv->flags & ASYNC_LOW_LATENCY)
l = 1;
 
@@ -1429,6 +1432,9 @@ static int read_latency_timer(struct usb_serial_port 
*port)
unsigned char *buf;
int rv;
 
+   if (priv->chip_type == SIO || priv->chip_type == FT8U232AM)
+   return -EINVAL;
+
buf = kmalloc(1, GFP_KERNEL);
if (!buf)
return -ENOMEM;
-- 
2.11.0

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

[PATCH v2 5/5] USB: serial: ftdi_sio: allow other bases for "event_char"

[Ian Abbott]

The 'store' function for the "event_char" device attribute currently
expects a base 10 value.  The value is composed of an enable bit in bit
8 and an 8-bit "event character" code in bits 7 to 0.  It seems
reasonable to allow hexadecimal and octal numbers to be written to the
device attribute in addition to decimal.  Make it so.

Change the debug message to show the value in hexadecimal, rather than
decimal.

Signed-off-by: Ian Abbott 
---
v2:
- This was patch 6 in the original patch series.
- As suggested by Johan Hovold, change the debug log message to show
the value written in hexadecimal instead of decimal.
---
 drivers/usb/serial/ftdi_sio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0f3f7bfe9294..ee5136baea71 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1740,10 +1740,10 @@ static ssize_t store_event_char(struct device *dev,
unsigned int v;
int rv;
 
-   if (kstrtouint(valbuf, 10, ) || v >= 0x200)
+   if (kstrtouint(valbuf, 0, ) || v >= 0x200)
return -EINVAL;
 
-   dev_dbg(>dev, "%s: setting event char = %i\n", __func__, v);
+   dev_dbg(>dev, "%s: setting event char = 0x%03x\n", __func__, v);
 
rv = usb_control_msg(udev,
 usb_sndctrlpipe(udev, 0),
-- 
2.11.0

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

[PATCH v2 2/5] USB: serial: ftdi_sio: detect BM chip with iSerialNumber bug

[Ian Abbott]

If a BM type chip has iSerialNumber set to 0 in its EEPROM, an incorrect
value is read from the bcdDevice field of the USB descriptor, making it
look like an AM type chip.  Attempt to correct this in
ftdi_determine_type() by attempting to read the latency timer for an AM
type chip if it has iSerialNumber set to 0.  If that succeeds, assume it
is a BM type chip.

Currently, read_latency_timer() bails out without reading the latency
timer for an AM type chip, so factor out the guts of
read_latency_timer() into a new function _read_latency_timer() that
attempts to read the latency timer regardless of chip type, and returns
either the latency timer value or a negative error number.

Signed-off-by: Ian Abbott 
---
v2:
- As suggested by Johan Hovold, only attempt to read latency timer for
AM type chip if iSerialNumber is 0 (indicating that it might be a BM
type chip with iSerialNumber bug).
---
 drivers/usb/serial/ftdi_sio.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 72314734dfd0..be2c77380320 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1425,16 +1425,13 @@ static int write_latency_timer(struct usb_serial_port 
*port)
return rv;
 }
 
-static int read_latency_timer(struct usb_serial_port *port)
+static int _read_latency_timer(struct usb_serial_port *port)
 {
struct ftdi_private *priv = usb_get_serial_port_data(port);
struct usb_device *udev = port->serial->dev;
unsigned char *buf;
int rv;
 
-   if (priv->chip_type == SIO || priv->chip_type == FT8U232AM)
-   return -EINVAL;
-
buf = kmalloc(1, GFP_KERNEL);
if (!buf)
return -ENOMEM;
@@ -1446,11 +1443,10 @@ static int read_latency_timer(struct usb_serial_port 
*port)
 0, priv->interface,
 buf, 1, WDR_TIMEOUT);
if (rv < 1) {
-   dev_err(>dev, "Unable to read latency timer: %i\n", rv);
if (rv >= 0)
rv = -EIO;
} else {
-   priv->latency = buf[0];
+   rv = buf[0];
}
 
kfree(buf);
@@ -1458,6 +1454,24 @@ static int read_latency_timer(struct usb_serial_port 
*port)
return rv;
 }
 
+static int read_latency_timer(struct usb_serial_port *port)
+{
+   struct ftdi_private *priv = usb_get_serial_port_data(port);
+   int rv;
+
+   if (priv->chip_type == SIO || priv->chip_type == FT8U232AM)
+   return -EINVAL;
+
+   rv = _read_latency_timer(port);
+   if (rv < 0) {
+   dev_err(>dev, "Unable to read latency timer: %i\n", rv);
+   return rv;
+   }
+
+   priv->latency = rv;
+   return 0;
+}
+
 static int get_serial_info(struct usb_serial_port *port,
struct serial_struct __user *retinfo)
 {
@@ -1609,9 +1623,19 @@ static void ftdi_determine_type(struct usb_serial_port 
*port)
priv->baud_base = 1200 / 16;
} else if (version < 0x400) {
/* Assume it's an FT8U232AM (or FT8U245AM) */
-   /* (It might be a BM because of the iSerialNumber bug,
-* but it will still work as an AM device.) */
priv->chip_type = FT8U232AM;
+   /*
+* It might be a BM type because of the iSerialNumber bug.
+* If iSerialNumber==0 and the latency timer is readable,
+* assume it is BM type.
+*/
+   if (udev->descriptor.iSerialNumber == 0 &&
+   _read_latency_timer(port) >= 0) {
+   dev_dbg(>dev,
+   "%s: has latency timer so not an AM type\n",
+   __func__);
+   priv->chip_type = FT232BM;
+   }
} else if (version < 0x600) {
/* Assume it's an FT232BM (or FT245BM) */
priv->chip_type = FT232BM;
-- 
2.11.0

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

[solution] usb: gadget: uvc: configfs: fails to enumerate in HOST

[Petr Cvek]

Hi,

I'm not subscribed to linux-usb mailing list so I found your post just by a 
pure luck. I've sent the patch for:

streaming_maxburst streaming_maxpacket streaming_interval

problem earlier this week. Try this patch [1]:

BTW please CC me if you will have another discusion in your thread (I will try 
to not forget it myself if I will continue in my thread).

P.S. Which userspace do you using, original uvc-gadget or unofficial repo [2]?

[1] https://www.spinics.net/lists/linux-usb/msg154417.html
[2] https://github.com/madscientist42/uvc-gadget

--
[PATCH] usb: gadget: uvc: Missing files for configfs interface

Commit 76e0da34c7ce ("usb-gadget/uvc: use per-attribute show and store
methods") caused a stringification of an undefined macro argument "aname",
so three UVC parameters (streaming_interval, streaming_maxpacket and
streaming_maxburst) were named "aname".

Add the definition of "aname" to the main macro and name the filenames as
originaly intended.

Signed-off-by: Petr Cvek 
---
 drivers/usb/gadget/function/uvc_configfs.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index 4e037d2a7a60..3a36b2e85788 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -2125,7 +2125,7 @@ static struct configfs_item_operations uvc_item_ops = {
.release= uvc_attr_release,
 };
 
-#define UVCG_OPTS_ATTR(cname, conv, str2u, uxx, vnoc, limit)   \
+#define UVCG_OPTS_ATTR(cname, aname, conv, str2u, uxx, vnoc, limit)\
 static ssize_t f_uvc_opts_##cname##_show(  \
struct config_item *item, char *page)   \
 {  \
@@ -2172,12 +2172,12 @@ UVC_ATTR(f_uvc_opts_, cname, aname)
 
 #define identity_conv(x) (x)
 
-UVCG_OPTS_ATTR(streaming_interval, identity_conv, kstrtou8, u8, identity_conv,
-  16);
-UVCG_OPTS_ATTR(streaming_maxpacket, le16_to_cpu, kstrtou16, u16, le16_to_cpu,
-  3072);
-UVCG_OPTS_ATTR(streaming_maxburst, identity_conv, kstrtou8, u8, identity_conv,
-  15);
+UVCG_OPTS_ATTR(streaming_interval, streaming_interval, identity_conv,
+  kstrtou8, u8, identity_conv, 16);
+UVCG_OPTS_ATTR(streaming_maxpacket, streaming_maxpacket, le16_to_cpu,
+  kstrtou16, u16, le16_to_cpu, 3072);
+UVCG_OPTS_ATTR(streaming_maxburst, streaming_maxburst, identity_conv,
+  kstrtou8, u8, identity_conv, 15);
 
 #undef identity_conv
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 09/19] scsi: csiostor: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
the name of some variables and the content of comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/csiostor/csio_hw.h   |  2 +-
 drivers/scsi/csiostor/csio_init.c | 11 ++-
 drivers/scsi/csiostor/csio_scsi.c |  6 +++---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 029bef8..55b04fc 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -465,7 +465,7 @@ struct csio_hw {
struct csio_pport   pport[CSIO_MAX_PPORTS]; /* Ports (XGMACs) */
struct csio_hw_params   params; /* Hw parameters */
 
-   struct pci_pool *scsi_pci_pool; /* PCI pool for SCSI */
+   struct dma_pool *scsi_dma_pool; /* DMA pool for SCSI */
mempool_t   *mb_mempool;/* Mailbox memory pool*/
mempool_t   *rnode_mempool; /* rnode memory pool */
 
diff --git a/drivers/scsi/csiostor/csio_init.c 
b/drivers/scsi/csiostor/csio_init.c
index dbe416f..292964c 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -485,9 +485,10 @@ csio_resource_alloc(struct csio_hw *hw)
if (!hw->rnode_mempool)
goto err_free_mb_mempool;
 
-   hw->scsi_pci_pool = pci_pool_create("csio_scsi_pci_pool", hw->pdev,
-   CSIO_SCSI_RSP_LEN, 8, 0);
-   if (!hw->scsi_pci_pool)
+   hw->scsi_dma_pool = dma_pool_create("csio_scsi_dma_pool",
+   >pdev->dev, CSIO_SCSI_RSP_LEN,
+   8, 0);
+   if (!hw->scsi_dma_pool)
goto err_free_rn_pool;
 
return 0;
@@ -505,8 +506,8 @@ csio_resource_alloc(struct csio_hw *hw)
 static void
 csio_resource_free(struct csio_hw *hw)
 {
-   pci_pool_destroy(hw->scsi_pci_pool);
-   hw->scsi_pci_pool = NULL;
+   dma_pool_destroy(hw->scsi_dma_pool);
+   hw->scsi_dma_pool = NULL;
mempool_destroy(hw->rnode_mempool);
hw->rnode_mempool = NULL;
mempool_destroy(hw->mb_mempool);
diff --git a/drivers/scsi/csiostor/csio_scsi.c 
b/drivers/scsi/csiostor/csio_scsi.c
index a1ff75f..dab0d3f 100644
--- a/drivers/scsi/csiostor/csio_scsi.c
+++ b/drivers/scsi/csiostor/csio_scsi.c
@@ -2445,7 +2445,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
 
/* Allocate Dma buffers for Response Payload */
dma_buf = >dma_buf;
-   dma_buf->vaddr = pci_pool_alloc(hw->scsi_pci_pool, GFP_KERNEL,
+   dma_buf->vaddr = dma_pool_alloc(hw->scsi_dma_pool, GFP_KERNEL,
_buf->paddr);
if (!dma_buf->vaddr) {
csio_err(hw,
@@ -2485,7 +2485,7 @@ csio_scsim_init(struct csio_scsim *scm, struct csio_hw 
*hw)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
@@ -2516,7 +2516,7 @@ csio_scsim_exit(struct csio_scsim *scm)
ioreq = (struct csio_ioreq *)tmp;
 
dma_buf = >dma_buf;
-   pci_pool_free(scm->hw->scsi_pci_pool, dma_buf->vaddr,
+   dma_pool_free(scm->hw->scsi_dma_pool, dma_buf->vaddr,
  dma_buf->paddr);
 
kfree(ioreq);
-- 
2.9.3

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

[PATCH v5 08/19] scsi: be2iscsi: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/scsi/be2iscsi/be_iscsi.c | 6 +++---
 drivers/scsi/be2iscsi/be_main.c  | 6 +++---
 drivers/scsi/be2iscsi/be_main.h  | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index a484457..d76ef77 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -87,8 +87,8 @@ struct iscsi_cls_session *beiscsi_session_create(struct 
iscsi_endpoint *ep,
return NULL;
sess = cls_session->dd_data;
beiscsi_sess = sess->dd_data;
-   beiscsi_sess->bhs_pool =  pci_pool_create("beiscsi_bhs_pool",
-  phba->pcidev,
+   beiscsi_sess->bhs_pool =  dma_pool_create("beiscsi_bhs_pool",
+  >pcidev->dev,
   sizeof(struct be_cmd_bhs),
   64, 0);
if (!beiscsi_sess->bhs_pool)
@@ -113,7 +113,7 @@ void beiscsi_session_destroy(struct iscsi_cls_session 
*cls_session)
struct beiscsi_session *beiscsi_sess = sess->dd_data;
 
printk(KERN_INFO "In beiscsi_session_destroy\n");
-   pci_pool_destroy(beiscsi_sess->bhs_pool);
+   dma_pool_destroy(beiscsi_sess->bhs_pool);
iscsi_session_teardown(cls_session);
 }
 
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 32b2713..dd43480 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -4307,7 +4307,7 @@ static void beiscsi_cleanup_task(struct iscsi_task *task)
pwrb_context = _ctrlr->wrb_context[cri_index];
 
if (io_task->cmd_bhs) {
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
task->hdr = NULL;
@@ -4424,7 +4424,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
struct beiscsi_session *beiscsi_sess = beiscsi_conn->beiscsi_sess;
dma_addr_t paddr;
 
-   io_task->cmd_bhs = pci_pool_alloc(beiscsi_sess->bhs_pool,
+   io_task->cmd_bhs = dma_pool_alloc(beiscsi_sess->bhs_pool,
  GFP_ATOMIC, );
if (!io_task->cmd_bhs)
return -ENOMEM;
@@ -4551,7 +4551,7 @@ static int beiscsi_alloc_pdu(struct iscsi_task *task, 
uint8_t opcode)
if (io_task->pwrb_handle)
free_wrb_handle(phba, pwrb_context, io_task->pwrb_handle);
io_task->pwrb_handle = NULL;
-   pci_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
+   dma_pool_free(beiscsi_sess->bhs_pool, io_task->cmd_bhs,
  io_task->bhs_pa.u.a64.address);
io_task->cmd_bhs = NULL;
return -ENOMEM;
diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h
index 2188579..cf58d31 100644
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -446,7 +446,7 @@ struct beiscsi_hba {
 test_bit(BEISCSI_HBA_ONLINE, >state))
 
 struct beiscsi_session {
-   struct pci_pool *bhs_pool;
+   struct dma_pool *bhs_pool;
 };
 
 /**
-- 
2.9.3

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

[PATCH v5 10/19] scsi: lpfc: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API. It also updates
some comments, accordingly.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/lpfc/lpfc.h   |  14 +++---
 drivers/scsi/lpfc/lpfc_init.c  |  16 +++
 drivers/scsi/lpfc/lpfc_mem.c   | 106 -
 drivers/scsi/lpfc/lpfc_nvme.c  |   6 +--
 drivers/scsi/lpfc/lpfc_nvmet.c |   4 +-
 drivers/scsi/lpfc/lpfc_scsi.c  |  12 ++---
 6 files changed, 77 insertions(+), 81 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 257bbdd..c6f82db 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -935,13 +935,13 @@ struct lpfc_hba {
struct list_head active_rrq_list;
spinlock_t hbalock;
 
-   /* pci_mem_pools */
-   struct pci_pool *lpfc_sg_dma_buf_pool;
-   struct pci_pool *lpfc_mbuf_pool;
-   struct pci_pool *lpfc_hrb_pool; /* header receive buffer pool */
-   struct pci_pool *lpfc_drb_pool; /* data receive buffer pool */
-   struct pci_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
-   struct pci_pool *txrdy_payload_pool;
+   /* dma_mem_pools */
+   struct dma_pool *lpfc_sg_dma_buf_pool;
+   struct dma_pool *lpfc_mbuf_pool;
+   struct dma_pool *lpfc_hrb_pool; /* header receive buffer pool */
+   struct dma_pool *lpfc_drb_pool; /* data receive buffer pool */
+   struct dma_pool *lpfc_hbq_pool; /* SLI3 hbq buffer pool */
+   struct dma_pool *txrdy_payload_pool;
struct lpfc_dma_pool lpfc_mbuf_safety_pool;
 
mempool_t *mbox_mem_pool;
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 661bd25..4569350 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -3151,7 +3151,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_put,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3162,7 +3162,7 @@ lpfc_scsi_free(struct lpfc_hba *phba)
list_for_each_entry_safe(sb, sb_next, >lpfc_scsi_buf_list_get,
 list) {
list_del(>list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, sb->data,
  sb->dma_handle);
kfree(sb);
phba->total_scsi_bufs--;
@@ -3193,7 +3193,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_put, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3204,7 +3204,7 @@ lpfc_nvme_free(struct lpfc_hba *phba)
list_for_each_entry_safe(lpfc_ncmd, lpfc_ncmd_next,
 >lpfc_nvme_buf_list_get, list) {
list_del(_ncmd->list);
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool, lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
phba->total_nvme_bufs--;
@@ -3517,7 +3517,7 @@ lpfc_sli4_scsi_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, psb,
 struct lpfc_scsi_buf, list);
if (psb) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  psb->data, psb->dma_handle);
kfree(psb);
}
@@ -3652,7 +3652,7 @@ lpfc_sli4_nvme_sgl_update(struct lpfc_hba *phba)
list_remove_head(_sgl_list, lpfc_ncmd,
 struct lpfc_nvme_buf, list);
if (lpfc_ncmd) {
-   pci_pool_free(phba->lpfc_sg_dma_buf_pool,
+   dma_pool_free(phba->lpfc_sg_dma_buf_pool,
  lpfc_ncmd->data,
  lpfc_ncmd->dma_handle);
kfree(lpfc_ncmd);
@@ -6673,8 +6673,8 @@ lpfc_create_shost(struct 

[PATCH v5 13/19] scsi: mvsas: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mvsas/mv_init.c | 6 +++---
 drivers/scsi/mvsas/mv_sas.c  | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index 8280046..41d2276 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -125,8 +125,7 @@ static void mvs_free(struct mvs_info *mvi)
else
slot_nr = MVS_CHIP_SLOT_SZ;
 
-   if (mvi->dma_pool)
-   pci_pool_destroy(mvi->dma_pool);
+   dma_pool_destroy(mvi->dma_pool);
 
if (mvi->tx)
dma_free_coherent(mvi->dev,
@@ -296,7 +295,8 @@ static int mvs_alloc(struct mvs_info *mvi, struct Scsi_Host 
*shost)
goto err_out;
 
sprintf(pool_name, "%s%d", "mvs_dma_pool", mvi->id);
-   mvi->dma_pool = pci_pool_create(pool_name, mvi->pdev, MVS_SLOT_BUF_SZ, 
16, 0);
+   mvi->dma_pool = dma_pool_create(pool_name, >pdev->dev,
+   MVS_SLOT_BUF_SZ, 16, 0);
if (!mvi->dma_pool) {
printk(KERN_DEBUG "failed to create dma pool %s.\n", 
pool_name);
goto err_out;
diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index c7cc803..ee81d10 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -790,7 +790,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
slot->n_elem = n_elem;
slot->slot_tag = tag;
 
-   slot->buf = pci_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
+   slot->buf = dma_pool_alloc(mvi->dma_pool, GFP_ATOMIC, >buf_dma);
if (!slot->buf) {
rc = -ENOMEM;
goto err_out_tag;
@@ -840,7 +840,7 @@ static int mvs_task_prep(struct sas_task *task, struct 
mvs_info *mvi, int is_tmf
return rc;
 
 err_out_slot_buf:
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
 err_out_tag:
mvs_tag_free(mvi, tag);
 err_out:
@@ -918,7 +918,7 @@ static void mvs_slot_task_free(struct mvs_info *mvi, struct 
sas_task *task,
}
 
if (slot->buf) {
-   pci_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
+   dma_pool_free(mvi->dma_pool, slot->buf, slot->buf_dma);
slot->buf = NULL;
}
list_del_init(>entry);
-- 
2.9.3

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

[PATCH v5 12/19] scsi: mpt3sas: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 73 +
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 5b7aec5..5ae1c23 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3200,9 +3200,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->sense) {
-   pci_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
-   if (ioc->sense_dma_pool)
-   pci_pool_destroy(ioc->sense_dma_pool);
+   dma_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
+   dma_pool_destroy(ioc->sense_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"sense_pool(0x%p): free\n",
ioc->name, ioc->sense));
@@ -3210,9 +3209,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply) {
-   pci_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
-   if (ioc->reply_dma_pool)
-   pci_pool_destroy(ioc->reply_dma_pool);
+   dma_pool_free(ioc->reply_dma_pool, ioc->reply, ioc->reply_dma);
+   dma_pool_destroy(ioc->reply_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_pool(0x%p): free\n",
ioc->name, ioc->reply));
@@ -3220,10 +3218,9 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
 
if (ioc->reply_free) {
-   pci_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
+   dma_pool_free(ioc->reply_free_dma_pool, ioc->reply_free,
ioc->reply_free_dma);
-   if (ioc->reply_free_dma_pool)
-   pci_pool_destroy(ioc->reply_free_dma_pool);
+   dma_pool_destroy(ioc->reply_free_dma_pool);
dexitprintk(ioc, pr_info(MPT3SAS_FMT
"reply_free_pool(0x%p): free\n",
ioc->name, ioc->reply_free));
@@ -3234,7 +3231,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
do {
rps = >reply_post[i];
if (rps->reply_post_free) {
-   pci_pool_free(
+   dma_pool_free(
ioc->reply_post_free_dma_pool,
rps->reply_post_free,
rps->reply_post_free_dma);
@@ -3246,8 +3243,7 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
} while (ioc->rdpq_array_enable &&
   (++i < ioc->reply_queue_count));
 
-   if (ioc->reply_post_free_dma_pool)
-   pci_pool_destroy(ioc->reply_post_free_dma_pool);
+   dma_pool_destroy(ioc->reply_post_free_dma_pool);
kfree(ioc->reply_post);
}
 
@@ -3268,12 +3264,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
if (ioc->chain_lookup) {
for (i = 0; i < ioc->chain_depth; i++) {
if (ioc->chain_lookup[i].chain_buffer)
-   pci_pool_free(ioc->chain_dma_pool,
+   dma_pool_free(ioc->chain_dma_pool,
ioc->chain_lookup[i].chain_buffer,
ioc->chain_lookup[i].chain_buffer_dma);
}
-   if (ioc->chain_dma_pool)
-   pci_pool_destroy(ioc->chain_dma_pool);
+   dma_pool_destroy(ioc->chain_dma_pool);
free_pages((ulong)ioc->chain_lookup, ioc->chain_pages);
ioc->chain_lookup = NULL;
}
@@ -3448,23 +3443,23 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->name);
goto out;
}
-   ioc->reply_post_free_dma_pool = pci_pool_create("reply_post_free pool",
-   ioc->pdev, sz, 16, 0);
+   ioc->reply_post_free_dma_pool = dma_pool_create("reply_post_free pool",
+   >pdev->dev, sz, 16, 0);
if (!ioc->reply_post_free_dma_pool) {
pr_err(MPT3SAS_FMT
-"reply_post_free pool: pci_pool_create failed\n",
+"reply_post_free pool: dma_pool_create failed\n",
 ioc->name);
goto out;
}
i = 0;
do {
ioc->reply_post[i].reply_post_free =
-   pci_pool_alloc(ioc->reply_post_free_dma_pool,
+   

[PATCH v5 14/19] scsi: pmcraid: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/scsi/pmcraid.c | 10 +-
 drivers/scsi/pmcraid.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 49e70a3..0f893c4 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4699,13 +4699,13 @@ pmcraid_release_control_blocks(
return;
 
for (i = 0; i < max_index; i++) {
-   pci_pool_free(pinstance->control_pool,
+   dma_pool_free(pinstance->control_pool,
  pinstance->cmd_list[i]->ioa_cb,
  pinstance->cmd_list[i]->ioa_cb_bus_addr);
pinstance->cmd_list[i]->ioa_cb = NULL;
pinstance->cmd_list[i]->ioa_cb_bus_addr = 0;
}
-   pci_pool_destroy(pinstance->control_pool);
+   dma_pool_destroy(pinstance->control_pool);
pinstance->control_pool = NULL;
 }
 
@@ -4762,8 +4762,8 @@ static int pmcraid_allocate_control_blocks(struct 
pmcraid_instance *pinstance)
pinstance->host->unique_id);
 
pinstance->control_pool =
-   pci_pool_create(pinstance->ctl_pool_name,
-   pinstance->pdev,
+   dma_pool_create(pinstance->ctl_pool_name,
+   >pdev->dev,
sizeof(struct pmcraid_control_block),
PMCRAID_IOARCB_ALIGNMENT, 0);
 
@@ -4772,7 +4772,7 @@ static int pmcraid_allocate_control_blocks(struct 
pmcraid_instance *pinstance)
 
for (i = 0; i < PMCRAID_MAX_CMD; i++) {
pinstance->cmd_list[i]->ioa_cb =
-   pci_pool_alloc(
+   dma_pool_alloc(
pinstance->control_pool,
GFP_KERNEL,
&(pinstance->cmd_list[i]->ioa_cb_bus_addr));
diff --git a/drivers/scsi/pmcraid.h b/drivers/scsi/pmcraid.h
index 568b18a..acf5a7b 100644
--- a/drivers/scsi/pmcraid.h
+++ b/drivers/scsi/pmcraid.h
@@ -755,7 +755,7 @@ struct pmcraid_instance {
 
/* structures related to command blocks */
struct kmem_cache *cmd_cachep;  /* cache for cmd blocks */
-   struct pci_pool *control_pool;  /* pool for control blocks */
+   struct dma_pool *control_pool;  /* pool for control blocks */
char   cmd_pool_name[64];   /* name of cmd cache */
char   ctl_pool_name[64];   /* name of control cache */
 
-- 
2.9.3

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

[PATCH v5 11/19] scsi: megaraid: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
Acked-by: Sumit Saxena 
---
 drivers/scsi/megaraid/megaraid_mbox.c   | 33 +++
 drivers/scsi/megaraid/megaraid_mm.c | 32 +++---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 29 +++--
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 66 +
 4 files changed, 77 insertions(+), 83 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_mbox.c 
b/drivers/scsi/megaraid/megaraid_mbox.c
index f0987f2..7dfc2e2 100644
--- a/drivers/scsi/megaraid/megaraid_mbox.c
+++ b/drivers/scsi/megaraid/megaraid_mbox.c
@@ -1153,8 +1153,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
 
// Allocate memory for 16-bytes aligned mailboxes
-   raid_dev->mbox_pool_handle = pci_pool_create("megaraid mbox pool",
-   adapter->pdev,
+   raid_dev->mbox_pool_handle = dma_pool_create("megaraid mbox pool",
+   >pdev->dev,
sizeof(mbox64_t) + 16,
16, 0);
 
@@ -1164,7 +1164,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
mbox_pci_blk = raid_dev->mbox_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   mbox_pci_blk[i].vaddr = pci_pool_alloc(
+   mbox_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->mbox_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1181,8 +1181,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 * share common memory pool. Passthru structures piggyback on memory
 * allocted to extended passthru since passthru is smaller of the two
 */
-   raid_dev->epthru_pool_handle = pci_pool_create("megaraid mbox pthru",
-   adapter->pdev, sizeof(mraid_epassthru_t), 128, 0);
+   raid_dev->epthru_pool_handle = dma_pool_create("megaraid mbox pthru",
+   >pdev->dev, sizeof(mraid_epassthru_t), 128, 0);
 
if (raid_dev->epthru_pool_handle == NULL) {
goto fail_setup_dma_pool;
@@ -1190,7 +1190,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   epthru_pci_blk[i].vaddr = pci_pool_alloc(
+   epthru_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->epthru_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1202,8 +1202,8 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
// Allocate memory for each scatter-gather list. Request for 512 bytes
// alignment for each sg list
-   raid_dev->sg_pool_handle = pci_pool_create("megaraid mbox sg",
-   adapter->pdev,
+   raid_dev->sg_pool_handle = dma_pool_create("megaraid mbox sg",
+   >pdev->dev,
sizeof(mbox_sgl64) * MBOX_MAX_SG_SIZE,
512, 0);
 
@@ -1213,7 +1213,7 @@ megaraid_mbox_setup_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS; i++) {
-   sg_pci_blk[i].vaddr = pci_pool_alloc(
+   sg_pci_blk[i].vaddr = dma_pool_alloc(
raid_dev->sg_pool_handle,
GFP_KERNEL,
_pci_blk[i].dma_addr);
@@ -1249,29 +1249,26 @@ megaraid_mbox_teardown_dma_pools(adapter_t *adapter)
 
sg_pci_blk = raid_dev->sg_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && sg_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
+   dma_pool_free(raid_dev->sg_pool_handle, sg_pci_blk[i].vaddr,
sg_pci_blk[i].dma_addr);
}
-   if (raid_dev->sg_pool_handle)
-   pci_pool_destroy(raid_dev->sg_pool_handle);
+   dma_pool_destroy(raid_dev->sg_pool_handle);
 
 
epthru_pci_blk = raid_dev->epthru_pool;
for (i = 0; i < MBOX_MAX_SCSI_CMDS && epthru_pci_blk[i].vaddr; i++) {
-   pci_pool_free(raid_dev->epthru_pool_handle,
+   dma_pool_free(raid_dev->epthru_pool_handle,
epthru_pci_blk[i].vaddr, epthru_pci_blk[i].dma_addr);
}
-   if (raid_dev->epthru_pool_handle)
-  

[PATCH v5 18/19] usb: host: Remove remaining pci_pool in comments

[Romain Perier]

This replaces remaining occurences of pci_pool by dma_pool, as
this is the new API that could be used for that purpose.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 drivers/usb/host/ehci-hcd.c | 2 +-
 drivers/usb/host/fotg210-hcd.c  | 2 +-
 drivers/usb/host/oxu210hp-hcd.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index ac2c4ea..6e834b83 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -597,7 +597,7 @@ static int ehci_run (struct usb_hcd *hcd)
/*
 * hcc_params controls whether ehci->regs->segment must (!!!)
 * be used; it constrains QH/ITD/SITD and QTD locations.
-* pci_pool consistent memory always uses segment zero.
+* dma_pool consistent memory always uses segment zero.
 * streaming mappings for I/O buffers, like pci_map_single(),
 * can return segments above 4GB, if the device allows.
 *
diff --git a/drivers/usb/host/fotg210-hcd.c b/drivers/usb/host/fotg210-hcd.c
index 1c5b34b..ced08dc 100644
--- a/drivers/usb/host/fotg210-hcd.c
+++ b/drivers/usb/host/fotg210-hcd.c
@@ -5047,7 +5047,7 @@ static int fotg210_run(struct usb_hcd *hcd)
/*
 * hcc_params controls whether fotg210->regs->segment must (!!!)
 * be used; it constrains QH/ITD/SITD and QTD locations.
-* pci_pool consistent memory always uses segment zero.
+* dma_pool consistent memory always uses segment zero.
 * streaming mappings for I/O buffers, like pci_map_single(),
 * can return segments above 4GB, if the device allows.
 *
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index bcf531c..ed20fb3 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -2708,7 +2708,7 @@ static int oxu_run(struct usb_hcd *hcd)
 
/* hcc_params controls whether oxu->regs->segment must (!!!)
 * be used; it constrains QH/ITD/SITD and QTD locations.
-* pci_pool consistent memory always uses segment zero.
+* dma_pool consistent memory always uses segment zero.
 * streaming mappings for I/O buffers, like pci_map_single(),
 * can return segments above 4GB, if the device allows.
 *
-- 
2.9.3

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

[PATCH v5 19/19] PCI: Remove PCI pool macro functions

[Romain Perier]

Now that all the drivers use dma pool API, we can remove the macro
functions for PCI pool.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
---
 include/linux/pci.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index eb3da1a..04a0703 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1281,15 +1281,6 @@ int pci_set_vga_state(struct pci_dev *pdev, bool decode,
 #include 
 #include 
 
-#definepci_pool dma_pool
-#define pci_pool_create(name, pdev, size, align, allocation) \
-   dma_pool_create(name, >dev, size, align, allocation)
-#definepci_pool_destroy(pool) dma_pool_destroy(pool)
-#definepci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, flags, 
handle)
-#definepci_pool_zalloc(pool, flags, handle) \
-   dma_pool_zalloc(pool, flags, handle)
-#definepci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr, 
addr)
-
 struct msix_entry {
u32 vector; /* kernel uses to write allocated vector */
u16 entry;  /* driver uses to specify entry, OS writes */
-- 
2.9.3

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

[PATCH v5 16/19] usb: gadget: net2280: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/usb/gadget/udc/net2280.c | 12 ++--
 drivers/usb/gadget/udc/net2280.h |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index 8550441..089081e 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -569,7 +569,7 @@ static struct usb_request
if (ep->dma) {
struct net2280_dma  *td;
 
-   td = pci_pool_alloc(ep->dev->requests, gfp_flags,
+   td = dma_pool_alloc(ep->dev->requests, gfp_flags,
>td_dma);
if (!td) {
kfree(req);
@@ -597,7 +597,7 @@ static void net2280_free_request(struct usb_ep *_ep, struct 
usb_request *_req)
req = container_of(_req, struct net2280_request, req);
WARN_ON(!list_empty(>queue));
if (req->td)
-   pci_pool_free(ep->dev->requests, req->td, req->td_dma);
+   dma_pool_free(ep->dev->requests, req->td, req->td_dma);
kfree(req);
 }
 
@@ -3578,10 +3578,10 @@ static void net2280_remove(struct pci_dev *pdev)
for (i = 1; i < 5; i++) {
if (!dev->ep[i].dummy)
continue;
-   pci_pool_free(dev->requests, dev->ep[i].dummy,
+   dma_pool_free(dev->requests, dev->ep[i].dummy,
dev->ep[i].td_dma);
}
-   pci_pool_destroy(dev->requests);
+   dma_pool_destroy(dev->requests);
}
if (dev->got_irq)
free_irq(pdev->irq, dev);
@@ -3723,7 +3723,7 @@ static int net2280_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
 
/* DMA setup */
/* NOTE:  we know only the 32 LSBs of dma addresses may be nonzero */
-   dev->requests = pci_pool_create("requests", pdev,
+   dev->requests = dma_pool_create("requests", >dev,
sizeof(struct net2280_dma),
0 /* no alignment requirements */,
0 /* or page-crossing issues */);
@@ -3735,7 +3735,7 @@ static int net2280_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
for (i = 1; i < 5; i++) {
struct net2280_dma  *td;
 
-   td = pci_pool_alloc(dev->requests, GFP_KERNEL,
+   td = dma_pool_alloc(dev->requests, GFP_KERNEL,
>ep[i].td_dma);
if (!td) {
ep_dbg(dev, "can't get dummy %d\n", i);
diff --git a/drivers/usb/gadget/udc/net2280.h b/drivers/usb/gadget/udc/net2280.h
index 2736a95..1088c37 100644
--- a/drivers/usb/gadget/udc/net2280.h
+++ b/drivers/usb/gadget/udc/net2280.h
@@ -187,7 +187,7 @@ struct net2280 {
struct usb338x_ll_chi_regs  __iomem *ll_chicken_reg;
struct usb338x_pl_regs  __iomem *plregs;
 
-   struct pci_pool *requests;
+   struct dma_pool *requests;
/* statistics...*/
 };
 
-- 
2.9.3

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

[PATCH v5 17/19] usb: gadget: pch_udc: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Reviewed-by: Peter Senna Tschudin 
Acked-by: Felipe Balbi 
---
 drivers/usb/gadget/udc/pch_udc.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index a97da64..84dcbcd 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -355,8 +355,8 @@ struct pch_udc_dev {
vbus_session:1,
set_cfg_not_acked:1,
waiting_zlp_ack:1;
-   struct pci_pool *data_requests;
-   struct pci_pool *stp_requests;
+   struct dma_pool *data_requests;
+   struct dma_pool *stp_requests;
dma_addr_t  dma_addr;
struct usb_ctrlrequest  setup_data;
void __iomem*base_addr;
@@ -1522,7 +1522,7 @@ static void pch_udc_free_dma_chain(struct pch_udc_dev 
*dev,
/* do not free first desc., will be done by free for request */
td = phys_to_virt(addr);
addr2 = (dma_addr_t)td->next;
-   pci_pool_free(dev->data_requests, td, addr);
+   dma_pool_free(dev->data_requests, td, addr);
td->next = 0x00;
addr = addr2;
}
@@ -1539,7 +1539,7 @@ static void pch_udc_free_dma_chain(struct pch_udc_dev 
*dev,
  *
  * Return codes:
  * 0:  success,
- * -ENOMEM:pci_pool_alloc invocation fails
+ * -ENOMEM:dma_pool_alloc invocation fails
  */
 static int pch_udc_create_dma_chain(struct pch_udc_ep *ep,
struct pch_udc_request *req,
@@ -1565,7 +1565,7 @@ static int pch_udc_create_dma_chain(struct pch_udc_ep *ep,
if (bytes <= buf_len)
break;
last = td;
-   td = pci_pool_alloc(ep->dev->data_requests, gfp_flags,
+   td = dma_pool_alloc(ep->dev->data_requests, gfp_flags,
_addr);
if (!td)
goto nomem;
@@ -1770,7 +1770,7 @@ static struct usb_request *pch_udc_alloc_request(struct 
usb_ep *usbep,
if (!ep->dev->dma_addr)
return >req;
/* ep0 in requests are allocated from data pool here */
-   dma_desc = pci_pool_alloc(ep->dev->data_requests, gfp,
+   dma_desc = dma_pool_alloc(ep->dev->data_requests, gfp,
  >td_data_phys);
if (NULL == dma_desc) {
kfree(req);
@@ -1809,7 +1809,7 @@ static void pch_udc_free_request(struct usb_ep *usbep,
if (req->td_data != NULL) {
if (req->chain_len > 1)
pch_udc_free_dma_chain(ep->dev, req);
-   pci_pool_free(ep->dev->data_requests, req->td_data,
+   dma_pool_free(ep->dev->data_requests, req->td_data,
  req->td_data_phys);
}
kfree(req);
@@ -2914,7 +2914,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
void*ep0out_buf;
 
/* DMA setup */
-   dev->data_requests = pci_pool_create("data_requests", dev->pdev,
+   dev->data_requests = dma_pool_create("data_requests", >pdev->dev,
sizeof(struct pch_udc_data_dma_desc), 0, 0);
if (!dev->data_requests) {
dev_err(>pdev->dev, "%s: can't get request data pool\n",
@@ -2923,7 +2923,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
}
 
/* dma desc for setup data */
-   dev->stp_requests = pci_pool_create("setup requests", dev->pdev,
+   dev->stp_requests = dma_pool_create("setup requests", >pdev->dev,
sizeof(struct pch_udc_stp_dma_desc), 0, 0);
if (!dev->stp_requests) {
dev_err(>pdev->dev, "%s: can't get setup request pool\n",
@@ -2931,7 +2931,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
return -ENOMEM;
}
/* setup */
-   td_stp = pci_pool_alloc(dev->stp_requests, GFP_KERNEL,
+   td_stp = dma_pool_alloc(dev->stp_requests, GFP_KERNEL,
>ep[UDC_EP0OUT_IDX].td_stp_phys);
if (!td_stp) {
dev_err(>pdev->dev,
@@ -2941,7 +2941,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
dev->ep[UDC_EP0OUT_IDX].td_stp = td_stp;
 
/* data: 0 packets !? */
-   td_data = pci_pool_alloc(dev->data_requests, GFP_KERNEL,
+   td_data = dma_pool_alloc(dev->data_requests, GFP_KERNEL,
>ep[UDC_EP0OUT_IDX].td_data_phys);
if (!td_data) {
dev_err(>pdev->dev,
@@ -3021,22 +3021,21 @@ 

[PATCH v5 15/19] usb: gadget: amd5536udc: Replace PCI pool old API

[Romain Perier]

The PCI pool API is deprecated. This commit replaces the PCI pool old
API by the appropriate function with the DMA pool API.

Signed-off-by: Romain Perier 
Acked-by: Peter Senna Tschudin 
Tested-by: Peter Senna Tschudin 
---
 drivers/usb/gadget/udc/amd5536udc.c | 8 
 drivers/usb/gadget/udc/amd5536udc.h | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/amd5536udc.c 
b/drivers/usb/gadget/udc/amd5536udc.c
index ea03ca7..270876b 100644
--- a/drivers/usb/gadget/udc/amd5536udc.c
+++ b/drivers/usb/gadget/udc/amd5536udc.c
@@ -583,7 +583,7 @@ udc_alloc_request(struct usb_ep *usbep, gfp_t gfp)
 
if (ep->dma) {
/* ep0 in requests are allocated from data pool here */
-   dma_desc = pci_pool_alloc(ep->dev->data_requests, gfp,
+   dma_desc = dma_pool_alloc(ep->dev->data_requests, gfp,
>td_phys);
if (!dma_desc) {
kfree(req);
@@ -622,7 +622,7 @@ static int udc_free_dma_chain(struct udc *dev, struct 
udc_request *req)
td = phys_to_virt(td_last->next);
 
for (i = 1; i < req->chain_len; i++) {
-   pci_pool_free(dev->data_requests, td,
+   dma_pool_free(dev->data_requests, td,
  (dma_addr_t)td_last->next);
td_last = td;
td = phys_to_virt(td_last->next);
@@ -652,7 +652,7 @@ udc_free_request(struct usb_ep *usbep, struct usb_request 
*usbreq)
if (req->chain_len > 1)
udc_free_dma_chain(ep->dev, req);
 
-   pci_pool_free(ep->dev->data_requests, req->td_data,
+   dma_pool_free(ep->dev->data_requests, req->td_data,
req->td_phys);
}
kfree(req);
@@ -847,7 +847,7 @@ static int udc_create_dma_chain(
for (i = buf_len; i < bytes; i += buf_len) {
/* create or determine next desc. */
if (create_new_chain) {
-   td = pci_pool_alloc(ep->dev->data_requests,
+   td = dma_pool_alloc(ep->dev->data_requests,
gfp_flags, _addr);
if (!td)
return -ENOMEM;
diff --git a/drivers/usb/gadget/udc/amd5536udc.h 
b/drivers/usb/gadget/udc/amd5536udc.h
index 4638d70..85d5aa5 100644
--- a/drivers/usb/gadget/udc/amd5536udc.h
+++ b/drivers/usb/gadget/udc/amd5536udc.h
@@ -545,8 +545,8 @@ struct udc {
u32 __iomem *txfifo;
 
/* DMA desc pools */
-   struct pci_pool *data_requests;
-   struct pci_pool *stp_requests;
+   struct dma_pool *data_requests;
+   struct dma_pool *stp_requests;
 
/* device data */
unsigned long   phys_addr;
-- 
2.9.3

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

[PATCH 2/2] usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed

[Roger Quadros]

As per USB3.0 Specification "Table 9-20. Standard Endpoint Descriptor",
for interrupt and isochronous endpoints, wMaxPacketSize must be set to
1024 if the endpoint defines bMaxBurst to be greater than zero.

Signed-off-by: Roger Quadros 
---
 drivers/usb/gadget/function/f_uvc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index c7689d0..f8a1881 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -594,6 +594,14 @@ uvc_function_bind(struct usb_configuration *c, struct 
usb_function *f)
opts->streaming_maxpacket = clamp(opts->streaming_maxpacket, 1U, 3072U);
opts->streaming_maxburst = min(opts->streaming_maxburst, 15U);
 
+   /* For SS, wMaxPacketSize has to be 1024 if bMaxBurst is not 0 */
+   if (opts->streaming_maxburst &&
+   (opts->streaming_maxpacket % 1024) != 0) {
+   opts->streaming_maxpacket = roundup(opts->streaming_maxpacket, 
1024);
+   INFO(cdev, "overriding streaming_maxpacket to %d\n",
+opts->streaming_maxpacket);
+   }
+
/* Fill in the FS/HS/SS Video Streaming specific descriptors from the
 * module parameters.
 *
-- 
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 0/2] usb: gadget: f_uvc: SuperSpeed fixes

[Laurent Pinchart]

Hi Roger,

Thank you for the patches.

On Wednesday 08 Mar 2017 16:05:42 Roger Quadros wrote:
> Hi Laurent & Felipe,
> 
> These are some fixes for SuperSpeed case.

For both patches,

Reviewed-by: Laurent Pinchart 

> --
> cheers,
> -roger
> 
> Roger Quadros (2):
>   usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's
> wBytesPerInterval
>   usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed
> 
>  drivers/usb/gadget/function/f_uvc.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe 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/2] usb: gadget: f_uvc: SuperSpeed fixes

[Roger Quadros]

Hi Laurent & Felipe,

These are some fixes for SuperSpeed case.

--
cheers,
-roger

Roger Quadros (2):
  usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's
wBytesPerInterval
  usb: gadget: f_uvc: Sanity check wMaxPacketSize for SuperSpeed

 drivers/usb/gadget/function/f_uvc.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

-- 
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 6/6] USB: serial: ftdi_sio: allow other bases for "event_char"

[Johan Hovold]

On Wed, Mar 08, 2017 at 01:58:51PM +, Ian Abbott wrote:
> On 02/03/17 14:37, Johan Hovold wrote:
> > On Tue, Feb 28, 2017 at 12:51:28PM +, Ian Abbott wrote:
> >> The 'store' function for the "event_char" device attribute currently
> >> expects a base 10 value.  The value is composed of an enable bit in bit
> >> 8 and an 8-bit "event character" code in bits 7 to 0.  It seems
> >> reasonable to allow hexadecimal and octal numbers to be written to the
> >> device attribute in addition to decimal.  Make it so.
> >>
> >> Signed-off-by: Ian Abbott 
> >> ---
> >>  drivers/usb/serial/ftdi_sio.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> >> index e6785d84280b..a007ec8238eb 100644
> >> --- a/drivers/usb/serial/ftdi_sio.c
> >> +++ b/drivers/usb/serial/ftdi_sio.c
> >> @@ -1742,7 +1742,7 @@ static ssize_t store_event_char(struct device *dev,
> >>unsigned int v;
> >>int rv;
> >>
> >> -  rv = kstrtouint(valbuf, 10, );
> >> +  rv = kstrtouint(valbuf, 0, );
> >>if (rv)
> >>return rv;
> >
> > How about changing the debug printk just below to use "0x%02x" as well?
> 
> Okay, although "0x%03x" would be better since it's a 9-bit value.

Yeah, I know that the 9th bit is the enable bit, but figured "0x%02x"
was still preferred as enable would be more clearly separated from
"disable" that way. But looking at the result now, you're right, %03x is
probably better.

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 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t

[Johannes Thumshirn]

On 03/08/2017 02:48 PM, Reshetova, Elena wrote:

On 03/06/2017 03:21 PM, Elena Reshetova wrote:

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.


The subject is wrong, should be something like "scsi: libfc convert
fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.

Other than that
Acked-by: Johannes Thumshirn 


Turns out that it is better that all these patches go through the respective 
maintainer trees, if present.
If I send an updated patch (with subject fixed), could you merge it through 
your tree?


Yes, but this would be the normal scsi tree from Martin and James.

Please include my Ack in the re-sends.

Thanks a lot,
Johannes


--
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe 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 v17 2/3] usb: USB Type-C connector class

[Guenter Roeck]

On 03/07/2017 10:50 PM, Peter Chen wrote:



You mean type-C trigger an ACPI event, and this ACPI event can notify
related USB controller driver doing role switch?


No (firmware programs the dual-role hw/registers), but never mind.
That could be the case.


If it is correct, there is a notifier between type-C and USB
controller driver, how to define this notifier for non-ACPI platform?


Once there is a platform with Type-C like that, the problem needs to
be solved. However..


I'm not commenting on Roger's dual role patch series, but I don't
really think it should be mixed with Type-C. USB Type-C and USB
Power Delivery define their own ways of handling the roles, and they
are not limited to the data role only. Things like OTG for example
will, and actually can not be supported. With Type-C we will have
competing state machines compared to OTG. The dual-role framework
may be useful on systems that provide more traditional connectors,
which possibly have the ID-pin like micro-AB, and possibly also
support OTG. It can also be something that exist in parallel with the Type-C

class, but there just can not be any dependencies between the two.




Yes, there are two independent things. But if the kernel doesn't have
a notifier between type-C message sender (type-c class) and message
receiver (like USB controller driver for role switch or other drivers
for alternate mode message), we had to find some ways at userspace.


..what ever the solution is, it really can't rely on user space.



... and, at least for our application, using extcon for the necessary 
notifications works
just fine.



I see, that means you have a hardware signal to notify role switch.



In our case the Type-C protocol manager (including alternate mode handling)
is implemented in an EC. The EC signals the extcon-cros_ec driver, which
in turn signals the phy driver as well as the DP driver. The Type-C class
is orthogonal; extcon-cros_ec will also register with the Type-C class code
once that is upstream.

As mentioned earlier, using extcon for signaling was the most convenient means
for us to pass events around. I am more than open to change it to a bus,
if that can be made to work - we'd have to keep in mind though that this code
already works without Type-C infrastructure and is for the most part already
upstream (the rk3399 code it ties into is upstream, and extcon-cros_ec has been
submitted as https://patchwork.kernel.org/patch/9583045/).

As for to how to handle alternate mode if the Type-C protocol manager
(TCPM) is implemented in the kernel - I have not yet implemented it yet,
but my thinking goes along the line described by Heikki in his last e-mail.

Note that we also have a kernel driver for FUSB302 which ties into my tcpm
driver. I'll have to check if that is public yet and if I or someone
else can publish it if there is interest.

Guenter

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

[PATCH 1/2] usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's wBytesPerInterval

[Roger Quadros]

The streaming_maxburst module parameter is 0 offset (0..15)
so we must add 1 while using it for wBytesPerInterval
calculation for the SuperSpeed companion descriptor.

Without this host uvcvideo driver will always see the wrong
wBytesPerInterval for SuperSpeed uvc gadget and may not find
a suitable video interface endpoint.
e.g. for streaming_maxburst = 0 case it will always
fail as wBytePerInterval was evaluating to 0.

Cc: sta...@vger.kernel.org
Signed-off-by: Roger Quadros 
---
 drivers/usb/gadget/function/f_uvc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index 29b41b5..c7689d0 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -625,7 +625,7 @@ uvc_function_bind(struct usb_configuration *c, struct 
usb_function *f)
uvc_ss_streaming_comp.bMaxBurst = opts->streaming_maxburst;
uvc_ss_streaming_comp.wBytesPerInterval =
cpu_to_le16(max_packet_size * max_packet_mult *
-   opts->streaming_maxburst);
+   (opts->streaming_maxburst + 1));
 
/* Allocate endpoints. */
ep = usb_ep_autoconfig(cdev->gadget, _control_ep);
-- 
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 4/6] USB: serial: ftdi_sio: only allow valid event_char values

[Johan Hovold]

On Wed, Mar 08, 2017 at 01:46:12PM +, Ian Abbott wrote:
> On 02/03/17 14:29, Johan Hovold wrote:
> > On Tue, Feb 28, 2017 at 12:51:26PM +, Ian Abbott wrote:
> >> The "event_char" device attribute value, when written, is interpreted as
> >> an enable bit in bit 8, and an "event character" in bits 7 to 0.  Return
> >> an error for out-of-range values.
> >>
> >> Signed-off-by: Ian Abbott 
> >> ---
> >>  drivers/usb/serial/ftdi_sio.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> >> index 2da99875cecb..2662fc3b49c5 100644
> >> --- a/drivers/usb/serial/ftdi_sio.c
> >> +++ b/drivers/usb/serial/ftdi_sio.c
> >> @@ -1738,6 +1738,9 @@ static ssize_t store_event_char(struct device *dev,
> >>int v = simple_strtoul(valbuf, NULL, 10);
> >>int rv;
> >>
> >> +  if (v < 0 || v >= 0x200)
> >> +  return -EINVAL;
> >> +
> >
> > v < 0 is always false here due to the unsigned simple_strtoul above,
> > which continues to accept negative values after this change.
> 
> Not necessarily.  Writing 18446744073709551615 (2^64 - 1) to the 
> "event_char" attribute file on a 64-bit system will set v to -1, for 
> example.

Yeah, my bad, you get negative values on overflow (> INT_MAX) (also on
32-bit). But we'd still be accepting negative values after this change.

> > It may be better to combine this with the kstrtouint conversion.
> 
> Yes to handle all invalid inputs in a consistently.  That also means 
> changing patch 3 (for the "latency_timer" attribute) in the same way.

Yep.

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 2/6] USB: serial: ftdi_sio: detect BM chip with iSerialNumber bug

[Ian Abbott]

On 02/03/17 14:17, Johan Hovold wrote:

On Tue, Feb 28, 2017 at 12:51:24PM +, Ian Abbott wrote:

If a BM type chip has iSerialNumber set to 0 in its EEPROM, an incorrect
value is read from the bcdDevice field of the USB descriptor, making it
look like an AM type chip.  Attempt to correct this in
ftdi_determine_type() by attempting to read the latency timer for an AM
type chip.  If that succeeds, assume it is a BM type chip.

Currently, read_latency_timer() bails out without reading the latency
timer for an AM type chip, so factor out the guts of
read_latency_timer() into a new function _read_latency_timer() that
attempts to read the latency timer regardless of chip type, and returns
either the latency timer value or a negative error number.

Signed-off-by: Ian Abbott 
---
 drivers/usb/serial/ftdi_sio.c | 38 ++
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 72314734dfd0..a1b90f4184a7 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c



@@ -1609,9 +1623,17 @@ static void ftdi_determine_type(struct usb_serial_port 
*port)
priv->baud_base = 1200 / 16;
} else if (version < 0x400) {
/* Assume it's an FT8U232AM (or FT8U245AM) */
-   /* (It might be a BM because of the iSerialNumber bug,
-* but it will still work as an AM device.) */
priv->chip_type = FT8U232AM;
+   /*
+* It might be a BM type because of the iSerialNumber bug.
+* If the latency timer is readable, assume it is BM type.
+*/
+   if (_read_latency_timer(port) >= 0) {


Would it be possible to only try to read the latency timer when
iSerialNumber is 0?


Okay, I'll change that in v2 patch series.

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
--
To unsubscribe from this list: send the line "unsubscribe 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 v17 2/3] usb: USB Type-C connector class

[Heikki Krogerus]

On Tue, Mar 07, 2017 at 11:30:54PM +0100, Mats Karrman wrote:
> > > So, both the DP controller and the USB PD phy are I2C devices, and now I 
> > > have to make them both
> > > attach to the AM bus as well?
> > The DP controller would provide the driver and the USB PD phy
> > (actually, the typec class) the device.
> > 
> > Would it be a problem to register these I2C devices with some other
> > subsystem, was it extcon or something like AM bus? It really would not
> > be that uncommon. Or have I misunderstood your question?
> 
> OK, so a bus could be used for drivers to find each other but it still does 
> not say
> anything about how those drivers are supposed to communicate so that must be 
> prescribed
> separately, right?

Yes.

> If I read Heikki's original suggestion I understand it like the DP driver 
> would be
> responsible for AM specific USB PD/VDM communication. But wouldn't that lead
> to a lot of code duplication since the AM protocol is the same for all 
> drivers of
> a kind?

No that's not what I mean. I'm still mixing your PD controller with
something else above, sorry about that. Your PD controller driver
should not ideally even need to be aware of Type-C connector, right?
It definitely does not need to do any USB PD communication.

I would imagine you have on top of the DP controller, a mux (which
could be a DP/USB3 PHY like on Rockchip RK3399, discrete mux like
Pericom PI3USB30532, or something else), and a USB Type-C PHY or USB
PD controller. The bus would be tying the mux to the Type-C port (PHY
or PD controller) and its partner (note that it does not tie the mux
to the DP controller). Please correct me if I'm wrong about your
hardware.

Assuming that is how your board roughly looks like, the driver for the
mux would be the driver for the DP altmode devices. That driver would
be the one converting things like the Attention messages notifying
about HPD into toggling of GPIOs, or what ever is needed on your
board, etc.

The actual PD communication with VDMs should be considered as just the
protocol, so we probable should have "protocol drivers". For example
DP alternate mode VDMs and communication will always be the same
despite of the hardware. The DP alternate mode "protocol driver" would
then be tied to the alternate mode device for the partner, and that
driver could have its own hooks for what ever is needed, like HPD
signal handling, configuration changes, whatever. In any case,
hopefully making things easy and straightforward for the "mux driver",
_so that it does not need to care about the actual PD communication_.


Thanks,

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

[PATCH v2] HID: remove initial reading of reports at connect

[Benjamin Tissoires]

It looks like a bunch of devices do not like to be polled
for their reports at init time. When you look into the details,
it seems that for those that are requiring the quirk
HID_QUIRK_NO_INIT_REPORTS, the driver fails to retrieve part
of the features/inputs while others (more generic) work.

IMO, it should be acceptable to remove the need for the quirk
in the general case. On the small amount of cases where
we actually need to read the current values, the driver
in charge (hid-mt or wacom) already retrieves the features
manually.

There are 2 cases where we might need to retrieve the reports at
init:
1. hiddev devices with specific use-space tool
2. a device that would require the driver to fetch a specific
   feature/input at plug

For case 2, I have seen this a few time on hid-multitouch. It
is solved in hid-multitouch directly by fetching the feature.
I hope it won't be too common and this can be solved on a per-case
basis (crossing fingers).

For case 1, we moved the implementation of HID_QUIRK_NO_INIT_REPORTS
in hiddev. When somebody starts calling ioctls that needs an initial
update, the hiddev device will fetch the initial state of the reports
to mimic the current behavior. This adds a small amount of time during
the first HIDIOCGUSAGE(S), but it should be acceptable in
most cases. To keep the currently known broken devices, we have to
keep around HID_QUIRK_NO_INIT_REPORTS, but the scope will only be
for hiddev.

Note that I don't think hidraw would be affected and I checked that
the FF drivers that need to interact with the report fields are all
using output reports, which are not initialized by
usbhid_init_reports().

NO_INIT_INPUT_REPORTS is then replaced by HID_QUIRK_NO_INIT_REPORTS:
there is no point keeping it for just one device.

Signed-off-by: Benjamin Tissoires 

---

changes in v2:
- amended subject (was: HID: get rid of HID_QUIRK_NO_INIT_REPORTS)
- kept around HID_QUIRK_NO_INIT_REPORTS
- force retrieval of reports at HIDIOCGUSAGE(S) in hiddev
---
 drivers/hid/i2c-hid/i2c-hid.c   | 63 -
 drivers/hid/usbhid/hid-core.c   | 11 ++-
 drivers/hid/usbhid/hid-quirks.c |  2 +-
 drivers/hid/usbhid/hiddev.c | 13 +
 include/linux/hid.h |  2 +-
 5 files changed, 18 insertions(+), 73 deletions(-)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 40f0acc..52f1776 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -508,66 +508,6 @@ static int i2c_hid_get_report_length(struct hid_report 
*report)
report->device->report_enum[report->type].numbered + 2;
 }
 
-static void i2c_hid_init_report(struct hid_report *report, u8 *buffer,
-   size_t bufsize)
-{
-   struct hid_device *hid = report->device;
-   struct i2c_client *client = hid->driver_data;
-   struct i2c_hid *ihid = i2c_get_clientdata(client);
-   unsigned int size, ret_size;
-
-   size = i2c_hid_get_report_length(report);
-   if (i2c_hid_get_report(client,
-   report->type == HID_FEATURE_REPORT ? 0x03 : 0x01,
-   report->id, buffer, size))
-   return;
-
-   i2c_hid_dbg(ihid, "report (len=%d): %*ph\n", size, size, buffer);
-
-   ret_size = buffer[0] | (buffer[1] << 8);
-
-   if (ret_size != size) {
-   dev_err(>dev, "error in %s size:%d / ret_size:%d\n",
-   __func__, size, ret_size);
-   return;
-   }
-
-   /* hid->driver_lock is held as we are in probe function,
-* we just need to setup the input fields, so using
-* hid_report_raw_event is safe. */
-   hid_report_raw_event(hid, report->type, buffer + 2, size - 2, 1);
-}
-
-/*
- * Initialize all reports
- */
-static void i2c_hid_init_reports(struct hid_device *hid)
-{
-   struct hid_report *report;
-   struct i2c_client *client = hid->driver_data;
-   struct i2c_hid *ihid = i2c_get_clientdata(client);
-   u8 *inbuf = kzalloc(ihid->bufsize, GFP_KERNEL);
-
-   if (!inbuf) {
-   dev_err(>dev, "can not retrieve initial reports\n");
-   return;
-   }
-
-   /*
-* The device must be powered on while we fetch initial reports
-* from it.
-*/
-   pm_runtime_get_sync(>dev);
-
-   list_for_each_entry(report,
-   >report_enum[HID_FEATURE_REPORT].report_list, list)
-   i2c_hid_init_report(report, inbuf, ihid->bufsize);
-
-   pm_runtime_put(>dev);
-
-   kfree(inbuf);
-}
-
 /*
  * Traverse the supplied list of reports and find the longest
  */
@@ -789,9 +729,6 @@ static int i2c_hid_start(struct hid_device *hid)
return ret;
}
 
-   if (!(hid->quirks & HID_QUIRK_NO_INIT_REPORTS))
-   i2c_hid_init_reports(hid);
-
return 0;
 }
 
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 

RE: [PATCH 21/29] drivers, s390: convert fc_fcp_pkt.ref_cnt from atomic_t to refcount_t

[Reshetova, Elena]

> On 03/06/2017 03:21 PM, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> 
> The subject is wrong, should be something like "scsi: libfc convert
> fc_fcp_pkt.ref_cnt from atomic_t to refcount_t" but not s390.
> 
> Other than that
> Acked-by: Johannes Thumshirn 

Turns out that it is better that all these patches go through the respective 
maintainer trees, if present. 
If I send an updated patch (with subject fixed), could you merge it through 
your tree?

Best Regards,
Elena.
> 
> --
> Johannes Thumshirn  Storage
> jthumsh...@suse.de+49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe 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: [Xen-devel] [PATCH 29/29] drivers, xen: convert grant_map.users from atomic_t to refcount_t

[Reshetova, Elena]

> On 03/06/2017 09:21 AM, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/xen/gntdev.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> Reviewed-by: Boris Ostrovsky 

Is there a tree that can take this change? Turns out it is better to propagate 
changes via separate trees and only leftovers can be taken via Greg's tree.  

Best Regards,
Elena.

Re: usb: gadget: uvc: configfs: fails to enumerate in HOST

[Bin Liu]

On Wed, Mar 08, 2017 at 01:59:50PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> (no top-posting, please)
> 
> Ganesh Biradar  writes:
> > Hi Felipe,
> >
> > I'm using TI latest vision sdk which has support for 4.4 kernel. i'm
> > not getting much help from TI e2e that's why i am asking here. can't

I don't think it is fair, you posted on TI e2e a few hours after started this
thread, then complain not getting much help from TI e2e at here?

But anyway, after all your configfs steps, have you run a userspace
application, such as uvc-gadget [1], to feed the video stream?

[1] git://git.ideasonboard.org/uvc-gadget.git

Regards,
-Bin.

> > try v4.10 or any other kernel as it has dependencies with respect to
> > SDK.
> 
> sorry, but you need to ask TI for help.
> 
> -- 
> balbi


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

Re: [PATCH 6/6] USB: serial: ftdi_sio: allow other bases for "event_char"

[Ian Abbott]

On 02/03/17 14:37, Johan Hovold wrote:

On Tue, Feb 28, 2017 at 12:51:28PM +, Ian Abbott wrote:

The 'store' function for the "event_char" device attribute currently
expects a base 10 value.  The value is composed of an enable bit in bit
8 and an 8-bit "event character" code in bits 7 to 0.  It seems
reasonable to allow hexadecimal and octal numbers to be written to the
device attribute in addition to decimal.  Make it so.

Signed-off-by: Ian Abbott 
---
 drivers/usb/serial/ftdi_sio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index e6785d84280b..a007ec8238eb 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1742,7 +1742,7 @@ static ssize_t store_event_char(struct device *dev,
unsigned int v;
int rv;

-   rv = kstrtouint(valbuf, 10, );
+   rv = kstrtouint(valbuf, 0, );
if (rv)
return rv;


How about changing the debug printk just below to use "0x%02x" as well?


Okay, although "0x%03x" would be better since it's a 9-bit value.

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
--
To unsubscribe from this list: send the line "unsubscribe 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/6] USB: serial: ftdi_sio: only allow valid event_char values

[Ian Abbott]

On 02/03/17 14:29, Johan Hovold wrote:

On Tue, Feb 28, 2017 at 12:51:26PM +, Ian Abbott wrote:

The "event_char" device attribute value, when written, is interpreted as
an enable bit in bit 8, and an "event character" in bits 7 to 0.  Return
an error for out-of-range values.

Signed-off-by: Ian Abbott 
---
 drivers/usb/serial/ftdi_sio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 2da99875cecb..2662fc3b49c5 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1738,6 +1738,9 @@ static ssize_t store_event_char(struct device *dev,
int v = simple_strtoul(valbuf, NULL, 10);
int rv;

+   if (v < 0 || v >= 0x200)
+   return -EINVAL;
+


v < 0 is always false here due to the unsigned simple_strtoul above,
which continues to accept negative values after this change.


Not necessarily.  Writing 18446744073709551615 (2^64 - 1) to the 
"event_char" attribute file on a 64-bit system will set v to -1, for 
example.



It may be better to combine this with the kstrtouint conversion.


Yes to handle all invalid inputs in a consistently.  That also means 
changing patch 3 (for the "latency_timer" attribute) in the same way.



dev_dbg(>dev, "%s: setting event char = %i\n", __func__, v);

rv = usb_control_msg(udev,


Johan



--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
--
To unsubscribe from this list: send the line "unsubscribe 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 3/6] USB: serial: ftdi_sio: only allow valid latency timer values

[Ian Abbott]

On 02/03/17 14:22, Johan Hovold wrote:

On Tue, Feb 28, 2017 at 12:51:25PM +, Ian Abbott wrote:

Valid latency timer values are between 1 ms and 255 ms in 1 ms steps.
The store function for the "latency_timer" device attribute currently
allows any value, although only the lower 8-bits will be written to the
latency timer.  Return an error for out-of-range values.


And in fact, 0 is currently used (and accepted by the device) if a
negative value is provided.


Yes, although for the same reason that writing the value 'foo' to the 
"latency_timer" device attribute results in 0 being used!





Signed-off-by: Ian Abbott 
---
 drivers/usb/serial/ftdi_sio.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index a1b90f4184a7..2da99875cecb 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1716,6 +1716,9 @@ static ssize_t latency_timer_store(struct device *dev,
int v = simple_strtoul(valbuf, NULL, 10);
int rv;

+   if (v < 1 || v > 255)
+   return -EINVAL;
+


We probably still need to accept 0 here, which seems to give a timer of
1 ms, as someone may be relying on that behaviour already.


Yes, I just partially confirmed that 0 gives a short latency timeout 
like 1, although I never measured it accurately.  (I only judged it from 
responsiveness of typed characters being echoed back through a serial 
loop-back connector.)


I'll fix that in v2 patch series.




priv->latency = v;
rv = write_latency_timer(port);
if (rv < 0)


Johan




--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
--
To unsubscribe from this list: send the line "unsubscribe 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: Implementing MSI support on my platform

[Mason]

On 07/03/2017 17:47, Mason wrote:

> As suggested by Marc, I'm trying to adapt
>   drivers/pci/host/pcie-altera-msi.c
> to my platform.

For my own reference, I have enabled verbose XHCI debug logs.
I have highlighted suspicious output with *

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.9.7-1-rc2 (gcc version 5.3.1 20160113 (Linaro 
GCC 5.3-2016.02) ) #53 SMP PREEMPT Wed Mar 8 10:53:55 CET 2017
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt:Machine model: Sigma Designs SMP8758 Vantage-1172 Rev E1
[0.00] debug: ignoring loglevel setting.
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 65536
[0.00] free_area_init_node: node 0, pgdat c1023980, node_mem_map 
cfdf9000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65536 pages, LIFO batch:15
[0.00] percpu: Embedded 14 pages/cpu @cfdd7000 s24960 r8192 d24192 
u57344
[0.00] pcpu-alloc: s24960 r8192 d24192 u57344 alloc=14*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 65024
[0.00] Kernel command line: mem=256M ignore_loglevel 
console=ttyS0,115200 earlyprintk
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 243976K/262144K available (4096K kernel code, 147K 
rwdata, 900K rodata, 10240K init, 233K bss, 18168K reserved, 0K cma-reserved, 
0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc050   (5088 kB)
[0.00]   .init : 0xc060 - 0xc100   (10240 kB)
[0.00]   .data : 0xc100 - 0xc1024d20   ( 148 kB)
[0.00].bss : 0xc1024d20 - 0xc105f200   ( 234 kB)
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 ID prefetch enabled, offset 4 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 cache controller enabled, 8 ways, 512 kB
[0.00] L2C-310: CACHE_ID 0x41c8, AUX_CTRL 0x72860401
[0.00] clocksource: tango-xtal: mask: 0x max_cycles: 
0x, max_idle_ns: 70787423951 ns
[0.04] sched_clock: 32 bits at 27MHz, resolution 37ns, wraps every 
79536431085ns
[0.007960] Switching to timer-based delay loop, resolution 37ns
[0.014323] Console: colour dummy device 80x30
[0.018896] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 54.25 BogoMIPS (lpj=9)
[0.029314] pid_max: default: 32768 minimum: 301
[0.034131] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.040871] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.048514] CPU: Testing write buffer coherency: ok
[0.053725] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.059550] Setting up static identity map for 0x8010 - 0x80100034
[0.120459] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.120523] Brought up 2 CPUs
[0.129374] SMP: Total of 2 processors activated (108.50 BogoMIPS).
[0.135764] CPU: All CPU(s) started in SVC mode.
[0.141062] devtmpfs: initialized
[0.145449] VFP support v0.3: implementor 41 architecture 3 part 30 variant 
9 rev 4
[0.153552] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 6370867519511994 ns
[0.163845] NET: Registered protocol family 16
[0.169109] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.177113] tango_pcie_init
[0.180010] [2e000] = ff00
[0.183187] [2e004] = ff00
[0.186346] [2e008] = ff00
[0.189515] [2e00c] = ff00
[0.192674] [2e010] = ff00
[0.195842] [2e014] = ff00
[0.199000] [2e018] = ff00
[0.202168] [2e01c] = ff00
[0.205326] [2e020] = 4ab099f2
[0.208492] [2e024] = 88b09c82

[PATCH] usb: dwc3: gadget: make to increment req->remaining in all cases

[Felipe Balbi]

Sometimes, we might get a completion for a TRB which is left with HWO
bit. Even in these cases, we should increment req->remaining to
properly report total transferred size. I noticed this while debuggin
a separate problem seen with MSC tests from USBCV. Sometimes we would
erroneously report a completion for a 512-byte transfer when, in
reality, we transferred 0 bytes.

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

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 3db5eeae2bfb..0d75158e43fe 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2189,12 +2189,12 @@ static int __dwc3_cleanup_done_trbs(struct dwc3 *dwc, 
struct dwc3_ep *dep,
return 1;
}
 
-   if ((trb->ctrl & DWC3_TRB_CTRL_HWO) && status != -ESHUTDOWN)
-   return 1;
-
count = trb->size & DWC3_TRB_SIZE_MASK;
req->remaining += count;
 
+   if ((trb->ctrl & DWC3_TRB_CTRL_HWO) && status != -ESHUTDOWN)
+   return 1;
+
if (dep->direction) {
if (count) {
trb_status = DWC3_TRB_SIZE_TRBSTS(trb->size);
-- 
2.11.0.295.gd7dffce1ce

--
To unsubscribe from this list: send the line "unsubscribe 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] usb: gadget: udc: atmel: fix debug output

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
> The debug output now contains the wrong variable, as seen from the compiler
> warning:
>
> drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable':
> drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>   DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
>
> This changes the debug output the same way as the other code.
>
> Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation 
> scheme")
> Signed-off-by: Arnd Bergmann 
> Acked-by: Alexandre Belloni 
> Acked-by: Nicolas Ferre 
> ---
> Originally this broke on Feb 1 and I sent this fix,
> I resent it after it wasn't applied by Feb 22.
>
> This is now one of only two build regressions that made it into
> 4.11-rc1 that are still broken on linux-next. Please apply

heh, it's in my queue. Just gimme time, I have a day job that's 100%
dedicated to mainline ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: usb: gadget: uvc: configfs: fails to enumerate in HOST

[Felipe Balbi]

Hi,

(no top-posting, please)

Ganesh Biradar  writes:
> Hi Felipe,
>
> I'm using TI latest vision sdk which has support for 4.4 kernel. i'm
> not getting much help from TI e2e that's why i am asking here. can't
> try v4.10 or any other kernel as it has dependencies with respect to
> SDK.

sorry, but you need to ask TI for help.

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

[Felipe Balbi]

Hi,

Felipe Balbi  writes:
>>> I've been looking at this and based on sniffer and dwc3 tracepoints, it
>>> seems like dwc3 is behaving properly. The real issue seems to be that
>>> g_mass_storage isn't queueing a new request to IN endpoint.
>>>
>>> I'll continue debugging this and try to find a solution that doesn't
>>> involve reverting $subject.
>>
>> oh no, wait. ep2out misses XferInProgress:
>>
>> file-storage-1592  [000] d..1   152.809922: dwc3_ep_queue: ep2out: req 
>> 88003cd6ee40 length 0/512 zsI ==> -115
>> file-storage-1592  [000] d..1   152.809931: dwc3_prepare_trb: ep2out: 
>> 3/8 trb 88003a196050 buf 2d5e4000 size 512 ctrl 0819 
>> (HlcS:sC:normal)
>> file-storage-1592  [000] d..1   152.809942: dwc3_gadget_ep_cmd: ep2out: 
>> cmd 'Update Transfer' [262151] params    --> status: 
>> Successful
>> file-storage-1592  [000]    152.809951: usb_ep_queue: ep2out: length 
>> 0/512 sgs 0/0 stream 0 zsI status -115 --> 0
>>  irq/34-dwc3-1593  [001] d..1   152.810212: dwc3_event: event 
>> (c040): ep0out: Transfer Complete [Setup Phase]
>>  irq/34-dwc3-1593  [001] d..1   152.810218: dwc3_ctrl_req: bRequestType 
>> 02 bRequest 01 wValue  wIndex 0002 wLength 0
>>  irq/34-dwc3-1593  [001] d..1   152.810228: __dwc3_gadget_ep_set_halt: 
>> ep2out: NOT stalled
>>
>> Sniffer shows me this completing, but I don't see IRQ for this.
>
> BTW, I just tested without $subject and it fails the same way. This is
> caused by something else. Can you rerun your bisect while I look at the
> problem here?

Okay, found it. This is caused by the ep_dequeue bug that I already
fixed. see [1] for that

[1] https://marc.info/?i=20170217105759.24356-1-felipe.ba...@linux.intel.com

-- 
balbi


signature.asc
Description: PGP signature

USB3.0 regression on ipq806x

[Thomas Reifferscheid]

Hi list! I'm running into a USB3.0 regression on ipq806x hardware. 
Consider one physical USB port as one linux-4.9 xHCI HC. It comes with 
two USB busses with one logical USB port each. One high-speed port and 
one superspeed port port.


] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
] ehci-platform: EHCI generic platform driver
] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
] ohci-platform: OHCI generic platform driver
] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
] xhci-hcd xhci-hcd.0.auto: hcc params 0x0228f065 hci version 0x100 
quirks 0x00010010

] xhci-hcd xhci-hcd.0.auto: irq 168, io mem 0x1100
] hub 1-0:1.0: USB hub found
] hub 1-0:1.0: 1 port detected
] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
] usb usb2: We don't know the algorithms for LPM for this host, 
disabling LPM.

] hub 2-0:1.0: USB hub found
] hub 2-0:1.0: 1 port detected
] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 3
] xhci-hcd xhci-hcd.1.auto: hcc params 0x0228f065 hci version 0x100 
quirks 0x00010010

] xhci-hcd xhci-hcd.1.auto: irq 169, io mem 0x1000
] hub 3-0:1.0: USB hub found
] hub 3-0:1.0: 1 port detected
] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 4
] usb usb4: We don't know the algorithms for LPM for this host, 
disabling LPM.

] hub 4-0:1.0: USB hub found
] hub 4-0:1.0: 1 port detected

Everything is working just fine when I'm waiting for the host to have 
finished starting up and then go on with inserting USB2.0 or USB3.0 devices.


] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd

The bug however:
Inserting a pendrive/thumbdrive first and next power on the host Linux 
3.4.103, 4.4.49, 4.9.10 all would be detecting a high-speed and a 
superspeed device at the same time (one for each logical USB port) and 
would make the xHCI HC getting halted just 10 seconds later.


] usb 3-1: new high-speed USB device number 2 using xhci-hcd
] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
+10s:
] xhci-hcd xhci-hcd.1.auto: xHCI host not responding to stop endpoint 
command.

] xhci-hcd xhci-hcd.1.auto: Assuming host is dying, halting host.
] xhci-hcd xhci-hcd.1.auto: Host not halted after 16000 microseconds.
] xhci-hcd xhci-hcd.1.auto: Non-responsive xHCI host is not halting.
] xhci-hcd xhci-hcd.1.auto: Completing active URBs anyway.
] xhci-hcd xhci-hcd.1.auto: HC died; cleaning up
] usb usb3-port1: couldn't allocate usb_device
] usb 4-1: USB disconnect, device number 2


Having enabled USB_DEBUG and xhci_dbg() from the drivers/usb/Kconfig and 
drivers/usb/Makefile files I was able to find three working "WORKAROUNDS".

1. Increase HUB_ROOT_RESET_TIME from 50 to "more than 130" in core/hub.c

--- drivers/usb/core/hub.c.orig 2017-03-05 14:26:42.248122743 +0100
+++ drivers/usb/core/hub.c  2017-03-05 14:26:50.072122785 +0100
@@ -2544,7 +2544,7 @@
 #define SET_CONFIG_TRIES   (2 * (use_both_schemes + 1))
 #define USE_NEW_SCHEME(i)  ((i) / 2 == (int)old_scheme_first)
-#define HUB_ROOT_RESET_TIME50  /* times are in msec */
+#define HUB_ROOT_RESET_TIME150 /* times are in msec */
 #define HUB_SHORT_RESET_TIME   10
 #define HUB_BH_RESET_TIME  50
 #define HUB_LONG_RESET_TIME200



2. In core/hub.c static int hub_port_wait_reset()

--- drivers/usb/core/hub.c.orig 2017-03-05 14:26:42.248122743 +0100
+++ drivers/usb/core/hub.c  2017-03-05 14:28:29.912123314 +0100
@@ -2603,7 +2603,7 @@
return ret;
 /* The port state is unknown until the reset completes. */
-   if (!(portstatus & USB_PORT_STAT_RESET))
+   if (!(portstatus & USB_PORT_STAT_RESET) && !(portstatus 
& USB_PORT_STAT_HIGH_SPEED))

 break;
 /* switch to the long delay after two short delay 
failures */



3. Follow the Netgear approach in their GPL'ed 3.4.103 kernel and send 
the root_hub in another reset() during init() which would come back with 
-ENOTCONN.


--- drivers/usb/core/hub.c.orig 2017-03-05 14:26:42.248122743 +0100
+++ drivers/usb/core/hub.c  2017-03-05 14:35:16.896125472 +0100
@@ -4269,6 +4269,13 @@
retval = hub_port_reset(hub, port1, udev, delay, false);
if (retval < 0) /* error or disconnect */
goto fail;
+
+if (udev->speed != USB_SPEED_SUPER) {
+retval = hub_port_reset(hub, port1, udev, delay, false);
+if (retval < 0)
+goto fail;
+}
+
/* success, speed is known */
 retval = -ENODEV;



All these 3 above fixes are fixing the observed behavior, that is the 
thumbdrive/pendrive no longer gets recognized as high-speed device and 
superspeed device but 

RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

[Felipe Balbi]

Hi,

Felipe Balbi  writes:
>> Thinh Nguyen  writes:
  drivers/usb/dwc3/gadget.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
 index 6faf484e5dfc..0a664d8eba3f 100644
 --- a/drivers/usb/dwc3/gadget.c
 +++ b/drivers/usb/dwc3/gadget.c
 @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep
 *dep, int value, int protocol)
unsigned transfer_in_flight;
unsigned started;
 
 +  if (dep->flags & DWC3_EP_STALL)
 +  return 0;
 +
if (dep->number > 1)
trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
else
 @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep
 *dep, int value, int protocol)
else
dep->flags |= DWC3_EP_STALL;
} else {
 +  if (!(dep->flags & DWC3_EP_STALL))
 +  return 0;
 
ret = dwc3_send_clear_stall_ep_cmd(dep);
if (ret)
 --
 2.11.0.295.gd7dffce1ce
 
 --
>>>
>>> I encounter an issue when I test mainline with USB 3 CV MSC test and
>>> bisected to this patch.
>>>
>>> Tester: USB 3 CV test (v2.1.3.0).
>>> Function Driver: f_mass_storage
>>> Reproducibility: always 
>>>
>>> The failure occurs under MSC Error Recovery Test (TD 1.4).
>>>
>>> Failure from the test sequence as follow (MSC compliance test spec) :
>>> 1. Place the device in the desired starting state.
>>> 2. Issue a Case 9 CBW (see Table 2) but with invalid signature of 
>>> 0xDEADBEEF.
>>> 3. Issue several In requests to the Bulk-Only Data Interface Bulk In 
>>> endpoint. Verify a
>>> STALL handshake is returned. If STALL handshake is not returned, skip to 
>>> step 11.
>>> 4. Issue a Get_Status(endpoint) request targeting the Bulk-Only Data 
>>> Interface bulk In
>>> endpoint. Verify that it completes normally, reports endpoint halt status.
>>>
>>>  ***After this point the device idles for 10 seconds and resets. ***
>>>
>>> Test fails.
>>
>> I've been looking at this and based on sniffer and dwc3 tracepoints, it
>> seems like dwc3 is behaving properly. The real issue seems to be that
>> g_mass_storage isn't queueing a new request to IN endpoint.
>>
>> I'll continue debugging this and try to find a solution that doesn't
>> involve reverting $subject.
>
> oh no, wait. ep2out misses XferInProgress:
>
> file-storage-1592  [000] d..1   152.809922: dwc3_ep_queue: ep2out: req 
> 88003cd6ee40 length 0/512 zsI ==> -115
> file-storage-1592  [000] d..1   152.809931: dwc3_prepare_trb: ep2out: 3/8 
> trb 88003a196050 buf 2d5e4000 size 512 ctrl 0819 
> (HlcS:sC:normal)
> file-storage-1592  [000] d..1   152.809942: dwc3_gadget_ep_cmd: ep2out: 
> cmd 'Update Transfer' [262151] params    --> status: 
> Successful
> file-storage-1592  [000]    152.809951: usb_ep_queue: ep2out: length 
> 0/512 sgs 0/0 stream 0 zsI status -115 --> 0
>  irq/34-dwc3-1593  [001] d..1   152.810212: dwc3_event: event (c040): 
> ep0out: Transfer Complete [Setup Phase]
>  irq/34-dwc3-1593  [001] d..1   152.810218: dwc3_ctrl_req: bRequestType 
> 02 bRequest 01 wValue  wIndex 0002 wLength 0
>  irq/34-dwc3-1593  [001] d..1   152.810228: __dwc3_gadget_ep_set_halt: 
> ep2out: NOT stalled
>
> Sniffer shows me this completing, but I don't see IRQ for this.

BTW, I just tested without $subject and it fails the same way. This is
caused by something else. Can you rerun your bisect while I look at the
problem here?

-- 
balbi


signature.asc
Description: PGP signature

Re: [solution] usb: gadget: uvc: configfs: fails to enumerate in HOST

[Ganesh Biradar]

Hi Petr,

I saw your patch and at the same time I saw Laurent suggestion.

I have tried both patches both are working but I'm going with Laurent suggestion

UVC_ATTR(f_uvc_opts_, cname, cname).

I'm going with unofficial uvc-gadget.

Before I can test usb uvc gadget  not enumerating.

Regards,
Ganesh Biradar

On Wed, Mar 8, 2017 at 2:13 PM, Petr Cvek  wrote:
> Hi,
>
> I'm not subscribed to linux-usb mailing list so I found your post just by a 
> pure luck. I've sent the patch for:
>
> streaming_maxburst streaming_maxpacket streaming_interval
>
> problem earlier this week. Try this patch [1]:
>
> BTW please CC me if you will have another discusion in your thread (I will 
> try to not forget it myself if I will continue in my thread).
>
> P.S. Which userspace do you using, original uvc-gadget or unofficial repo [2]?
>
> [1] https://www.spinics.net/lists/linux-usb/msg154417.html
> [2] https://github.com/madscientist42/uvc-gadget
>
> --
> [PATCH] usb: gadget: uvc: Missing files for configfs interface
>
> Commit 76e0da34c7ce ("usb-gadget/uvc: use per-attribute show and store
> methods") caused a stringification of an undefined macro argument "aname",
> so three UVC parameters (streaming_interval, streaming_maxpacket and
> streaming_maxburst) were named "aname".
>
> Add the definition of "aname" to the main macro and name the filenames as
> originaly intended.
>
> Signed-off-by: Petr Cvek 
> ---
>  drivers/usb/gadget/function/uvc_configfs.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
> b/drivers/usb/gadget/function/uvc_configfs.c
> index 4e037d2a7a60..3a36b2e85788 100644
> --- a/drivers/usb/gadget/function/uvc_configfs.c
> +++ b/drivers/usb/gadget/function/uvc_configfs.c
> @@ -2125,7 +2125,7 @@ static struct configfs_item_operations uvc_item_ops = {
> .release= uvc_attr_release,
>  };
>
> -#define UVCG_OPTS_ATTR(cname, conv, str2u, uxx, vnoc, limit)   \
> +#define UVCG_OPTS_ATTR(cname, aname, conv, str2u, uxx, vnoc, limit)\
>  static ssize_t f_uvc_opts_##cname##_show(  \
> struct config_item *item, char *page)   \
>  {  \
> @@ -2172,12 +2172,12 @@ UVC_ATTR(f_uvc_opts_, cname, aname)
>
>  #define identity_conv(x) (x)
>
> -UVCG_OPTS_ATTR(streaming_interval, identity_conv, kstrtou8, u8, 
> identity_conv,
> -  16);
> -UVCG_OPTS_ATTR(streaming_maxpacket, le16_to_cpu, kstrtou16, u16, le16_to_cpu,
> -  3072);
> -UVCG_OPTS_ATTR(streaming_maxburst, identity_conv, kstrtou8, u8, 
> identity_conv,
> -  15);
> +UVCG_OPTS_ATTR(streaming_interval, streaming_interval, identity_conv,
> +  kstrtou8, u8, identity_conv, 16);
> +UVCG_OPTS_ATTR(streaming_maxpacket, streaming_maxpacket, le16_to_cpu,
> +  kstrtou16, u16, le16_to_cpu, 3072);
> +UVCG_OPTS_ATTR(streaming_maxburst, streaming_maxburst, identity_conv,
> +  kstrtou8, u8, identity_conv, 15);
>
>  #undef identity_conv
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: xhci-mtk: check hcc_params after adding primary hcd

[Mathias Nyman]

On 08.03.2017 02:51, Chunfeng Yun wrote:

On Tue, 2017-03-07 at 17:10 +0200, Mathias Nyman wrote:

On 07.03.2017 05:32, Chunfeng Yun wrote:

hcc_params is set in xhci_gen_setup() called from usb_add_hcd(),
so checks the Maximum Primary Stream Array Size in the hcc_params
register after adding primary hcd.

Signed-off-by: Chunfeng Yun 


Thanks.
Looks like streams check has never worked for Mediatek xHC hosts,

Do you know if this has caused any issues?
looks like it should go usb-linus and maybe stable kernels as well.

No issues on mt8173, because it doesn't support bulk stream. But it
causes a issue on the newest SoC which is not upstreamed, so I think it
needn't go stable kernels.



Ok, thanks, skipping stable

-Mathias

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

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[gre...@linuxfoundation.org]

On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote:
> > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that might lead to use-after-free
> > > situations.
> > 
> > Looks good. Let me know how do you want to route the patch to upstream.
> 
> Greg, you previously mentioned that driver's conversions can go via your 
> tree. Does this still apply?
> Or should I be asking maintainers to merge these patches via their trees? 

You should ask them to take them through their trees, if they have them.
I'll be glad to scoop up all of the remaining ones that get missed, or
for subsystems that do not have trees.

thanks,

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

RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[Reshetova, Elena]

> On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> 
> Looks good. Let me know how do you want to route the patch to upstream.

Greg, you previously mentioned that driver's conversions can go via your tree. 
Does this still apply?
Or should I be asking maintainers to merge these patches via their trees? 
I am not sure about the correct (and easier for everyone) way, please suggest.  

Best Regards,
Elena.
> 
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/md/md.c | 6 +++---
> >  drivers/md/md.h | 3 ++-
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/md/md.c b/drivers/md/md.c
> > index 985374f..94c8ebf 100644
> > --- a/drivers/md/md.c
> > +++ b/drivers/md/md.c
> > @@ -449,7 +449,7 @@ EXPORT_SYMBOL(md_unplug);
> >
> >  static inline struct mddev *mddev_get(struct mddev *mddev)
> >  {
> > -   atomic_inc(>active);
> > +   refcount_inc(>active);
> > return mddev;
> >  }
> >
> > @@ -459,7 +459,7 @@ static void mddev_put(struct mddev *mddev)
> >  {
> > struct bio_set *bs = NULL;
> >
> > -   if (!atomic_dec_and_lock(>active, _mddevs_lock))
> > +   if (!refcount_dec_and_lock(>active, _mddevs_lock))
> > return;
> > if (!mddev->raid_disks && list_empty(>disks) &&
> > mddev->ctime == 0 && !mddev->hold_active) {
> > @@ -495,7 +495,7 @@ void mddev_init(struct mddev *mddev)
> > INIT_LIST_HEAD(>all_mddevs);
> > setup_timer(>safemode_timer, md_safemode_timeout,
> > (unsigned long) mddev);
> > -   atomic_set(>active, 1);
> > +   refcount_set(>active, 1);
> > atomic_set(>openers, 0);
> > atomic_set(>active_io, 0);
> > spin_lock_init(>lock);
> > diff --git a/drivers/md/md.h b/drivers/md/md.h
> > index b8859cb..4811663 100644
> > --- a/drivers/md/md.h
> > +++ b/drivers/md/md.h
> > @@ -22,6 +22,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -360,7 +361,7 @@ struct mddev {
> >  */
> > struct mutexopen_mutex;
> > struct mutexreconfig_mutex;
> > -   atomic_tactive;
>   /* general refcount */
> > +   refcount_t  active;
>   /* general refcount */
> > atomic_topeners;/*
> number of active opens */
> >
> > int
>   changed;/* True if we might need to
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" 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 10/29] drivers, md: convert stripe_head.count from atomic_t to refcount_t

[Reshetova, Elena]

> On Mon, Mar 06, 2017 at 04:20:57PM +0200, Elena Reshetova wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/md/raid5-cache.c |  8 +++---
> >  drivers/md/raid5.c   | 66 
> > 
> >  drivers/md/raid5.h   |  3 ++-
> >  3 files changed, 39 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> > index 3f307be..6c05e12 100644
> > --- a/drivers/md/raid5-cache.c
> > +++ b/drivers/md/raid5-cache.c
> 
> snip
> >sh->check_state, sh->reconstruct_state);
> >
> > analyse_stripe(sh, );
> > @@ -4924,7 +4924,7 @@ static void activate_bit_delay(struct r5conf *conf,
> > struct stripe_head *sh = list_entry(head.next, struct
> stripe_head, lru);
> > int hash;
> > list_del_init(>lru);
> > -   atomic_inc(>count);
> > +   refcount_inc(>count);
> > hash = sh->hash_lock_index;
> > __release_stripe(conf, sh,
> _inactive_list[hash]);
> > }
> > @@ -5240,7 +5240,7 @@ static struct stripe_head 
> > *__get_priority_stripe(struct
> r5conf *conf, int group)
> > sh->group = NULL;
> > }
> > list_del_init(>lru);
> > -   BUG_ON(atomic_inc_return(>count) != 1);
> > +   BUG_ON(refcount_inc_not_zero(>count));
> 
> This changes the behavior. refcount_inc_not_zero doesn't inc if original 
> value is 0

Hm.. So, you want to inc here in any case and BUG if the end result differs 
from 1. 
So essentially you want to only increment here from zero to one under normal 
conditions... This is a challenge for refcount_t and against the design.
Is it ok just to maybe do this here:

-   BUG_ON(atomic_inc_return(>count) != 1);
+   BUG_ON(refcount_read(>count) != 0);
+   refcount_set((>count, 1);

Do we have an issue with locking in this case? Or maybe it is then better to 
leave this one to be atomic_t without protection since it isn't a real 
refcounter as it turns out. 

Best Regards,
Elena. 

> 
> Thanks,
> Shaohua
--
To unsubscribe from this list: send the line "unsubscribe 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: dwc3: gadget: skip Set/Clear Halt when invalid

[Felipe Balbi]

Hi Thinh,

Thinh Nguyen  writes:
>>  drivers/usb/dwc3/gadget.c | 5 +
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 6faf484e5dfc..0a664d8eba3f 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep
>> *dep, int value, int protocol)
>>  unsigned transfer_in_flight;
>>  unsigned started;
>> 
>> +if (dep->flags & DWC3_EP_STALL)
>> +return 0;
>> +
>>  if (dep->number > 1)
>>  trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
>>  else
>> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep
>> *dep, int value, int protocol)
>>  else
>>  dep->flags |= DWC3_EP_STALL;
>>  } else {
>> +if (!(dep->flags & DWC3_EP_STALL))
>> +return 0;
>> 
>>  ret = dwc3_send_clear_stall_ep_cmd(dep);
>>  if (ret)
>> --
>> 2.11.0.295.gd7dffce1ce
>> 
>> --
>
> I encounter an issue when I test mainline with USB 3 CV MSC test and
> bisected to this patch.
>
> Tester: USB 3 CV test (v2.1.3.0).
> Function Driver: f_mass_storage
> Reproducibility: always 
>
> The failure occurs under MSC Error Recovery Test (TD 1.4).
>
> Failure from the test sequence as follow (MSC compliance test spec) :
> 1. Place the device in the desired starting state.
> 2. Issue a Case 9 CBW (see Table 2) but with invalid signature of 0xDEADBEEF.
> 3. Issue several In requests to the Bulk-Only Data Interface Bulk In 
> endpoint. Verify a
> STALL handshake is returned. If STALL handshake is not returned, skip to step 
> 11.
> 4. Issue a Get_Status(endpoint) request targeting the Bulk-Only Data 
> Interface bulk In
> endpoint. Verify that it completes normally, reports endpoint halt status.
>
>  ***After this point the device idles for 10 seconds and resets. ***
>
> Test fails.

I've been looking at this and based on sniffer and dwc3 tracepoints, it
seems like dwc3 is behaving properly. The real issue seems to be that
g_mass_storage isn't queueing a new request to IN endpoint.

I'll continue debugging this and try to find a solution that doesn't
involve reverting $subject.

-- 
balbi


signature.asc
Description: PGP signature

RE: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

[Felipe Balbi]

Felipe Balbi  writes:

> Hi Thinh,
>
> Thinh Nguyen  writes:
>>>  drivers/usb/dwc3/gadget.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>> 
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 6faf484e5dfc..0a664d8eba3f 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep
>>> *dep, int value, int protocol)
>>> unsigned transfer_in_flight;
>>> unsigned started;
>>> 
>>> +   if (dep->flags & DWC3_EP_STALL)
>>> +   return 0;
>>> +
>>> if (dep->number > 1)
>>> trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
>>> else
>>> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep
>>> *dep, int value, int protocol)
>>> else
>>> dep->flags |= DWC3_EP_STALL;
>>> } else {
>>> +   if (!(dep->flags & DWC3_EP_STALL))
>>> +   return 0;
>>> 
>>> ret = dwc3_send_clear_stall_ep_cmd(dep);
>>> if (ret)
>>> --
>>> 2.11.0.295.gd7dffce1ce
>>> 
>>> --
>>
>> I encounter an issue when I test mainline with USB 3 CV MSC test and
>> bisected to this patch.
>>
>> Tester: USB 3 CV test (v2.1.3.0).
>> Function Driver: f_mass_storage
>> Reproducibility: always 
>>
>> The failure occurs under MSC Error Recovery Test (TD 1.4).
>>
>> Failure from the test sequence as follow (MSC compliance test spec) :
>> 1. Place the device in the desired starting state.
>> 2. Issue a Case 9 CBW (see Table 2) but with invalid signature of 0xDEADBEEF.
>> 3. Issue several In requests to the Bulk-Only Data Interface Bulk In 
>> endpoint. Verify a
>> STALL handshake is returned. If STALL handshake is not returned, skip to 
>> step 11.
>> 4. Issue a Get_Status(endpoint) request targeting the Bulk-Only Data 
>> Interface bulk In
>> endpoint. Verify that it completes normally, reports endpoint halt status.
>>
>>  ***After this point the device idles for 10 seconds and resets. ***
>>
>> Test fails.
>
> I've been looking at this and based on sniffer and dwc3 tracepoints, it
> seems like dwc3 is behaving properly. The real issue seems to be that
> g_mass_storage isn't queueing a new request to IN endpoint.
>
> I'll continue debugging this and try to find a solution that doesn't
> involve reverting $subject.

oh no, wait. ep2out misses XferInProgress:

file-storage-1592  [000] d..1   152.809922: dwc3_ep_queue: ep2out: req 
88003cd6ee40 length 0/512 zsI ==> -115
file-storage-1592  [000] d..1   152.809931: dwc3_prepare_trb: ep2out: 3/8 
trb 88003a196050 buf 2d5e4000 size 512 ctrl 0819 
(HlcS:sC:normal)
file-storage-1592  [000] d..1   152.809942: dwc3_gadget_ep_cmd: ep2out: cmd 
'Update Transfer' [262151] params    --> status: 
Successful
file-storage-1592  [000]    152.809951: usb_ep_queue: ep2out: length 
0/512 sgs 0/0 stream 0 zsI status -115 --> 0
 irq/34-dwc3-1593  [001] d..1   152.810212: dwc3_event: event (c040): 
ep0out: Transfer Complete [Setup Phase]
 irq/34-dwc3-1593  [001] d..1   152.810218: dwc3_ctrl_req: bRequestType 02 
bRequest 01 wValue  wIndex 0002 wLength 0
 irq/34-dwc3-1593  [001] d..1   152.810228: __dwc3_gadget_ep_set_halt: 
ep2out: NOT stalled

Sniffer shows me this completing, but I don't see IRQ for this.

-- 
balbi


signature.asc
Description: PGP signature