public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gvb.uboot@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Warning for mpc8360emds users: fdt-cmd from u-boot-fdt.git
Date: Fri, 06 Apr 2007 18:39:03 -0400	[thread overview]
Message-ID: <4616CC07.9050400@gmail.com> (raw)
In-Reply-To: <4616C237.3020301@freescale.com>

Timur Tabi wrote:
> Jerry Van Baren wrote:
> 
>> This was sloppy on my part and I apologize in advance for any confusion 
>> this may cause.  Please take this opportunity to generate improvement 
>> patches, rather than invectives toward myself. ;-)
> 
> I finally had a chance to look at this code, and, well, I'm not crazy about it.
> 
> In short, I have a real problem with this:
> 
> #define	FT_BUSFREQ	0x00000002		/* source is bd->bi_busfreq */
> #define	FT_ENETADDR	0x00000004		/* source is bd->bi_enetaddr */
> 
> Using flags to determine the SOURCE of the property data is bad, IMHO.  It's just not 
> flexible enough.  Not only that, but you already have a bug in the definition of 
> fixup_props[]:
> 
> #ifdef CONFIG_MPC83XX_TSEC2
> 	{	FT_UPDATE | FT_ENETADDR,
> 		"/" OF_SOC "/ethernet at 25000,
> 		"mac-address",
> 	},
> 	{	FT_UPDATE | FT_ENETADDR,
> 		"/" OF_SOC "/ethernet at 25000,
> 		"local-mac-address",
> 	},
> #endif
> 
> FT_ENETADDR is the MAC address of eth0, but here it's being programmed into eth1!  The 
> obvious solution is to introduce:
> 
> #define	FT_ENETADDR1	0x00000008		/* source is bd->bi_enetaddr1 */
> 
> But then you need definitions for eth2 and eth3
> 
> #define	FT_ENETADDR2	0x00000010		/* source is bd->bi_enetaddr2 */
> #define	FT_ENETADDR3	0x00000020		/* source is bd->bi_enetaddr3 */
> 
> As you can see, you're already bloating the code.
> 
> A better solution would be to provide a function pointer for a function that can be called 
> to fill in the property.  Something like:
> 
> int ft_set_eth0(void *fdt, int nodeoffset, const char *name, bd_t *bd)
> {
> 	return fdt_setprop(fdt, nodeoffset, name, bd->bi_enetaddr, 6);
> }
> 
> or something like that.  Then define fixup_props[] like this:
> 
> static const struct {
> 	int  createflags;
> 	char *node;
> 	char *prop;
> 	int (*set_function)(void *fdt, int nodeoffset, const char *name, bd_t *bd);
> } fixup_props[] = {
> 
> What do you think about that?  If you like it, I can make the change to mpc83xx/cpu.c

Hi Timur,

Thanks for the code review.

Oops, yes, the MAC address programming was bad. :-(  I thought I was 
being clever but all I was was very incorrect.

I'm not all that wild about having a bunch of one-liner functions with a 
table of fn pointers, but I cannot think of a better way (the original 
code is/was a sequence of hardcoded calls).

I'll take you up on your offer with a proposed tweak: remove the 
"createflags" too - the only remaining purpose is to indicate "create" 
vs. "update only" (i.e. must previously exist).  This logic can go into 
each "setter" function.  Half the properties are "create or force set" 
so the fdt_get_property() call isn't needed, just set it.  The MAC 
setters that care can do the fdt_get_property() in the "setter" function.

static const struct {
	char *node;
	char *prop;
	int (*set_function)(void *fdt, int nodeoffset, const char *name, bd_t *bd);
} fixup_props[] = {

Does that make sense?

Thanks,
gvb

P.S. I've pushed a new fdt-cmd branch to the u-boot-fdt repo that does 
some clean up and separates out some fdt_support.c functions in 
preparation for improving the bootm automagic logic.  There should be no 
collisions with Timur's proposed changes (if there are, I'll bear the 
responsibility of merging them :-/).

  reply	other threads:[~2007-04-06 22:39 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-31 17:43 [U-Boot-Users] (Try 2) Please pull branch fdt-cmd from u-boot-fdt.git Jerry Van Baren
2007-03-31 18:20 ` Wolfgang Denk
2007-03-31 18:48   ` Jerry Van Baren
2007-04-03 23:50     ` Wolfgang Denk
2007-04-04 10:16       ` Jerry Van Baren
2007-04-04 12:22         ` [U-Boot-Users] Warning for mpc8360emds users: " Jerry Van Baren
2007-04-04 15:46           ` Timur Tabi
2007-04-04 16:17             ` Jerry Van Baren
2007-04-04 22:46               ` Wolfgang Denk
2007-04-05  3:08                 ` Jerry Van Baren
2007-04-05  8:06                   ` Wolfgang Denk
2007-04-05 11:00                     ` Jerry Van Baren
2007-04-05 18:02                       ` Bruce_Leonard at selinc.com
2007-04-05 18:12                         ` Jerry Van Baren
2007-04-05 18:40                           ` Bruce_Leonard at selinc.com
2007-04-06 21:57           ` Timur Tabi
2007-04-06 22:39             ` Jerry Van Baren [this message]
2007-04-07  0:15               ` Wolfgang Denk
2007-04-07  1:29                 ` Jerry Van Baren
2007-03-31 18:27 ` [U-Boot-Users] (Try 2) Please pull branch " Jerry Van Baren
2007-04-04  0:21   ` Wolfgang Denk
2007-04-03  9:39 ` Joakim Tjernlund
2007-04-03 10:34   ` Jerry Van Baren
2007-04-03 11:37     ` Joakim Tjernlund
2007-04-03 12:06       ` Jerry Van Baren
2007-04-03 12:59       ` [U-Boot-Users] dtb in env sector - was: (Try 2) Please pull Wolfgang Denk
2007-04-03 14:04         ` Joakim Tjernlund
2007-04-03 14:21           ` Jerry Van Baren
2007-04-03 14:36             ` Martin Krause
2007-04-03 15:14             ` Joakim Tjernlund
2007-04-03 15:17               ` Jerry Van Baren
2007-04-03 15:24             ` Wolfgang Denk
2007-04-03 18:53               ` Joakim Tjernlund
2007-04-03 12:53     ` Wolfgang Denk
2007-04-03 12:49   ` Wolfgang Denk
2007-04-03 13:58     ` Joakim Tjernlund
2007-04-03 15:18       ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4616CC07.9050400@gmail.com \
    --to=gvb.uboot@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox