From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Thu, 27 Aug 2009 13:11:25 +0200 Subject: [U-Boot] [PATCH v2] mpc83xx: update LCRR register handling In-Reply-To: <20090826173628.ddb2bdd4.kim.phillips@freescale.com> (Kim Phillips's message of "Wed, 26 Aug 2009 17:36:28 -0500") References: <4A93A975.40009@denx.de> <4A93CB96.8000701@denx.de> <20090825103925.dc7ec42c.kim.phillips@freescale.com> <4A94D615.1060504@denx.de> <20090826173628.ddb2bdd4.kim.phillips@freescale.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Kim, > o LCRR_PDYP, granted dangerous in your case, is obviously a writeable > bit (not read-only), and documented as such in later documentation. In > fact, there are no non-writeable bits in LCRR. Well, "reserved" != "non-writable" (usually there is a comment that writing reserved bits produces undefined behaviour) so I agree with Heiko that as long the documentation that we have access to, designates bits as reserved, it makes sense to have such a mask. > o the user loses visibility into what is going on if they > decide to drop/add sensitive bits such as LCRR_DBYP in their board's > CONFIG_SYS_LCRR settings, and there's a mask lurking in the background. > > o let's be practical here - in a board port, LCRR settings have to be > paid attention to, no matter what hidden behaviours or new bits there > are lying underneath - perhaps the form of 'protection' you seek is in > the form of a comment in the code? So what is it that you propose? That Heiko uses a LCRR in his board config (over-)writing reserved bits? Cheers Detlev -- vi vi vi - the roman numeral of the beast. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de