From: Roger Luethi <rl@hellgate.ch>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Andrew Morton <akpm@osdl.org>, netdev@oss.sgi.com
Subject: Re: [8/9][PATCH 2.6] Small fixes and clean-up
Date: Sun, 20 Jun 2004 00:23:19 +0200 [thread overview]
Message-ID: <20040619222319.GE3313@k3.hellgate.ch> (raw)
In-Reply-To: <40D4AFE1.6020508@pobox.com>
On Sat, 19 Jun 2004 17:28:01 -0400, Jeff Garzik wrote:
> In Linux lists of model names are discouraged. It's not terribly bad in
> via-rhine, but overall these things wind up getting patches quite often,
> and become a maintenance annoyance.
>
> It's up to you as maintainer, but I would recommend removing the string
> completely. For dmesg/printk purposes, the user only needs to know they
> have a 'via-rhine' controller.
The reason I put that in is that lspci does not identify those chips
correctly (because models differ only by PCI revision, not PCI id)
and thus people get confused. But maybe I should rather file patches
against pci.ids. Okay, I think I'll remove the model names.
> >- dev = alloc_etherdev(sizeof(*rp));
> >- if (dev == NULL) {
> >+ dev = alloc_etherdev(sizeof(struct rhine_private));
> >+ if (!dev) {
> > rc = -ENOMEM;
> >- printk(KERN_ERR "init_ethernet failed for card #%d\n",
> >- card_idx);
> >+ printk(KERN_ERR "alloc_etherdev failed\n");
>
> this error message change seems like a step backwards... print out
> pci_name() or _something_ to let the user know which card failed.
It is indeed. I plan to clean up all error messages together (there
are other issues like where dev->name is defined, what information is
useful, should use a bit mask instead of debug level, etc.).
Roger
next prev parent reply other threads:[~2004-06-19 22:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-15 17:47 [0/9] via-rhine: Major surgery Roger Luethi
2004-06-15 17:48 ` [1/9][PATCH 2.6] Restructure reset code Roger Luethi
2004-06-15 17:48 ` [2/9][PATCH 2.6] fix mc_filter on big-endian arch Roger Luethi
2004-06-15 17:48 ` [3/9][PATCH 2.6] Remove lingering PHY special casing Roger Luethi
2004-06-15 17:49 ` [4/9][PATCH 2.6] Rewrite PHY detection Roger Luethi
2004-06-15 17:49 ` [5/9][PATCH 2.6] Remove options, full_duplex parameters Roger Luethi
2004-06-15 17:49 ` [7/9][PATCH 2.6] Media mode rewrite Roger Luethi
2004-06-19 21:24 ` Jeff Garzik
2004-06-19 22:20 ` Roger Luethi
2004-06-15 17:49 ` [8/9][PATCH 2.6] Small fixes and clean-up Roger Luethi
[not found] ` <40D4AFE1.6020508@pobox.com>
2004-06-19 22:23 ` Roger Luethi [this message]
2004-06-15 17:50 ` [9/9][PATCH 2.6] Add WOL support Roger Luethi
2004-06-19 21:29 ` Jeff Garzik
2004-06-19 22:15 ` Roger Luethi
2004-06-16 15:03 ` [0/9] via-rhine: Major surgery Jeff Garzik
2004-06-19 21:20 ` Jeff Garzik
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=20040619222319.GE3313@k3.hellgate.ch \
--to=rl@hellgate.ch \
--cc=akpm@osdl.org \
--cc=jgarzik@pobox.com \
--cc=netdev@oss.sgi.com \
/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.