The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed w
On Wed, Jul 31, 2013 at 04:21:16PM +0200, Lothar Waßmann wrote:
> commit 40dcd0e introduced the following code to the ci_hdrc_probe()
> function:
>
> + if (!dev->of_node && dev->parent)
> + dev->of_node = dev->parent->of_node;
>
> This inadvertently associates the ci_hdrc devi
On Wed, Jul 31, 2013 at 04:21:15PM +0200, Lothar Waßmann wrote:
>
> Signed-off-by: Lothar Waßmann
> ---
> drivers/usb/chipidea/core.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index a5df24c..38b0a7a
On Wed, Jul 31, 2013 at 04:21:14PM +0200, Lothar Waßmann wrote:
> This prevents the USB PHY refcount to be decremented below zero upon
> unloading the ci-hdrc-imx module.
>
> Signed-off-by: Lothar Waßmann
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
> 1 files changed, 1 insertions(+),
On Wed, Jul 31, 2013 at 04:21:13PM +0200, Lothar Waßmann wrote:
> This patch provides a cleaner solution to the problem described in
> commit 20a677fd.
>
> The goal to be achieved is to force USB_CHIPIDEA=m if either
> USB_EHCI_HCD=m or USB_GADGET=m.
> If both are 'y' USB_CHIPIDEA may be selected
On 7/31/2013 1:46 AM, Sebastian Andrzej Siewior wrote:
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
On 7/31/2013 1:46 AM, Sebastian Andrzej Siewior wrote:
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 d
On Thu, 2013-08-01 at 12:41 +0800, Ming Lei wrote:
> From my trace result, lots of linear SKBs are cloned or header-cloned, so
> it needs skb copy too.
>
> Is it normal in xmit path to see cloned SKBs for driver? If not, I can add
> check
> to avoid allocation of 8 bytes header for non-cloned sk
Hi Eric,
Thanks for your review.
On Thu, Aug 1, 2013 at 11:51 AM, Eric Dumazet wrote:
> On Wed, 2013-07-31 at 18:51 +0800, Ming Lei wrote:
>> This patch enables 'can_dma_sg' flag for ax88179_178a device
>> if the attached host controller supports building packet from
>> discontinuous buffers(DMA
On Wed, 2013-07-31 at 18:51 +0800, Ming Lei wrote:
> This patch enables 'can_dma_sg' flag for ax88179_178a device
> if the attached host controller supports building packet from
> discontinuous buffers(DMA SG is possible), so both frame header
> and skb data buffers can be passed to usb stack via u
met an issue with using ADK2012 to test usb audio. android audio
thread is blocked 10s after ADK2012 HW disconnect(unpluged). In
audio_unbind function, we should wake up and notify potential
sleep thread timely.
not sure it's a good solution. please help suggest if any. thanks.
Qiao Zhou (1):
when usb audio device removes, it doesn't notify the ALSA read /
write thread. due to no data transmitting any more, those threads
wait for a long timeout(10s), then detects IO error. it causes
long time blocking in upper layer read/write.
to fix this issue, wake up potential sleep thread if neces
On Wed, Jul 31, 2013 at 11:15 PM, Eric Dumazet wrote:
> On Wed, 2013-07-31 at 16:02 +0200, Oliver Neukum wrote:
>
> Hmm, I would rather make sure SG is really supported before adding TSO
> support.
>
> TCP stack can build skb with fragments of any size, not multiple
> of 512 or 1024 bytes.
Now Sa
On Wed, Jul 31, 2013 at 10:15:12AM -0400, Tejun Heo wrote:
> hello,
>
> On Wed, Jul 31, 2013 at 09:55:26PM +0800, Peter Chen wrote:
> > I think the main point is we should allocate managed resource which is used
> > at interrupt handler before devm_request_irq, and all resources used
> > at interr
On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern wrote:
> On Wed, 31 Jul 2013, James Stone wrote:
>
>> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern
>> wrote:
>> > On Tue, 30 Jul 2013, Alan Stern wrote:
>> >
>> >> I can try to ameliorate the situation. Although the 7-ms delay will
>> >> inevitably ca
On 07/31/2013 11:41 AM, Tuomas Tynkkynen wrote:
> Hi all,
>
> Here are the patches for the USB tree to enable USB Host support on Tegra30
> and
> Tegra114. These are based on my and Mikko's cleanup patches that just got
> merged to Felipe's tree.
This series works fine for me on Dalmore. However
On 07/31/2013 04:20 PM, Sergei Shtylyov wrote:
> On 08/01/2013 02:06 AM, Stephen Warren wrote:
...
>>> That's really horrible design.
>>
>> Yup. Both USB PHY and EHCI controller registers really are interleaved
>> in one range.
>
>But the standard EHCI register space has no holes IIRC, so
On 08/01/2013 02:06 AM, Stephen Warren wrote:
Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.
diff --git a/arch/arm/boot/dts/tegra114.dtsi
b/arch/arm/boot/dts/tegra114.dtsi
index abf6c40..2905145 100644
--- a/arch/arm/boo
On 07/31/2013 11:42 AM, Tuomas Tynkkynen wrote:
> Add device tree entries for the 3 USB controllers and PHYs and
> enable the third controller on Cardhu and Beaver boards.
>
> Fix VBUS regulator entries on Beaver. The GPIO pins were wrong.
That much is correct.
> Also, a third GPIO is required t
On 07/31/2013 01:53 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 07/31/2013 11:31 PM, Tuomas Tynkkynen wrote:
Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.
diff --git a/arch/arm/boot/dts/tegra114.dtsi
b/ar
From: Hayes Wang
Date: Wed, 31 Jul 2013 17:21:22 +0800
> Some USB buffers use stack which may not be DMA-able.
> Use the buffers from kmalloc to replace those one.
>
> Signed-off-by: Hayes Wang
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a me
From: Hayes Wang
Date: Wed, 31 Jul 2013 17:21:23 +0800
> Don't replace the usb_control_msg() with usbnet_{read,write}_cmd()
> which couldn't be called inside suspend/resume callback. Keep the
> basic functions unlimited. Instead, using usb_autopm_get_interface()
> and usb_autopm_put_interface() i
From: Hayes Wang
Date: Wed, 31 Jul 2013 17:21:26 +0800
> - fix the conversion between cpu and __le32
> - replace some pla_ocp and usb_ocp functions with generic_ocp function
>
> Signed-off-by: Hayes Wang
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the
From: Hayes Wang
Date: Wed, 31 Jul 2013 17:21:25 +0800
> Allocate the required memory before calling usb_control_msg. And
> the additional memory copy is necessary.
>
> Signed-off-by: Hayes Wang
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a m
From: Hayes Wang
Date: Wed, 31 Jul 2013 17:21:24 +0800
> Replace 0 with the result from usbnet_cdc_bind().
>
> Signed-off-by: Hayes Wang
Applied.
--
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
On Wed, Jul 31, 2013 at 10:07 PM, Alan Stern wrote:
> On Wed, 31 Jul 2013, James Stone wrote:
>
>> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern
>> wrote:
>> > On Tue, 30 Jul 2013, Alan Stern wrote:
>> >
>> >> I can try to ameliorate the situation. Although the 7-ms delay will
>> >> inevitably ca
On Wed, 31 Jul 2013, James Stone wrote:
> On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern wrote:
> > On Tue, 30 Jul 2013, Alan Stern wrote:
> >
> >> I can try to ameliorate the situation. Although the 7-ms delay will
> >> inevitably cause an underrun, it doesn't have to cause errors the way
> >> it
On 07/31/2013 11:42 AM, Tuomas Tynkkynen wrote:
> The lock bit on PLL_U does not seem to be working correctly and
> sometimes never gets set when waiting for the PLL to come up.
> Remove the TEGRA_PLL_USE_LOCK flag to use a constant delay.
Peter, Prashant,
I think you said that the lock bits shou
On Wed, Jul 31, 2013 at 4:48 PM, Alan Stern wrote:
> On Tue, 30 Jul 2013, Alan Stern wrote:
>
>> I can try to ameliorate the situation. Although the 7-ms delay will
>> inevitably cause an underrun, it doesn't have to cause errors the way
>> it does now. I'll write a patch to handle this. It may
On Wed, 31 Jul 2013, Tomasz Figa wrote:
> Alan, Greg,
>
> On Tuesday 23 of July 2013 01:49:23 Tomasz Figa wrote:
> > This patch modifies the ohci-s3c2410 driver to prepare and unprepare
> > clocks in addition to enabling and disabling, since it is required
> > by common clock framework.
> >
> >
On Wed, 31 Jul 2013, Kumar Gaurav wrote:
> Fixed String splitted into multiple line issue using macro
I'm not an expert on this kind of style issue, but I prefer strings that
look like strings.
julia
> Signed-off-by: Kumar Gaurav
> ---
> drivers/staging/usbip/stub_dev.c | 17 ++---
Hello.
On 07/31/2013 11:31 PM, Tuomas Tynkkynen wrote:
From: Mikko Perttunen
Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.
I would have done the board patch separately from the SoC one.
Signed-off-by: Mikko
Hi,
On Wed, Jul 31, 2013 at 11:45:48PM +0400, Sergei Shtylyov wrote:
> >Sergei, Felipe, do you have a strong preference on this name? Or should
> >I take the patch as is?
>
>I've already said I don't have a strong preference.
I don't have a strong preference either, just think that adding t
Hello.
On 07/31/2013 10:48 PM, Sarah Sharp wrote:
Add Device Tree match table to xhci-plat.c. Add DT bindings document.
Signed-off-by: Al Cooper
---
Al, in the future, please add a description of your changes since the
last revision here, after the --- line. It makes it much easier to
r
Hello,
On 31/07/13 21:18, Sergei Shtylyov wrote:
Hello.
On 07/31/2013 09:42 PM, Tuomas Tynkkynen wrote:
From: Mikko Perttunen
Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.
I would have done the board patch sep
Alan, Greg,
On Tuesday 23 of July 2013 01:49:23 Tomasz Figa wrote:
> This patch modifies the ohci-s3c2410 driver to prepare and unprepare
> clocks in addition to enabling and disabling, since it is required
> by common clock framework.
>
> Signed-off-by: Tomasz Figa
> ---
> drivers/usb/host/ohc
On Thu, Jul 25, 2013 at 07:04:44PM -0400, Al Cooper wrote:
> Add Device Tree match table to xhci-plat.c. Add DT bindings document.
>
> Signed-off-by: Al Cooper
> ---
Al, in the future, please add a description of your changes since the
last revision here, after the --- line. It makes it much ea
> An odd sort of bug. You'd think that not getting a response back would
> be one of the first types of error the hardware designers would check
> for.
You'd think that, right? But apparently they didn't. I've now also
tried just hacking a pointless SET_INTERFACE message into the
hub_port_connect
On Wednesday 31 July 2013 14:38:34 Alan Stern wrote:
> See
>
> http://marc.info/?l=linux-usb&m=137523956310060&w=2
>
Yes, that's surely the same bug we're seeing. I guess the patch will be in
3.10.5, so I'll wait for that and in case it doesn't fix my problem (but I
doubt it won't) I'l
On Wed, 31 Jul 2013, Alberto Gonzalez wrote:
> Hello,
>
> There seems to be a regression in Kernel 3.10.3 (from 3.10.2) that prevents
> me
> being able to mount my external USB hard drive. When I plug it I get messages
> like:
>
> [ 82.633138] xhci_hcd :05:00.0: xHCI xhci_drop_endpoint
On Wed, 31 Jul 2013, Tuomas Tynkkynen wrote:
> The has_hostpc capability bit indicates that the host controller has the
> HOSTPC register extensions, but at the same time enables clock disabling
> power saving features with the PHY Low Power Clock Disable (PHCD) bit.
>
> However, some host contro
From: Julius Werner
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() function based on whether there was a
The following changes since commit fed1f1ed90bce42ea010e2904cbc04e7b8304940:
USB: serial: ftdi_sio: add more RT Systems ftdi devices (2013-07-29 13:38:38
-0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
tags/for-usb-linus-2013-07-3
From: James Hogan
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 includes to fix the build errors.
drivers/usb/host/xhci.c In function 'xhci_gen_setup':
drivers/usb/host/xhci.c +4872 : error: implicit
Hello,
There seems to be a regression in Kernel 3.10.3 (from 3.10.2) that prevents me
being able to mount my external USB hard drive. When I plug it I get messages
like:
[ 82.633138] xhci_hcd :05:00.0: xHCI xhci_drop_endpoint called with
disabled ep 88014c85a180
[ 82.633148] xhci_h
Hello.
On 07/31/2013 09:42 PM, Tuomas Tynkkynen wrote:
From: Mikko Perttunen
Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.
I would have done the board patch separately from the SoC one.
Signed-off-by: Mikko Per
Hi all,
Here are the patches for the USB tree to enable USB Host support on Tegra30 and
Tegra114. These are based on my and Mikko's cleanup patches that just got
merged to Felipe's tree.
The first one touches the core hub code to prevent certain (non-standard) clock
disable features as our contro
Hello.
On 07/31/2013 06:21 PM, Lothar Waßmann wrote:
This patch provides a cleaner solution to the problem described in
commit 20a677fd.
Please also specify that commit's summary line in parens.
The goal to be achieved is to force USB_CHIPIDEA=m if either
USB_EHCI_HCD=m or USB_GADGET=m.
The Tegra30 USB PHY is a bit different than the Tegra20 PHY:
- The EHCI controller supports the HOSTPC register extension, and some
of the fields that the PHY needs to modify (PHCD and PTS) have moved
to the new HOSTPC register.
- Some of the UTMI PLL configuration registers have moved from th
The Tegra30 TRM recommends configuration of certain PHY parameters for
optimal quality. Program the following registers based on device tree
parameters:
- UTMIP_XCVR_HSSLEW: HS slew rate control.
- UTMIP_HSSQUELCH_LEVEL: HS squelch detector level
- UTMIP_HSDISCON_LEVEL: HS disconnect detector leve
Fixed String splitted into multiple line issue using macro
Signed-off-by: Kumar Gaurav
---
drivers/staging/usbip/stub_dev.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index 83d629a.
Document the new device tree parameters for Tegra30 USB PHY.
Signed-off-by: Tuomas Tynkkynen
---
.../devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt| 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb
Some of the PHY parameters are not set according to the TRMs:
- UTMIP_FS_PREABMLE_J should be set, not cleared
- UTMIP_XCVR_LSBIAS_SEL should be cleared, not set
- UTMIP_PD_CHRG should be set in host mode and cleared in device mode
- UTMIP_XCVR_SETUP is a two-part field; the upper bits were not se
Add device tree entries for the 3 USB controllers and PHYs and
enable the third controller on Cardhu and Beaver boards.
Fix VBUS regulator entries on Beaver. The GPIO pins were wrong.
Also, a third GPIO is required to power the pullup resistors that drive
the VBUS voltage switches, so add an regul
The Tegra30 EHCI controller is mostly compatible with the Tegra20
controller, except Tegra30 includes the HOSTPC register extension.
The has_hostpc capability bit must be set in the ehci_hcd structure if
the controller has such extensions. The new tegra_ehci_soc_config
structure is added to describ
Hi all,
Here's the device tree changes required for USB Host support on Tegra30 and
Tegra114. This enables USB Host on the Cardhu's dock connector port and on the
single built-in A-ports on Dalmore and Beaver,
Mikko Perttunen (1):
ARM: dts: USB for Tegra114 Dalmore
Tuomas Tynkkynen (1):
ARM:
From: Mikko Perttunen
Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.
Signed-off-by: Mikko Perttunen
---
arch/arm/boot/dts/tegra114-dalmore.dts | 9 +
arch/arm/boot/dts/tegra114.dtsi| 62 ++
Hi all,
This patch is required for USB support on Tegra30 due to a likely hardware
bug in the PLL_U oscillator which clocks the USB complex.
Tuomas Tynkkynen (1):
clk: tegra30: Don't wait for PLL_U lock bit
drivers/clk/tegra/clk-tegra30.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The lock bit on PLL_U does not seem to be working correctly and
sometimes never gets set when waiting for the PLL to come up.
Remove the TEGRA_PLL_USE_LOCK flag to use a constant delay.
Signed-off-by: Tuomas Tynkkynen
---
drivers/clk/tegra/clk-tegra30.c | 2 +-
1 file changed, 1 insertion(+), 1
The has_hostpc capability bit indicates that the host controller has the
HOSTPC register extensions, but at the same time enables clock disabling
power saving features with the PHY Low Power Clock Disable (PHCD) bit.
However, some host controllers have the HOSTPC extensions but don't
support the l
On Wed, Jul 31, 2013 at 11:29:32AM -0400, Tejun Heo wrote:
> Yeah, sure, thank you very much for your input. It is of course
> strictly ordered and the documentation needs to be updated.
While I note the way you're saying this given the widespread adoption I
think there's a bit more effort neede
On Wed, Jul 31, 2013 at 10:43:30AM -0400, Alan Stern wrote:
> 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
On Wed, Jul 31, 2013 at 06:51:47PM +0800, Ming Lei wrote:
> This patch marks all xHCI controllers as no_sg_limit since
> xHCI supports building packet from discontinuous buffers.
>
> Cc: Sarah Sharp
> Signed-off-by: Ming Lei
Acked-by: Sarah Sharp
> ---
> drivers/usb/host/xhci.c |4
>
On Tue, Jul 30, 2013 at 07:33:46PM -0700, Julius Werner wrote:
> > Wait a moment. Why does each of these attempts lead to a 5-second
> > timeout? Why don't they fail immediately?
>
> Now that you mention it, that's a very good question. The kernel
> enqueues a control transfer to the now disconn
On Wed, Jul 31, 2013 at 11:49 PM, Ming Lei wrote:
> On Wed, Jul 31, 2013 at 5:56 PM, Till Schmalmack wrote:
>> Hello Ming,
>>
>> I am experiencing issues with the usbnet commits you did for the 3.10
>> kernel, in particular with
>>
>> 4be74c13 usbnet: mcs7830: apply usbnet_link_change
>>
>> I fil
On Wed, Jul 31, 2013 at 5:56 PM, Till Schmalmack wrote:
> Hello Ming,
>
> I am experiencing issues with the usbnet commits you did for the 3.10
> kernel, in particular with
>
> 4be74c13 usbnet: mcs7830: apply usbnet_link_change
>
> I filed this bug
>
> https://bugzilla.kernel.org/show_bug.cgi?id=6
On Tue, 30 Jul 2013, Alan Stern wrote:
> I can try to ameliorate the situation. Although the 7-ms delay will
> inevitably cause an underrun, it doesn't have to cause errors the way
> it does now. I'll write a patch to handle this. It may take a few
> days.
James, see what happens with this pat
On Wed, 2013-07-31 at 18:51 +0800, Ming Lei wrote:
> Hi,
>
> This patchset allows drivers to pass sg buffers which size can't be divided
> by max packet size of endpoint if the host controllers support this kind
> of sg buffers.
>
> Previously we add check[1] on the situation and don't allow thes
On Wed, Jul 31, 2013 at 04:25:23PM +0100, Mark Brown wrote:
> What I'm saying is that in essentially all the users I've seen devm is
> only being used for things like kfree() or clk_put() which aren't really
> connected in any way and can happen in any order. This (coupled with
> the lack of docum
On Wed, Jul 31, 2013 at 11:15 PM, Eric Dumazet wrote:
> On Wed, 2013-07-31 at 16:02 +0200, Oliver Neukum wrote:
>> On Wed, 2013-07-31 at 21:50 +0800, Ming Lei wrote:
>>
>> > In the usbnet case, the driver already supports non-sg well. Actually,
>> > all current drivers should support non-sg well b
On Wed, Jul 31, 2013 at 10:07:58AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 02:57:51PM +0100, Mark Brown wrote:
> > That's the only API I've ever heard of doing that. Everything else is
> > just using it to do deallocation.
> I'm not sure why or what you're trying to argue here but take
On Wed, 2013-07-31 at 16:02 +0200, Oliver Neukum wrote:
> On Wed, 2013-07-31 at 21:50 +0800, Ming Lei wrote:
>
> > In the usbnet case, the driver already supports non-sg well. Actually,
> > all current drivers should support non-sg well because urb->sg wasn't
> > introduced for very long time. We
On Wed, 31 Jul 2013, Oliver Neukum wrote:
> These errors should be handled cleanly. How about this patch?
> From 76a377d9894dc8945e9afecc7f9864e6dc3156b1 Mon Sep 17 00:00:00 2001
> From: Oliver Neukum
> Date: Wed, 31 Jul 2013 13:32:51 +0200
> Subject: [PATCH] sd: handle errors during suspend
>
On Tue, 30 Jul 2013, Martin K. Petersen wrote:
> James?
>
> [PATCH] SCSI: Don't attempt to send extended INQUIRY command if
> skip_vpd_pages is set
>
> If a device has the skip_vpd_pages flag set we should simply fail the
> scsi_get_vpd_page() call.
>
> Signed-off-by: Martin K. Petersen
> Ack
On Tue, 30 Jul 2013, Julius Werner wrote:
> > Wait a moment. Why does each of these attempts lead to a 5-second
> > timeout? Why don't they fail immediately?
>
> Now that you mention it, that's a very good question.
I have brought this up with Sarah on more than one occasion, but we
never fou
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() function
On Tue, 30 Jul 2013, Stoddard, Nate (GE Healthcare) wrote:
> > 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 themselv
This prevents the USB PHY refcount to be decremented below zero upon
unloading the ci-hdrc-imx module.
Signed-off-by: Lothar Waßmann
---
drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/us
Signed-off-by: Lothar Waßmann
---
drivers/usb/chipidea/core.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index a5df24c..38b0a7a 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -4
This patch provides a cleaner solution to the problem described in
commit 20a677fd.
The goal to be achieved is to force USB_CHIPIDEA=m if either
USB_EHCI_HCD=m or USB_GADGET=m.
If both are 'y' USB_CHIPIDEA may be selected to be 'm' or 'y'.
The old patch had the drawback, that USB_CHIPIDEA could b
commit 40dcd0e introduced the following code to the ci_hdrc_probe()
function:
+ if (!dev->of_node && dev->parent)
+ dev->of_node = dev->parent->of_node;
This inadvertently associates the ci_hdrc device with the ci_hdrc_imx
driver (which created the ci_hdrc device in the first
On Wed, 31 Jul 2013, boris brezillon wrote:
> Hello Alan,
>
> I don't know if you remember but a few days back I sent a series which
> included this patch ("ARM: at91: prepare transition to common clk
> framework").
>
> It was decided to move this patch out of the "prepare" series to avoid
> b
hello,
On Wed, Jul 31, 2013 at 09:55:26PM +0800, Peter Chen wrote:
> I think the main point is we should allocate managed resource which is used
> at interrupt handler before devm_request_irq, and all resources used
> at interrupt
> handler should be managed.
>
> If we use non-managed resource at
Hi Alex, any comments, now it finished 3.11-rc4, I don't want this patchset
missed at 3.11.
Please tell me which one is OK, and which one needs to be refined, thanks.
Best regards,
Peter
From: linux-usb-ow...@vger.kernel.org [linux-usb-ow...@vger.kernel.
On Wed, Jul 31, 2013 at 02:57:51PM +0100, Mark Brown wrote:
> That's the only API I've ever heard of doing that. Everything else is
> just using it to do deallocation.
I'm not sure why or what you're trying to argue here but take a look
at devm_pwm_release() for example. It calls back into low l
My patches "usb: chipidea: fix the build error with randconfig" fixes chipidea
problem.
It has already at USB fixes for 3.11-rc4.
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/b
On Wed, 2013-07-31 at 21:50 +0800, Ming Lei wrote:
> In the usbnet case, the driver already supports non-sg well. Actually,
> all current drivers should support non-sg well because urb->sg wasn't
> introduced for very long time. We can think it as a new feature or DMA
> enhancement for xHCI contro
On Wed, Jul 31, 2013 at 09:42:15AM -0400, Tejun Heo wrote:
> On Wed, Jul 31, 2013 at 02:27:08PM +0100, Mark Brown wrote:
> > It's really only interrupts that affect most devices - if there's DMA or
> > anything going on after the remove() then as you said earlier the driver
> > is probably doing s
On Wed, Jul 31, 2013 at 9:27 PM, Mark Brown wrote:
> On Wed, Jul 31, 2013 at 07:55:27AM -0400, Tejun Heo wrote:
>
>> If you have DMA / IRQ / command engine deactivations in devm path
>> which often is the case with full conversions, freeing any resources
>> including DMA areas and host private dat
On Wed, Jul 31, 2013 at 05:34:52PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 31-07-2013 10:22, Felipe Balbi wrote:
>
> >Use the wrapper function for retrieving the
> >platform_data instead of accessing dev->platform_data
> >directly.
>
> >Inspired-by: Jingoo Han
> >Signed-off-by: Felipe Ba
On Wed, Jul 31, 2013 at 8:47 PM, Greg Kroah-Hartman
wrote:
> On Wed, Jul 31, 2013 at 06:51:49PM +0800, Ming Lei wrote:
>> This patch enables 'can_dma_sg' flag for ax88179_178a device
>> if the attached host controller supports building packet from
>> discontinuous buffers(DMA SG is possible), so b
Hello,
On Wed, Jul 31, 2013 at 02:27:08PM +0100, Mark Brown wrote:
> It's really only interrupts that affect most devices - if there's DMA or
> anything going on after the remove() then as you said earlier the driver
> is probably doing something wrong.
Hmmm... it depends on the specific driver i
Hello.
On 31-07-2013 10:22, Felipe Balbi wrote:
Use the wrapper function for retrieving the
platform_data instead of accessing dev->platform_data
directly.
Inspired-by: Jingoo Han
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 delet
On Wed, Jul 31, 2013 at 07:55:27AM -0400, Tejun Heo wrote:
> If you have DMA / IRQ / command engine deactivations in devm path
> which often is the case with full conversions, freeing any resources
> including DMA areas and host private data in the wrong order is a
> horrible idea. It's worse as
On Tue, Jul 30, 2013 at 9:28 PM, Alan Stern wrote:
> 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
On Wed, Jul 31, 2013 at 05:21:25PM +0800, Hayes Wang wrote:
> Allocate the required memory before calling usb_control_msg. And
> the additional memory copy is necessary.
>
> Signed-off-by: Hayes Wang
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linux
On Wed, Jul 31, 2013 at 05:21:22PM +0800, Hayes Wang wrote:
> Some USB buffers use stack which may not be DMA-able.
> Use the buffers from kmalloc to replace those one.
>
> Signed-off-by: Hayes Wang
Acked-by: Greg Kroah-Hartman
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Wed, Jul 31, 2013 at 06:51:49PM +0800, Ming Lei wrote:
> This patch enables 'can_dma_sg' flag for ax88179_178a device
> if the attached host controller supports building packet from
> discontinuous buffers(DMA SG is possible), so both frame header
> and skb data buffers can be passed to usb stac
On Wed, Jul 31, 2013 at 12:50:27PM +0100, Mark Brown wrote:
> Most things would work just fine - most of the uses of devm_ are just
> resource allocations that can safely be freed in essentially any order.
> It doesn't really matter if you free the driver's private structure
> before you free the c
On Wed, Jul 31, 2013 at 7:12 PM, Oliver Neukum wrote:
> On Wed, 2013-07-31 at 18:51 +0800, Ming Lei wrote:
>> Hi,
>>
>> This patchset allows drivers to pass sg buffers which size can't be divided
>> by max packet size of endpoint if the host controllers support this kind
>> of sg buffers.
>
> Cool
1 - 100 of 160 matches
Mail list logo
