Skip to content

L
linux

Linux-御风守护者 / linux
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 1月, 2015 1 次提交
  3. 17 1月, 2015 3 次提交
  5. 14 1月, 2015 1 次提交
    • S
      net: fec: fix MDIO bus assignement for dual fec SoC's · 3d125f9c
      由 Stefan Agner 提交于 
      On i.MX28, the MDIO bus is shared between the two FEC instances.
The driver makes sure that the second FEC uses the MDIO bus of the
first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
is not an option since other logic, triggered by this quirk, is
still needed.

Furthermore, there are board designs which use the same MDIO bus
for both PHY's even though the second bus would be available on the
SoC side. Such layout are popular since it saves pins on SoC side.
Due to the above quirk, those boards currently do work fine. The
boards in the mainline tree with such a layout are:
- Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
- Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)

This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
makes sure that the MDIO bus of the first FEC is used in any case.

However, the boards above do have a SoC with a MDIO bus for each FEC
instance. But the PHY's are not connected in a 1:1 configuration. A
proper device tree description is needed to allow the driver to
figure out where to find its PHY. This patch fixes that shortcoming
by adding a MDIO bus child node to the first FEC instance, along
with the two PHY's on that bus, and making use of the phy-handle
property to add a reference to the PHY's.
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d125f9c
  7. 12 1月, 2015 6 次提交
  9. 10 1月, 2015 1 次提交
  11. 09 1月, 2015 2 次提交
  13. 08 1月, 2015 4 次提交
    • G
      ARM: shmobile: sh73a0 legacy: Set .control_parent for all irqpin instances · b0ddb319
      由 Geert Uytterhoeven 提交于 
      The sh73a0 INTC can't mask interrupts properly most likely due to a
hardware bug. Set the .control_parent flag to delegate masking to the
parent interrupt controller, like was already done for irqpin1.

Without this, accessing the three-axis digital accelerometer ADXL345
on kzm9g through /dev/input/event1 causes an interrupt storm, which
requires a power-cycle to recover from.

This was inspired by a patch for arch/arm/boot/dts/sh73a0.dtsi from
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Fixes: 341eb546 ("ARM: shmobile: INTC External IRQ pin driver on sh73a0")
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      b0ddb319
    • G
      ARM: 8253/1: mm: use phys_addr_t type in map_lowmem() for kernel mem region · ac084688
      由 Grygorii Strashko 提交于 
      Now local variables kernel_x_start and kernel_x_end defined using
'unsigned long' type which is wrong because they represent physical
memory range and will be calculated wrongly if LPAE is enabled.
As result, all following code in map_lowmem() will not work correctly.

For example, Keystone 2 boot is broken because
 kernel_x_start == 0x0000 0000
 kernel_x_end   == 0x0080 0000

instead of
 kernel_x_start == 0x0000 0008 0000 0000
 kernel_x_end   == 0x0000 0008 0080 0000
and as result whole low memory will be mapped with MT_MEMORY_RW
permissions by code (start > kernel_x_end):
		} else if (start >= kernel_x_end) {
			map.pfn = __phys_to_pfn(start);
			map.virtual = __phys_to_virt(start);
			map.length = end - start;
			map.type = MT_MEMORY_RW;

			create_mapping(&map);
		}

Hence, fix it by using phys_addr_t type for variables kernel_x_start
and kernel_x_end.
Tested-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ac084688
    • M
      ARM: 8249/1: mm: dump: don't skip regions · cca547e9
      由 Mark Rutland 提交于 
      Currently the arm page table dumping code starts dumping page tables
from USER_PGTABLES_CEILING. This is unnecessary for skipping any entries
related to userspace as the swapper_pg_dir does not contain such
entries, and results in a couple of unfortuante side effects.

Firstly, any kernel mappings which might exist below
USER_PGTABLES_CEILING will not be accounted in the dump output. This
masks any entries erroneously created below this address.

