From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 3 Sep 2015 22:05:44 +0200 Subject: [U-Boot] [RFC] Adding support for NI Ettus Research USRP E3XX series In-Reply-To: <201509032144.19673.marex@denx.de> References: <1441305841-27703-1-git-send-email-moritz.fischer@ettus.com> <201509032144.19673.marex@denx.de> Message-ID: <201509032205.45034.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 On Thursday, September 03, 2015 at 09:44:19 PM, Marek Vasut wrote: > On Thursday, September 03, 2015 at 08:44:00 PM, Moritz Fischer wrote: > > Hi all, > > Hi! > > > this patch adds basic support for NI Ettus Research E3XX series > > boards. I tagged this RFC because I'm not sure if the boards/xilinx/zynq > > subdirectory is the correct place for this, as I'll have some follow up > > patches that read the devices EEPROM for ethernet address etc. > > It's not, it should be board/ettus/e3xx/ . > > > Would putting it under boards/ni/zynq be the correct way of integrating > > it? While technically a Zynq device there are a lot of custom > > modifications, that I wouldn't like to force into > > board/xilinx/zynq/board.c in my follow up patches. However duplicating > > the entire board.c doesn't seem like a good idea neither. > > > > Any suggestions? For future reference do you want me to split out dts etc > > in a separate patch? > > It's always boards/VENDOR/BOARD/ . Oh btw, I'm not gonna review that patch you send, I ran checkpatch on it and these are the results: ./scripts/checkpatch.pl /tmp/\[RFC\]\ zynq_Add\ support\ for\ E3xx\ board..mbox [...] total: 13937 errors, 13285 warnings, 14 checks, 13691 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE NETWORKING_BLOCK_COMMENT_STYLE USLEEP_RANGE /tmp/[RFC] zynq_Add support for E3xx board..mbox has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. I'd suggest you drop all the useless generated documentation and fix the patch so that it follows kernel coding style [1]. Then, make sure it's checkpatch clean (see invocation above or use ./scripts/checkpatch.pl -f FILE to check separate files). [1] https://www.kernel.org/doc/Documentation/CodingStyle Best regards, Marek Vasut