Skip to content
  1. Apr 04, 2016
    • Linus Walleij's avatar
      ARM: dts: realview: DT support for the PBA8 and PBX-A9 · dfc8a117
      Linus Walleij authored 
      

This adds a devicetree for the ARM RealView PBA8 platform,
also known as HBI-0178, "RealView Platform Baseboard for
Cortex-A8" and PBX-A9 "RealView Platform Baseboard
Explore for Cortex-A9"

Tested in QEMU with -M realview-pb-a8, as well as with
-M realview-pbx-a9 -smp cpus=2

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: default avatarRobin Murphy <robin.murphy@arm.com>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      dfc8a117
    • Linus Walleij's avatar
      ARM: dts: realview: support all the RealView EB board variants · 2440d29d
      Linus Walleij authored 
      

The ARM RealView Evaluation Baseboards are basically these:

- The original ARMv5 EB board with an ARM926EJ-S, ARM1136 or
  ARM1176 core tile here described in arm-realview-eb.dts
  no matter which of these core tiles is being used. This
  can be emulated by QEMU "realview-eb" machine, which by
  default will have the ARM926EJ-S core tile.

- The same board with one of three MPCore Core tiles:
  ARM11MPCore, not to be confused with the similar ARM
  PB11MPCore ARM11MPCore test system. This exist in
  two revisions:
  - Revision A modeled in arm-realview-eb-11mp.dts
  - Revision B modeled arm-realview-eb-11mp-revb.dts
    Revision B can be emulated by the QEMU
    "realview-eb-mpcore" machine, but to match the hardware
    also the argument -smp cpus=4 must be passed so that
    it has four CPU cores, like the hardware.

  There is also evidently from the code in the kernel a
  Cortex-A9 core tile for the EB, and this is modeled in
  arm-realview-eb-a9mp.dts based on the kernel boardfile.
  I have not found a user guide for this EB core tile on
  the ARM website and it seems uncommon. It is however
  included for completeness.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      2440d29d
    • Linus Walleij's avatar
      ARM: dts: realview: PB1176: define a standard VGA panel · 95109b8b
      Linus Walleij authored 
      

This defines the CLCD block in the PB1176 and adds a standard
640x480 VGA panel to the device tree.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      95109b8b
    • Linus Walleij's avatar
      ARM: dts: realview: PB11MPCore: define a standard VGA panel · 6096188a
      Linus Walleij authored 
      

Let's supply a standard VGA panel by default on the PB11MPCore,
this will work with most monitors. If more screen real estate is
desired, users can update the DPI definition.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      6096188a
  3. Mar 26, 2016
  5. Mar 22, 2016
  7. Mar 21, 2016
  9. Mar 19, 2016
  11. Mar 18, 2016
  13. Mar 17, 2016
  15. Mar 16, 2016
    • Simon Horman's avatar
      clk: renesas: Rename header file renesas.h · 09c32427
      Simon Horman authored 
      

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Along with the above mentioned Kconfig changes it seems appropriate
to also rename files.

Signed-off-by: default avatarSimon Horman <horms+renesas@verge.net.au>
Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      09c32427
    • Arnd Bergmann's avatar
      ARM: pxa/raumfeld: use PROPERTY_ENTRY_INTEGER to define props · 4d2508a5
      Arnd Bergmann authored 
      

gcc-6.0 notices that the use of the property_entry in this file that
was recently introduced cannot work right, as we initialize the wrong
field:

raumfeld.c:387:3: error: the address of 'raumfeld_rotary_encoder_steps' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_steps, },
   ^~~~~~~~~~~~
raumfeld.c:389:3: error: the address of 'raumfeld_rotary_encoder_axis' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_axis, },
   ^~~~~~~~~~~~
raumfeld.c:391:3: error: the address of 'raumfeld_rotary_encoder_relative_axis' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_relative_axis, },
   ^~~~~~~~~~~~

The problem appears to stem from relying on an old definition of
'struct property', but it has changed several times since the code
could have last been correct.

This changes the code to use the PROPERTY_ENTRY_INTEGER() macro instead,
which works fine for the current definition and is a safer way of doing
the initialization.

Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Fixes: a9e340dc

 ("Input: rotary_encoder - move away from platform data structure")
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      4d2508a5
  17. Mar 15, 2016
  19. Mar 14, 2016
    • Alexander Duyck's avatar
      ipv6: Pass proto to csum_ipv6_magic as __u8 instead of unsigned short · 1e940829
      Alexander Duyck authored 
      

This patch updates csum_ipv6_magic so that it correctly recognizes that
protocol is a unsigned 8 bit value.

