* [PATCH 12/12] ARM: dts: imx6ul-14x14-evk: Move regulators out of simple-bus
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
It is not recommended to place regulator nodes inside simple-bus, so
move them out in order to fix the following build warnings with W=1:
arch/arm/boot/dts/imx6ul-14x14-evk.dtb: Warning (simple_bus_reg): Node /regulators/sd1_regulator missing or empty reg/ranges property
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
index e5d3ef8..18fdb08 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
@@ -30,19 +30,14 @@
status = "okay";
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
- reg_sd1_vmmc: sd1_regulator {
- compatible = "regulator-fixed";
- regulator-name = "VSD_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- gpio = <&gpio1 9 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
+ reg_sd1_vmmc: regulator-sd1-vmmc {
+ compatible = "regulator-fixed";
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
};
sound {
--
2.7.4
^ permalink raw reply related
* [PATCH 01/12] ARM: dts: imx51-ts4800: Fix syscon and touschscreen nodes
From: Damien Riegel @ 2017-12-01 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
Hi,
On Fri, Dec 01, 2017 at 05:24:34PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> The syscon node has an incorrect notation for its unit address and the
> wdt node has an unneeded unit address.
>
> Fix them so that the following build warnings with W=1 are gone:
>
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/syscon at b0010000/wdt at e has a unit name, but no reg property
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/touchscreen has a reg or ranges property, but no unit name
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (simple_bus_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/syscon at b0010000 simple-bus unit address format error, expected "10000"
> arch/arm/boot/dts/imx51-ts4800.dtb: Warning (simple_bus_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/touchscreen simple-bus unit address format error, expected "12000"
>
> Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Changes are fine to me, thank you for fixing the warnings. I don't know
what the rule is and if I should reply with a tag like Reviewed-by or
anything else, please let me know.
--
Damien
^ permalink raw reply
* [PATCH 01/12] ARM: dts: imx51-ts4800: Fix syscon and touschscreen nodes
From: Fabio Estevam @ 2017-12-01 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201194516.ix2oa7waxy5ph55s@workotop.localdomain>
Hi Damien,
On Fri, Dec 1, 2017 at 5:45 PM, Damien Riegel
<damien.riegel@savoirfairelinux.com> wrote:
> Changes are fine to me, thank you for fixing the warnings. I don't know
> what the rule is and if I should reply with a tag like Reviewed-by or
> anything else, please let me know.
Thanks for reviewing it.
If you could reply with a Reviewed-by or with a Tested-by (if you are
able to test it in the real hardware), that would be nice.
Thanks
^ permalink raw reply
* [PATCH 0/4] add support of pinctrl to MT7622 SoC
From: Linus Walleij @ 2017-12-01 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1511840374.git.sean.wang@mediatek.com>
On Tue, Nov 28, 2017 at 4:49 AM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> The patchset adds support for pinctrl on MT7622 SoC.
It would be good if the other Mediatek driver authors,
Honzhou, Yingjoe, Biao and Maoguang could review this patch set.
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] revert ARM SCPI changes for v4.15-rc1
From: Kevin Hilman @ 2017-12-01 19:53 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
These ARM SCPI changes caused SCPI regressions resulting in CPUfreq
failures on most Amlogic SoCs (found by kernelci.org.)
Unfortunately, this was not caught in linux-next due to other
bugs/panics on these platforms masking this problem so we've only found
it since we've fixed the other issues.
Since we're already in the -rc cycle, I'd prefer to revert to a known
working state (that of v4.14) rather than finding/reverting a subset,
which would just lead to another untested state.
These changes can then have some time to be better reviewed and tested
and resubmitted for v4.16.
I've tested this revert on the affect Amlogic SoCs and verified that
we're back to the previous (working) condition.
Also, I'm sending the pull directly to arm-soc instead of Sudeeep
because I understand that Sudeep is currently out-of-office and unlikely
to be able to address this himself during the -rc cycle.
Please pull,
Thanks,
Kevin
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/scpi-revert
for you to fetch changes up to 5f56b7f4854aaab34eb570c24a1866b2050fc3f5:
Revert "Merge tag 'scpi-updates-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers" (2017-12-01 10:56:35 -0800)
----------------------------------------------------------------
Revert ARM SCPI changes since v4.14.
Untested changes caused regressions in SCPI and CPUfreq/DVFS failures
on most Amlogic SoCs. Changes reverted for v4.15 so they can be
better reviewed and tested.
----------------------------------------------------------------
Kevin Hilman (1):
Revert "Merge tag 'scpi-updates-4.15' of git://git.kernel.org/.../sudeep.holla/linux into next/drivers"
drivers/firmware/arm_scpi.c | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------
1 file changed, 129 insertions(+), 87 deletions(-)
^ permalink raw reply
* [PATCH 01/12] ARM: dts: imx51-ts4800: Fix syscon and touschscreen nodes
From: Damien Riegel @ 2017-12-01 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Cdp4g0QRC1S0w9P+Uv5TmoPoO7qsU3aJ+-1mXNGRPDeA@mail.gmail.com>
On Fri, Dec 01, 2017 at 05:48:19PM -0200, Fabio Estevam wrote:
> Hi Damien,
>
> On Fri, Dec 1, 2017 at 5:45 PM, Damien Riegel
> <damien.riegel@savoirfairelinux.com> wrote:
>
> > Changes are fine to me, thank you for fixing the warnings. I don't know
> > what the rule is and if I should reply with a tag like Reviewed-by or
> > anything else, please let me know.
>
> Thanks for reviewing it.
>
> If you could reply with a Reviewed-by or with a Tested-by (if you are
> able to test it in the real hardware), that would be nice.
I don't have the hardware at hand to test it right now, so here is my
reviewed-by instead.
Reviewed-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
--
Damien
^ permalink raw reply
* [PATCH 1/8] ARM: dts: imx7d-sbc-iot: add initial iot gateway dts
From: Fabio Estevam @ 2017-12-01 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130201434.14122-2-tyler@opensourcefoundries.com>
On Thu, Nov 30, 2017 at 6:14 PM, <tyler@opensourcefoundries.com> wrote:
> +&ecspi3 {
> + fsl,spi-num-chipselects = <1>;
Please remove this property. It is no longer used.
> + dvicape at 39 {
> + compatible = "sil164_simple";
This compatible string does not exist.
> +&lcdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_lcdif_dat
> + &pinctrl_lcdif_ctrl>;
> + display = <&display0>;
> + status = "okay";
> +
> + display0: display {
> + bits-per-pixel = <24>;
> + bus-width = <24>;
> +
> + display-timings {
> + native-mode = <&timing0>;
> + timing0: dvi {
> + /* 1024x768p60 */
> + clock-frequency = <65000000>;
> + hactive = <1024>;
> + hfront-porch = <40>;
> + hback-porch = <220>;
> + hsync-len = <60>;
> + vactive = <768>;
> + vfront-porch = <7>;
> + vback-porch = <21>;
> + vsync-len = <10>;
> +
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <1>;
> + pixelclk-active = <0>;
Which panel is this? Could you use a simple panel driver compatible
string instead?
> + };
> + };
> + };
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart2>;
> + assigned-clocks = <&clks IMX7D_UART2_ROOT_SRC>;
> + assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
> + fsl,uart-has-rtscts;
Please use 'uart-has-rtscts' instead.
> + status = "okay";
> +};
> +
> +&uart5 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart5>;
> + assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
> + assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
> + fsl,uart-has-rtscts;
Ditto.
> + status = "okay";
> +};
> +
> +&uart7 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart7>;
> + assigned-clocks = <&clks IMX7D_UART7_ROOT_SRC>;
> + assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
> + fsl,uart-has-rtscts;
Ditto
^ permalink raw reply
* [PATCH 2/8] ARM: dts: imx7: build imx7d-sbc-iot-imx7 dtb
From: Fabio Estevam @ 2017-12-01 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130201434.14122-3-tyler@opensourcefoundries.com>
On Thu, Nov 30, 2017 at 6:14 PM, <tyler@opensourcefoundries.com> wrote:
> From: Tyler Baker <tyler@opensourcefoundries.com>
>
> Build the imx7d-sbc-iot-imx7 device tree blob.
>
> Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9..0334137 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -515,6 +515,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
> imx7d-nitrogen7.dtb \
> imx7d-pico.dtb \
> imx7d-sbc-imx7.dtb \
> + imx7d-sbc-iot-imx7.dtb \
This could be part of the previous patch that introduces the dts.
^ permalink raw reply
* [PATCH 3/8] ARM: dts: imx7d-cl-som: add nodes for usbh, and usbotg2
From: Fabio Estevam @ 2017-12-01 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130201434.14122-4-tyler@opensourcefoundries.com>
On Thu, Nov 30, 2017 at 6:14 PM, <tyler@opensourcefoundries.com> wrote:
> From: Tyler Baker <tyler@opensourcefoundries.com>
>
> Add device tree nodes for the USB hub, and USB OTG. i2c2 on this
> platform supports low state retention power state so lets use it.
>
> Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
> ---
> arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 36 +++++++++++++++++++++++++--------
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> index ae45af1..a9f690b 100644
> --- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> +++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
> @@ -30,6 +30,16 @@
> gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> };
> +
> + reg_usbh_nreset: regulator at 4 {
You should not use @4. Please make sure that regulators are not used
inside simple-bus.
> -
> pinctrl_uart1: uart1grp {
> fsl,pins = <
> MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX 0x79
> @@ -284,4 +297,11 @@
> MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x14 /* OTG PWREN */
> >;
> };
> -};
> \ No newline at end of file
This text here looks strange :-)
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX7D_PAD_LPSR_GPIO1_IO07__I2C2_SDA 0x4000000f
> + MX7D_PAD_LPSR_GPIO1_IO06__I2C2_SCL 0x4000000f
> + >;
> + };
> +};
> --
> 2.9.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 4/8] ARM: dts: imx7s: add dma support
From: Fabio Estevam @ 2017-12-01 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130201434.14122-5-tyler@opensourcefoundries.com>
On Thu, Nov 30, 2017 at 6:14 PM, <tyler@opensourcefoundries.com> wrote:
> From: Tyler Baker <tyler@opensourcefoundries.com>
>
> Enable dma on all SPI and UART interfaces.
You only touched SPI ports, not the UART.
^ permalink raw reply
* [PATCH 8/8] PCIe: imx6: imx7d: add support for phy refclk source
From: Fabio Estevam @ 2017-12-01 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130201434.14122-9-tyler@opensourcefoundries.com>
On Thu, Nov 30, 2017 at 6:14 PM, <tyler@opensourcefoundries.com> wrote:
> From: Tyler Baker <tyler@opensourcefoundries.com>
>
> In the i.MX7D the PCIe PHY can use either externel oscillator or
> internal PLL as a reference clock source.
> Add support for the PHY Reference Clock source including
> device tree property phy-ref-clk.
> External oscillator is used as a default reference clock source.
>
> Signed-off-by: Tyler Baker <tyler@opensourcefoundries.com>
> Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
Please submit this one to the PCI list and PCI maintainers.
As you are adding a new property you should update
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt.
> ---
> drivers/pci/dwc/pci-imx6.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index b734835..e935db4 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -45,6 +45,7 @@ enum imx6_pcie_variants {
> struct imx6_pcie {
> struct dw_pcie *pci;
> int reset_gpio;
> + u32 phy_refclk;
Could this be bool instead?
> bool gpio_active_high;
> struct clk *pcie_bus;
> struct clk *pcie_phy;
> @@ -474,7 +475,7 @@ static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
> switch (imx6_pcie->variant) {
> case IMX7D:
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> - IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
> + BIT(5), imx6_pcie->phy_refclk ? BIT(5) : 0);
> break;
> case IMX6SX:
> regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> @@ -733,6 +734,11 @@ static int imx6_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(pci->dbi_base))
> return PTR_ERR(pci->dbi_base);
>
> + /* Fetch PHY Reference Clock */
> + if (of_property_read_u32(node, "phy-ref-clk", &imx6_pcie->phy_refclk))
You could use of_property_read_bool instead.
^ permalink raw reply
* [PATCH] ARM: dts: imx6sx-sdb: Add DRM panel, power-enable and backlight support
From: Fabio Estevam @ 2017-12-01 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512046929-18597-1-git-send-email-marco.franchi@nxp.com>
The Subject could be improved to something like: Convert from fbdev to
drm bindings
On Thu, Nov 30, 2017 at 11:02 AM, Marco Franchi <marco.franchi@nxp.com> wrote:
> It is preferred to use the panel compatible string rather than passing
> the LCD timming in the device tree.
Typo: timing
>
> So pass the "sii,43wvf1g" compatible string, a new driver for the Seiko
> Panel, which describes the parallel LCD.
Please remove the "a new driver for the Seiko Panel".
>
> This new driver needs two power supply, so pass 'dvdd-supply' and
> 'avdd-supply', which makes the kernel to turn on the LCD on is own.
I would remove this too.
>
> Also, pass the 'backlight' property as described in
> Documentation/devicetree/bindings/display/panel/simple-panel.txt
>
> Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
> ---
> arch/arm/boot/dts/imx6sx-sdb.dtsi | 49 ++++++++++++++++++++-------------------
> 1 file changed, 25 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi b/arch/arm/boot/dts/imx6sx-sdb.dtsi
> index da81552..3a597a4 100644
> --- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
> +++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
> @@ -24,7 +24,7 @@
> reg = <0x80000000 0x40000000>;
> };
>
> - backlight {
> + backlight_display: backlight-display {
> compatible = "pwm-backlight";
> pwms = <&pwm3 0 5000000>;
> brightness-levels = <0 4 8 16 32 64 128 255>;
> @@ -129,6 +129,14 @@
> regulator-max-microvolt = <3300000>;
> gpios = <&gpio2 6 GPIO_ACTIVE_LOW>;
> };
> +
> + reg_lcd_5v: regulator at 7 {
> + compatible = "regulator-fixed";
> + reg = <7>;
> + regulator-name = "lcd-5v0";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
I have sent a patch that removes the regulators from simple-panel.
Please use linux-next when you send a v2.
^ permalink raw reply
* [PATCH 0/5] crypto: arm64 - disable NEON across scatterwalk API calls
From: Ard Biesheuvel @ 2017-12-01 21:19 UTC (permalink / raw)
To: linux-arm-kernel
As reported by Sebastian, the way the arm64 NEON crypto code currently
keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is
causing problems with RT builds, given that the skcipher walk API may
allocate and free temporary buffers it uses to present the input and
output arrays to the crypto algorithm in blocksize sized chunks (where
blocksize is the natural blocksize of the crypto algorithm), and doing
so with NEON enabled means we're alloc/free'ing memory with preemption
disabled.
This was deliberate: when this code was introduced, each kernel_neon_begin()
and kernel_neon_end() call incurred a fixed penalty of storing resp.
loading the contents of all NEON registers to/from memory, and so doing
it less often had an obvious performance benefit. However, in the mean time,
we have refactored the core kernel mode NEON code, and now kernel_neon_begin()
only incurs this penalty the first time it is called after entering the kernel,
and the NEON register restore is deferred until returning to userland. This
means pulling those calls into the loops that iterate over the input/output
of the crypto algorithm is not a big deal anymore (although there are some
places in the code where we relied on the NEON registers retaining their
values between calls)
So let's clean this up for arm64: update the NEON based skcipher drivers to
no longer keep the NEON enabled when calling into the skcipher walk API.
Note that the remaining crypto drivers simply operate on fixed buffers, so
while the RT crowd may still feel the need to disable those (and the ones
below as well, perhaps), they don't call back into the crypto layer like
the ones updated by this series, and so there's no room for improvement
there AFAICT.
Cc: Dave Martin <Dave.Martin@arm.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-rt-users at vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Ard Biesheuvel (5):
crypto: arm64/aes-ce-ccm - move kernel mode neon en/disable into loop
crypto: arm64/aes-blk - move kernel mode neon en/disable into loop
crypto: arm64/aes-bs - move kernel mode neon en/disable into loop
crypto: arm64/chacha20 - move kernel mode neon en/disable into loop
crypto: arm64/ghash - move kernel mode neon en/disable into loop
arch/arm64/crypto/aes-ce-ccm-glue.c | 47 +++++-----
arch/arm64/crypto/aes-glue.c | 81 +++++++++---------
arch/arm64/crypto/aes-modes.S | 90 ++++++++++----------
arch/arm64/crypto/aes-neonbs-glue.c | 38 ++++-----
arch/arm64/crypto/chacha20-neon-glue.c | 4 +-
arch/arm64/crypto/ghash-ce-glue.c | 9 +-
6 files changed, 132 insertions(+), 137 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/5] crypto: arm64/aes-ce-ccm - move kernel mode neon en/disable into loop
From: Ard Biesheuvel @ 2017-12-01 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201211927.24653-1-ard.biesheuvel@linaro.org>
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code that was introduced at the time keeps the NEON
enabled throughout the execution of the crypto API methods, which may
include calls back into the crypto API that could result in memory
allocation or other actions that we should avoid when running with
preemption disabled.
Since then, we have optimized the kernel mode NEON handling, which now
restores lazily (upon return to userland), and so the preserve action
is only costly the first time it is called after entering the kernel.
So let's put the kernel_neon_begin() and kernel_neon_end() calls around
the actual invocations of the NEON crypto code, and run the remainder of
the code with kernel mode NEON disabled (and preemption enabled)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-ccm-glue.c | 47 ++++++++++----------
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
index a1254036f2b1..68b11aa690e4 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -107,11 +107,13 @@ static int ccm_init_mac(struct aead_request *req, u8 maciv[], u32 msglen)
}
static void ccm_update_mac(struct crypto_aes_ctx *key, u8 mac[], u8 const in[],
- u32 abytes, u32 *macp, bool use_neon)
+ u32 abytes, u32 *macp)
{
- if (likely(use_neon)) {
+ if (may_use_simd()) {
+ kernel_neon_begin();
ce_aes_ccm_auth_data(mac, in, abytes, macp, key->key_enc,
num_rounds(key));
+ kernel_neon_end();
} else {
if (*macp > 0 && *macp < AES_BLOCK_SIZE) {
int added = min(abytes, AES_BLOCK_SIZE - *macp);
@@ -143,8 +145,7 @@ static void ccm_update_mac(struct crypto_aes_ctx *key, u8 mac[], u8 const in[],
}
}
-static void ccm_calculate_auth_mac(struct aead_request *req, u8 mac[],
- bool use_neon)
+static void ccm_calculate_auth_mac(struct aead_request *req, u8 mac[])
{
struct crypto_aead *aead = crypto_aead_reqtfm(req);
struct crypto_aes_ctx *ctx = crypto_aead_ctx(aead);
@@ -163,7 +164,7 @@ static void ccm_calculate_auth_mac(struct aead_request *req, u8 mac[],
ltag.len = 6;
}
- ccm_update_mac(ctx, mac, (u8 *)<ag, ltag.len, &macp, use_neon);
+ ccm_update_mac(ctx, mac, (u8 *)<ag, ltag.len, &macp);
scatterwalk_start(&walk, req->src);
do {
@@ -175,7 +176,7 @@ static void ccm_calculate_auth_mac(struct aead_request *req, u8 mac[],
n = scatterwalk_clamp(&walk, len);
}
p = scatterwalk_map(&walk);
- ccm_update_mac(ctx, mac, p, n, &macp, use_neon);
+ ccm_update_mac(ctx, mac, p, n, &macp);
len -= n;
scatterwalk_unmap(p);
@@ -242,43 +243,42 @@ static int ccm_encrypt(struct aead_request *req)
u8 __aligned(8) mac[AES_BLOCK_SIZE];
u8 buf[AES_BLOCK_SIZE];
u32 len = req->cryptlen;
- bool use_neon = may_use_simd();
int err;
err = ccm_init_mac(req, mac, len);
if (err)
return err;
- if (likely(use_neon))
- kernel_neon_begin();
-
if (req->assoclen)
- ccm_calculate_auth_mac(req, mac, use_neon);
+ ccm_calculate_auth_mac(req, mac);
/* preserve the original iv for the final round */
memcpy(buf, req->iv, AES_BLOCK_SIZE);
err = skcipher_walk_aead_encrypt(&walk, req, true);
- if (likely(use_neon)) {
+ if (may_use_simd()) {
while (walk.nbytes) {
u32 tail = walk.nbytes % AES_BLOCK_SIZE;
if (walk.nbytes == walk.total)
tail = 0;
+ kernel_neon_begin();
ce_aes_ccm_encrypt(walk.dst.virt.addr,
walk.src.virt.addr,
walk.nbytes - tail, ctx->key_enc,
num_rounds(ctx), mac, walk.iv);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, tail);
}
- if (!err)
+ if (!err) {
+ kernel_neon_begin();
ce_aes_ccm_final(mac, buf, ctx->key_enc,
num_rounds(ctx));
-
- kernel_neon_end();
+ kernel_neon_end();
+ }
} else {
err = ccm_crypt_fallback(&walk, mac, buf, ctx, true);
}
@@ -301,43 +301,42 @@ static int ccm_decrypt(struct aead_request *req)
u8 __aligned(8) mac[AES_BLOCK_SIZE];
u8 buf[AES_BLOCK_SIZE];
u32 len = req->cryptlen - authsize;
- bool use_neon = may_use_simd();
int err;
err = ccm_init_mac(req, mac, len);
if (err)
return err;
- if (likely(use_neon))
- kernel_neon_begin();
-
if (req->assoclen)
- ccm_calculate_auth_mac(req, mac, use_neon);
+ ccm_calculate_auth_mac(req, mac);
/* preserve the original iv for the final round */
memcpy(buf, req->iv, AES_BLOCK_SIZE);
err = skcipher_walk_aead_decrypt(&walk, req, true);
- if (likely(use_neon)) {
+ if (may_use_simd()) {
while (walk.nbytes) {
u32 tail = walk.nbytes % AES_BLOCK_SIZE;
if (walk.nbytes == walk.total)
tail = 0;
+ kernel_neon_begin();
ce_aes_ccm_decrypt(walk.dst.virt.addr,
walk.src.virt.addr,
walk.nbytes - tail, ctx->key_enc,
num_rounds(ctx), mac, walk.iv);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, tail);
}
- if (!err)
+ if (!err) {
+ kernel_neon_begin();
ce_aes_ccm_final(mac, buf, ctx->key_enc,
num_rounds(ctx));
-
- kernel_neon_end();
+ kernel_neon_end();
+ }
} else {
err = ccm_crypt_fallback(&walk, mac, buf, ctx, false);
}
--
2.11.0
^ permalink raw reply related
* [PATCH 2/5] crypto: arm64/aes-blk - move kernel mode neon en/disable into loop
From: Ard Biesheuvel @ 2017-12-01 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201211927.24653-1-ard.biesheuvel@linaro.org>
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code that was introduced at the time keeps the NEON
enabled throughout the execution of the crypto API methods, which may
include calls back into the crypto API that could result in memory
allocation or other actions that we should avoid when running with
preemption disabled.
Since then, we have optimized the kernel mode NEON handling, which now
restores lazily (upon return to userland), and so the preserve action
is only costly the first time it is called after entering the kernel.
So let's put the kernel_neon_begin() and kernel_neon_end() calls around
the actual invocations of the NEON crypto code, and run the remainder of
the code with kernel mode NEON disabled (and preemption enabled)
Note that this requires some reshuffling of the registers in the asm
code, because the XTS routines can no longer rely on the registers to
retain their contents between invocations.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-glue.c | 81 +++++++++---------
arch/arm64/crypto/aes-modes.S | 90 ++++++++++----------
arch/arm64/crypto/aes-neonbs-glue.c | 14 ++-
3 files changed, 90 insertions(+), 95 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 998ba519a026..c983a2bfebe3 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -64,17 +64,17 @@ MODULE_LICENSE("GPL v2");
/* defined in aes-modes.S */
asmlinkage void aes_ecb_encrypt(u8 out[], u8 const in[], u8 const rk[],
- int rounds, int blocks, int first);
+ int rounds, int blocks);
asmlinkage void aes_ecb_decrypt(u8 out[], u8 const in[], u8 const rk[],
- int rounds, int blocks, int first);
+ int rounds, int blocks);
asmlinkage void aes_cbc_encrypt(u8 out[], u8 const in[], u8 const rk[],
- int rounds, int blocks, u8 iv[], int first);
+ int rounds, int blocks, u8 iv[]);
asmlinkage void aes_cbc_decrypt(u8 out[], u8 const in[], u8 const rk[],
- int rounds, int blocks, u8 iv[], int first);
+ int rounds, int blocks, u8 iv[]);
asmlinkage void aes_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[],
- int rounds, int blocks, u8 ctr[], int first);
+ int rounds, int blocks, u8 ctr[]);
asmlinkage void aes_xts_encrypt(u8 out[], u8 const in[], u8 const rk1[],
int rounds, int blocks, u8 const rk2[], u8 iv[],
@@ -133,19 +133,19 @@ static int ecb_encrypt(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct crypto_aes_ctx *ctx = crypto_skcipher_ctx(tfm);
- int err, first, rounds = 6 + ctx->key_length / 4;
+ int err, rounds = 6 + ctx->key_length / 4;
struct skcipher_walk walk;
unsigned int blocks;
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
- for (first = 1; (blocks = (walk.nbytes / AES_BLOCK_SIZE)); first = 0) {
+ while ((blocks = (walk.nbytes / AES_BLOCK_SIZE))) {
+ kernel_neon_begin();
aes_ecb_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
- (u8 *)ctx->key_enc, rounds, blocks, first);
+ (u8 *)ctx->key_enc, rounds, blocks);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -153,19 +153,19 @@ static int ecb_decrypt(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct crypto_aes_ctx *ctx = crypto_skcipher_ctx(tfm);
- int err, first, rounds = 6 + ctx->key_length / 4;
+ int err, rounds = 6 + ctx->key_length / 4;
struct skcipher_walk walk;
unsigned int blocks;
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
- for (first = 1; (blocks = (walk.nbytes / AES_BLOCK_SIZE)); first = 0) {
+ while ((blocks = (walk.nbytes / AES_BLOCK_SIZE))) {
+ kernel_neon_begin();
aes_ecb_decrypt(walk.dst.virt.addr, walk.src.virt.addr,
- (u8 *)ctx->key_dec, rounds, blocks, first);
+ (u8 *)ctx->key_dec, rounds, blocks);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -173,20 +173,19 @@ static int cbc_encrypt(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct crypto_aes_ctx *ctx = crypto_skcipher_ctx(tfm);
- int err, first, rounds = 6 + ctx->key_length / 4;
+ int err, rounds = 6 + ctx->key_length / 4;
struct skcipher_walk walk;
unsigned int blocks;
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
- for (first = 1; (blocks = (walk.nbytes / AES_BLOCK_SIZE)); first = 0) {
+ while ((blocks = (walk.nbytes / AES_BLOCK_SIZE))) {
+ kernel_neon_begin();
aes_cbc_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
- (u8 *)ctx->key_enc, rounds, blocks, walk.iv,
- first);
+ (u8 *)ctx->key_enc, rounds, blocks, walk.iv);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -194,20 +193,19 @@ static int cbc_decrypt(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct crypto_aes_ctx *ctx = crypto_skcipher_ctx(tfm);
- int err, first, rounds = 6 + ctx->key_length / 4;
+ int err, rounds = 6 + ctx->key_length / 4;
struct skcipher_walk walk;
unsigned int blocks;
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
- for (first = 1; (blocks = (walk.nbytes / AES_BLOCK_SIZE)); first = 0) {
+ while ((blocks = (walk.nbytes / AES_BLOCK_SIZE))) {
+ kernel_neon_begin();
aes_cbc_decrypt(walk.dst.virt.addr, walk.src.virt.addr,
- (u8 *)ctx->key_dec, rounds, blocks, walk.iv,
- first);
+ (u8 *)ctx->key_dec, rounds, blocks, walk.iv);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -215,20 +213,18 @@ static int ctr_encrypt(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct crypto_aes_ctx *ctx = crypto_skcipher_ctx(tfm);
- int err, first, rounds = 6 + ctx->key_length / 4;
+ int err, rounds = 6 + ctx->key_length / 4;
struct skcipher_walk walk;
int blocks;
err = skcipher_walk_virt(&walk, req, true);
- first = 1;
- kernel_neon_begin();
while ((blocks = (walk.nbytes / AES_BLOCK_SIZE))) {
+ kernel_neon_begin();
aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
- (u8 *)ctx->key_enc, rounds, blocks, walk.iv,
- first);
+ (u8 *)ctx->key_enc, rounds, blocks, walk.iv);
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
- first = 0;
+ kernel_neon_end();
}
if (walk.nbytes) {
u8 __aligned(8) tail[AES_BLOCK_SIZE];
@@ -241,12 +237,13 @@ static int ctr_encrypt(struct skcipher_request *req)
*/
blocks = -1;
+ kernel_neon_begin();
aes_ctr_encrypt(tail, NULL, (u8 *)ctx->key_enc, rounds,
- blocks, walk.iv, first);
+ blocks, walk.iv);
+ kernel_neon_end();
crypto_xor_cpy(tdst, tsrc, tail, nbytes);
err = skcipher_walk_done(&walk, 0);
}
- kernel_neon_end();
return err;
}
@@ -272,14 +269,14 @@ static int xts_encrypt(struct skcipher_request *req)
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
for (first = 1; (blocks = (walk.nbytes / AES_BLOCK_SIZE)); first = 0) {
+ kernel_neon_begin();
aes_xts_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
(u8 *)ctx->key1.key_enc, rounds, blocks,
(u8 *)ctx->key2.key_enc, walk.iv, first);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -294,14 +291,14 @@ static int xts_decrypt(struct skcipher_request *req)
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
for (first = 1; (blocks = (walk.nbytes / AES_BLOCK_SIZE)); first = 0) {
+ kernel_neon_begin();
aes_xts_decrypt(walk.dst.virt.addr, walk.src.virt.addr,
(u8 *)ctx->key1.key_dec, rounds, blocks,
(u8 *)ctx->key2.key_enc, walk.iv, first);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -425,7 +422,7 @@ static int cmac_setkey(struct crypto_shash *tfm, const u8 *in_key,
/* encrypt the zero vector */
kernel_neon_begin();
- aes_ecb_encrypt(ctx->consts, (u8[AES_BLOCK_SIZE]){}, rk, rounds, 1, 1);
+ aes_ecb_encrypt(ctx->consts, (u8[AES_BLOCK_SIZE]){}, rk, rounds, 1);
kernel_neon_end();
cmac_gf128_mul_by_x(consts, consts);
@@ -454,8 +451,8 @@ static int xcbc_setkey(struct crypto_shash *tfm, const u8 *in_key,
return err;
kernel_neon_begin();
- aes_ecb_encrypt(key, ks[0], rk, rounds, 1, 1);
- aes_ecb_encrypt(ctx->consts, ks[1], rk, rounds, 2, 0);
+ aes_ecb_encrypt(key, ks[0], rk, rounds, 1);
+ aes_ecb_encrypt(ctx->consts, ks[1], rk, rounds, 2);
kernel_neon_end();
return cbcmac_setkey(tfm, key, sizeof(key));
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index 2674d43d1384..65b273667b34 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -40,24 +40,24 @@
#if INTERLEAVE == 2
aes_encrypt_block2x:
- encrypt_block2x v0, v1, w3, x2, x6, w7
+ encrypt_block2x v0, v1, w3, x2, x8, w7
ret
ENDPROC(aes_encrypt_block2x)
aes_decrypt_block2x:
- decrypt_block2x v0, v1, w3, x2, x6, w7
+ decrypt_block2x v0, v1, w3, x2, x8, w7
ret
ENDPROC(aes_decrypt_block2x)
#elif INTERLEAVE == 4
aes_encrypt_block4x:
- encrypt_block4x v0, v1, v2, v3, w3, x2, x6, w7
+ encrypt_block4x v0, v1, v2, v3, w3, x2, x8, w7
ret
ENDPROC(aes_encrypt_block4x)
aes_decrypt_block4x:
- decrypt_block4x v0, v1, v2, v3, w3, x2, x6, w7
+ decrypt_block4x v0, v1, v2, v3, w3, x2, x8, w7
ret
ENDPROC(aes_decrypt_block4x)
@@ -86,33 +86,32 @@ ENDPROC(aes_decrypt_block4x)
#define FRAME_POP
.macro do_encrypt_block2x
- encrypt_block2x v0, v1, w3, x2, x6, w7
+ encrypt_block2x v0, v1, w3, x2, x8, w7
.endm
.macro do_decrypt_block2x
- decrypt_block2x v0, v1, w3, x2, x6, w7
+ decrypt_block2x v0, v1, w3, x2, x8, w7
.endm
.macro do_encrypt_block4x
- encrypt_block4x v0, v1, v2, v3, w3, x2, x6, w7
+ encrypt_block4x v0, v1, v2, v3, w3, x2, x8, w7
.endm
.macro do_decrypt_block4x
- decrypt_block4x v0, v1, v2, v3, w3, x2, x6, w7
+ decrypt_block4x v0, v1, v2, v3, w3, x2, x8, w7
.endm
#endif
/*
* aes_ecb_encrypt(u8 out[], u8 const in[], u8 const rk[], int rounds,
- * int blocks, int first)
+ * int blocks)
* aes_ecb_decrypt(u8 out[], u8 const in[], u8 const rk[], int rounds,
- * int blocks, int first)
+ * int blocks)
*/
AES_ENTRY(aes_ecb_encrypt)
FRAME_PUSH
- cbz w5, .LecbencloopNx
enc_prepare w3, x2, x5
@@ -148,7 +147,6 @@ AES_ENDPROC(aes_ecb_encrypt)
AES_ENTRY(aes_ecb_decrypt)
FRAME_PUSH
- cbz w5, .LecbdecloopNx
dec_prepare w3, x2, x5
@@ -184,14 +182,12 @@ AES_ENDPROC(aes_ecb_decrypt)
/*
* aes_cbc_encrypt(u8 out[], u8 const in[], u8 const rk[], int rounds,
- * int blocks, u8 iv[], int first)
+ * int blocks, u8 iv[])
* aes_cbc_decrypt(u8 out[], u8 const in[], u8 const rk[], int rounds,
- * int blocks, u8 iv[], int first)
+ * int blocks, u8 iv[])
*/
AES_ENTRY(aes_cbc_encrypt)
- cbz w6, .Lcbcencloop
-
ld1 {v0.16b}, [x5] /* get iv */
enc_prepare w3, x2, x6
@@ -209,7 +205,6 @@ AES_ENDPROC(aes_cbc_encrypt)
AES_ENTRY(aes_cbc_decrypt)
FRAME_PUSH
- cbz w6, .LcbcdecloopNx
ld1 {v7.16b}, [x5] /* get iv */
dec_prepare w3, x2, x6
@@ -264,20 +259,19 @@ AES_ENDPROC(aes_cbc_decrypt)
/*
* aes_ctr_encrypt(u8 out[], u8 const in[], u8 const rk[], int rounds,
- * int blocks, u8 ctr[], int first)
+ * int blocks, u8 ctr[])
*/
AES_ENTRY(aes_ctr_encrypt)
FRAME_PUSH
- cbz w6, .Lctrnotfirst /* 1st time around? */
+
enc_prepare w3, x2, x6
ld1 {v4.16b}, [x5]
-.Lctrnotfirst:
- umov x8, v4.d[1] /* keep swabbed ctr in reg */
- rev x8, x8
+ umov x6, v4.d[1] /* keep swabbed ctr in reg */
+ rev x6, x6
#if INTERLEAVE >= 2
- cmn w8, w4 /* 32 bit overflow? */
+ cmn w6, w4 /* 32 bit overflow? */
bcs .Lctrloop
.LctrloopNx:
subs w4, w4, #INTERLEAVE
@@ -285,11 +279,11 @@ AES_ENTRY(aes_ctr_encrypt)
#if INTERLEAVE == 2
mov v0.8b, v4.8b
mov v1.8b, v4.8b
- rev x7, x8
- add x8, x8, #1
+ rev x7, x6
+ add x6, x6, #1
ins v0.d[1], x7
- rev x7, x8
- add x8, x8, #1
+ rev x7, x6
+ add x6, x6, #1
ins v1.d[1], x7
ld1 {v2.16b-v3.16b}, [x1], #32 /* get 2 input blocks */
do_encrypt_block2x
@@ -298,7 +292,7 @@ AES_ENTRY(aes_ctr_encrypt)
st1 {v0.16b-v1.16b}, [x0], #32
#else
ldr q8, =0x30000000200000001 /* addends 1,2,3[,0] */
- dup v7.4s, w8
+ dup v7.4s, w6
mov v0.16b, v4.16b
add v7.4s, v7.4s, v8.4s
mov v1.16b, v4.16b
@@ -316,9 +310,9 @@ AES_ENTRY(aes_ctr_encrypt)
eor v2.16b, v7.16b, v2.16b
eor v3.16b, v5.16b, v3.16b
st1 {v0.16b-v3.16b}, [x0], #64
- add x8, x8, #INTERLEAVE
+ add x6, x6, #INTERLEAVE
#endif
- rev x7, x8
+ rev x7, x6
ins v4.d[1], x7
cbz w4, .Lctrout
b .LctrloopNx
@@ -328,10 +322,10 @@ AES_ENTRY(aes_ctr_encrypt)
#endif
.Lctrloop:
mov v0.16b, v4.16b
- encrypt_block v0, w3, x2, x6, w7
+ encrypt_block v0, w3, x2, x8, w7
- adds x8, x8, #1 /* increment BE ctr */
- rev x7, x8
+ adds x6, x6, #1 /* increment BE ctr */
+ rev x7, x6
ins v4.d[1], x7
bcs .Lctrcarry /* overflow? */
@@ -385,15 +379,17 @@ CPU_BE( .quad 0x87, 1 )
AES_ENTRY(aes_xts_encrypt)
FRAME_PUSH
- cbz w7, .LxtsencloopNx
-
ld1 {v4.16b}, [x6]
- enc_prepare w3, x5, x6
- encrypt_block v4, w3, x5, x6, w7 /* first tweak */
- enc_switch_key w3, x2, x6
+ cbz w7, .Lxtsencnotfirst
+
+ enc_prepare w3, x5, x8
+ encrypt_block v4, w3, x5, x8, w7 /* first tweak */
+ enc_switch_key w3, x2, x8
ldr q7, .Lxts_mul_x
b .LxtsencNx
+.Lxtsencnotfirst:
+ enc_prepare w3, x2, x8
.LxtsencloopNx:
ldr q7, .Lxts_mul_x
next_tweak v4, v4, v7, v8
@@ -442,7 +438,7 @@ AES_ENTRY(aes_xts_encrypt)
.Lxtsencloop:
ld1 {v1.16b}, [x1], #16
eor v0.16b, v1.16b, v4.16b
- encrypt_block v0, w3, x2, x6, w7
+ encrypt_block v0, w3, x2, x8, w7
eor v0.16b, v0.16b, v4.16b
st1 {v0.16b}, [x0], #16
subs w4, w4, #1
@@ -450,6 +446,7 @@ AES_ENTRY(aes_xts_encrypt)
next_tweak v4, v4, v7, v8
b .Lxtsencloop
.Lxtsencout:
+ st1 {v4.16b}, [x6]
FRAME_POP
ret
AES_ENDPROC(aes_xts_encrypt)
@@ -457,15 +454,17 @@ AES_ENDPROC(aes_xts_encrypt)
AES_ENTRY(aes_xts_decrypt)
FRAME_PUSH
- cbz w7, .LxtsdecloopNx
-
ld1 {v4.16b}, [x6]
- enc_prepare w3, x5, x6
- encrypt_block v4, w3, x5, x6, w7 /* first tweak */
- dec_prepare w3, x2, x6
+ cbz w7, .Lxtsdecnotfirst
+
+ enc_prepare w3, x5, x8
+ encrypt_block v4, w3, x5, x8, w7 /* first tweak */
+ dec_prepare w3, x2, x8
ldr q7, .Lxts_mul_x
b .LxtsdecNx
+.Lxtsdecnotfirst:
+ dec_prepare w3, x2, x8
.LxtsdecloopNx:
ldr q7, .Lxts_mul_x
next_tweak v4, v4, v7, v8
@@ -514,7 +513,7 @@ AES_ENTRY(aes_xts_decrypt)
.Lxtsdecloop:
ld1 {v1.16b}, [x1], #16
eor v0.16b, v1.16b, v4.16b
- decrypt_block v0, w3, x2, x6, w7
+ decrypt_block v0, w3, x2, x8, w7
eor v0.16b, v0.16b, v4.16b
st1 {v0.16b}, [x0], #16
subs w4, w4, #1
@@ -522,6 +521,7 @@ AES_ENTRY(aes_xts_decrypt)
next_tweak v4, v4, v7, v8
b .Lxtsdecloop
.Lxtsdecout:
+ st1 {v4.16b}, [x6]
FRAME_POP
ret
AES_ENDPROC(aes_xts_decrypt)
diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c
index c55d68ccb89f..9d823c77ec84 100644
--- a/arch/arm64/crypto/aes-neonbs-glue.c
+++ b/arch/arm64/crypto/aes-neonbs-glue.c
@@ -46,10 +46,9 @@ asmlinkage void aesbs_xts_decrypt(u8 out[], u8 const in[], u8 const rk[],
/* borrowed from aes-neon-blk.ko */
asmlinkage void neon_aes_ecb_encrypt(u8 out[], u8 const in[], u32 const rk[],
- int rounds, int blocks, int first);
+ int rounds, int blocks);
asmlinkage void neon_aes_cbc_encrypt(u8 out[], u8 const in[], u32 const rk[],
- int rounds, int blocks, u8 iv[],
- int first);
+ int rounds, int blocks, u8 iv[]);
struct aesbs_ctx {
u8 rk[13 * (8 * AES_BLOCK_SIZE) + 32];
@@ -157,7 +156,7 @@ static int cbc_encrypt(struct skcipher_request *req)
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct aesbs_cbc_ctx *ctx = crypto_skcipher_ctx(tfm);
struct skcipher_walk walk;
- int err, first = 1;
+ int err;
err = skcipher_walk_virt(&walk, req, true);
@@ -167,10 +166,9 @@ static int cbc_encrypt(struct skcipher_request *req)
/* fall back to the non-bitsliced NEON implementation */
neon_aes_cbc_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
- ctx->enc, ctx->key.rounds, blocks, walk.iv,
- first);
+ ctx->enc, ctx->key.rounds, blocks,
+ walk.iv);
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
- first = 0;
}
kernel_neon_end();
return err;
@@ -311,7 +309,7 @@ static int __xts_crypt(struct skcipher_request *req,
kernel_neon_begin();
neon_aes_ecb_encrypt(walk.iv, walk.iv, ctx->twkey,
- ctx->key.rounds, 1, 1);
+ ctx->key.rounds, 1);
while (walk.nbytes >= AES_BLOCK_SIZE) {
unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/5] crypto: arm64/aes-bs - move kernel mode neon en/disable into loop
From: Ard Biesheuvel @ 2017-12-01 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201211927.24653-1-ard.biesheuvel@linaro.org>
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code that was introduced at the time keeps the NEON
enabled throughout the execution of the crypto API methods, which may
include calls back into the crypto API that could result in memory
allocation or other actions that we should avoid when running with
preemption disabled.
Since then, we have optimized the kernel mode NEON handling, which now
restores lazily (upon return to userland), and so the preserve action
is only costly the first time it is called after entering the kernel.
So let's put the kernel_neon_begin() and kernel_neon_end() calls around
the actual invocations of the NEON crypto code, and run the remainder of
the code with kernel mode NEON disabled (and preemption enabled)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-neonbs-glue.c | 26 +++++++++-----------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c
index 9d823c77ec84..fa09dc340a1e 100644
--- a/arch/arm64/crypto/aes-neonbs-glue.c
+++ b/arch/arm64/crypto/aes-neonbs-glue.c
@@ -101,7 +101,6 @@ static int __ecb_crypt(struct skcipher_request *req,
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
while (walk.nbytes >= AES_BLOCK_SIZE) {
unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
@@ -109,12 +108,13 @@ static int __ecb_crypt(struct skcipher_request *req,
blocks = round_down(blocks,
walk.stride / AES_BLOCK_SIZE);
+ kernel_neon_begin();
fn(walk.dst.virt.addr, walk.src.virt.addr, ctx->rk,
ctx->rounds, blocks);
+ kernel_neon_end();
err = skcipher_walk_done(&walk,
walk.nbytes - blocks * AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -160,17 +160,17 @@ static int cbc_encrypt(struct skcipher_request *req)
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
while (walk.nbytes >= AES_BLOCK_SIZE) {
unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
/* fall back to the non-bitsliced NEON implementation */
+ kernel_neon_begin();
neon_aes_cbc_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
ctx->enc, ctx->key.rounds, blocks,
walk.iv);
+ kernel_neon_end();
err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -183,7 +183,6 @@ static int cbc_decrypt(struct skcipher_request *req)
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
while (walk.nbytes >= AES_BLOCK_SIZE) {
unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
@@ -191,13 +190,14 @@ static int cbc_decrypt(struct skcipher_request *req)
blocks = round_down(blocks,
walk.stride / AES_BLOCK_SIZE);
+ kernel_neon_begin();
aesbs_cbc_decrypt(walk.dst.virt.addr, walk.src.virt.addr,
ctx->key.rk, ctx->key.rounds, blocks,
walk.iv);
+ kernel_neon_end();
err = skcipher_walk_done(&walk,
walk.nbytes - blocks * AES_BLOCK_SIZE);
}
- kernel_neon_end();
return err;
}
@@ -231,7 +231,6 @@ static int ctr_encrypt(struct skcipher_request *req)
err = skcipher_walk_virt(&walk, req, true);
- kernel_neon_begin();
while (walk.nbytes > 0) {
unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
u8 *final = (walk.total % AES_BLOCK_SIZE) ? buf : NULL;
@@ -242,8 +241,10 @@ static int ctr_encrypt(struct skcipher_request *req)
final = NULL;
}
+ kernel_neon_begin();
aesbs_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
ctx->rk, ctx->rounds, blocks, walk.iv, final);
+ kernel_neon_end();
if (final) {
u8 *dst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
@@ -258,8 +259,6 @@ static int ctr_encrypt(struct skcipher_request *req)
err = skcipher_walk_done(&walk,
walk.nbytes - blocks * AES_BLOCK_SIZE);
}
- kernel_neon_end();
-
return err;
}
@@ -307,9 +306,8 @@ static int __xts_crypt(struct skcipher_request *req,
err = skcipher_walk_virt(&walk, req, true);
kernel_neon_begin();
-
- neon_aes_ecb_encrypt(walk.iv, walk.iv, ctx->twkey,
- ctx->key.rounds, 1);
+ neon_aes_ecb_encrypt(walk.iv, walk.iv, ctx->twkey, ctx->key.rounds, 1);
+ kernel_neon_end();
while (walk.nbytes >= AES_BLOCK_SIZE) {
unsigned int blocks = walk.nbytes / AES_BLOCK_SIZE;
@@ -318,13 +316,13 @@ static int __xts_crypt(struct skcipher_request *req,
blocks = round_down(blocks,
walk.stride / AES_BLOCK_SIZE);
+ kernel_neon_begin();
fn(walk.dst.virt.addr, walk.src.virt.addr, ctx->key.rk,
ctx->key.rounds, blocks, walk.iv);
+ kernel_neon_end();
err = skcipher_walk_done(&walk,
walk.nbytes - blocks * AES_BLOCK_SIZE);
}
- kernel_neon_end();
-
return err;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 4/5] crypto: arm64/chacha20 - move kernel mode neon en/disable into loop
From: Ard Biesheuvel @ 2017-12-01 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201211927.24653-1-ard.biesheuvel@linaro.org>
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code that was introduced at the time keeps the NEON
enabled throughout the execution of the crypto API methods, which may
include calls back into the crypto API that could result in memory
allocation or other actions that we should avoid when running with
preemption disabled.
Since then, we have optimized the kernel mode NEON handling, which now
restores lazily (upon return to userland), and so the preserve action
is only costly the first time it is called after entering the kernel.
So let's put the kernel_neon_begin() and kernel_neon_end() calls around
the actual invocations of the NEON crypto code, and run the remainder of
the code with kernel mode NEON disabled (and preemption enabled)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/chacha20-neon-glue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/chacha20-neon-glue.c b/arch/arm64/crypto/chacha20-neon-glue.c
index cbdb75d15cd0..b9ca7bef428a 100644
--- a/arch/arm64/crypto/chacha20-neon-glue.c
+++ b/arch/arm64/crypto/chacha20-neon-glue.c
@@ -36,6 +36,7 @@ static void chacha20_doneon(u32 *state, u8 *dst, const u8 *src,
{
u8 buf[CHACHA20_BLOCK_SIZE];
+ kernel_neon_begin();
while (bytes >= CHACHA20_BLOCK_SIZE * 4) {
chacha20_4block_xor_neon(state, dst, src);
bytes -= CHACHA20_BLOCK_SIZE * 4;
@@ -55,6 +56,7 @@ static void chacha20_doneon(u32 *state, u8 *dst, const u8 *src,
chacha20_block_xor_neon(state, buf, buf);
memcpy(dst, buf, bytes);
}
+ kernel_neon_end();
}
static int chacha20_neon(struct skcipher_request *req)
@@ -72,7 +74,6 @@ static int chacha20_neon(struct skcipher_request *req)
crypto_chacha20_init(state, ctx, walk.iv);
- kernel_neon_begin();
while (walk.nbytes > 0) {
unsigned int nbytes = walk.nbytes;
@@ -83,7 +84,6 @@ static int chacha20_neon(struct skcipher_request *req)
nbytes);
err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
}
- kernel_neon_end();
return err;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 5/5] crypto: arm64/ghash - move kernel mode neon en/disable into loop
From: Ard Biesheuvel @ 2017-12-01 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201211927.24653-1-ard.biesheuvel@linaro.org>
When kernel mode NEON was first introduced on arm64, the preserve and
restore of the userland NEON state was completely unoptimized, and
involved saving all registers on each call to kernel_neon_begin(),
and restoring them on each call to kernel_neon_end(). For this reason,
the NEON crypto code that was introduced at the time keeps the NEON
enabled throughout the execution of the crypto API methods, which may
include calls back into the crypto API that could result in memory
allocation or other actions that we should avoid when running with
preemption disabled.
Since then, we have optimized the kernel mode NEON handling, which now
restores lazily (upon return to userland), and so the preserve action
is only costly the first time it is called after entering the kernel.
So let's put the kernel_neon_begin() and kernel_neon_end() calls around
the actual invocations of the NEON crypto code, and run the remainder of
the code with kernel mode NEON disabled (and preemption enabled)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/ghash-ce-glue.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/ghash-ce-glue.c b/arch/arm64/crypto/ghash-ce-glue.c
index cfc9c92814fd..ddd9b565d775 100644
--- a/arch/arm64/crypto/ghash-ce-glue.c
+++ b/arch/arm64/crypto/ghash-ce-glue.c
@@ -368,20 +368,22 @@ static int gcm_encrypt(struct aead_request *req)
pmull_gcm_encrypt_block(ks, iv, NULL,
num_rounds(&ctx->aes_key));
put_unaligned_be32(3, iv + GCM_IV_SIZE);
+ kernel_neon_end();
err = skcipher_walk_aead_encrypt(&walk, req, true);
while (walk.nbytes >= AES_BLOCK_SIZE) {
int blocks = walk.nbytes / AES_BLOCK_SIZE;
+ kernel_neon_begin();
pmull_gcm_encrypt(blocks, dg, walk.dst.virt.addr,
walk.src.virt.addr, &ctx->ghash_key,
iv, num_rounds(&ctx->aes_key), ks);
+ kernel_neon_end();
err = skcipher_walk_done(&walk,
walk.nbytes % AES_BLOCK_SIZE);
}
- kernel_neon_end();
} else {
__aes_arm64_encrypt(ctx->aes_key.key_enc, tag, iv,
num_rounds(&ctx->aes_key));
@@ -467,15 +469,18 @@ static int gcm_decrypt(struct aead_request *req)
pmull_gcm_encrypt_block(tag, iv, ctx->aes_key.key_enc,
num_rounds(&ctx->aes_key));
put_unaligned_be32(2, iv + GCM_IV_SIZE);
+ kernel_neon_end();
err = skcipher_walk_aead_decrypt(&walk, req, true);
while (walk.nbytes >= AES_BLOCK_SIZE) {
int blocks = walk.nbytes / AES_BLOCK_SIZE;
+ kernel_neon_begin();
pmull_gcm_decrypt(blocks, dg, walk.dst.virt.addr,
walk.src.virt.addr, &ctx->ghash_key,
iv, num_rounds(&ctx->aes_key));
+ kernel_neon_end();
err = skcipher_walk_done(&walk,
walk.nbytes % AES_BLOCK_SIZE);
@@ -483,8 +488,6 @@ static int gcm_decrypt(struct aead_request *req)
if (walk.nbytes)
pmull_gcm_encrypt_block(iv, iv, NULL,
num_rounds(&ctx->aes_key));
-
- kernel_neon_end();
} else {
__aes_arm64_encrypt(ctx->aes_key.key_enc, tag, iv,
num_rounds(&ctx->aes_key));
--
2.11.0
^ permalink raw reply related
* [PATCH] nvmem: meson-mx-efuse: fix reading from an offset other than 0
From: Martin Blumenstingl @ 2017-12-01 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171112183412.12806-1-martin.blumenstingl@googlemail.com>
Hi Srinivas, Hi Greg,
On Sun, Nov 12, 2017 at 7:34 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> meson_mx_efuse_read calculates the address internal to the eFuse based
> on the offset and the word size. This works fine with any given offset.
> However, the offset is also included when writing to the output buffer.
> This means that reading 4 bytes at offset 500 tries to write beyond the
> array allocated by the nvmem core as it wants to write the 4 bytes to
> "buffer address + offset (500)".
> This issue did not show up in the previous tests since no driver uses
> any value from the eFuse yet and reading the eFuse via sysfs simply
> reads the whole eFuse, starting at offset 0.
>
> Fix this by only including the offset in the internal address
> calculation.
>
> Fixes: 8caef1fa9176 ("nvmem: add a driver for the Amlogic Meson6/Meson8/Meson8b SoCs")
if you don't have any comments on this patch: could you please queue
it as a fix for 4.15 (which is where above commit landed)?
thank you!
Regards
Martin
^ permalink raw reply
* [PATCH 0/4] Move DP phy switch to PHY driver
From: Doug Anderson @ 2017-12-01 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6fb4d29-6c6d-7f39-3cdd-3bc42c4519a2@rock-chips.com>
Hi,
On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong <zyw@rock-chips.com> wrote:
> Hi Doug
>
> Thank you for mentioning this patch.
>
> I think the focus of the discussion is: can we put the grf control bit to
> dts.
>
> The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"
>
> can help to switch these 2 phy. So I think this bit can be considered as a
> part of
>
> Type-C phy, these 2 phy have different bits, just similar to other bits
> (such as "pipe-status").
>
> Put them to DTS file might be a accepted practice.
I guess the first step would be finding the person to make a decision.
Is that Heiko? Olof? Kishon? Rob?. As I see it there are a few
options:
1. Land this series as-is. This makes the new bit work just like all
the other ones next to it. If anyone happens to try to use an old
device tree on a new kernel they'll break. Seems rather unlikely
given that the whole type C PHY is not really fully functional
upstream, but technically this is a no-no from a device tree
perspective.
2. Change the series to make this property optional. If it's not
there then the code behaves like it always did. This would address
the "compatibility" problem but likely wouldn't actually help any real
people, and it would be extra work.
3. Redo the driver to deprecate all the old offsets / bits and just
put the table in the driver, keyed off the compatible string and base
address if the IO memory.
I can't make this decision. It's up to those folks who would be
landing the patch and I'd be happy with any of them. What I'm less
happy with, however, is the indecision preventing forward progress.
We should pick one of the above things and land it. My own personal
bias is #1: just land the series. No real people will be hurt and
it's just adding another property that matches the ones next to it.
>From a long term perspective (AKA how I'd write the next driver like
this) I personally lean towards to "tables in the driver, not in the
device tree" but quite honestly I'm happy to take whatever direction
the maintainers give.
-Doug
^ permalink raw reply
* [PATCH v6 0/2] memory: Introduce ti-emif-sram driver
From: Santosh Shilimkar @ 2017-12-01 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201175418.GS28152@atomide.com>
On 12/1/2017 9:54 AM, Tony Lindgren wrote:
> * Dave Gerlach <d-gerlach@ti.com> [171130 22:58]:
>> This is a resend of v5 of this series found here [1]. It introduces
>> relocatable PM handlers for the emif that are copied to sram and
>> run from there during low power mode entry.
>>
>> The patches still have the previous ACKs but have a small change to
>> accomodate a change made by Tony in commit cd57dc5a2099 ("ARM: dts:
>> Add missing hwmod related nodes for am33xx"). If there are objections
>> to this let me know ASAP.
>
> Still looks good to me thanks.
>
>> Now that a hwmod is present for the am335x EMIF, on probe fail the call to
>> pm_runtime_put_sync causes the board to hang. In fact, this emif driver should
>> never alter the PM state of the hardware at all through normal kernel calls, it
>> is the job of the suspend handlers that are added, that is the whole point of
>> this driver. Because of this, I have dropped all runtime pm calls, as any
>> change to the PM state while the kernel is running is dangerous as we may shut
>> of the memory controller. It makes the most sense just to drop runtime PM from
>> the driver entirely. Besides that patch is unchanged.
>
> OK makes sense to me.
>
Thanks Tony. Will queue this version once rc1 is tagged.
Regards,
Santosh
^ permalink raw reply
* [PATCH 0/4] Move DP phy switch to PHY driver
From: Heiko Stuebner @ 2017-12-01 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=Vk0fOfYXc2gGDpvoVuT8m9WGT-eJ4hOM=G5MY_Bzzpwg@mail.gmail.com>
Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
> Hi,
>
> On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong <zyw@rock-chips.com> wrote:
> > Hi Doug
> >
> > Thank you for mentioning this patch.
> >
> > I think the focus of the discussion is: can we put the grf control bit to
> > dts.
> >
> > The RK3399 has 2 Type-C phy, but only one DP controller, this "uphy_dp_sel"
> >
> > can help to switch these 2 phy. So I think this bit can be considered as a
> > part of
> >
> > Type-C phy, these 2 phy have different bits, just similar to other bits
> > (such as "pipe-status").
> >
> > Put them to DTS file might be a accepted practice.
>
> I guess the first step would be finding the person to make a decision.
> Is that Heiko? Olof? Kishon? Rob?. As I see it there are a few
> options:
>
> 1. Land this series as-is. This makes the new bit work just like all
> the other ones next to it. If anyone happens to try to use an old
> device tree on a new kernel they'll break. Seems rather unlikely
> given that the whole type C PHY is not really fully functional
> upstream, but technically this is a no-no from a device tree
> perspective.
>
> 2. Change the series to make this property optional. If it's not
> there then the code behaves like it always did. This would address
> the "compatibility" problem but likely wouldn't actually help any real
> people, and it would be extra work.
>
> 3. Redo the driver to deprecate all the old offsets / bits and just
> put the table in the driver, keyed off the compatible string and base
> address if the IO memory.
>
>
> I can't make this decision. It's up to those folks who would be
> landing the patch and I'd be happy with any of them. What I'm less
> happy with, however, is the indecision preventing forward progress.
> We should pick one of the above things and land it. My own personal
> bias is #1: just land the series. No real people will be hurt and
> it's just adding another property that matches the ones next to it.
I'd second that #1 . That whole type-c phy thingy never fully worked in
the past (some for the never used dp output), so personally I don't have
issues with going that route.
> From a long term perspective (AKA how I'd write the next driver like
> this) I personally lean towards to "tables in the driver, not in the
> device tree" but quite honestly I'm happy to take whatever direction
> the maintainers give.
It looks like we're in agreement here :-) . GRF stuff should not leak into
the devicetree, as it causes endless headaches later. But I guess we'll
need to live with the ones that happened so far.
Heiko
^ permalink raw reply
* [kernel-hardening][PATCH v2 3/3] arm: mm: dump: add checking for writable and executable pages
From: Laura Abbott @ 2017-12-01 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201113447.GA5234@pjb1027-Latitude-E5410>
On 12/01/2017 03:34 AM, Jinbum Park wrote:
> +static inline bool is_prot_ro(struct pg_state *st)
> +{
> + if (st->level < 4) {
> + #ifdef CONFIG_ARM_LPAE
> + if ((st->current_prot &
> + (L_PMD_SECT_RDONLY | PMD_SECT_AP2)) ==
> + (L_PMD_SECT_RDONLY | PMD_SECT_AP2))
> + return true;
> + #elif __LINUX_ARM_ARCH__ >= 6
> + if ((st->current_prot &
> + (PMD_SECT_APX | PMD_SECT_AP_READ | PMD_SECT_AP_WRITE)) ==
> + (PMD_SECT_APX | PMD_SECT_AP_WRITE))
> + return true;
> + #else
> + if ((st->current_prot &
> + (PMD_SECT_AP_READ | PMD_SECT_AP_WRITE)) == 0)
> + return true;
> + #endif
> + } else {
> + if ((st->current_prot & L_PTE_RDONLY) == L_PTE_RDONLY)
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static inline bool is_prot_nx(struct pg_state *st)
> +{
> + if (st->level < 4) {
> + if ((st->current_prot & PMD_SECT_XN) == PMD_SECT_XN)
> + return true;
> + } else {
> + if ((st->current_prot & L_PTE_XN) == L_PTE_XN)
> + return true;
> + }
> +
> + return false;
> +}
I know arm64 checks the bits directly, but the arm32 code is a bit
more fiddly and I have mixed feelings about copying and pasting
the checks. It would be cleaner if we could take advantage of
the existing pg_level and bits arrays. I also don't have my heart
set on this so if nobody else objects, the code can stay as is.
Thanks,
Laura
^ permalink raw reply
* [PATCH v5 0/9] Support PPTT for ARM64
From: Jeremy Linton @ 2017-12-01 22:23 UTC (permalink / raw)
To: linux-arm-kernel
This patch set is dependent on "[14/15] ACPICA: ACPI 6.2: Additional
PPTT flags" https://patchwork.kernel.org/patch/10064191/
ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is
used to describe the processor and cache topology. Ideally it is
used to extend/override information provided by the hardware, but
right now ARM64 is entirely dependent on firmware provided tables.
This patch parses the table for the cache topology and CPU topology.
When we enable ACPI/PPTT for arm64 we map the physical_id to the
PPTT node flagged as the physical package by the firmware.
This results in topologies that match what the remainder of the
system expects.
For example on juno:
[root at mammon-juno-rh topology]# lstopo-no-graphics
Package L#0
L2 L#0 (1024KB)
L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2)
L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3)
L2 L#1 (2048KB)
L1d L#4 (32KB) + L1i L#4 (48KB) + Core L#4 + PU L#4 (P#4)
L1d L#5 (32KB) + L1i L#5 (48KB) + Core L#5 + PU L#5 (P#5)
HostBridge L#0
PCIBridge
PCIBridge
PCIBridge
PCI 1095:3132
Block(Disk) L#0 "sda"
PCIBridge
PCI 1002:68f9
GPU L#1 "renderD128"
GPU L#2 "card0"
GPU L#3 "controlD64"
PCIBridge
PCI 11ab:4380
Net L#4 "enp8s0"
Git tree at:
http://linux-arm.org/git?p=linux-jlinton.git
branch: pptt_v5
v4->v5:
Update the cache type from NOCACHE to UNIFIED when all the cache
attributes we update are valid. This fixes a problem where caches
which are entirely created by the PPTT don't show up in lstopo.
Give the PPTT its own firmware_node in the cache structure instead of
sharing it with the of_node.
Move some pieces around between patches.
v3->v4:
Suppress the "Found duplicate cache level/type..." message if the
duplicate cache entry is actually a duplicate node. This allows cases
like L1I and L1D nodes that point at the same L2 node to be accepted
without the warning.
Remove cluster/physical split code. Add a patch to rename cluster_id
so that its clear the topology may not be referring to a cluster.
Add additional ACPICA patch for the PPTT cache properties. This matches
an outstanding ACPICA pull that should be merged in the near future.
Replace a number of (struct*)((u8*)ptr+offset) constructs with ACPI_ADD_PTR
Split out the topology parsing into an additional patch.
Tweak the cpu topology code to terminate on either a level, or a flag.
Add an additional function which retrives the physical package id
for a given cpu.
Various other comments/tweaks.
v2->v3:
Remove valid bit check on leaf nodes. Now simply being a leaf node
is sufficient to verify the processor id against the ACPI
processor ids (gotten from MADT).
Use the acpi processor for the "level 0" Id. This makes the /sys
visible core/thread ids more human readable if the firmware uses
small consecutive values for processor ids.
Added PPTT to the list of injectable ACPI tables.
Fix bug which kept the code from using the processor node as intended
in v2, caused by misuse of git rebase/fixup.
v1->v2:
The parser keys off the acpi_pptt_processor node to determine
unique cache's rather than the acpi_pptt_cache referenced by the
processor node. This allows PPTT tables which "share" cache nodes
across cpu nodes despite not being a shared cache.
Jeremy Linton (9):
arm64/acpi: Create arch specific cpu to acpi id helper
ACPI/PPTT: Add Processor Properties Topology Table parsing
ACPI: Enable PPTT support on ARM64
drivers: base cacheinfo: Add support for ACPI based firmware tables
arm64: Add support for ACPI based firmware tables
ACPI/PPTT: Add topology parsing code
arm64: Topology, rename cluster_id
arm64: topology: Enable ACPI/PPTT based CPU topology.
ACPI: Add PPTT to injectable table list
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/acpi.h | 4 +
arch/arm64/include/asm/topology.h | 4 +-
arch/arm64/kernel/cacheinfo.c | 15 +-
arch/arm64/kernel/topology.c | 74 ++++-
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/pptt.c | 592 ++++++++++++++++++++++++++++++++++++++
drivers/acpi/tables.c | 3 +-
drivers/base/cacheinfo.c | 20 +-
include/linux/cacheinfo.h | 13 +-
include/linux/topology.h | 2 +
12 files changed, 703 insertions(+), 29 deletions(-)
create mode 100644 drivers/acpi/pptt.c
--
2.13.5
^ permalink raw reply
* [PATCH v5 1/9] arm64/acpi: Create arch specific cpu to acpi id helper
From: Jeremy Linton @ 2017-12-01 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201222330.18863-1-jeremy.linton@arm.com>
Its helpful to be able to lookup the acpi_processor_id associated
with a logical cpu. Provide an arm64 helper to do this.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/include/asm/acpi.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..0db62a4cbce2 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -86,6 +86,10 @@ static inline bool acpi_has_cpu_in_madt(void)
}
struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu);
+static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
+{
+ return acpi_cpu_get_madt_gicc(cpu)->uid;
+}
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
void __init acpi_init_cpus(void);
--
2.13.5
^ 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