linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Ishizaki Kou <kou.ishizaki@toshiba.co.jp>
Cc: netdev@vger.kernel.org, jim@jklewis.com, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] drivers/net: spidernet driver on Celleb
Date: Tue, 12 Dec 2006 12:24:50 +0000	[thread overview]
Message-ID: <20061212122450.GA30466@infradead.org> (raw)
In-Reply-To: <200612120525.kBC5PpWC009418@toshiba.co.jp>

On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote:
> 
> Following are the changes.
> -This patch enables auto-negotiation.
> -Loading firmware is done when spidernet_open() is called.
> -And this patch adds other several small changes for Celleb. 

This should be split into three separate patches, sent as a patch
series.

> -/* outside loopback mode: ETOMOD signal dont matter, not connected */
> -#define SPIDER_NET_OPMODE_VALUE		0x00000063
> +/* ETOMOD signal is brought to PHY reset. bit2 must be 1 in Celleb */
> +#define SPIDER_NET_OPMODE_VALUE		0x00000067

Is it okay to simple change this value for the ibm blades?

> +static int is1000 = 1;

This should be in struct spider_net_card instead of a global flag.

>  	case SPIDER_NET_GTMFLLINT:
> -		if (netif_msg_intr(card) && net_ratelimit())
> -			pr_err("Spider TX RAM full\n");
> +		/* if (netif_msg_intr(card) && net_ratelimit())
> +			pr_err("Spider TX RAM full\n"); */

Either this should be kept or removed entirely.  In the latter case you
need a good description why it's removed in the patch header.

> +
> +	spider_net_write_reg(card, SPIDER_NET_GMACOPEMD,
> +	                     spider_net_read_reg(card, SPIDER_NET_GMACOPEMD) | 0x4);

Please make sure this doesn't overflow the 80 characters per line limit.

> +static int spider_net_init_firmware(struct spider_net_card *);

Random forward declarations in the middle of the file aren't very nice.
If you really need them put them at the beggining of the file, but it would
be even better if you moved spider_net_init_firmware further up in the
file so we wouldn't need the forward-declaration at all.

> +	if (card->phy.def->phy_id)
> +		mod_timer(&card->aneg_timer, jiffies + SPIDER_NET_ANEG_TIMER);
> +	else
> +		pr_err("No phy is available\n");

What is this idiom about?  Is not having a phy a fatal error in which case
we should abort here, or is it tolerable in which case pr_err is too much.

> +static void spider_net_init_card(struct spider_net_card *);

Same comment above forward declarations as above.

  reply	other threads:[~2006-12-12 12:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-12  5:25 [PATCH] drivers/net: spidernet driver on Celleb Ishizaki Kou
2006-12-12 12:24 ` Christoph Hellwig [this message]
2006-12-14 11:02   ` Ishizaki Kou
2006-12-13  1:14 ` Linas Vepstas
2006-12-13  3:54   ` Benjamin Herrenschmidt
2006-12-13  6:30     ` Jim Lewis
2006-12-13  9:03     ` Jens Osterkamp
2006-12-13 16:52     ` Linas Vepstas

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=20061212122450.GA30466@infradead.org \
    --to=hch@infradead.org \
    --cc=jim@jklewis.com \
    --cc=kou.ishizaki@toshiba.co.jp \
    --cc=linuxppc-dev@ozlabs.org \
    --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).