usbfs: struct async is a fixed size structure

[Pete Zaitcev]

The ISO descriptors are allocated separately in proc_submiturb for a fetch
from user mode, then tucked at the end of URB. This seems like a dead code.

Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 1f4f6d0..d51980a 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -210,9 +210,9 @@ err:
 
 static struct async *alloc_async(unsigned int numisoframes)
 {
-unsigned int assize = sizeof(struct async) + numisoframes * 
sizeof(struct usb_iso_packet_descriptor);
-struct async *as = kzalloc(assize, GFP_KERNEL);
+   struct async *as;
 
+   as = kzalloc(sizeof(struct async), GFP_KERNEL);
 if (!as)
 return NULL;
as->urb = usb_alloc_urb(numisoframes, GFP_KERNEL);
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

clutter in /var/log/messages (drivers/usb/serial/usb-serial.c)

[devzero]

Hello !

besides some other drivers, there is usb-serial which always prints kernel 
messages containing path and module sourcefile information.

some (maybe worst case) example:

modprobe keyspan:
 usbcore: registered new interface driver usbserial
 drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
 usbcore: registered new interface driver usbserial_generic
 drivers/usb/serial/usb-serial.c: USB Serial Driver core
 drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan - 
(without firmware)
 drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 1 
port adapter
 drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 2 
port adapter
 drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 4 
port adapter
 usbcore: registered new interface driver keyspan
 drivers/usb/serial/keyspan.c: v1.1.5:Keyspan USB to Serial Converter Driver

modprobe -r keyspan:
 usbcore: deregistering interface driver keyspan
 drivers/usb/serial/usb-serial.c: USB Serial deregistering driver Keyspan - 
(without firmware)
 drivers/usb/serial/usb-serial.c: USB Serial deregistering driver Keyspan 1 
port adapter
 drivers/usb/serial/usb-serial.c: USB Serial deregistering driver Keyspan 2 
port adapter
 drivers/usb/serial/usb-serial.c: USB Serial deregistering driver Keyspan 4 
port adapter
 usbcore: deregistering interface driver usbserial_generic
 drivers/usb/serial/usb-serial.c: USB Serial deregistering driver generic
 usbcore: deregistering interface driver usbserial

from my admin`s point of view, "drivers/usb/serial/usb-serial.c" is useless 
clutter which generates an overhead of ~30% here and makes reading dmesg more 
difficult.

is there a special reason why there is a path to a sourcefile being printed 
here ?

what`s the advantage of having this and not just "usb-serial:" instead ?
can this probable be optimized (as most drivers only print  "drivername:" 
anyway) ?

regards
roland
___
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=00

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/5] USB Kconfig: Reorganize USB Kconfig Menu

[Al Boldi]

Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device Driver
Menu.  This helps the USB Kconfig Menu to be more logical/usable.

Patchset against 2.6.23

 arch/arm/Kconfig|2 ++
 arch/v850/Kconfig   |2 ++
 drivers/Kconfig |2 ++
 drivers/usb/Kconfig |   26 --
 drivers/usb/atm/Kconfig |   12 ++--
 drivers/usb/class/Kconfig   |6 +-
 drivers/usb/core/Kconfig|7 +++
 drivers/usb/gadget/Kconfig  |   10 +-
 drivers/usb/host/Kconfig|3 ++-
 drivers/usb/image/Kconfig   |7 ++-
 drivers/usb/misc/Kconfig|6 +-
 drivers/usb/serial/Kconfig  |   10 --
 drivers/usb/storage/Kconfig |   25 ++---
 13 files changed, 72 insertions(+), 46 deletions(-)



Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] USB Kconfig: Select ATM for USB DSL modem support

[Al Boldi]

Select ATM for USB DSL modem support.


Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>

---

--- 23.a/drivers/usb/atm/Kconfig
+++ 23.b/drivers/usb/atm/Kconfig
@@ -4,7 +4,8 @@
 
 menuconfig USB_ATM
tristate "USB DSL modem support"
-   depends on USB && ATM
+   depends on USB && NET
+   select ATM
select CRC32
default n
help

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] USB Kconfig: Reorganize USB Kconfig Menu

[Al Boldi]

Reorganize USB Kconfig Menu, and move USB_GADGET out into the Device Driver
Menu.

Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>

---

--- 23.a/drivers/Kconfig
+++ 23.b/drivers/Kconfig
@@ -70,6 +70,8 @@ source "drivers/hid/Kconfig"
 
 source "drivers/usb/Kconfig"
 
+source "drivers/usb/gadget/Kconfig"
+
 source "drivers/mmc/Kconfig"
 
 source "drivers/leds/Kconfig"
--- 23.a/drivers/usb/Kconfig
+++ 23.b/drivers/usb/Kconfig
@@ -2,8 +2,8 @@
 # USB device configuration
 #
 
-menuconfig USB_SUPPORT
-   bool "USB support"
+config USB_SUPPORT
+   bool
depends on HAS_IOMEM
default y
---help---
@@ -52,8 +52,8 @@ config USB_ARCH_HAS_EHCI
default PCI
 
 # ARM SA chips have a non-PCI based "OHCI-compatible" USB host interface.
-config USB
-   tristate "Support for Host-side USB"
+menuconfig USB
+   tristate "Host-side USB"
depends on USB_ARCH_HAS_HCD
---help---
  Universal Serial Bus (USB) is a specification for a serial bus
@@ -87,21 +87,16 @@ config USB
  To compile this driver as a module, choose M here: the
  module will be called usbcore.
 
+if USB
+
 source "drivers/usb/core/Kconfig"
 
 source "drivers/usb/host/Kconfig"
 
-source "drivers/usb/class/Kconfig"
-
 source "drivers/usb/storage/Kconfig"
 
-source "drivers/usb/image/Kconfig"
-
 source "drivers/usb/mon/Kconfig"
 
-comment "USB port drivers"
-   depends on USB
-
 config USB_USS720
tristate "USS720 parport driver"
depends on USB && PARPORT
@@ -133,10 +128,13 @@ config USB_USS720
 
 source "drivers/usb/serial/Kconfig"
 
-source "drivers/usb/misc/Kconfig"
-
 source "drivers/usb/atm/Kconfig"
 
-source "drivers/usb/gadget/Kconfig"
+source "drivers/usb/class/Kconfig"
+
+source "drivers/usb/image/Kconfig"
+
+source "drivers/usb/misc/Kconfig"
 
