On Wed, Jun 16, 2010 at 01:31:17PM -0700, Alex Lee wrote:
It will be painful, but what about defining a whole new set of UAC2_xxx constants even if it is the same value as UAC1 ?
That doesn't really help much, as the code using these macros is hybrid, for both versions. Just grep for them in the sources to see what I mean :)
Daniel
On 16-Jun-2010, at 1:21 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 16 Jun 2010 19:40:44 +0200, Daniel Mack wrote:
On Wed, Jun 16, 2010 at 07:34:49PM +0200, Takashi Iwai wrote:
At Wed, 16 Jun 2010 17:57:28 +0200, Daniel Mack wrote:
diff --git a/include/linux/usb/audio.h b/include/linux/usb/audio.h index c51200c..a54b825 100644 --- a/include/linux/usb/audio.h +++ b/include/linux/usb/audio.h @@ -39,8 +39,8 @@ #define UAC_MIXER_UNIT 0x04 #define UAC_SELECTOR_UNIT 0x05 #define UAC_FEATURE_UNIT 0x06 -#define UAC_PROCESSING_UNIT_V1 0x07 -#define UAC_EXTENSION_UNIT_V1 0x08 +#define UAC1_PROCESSING_UNIT 0x07 +#define UAC1_EXTENSION_UNIT 0x08
So now we have mixed prefix here, UAC_ and UAC1_. Isn't it a bit confusing, too?
Honestly, I have no much preference about this name-ruling. But it's of course better if it's stabilized :)
Well yeah, I hate that too, especially as it is a matter of taste eventually.
Indeed, it's just a matter of taste.
However, the idea is: things that are common for both UAC1 and UAC2 are prefixed with UAC_, and only those things that are special get a number suffix. Which is the case in the block you quoted above.
Yeah, that I understood. It's just that I feel something not clear around this... It might be simply because of the salad I ate today, though. But I'd like to hear opinions of others before merging. If nothing comes up, I'm willing to apply as is.
(This perticular detail is really the greatest unnecessary confusion in the UAC2 spec, btw. They just drop one enumeration value and shuffled two others around for no obvious reason. Now we have to live with that.)
There are always enough examples how to behave rude :)
thanks,
Takashi