1. 14 3月, 2010 1 次提交
    • J
      drivers/net/tulip/eeprom.c: fix bogus "(null)" in tulip init messages · c251c7f7
      Joe Perches 提交于
      On Wed, 2010-03-10 at 08:41 -0800, David Miller wrote:
      > From: Mikael Pettersson <mikpe@it.uu.se>
      > Date: Wed, 10 Mar 2010 16:33:28 +0100
      > > Booting 2.6.34-rc1 on a machine with a tulip nic I see
      > > a number of kernel messages that include "(null)" where
      > > previous kernels included the string "tulip0":
      > CC:'ing the guilty party :-)  It's one of the following
      > commits:
      
      Thanks Mikael.
      
      Anonymity has some good attributes.
      Blame avoidance is one of them.
      
      I've broad shoulders.  It's me, then Dwight Howard...
      
      There might be another few of these where ->name or ->dev
      was used before struct device or net_device was registered.
      I'll go back and check.
      
      tulip_core has:
      
      	if (tp->flags & HAS_MEDIA_TABLE) {
      		sprintf(dev->name, DRV_NAME "%d", board_idx);	/* hack */
      		tulip_parse_eeprom(dev);
      		strcpy(dev->name, "eth%d");			/* un-hack */
      	}
      
      So I don't feel _too_ bad.
      
      tulip_parse_eeprom is done before register_netdev so the logging
      there can not use netdev_<level> or dev_<level>(&dev->dev
      Signed-off-by: NJoe Perches <joe@perches.com>
      Tested-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c251c7f7
  2. 01 2月, 2010 1 次提交
  3. 04 12月, 2009 1 次提交
  4. 13 11月, 2008 1 次提交
    • W
      netdevice: safe convert to netdev_priv() #part-3 · 8f15ea42
      Wang Chen 提交于
      We have some reasons to kill netdev->priv:
      1. netdev->priv is equal to netdev_priv().
      2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
         netdev_priv() is more flexible than netdev->priv.
      But we cann't kill netdev->priv, because so many drivers reference to it
      directly.
      
      This patch is a safe convert for netdev->priv to netdev_priv(netdev).
      Since all of the netdev->priv is only for read.
      But it is too big to be sent in one mail.
      I split it to 4 parts and make every part smaller than 100,000 bytes,
      which is max size allowed by vger.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f15ea42
  5. 25 6月, 2008 1 次提交
  6. 29 3月, 2008 1 次提交
    • G
      [netdrvr] tulip_read_eeprom fixes for BUG 4420 · 209261c0
      Grant Grundler 提交于
      If "location" is > "addr_len" bits, the high bits of location would interfere
      with the READ_CMD sent to the eeprom controller.
      
      A patch was submitted to bug:
          http://bugzilla.kernel.org/show_bug.cgi?id=4420
      
      which simply truncated the "location", read whatever was in "location
      modulo addr_len", and returned that value. That avoids confusing the
      eeprom but seems like the wrong solution to me.
      
      Correct would be to not read beyond "1 << addr_len" address of the eeprom.
      I am submitting two changes to implement this:
      1) tulip_read_eeprom will return zero (since we can't return -EINVAL)
         if this is attempted (defensive programming).
      2) In tulip_core.c, fix the tulip_read_eeprom caller so they don't
         iterate past addr_len bits and make sure the entire tp->eeprom[]
         array is cleared.
      
      I konw we don't strictly need both. I would prefer both in the tree
      since it documents the issue and provides a second "defense" from
      the bug from creeping back in.
      Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      209261c0
  7. 11 9月, 2006 1 次提交
  8. 27 5月, 2006 1 次提交
  9. 27 6月, 2005 1 次提交
  10. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4