Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 12月, 2010 1 次提交
  3. 12 12月, 2010 1 次提交
    • T
      drivers/net: don't use flush_scheduled_work() · 23f333a2
      由 Tejun Heo 提交于 
      flush_scheduled_work() is on its way out.  This patch contains simple
conversions to replace flush_scheduled_work() usage with direct
cancels and flushes.

Directly cancel the used works on driver detach and flush them in
other cases.

The conversions are mostly straight forward and the only dangers are,

* Forgetting to cancel/flush one or more used works.

* Cancelling when a work should be flushed (ie. the work must be
  executed once scheduled whether the driver is detaching or not).

I've gone over the changes multiple times but it would be much
appreciated if you can review with the above points in mind.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jay Cliburn <jcliburn@gmail.com>
Cc: Michael Chan <mchan@broadcom.com>
Cc: Divy Le Ray <divy@chelsio.com>
Cc: e1000-devel@lists.sourceforge.net
Cc: Vasanthy Kolluri <vkolluri@cisco.com>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Andrew Gallatin <gallatin@myri.com>
Cc: Francois Romieu <romieu@fr.zoreil.com>
Cc: Ramkrishna Vepa <ramkrishna.vepa@exar.com>
Cc: Matt Carlson <mcarlson@broadcom.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
Cc: netdev@vger.kernel.org
      23f333a2
  5. 11 12月, 2010 1 次提交
  7. 18 11月, 2010 1 次提交
    • S
      r8169: fix checksum broken · d5d3ebe3
      由 Shan Wei 提交于 
      If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed
wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field.

I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail.
RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp.
!(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header.

If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets
with invalid checksum.

If it's not right, please tell me.
Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5d3ebe3
  9. 10 11月, 2010 2 次提交
  11. 21 10月, 2010 9 次提交
  13. 17 10月, 2010 1 次提交
    • E
      r8169: use 50% less ram for RX ring · 6f0333b8
      由 Eric Dumazet 提交于 
      Using standard skb allocations in r8169 leads to order-3 allocations (if
PAGE_SIZE=4096), because NIC needs 16383 bytes, and skb overhead makes
this bigger than 16384 -> 32768 bytes per "skb"

Using kmalloc() permits to reduce memory requirements of one r8169 nic
by 4Mbytes. (256 frames * 16Kbytes). This is fine since a hardware bug
requires us to copy incoming frames, so we build real skb when doing
this copy.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f0333b8
  15. 10 10月, 2010 2 次提交
  17. 16 9月, 2010 1 次提交
  19. 08 9月, 2010 1 次提交
  21. 06 9月, 2010 1 次提交
    • E
      r8169: fix rx checksum offload · adea1ac7
      由 Eric Dumazet 提交于 
      While porting GRO to r8169, I found this driver has a bug in its rx
path.

All skbs given to network stack had their ip_summed set to
CHECKSUM_NONE, while hardware said they had correct TCP/UDP checksums.

The reason is driver sets skb->ip_summed on the original skb before the
copy eventually done by copybreak. The fresh skb gets the ip_summed =
CHECKSUM_NONE value, forcing network stack to recompute checksum, and
preventing my GRO patch to work.

Fix is to make the ip_summed setting after skb copy.

Note : rx_copybreak current value is 16383, so all frames are copied...
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      adea1ac7
  23. 03 9月, 2010 1 次提交
  25. 31 7月, 2010 1 次提交
    • A
      PCI: change device runtime PM settings for probe and remove · f3ec4f87
      由 Alan Stern 提交于 
      This patch (as1388) changes the way the PCI core handles runtime PM
settings when probing or unbinding drivers.  Now the core will make
sure the device is enabled for runtime PM, with a usage count >= 1,
when a driver is probed.  It does the same when calling a driver's
remove method.

If the driver wants to use runtime PM, all it has to do is call
pm_runtime_pu_noidle() near the end of its probe routine (to cancel
the core's usage increment) and pm_runtime_get_noresume() near the
start of its remove routine (to restore the usage count).  It does not
need to mess around with setting the runtime state to enabled,
disabled, active, or suspended.

The patch updates e1000e and r8169, the only PCI drivers that already
use the existing runtime PM interface.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f3ec4f87
  27. 12 7月, 2010 1 次提交
  29. 10 6月, 2010 1 次提交
  31. 07 6月, 2010 1 次提交
    • T
      r8169: fix random mdio_write failures · 024a07ba
      由 Timo Teräs 提交于 
      Some configurations need delay between the "write completed" indication
and new write to work reliably.

Realtek driver seems to use longer delay when polling the "write complete"
bit, so it waits long enough between writes with high probability (but
could probably break too). This patch adds a new udelay to make sure we
wait unconditionally some time after the write complete indication.

This caused a regression with XID 18000000 boards when the board specific
phy configuration writing many mdio registers was added in commit
2e955856 (r8169: phy init for the 8169scd). Some of the configration
mdio writes would almost always fail, and depending on failure might leave
the PHY in non-working state.
Signed-off-by: NTimo Teräs <timo.teras@iki.fi>
Acked-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      024a07ba
  33. 31 5月, 2010 1 次提交
  35. 01 5月, 2010 1 次提交
  37. 27 4月, 2010 2 次提交
  39. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      由 Jiri Pirko 提交于 
      Converts the list and the core manipulating with it to be the same as uc_list.

+uses two functions for adding/removing mc address (normal and "global"
 variant) instead of a function parameter.
+removes dev_mcast.c completely.
+exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
 manipulation with lists on a sandbox (used in bonding and 80211 drivers)
Signed-off-by: NJiri Pirko <jpirko@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  41. 02 4月, 2010 2 次提交
  43. 30 3月, 2010 1 次提交
    • N
      r8169: offical fix for CVE-2009-4537 (overlength frame DMAs) · c0cd884a
      由 Neil Horman 提交于 
      Official patch to fix the r8169 frame length check error.

Based on this initial thread:
http://marc.info/?l=linux-netdev&m=126202972828626&w=1
This is the official patch to fix the frame length problems in the r8169
driver.  As noted in the previous thread, while this patch incurs a performance
hit on the driver, its possible to improve performance dynamically by updating
the mtu and rx_copybreak values at runtime to return performance to what it was
for those NICS which are unaffected by the ideosyncracy (if there are any).

Summary:

    A while back Eric submitted a patch for r8169 in which the proper
allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too
much data.  This was done in commit fdd7b4c3.  A
long time prior to that however, Francois posted
126fa4b9, which expiclitly disabled the MaxSize
setting due to the fact that the hardware behaved in odd ways when overlong
frames were received on NIC's supported by this driver.  This was mentioned in a
security conference recently:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html

It seems that if we can't enable frame size filtering, then, as Eric correctly
noticed, we can find ourselves DMA-ing too much data to a buffer, causing
corruption.  As a result is seems that we are forced to allocate a frame which
is ready to handle a maximally sized receive.

This obviously has performance issues with it, so to mitigate that issue, this
patch does two things:

1) Raises the copybreak value to the frame allocation size, which should force
appropriately sized packets to get allocated on rx, rather than a full new 16k
buffer.

2) This patch only disables frame filtering initially (i.e., during the NIC
open), changing the MTU results in ring buffer allocation of a size in relation
to the new mtu (along with a warning indicating that this is dangerous).

