On Wed, Jun 19, 2013 at 11:44 PM, Alan Stern wrote:
> On Wed, 19 Jun 2013, Ming Lei wrote:
>
>> > The approach used in this patch is wrong. You shouldn't start the
>> > unlink, then wait, then finish the unlink. Consider what would happen
>>
>> What you mentioned above is just what the patch is
Hi Laurent,
Thanks for your mail,
On Tue, Jun 18, 2013 at 6:12 PM, Laurent Pinchart
wrote:
> Hi Chetan,
>
> On Tuesday 18 June 2013 11:17:40 Chetan Nanda wrote:
>> Hi,
>>
>> I am currently working with UVC camera device which send data using
>> bulk transfer for preview and capture.
>> I have mo
Hi,
On Wednesday 19 June 2013 09:19 PM, Sylwester Nawrocki wrote:
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+/**
+ * phy_create() - create a new phy
+ * @dev: device that is creating the new phy
+ * @id: id of the phy
+ * @ops: function pointers for performing phy operations
+
On 06/19/13 00:20, Peter Chen wrote:
> on i386:
>
> drivers/built-in.o: In function `ci_hdrc_probe':
> core.c:(.text+0x20446b): undefined reference to `of_usb_get_phy_mode'
>
> Signed-off-by: Peter Chen
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap
Thanks.
> ---
> Changes for v2:
> - Usi
On Thursday, June 13, 2013 12:54 AM, Manjunath Goudar wrote:
>
> Separate the Samsung OHCI EXYNOS host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11
On Wed, Jun 19, 2013 at 11:47 PM, Alan Stern wrote:
> On Wed, 19 Jun 2013, Ming Lei wrote:
>
>> On Wed, Jun 19, 2013 at 12:43 AM, Alan Stern
>> wrote:
>> > On Tue, 18 Jun 2013, Ming Lei wrote:
>> >
>> >> If HCD_BH is set for HC driver's flags, URB giveback will be
>> >> done in tasklet context i
On Wed, Jun 19, 2013 at 11:37 PM, Alan Stern wrote:
> On Wed, 19 Jun 2013, Ming Lei wrote:
>
>> >> @@ -835,9 +839,11 @@ static int usb_rh_urb_dequeue(struct usb_hcd *hcd,
>> >> struct urb *urb, int status)
>> >> hcd->status_urb = NULL;
>> >> usb_hcd_unl
On Wed, Jun 19, 2013 at 3:51 PM, Roger Quadros wrote:
> Hi Chao,
>
> On 06/19/2013 05:31 AM, Chao Xie wrote:
>> Some controller need software to initialize PHY before add
>> host controller, and shut down PHY after remove host controller.
>> Add the generic code for these controllers so they do no
From: Wei Yongjun
Remove duplicated include.
Signed-off-by: Wei Yongjun
---
drivers/usb/phy/phy-tegra-usb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 3446245..cec0855 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+
On Wed, Jun 19, 2013 at 03:33:51PM -0500, Thomas Pugliese wrote:
> Hi,
> I am attempting to debug a problem where the hwa_hc module occasionally
> fails to start correctly when an HWA device is plugged in. An HWA device
> consists of two USB interfaces each with its own driver: the radio contro
On Wed, 12 Jun 2013, Manjunath Goudar wrote:
> Separate the Samsung OHCI S3C host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
>
> V2:
> -Set
Hi,
I am attempting to debug a problem where the hwa_hc module occasionally
fails to start correctly when an HWA device is plugged in. An HWA device
consists of two USB interfaces each with its own driver: the radio control
interface (hwa_rc.ko), and the host controller interface (hwa_hc.ko).
On Wed, 12 Jun 2013, Manjunath Goudar wrote:
> Separate the TI OHCI Atmel host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
>
> V2:
> -Set non-s
Hi guys,
This was seen on a linux-next (Jun18th tree) allmodconfig build:
WARNING: drivers/usb/gadget/fotg210-udc.o(.data+0x0): Section mismatch in
reference from the variable fotg210_driver to the function
.init.text:fotg210_udc_probe()
The variable fotg210_driver references
the function __ini
Sarah:
This report surfaced in Bugzilla #59011 (see especially comments #38
and #39). Toralf reports, among other things, that the integrated
"rate-matching" hub in his ThinkPad T420 (6 Series/C200 Series chipset)
isn't behaving the way it should.
The particular symptom is that when the hub is s
Roger Quadros writes:
> Add the Idle state pins for USB host and enable WAKEUP on
> DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
> sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
>
> CC: Benoît Cousson
> Signed-off-by: Roger Quadros
This one doesn't apply...
Hi Roger,
Roger Quadros writes:
> Runtime suspend the controller during bus suspend and resume it
> during bus resume. This will ensure that the USB Host power domain
> enters lower power state and does not prevent the SoC from
> endering deeper sleep states.
>
> Remote wakeup will come up as an
Hello.
On 06/19/2013 06:42 PM, Manjunath Goudar wrote:
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() w
Hello.
On 06/19/2013 06:05 PM, Roger Quadros wrote:
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 fi
On 06/18/2013 10:27 AM, Felipe Balbi wrote:
>> --- a/arch/arm/boot/dts/am33xx.dtsi +++
>> b/arch/arm/boot/dts/am33xx.dtsi @@ -341,6 +341,14 @@ port1-mode =
>> <3>; power = <250>; ti,hwmods = "usb_otg_hs"; + phys =
>> <&nopphy0 &nopphy1>; + }; + + nopphy0:
Hi Roger,
Roger Quadros writes:
> In order to support wake up from suspend use the pinctrl
> framework to put the USB host pins in IDLE state during suspend.
>
> CC: Samuel Ortiz
> Signed-off-by: Roger Quadros
You should use helpers for this now in the pinctrl core:
http://lists.infradea
On Tue, Jun 18, 2013 at 11:34:26AM +0300, Felipe Balbi wrote:
> MUSB alone has 8 different arch choices. Before, it used to be that core
> driver was dependendent on all of them, so whenever someone wanted to
> build MUSB for another arch, they had to introdude their glue code and
> modify the dep
On Wed, 19 Jun 2013, Ming Lei wrote:
> > The approach used in this patch is wrong. You shouldn't start the
> > unlink, then wait, then finish the unlink. Consider what would happen
>
> What you mentioned above is just what the patch is doing, :-)
>
> start_unlink_intr() only sets the qh as QH_
On Wed, 19 Jun 2013, Ming Lei wrote:
> > There's a good chance this problem was caused by a change in the
> > xhci-hcd driver.
>
> I am wondering why xhci-hcd may cause the problem since the affected
> hub is 'Intel Corp. Integrated Rate Matching Hub' which is connected to
> EHCI root hub.
It's
Hi,
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
> +/**
> + * phy_create() - create a new phy
> + * @dev: device that is creating the new phy
> + * @id: id of the phy
> + * @ops: function pointers for performing phy operations
> + * @label: label given to the phy
> + * @priv: private data
On Wed, 19 Jun 2013, Ming Lei wrote:
> On Wed, Jun 19, 2013 at 12:43 AM, Alan Stern
> wrote:
> > On Tue, 18 Jun 2013, Ming Lei wrote:
> >
> >> If HCD_BH is set for HC driver's flags, URB giveback will be
> >> done in tasklet context instead of interrupt context, so the
> >> ehci->lock needn't to
The core code creates a controller and immediately after that it calls
the ->start() callback. This one might drop an error but nobody cares.
The same thing happens in the destroy corner: First ->stop() called
followed by destroy callback. So why not merge those two into the same
function since the
it does not compile since 09fc7d ("usb: musb: fix incorrect usage of
resource pointer"). What makes me wonder most is if source of the
Tested-by tag :)
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/omap2430.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
The cleanup in the error is missing the dma controller. The structure is
allocated at runtime and ux500 allocates even a little more than just
this struct. So cleanup!
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/
If the descriptor is missing the reqeust is never unmapped. This patch
changes this and renames the cleanup label to unlock since there is no
cleanup done. The cleanup would revert the allocation of ressource (i.e.
this dma mapping) but it does not, it simply unlocks and returns.
Signed-off-by: Se
This patch removes is_dma_capable() and an ifdef in the init/exit path
around init/de-init of the dma_controller. Since we have the empty stubs
in the PIO code we can call it without gcc trouble. Earlier we had an
ifdef and the is_dma_capable() macro where gcc ignored the if (0) path
even that the
The ifdef reads somehow better than an ifndef
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_dma.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 1b6b827..8919ce2 100644
--- a/drivers/u
This check is hardly required and alas is wrong. 'c' might be NULL but
the chances are low that 'controller' after the container_of() becomes
NULL.
Since no other DMA implementation is doing that and musb-core does not
call it with a NULL pointer it can dropped.
Signed-off-by: Sebastian Andrzej Si
Hi Felipe,
here is a bunch of small musb patches.
Sebastian
--
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 Wed, 19 Jun 2013, Ming Lei wrote:
> >> @@ -835,9 +839,11 @@ static int usb_rh_urb_dequeue(struct usb_hcd *hcd,
> >> struct urb *urb, int status)
> >> hcd->status_urb = NULL;
> >> usb_hcd_unlink_urb_from_ep(hcd, urb);
> >>
> >> - s
Add a dma_controller_create() returning NULL so a few ifdefs can
dropped.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/usb/musb/musb_dma.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 3603711..c8e67fd 100
On Wed, 19 Jun 2013, Ming Lei wrote:
> On Wed, Jun 19, 2013 at 12:36 AM, Alan Stern
> wrote:
> > On Tue, 18 Jun 2013, Ming Lei wrote:
> >
> >> We disable local IRQs here in case of running complete() by
> >> tasklet to avoid possible deadlock because drivers may call
> >> spin_lock() to hold loc
Hi,
Thanks for your reply.
On Wed, Jun 19, 2013 at 11:17 PM, Alan Stern wrote:
> On Wed, 19 Jun 2013, Ming Lei wrote:
>
>> Hi,
>>
>> Recently, there is one bug report from Ubuntu community:
>>
>> USB 2.0 Ports Dont Work on Sony Vaio Laptop
>>
>> and the problem exists on upstream kernel too
On Wed, 19 Jun 2013, Roger Quadros wrote:
> Hi,
>
> This series attempts to suspend the OMAP EHCI host controller on USB
> Bus suspend.
Why do you want to suspend the host controller during bus suspend?
They are two different operations and should be carried out at two
different times. The c
On Wed, 19 Jun 2013, Ming Lei wrote:
> Hi,
>
> Recently, there is one bug report from Ubuntu community:
>
> USB 2.0 Ports Dont Work on Sony Vaio Laptop
>
> and the problem exists on upstream kernel too.
>
> The built-in two USB 2.0 devices can be recognized correctly,
> but external devic
On 06/18/2013 05:39 PM, Alan Stern wrote:
On Mon, 17 Jun 2013, Sarah Sharp wrote:
Correct me if I'm wrong here. The original idea was to switch
everything over to xHCI during some early stage (like when the xHCI
controller is first passed to the pci-quirks.c code) and switch back to
EHCI at sh
On 19 June 2013 20:12, Manjunath Goudar wrote:
> On 19 June 2013 18:13, Sergei Shtylyov
>> On 19-06-2013 16:12, Manjunath Goudar wrote:
>>> struct usb_hcd *hcd = platform_get_drvdata(pdev);
>>> struct ohci_hcd *ohci = hcd_to_ohci(hcd);
>>> + booldo_wakeup = device_may_w
On 06/13/13 06:38, Tomasz Figa wrote:
[...]
Another thing is that it's unlikely for any new SoC from S3C64xx
series to show up, so basically the clock list is fixed.
Sure. I can take this into clk-next along with patch #1, or if you
prefer:
Acked-by: Mike Turquette
Thanks.
IMHO with all
On Wed, Jun 19, 2013 at 09:12:56AM +0200, Jiri Slaby wrote:
> On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
> > On 17/06/13 23:05, Jiri Slaby wrote:
> >
> >> The last point I inclined to the Greg's argument to remove the
> >> EXPERT dependency.
> >>
> >> So currently I have what is attached... Co
On Wednesday 19 of June 2013 23:17:06 Kukjin Kim wrote:
> On 06/06/13 08:57, Tomasz Figa wrote:
> > This series is an attempt to move clock support on Samsung S3C64xx SoCs
> > to Common Clock Framework.
>
> Looks good :)
Thanks.
> > First, support for PLL types present on S3C64xx SoCs is added t
On 06/06/13 08:57, Tomasz Figa wrote:
This series is an attempt to move clock support on Samsung S3C64xx SoCs
to Common Clock Framework.
Looks good :)
First, support for PLL types present on S3C64xx SoCs is added to Samsung
Common Clock Framework driver. Then the main clock driver for mention
We no longer need to be initialized in any particular order
so move driver initialization to the standard place i.e. module_init()
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 10 +-
drivers/mfd/omap-usb-tll.c |8 +---
2 files changed, 2 ins
In order to support wake up from suspend use the pinctrl
framework to put the USB host pins in IDLE state during suspend.
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 46 +++
1 files changed, 46 insertions(+), 0 deleti
Some drivers (e.g. ehci_omap) need to do additional work in
bus suspend/resume and interrupt handler to support low power
modes and remote wakeup.
Allow drivers to override these functions through ehci_driver_overrides.
Also export the ehci_irq(), ehci_bus_suspend() and ehci_bus_resume()
functions
Hi,
This series attempts to suspend the OMAP EHCI host controller on USB
Bus suspend. This will cause its parent, the OMAP USB Host Module as well
as the USB TLL Module to be put in suspend and hence allow the USB power domain
to be put in a lower power state. Then we no longer prevent the rest of
Runtime suspend the controller during bus suspend and resume it
during bus resume. This will ensure that the USB Host power domain
enters lower power state and does not prevent the SoC from
endering deeper sleep states.
Remote wakeup will come up as an interrupt while the controller
is suspended,
To ensure hardware context is restored while resuming from
OFF mode we need to enable the Hardware SAR bit for the
USB Host power domain.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/powerdomains3xxx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/a
Add the Idle state pins for USB host and enable WAKEUP on
DIR, DAT0-3, so that the PHY can wakeup the OMAP SoC from
sleep on any USB activity (e.g. remote wakeup or connect/disconnect).
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 29
Hi Joseph,
had a fast look...
[ ... ]
> +static int dm9620_set_eeprom(struct net_device *net,
> + struct ethtool_eeprom *eeprom, u8 *data)
> +{
> + struct usbnet *dev = netdev_priv(net);
> + int offset = eeprom->offset;
> + int len = eeprom->len;
> + int done;
> +
> +
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenari
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scena
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
Hello.
On 19-06-2013 16:12, Manjunath Goudar wrote:
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspe
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON
---
drivers/usb/host/ohci-at91.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/u
DM9620 is an USB2.0 network adapter rather than DM9601 USB1.1. This
driver processed the RX data with 4 bytes header, TX 2 bytes header,
make the control bit exactly right in PHY write operation, and optional
IFF_ALLMULTI bit for RX control.
Tested good for many platforms, include X86 desktop and
This patch adds missing unlocks on error paths in the
xhci_free_streams and xhci_configure_endpoint functions.
Signed-off-by: Emil Goode
---
drivers/usb/host/xhci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6779c92..2c49f00 1
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc
Suspend scenario in case of ohci-platform glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_platform_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Berg
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Be
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in exynos_ohci_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON
---
drivers/usb/gadget/at91_udc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drive
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. This does proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Cc: Alan Stern
Cc: Greg KH
Cc: linux-usb@vger.kernel.org
V3: New patch.
---
drivers/usb/host/ohci-hcd.c |9
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Acked-by: Ala
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arn
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar
Cc: Arnd Bergmann
Suspend scenario in case of ohci bus glue was not properly handled as
it was not suspending generic part of ohci controller. Calling
explicitly the ohci_suspend()routine will ensure proper handling
of suspend scenario.
V2:
-Incase ohci_suspend() fails, return right away without executing further.
On Wed, Jun 19, 2013 at 10:59 AM, Ming Lei wrote:
> On Wed, Jun 19, 2013 at 12:05 AM, Alan Stern
> wrote:
>> On Tue, 18 Jun 2013, Ming Lei wrote:
>>
>>> This patch implements the mechanism of giveback of URB in
>>> tasklet context, so that hardware interrupt handling time for
>>> usb host contro
ATENÇÃO;
Sua caixa de correio excedeu o limite de 5 GB de armazenamento, que é como
definido pelo administrador, você está atualmente em execução no 10.9GB, você
pode não ser capaz de enviar ou receber novas mensagens até que você re-validar
a sua caixa de correio. Para revalidar sua caixa de c
This avoids a build error in at91sam9261_9g10_defconfig:
drivers/usb/gadget/at91_udc.c: In function 'at91udc_probe':
drivers/usb/gadget/at91_udc.c:1685:34: warning: 'flags' may be used
uninitialized in this
function [-Wmaybe-uninitialized]
board->vbus_active_low = (flags & OF_GPIO_ACTIVE_LOW) ?
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON
---
drivers/usb/host/ehci-atmel.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb
--
ATENÇÃO;
Sua caixa de correio excedeu o limite de 5 GB de armazenamento, que é como
definido pelo administrador, você está atualmente em execução no 10.9GB, você
pode não ser capaz de enviar ou receber novas mensagens até que você re-validar
a sua caixa de correio. Para revalidar sua caix
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Tested-by: Tomi Valkeinen
---
arch/arm/mach-omap2/usb-musb.c |6 +-
i
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So
added a new API to get the PHY reference by PHY label (PHY label
should be filled which creating the PHY).
Signed-off
In the case of non-dt boot, the platform specific initialization file
(board file) will do usb_bind_phy that binds the usb controller with the
PHY using device names. After the device names are created using
PLATFORM_DEVID_AUTO, our original method of binding by device names doesn't
work reliably
After the devices are created using PLATFORM_DEVID_AUTO,
devm_usb_get_phy_dev and usb_get_phy_dev can't be used reliably
as it relies on the device_names passed in usb_bind_phy. So used the
new API devm_usb_get_phy_by_name to get the PHY reference.
Signed-off-by: Kishon Vijay Abraham I
Acked-by:
Now that MUSB for OMAP started using devm_usb_get_phy_by_name
which does not require PHY library to already have the binding
information, removed usb_bind_phy calls that binds the MUSB controller
with the PHY from the board files.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Test
Hi Chao,
On 06/19/2013 05:31 AM, Chao Xie wrote:
> Some controller need software to initialize PHY before add
> host controller, and shut down PHY after remove host controller.
> Add the generic code for these controllers so they do not need
> do it in its own host controller driver.
>
> Signed-o
on i386:
drivers/built-in.o: In function `ci_hdrc_probe':
core.c:(.text+0x20446b): undefined reference to `of_usb_get_phy_mode'
Signed-off-by: Peter Chen
---
Changes for v2:
- Using IS_ENABLED to MACRO define
include/linux/usb/of.h | 16 ++--
1 files changed, 10 insertions(+), 6
On 19/06/13 10:12, Jiri Slaby wrote:
> On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
>> On 17/06/13 23:05, Jiri Slaby wrote:
>>
>>> The last point I inclined to the Greg's argument to remove the
>>> EXPERT dependency.
>>>
>>> So currently I have what is attached... Comments?
>>
>> The patch looks a
Hi,
>> There is a mistake in the previous log file, because the fifo size is
>> still set to 512 byte. Now i change it to 64 byte if it is Full speed.
>
> The FIFO size should always be set to the value in the endpoint
> descriptor, no matter what speed the connection is.
>
>> The log file are att
On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
> On 17/06/13 23:05, Jiri Slaby wrote:
>
>> The last point I inclined to the Greg's argument to remove the
>> EXPERT dependency.
>>
>> So currently I have what is attached... Comments?
>
> The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. Yo
On 17/06/13 23:05, Jiri Slaby wrote:
> The last point I inclined to the Greg's argument to remove the EXPERT
> dependency.
>
> So currently I have what is attached... Comments?
The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're not
adding COMPILE_TEST there, but you're adding a to
On Wed, Jun 19, 2013 at 09:25:27AM +0300, Felipe Balbi wrote:
> On Wed, Jun 19, 2013 at 10:11:05AM +0800, Peter Chen wrote:
> > on i386:
> >
> > drivers/built-in.o: In function `ci_hdrc_probe':
> > core.c:(.text+0x20446b): undefined reference to `of_usb_get_phy_mode'
> >
> > Signed-off-by: Peter
92 matches
Mail list logo
