All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Stefan Roese <sr@denx.de>
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, 05 Nov 2007 22:04:11 +1100	[thread overview]
Message-ID: <1194260652.6511.70.camel@pasglop> (raw)
In-Reply-To: <200711051019.04287.sr@denx.de>


On Mon, 2007-11-05 at 10:19 +0100, Stefan Roese wrote:
> 
> > 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;
>                         };
> 

The above.

Properties without values are typically used for such "flags". I'll
fixup the driver to also take that for the inverted STACR and will post
a patch fixing that up asap.

> 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.

Ok.

> 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?

That's always the main question imho ... When it gets nasty like that I
tend to think the compatible property is a good compromise. It's mostly
a matter of taste. Unless you can come up with some more pleasant way to
do it... maybe a stacr-type property with multiple values but it's
really not worth complicating things when a compatible property will do
the job just fine. In that case, it's not really a "feature" of a given
implementation, but more about subtle differences between
implementations.

Ben.

  reply	other threads:[~2007-11-05 11:05 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
2007-11-05 11:04       ` Benjamin Herrenschmidt [this message]
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=1194260652.6511.70.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=sr@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 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.