* [PATCH net-next 0/2] drivers: net: xgene: fix: Use GPIO to get link status
From: David Miller @ 2016-10-12 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475789758-5196-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Thu, 6 Oct 2016 14:35:56 -0700
> Since the link value reported by the link status register is not
> reliable if no SPF module inserted, this patchset fixes the issue by
> using GPIO to determine the link status when no module inserted.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Quan Nguyen <qnguyen@apm.com>
Series applied, thanks.
^ permalink raw reply
* [PATCH 2/2] arm64: dts: zx: Add clock controller nodes
From: Shawn Guo @ 2016-10-12 2:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476238456-20420-2-git-send-email-jun.nie@linaro.org>
On Wed, Oct 12, 2016 at 10:14:16AM +0800, Jun Nie wrote:
> Add clock controller nodes, including one top controller
> two low speed controllers and one audio controller.
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index 6b239a3..33e42d5 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -279,9 +279,33 @@
> dma-requests = <32>;
> };
>
> + lsp0crm: clock-controller at 01420000 {
Please drop the leading zeros from unit-address in node name.
Shawn
> + compatible = "zte,zx296718-lsp0crm";
> + reg = <0x01420000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + lsp1crm: clock-controller at 01430000 {
> + compatible = "zte,zx296718-lsp1crm";
> + reg = <0x01430000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + topcrm: clock-controller at 01461000 {
> + compatible = "zte,zx296718-topcrm";
> + reg = <0x01461000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> sysctrl: sysctrl at 1463000 {
> compatible = "zte,zx296718-sysctrl", "syscon";
> reg = <0x1463000 0x1000>;
> };
> +
> + audiocrm: clock-controller at 01480000 {
> + compatible = "zte,zx296718-audiocrm";
> + reg = <0x01480000 0x1000>;
> + #clock-cells = <1>;
> + };
> };
> };
> --
> 1.9.1
>
>
> _______________________________________________
> 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 1/2] arm64: dts: zx: Change gic node to fix boot failure
From: Shawn Guo @ 2016-10-12 2:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476238456-20420-1-git-send-email-jun.nie@linaro.org>
On Wed, Oct 12, 2016 at 10:14:15AM +0800, Jun Nie wrote:
> GICR for multiple CPU can be described with start address and stride,
> or with multiple address. Current multiple address and stride are
> both used. Fix it.
I think we need to tell the full story about this boot failure in commit
log, i.e. it boots fine on v4.8-rc and fails on linux-next because of
the mm/vmalloc.c changes.
Shawn
>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
> arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index a223066..6b239a3 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -239,16 +239,11 @@
> compatible = "arm,gic-v3";
> #interrupt-cells = <3>;
> #address-cells = <0>;
> - #redistributor-regions = <6>;
> - redistributor-stride = <0x0 0x40000>;
> + #redistributor-regions = <1>;
> + redistributor-stride = <0x20000>;
> interrupt-controller;
> reg = <0x02a00000 0x10000>,
> - <0x02b00000 0x20000>,
> - <0x02b20000 0x20000>,
> - <0x02b40000 0x20000>,
> - <0x02b60000 0x20000>,
> - <0x02b80000 0x20000>,
> - <0x02ba0000 0x20000>;
> + <0x02b00000 0xc0000>;
> interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> };
>
> --
> 1.9.1
>
>
> _______________________________________________
> 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 2/2] arm64: dts: zx: Add clock controller nodes
From: Jun Nie @ 2016-10-12 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476238456-20420-1-git-send-email-jun.nie@linaro.org>
Add clock controller nodes, including one top controller
two low speed controllers and one audio controller.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..33e42d5 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -279,9 +279,33 @@
dma-requests = <32>;
};
+ lsp0crm: clock-controller at 01420000 {
+ compatible = "zte,zx296718-lsp0crm";
+ reg = <0x01420000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ lsp1crm: clock-controller at 01430000 {
+ compatible = "zte,zx296718-lsp1crm";
+ reg = <0x01430000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ topcrm: clock-controller at 01461000 {
+ compatible = "zte,zx296718-topcrm";
+ reg = <0x01461000 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysctrl: sysctrl at 1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
};
+
+ audiocrm: clock-controller at 01480000 {
+ compatible = "zte,zx296718-audiocrm";
+ reg = <0x01480000 0x1000>;
+ #clock-cells = <1>;
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: zx: Change gic node to fix boot failure
From: Jun Nie @ 2016-10-12 2:14 UTC (permalink / raw)
To: linux-arm-kernel
GICR for multiple CPU can be described with start address and stride,
or with multiple address. Current multiple address and stride are
both used. Fix it.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index a223066..6b239a3 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -239,16 +239,11 @@
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <0>;
- #redistributor-regions = <6>;
- redistributor-stride = <0x0 0x40000>;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x20000>;
interrupt-controller;
reg = <0x02a00000 0x10000>,
- <0x02b00000 0x20000>,
- <0x02b20000 0x20000>,
- <0x02b40000 0x20000>,
- <0x02b60000 0x20000>,
- <0x02b80000 0x20000>,
- <0x02ba0000 0x20000>;
+ <0x02b00000 0xc0000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: multi_v7_defconfig: Enable Intel e1000e driver
From: Scott Branden @ 2016-10-11 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8265935.TobkRj9BnG@wuerfel>
Hi Arnd,
On 16-10-10 12:47 AM, Arnd Bergmann wrote:
> On Saturday, October 8, 2016 1:41:04 PM CEST Scott Branden wrote:
>> Enable support for the Intel e1000e driver
>>
>> Signed-off-by: Ray Jui <rjui@broadcom.com>
>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>
>
> Can we make this a loadable module and group it with the other
> ethernet drivers?
>
We use a fixed rootfs image to test the kernel. For simplicity we don't
construct a rootfs or load any modules. We just test the kernel image.
So for us every defconfig we use needs to be set to y to use the
upstreamed kernel.
Plus, how do you NFS mount a rootfs if the ethernet driver is a loadable
module?
> Arnd
>
Regards,
Scott
^ permalink raw reply
* [PATCH] arm64: defconfig: enable EEPROM_AT25 config option
From: Scott Branden @ 2016-10-11 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1503155.onL8VV3RJv@wuerfel>
Hi Arnd,
On 16-10-10 02:20 AM, Arnd Bergmann wrote:
> On Monday, October 10, 2016 2:08:05 AM CEST Florian Fainelli wrote:
>> On 10/07/2016 02:23 PM, Scott Branden wrote:
>>> Enable support for on board SPI EEPROM by turning on
>>> CONFIG_EEPROM_AT25.
>>>
>>> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
>>
>> Looks fine to me, unless this needs to be a module, Arnd, what do you think?
>
> Please either make it a module or explain in the patch description
> why it should be built-in.
We use a fixed rootfs image to test the kernel. For simplicity we don't
construct a rootfs or load any modules. We just test the kernel image.
So for us every defconfig we use needs to be set to y to use the
upstreamed kernel.
>
> Arnd
>
Regards,
Scott
^ permalink raw reply
* [PATCH v1 1/2] include: dt-bindings: Add GPIO pin index definition for rockchip pinctrl
From: Heiko Stuebner @ 2016-10-11 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473210053-23743-1-git-send-email-andy.yan@rock-chips.com>
Am Mittwoch, 7. September 2016, 09:00:53 CEST schrieb Andy Yan:
> Add gpio pin index definition to make it easier to describe
> GPIO in dts.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
just as a heads up, as I didn't respond yet:
Looks good and I'll take them, I just want to wait for the merge-window to
close (should be the coming sunday), to be able to put the header change in a
shared branch for the case that other users appear during the 4.10 cycle.
Heiko
> ---
>
> Changes in v1:
> - remove gpio bank definition RK_GPIO7/8
> - redefine GPIO PIN as RK_PA/B/C/Dx
>
> include/dt-bindings/pinctrl/rockchip.h | 33
> +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
>
> diff --git a/include/dt-bindings/pinctrl/rockchip.h
> b/include/dt-bindings/pinctrl/rockchip.h index 743e66a..aaec8ba 100644
> --- a/include/dt-bindings/pinctrl/rockchip.h
> +++ b/include/dt-bindings/pinctrl/rockchip.h
> @@ -25,6 +25,39 @@
> #define RK_GPIO4 4
> #define RK_GPIO6 6
>
> +#define RK_PA0 0
> +#define RK_PA1 1
> +#define RK_PA2 2
> +#define RK_PA3 3
> +#define RK_PA4 4
> +#define RK_PA5 5
> +#define RK_PA6 6
> +#define RK_PA7 7
> +#define RK_PB0 8
> +#define RK_PB1 9
> +#define RK_PB2 10
> +#define RK_PB3 11
> +#define RK_PB4 12
> +#define RK_PB5 13
> +#define RK_PB6 14
> +#define RK_PB7 15
> +#define RK_PC0 16
> +#define RK_PC1 17
> +#define RK_PC2 18
> +#define RK_PC3 19
> +#define RK_PC4 20
> +#define RK_PC5 21
> +#define RK_PC6 22
> +#define RK_PC7 23
> +#define RK_PD0 24
> +#define RK_PD1 25
> +#define RK_PD2 26
> +#define RK_PD3 27
> +#define RK_PD4 28
> +#define RK_PD5 29
> +#define RK_PD6 30
> +#define RK_PD7 31
> +
> #define RK_FUNC_GPIO 0
> #define RK_FUNC_1 1
> #define RK_FUNC_2 2
^ permalink raw reply
* [PATCH V2 0/3] ACPI,PCI,IRQ: revert penalty calculation for SCI
From: Rafael J. Wysocki @ 2016-10-11 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475615720-31047-1-git-send-email-okaya@codeaurora.org>
On Tuesday, October 04, 2016 05:15:16 PM Sinan Kaya wrote:
> Restoring the old behavior for IRQ < 256 and the dynamic penalty behavior
> will remain effective for IRQ >= 256.
>
> By the time ACPI gets initialized, this code tries to determine an
> IRQ number based on penalty values in this array. It will try to locate
> the IRQ with the least penalty assignment so that interrupt sharing is
> avoided if possible.
>
> A couple of notes about the external APIs:
> 1. These API can be called before the ACPI is started. Therefore, one
> cannot assume that the PCI link objects are initialized for calculating
> penalties.
> 2. The polarity and trigger information passed via the
> acpi_penalize_sci_irq from the BIOS may not match what the IRQ subsystem
> is reporting as the call might have been placed before the IRQ is
> registered by the interrupt subsystem.
>
> The reverted changes were in the direction to remove these external API and
> try to calculate the penalties at runtime for the ISA, SCI as well as PCI
> IRQS. This didn't work out well with the existing platforms.
>
> Changes from V1 (https://lkml.org/lkml/2016/10/1/106):
> * Commit message updates
>
> Sinan Kaya (3):
> Revert "ACPI,PCI,IRQ: reduce static IRQ array size to 16"
> ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
> Revert "ACPI,PCI,IRQ: remove SCI penalize function"
>
> arch/x86/kernel/acpi/boot.c | 1 +
> drivers/acpi/pci_link.c | 71 ++++++++++++++++++++++-----------------------
> include/linux/acpi.h | 1 +
> 3 files changed, 37 insertions(+), 36 deletions(-)
>
I've queued up the series, but still waiting on Bjorn's response.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] MAINTAINERS: Add ARM64-specific ACPI maintainers entry
From: Rafael J. Wysocki @ 2016-10-11 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005112540.22189-1-lorenzo.pieralisi@arm.com>
On Wednesday, October 05, 2016 12:25:40 PM Lorenzo Pieralisi wrote:
> The ARM64 architecture defines ARM64 specific ACPI bindings to
> configure and set-up arch specific components. To simplify
> code reviews/updates and streamline the maintainership structure
> supporting the arch specific code, a new arm64 directory was created in
> /drivers/acpi, to contain ACPI code that is specific to ARM64
> architecture.
>
> Add the ARM64-specific ACPI maintainers entry in MAINTAINERS for
> the newly created subdirectory and respective code content.
>
> Lorenzo Pieralisi will be in charge of submitting and managing
> the pull requests on behalf of all maintainers listed.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Link: http://lkml.kernel.org/r/1603704.EGiVTcCxLR at vostro.rjw.lan
> ---
> MAINTAINERS | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f593300..2a70dd9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -316,6 +316,14 @@ W: https://01.org/linux-acpi
> S: Supported
> F: drivers/acpi/fan.c
>
> +ACPI FOR ARM64 (ACPI/arm64)
> +M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> +M: Hanjun Guo <hanjun.guo@linaro.org>
> +M: Sudeep Holla <sudeep.holla@arm.com>
> +L: linux-acpi at vger.kernel.org
> +S: Maintained
> +F: drivers/acpi/arm64
> +
> ACPI THERMAL DRIVER
> M: Zhang Rui <rui.zhang@intel.com>
> L: linux-acpi at vger.kernel.org
>
Applied (with tags).
Thanks,
Rafael
^ permalink raw reply
* latest version of bluetooth for n950?
From: Sebastian Reichel @ 2016-10-11 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011145140.cq3jex2r23wuayph@earth>
Hi,
On Tue, Oct 11, 2016 at 04:51:40PM +0200, Sebastian Reichel wrote:
> On Tue, Oct 11, 2016 at 09:47:04AM +0200, Pavel Machek wrote:
> > I got some free cycles to play with n900 and bluetooth. There's still
> > some unrelated config option that breaks even the old vesion of
> > patches, but I'm ready for more debugging now.
> >
> > Could I have the latest version of the (clean) bluetooth patch? I have
> > feeling it might work with the right config option, and would like to
> > try.
> >
> > For the record, here's working .config and the tricky tricky oneliner
> > that took me week to figure out.
>
> https://git.kernel.org/cgit/linux/kernel/git/sre/linux-n900.git/log/?h=n950-bluetooth
>
> My local branch is based on 4.8 and fixes a few of Marcel's
> comments. I'm currently at ELCE, but I will push my local
> stuff later in the hotel after verifying, that it works as
> expected (luckily I brought N950 with me :)).
It does not. Rebasing the pushed branch to v4.8 works, so the
problem is somewhere in my new changes. I will try to have a
look at it tomorrow.
The changes shouldn't affect you for any tests, though. Just
take the branch from above (and optionally rebase to v4.8).
-- Sebastian
-------------- 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/20161011/59a1c8ba/attachment.sig>
^ permalink raw reply
* [PATCH v19 01/12] fpga: add bindings document for fpga region
From: atull @ 2016-10-11 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161008204928.GB11595@rob-hp-laptop>
On Sat, 8 Oct 2016, Rob Herring wrote:
> On Wed, Sep 28, 2016 at 01:21:49PM -0500, Alan Tull wrote:
> > New bindings document for FPGA Region to support programming
> > FPGA's under Device Tree control
> >
> > Signed-off-by: Alan Tull <atull@opensource.altera.com>
> > Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> > ---
> > v9: initial version added to this patchset
> > v10: s/fpga/FPGA/g
> > replace DT overlay example with slightly more complicated example
> > move to staging/simple-fpga-bus
> > v11: No change in this patch for v11 of the patch set
> > v12: Moved out of staging.
> > Changed to use FPGA bridges framework instead of resets
> > for bridges.
> > v13: bridge at 0xff20000 -> bridge at ff200000, etc
> > Leave out directly talking about overlays
> > Remove regs and clocks directly under simple-fpga-bus in example
> > Use common "firmware-name" binding instead of "fpga-firmware"
> > v14: Use firmware-name in bindings description
> > Call it FPGA Area
> > Remove bindings that specify FPGA Manager and FPGA Bridges
> > v15: Cleanup as per Rob's comments
> > Combine usage doc with bindings document
> > Document as being Altera specific
> > Additions and changes to add FPGA Bus
> > v16: Reworked to document FPGA Regions
> > rename altera-fpga-bus-fpga-area.txt -> fpga-region.txt
> > Remove references that made it sound exclusive to Altera
> > Remove altr, prefix from fpga-bus and fpga-area compatible strings
> > Added Moritz' usage example with Xilinx
> > Cleaned up unit addresses
> > v17: Lots of rewrites to try to make things clearer
> > Clarify that overlay can be rejected if FPGA isn't programmed
> > Add external-fpga-config binding already used in u-boot
> > Change partial-reconfig binding to partial-fpga-config to align
> > with existing u-boot binding format *-fpga-config
> > Add a document from Xilinx' website
> > v18: Fix node names underscores to be hyphens
> > Fix copy/pasted duplicate nodes in diagram
> > v19: Fix more underscores
> > Make FPGA regions to be children of bridges
> > General cleanup and clarification
> > ---
> > .../devicetree/bindings/fpga/fpga-region.txt | 494 +++++++++++++++++++++
> > 1 file changed, 494 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt
>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Nice job.
>
> Rob
>
Thanks, Rob! I'll add your reviewed-by in v20 just
to make it even.
Besides that, squashing some patches and some
minor changes for the Arria10 FPGA manager support.
Alan
^ permalink raw reply
* [PATCH V3 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
From: Russell King - ARM Linux @ 2016-10-11 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475875882-2604-3-git-send-email-tbaicar@codeaurora.org>
On Fri, Oct 07, 2016 at 03:31:14PM -0600, Tyler Baicar wrote:
> +static void cper_estatus_print_section_v300(const char *pfx,
> + const struct acpi_hest_generic_data_v300 *gdata)
> +{
> + __u8 hour, min, sec, day, mon, year, century, *timestamp;
> +
> + if (gdata->validation_bits & ACPI_HEST_GEN_VALID_TIMESTAMP) {
> + timestamp = (__u8 *)&(gdata->time_stamp);
> + memcpy(&sec, timestamp, 1);
> + memcpy(&min, timestamp + 1, 1);
> + memcpy(&hour, timestamp + 2, 1);
> + memcpy(&day, timestamp + 4, 1);
> + memcpy(&mon, timestamp + 5, 1);
> + memcpy(&year, timestamp + 6, 1);
> + memcpy(¢ury, timestamp + 7, 1);
This is utterly silly. Why are you using memcpy() to access individual
bytes of a u8 pointer? What's wrong with:
sec = timestamp[0];
min = timestamp[1];
hour = timestamp[2];
day = timestamp[4];
mon = timestamp[5];
year = timestamp[6];
century = timestamp[7];
or even do the conversion here:
sec = bcd2bin(timestamp[0]);
... etc ...
> + printk("%stime: ", pfx);
> + printk("%7s", 0x01 & *(timestamp + 3) ? "precise" : "");
> + printk(" %02d:%02d:%02d %02d%02d-%02d-%02d\n",
> + bcd2bin(hour), bcd2bin(min), bcd2bin(sec),
> + bcd2bin(century), bcd2bin(year), bcd2bin(mon),
> + bcd2bin(day));
> + }
It's also a good idea to (as much as possible) keep to single printk()
statements - which makes the emission of the string more atomic wrt
other CPUs and contexts. So, this should probably become (with the
conversion being done at the assignment of sec etc):
printk("%stime: %7s %02d:%02d:%02d %02d%02d-%02d-%02d\n",
pfx, 0x01 & timestamp[3] ? "precise" : "",
hour, min, sec, century, year, mon, day);
which, IMHO, looks a lot nicer and doesn't risk some other printk()
getting between each individual part of the line.
> +}
> +
> static void cper_estatus_print_section(
> - const char *pfx, const struct acpi_hest_generic_data *gdata, int sec_no)
> + const char *pfx, struct acpi_hest_generic_data *gdata, int sec_no)
> {
> uuid_le *sec_type = (uuid_le *)gdata->section_type;
> __u16 severity;
> char newpfx[64];
>
> + if ((gdata->revision >> 8) >= 0x03)
> + cper_estatus_print_section_v300(pfx,
> + (const struct acpi_hest_generic_data_v300 *)gdata);
> +
> severity = gdata->error_severity;
> printk("%s""Error %d, type: %s\n", pfx, sec_no,
> cper_severity_str(severity));
Not sure why you have the "" here - %sError works just as well and the
"" is just obfuscation - the compiler will eliminate the double-double
quote and merge the strings anyway.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 3/5] Input: add driver for Ilitek ili2139 touch IC
From: Dmitry Torokhov @ 2016-10-11 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <220181476210841@web5j.yandex.ru>
On Wed, Oct 12, 2016 at 02:34:01AM +0800, Icenowy Zheng wrote:
>
>
> 12.10.2016, 01:40, "Dmitry Torokhov" <dmitry.torokhov@gmail.com>:
> > Hi Icenowy,
> >
> > On Tue, Oct 11, 2016 at 08:33:57AM +0800, Icenowy Zheng wrote:
> >> ?This driver adds support for Ilitek ili2139 touch IC, which is used in
> >> ?several Colorfly tablets (for example, Colorfly E708 Q1, which is an
> >> ?Allwinner A31s tablet with mainline kernel support).
> >>
> >> ?Theortically it may support more Ilitek touch ICs, however, only ili2139
> >> ?is used in any mainlined device.
> >>
> >> ?It supports device tree enumeration, with screen resolution and axis
> >> ?quirks configurable.
> >>
> >> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> >
> > Please extend ili210x.c instead of adding brand new driver, they look
> > very similar.
> >
> > Thanks.
>
> The driver is too old, lack of maintaince and needs some platform data hacks.
> (At least makes it not capable to be used on current ARM devices, as they're
> described with device tree)
There are many drivers that can do both platform and dt-setup.
>
> Maybe I will rename the new driver modified by me to ili210x, add support for
> the old protocol (but I have no chips to test it), and drop the old ili210x.
> (This driver is capable of dt probing, and uses devm_ functions)
You can add "racy on removal" to the list (you need to take care your
work is canceled at right times, and canceling it before interrupt is
freed is not the right time as interrupt might fire and the work get
scheduled again). Also I think your driver is essentially working in
polling mode because you always reschedule the delayed work.
No, like I said, please work with existing driver, adding DT support and
support for the newer version of the protocol.
Thanks.
--
Dmitry
^ permalink raw reply
* The possible regression in kernel 4.8 - clk: imx: correct AV PLL rate formula
From: Otavio Salvador @ 2016-10-11 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CVggufx2U0pZUXd1o=i36Jo-c1B=hgFcSaWeM+=oagaQ@mail.gmail.com>
On Tue, Oct 11, 2016 at 3:00 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Ken,
>
> On Tue, Oct 11, 2016 at 2:49 PM, Ken.Lin <ken.lin@advantech.com> wrote:
>
>> With the patches applied, the pixel clock (148500000 required for 1920x1080 at 60) is correct as we checked in kernel 4.7 and the actual measurement result looked good as we expected.
>> I think the patches should fix the issue.
>
> That's good news. Thanks for testing.
>
> Emil is working on a v3 version of the patch series.
>
> Emil,
>
> Please add Ken Lin on Cc when you submit v3.
And what will be done regarding 4.8? Is the faulty change to be
reverted or this patches will be backported?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* [PATCH 3/5] Input: add driver for Ilitek ili2139 touch IC
From: Icenowy Zheng @ 2016-10-11 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011174046.GA27925@dtor-ws>
12.10.2016, 01:40, "Dmitry Torokhov" <dmitry.torokhov@gmail.com>:
> Hi Icenowy,
>
> On Tue, Oct 11, 2016 at 08:33:57AM +0800, Icenowy Zheng wrote:
>> ?This driver adds support for Ilitek ili2139 touch IC, which is used in
>> ?several Colorfly tablets (for example, Colorfly E708 Q1, which is an
>> ?Allwinner A31s tablet with mainline kernel support).
>>
>> ?Theortically it may support more Ilitek touch ICs, however, only ili2139
>> ?is used in any mainlined device.
>>
>> ?It supports device tree enumeration, with screen resolution and axis
>> ?quirks configurable.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Please extend ili210x.c instead of adding brand new driver, they look
> very similar.
>
> Thanks.
The driver is too old, lack of maintaince and needs some platform data hacks.
(At least makes it not capable to be used on current ARM devices, as they're
described with device tree)
Maybe I will rename the new driver modified by me to ili210x, add support for
the old protocol (but I have no chips to test it), and drop the old ili210x.
(This driver is capable of dt probing, and uses devm_ functions)
>
>> ?---
>> ??drivers/input/touchscreen/Kconfig | 14 ++
>> ??drivers/input/touchscreen/Makefile | 1 +
>> ??drivers/input/touchscreen/ili2139.c | 320 ++++++++++++++++++++++++++++++++++++
>> ??3 files changed, 335 insertions(+)
>> ??create mode 100644 drivers/input/touchscreen/ili2139.c
>>
>> ?diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
>> ?index 5079813..bb4d9d2 100644
>> ?--- a/drivers/input/touchscreen/Kconfig
>> ?+++ b/drivers/input/touchscreen/Kconfig
>> ?@@ -348,6 +348,20 @@ config TOUCHSCREEN_ILI210X
>> ????????????To compile this driver as a module, choose M here: the
>> ????????????module will be called ili210x.
>>
>> ?+config TOUCHSCREEN_ILI2139
>> ?+ tristate "Ilitek ILI2139 based touchscreen"
>> ?+ depends on I2C
>> ?+ depends on OF
>> ?+ help
>> ?+ Say Y here if you have a ILI2139 based touchscreen
>> ?+ controller. Such kind of chipsets can be found in several
>> ?+ Colorfly tablets.
>> ?+
>> ?+ If unsure, say N.
>> ?+
>> ?+ To compile this driver as a module, choose M here; the
>> ?+ module will be called ili2139.
>> ?+
>> ??config TOUCHSCREEN_IPROC
>> ??????????tristate "IPROC touch panel driver support"
>> ??????????depends on ARCH_BCM_IPROC || COMPILE_TEST
>> ?diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
>> ?index 81b8645..930b5e2 100644
>> ?--- a/drivers/input/touchscreen/Makefile
>> ?+++ b/drivers/input/touchscreen/Makefile
>> ?@@ -40,6 +40,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX_SERIAL) += egalax_ts_serial.o
>> ??obj-$(CONFIG_TOUCHSCREEN_FUJITSU) += fujitsu_ts.o
>> ??obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix.o
>> ??obj-$(CONFIG_TOUCHSCREEN_ILI210X) += ili210x.o
>> ?+obj-$(CONFIG_TOUCHSCREEN_ILI2139) += ili2139.o
>> ??obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC) += imx6ul_tsc.o
>> ??obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
>> ??obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
>> ?diff --git a/drivers/input/touchscreen/ili2139.c b/drivers/input/touchscreen/ili2139.c
>> ?new file mode 100644
>> ?index 0000000..65c2dea
>> ?--- /dev/null
>> ?+++ b/drivers/input/touchscreen/ili2139.c
>> ?@@ -0,0 +1,320 @@
>> ?+/* -------------------------------------------------------------------------
>> ?+ * Copyright (C) 2016, Icenowy Zheng <icenowy@aosc.xyz>
>> ?+ *
>> ?+ * Derived from:
>> ?+ * ili210x.c
>> ?+ * Copyright (C) Olivier Sobrie <olivier@sobrie.be>
>> ?+ *
>> ?+ * This program is free software; you can redistribute it and/or modify
>> ?+ * it under the terms of the GNU General Public License as published by
>> ?+ * the Free Software Foundation; either version 2 of the License, or
>> ?+ * (at your option) any later version.
>> ?+ *
>> ?+ * This program is distributed in the hope that it will be useful,
>> ?+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> ?+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> ?+ * GNU General Public License for more details.
>> ?+ * -------------------------------------------------------------------------
>> ?+ */
>> ?+
>> ?+#include <linux/module.h>
>> ?+#include <linux/i2c.h>
>> ?+#include <linux/interrupt.h>
>> ?+#include <linux/slab.h>
>> ?+#include <linux/input.h>
>> ?+#include <linux/input/mt.h>
>> ?+#include <linux/input/touchscreen.h>
>> ?+#include <linux/delay.h>
>> ?+#include <linux/workqueue.h>
>> ?+
>> ?+#define DEFAULT_POLL_PERIOD 20
>> ?+
>> ?+#define MAX_TOUCHES 10
>> ?+#define COMPATIBLE_TOUCHES 2
>> ?+
>> ?+/* Touchscreen commands */
>> ?+#define REG_TOUCHDATA 0x10
>> ?+#define REG_TOUCHSUBDATA 0x11
>> ?+#define REG_PANEL_INFO 0x20
>> ?+#define REG_FIRMWARE_VERSION 0x40
>> ?+#define REG_PROTO_VERSION 0x42
>> ?+
>> ?+#define SUBDATA_STATUS_TOUCH_POINT 0x80
>> ?+#define SUBDATA_STATUS_RELEASE_POINT 0x00
>> ?+
>> ?+struct finger {
>> ?+ u8 x_low;
>> ?+ u8 x_high;
>> ?+ u8 y_low;
>> ?+ u8 y_high;
>> ?+} __packed;
>> ?+
>> ?+struct touchdata {
>> ?+ u8 length;
>> ?+ struct finger finger[COMPATIBLE_TOUCHES];
>> ?+} __packed;
>> ?+
>> ?+struct touch_subdata {
>> ?+ u8 status;
>> ?+ struct finger finger;
>> ?+} __packed;
>> ?+
>> ?+struct panel_info {
>> ?+ struct finger finger_max;
>> ?+ u8 xchannel_num;
>> ?+ u8 ychannel_num;
>> ?+} __packed;
>> ?+
>> ?+struct firmware_version {
>> ?+ u8 id;
>> ?+ u8 major;
>> ?+ u8 minor;
>> ?+} __packed;
>> ?+
>> ?+struct ili2139 {
>> ?+ struct i2c_client *client;
>> ?+ struct input_dev *input;
>> ?+ unsigned int poll_period;
>> ?+ struct delayed_work dwork;
>> ?+ struct touchscreen_properties prop;
>> ?+ int slots[MAX_TOUCHES];
>> ?+ int ids[MAX_TOUCHES];
>> ?+ struct input_mt_pos pos[MAX_TOUCHES];
>> ?+};
>> ?+
>> ?+static int ili2139_read_reg(struct i2c_client *client, u8 reg, void *buf,
>> ?+ size_t len)
>> ?+{
>> ?+ struct i2c_msg msg[2] = {
>> ?+ {
>> ?+ .addr = client->addr,
>> ?+ .flags = 0,
>> ?+ .len = 1,
>> ?+ .buf = ®,
>> ?+ },
>> ?+ {
>> ?+ .addr = client->addr,
>> ?+ .flags = I2C_M_RD,
>> ?+ .len = len,
>> ?+ .buf = buf,
>> ?+ }
>> ?+ };
>> ?+
>> ?+ if (i2c_transfer(client->adapter, msg, 2) != 2) {
>> ?+ dev_err(&client->dev, "i2c transfer failed\n");
>> ?+ return -EIO;
>> ?+ }
>> ?+
>> ?+ return 0;
>> ?+}
>> ?+
>> ?+static void ili2139_work(struct work_struct *work)
>> ?+{
>> ?+ int id;
>> ?+ struct ili2139 *priv = container_of(work, struct ili2139,
>> ?+ dwork.work);
>> ?+ struct i2c_client *client = priv->client;
>> ?+ struct touchdata touchdata;
>> ?+ struct touch_subdata subdata;
>> ?+ int error;
>> ?+
>> ?+ error = ili2139_read_reg(client, REG_TOUCHDATA,
>> ?+ &touchdata, sizeof(touchdata));
>> ?+ if (error) {
>> ?+ dev_err(&client->dev,
>> ?+ "Unable to get touchdata, err = %d\n", error);
>> ?+ return;
>> ?+ }
>> ?+
>> ?+ for (id = 0; id < touchdata.length; id++) {
>> ?+ error = ili2139_read_reg(client, REG_TOUCHSUBDATA, &subdata,
>> ?+ sizeof(subdata));
>> ?+ if (error) {
>> ?+ dev_err(&client->dev,
>> ?+ "Unable to get touch subdata, err = %d\n",
>> ?+ error);
>> ?+ return;
>> ?+ }
>> ?+
>> ?+ priv->ids[id] = subdata.status & 0x3F;
>> ?+
>> ?+ /* The sequence changed in the v2 subdata protocol. */
>> ?+ touchscreen_set_mt_pos(&priv->pos[id], &priv->prop,
>> ?+ (subdata.finger.x_high | (subdata.finger.x_low << 8)),
>> ?+ (subdata.finger.y_high | (subdata.finger.y_low << 8)));
>> ?+ }
>> ?+
>> ?+ input_mt_assign_slots(priv->input, priv->slots, priv->pos,
>> ?+ touchdata.length, 0);
>> ?+
>> ?+ for (id = 0; id < touchdata.length; id++) {
>> ?+ input_mt_slot(priv->input, priv->slots[id]);
>> ?+ input_mt_report_slot_state(priv->input, MT_TOOL_FINGER,
>> ?+ subdata.status &
>> ?+ SUBDATA_STATUS_TOUCH_POINT);
>> ?+ input_report_abs(priv->input, ABS_MT_POSITION_X,
>> ?+ priv->pos[id].x);
>> ?+ input_report_abs(priv->input, ABS_MT_POSITION_Y,
>> ?+ priv->pos[id].y);
>> ?+ }
>> ?+
>> ?+ input_mt_sync_frame(priv->input);
>> ?+ input_sync(priv->input);
>> ?+
>> ?+ schedule_delayed_work(&priv->dwork,
>> ?+ msecs_to_jiffies(priv->poll_period));
>> ?+}
>> ?+
>> ?+static irqreturn_t ili2139_irq(int irq, void *irq_data)
>> ?+{
>> ?+ struct ili2139 *priv = irq_data;
>> ?+
>> ?+ schedule_delayed_work(&priv->dwork, 0);
>> ?+
>> ?+ return IRQ_HANDLED;
>> ?+}
>> ?+
>> ?+static int ili2139_i2c_probe(struct i2c_client *client,
>> ?+ const struct i2c_device_id *id)
>> ?+{
>> ?+ struct device *dev = &client->dev;
>> ?+ struct ili2139 *priv;
>> ?+ struct input_dev *input;
>> ?+ struct panel_info panel;
>> ?+ struct firmware_version firmware;
>> ?+ int xmax, ymax;
>> ?+ int error;
>> ?+
>> ?+ dev_dbg(dev, "Probing for ILI2139 I2C Touschreen driver");
>> ?+
>> ?+ if (client->irq <= 0) {
>> ?+ dev_err(dev, "No IRQ!\n");
>> ?+ return -ENODEV;
>> ?+ }
>> ?+
>> ?+ /* Get firmware version */
>> ?+ error = ili2139_read_reg(client, REG_FIRMWARE_VERSION,
>> ?+ &firmware, sizeof(firmware));
>> ?+ if (error) {
>> ?+ dev_err(dev, "Failed to get firmware version, err: %d\n",
>> ?+ error);
>> ?+ return error;
>> ?+ }
>> ?+
>> ?+ /* get panel info */
>> ?+ error = ili2139_read_reg(client, REG_PANEL_INFO, &panel, sizeof(panel));
>> ?+ if (error) {
>> ?+ dev_err(dev, "Failed to get panel information, err: %d\n",
>> ?+ error);
>> ?+ return error;
>> ?+ }
>> ?+
>> ?+ xmax = panel.finger_max.x_low | (panel.finger_max.x_high << 8);
>> ?+ ymax = panel.finger_max.y_low | (panel.finger_max.y_high << 8);
>> ?+
>> ?+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> ?+ input = devm_input_allocate_device(dev);
>> ?+ if (!priv || !input)
>> ?+ return -ENOMEM;
>> ?+
>> ?+ priv->client = client;
>> ?+ priv->input = input;
>> ?+ priv->poll_period = DEFAULT_POLL_PERIOD;
>> ?+ INIT_DELAYED_WORK(&priv->dwork, ili2139_work);
>> ?+
>> ?+ /* Setup input device */
>> ?+ input->name = "ILI2139 Touchscreen";
>> ?+ input->id.bustype = BUS_I2C;
>> ?+ input->dev.parent = dev;
>> ?+
>> ?+ __set_bit(EV_SYN, input->evbit);
>> ?+ __set_bit(EV_KEY, input->evbit);
>> ?+ __set_bit(EV_ABS, input->evbit);
>> ?+
>> ?+ /* Multi touch */
>> ?+ input_mt_init_slots(input, MAX_TOUCHES, INPUT_MT_DIRECT |
>> ?+ INPUT_MT_DROP_UNUSED | INPUT_MT_TRACK);
>> ?+ input_set_abs_params(input, ABS_MT_POSITION_X, 0, xmax, 0, 0);
>> ?+ input_set_abs_params(input, ABS_MT_POSITION_Y, 0, ymax, 0, 0);
>> ?+
>> ?+ touchscreen_parse_properties(input, true, &priv->prop);
>> ?+
>> ?+ input_set_drvdata(input, priv);
>> ?+ i2c_set_clientdata(client, priv);
>> ?+
>> ?+ error = devm_request_irq(dev, client->irq, ili2139_irq,
>> ?+ IRQF_TRIGGER_FALLING, client->name, priv);
>> ?+ if (error) {
>> ?+ dev_err(dev, "Unable to request touchscreen IRQ, err: %d\n",
>> ?+ error);
>> ?+ return error;
>> ?+ }
>> ?+
>> ?+ error = input_register_device(priv->input);
>> ?+ if (error) {
>> ?+ dev_err(dev, "Cannot register input device, err: %d\n", error);
>> ?+ return error;
>> ?+ }
>> ?+
>> ?+ device_init_wakeup(&client->dev, 1);
>> ?+
>> ?+ dev_dbg(dev,
>> ?+ "ILI2139 initialized (IRQ: %d), firmware version %d.%d.%d",
>> ?+ client->irq, firmware.id, firmware.major, firmware.minor);
>> ?+
>> ?+ return 0;
>> ?+}
>> ?+
>> ?+static int ili2139_i2c_remove(struct i2c_client *client)
>> ?+{
>> ?+ struct ili2139 *priv = i2c_get_clientdata(client);
>> ?+
>> ?+ cancel_delayed_work_sync(&priv->dwork);
>> ?+
>> ?+ return 0;
>> ?+}
>> ?+
>> ?+static int __maybe_unused ili2139_i2c_suspend(struct device *dev)
>> ?+{
>> ?+ struct i2c_client *client = to_i2c_client(dev);
>> ?+
>> ?+ if (device_may_wakeup(&client->dev))
>> ?+ enable_irq_wake(client->irq);
>> ?+
>> ?+ return 0;
>> ?+}
>> ?+
>> ?+static int __maybe_unused ili2139_i2c_resume(struct device *dev)
>> ?+{
>> ?+ struct i2c_client *client = to_i2c_client(dev);
>> ?+
>> ?+ if (device_may_wakeup(&client->dev))
>> ?+ disable_irq_wake(client->irq);
>> ?+
>> ?+ return 0;
>> ?+}
>> ?+
>> ?+static SIMPLE_DEV_PM_OPS(ili2139_i2c_pm,
>> ?+ ili2139_i2c_suspend, ili2139_i2c_resume);
>> ?+
>> ?+static const struct i2c_device_id ili2139_i2c_id[] = {
>> ?+ { "ili2139", 0 },
>> ?+ { }
>> ?+};
>> ?+MODULE_DEVICE_TABLE(i2c, ili2139_i2c_id);
>> ?+
>> ?+static struct i2c_driver ili2139_ts_driver = {
>> ?+ .driver = {
>> ?+ .name = "ili2139_i2c",
>> ?+ .pm = &ili2139_i2c_pm,
>> ?+ },
>> ?+ .id_table = ili2139_i2c_id,
>> ?+ .probe = ili2139_i2c_probe,
>> ?+ .remove = ili2139_i2c_remove,
>> ?+};
>> ?+
>> ?+module_i2c_driver(ili2139_ts_driver);
>> ?+
>> ?+MODULE_AUTHOR("Olivier Sobrie <olivier@sobrie.be>");
>> ?+MODULE_DESCRIPTION("ILI2139 I2C Touchscreen Driver");
>> ?+MODULE_LICENSE("GPL");
>> ?--
>> ?2.10.1
>
> --
> Dmitry
^ permalink raw reply
* [PATCH v2 8/8] crypto: arm/aes-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
The AES key schedule generation is mostly endian agnostic, with the
exception of the rotation and the incorporation of the round constant
at the start of each round. So implement a big endian specific version
of that part to make the whole routine big endian compatible.
Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index aef022a87c53..04410d9f5e72 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -88,8 +88,13 @@ static int ce_aes_expandkey(struct crypto_aes_ctx *ctx, const u8 *in_key,
u32 *rki = ctx->key_enc + (i * kwords);
u32 *rko = rki + kwords;
+#ifndef CONFIG_CPU_BIG_ENDIAN
rko[0] = ror32(ce_aes_sub(rki[kwords - 1]), 8);
rko[0] = rko[0] ^ rki[0] ^ rcon[i];
+#else
+ rko[0] = rol32(ce_aes_sub(rki[kwords - 1]), 8);
+ rko[0] = rko[0] ^ rki[0] ^ (rcon[i] << 24);
+#endif
rko[1] = rko[0] ^ rki[1];
rko[2] = rko[1] ^ rki[2];
rko[3] = rko[2] ^ rki[3];
--
2.7.4
^ permalink raw reply related
* [PATCH v2 7/8] crypto: arm64/aes-xts-ce: fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
Emit the XTS tweak literal constants in the appropriate order for a
single 128-bit scalar literal load.
Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce.S | 1 +
arch/arm64/crypto/aes-modes.S | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-ce.S b/arch/arm64/crypto/aes-ce.S
index 78f3cfe92c08..b46093d567e5 100644
--- a/arch/arm64/crypto/aes-ce.S
+++ b/arch/arm64/crypto/aes-ce.S
@@ -10,6 +10,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#define AES_ENTRY(func) ENTRY(ce_ ## func)
#define AES_ENDPROC(func) ENDPROC(ce_ ## func)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index f6e372c528eb..c53dbeae79f2 100644
--- a/arch/arm64/crypto/aes-modes.S
+++ b/arch/arm64/crypto/aes-modes.S
@@ -386,7 +386,8 @@ AES_ENDPROC(aes_ctr_encrypt)
.endm
.Lxts_mul_x:
- .word 1, 0, 0x87, 0
+CPU_LE( .quad 1, 0x87 )
+CPU_BE( .quad 0x87, 1 )
AES_ENTRY(aes_xts_encrypt)
FRAME_PUSH
--
2.7.4
^ permalink raw reply related
* [PATCH v2 6/8] crypto: arm64/aes-neon - fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
The AES implementation using pure NEON instructions relies on the generic
AES key schedule generation routines, which store the round keys as arrays
of 32-bit quantities stored in memory using native endianness. This means
we should refer to these round keys using 4x4 loads rather than 16x1 loads.
In addition, the ShiftRows tables are loading using a single scalar load,
which is also affected by endianness, so emit these tables in the correct
order depending on whether we are building for big endian or not.
Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-neon.S | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-neon.S b/arch/arm64/crypto/aes-neon.S
index b93170e1cc93..85f07ead7c5c 100644
--- a/arch/arm64/crypto/aes-neon.S
+++ b/arch/arm64/crypto/aes-neon.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#define AES_ENTRY(func) ENTRY(neon_ ## func)
#define AES_ENDPROC(func) ENDPROC(neon_ ## func)
@@ -83,13 +84,13 @@
.endm
.macro do_block, enc, in, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in\().16b, \in\().16b, v15.16b /* ^round key */
tbl \in\().16b, {\in\().16b}, v13.16b /* ShiftRows */
sub_bytes \in
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -229,7 +230,7 @@
.endm
.macro do_block_2x, enc, in0, in1 rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -237,7 +238,7 @@
sub_bytes_2x \in0, \in1
tbl \in0\().16b, {\in0\().16b}, v13.16b /* ShiftRows */
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -254,7 +255,7 @@
.endm
.macro do_block_4x, enc, in0, in1, in2, in3, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -266,7 +267,7 @@
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
tbl \in2\().16b, {\in2\().16b}, v13.16b /* ShiftRows */
tbl \in3\().16b, {\in3\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -306,12 +307,16 @@
.text
.align 4
.LForward_ShiftRows:
- .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3
- .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb
+CPU_LE( .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3 )
+CPU_LE( .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb )
+CPU_BE( .byte 0xb, 0x6, 0x1, 0xc, 0x7, 0x2, 0xd, 0x8 )
+CPU_BE( .byte 0x3, 0xe, 0x9, 0x4, 0xf, 0xa, 0x5, 0x0 )
.LReverse_ShiftRows:
- .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb
- .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3
+CPU_LE( .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb )
+CPU_LE( .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3 )
+CPU_BE( .byte 0x3, 0x6, 0x9, 0xc, 0xf, 0x2, 0x5, 0x8 )
+CPU_BE( .byte 0xb, 0xe, 0x1, 0x4, 0x7, 0xa, 0xd, 0x0 )
.LForward_Sbox:
.byte 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/8] crypto: arm64/aes-ccm-ce: fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
refers to the AES round keys as pairs of 64-bit quantities, which causes
failures when building the code for big endian. In addition, it byte swaps
the input counter unconditionally, while this is only required for little
endian builds. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
index a2a7fbcacc14..3363560c79b7 100644
--- a/arch/arm64/crypto/aes-ce-ccm-core.S
+++ b/arch/arm64/crypto/aes-ce-ccm-core.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
.text
.arch armv8-a+crypto
@@ -19,7 +20,7 @@
*/
ENTRY(ce_aes_ccm_auth_data)
ldr w8, [x3] /* leftover from prev round? */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v0.16b}, [x0] /* load mac */
cbz w8, 1f
sub w8, w8, #16
eor v1.16b, v1.16b, v1.16b
@@ -31,7 +32,7 @@ ENTRY(ce_aes_ccm_auth_data)
beq 8f /* out of input? */
cbnz w8, 0b
eor v0.16b, v0.16b, v1.16b
-1: ld1 {v3.2d}, [x4] /* load first round key */
+1: ld1 {v3.16b}, [x4] /* load first round key */
prfm pldl1strm, [x1]
cmp w5, #12 /* which key size? */
add x6, x4, #16
@@ -41,17 +42,17 @@ ENTRY(ce_aes_ccm_auth_data)
mov v5.16b, v3.16b
b 4f
2: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x6], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x6], #16 /* load 2nd round key */
3: aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
-4: ld1 {v3.2d}, [x6], #16 /* load next round key */
+4: ld1 {v3.16b}, [x6], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
-5: ld1 {v4.2d}, [x6], #16 /* load next round key */
+5: ld1 {v4.16b}, [x6], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
- ld1 {v5.2d}, [x6], #16 /* load next round key */
+ ld1 {v5.16b}, [x6], #16 /* load next round key */
bpl 3b
aese v0.16b, v4.16b
subs w2, w2, #16 /* last data? */
@@ -60,7 +61,7 @@ ENTRY(ce_aes_ccm_auth_data)
ld1 {v1.16b}, [x1], #16 /* load next input block */
eor v0.16b, v0.16b, v1.16b /* xor with mac */
bne 1b
-6: st1 {v0.2d}, [x0] /* store mac */
+6: st1 {v0.16b}, [x0] /* store mac */
beq 10f
adds w2, w2, #16
beq 10f
@@ -79,7 +80,7 @@ ENTRY(ce_aes_ccm_auth_data)
adds w7, w7, #1
bne 9b
eor v0.16b, v0.16b, v1.16b
- st1 {v0.2d}, [x0]
+ st1 {v0.16b}, [x0]
10: str w8, [x3]
ret
ENDPROC(ce_aes_ccm_auth_data)
@@ -89,27 +90,27 @@ ENDPROC(ce_aes_ccm_auth_data)
* u32 rounds);
*/
ENTRY(ce_aes_ccm_final)
- ld1 {v3.2d}, [x2], #16 /* load first round key */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v3.16b}, [x2], #16 /* load first round key */
+ ld1 {v0.16b}, [x0] /* load mac */
cmp w3, #12 /* which key size? */
sub w3, w3, #2 /* modified # of rounds */
- ld1 {v1.2d}, [x1] /* load 1st ctriv */
+ ld1 {v1.16b}, [x1] /* load 1st ctriv */
bmi 0f
bne 3f
mov v5.16b, v3.16b
b 2f
0: mov v4.16b, v3.16b
-1: ld1 {v5.2d}, [x2], #16 /* load next round key */
+1: ld1 {v5.16b}, [x2], #16 /* load next round key */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-2: ld1 {v3.2d}, [x2], #16 /* load next round key */
+2: ld1 {v3.16b}, [x2], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-3: ld1 {v4.2d}, [x2], #16 /* load next round key */
+3: ld1 {v4.16b}, [x2], #16 /* load next round key */
subs w3, w3, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
@@ -120,47 +121,47 @@ ENTRY(ce_aes_ccm_final)
aese v1.16b, v4.16b
/* final round key cancels out */
eor v0.16b, v0.16b, v1.16b /* en-/decrypt the mac */
- st1 {v0.2d}, [x0] /* store result */
+ st1 {v0.16b}, [x0] /* store result */
ret
ENDPROC(ce_aes_ccm_final)
.macro aes_ccm_do_crypt,enc
ldr x8, [x6, #8] /* load lower ctr */
- ld1 {v0.2d}, [x5] /* load mac */
- rev x8, x8 /* keep swabbed ctr in reg */
+ ld1 {v0.16b}, [x5] /* load mac */
+CPU_LE( rev x8, x8 ) /* keep swabbed ctr in reg */
0: /* outer loop */
- ld1 {v1.1d}, [x6] /* load upper ctr */
+ ld1 {v1.8b}, [x6] /* load upper ctr */
prfm pldl1strm, [x1]
add x8, x8, #1
rev x9, x8
cmp w4, #12 /* which key size? */
sub w7, w4, #2 /* get modified # of rounds */
ins v1.d[1], x9 /* no carry in lower ctr */
- ld1 {v3.2d}, [x3] /* load first round key */
+ ld1 {v3.16b}, [x3] /* load first round key */
add x10, x3, #16
bmi 1f
bne 4f
mov v5.16b, v3.16b
b 3f
1: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x10], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x10], #16 /* load 2nd round key */
2: /* inner loop: 3 rounds, 2x interleaved */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-3: ld1 {v3.2d}, [x10], #16 /* load next round key */
+3: ld1 {v3.16b}, [x10], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-4: ld1 {v4.2d}, [x10], #16 /* load next round key */
+4: ld1 {v4.16b}, [x10], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
aese v1.16b, v3.16b
aesmc v1.16b, v1.16b
- ld1 {v5.2d}, [x10], #16 /* load next round key */
+ ld1 {v5.16b}, [x10], #16 /* load next round key */
bpl 2b
aese v0.16b, v4.16b
aese v1.16b, v4.16b
@@ -177,14 +178,14 @@ ENDPROC(ce_aes_ccm_final)
eor v0.16b, v0.16b, v2.16b /* xor mac with pt ^ rk[last] */
st1 {v1.16b}, [x0], #16 /* write output block */
bne 0b
- rev x8, x8
- st1 {v0.2d}, [x5] /* store mac */
+CPU_LE( rev x8, x8 )
+ st1 {v0.16b}, [x5] /* store mac */
str x8, [x6, #8] /* store lsb end of ctr (BE) */
5: ret
6: eor v0.16b, v0.16b, v5.16b /* final round mac */
eor v1.16b, v1.16b, v5.16b /* final round enc */
- st1 {v0.2d}, [x5] /* store mac */
+ st1 {v0.16b}, [x5] /* store mac */
add w2, w2, #16 /* process partial tail block */
7: ldrb w9, [x1], #1 /* get 1 byte of input */
umov w6, v1.b[0] /* get top crypted ctr byte */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/8] crypto: arm64/sha2-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA256 digest is an array of 8 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x32 vector
ones where appropriate.
Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha2-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index 5df9d9d470ad..01cfee066837 100644
--- a/arch/arm64/crypto/sha2-ce-core.S
+++ b/arch/arm64/crypto/sha2-ce-core.S
@@ -85,7 +85,7 @@ ENTRY(sha2_ce_transform)
ld1 {v12.4s-v15.4s}, [x8]
/* load state */
- ldp dga, dgb, [x0]
+ ld1 {dgav.4s, dgbv.4s}, [x0]
/* load sha256_ce_state::finalize */
ldr w4, [x0, #:lo12:sha256_ce_offsetof_finalize]
@@ -148,6 +148,6 @@ CPU_LE( rev32 v19.16b, v19.16b )
b 1b
/* store new state */
-3: stp dga, dgb, [x0]
+3: st1 {dgav.4s, dgbv.4s}, [x0]
ret
ENDPROC(sha2_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/8] crypto: arm64/sha1-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA1 digest is an array of 5 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x4 vector
ones where appropriate.
Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha1-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
index 033aae6d732a..c98e7e849f06 100644
--- a/arch/arm64/crypto/sha1-ce-core.S
+++ b/arch/arm64/crypto/sha1-ce-core.S
@@ -78,7 +78,7 @@ ENTRY(sha1_ce_transform)
ld1r {k3.4s}, [x6]
/* load state */
- ldr dga, [x0]
+ ld1 {dgav.4s}, [x0]
ldr dgb, [x0, #16]
/* load sha1_ce_state::finalize */
@@ -144,7 +144,7 @@ CPU_LE( rev32 v11.16b, v11.16b )
b 1b
/* store new state */
-3: str dga, [x0]
+3: st1 {dgav.4s}, [x0]
str dgb, [x0, #16]
ret
ENDPROC(sha1_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/8] crypto: arm64/ghash-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
The GHASH key and digest are both pairs of 64-bit quantities, but the
GHASH code does not always refer to them as such, causing failures when
built for big endian. So replace the 16x1 loads and stores with 2x8 ones.
Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/ghash-ce-core.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index dc457015884e..f0bb9f0b524f 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -29,8 +29,8 @@
* struct ghash_key const *k, const char *head)
*/
ENTRY(pmull_ghash_update)
- ld1 {SHASH.16b}, [x3]
- ld1 {XL.16b}, [x1]
+ ld1 {SHASH.2d}, [x3]
+ ld1 {XL.2d}, [x1]
movi MASK.16b, #0xe1
ext SHASH2.16b, SHASH.16b, SHASH.16b, #8
shl MASK.2d, MASK.2d, #57
@@ -74,6 +74,6 @@ CPU_LE( rev64 T1.16b, T1.16b )
cbnz w0, 0b
- st1 {XL.16b}, [x1]
+ st1 {XL.2d}, [x1]
ret
ENDPROC(pmull_ghash_update)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/8] crypto: arm64/aes-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476209720-21114-1-git-send-email-ard.biesheuvel@linaro.org>
The core AES cipher implementation that uses ARMv8 Crypto Extensions
instructions erroneously loads the round keys as 64-bit quantities,
which causes the algorithm to fail when built for big endian. In
addition, the key schedule generation routine fails to take endianness
into account as well, when loading the combining the input key with
the round constants. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-cipher.c | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-cipher.c b/arch/arm64/crypto/aes-ce-cipher.c
index f7bd9bf0bbb3..50d9fe11d0c8 100644
--- a/arch/arm64/crypto/aes-ce-cipher.c
+++ b/arch/arm64/crypto/aes-ce-cipher.c
@@ -47,24 +47,24 @@ static void aes_cipher_encrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aese v0.16b, v2.16b ;"
" aesmc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aese v0.16b, v3.16b ;"
" aesmc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aese v0.16b, v1.16b ;"
" aesmc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aese v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -92,24 +92,24 @@ static void aes_cipher_decrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aesd v0.16b, v2.16b ;"
" aesimc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aesd v0.16b, v3.16b ;"
" aesimc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aesd v0.16b, v1.16b ;"
" aesimc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aesd v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -173,7 +173,12 @@ int ce_aes_expandkey(struct crypto_aes_ctx *ctx, const u8 *in_key,
u32 *rki = ctx->key_enc + (i * kwords);
u32 *rko = rki + kwords;
+#ifndef CONFIG_CPU_BIG_ENDIAN
rko[0] = ror32(aes_sub(rki[kwords - 1]), 8) ^ rcon[i] ^ rki[0];
+#else
+ rko[0] = rol32(aes_sub(rki[kwords - 1]), 8) ^ (rcon[i] << 24) ^
+ rki[0];
+#endif
rko[1] = rko[0] ^ rki[1];
rko[2] = rko[1] ^ rki[2];
rko[3] = rko[2] ^ rki[3];
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-11 18:15 UTC (permalink / raw)
To: linux-arm-kernel
As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
currently work, or have ever worked correctly when built for big endian. So this
series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
well, and an additional fix for XTS which escaped my attention before.
Each of these patches carries a fixes tag, and could be backported to stable.
However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
fix is compatible with, not the patch that introduced the algorithm. This is due
to the fact that the key schedules are incompatible between generic AES and the
arm64 Crypto Extensions implementation (but only when building for big endian)
This is not a problem in practice, but it does mean that the AES-CCM and AES in
EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
one that is compatible with the generic AES key schedule generation code (which
it currently no longer uses)
In any case, please apply with cc to stable.
Ard Biesheuvel (8):
crypto: arm64/aes-ce - fix for big endian
crypto: arm64/ghash-ce - fix for big endian
crypto: arm64/sha1-ce - fix for big endian
crypto: arm64/sha2-ce - fix for big endian
crypto: arm64/aes-ccm-ce: fix for big endian
crypto: arm64/aes-neon - fix for big endian
crypto: arm64/aes-xts-ce: fix for big endian
crypto: arm/aes-ce - fix for big endian
arch/arm/crypto/aes-ce-glue.c | 5 ++
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
arch/arm64/crypto/aes-ce.S | 1 +
arch/arm64/crypto/aes-modes.S | 3 +-
arch/arm64/crypto/aes-neon.S | 25 +++++----
arch/arm64/crypto/ghash-ce-core.S | 6 +--
arch/arm64/crypto/sha1-ce-core.S | 4 +-
arch/arm64/crypto/sha2-ce-core.S | 4 +-
9 files changed, 72 insertions(+), 54 deletions(-)
--
2.7.4
^ permalink raw reply
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