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 is not always
available until an application is up and running which
Message helps to understand that the Freescale Gadget driver
is up without any error.
Signed-off-by: Suresh Gupta suresh.gu...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
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).
Those functions seem to be independent. Even
From: Peter Chen peter.c...@freescale.com
We already have CONFIG_USB_OTG which can cover all CONFIG_USB_OTG_FSM
does.
Cc: Jun Li b47...@freescale.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/phy/Kconfig | 11 +--
From: Peter Chen peter.c...@freescale.com
It is should be condition or not bit or.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/phy/phy-fsm-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-fsm-usb.c
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 b47...@freescale.com
---
drivers/usb/phy/phy-fsm-usb.c |
From: Li Jun b47...@freescale.com
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
From: Suresh Gupta b42...@freescale.com
Add FSL USB Gadget entry in platform device id table
Signed-off-by: Suresh Gupta b42...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
From: Suresh Gupta b42...@freescale.com
Signed-off-by: Suresh Gupta b42...@freescale.com
---
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
---
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
From: Fabio Estevam fabio.este...@freescale.com
Like other imx SoCs only one USB clock is needed on mx25.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/boot/dts/imx25.dtsi |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
From: Fabio Estevam fabio.este...@freescale.com
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
Signed-off-by: Denis Carikli de...@eukrea.com
---
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
Signed-off-by: Denis Carikli de...@eukrea.com
---
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
From: Fabio Estevam fabio.este...@freescale.com
Like other imx SoCs only one USB clock is needed on mx35.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
arch/arm/boot/dts/imx35.dtsi |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
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 de...@eukrea.com
---
Changelog v3-v4:
- The MXC_EHCI_INTERFACE_* were renamed in
Signed-off-by: Denis Carikli de...@eukrea.com
---
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.
---
Signed-off-by: Denis Carikli de...@eukrea.com
---
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
Signed-off-by: Denis Carikli de...@eukrea.com
---
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.
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 fabio.este...@freescale.com above your
Signed-off-by line.
Thanks.
+ usbphy {
+ #address-cells = 1;
+
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
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
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 see
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 to be able
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 would
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
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
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
It is not necessary to have many transfer buffers. Reduce the number
from 10 to 4.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
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
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
don't
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 : \
+
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 Keystone
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
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
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).
Those
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 due to HID
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
On Wed, 12 Mar 2014, David Mosberger wrote:
On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern st...@rowland.harvard.edu 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
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
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 drivers
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
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 is
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 suresh.gu...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 1 +
1 file
On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
From: Suresh Gupta b42...@freescale.com
Add FSL USB Gadget entry in platform device id table
why this tab ?
Signed-off-by: Suresh Gupta b42...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 2 ++
1 file changed,
Hi,
On Thu, Mar 13, 2014 at 07:37:12PM +0530, Suresh Gupta wrote:
From: Suresh Gupta b42...@freescale.com
return -ENOLOG
Signed-off-by: Suresh Gupta b42...@freescale.com
---
drivers/usb/gadget/fsl_udc_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hello.
On 13-03-2014 7:17, Peter Chen wrote:
It also adapt the dts that uses it.
Signed-off-by: Denis Carikli de...@eukrea.com
[...]
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
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 the core unbind
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
Path length should not be placed in constant size buffer
but in allocated memory.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
configure.ac |1 +
src/usbg.c | 16
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
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 k.opas...@samsung.com
---
include/usbg/usbg.h |
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 k.opas...@samsung.com
---
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 k.opas...@samsung.com
---
src/usbg.c | 177
Path and name length should not be placed in constant
size buffer but in allocated memory.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c | 61
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git
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 k.opas...@samsung.com
---
include/usbg/usbg.h |1 -
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.
...
- char
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
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 k.opas...@samsung.com
---
Path length should not be placed in constant size buffer
but in allocated memory.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
configure.ac |1 +
src/usbg.c | 16
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
Add functions which allow to remove strings in gadget
and configuration.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
include/usbg/usbg.h | 16 +++
src/usbg.c | 56 +++
2 files changed, 72 insertions(+)
diff
Path and name length should not be placed in constant
size buffer but in allocated memory.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
src/usbg.c | 61
1 file changed, 37 insertions(+), 24 deletions(-)
diff --git
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 k.opas...@samsung.com
---
include/usbg/usbg.h |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 k.opas...@samsung.com
---
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 k.opas...@samsung.com
---
include/usbg/usbg.h | 10 ++
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 k.opas...@samsung.com
---
src/usbg.c | 91
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 k.opas...@samsung.com
---
include/usbg/usbg.h | 10
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 k.opas...@samsung.com
---
include/usbg/usbg.h | 10
Removing gadget/config/function/binding functionality
has been added to API so add example of how to use it.
Signed-off-by: Krzysztof Opasiak k.opas...@samsung.com
---
examples/Makefile.am |3 +-
examples/gadget-vid-pid-remove.c | 113 ++
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 k.opas...@samsung.com
---
include/usbg/usbg.h |
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
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 tell
Alan,
On Thu, Mar 13, 2014 at 11:12 AM, Alan Stern st...@rowland.harvard.edu 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
From: David Laight david.lai...@aculab.com
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) | \
+
[ 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
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
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.
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) set pm_qos_no_poweroff to '0' for port1
(1) hub 2-2:1.0: hub_resume
(2) hub 2-2:1.0: port
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
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
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,
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 tianyu@intel.com
describe the mechanisms for controlling port power policy and
discovering the port power state.
Cc: Oliver Neukum oneu...@suse.de
[oliver]: fixes, clarification of wakeup vs port-power-control
Signed-off-by: Lan Tianyu tianyu@intel.com
[sarah]:
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
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 a
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 also as a
On Wed, 12 Mar 2014, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [140307 02:18]:
From: Keshava Munegowda keshava_mgo...@ti.com
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
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
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 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, which
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
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 just a
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 NAKs
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 you please Ack
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.
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 doesn't
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:
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 changed the
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
From: hayeswang hayesw...@realtek.com
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.
From: Li Jun b47...@freescale.com
Use a more general way to read and write otgsc register.
Signed-off-by: Li Jun b47...@freescale.com
---
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 |
This patch adds below registers dump for debug:
- USBINTR
- USBSTS
- USBMODE
- USBCMD
- PORTSC
- OTGSC
Signed-off-by: Li Jun b47...@freescale.com
---
Change for v2:
Add ci-is_otg condition check for otgsc register read.
drivers/usb/chipidea/debug.c | 51
1 - 100 of 101 matches
Mail list logo
