From: Mateusz Zalega <m.zalega@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] usb: new board-specific USB init interface
Date: Fri, 06 Sep 2013 13:22:06 +0200 [thread overview]
Message-ID: <5229BADE.3040202@samsung.com> (raw)
In-Reply-To: <201309051951.57034.marex@denx.de>
On 09/05/13 19:51, Marek Vasut wrote:
>>> Why not wrap board_usb_init() and board_usb_init_fail() into single call.
>>> You now pass some flags to board_usb_init() already, so just add another
>>> for the fail case. How does it sound to you?
>>
>> Like overengineering. It would lead to "board_usb_init(USB_INIT_ALL,
>> USB_INIT_DEVICE, USB_CLEANUP)" calls, which are not very readable.
>
> This is not what I mean, see this:
>
> int board_usb_init(int index, enum board_usb_init_type init)
>
> Add a new "init" type (or maybe change the init field to be flags) that will say
> "OK, do a fail init" ?
As for providing a way to do a selective cleanup if anything gone wrong,
it's a good idea, but adding such functionality to board_usb_init()
would be confusing, especially for newcomers. Why not do this in
board_usb_init_fail(int index, enum board_usb_init_type)?
...and maybe rename board_usb_init_fail to board_usb_cleanup.
>>> 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.
Best Regards,
--
Mateusz Zalega
Samsung R&D Institute Poland
next prev parent reply other threads:[~2013-09-06 11:22 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-06 10:50 [U-Boot] [RFC 00/10] New board-specific USB initialization interface Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 01/10] " Mateusz Zalega
2013-08-07 16:23 ` Stephen Warren
2013-08-11 18:04 ` Marek Vasut
2013-08-12 9:33 ` Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 02/10] nvidia, tegra: new USB hardware init interface Mateusz Zalega
2013-08-07 16:26 ` Stephen Warren
2013-08-06 10:50 ` [U-Boot] [RFC 03/10] Voipac PXA270: " Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 04/10] Trizeps IV: " Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 05/10] Colibri PXA270: " Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 06/10] icpdas lp8x4x: " Mateusz Zalega
2013-08-11 18:07 ` Marek Vasut
2013-08-06 10:50 ` [U-Boot] [RFC 07/10] esd pmc440: " Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 08/10] esd apc405: " Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 09/10] balloon3: " Mateusz Zalega
2013-08-06 10:50 ` [U-Boot] [RFC 10/10] canyonlands: " Mateusz Zalega
2013-08-06 11:40 ` [U-Boot] [RFC 00/10] New board-specific USB initialization interface Wolfgang Denk
2013-08-07 15:57 ` Mateusz Zalega
2013-08-07 16:59 ` Mateusz Zalega
2013-08-07 17:01 ` Wolfgang Denk
2013-08-20 13:35 ` [U-Boot] [PATCH] usb: new board-specific USB init interface Mateusz Zalega
2013-08-21 3:33 ` Marek Vasut
2013-08-21 10:22 ` Mateusz Zalega
2013-08-21 13:08 ` Marek Vasut
2013-08-22 10:32 ` Mateusz Zalega
2013-08-22 19:37 ` Marek Vasut
2013-08-26 10:41 ` Mateusz Zalega
2013-08-27 19:50 ` Marek Vasut
2013-08-21 8:33 ` [U-Boot] [PATCH v2] " Mateusz Zalega
2013-08-27 15:51 ` Mateusz Zalega
2013-09-03 10:41 ` [U-Boot] [PATCH v3] " Mateusz Zalega
2013-09-05 15:50 ` Marek Vasut
2013-09-05 17:37 ` Mateusz Zalega
2013-09-05 17:51 ` Marek Vasut
2013-09-06 11:22 ` Mateusz Zalega [this message]
2013-09-06 11:24 ` Marek Vasut
2013-09-06 11:36 ` Mateusz Zalega
2013-09-06 11:40 ` Marek Vasut
2013-09-06 12:17 ` Mateusz Zalega
2013-09-15 14:21 ` Marek Vasut
2013-09-16 8:27 ` Mateusz Zalega
2013-09-10 15:10 ` [U-Boot] [PATCH v4] " Mateusz Zalega
2013-09-15 16:44 ` Marek Vasut
2013-09-16 9:10 ` Mateusz Zalega
2013-09-16 14:24 ` Marek Vasut
2013-09-17 16:11 ` Igor Grinberg
2013-09-18 10:58 ` Mateusz Zalega
2013-09-19 13:34 ` Marek Vasut
2013-09-19 13:40 ` Marek Vasut
2013-09-19 14:34 ` Marek Vasut
2013-09-24 11:54 ` Minkyu Kang
2013-09-24 13:15 ` Marek Vasut
2013-09-25 11:01 ` Mateusz Zalega
2013-09-26 1:50 ` Marek Vasut
2013-09-26 10:04 ` Mateusz Zalega
2013-10-02 19:11 ` [U-Boot] [PATCH v5] " Mateusz Zalega
2013-10-03 15:16 ` Marek Vasut
2013-10-04 17:22 ` [U-Boot] [PATCH v6] " Mateusz Zalega
2013-10-05 0:48 ` Troy Kisky
2013-10-07 10:32 ` Mateusz Zalega
2013-10-08 0:09 ` Troy Kisky
2013-10-08 10:31 ` Marek Vasut
2013-10-06 13:55 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5229BADE.3040202@samsung.com \
--to=m.zalega@samsung.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox