Recent commits introduced the following
Kconfig warning:
warning: (USB_MUSB_HDRC && OMAP_USB3) selects \
OMAP_CONTROL_USB which has unmet direct \
dependencies (USB_SUPPORT && ARCH_OMAP2PLUS)
This patch just fixes it, by removing the
unnecessary OMAP dependency.
Signed-off-by: Fe
Hello Michael,
Michael Leun writes:
> I would vote to not accept that driver for mainline as long as this
> issues are not fixed.
>
> The vendor should not be able to claim "hooray, hooray, great device,
> we even have an driver in linux main line" when it is actually such an
> useless crap.
W
Hi,
>> Problem is that uas is pretty much the only device using streams,
>> so uas will be the one who triggers any stream bugs in xhci.
>> I have no idea how solid xhci streams support is at the moment.
>
> The xHCI streams support isn't well tested, because the UAS devices I
> had were so bug
Hi,
The following page allocation failure triggers sometimes when I plug my
memory card reader on a USB port.
[850845.928795] usb 1-4: new high-speed USB device number 48 using ehci-pci
[850846.300702] usb 1-4: New USB device found, idVendor=0bda, idProduct=0119
[850846.300707] usb 1-4: New USB
From: Sebastian Andrzej Siewior
This patch converts the nokia gadget to make use of the function
framework to request the ACM function.
The "old" include interface for acm is now removed since nokia was the
last user of it (for ACM).
Signed-off-by: Sebastian Andrzej Siewior
[Andrzej Pietrasie
Hi Michael,
On Mon, Jan 28, 2013 at 03:10:05, Michael Grzeschik wrote:
> On Thu, Sep 27, 2012 at 11:15:05AM +0530, Afzal Mohammed wrote:
> > From: "B, Ravi"
> >
> > Added device tree support for nop transceiver driver and updated the
> > Documentation with device tree binding information for am
On 01/27/13 13:54, Vlad Silman wrote:
> Hello,
>
> I have a few questions regarding Linux UAS host-side and device-side drivers.
> I've seen that Linux UAS host driver supports the task management
> commands as defined by T10 UAS spec, such as ABORT TASK and LOGICAL
> UNIT RESET.
> I'm trying to w
Moving register and structure definitions to header file,
and keeping the generic functions to be used across
multiple PHYs in common file "samsung-usbphy.c".
Also renaming the usb 2.0 phy driver to "samsung-usb2.c"
Signed-off-by: Vivek Gautam
---
Changes from v3:
- Using separate config SAMSUN
Adding PHY driver support for USB 3.0 controller for Samsung's
SoCs.
Signed-off-by: Vivek Gautam
---
Changes from v3:
- Making SAMSUNG_USB3PHY dependent on SAMSUNG_USBPHY.
- Adding USB_DWC3 to dependencies of SAMSUNG_USB2PHY since
dwc3 controller also looks for USB2 type PHY.
drivers/usb/
Use resource managed kzalloc.
Signed-off-by: Roger Quadros
---
drivers/usb/otg/nop-usb-xceiv.c | 16
1 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index a3ce24b..7ffb0c8 100644
--- a/drivers/us
Hi,
The OMAP's High Speed Host controller can interface to ULPI/UTMI
PHYs transparently i.e. whithout requiring the device drivers to
access the PHY. However, the OS must ensure that the PHY has the necessary
resources (power/clock/reset) enabled before it is used.
Till now, the omap-ehci driver
If the PHY has a clock associated to it then manage the clock.
We just enable the clock in .init() and disable it in .shutdown().
Add clk_rate parameter in platform data and configure the
clock rate during probe if supplied.
Signed-off-by: Roger Quadros
---
drivers/usb/otg/nop-usb-xceiv.c |
Add platform device and data for 'nop-usb-xceiv'. This will be used
as PHY for HS USB port 1, so provide binding information for it.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Ports 1 and 2, so provide binding information for them.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link it
to the respective 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-zoom.c | 56 ++
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-devkit8000.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3stalker.c |
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3pandora.c |
All users have been adapted to the changes in ehci-omap. We can now
get rid of the unused fields from usbhs_omap_platform_data.
Signed-off-by: Roger Quadros
---
include/linux/platform_data/usb-omap.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/linux/platfor
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-overo.c | 55 +
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET for HS USB Port 2 as GPIO fixed regulator and link
it to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3evm.c | 6
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Port 1 and 2, so provide binding information for them.
Model RESET for HS USB Port 1 as GPIO fixed regulator and link it
to the 'nop-usb-xceiv' PHY on port 1.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Model RESET and Power for HS USB Port 2 as GPIO fixed regulators
and link them to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-oma
For each port that is in PHY mode we obtain a PHY device using the USB PHY
library and put it out of suspend.
It is upto platform code to associate the PHY to the controller's
port and it is upto the PHY driver to manage the PHY's resources.
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehc
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Model RESET and Power for HS USB Port 1 as GPIO fixed regulators
and link them to the 'nop-usb-xceiv' PHY.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-am3
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Model RESET for HS USB Ports 1 and 2 as GPIO fixed regulators and
link them to the 2 PHYs we just created.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap
Model RESET and Power for HS USB Port 1 as GPIO fixed regulators
and link them to the 'nop-usb-xceiv' PHY by making them as "reset"
and "vcc" supplies.
The RESET and Power will then be managed by the PHY driver.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap4panda.c | 93
This patch-series enables runtime power management on xhci-plat,
dwc3-core, dwc3-exynos as well as on samsung-usb3 type PHY.
This allows usb 3.0 host ports to be power managed at runtime.
We also turn off the PHY ref_clk PLL, which supplies reference clock
to USB3 type phy, when ports are not in us
PHY regulator handling must be done in the PHY driver
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c | 34 --
1 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 3c63619
By enabling runtime pm in this driver is allows users of xhci-plat to
enter into runtime pm. This is not full runtime pm support (AKA
xhci-plat doesn't actually power anything off when in runtime suspend
mode) but just basic enablement.
Signed-off-by: Vivek Gautam
Signed-off-by: Doug Anderson
-
Make use of devm_request_and_ioremap() and correct comment.
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 30fc482..fd2f545
The current code in the dwc3 probe effectively disables runtime pm
from ever working because it calls a get() that was never put() until
device removal. Change the runtime pm code to match the standard
formula and allow runtime pm to function.
Note that this doesn't enable full runtime pm on the
PHY reset GPIO handling will be done in the PHY driver
Signed-off-by: Roger Quadros
Acked-by: Samuel Ortiz
---
drivers/mfd/omap-usb-host.c | 47 ---
1 files changed, 0 insertions(+), 47 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mf
EHCI driver would need to know the number of ports available
on the platform. We set the nports parameter of platform_data
based on IP version if it was not already provided.
Signed-off-by: Roger Quadros
Acked-by: Samuel Ortiz
---
drivers/mfd/omap-usb-host.c |1 +
1 files changed, 1 inserti
We expect the RESET line to be modeled as a regulator with supply
name "reset". The regulator should be modeled such that enabling
the regulator brings the PHY device out of RESET and disabling the
regulator holds the device in RESET.
They PHY will be held in RESET in .shutdown() and brought out o
Enabling runtime power management on dwc3-exynos to save
power and allow its PHY's power to be managed at runtime.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 47
1 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drive
We use "vcc" as the supply name for the PHY's power supply.
The power supply will be enabled during .init() and disabled
during .shutdown()
Signed-off-by: Roger Quadros
---
drivers/usb/otg/nop-usb-xceiv.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/
We would need to support multiple PHYs of the same type
so use the new PHY API usb_add_phy_dev() to register the PHY.
Signed-off-by: Roger Quadros
---
drivers/usb/otg/nop-usb-xceiv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/driv
Enabling runtime power management support on samsung-usb3 phy
and further adding support to turn off the PHY ref_clk PLL.
It thereby requires PHY ref_clk to be switched between internal
core clock and external PLL clock.
Signed-off-by: Vivek Gautam
---
drivers/usb/phy/samsung-usb3.c | 107 +++
From: Alan Stern
This patch (as1645) converts ehci-omap over to the new "ehci-hcd is a
library" approach, so that it can coexist peacefully with other EHCI
platform drivers and can make use of the private area allocated at
the end of struct ehci_hcd.
Signed-off-by: Alan Stern
---
drivers/usb/h
Reset GPIO handling for the PHY must be done in the PHY
driver. We use the PHY helpers instead to reset the PHY.
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c | 70 +
1 files changed, 9 insertions(+), 61 deletions(-)
diff --git a/drivers
On Mon, Jan 28, 2013 at 05:12:26PM +0530, Vivek Gautam wrote:
> The current code in the dwc3 probe effectively disables runtime pm
> from ever working because it calls a get() that was never put() until
> device removal. Change the runtime pm code to match the standard
> formula and allow runtime
On Mon, Jan 28, 2013 at 05:12:27PM +0530, Vivek Gautam wrote:
> Enabling runtime power management on dwc3-exynos to save
> power and allow its PHY's power to be managed at runtime.
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/dwc3/dwc3-exynos.c | 47
> ++
Hi Balbi,
On Mon, Jan 28, 2013 at 5:17 PM, Felipe Balbi wrote:
> On Mon, Jan 28, 2013 at 05:12:27PM +0530, Vivek Gautam wrote:
>> Enabling runtime power management on dwc3-exynos to save
>> power and allow its PHY's power to be managed at runtime.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> dr
Hi,
On Mon, Jan 28, 2013 at 05:12:28PM +0530, Vivek Gautam wrote:
> Enabling runtime power management support on samsung-usb3 phy
> and further adding support to turn off the PHY ref_clk PLL.
> It thereby requires PHY ref_clk to be switched between internal
> core clock and external PLL clock.
>
Hi,
On Mon, Jan 28, 2013 at 05:28:30PM +0530, Vivek Gautam wrote:
> >> +static int dwc3_exynos_runtime_resume(struct device *dev)
> >> +{
> >> + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
> >> + struct platform_device *pdev_dwc = exynos->dwc3;
> >> + struct dwc3
On Mon, Jan 28, 2013 at 5:42 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 28, 2013 at 05:28:30PM +0530, Vivek Gautam wrote:
>> >> +static int dwc3_exynos_runtime_resume(struct device *dev)
>> >> +{
>> >> + struct dwc3_exynos *exynos = dev_get_drvdata(dev);
>> >> + struct platform_dev
On Mon, Jan 28, 2013 at 05:57:04PM +0530, Vivek Gautam wrote:
> On Mon, Jan 28, 2013 at 5:42 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 28, 2013 at 05:28:30PM +0530, Vivek Gautam wrote:
> >> >> +static int dwc3_exynos_runtime_resume(struct device *dev)
> >> >> +{
> >> >> + struct dwc3
Hello,
In drivers/usb/core/hcd.c: usb_hcd_flush_endpoint() uses
list_for_each_entry() to unlink URBs pending on
endpoint. At the same time unlink1() calls usb_rh_urb_dequeue()
where URB is removed from its endpoint queue:
void usb_hcd_unlink_urb_from_ep(struct usb_hcd *hcd, struct urb *urb)
{
Hi Felipe,
On Mon, Jan 28, 2013 at 5:39 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 28, 2013 at 05:12:28PM +0530, Vivek Gautam wrote:
>> Enabling runtime power management support on samsung-usb3 phy
>> and further adding support to turn off the PHY ref_clk PLL.
>> It thereby requires PHY ref_c
Hi,
On Mon, Jan 28, 2013 at 06:34:15PM +0530, Vivek Gautam wrote:
> >> @@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
> >> samsung_usbphy *sphy)
> >> return reg;
> >> }
> >>
> >> -static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
> >> +/*
> >> + * Se
Hi Felipe,
On Mon, Jan 28, 2013 at 6:37 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 28, 2013 at 06:34:15PM +0530, Vivek Gautam wrote:
>> >> @@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
>> >> samsung_usbphy *sphy)
>> >> return reg;
>> >> }
>> >>
>> >> -static int sam
On Mon, Jan 28, 2013 at 06:54:42PM +0530, Vivek Gautam wrote:
> Hi Felipe,
>
>
> On Mon, Jan 28, 2013 at 6:37 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 28, 2013 at 06:34:15PM +0530, Vivek Gautam wrote:
> >> >> @@ -65,7 +67,22 @@ static u32 samsung_usb3_phy_set_refclk(struct
> >> >> sa
Hi Felipe,
On Mon, Jan 28, 2013 at 5:15 PM, Felipe Balbi wrote:
> On Mon, Jan 28, 2013 at 05:12:26PM +0530, Vivek Gautam wrote:
>> The current code in the dwc3 probe effectively disables runtime pm
>> from ever working because it calls a get() that was never put() until
>> device removal. Chang
> I would vote to not accept that driver for mainline as long as this
> issues are not fixed.
Michael, could you give me more information about how do you test this driver?
I have tried to reproduce the issue by using "ifconfig ethX mtu 1500", but I
didn't confront the same issue.
Thank you in
"Freddy" writes:
> Bjørn, I am trying to reproduce the issue mentioned by Michael and I
> have a question about submitting this driver.
>
> Should I merge this driver into asix_devices.c and asix_common.c even
> through the usb command, tx_fixup, and rx_fixup functions are totally
> different?
T
On Mon, Jan 28, 2013 at 10:20:47AM +0200, Felipe Balbi wrote:
> Recent commits introduced the following
> Kconfig warning:
>
> warning: (USB_MUSB_HDRC && OMAP_USB3) selects \
> OMAP_CONTROL_USB which has unmet direct \
> dependencies (USB_SUPPORT && ARCH_OMAP2PLUS)
>
> This patch just
Hi,
On Mon, Jan 28, 2013 at 06:41:54AM -0800, Greg KH wrote:
> On Mon, Jan 28, 2013 at 10:20:47AM +0200, Felipe Balbi wrote:
> > Recent commits introduced the following
> > Kconfig warning:
> >
> > warning: (USB_MUSB_HDRC && OMAP_USB3) selects \
> > OMAP_CONTROL_USB which has unmet direct \
>
On Mon, 28 Jan 2013, Roger Quadros wrote:
> Make use of devm_request_and_ioremap() and correct comment.
Didn't a big patch come through recently converting all usages of
devm_request_and_ioremap() to another function (I forget the name) that
does its own error reporting and returns an ERR_PTR v
On Mon, Jan 28, 2013 at 10:17:33AM -0500, Alan Stern wrote:
> On Mon, 28 Jan 2013, Roger Quadros wrote:
>
> > Make use of devm_request_and_ioremap() and correct comment.
>
> Didn't a big patch come through recently converting all usages of
> devm_request_and_ioremap() to another function (I forg
On Mon, 28 Jan 2013, Anton Tikhomirov wrote:
> Hello,
>
> In drivers/usb/core/hcd.c: usb_hcd_flush_endpoint() uses
> list_for_each_entry() to unlink URBs pending on
> endpoint. At the same time unlink1() calls usb_rh_urb_dequeue()
> where URB is removed from its endpoint queue:
>
> void usb_hcd_
Hi folks,
we have generic implementations for a reason, right ?
This patchset converts a few more of the UDC drivers to
use the generic usb_gadget_map/unmap_request() calls.
After this series, only the following UDC drivers are
offending:
drivers/usb/gadget/fsl_qe_udc.c
drivers/usb/gadget/mv_u3
we have generic implementations for a reason,
let's use them.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/s3c-hsotg.c | 46 +-
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hso
that member isn't used anywhere in the driver
and be removed with no mercy.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/amd5536udc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/gadget/amd5536udc.h b/drivers/usb/gadget/amd5536udc.h
index f1bf32e..6744d3b 100644
--- a/dri
we have generic implementations for a reason,
let's use them.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/atmel_usba_udc.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/gadget/atmel_usba_udc.c
b/drivers/usb/gadget/atmel_usba_
we have generic implementations for a reason,
let's use them
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/fsl_udc_core.c | 51 ++-
1 file changed, 13 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl
we have generic implementations for a reason,
let's use them
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/fusb300_udc.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/fusb300_udc.c b/drivers/usb/gadget/fusb300_udc.c
index bf51625..
we have generic implementations for a reason,
let's use them
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/lpc32xx_udc.c | 39 ---
1 file changed, 4 insertions(+), 35 deletions(-)
diff --git a/drivers/usb/gadget/lpc32xx_udc.c b/drivers/usb/gadget/lpc32xx
we have generic implementations for a reason,
let's use them
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/mv_udc_core.c | 53 +---
1 file changed, 6 insertions(+), 47 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc
we have generic implementations for a reason,
let's use them
Signed-off-by: Felipe Balbi
---
drivers/usb/musb/musb_gadget.c | 158 ++---
1 file changed, 53 insertions(+), 105 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gad
On Mon, 28 Jan 2013, Roger Quadros wrote:
> For each port that is in PHY mode we obtain a PHY device using the USB PHY
> library and put it out of suspend.
>
> It is upto platform code to associate the PHY to the controller's
> port and it is upto the PHY driver to manage the PHY's resources.
"u
Add VID and PID for Telit Gobi QDL device
Signed-off-by: Daniele Palmas
---
drivers/usb/serial/qcserial.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index aa148c2..2466254 100644
--- a/drivers/usb/serial/
From: danielepa
Add PID and special handling for Telit LE920
Signed-off-by: Daniele Palmas
---
drivers/usb/serial/option.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 0d9dac9..384bb92 100644
---
Add VID, PID and fixed interface for Telit LE920
Signed-off-by: Daniele Palmas
---
drivers/net/usb/qmi_wwan.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 6a1ca50..e32f9a1 100644
--- a/drivers/net/usb/qmi_w
On 01/28/2013 05:40 PM, Alan Stern wrote:
> On Mon, 28 Jan 2013, Roger Quadros wrote:
>
>> For each port that is in PHY mode we obtain a PHY device using the USB PHY
>> library and put it out of suspend.
>>
>> It is upto platform code to associate the PHY to the controller's
>> port and it is upto
On Mon, 28 Jan 2013 21:36:20 +0800
"Freddy" wrote:
> > I would vote to not accept that driver for mainline as long as this
> > issues are not fixed.
>
>
> Michael, could you give me more information about how do you test
> this driver? I have tried to reproduce the issue by using "ifconfig
> e
Daniele Palmas writes:
> Add VID, PID and fixed interface for Telit LE920
>
> Signed-off-by: Daniele Palmas
> ---
> drivers/net/usb/qmi_wwan.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 6a1ca50..e
This reverts commit 88bb965ed711e8a5984e70208ebc901a6ff4141f.
The linux-next branch of linux-pm tree has replaced
acpi_power_resource_(un)register_device() with new routines.
Commit 88bb965 will cause conflict in the linux-next tree.
So revert it and this will not affect other functions. Will
send
On Mon, 28 Jan 2013, Roger Quadros wrote:
> Reset GPIO handling for the PHY must be done in the PHY
> driver. We use the PHY helpers instead to reset the PHY.
>
> Signed-off-by: Roger Quadros
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the b
On Mon, 28 Jan 2013, Roger Quadros wrote:
> PHY regulator handling must be done in the PHY driver
>
> Signed-off-by: Roger Quadros
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 01/24/2013 03:27 AM, Venu Byravarasu wrote:
> As pointer to PHY structure can be stored in struct usb_hcd
> making use of it, to call Tegra PHY APIs.
>
> Call to usb_phy_shutdown() is moved up in tegra_ehci_remove(),
> so that to avoid dereferencing of hcd after its freed up.
I have applied th
Knowledge of the clock setup delay should remain at the clock level (so
it can be clock specific and CPU specific). Add the 100 milliseconds
required clock delay for the USB host clock when it gets enabled.
Signed-off-by: Florian Fainelli
---
arch/mips/bcm63xx/clk.c |5 +
1 file changed,
This patch adds the required 10 micro seconds delay to the USB device
clock enable operation. Put this where the correct clock knowledege is,
which is in the clock code, and remove this delay from the bcm63xx_udc
gadget driver where it was before.
Signed-off-by: Florian Fainelli
---
arch/mips/bc
This patch moves the code touching the USB private register in the
bcm63xx USB gadget driver to arch/mips/bcm63xx/usb-common.c in
preparation for adding support for OHCI and EHCI host controllers which
will also touch the USB private register.
Signed-off-by: Florian Fainelli
---
arch/mips/bcm63x
BCM63XX-based board can control the registration of the EHCI controller
by setting their has_ehci0 flag to 1. Handle this in the generic
code dealing with board registration and call the actual helper to register
the EHCI controller.
Signed-off-by: Florian Fainelli
---
arch/mips/bcm63xx/boards/b
This configuration symbol can be used by CPUs supporting the on-chip
OHCI controller, and ensures that all relevant OHCI-related
configuration options are correctly selected. So far, OHCI support is
available for the 6328, 6348, 6358 and 6358 SoCs.
Signed-off-by: Florian Fainelli
---
arch/mips/b
This patch updates the common USB code touching the USB private
registers with the specific bits to properly enable OHCI and EHCI
controllers on BCM63xx SoCs. As a result we now need to protect access
to Read Modify Write sequences using a spinlock because we cannot
guarantee that any of the expose
This patch sets the ignore_oc flag for the BCM63XX EHCI controller as it
does not support proper overcurrent reporting.
Signed-off-by: Florian Fainelli
---
arch/mips/bcm63xx/dev-usb-ehci.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/bcm63xx/dev-usb-ehci.c b/arch/mips/bcm63xx
Broadcom BCM63XX SoCs include an on-chip EHCI controller which can be
driven by the generic ehci-platform driver by using specific power
on/off/suspend callbacks to manage clocks and hardware specific
configuration.
Signed-off-by: Maxime Bizon
Signed-off-by: Florian Fainelli
---
arch/mips/bcm63
This patch updates the BCM63XX defconfig with the USB OHCI and EHCI host
drivers as well as the USB gadget driver.
Signed-off-by: Florian Fainelli
---
arch/mips/configs/bcm63xx_defconfig | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/mips/confi
BCM63XX-based boards can control the registration of the OHCI controller
by setting their has_ohci0 flag to 1. Handle this in the generic
code dealing with board registration and call the actual helper to
register the OHCI controller.
Signed-off-by: Florian Fainelli
---
arch/mips/bcm63xx/boards/
Broadcom BCM63XX SoCs include an on-chip OHCI controller which can be
driven by the ohci-platform generic driver by using specific power
on/off/suspend callback to manage clocks and hardware specific
configuration.
Signed-off-by: Maxime Bizon
Signed-off-by: Florian Fainelli
---
arch/mips/bcm63x
This patch adds an ignore_oc flag which can be set by EHCI controller
not supporting or wanting to disable overcurrent checking. The EHCI
platform data in include/linux/usb/ehci_pdriver.h is also augmented to
take advantage of this new flag.
Signed-off-by: Florian Fainelli
---
drivers/usb/host/e
Hi all,
This patch series adds support for the Broadcom BCM63xx OHCI and EHCI
integrated controllers. Thanks to the latest developments of the OHCI and
EHCI platform drivers we no longer need a dedicated ohci or ehci driver
stub and can use the generic platform drivers instead.
This serie was ini
This configuration symbol can be used by CPUs supporting the on-chip
EHCI controller, and ensures that all relevant EHCI-related
configuration options are selected. So far BCM6328, BCM6358 and BCM6368
have an EHCI controller and do select this symbol. Update
drivers/usb/host/Kconfig with BCM63XX to
On 01/28/2013 11:06 AM, Florian Fainelli wrote:
This configuration symbol can be used by CPUs supporting the on-chip
EHCI controller, and ensures that all relevant EHCI-related
configuration options are selected. So far BCM6328, BCM6358 and BCM6368
have an EHCI controller and do select this symbo
1 - 100 of 116 matches
Mail list logo
