All of lore.kernel.org
 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 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.