1. 23 Jan, 2013 12 commits
    • Yuval Mintz's avatar
      bnx2x: Add additional debug information · 04c46736
      Yuval Mintz authored
      
      
      Add/Revise several debug prints in the bnx2x driver - on regular flows
      as well as error flows.
      Signed-off-by: default avatarYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: default avatarAriel Elior <ariele@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      04c46736
    • Yuval Mintz's avatar
      bnx2x: correct usleep_range usage · 0926d499
      Yuval Mintz authored
      
      
      Change the incorrect usage of `usleep_range(1000, 1000)' into
      `usleep_range(1000, 2000)'.
      Signed-off-by: default avatarYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: default avatarAriel Elior <ariele@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0926d499
    • Yuval Mintz's avatar
      bnx2x: reorganization and beautification · 924d75ab
      Yuval Mintz authored
      
      
      Slightly changes the bnx2x code without `true' functional changes.
      Changes include:
       1. Gathering macros into a single macro when combination is used multiple
          times.
       2. Exporting parts of functions into their own functions.
       3. Return values after if-else instead of only on the else condition
          (where current flow would simply return same value later in the code)
       4. Removing some unnecessary code (either dead-code or incorrect conditions)
      Signed-off-by: default avatarYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: default avatarAriel Elior <ariele@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      924d75ab
    • Yuval Mintz's avatar
      bnx2x: Semantic renovation · 2de67439
      Yuval Mintz authored
      
      
      Mostly corrects white spaces, indentations, and comments.
      Signed-off-by: default avatarYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: default avatarAriel Elior <ariele@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2de67439
    • Claudiu Manoil's avatar
      gianfar: Restore promisc mode on gfar_init_mac() · f5ae6279
      Claudiu Manoil authored
      
      
      Reactivate promiscuous mode in H/W upon gfar_init_mac(), if the
      net dev requires it (IFF_PROMISC flag set).
      This way the promisc mode is preserved accross device reset conditions
      like tx timeout, device restore, a.s.o.
      Signed-off-by: default avatarVoncken C Acksys <cedric.voncken@acksys.fr>
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5ae6279
    • David S. Miller's avatar
      Merge branch 'soreuseport' · c617f398
      David S. Miller authored
      
      
      Tom Herbert says:
      
      ====================
      This series implements so_reuseport (SO_REUSEPORT socket option) for
      TCP and UDP.  For TCP, so_reuseport allows multiple listener sockets
      to be bound to the same port.  In the case of UDP, so_reuseport allows
      multiple sockets to bind to the same port.  To prevent port hijacking
      all sockets bound to the same port using so_reuseport must have the
      same uid.  Received packets are distributed to multiple sockets bound
      to the same port using a 4-tuple hash.
      
      The motivating case for so_resuseport in TCP would be something like
      a web server binding to port 80 running with multiple threads, where
      each thread might have it's own listener socket.  This could be done
      as an alternative to other models: 1) have one listener thread which
      dispatches completed connections to workers. 2) accept on a single
      listener socket from multiple threads.  In case #1 the listener thread
      can easily become the bottleneck with high connection turn-over rate.
      In case #2, the proportion of connections accepted per thread tends
      to be uneven under high connection load (assuming simple event loop:
      while (1) { accept(); process() }, wakeup does not promote fairness
      among the sockets.  We have seen the  disproportion to be as high
      as 3:1 ratio between thread accepting most connections and the one
      accepting the fewest.  With so_reusport the distribution is
      uniform.
      
      The TCP implementation has a problem in that the request sockets for a
      listener are attached to a listener socket.  If a SYN is received, a
      listener socket is chosen and request structure is created (SYN-RECV
      state).  If the subsequent ack in 3WHS does not match the same port
      by so_reusport, the connection state is not found (reset) and the
      request structure is orphaned.  This scenario would occur when the
      number of listener sockets bound to a port changes (new ones are
      added, or old ones closed).  We are looking for a solution to this,
      maybe allow multiple sockets to share the same request table...
      
      The motivating case for so_reuseport in UDP would be something like a
      DNS server.  An alternative would be to recv on the same socket from
      multiple threads.  As in the case of TCP, the load across these threads
      tends to be disproportionate and we also see a lot of contection on
      the socket lock.  Note that SO_REUSEADDR already allows multiple UDP
      sockets to bind to the same port, however there is no provision to
      prevent hijacking and nothing to distribute packets across all the
      sockets sharing the same bound port.  This patch does not change the
      semantics of SO_REUSEADDR, but provides usable functionality of it
      for unicast.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c617f398
    • Tom Herbert's avatar
      soreuseport: UDP/IPv6 implementation · 72289b96
      Tom Herbert authored
      
      
      Motivation for soreuseport would be something like a DNS server.  An
      alternative would be to recv on the same socket from multiple threads.
      As in the case of TCP, the load across these threads tends to be
      disproportionate and we also see a lot of contection on the socket lock.
      Note that SO_REUSEADDR already allows multiple UDP sockets to bind to
      the same port, however there is no provision to prevent hijacking and
      nothing to distribute packets across all the sockets sharing the same
      bound port.  This patch does not change the semantics of SO_REUSEADDR,
      but provides usable functionality of it for unicast.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72289b96
    • Tom Herbert's avatar
      soreuseport: TCP/IPv6 implementation · 5ba24953
      Tom Herbert authored
      
      
      Motivation for soreuseport would be something like a web server
      binding to port 80 running with multiple threads, where each thread
      might have it's own listener socket.  This could be done as an
      alternative to other models: 1) have one listener thread which
      dispatches completed connections to workers. 2) accept on a single
      listener socket from multiple threads.  In case #1 the listener thread
      can easily become the bottleneck with high connection turn-over rate.
      In case #2, the proportion of connections accepted per thread tends
      to be uneven under high connection load (assuming simple event loop:
      while (1) { accept(); process() }, wakeup does not promote fairness
      among the sockets.  We have seen the  disproportion to be as high
      as 3:1 ratio between thread accepting most connections and the one
      accepting the fewest.  With so_reusport the distribution is
      uniform.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5ba24953
    • Tom Herbert's avatar
      soreuseport: UDP/IPv4 implementation · ba418fa3
      Tom Herbert authored
      
      
      Allow multiple UDP sockets to bind to the same port.
      
      Motivation soreuseport would be something like a DNS server.  An
      alternative would be to recv on the same socket from multiple threads.
      As in the case of TCP, the load across these threads tends to be
      disproportionate and we also see a lot of contection on the socketlock.
      Note that SO_REUSEADDR already allows multiple UDP sockets to bind to
      the same port, however there is no provision to prevent hijacking and
      nothing to distribute packets across all the sockets sharing the same
      bound port.  This patch does not change the semantics of SO_REUSEADDR,
      but provides usable functionality of it for unicast.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba418fa3
    • Tom Herbert's avatar
      soreuseport: TCP/IPv4 implementation · da5e3630
      Tom Herbert authored
      
      
      Allow multiple listener sockets to bind to the same port.
      
      Motivation for soresuseport would be something like a web server
      binding to port 80 running with multiple threads, where each thread
      might have it's own listener socket.  This could be done as an
      alternative to other models: 1) have one listener thread which
      dispatches completed connections to workers. 2) accept on a single
      listener socket from multiple threads.  In case #1 the listener thread
      can easily become the bottleneck with high connection turn-over rate.
      In case #2, the proportion of connections accepted per thread tends
      to be uneven under high connection load (assuming simple event loop:
      while (1) { accept(); process() }, wakeup does not promote fairness
      among the sockets.  We have seen the  disproportion to be as high
      as 3:1 ratio between thread accepting most connections and the one
      accepting the fewest.  With so_reusport the distribution is
      uniform.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da5e3630
    • Tom Herbert's avatar
      soreuseport: infrastructure · 055dc21a
      Tom Herbert authored
      
      
      Definitions and macros for implementing soreusport.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      055dc21a
    • Matt Wilson's avatar
      xen-netback: allow changing the MAC address of the interface · 4a633a60
      Matt Wilson authored
      
      
      Sometimes it is useful to be able to change the MAC address of the
      interface for netback devices. For example, when using ebtables it may
      be useful to be able to distinguish traffic from different interfaces
      without depending on the interface name.
      Reported-by: default avatarNikita Borzykh <sample.n@gmail.com>
      Reported-by: default avatarPaul Harvey <stockingpaul@hotmail.com>
      Cc: netdev@vger.kernel.org
      Cc: xen-devel@lists.xen.org
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: default avatarMatt Wilson <msw@amazon.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a633a60
  2. 22 Jan, 2013 24 commits
    • Cong Wang's avatar
      netpoll: fix an uninitialized variable · e39363a9
      Cong Wang authored
      
      
      Fengguang reported:
      
         net/core/netpoll.c: In function 'netpoll_setup':
         net/core/netpoll.c:1049:6: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      in !CONFIG_IPV6 case, we may error out without initializing
      'err'.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e39363a9
    • Cong Wang's avatar
      ipv6: remove duplicated declaration of ip6_fragment() · 9647bb80
      Cong Wang authored
      
      
      It is declared in:
      include/net/ip6_route.h:187:int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *));
      
      and net/ip6_route.h is already included.
      
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9647bb80
    • David S. Miller's avatar
      Merge branch 'legacy-isa-delete' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux · 930d52c0
      David S. Miller authored
      
      
      Paul Gortmaker says:
      
      ====================
      The Ethernet-HowTo was maintained for roughly 10 years, from 1993 to 2003.
      Fortunately sane hardware probing and auto detection (via PCI and ISA/PnP)
      largely made the document a relic of the past, hence it being abandoned
      a decade ago.
      
      However, there is one last useful thing that we can extract from the
      effort made in maintaining that document.  We can use it to guide us
      with respect to what rare, experimental and/or super ancient 10Mbit
      ISA drivers don't make sense to maintain in-tree anymore.
      
      Nobody will argue that ISA is obsolete.  Availability went away at about
      the time Pentium3 motherboards moved from 500MHz Slot1/SECC processors
      to the green 500MHz Socket 370 Pentium3 chips, at the turn of the century.
      
      In theory, it is possible that someone could still be running one of these
      12+ year old P3 machines and want 3.9+ bleeding edge kernels (but unlikely).
      In light of the above (remote) possibility, we can defer the removal of some
      ISA network drivers that were highly popular and well tested.  Typically
      that means the stuff more from the mid to late '90s, some with ISA PnP
      support, like the 3c509, the wd/SMC 8390 based stuff, PCnet/lance etc.
      
      But a lot of other drivers, typically from the early 1990s were for rare
      hardware, and experimental (to the point of requiring a cron job that would
      do a test ping, and then ifconfig down/up and/or a rmmod/insmod!).  And
      some of these drivers (znet, and lp486e to name two) are physically tied
      to platforms with on motherboard ethernet -- of 486 machines that date
      from the early 1990s and can only have single digit amounts of memory.
      
      What I'd like to achieve here with this series, is to get rid of those old
      drivers that are no longer being used.  In an earlier discussion where
      I'd proposed deleting a single driver, Alan suggested we instead dump
      all the historical stuff in one go, to make it "...immediately obvious
      where the break point is..."[1] and that it was "perfectly reasonable it
      (and a pile of other ISA cards) ought to be shown the door"[2].  So that
      is the goal here - make a clear line in the sand where the really ancient
      stuff finally gets kicked to the curb.
      
      Two old parallel port drivers are considered for removal here as well,
      since in early 386/486 ISA machines, the parallel port was typically found
      with the UARTS on the multi-I/O ISA controller card.  These drivers also date
      from the early 1990's; parallel ports are no longer found on modern boards,
      and their performance was not even capable of 10% of 10Mbit bandwidth.
      
      Allow me a preemptive justification against the inevitable comments from
      well meaning bystanders who suggest "why not just leave all this alone?".
      Dead drivers cost us all if they are left in tree.  If you think that
      is false, then please first consider:
      
      -every time you type "git status", you are checking to see if modifications
       have been made by you to all that dead code.
      
      -every time you type "git grep <regex>" you are searching through files
       which contain that dead code that simply does not interest you.
      
      -every time you build a "allyesconfig" and an "allmodconfig" (don't tell
       me you skip this step before submitting your changes to a maintainer),
       you waste CPU cycles building this dead code.
      
      -every time there is a tree wide API change, or cleanup, or file relocation,
       we pay the cost of updating dead code, or moving dead code.
      
      -daily regression tests (take linux-next as the most transparent
       example) spend time building (and possibly running) this dead code.
      
      -hard working people who regularly run auditing tools looking for lurking
       bugs (sparse/coverity/smatch/coccinelle) are wasting time checking for,
       and fixing bugs in this dead code.
      
      This last one is key.  Please take a look at the git history for the
      files that are proposed for removal here.  Look at the git history for
      any one of them ("git whatchanged --follow drivers/net/.../driver.c")
      Mentally sort the changes into two bins -- (1) the robotic tree-wide
      changes, and (2) the "look I found a real run-time bug while using this"
      category.  You will see that category #2 is essentially empty.
      
      Further to that, realize that drivers don't simply disappear.  We are
      not operating in the binary-only distribution space like other OS.  All
      these drivers remain in the git history forever.  If a person is an
      enthusiast for extreme legacy hardware, they are probably already
      customizing their kernel source and building it themselves to support
      such systems.  Also keep in mind that they could still build the 3.8
      kernel exactly as-is, and run it (or a 3.8.x stable variant of it) for
      several more years if they were really determined to cling to these old
      experimental ISA drivers for some reason.
      
      In summary, I hope that folks can be pragmatic about this, and not
      get swept up in nostalgia.  Ask yourself whether it is realistic to
      expect a person would have a genuine use case where they would
      need to build a 3.9+ modern kernel and install it on some legacy hardware
      that has no option but to absolutely _require_ one of the drivers
      that are deleted here.
      
      The following series was created with --irreversible-delete for
      ease of review (it skips showing the content of files that are
      deleted); however the complete patches can be pulled as per below.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      930d52c0
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
      neigh: Keep neighbour cache entries if number of them is small enough. · 2724680b
      YOSHIFUJI Hideaki / 吉藤英明 authored
      
      
      Since we have removed NCE (Neighbour Cache Entry) reference from
      routing entries, the only refcnt holders of an NCE are its timer
      (if running) and its owner table, in usual cases.  As a result,
      neigh_periodic_work() purges NCEs over and over again even for
      gateways.
      
      It does not make sense to purge entries, if number of them is
      very small, so keep them.  The minimum number of entries to keep
      is specified by gc_thresh1.
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2724680b
    • Nicolas Dichtel's avatar
      ipmr: fix sparse warning when testing origin or group · 360eb5da
      Nicolas Dichtel authored
      
      
      mfc_mcastgrp and mfc_origin are __be32, thus we need to convert INADDR_ANY.
      Because INADDR_ANY is 0, this patch just fix sparse warnings.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      360eb5da
    • Paul Gortmaker's avatar
      drivers/net: delete old x86 variant of the seeq8005 driver · 463d413c
      Paul Gortmaker authored
      
      
      The last update to the Ethernet HowTo (over 10 years ago) listed this:
      
       ------------------------
         SEEQ 8005
      
         Status: Obsolete, Driver Name: seeq8005
      
         There is little information about the card included in the driver,
         and hence little information to be put here. If you have a question,
         you are probably best trying to e-mail the driver author as listed
         in the source.
      
         It was marked obsolete as of the 2.4 series kernels.
       ------------------------
      
      If it was obsolete over a decade ago, the situation can not have
      improved with the passage of time, so let us act on that.  Even with
      today's improved search engines, I was unable to locate any real
      meaningful information on the ISA implementation of this rare chip.
      
      There are ARM and SGI variants of the driver in tree, but they do
      not depend on the original x86 driver source or header file.  We
      leave those non-x86 drivers to be deleted by the arch maintainers
      when they decide to expire those legacy platforms as a whole.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      463d413c
    • Paul Gortmaker's avatar
      drivers/net: delete Digital EtherWorks-3 support. · 0ffd89e4
      Paul Gortmaker authored
      
      
      This is another one that makes sense to target for obsolescence, since
      it (a)appeared pre-1995, and (b)was rather rare, and (c)did not
      really have any statistically significant active linux user base.
      
      Removing this ISA 10Mbit driver support is unlikely to be even noticed
      by the user base of 3.9+ linux kernels, especially when the documentation
      clearly indicates the vintage with this text:
      
      	 "...designed to  work with all kernels > 1.1.33"
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      0ffd89e4
    • Paul Gortmaker's avatar
      drivers/net: delete old DEC depca ISA drivers support. · 1f1c7a5c
      Paul Gortmaker authored
      
      
      These are old ISA 10Mbit cards from the 1st 1/2 of the 1990s and
      required manual jumper settings in order to configure them.  Here
      we remove them on the premise that they are no longer used in any
      modern 3.9+ kernels.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      1f1c7a5c
    • Paul Gortmaker's avatar
      drivers/net: delete the really obsolete 8390 based 10Mbit ISA drivers · fce3cd45
      Paul Gortmaker authored
      
      
      This is an area I know all too well, after being author of several 8390
      drivers, and maintainer of all 8390 drivers during a large part of their
      active lifecycle.
      
      To that end, I can say this with a reasonable degree of confidence.
      The drivers deleted here represent the earliest (as in early 1990)
      hardware and/or rare hardware.  The remaining hardware not deleted
      here is the more modern/sane of the lot, with ISA-PnP and jumperless
      "soft configuration" like the wd and smc cards had.
      
      The original ne2000 driver (ne.c) gets a pass at this time since
      AT/LANTIC based cards that could be both ne2000 or wd-like (with
      shared memory) and with jumperless configuration were made in the
      mid to late 1990's, and performed reasonably well for their era.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      fce3cd45
    • Paul Gortmaker's avatar
      drivers/net: delete old fujitsu based eth16i driver · bb37f122
      Paul Gortmaker authored
      
      
      This is another driver for relatively rare 10Mbit hardware that
      originated in the early 1990's.  So we select it for removal at
      this point in time as well.
      
      Cc: Mika Kuoppala <miku@iki.fi>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      bb37f122
    • Paul Gortmaker's avatar
      drivers/net: delete at1700 ISA 10Mbit driver · 13a80cb8
      Paul Gortmaker authored
      
      
      These Fujitsu MB86965 based ISA 10Mbit cards were another of the
      relatively rare cards dating from the early 1990s that for one reason
      or another didn't seem to get a lot of use in linux.  So we retire it
      now with a reasonable degree of confidence that it won't impact anyone.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      13a80cb8
    • Paul Gortmaker's avatar
      drivers/net: delete old 8 bit ISA Racal ni5010 support. · d2477de7
      Paul Gortmaker authored
      
      
      These cards were only available in 8bit format, and in addition
      they only had AUI and BNC(10-Base2) interfaces (i.e. no RJ-45).
      
      In fact, they are so rare, that an internet search on these old
      cards almost comes up empty, unless the "Micom interlan" name
      is used.
      
      This puts them in the equivalent domain as the 3c501, so there
      should be no strong opposition to the driver removal, as nobody
      is seriously using 3.9+ with 8 bit ISA hardware.
      
      In doing so, the whole "ethernet/racal" category becomes empty,
      so we clean up the Makefile/Kconfig and subdir appropriately.
      
      Cc: Andreas Mohr <andi@lisas.de>
      Cc: Jan-Pascal van Best <janpascal@vanbest.org>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      d2477de7
    • Paul Gortmaker's avatar
      drivers/net: delete Racal Interlan ISA ni52 (i825xx) driver · 04861c53
      Paul Gortmaker authored
      
      
      Like the other drivers that were in the ISA i825xx family, the ni52
      was rather rare, not widely used, and hence perhaps not as reliable
      as the more mainstream ISA drivers that were heavily used.  Given
      that, it is chosen for retirement at this time as well.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      04861c53
    • Paul Gortmaker's avatar
      drivers/net: delete intel i825xx based znet notebook driver · 8a594170
      Paul Gortmaker authored
      
      
      This driver supported early to mid 1990's Zenith laptops, of the
      2" thick variety.  The driver was already dead 10+ years ago, but
      we see this in the source:
      
       ----------------
       /* 10/2002
      
       [...]
      
         Tested on a vintage Zenith Z-Note 433Lnp+. Probably broken on
         anything else. Testers (and detailed bug reports) are welcome :-).
       ----------------
      
      To clarify, a 433 translates into a 486 at 33MHz, and a system with
      a default of 4MB RAM.  I can't fault the noble effort to keep things
      working a decade ago, but at this point in time, there is no valid
      justification to continue carrying this driver along.
      
      Note that there is no associated Space.c cleanup here since this
      driver was using module_init to hook itself in.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      8a594170
    • Paul Gortmaker's avatar
      drivers/net: delete ISA intel eexpress and eepro i825xx drivers · f84932d8
      Paul Gortmaker authored
      
      
      These old drivers should not be confused with the very common PCI
      cards that are supported by e100.c -- these older 10Mbit ISA only
      drivers were not as commonly used as some of the other ISA drivers,
      simply due to hardware availability and pricing.
      
      Given the rarity of the hardware, and the subsequent less extensive
      use of the drivers, it makes sense to obsolete them at this point
      in time, along with other rare/experimental ISA drivers.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      f84932d8
    • Paul Gortmaker's avatar
      drivers/net: delete the 3Com 3c505/3c507 intel i825xx support · 0e245dba
      Paul Gortmaker authored
      
      
      For those of us who were around in the early to mid 1990's, we
      will remember that the i825xx ethernet support was not something
      that was considered sufficiently vetted for 24/7 use.
      
      Folks might be inclined to use *functional* ISA hardware on some
      near expired P3 ISA machines for dedicated workhorse applications,
      but the odds of using (and relying on) one of these old/experimental
      drivers is essentially nil.  So lets remove them.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      0e245dba
    • Paul Gortmaker's avatar
      drivers/net: delete old parallel port de600/de620 drivers · 168e06ae
      Paul Gortmaker authored
      
      
      The parallel port is largely replaced by USB, and even in the
      day where these drivers were current, the documented speed was
      less than 100kB/s.  Let us not pretend that anyone cares about
      these drivers anymore, or worse - pretend that anyone is using
      them on a modern kernel.
      
      As a side bonus, this is the end of legacy parallel port ethernet,
      so we get to drop the whole chunk relating to that in the legacy
      Space.c file containing the non-PCI unified probe dispatch.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      168e06ae
    • Paul Gortmaker's avatar
      drivers/net: delete old 8bit ISA 3c501 driver. · de8270ff
      Paul Gortmaker authored
      
      
      It was amusing that linux was able to make use of this 1980's
      technology on machines long past its intended lifespan, but
      it probably should go now.
      
      To set some context, the 3c501 was designed in the 1980's to be
      used on 8088 PC-XT 8bit ISA machines.  It was built using a large
      number of discrete TTL components and truly looks like a relic
      of the ancient past before large scale integration was common.
      
      But from a functional point of view, the real issue, as stated
      in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can
      only do one thing at a time -- while you are removing one packet
      from the single-packet buffer it cannot receive another packet,
      nor can it receive a packet while loading a transmit packet."
      
      You know things are not good when the Kconfig help text suggests
      you make a cron job doing a ping every minute.
      
      Hardware that old and crippled is simply not going to be used by
      anyone in a time where 10 year old 100Mbit PCI cards (that are
      still functional) are largely give-away items.
      
      Cc: Alan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      de8270ff
    • Paul Gortmaker's avatar
      drivers/net: delete intel 486 panther onboard ethernet support · 5205939d
      Paul Gortmaker authored
      
      
      This driver was specific to a "professional workstation" line
      of products from around 1993 that used the i82596 ethernet chip
      as an on-board ethernet solution.
      
      With a 486 processor, and the premium top of the line model maxing
      out at a clock speed of 50MHz, we can safely retire this support.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      5205939d
    • Paul Gortmaker's avatar
      drivers/net: delete 486 Apricot support · 6e07ba3e
      Paul Gortmaker authored
      
      
      The Apricot was a 486 PC with 4MB RAM, and an on-board ethernet
      via an intel i82596 hard-wired to i/o 0x300.
      
      Those who were using linux in the 1990's will recall that the
      i82596 driver was not one of the more stable or widely used
      drivers of its day.  Combine that with the extremely limited
      resources of the platform, and it is truly time to expire the
      support for this thing.
      
      There are some old m68k targets who were also using this chip,
      so rather than poll the m68k user base, we simply cut out the
      x86/Apricot support here in this commit.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      6e07ba3e
  3. 21 Jan, 2013 4 commits