Timur Tabi wrote:
Kumar Gala wrote:
How about adding a comment that the RM is wrong? Any time the code
disagrees with the RM, it *has* to be documented.
Its documented in the commit.
Sorry, but that's just not good enough for me. I *hate* it when people say
that
it is.
When I'm
Dear Jerry Van Baren,
In message [EMAIL PROTECTED] you wrote:
Would it really have been so hard to add this line?
/* The MPC8544 RM says it's bit 26, but it's really bit 28 */
I have to agree with Timur, we *need* a comment in the source code for
future reference. The git log is
On Oct 20, 2008, at 2:22 PM, Wolfgang Denk wrote:
Dear Jerry Van Baren,
In message [EMAIL PROTECTED] you wrote:
Would it really have been so hard to add this line?
/* The MPC8544 RM says it's bit 26, but it's really bit 28 */
I have to agree with Timur, we *need* a comment in the source
Hi Kumar,
Kumar Gala wrote:
The MPC8544 RM incorrect shows the SEC_CFG bit in PORDEVSR2 as being
bit 26, instead it should be bit 28. This caused in incorrect
interpretation of the i2c_clk which is the same as the SEC clk on
MPC8544. The SEC clk is controlled by cfg_sec_freq that is
On Thu, Oct 16, 2008 at 9:58 PM, Kumar Gala [EMAIL PROTECTED] wrote:
-#define MPC85xx_PORDEVSR2_SEC_CFG 0x0020
+#define MPC85xx_PORDEVSR2_SEC_CFG 0x0080
How about adding a comment that the RM is wrong? Any time the code
disagrees with the RM, it *has* to be documented.
--
On Oct 17, 2008, at 1:54 PM, Timur Tabi wrote:
On Thu, Oct 16, 2008 at 9:58 PM, Kumar Gala
[EMAIL PROTECTED] wrote:
-#define MPC85xx_PORDEVSR2_SEC_CFG 0x0020
+#define MPC85xx_PORDEVSR2_SEC_CFG 0x0080
How about adding a comment that the RM is wrong? Any time the code
Kumar Gala wrote:
How about adding a comment that the RM is wrong? Any time the code
disagrees with the RM, it *has* to be documented.
Its documented in the commit.
Sorry, but that's just not good enough for me. I *hate* it when people say that
it is.
When I'm looking at some code, and
The MPC8544 RM incorrect shows the SEC_CFG bit in PORDEVSR2 as being
bit 26, instead it should be bit 28. This caused in incorrect
interpretation of the i2c_clk which is the same as the SEC clk on
MPC8544. The SEC clk is controlled by cfg_sec_freq that is reported
in PORDEVSR2.
Signed-off-by:
8 matches
Mail list logo