netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: linas@austin.ibm.com (Linas Vepstas)
To: Jens Osterkamp <jens@de.ibm.com>
Cc: jgarzik@pobox.com, benh@kernel.crashing.org,
	James K Lewis <jim@jklewis.com>,
	Ishizaki Kou <kou.ishizaki@toshiba.co.jp>,
	netdev@vger.kernel.org, cbe-oss-dev@ozlabs.org
Subject: Re: [PATCH] [v3] spidernet : add improved phy support
Date: Mon, 12 Feb 2007 17:26:18 -0600	[thread overview]
Message-ID: <20070212232618.GD923@austin.ibm.com> (raw)
In-Reply-To: <200702122135.34417.jens@de.ibm.com>


Tested the patch, it works for me.  Thus I'll attach a pre-emptive 
Acked-by: Linas Vepstas <linas@austin.ibm.com>

However, some quibbbles, which I think would be nice to see fixed:

On Mon, Feb 12, 2007 at 09:35:34PM +0100, Jens Osterkamp wrote:
> 
> Index: linux-2.6.20/drivers/net/sungem_phy.c
> ===================================================================
> --- linux-2.6.20.orig/drivers/net/sungem_phy.c
> +++ linux-2.6.20/drivers/net/sungem_phy.c
>  
> +#define BCM5421_MODE_MASK	(1 << 5)

Customary practice is to have these in the heder file ... 

> +	mode = (phy_reg & BCM5421_MODE_MASK) >> 5;
> +
> +	if ( mode == BCM54XX_COPPER)

All this shifting makes the code hard to read and 
hard to verify for correctness.  Part of the problem 
seems to be that you are trying to re-cycle the 
BCM5421_COPPER and BCM5461_COPPER which are in 
different locations.

It would have been clearer to simply have

#define BCM5421_MODE_MASK  (1 << 5)
#define BCM5421_COPPER     0

if (phy_reg & BCM5421_MODE_MASK == BCM5421_COPPER)

> +	if ( (phy_reg & 0x0080) >> 7)

There is no need for the shift. The if statement is 
just as true (or false) with or without the shift.

> +#define BCM5461_FIBER_LINK	(1 << 2)
> +#define BCM5461_MODE_MASK	(3 << 1)
> +
> +	mode = (phy_reg & BCM5461_MODE_MASK ) >> 1;

More confusing shifting ....

> +enum {
> +	BCM54XX_COPPER,
> +	BCM54XX_FIBER,
> +	BCM54XX_GBIC,
> +	BCM54XX_SGMII,

Things that are being used for bitmak tests should probably
not be declared in an enum. For me, at least, there's a 
cognitive dissonance in doing things this way.

-- linas

      parent reply	other threads:[~2007-02-12 23:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-12 20:35 [PATCH] [v3] spidernet : add improved phy support Jens Osterkamp
2007-02-12 21:40 ` Benjamin Herrenschmidt
2007-02-12 23:26 ` Linas Vepstas [this message]

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=20070212232618.GD923@austin.ibm.com \
    --to=linas@austin.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=jens@de.ibm.com \
    --cc=jgarzik@pobox.com \
    --cc=jim@jklewis.com \
    --cc=kou.ishizaki@toshiba.co.jp \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).