[patch 2.6.24-rc-git] usb: fix HCD Kconfig goofage
Add a missing dependency which goofs up the xconfig display. Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -79,6 +79,7 @@ config USB_EHCI_BIG_ENDIAN_DESC config USB_EHCI_FSL bool + depends on USB_EHCI_HCD select USB_EHCI_ROOT_HUB_TT default y if MPC834x || PPC_MPC831x ---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: Kingston Datatraveler
Hi, Here is the trace. I just discover some thing, If I ouput the trace to a serial port the system works fine. However If I output the trace to the disk I have the same problem as before. This trace is with the problem. c127f3e0 4628504 C Ii:1:001:1 0:128 1 = 04 c127f3e0 4628540 S Ii:1:001:1 -115:128 2 < c127f3e0 4628556 C Ii:1:001:1 0:128 1 = 04 c127f3e0 4628566 S Ii:1:001:1 -115:128 2 < c12e78a0 4628601 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4628623 C Ci:1:001:0 0 4 = 01010100 c12e78a0 4628638 S Co:1:001:0 s 23 01 0010 0002 0 c12e78a0 4628650 C Co:1:001:0 0 0 c12e78a0 4628673 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4628685 C Ci:1:001:0 0 4 = 0101 c12e78a0 4660477 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4660493 C Ci:1:001:0 0 4 = 0101 c12e78a0 4692473 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4692488 C Ci:1:001:0 0 4 = 0101 c12e78a0 4724476 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4724490 C Ci:1:001:0 0 4 = 0101 c12e78a0 4756477 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4756491 C Ci:1:001:0 0 4 = 0101 c12e78a0 4756530 S Co:1:001:0 s 23 03 0004 0002 0 c12e78a0 4756542 C Co:1:001:0 0 0 c12e78a0 4812481 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4812508 C Ci:1:001:0 0 4 = 0301 c12e78a0 4868484 S Co:1:001:0 s 23 01 0014 0002 0 c12e78a0 4868495 C Co:1:001:0 0 0 c12e78a0 4868522 S Ci:1:000:0 s 80 06 0100 0040 64 < c12e78a0 4868606 C Ci:1:000:0 0 8 = 12010001 0908 c12e78a0 4872507 S Co:1:001:0 s 23 03 0004 0002 0 c12e78a0 4872519 C Co:1:001:0 0 0 c127f3e0 4876486 C Ii:1:001:1 0:128 1 = 04 c127f3e0 4876498 S Ii:1:001:1 -115:128 2 < c12e78a0 4928487 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e78a0 4928515 C Ci:1:001:0 0 4 = 0301 c12e78a0 4984489 S Co:1:001:0 s 23 01 0014 0002 0 c12e78a0 4984502 C Co:1:001:0 0 0 c12e78a0 4984513 S Co:1:000:0 s 00 05 0002 0 c12e78a0 4987440 C Co:1:000:0 0 0 c12e78a0 5004501 S Ci:1:002:0 s 80 06 0100 0012 18 < c12e78a0 5010438 C Ci:1:002:0 0 18 = 12010001 0908 51044614 0001 0001 c12e78a0 5010465 S Ci:1:002:0 s 80 06 0200 0009 9 < c12e78a0 5015434 C Ci:1:002:0 0 9 = 09021900 010100e0 32 c12e78a0 5015459 S Ci:1:002:0 s 80 06 0200 0019 25 < c12e78a0 5022433 C Ci:1:002:0 0 25 = 09021900 010100e0 32090400 00010900 0705 81030100 ff c12e78a0 5022776 S Co:1:002:0 s 00 09 0001 0 c12e78a0 5024450 C Co:1:002:0 0 0 c12e78a0 5024723 S Ci:1:002:0 s a0 06 2900 000f 15 < c12e78a0 5026461 C Ci:1:002:0 0 9 = 09290409 00326400 00 c12e78a0 5026624 S Ci:1:002:0 s 80 00 0002 2 < c12e78a0 5027461 C Ci:1:002:0 0 2 = 0100 c12e78a0 5027502 S Ci:1:002:0 s a0 00 0004 4 < c12e78a0 5028447 C Ci:1:002:0 0 4 = c12e7920 5028550 S Co:1:002:0 s 23 03 0008 0001 0 c12e7920 5029440 C Co:1:002:0 0 0 c12e7920 5029505 S Co:1:002:0 s 23 03 0008 0002 0 c12e7920 5030436 C Co:1:002:0 0 0 c12e7920 5030465 S Co:1:002:0 s 23 03 0008 0003 0 c12e7920 5031434 C Co:1:002:0 0 0 c12e7920 5031455 S Co:1:002:0 s 23 03 0008 0004 0 c12e7920 5032433 C Co:1:002:0 0 0 c12e78a0 5132499 S Ii:1:002:1 -115:128 1 < c12e7920 5132741 S Ci:1:001:0 s a3 00 0002 0004 4 < c12e7920 5132755 C Ci:1:001:0 0 4 = 0301 c12e7920 5132777 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 5134435 C Ci:1:002:0 0 4 = 0001 c12e7920 5134482 S Ci:1:002:0 s a3 00 0002 0004 4 < c12e7920 5135420 C Ci:1:002:0 0 4 = 0001 c12e7920 5135451 S Ci:1:002:0 s a3 00 0003 0004 4 < c12e7920 5136418 C Ci:1:002:0 0 4 = 0001 c12e7920 5136440 S Ci:1:002:0 s a3 00 0004 0004 4 < c12e7920 5137417 C Ci:1:002:0 0 4 = 0001 c12e78a0 8627828 C Ii:1:002:1 0:128 1 = 02 c12e78a0 8627842 S Ii:1:002:1 -115:128 1 < c12e7920 8627882 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 8629834 C Ci:1:002:0 0 4 = 01030100 c12e7920 8629860 S Co:1:002:0 s 23 01 0010 0001 0 c12e7920 8630832 C Co:1:002:0 0 0 c12e7920 8630869 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 8631834 C Ci:1:002:0 0 4 = 0103 c12e7920 8660701 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 8661827 C Ci:1:002:0 0 4 = 0103 c12e7920 8692701 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 8693822 C Ci:1:002:0 0 4 = 0103 c12e7920 8724703 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 8725818 C Ci:1:002:0 0 4 = 0103 c12e7920 8756705 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 8757811 C Ci:1:002:0 0 4 = 0103 c12e7920 8757858 S Co:1:002:0 s 23 03 0004 0001 0 c12e7920 8758811 C Co:1:002:0 0 0 c12e7920 8772706 S Ci:1:002:0 s a3 00 0001 0004 4 < c12e7920 8773811 C Ci:1:002:0 0 4 = 03031000 c12e7920 8828709 S Co:1:002:0 s 23 01 0014 0001 0 c12e7920 8829800 C Co:1:002:0 0 0 c12e7920 8829838 S Ci:1:000:0 s 80 06 0100 0040 64 < c12e7920 8836796 C Ci:1:000:0 0 18 = 12011001 0008 3c410032 10290102 0001 c12e7920 8836821 S Co:1:002:0 s 23 03 0004 0001 0 c12e7920 8837796 C Co:1:002:0 0 0 c12e7920 8852711 S Ci:1:002:0 s a3 00 0001 0
Re: usb_storage goes haywire after writing few MiB on x86_64 with 2.6.23.11 and 2.6.24-rc5
On 20.12.2007 22:02, Alan Stern wrote:
> On Fri, 21 Dec 2007, Matthias Schniedermeyer wrote:
>
> > On 20.12.2007 13:58, Pete Zaitcev wrote:
> > > On Thu, 20 Dec 2007 21:59:52 +0100, Matthias Schniedermeyer <[EMAIL
> > > PROTECTED]> wrote:
> > >
> > > > So i will throw >dozen of the faulty hubs into the box where i collect
> > > > my e-waste.
> > >
> > > What's the chipset on the broken one? Certainly you can crack one
> > > open and have a look now that it's out of service.
> >
> > Ups. Copied the wrong set of ids.
> >
> > vendor-id: 04b4
> > product-id: 6560
> > Name: Cypress Semiconductor Corp. CY7C65640 USB-2.0 "TetraHub"
>
> How about IDs for the working hubs? They could be just as useful.
They are:
Brand: SEPIA
058f:6254 Alcor Micro Corp.
Brand: Belkin
0409:005a NEC Corp.
Brand: Hama
05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
>From the last i have 3 different, all with same IDs, so i just assume
that vendors use the same chips for their different models.
And last but not least the problem(tm) with the the AC-adapters.
Not all support "worst case" scenario. Some only provide enough power to
support 2 ports with full power and many other are only bus-powered.
The 3 hama models are exemplary for this.
One is without AC-adapter ("For Notebook").
The next is with a "half"-sized AC-adapter.
The last one has a "full"-sized AC-adapter.
The Belkin model i got supports full and the Sepia half.
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
-
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] Unbreak fsl_usb2_udc
> "David" == David Brownell <[EMAIL PROTECTED]> writes:
Hi,
David> On Tuesday 06 November 2007, Peter Korsgaard wrote:
>> Commit a4e3ef5... (USB: gadget: gadget_is_{dualspeed,otg} predicates and
>> cleanup) broke fsl_usb2_udc. udc->gadget is a struct usb_gadget, not a
>> pointer to one.
>>
>> Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
David> ACK.
David> Sorry about that. What seems to have happened is that I did the
David> test builds against all the gadget drivers, but no peripheral
David> controller was involved. Patches for the two affected ones have
David> now been submitted to Greg. (The other was omap_udc.)
This never seems to have made it's way to Linus? (the omap one did)
--
Bye, Peter Korsgaard
-
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: Kingston Datatraveler
On Fri, 21 Dec 2007 10:50:06 +, "Brian Murphy" <[EMAIL PROTECTED]> wrote: > I just discover some thing, If I ouput the trace to > a serial port the system works fine. However If I output the trace to > the disk I have the same problem as before. [...] I think your device is asking for US_FL_GO_SLOW or equivalent. It keels over on the very first read after the WP sensing: > c12e7ea0 43055373 S Bo:1:004:2 -115 31 = 55534243 0b00 0010 8a28 > 0008 00 > c12e7ea0 43056075 C Bo:1:004:2 0 31 > > c12e7720 43056160 S Bi:1:004:1 -115 4096 < > c12e7720 43162104 C Bi:1:004:1 -84 0 I had major issues with the Kingston in the past because they do not like a halt clear while not halted, but nothing like this. Perhaps it's a new cheaper revision, buggier than before. -- Pete - 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: [RFC] USB Kconfig: Declutter USB Kconfig Menu
On Dec 21 2007 16:30, Al Boldi wrote: > >The current USB Kconfig menu is rather cluttered and unorganized. > >Propose new layout as follows: > Yes, this has been done before in a lot of places, and attempts to clean up more menus is always welcome. Try to use 'menuconfig' objects so people can disable a whole menu at once without having to enter it, e.g. that USB Gadget thing down there. (You are free to post UTF-8.) > ┌ USB support > ─┐ > │ Arrow keys navigate the menu. selects submenus --->. > Highlighted letters │ > │ are hotkeys. Pressing includes, excludes, modularizes > features. Press │ > │ to exit, for Help, for Search. Legend: [*] built-in > [ ]│ > │ excluded module < > module capable > │ > │ > ┌──┐ > │ > │ │ --- USB support > │ │ > │ │ <*> Support for Host-side USB ---> > │ │ > │ │USB Host Controller Drivers ---> > │ │ > │ │USB Device Class drivers ---> > │ │ > │ │ --- NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may > │ │ > │ │ --- also be needed; see USB_STORAGE Help for more information > │ │ > │ │ <*> USB Mass Storage support ---> > │ │ > │ │ [ ] The shared table of common (or usual) storage devices > │ │ > │ │ [ ] USB Monitor > │ │ > │ │USB Serial Converter support ---> > │ │ > │ │USB DSL modem support ---> > │ │ > │ │USB Imaging devices ---> > │ │ > │ │USB Miscellaneous drivers ---> > │ │ > │ │USB Gadget Support ---> > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ │ > │ > └──┘ > │ > > ├──┤ > > │ < Exit >< Help > > │ > > └──┘ > > > >Any comments appreciated. > > >Thanks! > >-- >Al > >-- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > - 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
[no subject]
linux-usb@vger.kernel.org Bcc: Subject: Re: Regarding request for IBM camera patch to be applied to the main tree Reply-To: In-Reply-To: <[EMAIL PROTECTED]> On Fri, Dec 21, 2007 at 03:21:30PM -0600, David Hilvert wrote: > > > http://www.linux-usb.org/ibmcam/ > > > > http://auricle.dyndns.org/xvp610/ > > [Remainder of private e-mail context snipped; message has been blind-CC'ed to > the original recipients. Please CC any replies intended for me.] > > As the author of the second patch noted, I had avoided sending it to lkml due > to the difficulty of determining whether the patch is correct (e.g., having no > ill effect on other cameras), due, in turn, to lack of documentation for this > series of cameras. Perhaps dmitri could comment further on this, if he has > time and access to test on any other cameras that might fall under the 'model > 3' designation (whatever this designation might mean). The (rather old, now) > patch in question (against 2.6.1 or so, and perhaps other versions) follows; > if > I recall correctly, it was designed to minimize change lines rather than > provide for overall clarity, so that a clearer final implementation is > probably > possible. > > > diff -urN linux-2.6.1/drivers/usb/media/ibmcam.c > linux-2.6.1-patched/drivers/usb/media/ibmcam.c > --- linux-2.6.1/drivers/usb/media/ibmcam.cFri Jan 9 00:59:19 2004 > +++ linux-2.6.1-patched/drivers/usb/media/ibmcam.cFri Feb 6 14:54:33 2004 I suggest forward porting it to the latest tree and submit it to the usb video maintainers for inclusion. thanks, greg k-h - 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: [RFC] USB Kconfig: Declutter USB Kconfig Menu
> >Propose new layout as follows: > > Yes, this has been done before in a lot of places, and attempts to > clean up more menus is always welcome. > > Try to use 'menuconfig' objects so people can disable a whole menu > at once without having to enter it, e.g. that USB Gadget thing down > there. Notice that this whole menu is for "Host-side USB", except for that gadget stuff. That might usefully be labeled as "Peripheral-side USB". For that matter, it could be moved up a level in the menu, so the top level driver menu has two USB entries: Host side, and Peripheral side. The driver stacks are independent of each other, except for common data structures like what's in the header file. I think there's no real point, other than history, to having both sides share the same menu. - Dave > > ┌─┐ > > │ --- USB support │ > > │ <*> Support for Host-side USB ---> │ > > │ USB Host Controller Drivers ---> │ > > │ USB Device Class drivers --->│ > > │ --- NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may │ > > │ --- also be needed; see USB_STORAGE Help for more information │ > > │ <*> USB Mass Storage support --->│ > > │ [ ] The shared table of common (or usual) storage devices │ > > │ [ ] USB Monitor │ > > │ USB Serial Converter support --->│ > > │ USB DSL modem support ---> │ > > │ USB Imaging devices ---> │ > > │ USB Miscellaneous drivers ---> │ > > │ USB Gadget Support ---> │ > > │ │ - 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] Export suspend statistics.
This patch exports two statistics to userspace:
/sys/bus/usb/device/.../power/connected_duration
/sys/bus/usb/device/.../power/active_duration
connected_duration is the total time (in jiffies) that the device has
been connected. active_duration is the total time the device has not
been suspended. With these two statistics, tools like PowerTOP can
calculate the percentage time that a device is active, i.e. not
suspended or auto-suspended.
Users can also use the active_duration to check if a device is actually
autosuspended. Currently, they can set power/level to auto and
power/autosuspend to a positive timeout, but there's no way to know from
userspace if a device was actually autosuspended without looking at the
dmesg output. These statistics will be useful in creating an automated
userspace script to test autosuspend for USB devices.
Signed-off-by: Sarah Sharp <[EMAIL PROTECTED]>
---
Merry Christmas Arjan!
drivers/usb/core/hub.c | 14 +-
drivers/usb/core/sysfs.c | 46 ++
drivers/usb/core/usb.c |2 ++
include/linux/usb.h |2 ++
4 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index b04d232..cad04be 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1027,8 +1027,12 @@ static void recursively_mark_NOTATTACHED(struct
usb_device *udev)
if (udev->children[i])
recursively_mark_NOTATTACHED(udev->children[i]);
}
- if (udev->state == USB_STATE_SUSPENDED)
+ if (udev->state == USB_STATE_SUSPENDED) {
udev->discon_suspended = 1;
+#ifdef CONFIG_PM
+ udev->active_duration -= jiffies;
+#endif
+ }
udev->state = USB_STATE_NOTATTACHED;
}
@@ -1077,6 +1081,14 @@ void usb_set_device_state(struct usb_device *udev,
else
device_init_wakeup(&udev->dev, 0);
}
+#ifdef CONFIG_PM
+ if (udev->state == USB_STATE_SUSPENDED &&
+ new_state != USB_STATE_SUSPENDED)
+ udev->active_duration -= jiffies;
+ else if (new_state == USB_STATE_SUSPENDED &&
+ udev->state != USB_STATE_SUSPENDED)
+ udev->active_duration += jiffies;
+#endif
udev->state = new_state;
} else
recursively_mark_NOTATTACHED(udev);
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index 32bd130..554647c 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -249,6 +249,38 @@ static void remove_persist_attributes(struct device *dev)
#ifdef CONFIG_USB_SUSPEND
static ssize_t
+show_connected_duration(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_device *udev = to_usb_device(dev);
+
+ return sprintf(buf, "%lu\n", jiffies - udev->connect_time);
+}
+
+static DEVICE_ATTR(connected_duration, S_IRUGO, show_connected_duration, NULL);
+
+/*
+ * If the device is resumed, the last time the device was suspended has
+ * been pre-subtracted from active_duration. We add the current time to
+ * get the duration that the device was actually active.
+ *
+ * If the device is suspended, the active_duration is up-to-date.
+ */
+static ssize_t
+show_active_duration(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_device *udev = to_usb_device(dev);
+
+ if (udev->state != USB_STATE_SUSPENDED)
+ return sprintf(buf, "%lu\n", jiffies + udev->active_duration);
+ else
+ return sprintf(buf, "%lu\n", udev->active_duration);
+}
+
+static DEVICE_ATTR(active_duration, S_IRUGO, show_active_duration, NULL);
+
+static ssize_t
show_autosuspend(struct device *dev, struct device_attribute *attr, char *buf)
{
struct usb_device *udev = to_usb_device(dev);
@@ -365,6 +397,14 @@ static int add_power_attributes(struct device *dev)
rc = sysfs_add_file_to_group(&dev->kobj,
&dev_attr_level.attr,
power_group);
+ if (rc == 0)
+ rc = sysfs_add_file_to_group(&dev->kobj,
+ &dev_attr_connected_duration.attr,
+ power_group);
+ if (rc == 0)
+ rc = sysfs_add_file_to_group(&dev->kobj,
+ &dev_attr_active_duration.attr,
+ power_group);
}
return rc;
}
@@ -372,6 +412,12 @@ static int add_power_attributes(struct device *dev)
static void remove_power_attributes(struct device *dev)
{
sysfs_remove_file_from_group(&dev->kobj,
+ &dev_attr_active_duration.attr,
+ p
Re: Kingston Datatraveler
On Fri, 21 Dec 2007, Pete Zaitcev wrote: > On Fri, 21 Dec 2007 10:50:06 +, "Brian Murphy" <[EMAIL PROTECTED]> wrote: > > > I just discover some thing, If I ouput the trace to > > a serial port the system works fine. However If I output the trace to > > the disk I have the same problem as before. [...] > > I think your device is asking for US_FL_GO_SLOW or equivalent. > It keels over on the very first read after the WP sensing: > > > c12e7ea0 43055373 S Bo:1:004:2 -115 31 = 55534243 0b00 0010 > > 8a28 0008 00 > > c12e7ea0 43056075 C Bo:1:004:2 0 31 > > > c12e7720 43056160 S Bi:1:004:1 -115 4096 < > > c12e7720 43162104 C Bi:1:004:1 -84 0 > > I had major issues with the Kingston in the past because they do not > like a halt clear while not halted, but nothing like this. Perhaps > it's a new cheaper revision, buggier than before. That's possible. It leaves open the question of why the device works okay when no mouse nor any other HID device is attached... 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: [RFC] USB Kconfig: Declutter USB Kconfig Menu
> > Notice that this whole menu is for "Host-side USB", except for that > > gadget stuff. That might usefully be labeled as "Peripheral-side USB". > > > > For that matter, it could be moved up a level in the menu, so the top > > level driver menu has two USB entries: Host side, and Peripheral side. > > Actually, when you disable Host-side USB support, the menu looks like this: > > ┌───???──???──???───┐ > │ --- USB support │ > │ < > Support for Host-side USB ---> │ > │ USB Gadget Support ---> │ > │ │ Right, that's what I said. It makes the gadget stuff needlessly hard to find, as well as being less clear about what a "gadget" is than it really should be. > I think renaming 'USB Gadget Support' to 'Support for Peripheral-side USB' is > probably a good idea. Only for displaying in its topmost menu... > > The driver stacks are independent of each other, except for common data > > structures like what's in the header file. I think > > there's no real point, other than history, to having both sides share > > the same menu. > > They aren't. How can you say that, when you showed (right above!!) that they are??? Sure, there are submenus too. But they're clearly in the same menu. > USB Gadget Support is in its own sub-menu. And strictly > speaking, Host-side USB should be too, but some people may feel that this > would be nesting it too deep, and so it unfolds in the same menu. Which is why my suggestion was to have them both move up a level, with host and peripheral side menus nested normally: Device Drivers: ... [ ] HID devices < > Host side USB < > Peripheral side USB < > MMC/SD/SDIO card support [ ] LED support ... That way both host and peripheral side support would have their own menu, and that pointless nesting would be reduced. - Dave - 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: [RFC] USB Kconfig: Declutter USB Kconfig Menu
David Brownell wrote: > > > The driver stacks are independent of each other, except for common > > > data structures like what's in the header file. I > > > think there's no real point, other than history, to having both sides > > > share the same menu. > > > > They aren't. > > How can you say that, when you showed (right above!!) that they are??? > Sure, there are submenus too. But they're clearly in the same menu. Well, in that case even if you moved them to the upper level, then they would still be in the same menu, if that's what you mean. > > USB Gadget Support is in its own sub-menu. And strictly > > speaking, Host-side USB should be too, but some people may feel that > > this would be nesting it too deep, and so it unfolds in the same menu. > > Which is why my suggestion was to have them both move up a level, with > host and peripheral side menus nested normally: > > Device Drivers: > ... > [ ] HID devices > < > Host side USB > < > Peripheral side USB > < > MMC/SD/SDIO card support > [ ] LED support > ... > > That way both host and peripheral side support would have their own > menu, and that pointless nesting would be reduced. You mean: [ ] Host side USB [ ] Peripheral side USB Right? All this does is loose the USB menu, which was used to group them and to un-clutter the Device Drivers menu. Note: They would still be sharing the same menu, only this time it's the Device Drivers menu. I guess it's a judgment call. Let's see what others think. 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: [RFC] USB Kconfig: Declutter USB Kconfig Menu
> > Which is why my suggestion was to have them both move up a level, with > > host and peripheral side menus nested normally: > > > > Device Drivers: > > ... > > [ ] HID devices > > < > Host side USB > > < > Peripheral side USB > > < > MMC/SD/SDIO card support > > [ ] LED support > > ... > > > > That way both host and peripheral side support would have their own > > menu, and that pointless nesting would be reduced. > > You mean: > [ ] Host side USB > [ ] Peripheral side USB > > Right? Both of those subsystems are already set up with the main choice as tristate "< >//<*>". If we're simplifying the navigation, I can't see a point to requiring *two* menu actions not one. - Dave - 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
