GT64260 merge warning

GT64260 merge warning

[Troy Benjegerdes]

I'm getting close to a point where I want to start merging appropriate
things from the linuxppc_2_4_galileo tree on source.mvista.com into
2_4_devel.

The first thing I'm going to do is a moderately large cleanup to
drivers/net/gt64260_eth.c.

The second thing is to check in the drivers/char/gt64260_mpsc.c driver
originally from Zuma networks. This driver is reasonably well written, and
actually works on SMP.

There may be a few other relatively minor things later.

So, if you are actually using _devel and the 64260 ethernet driver, speak
up now.

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

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

Re: GT64260 merge warning

[Paul Mackerras]

Troy Benjegerdes writes:

> I'm getting close to a point where I want to start merging appropriate
> things from the linuxppc_2_4_galileo tree on source.mvista.com into
> 2_4_devel.

I'll be interested to see it - I'm in code review mode at the moment. :)

> The first thing I'm going to do is a moderately large cleanup to
> drivers/net/gt64260_eth.c.

Good.  Can you get rid of the config option for the MAC address?
Please? :)  I suggest that we define a BI_MAC_ADDRESS bi_rec type
which is used to pass in a default MAC address for the system, and we
use that (single) MAC address for all the ethernet interfaces on the
system which don't have any way to find out a MAC address for that
specific interface.

Paul.

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

Re: GT64260 merge warning

[benh]

>> I'm getting close to a point where I want to start merging appropriate
>> things from the linuxppc_2_4_galileo tree on source.mvista.com into
>> 2_4_devel.
>
>I'll be interested to see it - I'm in code review mode at the moment. :)
>
>> The first thing I'm going to do is a moderately large cleanup to
>> drivers/net/gt64260_eth.c.
>
>Good.  Can you get rid of the config option for the MAC address?
>Please? :)  I suggest that we define a BI_MAC_ADDRESS bi_rec type
>which is used to pass in a default MAC address for the system, and we
>use that (single) MAC address for all the ethernet interfaces on the
>system which don't have any way to find out a MAC address for that
>specific interface.

I'm almost done with the new bi_rec stuffs, I'll push it to _2_5
this week as soon as I've tested a bit.

Ben.


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

Re: GT64260 merge warning

[Paul Mackerras]

benh@kernel.crashing.org writes:

> I'm almost done with the new bi_rec stuffs, I'll push it to _2_5
> this week as soon as I've tested a bit.

Interesting...  I hope we're not going to end up with a lot of extra
complexity for not very much gain, though.  If we are going to have a
more complex bi_rec setup, let's make sure that it is capable of
expressing a complete device tree.  If not then I would prefer to see
a minimal amount of extra complexity.

In other words I think there are 2 tenable positions: the minimal one,
which just adds a BI_MAC_ADDR and maybe a BI_GT64260_ADDR tag to the
existing list of tags (and makes no change to the bi_rec structure),
and a full-featured one which allows for a tree of device records with
each device having a list of properties, each with a string name and
arbitrary binary data.

Paul.

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

Re: GT64260 merge warning

[benh]

>Interesting...  I hope we're not going to end up with a lot of extra
>complexity for not very much gain, though.  If we are going to have a
>more complex bi_rec setup, let's make sure that it is capable of
>expressing a complete device tree.  If not then I would prefer to see
>a minimal amount of extra complexity.
>
>In other words I think there are 2 tenable positions: the minimal one,
>which just adds a BI_MAC_ADDR and maybe a BI_GT64260_ADDR tag to the
>existing list of tags (and makes no change to the bi_rec structure),
>and a full-featured one which allows for a tree of device records with
>each device having a list of properties, each with a string name and
>arbitrary binary data.

Well, have you read the previous discussion ? We finally managed to
agree on some mecanism after much arguments, and now you come up with
something different :)

What I'm coming up with is 2 more functions that allow to 1) find
a bi_rec by tag (so one don't have to modify the parse loop in setup.c
to locate a bi_rec), and 2) find a BI_DEVICE record based on BI_DEV_TYPE
and BI_DEV_ID within it. (the first function has the ability to look
for bi_recs within a bi_rec). That, along with some code to handle
saving the bi_recs in a persistent place and retreiving them by pointer.

Now that you have the functions, how you use them is up to you. I define
a simple mecanism for devices (BI_DEVICE composite rec with BI_DEV_TYPE
and BI_DEV_ID tags to locate it). That record contains whatever you want
to pass to your device.

It is _not_ intended, at first, to act like a device tree. Most embedded
targets really don't need that, it's more intended to pass _only_ those
informations that may be variable to a given driver. That is things like
HW MAC address, and eventually, interrupt routing, chipselect routing for
external bus peripherials, but that's completely up to a given board
designer to decide what he wants to retreive from bi_recs and what is
hard coded in the driver.

In my case, I know I will pass all the chipselect & interrupt routing
informations for my non-OCP peripherials, but that isn't mandatory.

