Hi,
Please excuse me but I have missed this question yesterday.
> From: Philippe De Swert
>
> This patch series fixes a number of issues found with coverity in
> libusbg
> A pull request has also be made:
> https://github.com/libusbg/libusbg/pull/4
>
> There is one potential remaing potentia
Hi,
On Tuesday 13 May 2014 11:37 AM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Mon, May 12, 2014 at 6:33 PM, Kishon Vijay Abraham I wrote:
>> Hi Gautam,
>>
>> On Friday 09 May 2014 07:27 PM, Vivek Gautam wrote:
>>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>>> The new driv
Hi,
On 05/12/2014 09:34 PM, Maxime Ripard wrote:
> Move the phy initialization and variables declaration to the loop itself,
> since
> it is where it really belongs. Also remove all the temporary variables, we can
> use the structure members directly.
>
> Signed-off-by: Maxime Ripard
> ---
> d
Hi Alan,
On Mon, May 12, 2014 at 11:19:33PM +0800, Alan Stern wrote:
> On Mon, 12 May 2014, Pratyush Anand wrote:
>
> > OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> > system (SS-OVS) which consists of an excersizer and analyzer.
> >
> > USB Compliance Suite from Lecr
Hi,
On Mon, May 12, 2014 at 10:19 PM, Kamil Debski wrote:
> When the driver is removed s3c_hsotg_phy_disable is called three times
> instead of once. This results in decreasing of the phy reference counter
> below zero and thus consecutive inserts of the module fails.
>
> This patch removes call
Hi Kishon,
On Mon, May 12, 2014 at 6:33 PM, Kishon Vijay Abraham I wrote:
> Hi Gautam,
>
> On Friday 09 May 2014 07:27 PM, Vivek Gautam wrote:
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 contro
Hi,
On Sunday 11 May 2014 11:47 PM, Thomas Petazzoni wrote:
> From: Gregory CLEMENT
>
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers.
>
> This commit adds a
On Tue, May 13, 2014 at 12:33:30AM +, Peter Chen wrote:
>
> >
> > On Sat, May 10, 2014 at 09:57:39PM +0800, Li Jun wrote:
> > > On Sat, May 10, 2014 at 09:18:36PM +0800, Shawn Guo wrote:
> > > > + Robin and David,
> > > >
> > > > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconf
On Tue, May 13, 2014 at 09:10:36AM +0800, Li Jun wrote:
> Firstly, w/o USB_OTG and USB_OTG_FSM, your OTG port will work well as before
> (i.e. it can be host or can be gadget as you want, so it's enough for you if
> connect normal usb device or PC host), I assume you are not wanting more here,
> th
the user should only select it when the board supports HNP and SRP,
it should NOT be selected if the board only supports dual-role
switch through ID pin.
There is a discussion for it:
http://marc.info/?l=linux-arm-kernel&m=139994896101516&w=2
http://marc.info/?l=linux-usb&m=139994881701504&w=2
Si
On Tue, May 13, 2014 at 09:42:48AM +0800, Shawn Guo wrote:
> On Tue, May 13, 2014 at 08:25:18AM +0800, Chen Peter-B29397 wrote:
> >
> > > > >
> > > >
> > > > In your case, you should not set CONFIG_USB_OTG no matter at defconfig
> > > > and at menuconfig.
> > >
> > > Hmm, at least in my testing
> >
> > > > >
> > > >
> > > > In your case, you should not set CONFIG_USB_OTG no matter at
> > > > defconfig and at menuconfig.
> > >
> > > Hmm, at least in my testing (USB mouse/keyboard connected to OTG
> > > port), it works as before even I enable CONFIG_USB_OTG, as long as I
> > > do *not* en
On Tue, May 13, 2014 at 08:25:18AM +0800, Chen Peter-B29397 wrote:
>
> > > >
> > >
> > > In your case, you should not set CONFIG_USB_OTG no matter at defconfig
> > > and at menuconfig.
> >
> > Hmm, at least in my testing (USB mouse/keyboard connected to OTG port),
> > it works as before even I e
Quoting Maxime Ripard (2014-05-12 12:34:27)
> The A31 USB clock slightly differ from its older counterparts, mostly because
> it has a different gate for each PHY, while the older one had a single gate
> for
> all the phy.
>
> Signed-off-by: Maxime Ripard
> Reviewed-by: Hans de Goede
Acked-by:
> > >
> >
> > In your case, you should not set CONFIG_USB_OTG no matter at defconfig
> > and at menuconfig.
>
> Hmm, at least in my testing (USB mouse/keyboard connected to OTG port),
> it works as before even I enable CONFIG_USB_OTG, as long as I do *not*
> enable CONFIG_USB_OTG_FSM.
>
> Since
>
> On Sat, May 10, 2014 at 09:57:39PM +0800, Li Jun wrote:
> > On Sat, May 10, 2014 at 09:18:36PM +0800, Shawn Guo wrote:
> > > + Robin and David,
> > >
> > > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> > > index cb8e991..9081757 100644
> > > --- a/drivers/usb/core/Kconfi
[1.] One line summary of the problem:
[Sony VAIO SVT13136CXS] usb2 port does not work.
[2.] Full description of the problem/report:
My laptop has two usb ports, one 2.0 and the other 3.0. The usb 2.0 port
does nothing. It seems to have power (a mp3 player took charge, but a
cellphone did not) b
On Mon, 12 May 2014, Maxime Ripard wrote:
> From: Boris BREZILLON
>
> On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
> be deasserted for the EHCI block to be usable.
>
> Add support for an optional reset controller that will be deasserted on
> power off and asserted o
The USB clocks of the A31 seems to be parented to the 24MHz oscillator, and
handle the clocks for the USB phys and OHCI devices.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
arch/arm/boot/dts/sun6i-a31.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm
The A31 USB clock slightly differ from its older counterparts, mostly because
it has a different gate for each PHY, while the older one had a single gate for
all the phy.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
drivers/clk/sunxi/clk-sunxi.c | 6 ++
1 file changed, 6 inse
Move the phy initialization and variables declaration to the loop itself, since
it is where it really belongs. Also remove all the temporary variables, we can
use the structure members directly.
Signed-off-by: Maxime Ripard
---
drivers/phy/phy-sun4i-usb.c | 44 ---
The A31 has two ECHI/OHCI controllers, and one OHCI-only phy-less controller.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
arch/arm/boot/dts/sun6i-a31.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dt
From: Boris BREZILLON
The APP4 EVB1 development boards embeds an A31, together with some NAND, one SD
card slot, and one SDIO + UART WiFi and Bluetooth chip, a few I2C buses, USB,
and a LCD display.
Signed-off-by: Boris BREZILLON
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
ar
From: Boris BREZILLON
On the Allwinner's A31 SoC the reset line connected to the EHCI IP has to
be deasserted for the EHCI block to be usable.
Add support for an optional reset controller that will be deasserted on
power off and asserted on power on.
Signed-off-by: Boris BREZILLON
Signed-off-b
The OHCI controllers used in the Allwinner A31 are asserted in reset using a
global reset controller.
Add optional support for such a controller in the OHCI platform driver.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
d
Hi everyone,
This patchset adds support for the USB controllers found in the
Allwinner A31.
While the design is similar to the earlier Allwinner SoCs that are
already supported, a few details here and there change, like the fact
that the PHYs now have one clock per phy, while it used to be only o
The USB phy controller in the A31 differs mostly from the older controllers
because it has a clock dedicated for each phy, while the older ones were having
a single clock for all the phys.
Signed-off-by: Maxime Ripard
Reviewed-by: Hans de Goede
---
drivers/phy/phy-sun4i-usb.c | 33 +
On Mon, 12 May 2014, Dan Williams wrote:
> Fixed. And dropped "wakeup" out of the patch subject.
>
> > There's a nasty bug here. I'll let you figure it out for yourself. :-)
> > Hint: Hiding a variable by declaring another local variable with the
> > same name in an inner block often leads to
On Mon, 2014-05-12 at 10:22 -0400, Alan Stern wrote:
> On Fri, 9 May 2014, Dan Williams wrote:
>
> > Testing looks good. In my objection to this approach I neglected to
> > consider that the port_status_lock now protects us from port_event()
> > usb_port_{suspend_resume} collisions. I have updat
On Sun, May 11, 2014 at 08:17:55PM +0200, Thomas Petazzoni wrote:
> From: Gregory CLEMENT
>
> Some platforms (such as the Armada 38x ones) can gate the clock of
> their USB controller. This patch adds the support for one clock in
> xhci-plat, by enabling it during probe and disabling it on remove
On Mon, May 12, 2014 at 7:22 AM, Alan Stern wrote:
> On Fri, 9 May 2014, Dan Williams wrote:
>
>> Testing looks good. In my objection to this approach I neglected to
>> consider that the port_status_lock now protects us from port_event()
>> usb_port_{suspend_resume} collisions. I have updated th
Dear Mathias Nyman,
On Mon, 12 May 2014 20:24:45 +0300, Mathias Nyman wrote:
> > +int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev)
> > +{
> > + struct resource *res;
> > + void __iomem *base;
> > + const struct mbus_dram_target_info *dram;
>
> Hi
>
> Sparse warns about this:
>
On 05/12/2014 05:46 PM, Gregory CLEMENT wrote:
Hi Mathias, Felipe,
On 11/05/2014 20:17, Thomas Petazzoni wrote:
From: Gregory CLEMENT
Some platforms (such as the Armada 38x ones) can gate the clock of
their USB controller. This patch adds the support for one clock in
xhci-plat, by enabling it
On 05/11/2014 09:17 PM, Thomas Petazzoni wrote:
From: Gregory CLEMENT
This commit extends the compatible string list of the xhci-platform
binding with the new "armada-375-xhci" and "armada-380-xhci"
compatible strings. It is used to describe the XHCI controller which
is available in the Armada
On 05/11/2014 09:17 PM, Thomas Petazzoni wrote:
From: Gregory CLEMENT
The Armada 375 and 38x SoCs come with an XHCI controller that requires
some specific initialization related to the MBus windows
configuration. This patch adds the support for this special
configuration as an XHCI quirk execut
On 05/10/2014 06:00 AM, Vivek Gautam wrote:
> Using devm_ioremap_resource() API should actually be preferred over
> devm_ioremap(), since the former request the mem region first and then
> gives back the ioremap'ed memory pointer.
> devm_ioremap_resource() calls request_mem_region(), therby prevent
Alan Stern writes:
> The biggest bug may not be an obvious one. Suppose the lvstest driver
> has been built into the kernel. When the kernel boots and the root
> hubs are registered, what will prevent them all from binding to lvstest
> instead of the normal hub driver?
I don't know if this
When the driver is removed s3c_hsotg_phy_disable is called three times
instead of once. This results in decreasing of the phy reference counter
below zero and thus consecutive inserts of the module fails.
This patch removes calls to s3c_hsotg_phy_disable from s3c_hsotg_remove
and s3c_hsotg_udc_sto
On Mon, May 12, 2014 at 5:34 PM, Alan Stern wrote:
> On Mon, 12 May 2014, poma wrote:
>
>> >> BTW 3.15.0-0.rc5.git0.1.fc21.x86_64 doesn't have this bug.
>> >
>> > This is a known bug, as you can tell from the fact that it has already
>> > been fixed. (And, as you can tell by looking at the stack
On 12/05/2014 17:46, Alan Stern wrote:
> On Mon, 12 May 2014, Gregory CLEMENT wrote:
>
>> Hi Alan,
>>
>> On 11/05/2014 20:17, Thomas Petazzoni wrote:
>>> This commit updates the Device Tree binding documentation of
>>> ehci-orion to take into account the fact that we can now optionally
>>> pass a
On Mon, 12 May 2014, Gregory CLEMENT wrote:
> Hi Alan,
>
> On 11/05/2014 20:17, Thomas Petazzoni wrote:
> > This commit updates the Device Tree binding documentation of
> > ehci-orion to take into account the fact that we can now optionally
> > pass a clock and a PHY reference.
>
> Would you agr
On Mon, 12 May 2014, poma wrote:
> >> BTW 3.15.0-0.rc5.git0.1.fc21.x86_64 doesn't have this bug.
> >
> > This is a known bug, as you can tell from the fact that it has already
> > been fixed. (And, as you can tell by looking at the stack dump, the
> > bug was in the SCSI layer rather than the
On Mon, 12 May 2014, Pratyush Anand wrote:
> OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> system (SS-OVS) which consists of an excersizer and analyzer.
>
> USB Compliance Suite from Lecroy can act as such SS-OVS for Link Layer
> Validation (LVS).
>
> Some modificati
On Mon, May 12, 2014 at 05:14:26PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Sat, May 10, 2014 at 8:56 PM, Maxime Ripard
> wrote:
> > The USB phy controller in the A31 differs mostly from the older controllers
> > because it has a clock dedicated for each phy, while the older ones were
> > having
Hi Felipe, Kishon,
On 11/05/2014 20:17, Thomas Petazzoni wrote:
> From: Gregory CLEMENT
>
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers.
>
> This commit add
On 12.05.2014 16:02, Alan Stern wrote:
> On Mon, 12 May 2014, poma wrote:
>
>> ...
>>> "initial 64-byte descriptor request timeout"
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/core/hub.c#n67
>>> https://www.kernel.org/doc/Documentation/kernel-parameters.tx
On Sun, May 11, 2014 at 12:12:32AM +, Wilfried Klaebe wrote:
> net: get rid of SET_ETHTOOL_OPS
>
> Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone.
> This does that.
>
> Mostly done via coccinelle script:
> @@
> struct ethtool_ops *ops;
> struct net_device *dev;
> @@
> - SET
Hi Mathias, Felipe,
On 11/05/2014 20:17, Thomas Petazzoni wrote:
> From: Gregory CLEMENT
>
> Some platforms (such as the Armada 38x ones) can gate the clock of
> their USB controller. This patch adds the support for one clock in
> xhci-plat, by enabling it during probe and disabling it on remove
On 05/08/2014 07:21 PM, Dan Williams wrote:
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
On 05/10/2014 12:39 AM, baum...@hotmail.com wrote:
Are there any new patches to test or news regarding "xhci_drop_endpoint"-issue?
Thanks, Bernhard
No, sorry, not at the moment.
At least nothing directly targeted at this.
This doesn't seem to be related to link power management
If you want y
Hi Alan,
On Sat, May 10, 2014 at 10:35:49AM -0400, Alan Stern wrote:
> > @@ -206,6 +208,19 @@ static int ehci_platform_probe(struct platform_device
> > *dev)
> > break;
> > }
> > }
> > +
> > + priv->rst = devm_reset_control_get
Hi Alan,
On 11/05/2014 20:17, Thomas Petazzoni wrote:
> This commit updates the Device Tree binding documentation of
> ehci-orion to take into account the fact that we can now optionally
> pass a clock and a PHY reference.
Would you agree to take this patch with the 4 first ones?
For this kind o
On 11/05/2014 20:17, Thomas Petazzoni wrote:
> Hello,
>
> This patch set adds the USB support for the Armada 38x and Armada 375
> SOCs. These SoCs use an xHCI but still need specific initialization,
> mainly to setup the MBus memory windows. They also have another USB
> controller for EHCI, identi
On Mon, 12 May 2014, Anastasija FEDANE wrote:
> Hi,
>
> I am working on a project to simulate a usb device on a software level
> in Linux environment.
Do you realize that such a simulation already exists in the Linux
kernel?
> Do you know if it is possible to simulate a
> hardware event (such
On Fri, 9 May 2014, Dan Williams wrote:
> Testing looks good. In my objection to this approach I neglected to
> consider that the port_status_lock now protects us from port_event()
> usb_port_{suspend_resume} collisions. I have updated the changelog
> accordingly.
>
> 8<---
> Subject: u
On Fri, 9 May 2014, Dan Williams wrote:
> Updated patch:
>
> 8<--
> Subject: usb: hub_handle_remote_wakeup() depends on CONFIG_PM_RUNTIME=y
>
> From: Dan Williams
>
> Per Alan:
> "You mean from within hub_handle_remote_wakeup()? That routine will
> never get called if CONFIG_PM_RU
On 12 May 10:29 AM, George Cherian wrote:
> On 5/8/2014 10:57 PM, Ezequiel Garcia wrote:
> >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
On Sat, 10 May 2014, Vivek Gautam wrote:
> Based on 'usb-next' branch of Greg's usb tree.
>
> devm_ioremap_resource() API is advantageous over devm_ioremap()
> and should therefore be preferred to request any ioremap'ed address
> for hcd.
>
> Changes from v1:
> - Changed the way returned pointe
On Mon, 12 May 2014, poma wrote:
> ...
> > "initial 64-byte descriptor request timeout"
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/core/hub.c#n67
> > https://www.kernel.org/doc/Documentation/kernel-parameters.txt
> > usbcore.initial_descriptor_timeout=
>
On Mon, May 12, 2014 at 09:22:33AM +0800, Chen Peter-B29397 wrote:
>
> > >
> > > So when the board is OTG & EH (CONFIG_USB_OTG is set), it should have
> > > TPL according to spec. In fact, even the CONFIG_USB_OTG_WHITELIST is
> > > not set, the non-TPL devices have not worked well, eg, it will no
Hi Gautam,
On Friday 09 May 2014 07:27 PM, Vivek Gautam wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
>
> Also, created a new header file in linux
...
> "initial 64-byte descriptor request timeout"
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/usb/core/hub.c#n67
> https://www.kernel.org/doc/Documentation/kernel-parameters.txt
> usbcore.initial_descriptor_timeout=
> & Co.
>
I made several tests concerning th
Hi,
On 05/12/2014 02:24 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 12 May 2014 05:29 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 05/12/2014 11:14 AM, Chen-Yu Tsai wrote:
>>> Hi,
>>>
>>> On Sat, May 10, 2014 at 8:56 PM, Maxime Ripard
>>> wrote:
The USB phy controller in the A31 diffe
Hi,
On Monday 12 May 2014 05:29 PM, Hans de Goede wrote:
> Hi,
>
> On 05/12/2014 11:14 AM, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Sat, May 10, 2014 at 8:56 PM, Maxime Ripard
>> wrote:
>>> The USB phy controller in the A31 differs mostly from the older controllers
>>> because it has a clock dedicate
Hi,
On 05/12/2014 11:14 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Sat, May 10, 2014 at 8:56 PM, Maxime Ripard
> wrote:
>> The USB phy controller in the A31 differs mostly from the older controllers
>> because it has a clock dedicated for each phy, while the older ones were
>> having
>> a single cloc
Hi,
On Sat, May 10, 2014 at 8:56 PM, Maxime Ripard
wrote:
> The USB phy controller in the A31 differs mostly from the older controllers
> because it has a clock dedicated for each phy, while the older ones were
> having
> a single clock for all the phys.
>
> Signed-off-by: Maxime Ripard
> Revie
Hi,
I am working on a project to simulate a usb device on a software level
in Linux environment. Do you know if it is possible to simulate a
hardware event (such as voltage change to emulate the attach/detach
event for usb, for example)?
Maybe there is a better approach? I am a newbie in this kind
67 matches
Mail list logo