+endif # USB
 endif # USB_SUPPORT
--- 23.a/drivers/usb/serial/Kconfig
+++ 23.b/drivers/usb/serial/Kconfig
@@ -2,10 +2,7 @@
 # USB Serial device configuration
 #
 
-menu "USB Serial Converter support"
-   depends on USB!=n
-
-config USB_SERIAL
+menuconfig USB_SERIAL
tristate "USB Serial Converter support"
depends on USB
---help---
@@ -20,6 +17,8 @@ config USB_SERIAL
  To compile this driver as a module, choose M here: the
  module will be called usbserial.
 
+if USB_SERIAL
+
 config USB_SERIAL_CONSOLE
bool "USB Serial Console device support (EXPERIMENTAL)"
depends on USB_SERIAL=y && EXPERIMENTAL
@@ -581,5 +580,4 @@ config USB_EZUSB
default y
 
 
-endmenu
-
+endif # USB_SERIAL
--- 23.a/drivers/usb/core/Kconfig
+++ 23.b/drivers/usb/core/Kconfig
@@ -1,6 +1,12 @@
 #
 # USB Core configuration
 #
+menuconfig USB_CORE_MENU
+   bool "USB Core Config"
+   depends on USB
+
+if USB_CORE_MENU
+
 config USB_DEBUG
bool "USB verbose debug messages"
depends on USB
@@ -142,3 +148,4 @@ config USB_OTG_BLACKLIST_HUB
  external hubs.  OTG hosts are allowed to reduce hardware
  and software costs by not supporting external hubs.
 
+endif # USB_CORE_MENU
--- 23.a/drivers/usb/host/Kconfig
+++ 23.b/drivers/usb/host/Kconfig
@@ -1,7 +1,7 @@
 #
 # USB Host Controller Drivers
 #
-comment "USB Host Controller Drivers"
+menu "USB Host Controller Drivers"
depends on USB
 
 config USB_EHCI_HCD
@@ -248,3 +248,4 @@ config USB_R8A66597_HCD
  To compile this driver as a module, choose M here: the
  module will be called r8a66597-hcd.
 
+endmenu
--- 23.a/drivers/usb/class/Kconfig
+++ 23.b/drivers/usb/class/Kconfig
@@ -1,9 +1,12 @@
 #
 # USB Class driver configuration
 #
-comment "USB Device Class drivers"
+menuconfig USB_DEVICE_CLASS_MENU
+   bool "USB Device Class drivers"
depends on USB
 
+if USB_DEVICE_CLASS_MENU
+
 config USB_ACM
tristate "USB Modem (CDC ACM) support"
depends on USB
@@ -29,3 +32,4 @@ config USB_PRINTER
  To compile this driver as a module, choose M here: the
  module will be called usblp.
 
+endif # USB_DEVICE_CLASS_MENU
--- 23.a/drivers/usb/gadget/Kconfig
+++ 23.b/drivers/usb/gadget/Kconfig
@@ -12,10 +12,8 @@
 # With help from a special transceiver and a "Mini-AB" jack, systems with
 # both kinds of controller can also support "USB On-the-Go" (CONFIG_USB_OTG).
 #
-menu "USB Gadget Support"
-
-config USB_GADGET
-   tristate "Support for USB Gadgets"
+menuconfig USB_GADGET
+   tristate "Peripheral-side USB"
help
   USB is a master/slave protocol, organized with one master
   host (such as a PC) controlling up to 127 peripheral devices.
@@ -42,6 +40,8 @@ config USB_GADGET
   For more information, see  and
   the kernel DocBook documentation for this API.
 
+if USB_GADGET
+
 config USB_GADGET_DEBUG
boolean "Debugging messages"
depends on USB_GADGET && DEBUG_KE

Re: [PATCH 4/5] USB Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm

[Al Boldi]

From: David Brownell <[EMAIL PROTECTED]>

Source "drivers/usb/gadget/Kconfig" for ARCH=arm.


Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>

---

--- 23.a/arch/arm/Kconfig
+++ 23.b/arch/arm/Kconfig
@@ -1049,6 +1049,8 @@ source "drivers/hid/Kconfig"
 
 source "drivers/usb/Kconfig"
 
+source "drivers/usb/gadget/Kconfig"
+
 source "drivers/mmc/Kconfig"
 
 source "drivers/rtc/Kconfig"

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Al Boldi]

Select SCSI for USB Mass Storage support.


Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>

---

--- 23.a/drivers/usb/storage/Kconfig
+++ 23.b/drivers/usb/storage/Kconfig
@@ -2,14 +2,10 @@
 # USB Storage driver configuration
 #
 
-comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"
-   depends on USB
-comment "also be needed; see USB_STORAGE Help for more information"
-   depends on USB
-
 menuconfig USB_STORAGE
tristate "USB Mass Storage support"
-   depends on USB && SCSI
+   depends on USB
+   select SCSI
---help---
  Say Y here if you want to connect USB mass storage devices to your
  computer's USB port. This is the driver you need for USB
@@ -18,13 +14,17 @@ menuconfig USB_STORAGE
  similar devices. This driver may also be used for some cameras
  and card readers.
 
- This option depends on 'SCSI' support being enabled, but you
- probably also need 'SCSI device support: SCSI disk support'
+ This option selects 'SCSI' support , but you probably
+ also need 'SCSI device support: SCSI disk support'
  (BLK_DEV_SD) for most USB storage devices.
 
  To compile this driver as a module, choose M here: the
  module will be called usb-storage.
 
+if USB_STORAGE
+comment "NOTE: USB_STORAGE selects SCSI, but 'SCSI disk support' may"
+comment "also be needed; see USB_STORAGE Help for more information"
+
 config USB_STORAGE_DEBUG
bool "USB Mass Storage verbose debug"
depends on USB_STORAGE
@@ -147,6 +147,8 @@ config USB_STORAGE_KARMA
  on the resulting scsi device node returns the Karma to normal
  operation.
 
+endif # USB_STORAGE
+
 config USB_LIBUSUAL
bool "The shared table of common (or usual) storage devices"
depends on USB

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] USB Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=v850

[Al Boldi]

Source "drivers/usb/gadget/Kconfig" for ARCH=v850.


Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>

---

