On Wed, Sep 16, 2015 at 11:45:19AM -0500, Felipe Balbi wrote:
> Hi Greg,
>
> Here's the first set of fixes for v4.3-rc cycle. Please consider
> merging. Patches have been tested on platforms I have around
> (AM437x, AM335x, DRA7x) and have been in next for a few days.
>
> Let me know if you want
On 9/9/2015 3:20 AM, Mian Yousaf Kaukab wrote:
> Hi,
> This series consists of various bug fixes for both host and gadget
> sides. All patches are verified on dwc2 v3.0a with dedicated fifos.
> It would be good to get some Tested-bys for other platforms.
>
> It is based on testing/next branch in F
On 9/9/2015 3:21 AM, Mian Yousaf Kaukab wrote:
> From: Gregory Herrero
>
> No point of continue with initialization if core is not in a sane
> state.
>
> Signed-off-by: Gregory Herrero
> Signed-off-by: Mian Yousaf Kaukab
> Tested-by: Robert Baldyga
> ---
> drivers/usb/dwc2/gadget.c | 6 +
add Alan Stern
On Thursday, September 17, 2015 11:09 AM, WEN Pingbo wrote:
> The millisecond of the last second will be normal if tv_sec is
> overflowed. But for y2038 consistency and demonstration purpose,
> and avoiding further risks, we need to remove 'timeval' in this
> driver, to avoid simila
The millisecond of the last second will be normal if tv_sec is
overflowed. But for y2038 consistency and demonstration purpose,
and avoiding further risks, we need to remove 'timeval' in this
driver, to avoid similair problems.
V2 Updates:
- using monotonic time here by replacing getnstimeofday()
On 09/16/2015 07:56 AM, David Laight wrote:
From: Austin S Hemmelgarn
Sent: 16 September 2015 12:46
On 2015-09-15 20:09, Steve Calfee wrote:
On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin wrote:
Signed-off-by: Eric Curtin
diff --git a/tools/usb/usbip/src/usbip_detach.c
b/tools/usb/usbip/sr
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Wed, Sep 16, 2015 at 04:27:43PM -0700, Todd Efflam wrote:
> We were using EHCI with the 2.6.35 kernel. When disabling XHCI in
> 3.14 and using EHCI the device still doesn't work however.
Really?
We were using EHCI with the 2.6.35 kernel. When disabling XHCI in
3.14 and using EHCI the device still doesn't work however.
The reason we are stuck with 3.14 is we use the Yocto build system and
their latest support is for 3.14.
Thanks,
Todd
On Wed, Sep 16, 2015 at 3:59 PM, Greg KH wrote:
> O
On Wed, Sep 16, 2015 at 03:46:36PM -0700, Todd Efflam wrote:
> Sorry if this is the wrong place for this question - the device is
> part of a family of products we sell and only intended to be used with
> our other product (running linux). The reason we can't change the
> firmware is we have alrea
> Also removing the XHCI_LPM_SUPPORT flag should do the trick, for example for
> Intel hosts:
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 2be1b7b..8f2eafb 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -127,7 +127,6 @@ st
Sorry if this is the wrong place for this question - the device is
part of a family of products we sell and only intended to be used with
our other product (running linux). The reason we can't change the
firmware is we have already sold the product and it worked fine with
our old kernel (2.6.35.13
On Wed, Sep 16, 2015 at 09:21:58PM +0100, Eric Curtin wrote:
> On 16 September 2015 at 21:02, Greg KH wrote:
> > On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
> >> Hi Greg,
> >>
> >> As I said in the subject of the mail (which I have been since told I
> >> shouldn't have done this),
On Wed, Sep 16, 2015 at 02:18:23PM -0700, Todd Efflam wrote:
> Hello,
> We have an issue where we cannot communicate with an old device with a
> wMaxPacketSize set to 0x. It is visible using lsusb -v and shows
> the correct max packte size, but is not listed in lsusb -t. The
> dmesg output g
On 9/9/2015 3:20 AM, Mian Yousaf Kaukab wrote:
> From: Gregory Herrero
>
> lx_state must be used to reflect controller power state only and not
> bus state. Thus add a flag to track state during bus suspend.
>
> Signed-off-by: Gregory Herrero
> Signed-off-by: Mian Yousaf Kaukab
> Tested-by: Ro
Hello,
We have an issue where we cannot communicate with an old device with a
wMaxPacketSize set to 0x. It is visible using lsusb -v and shows
the correct max packte size, but is not listed in lsusb -t. The
dmesg output gives us "usb 2-2.1: Not enough bandwidth for new device
state. " and th
On 16 September 2015 at 21:02, Greg KH wrote:
> On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
>> Hi Greg,
>>
>> As I said in the subject of the mail (which I have been since told I
>> shouldn't have done this), I'm a noob to kernel code. I tried to pick
>> off something super simple
On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
> Hi Greg,
>
> As I said in the subject of the mail (which I have been since told I
> shouldn't have done this), I'm a noob to kernel code. I tried to pick
> off something super simple to just see what the process of getting a
> patch in
Fix the regression caused by commit ad78c91 (usb: musb: dsps: just start
polling already) which causes polling the ID pin status even in
device-only mode.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_dsps.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/us
Hi Clemens,
On Mon, Sep 14, 2015 at 4:24 AM, Clemens Ladisch wrote:
> The "fsl_usb2_udc" driver (if that is what you're using) uses a coherent
> DMA pool for "TD management". I see no obvious problem with how it
> calls dma_pool_alloc()/dma_pool_free(). Are there any messages in the
> system l
On Wed, Sep 16, 2015 at 06:22:27PM +0100, Felipe Tonello wrote:
> Hi Estevam,
>
> On Tue, Sep 15, 2015 at 5:09 AM, Fabio Estevam wrote:
> > On Thu, Sep 10, 2015 at 6:47 AM, Felipe Tonello
> > wrote:
> >> Hi,
> >>
> >> I have the following setup:
> >>
> >> DSP (read sensors and read/send MIDI) <
Hi Eric,
First of all, thanks for your attempt and I really hope you haven't
been totally discouraged from future participation. Getting a patch
into the kernel is hard, but I'm pretty disappointed with the
responses you've gotten so far.
On Wed, Sep 16, 2015 at 12:40 PM, Theodore Ts'o wrote:
>
On 09/16/15 09:40, Theodore Ts'o wrote:
On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
Hi Greg,
As I said in the subject of the mail (which I have been since told I
shouldn't have done this), I'm a noob to kernel code. I tried to pick
off something super simple to just see what
Hi Estevam,
On Tue, Sep 15, 2015 at 5:09 AM, Fabio Estevam wrote:
> On Thu, Sep 10, 2015 at 6:47 AM, Felipe Tonello
> wrote:
>> Hi,
>>
>> I have the following setup:
>>
>> DSP (read sensors and read/send MIDI) <- UART -> SOC (imx6) <- USB
>> MIDI GADGET -> HOST
>>
>> When the throughput from th
On Wed, 16 Sep 2015, Sudip Mukherjee wrote:
> On error find_tt() returns either a NULL pointer or the error value in
> ERR_PTR. But we were dereferencing it directly without even checking if
> find_tt() returned a valid pointer or not.
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> v2: used IS_ER
Hi Greg,
Here's the first set of fixes for v4.3-rc cycle. Please consider
merging. Patches have been tested on platforms I have around
(AM437x, AM335x, DRA7x) and have been in next for a few days.
Let me know if you want anything to be changed
cheers
The following changes since commit 6ff33f390
On Wed, Sep 16, 2015 at 05:03:39PM +0100, Eric Curtin wrote:
> Hi Greg,
>
> As I said in the subject of the mail (which I have been since told I
> shouldn't have done this), I'm a noob to kernel code. I tried to pick
> off something super simple to just see what the process of getting a
> patch in
This reverts commit d80c0d14183516f184a5ac88e11008ee4c7d2a2e
(excluding the change to MAX_BL_NUM, which has since been removed).
The qcserial driver now enables the SET_CONTROL_LINE_STATE request
so that AT URCs will work. Move these devices back to the qcserial
driver, which is used for other dev
This reverts commit 653cdc13a340ad1cef29f1bab0d05d0771fa1d57.
The qcserial driver now enables the SET_CONTROL_LINE_STATE request
so that AT URCs will work. Move these devices back to the qcserial
driver, which is used for other devices in this series that follow
the same layout.
Cc: Bjørn Mork
S
This comment is ambiguous since there are other MC73xx devices with
different USB IDs. This USB ID is found in the MC7304 and MC7354.
Cc: Bjørn Mork
Signed-off-by: David Ward
---
drivers/usb/serial/qcserial.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/
This is a partial, context modified revert of commit e463c6dda8f5
("USB: option: handle send_setup blacklisting at probe"), which
introduced an unnecessary struct option_private for storing the
interface number used in option_send_setup. Removing this struct
will allow option_send_setup to be gener
Three Sierra Wireless modems have been found to require the CDC ACM
SET_CONTROL_LINE_STATE request on the AT port in order to receive
unsolicited response codes, most recently the Dell Wireless 5808e
(which is a re-branded Sierra Wireless EM7355). On the other hand,
the Sierra Wireless MC7710 does
Only the option driver implements the send_setup callback; it uses the
SET_CONTROL_LINE_STATE request in CDC ACM to generate DTR/RTS signals
on the port. This is not driver-specific though and is needed by other
drivers, so move the function to the usb_wwan driver (with formatting
tweaks), and repl
On error find_tt() returns either a NULL pointer or the error value in
ERR_PTR. But we were dereferencing it directly without even checking if
find_tt() returned a valid pointer or not.
Signed-off-by: Sudip Mukherjee
---
v2: used IS_ERR_OR_NULL (didn't know it was there. thanks)
drivers/usb/h
Hi Greg,
As I said in the subject of the mail (which I have been since told I
shouldn't have done this), I'm a noob to kernel code. I tried to pick
off something super simple to just see what the process of getting a
patch in is. Youtube videos and documentation only get you so far.
>From reading
On Wed, Sep 16, 2015 at 09:17:20AM -0500, Felipe Balbi wrote:
> Hi Paul, good to get a mail from you :-)
>
> On Tue, Sep 15, 2015 at 04:31:03PM -0700, pauldzim . wrote:
> > It's dangerous to use Update Transfer when the DWC3_TRB_CTRL_LST bit
> > might be set in one of the TRBs. The reason is, ther
Hello.
On 9/16/2015 5:08 PM, Sudip Mukherjee wrote:
On error find_tt() returns either a NULL pointer or the error value in
ERR_PTR. But we were dereferencing it directly without even checking if
find_tt() returned a valid pointer or not.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/host/e
On Wed, Sep 16, 2015 at 11:08 AM, Sudip Mukherjee
wrote:
> On error find_tt() returns either a NULL pointer or the error value in
> ERR_PTR. But we were dereferencing it directly without even checking if
> find_tt() returned a valid pointer or not.
>
> Signed-off-by: Sudip Mukherjee
> ---
> driv
Hi Paul, good to get a mail from you :-)
On Tue, Sep 15, 2015 at 04:31:03PM -0700, pauldzim . wrote:
> It's dangerous to use Update Transfer when the DWC3_TRB_CTRL_LST bit
> might be set in one of the TRBs. The reason is, there is a window
> between checking that the transfer has not completed yet
On error find_tt() returns either a NULL pointer or the error value in
ERR_PTR. But we were dereferencing it directly without even checking if
find_tt() returned a valid pointer or not.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/host/ehci-sched.c | 4
1 file changed, 4 insertions(+)
di
On 09/15/2015 08:49 PM, Peter Chen wrote:
> Some SoCs needs three clock to let controller work, but others only
> need one, add one property to differentiate this.
A given licensed IP block is going to have the same number of clock
inputs from SOC to SOC. So different numbers of clocks is a bit su
From: Aaro Koskinen
> Sent: 15 September 2015 21:56
...
> > - for (unsigned int i = 0; i < strlen(port); i++)
> > + unsigned int port_len = strlen(port);
> > +
> > + for (unsigned int i = 0; i < port_len; i++)
>
> port is read only in this function, so maybe just use "const" and the
> compil
On Wed, Sep 16, 2015 at 07:45:53AM -0400, Austin S Hemmelgarn wrote:
> On 2015-09-15 20:09, Steve Calfee wrote:
> >On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin wrote:
> >>Signed-off-by: Eric Curtin
> >>
> >>diff --git a/tools/usb/usbip/src/usbip_detach.c
> >>b/tools/usb/usbip/src/usbip_detach.c
From: Austin S Hemmelgarn
> Sent: 16 September 2015 12:46
> On 2015-09-15 20:09, Steve Calfee wrote:
> > On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin
> > wrote:
> >> Signed-off-by: Eric Curtin
> >>
> >> diff --git a/tools/usb/usbip/src/usbip_detach.c
> >> b/tools/usb/usbip/src/usbip_detach.c
>
DWC2 module on some platforms needs three additional hardware
resources: phy controller, clock and power supply. All of them must be
enabled/activated to properly initialize and operate. This was initially
handled in s3c-hsotg driver, which has been converted to 'gadget' part
of dwc2 driver. Unfort
On 2015-09-15 20:09, Steve Calfee wrote:
On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin wrote:
Signed-off-by: Eric Curtin
diff --git a/tools/usb/usbip/src/usbip_detach.c
b/tools/usb/usbip/src/usbip_detach.c
index 05c6d15..9db9d21 100644
--- a/tools/usb/usbip/src/usbip_detach.c
+++ b/tools/usb
Hello,
There is my next patches series containing few fixes and slightly
reworking USB gadget function API. It introduces ep->enabled flag which
indicates whether endpointis enabled or not, and encapsulates its checking
and setting into usb_ep_enable() and usb_ep_disable() functions. So now
these
Fix comments in code to make them up to date.
composite: claiming endpoint is now done by setting ep->claimed flag,
not ep->driver_data.
epautoconf: usb_ep_autoconfig() and usb_ep_autoconfig_ss() return
claimed endpoint with ep->claimed flag already set.
Signed-off-by: Robert Baldyga
---
drive
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_ecm, ep->driver_data was used only for endpoint
This patch introduces usb_ep_autoconfig_release() function which allows
to release endpoint previously obtained from usb_ep_autoconfig() during
USB function bind.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/epautoconf.c | 17 +
include/linux/usb/gadget.h | 2 ++
2
The 'driver_data' field in ep0 is never set to pointer to cdev, so we
have to obtain it from another source as in this context ep->driver_data
contains invalid data.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/function/f_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This patch introduces 'enabled' flag in struct usb_ep, and modifies
usb_ep_enable() and usb_ep_disable() functions to encapsulate endpoint
enabled/disabled state. It helps to avoid enabling endpoints which are
already enabled, and disabling endpoints which are already disables.
>From now USB funct
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_hid we only need to store in ep->driver_data poi
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_phonet we only need to store in ep->driver_data
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_hid we only need to store in ep->driver_data poi
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_midi we only need to store in ep->driver_data po
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_ncm, ep->driver_data was used only for endpoint
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_obex, ep->driver_data was used only for endpoint
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_mass_storage we only need to store in ep->driver
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_uac2, ep->driver_data was used only for endpoint
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of dbgp, ep->driver_data was used only for endpoint c
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of u_serial ep->driver_data stores pointer to struct
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of tcm, ep->driver_data was used only for endpoint cl
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of u_ether we only need to store in ep->driver_data p
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_subset, ep->driver_data was used only for endpoi
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_uac1, ep->driver_data was used only for endpoint
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_sourcesink we only need to store in ep->driver_d
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_serial, ep->driver_data was used only for endpoi
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_rndis, ep->driver_data was used only for endpoin
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_printer we only need to store in ep->driver_data
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_uvc, ep->driver_data was used only for endpoint
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_acm we only need to store in ep->driver_data poi
Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.
In case of f_ecm, ep->driver_data was used only for endpoint
On 09/15/2015 05:45 PM, Krzysztof Opasiak wrote:
>
>
> On 09/15/2015 04:26 PM, Robert Baldyga wrote:
>> Since ep->driver_data is not used for endpoint claiming, neither for
>> enabled/disabled state storing, we can reduce number of places where
>> we read or modify it's value, as now it has no pa
They aren't needed and are just creating null statements so remove it.
Signed-off-by: Javier Martinez Canillas
---
drivers/mmc/host/vub300.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/vub300.c b/drivers/mmc/host/vub300.c
index fbabbb82b354..1e819
On 15-09-16 15:54:21, Peter Chen wrote:
> On Wed, Sep 16, 2015 at 02:18:49PM +0530, maitysancha...@gmail.com wrote:
> > Hello Peter,
> >
> > >
> > > Enable CONFIG_DEBUG_LIST, it has below position if you
> > > run make menuconfig
> > > Kernel hacking --->
> > > [*] Debug linked list manipulation
On Wed, Sep 16, 2015 at 02:18:49PM +0530, maitysancha...@gmail.com wrote:
> Hello Peter,
>
> >
> > Enable CONFIG_DEBUG_LIST, it has below position if you
> > run make menuconfig
> > Kernel hacking --->
> > [*] Debug linked list manipulation
> >
>
> Sorry for the delay. When I enabled this co
Hello Peter,
On 15-09-14 13:11:16, Peter Chen wrote:
> On Fri, Sep 11, 2015 at 04:51:22PM +0530, maitysancha...@gmail.com wrote:
> > On 15-09-11 15:56:17, maitysancha...@gmail.com wrote:
> > > Hello Peter,
> > >
> > > On 15-09-11 16:58:52, Peter Chen wrote:
> > > > On Fri, Sep 11, 2015 at 02:36:5
From: "Peter E. Berger"
Fix non-standard formatting in some of the comments.
Signed-off-by: Peter E. Berger
---
drivers/usb/serial/io_ti.c | 148 +
1 file changed, 96 insertions(+), 52 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/u
From: "Peter E. Berger"
Remove extra blank lines in the several places where functions were
separated by more than one.
Signed-off-by: Peter E. Berger
---
drivers/usb/serial/io_ti.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
From: "Peter E. Berger"
Separate the download and boot mode code from download_fw() into two new
helper functions: do_download_mode() and do_boot_mode().
Signed-off-by: Peter E. Berger
---
drivers/usb/serial/io_ti.c | 362 -
1 file changed, 195 inser
From: "Peter E. Berger"
Move request_firmware from edge_startup to download_fw.
Signed-off-by: Peter E. Berger
---
drivers/usb/serial/io_ti.c | 56 +-
1 file changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/driver
From: "Peter E. Berger"
Remove unused "dev" parameter from build_i2c_fw_hdr() and its caller.
Signed-off-by: Peter E. Berger
---
drivers/usb/serial/io_ti.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 0ac
From: "Peter E. Berger"
Use serial->interface instead of serial->dev for messages in download_fw().
Signed-off-by: Peter E. Berger
---
drivers/usb/serial/io_ti.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index fc
From: "Peter E. Berger"
While working on a previous patchset for this driver [1] we were
hampered by the facts that download_fw() is very long and its return
paths are so complicated. Thus we were compelled to put the patched
request_firmware() call in edge_startup(), when it much more naturally
From: Peter Chen
Add "fsl,imx6ul-usbphy" compatible string for iMX6ul usb phy
Signed-off-by: Peter Chen
Signed-off-by: Li Jun
---
drivers/usb/phy/phy-mxs-usb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 4d863eb.
From: Peter Chen
Add imx6ul usb support.
Signed-off-by: Peter chen
Signed-off-by: Li Jun
---
Change for v2:
- remove CI_HDRC_DISABLE_HOST_STREAMING.
drivers/usb/chipidea/ci_hdrc_imx.c | 6 ++
drivers/usb/chipidea/usbmisc_imx.c | 4
2 files changed, 10 insertions(+)
diff --git a/dri
Aaro Koskinen wrote:
> On Tue, Sep 15, 2015 at 09:27:20PM +0100, Eric Curtin wrote:
>> -for (unsigned int i = 0; i < strlen(port); i++)
>> +unsigned int port_len = strlen(port);
>> +
>> +for (unsigned int i = 0; i < port_len; i++)
>
> port is read only in this function, so maybe just us
On Wed, Sep 16, 2015 at 02:50:01PM +0800, Li Jun wrote:
> From: Peter Chen
>
> Add imx6ul usb support.
>
> Signed-off-by: Peter chen
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 7 +++
> drivers/usb/chipidea/usbmisc_imx.c | 4
> 2 files changed, 11 insertions(
Use imx6sx instead of imx6sl's platform flags for imx6sx.
Fixes: e14db48dfcf3 ("usb: chipidea: imx: add runtime power management support")
Cc: # v4.1+
Signed-off-by: Li Jun
---
drivers/usb/chipidea/ci_hdrc_imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chi
89 matches
Mail list logo
