Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

On 27 May 2016 at 05:41, Peter Chen wrote: > On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote: >> Hello, >> >> I was updating my config by make oldconfig for a while and noticed that my >> USB >> OTG controller is not working. Apparently it grew dependency

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

On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote: > There is a double free problem in the usb driver. Which driver? > This is caused by delayed deregister for scsi device. > <*> at Insert USB Storage > - USB bus #1 register > usb_create_hcd (primary-kref==1) > *

Re: [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote: > Hello, > > I was updating my config by make oldconfig for a while and noticed that my USB > OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV > over time. > > Looking through defconfigs some have it

Re: [RFC 4/5] ARM: tegra: Enable UDC on Dalmore

On Thu, May 26, 2016 at 05:40:04PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Override the compatible string of the first USB controller to enable > device mode. > > Signed-off-by: Thierry Reding > --- >

Re: [RFC 0/5] usb: chipidea: Add support for Tegra20 through Tegra124

On Thu, May 26, 2016 at 05:40:00PM +0200, Thierry Reding wrote: > From: Thierry Reding > > All Tegra SoC generations from Tegra20 through Tegra124 have a ChipIdea > USB device controller. This set of patches adds very rudimentary support > for it to the existing ChipIdea

Re: composite gadget with _real_ USB device

> How about setting up USBIP, using the same machine as both the server > and the client? That’s an interesting idea, I’ll check it out. Thanks for the tip! And thanks Felipe for your input too, I really appreciate the help. > On May 20, 2016, at 9:38 AM, Alan Stern

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

There is a double free problem in the usb driver. This is caused by delayed deregister for scsi device. <*> at Insert USB Storage - USB bus #1 register usb_create_hcd (primary-kref==1) * primary-bandwidth_mutex(alloc)) usb_get_hcd(primary-kref==2) - USB bus #2 register

[PATCH v2] usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command

As of core revision 2.60a the recommended programming model is to set the ClearPendIN bit when issuing a Clear Stall EP command for IN endpoints. This is to prevent an issue where some (non-compliant) hosts may not send ACK TPs for pending IN transfers due to a mishandled error condition. Synopsys

Re: [PATCH] reset: Put back *_optional variants

On 5/26/2016 1:25 PM, Hans de Goede wrote: > Hi, > > On 26-05-16 03:15, John Youn wrote: >> Prior to commit 6c96f05c8bb8 ("reset: Make [of_]reset_control_get[_foo] >> functions wrappers"), the optional variants returned -ENOTSUPP when >> CONFIG_RESET_CONTROLLER was not set. This patch reverts to

Re: [RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

On 05/26/2016 03:17 PM, Stephen Warren wrote: On 05/26/2016 09:40 AM, Thierry Reding wrote: From: Thierry Reding All of these Tegra SoC generations have a ChipIdea UDC IP block that can be used for device mode communication with a host. Implement rudimentary support that

Re: [RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

On 05/26/2016 09:40 AM, Thierry Reding wrote: From: Thierry Reding All of these Tegra SoC generations have a ChipIdea UDC IP block that can be used for device mode communication with a host. Implement rudimentary support that doesn't allow switching between host and device

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

On Thu, May 26, 2016 at 3:30 AM, Felipe Balbi wrote: > > Hi, > > Leo Li writes: On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set to be able to do DMA allocations, so use the of_dma_configure() helper to

Re: [PATCH] reset: Put back *_optional variants

Hi, On 26-05-16 03:15, John Youn wrote: Prior to commit 6c96f05c8bb8 ("reset: Make [of_]reset_control_get[_foo] functions wrappers"), the optional variants returned -ENOTSUPP when CONFIG_RESET_CONTROLLER was not set. This patch reverts to this behavior. Otherwise those calls will return -EINVAL

[PATCH] usb: select NOP_USB_XCEIV by drivers that require it

Hello, I was updating my config by make oldconfig for a while and noticed that my USB OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV over time. Looking through defconfigs some have it included and some which seem in need of it don't. Since the dependency is not

Re: SuperH 7760 OHCI

On Thu, 26 May 2016, Martin Townsend wrote: > >> and setting the HCD_MEMORY_LOCAL flag in the HC driver. > > > > Did you do this correctly? That is, in the correct driver? > > > I put the code for the declaring the DMA coherent memory into ohci-platform.c > and set the flag in ohci-hcd.c Okay.

Re: SuperH 7760 OHCI

On Thu, May 26, 2016 at 6:31 PM, Alan Stern wrote: > On Thu, 26 May 2016, Martin Townsend wrote: > >> I tried hacking in the relevant code straight into the OHCI platform driver >> res_mem = platform_get_resource(dev, IORESOURCE_MEM, 1); >> if (res_mem == NULL)

Re: SuperH 7760 OHCI

On Thu, 26 May 2016, Martin Townsend wrote: > I tried hacking in the relevant code straight into the OHCI platform driver > res_mem = platform_get_resource(dev, IORESOURCE_MEM, 1); > if (res_mem == NULL) { > dev_err(>dev, "no resource definition for memory\n"); > err =

Re: SuperH 7760 OHCI

On Thu, 26 May 2016, Martin Townsend wrote: > On Thu, May 26, 2016 at 4:24 PM, Alan Stern wrote: > > On Thu, 26 May 2016, Martin Townsend wrote: > > > >> Hi, > >> > >> I'm currently trying to get the USB Host working on the SH7760. I > >> tried the platform driver to

Re: SuperH 7760 OHCI

On Thu, May 26, 2016 at 4:05 PM, Martin Townsend wrote: > Hi, > > I'm currently trying to get the USB Host working on the SH7760. I > tried the platform driver to start with and get the following error on > boot: > [3.60] usb 1-1: new full-speed USB device number

[PATCH v3] usb: gadget: fix spinlock dead lock in gadgetfs

[ 40.467381] = [ 40.473013] [ INFO: possible recursive locking detected ] [ 40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted [ 40.483466] - [ 40.489098] usb/733 is trying to acquire lock: [

Re: [PATCH v2] usb: gadget: fix spinlock dead lock in gadgetfs

Hi, On Thu, May 26, 2016 at 07:26:44PM +0300, Felipe Balbi wrote: > > >> Bin Liu writes: > >> > On Wed, May 25, 2016 at 02:18:34PM -0500, Bin Liu wrote: > >> >> [ 40.467381] = > >> >> [ 40.473013] [ INFO: possible recursive locking

Re: [PATCH v2] usb: gadget: fix spinlock dead lock in gadgetfs

>> Bin Liu writes: >> > On Wed, May 25, 2016 at 02:18:34PM -0500, Bin Liu wrote: >> >> [ 40.467381] = >> >> [ 40.473013] [ INFO: possible recursive locking detected ] >> >> [ 40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted >> >> [

[RFC 3/5] ARM: tegra: Enable UDC on Beaver

From: Thierry Reding Override the compatible string of the first USB controller to enable device mode. Signed-off-by: Thierry Reding --- arch/arm/boot/dts/tegra30-beaver.dts | 11 +++ 1 file changed, 11 insertions(+) diff --git

Re: SuperH 7760 OHCI

On Thu, May 26, 2016 at 4:24 PM, Alan Stern wrote: > On Thu, 26 May 2016, Martin Townsend wrote: > >> Hi, >> >> I'm currently trying to get the USB Host working on the SH7760. I >> tried the platform driver to start with and get the following error on >> boot: >> [

[RFC 0/5] usb: chipidea: Add support for Tegra20 through Tegra124

From: Thierry Reding All Tegra SoC generations from Tegra20 through Tegra124 have a ChipIdea USB device controller. This set of patches adds very rudimentary support for it to the existing ChipIdea driver and enables them on the set of boards that I could easily test on. I'm

[RFC 4/5] ARM: tegra: Enable UDC on Dalmore

From: Thierry Reding Override the compatible string of the first USB controller to enable device mode. Signed-off-by: Thierry Reding --- arch/arm/boot/dts/tegra114-dalmore.dts | 11 +++ 1 file changed, 11 insertions(+) diff --git

[RFC 1/5] usb: chipidea: Add support for Tegra20/30/114/124

From: Thierry Reding All of these Tegra SoC generations have a ChipIdea UDC IP block that can be used for device mode communication with a host. Implement rudimentary support that doesn't allow switching between host and device modes. Signed-off-by: Thierry Reding

[RFC 2/5] ARM: tegra: Enable UDC on TrimSlice

From: Thierry Reding Override the compatible string of the first USB controller to enable device mode. Signed-off-by: Thierry Reding --- arch/arm/boot/dts/tegra20-trimslice.dts | 3 +++ 1 file changed, 3 insertions(+) diff --git

[RFC 5/5] ARM: tegra: Enable UDC on Jetson TK1

From: Thierry Reding Override the compatible string of the first USB controller to enable device mode. Signed-off-by: Thierry Reding --- arch/arm/boot/dts/tegra124-jetson-tk1.dts | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff

Re: [PATCH v2] usb: gadget: fix spinlock dead lock in gadgetfs

Hi, On Thu, May 26, 2016 at 09:27:26AM +0300, Felipe Balbi wrote: > > Hi, > > Bin Liu writes: > > On Wed, May 25, 2016 at 02:18:34PM -0500, Bin Liu wrote: > >> [ 40.467381] = > >> [ 40.473013] [ INFO: possible recursive locking

Re: SuperH 7760 OHCI

On Thu, 26 May 2016, Martin Townsend wrote: > Hi, > > I'm currently trying to get the USB Host working on the SH7760. I > tried the platform driver to start with and get the following error on > boot: > [3.60] usb 1-1: new full-speed USB device number 2 using ohci-platform > [

Re: [PATCH v4 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice

On Thu, May 26, 2016 at 05:23:30PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Starting with commit 0b52297f2288 ("reset: Add support for shared reset > controls") there is a reference count for reset control assertions. The > goal is to allow resets to be shared

[PATCH v4 2/2] usb: host: ehci-tegra: Avoid getting the same reset twice

From: Thierry Reding Starting with commit 0b52297f2288 ("reset: Add support for shared reset controls") there is a reference count for reset control assertions. The goal is to allow resets to be shared by multiple devices and an assert will take effect only when all instances

[PATCH v4 1/2] usb: host: ehci-tegra: Grab the correct UTMI pads reset

From: Thierry Reding There are three EHCI controllers on Tegra SoCs, each with its own reset line. However, the first controller contains a set of UTMI configuration registers that are shared with its siblings. These registers will only be reset as part of the first

SuperH 7760 OHCI

Hi, I'm currently trying to get the USB Host working on the SH7760. I tried the platform driver to start with and get the following error on boot: [3.60] usb 1-1: new full-speed USB device number 2 using ohci-platform [3.872000] ohci-platform ohci-platform: frame counter not

Re: [PATCH v4] input: tablet: add Pegasus Notetaker tablet driver

Am 2016-05-26 um 02:29 schrieb Dmitry Torokhov: > Hi Martin, > > On Wed, May 25, 2016 at 09:44:34AM +0200, Martin Kepplinger wrote: >> This adds a driver for the Pegasus Notetaker Pen. When connected, >> this uses the Pen as an input tablet. >> >> This device was sold in various different

Re: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"

On Wed, May 25, 2016 at 07:52:36PM +0200, Steinar H. Gunderson wrote: >> Actually their are some missing patches to tune the usb3 phy. >> >> https://lkml.org/lkml/2014/10/31/266 > This explains why the default networking speed refused to go above > ~300 Mbit/sec! What happened to the patches, I

[RFC PATCH v3 4/6] xhci: don't rely on precalculated value of needed trbs in the enqueue loop

Queue trbs until all payload data in the urb is tranferred. The actual number of trbs might need to change from the pre-calculated number when the packet alignment restrictions for td fragments in xhci 4.11.7.1 are taken into account. Long term plan is to get rid of calculating the needed trbs

[RFC PATCH v3 6/6] xhci: TD-fragment, align the unsplittable case with a bounce buffer

If the last trb before a link is not packet size aligned, and is not splittable then use a bounce buffer for that chunk of max packet size unalignable data. Allocate a max packet size bounce buffer for every segment of a bulk endpoint ring at the same time as allocating the ring. If we need to

[RFC PATCH v3 5/6] xhci: align the last trb before link if it is easily splittable.

TD fragments section 4.11.7.1 in xhci specs have additional requirements on how trbs in TDs must be organized. TD fragments shall not span transfer ring segments and TD fragments must be packet aligned. Normally we don't care about TD fragments, on TD is one big fragment, but if a TD spans ring

[RFC PATCH v3 3/6] xhci: use boolean to indicate last trb in td remainder calculation

We only need to know if we are queuing the last trb for a TD when calculating the td remainder field. The total number of trbs left is not used. We won't be able to trust the pre-calculated number of trbs used if we need to align trb data by splitting or merging trbs in order to satisfy comply

[RFC PATCH v3 2/6] xhci: properly prepare zero packet TD after normal bulk TD.

If a zero-length packet is needed after a bulk transfer, then an additional zero length TD was prepared before enqueueing the bulk transfer This set up the zero packet TD structure with incorrect td->start_seg and td->first_trb pointers. Prepare the zero packet TD after the data bulk TD is

[RFC PATCH v3 0/6] xhci: conform with xhci td fragment constraints

This patchseries makes sure we follow the td fragmentation constraints in xhci 4.11.7.1 for bulk tranfers. The specs say that: "constraints must be imposed to ensure that the hardware gate count and validation requirements are minimized for xHC implementations" The constraint we need to conform

[RFC PATCH v3 1/6] xhci: rename ep_ring variable in queue_bulk_tx(), no functional change

Tiny change, a bit more readable. The real reason for this change is that the coming td fragment work had several over 80 lines character lines split just because of a few extra characters in variable names. no functional changes Signed-off-by: Mathias Nyman ---

Re: [RFC PATCH v2 5/6] xhci: align the last trb before link if it is easily splittable.

On 26.05.2016 15:08, Mathias Nyman wrote: TD fragments section 4.11.7.1 in xhci specs have additional requirements on how trbs in TDs must be organized. TD fragments shall not span transfer ring segments and TD fragments must be packet aligned. Normally we don't care about TD fragments, on TD

[RFC PATCH v2 2/6] xhci: properly prepare zero packet TD after normal bulk TD.

If a zero-length packet is needed after a bulk transfer, then an additional zero length TD was prepared before enqueueing the bulk transfer This set up the zero packet TD structure with incorrect td->start_seg and td->first_trb pointers. Prepare the zero packet TD after the data bulk TD is

[RFC PATCH v2 6/6] xhci: TD-fragment, align the unsplittable case with a bounce buffer

If the last trb before a link is not packet size aligned, and is not splittable then use a bounce buffer for that chunk of max packet size unalignable data. Allocate a max packet size bounce buffer for every segment of a bulk endpoint ring at the same time as allocating the ring. If we need to

[RFC PATCH v2 5/6] xhci: align the last trb before link if it is easily splittable.

TD fragments section 4.11.7.1 in xhci specs have additional requirements on how trbs in TDs must be organized. TD fragments shall not span transfer ring segments and TD fragments must be packet aligned. Normally we don't care about TD fragments, on TD is one big fragment, but if a TD spans ring

[RFC PATCH v2 3/6] xhci: use boolean to indicate last trb in td remainder calculation

We only need to know if we are queuing the last trb for a TD when calculating the td remainder field. The total number of trbs left is not used. We won't be able to trust the pre-calculated number of trbs used if we need to align trb data by splitting or merging trbs in order to satisfy comply

[RFC PATCH v2 4/6] xhci: don't rely on precalculated value of needed trbs in the enqueue loop

Queue trbs until all payload data in the urb is tranferred. The actual number of trbs might need to change from the pre-calculated number when the packet alignment restrictions for td fragments in xhci 4.11.7.1 are taken into account. Long term plan is to get rid of calculating the needed trbs

[RFC PATCH v2 1/6] xhci: rename ep_ring variable in queue_bulk_tx(), no functional change

Tiny change, a bit more readable. The real reason for this change is that the coming td fragment work had several over 80 lines character lines split just because of a few extra characters in variable names. no functional changes Signed-off-by: Mathias Nyman ---

[RFC PATCH v2 0/6] xhci: conform with xhci td fragment constraints

This patchseries makes sure we follow the td fragmentation constraints in xhci 4.11.7.1 for bulk tranfers. The specs say that: "constraints must be imposed to ensure that the hardware gate count and validation requirements are minimized for xHC implementations" The constraint we need to conform

Re: [RFC PATCH 6/6] xhci: TD-fragment, align the unsplittable case with a bounce buffer

On 26.05.2016 14:32, Felipe Balbi wrote: Hi, Mathias Nyman writes: @@ -3098,24 +3136,66 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred, return (total_packet_count - ((transferred + trb_buff_len) / maxp)); } + } +

Re: [RFC PATCH 6/6] xhci: TD-fragment, align the unsplittable case with a bounce buffer

Hi, Mathias Nyman writes: > @@ -3098,24 +3136,66 @@ static u32 xhci_td_remainder(struct xhci_hcd *xhci, > int transferred, > return (total_packet_count - ((transferred + trb_buff_len) / maxp)); > } > > + > static int xhci_align_td(struct xhci_hcd *xhci,

Re: [RFC PATCH 5/6] xhci: align the last trb before link if it is easily splittable.

Hi, Mathias Nyman writes: > TD fragments section 4.11.7.1 in xhci specs have additional requirements > on how trbs in TDs must be organized. > > TD fragments shall not span transfer ring segments and TD fragments must > be packet aligned. Normally we don't care

Re: [RFC PATCH 5/6] xhci: align the last trb before link if it is easily splittable.

Hi, Mathias Nyman writes: > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c > index d86da81..c7c9521 100644 > --- a/drivers/usb/host/xhci-ring.c > +++ b/drivers/usb/host/xhci-ring.c > @@ -3098,6 +3098,27 @@ static u32

[RFC PATCH 4/6] xhci: don't rely on precalculated value of needed trbs in the enqueue loop

Queue trbs until all payload data in the urb is tranferred. The actual number of trbs might need to change from the pre-calculated number when the packet alignment restrictions for td fragments in xhci 4.11.7.1 are taken into account. Long term plan is to get rid of calculating the needed trbs

[RFC PATCH 0/6] xhci: conform with xhci td fragment constraints

This patchseries makes sure we follow the td fragmentation constraints in xhci 4.11.7.1 for bulk tranfers. The specs say that: "constraints must be imposed to ensure that the hardware gate count and validation requirements are minimized for xHC implementations" The constraint we need to conform

[RFC PATCH 5/6] xhci: align the last trb before link if it is easily splittable.

TD fragments section 4.11.7.1 in xhci specs have additional requirements on how trbs in TDs must be organized. TD fragments shall not span transfer ring segments and TD fragments must be packet aligned. Normally we don't care about TD fragments, on TD is one big fragment, but if a TD spans ring

[RFC PATCH 3/6] xhci: use boolean to indicate last trb in td remainder calculation

We only need to know if we are queuing the last trb for a TD when calculating the td remainder field. The total number of trbs left is not used. We won't be able to trust the pre-calculated number of trbs used if we need to align trb data by splitting or merging trbs in order to satisfy comply

[RFC PATCH 2/6] xhci: properly prepare zero packet TD after normal bulk TD.

If a zero-length packet is needed after a bulk transfer, then an additional zero length TD was prepared before enqueueing the bulk transfer This set up the zero packet TD structure with incorrect td->start_seg and td->first_trb pointers. Prepare the zero packet TD after the data bulk TD is

[RFC PATCH 6/6] xhci: TD-fragment, align the unsplittable case with a bounce buffer

If the last trb before a link is not packet size aligned, and is not splittable then use a bounce buffer for that chunk of max packet size unalignable data. Allocate a max packet size bounce buffer for every segment of a bulk endpoint ring at the same time as allocating the ring. If we need to

Re: [PATCH v3 08/13] usb: dwc2: gadget: Add dwc2_gadget_read_ep_interrupts function

Hello. On 5/26/2016 4:07 AM, John Youn wrote: From: Vardan Mikayelyan Reads and returns interrupts for given endpoint, by masking epint_reg with corresponding mask. Tested-by: John Keeping Signed-off-by: Vardan Mikayelyan

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

On 26 May 2016 at 18:27, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> On 26 May 2016 at 17:45, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Baolin Wang writes: >>> >>> >>> > Also note that the

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

Hi, Baolin Wang writes: > On 26 May 2016 at 17:45, Felipe Balbi wrote: >> >> Hi, >> >> Baolin Wang writes: >> >> >> Also note that the usb_endpoint_xfer_isoc() call on line 2067 of gadget.c (as in my testing/next

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

On 26 May 2016 at 17:45, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: > > > >>> Also note that the usb_endpoint_xfer_isoc() call on line 2067 of >>> gadget.c (as in my testing/next from today) won't even get executed, so >>> we're safe there. >>

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

Hi, Baolin Wang writes: >> Also note that the usb_endpoint_xfer_isoc() call on line 2067 of >> gadget.c (as in my testing/next from today) won't even get executed, so >> we're safe there. > > Never will be executed? then we can remove the > usb_endpoint_xfer_isoc()

Re: [PATCH] drivers: usb: dwc3 : Configure DMA properties and ops from DT

Hi, Leo Li writes: >>> On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set >>> to be able to do DMA allocations, so use the of_dma_configure() helper >>> to populate the dma properties and assign an appropriate dma_ops. >>> >>> Signed-off-by: Rajesh

Re: [PATCH] dwc3: gadget: Introduce dwc3_endpoint_xfer_xxx() to check endpoint type

Hi Felipe, On 26 May 2016 at 14:22, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: >> When handling the endpoint interrupt handler, it maybe disable the endpoint >> from another core user to set the USB endpoint descriptor pointor to be NULL >>

Re: [PATCH] usb: host: ehci-msm: Conditionally call ehci suspend/resume

On 21 May 2016 at 03:05, Andy Gross wrote: > This patch fixes a suspend/resume issue where the driver is blindly > calling ehci_suspend/resume functions when the ehci hasn't been setup. > This results in a crash during suspend/resume operations. > > Signed-off-by: Andy

Re: [PATCH v2] usb: gadget: fix spinlock dead lock in gadgetfs

Hi, Bin Liu writes: > On Wed, May 25, 2016 at 02:18:34PM -0500, Bin Liu wrote: >> [ 40.467381] = >> [ 40.473013] [ INFO: possible recursive locking detected ] >> [ 40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted >> [ 40.483466]