--- 23.a/arch/v850/Kconfig
+++ 23.b/arch/v850/Kconfig
@@ -331,6 +331,8 @@ source "sound/Kconfig"
 
 source "drivers/usb/Kconfig"
 
+source "drivers/usb/gadget/Kconfig"
+
 source "arch/v850/Kconfig.debug"
 
 source "security/Kconfig"

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Can ARM use drivers/Kconfig [Was: Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm]

[Sam Ravnborg]

On Sat, Jan 05, 2008 at 06:42:52PM +0300, Al Boldi wrote:
> 
> From: David Brownell <[EMAIL PROTECTED]>
> 
> Source "drivers/usb/gadget/Kconfig" for ARCH=arm.
> 
> 
> Cc: David Brownell <[EMAIL PROTECTED]>
> Cc: Greg KH <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
> 
> ---
> 
> --- 23.a/arch/arm/Kconfig
> +++ 23.b/arch/arm/Kconfig
> @@ -1049,6 +1049,8 @@ source "drivers/hid/Kconfig"
>  
>  source "drivers/usb/Kconfig"
>  
> +source "drivers/usb/gadget/Kconfig"
> +
>  source "drivers/mmc/Kconfig"
>  
>  source "drivers/rtc/Kconfig"

What is preventing ARM from using drivers/Kconfig?
That a better fix IMO.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[David Brownell]

On Saturday 05 January 2008, Al Boldi wrote:
> +comment "NOTE: USB_STORAGE selects SCSI, but 'SCSI disk support' may"
> +comment "also be needed; see USB_STORAGE Help for more information"
> +
>  config USB_STORAGE_DEBUG

Better ... but wouldn't something like

comment "You probably also need to enable 'SCSI disk support'"
depends on !BLK_DEV_SD

be better?  No point in telling people stuff they don't need to know...
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Randy Dunlap]

On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:

> 
> Select SCSI for USB Mass Storage support.
> 
> 
> Cc: David Brownell <[EMAIL PROTECTED]>
> Cc: Greg KH <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
> 
> ---
> 
> --- 23.a/drivers/usb/storage/Kconfig
> +++ 23.b/drivers/usb/storage/Kconfig
> @@ -2,14 +2,10 @@
>  # USB Storage driver configuration
>  #
>  
> -comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"
> - depends on USB
> -comment "also be needed; see USB_STORAGE Help for more information"
> - depends on USB
> -
>  menuconfig USB_STORAGE
>   tristate "USB Mass Storage support"
> - depends on USB && SCSI
> + depends on USB
> + select SCSI

We try not to use 'select' on subsystems and try to limit its use
to library-like code that is relatively small.  Selecting SCSI
breaks both of those efforts.
Furthermore, we try to give the user help here in both the
comments and help text.

NAK as far as I am concerned.

>   ---help---
> Say Y here if you want to connect USB mass storage devices to your
> computer's USB port. This is the driver you need for USB
> @@ -18,13 +14,17 @@ menuconfig USB_STORAGE
> similar devices. This driver may also be used for some cameras
> and card readers.
>  
> -   This option depends on 'SCSI' support being enabled, but you
> -   probably also need 'SCSI device support: SCSI disk support'
> +   This option selects 'SCSI' support , but you probably
> +   also need 'SCSI device support: SCSI disk support'
> (BLK_DEV_SD) for most USB storage devices.
>  
> To compile this driver as a module, choose M here: the
> module will be called usb-storage.
>  
> +if USB_STORAGE
> +comment "NOTE: USB_STORAGE selects SCSI, but 'SCSI disk support' may"
> +comment "also be needed; see USB_STORAGE Help for more information"
> +
>  config USB_STORAGE_DEBUG
>   bool "USB Mass Storage verbose debug"
>   depends on USB_STORAGE
> @@ -147,6 +147,8 @@ config USB_STORAGE_KARMA
> on the resulting scsi device node returns the Karma to normal
> operation.
>  
> +endif # USB_STORAGE
> +
>  config USB_LIBUSUAL
>   bool "The shared table of common (or usual) storage devices"
>   depends on USB



---
~Randy
desserts:  http://www.xenotime.net/linux/recipes/
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] USB Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm

[David Brownell]

> --- 23.a/arch/arm/Kconfig
> +++ 23.b/arch/arm/Kconfig
> @@ -1049,6 +1049,8 @@ source "drivers/hid/Kconfig"
>  
>  source "drivers/usb/Kconfig"
>  
> +source "drivers/usb/gadget/Kconfig"
> +
>  source "drivers/mmc/Kconfig"
>  
>  source "drivers/rtc/Kconfig"
> 


Better IMO to include such updates with the patch that reorganizes
that part of the menu ... it's conceptually a single change, and
fragmenting it will cause bisection problems.

In fact, moving the gadget Kconfig in a separate step would make
your main changes more clear too.
 
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can ARM use drivers/Kconfig [Was: Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm]

[Sam Ravnborg]

On Sat, Jan 05, 2008 at 08:31:24PM +, Russell King wrote:
> On Sat, Jan 05, 2008 at 08:20:00PM +0100, Sam Ravnborg wrote:
> > On Sat, Jan 05, 2008 at 06:42:52PM +0300, Al Boldi wrote:
> > > 
> > > From: David Brownell <[EMAIL PROTECTED]>
> > > 
> > > Source "drivers/usb/gadget/Kconfig" for ARCH=arm.
> > > 
> > > 
> > > Cc: David Brownell <[EMAIL PROTECTED]>
> > > Cc: Greg KH <[EMAIL PROTECTED]>
> > > Cc: Andrew Morton <[EMAIL PROTECTED]>
> > > Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
> > > 
> > > ---
> > > 
> > > --- 23.a/arch/arm/Kconfig
> > > +++ 23.b/arch/arm/Kconfig
> > > @@ -1049,6 +1049,8 @@ source "drivers/hid/Kconfig"
> > >  
> > >  source "drivers/usb/Kconfig"
> > >  
> > > +source "drivers/usb/gadget/Kconfig"
> > > +
> > >  source "drivers/mmc/Kconfig"
> > >  
> > >  source "drivers/rtc/Kconfig"
> > 
> > What is preventing ARM from using drivers/Kconfig?
> > That a better fix IMO.
> 
> Not everything in drivers/ is suitable for every ARM configuration.  It
> was felt at the time better for ARM to remain separate because people
> didn't want to pollute drivers/Kconfig with the ARM specific conditionals.
> 
Today we would have used HAVE_ for the problematic parts and thus
it would have been easy to not select what ARM does not support.
But unfortunately thats not how it got designed.