Because of item (2), individuals who can't cope with the performance hit (or can
otherwise filter frames to prevent the bug), or who have hardware they are sure
is unaffected by this issue, can manually lower the copybreak and reset the mtu
such that performance is restored easily.
Signed-off-by: NNeil Horman <nhorman@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c0cd884a
  45. 28 3月, 2010 1 次提交
    • F
      r8169: fix broken register writes · 78f1cd02
      由 Francois Romieu 提交于 
      This is quite similar to b39fe41f
though said registers are not even documented as 64-bit registers
- as opposed to the initial TxDescStartAddress ones - but as single
bytes which must be combined into 32 bits at the MMIO read/write
level before being merged into a 64 bit logical entity.

Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR
registers (aka "multicast is broken for ages on ARM) and to
Timo Teräs <timo.teras@iki.fi> for the MAC registers.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78f1cd02
  47. 27 3月, 2010 1 次提交
  49. 17 3月, 2010 1 次提交
  51. 04 3月, 2010 1 次提交
  53. 26 2月, 2010 1 次提交
  55. 20 2月, 2010 1 次提交
    • R
      r8169: enable 64-bit DMA by default for PCI Express devices (v2) · 35317688
      由 Robert Hancock 提交于 
      Currently use of 64-bit DMA is disabled in r8169 unless the user passes the
use_dac module option. This is reasonable for conventional PCI devices where
broken chipsets may not handle dual-address-cycle transfers properly for
32-bit slots and so this may not be safe. However, PCI Express should not have
this problem and not using 64-bit DMA results in DMA transfers needlessly using
the IOMMU or SWIOTLB. Set the use_dac module parameter to a new default value of
-1 which results in 64-bit DMA being enabled by default for PCI Express devices
only.
Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35317688