On Thu, Aug 02, 2007 at 09:43:29AM -0700, Greg KH wrote:
...
It wasn't just MIPS. IBM has a very popular blade system that has huge
issues with this, and I think there are some other IBM systems based on
the same BIOS that also do bad things if we don't grab the USB
controller away from the
to HCI mode.
I've seen extract() and implement() functions have been patched a few weeks
ago :
USB: input: extract() and implement() are bit field manipulation routines
author Grant Grundler [EMAIL PROTECTED]
Tue, 10 Oct 2006 21:42:51 + (14:42 -0700)
commit
On Thu, Oct 19, 2006 at 02:33:31PM -0400, Adam Kropelin wrote:
...
No problem with the first two changes.
I like the comments to accurate.
+ * One model of UPS is claimed to report LINEV as a 32-bit field.
I'd prefer to remove the word claimed and say instead, One model of APC
UPS reports
On Wed, Oct 18, 2006 at 12:44:30AM -0600, Grant Grundler wrote:
And I've fixed the algorithm to handle 32-bit extracts in the test
below and will submit the same code in the next patch.
Greg,
Previous patch broke extract/implement for 32-bit report fields.
Adam Kropelin had posted 32-bit fix
On Thu, Oct 19, 2006 at 10:32:39AM -0600, Grant Grundler wrote:
I've written (and will shortly post) a test for implement().
I've dropped test_implement.c and a few other user space test
programs on http://iou.parisc-linux.org/~grundler/tests/
-rw-r--r-- 1 grundler grundler 1750 Oct 18 09:13
On Tue, Oct 17, 2006 at 11:12:56PM -0400, Adam Kropelin wrote:
...
Write the code in userspace to prove it to yourself if you don't believe
me. In fact, here. I did it for you. (x86 32 bit assumed; adjust to
taste)
Thanks for the test code.
I'll resubmit with a patch that works for 32-bit
On Wed, Oct 18, 2006 at 07:30:40AM -0400, Adam Kropelin wrote:
Interesting. I'll fully admit to not having enough 64 bit arch
experience to have predicted that, but that's why I like to unit test
that sort of thing.
Uhm...it has nothing to do with 64-bit arch.
We only have a 32-bit user
On Tue, Oct 17, 2006 at 08:33:06PM -0400, Adam Kropelin wrote:
...
If someone needs either function to handle more than 24-bits, please
document why - point at a specification or specific USB hid device - in
comments in the code.
Ummm. Ok. How many pages of the HID 1.11 spec shall I paste
On Sat, Jun 04, 2005 at 06:59:53PM -0400, Alan Stern wrote:
The point I was driving at is that we currently have separate APIs for
byte swapping and for unaligned access, and it would make a lot of sense
to combine them into a single API. Knowing that the bytes have to be
swapped _and_
On Sat, Jun 04, 2005 at 11:06:52AM -0400, Alan Stern wrote:
In spite of the total overall number of changes required, wouldn't it be
much simpler to have a suite of routines (inlines or macros) like:
get_16, put_16, get_le16, put_le16, get_be16, put_be16
get_32, put_32,
On Fri, Jun 03, 2005 at 06:41:55PM -0400, John David Anglin wrote:
extract() and implement() have brain damaged attempts to handle
32-bit wide fields.
It seems that this problem has been around for some time.
I didn't check to see how long this code has been around.
Does it fix the usb
exception.
o static inline is preferred as per Documentation/SubmittingPatches.
I'd be happy to submit a patch if someone isn't able
to run sed -e 's/__inline__/inline/' over the code.
thanks,
grant
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
Index: drivers/usb/input/hid-core.c
On Mon, Apr 25, 2005 at 04:14:13PM -0400, Alan Stern wrote:
Not sure what you mean by make kexec work nicer but if it is because
some devices don't work after a kexec I have some objections.
That was indeed the reason, at least in my case. The newly-rebooted
kernel doesn't work too well
On Mon, Apr 25, 2005 at 05:12:09PM -0400, Alan Stern wrote:
Do you have any suggestions for a better way to stop a device from issuing
IRQs and doing DMA at any point between the time when the old kernel
panics and the time when the new kernel loads the device's driver?
PCI Bus resets?
That
On Tue, Apr 26, 2005 at 02:30:12PM +1000, Benjamin Herrenschmidt wrote:
Additionally, some machines won't properly park/flush the disk, it's
necessary to send the proper suspend commands to IDE hard disks prior to
shutting down or we risk data loss.
That sounds like the disk is caching write
On Tue, Apr 26, 2005 at 12:07:41PM -0400, Richard B. Johnson wrote:
DMAs don't go on forever
They don't. But we also don't know when they will stop.
E.g. NICs will stop DMA when the RX descriptor ring is full.
I don't know when USB stop on it's own.
and at the time they are started they
are
On Tue, Apr 26, 2005 at 12:04:00PM -0400, Alan Stern wrote:
Sure there is. Every IRQ line goes to an IRQ controller.
Arch specific code deals with programming the controller and can
mask all interrupts (or not). Historically, they've been left unmasked
for ISA IRQ discovery and debugging
On Tue, Apr 26, 2005 at 01:14:38PM -0400, Alan Stern wrote:
On Tue, 26 Apr 2005, Grant Grundler wrote:
Agreed - but this is a different problem than shutting down IRQs.
My point was arch specific code knows how to mask all IRQs.
irq_disable() is expected to work regardless of what state
On Mon, Mar 14, 2005 at 10:46:02AM -0500, Alan Stern wrote:
...
Very helpful, thanks. It appears that the main problem with disabling
PCI devices as they are discovered lies with devices that are already in
use (before their drivers have initialized!).
Yes - e.g. firmware is used to talk to
On Tue, Mar 15, 2005 at 04:18:21PM -0700, Grant Grundler wrote:
...
Worse than that, it will disable the entire IRQ line, thus affecting other
devices that may be sharing it. That's not what I want; I need a way to
prevent a generic PCI device from issuing interrupt requests without
On Tue, Mar 15, 2005 at 10:10:57PM -0500, Brown, Len wrote:
Interrupt Disable bit was added via an
Engineering Change Notice. At the same time, an Interrupt Status
bit was defined for the Status register.
I believe that this is for (new) devices that support MSI.
Hrm...that sounds like a
unfortunate that the mailing list archives are so large and have such
inadequate indexing and search facilities...
Maybe this would help narrow the search?
| Date: Tue, 6 Mar 2001 20:20:25 +0300
| From: Ivan Kokshaysky [EMAIL PROTECTED]
| To: Grant Grundler [EMAIL PROTECTED]
| Cc: linux-kernel
On Fri, Mar 11, 2005 at 04:19:08PM +, Matthew Wilcox wrote:
During a normal boot most devices are left in reasonably quiescent and
safe condition when the BIOS passes control to the OS. But sometimes a
few of them aren't; that's why we need to have the USB early-handoff quirk
code.
On Sat, Mar 06, 2004 at 08:37:43AM -0800, David Brownell wrote:
DMA-coherent memory is defined as memory for which a write by either
the device or the processor can immediately be read by the processor
or device without having to worry about caching effects.
The use of immediate here means no
24 matches
Mail list logo
