On Wed, Jun 21, 2006 at 06:15:13PM -0300, Luiz Fernando N. Capitulino wrote:
On Wed, 21 Jun 2006 17:43:36 +0100
Russell King [EMAIL PROTECTED] wrote:
| In the uart_update_mctrl() case, the purpose of the locking is to
| prevent two concurrent changes to the modem control state resulting
to atomically update tty-hw_stopped in some circumstances
(that may also be modified from irq context.) Therefore, to give
the driver a consistent locking picture, the spinlock is _always_
held.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6
methods are ever called from interrupt context or not.
What we could do is put a WARN_ON() or might_sleep() in there and
find out over time if they are called from non-process context.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
as they all use the
same platform device :)
So what do folk want me to do? Blindly merge the patch (hint: it's still
in the incoming queue...)
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Thu, Feb 16, 2006 at 09:57:32AM -0800, James Bottomley wrote:
On Thu, 2006-02-16 at 17:12 +, Russell King wrote:
This is probably an idiotic question, but if there's something in the
scsi release handler can't be called in non-process context, why can't
scsi queue up the release
On Thu, Feb 16, 2006 at 10:14:31AM -0800, James Bottomley wrote:
On Thu, 2006-02-16 at 18:09 +, Russell King wrote:
where scsi_release() is the function called by the device model on the
last put of a scsi device.
I guess is more or less what you're trying to do invasively via
, rather
than having to have this additional code and complexity for everyone?
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
---
This SF.net email is sponsored by: Splunk Inc. Do
crap in bugzilla, otherwise
I'd reassign it. Please kick the bt folk.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
---
This SF.net email is sponsored by: Splunk Inc. Do you grep
thinks it's a serial
bug. I'm not sure why though, I've fully explained why it isn't
a serial problem in the bug comments.
akpm is buggy and needs fixing. Where do I file this bug? 8)
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Thu, Jan 12, 2006 at 01:27:12PM +0100, Mikael Pettersson wrote:
On Fri, 6 Jan 2006 18:38:46 +, Russell King wrote:
is there any architecture for which packed is required in structures like
this:
/* All standard descriptors have these 2 fields at the beginning */
struct
On Thu, Jan 12, 2006 at 01:47:29PM +, Russell King wrote:
Due to lack of manpower on the Linux side (iow, more or less just me)
this became the ABI of the early ARM Linux a.out toolchain. At that
time, I did not consider this to be a problem - it wasn't a problem
as far as the kernel
'... room for one other int.
r7 syscall number
and as such will be uncallable with this argument ordering for EABI.
We've already had to sanitise sys_fadvise64_64() because of this.
So, I forsee more problems appearing with EABI, not less. ;(
--
Russell King
Linux kernel2.6 ARM Linux
to present such cases when I get copied on
emails to answer questions? I don't understand the stupid mentality
there - this is _not_ the first time this has happened in the 12 days
of 2006 so far.)
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer
On Thu, Jan 12, 2006 at 05:22:47PM +, David Vrabel wrote:
Russell King wrote:
BTW, it's worth noting that the new EABI stuff has it's own set of
problems. We have r0 to r6 to pass 32-bit or 64-bit arguments.
With EABI, 64-bit arguments will be aligned to an _even_ numbered
register
bDescriptorType;
};
sizeof(struct usb_descriptor_header) will be 4 on ARM. If this
concerns you, you need to pack the structure thusly:
struct usb_descriptor_header {
__u8 bLength;
__u8 bDescriptorType;
} __attribute__((packed));
--
Russell King
Linux kernel2.6 ARM
? Screw that. Every case of ((packed)) has to have
a very explicit justification.
Your comments are offensive. Screw yourself instead please.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
respects to him, but his comments
show that he is _quite_ naieve concerning this. If he wishes to have
a view, he needs to research his facts before expressing such ill-
informed comments.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
the serial_core layer exists and
it's to get these kind of semantics (and bugs) centralised in one
place rather than spread across thousands of drivers.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Please don't cross-post between linux-usb-devel and linux-arm-kernel.
Linux-arm-kernel is a subscriber only list, and therefore replies by
linux-usb-devel folk will cause them to receive moderation messages,
which can upset people.
---
SF
. This
is obviously not the point of the original idea behind this.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Tue, Oct 12, 2004 at 07:01:41PM -0700, David Brownell wrote:
On Tuesday 12 October 2004 3:16 pm, Russell King wrote:
3. bh discovers the device speed and enables SOFs
4. some time later, the USB subsystem issues a reset, which disables SOFs
Strictly speaking, speed isn't known until
On Sun, Oct 10, 2004 at 06:10:22PM -0700, David Brownell wrote:
On Sunday 10 October 2004 9:43 am, Russell King wrote:
7. This one is the killer. Once it's been hacked to compile, plugging
in a USB flash key results in:
usb 1-1: new full speed USB device using address 2
usb 1-1
On Tue, Oct 12, 2004 at 01:57:43PM -0700, David Brownell wrote:
On Tuesday 12 October 2004 9:41 am, Russell King wrote:
I suspect that problem isn't associated with Lothar's code at all;
a lot of folk have been running into problems like that lately.
Actually it is. After running
On Wed, Sep 29, 2004 at 11:13:27AM +0200, Lothar Wassmann wrote:
Hi Russell and David,
Russell King writes:
File comments are important, and we as a whole community should be
jumping on people who do not correctly modify these as soon as they
send a driver for review. It is simply
On Tue, Sep 28, 2004 at 06:55:15AM -0700, David Brownell wrote:
On Monday 27 September 2004 3:20 pm, Russell King wrote:
This driver doesn't appear to build as a module in current 2.6 kernel
sources, namely because it references usb_kill_urb_queue which isn't
exported.
What would
about the USB subsystem instead.
Doesn't seem a really efficient use of my time... and I don't want to
end up maintaining yet another driver for a subsystem I don't
particularly want to learn about. Sigh.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk
dma mapping of hcd.c rather gets in the way.
I somehow doubt that exporting usb_kill_urb_queue would be the magical
fix that makes this driver works, so maybe if someone could also give
a quick review of it (hc_sl811.c and hc_simple.c) I'd appreciate it.
Thanks.
--
Russell King
Linux kernel
[usbcore]) from [bf019f08]
(hub_events+0x354/0x4a4 [usbcore])
[bf019bb4] (hub_events+0x0/0x4a4 [usbcore]) from [bf01a080] (hub_thread+0x28/0x130
[usbcore])
[bf01a058] (hub_thread+0x0/0x130 [usbcore]) from [c023b7a4] (do_exit+0x0/0x3ac)
--
Russell King
Linux kernel2.6 ARM Linux - http
On Fri, Feb 20, 2004 at 07:48:13PM +1100, Benjamin Herrenschmidt wrote:
Anyway, a platform hook in device_add() seem like it could be
useful for other things as well...
What about platform_notify() which already seems to be provided for you ?
--
Russell King
Linux kernel2.6 ARM Linux
be asserted during DMA cycles, although
it can address more than 1MB of memory. The effect of this is that
even MB are dma-able and odd MB aren't. Not nice.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk
On Mon, Sep 22, 2003 at 02:02:38AM -0700, Pier Paolo Glave wrote:
After a long session of debugging with printk, I found
out that in those cases one of the calls to
schedule_timeout() (issued when waiting for an URB
response in usb.c) never returns.
I can avoid this situation by removing the
it might be an idea to hold
back on integrating it until David has had a chance to respond to this.
- - - Submitted by Russell King on 16 Sep 2003 17:06:20 (UTC) - - -
Well, asm/proc/cache.h is gone in 2.6, so this doesn't compile. I've also
been wondering why you want to include this file
On Tue, Jul 09, 2002 at 05:05:07PM -0700, Pering, Trevor wrote:
Hello -- this is a re-post of an earlier problem from last week I'm still
working on.
The problem is consistent_alloc(). When it was written, it didn't need
to handle allocations from interrupts. However, the spec changed, and
On Wed, Jun 05, 2002 at 03:17:10PM -0700, Christopher Hoover wrote:
[PATCH] SA- support for ohci-hcd
This patch is a first cut at SA- support for ohci-hcd. It seems
to limp along OK.
I intentionally tried to change as little as possible for this first
cut. Therefore the
that from the discussions that
have been made recently about hash tables.
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
___
[EMAIL PROTECTED]
To unsubscribe, use the
35 matches
Mail list logo
