public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Franz Pletz <franz_pletz@t-online.de>,
	Michal Rokos <michal@rokos.info>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Manfred Spraul <manfred@colorfullife.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH 2.6] Natsemi - remove compilation warnings
Date: Thu, 30 Sep 2004 14:21:57 -0400	[thread overview]
Message-ID: <415C4EC5.4040603@pobox.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0409300951150.2403@ppc970.osdl.org>

Linus Torvalds wrote:
> 
> On Thu, 30 Sep 2004, Franz Pletz wrote:
> 
>>It seems like your patch unfortunately went into 2.6.9-rc2-mm[3,4] and 
>>2.6.9-rc3.
> 
> 
> It's definitely not in _my_ -rc3. Which kernel are you looking at?
> 
> 
>>My Natsemi network card stops working with 2.6.9-rc3. After succesfully 
>>revoking your patch from 
>>http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm3/broken-out/natsemi-remove-compilation-warnings.patch
>>everything works fine.
> 
> 
> That patch does indeed look totally bogus. The reason a lot of network

<blink> <blink> <blink>  This patch is so bogus its laffable.  I think 
akpm forgot his coffee, I know he's smarter than that :)


> drivers complain about readl/writel is that "struct net_device" is very
> confused about what the IO addresses mean, and they mean different things
> for different users. Which makes type safety basically disappear, and now
> that we check it more carefully, things break.
> 
> This patch should clean up natsemi.c a bit, and makes the warnings go 
> away. Does it work for you? (It really should, it's just a basic 
> search-and-replace fix).
> 
> This is bigger than the broken patch, but that's really pretty
> unavoidable, unless "struct net_device" is fixed. And the way it's
> structured, if "net_device" ever _is_ fixed, this driver will now be
> trivially updated.
> 
> 		Linus
> 
> ----
> ===== drivers/net/natsemi.c 1.68 vs edited =====
> --- 1.68/drivers/net/natsemi.c	2004-07-27 11:18:53 -07:00
> +++ edited/drivers/net/natsemi.c	2004-09-30 10:22:44 -07:00
> @@ -719,7 +719,7 @@
>  };
>  
>  static void move_int_phy(struct net_device *dev, int addr);
> -static int eeprom_read(long ioaddr, int location);
> +static int eeprom_read(void __iomem *ioaddr, int location);
>  static int mdio_read(struct net_device *dev, int reg);
>  static void mdio_write(struct net_device *dev, int reg, u16 data);
>  static void init_phy_fixup(struct net_device *dev);
> @@ -769,9 +769,15 @@
>  static int netdev_get_regs(struct net_device *dev, u8 *buf);
>  static int netdev_get_eeprom(struct net_device *dev, u8 *buf);
>  
> +static inline void __iomem *ns_ioaddr(struct net_device *dev)
> +{
> +	return (void __iomem *) dev->base_addr;
> +}
> +

hmmmm.  Since dev->base_addr gets exported to userspace, I don't think 
it's that quick/easy to change.

Wouldn't it be better to just phase out the base of dev->base_addr 
completely?  I tend to prefer adding a "void __iomem *regs" to struct 
netdev_private, and ignore dev->base_addr completely.

	Jeff



  parent reply	other threads:[~2004-09-30 18:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-23  7:58 [PATCH 2.6] Natsemi - remove compilation warnings Michal Rokos
2004-09-23 14:18 ` Michal Rokos
2004-09-30 16:44   ` Franz Pletz
2004-09-30 17:24     ` Linus Torvalds
2004-09-30 18:09       ` Andrey S. Klochko
2004-09-30 18:22         ` Linus Torvalds
2004-09-30 18:16       ` Franz Pletz
2004-09-30 18:21       ` Jeff Garzik [this message]
2004-09-30 18:33         ` Linus Torvalds
2004-09-30 18:40         ` Tim Hockin
2004-09-30 19:53         ` David S. Miller
2004-09-30 20:08           ` 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=415C4EC5.4040603@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=franz_pletz@t-online.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=michal@rokos.info \
    --cc=torvalds@osdl.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