Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 02 1月, 2017 3 次提交
  3. 31 12月, 2016 2 次提交
  5. 30 12月, 2016 16 次提交
  7. 28 12月, 2016 2 次提交
  9. 27 12月, 2016 1 次提交
  11. 26 12月, 2016 1 次提交
    • T
      ktime: Cleanup ktime_set() usage · 8b0e1953
      由 Thomas Gleixner 提交于 
      ktime_set(S,N) was required for the timespec storage type and is still
useful for situations where a Seconds and Nanoseconds part of a time value
needs to be converted. For anything where the Seconds argument is 0, this
is pointless and can be replaced with a simple assignment.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
      8b0e1953
  13. 25 12月, 2016 2 次提交
  15. 24 12月, 2016 4 次提交
  17. 22 12月, 2016 3 次提交
    • T
      net: mvpp2: fix dma unmapping of TX buffers for fragments · 8354491c
      由 Thomas Petazzoni 提交于 
      Since commit 71ce391d ("net: mvpp2: enable proper per-CPU TX
buffers unmapping"), we are not correctly DMA unmapping TX buffers for
fragments.

Indeed, the mvpp2_txq_inc_put() function only stores in the
txq_cpu->tx_buffs[] array the physical address of the buffer to be
DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
skb_headlen(skb) to get the size to be unmapped. Both of this works fine
for TX descriptors that are associated directly to a SKB, but not the
ones that are used for fragments, with a NULL pointer as skb:

 - We have a NULL physical address when calling DMA unmap
 - skb_headlen(skb) crashes because skb is NULL

This causes random crashes when fragments are used.

To solve this problem, we need to:

 - Store the physical address of the buffer to be unmapped
   unconditionally, regardless of whether it is tied to a SKB or not.

 - Store the length of the buffer to be unmapped, which requires a new
   field.

Instead of adding a third array to store the length of the buffer to be
unmapped, and as suggested by David Miller, this commit refactors the
tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
added. Therefore, instead of having three arrays to allocate/free, we
have a single one, which also improve data locality, reducing the
impact on the CPU cache.

Fixes: 71ce391d ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
Reported-by: NRaphael G <raphael.glon@corp.ovh.com>
Cc: Raphael G <raphael.glon@corp.ovh.com>
Cc: stable@vger.kernel.org
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8354491c
    • H
      net: ethernet: stmmac: dwmac-rk: make clk enablement first in powerup · f217bfde
      由 Heiko Stübner 提交于 
      Right now the dwmac-rk tries to set up the GRF-specific speed and link
options before enabling clocks, phys etc and on previous socs this works
because the GRF is supplied on the whole by one clock.

On the rk3399 however the GRF (General Register Files) clock-supply
has been split into multiple clocks and while there is no specific
grf-gmac clock like for other sub-blocks, it seems the mac-specific
portions are actually supplied by the general mac clock.

This results in hangs on rk3399 boards if the driver is build as module.
When built in te problem of course doesn't surface, as the clocks
are of course still on at the stage before clock_disable_unused.

To solve this, simply move the clock enablement to the first position
in the powerup callback. This is also a good idea in general to
enable clocks before everything else.

Tested on rk3288, rk3368 and rk3399 the dwmac still works on all of them.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f217bfde
    • K
      be2net: Increase skb headroom size to 256 bytes · 76b15923
      由 Kalesh A P 提交于 
      The driver currently allocates 128 bytes of skb headroom.
This was found to be insufficient with some configurations
like Geneve tunnels, which resulted in skb head reallocations.

Increase the headroom to 256 bytes to fix this.
Signed-off-by: NKalesh A P <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: NSuresh Reddy <suresh.reddy@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76b15923
  19. 21 12月, 2016 6 次提交