* Felipe Balbi [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 "generic
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 Sat
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.
> http://www.mail-archive.com/l
On Mon, Jul 29, 2013 at 7:04 PM, Alan Stern wrote:
> It turns out I was probably wrong. Take a look at this message:
>
> http://marc.info/?l=linux-scsi&m=137511040432420&w=2
>
> The patch in that email may fix your problem.
It does. Thanks!
I am unfortunately still seeing the suspend/res
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,
> th
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 0x64
* Sebastian Andrzej Siewior [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
> > series? You can t
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/host/ehci-fsl.c | 14 +++---
drivers/usb/host/ehci-mv.c |2 +-
drivers/usb/host/ehci-mxc.c |4 ++--
drivers/usb/
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/gadget/at91_udc.c |4 ++--
drivers/usb/gadget/atmel_usba_udc.c |2 +-
drivers/usb/gadget/bcm63xx_udc.c|2 +-
drivers/usb/gad
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/phy/phy-fsl-usb.c |6 +++---
drivers/usb/phy/phy-gpio-vbus-usb.c | 10 +-
drivers/usb/phy/phy-msm-usb.c |4 ++--
dri
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/musb/am35x.c | 14 +++---
drivers/usb/musb/blackfin.c |2 +-
drivers/usb/musb/da8xx.c |2 +-
drivers/usb/musb/davinci.c
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/chipidea/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/misc/usb3503.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
inde
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/renesas_usbhs/common.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/us
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 oh
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
>> maintain a separate list for binding like how we had in USB PHY
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
> >>
[ Repost without gmail HTML... Sorry about the noise. ]
On Mon, Jul 29, 2013 at 6:33 PM, Frank Schäfer
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 rounded up to 1228800 ba
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/c67x00/c67x00-drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/c67x00/c67x00-drv.c b/drivers/usb/c67x0
Allocate the transfer buffer in probe(), and use the buffer for
usb control transfer.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r815x.c | 117 +---
1 file changed, 90 insertions(+), 27 deletions(-)
diff --git a/drivers/net/usb/r815x.c b/drivers/ne
- fix the conversion between cpu and __le32
- replace some pla_ocp and usb_ocp functions with generic_ocp function
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 66 +
1 file changed, 23 insertions(+), 43 deletions(-)
diff --git a/drive
Allocate the required transfer buffer for usb_control_msg.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 91 +++--
1 file changed, 66 insertions(+), 25 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ee13f9e
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-
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
+ arch/powerpc/kvm/bo
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 devi
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
> > > > +++ b/driver
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.
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 lin
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: Jingoo Han
---
drivers/usb/host/ehci-fsl.c | 14 +++---
drivers/usb/host/ehci-mv.c |2 +-
drivers/usb/host/ehci-mxc.c |4 ++--
drivers/usb/
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 aroun
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: chipide
From: Peter Chen
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 switches.
When the host roles
From: Michael Grzeschik
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
---
drivers/usb/chipidea/ci_hdrc_imx.c | 26 ++-
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 cre
On Tue, Jul 30, 2013 at 02:41:23PM +0200, Michael Grzeschik wrote:
> From: Michael Grzeschik
>
> 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.
quite a few t
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
> ---
> drivers/net/usb/r815x.c | 117
> +---
> 1 file changed, 90 inse
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
> ---
> drivers/net/usb/r8152.c | 91
> +++--
> 1 file changed, 66 insertions(+), 25 deletions(-)
>
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
> ---
> drivers/net/usb/r815x.c | 117
> +---
> 1 file changed, 90 inse
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 mention
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 gener
On Tue, Jul 30, 2013 at 4:28 PM, Hayes Wang 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
you can avoid to ac
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
-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 t
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
---
This might help...
diff --git a/MAINTAINERS b/MAINTAINERS
index 339e798..9b53
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 t
On Tue, 30 Jul 2013, Philipp Dreimann wrote:
> On Mon, Jul 29, 2013 at 7:04 PM, Alan Stern wrote:
> > It turns out I was probably wrong. Take a look at this message:
> >
> > http://marc.info/?l=linux-scsi&m=137511040432420&w=2
> >
> > The patch in that email may fix your problem.
> It do
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.
> >
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 b
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 i
From: Greg KH
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 register access.
Using kmallo
On Tue, 2013-07-30 at 11:33 -0700, David Miller wrote:
> From: Greg KH
> 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,
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 assig
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 f
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 f
From: Joe Perches
Date: Tue, 30 Jul 2013 11:41:17 -0700
> On Tue, 2013-07-30 at 11:33 -0700, David Miller wrote:
>> From: Greg KH
>> 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 stru
> -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 Hu
On Tue, Jul 30, 2013 at 11:33:29AM -0700, David Miller wrote:
> From: Greg KH
> 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 th
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. Therefor
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/
tags/usb-3.11-r
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 Co:4:
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 CONFIG_USB_EHCI_ROOT_HUB_T
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 flus
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
---
[as1694]
drivers/usb/core/hub.c
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 cha
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 ap
Signed-off-by: Frank Schäfer
---
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 dd48317..174c685 100644
--- a/drivers/
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 b
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 for
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 stan
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 ago,
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: F
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
Signed-off-by: Frank Schäfer
Signed-off-by: Reinhard Max
---
drive
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
Likewi
This patch series against usb-next improves the baud rate support of the pl2303
driver.
Currently only a fixed set of 25 standard baud rates from 75 to 6M baud is
supported. With this patch series applied, almost continuous baud rate
adjustment is possible between 46 and 6.6M baud.
Luca Olivetti
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: Sebast
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 fo
This patch exports the mostly generic functions so they can be used from
other phy driver instead of duplicating the code.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/phy/phy-generic.c | 130 --
drivers/usb/phy/phy-generic.h | 20 +++
2 f
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:
On Tue, Jul 30, 2013 at 03:39:02PM -0400, Alan Stern wrote:
> 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
Thanks for the patch James! I'll send it off to Greg in a couple days.
Sarah Sharp
On Fri, Jul 26, 2013 at 01:34:43PM +0100, James Hogan wrote:
> A randconfig build hit the following build errors because xhci.c and
> xhci-mem.c use dma mapping functions but don't include
> . Add the missing incl
On Tue, 2013-07-30 at 14:41 -0400, Alan Stern wrote:
> 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
>
> The driver has to set up the data structures for the transfers, which includes
> scheduling when the SSPLIT and CSPLIT transactions will occur and figuring
> out how much bandwidth they will consume. The transactions themselves
> are handled entirely by the EHCI hardware.
>
So you would ex
This patch defines a new trace event, which is called xhci_dbg_context_change
and belongs in the event class xhci_log_msg, and adds tracepoints for tracing
the debug messages related to context updates performed with Configure Endpoint
and Evaluate Context commands.
Signed-off-by: Xenia Ragiadakou
This patch defines a new trace event, which is called xhci_dbg_reset_ep
and belongs in the event class xhci_log_msg, and adds tracepoints that
trace the debug messages associated with resetting an endpoint after
the reception of a STALL packet.
Signed-off-by: Xenia Ragiadakou
---
drivers/usb/hos
This patch creates a new event class, called xhci_log_cmd,
for tracing the commands issued to xHC that generate a
completion event in the event ring by placing into the
ring buffer the completion event's status and flags as
well as the command TRB's data, dma and virtual address.
This info can be
This patch defines a new event class, called xhci_log_ctx,
that records in the ring buffer the context data, the
context type (input or output), the context dma and virtual
addresses, the context endpoint entries, the slot ID and
whether the xHC uses 64 byte context data structures.
This informati
This patch defines a new trace event, which is called xhci_dbg_quirks
and belongs in the event class xhci_log_msg, and adds tracepoints that
trace the debug messages associated with xHCs' quirks.
Signed-off-by: Xenia Ragiadakou
---
drivers/usb/host/xhci-hub.c | 7 --
drivers/usb/host/xhci
From: Fabio Estevam
By using devm_request_irq() we don't need to call free_irq(), which simplifies
the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/core.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/ch
From: Fabio Estevam
After the rename to ci_hdrc we ended up with two MODULE_ALIAS entries, so
remove the old one.
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a5d
On Wed, 2013-07-31 at 03:56 +0300, Xenia Ragiadakou wrote:
> #define PORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
> #define PORT_RWC_BITS (PORT_CSC | PORT_PEC | PORT_WRC | PORT_OCC | \
> @@ -528,8 +529,10 @@ void xhci_del_comp_mod_timer(struct xhci_hcd *xhci, u32
>
1 - 100 of 124 matches
Mail list logo
