* [PATCH v2 3/7] PWM: add pwm-stm32 DT bindings
From: Rob Herring @ 2016-11-30 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480000463-9625-4-git-send-email-benjamin.gaignard@st.com>
On Thu, Nov 24, 2016 at 04:14:19PM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..36263f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,37 @@
> +STMicroelectronics PWM driver bindings for STM32
> +
> +Must be a sub-node of STM32 general purpose timer driver
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm"
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes
> + for PWM module.
> + For Pinctrl properties, please refer to [1].
> +
> +Optional parameters:
> +- st,breakinput: Set if the hardware have break input capabilities
> +- st,breakinput-polarity: Set break input polarity. Default is 0
> + The value define the active polarity:
> + - 0 (active LOW)
> + - 1 (active HIGH)
> +- st,pwm-num-chan: Number of available PWM channels. Default is 0.
> +- st,32bits-counter: Set if the hardware have a 32 bits counter
> +- st,complementary: Set if the hardware have complementary output channels
What does complementary mean here?
> +
> +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> +
> +Example:
> + gptimer1: gptimer1 at 40010000 {
timer at ...
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm1 at 0 {
pwm {
Is there more than one?
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* [GIT PULL 4/6] Broadcom maintainers-arm64 changes for 4.10
From: Arnd Bergmann @ 2016-11-30 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122054824.16974-4-f.fainelli@gmail.com>
On Monday, November 21, 2016 9:48:22 PM CET Florian Fainelli wrote:
> This pull request contains MAINTAINERS file updates for Broadcom ARM64 entries,
> please pull:
>
> - Jayachandran updates his email address for the Broadcom Vulcan entry
>
Pulled into next/arm64, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 10/10] arm64: tegra: Default configuration updates for v4.10-rc1
From: Arnd Bergmann @ 2016-11-30 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130163929.GA20246@ulmo.ba.sec>
On Wednesday, November 30, 2016 5:39:29 PM CET Thierry Reding wrote:
> On Wed, Nov 30, 2016 at 05:10:43PM +0100, Arnd Bergmann wrote:
> > On Friday, November 18, 2016 5:17:19 PM CET Thierry Reding wrote:
> > > arm64: tegra: Default configuration updates for v4.10-rc1
> > >
> > > Enable Tegra186 support.
> > >
> >
> > This was already in next/arm64 (but I didn't see a notification),
> > and with the arm64-dt branch now merged as well, we should have
> > everything you sent.
>
> I had also sent a couple of individual patches that seemed to not have
> it made into v4.9 and v4.8 for some reason (they were part of the pull
> requests, as far as I can tell). Do you think you could pull those in
> as well?
Most likely yes, but I have trouble finding them right now. Can you
just resend them?
Arnd
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Arnd Bergmann @ 2016-11-30 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92af0586-7deb-9e94-a0e7-377337ebfb9e@oracle.com>
On Wednesday, November 30, 2016 9:13:44 AM CET Santosh Shilimkar wrote:
>
> Can you apply this to your non critical fixes queue ?
>
> On 11/30/2016 9:09 AM, Grygorii Strashko wrote:
> > + Santosh Shilimkar <santosh.shilimkar@oracle.com>
> >
> > On 11/30/2016 10:53 AM, Grygorii Strashko wrote:
> >> The irq_set_affinity_hint() will always fail when !SMP and
> >> Networking will fail on Keystone 2 devices in this case.
> >> Hence, fix by ignoring IRQ affinity settings when !SMP.
> >>
> >> Cc: Arnd Bergmann <arnd@arndb.de>
> >> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >> ---
> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
>
>
Applied, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Arnd Bergmann @ 2016-11-30 21:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6f67f67f-7489-6d62-c2c2-9bba440cfabc@ti.com>
On Wednesday, November 30, 2016 7:59:26 PM CET Tero Kristo wrote:
>
> Thanks Arnd, that looks good to me.
>
> I'll figure out how to add branch description next time when I am going
> to be sending a pull-request directly to you guys.
>
>
You should get a prompt when you sign the tag.
Actually my preference would be for you to forward this to Santosh:
There are a lot of little details to know about the submission
process to for arm-soc, and it's easier for us if fewer people
have to be aware of them.
Arnd
^ permalink raw reply
* [PATCH v2 4/9] clk: stm32f4: Add lcd-tft clock
From: Rob Herring @ 2016-11-30 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-5-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:44PM +0100, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces lcd-tft clock for stm32f4 soc.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 1 +
> drivers/clk/clk-stm32f4.c | 118 +++++++++++++++++++++
> include/dt-bindings/clock/stm32f4-clock.h | 3 +-
> 3 files changed, 121 insertions(+), 1 deletion(-)
> diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
> index 56b8e10..1be4a3a 100644
> --- a/include/dt-bindings/clock/stm32f4-clock.h
> +++ b/include/dt-bindings/clock/stm32f4-clock.h
> @@ -27,7 +27,8 @@
> #define CLK_RTC 5
> #define PLL_VCO_I2S 6
> #define PLL_VCO_SAI 7
> +#define CLK_LCD 8
>
> -#define END_PRIMARY_CLK 8
> +#define END_PRIMARY_CLK 9
Do you really need this? Having this change could cause compatibility
problems between dtb and kernel versions.
Please restructure the patch series and put all of the binding changes
including this header into a single patch. Incrementally add s/w
features, not h/w.
Rob
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-11-30 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <185067972.ij8nq5Ea6J@jernej-laptop>
On Wed, Nov 30, 2016 at 09:41:26PM +0100, Jernej ?krabec wrote:
> > > > > The only
> > > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > > Rockhip
> > > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > > as
> > > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > > code
> > > > > and compare it.
> > > >
> > > > So is the TCON of DE 2.0 identical to the original TCON?
> > > >
> > > > If so, we should reuse sun4i-tcon ...
> > >
> > > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > > one for TV. However, register offsets are same as before, so I guess
> > > driver reusage make sense. I think that there are few additional
> > > registers, but they can be ignored for simplefb.
> >
> > The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> > clock and I/O area.
> >
>
> True, H3 user manual can be misleading sometimes. But this doesn't change the
> fact that TCON0 has same register offsets with same meaning.
Then yes, we should definitely share the drivers too. So, in the end,
the only thing that is actually new is the display-engine?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/dbe6e562/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/9] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Rob Herring @ 2016-11-30 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-3-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:42PM +0100, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces PLL_I2S and PLL_SAI.
> Vco clock of these PLLs can be modify by DT (only n multiplicator,
> m divider is still fixed by the boot-loader).
> Each PLL has 3 dividers. PLL should be off when we modify the rate.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 2 +
> drivers/clk/clk-stm32f4.c | 342 ++++++++++++++++++++-
> include/dt-bindings/clock/stm32f4-clock.h | 4 +-
> 3 files changed, 332 insertions(+), 16 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 1/9] clk: stm32f4: Update DT bindings documentation
From: Rob Herring @ 2016-11-30 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-2-git-send-email-gabriel.fernandez@st.com>
On Thu, Nov 24, 2016 at 03:45:41PM +0100, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> Creation of dt include file for specific stm32f4 clocks.
> These specific clocks are not derived from system clock (SYSCLOCK)
> We should use index 1 to use these clocks in DT.
> e.g. <&rcc 1 CLK_LSI>
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 8 ++++++
> drivers/clk/clk-stm32f4.c | 9 +++++--
> include/dt-bindings/clock/stm32f4-clock.h | 31 ++++++++++++++++++++++
> 3 files changed, 46 insertions(+), 2 deletions(-)
> create mode 100644 include/dt-bindings/clock/stm32f4-clock.h
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v28 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Rob Herring @ 2016-11-30 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124171413.GE7452@e104818-lin.cambridge.arm.com>
On Thu, Nov 24, 2016 at 05:14:13PM +0000, Catalin Marinas wrote:
> On Thu, Nov 24, 2016 at 06:59:44PM +0900, AKASHI Takahiro wrote:
> > From: James Morse <james.morse@arm.com>
> >
> > Add documentation for
> > linux,crashkernel-base and crashkernel-size,
> > linux,usable-memory-range
> > linux,elfcorehdr
> > used by arm64 kdump to decribe the kdump reserved area, and
> > the elfcorehdr's location within it.
> >
> > Signed-off-by: James Morse <james.morse@arm.com>
> > [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Cc: devicetree at vger.kernel.org
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Mark Rutland <mark.rutland@arm.com>
>
> Rob, Mark, are you ok with this patch?
I'm leaving this one to Mark.
Rob
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jernej Škrabec @ 2016-11-30 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130203724.a390595df0199ed19069f91d@free.fr>
Dne sreda, 30. november 2016 ob 20:37:24 CET je Jean-Francois Moine
napisal(a):
> On Wed, 30 Nov 2016 20:14:11 +0100
>
> Jernej ?krabec <jernej.skrabec@gmail.com> wrote:
> > Dne ?etrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng
napisal(a):
> > > 2016?12?1? 02:49? Jernej Skrabec <jernej.skrabec@gmail.com>???
> > >
> > > > Hi Jean-Fran?ois,
> > > >
> > > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-Fran?ois
> > > > Moine
> >
> > napisala:
> > > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > > >>
> > > >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> > > >> > > > I'm still not sure which pipeline should I use.
> > > >> > > >
> > > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > > >> > > >
> > > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > > >> > >
> > > >> > > So, I don't see how this may work.
> > > >> > > How can the u-boot know the resolutions of the HDMI display
> > > >> > > device?
> > > >> > >
> > > >> > > In other words: I have a new H3 board with the last u-boot and
> > > >> > > kernel.
> > > >> > > I plug my (rather old or brand new) HDMI display device.
> > > >> > > After powering on the system, I hope to get something on the
> > > >> > > screen.
> > > >> > > How?
> > > >> >
> > > >> > If it works like the driver for the first display engine in U-Boot,
> > > >> > it
> > > >> > will use the preferred mode reported by the EDID, and will fallback
> > > >> > to
> > > >> > 1024x768 if it cannot access it.
> > > >>
> > > >> Icenowy wrote: "simplefb won't use EDID"
> > > >>
> > > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > > >> not work with HDMI (different timings).
> > > >
> > > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > > was tested with at least following resolutions:
> > > > - 1920x1080 @ 60 Hz
> > > > - 1280x1024 @ 60 Hz
> > > > - 1280x800 @ 60 Hz (slight clock difference)
> > > > - 800x480 (not sure about frame rate)
> > > > - 3840x2160 @ 30 Hz (4K)
> > >
> > > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> > >
> > > > and nobody complained so far. I'm pretty sure 1024x768 would work.
>
> Check the timings offered by the DRM core.
I'm not really familiar with DRM code, but my Linux laptop happily works with
1024x768 @ 75 Hz and other non CEA resolutions through HDMI, so I guess it
should be possible here too. Isn't function drm_add_edid_modes() designed
exactly for that?
Anyway, this is off topic for simplefb. Simplefb driver will just take over
framebuffer set up by U-Boot with some additional info like width, height,
pitch... It doesn't have to deal with HW directly.
>
> > > >> > Maybe it would be worth exchanging on the EDID code that has been
> > > >> > done
> > > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > > >>
> > > >> The u-boot got my code, and, up to now, I could not fix the random or
> > > >> permanent failures of EDID reading in some boards.
> > > >
> > > > I only have one OPi2, but as I said, EDID always worked for me.
>
> Happy guy!
>
> > > > The only
> > > > code left from you is for DE2. HDMI stuff is basically copied from
> > > > Rockhip
> > > > driver (including EDID reading), TCON code is now reverted to the same
> > > > as
> > > > it is in sunxi_display.c. I think it is worth to take a look at EDID
> > > > code
> > > > and compare it.
> > >
> > > So is the TCON of DE 2.0 identical to the original TCON?
> > >
> > > If so, we should reuse sun4i-tcon ...
> >
> > Well, TCON is splitted in two parts (two base addresses), one for HDMI and
> > one for TV. However, register offsets are same as before, so I guess
> > driver reusage make sense. I think that there are few additional
> > registers, but they can be ignored for simplefb.
>
> The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
> clock and I/O area.
>
True, H3 user manual can be misleading sometimes. But this doesn't change the
fact that TCON0 has same register offsets with same meaning.
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 3/3] arm64: dts: r8a7796: Add CAN FD support
From: Rob Herring @ 2016-11-30 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479903288-2009-1-git-send-email-chris.paterson2@renesas.com>
On Wed, Nov 23, 2016 at 12:14:48PM +0000, Chris Paterson wrote:
> Adds CAN FD controller node for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
> ---
> .../devicetree/bindings/net/can/rcar_canfd.txt | 12 ++++++-----
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 24 ++++++++++++++++++++++
> 2 files changed, 31 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/3] arm64: dts: r8a7796: Add CAN support
From: Rob Herring @ 2016-11-30 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479903279-1950-1-git-send-email-chris.paterson2@renesas.com>
On Wed, Nov 23, 2016 at 12:14:39PM +0000, Chris Paterson wrote:
> Adds CAN controller nodes for r8a7796.
>
> Based on a patch for r8a7795 by Ramesh Shanmugasundaram.
>
> Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
> ---
> .../devicetree/bindings/net/can/rcar_can.txt | 12 +++++----
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 30 ++++++++++++++++++++++
> 2 files changed, 37 insertions(+), 5 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.
From: Rob Rice @ 2016-11-30 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480536453-24781-1-git-send-email-rob.rice@broadcom.com>
Add Northstar2 device tree entry for Broadcom Secure Processing
Unit (SPU) crypto driver.
Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
Signed-off-by: Rob Rice <rob.rice@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..8b81b0d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@
#include "ns2-clock.dtsi"
+ spu-crypto at 612d0000 {
+ compatible = "brcm,spum-crypto";
+ reg = <0x612d0000 0x900>, /* SPU 0 control regs */
+ <0x612f0000 0x900>, /* SPU 1 control regs */
+ <0x61310000 0x900>, /* SPU 2 control regs */
+ <0x61330000 0x900>; /* SPU 3 control regs */
+ mboxes = <&pdc0 0>,
+ <&pdc1 0>,
+ <&pdc2 0>,
+ <&pdc3 0>;
+ };
+
dma0: dma at 61360000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x61360000 0x1000>;
--
2.1.0
^ permalink raw reply related
* [PATCH 1/3] crypto: brcm: DT documentation for Broadcom SPU driver
From: Rob Rice @ 2016-11-30 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480536453-24781-1-git-send-email-rob.rice@broadcom.com>
Device tree documentation for Broadcom Secure Processing Unit
(SPU) crypto driver.
Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
Signed-off-by: Rob Rice <rob.rice@broadcom.com>
---
.../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
new file mode 100644
index 0000000..e5fe942
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
@@ -0,0 +1,25 @@
+The Broadcom Secure Processing Unit (SPU) driver supports symmetric
+cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
+multiple SPU hardware blocks.
+
+Required properties:
+- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
+ (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
+ of the SPU-M hardware.
+
+- reg: Should contain SPU registers location and length.
+- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
+channels correspond to DMA rings on the device.
+
+Example:
+ spu-crypto at 612d0000 {
+ compatible = "brcm,spum-crypto";
+ reg = <0 0x612d0000 0 0x900>, /* SPU 0 control regs */
+ <0 0x612f0000 0 0x900>, /* SPU 1 control regs */
+ <0 0x61310000 0 0x900>, /* SPU 2 control regs */
+ <0 0x61330000 0 0x900>; /* SPU 3 control regs */
+ mboxes = <&pdc0 0>,
+ <&pdc1 0>,
+ <&pdc2 0>,
+ <&pdc3 0>;
+ };
--
2.1.0
^ permalink raw reply related
* [PATCH 0/3] Add Broadcom SPU Crypto Driver
From: Rob Rice @ 2016-11-30 20:07 UTC (permalink / raw)
To: linux-arm-kernel
The Broadcom SPU crypto driver provides access to SPU hardware
for symmetric crypto offload. The driver supports ablkcipher,
ahash, and aead operations. The driver supports several
Broadcom SoCs with different revisions of the SPU hardware.
The driver supports SPU-M and SPU2 hardware revisions, and
a couple versions of each hw revision, each version with minor
differences.
The device tree entries for the SPU depends on device tree entries
for the Broadcom PDC driver. The PDC DT entries have been accepted
upstream, but are not yet included in the crypto repo. See commit
e79249143f468f8d3365dbbd1642c045bdcc98c5.
Rob Rice (3):
crypto: brcm: DT documentation for Broadcom SPU driver
crypto: brcm: Add Broadcom SPU driver
crypto: brcm: Add Broadcom SPU driver DT entry.
.../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 +
arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 +
drivers/crypto/Kconfig | 10 +
drivers/crypto/Makefile | 1 +
drivers/crypto/bcm/Makefile | 15 +
drivers/crypto/bcm/cipher.c | 4943 ++++++++++++++++++++
drivers/crypto/bcm/cipher.h | 472 ++
drivers/crypto/bcm/spu.c | 1252 +++++
drivers/crypto/bcm/spu.h | 288 ++
drivers/crypto/bcm/spu2.c | 1402 ++++++
drivers/crypto/bcm/spu2.h | 228 +
drivers/crypto/bcm/spum.h | 174 +
drivers/crypto/bcm/util.c | 584 +++
drivers/crypto/bcm/util.h | 117 +
14 files changed, 9523 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
create mode 100644 drivers/crypto/bcm/Makefile
create mode 100644 drivers/crypto/bcm/cipher.c
create mode 100644 drivers/crypto/bcm/cipher.h
create mode 100644 drivers/crypto/bcm/spu.c
create mode 100644 drivers/crypto/bcm/spu.h
create mode 100644 drivers/crypto/bcm/spu2.c
create mode 100644 drivers/crypto/bcm/spu2.h
create mode 100644 drivers/crypto/bcm/spum.h
create mode 100644 drivers/crypto/bcm/util.c
create mode 100644 drivers/crypto/bcm/util.h
--
2.1.0
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jean-Francois Moine @ 2016-11-30 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2717236.xBNAaGdqdc@jernej-laptop>
On Wed, 30 Nov 2016 20:14:11 +0100
Jernej ?krabec <jernej.skrabec@gmail.com> wrote:
> Dne ?etrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> > 2016?12?1? 02:49? Jernej Skrabec <jernej.skrabec@gmail.com>???
> >
> > > Hi Jean-Fran?ois,
> > >
> > > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-Fran?ois Moine
> napisala:
> > >> On Tue, 29 Nov 2016 22:59:32 +0100
> > >>
> > >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> > >> > > > I'm still not sure which pipeline should I use.
> > >> > > >
> > >> > > > And, it seems that HDMI Slow Clock is not needed?
> > >> > > >
> > >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> > >> > >
> > >> > > So, I don't see how this may work.
> > >> > > How can the u-boot know the resolutions of the HDMI display device?
> > >> > >
> > >> > > In other words: I have a new H3 board with the last u-boot and
> > >> > > kernel.
> > >> > > I plug my (rather old or brand new) HDMI display device.
> > >> > > After powering on the system, I hope to get something on the screen.
> > >> > > How?
> > >> >
> > >> > If it works like the driver for the first display engine in U-Boot, it
> > >> > will use the preferred mode reported by the EDID, and will fallback to
> > >> > 1024x768 if it cannot access it.
> > >>
> > >> Icenowy wrote: "simplefb won't use EDID"
> > >>
> > >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> > >> not work with HDMI (different timings).
> > >
> > > U-Boot driver now accept any timings recommended by EDID. So far it
> > > was tested with at least following resolutions:
> > > - 1920x1080 @ 60 Hz
> > > - 1280x1024 @ 60 Hz
> > > - 1280x800 @ 60 Hz (slight clock difference)
> > > - 800x480 (not sure about frame rate)
> > > - 3840x2160 @ 30 Hz (4K)
> >
> > I tested on 1024x600 (If my memory is right, it's @ 60Hz)
> >
> > > and nobody complained so far. I'm pretty sure 1024x768 would work.
Check the timings offered by the DRM core.
> > >
> > >> > Maybe it would be worth exchanging on the EDID code that has been done
> > >> > for the u-boot driver too, so that it can be fixed in your driver.
> > >>
> > >> The u-boot got my code, and, up to now, I could not fix the random or
> > >> permanent failures of EDID reading in some boards.
> > >
> > > I only have one OPi2, but as I said, EDID always worked for me.
Happy guy!
> > > The only
> > > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > > driver (including EDID reading), TCON code is now reverted to the same as
> > > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > > and compare it.
> >
> > So is the TCON of DE 2.0 identical to the original TCON?
> >
> > If so, we should reuse sun4i-tcon ...
>
> Well, TCON is splitted in two parts (two base addresses), one for HDMI and one
> for TV. However, register offsets are same as before, so I guess driver
> reusage make sense. I think that there are few additional registers, but they
> can be ignored for simplefb.
The TCON1 of the H3 is not usable (no ckock). Analog TV has its own
clock and I/O area.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: atull @ 2016-11-30 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6989b2ee-9caf-81b3-2328-9d4e287794cb@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Joshua,
> Hi Alan,
>
> On 11/30/2016 09:45 AM, atull wrote:
> > On Wed, 30 Nov 2016, Joshua Clayton wrote:
> >
> > Hi Clayton,
> >
> > I just have a few minor one line changes below. Only one
> > is operational, I should have caught that earlier.
> >
> Thanks for the speedy review.
> >> +};
> >> +MODULE_DEVICE_TABLE(of, of_ef_match);
> >> +
> >> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
> >> +{
> >> + return mgr->state;
> >> +}
> > This function gets called once to initialize mgr->state in
> > fpga_mgr_register(). So it should at least return the state the FPGA
> > is at then. If it is unknown, it can just return
> > FPGA_MGR_STATE_UNKNOWN.
> >
> I guess I didn't understand the purpose of this function.
> The driver has access to the status pin at this phase, so I can return
> FPGA_MGR_STATE_UNKNOWN or FPGA_MGR_STATE_RESET depending
> on the state of that pin.
>
> >> +
> >> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
> >> + const char *buf, size_t count)
> > Minor, but please fix the indentation of 'const' to match that of
> > 'struct' above. checkpatch.pl is probably issuing warnings
> > about that.
> I double checked. The indentation is correct here. It only has
> The appearance of being off by one due to the diff format.
Yes, I understand.
> >> +{
> >> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> >> + int i;
> >> +
> >> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
> >> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + gpiod_set_value(conf->config, 0);
> >> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
> >> + if (gpiod_get_value(conf->status) == 1) {
> >> + dev_err(&mgr->dev, "Status pin should be low.\n");
> >> + return -EIO;
> >> + }
> >> +
> >> + gpiod_set_value(conf->config, 1);
> >> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
> >> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
> >> + if (gpiod_get_value(conf->status))
> >> + return 0;
> >> + }
> >> +
> >> + dev_err(&mgr->dev, "Status pin not ready.\n");
> >> + return -EIO;
> >> +}
> >> +
> >> +static void rev_buf(void *buf, size_t len)
> >> +{
> >> + u32 *fw32 = (u32 *)buf;
> >> + const u32 *fw_end = (u32 *)(buf + len);
> >> +
> >> + /* set buffer to lsb first */
> >> + while (fw32 < fw_end) {
> >> + *fw32 = bitrev8x4(*fw32);
> >> + fw32++;
> >> + }
> >> +}
> >> +
> >> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> >> + size_t count)
> > Please fix alignment here also.
> Same as above. Indentation is OK.
>
>
> I'll get a v4 turned around soon.
No rush since the other two patches need acks from
their respective maintainers and this won't be able
to go in without them. But with that one change
it looks good to me.
Alan
> Thanks,
> Joshua
>
^ permalink raw reply
* Unable to use perf in VM
From: Wei Huang @ 2016-11-30 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a81f82da-322a-a52b-de0e-316b7ce5f463@arm.com>
On 11/30/2016 07:37 AM, Marc Zyngier wrote:
> On 30/11/16 11:48, Marc Zyngier wrote:
>> + Shannon
>>
>> On 29/11/16 22:04, Itaru Kitayama wrote:
>>> Hi,
>>>
>>> In a VM (virsh controlled, KVM acceleration enabled) on a recent
>>> kvmarm kernel host, I find I am unable to use perf to obtain
>>> performance statistics for a complex task like kernel build.
>>> (I've verified this is seen with a Fedora 25 VM and host combination
>>> as well)
>>> APM folks CC'ed think this might be caused by a bug in the core PMU
>>> framework code, thus I'd like to have experts opinion on this issue.
>>>
>>> [root at localhost linux]# perf stat -B make
>>> CHK include/config/kernel.release
>>> [ 119.617684] git[1144]: undefined instruction: pc=fffffc000808ff30
>>> [ 119.623040] Code: 51000442 92401042 d51b9ca2 d5033fdf (d53b9d40)
>>> [ 119.627607] Internal error: undefined instruction: 0 [#1] SMP
>>
>> [...]
>>
>> In a VM running mainline hosted on an AMD Seattle box:
>>
>> Performance counter stats for 'make':
>>
>> 1526089.499304 task-clock:u (msec) # 0.932 CPUs utilized
>> 0 context-switches:u # 0.000 K/sec
>> 0 cpu-migrations:u # 0.000 K/sec
>> 29527793 page-faults:u # 0.019 M/sec
>> 2913174122673 cycles:u # 1.909 GHz
>> 2365040892322 instructions:u # 0.81 insn per cycle
>> <not supported> branches:u
>> 32049215378 branch-misses:u # 0.00% of all branches
>>
>> 1637.531444837 seconds time elapsed
>>
>> Running the same host kernel on a Mustang system, the guest explodes
>> in the way you reported. The failing instruction always seems to be
>> an access to pmxevcntr_el0 (I've seen both reads and writes).
>>
>> Funnily enough, it dies if you try any HW event other than cycles
>> ("perf stat -e cycles ls" works, and "perf stat -e instructions ls"
>> explodes). Which would tend to indicate that we're screwing up
>> the counter selection, but I have no proof of that (specially that
>> the Seattle guest is working just as expected).
>
> It turns out that we *don't* inject an undef. It seems to be generated
> locally at EL1.
>
> Still digging.
Just FYI: I saw it on Mustang before. My initial thought was HW related,
but without proof. I am interested to see your findings...
>
> M.
>
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jernej Škrabec @ 2016-11-30 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130220324.3Kg4VPEw@smtp1m.mail.yandex.net>
Dne ?etrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> 2016?12?1? 02:49? Jernej Skrabec <jernej.skrabec@gmail.com>???
>
> > Hi Jean-Fran?ois,
> >
> > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-Fran?ois Moine
napisala:
> >> On Tue, 29 Nov 2016 22:59:32 +0100
> >>
> >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> >> > > > I'm still not sure which pipeline should I use.
> >> > > >
> >> > > > And, it seems that HDMI Slow Clock is not needed?
> >> > > >
> >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> >> > >
> >> > > So, I don't see how this may work.
> >> > > How can the u-boot know the resolutions of the HDMI display device?
> >> > >
> >> > > In other words: I have a new H3 board with the last u-boot and
> >> > > kernel.
> >> > > I plug my (rather old or brand new) HDMI display device.
> >> > > After powering on the system, I hope to get something on the screen.
> >> > > How?
> >> >
> >> > If it works like the driver for the first display engine in U-Boot, it
> >> > will use the preferred mode reported by the EDID, and will fallback to
> >> > 1024x768 if it cannot access it.
> >>
> >> Icenowy wrote: "simplefb won't use EDID"
> >>
> >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> >> not work with HDMI (different timings).
> >
> > U-Boot driver now accept any timings recommended by EDID. So far it
> > was tested with at least following resolutions:
> > - 1920x1080 @ 60 Hz
> > - 1280x1024 @ 60 Hz
> > - 1280x800 @ 60 Hz (slight clock difference)
> > - 800x480 (not sure about frame rate)
> > - 3840x2160 @ 30 Hz (4K)
>
> I tested on 1024x600 (If my memory is right, it's @ 60Hz)
>
> > and nobody complained so far. I'm pretty sure 1024x768 would work.
> >
> >> > Maybe it would be worth exchanging on the EDID code that has been done
> >> > for the u-boot driver too, so that it can be fixed in your driver.
> >>
> >> The u-boot got my code, and, up to now, I could not fix the random or
> >> permanent failures of EDID reading in some boards.
> >
> > I only have one OPi2, but as I said, EDID always worked for me. The only
> > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > driver (including EDID reading), TCON code is now reverted to the same as
> > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > and compare it.
>
> So is the TCON of DE 2.0 identical to the original TCON?
>
> If so, we should reuse sun4i-tcon ...
>
Well, TCON is splitted in two parts (two base addresses), one for HDMI and one
for TV. However, register offsets are same as before, so I guess driver
reusage make sense. I think that there are few additional registers, but they
can be ignored for simplefb.
> >
> >
> >> --
> >> Ken ar c'henta? | ** Breizh ha Linux atav! **
> >> Jef | http://moinejf.free.fr/
> >
> > Best regards,
> > Jernej ?krabec
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscribe at googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.
Best regards,
Jernej ?krabec
^ permalink raw reply
* [PATCH net-next] net: thunderx: Fix transmit queue timeout issue
From: David Miller @ 2016-11-30 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480419620-32500-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Tue, 29 Nov 2016 17:10:20 +0530
> + /* Check again, incase another cpu freed descriptors */
> + if (atomic_read(&sq->free_cnt) > MIN_SQ_DESC_PER_PKT_XMIT) {
> + netif_tx_start_queue(txq);
You have to use netif_tx_wake_queue() any time you restart a queue after bringing
the device up.
^ permalink raw reply
* [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Joshua Clayton @ 2016-11-30 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1611301122470.2617@atull-730U3E-740U3E>
Hi Alan,
On 11/30/2016 09:45 AM, atull wrote:
> On Wed, 30 Nov 2016, Joshua Clayton wrote:
>
> Hi Clayton,
>
> I just have a few minor one line changes below. Only one
> is operational, I should have caught that earlier.
>
Thanks for the speedy review.
>> +};
>> +MODULE_DEVICE_TABLE(of, of_ef_match);
>> +
>> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
>> +{
>> + return mgr->state;
>> +}
> This function gets called once to initialize mgr->state in
> fpga_mgr_register(). So it should at least return the state the FPGA
> is at then. If it is unknown, it can just return
> FPGA_MGR_STATE_UNKNOWN.
>
I guess I didn't understand the purpose of this function.
The driver has access to the status pin at this phase, so I can return
FPGA_MGR_STATE_UNKNOWN or FPGA_MGR_STATE_RESET depending
on the state of that pin.
>> +
>> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
>> + const char *buf, size_t count)
> Minor, but please fix the indentation of 'const' to match that of
> 'struct' above. checkpatch.pl is probably issuing warnings
> about that.
I double checked. The indentation is correct here. It only has
The appearance of being off by one due to the diff format.
>> +{
>> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> + int i;
>> +
>> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
>> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
>> + return -EINVAL;
>> + }
>> +
>> + gpiod_set_value(conf->config, 0);
>> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
>> + if (gpiod_get_value(conf->status) == 1) {
>> + dev_err(&mgr->dev, "Status pin should be low.\n");
>> + return -EIO;
>> + }
>> +
>> + gpiod_set_value(conf->config, 1);
>> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
>> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
>> + if (gpiod_get_value(conf->status))
>> + return 0;
>> + }
>> +
>> + dev_err(&mgr->dev, "Status pin not ready.\n");
>> + return -EIO;
>> +}
>> +
>> +static void rev_buf(void *buf, size_t len)
>> +{
>> + u32 *fw32 = (u32 *)buf;
>> + const u32 *fw_end = (u32 *)(buf + len);
>> +
>> + /* set buffer to lsb first */
>> + while (fw32 < fw_end) {
>> + *fw32 = bitrev8x4(*fw32);
>> + fw32++;
>> + }
>> +}
>> +
>> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
>> + size_t count)
> Please fix alignment here also.
Same as above. Indentation is OK.
I'll get a v4 turned around soon.
Thanks,
Joshua
^ permalink raw reply
* [PATCH v4 net-next 3/7] net: mvneta: Use cacheable memory to store the rx buffer virtual address
From: David Miller @ 2016-11-30 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb2f1a61e9b912905f8390f7a06c36f9f1e7ab66.1480431285.git-series.gregory.clement@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Tue, 29 Nov 2016 15:55:21 +0100
> + /* Virtual address of the RX buffer */
> + void **buf_virt_addr;
> +
> /* Virtual address of the RX DMA descriptors array */
> struct mvneta_rx_desc *descs;
>
...
> + data = (unsigned char *)rxq->buf_virt_addr[index];
This cast is unnecessary, please remove it.
^ permalink raw reply
* [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Florian Fainelli @ 2016-11-30 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480499246.17538.208.camel@baylibre.com>
On 11/30/2016 01:47 AM, Jerome Brunet wrote:
>> If we start supporting generic "enable", "disable" type of properties
>> with values that map directly to register definitions of the HW, we
>> leave too much room for these properties to be utilized to implement
>> a
>> specific policy, and this is not acceptable.
>
> Florian,
>
> I agree that DT should not be used to setup a policy, but to describe
> what the HW is.
>
> I tried to implement it the way you suggested, using phy fixup, too see
> what it looks like.
> There is 2 places in the code that seems (remotely) linked to the
> issue:
> - meson8b_dwmac driver : if the mac, regardless of the board/platform,
> could not tolerate to have EEE activated, it would make sense to have
> the fixup here. It can provide a C callback for such case.
> - realtek phy driver: philosophy is kind of the same
>
> To be clear, it is doable and it works that way, but I don't think
> embedding this directly in the code is the right way to do it. It seems
> we are hiding an information specific about the board inside a generic
> driver.
So there are a few things about that:
- if we were not on ARM64, there would be possibly a remote chance of
having some concept of a board file which would be where such a PHY
fixup, or fixup of any kind would reside
- having the PHY fixup in the PHY driver gated by both an exact match on
the PHY OUI *and* the specific affected board makes it reasonably easy
to locate it
>
> We have several amlogic's design with the same MAC, sometimes with the
> same PHY, which have no problem with EEE at all. The issue is really
> about the board design.
OK, not a problem then: of_machine_is_compatible() should help you here?
>
> What I propose is not an enable/disable configuration switch, but to
> clearly state that a particular mode of operation is broken. Like the
> "max-speed" property, it setup a restriction. IMO, this is a
> description of what the HW is and is capable of, and as such it should
> be part of the DT.
Sure, there is a fine line between describing what's broken, and being
able to use that to actually configure non-broken hardware the way you want.
>
> Yes the property directly map to a register, but it does let you
> directly manipulate it (you can't pass the value you want to write in
> the register). Having it this way just makes the code simple on both
> ends (user and driver).
That's exactly the part that is giving me the creeps, any property that
directly maps to a register value has a chance of a) leading to hard to
debug problem if mis-configured, and b) being used as a policy as
opposed to purely describing what is going on with the HW.
>
> Yes people could start abusing this to setup policy. In the end, it is
> our responsibility, as community, to make sure APIs are used in a
> proper way, and not let it be used that way.
>
> I'm open to suggestion on how improve the solution, maybe something
> which could bring more confidence that property won't be misused.
Once the binding lands in the kernel, there is absolutely zero guarantee
nor visibility in how people end-up using in e.g: DT aware bootloader,
and I am one of these people. Since there is a binding, there is
consumer code in the kernel that needs to behave properly with respect
to how the binding is defined. This is the same problem as with any kind
of ABI, and a diverse range of consumers.
--
Florian
^ permalink raw reply
* [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-30 18:21 UTC (permalink / raw)
To: linux-arm-kernel
On ThunderX systems with certain memory configurations we see the
following BUG_ON():
kernel BUG at mm/page_alloc.c:1848!
This happens for some configs with 64k page size enabled. The BUG_ON()
checks if start and end page of a memmap range belongs to the same
zone.
The BUG_ON() check fails if a memory zone contains NOMAP regions. In
this case the node information of those pages is not initialized. This
causes an inconsistency of the page links with wrong zone and node
information for that pages. NOMAP pages from node 1 still point to the
mem zone from node 0 and have the wrong nid assigned.
The reason for the mis-configuration is a change in pfn_valid() which
reports pages marked NOMAP as invalid:
68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
This causes pages marked as nomap being no long reassigned to the new
zone in memmap_init_zone() by calling __init_single_pfn().
Fixing this by restoring the old behavior of pfn_valid() to use
memblock_is_memory(). Also changing users of pfn_valid() in arm64 code
to use memblock_is_map_memory() where necessary. This only affects
code in ioremap.c. The code in mmu.c still can use the new version of
pfn_valid().
As a consequence, pfn_valid() can not be used to check if a physical
page is RAM. It just checks if there is an underlying memmap with a
valid struct page. Moreover, for performance reasons the whole memmap
(with pageblock_nr_pages number of pages) has valid pfns (SPARSEMEM
config). The memory range is extended to fit the alignment of the
memmap. Thus, pfn_valid() may return true for pfns that do not map to
physical memory. Those pages are simply not reported to the mm, they
are not marked reserved nor added to the list of free pages. Other
functions such a page_is_ram() or memblock_is_map_ memory() must be
used to check for memory and if the page can be mapped with the linear
mapping.
Since NOMAP mem ranges may need to be mapped with different mem
attributes (e.g. read-only or non-caching) we can not use linear
mapping here. The use of memblock_is_memory() in pfn_valid() may not
break this behaviour. Since commit:
e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
NOMAP mem resources are no longer marked as system RAM (IORESOURCE_
SYSTEM_RAM). Now page_is_ram() and region_intersects() (see
memremap()) do not detect NOMAP mem as system ram and NOMAP mem is not
added to the linear mapping as system RAM is.
v2:
* Added Ack
* updated description to reflect the discussion
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 2 +-
arch/arm64/mm/ioremap.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 212c4d1e2f26..166911f4a2e6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
- return memblock_is_map_memory(pfn << PAGE_SHIFT);
+ return memblock_is_memory(pfn << PAGE_SHIFT);
}
EXPORT_SYMBOL(pfn_valid);
#endif
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index 01e88c8bcab0..c17c220b0c48 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -21,6 +21,7 @@
*/
#include <linux/export.h>
+#include <linux/memblock.h>
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/io.h>
@@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
/*
* Don't allow RAM to be mapped.
*/
- if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+ if (WARN_ON(memblock_is_map_memory(phys_addr)))
return NULL;
area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap);
void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
{
/* For normal memory we already have a cacheable mapping. */
- if (pfn_valid(__phys_to_pfn(phys_addr)))
+ if (memblock_is_map_memory(phys_addr))
return (void __iomem *)__phys_to_virt(phys_addr);
return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox