From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mateusz Zalega Date: Fri, 06 Sep 2013 14:17:44 +0200 Subject: [U-Boot] [PATCH v3] usb: new board-specific USB init interface In-Reply-To: <201309061340.32372.marex@denx.de> References: <1375786242-11734-1-git-send-email-m.zalega@samsung.com> <201309061324.38445.marex@denx.de> <5229BE28.7050309@samsung.com> <201309061340.32372.marex@denx.de> Message-ID: <5229C7E8.9070803@samsung.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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