On Thu, 26 Feb 2004 08:56:51 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> Call it creeping complexity ... plus, none of the current drivers
> needs ISO (or high bandwidth interrupt) transfers. They add a lot
> more variables, and aren't widely used in any products.
Ok, then we may leave ISO out of parenthesis. In general, what we are
discussing here are just helper routines, so if some gadget doesn't like
them it could examine the available UDC driver itself.
> It's not a "free-format" string, as I've explaned to you before.
> After the initial "ep", hardware restrictions show up like:
> * "N" for address-restricted endpoints
> * Then "in" or "out" for direction-restricted endpoints
> * Then "-bulk" or "-iso" (or rarely "-int") for type-restricted
> ones
hmm, well, the datasheet for MediaQ 1132 says endpoint 1 is restricted
to interrupt transfers, endpoints 2 and 3 are just bulk/isochronous. Not
a single word about interrupt transfers, although maybe it still can be
used for that, just not *designed* for that.
> If "name" were removed, then you'd encourage every different driver
> and controller (and gadgetfs) to come up with a different naming
> convention. That's confusing and error prone; bad diagnostics have
> a bigger cost than may immediately be apparent.
No naming convention at all: if you need endpoint names for debug
printk's, there could be provided a simple macro:
#define EP_NAME(ep) ep->num, ep->is_in ? "in" : "out"
then use like this:
printk ("something bad happened with endpoint ep%d%s\n", EP_NAME(ep));
By the way, how net2280 driver fits into this naming scheme? It has
"ep-a", "ep-b" and so on until "ep-f".
> If we ever come up with a real _need_ for a capabilities bitfield,
> we can add one. But at this point it's not needed, and there's no
> point in talking about removing a "name" field that's simple, easy
> to use, multi-purpose, and hasn't caused any problems.
Sure it haven't caused because they weren't analyzed in general until
now. I don't say its impossible to analyze them, my point is that
bitfields are easier to use (and produce less code). Am I wrong?
> Which was exactly what I described ... except for the #ifdefs, where
> I suggested macros like the mach_is_xxx() family on ARM, which would
> be optimized away by the compiler.
It's not a matter of mach_is_xxx, it's a matter of
#ifdef CONFIG_USB_GOKU, #ifdef CONFIG_USB_PXA2XX and so on. If the
driver haven't been compiled even as a module, we can ommit support for
it altogether.
> Nope, don't need to. Just check if gadget->name is "sh_udc".
> (ISO endpoints by definition don't halt, by the way.) Then
> it's known that the quirk applies.
Ok, I agree for such very specific quirks that applies to a single UDC
(and this would be protected by #ifdef CONFIG_USB_SH). But I still like
bitfields a lot more for features found in more than one UDC. You can't
encode everything in the endpoint name string (and I don't like
analyzing strings for such simple checks, I already said that).
> Erm, no. Controller drivers should be policy free. All of those
> identifers are policies. Different gadget (and eventually, function)
> drivers implement different policies.
What you mean a policy? I mean the following: there are a lot of
usb-storage devices, and they all have different strings, different
vendor/product IDs. Someone may want to produce a Linux-based, say,
camera which would be a usb-storage device. It will need to set its own
USB strings and IDs.
> You seem to be assuming that the only way to share code is to have
> it live in a UDC.
No, I'm just trying to minimize the number of modules required. Of
course, there could be a "strings/ids" module, but since a) it is always
required and b) there can be only one instance of this module per UDC,
it could be combined with the UDC driver. Sure, it would be shared code
("utility" in your terminology) - no need to implement it for every UDC
driver. Just like the usbstring.c utility.
Making it easy to reconfigure the strings/IDs at runtime (via sysfs)
would be handy for PDAs, where a single Linux distro would run on
different PDAs - and of course I would like to see my Dell Axim listed
as "Dell Axim" in lsusb rather than as a "iPAQ".
--
Greetings,
Andrew
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
