From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Tue, 09 Dec 2008 11:11:40 -0800 Subject: [U-Boot] [PATCH v3 2/2] ppc4xx: Add PPC4xx SPI helpers to Sequoia In-Reply-To: <20081209185341.71DAD834B020@gemini.denx.de> References: <493E9C46.8000101@harris.com> <493EA876.7090008@gmail.com> <20081209185341.71DAD834B020@gemini.denx.de> Message-ID: <493EC2EC.4050602@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, Wolfgang Denk wrote: > Dear Ben Warren, > > In message <493EA876.7090008@gmail.com> you wrote: > >> Why not enable this feature on Sequoia? Wolfgang's argument for keeping >> the patch out then goes away. IMHO, eval boards should have as many >> options enabled by default as possible, and the user then has the option >> to opt out. >> > > But there is not a single SPI device on the Sequoia board, and if you > attach one, you have to write driver code for it that implements the > chip select handling and the specific device protocol. We would have > a driver included, without any "users" (code that actually calls > these functions). > > Sure. Ignorant assumption on my part that the eval board had something like a SPI EEPROM, but it looks like there's just a header. In that case, the only advantage to including it is to ensure the driver keeps up with any API changes. > In other words, this driver is a prerequisite for other SPI device > drivers that might follow later, but as is, it's just a waste of > memory. > > It would just waste memory to enable it. > > OK, but who cares about memory on an evaluation board? Their entire raison-d'etre is to serve as a starting point for custom boards. I know if I was building a board with this CPU and planned on using SPI, it would be much nicer if the driver was included than having to search the message boards. Just my 2c. > Best regards, > > Wolfgang Denk > > regards, Ben