1. 05 12月, 2008 32 次提交
  2. 04 12月, 2008 8 次提交
    • J
      36cbac59
    • W
      if_usb: Kill directly reference of netdev->priv · df66f858
      Wang Chen 提交于
      Simply replace netdev->priv with netdev_priv().
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df66f858
    • L
      smc91x: remove isa stuff from smc91x driver · 48502180
      Luotao Fu 提交于
      ISA support in smc91x is incomplete. I doubt there're any smc91x isa card.
      This driver is greatly used on arm pxa platforms. Hence we remove the
      isa stuff from smc91x driver.
      Signed-off-by: NLuotao Fu <lfu@pengutronix.de>
      Acked-by: NSteve Glendinning <steve.glendinning@smsc.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48502180
    • B
      net: /proc/net/ip_mr_cache, display Iif as a signed short · 999890b2
      Benjamin Thery 提交于
      Today, iproute2 fails to show multicast forwarding unresolved cache
      entries while scanning /proc/net/ip_mr_cache.
      
      Indeed, it expects to see -1 in 'Iif' column to identify unresolved
      entries but the kernel outputs 65535. It's a signed/unsigned issue:
      
      'Iif', the source interface, is retrieved from member mfc_parent in
      struct mfc_cache. mfc_parent is a vifi_t: unsigned short, but is
      displayed in ipmr_mfc_seq_show() as "%-3d", signed integer.
      
      In unresolevd entries, the 65535 value (0xFFFF) comes from this define:
      #define ALL_VIFS    ((vifi_t)(-1))
      
      That may explains why the guy who added support for this in iproute2
      thought a -1 should be expected.
      
      I don't know if this must be fixed in kernel or in iproute2. Who is
      right? What is the correct API? How was it designed originally?
      
      I let you decide if it should goes in the kernel or be fixed in iproute2.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      999890b2
    • B
      net: fix /proc/net/ip_mr_cache display - V2 · 1ea472e2
      Benjamin Thery 提交于
      /proc/net/ip_mr_cache and /proc/net/ip6_mr_cache displays garbage when
      showing unresolved mfc_cache entries.
      
      [root@qemu tests]# cat /proc/net/ip_mr_cache
      Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
      014C00EF 010014AC 1         10    10050        0  2:1    3:1
      024C00EF 010014AC 65535      514        2 -559067475
      
      The first line is correct. It is a resolved cache entry, 10 packets used it...
      The second line represents an unresolved entry, and the columns Pkts(4th),
      Bytes(5th) and Wrong(6th) just show garbage.
      
      In struct mfc_cache, there's an union to store data for resolved and
      unresolved cases. And what ipmr_mfc_seq_show() is printing in these 
      columns for the unresolved entries is some bytes from mfc_cache.mfc_un.res.
      Bad.
      (eg. In our case -559067475 is in fact 0xdead4ead which is the spinlock
      magic from mfc_cache.mfc_un.unres.unresolved.lock.magic).
      
      This patch replaces the garbage data written in these columns for the
      unresolved entries by '0' (zeros) which is more correct.
      This change doesn't break the ABI.
      
      Also, mfc->mfc_un.res.pkt, mfc->mfc_un.res.bytes, mfc->mfc_un.res.wrong_if
      are unsigned long.
      
      It applies on top of net-next-2.6.
      
      The patch for net-2.6 is slightly different because of the NIP6_FMT to
      %pI6 conversion that was made in the seq_printf.
      
      Changelog:
      ==========
      V2:
      * Instead of breaking the ABI by suppressing the columns that have no
        meaning for unresolved entries, fill them with 0 values.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ea472e2
    • A
      netdev: remove pathetic compile-command lines · 9de6d99a
      Alexey Dobriyan 提交于
      -m486, -O6 are partircularly amusing.
      
      Remove some other useless lines near as well.
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9de6d99a
    • D
      atm: 32-bit ioctl compatibility · 8865c418
      David Woodhouse 提交于
      We lack compat ioctl support through most of the ATM code. This patch
      deals with most of it, and I can now at least use BR2684 and PPPoATM
      with 32-bit userspace.
      
      I haven't added a .compat_ioctl method to struct atm_ioctl, because
      AFAICT none of the current users need any conversion -- so we can just
      call the ->ioctl() method in every case. I looked at br2684, clip, lec,
      mpc, pppoatm and atmtcp.
      
      In svc_compat_ioctl() the only mangling which is needed is to change
      COMPAT_ATM_ADDPARTY to ATM_ADDPARTY. Although it's defined as
      	_IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
      it doesn't actually _take_ a struct atm_iobuf as an argument -- it takes
      a struct sockaddr_atmsvc, which _is_ the same between 32-bit and 64-bit
      code, so doesn't need conversion.
      
      Almost all of vcc_ioctl() would have been identical, so I converted that
      into a core do_vcc_ioctl() function with an 'int compat' argument.
      
      I've done the same with atm_dev_ioctl(), where there _are_ a few
      differences, but still it's relatively contained and there would
      otherwise have been a lot of duplication.
      
      I haven't done any of the actual device-specific ioctls, although I've
      added a compat_ioctl method to struct atmdev_ops.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8865c418
    • S
      ne-h8300: convert to net_device_ops · dcd39c90
      Stephen Hemminger 提交于
      Another device using 8390 library that needs converting.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dcd39c90