Confusing ? Well... The mecanism is very simple, flexible enough for
you to be able to use as a kind of device-tree if you like, but enough
people here expressed the need NOT to use it as a device tree. I know
for example most OCP peripherials _could_ be indeed described with
bi_recs, but it's up to the 4xx/8xx platform maintainer to decide how
he wants to deal with those.

Now, it would be nice if all of this could be discussed around a table
at OLS, do you have plans to schedule a PPC BOF there ? :)


Ben.


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

Re: GT64260 merge warning

[Troy Benjegerdes]

On Wed, Apr 03, 2002 at 04:23:18PM +1000, Paul Mackerras wrote:
> Troy Benjegerdes writes:
>
> > I'm getting close to a point where I want to start merging appropriate
> > things from the linuxppc_2_4_galileo tree on source.mvista.com into
> > 2_4_devel.
>
> I'll be interested to see it - I'm in code review mode at the moment. :)

Good, can you review drivers/char/gt64260_mpsc.{c,h} for me then?

I want to change the filenames to 'gt642xx_mpsc' in the hopes that the
same driver can be used on the MIPS gt64240 brige chips. Other than that,
I'd say this driver is ready to go..  It works and it's pretty clean.

>
> > The first thing I'm going to do is a moderately large cleanup to
> > drivers/net/gt64260_eth.c.
>
> Good.  Can you get rid of the config option for the MAC address?
> Please? :)  I suggest that we define a BI_MAC_ADDRESS bi_rec type
> which is used to pass in a default MAC address for the system, and we
> use that (single) MAC address for all the ethernet interfaces on the
> system which don't have any way to find out a MAC address for that
> specific interface.
>
> Paul.

Yeah, the config option needs to die. I'm waiting for

a) benh to get his new bi_rec implementation done,

b) get this damn driver working on SMP

Also, I'd need to have two BI_MAC_ADDRESS records, since I need to be able
to pass the mac addresses of both ethernets from the firmware for the
board I have.

--
Troy Benjegerdes | master of mispeeling | 'da hozer' |  hozer@drgw.net
-----"If this message isn't misspelled, I didn't write it" -- Me -----
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's
why I draw cartoons. It's my life." -- Charles Schulz

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

Re: GT64260 merge warning

[Benjamin Herrenschmidt]

>Yeah, the config option needs to die. I'm waiting for
>
>a) benh to get his new bi_rec implementation done,
>
>b) get this damn driver working on SMP
>
>Also, I'd need to have two BI_MAC_ADDRESS records, since I need to be able
>to pass the mac addresses of both ethernets from the firmware for the
>board I have.

You'll have 2 BI_DEVICE records each containing a MAC address ;)

Ben.


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

Re: GT64260 merge warning

[Paul Mackerras]

Troy Benjegerdes writes:

> Also, I'd need to have two BI_MAC_ADDRESS records, since I need to be able
> to pass the mac addresses of both ethernets from the firmware for the
> board I have.

They can both use the same hardware address, that's perfectly legal.

Paul.

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

Re: GT64260 merge warning

[Dan Malek]

Paul Mackerras wrote:

> They can both use the same hardware address, that's perfectly legal.

Ummmm....I'm not sure arp is happy about this.  Just be careful that
an arp request on one net doesn't get sent out the first interface......


	-- Dan


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

Re: GT64260 merge warning

[Geert Uytterhoeven]

On Wed, 3 Apr 2002, Dan Malek wrote:
> Paul Mackerras wrote:
> > They can both use the same hardware address, that's perfectly legal.
>
> Ummmm....I'm not sure arp is happy about this.  Just be careful that
> an arp request on one net doesn't get sent out the first interface......

AFAIK Solaris boxes have used the same MAC address on all interfaces since
ages.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: [Linux-galileo] Re: GT64260 merge warning

[Nye Liu]

On Thu, Apr 04, 2002 at 09:51:34AM +0200, Geert Uytterhoeven wrote:
> On Wed, 3 Apr 2002, Dan Malek wrote:
> > Paul Mackerras wrote:
> > > They can both use the same hardware address, that's perfectly legal.
> >
> > Ummmm....I'm not sure arp is happy about this.  Just be careful that
> > an arp request on one net doesn't get sent out the first interface......
>
> AFAIK Solaris boxes have used the same MAC address on all interfaces since
> ages.

And everybody who administers networks with Suns agrees this is VERY
wrong and bad behaviour. Sun does MANY things considered harmful "since
ages"; bad example ;)

>
> Gr{oetje,eeting}s,
>
> 						Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
>
>
> _______________________________________________
> Linux-galileo mailing list
> Linux-galileo@source.mvista.com
> http://source.mvista.com/cgi-bin/mailman/listinfo/linux-galileo

--
Nye Liu
nyet@zumanetworks.com

"Who would be stupid enough to quote a fictitious character?"
	-- Don Quixote

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