This patch adds below registers dump for debug:
- USBINTR
- USBSTS
- USBMODE
- USBCMD
- PORTSC
- OTGSC
Signed-off-by: Li Jun
---
Change for v2:
Add ci->is_otg condition check for otgsc register read.
drivers/usb/chipidea/debug.c | 51 ++
1 file changed
This patch moves usb interrupt enable and status register read functions
from udc driver to core driver to use them in all ci drivers.
Acked-by: Peter Chen
Signed-off-by: Li Jun
---
drivers/usb/chipidea/ci.h |4
drivers/usb/chipidea/core.c | 20
drivers/usb/chi
From: Li Jun
Use a more general way to read and write otgsc register.
Signed-off-by: Li Jun
---
Changes for v2:
Use one API for otgsc regiter write, and add mask as input parameter
for otgsc register target bits read.
drivers/usb/chipidea/core.c | 16 ++--
drivers/usb/chipidea/
From: hayeswang
Date: Fri, 14 Mar 2014 10:37:21 +0800
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Friday, March 14, 2014 1:22 AM
> [...]
>> And I fundamentally disagree with this being a Kconfig parameter.
>>
>> Make it run-time calculated _or_ settable via ethtool.
>
> Excuse
From: David Miller [mailto:da...@davemloft.net]
Sent: Friday, March 14, 2014 1:22 AM
[...]
> And I fundamentally disagree with this being a Kconfig parameter.
>
> Make it run-time calculated _or_ settable via ethtool.
Excuse me. How should I make it run-time calculated without a
Kconfig parame
>
> > According to Power_ePAPR_APPROVED_v1.1.pdf "ethernet-phy" is the node
> > name, it is the same with Sergei's suggestion.
>
> Nobody's talking about "ehternet-phy" here.
>
Hmm, you take "ethernet-phy" as an example, and suggest changing to "usb-phy"
at last email.
> > But you have
For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w
On Thursday 13 March 2014 19:09:41 Gene Heskett did opine:
> On Thursday 13 March 2014 18:15:06 David Mosberger did opine:
> > To answer my own question: it appears that USB peripherals return NAKs
> > not only when the peripheral is not ready to accept the data, but also
> > when the peripheral d
Hi there,
After much googling I'm reporting this issue here, as I believe (but
certainly am not sure) its the best place.
I've produced a gist to track this issue at
https://gist.github.com/diabolo/9538091, if you need extra information
I'm happy to add it there and/or include it in this thread.
> > > That does mean I need a) all of the Maintainer Acks and b) you to tell
> > > me which ones need to go through a single tree.
> >
> > You need to take patches 1 to 6 in the MFD tree. Out of these, patches 1 to
> > 4
> > need to be shared with Tony as an immutable branch.
> >
> > Tony, could
On Thursday 13 March 2014 18:15:06 David Mosberger did opine:
> To answer my own question: it appears that USB peripherals return NAKs
> not only when the peripheral is not ready to accept the data, but also
> when the peripheral doesn't know what to do with the data. So an
> infinite series of N
On Thu, 2014-03-13 at 17:33 -0400, Alan Stern wrote:
> On Thu, 13 Mar 2014, Dan Williams wrote:
>
> > Sorry for the delay, I know it's distracting to lose context like this.
>
> No problem.
>
> > > In fact, do we need the pre/post_modify actions at all? Wouldn't it be
> > > sufficient to do ju
To answer my own question: it appears that USB peripherals return NAKs
not only when the peripheral is not ready to accept the data, but also
when the peripheral doesn't know what to do with the data. So an
infinite series of NAKs basically is just the device's way of saying:
I don't know what the
On Thu, Mar 13, 2014 at 04:41:47PM -0500, Dan Williams wrote:
> On Thu, 2014-03-13 at 22:25 +0200, Pasi Kärkkäinen wrote:
> > On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
> > >
> > > [quote Enrico Mioso]
> > >
> > > So this is a new, revised, edition of the huawei_cdc_ncm.c driver,
On Tue, 2014-03-11 at 22:42 +, Paul Zimmerman wrote:
> > From: Dinh Nguyen [mailto:dinh.li...@gmail.com]
> > Sent: Monday, March 10, 2014 5:52 AM
> >
> > In preparation of combining the dwc2/s3c-hsotg driver in a single DRD
> > driver,
> > the defines in dwc2/hw.h needs to get updated so that
Thanks Johan,
Apologies for not including lsusb output before, I was having hardware
issues. It's included below
https://gist.github.com/bewest/6488955#file-lsusb
I can take patches, sure.
Would it be possible for me to just follow someone's branch from somewhere?
I'm currently using (after ubun
Hi,
On Thu, Mar 13, 2014 at 10:20:24AM -0500, Felipe Balbi wrote:
> On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote:
> > This fixes a regression on Keystone 2 platforms caused by patch
> > 57303488cd37da58263e842de134dc65f7c626d5
> > "usb: dwc3: adapt dwc3 core to use Generic PHY
On Wed, 12 Mar 2014, Tony Lindgren wrote:
> * Roger Quadros [140307 02:18]:
> > From: Keshava Munegowda
> >
> > Create hwmods for ocp2scp3 and sata modules.
>
> Paul, does this look OK to you?
I didn't go over every entry with a magnifying glass, but did take a
quick look at the sysc_offs an
On Thu, 2014-03-13 at 22:25 +0200, Pasi Kärkkäinen wrote:
> On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
> >
> > [quote Enrico Mioso]
> >
> > So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
> > supports devices resembling the NCM standard, but using it als
On Thu, 13 Mar 2014, Dan Williams wrote:
> Sorry for the delay, I know it's distracting to lose context like this.
No problem.
> > In fact, do we need the pre/post_modify actions at all? Wouldn't it be
> > sufficient to do just a pm_runtime_get_sync on the SuperSpeed peer?
>
> I think we miss
Unconditionally wake up the child device when the power session is
recovered.
This address the following scenarios:
1/ The device may need a reset on power-session loss, without this
change port power-on recovery exposes khubd to scenarios that
usb_port_resume() is set to handle. Prior to
From: Lan Tianyu
describe the mechanisms for controlling port power policy and
discovering the port power state.
Cc: Oliver Neukum
[oliver]: fixes, clarification of wakeup vs port-power-control
Signed-off-by: Lan Tianyu
[sarah]: wordsmithing
[djbw]: updates for peer port changes
Signed-off-by:
In general we do not want khubd to act on port status changes that are
the result of in progress resets or USB runtime PM operations.
Specifically port power control testing has been able to trigger an
unintended disconnect in hub_port_connect_change(), paraphrasing:
if ((portstatus & USB_
Resuming a powered down port sometimes results in the port state being
stuck in the training sequence.
hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
port1: can't get reconnection after setting port power on, status -110
hub 3-0:1.0: port 1 status .02e0 after resume, -
Three reasons:
1/ It's an invalid operation on usb3 ports
2/ There's no guarantee of when / if a usb2 port has entered an error
state relative to PORT_POWER request
3/ The port is active / powered at this point, so khubd will clear it as
a matter of course
Signed-off-by: Dan Williams
---
d
Per Alan's request this is the second half of the series that addresses
the following disconnect scenarios when attempting to use port
power-off. Now that part1 is mostly acked, these 8 patches address
scenarios 2 and 3. Scenario one was addressed in part1 [1]
1/ Superspeed devices downgrade to
The port pm_runtime implementation unconditionally clears FEAT_C_ENABLE
after clearing PORT_POWER, but the bit is reserved on usb3 hub ports.
We expect khubd to be prevented from running because the port state is
not RPM_ACTIVE, so we need to clear any errors for usb2 ports.
Signed-off-by: Dan Wil
If a port is powered-off, or in the process of being powered-off, prevent
khubd from operating on it. Otherwise, the following sequence of events
leading to an unintended disconnect may occur:
Events:
(0)
(1) hub 2-2:1.0: hub_resume
(2) hub 2-2:1.0: port 1: status 0301 change
(3) hub 2-2:1.
In preparation for synchronizing port handling with pm_runtime
transitions refactor port handling into its own subroutine.
We expect that clearing some status flags will be required regardless of
the port state, so handle those first and group all non-trivial actions
at the bottom of the routine.
On Mon, Nov 04, 2013 at 09:50:46AM +0100, Bjørn Mork wrote:
>
> [quote Enrico Mioso]
>
> So this is a new, revised, edition of the huawei_cdc_ncm.c driver, which
> supports devices resembling the NCM standard, but using it also as a mean
> to encapsulate other protocols, as is the case for the
Sorry for the delay, I know it's distracting to lose context like this.
I was traveling this week for a personal matter, and I spent some extra
time experimenting and convincing myself that we do not want to
warm-reset by default.
Picking up where we left off...
On Thu, 2014-03-06 at 15:14 -0500,
[ Adding Sarah as Cc. ]
On Wed, Mar 12, 2014 at 10:29:13AM -0700, Benjamin West wrote:
> Howdy,
>
> First, many many thanks for usbserial and friends!
> I'm using a Medtronic Carelink usb stick (to download my insulin pump data).
> With usb 2.0 ports, it works very well thanks to the usbserial mo
From: David Laight
Date: Thu, 13 Mar 2014 13:12:35 +
> From: Hayes Wang
> ...
>
> I should have spotted this before.
>
>> /* USB_RX_EARLY_AGG */
>> -#define EARLY_AGG_SUPPER0x0e832981
>> +#define EARLY_AGG_SUPER rx_buf_sz - 1522) / 4) << 16) | \
>> +(u32)(CONFIG_RTL8152_EAR
Alan,
On Thu, Mar 13, 2014 at 11:12 AM, Alan Stern wrote:
> Okay. Maybe this would have been easier to see if you had been writing
> actual data instead of just a lot of zeros; the errors would have shown
> up when you checked the received data (incorrect checksum or something
> like that).
Pe
On Thu, 13 Mar 2014, David Mosberger wrote:
> OK, I finally know where the problem is coming from! The MAX3421E
> chip uses double-buffering. Specifically, it has two 64-byte send
> FIFOs. You write up to 64 bytes to a send FIFO by repeatedly writing
> to SPI register 2 (SNDFIFO). Then you tel
OK, I finally know where the problem is coming from! The MAX3421E
chip uses double-buffering. Specifically, it has two 64-byte send
FIFOs. You write up to 64 bytes to a send FIFO by repeatedly writing
to SPI register 2 (SNDFIFO). Then you tell the chip how many bytes
you just put in the FIFO by
Add function which allow to remove USB function.
This functions also remove function from internal
library structures what means that after this
operation all pointers to removed function are invalid.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h | 10 ++
src/usbg.c
Path and name length should not be placed in constant
size buffer but in allocated memory.
Use also PATH_MAX macro from limits.h instead of internal
library macro. Handle overflows of snprintf in related funcitons.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h |1 +
src/usbg.c
Add function which allow to remove configuration.
This functions also remove binding from internal
library structures what means that after this
operation all pointers to removed config are invalid.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h | 10
src/usbg.c |
Removing gadget/config/function/binding functionality
has been added to API so add example of how to use it.
Signed-off-by: Krzysztof Opasiak
---
examples/Makefile.am |3 +-
examples/gadget-vid-pid-remove.c | 113 ++
include/usbg/usbg.h
Usage of sprintf() may be dangerous in some cases
so use snprintf() to avoid writing after allocated
memory.
Replace USBG_MAX_PATH_SIZE with PATH_MAX from limits.h
to be consistent with maximum size of path.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h |1 -
src/usbg.c
Path and name length should not be placed in constant
size buffer but in allocated memory.
Use also PATH_MAX macro from limits.h instead of internal
library macro. Handle overflows of snprintf in related funcitons.
Signed-off-by: Krzysztof Opasiak
---
src/usbg.c | 177 +
Add function which allow to remove USB gadget.
This functions also remove gadget from internal
library structures what means that after this
operation all pointers to removed gadget are invalid.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h | 10 ++
src/usbg.c | 5
Path and name length should not be placed in constant
size buffer but in allocated memory.
Use also PATH_MAX macro from limits.h instead of internal
library macro. Handle overflows of snprintf in related funcitons.
Signed-off-by: Krzysztof Opasiak
---
src/usbg.c | 91 +
Add functions which allow to remove strings in gadget
and configuration.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h | 16 +++
src/usbg.c | 56 +++
2 files changed, 72 insertions(+)
diff --git a/include/usbg/u
Path and name length should not be placed in constant
size buffer but in allocated memory.
Signed-off-by: Krzysztof Opasiak
---
src/usbg.c | 61
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
Path length should not be placed in constant size buffer
but in allocated memory.
Signed-off-by: Krzysztof Opasiak
---
configure.ac |1 +
src/usbg.c | 16
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 45449e2..878c2ab 1
Add function which allow to remove binding between function
and configuration. This functions also remove binding from
internal library structures wht means that after this
operation all pointers to removed binding are invalid.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h | 10
Dear Matt,
In this series of patch I have added remove gadget, config, function,
binding functionality which was missing since introduction of library.
I have also added remove strings functionality which allow to remove
gadget and configuration strings in given language.
To show how to use new p
From: Krzysztof Opasiak
> Path and name length should not be placed in constant
> size buffer but in allocated memory.
>
> Use also PATH_MAX macro from limits.h instead of internal
> library macro.
There might be some sense in keeping USBG_MAX_PATH_LENGTH
but defaulting to PATH_MAX.
...
> -
Usage of sprintf() may be dangerous in some cases
so use snprintf() to avoid writing after allocated
memory.
Replace USBG_MAX_PATH_SIZE with PATH_MAX from limits.h
to be consistent with maximum size of path.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h |1 -
src/usbg.c
Path and name length should not be placed in constant
size buffer but in allocated memory.
Signed-off-by: Krzysztof Opasiak
---
src/usbg.c | 61
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git a/src/usbg.c b/src/usbg.c
Path and name length should not be placed in constant
size buffer but in allocated memory.
Use also PATH_MAX macro from limits.h instead of internal
library macro. Handle overflows of snprintf in related funcitons.
Signed-off-by: Krzysztof Opasiak
---
src/usbg.c | 91 +
Path and name length should not be placed in constant
size buffer but in allocated memory.
Use also PATH_MAX macro from limits.h instead of internal
library macro. Handle overflows of snprintf in related funcitons.
Signed-off-by: Krzysztof Opasiak
---
src/usbg.c | 177 +
Path length should not be placed in constant size buffer
but in allocated memory.
Signed-off-by: Krzysztof Opasiak
---
configure.ac |1 +
src/usbg.c | 16
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 45449e2..878c2ab 1
Path and name length should not be placed in constant
size buffer but in allocated memory.
Use also PATH_MAX macro from limits.h instead of internal
library macro. Handle overflows of snprintf in related funcitons.
Signed-off-by: Krzysztof Opasiak
---
include/usbg/usbg.h |1 +
src/usbg.c
Dear Matt,
due to recent discussion at linux-usb mailing list [1] about usage
of sprintf in libusbg I took up the task to fix this issue.
I have removed fixed size tabs in library structures reserved for
name and path and replaced the with dynamically alocated strings.
I have also replaced sprin
On Thu, 13 Mar 2014, Oliver Neukum wrote:
> On Thu, 2014-03-13 at 10:11 -0400, Alan Stern wrote:
> > On Thu, 13 Mar 2014, Oliver Neukum wrote:
> >
> > > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > > > My thought was to fix the usbcore rebind issue (with pm_runtime)
> > > > to let
Hello.
On 13-03-2014 7:17, Peter Chen wrote:
It also adapt the dts that uses it.
Signed-off-by: Denis Carikli
[...]
According to Power_ePAPR_APPROVED_v1.1.pdf
"ethernet-phy" is the node name, it is the same with Sergei's suggestion.
Nobody's talking about "ehternet-phy" here.
But
Hi,
On Thu, Mar 13, 2014 at 07:37:12PM +0530, Suresh Gupta wrote:
> From: Suresh Gupta
return -ENOLOG
> Signed-off-by: Suresh Gupta
> ---
> drivers/usb/gadget/fsl_udc_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/gadget/fsl_udc_core.c
> b/drivers/usb/gadget/fsl
On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
> From: Suresh Gupta
>
> Add FSL USB Gadget entry in platform device id table
why this tab ?
> Signed-off-by: Suresh Gupta
> ---
> drivers/usb/gadget/fsl_udc_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/
On Thu, Mar 13, 2014 at 06:41:50PM +0530, Suresh Gupta wrote:
> Message helps to understand that the Freescale Gadget driver
> is up without any error.
why this tab ?
>
> Signed-off-by: Suresh Gupta
> ---
> drivers/usb/gadget/fsl_udc_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
Hi,
On Thu, Mar 13, 2014 at 06:40:55PM +0530, Suresh Gupta wrote:
> Attached is a small fix for the fsl usb gadget driver. This fix the
> driver in a way that the usb device will be only "pulled up" on requests
> like other usb gadget drivers do.
> This is necessary, because the device information
On Thu, Mar 13, 2014 at 01:11:13PM +0200, Grygorii Strashko wrote:
> This fixes a regression on Keystone 2 platforms caused by patch
> 57303488cd37da58263e842de134dc65f7c626d5
> "usb: dwc3: adapt dwc3 core to use Generic PHY Framework" which adds
> optional support of generic phy in DWC3 core.
>
>
On Thu, 2014-03-13 at 10:11 -0400, Alan Stern wrote:
> On Thu, 13 Mar 2014, Oliver Neukum wrote:
>
> > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > > My thought was to fix the usbcore rebind issue (with pm_runtime)
> > > to let the core unbind and rebind the device's interfaces for
Yeah, sorry, the READ_10s were a total red herring. They're there
because I forgot to specify bs=1024. ;-(
I'll try to capture better traces today and if they look interesting,
make them available.
--david
--
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.976
--
To unsubsc
On Wed, 12 Mar 2014, David Mosberger wrote:
> On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern wrote:
> > On Wed, 12 Mar 2014, David Mosberger wrote:
>
> >> I see the same WRITE_10 commands of 122,880 bytes (240 sectors), but
> >> the glaring difference is that each such WRITE_10 command seems to be
On Thu, 13 Mar 2014, Jagdish Gedia wrote:
> Hi,
> I want to check in my driver if usb device is suspended or not?
Why do you need to check? Your driver gets told every time the device
suspends and every time it resumes. Therefore it should already know
the answer.
> currently i am doing it l
On Thu, 13 Mar 2014, Oliver Neukum wrote:
> On Thu, 2014-03-13 at 08:05 +, Peter Chen wrote:
> > >
> > > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
>
> > > > Implementing the btusb reset_resume seems risky, a patch implementing
> > > > this callback has been previously reverted
On Thu, 13 Mar 2014, Oliver Neukum wrote:
> On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > My thought was to fix the usbcore rebind issue (with pm_runtime)
> > to let the core unbind and rebind the device's interfaces for drivers
> > with no reset_resume callback (not only btusb).
>
On Thursday 13 March 2014 09:43 PM, Kishon Vijay Abraham I wrote:
> Hi Santosh,
>
> On Thursday 13 March 2014 07:07 PM, Santosh Shilimkar wrote:
>> On Thursday 13 March 2014 07:11 PM, Strashko, Grygorii wrote:
>>> This fixes a regression on Keystone 2 platforms caused by patch
>>> 57303488cd37da58
Hi Santosh,
On Thursday 13 March 2014 07:07 PM, Santosh Shilimkar wrote:
On Thursday 13 March 2014 07:11 PM, Strashko, Grygorii wrote:
This fixes a regression on Keystone 2 platforms caused by patch
57303488cd37da58263e842de134dc65f7c626d5
"usb: dwc3: adapt dwc3 core to use Generic PHY Framewor
On Thursday 13 March 2014 07:11 PM, Strashko, Grygorii wrote:
> This fixes a regression on Keystone 2 platforms caused by patch
> 57303488cd37da58263e842de134dc65f7c626d5
> "usb: dwc3: adapt dwc3 core to use Generic PHY Framework" which adds
> optional support of generic phy in DWC3 core.
>
> On K
From: Hayes Wang
...
I should have spotted this before.
> /* USB_RX_EARLY_AGG */
> -#define EARLY_AGG_SUPPER 0x0e832981
> +#define EARLY_AGG_SUPER rx_buf_sz - 1522) / 4) << 16) | \
> + (u32)(CONFIG_RTL8152_EARLY_AGG_TIMEOUT_SUPER <= 0 ? 85 * 125 : \
> + min(CONFIG_RTL8152_EA
On Thu, 2014-03-13 at 17:13 +0530, Jagdish Gedia wrote:
> Hi,
> I want to check in my driver if usb device is suspended or not?
> currently i am doing it like
>
> if(udev->state==USB_STATE_SUSPENDED)
>
> Is this the proper way? Is this enough?
This question is near meaningless. Assuming that you
For slow CPU, the frequent bulk transfer would cause poor throughput.
One solution is to increase the timeout of the aggregation. It let
the hw could complete the bulk transfer later and fill more packets
into the buffer. Besides, it could reduce the frequency of the bulk
transfer efficiently and i
Add opportunity to change the default setting and reduce the tx/rx
buffers.
v2: modify the patch #1 to let the value readable.
v3: modify the definition of the EARLY_AGG_SUPER for patch #1.
Hayes Wang (2):
r8152: add RTL8152_EARLY_AGG_TIMEOUT_SUPER
r8152: reduce the numbers of the bulks
dr
It is not necessary to have many transfer buffers. Reduce the number
from 10 to 4.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 756c0a6..b6bde59 100644
--- a/d
Hi,
I want to check in my driver if usb device is suspended or not?
currently i am doing it like
if(udev->state==USB_STATE_SUSPENDED)
Is this the proper way? Is this enough?
Thanks,
Jagdish Gediya
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a m
On Wed, Mar 12, 2014 at 12:44:27PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Mar 12, 2014 at 07:09:37PM +0100, Johan Hovold wrote:
> > Remove erroneous call to usb_clear_halt which is blocking and cannot be
> > used in interrupt context.
> >
> > This code has possibly never been executed as it wo
On Thu, Mar 13, 2014 at 09:40:02AM +, Ludovic wrote:
> > Did you get a chance to verify my (unmodified) patch (on BE and LE)? Are you
> > able to test it against a recent kernel on your router or are you stuck
> > with an old kernel?
>
> Hi!
>
> I've just installed a VM with a custom kernel t
On Wed, Mar 12, 2014 at 10:35:25PM +0100, Emanuel Koczwara wrote:
> Yes, it works. The device is recognized. I'm waiting for detailed
> informations and logs, I'll post them here (I don't have the device
> anymore). Thank you for your interest.
That sounds promising. It would be interesting to s
This fixes a regression on Keystone 2 platforms caused by patch
57303488cd37da58263e842de134dc65f7c626d5
"usb: dwc3: adapt dwc3 core to use Generic PHY Framework" which adds
optional support of generic phy in DWC3 core.
On Keystone 2 platforms the USB is not working now because
CONFIG_GENERIC_PHY
> Did you get a chance to verify my (unmodified) patch (on BE and LE)? Are you
> able to test it against a recent kernel on your router or are you stuck
> with an old kernel?
Hi!
I've just installed a VM with a custom kernel to be able to test the latest
patch on LE. But for BE, I'm stuck with an
From: Hayes Wang
> For slow CPU, the frequent bulk transfer would cause poor throughput.
> One solution is to increase the timeout of the aggregation. It let
> the hw could complete the bulk transfer later and fill more packets
> into the buffer. Besides, it could reduce the frequency of the bulk
>
On 03/12/2014 12:08 PM, Fabio Estevam wrote:
Hi Denis,
Hi,
As you add me in the From field, you also need to add:
Signed-off-by: Fabio Estevam above your
Signed-off-by line.
Thanks.
+ usbphy {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ c
Signed-off-by: Denis Carikli
---
Changelog v3->v4:
- Moved the compatible of usbphy on top to match the other nodes.
- the usb phy's names were renamed from usbphy to usb-phy.
- The patch renaming the fsl,usbphy property in usb-phy was removed.
So this patch was adapted to that.
Changelog v2->v
Signed-off-by: Denis Carikli
---
Changelog v2->v3:
- Extra gadget drivers additions were removed from this patch.
Changelog v1->v2:
- With the clock fix patches, the usb gadget also work.
So I've addeed it to this patch too.
- CONFIG_USB_OTG_FSM=y was not needed, so it was removed.
---
arch/ar
Signed-off-by: Denis Carikli
---
Changelog v1->v2:
- With the clock fix patches, the usb gadget also work.
So I've set the otg port to otg instead of host.
- Before I forgott to set dr_mode to host in the usbhost port.
That is now fixed.
---
.../boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts
This adds the i.MX25 and the i.MX35 support in the
ChipIdea usbmisc driver.
The i.MX25 and i.MX35 usb controllers are similar enough to be
able to use the same code.
Signed-off-by: Denis Carikli
---
Changelog v3->v4:
- The MXC_EHCI_INTERFACE_* were renamed in MX25_EHCI_INTERFACE_*
- Since the pe
Signed-off-by: Denis Carikli
---
Changelog v1->v2:
- With the clock fix patches, the usb gadget also work.
So I've set the otg port to otg instead of host.
---
.../boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/d
From: Fabio Estevam
Like other imx SoCs only one USB clock is needed on mx35.
Signed-off-by: Fabio Estevam
---
arch/arm/boot/dts/imx35.dtsi |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index e59ccb4..47
From: Fabio Estevam
Signed-off-by: Fabio Estevam
Signed-off-by: Denis Carikli
---
Changelog v3->v4:
- Added Fabio Estevam's Signed-off-by: it was given
as a mail response to this patch.
- Moved the compatible of usbphy on top to match the other nodes.
- the usb phy's names were renamed from u
From: Fabio Estevam
Like other imx SoCs only one USB clock is needed on mx25.
Signed-off-by: Fabio Estevam
---
arch/arm/boot/dts/imx25.dtsi |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 77bb743..82
On Thu, 2014-03-13 at 08:05 +, Peter Chen wrote:
> >
> > On Wed, 2014-03-12 at 15:18 +, Poulain, Loic wrote:
> > > Implementing the btusb reset_resume seems risky, a patch implementing
> > > this callback has been previously reverted due to HID dual mode device
> > > regression. (cf http
From: Suresh Gupta
Signed-off-by: Suresh Gupta
---
drivers/usb/gadget/fsl_udc_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 35b20e6..2a43d9d 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb
From: Suresh Gupta
Add FSL USB Gadget entry in platform device id table
Signed-off-by: Suresh Gupta
---
drivers/usb/gadget/fsl_udc_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index b7dea4e..35b20e6
From: Li Jun
Hi Felipe,
Two for fsm, the other one is to delete CONFIG_USB_OTG_FSM
since it is duplicated with CONFIG_USB_OTG, thanks.
Change on v1:
Remove "{}" for a single statement in patch:
usb: phy-fsm: update OTG HNP state transition.
Li Jun (1):
usb: phy-fsm: update OTG HNP state tran
According to:"On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification July 27, 2012 Revision 2.0 version 1.1a"
- add a_wait_vrise to a_wait_vfall
- update condition from a_wait_vrise to a_wait_bcon
Signed-off-by: Li Jun
---
drivers/usb/phy/phy-fsm-usb.c |7 ---
1 fil
From: Peter Chen
We already have CONFIG_USB_OTG which can cover all CONFIG_USB_OTG_FSM
does.
Cc: Jun Li
Cc: Anton Tikhomirov
Signed-off-by: Peter Chen
---
drivers/usb/phy/Kconfig | 11 +--
drivers/usb/phy/Makefile |2 +-
2 files changed, 2 insertions(+), 11 deletions(-)
diff
1 - 100 of 104 matches
Mail list logo
