Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 10月, 2016 1 次提交
  3. 03 10月, 2016 1 次提交
  5. 27 9月, 2016 3 次提交
  7. 14 8月, 2016 1 次提交
  9. 27 6月, 2016 2 次提交
  11. 13 6月, 2016 1 次提交
  13. 12 6月, 2016 1 次提交
  15. 08 6月, 2016 1 次提交
  17. 01 6月, 2016 1 次提交
  19. 11 5月, 2016 2 次提交
  21. 05 5月, 2016 1 次提交
  23. 19 4月, 2016 1 次提交
  25. 01 4月, 2016 1 次提交
  27. 07 3月, 2016 1 次提交
  29. 17 2月, 2016 1 次提交
  31. 11 2月, 2016 8 次提交
  33. 26 1月, 2016 2 次提交
    • J
      net: fec: use CONFIG_ARM instead of CONFIG_ARCH_MXC/SOC_IMX28 · 05f3b50e
      由 Johannes Berg 提交于 
      As Arnd Bergmann points out, using CONFIG_ARCH_MXC and/or SOC_IMX28
is wrong if some other ARM platform uses this device - the operation
of the driver would depend on an unrelated ARM platform that might
or might not be set for multi-platform kernels.

Prior to my previous patch, any other platforms using it would have
been broken already due to having the cbd_datlen/cbd_sc fields in
the wrong order, but byte ordering correctly, so no such platforms
can exist and work today.

In any case, it seems likely that only Freescale SoCs use this part,
and those are little-endian on ARM, so CONFIG_ARM is safe for them.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      05f3b50e
    • J
      net: fec: make driver endian-safe · 5cfa3039
      由 Johannes Berg 提交于 
      The driver treats the device descriptors as CPU-endian, which appears
to be correct with the default endianness on both ARM (typically LE)
and PowerPC (typically BE) SoCs, indicating that the hardware block
is generated differently. Add endianness annotations and byteswaps as
necessary.

It's not clear that the ifdef there really is correct and shouldn't
just be #ifdef CONFIG_ARM, but I also can't test on anything but the
i.MX6 HummingBoard where this gets it working with a BE kernel.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5cfa3039
  35. 08 1月, 2016 3 次提交
  37. 25 11月, 2015 1 次提交
  39. 02 11月, 2015 1 次提交
  41. 29 9月, 2015 1 次提交
  43. 10 9月, 2015 1 次提交
    • N
      net: fec: add netif status check before set mac address · 9638d19e
      由 Nimrod Andy 提交于 
      There exist one issue by below case that case system hang:
ifconfig eth0 down
ifconfig eth0 hw ether 00:10:19:19:81:19

After eth0 down, all fec clocks are gated off. In the .fec_set_mac_address()
function, it will set new MAC address to registers, which causes system hang.

So it needs to add netif status check to avoid registers access when clocks are
gated off. Until eth0 up the new MAC address are wrote into related registers.

V2:
As Lucas Stach's suggestion, add a comment in the code to explain why it needed.

CC: Lucas Stach <l.stach@pengutronix.de>
CC: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NFugang Duan <B38611@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9638d19e
  45. 06 9月, 2015 1 次提交
  47. 03 9月, 2015 1 次提交
  49. 26 8月, 2015 1 次提交
    • R
      net: fec: use reinit_completion() in mdio accessor functions · aac27c7a
      由 Russell King 提交于 
      Rather than re-initialising the entire completion on every mdio access,
use reinit_completion() which only resets the completion count.  This
avoids possible reinitialisation of the contained spinlock and waitqueue
while they may be in use (eg, mid-completion.)

Such an event could occur if there's a long delay in interrupt handling
causing the mdio accessor to time out, then a second access comes in
while the interrupt handler on a different CPU has called complete().
Another scenario where this has been observed is while locking has
been missing at the phy layer, allowing concurrent attempts to access
the MDIO bus.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aac27c7a
  51. 13 8月, 2015 1 次提交