> On 15.01.2013 23:05, "Bernd Krumböck" wrote:
>
>>> [ 960.047130] usb_8dev 2-1.4:1.0 can2: Unknown status/error message
>>> (0)
>>> [ 976.544343] usb_8dev 2-1.4:1.0 can2: Unknown status/error message
>>> (0)
>>>
>>> Did you check these kind of 'unfriendly user' tests?
>>
>> Not really. At least
Hi Vivek,
Same comment as for patch 2.
Best regards,
Tomasz
On Wednesday 16 of January 2013 11:15:43 Vivek Gautam wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by:
Hi Vivek,
Same comment as for patch 2.
Best regards,
Tomasz
On Tuesday 15 of January 2013 19:08:32 Vivek Gautam wrote:
> Adding DWC3 device tree node for Exynos5250 needed to
> parse device tree data.
> Also enabling XHCI support on exynos5250.
>
> Signed-off-by: Vivek Gautam
> ---
> .../devi
Hi Vivek,
Don't you need also some clkdev lookup entry to make the clock available
in the driver?
Best regards,
Tomasz
On Tuesday 15 of January 2013 19:08:31 Vivek Gautam wrote:
> Adding necessary device clock to exynos5 needed for
> the DWC3 controller.
>
> Signed-off-by: Vivek Gautam
> ---
Hi Vivek,
On Tuesday 15 of January 2013 19:08:30 Vivek Gautam wrote:
> Adding OHCI device tree node for Exynos5250 along with
> the device base address.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by: Grant Likely
> ---
> .../devicetree/bindings/usb/exynos-usb.txt |
On Wed, Jan 16, 2013 at 11:31:32AM +0530, kishon wrote:
> Hi Ravi,
>
> On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote:
> >>Hi,
> >>
> >>On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
> >>>Hi Arnd,
> >>>
> >>>On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
> On Tuesday 15
Hi,
On Tue, Jan 15, 2013 at 11:04:51AM -0700, Stephen Warren wrote:
> On 01/15/2013 03:19 AM, Venu Byravarasu wrote:
> > As tegra_usb_phy_clk_disable/enable() are not being
> > used, removing them.
>
> Greg, Felipe,
>
> Again if I may, I'll take this through the Tegra tree. I think the next
> se
On 15.01.2013 23:05, "Bernd Krumböck" wrote:
>> [ 960.047130] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)
>> [ 976.544343] usb_8dev 2-1.4:1.0 can2: Unknown status/error message (0)
>>
>> Did you check these kind of 'unfriendly user' tests?
>
> Not really. At least I don't know wha
Hi Ravi,
On Tuesday 15 January 2013 09:36 PM, B, Ravi wrote:
Hi,
On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
Hi Arnd,
On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of contro
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Acked-by: Grant Likely
---
Changes from v4:
- Added gpio line for VBUS of USB2.0 on snow board.
.../devicetree/bindings/usb/exynos-usb.txt
On Tue, Jan 15, 2013 at 7:08 PM, Vivek Gautam wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> Acked-by: Grant Likely
> ---
> .../devicetree/bindings/usb/exynos-usb.txt
Hi Jiri,
On 2013/01/16 01:02, Jiri Kosina wrote:
On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mou
Alan Stern wrote:
On Sat, 12 Jan 2013, Andreas Mohr wrote:
There's of course the EHCI vs. UHCI(/OHCI) duality
(EHCI host controller responsible for high speed transfers,
the other for 1.1 full speed, both serving the same port connectors).
So if the coordination between the two is a problem,
yo
Tejun Heo writes:
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3058,8 +3064,25 @@ static int do_init_module(struct module
> blocking_notifier_call_chain(&module_notify_list,
>MODULE_STATE_LIVE, mod);
>
> - /* We need to finish all async code
On Tue, Jan 15, 2013 at 7:05 PM, Ming Lei wrote:
>
> So looks only sd.c and floppy.c are to be synchronized suppose
> some sync interfaces are introduced, doesn't it?
What about ata_host_register() (usually called through ata_host_activate())?
I don't understand why you continue to push for some
On Tue, 15 Jan 2013, Tejun Heo wrote:
> Hello, Arjan.
>
> On Tue, Jan 15, 2013 at 04:25:54PM -0800, Arjan van de Ven wrote:
> > async fundamentally had the concept of a monotonic increasing number,
> > and that you could always wait for "everyone before me".
> > then people (like me) wanted excep
On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo wrote:
> Hello, Linus.
>
> On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
>> That said, maybe we could just make the rule be that you can't pick a
>> default IO scheduler that is modular.
>
> This is definitely much more preferable but it
On Wed, Jan 16, 2013 at 10:52 AM, Tejun Heo wrote:
> If the default iosched is built as module, the kernel may deadlock
> while trying to load the iosched module on device probe if the probing
> was running off async. This is because async_synchronize_full() at
> the end of module init ends up wa
Hello, Linus.
On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
> That said, maybe we could just make the rule be that you can't pick a
> default IO scheduler that is modular.
This is definitely much more preferable but it would affect use case
where everything is built modular and
On Wed, Jan 16, 2013 at 1:36 AM, Linus Torvalds
wrote:
>
> Because it's not just sd.c that uses async_schedule(), and would need
> the async synchronize. It's floppy.c, it's generic scsi scanning (so
> scsi tapes etc), and it's libata-core.c.
As discussed previously, only the module which will po
On Tue, Jan 15, 2013 at 6:52 PM, Tejun Heo wrote:
>
> It makes me feel dirty but makes the problem go away and I can't think
> of anything better, so here is the implementation of "used async"
> workaround.
Ok, people, can we get a tested-by (or "Nope, doesn't work") from the
people who saw this?
If the default iosched is built as module, the kernel may deadlock
while trying to load the iosched module on device probe if the probing
was running off async. This is because async_synchronize_full() at
the end of module init ends up waiting for the async job which
initiated the module loading.
On Wed, Jan 16, 2013 at 09:48:57AM +0800, Shawn Guo wrote:
> On Wed, Jan 16, 2013 at 09:18:46AM +0800, Peter Chen wrote:
> > On Tue, Jan 15, 2013 at 07:33:16PM +0800, Shawn Guo wrote:
> > > On Tue, Jan 15, 2013 at 02:08:34PM +0800, Peter Chen wrote:
> > > > For mxs-phy user i.mx6q, the PHY's clock
On Wed, Jan 16, 2013 at 09:18:46AM +0800, Peter Chen wrote:
> On Tue, Jan 15, 2013 at 07:33:16PM +0800, Shawn Guo wrote:
> > On Tue, Jan 15, 2013 at 02:08:34PM +0800, Peter Chen wrote:
> > > For mxs-phy user i.mx6q, the PHY's clock is controlled by
> > > hardware automatically, the software only ne
On Tue, Jan 15, 2013 at 10:03:46PM +0800, Shawn Guo wrote:
> On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> > As mach/hardware.h is deleted, we need to use platform_device_id to
> > differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
> > already used pdata to differenti
Martin Mokrejs wrote:
> Alan Stern wrote:
>> On Sun, 13 Jan 2013, Martin Mokrejs wrote:
>>
Don't worry about what kmemleak says when the drives are plugged in.
See what it says when all the USB drives are unplugged. That's what
matters.
>>>
>>> Now it is the only one drive connec
Alan Stern wrote:
> On Sun, 13 Jan 2013, Martin Mokrejs wrote:
>
>>> Don't worry about what kmemleak says when the drives are plugged in.
>>> See what it says when all the USB drives are unplugged. That's what
>>> matters.
>>
>> Now it is the only one drive connected. If I disconnect it kmemle
On Tue, Jan 15, 2013 at 07:33:16PM +0800, Shawn Guo wrote:
> On Tue, Jan 15, 2013 at 02:08:34PM +0800, Peter Chen wrote:
> > For mxs-phy user i.mx6q, the PHY's clock is controlled by
> > hardware automatically, the software only needs to enable it
> > at probe, disable it at remove. During the runt
On Wed, Jan 16, 2013 at 12:37:43AM +, Tilman wrote:
>
> Greg KH writes:
> > > Btw. are there repositories that would be suitable to make
> > > highly experimental
> > > code available ?
> >
> > Yes, that is what drivers/staging/ is for, why not submit your driver
> > for inclusion there?
>
On Tue, Jan 15, 2013 at 04:36:34PM -0800, Linus Torvalds wrote:
> The thing is, the module loading in particular is not necessarily
> happening in the same context as what *started* the module loading. A
> module loader will request the module from user space, and then later
> user space - through
On Tue, Jan 15, 2013 at 4:36 PM, Linus Torvalds
wrote:
>
> There's a reason I asked for a warning for this. Or the "let's flag
> the current thread if it ever started anything asynchronous". Because
> it's complicated.
Btw, the sequence counter (that is *not* taking anything else into
account) is
Greg KH writes:
> > Btw. are there repositories that would be suitable to make
> > highly experimental
> > code available ?
>
> Yes, that is what drivers/staging/ is for, why not submit your driver
> for inclusion there?
The driver is not even close from being finished...
> Ugh, the whitehea
On Tue, Jan 15, 2013 at 3:50 PM, Tejun Heo wrote:
>
> For now, I'm gonna implement simple "I'm not gonna wait for myself"
> self-deadlock avoidance.
You can't really do that. Or rather, it won't *help*.
The thing is, the module loading in particular is not necessarily
happening in the same conte
Hello, Arjan.
On Tue, Jan 15, 2013 at 04:25:54PM -0800, Arjan van de Ven wrote:
> async fundamentally had the concept of a monotonic increasing number,
> and that you could always wait for "everyone before me".
> then people (like me) wanted exceptions to what "everyone" means ;-(
> I'm ok with go
For now, I'm gonna implement simple "I'm not gonna wait for myself"
self-deadlock avoidance. If this needs any more sophistication, I
think we better reimplement it so that we can explicitly match up and
track who's gonna wait for what instead of throwing everything into a
single cookie space a
Hi,
On Tue, Jan 15, 2013 at 6:54 PM, Ezequiel Garcia
wrote:
> Cc: Lior Amsalem
> Cc: Thomas Petazzoni
> Cc: Gregory CLEMENT
> Signed-off-by: Ezequiel Garcia
> ---
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> dif
cc'ing Arjan. Arjan, the original thread can be read from
http://thread.gmane.org/gmane.linux.kernel/1420814
Hello, again.
On Tue, Jan 15, 2013 at 12:18:01PM -0800, Linus Torvalds wrote:
> I think that is a good solution if it works, but look out: we need to
> synchronize across *all* domains
Hello, Linus
Will continue on another reply but this one is relevant so...
On Tue, Jan 15, 2013 at 10:18:45AM -0800, Linus Torvalds wrote:
> Tejun, is there a good way for code to see "I'm running in async
> context"? Then we could do something like
Almost. With a bit of modification we can ask
Florian,
On 01/15/2013 04:54 PM, Florian Fainelli wrote:
> On Tuesday 15 January 2013 06:59:57 Ezequiel Garcia wrote:
>> Hi,
>>
>> This small patch set enables USB support on Armada 370 and Armada XP
>> platforms.
>> It's based on Jason Cooper's mvebu/dt branch.
>>
>> Any comments or feedback are
Hi Oliver!
> Hi Bernd,
>
> On 16.12.2012 08:01, Bernd Krumboeck wrote:
>
>> Add device driver for USB2CAN interface from "8 devices"
>> (http://www.8devices.com).
>>
>> changes since v8:
>> * remove all sysfs files
>>
>> changes since v7:
>> * add sysfs documentation
>> * fix minor styling issue
>
On 01/15/2013 09:30 PM, Oliver Hartkopp wrote:
> On 15.01.2013 21:23, Marc Kleine-Budde wrote:
>
>> On 01/14/2013 09:59 PM, Oliver Hartkopp wrote:
>
>
>>
>> What do you suggest? Add the driver or fix the errors first?
>
>
> Hm.
>
> We're currently at 3.8-rc3 - so waiting for reactions from Be
On 15.01.2013 21:23, Marc Kleine-Budde wrote:
> On 01/14/2013 09:59 PM, Oliver Hartkopp wrote:
>
> What do you suggest? Add the driver or fix the errors first?
Hm.
We're currently at 3.8-rc3 - so waiting for reactions from Bernd makes more
sense to me.
That's better than sending a pull requ
On Wed, 2013-01-09 at 19:27 +, Karl Relton wrote:
> On coming out of suspend my usb bluetooth adaptor is being reset by the
> system.
>
> In linux 3.7 the usb devices are being removed from the sysfs tree
> first, and then the various 'child' devices (like my bluetooth mouse &
> keyboard relat
On 01/14/2013 09:59 PM, Oliver Hartkopp wrote:
> Hi Bernd,
>
> On 16.12.2012 08:01, Bernd Krumboeck wrote:
>
>> Add device driver for USB2CAN interface from "8 devices"
>> (http://www.8devices.com).
>>
>> changes since v8:
>> * remove all sysfs files
>>
>> changes since v7:
>> * add sysfs docume
On Tue, Jan 15, 2013 at 10:32 AM, Tejun Heo wrote:
>
> I think the root problem here, apart from request_module() from block
> - which is a bit nasty but making that part completely async would too
> be quite nasty albeit in a different way - is that
> async_synchronize_full() is way too indescrim
Hello Ezequiel,
On Tuesday 15 January 2013 06:59:57 Ezequiel Garcia wrote:
> Hi,
>
> This small patch set enables USB support on Armada 370 and Armada XP
> platforms.
> It's based on Jason Cooper's mvebu/dt branch.
>
> Any comments or feedback are welcome.
I successfully tested this serie on a
stl wrote:
> I am at the moment working on a uClinux 2.6.19.
Don't do that. Work on the absolutely latest source code. If you work
on anything else it is impossible for you to get any help with any
issues, and you will have to spend a lot of extra time to make your
finished work possible to includ
Hi,
I had a look on some extracts of your book I think I will buy it
because it seems to correspond
to what I am looking for. Thanks for the link!
However, it has been done on a 2.6.34 kernel, but I am at the moment
working on a uClinux 2.6.19.
The registration function platform_driver_probe() s
Hello, Alan.
On Tue, Jan 15, 2013 at 01:20:58PM -0500, Alan Stern wrote:
> It may not be so easy. When the SCSI async thread probes the new disk,
> it has to do I/O. So it needs to use a scheduler.
>
> But maybe it could use a built-in trivial scheduler until the proper
> one is loaded. Then
Hello, Linus.
On Tue, Jan 15, 2013 at 09:36:57AM -0800, Linus Torvalds wrote:
> Tejun, comments? You can see the whole thread on lkml, but the basic
> problem is that the module loading doing the unconditional
> async_synchronize_full() has caused problems, because we have
>
> - load module A
>
On Tue, 15 Jan 2013, makuda wrote:
> Alan Stern writes:
>
> >
> > On Fri, 17 Dec 2010, Alessio Sangalli wrote:
> >
> > > On 12/17/2010 07:42 AM, Alan Stern wrote:
> > >
> > > > Anyway, you can force individual root-hub ports to be dedicated to the
> > > > companion controller by using sysfs.
On Tue, 15 Jan 2013, Linus Torvalds wrote:
> Tejun, comments? You can see the whole thread on lkml, but the basic
> problem is that the module loading doing the unconditional
> async_synchronize_full() has caused problems, because we have
>
> - load module A
>- module A does per-controller a
On Tue, Jan 15, 2013 at 9:36 AM, Linus Torvalds
wrote:
>
> This kind of "let's randomly encourage people to write subtly buggy
> code that has magical timing dependencies, so that the developer won't
> likely even see it because he has fast disks etc" code is totally
> unacceptable. And this code
On Tue, Jan 15, 2013 at 11:04:51AM -0700, Stephen Warren wrote:
> On 01/15/2013 03:19 AM, Venu Byravarasu wrote:
> > As tegra_usb_phy_clk_disable/enable() are not being
> > used, removing them.
>
> Greg, Felipe,
>
> Again if I may, I'll take this through the Tegra tree. I think the next
> set of
On 01/15/2013 03:19 AM, Venu Byravarasu wrote:
> As tegra_usb_phy_clk_disable/enable() are not being
> used, removing them.
Greg, Felipe,
Again if I may, I'll take this through the Tegra tree. I think the next
set of patches that Venu posts should actually expose the dependencies
between his USB
Alan Stern writes:
>
> On Fri, 17 Dec 2010, Alessio Sangalli wrote:
>
> > On 12/17/2010 07:42 AM, Alan Stern wrote:
> >
> > > Anyway, you can force individual root-hub ports to be dedicated to the
> > > companion controller by using sysfs. For example, let's say you wanted
> > > port 4 on bus
[ Added Tejun to the discussion, since he's the async go-to-guy ]
On Mon, Jan 14, 2013 at 10:23 PM, Ming Lei wrote:
>
> But I have another idea to address the problem, and let module code call
> async_synchronize_full() only if the module requires that explicitly, so how
> about the below draft p
> Hi,
>
> On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
> > Hi Arnd,
> >
> > On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
> > >On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
> > >>Added a new driver for the usb part of control module.
> This has an
> > >>API to
On Tue, 15 Jan 2013, Fernando Luis Vázquez Cao wrote:
> Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
> a RF receiver, multi-interface USB device 054c:0374, that is used to connect
> a wireless keyboard and a wireless mouse.
>
> The keyboard works flawlessly, but the
On Tuesday, January 15, 2013 1:03 PM Sebastian Andrzej Siewior wrote:
> >usb_function_driver.
> >
> >I would call the structure in question "usb_function_module".
> >Or even better: "usb_function_pool" - you get usb_functions from it.
> >Please see inline for what it looks like.
>
> Not sure I
Hi,
On Tue, Jan 15, 2013 at 04:18:00PM +0100, stl wrote:
> Hello all,
> I need some clarifications concerning the terms used in the linux usb
> documentation
> for usb driver:
>
> Firstly, what is the difference between:
> - device driver
> - chipset driver
> - interface driver
> - gadget driver
Hi,
On Tue, Jan 15, 2013 at 04:09:42PM +0100, stl wrote:
> Hello all,
> I want to write a usb driver for our usb controller.
> I aim to use it as "device-side" driver, so if I well understood
> as a "gadget driver".
> Is "gadget driver" really what I need?
you need to write a "UDC driver" just li
Hi,
On Tue, Jan 15, 2013 at 08:09:22PM +0530, kishon wrote:
> Hi Arnd,
>
> On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
> >On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
> >>Added a new driver for the usb part of control module. This has an API
> >>to power on the USB2 phy
On Tuesday 15 January 2013, kishon wrote:
> Good point :-). Currently, none of the OMAP platforms have multiple
> control modules and it doesn't seem to be in the future (AFAIK). While
> it might be simpler to support multiple control devices with phandle, it
> might face the same complications
Hi Arnd,
On Tuesday 15 January 2013 07:11 PM, Arnd Bergmann wrote:
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in
On Tuesday 15 January 2013 06:23 PM, Sergei Shtylyov wrote:
Hello.
On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by t
Hi Arnd,
On Tuesday 15 January 2013 07:06 PM, Arnd Bergmann wrote:
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be "ti,omap-control-usb"
+ - reg : Address and length of the register set for the device. It contains
+
On Tue, Jan 15, 2013 at 10:29:33AM +0800, Peter Chen wrote:
> As mach/hardware.h is deleted, we need to use platform_device_id to
> differentiate SoCs. Besides, one cpu_is_mx35 is useless as it has
> already used pdata to differentiate runtime
>
> Meanwhile we update the platform code accordingly.
Hi Arnd,
On 01/15/2013 10:07 AM, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Ezequiel Garcia wrote:
>> Cc: Lior Amsalem
>> Cc: Thomas Petazzoni
>> Cc: Gregory CLEMENT
>> Signed-off-by: Ezequiel Garcia
>
> The patches look good, but when you have four trivial patches
> doing the same th
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
> Added a new driver for the usb part of control module. This has an API
> to power on the USB2 phy and an API to write to the mailbox depending on
> whether MUSB has to act in host mode or in device mode.
>
> Writing to control module regi
On Tuesday 15 January 2013, Kishon Vijay Abraham I wrote:
> +OMAP CONTROL USB
> +
> +Required properties:
> + - compatible: Should be "ti,omap-control-usb"
> + - reg : Address and length of the register set for the device. It contains
> + the address of "control_dev_conf" and "otghs_control".
> +
Adding DWC3 device tree node for Exynos5250 needed to
parse device tree data.
Also enabling XHCI support on exynos5250.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/usb/exynos-usb.txt | 14 ++
arch/arm/boot/dts/exynos5250.dtsi |6 ++
arch
Adding necessary device clock to exynos5 needed for
the DWC3 controller.
Signed-off-by: Vivek Gautam
---
arch/arm/mach-exynos/clock-exynos5.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exy
Adding OHCI device tree node for Exynos5250 along with
the device base address.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Acked-by: Grant Likely
---
.../devicetree/bindings/usb/exynos-usb.txt | 15 +++
arch/arm/boot/dts/exynos5250.dtsi |6 +
Adding EHCI device tree node for Exynos5250 along with
the device base adress and gpio line for vbus.
Signed-off-by: Vivek Gautam
Acked-by: Jingoo Han
Acked-by: Grant Likely
---
.../devicetree/bindings/usb/exynos-usb.txt | 25
arch/arm/boot/dts/exynos5250-smdk525
Changes from v3:
- Clubbed together arch enable patches for ehci/ohci and dwc3:
[PATCH v3 0/2] Enable ehci and ohci devices for exynos5250, and
[PATCH v3] ARM: Exynos5250: Enabling dwc3-exynos driver
- Dropped OF_DEV_AUXDATA entry in mach-exysno5-dt since we don't
need it.
- Splitted th
yes. usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
IFF_POINTTOPOINT. At least we should do something to handle
relationship of these flags rather than only have different names.
or new flag FLAG_NOARP could be introduced to corresponding to IFF_NOARP.
2013/1/15 Dan Williams :
> On Sa
On Tuesday 15 January 2013, Ezequiel Garcia wrote:
> Cc: Lior Amsalem
> Cc: Thomas Petazzoni
> Cc: Gregory CLEMENT
> Signed-off-by: Ezequiel Garcia
The patches look good, but when you have four trivial patches
doing the same thing in different files, and you decide that it's
not worth writing
Hello.
On 15-01-2013 12:42, Kishon Vijay Abraham I wrote:
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mail
* Andrzej Pietrasiewicz | 2013-01-03 16:37:45 [+0100]:
>Hello Sebastian,
Hello Andrzej,
>On Sunday, December 23, 2012 9:10 PM Sebastian Andrzej Siewior wrote:
>
>> Subject: [PATCH 06/30] usb/gadget: add some infracture to
>> register/unregister functions
>>
>> This patch provides an infrastructu
On Tue, Jan 15, 2013 at 02:08:34PM +0800, Peter Chen wrote:
> For mxs-phy user i.mx6q, the PHY's clock is controlled by
> hardware automatically, the software only needs to enable it
> at probe, disable it at remove. During the runtime,
> we don't need to control it. So for the usbphy clk policy:
>
Hi Felipe,
thank you for advice.
I've looked at your patch and it makes quite sense to me. But
surprisingly, it doesn't help. So I've done a small investigation and
I've added printk into "gs_flush_chars" and discovered, that it is never
called.
I suppose, that calling "tcflush(fd, TCOFLUSH)
Hi Florian,
On 01/15/2013 07:23 AM, Florian Fainelli wrote:
> Le 01/15/13 10:54, Ezequiel Garcia a écrit :
>> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
>> index 440b13e..5e4fcde 100644
>> --- a/arch/arm/mach-mvebu/Kconfig
>> +++ b/arch/arm/mach-mvebu/Kconfig
>> @@ -24,
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any p
DWC3 controller curretly depends on USB && USB_GADGET.
Some hardware may like to use only host feature on dwc3,
or only gadget feature.
So, removing this dependency of USB_DWC3 on USB and USB_GADGET.
Adding the mode of operaiton of DWC3 also here
HOST/GADGET/DUAL_ROLE based on which features are en
Hello Ezequiel,
Le 01/15/13 10:54, Ezequiel Garcia a écrit :
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..5e4fcde 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -24,6 +24,7 @@ config MACH_ARMADA_370_XP
select HAVE_SM
As tegra_usb_phy_clk_disable/enable() are not being
used, removing them.
Signed-off-by: Venu Byravarasu
---
drivers/usb/phy/tegra_usb_phy.c | 13 -
include/linux/usb/tegra_usb_phy.h |4
2 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/phy/tegra
Hi,
This small patch set enables USB support on Armada 370 and Armada XP platforms.
It's based on Jason Cooper's mvebu/dt branch.
Any comments or feedback are welcome.
Ezequiel Garcia (6):
arm: mvebu: Add support for USB host controllers in Armada 370/XP
arm: mvebu: Enable USB controllers on A
Cc: Lior Amsalem
Cc: Thomas Petazzoni
Cc: Gregory CLEMENT
Signed-off-by: Ezequiel Garcia
---
arch/arm/configs/mvebu_defconfig |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index c3c6326..f8d0183
Cc: Lior Amsalem
Cc: Thomas Petazzoni
Cc: Gregory CLEMENT
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
b/arch/arm/boot/dts/a
The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.
Cc: Lior Amsalem
Cc: Thomas Petazzoni
Signed-off-by: Gregory CLEMENT
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/ar
Cc: Lior Amsalem
Cc: Thomas Petazzoni
Cc: Gregory CLEMENT
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370-mirabox.dts |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox
Cc: Lior Amsalem
Cc: Thomas Petazzoni
Cc: Gregory CLEMENT
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-xp-db.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index c7
Cc: Lior Amsalem
Cc: Thomas Petazzoni
Cc: Gregory CLEMENT
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370-db.dts |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 8e66
Hi Antonio,
On 2013/01/15 18:36, Antonio Ospite wrote:
On Tue, 15 Jan 2013 12:43:48 +0900 Fernando Luis Vázquez Cao
wrote:
diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-sony.c
linux-3.8-rc3/drivers/hid/hid-sony.c
--- linux-3.8-rc3-orig/drivers/hid/hid-sony.c 2012-12-11 12:30:57.0
On Tue, 15 Jan 2013 12:43:48 +0900
Fernando Luis Vázquez Cao wrote:
Hi Fernando,
> Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
> a RF receiver, multi-interface USB device 054c:0374, that is used to connect
> a wireless keyboard and a wireless mouse.
>
> The keyb
The driver description files gives these names to the vendor specific
functions on this modem:
Diagnostics VID_2357&PID_0201&MI_00
NMEAVID_2357&PID_0201&MI_01
Modem VID_2357&PID_0201&MI_03
Networkcard VID_2357&PID_0201&MI_04
Reported-by: Thomas Schäfer
Signed-off-by: Bjørn Mork
Thomas Schäfer writes:
> Here are all infos about this device. I think I catched the relevant data.
>
> Switching to modem/network-mode works with
>
> eject /dev/sr0
>
> It works with "option"
> /dev/ttyUSB2 has accepted at-commands
>
> and qmi_wwan (in testcase with interface 1 instead of 0)
>
The driver description files gives these names to the vendor specific
functions on this modem:
Diagnostics VID_2357&PID_0201&MI_00
NMEAVID_2357&PID_0201&MI_01
Modem VID_2357&PID_0201&MI_03
Networkcard VID_2357&PID_0201&MI_04
The "Networkcard" function has been verified to suppor
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers for doing the above task which was
previously done in omap glu
1 - 100 of 109 matches
Mail list logo
