Am Samstag, 3. März 2007 01:29 schrieb Greg KH:
> On Sat, Mar 03, 2007 at 01:27:07AM +0100, Oleg Verych wrote:
> >
> > If you can proof that it doesn't influence kernel's control above system
> > hardware. Ironically such stuff in the userspace can give additional
> > intrusion way to the kernel.
Am Freitag, 2. März 2007 22:12 schrieb Adam J. Richter:
> When I plug in a pl2303-based usb serial device, the device is
> supposed to appear as /dev/tts/USB0 (character device 188, 0).
> However, under kernels that I have tried from 2.6.20-git3 through
> 2.6.21-rc2-git1, /dev/tts/USB is crea
On Sat, Mar 03, 2007 at 01:56:31AM +0100, Oleg Verych wrote:
> On Fri, Mar 02, 2007 at 04:29:57PM -0800, Greg KH wrote:
> > On Sat, Mar 03, 2007 at 01:27:07AM +0100, Oleg Verych wrote:
> > >
> > > If you can proof that it doesn't influence kernel's control above system
> > > hardware. Ironically s
On Fri, Mar 02, 2007 at 04:29:57PM -0800, Greg KH wrote:
> On Sat, Mar 03, 2007 at 01:27:07AM +0100, Oleg Verych wrote:
> >
> > If you can proof that it doesn't influence kernel's control above system
> > hardware. Ironically such stuff in the userspace can give additional
> > intrusion way to the
On Sat, Mar 03, 2007 at 01:27:07AM +0100, Oleg Verych wrote:
>
> If you can proof that it doesn't influence kernel's control above system
> hardware. Ironically such stuff in the userspace can give additional
> intrusion way to the kernel.
Do you know of any way to use the firmware interface to t
On Fri, Mar 02, 2007 at 02:57:36PM -0800, Greg KH wrote:
> On Fri, Mar 02, 2007 at 02:56:42AM -0600, Al Borchers wrote:
> > (resend with subject)
> >
> > Greg --
[]
> > Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
> > driver as .h files? Or should I use request_firmwar
On Fri, Mar 02, 2007 at 02:56:42AM -0600, Al Borchers wrote:
> (resend with subject)
>
> Greg --
>
> Multitech has 5 new ti_usb_3410_5052 devices that all need
> special firmware.
>
> Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
> driver as .h files? Or should I us
This is a note to let you know that I've just added the patch titled
Subject: USB: kill dead code from hub.c
to my gregkh-2.6 tree. Its filename is
usb-kill-dead-code-from-hub.c.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patc
This is a note to let you know that I've just added the patch titled
Subject: USB: kill BKL in skeleton driver
to my gregkh-2.6 tree. Its filename is
usb-kill-bkl-in-skeleton-driver.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
When I plug in a pl2303-based usb serial device, the device is
supposed to appear as /dev/tts/USB0 (character device 188, 0).
However, under kernels that I have tried from 2.6.20-git3 through
2.6.21-rc2-git1, /dev/tts/USB is created, and
attempting to open that file returns a "no such devic
On Fri, 2 Mar 2007, Oliver Neukum wrote:
> Have a delay attribute per interface and give each device an attribute
> "SuspensionState" with the permissible values "on", "auto" & "suspend"
> Handle RemoteWakeup as an orthogonal issue.
We could even arrange things so that writing "suspend" will caus
When I plug in a pl2303-based usb serial device, the device is
supposed to appear as /dev/tts/USB0 (character device 188, 0).
However, under kernels that I have tried from 2.6.20-git3 through
2.6.21-rc2-git1, /dev/tts/USB is created, and
attempting to open that file returns a "no such devic
Am Freitag, 2. März 2007 17:27 schrieb Alan Stern:
> On Thu, 1 Mar 2007, Oliver Neukum wrote:
>
> > Down an interface and it stays down. Suspend an interface and it ...
>
> ... and it stays suspended until the kernel tries to send a packet out
> through that interface or until a packet is receive
Somewhere around 2.6.18, reading or writing the sysfs attributes for the
ftdi_sio driver started causing seg faults; the wrong dev structure was
being accessed.
This patch fixes the problem, and fixes a conceptual error in the
original implementation which assumed that there was only one port
On Fri, 2 Mar 2007, Hans-Joachim Baader wrote:
> Hi,
>
> I have a Motorola A1200 smartphone now. It doesn't have a MicroSD
> card yet, only internal memory. I thought it should be possible
> to mount this internal storage but no luck so far:
>
> usb 1-2.4: new full speed USB device using ehci_hc
Hi,
I have a Motorola A1200 smartphone now. It doesn't have a MicroSD
card yet, only internal memory. I thought it should be possible
to mount this internal storage but no luck so far:
usb 1-2.4: new full speed USB device using ehci_hcd and address 11
usb 1-2.4: configuration #1 chosen from 1 cho
On Fri, 2 Mar 2007 10:22:03 +0300, "Max Dmitrichenko" <[EMAIL PROTECTED]> wrote:
> If I understand write, the only place from which the ehci_hub_control
> is called is function rh_call_control(). But it passes a pointer to
> the buffer allocated on the stack with __attribute__((aligned(4))).
> Tha
On Thu, 1 Mar 2007, Oliver Neukum wrote:
> Down an interface and it stays down. Suspend an interface and it ...
... and it stays suspended until the kernel tries to send a packet out
through that interface or until a packet is received (assuming proper
hardware wakeup support is available and ena
On Thu, 1 Mar 2007, Oliver Neukum wrote:
> > Actually I had in mind something simpler, like getting rid of the
> > GET_DESCRIPTOR_TRIES loop for i (or reducing it to one attempt using the
> > new scheme and one attempt using the old scheme) and getting rid of the
> > SET_ADDRESS_TRIES loop for j,
Hallo, Alan. Nice to meet you!
On Fri, Mar 02, 2007 at 04:15:16PM +, Alan Cox wrote:
> > > Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
> > > driver as .h files? Or should I use request_firmware?
> >
> > As far as i can see: userspace firmware helper is orphan, Gre
On Fri, 2 Mar 2007, Max Dmitrichenko wrote:
> > > > Strange ... but, ACK.
> > >
> > > It would be a good idea to track this down a little further. The comment
> > > in the code _should_ be correct. If it isn't, then something funny is
> > > going on.
>
> Why then the OHCI driver (ohci-hub.c) in
> > Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
> > driver as .h files? Or should I use request_firmware?
>
> As far as i can see: userspace firmware helper is orphan, Greg
> advertise himself for writing new drivers, all is working *somehow*,
> it will be OK to have a
On Fri, Mar 02, 2007 at 02:56:42AM -0600, Al Borchers wrote:
> (resend with subject)
>
> Greg --
>
> Multitech has 5 new ti_usb_3410_5052 devices that all need
> special firmware.
>
> Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
> driver as .h files? Or should I us
On Fri, Mar 02, 2007 at 01:53:48AM -0600, Al Borchers wrote:
> Oleg --
>
> Comments in line below.
>
> Quoting Oleg Verych <[EMAIL PROTECTED]>:
>
> > pp-by: Oleg Verych
> > ---
[]
> > -/* Firmware image header */
> > -struct ti_firmware_header {
> > - __le16 wLength;
> > - __u8bCheckSum
David Brownell wrote:
On Monday 19 February 2007 8:59 am, Raphael Assenat wrote:
How about adding an OHCI_QUIRK_NO_RH_SUSPEND flag in struct ohci_hcd
and using it to disable suspend for this chip? The flag can be set
automatically in ohci-pci.c. The only thing I'm not sure about is
the appr
On Fri, 2 Mar 2007, Robert Marquardt wrote:
> Put all Code Mercenaries (VID 0x07c0) IOWarriors (PIDs 0x1500 to 0x15ff)
> on the HID blacklist. The range of PIDs has been reserved for
> IOWarriors. Only 5 PIDs are really used yet.
> The diff is from drivers/usb/input/hid-core.c of 2.6.21-rc2
> Si
Put all Code Mercenaries (VID 0x07c0) IOWarriors (PIDs 0x1500 to 0x15ff)
on the HID blacklist. The range of PIDs has been reserved for
IOWarriors. Only 5 PIDs are really used yet.
The diff is from drivers/usb/input/hid-core.c of 2.6.21-rc2
Signed-off-by: Robert Marquardt <[EMAIL PROTECTED]>
On Fri, 2 Mar 2007, Robert Marquardt wrote:
> > Thanks. Could you please resubmit with proper Signed-off-by line, so
> > that I could merge it into the HID tree?
> I am still a kernel newbie. Tell me how.
Basically just add a Signed-off-by: line(s) to the patch, denoting you or
other people, wh
On Fri, 2 Mar 2007, Robert Marquardt wrote:
> The change puts all Code Mercenaries (VID 0x07c0) IOWarriors (PIDs 0x1500 to
> 0x15ff) on the blacklist. The range of PIDs has been reserved for IOWarriors.
> Only 5 PIDs are really used yet.
> The diff is from drivers/usb/input/hid-core.c of 2.6.21-rc
On Thu, 1 Mar 2007 13:08:57 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Thursday 01 March 2007 6:32 am, Milan Svoboda wrote:
> > This patch adds second parameter to gpio_direction_output function.
> > This allows users to specify default output level.
> >
> > Patch covers pxa and ixp4xx
(resend with subject)
Greg --
Multitech has 5 new ti_usb_3410_5052 devices that all need
special firmware.
Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
driver as .h files? Or should I use request_firmware?
Obviously including them in the driver would be easier fo
Greg --
Multitech has 5 new ti_usb_3410_5052 devices that all need
special firmware.
Is it ok to include the 5 new firmware images in the ti_usb_3410_5052
driver as .h files? Or should I use request_firmware?
Obviously including them in the driver would be easier for users,
and that is what I
I'm sorry, I forget to 'quilt refresh' so previous mail contains old
version. Use this patch please.
This patch lets the pxa2xx_udc to use the generic gpio layer.
Apply it on top of [patch 2.6.21-rc1] pxa2xx_udc: cleanups, use
platform_get_irq,
on top of patch to make ixp4xx provide generic gpi
This patch lets the pxa2xx_udc to use the generic gpio layer.
Apply it on top of [patch 2.6.21-rc1] pxa2xx_udc: cleanups, use
platform_get_irq,
on top of patch to make ixp4xx provide generic gpio support (already
sent to Russell's patch system) and on top of David's [patch 2.6.20-rc2]
gpio_dire
On Thu, 2007-03-01 at 19:48 -0800, Pete Zaitcev wrote:
> > @@ -441,7 +441,7 @@ static void mon_bin_event(struct mon_rea
> > /* We use the fact that usb_pipein() returns 0x80 */
> > ep->epnum = usb_pipeendpoint(urb->pipe) | usb_pipein(urb->pipe);
> > ep->devnum = usb_pipedevice(urb->pipe
Since Greg did not like my idea of changing the HID blacklist to ranges
of PIDs i offer the minimal change for our devices.
I still think the idea of ranges in the blacklist is a good one. It
would make the handling more uniform. No special code for Wacom and our
devices needed then.
The chang
Oleg --
Ah... Now I see 0x01E and 0xA1B. Clever.
-- Al
Quoting Oleg Verych <[EMAIL PROTECTED]>:
> pp-by: Oleg Verych
> ---
> i.e. no more uGLYdev with sysfs
>
> Alan, i'm looking forward to deal with this crutch :-E
>
> drivers/usb/serial/ti_usb_3410_5052.c |6 +++---
> 1 file changed,
Oleg --
Quoting Oleg Verych <[EMAIL PROTECTED]>:
> pp-by: Oleg Verych
> ---
> i.e. no more uGLYdev with sysfs
>
> Alan, i'm looking forward to deal with this crutch :-E
>
> drivers/usb/serial/ti_usb_3410_5052.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-2
38 matches
Mail list logo
