Hi Jan,
we are using a GTM601 modem (Firmware 1.7) for a while and have spotted an
issue that under some conditions the modem sends a packed wIndex over USB
that is rejected by the hso driver making troubles afterwards. Not rejecting
makes
it work fine.
BR,
Nikolaus Schaller
---
>From f5c7e15b
On 10/01/2013 06:57 PM, Daniel Mack wrote:
> That sound's like a good idea. Everything that make the driver smaller
> and easier to understand is certainly a good thing :)
>
> So we can drop this patch favor of your cleanup. However, I appreciate
> if you did it on top of the second round of patch
On 10/02/2013 04:04 AM, Joe Perches wrote:
Convert the memset/memcpy uses of 6 to ETH_ALEN
where appropriate.
Also convert some struct definitions and u8 array
declarations of [6] to ETH_ALEN.
For brcmsmac
Acked-by: Arend van Spriel
Signed-off-by: Joe Perches
---
drivers/net/wireless/brc
Hi Thomas,
I have successfully connected the TP-Link dongle on our system based on
your suggestion below. Another question let's say i reboot the system
will this be automatically connected or I need to do the same procedure?
Thanks,
Edison
On 10/1/2013 8:15 PM, Thomas Schäfer wrote:
Hi Edi
On 30.09.2013 18:25, Felipe Balbi wrote:
On Fri, Sep 27, 2013 at 08:47:10PM +0200, Daniel Mack wrote:
>> So are you happy with this v2?
>> > It's just a cosmetic cleanup after all ...
> I can't see v2 anywhere... The only version I have is the one with
> DEV_PM_OPS still in it.
Seen them this tim
* Daniel Mack | 2013-10-01 15:31:11 [+0200]:
>In cppi41_tear_down_chan(), bail out earlier in case td_seen is unset
>instead of popping another descriptor when td_desc_seen is also unset.
>
>My system ran into WARN() condition multiple times when
>cppi41_tear_down_chan() was called for channels th
Hey Dinh,
> >Reported-by: Dinh Nguyen
> Can you please use:
> Dinh Nguyen
Sorry, I just used your sender address, should have checked your patch
instead.
Paul, if you can ack this patch, I'll resend it with the proper tag and
include your acked-by as well.
Gr.
Matthijs
signature.asc
Descrip
On 2013-10-01 16:19, Felipe Balbi wrote:
Hi,
On Tue, Oct 01, 2013 at 10:34:47AM +0200, Andreas Larsson wrote:
+/* #define VERBOSE_DEBUG */
we don't want this, we want verbose debug to be selectable on Kconfig,
which already is ;-)
I was only aware of CONFIG_USB_GADGET_DEBUG leading to DEBUG
This patch changes ep maxpacket value from 512 to 1024, because it's needed
to handle interupt and isochronous endpoints in high-speed mode. This change
doesn't affect on driver functioning, because fifo size (3072) is still enough
for the maximum transaction payload (3*1024 for high-speed high-ban
Hi Sebastian,
On 02.10.2013 10:29, Sebastian Andrzej Siewior wrote:
> * Daniel Mack | 2013-10-01 15:31:11 [+0200]:
>> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
>> index 7747bf7..6decf34 100644
>> --- a/drivers/dma/cppi41.c
>> +++ b/drivers/dma/cppi41.c
>> @@ -586,6 +586,9 @@ static
BugLink: http://bugs.launchpad.net/bugs/1180881
Synaptics large touchscreen doesn't support some of the report request
while initializing. The unspoorted request will make the device unreachable,
and will lead to the following usb_submit_urb() function call timeout.
So, add the IDs into HID_QUIRK_
BugLink: http://bugs.launchpad.net/bugs/1180881
This device needs to be added to the quirks list with HID_QUIRK_NO_INIT_REPORTS,
otherwise it causes 10 seconds timeout during report initialization.
[12431.828467] hid-multitouch 0003:0457:1013.0475: usb_submit_urb(ctrl) failed:
-1
[12431.828507]
This patch fix validation of maxpacket value given in endpoint descriptor.
Add check of maxpacket for bulk endpoints. If maxpacket is not set in
descriptor, it's set to maximum value for given type on endpoint in used
speed.
Correct maxpacket value is:
FULL-SPEEDHIGH-SPEED
From: Manjunath Goudar
Suspend scenario in case of ohci-at91 glue was not properly handled
as it was not suspending generic part of ohci controller. Alan Stern
suggested, properly handle ohci-at91 suspend scenario.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will
From: Manjunath Goudar
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. Alan Stern
suggested, properly handle OHCI suspend scenario.
This does generic proper handling of suspend
scenario to all OHCI SOC.
Signed-off-by: Manjunath Goudar
Signed-off-by: Manjunat
From: Manjunath Goudar
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-s3c2410 suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspe
From: Manjunath Goudar
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-da8xx suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensu
From: Manjunath Goudar
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-omap suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_omap_suspend() will ensure
From: Manjunath Goudar
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-ep93xx suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_hcd_ep93xx_drv_suspend(
From: Manjunath Goudar
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-exynos suspend scenario.
Calling explicitly the ohci_suspend() routine in
exynos_ohci_suspend() will e
From: Manjunath Goudar
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller.Alan Stern suggested, properly handle
ohci-platform suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_platform_suspend() w
From: Manjunath Goudar
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-spear suspend scenario.
Calling explicitly the ohci_suspend() routine in
spear_ohci_hcd_drv_suspend()
From: Manjunath Goudar
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly
handle ohci-sm501 suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_sm501_suspend() will ens
From: Manjunath Goudar
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly
handle ohci-pxa27x suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_hcd_pxa27x_drv_suspend
Hi Tony,
On 09/24/2013 11:53 AM, Roger Quadros wrote:
> The platform data bits can be inferred from the other members of
> struct usbhs_phy_data. So get rid of the platform_data member.
>
> Build the platform data for the PHY device in usbhs_init_phys() instead.
>
> Signed-off-by: Roger Quadros
* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
>Patch #3, however, gives me headaches. I can't fully explain what's
>going on, but I can tell for sure that if fixes a problem that I stared
>on for many hours.
>
>The problem is that on resume, the musb core will detect that some of
>the suspended USB
Hi Tony,
On 09/24/2013 11:53 AM, Roger Quadros wrote:
> The USB phy-nop nop driver expects the RESET line information
> to be sent as a GPIO number via platform data. Adapt to that.
>
> Signed-off-by: Roger Quadros
Need your Ack on this one as well.
cheers,
-roger
> ---
> arch/arm/mach-omap2
On 10/02/2013 11:19 AM, Daniel Mack wrote:
> Hi Sebastian,
Hi Daniel,
> On 02.10.2013 10:29, Sebastian Andrzej Siewior wrote:
>> * Daniel Mack | 2013-10-01 15:31:11 [+0200]:
>
> Thanks a lot for having a look! As I'm going to be off for a couple of
> days now, and only be able to read my mails s
On 10/01/2013 04:45 PM, Felipe Balbi wrote:
Hello,
Hi,
On Tue, Sep 24, 2013 at 11:47:16AM +0200, Robert Baldyga wrote:
Hello,
This is update for my proposal for isochronous transfers support in s3c-hsotg
driver. I've fixed issuses pointed by Bartlomiej Zolnierkiewicz. For more
information, ple
* Daniel Mack | 2013-10-01 15:39:53 [+0200]:
>musb_port_reset() sleeps, so we can't call it from atomic context. It
>is, however, called from places inside musb_hub_control() while
>&musb->lock is held, which leads to a "scheduling while atomic" warning.
I guess you are hit by the msleep(1) here.
* Daniel Mack | 2013-10-01 15:39:54 [+0200]:
>Make musb_port_suspend() externally available, and call it when to host
>goes into suspend. This allows the core to go into suspend while a
>device is connected.
Sorry for asking this stupid question but what is usally happening when
the host goes to
On 02.10.2013 12:20, Sebastian Andrzej Siewior wrote:
> * Daniel Mack | 2013-10-01 15:31:08 [+0200]:
>
>> Patch #3, however, gives me headaches. I can't fully explain what's
>> going on, but I can tell for sure that if fixes a problem that I stared
>> on for many hours.
>>
>> The problem is that o
On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote:
> * Daniel Mack | 2013-10-01 15:39:54 [+0200]:
>
>> Make musb_port_suspend() externally available, and call it when to host
>> goes into suspend. This allows the core to go into suspend while a
>> device is connected.
>
> Sorry for asking this
On 02.10.2013 12:46, Sebastian Andrzej Siewior wrote:
> * Daniel Mack | 2013-10-01 15:39:53 [+0200]:
>
>> musb_port_reset() sleeps, so we can't call it from atomic context. It
>> is, however, called from places inside musb_hub_control() while
>> &musb->lock is held, which leads to a "scheduling wh
Hi,
On Wednesday, October 02, 2013 03:45:42 PM Majunath Goudar wrote:
> From: Manjunath Goudar
>
> Suspend scenario in case of ohci-exynos glue was not
> properly handled as it was not suspending generic part
> of ohci controller. Alan Stern suggested, properly handle
> ohci-exynos suspend scen
On 02.10.2013 12:25, Sebastian Andrzej Siewior wrote:
> On 10/02/2013 11:19 AM, Daniel Mack wrote:
>> Once the system is booted up and the USB media is detected, I send the
>> system to sleep mode with "cat mem >/sys/power/state". After wakeup, I
>> access the media by mounting and unmounting it o
On 10/02/2013 01:14 PM, Daniel Mack wrote:
> On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote:
>> * Daniel Mack | 2013-10-01 15:39:54 [+0200]:
>>
>>> Make musb_port_suspend() externally available, and call it when to host
>>> goes into suspend. This allows the core to go into suspend while a
>>
On 02.10.2013 14:01, Sebastian Andrzej Siewior wrote:
> On 10/02/2013 01:14 PM, Daniel Mack wrote:
>> On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote:
>>> What happens if the device is unplugged while the host is suspended and
>>> not there on resume?
>>
>> That condition is detected and a fu
Hi Sarah,
Em Tue, 1 Oct 2013 13:45:54 -0700
Sarah Sharp escreveu:
> On Tue, Oct 01, 2013 at 10:01:08PM +0300, Xenia Ragiadakou wrote:
> > Hi Sarah,
> >
> > I read the mail on 'possible conflict between xhci_hcd and a patched
> > usbhid'.
>
> For reference to others:
> http://marc.info/?l=linux
On 10/02/2013 01:07 PM, Daniel Mack wrote:
> No, as stated, the line numbers in the kernel message are somewhat off
> due to added debugging code. What kicks in here is this one:
>
> if (!c->td_desc_seen) {
> desc_phys = cppi41_pop_desc(cdd, c->q_comp_num);
>
On 10/01/2013 04:33 PM, Felipe Balbi wrote:
> Hi,
Hi,
> On Tue, Aug 13, 2013 at 07:49:43PM +0200, Sebastian Andrzej Siewior
> wrote:
>> This patch defines four types of current supported DMA engines
>> and assignes them to each dma engine. This should get rid of a
>> few ifdefs later on.
>>
>> S
On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote:
> Hi Felipe,
>
> On 09/18/2013 03:49 PM, Roger Quadros wrote:
> > "usb_otg_ss_refclk960m" is an optional functional clock to the
> > UBS_OTG_SS module. So manage it in the driver.
> >
>
> Just realized that "usb_otg_ss_refclk960m" is
On 01.10.2013 21:32, Thomas Pugliese wrote:
> This patch updates snd_usb_audio_create also support devices whose
> speed == USB_SPEED_WIRELESS.
Interesting. What device are you testing this with?
Daniel
>
> Signed-off-by: Thomas Pugliese
> ---
> sound/usb/card.c |1 +
> 1 file changed,
On 10/02/2013 04:11 PM, Felipe Balbi wrote:
> On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote:
>> Hi Felipe,
>>
>> On 09/18/2013 03:49 PM, Roger Quadros wrote:
>>> "usb_otg_ss_refclk960m" is an optional functional clock to the
>>> UBS_OTG_SS module. So manage it in the driver.
>>>
>>
W dniu 01.10.2013 16:53, Felipe Balbi pisze:
On Thu, Sep 26, 2013 at 02:38:21PM +0200, Andrzej Pietrasiewicz wrote:
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
On Tue, 1 Oct 2013, Sarah Sharp wrote:
> > When you say a new API, what do you mean? New functions in usbcore
> > to be used by usb device drivers?
>
> Yes. You would export the function in the USB core, and put a prototype
> in a USB include file (probably in include/linux/usb.h). Let's say th
On Tue, 1 Oct 2013, [ISO-8859-1] Jorge Mu�oz Camadro wrote:
> When connecting a eternal usb dd Western Digital My Passport usb 3.0
> dmesg shows the device is outlined, not ready after error recovery.
>
> Linux distro: Arch x64
> Kernel: 3.11.2-1
> Linux firmware: 20130903-1
> Kmod: 15-1
> System
On Wed, 2 Oct 2013, yoma sophian wrote:
> hi alan:
>
> 2013/10/2 Alan Stern :
> > On Wed, 2 Oct 2013, yoma sophian wrote:
> >
> >> 1. in susped, we will gate our ehci clk
> >> in resumt, we need to release clk gating to let ehci control work.
> >> and above are platform specific behavior need to
On Wed, 2 Oct 2013, Daniel Mack wrote:
> On 01.10.2013 21:32, Thomas Pugliese wrote:
> > This patch updates snd_usb_audio_create also support devices whose
> > speed == USB_SPEED_WIRELESS.
>
> Interesting. What device are you testing this with?
>
>
> Daniel
>
The device I am testing with i
On Wed, 2 Oct 2013, Daniel Mack wrote:
> On 02.10.2013 14:01, Sebastian Andrzej Siewior wrote:
> > On 10/02/2013 01:14 PM, Daniel Mack wrote:
> >> On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote:
>
> >>> What happens if the device is unplugged while the host is suspended and
> >>> not there
On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz wrote:
> Maybe it would make sense to cleanup ohci_suspend() first (before adding
> new ohci_suspend() users) and remove unused do_wakeup parameter?
Not possible. The do_wakeup parameter is part of a function prototype
shared by other callback routin
On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
> Let me see if I understand the changes at the media drivers. So, please
> correct me if I got it wrong.
>
> I'm yet to get any USB 3.0 media device, although it is common to connect
> an USB 1.1 or USB 2.0 device on a USB 3.0 host port.
>
> So,
Hi,
On Wednesday, October 02, 2013 10:38:58 AM Alan Stern wrote:
> On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz wrote:
>
> > Maybe it would make sense to cleanup ohci_suspend() first (before adding
> > new ohci_suspend() users) and remove unused do_wakeup parameter?
>
> Not possible. The do_w
On Wed, 2 Oct 2013, Robert Baldyga wrote:
> This patch fix validation of maxpacket value given in endpoint descriptor.
> Add check of maxpacket for bulk endpoints. If maxpacket is not set in
> descriptor, it's set to maximum value for given type on endpoint in used
> speed.
>
> Correct maxpacket
On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, October 02, 2013 10:38:58 AM Alan Stern wrote:
> > On Wed, 2 Oct 2013, Bartlomiej Zolnierkiewicz wrote:
> >
> > > Maybe it would make sense to cleanup ohci_suspend() first (before adding
> > > new ohci_suspend() user
On Mon, Sep 23, 2013 at 04:29:40PM -0700, Dan Williams wrote:
> Change the enumeration scheme for xhci attached devices from:
>
>SetAddress
>GetDescriptor(8)
>GetDescriptor(18)
>
> ...to:
>
>GetDescriptor(64)
>SetAddress
>GetDescriptor(18)
Thinking about this sequence ag
Em Wed, 02 Oct 2013 11:00:13 -0400 (EDT)
Alan Stern escreveu:
> On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
>
> > Let me see if I understand the changes at the media drivers. So, please
> > correct me if I got it wrong.
> >
> > I'm yet to get any USB 3.0 media device, although it is common
On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
> > > So, there's no need to call usb_change_ep_bandwidth().
> >
> > That's right.
> >
> > > If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
> > > or wMaxPacketSize were improperly filled.
> > >
> > > Right?
> >
> > Or if the valu
Hi Felipe,
On 30 September 2013 09:44, Sachin Kamat wrote:
> The data structure of_match_ptr() protects is always compiled in.
> Hence of_match_ptr() is not needed.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/usb/musb/musb_am335x.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, Oct 2, 2013 at 9:14 AM, Sarah Sharp
wrote:
> On Mon, Sep 23, 2013 at 04:29:40PM -0700, Dan Williams wrote:
>> Change the enumeration scheme for xhci attached devices from:
>>
>>SetAddress
>>GetDescriptor(8)
>>GetDescriptor(18)
>>
>> ...to:
>>
>>GetDescriptor(64)
>>SetAd
On Wed, 2 Oct 2013, Sarah Sharp wrote:
> On Mon, Sep 23, 2013 at 04:29:40PM -0700, Dan Williams wrote:
> > Change the enumeration scheme for xhci attached devices from:
> >
> >SetAddress
> >GetDescriptor(8)
> >GetDescriptor(18)
> >
> > ...to:
> >
> >GetDescriptor(64)
> >SetA
Em Wed, 02 Oct 2013 12:38:14 -0400 (EDT)
Alan Stern escreveu:
> On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
>
> > > > So, there's no need to call usb_change_ep_bandwidth().
> > >
> > > That's right.
> > >
> > > > If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
> > > > or wM
On Wed, Oct 02, 2013 at 12:16:04AM +0300, Xenia Ragiadakou wrote:
> On 10/01/2013 11:45 PM, Sarah Sharp wrote:
> >Sure. I would actually suggest you first finish up the patch to issue a
> >configure endpoint if userspace wants to clear a halt, but the endpoint
> >isn't actually halted. Did your m
On Wed, Oct 02, 2013 at 10:22:52AM -0400, Alan Stern wrote:
> On Tue, 1 Oct 2013, Sarah Sharp wrote:
>
> > > When you say a new API, what do you mean? New functions in usbcore
> > > to be used by usb device drivers?
> >
> > Yes. You would export the function in the USB core, and put a prototype
Hi Hans,
2013-09-28 Hans de Goede :
> Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These
> devices default to hid mode for BIOS use. This means that after having been
> reset they will revert to HID mode, and are no longer usable as a HCI.
>
> Therefor it is a very bad i
On Wed, 2 Oct 2013, Sarah Sharp wrote:
> > In particular, do we want to go around changing single endpoints, one
> > at a time? Or do we want to change all the endpoints in an interface
> > at once?
> >
> > Given that a change to one endpoint may require the entire schedule to
> > be recomput
On Wed, 2 Oct 2013, Alan Stern wrote:
> > Ok, so it sounds like we want to keep the changes the endpoints across
> > alt setting changes.
>
> No, just the opposite. That was the point I was trying to make. Any
> changes to ep5 in altsetting 0 (for example) will have no effect on ep1
---
On Wed, Oct 2, 2013 at 9:14 AM, Sarah Sharp
wrote:
> On Mon, Sep 23, 2013 at 04:29:40PM -0700, Dan Williams wrote:
>> Change the enumeration scheme for xhci attached devices from:
>>
>>SetAddress
>>GetDescriptor(8)
>>GetDescriptor(18)
>>
>> ...to:
>>
>>GetDescriptor(64)
>>SetAd
From: Joe Perches
Date: Tue, 01 Oct 2013 19:04:40 -0700
> Convert the memset/memcpy uses of 6 to ETH_ALEN
> where appropriate.
>
> Also convert some struct definitions and u8 array
> declarations of [6] to ETH_ALEN.
>
> Signed-off-by: Joe Perches
Looks fine, applied, thanks Joe.
--
To unsubsc
I am sending you this email on behalf of Mrs. Margaret Crawford in regards to
her wish. She have decided to will her inheritance to you for Humanitarian work
and your personal use. For more info contact her Attorney, Mark Lawson on
email: mark.laws...@rogers.com
This electronic transmission m
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Tuesday, October 01, 2013 2:43 PM
>
> The hardware offers a 4-bit register containing the number of host
> channels. However, the values of these register mean 1-16 host channels,
> not 0-15. Since the dwc2_hw_params struct stores the ac
Usbmon shows this when plugin the usb external drive:
880202ba1d80 1366339094 S Co:3:003:0 s 20 00 0005 5 = 0c200200 00
880202ba1d80 1366339454 C Co:3:003:0 0 5 >
880209b433c0 1366347550 C Ii:3:003:1 0:1 6 = 0e04010c 2000
880209b433c0 1366347561 S Ii:3:003:1 -115:1 64 <
f
Hi Gustavo,
>> Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These
>> devices default to hid mode for BIOS use. This means that after having been
>> reset they will revert to HID mode, and are no longer usable as a HCI.
>>
>> Therefor it is a very bad idea to just blindly
struct otg_fsm may be embedded to device's context structure.
The callbacks may require pointer to struct otg_fsm to obtain
necessary data for its operation (example: regulator reference
for drv_vbus()).
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsl-usb.c | 30 +++
In accordance with OTG and EH supplement, the correct name
of the FSM input is b_ssend_srp.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsl-usb.c |4 ++--
drivers/usb/phy/phy-fsm-usb.c |2 +-
drivers/usb/phy/phy-fsm-usb.h |2 +-
3 files changed, 4 insertions(+), 4 deletio
Reorder variables in struct otg_fsm as they appear in OTG and EH
supplement to USB2.0.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsm-usb.h | 46 +
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/phy/phy-fsm-usb.h
Get rid of using OTG driver specific timers by passing timer
type to corresponding callbacks.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsl-usb.c | 60 +++--
drivers/usb/phy/phy-fsm-usb.c | 28 +--
drivers/usb/phy/phy-fsm-usb.
a_bidl_adis_tmr and a_wait_vfall_tmr OTG timers missed in
current FSM implementation. This patch adds and makes use
of the timers as speicfied in OTG and EH supplement to USB2.0.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsm-usb.c | 12 +---
drivers/usb/phy/phy-fsm-usb.h
Existence of callback must be checked to avoid NULL pointer
dereferncing.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsm-usb.h | 35 ---
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/phy/phy-fsm-usb.h b/drivers/usb/phy/p
Several input/output variables missed in current FSM implementation.
This patch adds and makes use of them as specified in OTG and EH
supplement to USB2.0.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsm-usb.c | 18 +++---
drivers/usb/phy/phy-fsm-usb.h | 36 ++
This patch implements missed helper functions for start_gadget() and
start_host() OTG FSM callbacks.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsm-usb.c |8
drivers/usb/phy/phy-fsm-usb.h | 14 ++
2 files changed, 18 insertions(+), 4 deletions(-)
diff --g
Mark informative variables with suffix '_inf' to distinguish
them from other non-informative variables with the same name.
If such non-informative varialbes were missed, they are created.
Signed-off-by: Anton Tikhomirov
---
drivers/usb/phy/phy-fsl-usb.c |2 +-
drivers/usb/phy/phy-fsm-usb.c |
Hello,
This patch set implements several fixes to USB2.0 OTG Final
State Machine. All changes affect the only user of OTG FSM,
Freescale USB OTG Transceiver Driver, as little as possible
and (hope) keep it functional. Further changes to OTG FSM
will require reworking of the driver.
Anton Tikhomir
* Roger Quadros [131002 03:27]:
> Hi Tony,
>
> On 09/24/2013 11:53 AM, Roger Quadros wrote:
> > The platform data bits can be inferred from the other members of
> > struct usbhs_phy_data. So get rid of the platform_data member.
> >
> > Build the platform data for the PHY device in usbhs_init_phy
* Roger Quadros [131002 03:28]:
> Hi Tony,
>
> On 09/24/2013 11:53 AM, Roger Quadros wrote:
> > The USB phy-nop nop driver expects the RESET line information
> > to be sent as a GPIO number via platform data. Adapt to that.
> >
> > Signed-off-by: Roger Quadros
>
> Need your Ack on this one as
Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
introduced a new AMD chipset type to filter AMD platforms with different
chipsets.
According to a recent thread [1], this patch updates USB subsystem hang
symptom quirk which is observed on AMD all SB600 and SB700 revision
Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types"
introduced a new AMD chipset type to filter AMD platforms with different
chipsets.
According to a recent thread [1], this patch updates SB800 prefetch routine
in AMD PLL quirk. And make it use the new chipset type to repres
On Tue, Oct 01, 2013 at 02:32:58PM -0700, David Cohen wrote:
> Signed-off-by: David Cohen
> ---
> drivers/usb/chipidea/ci_hdrc_pci.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c
> b/drivers/usb/chipidea/ci_hdrc_pci.c
> index 08a724b..d514332 1
88 matches
Mail list logo
