[U-Boot] [PATCH v3] usb: new board-specific USB init interface

Mateusz Zalega
2013-09-06T12:17:44Z

On 09/06/13 13:40, Marek Vasut wrote:
>>>>>>> Moreover, the 'int index' should likely be unsigned int and the
>>>>>>> special value to init all controllers at once should probably then
>>>>>>> be 0xffffffff
>>>>>>
>>>>>> Despite our greatest ambitions, I don't think we're likely to use more
>>>>>> than 2^31-1 USB controllers at a time. Besides, negative values look
>>>>>> better both in code and debugger session.
>>>>>
>>>>> Thinking of it further, instead of using negative value here, like I
>>>>> mentioned above, why not make the "board_usb_init_type" into a field of
>>>>> flags , then add flag to init all controllers at once ?
>>>>
>>>> That's unnecessary. It wouldn't lead to any practical advantage over
>>>> existing interface.
>>>
>>> The advantage would be you won't be mixing two things (value AND value
>>> with special meaning) into the "index" parameter.
>>
>> Alright, provide a use-case. The only 'special' value we have now
>> doesn't interfere with controller index. Why write code or interfaces
>> that won't ever be used?
>
> Look, abusing the index field with a special value is moronic, especially if you

I wouldn't call a de-facto standard abusive or moronic.
On the other hand, contributing to unnecessary code bloat would be.

> _do_ have another field that can very well be turned into a block of flags

Have you provided another use-case for that, as I asked?

> instead of enum right next to it.
>
> function(int foo , enum bar)
> | ^
> | |
> `---------'
> flags go
> here
>
> Then int foo can be turned into unsigned int foo _and_ be used for it's one
> singular purpose. Likewise, enum bar will now be "unsigned int flags" . Do you
> see the separation now ?

Read your mail carefully - at this point I don't have any problems
understanding what you wish to do, but I see your API changes as
unjustified. Can you justify them without appealing to your authority
and maybe inserting a couple of ad-hominems here and there?

--
Mateusz Zalega
Samsung R&D Institute Poland