Re: EV-64260-BP & GT64260 bi_recs

Mark A. Greer [off-list ref] wrote:

[3] tag: BI_STRUCT                      (embedded enet cltr 0)
    size: 76                            (12 + 3*12 + 25 + 3 == 76)
    data: BI_DEVICE

    [3.0] tag: BI_DEV_TYPE
          size: 12
          data: BI_DEV_EMBEDDED

    [3.1] tag: BI_DEV_CLASS
          size: 12
          data: BI_CLASS_ENET

    [3.2] tag: BI_DEV_ID
          size: 12
          data: 0                       (1st enet device)

    [3.3] tag: BI_MAC_ADDR
          size: 25
          data: aa:bb:cc:dd:ee:ff       (ascii)
    pad: 3

[Skipped identical structs for the other two ports]

I disagree. I think BI_GT64260_ETH_CFG as I implemented it is better.

Now if you actually implement your way in code and make it work, I'll accept it
even though I dislike it, but if your above proposal remains verbiage, my patch
must be pushed instead. Unimplemented verbiage must not take precedence over
working code.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Michael Sokolov wrote:

Now if you actually implement your way in code and make it work, I'll accept it
even though I dislike it, but if your above proposal remains verbiage, my patch
must be pushed instead. Unimplemented verbiage must not take precedence over
working code.

First, we need to see if this is going to fit with everything else in
2_4/2_4_devel and then it will get implemented.

Its not that much work:

1) Make a function (or two) like what's already been talked about to search for
bi_recs of certain types (starting from a specified location so you don't keep
finding the same one).

2) Change parse_bootinfo to use that function but only look up truly generic ones
like BI_CMD_LINE

3) Change the gt64260_enet driver to search for the ones specific to it (and
remove the code for it that is in parse_bootinfo in your patch)

Mark


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/