USB ID for GTA03

Jay Vaughan jayv at synth.net
Tue Aug 5 12:38:56 CEST 2008


>> How about configure the USB vendor/product IDs as 0x1d50, 0x511e
>> respectively for gta03?
>
> We don't actually need to change this. The protocol and most of the
> functionality stays the same. Also, GTA01 and GTA02 share the same
> product IDs, and GTA03 will be very similar to GTA02.
>

I must protest!  The GTA01 and GTA02 (and GTA03) are different  
products, it makes no sense for them to have all the same product ID's.

What if I'm writing a gadget_audio driver (I am) which needs to  
identify what hardware its running with and only allocate resources  
for the specific hardware?  In particular, the GTA01 has less  
processing power than the GTA02 - this conflation of Product ID's  
means that I can't write a host driver (on the PC side) which knows  
which product its talking to and allocates/advertises resources  
accordingly.  GTA01 doesn't have the same amount of power as GTA02,  
and thus, in the case of a gadget_audio driver, I might need to only  
support 2 channel operation as opposed to 4 channel operation.

Please, just consider this carefully is all I'm asking - I know there  
is a tendency to 'do the simple', but if you don't consider all full  
cases all the way through, you might miss something important that  
makes it very difficult to address properly further down the line  
(like, when a few million people are using the machine instead of just  
a few thousand ..)
>
> Vendor/product IDs are often (incorrectly) used to identify specific
> functions, so if we don't change the numbers, this means that all the
> people who are blessed with systems that need vendor/product IDs to
> be explicitly declared before they can use them on generic devices,
> can just use the GTA02 setup.
>

Product ID's are supposed to be used to identify different products;  
and different products have different functionality.  For sure, we  
need to consider this.

> There is the further complication that the IDs are also hard-coded on
> the kernel side. This will already be a major problem when merging
> our code upstream, and adding even more variants would just make it
> worse.


This is a problem to solve.

;
--
Jay Vaughan








More information about the openmoko-kernel mailing list