* [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
* The possible regression in kernel 4.8 - clk: imx: correct AV PLL rate formula
From: Fabio Estevam @ 2016-10-11 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <WM!8ae38b052eee9a42a4712d13aee34e2d793055d4125e98cc2c03451811f33168b3556d3bf52ee5ba8dda879cea808cdc!@dg.advantech.com>
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.
^ permalink raw reply
* [PATCH] ARM: imx: gpc: Initialize all power domains
From: Fabio Estevam @ 2016-10-11 17:53 UTC (permalink / raw)
To: linux-arm-kernel
When booting a kernel built with multi_v7_defconfig the following
probe error is seen:
imx-gpc: probe of 20dc000.gpc failed with error -22
Later on the kernel crashes like this:
[ 1.723358] Unable to handle kernel NULL pointer dereference at virtual address 00000040
[ 1.731500] pgd = c0204000
[ 1.731863] hctosys: unable to open rtc device (rtc0)
[ 1.739301] [00000040] *pgd=00000000
[ 1.739310] Internal error: Oops: 5 [#1] SMP ARM
[ 1.739319] Modules linked in:
[ 1.739328] CPU: 1 PID: 95 Comm: kworker/1:4 Not tainted 4.8.0-11897-g6b5e09a #1
[ 1.739331] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 1.739352] Workqueue: pm genpd_power_off_work_fn
[ 1.739356] task: ee63d400 task.stack: ee70a000
[ 1.739365] PC is at mutex_lock+0xc/0x4c
[ 1.739374] LR is at regulator_disable+0x2c/0x60
[ 1.739379] pc : [<c0bc0da0>] lr : [<c06e4b10>] psr: 60000013
[ 1.739379] sp : ee70beb0 ip : 10624dd3 fp : ee6e6280
[ 1.739382] r10: eefb0900 r9 : 00000000 r8 : c1309918
[ 1.739385] r7 : 00000000 r6 : 00000040 r5 : 00000000 r4 : 00000040
[ 1.739390] r3 : 0000004c r2 : 7fffd540 r1 : 000001e4 r0 : 00000040
The gpc probe fails because of_genpd_add_provider_onecell() checks
if all the domains are initialized via pm_genpd_present() function
and it returns an error on the multi_v7_defconfig case.
In order to fix this error, initialize all the imx_gpc_domains, not
only the imx6q_pu_domain.base one.
Reported-by: Olof's autobooter <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/mach-imx/gpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 0df062d..d0463e9 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -430,7 +430,8 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
return 0;
- pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
+ for (i = 0; i < ARRAY_SIZE(imx_gpc_domains); i++)
+ pm_genpd_init(imx_gpc_domains[i], NULL, false);
return of_genpd_add_provider_onecell(dev->of_node,
&imx_gpc_onecell_data);
--
2.7.4
^ permalink raw reply related
* The possible regression in kernel 4.8 - clk: imx: correct AV PLL rate formula
From: Ken.Lin @ 2016-10-11 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <WM!8b5ef465717800ac4466674b98bb32450dc231d955cd4979ca96fd54828a7c3af7de5f376015ebf046c75f20677161c6!@dgg.advantech.com>
Hi Fabio,
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Thursday, October 6, 2016 4:38 PM
> To: Ken.Lin
> Cc: shawnguo at kernel.org; kernel at pengutronix.de; sboyd at codeaurora.org;
> mturquette at baylibre.com; linux-arm-kernel at lists.infradead.org; linux-
> clk at vger.kernel.org; linux-kernel at vger.kernel.org; Peter.Stretz; Peter.Chiang;
> Akshay Bhat; Jason Moss; emil at limesaudio.com
> Subject: Re: The possible regression in kernel 4.8 - clk: imx: correct AV PLL rate
> formula
>
> Hi Ken,
>
> On Thu, Oct 6, 2016 at 8:26 PM, Ken.Lin <ken.lin@advantech.com> wrote:
> > Hi,
> >
> > We found a possible regression issue (not seen in kernel 4.7-stable), which has
> to do with the new NXP commit ba7f4f557eb67ee21c979c8539dc1886f5d5341c
> when we did a DP test (1920x1080 at 60) with clock source PLL5.
> > The DP desired pixel clock (148.5MHz that is calculated from the input of PLL
> output frequency) would be correct again when we reverted this commit.
> > Could you please help check if the commit has the side effect since it would
> have impacts on our on-going project when it requires moving from kernel 4.7
> to kernel 4.8 or newer version?
> >
> > Please check the following URL for the details
> > https://www.dropbox.com/s/7wc5jdp8unlsiob/possible_regression_for_clk_
> > imx_correct_VL_PLL_rate_formula.pdf?dl=0
>
> Do these patches from Emil fix the issue?
>
> http://www.spinics.net/lists/arm-kernel/msg535204.html
>
> and
>
> http://www.spinics.net/lists/arm-kernel/msg535203.html
>
> Thanks
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.
Ref: /sys/kernel/debug/clk/clk_summary
pll5 1 1 1039500000 0 0
pll5_bypass 1 1 1039500000 0 0
pll5_video 1 1 1039500000 0 0
pll5_post_div 1 1 519750000 0 0
pll5_video_div 2 2 519750000 0 0
ipu2_di1_pre_sel 0 0 519750000 0 0
ipu2_di1_pre 0 0 173250000 0 0
ipu2_di1_sel 0 0 173250000 0 0
ipu2_di1 0 0 173250000 0 0
ipu2_di0_pre_sel 0 0 519750000 0 0
ipu2_di0_pre 0 0 173250000 0 0
ldb_di1_sel 1 1 519750000 0 0
ldb_di1_div_3_5 1 1 148500000 0 0
ldb_di1_podf 1 1 148500000 0 0
ldb_di1 2 2 148500000 0 0
ipu2_di0_sel 1 1 148500000 0 0
ipu2_di0 1 1 148500000 0 0
ldb_di0_sel 1 1 519750000 0 0
ldb_di0_div_3_5 1 1 148500000 0 0
ldb_di0_podf 1 1 148500000 0 0
ldb_di0 1 1 148500000 0 0
Ref: kernel debug messages
[ 113.848959] imx-ipuv3-crtc imx-ipuv3-crtc.6: ipu_crtc_mode_set_nofb: mode->hdisplay: 1920
[ 113.857201] imx-ipuv3-crtc imx-ipuv3-crtc.6: ipu_crtc_mode_set_nofb: mode->vdisplay: 1080
[ 113.865421] imx-ipuv3-crtc imx-ipuv3-crtc.6: ipu_crtc_mode_set_nofb: attached to encoder types 0x8
[ 113.874483] imx-ipuv3 2800000.ipu: disp 0: panel size = 1920 x 1080
[ 113.880803] imx-ipuv3 2800000.ipu: Clocks: IPU 264000000Hz DI 75833334Hz Needed 148500000Hz
[ 113.889252] imx-ipuv3 2800000.ipu: Want 148500000Hz IPU 264000000Hz DI 75833334Hz using DI, 75833334Hz
[ 113.898768] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock: now: 227500000 want: 519750000
[ 113.908018] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock after: 519750000
[ 113.915886] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock: now: 148500000 want: 148500000
[ 113.925050] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock after: 148500000
[ 113.932928] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock: now: 519750000 want: 519750000
[ 113.942096] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock after: 519750000
[ 113.949938] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock: now: 148500000 want: 148500000
[ 113.959104] imx-ldb 2000000.aips-bus:ldb at 020e0008: imx_ldb_set_clock after: 148500000
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
Thank you
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* [PATCH 3/5] Input: add driver for Ilitek ili2139 touch IC
From: Dmitry Torokhov @ 2016-10-11 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011003359.26079-3-icenowy@aosc.xyz>
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.
> ---
> 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 V3 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
From: Suzuki K Poulose @ 2016-10-11 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475875882-2604-3-git-send-email-tbaicar@codeaurora.org>
On 07/10/16 22:31, Tyler Baicar wrote:
> Currently when a RAS error is reported it is not timestamped.
> The ACPI 6.1 spec adds the timestamp field to the generic error
> data entry v3 structure. The timestamp of when the firmware
> generated the error is now being reported.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> Signed-off-by: Richard Ruigrok <rruigrok@codeaurora.org>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
Please could you keep the people who reviewed/commented on your series in the past,
whenever you post a new version ?
> ---
> drivers/acpi/apei/ghes.c | 25 ++++++++++--
> drivers/firmware/efi/cper.c | 97 +++++++++++++++++++++++++++++++++++++++------
> 2 files changed, 105 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 3021f0e..c8488f1 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -80,6 +80,10 @@
> ((struct acpi_hest_generic_status *) \
> ((struct ghes_estatus_node *)(estatus_node) + 1))
>
> +#define acpi_hest_generic_data_version(gdata) \
> + (gdata->revision >> 8)
...
> +inline void *acpi_hest_generic_data_payload(struct acpi_hest_generic_data *gdata)
> +{
> + return acpi_hest_generic_data_version(gdata) >= 3 ?
> + (void *)(((struct acpi_hest_generic_data_v300 *)(gdata)) + 1) :
> + gdata + 1;
> +}
> +
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index d425374..9fa1317 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> +#define acpi_hest_generic_data_version(gdata) \
> + (gdata->revision >> 8)
> +
...
> +static inline void *acpi_hest_generic_data_payload(struct acpi_hest_generic_data *gdata)
> +{
> + return acpi_hest_generic_data_version(gdata) >= 3 ?
> + (void *)(((struct acpi_hest_generic_data_v300 *)(gdata)) + 1) :
> + gdata + 1;
> +}
Could these go to a header file, so that we don't need duplicate definitions of these helpers in
different files ?
> +
> +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);
> + printk("%stime: ", pfx);
> + printk("%7s", 0x01 & *(timestamp + 3) ? "precise" : "");
What format is the (timestamp + 3) stored in ? Does it need conversion ?
> + printk(" %02d:%02d:%02d %02d%02d-%02d-%02d\n",
> + bcd2bin(hour), bcd2bin(min), bcd2bin(sec),
> + bcd2bin(century), bcd2bin(year), bcd2bin(mon),
> + bcd2bin(day));
> + }
minor nit: Would it be easier to order/parse the error messages if the date
is printed first followed by time ?
i.e,
17:20:14 2016-09-15 Mon
vs
2016-09-15 Mon 17:20:14
e.g, people looking at a huge log, looking for logs from a specific date might
find the latter more useful to skip the messages.
> +}
> +
> 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)
Could we use the helper defined above ?
> @@ -451,12 +497,22 @@ void cper_estatus_print(const char *pfx,
> printk("%s""event severity: %s\n", pfx, cper_severity_str(severity));
> data_len = estatus->data_length;
> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
> + if ((gdata->revision >> 8) >= 0x03)
Same as above, use the macro ?
> + gdata_v3 = (struct acpi_hest_generic_data_v300 *)gdata;
> +
> snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
> +
> while (data_len >= sizeof(*gdata)) {
> gedata_len = gdata->error_data_length;
> cper_estatus_print_section(newpfx, gdata, sec_no);
> - data_len -= gedata_len + sizeof(*gdata);
> - gdata = (void *)(gdata + 1) + gedata_len;
> + if(gdata_v3) {
> + data_len -= gedata_len + sizeof(*gdata_v3);
> + gdata_v3 = (void *)(gdata_v3 + 1) + gedata_len;
> + gdata = (struct acpi_hest_generic_data *)gdata_v3;
> + } else {
> + data_len -= gedata_len + sizeof(*gdata);
> + gdata = (void *)(gdata + 1) + gedata_len;
> + }
> sec_no++;
> }
...
>
> @@ -486,15 +543,29 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
> return rc;
> data_len = estatus->data_length;
> gdata = (struct acpi_hest_generic_data *)(estatus + 1);
> - while (data_len >= sizeof(*gdata)) {
> - gedata_len = gdata->error_data_length;
> - if (gedata_len > data_len - sizeof(*gdata))
> +
> + if ((gdata->revision >> 8) >= 0x03) {
> + gdata_v3 = (struct acpi_hest_generic_data_v300 *)gdata;
> + while (data_len >= sizeof(*gdata_v3)) {
> + gedata_len = gdata_v3->error_data_length;
> + if (gedata_len > data_len - sizeof(*gdata_v3))
> + return -EINVAL;
> + data_len -= gedata_len + sizeof(*gdata_v3);
> + gdata_v3 = (void *)(gdata_v3 + 1) + gedata_len;
> + }
> + if (data_len)
> + return -EINVAL;
> + } else {
> + while (data_len >= sizeof(*gdata)) {
> + gedata_len = gdata->error_data_length;
> + if (gedata_len > data_len - sizeof(*gdata))
> + return -EINVAL;
> + data_len -= gedata_len + sizeof(*gdata);
> + gdata = (void *)(gdata + 1) + gedata_len;
> + }
> + if (data_len)
As mentioned in the previous version, would it make sense to add some more
helpers to deal with record versions ? We seem to be doing the version switch and
code duplication at different places.
Does the following help ? Thoughts ?
#define acpi_hest_generic_data_error_length(gdata) (((struct acpi_hest_generic_data *)(gdata))->error_data_length)
#define acpi_hest_generic_data_size(gdata) \
((acpi_hest_generic_data_version(gdata) >= 3) ? \
sizeof(struct acpi_hest_generic_data_v300) : \
sizeof(struct acpi_hest_generic_data))
#define acpi_hest_generic_data_record_size(gdata)
(acpi_hest_generic_data_size(gdata) + \
acpi_hest_generic_data_error_length(gdata))
#define acpi_hest_generic_data_next(gdata) \
((void *)(gdata) + acpi_hest_generic_data_record_size(gdata))
Suzuki
^ 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