From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mateusz Zalega Date: Wed, 07 Aug 2013 18:59:00 +0200 Subject: [U-Boot] [RFC 00/10] New board-specific USB initialization interface In-Reply-To: <52026E5A.4040403@samsung.com> References: <1375786242-11734-1-git-send-email-m.zalega@samsung.com> <20130806114004.60092380DF0@gemini.denx.de> <52026E5A.4040403@samsung.com> Message-ID: <52027CD4.5040702@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 08/06/13 13:40, Wolfgang Denk wrote: >> Dear Mateusz Zalega, >> >> In message <1375786242-11734-1-git-send-email-m.zalega@samsung.com> you wrote: >>> Current implementation of do_dfu() and do_usb_mass_storage() requires >>> board-specific board_usb_init() which performs USB hardware initialization. >>> >>> I noticed that several boards have such a function defined, named either >>> usb_board_init() (which binds to ohci-hcd.c driver and had been used solely >>> by it) or board_usb_init() (as in ehci-omap.c). I _assumed_ that these functions >>> do what's required by do_*() and renamed the earlier in order to unify the naming >>> convention. >> >> I appreciate your efforts, but this whole area clearly falls into the >> domain of the device model rework. Is your suggested implementation >> in any way synchronized with what has been discussed about this topic >> before? > > I've caught up with driver model discussion. The changes I submitted are > related to sharing of board-specific hardware initialization functions > between drivers, therefore my patches, if I don't miss anything, do not > collide with driver model rework - these changes would have to be done > anyway. If new USB driver model would use some other API to deal with board-specific functions, please correct me. I didn't manage to find related information, maybe I didn't look for it carefully enough. -- Mateusz Zalega Samsung R&D Institute Poland (SRPOL) | Kernel and System Framework group