This patch allows gadget drivers that support high speed (e.g. gadgetfs)
to work properly with at91_udc.
Signed-off-by: Wojtek Kaniewski <[EMAIL PROTECTED]>
Cc: Andrew Victor <[EMAIL PROTECTED]>
---
Fix suggested by Milan Svoboda in
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=1158221847118
This patch zeroes some variables when usb_gadget_register_driver()
fails. gadgetfs does a dummy registration to get the name of the USB
driver and then waits for user-land driver. If someone plugs the cable
in the meantime, bad things happen, because at91_udc has been left in
inconsistent state.
S
This patch performs additional checks in at91_udc, just in case of
some spurious interrupts or device enumeration.
Signed-off-by: Wojtek Kaniewski <[EMAIL PROTECTED]>
Cc: Andrew Victor <[EMAIL PROTECTED]>
--- linux-2.6.19.orig/drivers/usb/gadget/at91_udc.c 2006-12-08
09:36:02.0 +0100
On 12/7/06, Greg KH <[EMAIL PROTECTED]> wrote:
> Ugh, no, never use the usb-serial driver as a console device.
>
> That was a bad hack done as a bet many years ago. For many obvious
> reasons it does not work well.
understood, I found with usb_serial convertor could lose some chatacter.
but the us
On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Ugh. I'd check the code. But it looks like my tweak to the
> early fixmap code. But my hunch is that my tweak to __fixmap
> so that it's pud and pmd were prepopulated didn't take on
> your build.
I missed some options?
YH
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 12/7/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Ugh. I'd check the code. But it looks like my tweak to the
>> early fixmap code. But my hunch is that my tweak to __fixmap
>> so that it's pud and pmd were prepopulated didn't take on
>> your
On Wed, 6 Dec 2006, Dominik Brodowski wrote:
> > > Now I tested this a bit further... and strangely, if I modprobe the USB
> > > modules somewhen later, it is no problem at all. Running many many
> > > possible
> > > combinations of modprobe'ing yenta_socket, ehci_hcd, uhci_hcd and other
> > > mo
On Thu, 7 Dec 2006, Garrett D'Amore wrote:
> I'm developing a USB "transport protocol" (for a thin-client
> application, that basically allows a remote server to access the USB bus
> on a thin-client device, e.g. so you can access your USB thumbdrive
> using your thin-client.) We have this workin
On Thu, 7 Dec 2006, Dominik Brodowski wrote:
> > Or perhaps not. I can't think of any reason why the EHCI controller
> > should have generated the unhandled IRQ, and it seems very suspicious that
> > it occurred just as the cs port probing was going on. So maybe
> > yenta_socket is at fault, and
hi
On Friday 08 December 2006 08.38, J.P. Delport wrote:
> Hi,
>
> the usbtouchscreen driver as included in kernel 2.6.19 almost works with
> the itm based touchscreen that I have (an LG L1730SF).
>
> I reported earlier that the screen does not provide valid x and y values
> when the screen is
Here are some patches that move the HID code to a new directory allowing
it to be used by other kernel subsystems easier.
This patch was approved by Dmitry, Marcel and myself, and Andrew asked
that I get this to you now to make merges with other parts of our
respective queues easier.
Many thanks
From: Jiri Kosina <[EMAIL PROTECTED]>
This patch is a part of generic HID layer introduction. USB HID is
disabled, so that the code split and changes could be introduced in a
way that is reviewable (i.e. separate patches), but not to break git
bisect by uncompilable kernel throughout different sta
From: Jiri Kosina <[EMAIL PROTECTED]>
- fixed generic API (added neccessary EXPORT_SYMBOL, fixed hid.h to provide
correct
prototypes)
- extended hid_device with open/close/event function pointers to driver-specific
functions
- added driver specific driver_data to hid_device
Signed-off-by: Ji
From: Jiri Kosina <[EMAIL PROTECTED]>
- hiddev is USB-only (agreed with Marcel Holtmann that Bluetooth currently
doesn't need it, and future planned interface (rawhid) will be more flexible
and usable)
- both HID and USB-hid can be now compiled as modules (wasn't possible before
hiddev was f
From: Jiri Kosina <[EMAIL PROTECTED]>
- 'dev' in struct hid_device changed from struct usb_device to
struct device and fixed all the users
- renamed functions which are part of USB HID API from 'hid_*' to
'usbhid_*'
- force feedback initialization moved from common part into USB-specific
dri
From: Jiri Kosina <[EMAIL PROTECTED]>
hid_input_report() was needlessly USB-specific in USB HID. This patch
makes the function independent of HID implementation and fixes all
the current users. Bluetooth patches comply with this prototype.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
Signed-off
From: Jiri Kosina <[EMAIL PROTECTED]>
pb_fnmode parameter has to be passed to usbhid, both for compatibility reasons
and also because it logically belongs there.
Also removes empty hid-input.c file in drivers/usb/input.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
Signed-off-by: Marcel Holtman
From: Jiri Kosina <[EMAIL PROTECTED]>
This modifies Makefiles and Kconfigs to properly reflect the creation of
generic HID layer.
It also removes the dependency of BROKEN, which was introduced by the
first patch in series (see the comment). Also updates credits.
Signed-off-by: Jiri Kosina <[EMAI
David Brownell wrote:
> On Thursday 07 December 2006 10:24 am, Geoff Levand wrote:
> It'd be advantageous to (re)use the same driver glue. If it
> weren't for the fact that each chip/system vendor ends up with
> minor differences related to system integration, we could make
> do with a lot fewer "
On Fri, 8 Dec 2006, Greg KH wrote:
>
> Here are some patches that move the HID code to a new directory allowing
> it to be used by other kernel subsystems easier.
I pulled. However, I think the Kconfig changes are HORRIBLE.
I don't understand why people don't use "select" more. Why should Kconf
Hi Linus,
> > Here are some patches that move the HID code to a new directory allowing
> > it to be used by other kernel subsystems easier.
>
> I pulled. However, I think the Kconfig changes are HORRIBLE.
>
> I don't understand why people don't use "select" more. Why should Kconfig
> ask for "G
On Fri, Dec 08, 2006 at 11:28:57AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 8 Dec 2006, Greg KH wrote:
> >
> > Here are some patches that move the HID code to a new directory allowing
> > it to be used by other kernel subsystems easier.
>
> I pulled. However, I think the Kconfig changes are HO
On Fri, 8 Dec 2006, Marcel Holtmann wrote:
> since we don't have any user-space or out of kernel HID transport
> drivers at the moment it would make sense to simply select HID if
> someone selects USB_HID or the upcoming Bluetooth transport.
OK, I agree. Something like this? (applies on top of
This moves to to reduce more of the
clutter of usb header files.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
It'd be good to make this patch do the GIT magic to actually move the file
rather than the add/remove done by this patch.
Index: g26/drivers/usb/gadget/net2280.c
=
Hi,
On Fri, Dec 08, 2006 at 11:00:15AM -0500, Alan Stern wrote:
> Okay. Here's a patch that will print out some information for each of the
> first 100 interrupts received by ehci-hcd. Block yenta-socket from being
> loaded, so as to reduce the number of extraneous interrupts, and see what
>
On Wed, Dec 06, 2006 at 07:20:16PM -0800, Lu, Yinghai wrote:
> Greg,
>
> I wonder why the netconsole could print all boot log from beginning with
> buffer. But your usb serial console can not.
Buffer size? flow control? the fact that the buffer has already
overflowed? Who knows, don't trust us
-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2006 5:17 PM
>Buffer size? flow control? the fact that the buffer has already
>overflowed? Who knows, don't trust usb-serial as a real "console"
>please :)
I set buffer size to 128k, and can get all
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2006 11:42 PM
>> With Eric code in LinuxBIOS, it will report "No device found in debug
>> port"
>Hmm. At least this is partial progress :)
It works in LinuxBIOS now. It will loop all connect
On Friday 08 December 2006 9:00 am, Geoff Levand wrote:
> David Brownell wrote:
> > It'd be advantageous to (re)use the same driver glue. ... But
> > having two (or three) for Cell seems excessive, especially
> > if they're all going to the same IOIF ohci controller...
>
>
> Well yes, the unde
This patch applies David Brownell's suggestion for reworking the
OHCI quirk mecanism via a table of PCI IDs. It adapts the existing
quirks to use that mecanism.
Note that I haven't moved the quirks to reset() as suggested by
the comment in there as I'd like to avoid functional changes and
I'm not
These patches are reworked versions of the patch I posted on behalf of
Toshiba a while ago. I've reworked things significantly, mostly to
address David's concerns and my own issues. I've also split the patch.
- Patch 1 : Rework the OHCI quirk mecanism as suggested by David
- Patch 2 : Implement
This patch separates support for big endian MMIO register access
and big endian descriptors in order to support the Toshiba SCC
implementation which has big endian registers but little endian
in-memory descriptors.
It simplifies the access functions a bit in ohci.h while at it.
Signed-off-by: Ben
This patch implements supports for EHCI controllers whose MMIO
registers are big endian and enables that functionality for
the Toshiba SCC chip. It does _not_ add support for big endian
in-memory data structures as this is not needed for that chip
and I hope it will never be.
Signed-off-by: Kou Is
On Mon, 2006-10-30 at 05:12 -0500, Joseph Fannin wrote:
> On Sat, Oct 28, 2006 at 10:27:46PM +0200, Soeren Sonnenburg wrote:
> > On Sat, 2006-10-28 at 20:55 +0200, Oliver Neukum wrote:
> > > > From: Sergey Vlasov <[EMAIL PROTECTED]>
> > > > Subject: usbhid: Add HID_QUIRK_IGNORE_MOUSE flag
> > > >
>
34 matches
Mail list logo