It would be nice to revist one day to see how much is actually needed
to cleanly supprt ARM in drivers/Kconfig.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can ARM use drivers/Kconfig [Was: Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm]

[Russell King]

On Sat, Jan 05, 2008 at 08:20:00PM +0100, Sam Ravnborg wrote:
> On Sat, Jan 05, 2008 at 06:42:52PM +0300, Al Boldi wrote:
> > 
> > From: David Brownell <[EMAIL PROTECTED]>
> > 
> > Source "drivers/usb/gadget/Kconfig" for ARCH=arm.
> > 
> > 
> > Cc: David Brownell <[EMAIL PROTECTED]>
> > Cc: Greg KH <[EMAIL PROTECTED]>
> > Cc: Andrew Morton <[EMAIL PROTECTED]>
> > Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
> > 
> > ---
> > 
> > --- 23.a/arch/arm/Kconfig
> > +++ 23.b/arch/arm/Kconfig
> > @@ -1049,6 +1049,8 @@ source "drivers/hid/Kconfig"
> >  
> >  source "drivers/usb/Kconfig"
> >  
> > +source "drivers/usb/gadget/Kconfig"
> > +
> >  source "drivers/mmc/Kconfig"
> >  
> >  source "drivers/rtc/Kconfig"
> 
> What is preventing ARM from using drivers/Kconfig?
> That a better fix IMO.

Not everything in drivers/ is suitable for every ARM configuration.  It
was felt at the time better for ARM to remain separate because people
didn't want to pollute drivers/Kconfig with the ARM specific conditionals.

(mtd is conditional because it's not supported on ARM CPUs without
alignment trap support.)

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Stefan Richter]

Al Boldi wrote:
> -comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"
> - depends on USB
> -comment "also be needed; see USB_STORAGE Help for more information"
> - depends on USB

Your patch description fails to mention what is wrong with the existing
solution.
-- 
Stefan Richter
-=-==--- ---= --=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2.6.24-rc6-git] usb: at91_udc uses generic GPIO calls; minor cleanup

[David Brownell]

From: David Brownell <[EMAIL PROTECTED]>

Various small at91_udc cleanups:

 - Use generic GPIO calls, not older platform-specific ones
 - Use gpio_request()/gpio_free()
 - Use VERBOSE_DEBUG convention, not older VERBOSE
 - Fix sparse complaint about parameter type (changed to gfp_t)
 - Add missing newline to some rarely-seen debug messages
 - Fix some old cleanup bugs on probe() fault paths

Also add a mechanism whereby rm9200 gpios can drive the D+ pullup
through an inverting transistor, based on a patch from Steve Birtles.
Most UDC drivers supporting a GPIO based pullup should probably have
such an option, but testing it requries such a board in hand!

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Updated with better fixes for those cleanup bugs, and to include the
support for active-low rm9200 VBUS pullup.

 drivers/usb/gadget/at91_udc.c |   79 --
 drivers/usb/gadget/at91_udc.h |2 
 include/asm-arm/arch-at91/board.h |3 -
 3 files changed, 63 insertions(+), 21 deletions(-)

--- at91.orig/drivers/usb/gadget/at91_udc.c 2008-01-05 12:48:16.0 
-0800
+++ at91/drivers/usb/gadget/at91_udc.c  2008-01-05 13:07:59.0 -0800
@@ -21,8 +21,7 @@
  * Boston, MA  02111-1307, USA.
  */
 
-#undef DEBUG
-#undef VERBOSE
+#undef VERBOSE_DEBUG
 #undef PACKET_TRACE
 
 #include 
@@ -46,8 +45,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 #include 
 #include 
