From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Sun, 29 Jul 2012 15:10:41 +0200 Subject: [U-Boot] [RFC PATCH 2/5] mxs: prefix register acessor macros with 'mxs' prefix In-Reply-To: References: <1343515844-5764-1-git-send-email-otavio@ossystems.com.br> <201207291455.11335.marex@denx.de> Message-ID: <201207291510.41329.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Otavio Salvador, > On Sun, Jul 29, 2012 at 9:55 AM, Marek Vasut wrote: > > Dear Otavio Salvador, > > > >> On Sun, Jul 29, 2012 at 4:00 AM, Stefano Babic wrote: > >> > Personally I prefer that the function names are the same and the > >> > implementation itself of the function hides the SOC details. In this > >> > way, we provide the same interface API to the user (=the board > >> > maintainer) and to the drivers that are surely shared between the MX28 > >> > and MX23. > >> > >> Sure but the accessing structure is the same for MX233 and MX28 so > >> makes sense to have it with SOC name. If we have some divertion here a > >> ifdef will be need to handle. > > > > And fill the files with gazilions of ifdefs, making them unreadable. > > No; if we have too much difference we can move the structs to another > header and keep one to "include the right" providing the layer and > hidding it. That's it > Am I missing something? > > >> I also think we ought to try to split function implementation when it > >> diverts much (as code of spl_mem_init does > > > > spl_mem_init() does not. How? > > The are code there would need many ifdefs to get working fine for > both; What code? You can split that into functions (if you mean those few writes after programming the memory registers). I didn't notice much else. Ah yes, programming the mem power rail. > this could be split on spl_mem_mx233.c and spl_mem_mx28.c and > spl_mem.c doing the generic part and calling the specifics. No, it's not that different. Best regards, Marek Vasut