The replacement of spin_lock_irq/spin_unlock_irq pair in
twl4030_usb_linkstat function by
spin_lock_irqsave/spin_lock_irqrestore pair.
The twl4030_usb_linkstat function is called from twl4030_usb_irq
interrupt handler. Therefore reenabling of handler interrupt line
should be avoided.
Found by Linu
On Friday 20 July 2012, Tony Prisk wrote:
> Add support for a generic non-pci UHCI companion controller.
> Existing board files for arch-vt8500 updated to include UHCI
> support.
>
> Signed-off-by: Tony Prisk
Looks almost good, but
* please add a binding document
* cc the maintainers and usb m
On Saturday, July 21, 2012, Ming Lei wrote:
> CC guys who discussed the problem in the below link in Jan. :
>
> http://marc.info/?t=13252895602&r=10&w=2
>
> On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei wrote:
> > The RFC patch is just for discussing if the idea of deferring
> > request_fi
Signed-off-by: Tony Prisk
---
v4:
Minor changes to the documentation of required properties.
.../devicetree/bindings/usb/vt8500-ehci.txt| 12
drivers/usb/host/ehci-vt8500.c |9 +
2 files changed, 21 insertions(+), 0 deletions(-)
create mode
Add support for a generic non-pci UHCI companion controller.
Existing board files for arch-vt8500 updated to include UHCI
support.
Signed-off-by: Tony Prisk
---
v4:
Add the binding documentation.
Changed the OF .compatibility to 'platform-uhci'
.../devicetree/bindings/usb/platform-uhci.txt
On Sat, Jul 21, 2012 at 5:56 PM, Rafael J. Wysocki wrote:
> On Saturday, July 21, 2012, Ming Lei wrote:
>> CC guys who discussed the problem in the below link in Jan. :
>>
>> http://marc.info/?t=13252895602&r=10&w=2
>>
>> On Fri, Jul 20, 2012 at 8:33 PM, Ming Lei wrote:
>> > The RFC pat
On Fri, 20 Jul 2012, Mason wrote:
> Hello,
>
> I'm testing an embedded system, which is running a somewhat dated
> (May 2009) 2.6.28.10 kernel.
>
> When I plug this cheap 2-GB USB drive, I get the following message:
>
> hub_port_init 1
> Plug in USB Port3
> udev->speed: 3
> usb 3-1: configurati
On Fri, 20 Jul 2012, Mason wrote:
> Sorry, my brain glitched for a moment, looking at the device nodes,
> instead of the appropriate mount point.
>
> # ls -l /mnt/sda/
> -rwxrwxrwx1 root 0 572928 Mar 27 2012 hfs.exe
>
> sda instead of sda1 means there is no MBR, thus no partiti
Hello,
Kindly let me know
how an usb device connection is reported to kernel when we plug an usb cable.
I see that Udev/ueventd is responsible for that.
I want to know how exactly usb device will report to (kernel or udev)
when an device is plugged.
how can to create an sysfs(node) from gadget driv
On Sat, Jul 21, 2012 at 08:06:01PM +0530, chetan cr123 wrote:
> Hello,
> Kindly let me know
> how an usb device connection is reported to kernel when we plug an usb cable.
> I see that Udev/ueventd is responsible for that.
> I want to know how exactly usb device will report to (kernel or udev)
> wh
Hello.
On 21-07-2012 2:10, Arnd Bergmann wrote:
+static const struct of_device_id platform_uhci_ids[] = {
+ { .compatible = "of-uhci", },
+ {}
+};
The of- part is clearly meaningless in the binding that is about of
devices. Using usb-uhci would be more appropriate I think, but ma
On Saturday, July 21, 2012, Ming Lei wrote:
> On Sat, Jul 21, 2012 at 5:56 PM, Rafael J. Wysocki wrote:
> > On Saturday, July 21, 2012, Ming Lei wrote:
> >> CC guys who discussed the problem in the below link in Jan. :
> >>
> >> http://marc.info/?t=13252895602&r=10&w=2
> >>
> >> On Fri,
On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
NAK.
It really *has* to be handled
On Friday, July 20, 2012, Ming Lei wrote:
> The RFC patch is just for discussing if the idea of deferring
> request_firmware is doable for addressing the issue of
> request_firmware in resume path, which is caused by driver
> unbind/rebind during resume.
>
> At least usb bus is involved in such th
On Saturday, July 21, 2012, Linus Torvalds wrote:
> On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
> > The RFC patch is just for discussing if the idea of deferring
> > request_firmware is doable for addressing the issue of
> > request_firmware in resume path, which is caused by driver
> > unbin
On Sat, 21 Jul 2012, chetan cr123 wrote:
> Hello,
> Kindly let me know
> how an usb device connection is reported to kernel when we plug an usb cable.
> I see that Udev/ueventd is responsible for that.
It sounds like you're talking about the device's kernel, not the host's
kernel.
> I want to k
On Fri, 20 Jul 2012, Sarah Sharp wrote:
> > Well, then the device violates the standard for power consumption.
>
> Not necessarily.
>
> Tianyu, are you measuring the whole system power consumption or just the
> power drawn by the device? How are you measuring power consumption?
>
> Also, are y
Thanks for your so detailed comments.
On Sun, Jul 22, 2012 at 1:31 AM, Linus Torvalds
wrote:
> On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
>> The RFC patch is just for discussing if the idea of deferring
>> request_firmware is doable for addressing the issue of
>> request_firmware in resume
On Sun, Jul 22, 2012 at 1:49 AM, Rafael J. Wysocki wrote:
> On Friday, July 20, 2012, Ming Lei wrote:
>> + if (system_state != SYSTEM_RUNNING)
>> + return -EPROBE_DEFER;
>
> You can't just return here, _request_firmware_cleanup() has to be done still.
Good catch, thanks.
>
>> +
On Sat, Jul 21, 2012 at 12:55 PM, Ming Lei wrote:
>
> Suppose it is not good for resume case, I think it still makes sense
> for early boot situation, at least the patch will support to request
> firmware inside init call, and allow drivers to be built in kernel i
> case of requesting firmware fro
On Sat, 21 Jul 2012, Linus Torvalds wrote:
In my opinion, we should cache firmware data for all hotplug
devices or devices which may experience power loss automatically
in kernel during suspend-resume cycle because all such devices may be
disconnected and connected again during suspend-resume c
On Saturday, July 21, 2012, Ming Lei wrote:
> On Sun, Jul 22, 2012 at 1:49 AM, Rafael J. Wysocki wrote:
> > On Friday, July 20, 2012, Ming Lei wrote:
>
> >> + if (system_state != SYSTEM_RUNNING)
> >> + return -EPROBE_DEFER;
> >
> > You can't just return here, _request_firmware_cle
Ming Lei :
> On Sun, Jul 22, 2012 at 1:31 AM, Linus Torvalds
> wrote:
> > On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei wrote:
> >> The RFC patch is just for discussing if the idea of deferring
> >> request_firmware is doable for addressing the issue of
> >> request_firmware in resume path, which is
Hi,
with
http://download.opensuse.org/repositories/Kernel:/linux-
next/standard/x86_64/kernel-vanilla-3.5.rc7.next.20120720-1.1.x86_64.rpm
No one of my sticks works in qmi/wwan mode anymore. The modules seems to be
loaded, option and qmi_wwan, but the dial-in-skripts do nothing.
While removin
On Sun, Jul 22, 2012 at 4:38 AM, Linus Torvalds
wrote:
>
> I agree that this is a problem. At the same time, early boot has some
> of the exact same problems as resume has, and I do wish that people
> would ask themselves: "why do I try to load the firmware at early boot
> time"?
>
> There is real
On Tue, Jul 17, 2012 at 03:28:41PM -0700, Sarah Sharp wrote:
> The following changes since commit 66177cc10295ffdfc613c06f59b07a577d91ee82:
>
> usb: s3c-hsotg: Add header file protection macros in s3c-hsotg.h
> (2012-07-17 10:54:29 -0700)
>
> are available in the git repository at:
>
> git:
[sorry for sending this twice to you Thomas. Bad app defaults
made me enter the linux-usb list manually, and bad keyboard
made me get it wrong]
"Thomas Schäfer" wrote:
>with
>
>http://download.opensuse.org/repositories/Kernel:/linux-
>next/standard/x86_64/kernel-vanilla-3.5.rc7.next.20120720
27 matches
Mail list logo