@@ -580,7 +579,7 @@ static int at91_ep_disable (struct usb_e
  */
 
 static struct usb_request *
-at91_ep_alloc_request(struct usb_ep *_ep, unsigned int gfp_flags)
+at91_ep_alloc_request(struct usb_ep *_ep, gfp_t gfp_flags)
 {
struct at91_request *req;
 
@@ -881,6 +880,8 @@ static void clk_off(struct at91_udc *udc
  */
 static void pullup(struct at91_udc *udc, int is_on)
 {
+   int active = !udc->board.pullup_active_low;
+
if (!udc->enabled || !udc->vbus)
is_on = 0;
DBG("%sactive\n", is_on ? "" : "in");
@@ -890,7 +891,7 @@ static void pullup(struct at91_udc *udc,
at91_udp_write(udc, AT91_UDP_ICR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, 0);
if (cpu_is_at91rm9200())
-   at91_set_gpio_value(udc->board.pullup_pin, 1);
+   gpio_set_value(udc->board.pullup_pin, active);
else if (cpu_is_at91sam9260() || cpu_is_at91sam9263()) {
u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
 
@@ -908,7 +909,7 @@ static void pullup(struct at91_udc *udc,
at91_udp_write(udc, AT91_UDP_IDR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
if (cpu_is_at91rm9200())
-   at91_set_gpio_value(udc->board.pullup_pin, 0);
+   gpio_set_value(udc->board.pullup_pin, !active);
else if (cpu_is_at91sam9260() || cpu_is_at91sam9263()) {
u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);
 
@@ -1551,7 +1552,7 @@ static irqreturn_t at91_vbus_irq(int irq
 
/* vbus needs at least brief debouncing */
udelay(10);
-   value = at91_get_gpio_value(udc->board.vbus_pin);
+   value = gpio_get_value(udc->board.vbus_pin);
if (value != udc->vbus)
at91_vbus_session(&udc->gadget, value);
 
@@ -1645,12 +1646,12 @@ static int __init at91udc_probe(struct p
}
 
if (pdev->num_resources != 2) {
-   DBG("invalid num_resources");
+   DBG("invalid num_resources\n");
return -ENODEV;
}
if ((pdev->resource[0].flags != IORESOURCE_MEM)
|| (pdev->resource[1].flags != IORESOURCE_IRQ)) {
-   DBG("invalid resource type");
+   DBG("invalid resource type\n");
return -ENODEV;
}
 
@@ -1672,10 +1673,26 @@ static int __init at91udc_probe(struct p
udc->pdev = pdev;
udc->enabled = 0;
 
+   /* rm9200 needs manual D+ pullup; off by default */
+   if (cpu_is_at91rm9200()) {
+   if (udc->board.pullup_pin <= 0) {
+   DBG("no D+ pullup?\n");
+   retval = -ENODEV;
+   goto fail0;
+   }
+   retval = gpio_request(udc->board.pullup_pin, "udc_pullup");
+   if (retval) {
+   DBG("D+ pullup is busy\n");
+   goto fail0;
+   }
+   gpio_direction_output(udc->board.pullup_pin,
+   udc->board.pullup_active_low);
+   }
+
udc->udp_baseaddr = ioremap(res->start, res->end - res->start + 1);
if (!udc->udp_baseaddr) {
-   release_mem_region(res->start, res->end - res->start + 1);
-   return -ENOMEM;
+   retval = -ENOMEM;
+   goto fail0a;
}
 
udc_reinit(ud

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Adrian Bunk]

On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote:
> On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:
> 
> > 
> > Select SCSI for USB Mass Storage support.
> > 
> > 
> > Cc: David Brownell <[EMAIL PROTECTED]>
> > Cc: Greg KH <[EMAIL PROTECTED]>
> > Cc: Andrew Morton <[EMAIL PROTECTED]>
> > Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
> > 
> > ---
> > 
> > --- 23.a/drivers/usb/storage/Kconfig
> > +++ 23.b/drivers/usb/storage/Kconfig
> > @@ -2,14 +2,10 @@
> >  # USB Storage driver configuration
> >  #
> >  
> > -comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"
> > -   depends on USB
> > -comment "also be needed; see USB_STORAGE Help for more information"
> > -   depends on USB
> > -
> >  menuconfig USB_STORAGE
> > tristate "USB Mass Storage support"
> > -   depends on USB && SCSI
> > +   depends on USB
> > +   select SCSI
> 
> We try not to use 'select' on subsystems and try to limit its use
> to library-like code that is relatively small.  Selecting SCSI
> breaks both of those efforts.
>...

_You_ are trying to do this.

For kconfig users, "select" is _much_ better than sending them through 
different menus.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can ARM use drivers/Kconfig [Was: Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm]

[Russell King]

On Sat, Jan 05, 2008 at 09:54:24PM +0100, Sam Ravnborg wrote:
> On Sat, Jan 05, 2008 at 08:31:24PM +, Russell King wrote:
> > Not everything in drivers/ is suitable for every ARM configuration.  It
> > was felt at the time better for ARM to remain separate because people
> > didn't want to pollute drivers/Kconfig with the ARM specific conditionals.
> > 
> Today we would have used HAVE_ for the problematic parts and thus
> it would have been easy to not select what ARM does not support.
> But unfortunately thats not how it got designed.
> 
> 
> It would be nice to revist one day to see how much is actually needed
> to cleanly supprt ARM in drivers/Kconfig.

You could diff the two Kconfig files - I try to keep them so they list
the same Kconfigs in the same order to keep the diff size down.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Sam Ravnborg]

On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
> On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote:
> > On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:
> > 
> > > 
> > > Select SCSI for USB Mass Storage support.
> > > 
> > > 
> > > Cc: David Brownell <[EMAIL PROTECTED]>
> > > Cc: Greg KH <[EMAIL PROTECTED]>
> > > Cc: Andrew Morton <[EMAIL PROTECTED]>
> > > Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
> > > 
> > > ---
> > > 
> > > --- 23.a/drivers/usb/storage/Kconfig
> > > +++ 23.b/drivers/usb/storage/Kconfig
> > > @@ -2,14 +2,10 @@
> > >  # USB Storage driver configuration
> > >  #
> > >  
> > > -comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"
> > > - depends on USB
> > > -comment "also be needed; see USB_STORAGE Help for more information"
> > > - depends on USB
> > > -
> > >  menuconfig USB_STORAGE
> > >   tristate "USB Mass Storage support"
> > > - depends on USB && SCSI
> > > + depends on USB
> > > + select SCSI
> > 
> > We try not to use 'select' on subsystems and try to limit its use
> > to library-like code that is relatively small.  Selecting SCSI
> > breaks both of those efforts.
> >...
> 
> _You_ are trying to do this.
> 
> For kconfig users, "select" is _much_ better than sending them through 
> different menus.
Only if used within the current limitations of Kconfig.
And that requires you to use select only to select symbols with
no dependencies.

In this case we do not know if BLOCK is enabled or not.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can ARM use drivers/Kconfig [Was: Kconfig: Source "drivers/usb/gadget/Kconfig" for ARCH=arm]

[Arnd Bergmann]

On Saturday 05 January 2008, Russell King wrote:
> Not everything in drivers/ is suitable for every ARM configuration.  It
> was felt at the time better for ARM to remain separate because people
> didn't want to pollute drivers/Kconfig with the ARM specific conditionals.

We made drivers/Kconfig work for s390 in the meantime, which is far more
special than arm in this regard, so I think you should try to give it
another go.

What are the main obstacles on arm that prevent you from building these
drivers?

Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Randy Dunlap]

Sam Ravnborg wrote:

On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:

On Sat, Jan 05, 2008 at 11:30:24AM -0800, Randy Dunlap wrote:

On Sat, 5 Jan 2008 18:41:39 +0300 Al Boldi wrote:


Select SCSI for USB Mass Storage support.


Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>

---

--- 23.a/drivers/usb/storage/Kconfig
+++ 23.b/drivers/usb/storage/Kconfig
@@ -2,14 +2,10 @@
 # USB Storage driver configuration
 #
 
-comment "NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may"

-   depends on USB
-comment "also be needed; see USB_STORAGE Help for more information"
-   depends on USB
-
 menuconfig USB_STORAGE
tristate "USB Mass Storage support"
-   depends on USB && SCSI
+   depends on USB
+   select SCSI

We try not to use 'select' on subsystems and try to limit its use
to library-like code that is relatively small.  Selecting SCSI
breaks both of those efforts.
...

_You_ are trying to do this.


I'd say that sometimes Andrew helps also.

For kconfig users, "select" is _much_ better than sending them through 
different menus.

Only if used within the current limitations of Kconfig.
And that requires you to use select only to select symbols with
no dependencies.


Right.  One of the main (or maybe even the only) problem(s) is
that select does not follow dependency chains.
and that no one works on that problem.


In this case we do not know if BLOCK is enabled or not.


For Aunt Tillie cases, "select" makes sense.  For other cases,
I'd argue that it makes sense for config users to know when they
do something that causes an entire subsystem to be added to their
kernel (like SCSI or NET).

--
~Randy
desserts:  http://www.xenotime.net/linux/recipes/
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Adrian Bunk]

On Sat, Jan 05, 2008 at 03:22:14PM -0800, Randy Dunlap wrote:
>...
> For Aunt Tillie cases, "select" makes sense.  For other cases,
> I'd argue that it makes sense for config users to know when they
> do something that causes an entire subsystem to be added to their
> kernel (like SCSI or NET).

We are not talking about Aunt Tillie [1] since she anyway does not build 
her own kernel.

The vast majority of kconfig users should be covered by the
"system administrator" use case. And for them it's a lot easier if they 
simply find the options for their hardware in the logical places without 
additional hassle.

Whether or not an option requires an additional subsystem like e.g. SCSI 
or SSB are hardware and implementation details we shouldn't bother 
kconfig users with.

cu
Adrian

[1] kconfig version of Godwin's law

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Which hub chip?

[Berthold Cogel]

Diego Zuccato schrieb:

Hello all.

I'd need to handle many USB devices (the more the best). So, to reduce
hubs number I'm going to use 7-port ones. I've found those, so far:
- USB2507 (SMSC)
- ISB1521 (Philips)
- μPD720113 (NEC)

The host is a Linux box. Does some1 know of possible problems with any
of these? Or have used one and recommends it? I'm not planning to use
ISO transfers, and the connected devices are full-speed (FTDI-based).

Thanks,
 Diego.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


I'm using a Belkin hub for the same reason, to reduce the number of hubs:

http://catalog.belkin.com/IWCatProductPage.process?Product_Id=158910

Hi-Speed USB 2.0 7-Port Hub
Price: about 40 Euro

I've seen no problems so far.

The hub has 5 connectors on the back and 2 on the top. The interesting 
part is that you can stack two hubs without loosing the top connectors 
of the lower hub. This is very useful if you often need to connect 
mobile devices like USB sticks or mp3 player. Each hub has it's own 
connection to the computer.


They have a new model now, that is similar to the one I use:

http://catalog.belkin.com/IWCatProductPage.process?Product_Id=357387

Berthold
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [pl2303 regression] Linux 2.6.23 breaks gpsbabel's DG-100 support

[Mirko Parthey]

On Sat, Jan 05, 2008 at 02:09:32AM +, Alan Cox wrote:
> > first segment reverted -> works OK
> > first segment applied -> breaks
> 
> So I would guess while data is being transferred your code sets the tty
> settings to the exact ones that were still in use, and this now drops
> bytes ?

Yes - as far as I can see, only VMIN and VTIME change between ioctl()s.

I made two strace logs:
* strace-OK with patch segment 1 backed out
* strace-broken with patch segment 1 applied

They are trimmed at the beginning and end, and select() calls were
removed.

I'll attach a diff between the two logs, with lots of context.
Please let me know if you need anything further.

Mirko
--- strace-OK   2008-01-06 00:26:29.0 +0100
+++ strace-broken   2008-01-06 00:26:44.0 +0100
@@ -1,55 +1,54 @@
 open("/dev/ttyUSB0", O_RDWR|O_NOCTTY)   = 3
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0x1cb2, c_lflags=0, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=255, 
c_cc="\x03\x1c\x7f\x15\x04\xff\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0x1cb2, c_lflags=0, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=255, 
c_cc="\x03\x1c\x7f\x15\x04\xff\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0x1cb2, c_lflags=0, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=255, 
c_cc="\x03\x1c\x7f\x15\x04\xff\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {c_iflags=0, c_oflags=0, c_cflags=0xcbc, 
c_lflags=0, c_line=0, c_cc[VMIN]=0, c_cc[VTIME]=0, 
c_cc="\x03\x1c\x7f\x15\x04\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0xcbc, c_lflags=0, c_line=0, c_cc[VMIN]=0, c_cc[VTIME]=0, 
c_cc="\x03\x1c\x7f\x15\x04\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0xcbc, c_lflags=0, c_line=0, c_cc[VMIN]=0, c_cc[VTIME]=0, 
c_cc="\x03\x1c\x7f\x15\x04\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0xcbc, c_lflags=0, c_line=0, c_cc[VMIN]=0, c_cc[VTIME]=0, 
c_cc="\x03\x1c\x7f\x15\x04\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_STOP or TCSETSW, {c_iflags=0, c_oflags=0, c_cflags=0x1cb2, 
c_lflags=0, c_line=0, c_cc[VMIN]=0, c_cc[VTIME]=0, 
c_cc="\x03\x1c\x7f\x15\x04\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0x1cb2, c_lflags=0, c_line=0, c_cc[VMIN]=0, c_cc[VTIME]=0, 
c_cc="\x03\x1c\x7f\x15\x04\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 write(3, "\240\242\0\3\273\0\0\0\273\260\263", 11) = 11
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0x1cb2, c_lflags=0, c_line=0, c_cc[VMIN]=0, c_cc[VTIME]=0, 
c_cc="\x03\x1c\x7f\x15\x04\x00\x00\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_START or TCSETS, {c_iflags=0, c_oflags=0, c_cflags=0x1cb2, 
c_lflags=0, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=255, 
c_cc="\x03\x1c\x7f\x15\x04\xff\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {c_iflags=0, c_oflags=0, 
c_cflags=0x1cb2, c_lflags=0, c_line=0, c_cc[VMIN]=1, c_cc[VTIME]=255, 
c_cc="\x03\x1c\x7f\x15\x04\xff\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"})
 = 0
 read(3, "\240", 1)  = 1
 read(3, "\242", 1)  = 1
 read(3, "\6", 1)= 1
 read(3, "\312", 1)  = 1
 read(3, "\273", 1)  = 1
 read(3, "\0", 1)= 1
 read(3, "\220", 1)  = 1
 read(3, "\0", 1)= 1
 read(3, "\220", 1)  = 1
 read(3, "\0", 1)= 1
 read(3, "\2", 1)= 1
 read(3, "{", 1) = 1
 read(3, "\253", 1)  = 1
 read(3, "\0", 1)= 1
 read(3, "\4", 1)= 1
 read(3, "\277", 1)  = 1
 read(3, "\247", 1)  = 1
 read(3, "\0", 1)= 1
 read(3, "\0", 1)= 1
 read(3, "\0", 1)= 1
 read(3, "\0", 1)= 1
 read(3, "\0", 1)= 1
 read(3, "\2", 1)= 1
 read(3, "~", 1) = 1
 read(3, "Z", 1) = 1
 read(3, "\0", 1)= 1
 read(3, "\4", 1)= 1
 read(3, "\277", 1)  = 1
 read(3, "\247", 1)  = 1
 read(3, "\0", 1)= 1
 read(3, "\0", 1)   

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Stefan Richter]

Adrian Bunk wrote:
> Whether or not an option requires an additional subsystem like e.g. SCSI 
> or SSB are hardware and implementation details we shouldn't bother 
> kconfig users with.

What is an implementation detail and what is not?  In the end,
everything that we configure in Kconfig is implementation details.

PS:
Kill 'select' already, and instead work on better UIs if you have got
trouble with the complexities of the dependencies graph.  The graphic
UIs including menuconfig currently work best for tree-like dependencies,
but the graph isn't a tree.  Think about how to present this properly in
an UI.  The Kconfig files are the wrong place to attack this problem.

PPS:
Really, it's *not* hard *at all* to configure a 2.6.24-rc6 kernel with
USB storage support.  I don't read linux-usb --- has there been repeated
questions how to enable usb-storage in the kernel configuration?  I can
tell you that there has been no such question about sbp2 (FireWire
storage support) in years.  Don't fix what ain't broken.  In fact, don't
/break/ what ain't broken by adding more of the (as yet) broken 'select'
everywhere.
-- 
Stefan Richter
-=-==--- ---= --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Adrian Bunk]

On Sun, Jan 06, 2008 at 01:35:21AM +0100, Stefan Richter wrote:
> Adrian Bunk wrote:
> > Whether or not an option requires an additional subsystem like e.g. SCSI 
> > or SSB are hardware and implementation details we shouldn't bother 
> > kconfig users with.
> 
> What is an implementation detail and what is not?  In the end,
> everything that we configure in Kconfig is implementation details.

With the use case "system administrator" we can expect people to know 
the name of their ethernet card and which filesystems they use, but we 
should not bother them with the fact that their network card might 
require the Sonics Silicon Backplane support.

> PS:
> Kill 'select' already, and instead work on better UIs if you have got
> trouble with the complexities of the dependencies graph.  The graphic
> UIs including menuconfig currently work best for tree-like dependencies,
> but the graph isn't a tree.  Think about how to present this properly in
> an UI.  The Kconfig files are the wrong place to attack this problem.
>...

Duplicating the structure in each UI should be an improvement?

Hardly.

> Stefan Richter

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Randy Dunlap]

Stefan Richter wrote:

Adrian Bunk wrote:
Whether or not an option requires an additional subsystem like e.g. SCSI 
or SSB are hardware and implementation details we shouldn't bother 
kconfig users with.


What is an implementation detail and what is not?  In the end,
everything that we configure in Kconfig is implementation details.

PS:
Kill 'select' already, and instead work on better UIs if you have got
trouble with the complexities of the dependencies graph.  The graphic
UIs including menuconfig currently work best for tree-like dependencies,
but the graph isn't a tree.  Think about how to present this properly in
an UI.  The Kconfig files are the wrong place to attack this problem.

PPS:
Really, it's *not* hard *at all* to configure a 2.6.24-rc6 kernel with
USB storage support.  I don't read linux-usb --- has there been repeated
questions how to enable usb-storage in the kernel configuration?  I can


I do read linux-usb.  I don't think that USB storage configuration
is a big issue (currently, without using "select").
But that's just my take on it.


tell you that there has been no such question about sbp2 (FireWire
storage support) in years.  Don't fix what ain't broken.  In fact, don't
/break/ what ain't broken by adding more of the (as yet) broken 'select'
everywhere.



--
~Randy
desserts:  http://www.xenotime.net/linux/recipes/
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WD My Book 500G external drive: error -110

[seandarcy]

I'm running Fedora 8:

uname -r
2.6.23.8-63.fc8

I connected my new Western Digital My Book 500G external drive to the 
usb port.


syslog:

Jan  5 21:53:35 testbox kernel: usb 1-4: new high speed USB device using 
ehci_hcd and address 2
Jan  5 21:53:50 testbox kernel: usb 1-4: device descriptor read/64, 
error -110
Jan  5 21:54:05 testbox kernel: usb 1-4: device descriptor read/64, 
error -110
Jan  5 21:54:05 testbox kernel: usb 1-4: new high speed USB device using 
ehci_hcd and address 3
Jan  5 21:54:20 testbox kernel: usb 1-4: device descriptor read/64, 
error -110
Jan  5 21:54:36 testbox kernel: usb 1-4: device descriptor read/64, 
error -110
Jan  5 21:54:36 testbox kernel: usb 1-4: new high speed USB device using 
ehci_hcd and address 4
Jan  5 21:54:41 testbox kernel: usb 1-4: device descriptor read/8, error 
-110

.

Any help apprecoated.

sean

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: WD My Book 500G external drive: error -110

[Alan Stern]

On Sat, 5 Jan 2008, seandarcy wrote:

> I'm running Fedora 8:
> 
> uname -r
> 2.6.23.8-63.fc8
> 
> I connected my new Western Digital My Book 500G external drive to the 
> usb port.
> 
> syslog:
> 
> Jan  5 21:53:35 testbox kernel: usb 1-4: new high speed USB device using 
> ehci_hcd and address 2
> Jan  5 21:53:50 testbox kernel: usb 1-4: device descriptor read/64, 
> error -110
> Jan  5 21:54:05 testbox kernel: usb 1-4: device descriptor read/64, 
> error -110
> Jan  5 21:54:05 testbox kernel: usb 1-4: new high speed USB device using 
> ehci_hcd and address 3
> Jan  5 21:54:20 testbox kernel: usb 1-4: device descriptor read/64, 
> error -110
> Jan  5 21:54:36 testbox kernel: usb 1-4: device descriptor read/64, 
> error -110
> Jan  5 21:54:36 testbox kernel: usb 1-4: new high speed USB device using 
> ehci_hcd and address 4
> Jan  5 21:54:41 testbox kernel: usb 1-4: device descriptor read/8, error 
> -110
> .
> 
> Any help apprecoated.

It certainly looks like either the disk drive's USB interface or your 
computer's USB controller isn't working.

You can try attaching the drive to a different computer or attaching 
different high-speed USB devices to your computer.  That should 
indicate which component is at fault.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB Kconfig: Select SCSI for USB Mass Storage support

[Al Boldi]

Sam Ravnborg wrote:
> On Sat, Jan 05, 2008 at 11:03:30PM +0200, Adrian Bunk wrote:
> > For kconfig users, "select" is _much_ better than sending them through
> > different menus.
>
> Only if used within the current limitations of Kconfig.
> And that requires you to use select only to select symbols with
> no dependencies.
>
> In this case we do not know if BLOCK is enabled or not.

Good point!  How about we solve it like this:

menuconfig USB_STORAGE
tristate "USB Mass Storage support"
-   depends on USB && SCSI
+   depends on USB && BLOCK
+   select SCSI


Thanks!

--
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2.6.24-rc6-git] usb: at91_udc uses generic GPIO calls; minor cleanup

[steve birtles]

That's great David,

I've just move forward to  rc6 ,GOD what a fiasco that was.
 I'm showing a kernel panic in the  Amtel_spi code (i thought we  
finished with that damned thing), which I have disabled for now.