Secondly, if the final page table entry walked is part of a valid
mapping the page table dumping code will not log the region this entry
is part of, as the final note_page call in walk_pgd will trigger an
early return when 0 < USER_PGTABLES_CEILING. Luckily this isn't seen on
contemporary systems as they typically don't have enough RAM to extend
the linear mapping right to the end of the address space.

Due to the way addr is constructed in the walk_* functions, it can never
be less than USER_PGTABLES_CEILING when walking the page tables, so it
is not necessary to avoid dereferencing invalid table addresses. The
existing checks for st->current_prot and st->marker[1].start_address are
sufficient to ensure we will not print and/or dereference garbage when
trying to log information.

This patch removes both problematic uses of USER_PGTABLES_CEILING from
the arm page table dumping code, preventing both of these issues. We
will now report any low mappings, and the final note_page call will not
return early, ensuring all regions are logged.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Cc: Steve Capper <steve.capper@linaro.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      cca547e9
    • R
      ARM: wire up execveat syscall · 841ee230
      由 Russell King 提交于 
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      841ee230
  15. 07 1月, 2015 4 次提交
  17. 06 1月, 2015 7 次提交
  19. 05 1月, 2015 2 次提交
  21. 30 12月, 2014 1 次提交
    • S
      Add USB_EHCI_EXYNOS to multi_v7_defconfig · 007487f1
      由 Steev Klimaszewski 提交于 
      Currently we enable Exynos devices in the multi v7 defconfig, however, when
testing on my ODROID-U3, I noticed that USB was not working.  Enabling this
option causes USB to work, which enables networking support as well since the
ODROID-U3 has networking on the USB bus.

[arnd] Support for odroid-u3 was added in 3.10, so it would be nice to
backport this fix at least that far.
Signed-off-by: NSteev Klimaszewski <steev@gentoo.org>
Cc: stable@vger.kernel.org # 3.10
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      007487f1
  23. 29 12月, 2014 4 次提交
  25. 21 12月, 2014 2 次提交
    • D
      ARM: dts: rockchip: bump sd card pin drive strength up on rk3288-evb · 6618e478
      由 Doug Anderson 提交于 
      It seems that ever since (536f6b91 mmc: dw_mmc: Reset DMA before
enabling IDMAC) landed upstream that SD cards have been very unhappy
on rk3288-evb.  They were a little unhappy before that change, but
after that change they're REALLY unhappy.

It turns out that the above fix happens to fix a corruption when
reading card information during probe time.  Without the fix we didn't
detect that high speed SD cards could actually support high speed.
With the fix we suddenly detect that they're high speed and we try to
use them at 50MHz.  That doesn't work so well on EVB with the default
drive strength (maybe because there are two physical SD card slots
hooked up to the same pin?).

Fix the problem by bumping up the drive strength of the sdmmc lines.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Fixes: 536f6b91 ("mmc: dw_mmc: Reset DMA before enabling IDMAC")
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      6618e478
    • G
      ARM: mvebu: Fix pinctrl configuration for Armada 370 DB · d4b0833a
      由 Gregory CLEMENT 提交于 
      The commit b4607572 (ARM: mvebu: remove conflicting muxing on
Armada 370 DB) removes the hog pins muxing. As it is explained in the
commit log it solves a warning a boot time, but more important it also
allows using the Giga port 0 of the board.

Unfortunately in the same time the commit 4904a82a (arm: mvebu:
move Armada 370/XP pinctrl node definition armada-370-xp.dtsi) was
merged and it introduced again the hog pins muxing. Because of it, the
Giga port 0 of the board is no more usable.

This commit remove again the conflicting muxing (hopefully for the
last time).
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
[andrew@lunn.ch: Correct commit IDs]
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Fixes: 4904a82a ("arm: mvebu: move Armada 370/XP pinctrl node definition armada-370-xp.dtsi")
      d4b0833a
  27. 20 12月, 2014 1 次提交
  29. 19 12月, 2014 1 次提交