From: Stefan Roese <sr@denx.de>
To: benh@kernel.crashing.org
Cc: Olof Johansson <olof@lixom.net>,
netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] net: Add 405EX support to new EMAC driver
Date: Mon, 5 Nov 2007 10:19:03 +0100 [thread overview]
Message-ID: <200711051019.04287.sr@denx.de> (raw)
In-Reply-To: <1194147479.6511.11.camel@pasglop>
On Sunday 04 November 2007, Benjamin Herrenschmidt wrote:
> > Isn't this the case where there should really be device tree properties
> > instead? If you had an "ibm,emac-has-axon-stacr" property in the device
> > node, then you don't have to modify the driver for every new board out
> > there. Same for the other device properties, of course.
> >
> > I thought this was what having the device tree was all about. :(
>
> Somewhat yeah. There are subtle variations here or there we haven't
> totally indenfified... It might be a better option in our case here to
> add "has-mdio" to the rgmii nodes indeed.
So how exactly do you want me to handle this (I'm still new to this device
tree stuff, so please bear with me)? Like this?
RGMII0: emac-rgmii@ef601000 {
device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = <ef601000 8>;
has-mdio;
};
Or add this to the compatible property?
RGMII0: emac-rgmii@ef601000 {
device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii", "ibm,has-mdio";
reg = <ef601000 8>;
};
> Part of the problem with those cells is that the chip folks keep
> changing things subtly from one rev to another though, it's not even
> totally clear to me yet whether the RGMII registers are totally
> compatible betwee axon and 405ex, which is why I've pretty much stuck to
> "compatible" properties to identify the variants.
>
> The device-tree can do both. It's still better than no device-tree since
> at least you know what cell variant is in there.
>
> As for the STACR, Axon isn't the first one to have that bit flipped, I
> think we should name the property differently, something like
> "stacr-oc-inverted".
It's not only the OC bit-flip on AXON, but also the different STACR register
layout for read/write op-codes (STAOPC). This seems to be the same on all new
EMAC core's like on AXON, 440EPx/GRx and 405EX. So "stacr-oc-inverted" is not
enough here. This is what is needed for 440SPe, which "only" has the bit-flip
and the "old" STAOPC layout.
So perhaps most flexible would be to add individual properties,
like "stacr-oc-inverted" and "stacr-staopc-19-20". What do you think? And
again the additional question: Should the be added as an new property or
added to the compatible property?
Please advise. Thanks.
Best regards,
Stefan
next prev parent reply other threads:[~2007-11-05 9:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-02 7:14 [PATCH] net: Add 405EX support to new EMAC driver Stefan Roese
2007-11-02 16:03 ` Olof Johansson
2007-11-04 3:37 ` Benjamin Herrenschmidt
2007-11-04 17:16 ` Olof Johansson
2007-11-05 9:19 ` Stefan Roese [this message]
2007-11-05 11:04 ` Benjamin Herrenschmidt
2007-11-05 11:11 ` Stefan Roese
-- strict thread matches above, loose matches on Subject: below --
2007-11-01 14:54 Stefan Roese
2007-11-01 20:37 ` Benjamin Herrenschmidt
2007-11-01 21:07 ` Josh Boyer
2007-11-01 21:31 ` Stefan Roese
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=200711051019.04287.sr@denx.de \
--to=sr@denx.de \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=olof@lixom.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.