But let me apply this patch  and see how it goes.

Steve



On Jan 6, 2008, at 5:21 AM, David Brownell wrote:


From: David Brownell <[EMAIL PROTECTED]>

Various small at91_udc cleanups:

 - Use generic GPIO calls, not older platform-specific ones
 - Use gpio_request()/gpio_free()
 - Use VERBOSE_DEBUG convention, not older VERBOSE
 - Fix sparse complaint about parameter type (changed to gfp_t)
 - Add missing newline to some rarely-seen debug messages
 - Fix some old cleanup bugs on probe() fault paths

Also add a mechanism whereby rm9200 gpios can drive the D+ pullup
through an inverting transistor, based on a patch from Steve Birtles.
Most UDC drivers supporting a GPIO based pullup should probably have
such an option, but testing it requries such a board in hand!

Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Updated with better fixes for those cleanup bugs, and to include the
support for active-low rm9200 VBUS pullup.

 drivers/usb/gadget/at91_udc.c |   79 ++ 
++--

 drivers/usb/gadget/at91_udc.h |2
 include/asm-arm/arch-at91/board.h |3 -
 3 files changed, 63 insertions(+), 21 deletions(-)

--- at91.orig/drivers/usb/gadget/at91_udc.c	2008-01-05  
12:48:16.0 -0800
+++ at91/drivers/usb/gadget/at91_udc.c	2008-01-05  
13:07:59.0 -0800

