Hi,
On Tue, Jul 30, 2013 at 10:44:48AM +0530, Kishon Vijay Abraham I wrote:
On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while
creating
MUSB core device. So in usb_bind_phy (binds the controller
On 07/30/2013 12:23 AM, Felipe Balbi wrote:
* PGP Signed by an unknown key
Hi,
On Tue, Jul 30, 2013 at 12:19:32AM +0300, Felipe Balbi wrote:
On Mon, Jul 29, 2013 at 09:24:46AM -0600, Stephen Warren wrote:
On 06/28/2013 06:33 AM, Mikko Perttunen wrote:
Add vbus-supply as an optional property
Hi,
On Tuesday 30 July 2013 11:31 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 10:44:48AM +0530, Kishon Vijay Abraham I wrote:
On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while
creating
MUSB
commit 052a11d (usb: phy: make PHY driver selection
possible by controller drivers) changed the rules
on how drivers/usb/phy/of.c would be compiled and
failed to update include/linux/usb/of.h accordingly.
Because of that, we can fall into situations where
of_usb_get_phy_mode() is redefined. In
Hi,
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@
Hi,
On Tuesday 30 July 2013 11:48 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
---
On Mon, Jul 29, 2013 at 02:44:13PM -0700, Julius Werner wrote:
This patch simplifies the way the phy-samsung-usb code finds the correct
power management register to enable PHY clock gating. Previously, the
code would calculate the register address from a device tree supplied
base address and
Hi,
On Tue, Jul 30, 2013 at 11:55:04AM +0530, Kishon Vijay Abraham I wrote:
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
---
On Tue, Jul 30, 2013 at 07:54:02AM +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return -EINVAL in the vendor param set error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
this
On Tue, Jul 30, 2013 at 09:10:12AM +0300, Mikko Perttunen wrote:
On 07/30/2013 12:23 AM, Felipe Balbi wrote:
* PGP Signed by an unknown key
Hi,
On Tue, Jul 30, 2013 at 12:19:32AM +0300, Felipe Balbi wrote:
On Mon, Jul 29, 2013 at 09:24:46AM -0600, Stephen Warren wrote:
On 06/28/2013
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
---
Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
At Mon, 29 Jul 2013 21:23:15 +0200,
Daniel Mack wrote:
On 29.07.2013 20:20, Alan Stern wrote:
data_ep_set_params() checks snd_usb_endpoint_implicit_feedback_sink()
in three places. It looks like only the second place is correct.
Can you verify whether the other two are right, and
On Tue, Jul 30, 2013 at 09:38:44AM +0300, Mikko Perttunen wrote:
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
return -ENOLOG;
sorry, I can't apply without a commit log. Please mention that the
previous commit had a typo which you're fixing.
--
balbi
signature.asc
Description:
Hi,
On Tuesday 30 July 2013 11:58 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 11:55:04AM +0530, Kishon Vijay Abraham I wrote:
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
The device tree binding documentation for tegra20-usb-phy used to claim
that the vbus-supply property is required for host phys and optional
for otg phys. This should be the other way around.
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
---
On 07/30/2013 09:44 AM, Felipe Balbi wrote:
* PGP Signed by an unknown key
On Tue, Jul 30, 2013 at 09:38:44AM +0300, Mikko Perttunen wrote:
Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
return -ENOLOG;
sorry, I can't apply without a commit log. Please mention that the
previous commit
* Felipe Balbi ba...@ti.com [130729 05:27]:
On Fri, Jul 26, 2013 at 10:15:54PM +0200, Sebastian Andrzej Siewior wrote:
The nop driver isn't a do-nothing-stub but supports a couple functions
like clock on/off or is able to use a voltage regulator. This patch
simply renames the driver to
On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,
On Saturday 20 of July 2013
Hi,
On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
the list of controller device (names) it can support (PHY framework does
not
maintain a separate list for binding like how we had in USB PHY
library). e.g.
On Mon, Jul 29, 2013 at 7:04 PM, Alan Stern st...@rowland.harvard.edu wrote:
It turns out I was probably wrong. Take a look at this message:
http://marc.info/?l=linux-scsim=137511040432420w=2
The patch in that email may fix your problem.
It does. Thanks!
I am unfortunately still
On 07/30/2013 09:08 AM, Tony Lindgren wrote:
Looking at this patch there's a pretty high probability of introducing
pointless merge conflicts.
How about do the platform data related changes as a separate follow-up
series? You can typically do this by keeping the old features around,
then
On 07/30/2013 06:53 AM, George Cherian wrote:
Control module have 2 separate registers for phy on/off per instance
(offset 0x620 and 0x628), where as
wkup_ctrl is a shared control module register (offset 0x648). Currently
the control module driver maps
memory from 0x620 till beyond 0x648
* Sebastian Andrzej Siewior bige...@linutronix.de [130730 00:41]:
On 07/30/2013 09:08 AM, Tony Lindgren wrote:
Looking at this patch there's a pretty high probability of introducing
pointless merge conflicts.
How about do the platform data related changes as a separate follow-up
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/ehci-fsl.c | 14 +++---
drivers/usb/host/ehci-mv.c |2 +-
drivers/usb/host/ehci-mxc.c |4
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/gadget/at91_udc.c |4 ++--
drivers/usb/gadget/atmel_usba_udc.c |2 +-
drivers/usb/gadget/bcm63xx_udc.c|2
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/phy/phy-fsl-usb.c |6 +++---
drivers/usb/phy/phy-gpio-vbus-usb.c | 10 +-
drivers/usb/phy/phy-msm-usb.c
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/chipidea/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/misc/usb3503.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/renesas_usbhs/common.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi,
On Tue, Jul 30, 2013 at 05:00:18PM +0900, Jingoo Han wrote:
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..d42ec85 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -191,7 +191,8 @@ static void start_hnp(struct
On Tue, Jul 30, 2013 at 01:41:23PM +0530, Kishon Vijay Abraham I wrote:
On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote:
the list of controller device (names) it can support (PHY framework
does not
[ Repost without gmail HTML... Sorry about the noise. ]
On Mon, Jul 29, 2013 at 6:33 PM, Frank Schäfer
fschaefer@googlemail.com wrote:
Fixes the following regression that has been introduced recently with commit
b2d6d98fc7:
With type_0 and type_1 chips
- all baud rates 1228800 baud are
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/c67x00/c67x00-drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/c67x00/c67x00-drv.c
Allocate the transfer buffer in probe(), and use the buffer for
usb control transfer.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r815x.c | 117 +---
1 file changed, 90 insertions(+), 27 deletions(-)
diff --git
- fix the conversion between cpu and __le32
- replace some pla_ocp and usb_ocp functions with generic_ocp function
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 66 +
1 file changed, 23 insertions(+), 43
Allocate the required transfer buffer for usb_control_msg.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 91 +++--
1 file changed, 66 insertions(+), 25 deletions(-)
diff --git a/drivers/net/usb/r8152.c
On Tuesday, July 30, 2013 5:08 PM, Felipe Balbi wrote:
On Tue, Jul 30, 2013 at 05:00:18PM +0900, Jingoo Han wrote:
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..d42ec85 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
Hi,
On Tue, Jul 30, 2013 at 05:37:03PM +0900, Jingoo Han wrote:
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..d42ec85 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -191,7 +191,8 @@ static void
On Tue, 30 Jul 2013, Geert Uytterhoeven wrote:
JFYI, when comparing v3.11-rc3 to v3.11-rc2[3], the summaries are:
- build errors: +38/-14
+ arch/powerpc/kvm/book3s_emulate.c: error: 'bat' may be used uninitialized
in this function [-Werror=uninitialized]: = 349:2
+
On 07/30/2013 07:19 AM, George Cherian wrote:
So from what I see now, it is most likely the easiest thing to just add
that wakeup to the phy driver I posted. Do you agree?
The whole idea of writing a seperate phy driver was to use the generic
phy framework
and most of the am devices
On Tuesday, July 30, 2013 5:44 PM, Felipe Balbi wrote:
On Tue, Jul 30, 2013 at 05:37:03PM +0900, Jingoo Han wrote:
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..d42ec85 100644
--- a/drivers/usb/host/ohci-omap.c
+++
On Tue, Jul 30, 2013 at 05:54:26PM +0900, Jingoo Han wrote:
On Tuesday, July 30, 2013 5:44 PM, Felipe Balbi wrote:
On Tue, Jul 30, 2013 at 05:37:03PM +0900, Jingoo Han wrote:
diff --git a/drivers/usb/host/ohci-omap.c
b/drivers/usb/host/ohci-omap.c
index 8747fa6..d42ec85 100644
On 07/30/2013 09:56 AM, Tony Lindgren wrote:
A separate minimal branch against -rc3 sounds good to me.
Great. Felipe, can you please put this change in a separate -rc3 based
branch which you and Tony will pull in?
Regards,
Tony
Sebastian
--
To unsubscribe from this list: send the line
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
---
drivers/usb/host/ehci-fsl.c | 14 +++---
drivers/usb/host/ehci-mv.c |2 +-
drivers/usb/host/ehci-mxc.c |4
Current implementation assumes HZ = 1000 for calculating
all internal timer intervals, which creates problem on
platforms where HZ != 1000.
As well we need resolution of less than 10 mSec for heartbeat
calculation, this creates problem on some platforms where HZ is
configured as HZ = 100, or
Hi,
this two patches are based on the latest series of Peter Chen.
They address the vbus handling for the different roles and move the
vbus glue code into the core layer.
Thanks,
Michael
Michael Grzeschik (1):
usb: chipidea: move vbus regulator operation to core
Peter Chen (1):
usb:
From: Peter Chen peter.c...@freescale.com
For boards which have board level vbus control (eg, through gpio), we
need to vbus operation according to below rules:
- For host, we need open vbus before start hcd, and close it
after remove hcd.
- For otg, the vbus needs to be on/off when usb role
From: Michael Grzeschik m...@pengutronix.de
This patch moves the regulator code from ci_hdrc_imx gluecode to the
core layer. It also checks the errorpathes in case the platformglue
didn't prepare an regulator for this driver.
Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
---
On Tue, Jul 30, 2013 at 01:31:50PM +0100, Rupesh Gujare wrote:
Current implementation assumes HZ = 1000 for calculating
all internal timer intervals, which creates problem on
platforms where HZ != 1000.
As well we need resolution of less than 10 mSec for heartbeat
calculation, this creates
On Tue, Jul 30, 2013 at 02:41:23PM +0200, Michael Grzeschik wrote:
From: Michael Grzeschik m...@pengutronix.de
This patch moves the regulator code from ci_hdrc_imx gluecode to the
core layer. It also checks the errorpathes in case the platformglue
didn't prepare an regulator for this driver.
On 30/07/13 14:12, Dan Carpenter wrote:
On Tue, Jul 30, 2013 at 01:31:50PM +0100, Rupesh Gujare wrote:
Current implementation assumes HZ = 1000 for calculating
all internal timer intervals, which creates problem on
platforms where HZ != 1000.
As well we need resolution of less than 10 mSec for
On Tue, Jul 30, 2013 at 04:28:54PM +0800, Hayes Wang wrote:
Allocate the transfer buffer in probe(), and use the buffer for
usb control transfer.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r815x.c | 117
+---
1 file
On Tue, Jul 30, 2013 at 04:28:55PM +0800, Hayes Wang wrote:
Allocate the required transfer buffer for usb_control_msg.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 91
+++--
1 file changed, 66 insertions(+), 25
On Tue, Jul 30, 2013 at 04:28:54PM +0800, Hayes Wang wrote:
Allocate the transfer buffer in probe(), and use the buffer for
usb control transfer.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r815x.c | 117
+---
1 file
On Tue, Jul 30, 2013 at 11:15:20AM +0300, Felipe Balbi wrote:
look at Greg's and my reply to that email.
but finally Greg agreed to what Tomasz proposed no?
that's not what I see in the thread. I see Greg agreed to regulator's
own IDs being sequentially created, but he mentions device
On 7/30/2013 2:23 PM, Sebastian Andrzej Siewior wrote:
On 07/30/2013 07:19 AM, George Cherian wrote:
So from what I see now, it is most likely the easiest thing to just add
that wakeup to the phy driver I posted. Do you agree?
The whole idea of writing a seperate phy driver was to use the
On Tue, Jul 30, 2013 at 4:28 PM, Hayes Wang hayesw...@realtek.com wrote:
Allocate the transfer buffer in probe(), and use the buffer for
usb control transfer.
Looks this is a usbnet device, so suggest to use usbnet command APIs
(usbnet_read_cmd/usbnet_write_cmd) to do that, another advantage is
On Tue, Jul 30, 2013 at 07:54:55PM +0530, George Cherian wrote:
On 7/30/2013 2:23 PM, Sebastian Andrzej Siewior wrote:
On 07/30/2013 07:19 AM, George Cherian wrote:
So from what I see now, it is most likely the easiest thing to just add
that wakeup to the phy driver I posted. Do you agree?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/30/2013 04:33 PM, Felipe Balbi wrote:
let's try not to add any new TI-specific DT bindings, can you
figure that out by reading some revision register ? Or perhaps by
using different compatible strings ?
I would suggest to use a different
On Mon, 29 Jul 2013, Stoddard, Nate (GE Healthcare) wrote:
Our design's USB topology is as follows:
FS device #1 -| |
FS device #2 -| |
|-- HS Hub #1--|---|
FS device #3 -|
On Mon, 2013-07-29 at 10:21 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, Oliver Neukum wrote:
On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
In addition to my earlier comment, the patch below should be applied.
It will fix your immediate problem, although not in the best
On Tue, 2013-07-30 at 06:58 -0700, Greg KH wrote:
In the future, you do not need to send drivers/net/usb/ patches to me,
netdev and the linux-usb mailing lists should be sufficient.
Signed-off-by: Joe Perches j...@perches.com
---
This might help...
diff --git a/MAINTAINERS b/MAINTAINERS
On Mon, 29 Jul 2013, James Stone wrote:
OK, having said that, I just got it to happen - listening to audacity
and just logging into Facebook (of all things!! Meh!)
This is the contents of the trace file (as per instructions on bug #1191603)
# tracer: irqsoff
#
# irqsoff latency trace
On Tue, 30 Jul 2013, Philipp Dreimann wrote:
On Mon, Jul 29, 2013 at 7:04 PM, Alan Stern st...@rowland.harvard.edu wrote:
It turns out I was probably wrong. Take a look at this message:
http://marc.info/?l=linux-scsim=137511040432420w=2
The patch in that email may fix your
On Tue, 30 Jul 2013, Oliver Neukum wrote:
On Mon, 2013-07-29 at 10:21 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, Oliver Neukum wrote:
On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
In addition to my earlier comment, the patch below should be applied.
It will fix
The USB hub driver's event handler contains a check to catch SuperSpeed
devices that transitioned into the SS.Inactive state and tries to fix
them with a reset. It decides whether to do a plain hub port reset or
call the usb_reset_device() method based on whether there was a device
attached to the
-andiry.xu... he wrote that section originally but it seems that his
address is no longer available.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 30 Jul 2013, Julius Werner wrote:
The USB hub driver's event handler contains a check to catch SuperSpeed
devices that transitioned into the SS.Inactive state and tries to fix
them with a reset. It decides whether to do a plain hub port reset or
call the usb_reset_device() method
On Tue, 2013-07-30 at 11:42 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, James Stone wrote:
Just an FYI, it is usually better to email my rost...@goodmis.org
account. I don't always read my redhat email. That's reserved for
bugzillas assigned to me ;-)
OK, having said that, I just got it
From: Greg KH gre...@linuxfoundation.org
Date: Tue, 30 Jul 2013 07:00:59 -0700
This call is so slow, you can afford to make a call to kmalloc for the
data, as it sure just did for other structures it needed :)
I told him to implement things this way, to avoid calling kmalloc every
single
On Tue, 2013-07-30 at 11:33 -0700, David Miller wrote:
From: Greg KH gre...@linuxfoundation.org
Date: Tue, 30 Jul 2013 07:00:59 -0700
This call is so slow, you can afford to make a call to kmalloc for the
data, as it sure just did for other structures it needed :)
I told him to
On Tue, 30 Jul 2013, Steven Rostedt wrote:
On Tue, 2013-07-30 at 11:42 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, James Stone wrote:
Just an FYI, it is usually better to email my rost...@goodmis.org
account. I don't always read my redhat email. That's reserved for
bugzillas assigned to
On Mon, 29 Jul 2013, Stuart Foster wrote:
Stuart and Ed, does Martin's patch fix your problem?
Alan Stern
Hi Alan,
The patch is good for me.
thanks
There also have been positive reports from Marc Meledandri and Philipp
Dreimann.
Martin, please submit your patch for inclusion
On Tue, Jul 30, 2013 at 02:05:29PM -0400, Steven Rostedt wrote:
On Tue, 2013-07-30 at 11:42 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, James Stone wrote:
Just an FYI, it is usually better to email my rost...@goodmis.org
account. I don't always read my redhat email. That's reserved for
From: Joe Perches j...@perches.com
Date: Tue, 30 Jul 2013 11:41:17 -0700
On Tue, 2013-07-30 at 11:33 -0700, David Miller wrote:
From: Greg KH gre...@linuxfoundation.org
Date: Tue, 30 Jul 2013 07:00:59 -0700
This call is so slow, you can afford to make a call to kmalloc for the
data, as
-Original Message-
All of the hubs support Multi-TT. Based on this topology, I would
assume Hub #1 and Hub #2 perform the FS splitting, and the EHCI
controller on the USB host performs the FS un-splitting. Hub #3 would
only be passing high speed traffic between Hubs 1/2 and
On Tue, Jul 30, 2013 at 11:33:29AM -0700, David Miller wrote:
From: Greg KH gre...@linuxfoundation.org
Date: Tue, 30 Jul 2013 07:00:59 -0700
This call is so slow, you can afford to make a call to kmalloc for the
data, as it sure just did for other structures it needed :)
I told him to
This patch fixes a NULL pointer dereference and a WARN_ON in
dummy-hcd. These things were the result of moving to the UDC core
framework, and possibly of changes to that framework.
Now unloading a gadget driver causes the UDC to be stopped after the
gadget driver is unbound, not before.
The following changes since commit 2c7b871b9102c497ba8f972aa5d38532f05b654d:
usb: Clear both buffers when clearing a control transfer TT buffer.
(2013-07-25 11:37:13 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/
On Tue, Jul 30, 2013 at 12:52:40PM -0400, Alan Stern wrote:
Sarah, the usbmon trace shows that after doing a successful port reset
and clearing a bunch of port features, the system tells the port to go
into the SS.disabled state for no apparent reason:
88014649f3c0 1804119918 S
On Tue, 30 Jul 2013, Stoddard, Nate (GE Healthcare) wrote:
As a follow-up question, is the processing of Ssplit and Csplit
handled by the EHCI hardware? Or does the kernel software need
process the split transactions? If it matters, the our PC
configuration has
On Tue, 2013-07-30 at 13:00 -0400, Alan Stern wrote:
That's why I said the patch would fix the immediate problem but it
wasn't the best solution. You do agree that the patch is correct, as
far as it goes?
It will allow the system to sleep. But it seems to me that
a genuine error while
On Tue, 30 Jul 2013, Sarah Sharp wrote:
On Tue, Jul 30, 2013 at 12:52:40PM -0400, Alan Stern wrote:
Sarah, the usbmon trace shows that after doing a successful port reset
and clearing a bunch of port features, the system tells the port to go
into the SS.disabled state for no apparent
This patch simplifies the interface presented by usb_get_status().
Instead of forcing callers to check for the proper data length and
convert the status value to host byte order, the function will now
do these things itself.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
---
[as1694]
The hub driver is inconsistent in its organization of code for
enabling and disabling remote wakeup. There is a special routine to
disable wakeup for SuperSpeed devices but not for slower devices, and
there is no special routine to enable wakeup.
This patch refactors the code. It renames and
The hub driver's usb_port_suspend() routine doesn't handle errors
related to Link Power Management properly. It always returns failure,
it doesn't try to clean up the wakeup setting, (in the case of system
sleep) it doesn't try to go ahead with the port suspend regardless,
and it doesn't try to
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 215 +++
1 Datei geändert, 114 Zeilen hinzugefügt(+), 101 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index
I've found some new datasheets which describe some additionally supported
standard baud rates and I've verified them with my HX (rev. 3A) device.
But adding support for individual (chip type specific) baud rates would add a
good amount of extra code (especially when support for further chips will
Based on the formula in the code description, Reinhard Max and me have
investigated the devices behavior / functional principle of the divisor based
baud rate encoding method.
It turned out, that (although beeing a good starting point) the current code has
some flaws. It doesn't work correctly
Commit 0c967e7e added 50 baud to the list of supported standard baud rates.
But the reason why the driver works with this baud rate is, that since commit
8d48fdf6 a second (divisor based) baud rate encoding method is used for values
above 115200 baud, which is not limited to a fixed set of
It's not clear if the type_0 and type_1 chips support the divisor based baud
rate encoding method, so don't use it until anyone with such chip has tested it
to avoid regressions with the following patches.
Even if it has been working fine with these chips since the code has been added
2 years
Now that divisior based baud rate encoding method has been fixed and extended,
it can also be used for baud rates 115200 baud with HX chips.
This makes it possible to adjust the baud rate almost continuously instead of
just beeing able to select between 16 fixed standard values.
Signed-off-by:
In opposition to the direct baud rate encoding method, the divisor based method
is not limited to a fixed set of standard baud rates. Hence there is no need to
round to the next nearest standard value.
Reported-by: Mastro Gippo gip...@gmail.com
Signed-off-by: Frank Schäfer
Reinhard Max has done some tests with a PL2303HX (rev A) and a logic analyzer
and
it seems, that although the PL2303HX is specified for baud rates from 75 to 6M
baud, the full divisor range can be used with the divisor based baud rate
encoding method. This corresponds to baud rates from 46 to 24M
Hello.
On 07/30/2013 11:49 PM, Frank Schäfer wrote:
Commit 0c967e7e added 50 baud to the list of supported standard baud rates.
Please also specify that commit's summary line in parens.
But the reason why the driver works with this baud rate is, that since commit
8d48fdf6
The nop driver isn't a do-nothing-stub but supports a couple functions
like clock on/off or is able to use a voltage regulator. This patch
simply renames the driver to generic since it is easy possible to
extend it by a simple function istead of writing a complete driver.
Signed-off-by: Sebastian
dsps uses a nop driver which is added in dsps itself and does the PHY
on/off calls within dsps. Since those calls are now moved the nop driver
itself, we can now request the phy proper phy and remove those calls.
Currently only the first musb interface is used so we only add one phy
node for now.
Hi,
patch is mostly unchanged. I also added a phy a rename. I belive Tony is okay
with taking this on a -rc4 based branch.
#2 creates exports the common functions su am335x pieces don't polute the file.
#3 is the new phy using the reset module which is similar to what omap does.
#5 has be alted
This moves the two instances from the big node into two child nodes. The
glue layer ontop does almost nothing.
There is one devices containing the control module for USB (2) phy,
(2) usb and later the dma engine. The usb device is the glue device
which contains the musb device as a child. This is
This driver is a redo of my earlier attempt. It uses parts of the
generic PHY driver and uses the new control driver for the register
the phy needs to power on/off the phy. It also enables easy access for
the wakeup register which is not yet implemented.
The difference between the omap attempt is:
1 - 100 of 124 matches
Mail list logo
