Hi Amit,
On Tue, May 06, 2014 at 02:22:12PM +0800, Amit VIRDI wrote:
> On 5/6/2014 12:56 AM, Felipe Balbi wrote:
> >> I understand that enabling XferInProgress event for bulk/interrupt
> >> >transfers will completely
> >> >change the design of the dwc3 driver and hence is not the viable solution
>
To whom it may concern:
I am having trouble with the Silicon Labs CP2105 (usb serial driver
cp210x) enumerating both USB interfaces.
When the CP2105-EK evaluation board is connected to the PC, Linux only
creates a `/dev/ttyUSB0` device, but no `/dev/ttyUSB1` device is
created. Upon unplugging the
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, May 08, 2014 2:18 PM
>
> On Thu, 8 May 2014, Paul Zimmerman wrote:
>
> > > When the host already timed out the control transfer and started a new
> > > one. Here's what I'm talking about:
> > >
> > > Host sends a Set-Confi
On Thu, 8 May 2014, Russel Hughes wrote:
> Hi,
>
>Some more information from someone who has the same DAC as me and
> has got it working on USB3.0 under Linux. I dont know if this helps
> with a workround or just points to some fundamental problem with the
> Intel hardware.
>
> "I was right
On Thu, 8 May 2014, Paul Zimmerman wrote:
> > When the host already timed out the control transfer and started a new
> > one. Here's what I'm talking about:
> >
> > Host sends a Set-Configuration request.
> >
> > The UDC driver calls the gadget driver's setup function.
> >
> > The
On Thu, May 08, 2014 at 03:06:48PM -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Paul Zimmerman wrote:
>
> > Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> > It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> > properly according to the databook. I
> Does your computer have any USB-2 ports? Or is it possible to disable
> the USB-3 controllers in the BIOS? It would be worthwhile to see if
> the audio works when the device is attached to a non-USB-3 controller.
>
Hi,
Some more information from someone who has the same DAC as me and
has g
On Thu, May 08, 2014 at 06:56:02PM +, Paul Zimmerman wrote:
> > From: linux-usb-ow...@vger.kernel.org
> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Paul Zimmerman
> > Sent: Thursday, May 08, 2014 11:42 AM
> >
> > > From: linux-usb-ow...@vger.kernel.org
> > > [mailto:linux-usb-ow.
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Thursday, May 08, 2014 12:07 PM
>
> On Thu, 8 May 2014, Paul Zimmerman wrote:
>
> > Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> > It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> >
On Thu, May 08, 2014 at 06:42:53PM +, suresh.gu...@freescale.com wrote:
> > > And Host might be attach after system bootup or after driver
> > > initialization. So putting this check in probe will not help much.
> >
> > If the host is attached after the driver was initialised, the interrupt
>
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern
> Sent: Wednesday, May 07, 2014 9:59 AM
>
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
>
> > > A similar problem can occur in the opposite sense: The thread queuing
> > > the delayed status
On Thursday, May 08, 2014 08:56:24 AM Dan Williams wrote:
> On Thu, May 8, 2014 at 4:09 AM, Rafael J. Wysocki wrote:
> > On Wednesday, May 07, 2014 10:37:24 PM Dan Williams wrote:
> >> Unconditionally wake up the child device when the power session is
> >> recovered.
> >
> > [cut]
> >
> >> +
On Thu, 8 May 2014, Dan Williams wrote:
> On Thu, May 8, 2014 at 11:09 AM, Alan Stern wrote:
> > On Thu, 8 May 2014, Dan Williams wrote:
> >
> >> On Thu, May 8, 2014 at 9:09 AM, Alan Stern
> >> wrote:
> >> > On Thu, 8 May 2014, Dan Williams wrote:
> >> >
> >> >> > I don't understand this last p
On Thu, 8 May 2014, Paul Zimmerman wrote:
> > Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> > It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> > properly according to the databook. If the buffer fills up, then
> > further SETUP packets will get l
On Thu, 8 May 2014, Paul Zimmerman wrote:
> Just FYI, the DWC3 core is designed to always respond to SETUP packets.
> It has a 3-deep input buffer for SETUPs, provided the RxFIFO is set up
> properly according to the databook. If the buffer fills up, then
> further SETUP packets will get lost, but
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Paul Zimmerman
> Sent: Thursday, May 08, 2014 11:42 AM
>
> > From: linux-usb-ow...@vger.kernel.org
> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern
> > Sent: Thursday, May 08, 2014
> -Original Message-
> From: Paul Fertser [mailto:fercer...@gmail.com]
> Sent: Thursday, May 08, 2014 9:09 PM
> To: Gupta Suresh-B42813
> Cc: ba...@ti.com; Li Yang-Leo-R58472; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] usb: gadget: fsl: check vbus pr
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alan Stern
> Sent: Thursday, May 08, 2014 10:40 AM
>
> On Thu, 8 May 2014, Felipe Balbi wrote:
>
> > > The dwc3 driver should always prepare a buffer for the next ep0 SETUP
> > > packet as soon as it
On Thu, May 8, 2014 at 11:09 AM, Alan Stern wrote:
> On Thu, 8 May 2014, Dan Williams wrote:
>
>> On Thu, May 8, 2014 at 9:09 AM, Alan Stern wrote:
>> > On Thu, 8 May 2014, Dan Williams wrote:
>> >
>> >> > I don't understand this last part. Why do we need to guarantee the
>> >> > child device ha
On Thu, 8 May 2014, Dan Williams wrote:
> > Also, instead of adding another #ifdef here, you could add a #else
> > section to the existing #ifdef in which you define an inline version of
> > hub_handle_remote_wakeup() (or a macro version) that always returns 0.
>
> I originally started down that
On Thu, 8 May 2014, Dan Williams wrote:
> On Thu, May 8, 2014 at 9:09 AM, Alan Stern wrote:
> > On Thu, 8 May 2014, Dan Williams wrote:
> >
> >> > I don't understand this last part. Why do we need to guarantee the
> >> > child device has recovered from power loss? Why not proceed the same
> >>
On Thu, May 8, 2014 at 9:01 AM, Alan Stern wrote:
> On Wed, 7 May 2014, Dan Williams wrote:
>
>> Per Alan:
>> "You mean from within hub_handle_remote_wakeup()? That routine will
>> never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd
>> never sees wakeup requests if they arise durin
On Thu, 8 May 2014, Felipe Balbi wrote:
> > The dwc3 driver should always prepare a buffer for the next ep0 SETUP
> > packet as soon as it retrieves the information for the current SETUP
> > packet from the buffer.
> >
> > Otherwise, as you described it, if the gadget driver never sends its
> >
At probe time, the musb_am335x driver registers its childs by
calling of_platform_populate(), which registers all childs in
the devicetree hierarchy recursively.
On the other side, the driver's remove() function uses of_device_unregister()
to remove each child in the musb_am335x driver device stru
On Thu, May 08, 2014 at 11:22:36AM -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
>
> > > dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not
> > > allow it. A device must always respond to SETUP with ACK.
> > It true that device can not return NYET to a
On Thu, May 8, 2014 at 9:47 AM, Joe Perches wrote:
> On Thu, 2014-05-08 at 19:25 +0300, Mathias Nyman wrote:
>> Save someone else the debug cycles of figuring out why a driver's
>> transfer request is failing or causing undefined system behavior.
>> Buffers submitted for dma must come from GFP all
On Thu, 2014-05-08 at 19:25 +0300, Mathias Nyman wrote:
> Save someone else the debug cycles of figuring out why a driver's
> transfer request is failing or causing undefined system behavior.
> Buffers submitted for dma must come from GFP allocated / DMA-able
> memory.
>
> Return -EAGAIN matching
On Thu, May 8, 2014 at 9:22 AM, David Laight wrote:
> From: Mathias Nyman
>> From: Dan Williams
>>
>> Save someone else the debug cycles of figuring out why a driver's
>> transfer request is failing or causing undefined system behavior.
>> Buffers submitted for dma must come from GFP allocated /
From: Mathias Nyman
> From: Dan Williams
>
> Save someone else the debug cycles of figuring out why a driver's
> transfer request is failing or causing undefined system behavior.
> Buffers submitted for dma must come from GFP allocated / DMA-able
> memory.
>
> Return -EAGAIN matching the return
On Thu, May 8, 2014 at 9:25 AM, Mathias Nyman
wrote:
> From: Dan Williams
>
> Save someone else the debug cycles of figuring out why a driver's
> transfer request is failing or causing undefined system behavior.
> Buffers submitted for dma must come from GFP allocated / DMA-able
> memory.
>
> Ret
From: Alexander Gordeev
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix
From: Sarah Sharp
xHCI host controllers may only support a limited number of device slot
IDs, which is usually far less than the theoretical maximum number of
devices (255) that the USB specifications advertise. This is
frustrating to consumers that expect to be able to plug in a large
number of
Hi Greg
These following xhci patches are for usb-next and hopefully for 3.16
This patcheseries includes a bigger change in xhci command queue code,
(last four patches), a task that I've been working on for a longer time.
Sarah gave green light for v5 before she went on her sabbatical.
http://mar
From: Dan Williams
Add a command line switch for disabling ehci port switchover. Useful
for working around / debugging xhci incompatibilities where ehci
operation is available.
Reference: http://marc.info/?l=linux-usb&m=138920063001509&w=2
Cc: Sarah Sharp
Cc: Mathias Nyman
Cc: Holger Hans Pe
From: Fabio Estevam
Using the IS_ENABLED() macro can make the code shorter and easier to read.
Signed-off-by: Fabio Estevam
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host
To create a global command queue we require that each command put on the
command ring is submitted with a command structure.
Functions that queue commands and wait for completion need to allocate a command
before submitting it, and free it once completed. The following command queuing
functions ne
Create a list to store command structures, add a structure to it every time
a command is submitted, and remove it from the list once we get a
command completion event matching the command.
Callers that wait for completion will free their command structures themselves.
The other command structures
Remove the per-device command list and handle_cmd_in_cmd_wait_list()
and use the completion and status variables found in the
command structure in the global command list.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 11 --
drivers/usb/host/xhci-mem.c | 1 -
drivers/usb/
From: Dan Williams
Save someone else the debug cycles of figuring out why a driver's
transfer request is failing or causing undefined system behavior.
Buffers submitted for dma must come from GFP allocated / DMA-able
memory.
Return -EAGAIN matching the return value for dma_mapping_error() cases.
From: Lin Wang
This patch fix wrong port number reported when trying to enable/disable
USB2.0 hardware LPM.
Signed-off-by: Lin Wang
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/us
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each
On Thu, May 8, 2014 at 9:09 AM, Alan Stern wrote:
> On Thu, 8 May 2014, Dan Williams wrote:
>
>> > I don't understand this last part. Why do we need to guarantee the
>> > child device has recovered from power loss? Why not proceed the same
>> > way we do now when the child is suspended?
>>
>> Tw
On 08.05.2014 17:59, Andreas Färber wrote:
> Hello,
>
> Am 05.05.2014 14:30, schrieb Vivek Gautam:
>> The exynos5250-snow has a SMSC USB3503 connected in
>> hardware only mode like a PHY. Enable support for it,
>> and add necessary 'reset-gpio' for it.
>>
>> This is in correspondance to similar pa
On Thu, 8 May 2014, Dan Williams wrote:
> > I don't understand this last part. Why do we need to guarantee the
> > child device has recovered from power loss? Why not proceed the same
> > way we do now when the child is suspended?
>
> Two reasons I believe:
>
> 1/ The child may be gone, and us
Hi Vivek,
On 05.05.2014 14:30, Vivek Gautam wrote:
> The exynos5250-snow has a SMSC USB3503 connected in
> hardware only mode like a PHY. Enable support for it,
> and add necessary 'reset-gpio' for it.
>
> This is in correspondance to similar patch by Mark Brown
> 7c1b0ec ARM: dts: Enable USB hub
On Wed, 7 May 2014, Dan Williams wrote:
> Per Alan:
> "You mean from within hub_handle_remote_wakeup()? That routine will
> never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd
> never sees wakeup requests if they arise during system suspend.
>
> In fact, that routine ought to go i
On Thu, May 8, 2014 at 8:44 AM, Alan Stern wrote:
> On Wed, 7 May 2014, Dan Williams wrote:
>
>> Unconditionally wake up the child device when the power session is
>> recovered.
>
> ...
>
>> 1, 2, and 4 are not a problem in the system dpm_resume() case because,
>> although the power-session is los
Hello,
Am 05.05.2014 14:30, schrieb Vivek Gautam:
> The exynos5250-snow has a SMSC USB3503 connected in
> hardware only mode like a PHY. Enable support for it,
> and add necessary 'reset-gpio' for it.
>
> This is in correspondance to similar patch by Mark Brown
> 7c1b0ec ARM: dts: Enable USB hub
On Thu, May 8, 2014 at 4:09 AM, Rafael J. Wysocki wrote:
> On Wednesday, May 07, 2014 10:37:24 PM Dan Williams wrote:
>> Unconditionally wake up the child device when the power session is
>> recovered.
>
> [cut]
>
>> + /*
>> + * Revalidate t
Hi,
(using private email as I'm having issue with company's VPN, will get
that sorted out by tomorrow hopefully)
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
> > > dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does
> > > not
> > > allow it. A device must always respond to SETUP
On Thu, 8 May 2014, Arnd Bergmann wrote:
> The dependency on the isp1301 driver is not something that
> should be in the main OHCI driver but rather the SoC specific
> part of it.
>
> This moves the dependency for LPC32xx into USB_OHCI_HCD_LPC32XX,
> and changes the 'select ISP1301_OMAP' to a sim
On Thu, 8 May 2014, Arnd Bergmann wrote:
> The PHY setup code of the TI DaVinci DA8xx OHCI controller
> uses ad-hoc register access using a pointer that is meant to
> be used only by the DaVinci platform implementation and that
> is intentionally not exported to loadable modules. This results
> in
On Wed, 7 May 2014, Dan Williams wrote:
> Unconditionally wake up the child device when the power session is
> recovered.
...
> 1, 2, and 4 are not a problem in the system dpm_resume() case because,
> although the power-session is lost, khubd is frozen until after device
> resume. For the rpm_r
Hi,
On Thu, May 08, 2014 at 02:30:39PM +, suresh.gu...@freescale.com wrote:
> As per my limited knowledge, the purpose of
> OTGSC_STS_B_SESSION_VALID bit is to tell either VBUS is above the B
> session valid threshold and which comes only Host is attached.
Yes, that matches the datasheet I've
On Wed, 2014-05-07 at 15:30 +0530, Suresh Kumar N. wrote:
> On Tue, May 6, 2014 at 9:42 PM, Dan Williams wrote:
> > On Tue, 2014-05-06 at 14:27 +0530, Suresh Kumar N. wrote:
> >> On Mon, May 5, 2014 at 8:38 PM, Dan Williams wrote:
> >> > On Mon, 2014-05-05 at 11:07 +0530, Suresh Kumar N. wrote:
>
On Thu, 8 May 2014, Zhuang Jin Can wrote:
> > dwc3 _cannot_ return NYET to a SETUP packet. The USB protocol does not
> > allow it. A device must always respond to SETUP with ACK.
> It true that device can not return NYET to a SETUP packet.
> A device must always respond to SETUP with ACK _if_ t
On Thu, May 08, 2014 at 10:25:46AM -0400, Alan Stern wrote:
> On Thu, 8 May 2014, Zhuang Jin Can wrote:
>
> > > When the host already timed out the control transfer and started a new
> > > one. Here's what I'm talking about:
> > >
> > > Host sends a Set-Configuration request.
> > >
> > > T
On Thu, 2014-05-08 at 16:27 +0200, Arnd Bergmann wrote:
> On Thursday 08 May 2014 17:21:49 Ivan T. Ivanov wrote:
> > > @@ -168,7 +168,7 @@ config USB_EHCI_HCD_AT91
> > >
> > > config USB_EHCI_MSM
> > > tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
> > > - depends
Hi,
As per my limited knowledge, the purpose of OTGSC_STS_B_SESSION_VALID bit is to
tell either VBUS is above the B session valid threshold and which comes only
Host is attached.
And Host might be attach after system bootup or after driver initialization. So
putting this check in probe will not
On Thursday 08 May 2014 17:21:49 Ivan T. Ivanov wrote:
> > @@ -168,7 +168,7 @@ config USB_EHCI_HCD_AT91
> >
> > config USB_EHCI_MSM
> > tristate "Support for Qualcomm QSD/MSM on-chip EHCI USB controller"
> > - depends on ARCH_MSM
> > + depends on ARCH_MSM && RESET_CONTROLLER
>
> T
On Thu, 8 May 2014, Zhuang Jin Can wrote:
> > When the host already timed out the control transfer and started a new
> > one. Here's what I'm talking about:
> >
> > Host sends a Set-Configuration request.
> >
> > The UDC driver calls the gadget driver's setup function.
> >
> > The
Hi Arnd,
On Thu, 2014-05-08 at 15:52 +0200, Arnd Bergmann wrote:
> Commit a27345434134 "usb: phy: msm: Use reset framework for LINK
> and PHY resets" introduced a mandatory call to reset_control_get
> into the msm usb phy driver, which means we have to add a Kconfig
> dependency on the API to av
On Thu, 8 May 2014, Hans de Goede wrote:
> Hi,
>
> On 05/08/2014 12:00 AM, Maxime Ripard wrote:
> > On Wed, May 07, 2014 at 10:25:55AM -0400, Alan Stern wrote:
> >> On Tue, 6 May 2014, Maxime Ripard wrote:
> >>
> >>> From: Boris BREZILLON
> >>>
> >>> On the Allwinner's A31 SoC the reset line con
The PHY setup code of the TI DaVinci DA8xx OHCI controller
uses ad-hoc register access using a pointer that is meant to
be used only by the DaVinci platform implementation and that
is intentionally not exported to loadable modules. This results
in a link error on configurations that use a modular O
These is the usb part of my longer ARM randconfig build bug
series. None of these are actually needed for 3.15 as far as
I can tell, but it would be good to have them included in the
next merge window.
The xhci patch is only for a build warning, not a failure, but
we see this one all the time beca
The dependency on the isp1301 driver is not something that
should be in the main OHCI driver but rather the SoC specific
part of it.
This moves the dependency for LPC32xx into USB_OHCI_HCD_LPC32XX,
and changes the 'select ISP1301_OMAP' to a similar 'depends on'.
Since the same dependency exists fo
A configuration with CONFIG_USB_MUSB_HDRC=y, CONFIG_USB_TUSB_OMAP_DMA=y
and CONFIG_USB_MUSB_TUSB6010=m causes a link failure because of the
dependency on the tusb_get_revision symbol:
(.text+0x154ce8): undefined reference to `tusb_get_revision'
This patch ensures that either MUSB_HDRC and MUSB_TU
The musb/omap2430.c bus glue driver calls usb_hcd_poll_rh_status,
which is only available if CONFIG_USB is also set, i.e. we
are building USB host mode and not just endpoint mode.
Signed-off-by: Arnd Bergmann
Cc: linux-o...@vger.kernel.org
---
drivers/usb/musb/Kconfig | 2 +-
1 file changed, 1 i
pr_debug() may be defined as "do { } while (0)" in some configurations,
which means one cannot rely on the return value to be available.
In the dprintk function in this driver, we can work around the
resulting build error trivially by returning the length that
this function already knows and ignor
Commit a27345434134 "usb: phy: msm: Use reset framework for LINK
and PHY resets" introduced a mandatory call to reset_control_get
into the msm usb phy driver, which means we have to add a Kconfig
dependency on the API to avoid this build error:
phy/phy-msm-usb.c: In function 'msm_otg_read_dt':
phy
The isp1301-omap driver cannot be built-in if the tps65010 driver
is a module, otherwise we get a link error from the reference to
the tps65010_set_vbus_draw function.
There is already a hack in the driver to work around the problem
of tps65010 being not available at all. This patch extends that
h
If we build a kernel with PM_SUSPEND set and no PM_SLEEP,
we get a build warning in the xhci-plat driver about unused
functions.
To fix this, use "#ifdef CONFIG_PM_SLEEP", like we do in most
other drivers nowadays.
Signed-off-by: Arnd Bergmann
Cc: Mathias Nyman
---
drivers/usb/host/xhci-plat.c
Hello.
On 05/08/2014 02:03 AM, Maxime Ripard wrote:
The OHCI controllers used in the Allwinner A31 are asserted in reset using a
s/asserted/powered up/?
No. There's an external reset controller that maintains these devices
into reset. It's not only a power on thing, it can also be put
On 2014-05-07 22:26, Alexey Khoroshilov wrote:
As far as gr_queue() is called with spinlock held,
we have to pass GFP_ATOMIC regardless of gfp argument.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Acked-by: Andreas Larsson
---
drivers
In order for usb functions to expose OS descriptors they
need to be made aware of OS descriptors. This involves
extending the "options" structure and setting up
appropriate associations.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Michal Nazarewicz
---
drivers/usb/gadget/f_rndis.c | 24 +
There is a custom (non-USB IF) extension to the USB standard:
http://msdn.microsoft.com/library/windows/hardware/gg463182
They grant permission to use the specification - there is
"Microsoft OS Descriptor Specification License Agreement"
under the link mentioned above, and its Section 2 "Grant
of
Add handling of OS Extended Properties descriptors from configfs interface.
One kind of "OS Descriptors" are "Extended Properties" descriptors, which
need to be specified per interface or per group of interfaces described
by an IAD. This patch adds support for creating subdirectories
in interface.
Add handling of OS Extended Compatibility descriptors from configfs interface.
Hosts which expect the "OS Descriptors" ask only for configurations @ index 0,
but linux-based USB devices can provide more than one configuration.
This patch adds marking one of gadget's configurations the configuration
Added handling of OS Descriptors support for f_rndis.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/usb/gadget/f_rndis.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
index a7633d6..eed3ad8 100644
--- a/drivers/usb/gadge
There is a custom (non-USB IF) extension to the USB standard:
http://msdn.microsoft.com/library/windows/hardware/gg463182
They grant permission to use the specification - there is
"Microsoft OS Descriptor Specification License Agreement"
under the link mentioned above, and its Section 2 "Grant
of
There is a custom (non-USB IF) extension to the USB standard:
http://msdn.microsoft.com/library/windows/hardware/gg463182
They grant permission to use the specification - there is
"Microsoft OS Descriptor Specification License Agreement"
under the link mentioned above, and its Section 2 "Grant
of
Add handling of OS String extension from the configfs interface.
A directory "os_desc" is added at the top level of a gadget's
directories hierarchy. In the "os_desc" directory there are
three attributes: "use", "b_vendor_code" and "qw_sign".
If "use" contains "0" the OS string is not reported to t
Variable Length Array macros allow portable (compilable with both gcc
and clang) way of allocating a number of structures using a single
memory chunk. They can be useful for files other than f_fs.c,
so move them to a header file.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Michal Nazarewicz
-
On Wednesday, May 07, 2014 10:37:24 PM Dan Williams wrote:
> Unconditionally wake up the child device when the power session is
> recovered.
[cut]
> + /*
> + * Revalidate the device if it was requested by
> + *
AM335x MUSB supports both PIO and DMA mode. When DMA mode is
selected users need to explicitly enable the DMA driver. To avoid the
extra configuration select the DMA driver if DMA mode is set for AM335x MUSB.
Signed-off-by: George Cherian
---
drivers/usb/musb/Kconfig | 1 +
1 file changed, 1 ins
On 5/8/2014 3:17 PM, Daniel Mack wrote:
Hi Geroge,
On 05/08/2014 11:35 AM, George Cherian wrote:
-static inline void musb_platform_reset(struct musb *musb)
+static inline int musb_platform_reset(struct musb *musb)
{
- if (musb->ops->reset)
- musb->ops->reset(musb);
+
Hi Geroge,
On 05/08/2014 11:35 AM, George Cherian wrote:
> -static inline void musb_platform_reset(struct musb *musb)
> +static inline int musb_platform_reset(struct musb *musb)
> {
> - if (musb->ops->reset)
> - musb->ops->reset(musb);
> + if (!musb->ops->reset)
> +
Series add support for SW babble control logic found in
new silicon versions of AM335x. Runtime differentiation of
silicon version is done by checking the BABBLE_CTL register.
For newer silicon the register default value read is 0x4 and
for older versions its 0x0.
Patch 1 -> Convert recover work
For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_dsps.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb
During babble condition first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.
To acheive this schedule a delayed work for babble rrecovery.
While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_dsps.c | 34 +++
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_dsps.c |
Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetti
The series does some refactoring on dwc3_probe()
Patch 1-3 - reduce the size of dwc3_probe()
Patch 4 - Fix the crash on dwc3_omap removal
Patch 5 - Addresses the issue of xhci hang while resuming from system sleep.
George Cherian (5):
usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset function
Following crash is seen on dwc3_omap removal
Unable to handle kernel NULL pointer dereference at virtual address 0018
pgd = ec098000
[0018] *pgd=ad1f9831, *pte=, *ppte=
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in: usb_f_ss_lb g_zero usb_f_acm u_serial usb_f_ecm u
Calculate the wrapper register offsets in a seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian
---
drivers/usb/dwc3/dwc3-omap.c | 80
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git
Move the extcon related code to its own function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian
---
drivers/usb/dwc3/dwc3-omap.c | 65 ++--
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/us
Enabling the core interrupts in complete is too late for XHCI, and stops
xhci from proper operation. So remove prepare and complete and disable/enable
interrupts in suspend/resume
Signed-off-by: George Cherian
---
drivers/usb/dwc3/dwc3-omap.c | 20 ++--
1 file changed, 2 insertio
Move find and set the utmi mode to its own seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian
---
drivers/usb/dwc3/dwc3-omap.c | 44 +---
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git
On Thursday 08 May 2014 02:51 PM, George Cherian wrote:
> Move the extcon related code to its own function.
> Improve code readability, decrease the dwc3_probe() size.
>
> Signed-off-by: George Cherian
> ---
> drivers/usb/dwc3/dwc3-omap.c | 65
> ++--
>
1 - 100 of 102 matches
Mail list logo