@@ -21,8 +21,7 @@
  * Boston, MA  02111-1307, USA.
  */

-#undef DEBUG
-#undef VERBOSE
+#undef VERBOSE_DEBUG
 #undef PACKET_TRACE

 #include 
@@ -46,8 +45,8 @@
 #include 
 #include 
 #include 
+#include 

-#include 
 #include 
 #include 
 #include 
@@ -580,7 +579,7 @@ static int at91_ep_disable (struct usb_e
  */

 static struct usb_request *
-at91_ep_alloc_request(struct usb_ep *_ep, unsigned int gfp_flags)
+at91_ep_alloc_request(struct usb_ep *_ep, gfp_t gfp_flags)
 {
struct at91_request *req;

@@ -881,6 +880,8 @@ static void clk_off(struct at91_udc *udc
  */
 static void pullup(struct at91_udc *udc, int is_on)
 {
+   int active = !udc->board.pullup_active_low;
+
if (!udc->enabled || !udc->vbus)
is_on = 0;
DBG("%sactive\n", is_on ? "" : "in");
@@ -890,7 +891,7 @@ static void pullup(struct at91_udc *udc,
at91_udp_write(udc, AT91_UDP_ICR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, 0);
if (cpu_is_at91rm9200())
-   at91_set_gpio_value(udc->board.pullup_pin, 1);
+   gpio_set_value(udc->board.pullup_pin, active);
else if (cpu_is_at91sam9260() || cpu_is_at91sam9263()) {
u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);

@@ -908,7 +909,7 @@ static void pullup(struct at91_udc *udc,
at91_udp_write(udc, AT91_UDP_IDR, AT91_UDP_RXRSM);
at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
if (cpu_is_at91rm9200())
-   at91_set_gpio_value(udc->board.pullup_pin, 0);
+   gpio_set_value(udc->board.pullup_pin, !active);
else if (cpu_is_at91sam9260() || cpu_is_at91sam9263()) {
u32 txvc = at91_udp_read(udc, AT91_UDP_TXVC);

@@ -1551,7 +1552,7 @@ static irqreturn_t at91_vbus_irq(int irq

/* vbus needs at least brief debouncing */
udelay(10);
-   value = at91_get_gpio_value(udc->board.vbus_pin);
+   value = gpio_get_value(udc->board.vbus_pin);
if (value != udc->vbus)
at91_vbus_session(&udc->gadget, value);

@@ -1645,12 +1646,12 @@ static int __init at91udc_probe(struct p
}

if (pdev->num_resources != 2) {
-   DBG("invalid num_resources");
+   DBG("invalid num_resources\n");
return -ENODEV;
}
if ((pdev->resource[0].flags != IORESOURCE_MEM)
|| (pdev->resource[1].flags != IORESOURCE_IRQ)) {
-   DBG("invalid resource type");
+   DBG("invalid resource type\n");
return -ENODEV;
}

@@ -1672,10 +1673,26 @@ static int __init at91udc_probe(struct p
udc->pdev = pdev;
udc->enabled = 0;

+   /* rm9200 needs manual D+ pullup; off by default */
+   if (cpu_is_at91rm9200()) {
+   if (udc->board.pullup_pin <= 0) {
+   DBG("no D+ pullup?\n");
+   retval = -ENODEV;
+   goto fail0;
+   }
+   retval = gpio_request(udc->board.pullup_pin, "udc_pullup");
+   if (retval) {
+   DBG("D+ pullup is busy\n");
+   goto fail0;
+   }
+   gpio_direction_output(udc->board.pullup_pin,
+   udc->board.pullup_active_low);
+