1. 04 5月, 2010 3 次提交
    • P
      dm9601: fix phy/eeprom write routine · e9162ab1
      Peter Korsgaard 提交于
      Use correct bit positions in DM_SHARED_CTRL register for writes.
      
      Michael Planes recently encountered a 'KY-RS9600 USB-LAN converter', which
      came with a driver CD containing a Linux driver. This driver turns out to
      be a copy of dm9601.c with symbols renamed and my copyright stripped.
      That aside, it did contain 1 functional change in dm_write_shared_word(),
      and after checking the datasheet the original value was indeed wrong
      (read versus write bits).
      
      On Michaels HW, this change bumps receive speed from ~30KB/s to ~900KB/s.
      On other devices the difference is less spectacular, but still significant
      (~30%).
      Reported-by: NMichael Planes <michael.planes@free.fr>
      CC: stable@kernel.org
      Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9162ab1
    • S
      ppp_generic: handle non-linear skbs when passing them to pppd · 19937d04
      Simon Arlott 提交于
      Frequently when using PPPoE with an interface MTU greater than 1500,
      the skb is likely to be non-linear. If the skb needs to be passed to
      pppd then the skb data must be read correctly.
      
      The previous commit fixes an issue with accidentally sending skbs
      to pppd based on an invalid read of the protocol type. When that
      error occurred pppd was reading invalid skb data too.
      Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19937d04
    • S
      ppp_generic: pull 2 bytes so that PPP_PROTO(skb) is valid · ea8420e9
      Simon Arlott 提交于
      In ppp_input(), PPP_PROTO(skb) may refer to invalid data in the skb.
      
      If this happens and (proto >= 0xc000 || proto == PPP_CCPFRAG) then
      the packet is passed directly to pppd.
      
      This occurs frequently when using PPPoE with an interface MTU
      greater than 1500 because the skb is more likely to be non-linear.
      
      The next 2 bytes need to be pulled in ppp_input(). The pull of 2
      bytes in ppp_receive_frame() has been removed as it is no longer
      required.
      Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ea8420e9
  2. 02 5月, 2010 1 次提交
  3. 01 5月, 2010 3 次提交
  4. 29 4月, 2010 4 次提交
  5. 28 4月, 2010 12 次提交
  6. 27 4月, 2010 4 次提交
  7. 25 4月, 2010 1 次提交
  8. 24 4月, 2010 2 次提交
    • A
      gianfar: Fix potential oops during OF address translation · 7ce97d4f
      Anton Vorontsov 提交于
      gianfar driver may pass NULL pointer to the of_translate_address(),
      which may lead to a kernel oops. Fix this by using of_iomap(), which
      is also much simpler and shorter.
      Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ce97d4f
    • A
      fsl_pq_mdio: Fix kernel oops during OF address translation · 3b1fd3e5
      Anton Vorontsov 提交于
      Old P1020RDB device trees were not specifing tbipa address for
      MDIO nodes, which is now causing this kernel oops:
      
       ...
       eth2: TX BD ring size for Q[6]: 256
       eth2: TX BD ring size for Q[7]: 256
       Unable to handle kernel paging request for data at address 0x00000000
       Faulting instruction address: 0xc0015504
       Oops: Kernel access of bad area, sig: 11 [#1]
       ...
       NIP [c0015504] memcpy+0x3c/0x9c
       LR [c000a9f8] __of_translate_address+0xfc/0x21c
       Call Trace:
       [df839e00] [c000a94c] __of_translate_address+0x50/0x21c (unreliable)
       [df839e50] [c01a33e8] get_gfar_tbipa+0xb0/0xe0
       ...
      
      The old device trees are buggy, though having a dead ethernet is
      better than a dead kernel, so fix the issue by using of_iomap().
      
      Also, a somewhat similar issue exist in the probe() routine, though
      there the oops is only a possibility. Nonetheless, fix it too.
      Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b1fd3e5
  9. 22 4月, 2010 5 次提交
  10. 20 4月, 2010 3 次提交
  11. 19 4月, 2010 2 次提交