This will allow us to better understand what limitations may or may not be
present in how we handle the data.  For example there are a number of
places that call htonl on the protocol value.  This is likely not necessary
and can be replaced with a multiplication by ntohl(1) which will be
converted to a shift by the compiler.

Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e940829
    • Alexander Duyck's avatar
      ipv4: Update parameters for csum_tcpudp_magic to their original types · 01cfbad7
      Alexander Duyck authored 
      

This patch updates all instances of csum_tcpudp_magic and
csum_tcpudp_nofold to reflect the types that are usually used as the source
inputs.  For example the protocol field is populated based on nexthdr which
is actually an unsigned 8 bit value.  The length is usually populated based
on skb->len which is an unsigned integer.

This addresses an issue in which the IPv6 function csum_ipv6_magic was
generating a checksum using the full 32b of skb->len while
csum_tcpudp_magic was only using the lower 16 bits.  As a result we could
run into issues when attempting to adjust the checksum as there was no
protocol agnostic way to update it.

With this change the value is still truncated as many architectures use
"(len + proto) << 8", however this truncation only occurs for values
greater than 16776960 in length and as such is unlikely to occur as we stop
the inner headers at ~64K in size.

I did have to make a few minor changes in the arm, mn10300, nios2, and
score versions of the function in order to support these changes as they
were either using things such as an OR to combine the protocol and length,
or were using ntohs to convert the length which would have truncated the
value.

I also updated a few spots in terms of whitespace and type differences for
the addresses.  Most of this was just to make sure all of the definitions
were in sync going forward.

Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      01cfbad7
  21. Mar 13, 2016
  23. Mar 12, 2016
    • Thomas Petazzoni's avatar
      ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window · d7d5a43c
      Thomas Petazzoni authored 
      When the Crypto SRAM mappings were added to the Device Tree files
describing the Armada XP boards in commit c466d997 ("ARM: mvebu:
define crypto SRAM ranges for all armada-xp boards"), the fact that
those mappings were overlaping with the PCIe memory aperture was
overlooked. Due to this, we currently have for all Armada XP platforms
a situation that looks like this:

Memory mapping on Armada XP boards with internal registers at
0xf1000000:

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory aperture
 - 0xf8100000 -> 0xf8110000	64KB	Crypto SRAM #0	=> OVERLAPS WITH PCIE !
 - 0xf8110000 -> 0xf8120000	64KB	Crypto SRAM #1	=> OVERLAPS WITH PCIE !
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O aperture
 - 0xfff0000  -> 0xffffffff	1M	BootROM

The overlap means that when PCIe devices are added, depending on their
memory window needs, they might or might not be mapped into the
physical address space. Indeed, they will not be mapped if the area
allocated in the PCIe memory aperture by the PCI core overlaps with
one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB
of PCIe memory will see its PCIe memory window allocated from
0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due
to this, the PCIe window is not created, and any attempt to access the
PCIe window makes the kernel explode:

[    3.302213] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143)
[    3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window
[    3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22
[    3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018

This problem does not occur on Armada 370 boards, because we use the
following memory mapping (for boards that have internal registers at
0xf1000000):

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0 => OK !
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

Obviously, the solution is to align the location of the Crypto SRAM
mappings of Armada XP to be similar with the ones on Armada 370, i.e
have them between the "internal registers" area and the beginning of
the PCIe aperture.

However, we have a special case with the OpenBlocks AX3-4 platform,
which has a 128 MB NOR flash. Currently, this NOR flash is mapped from
0xf0000000 to 0xf8000000. This is possible because on OpenBlocks
AX3-4, the internal registers are not at 0xf1000000. And this explains
why the Crypto SRAM mappings were not configured at the same place on
Armada XP.

Hence, the solution is two-fold:

 (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from
     0xe8000000 to 0xf0000000. This frees the 0xf0000000 ->
     0xf80000000 space.

 (2) Move the Crypto SRAM mappings on Armada XP to be similar to
     Armada 370 (except of course that Armada XP has two Crypto SRAM
     and not one).

After this patch, the memory mapping on Armada XP boards with
registers at 0xf1 is:

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

And the memory mapping for the special case of the OpenBlocks AX3-4
(internal registers at 0xd0000000, NOR of 128 MB):

 - 0x00000000 -> 0xc0000000	3G 	RAM
 - 0xd0000000 -> 0xd1000000	1M	internal registers
 - 0xe800000  -> 0xf0000000	128M	NOR flash
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

Fixes: c466d997

 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards")
Reported-by: default avatarPhil Sutter <phil@nwl.cc>
Cc: Phil Sutter <phil@nwl.cc>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      d7d5a43c