1. 14 May, 2006 8 commits
  2. 13 May, 2006 5 commits
  3. 12 May, 2006 13 commits
  4. 11 May, 2006 1 commit
  5. 10 May, 2006 1 commit
  6. 08 May, 2006 5 commits
  7. 07 May, 2006 1 commit
    • Lennert Buytenhek's avatar
      [MTD] Convert physmap to platform driver · 73566edf
      Lennert Buytenhek authored
      After dwmw2 let me know it ought to be done, I rewrote the physmap map
      driver to be a platform driver.  I know zilch about the driver model,
      so I probably botched it in some way, but I've done some tests on an
      ixp23xx board which uses physmap, and it all seems to work.
      
      In order to not break existing physmap users, I've added some compat
      code that will instantiate a platform device iff CONFIG_MTD_PHYSMAP_LEN
      is defined and != 0.  Also, I've changed the default value for
      CONFIG_MTD_PHYSMAP_LEN to zero, so that people who inadvertently
      compile in physmap (or new, platform-style, users of physmap) don't get
      burned.
      
      This works pretty well -- the new physmap driver is a drop-in replacement
      for the old one, and works on said ixp23xx board without any code changes
      needed.  (This should hold as long as users don't touch 'physmap_map'
      directly.)
      
      Once all physmap users have been converted to instantiate their own
      platform devices, the compat code can go.  (Or we decide that we can
      change all the in-tree users at the same time, and never merge the
      compat code.)
      Signed-off-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      73566edf
  8. 05 May, 2006 1 commit
  9. 03 May, 2006 3 commits
  10. 02 May, 2006 2 commits
    • Ayaz Abdulla's avatar
      forcedeth: fix multi irq issues · ebf34c9b
      Ayaz Abdulla authored
      This patch fixes the issues with multiple irqs.
      
      I am resending based on feedback. I decoupled the dma mask for
      consistent memory and fixed leak with multiple irq in error path.
      
      Thanks to Manfred for catching the spin lock problem.
      Signed-Off-By: default avatarAyaz Abdulla <aabdulla@nvidia.com>
      ebf34c9b
    • Craig Brind's avatar
      [PATCH] via-rhine: zero pad short packets on Rhine I ethernet cards · 3e0d167a
      Craig Brind authored
      Fixes Rhine I cards disclosing fragments of previously transmitted frames
      in new transmissions.
      
      Before transmission, any socket buffer (skb) shorter than the ethernet
      minimum length of 60 bytes was zero-padded.  On Rhine I cards the data can
      later be copied into an aligned transmission buffer without copying this
      padding.  This resulted in the transmission of the frame with the extra
      bytes beyond the provided content leaking the previous contents of this
      buffer on to the network.
      
      Now zero-padding is repeated in the local aligned buffer if one is used.
      
      Following a suggestion from the via-rhine maintainer, no attempt is made
      here to avoid the duplicated effort of padding the skb if it is known that
      an aligned buffer will definitely be used.  This is to make the change
      "obviously correct" and allow it to be applied to a stable kernel if
      necessary.  There is no change to the flow of control and the changes are
      only to the Rhine I code path.
      
      The patch has run on an in-service Rhine-I host without incident.  Frames
      shorter than 60 bytes are now correctly zero-padded when captured on a
      separate host.  I see no unusual stats reported by ifconfig, and no unusual
      log messages.
      Signed-off-by: default avatarCraig Brind <craigbrind@gmail.com>
      Signed-off-by: default avatarRoger Luethi <rl@hellgate.ch>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      3e0d167a