* 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
* [PATCH] arm64: mmu: set the contiguous for kernel mappings when appropriate
From: Ard Biesheuvel @ 2016-10-11 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011162914.GF9532@arm.com>
On 11 October 2016 at 17:29, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Oct 11, 2016 at 01:56:26PM +0100, Ard Biesheuvel wrote:
>> On 11 October 2016 at 13:41, Will Deacon <will.deacon@arm.com> wrote:
>> > On Tue, Oct 11, 2016 at 12:17:54PM +0100, Ard Biesheuvel wrote:
>> >> On 11 October 2016 at 10:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >> > On 11 October 2016 at 09:48, Steve Capper <steve.capper@linaro.org> wrote:
>> >> >> So in arch/arm64/include/asm/pgtable-hwdef.h, we have:
>> >> >> CONT_PTE_SHIFT
>> >> >> CONT_PMD_SHIFT
>> >> >> CONT_PTES
>> >> >> CONT_PMDS
>> >> >> CONT_PTE_SIZE
>> >> >> CONT_PTE_MASK
>> >> >> ...
>> >> >>
>> >> >> which are used by the contiguous hint HugeTLB code.
>> >> >> Can those be adopted instead of CONT_MASK and CONT_SIZE?
>> >> >>
>> >>
>> >> Looking at the hugetlb code, it appears to support contiguous PMDs for
>> >> 4k and 64k pages as well, while the ARM ARM only defines it for 16k
>> >> pages. I suppose the contiguous bit is simply ignored for level 2
>> >> entries when using 4k or 64k pages kernels, but I think it would be
>> >> better for the code to reflect this as well.
>> >
>> > Which bit in the ARM ARM says that you can't support contiguous PMDs for 4k
>> > and 64k pages? I see that the number of contiguous entries changes between
>> > levels for 16k pages, but that's it.
>> >
>>
>> You are right, the ARM ARM does not say that at all. But given Mark's comment:
>>
>> """
>> With 16K pages, we can have contiguous PMD entries. Should we handle those,
>> too? e.g. have separate {PMD,PTE}_CONT{,_SIZE}?
>> """
>>
>> it seems I am not the only one who is confused about this. In any
>> case, the fact that the ARM ARM documents levels 2 and 3 explicitly
>> for 16k pages does very little to clarify at which levels this bit is
>> defined, and if it is defined at levels < 2, what the granularity is
>> for 16k pages.
>
> I see you're going to work on a more comprehensive v3 (thanks!), but just
> to help clarify this: the contiguous bit is valid whenever a block or page
> (i.e. a leaf) entry is valid. The only complication with 16k pages is that
> the number of contiguous entries changes between level 2 and level 3,
> which makes sense if you think about the TLB entries supported due to
> non-contiguous block mappings in other regimes anyway (and brings into
> question whether people bother with 16G in practice).
>
> That means you can use the contiguous bit as:
>
> 4k: levels 1,2,3 (16G, 32M, 64K)
> 16k: levels 2,3 (1G, 2M)
> 64k: levels 2,3 (16G, 2M)
>
> Hopefully my maths is correct and that clears things up,
>
Yes, that resembles my own calculations. Another complication is that
folded PUDs and PMDs need to be dealt with at the PGD level, but I
think I have worked it out now.
Re 16 GB: are you saying don't bother? Because supporting this would
require ARM64_MEMSTART_SHIFT to be increased to (CONT_PUD_SHIFT +
PUD_SHIFT) or (CONT_PMD_SHIFT + PMD_SHIFT) [for 4k and 16k/64k,
respectively] in order to guarantee that the physical and virtual
addresses are always equal modulo 16 GB (for granules that support
it). It's a nice idea that the linear mapping can be covered by fewer
TLB entries if you have huge amounts of RAM, but if the hardware is
unlikely to honour it, it may not be worth the trouble.
^ permalink raw reply
* [PATCH 4/5] rpmsg: Driver for user space endpoint interface
From: Bjorn Andersson @ 2016-10-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1005047c-ef7c-ccd8-848c-4974f893c820@st.com>
On Tue 11 Oct 00:46 PDT 2016, loic pallardy wrote:
> On 10/08/2016 06:23 AM, Bjorn Andersson wrote:
[..]
> >diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
> >index ae9c9132cf76..5daf1209b77d 100644
> >--- a/drivers/rpmsg/Makefile
> >+++ b/drivers/rpmsg/Makefile
> >@@ -1,3 +1,3 @@
> >-obj-$(CONFIG_RPMSG) += rpmsg_core.o
> >+obj-$(CONFIG_RPMSG) += rpmsg_core.o rpmsg_char.o
> Hi Bjorn,
>
> Could you please create a dedicated Kconfig entry for this new interface?
> This should be an option like i2C_dev.
>
No problem, I'll do that.
Regards,
Bjorn
^ permalink raw reply
* [PATCH] arm64: mmu: set the contiguous for kernel mappings when appropriate
From: Will Deacon @ 2016-10-11 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_AX80Uts8gtn+PD9F0DWDMU2tEw6PEZg1p6G+ajXS_eg@mail.gmail.com>
On Tue, Oct 11, 2016 at 01:56:26PM +0100, Ard Biesheuvel wrote:
> On 11 October 2016 at 13:41, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Oct 11, 2016 at 12:17:54PM +0100, Ard Biesheuvel wrote:
> >> On 11 October 2016 at 10:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >> > On 11 October 2016 at 09:48, Steve Capper <steve.capper@linaro.org> wrote:
> >> >> So in arch/arm64/include/asm/pgtable-hwdef.h, we have:
> >> >> CONT_PTE_SHIFT
> >> >> CONT_PMD_SHIFT
> >> >> CONT_PTES
> >> >> CONT_PMDS
> >> >> CONT_PTE_SIZE
> >> >> CONT_PTE_MASK
> >> >> ...
> >> >>
> >> >> which are used by the contiguous hint HugeTLB code.
> >> >> Can those be adopted instead of CONT_MASK and CONT_SIZE?
> >> >>
> >>
> >> Looking at the hugetlb code, it appears to support contiguous PMDs for
> >> 4k and 64k pages as well, while the ARM ARM only defines it for 16k
> >> pages. I suppose the contiguous bit is simply ignored for level 2
> >> entries when using 4k or 64k pages kernels, but I think it would be
> >> better for the code to reflect this as well.
> >
> > Which bit in the ARM ARM says that you can't support contiguous PMDs for 4k
> > and 64k pages? I see that the number of contiguous entries changes between
> > levels for 16k pages, but that's it.
> >
>
> You are right, the ARM ARM does not say that at all. But given Mark's comment:
>
> """
> With 16K pages, we can have contiguous PMD entries. Should we handle those,
> too? e.g. have separate {PMD,PTE}_CONT{,_SIZE}?
> """
>
> it seems I am not the only one who is confused about this. In any
> case, the fact that the ARM ARM documents levels 2 and 3 explicitly
> for 16k pages does very little to clarify at which levels this bit is
> defined, and if it is defined at levels < 2, what the granularity is
> for 16k pages.
I see you're going to work on a more comprehensive v3 (thanks!), but just
to help clarify this: the contiguous bit is valid whenever a block or page
(i.e. a leaf) entry is valid. The only complication with 16k pages is that
the number of contiguous entries changes between level 2 and level 3,
which makes sense if you think about the TLB entries supported due to
non-contiguous block mappings in other regimes anyway (and brings into
question whether people bother with 16G in practice).
That means you can use the contiguous bit as:
4k: levels 1,2,3 (16G, 32M, 64K)
16k: levels 2,3 (1G, 2M)
64k: levels 2,3 (16G, 2M)
Hopefully my maths is correct and that clears things up,
Will
^ permalink raw reply
* [PATCH v6 2/2] i2c: qup: support SMBus block read
From: Austin Christ @ 2016-10-11 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476203277-6893-1-git-send-email-austinwc@codeaurora.org>
From: Naveen Kaje <nkaje@codeaurora.org>
I2C QUP driver relies on SMBus emulation support from the framework.
To handle SMBus block reads, the driver should check I2C_M_RECV_LEN
flag and should read the first byte received as the message length.
The driver configures the QUP hardware to read one byte. Once the
message length is known from this byte, the QUP hardware is configured
to read the rest.
Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
Signed-off-by: Austin Christ <austinwc@codeaurora.org>
Reviewed-by: Sricharan R <sricharan@codeaurora.org>
---
drivers/i2c/busses/i2c-qup.c | 64 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index bf0957e..d34120a 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -517,6 +517,33 @@ static int qup_i2c_get_data_len(struct qup_i2c_dev *qup)
return data_len;
}
+static bool qup_i2c_check_msg_len(struct i2c_msg *msg)
+{
+ return ((msg->flags & I2C_M_RD) && (msg->flags & I2C_M_RECV_LEN));
+}
+
+static int qup_i2c_set_tags_smb(u16 addr, u8 *tags, struct qup_i2c_dev *qup,
+ struct i2c_msg *msg)
+{
+ int len = 0;
+
+ if (msg->len > 1) {
+ tags[len++] = QUP_TAG_V2_DATARD_STOP;
+ tags[len++] = qup_i2c_get_data_len(qup) - 1;
+ } else {
+ tags[len++] = QUP_TAG_V2_START;
+ tags[len++] = addr & 0xff;
+
+ if (msg->flags & I2C_M_TEN)
+ tags[len++] = addr >> 8;
+
+ tags[len++] = QUP_TAG_V2_DATARD;
+ /* Read 1 byte indicating the length of the SMBus message */
+ tags[len++] = 1;
+ }
+ return len;
+}
+
static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
struct i2c_msg *msg, int is_dma)
{
@@ -526,6 +553,10 @@ static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
int last = (qup->blk.pos == (qup->blk.count - 1)) && (qup->is_last);
+ /* Handle tags for SMBus block read */
+ if (qup_i2c_check_msg_len(msg))
+ return qup_i2c_set_tags_smb(addr, tags, qup, msg);
+
if (qup->blk.pos == 0) {
tags[len++] = QUP_TAG_V2_START;
tags[len++] = addr & 0xff;
@@ -1065,9 +1096,17 @@ static int qup_i2c_read_fifo_v2(struct qup_i2c_dev *qup,
struct i2c_msg *msg)
{
u32 val;
- int idx, pos = 0, ret = 0, total;
+ int idx, pos = 0, ret = 0, total, msg_offset = 0;
+ /*
+ * If the message length is already read in
+ * the first byte of the buffer, account for
+ * that by setting the offset
+ */
+ if (qup_i2c_check_msg_len(msg) && (msg->len > 1))
+ msg_offset = 1;
total = qup_i2c_get_data_len(qup);
+ total -= msg_offset;
/* 2 extra bytes for read tags */
while (pos < (total + 2)) {
@@ -1087,8 +1126,8 @@ static int qup_i2c_read_fifo_v2(struct qup_i2c_dev *qup,
if (pos >= (total + 2))
goto out;
-
- msg->buf[qup->pos++] = val & 0xff;
+ msg->buf[qup->pos + msg_offset] = val & 0xff;
+ qup->pos++;
}
}
@@ -1128,6 +1167,20 @@ static int qup_i2c_read_one_v2(struct qup_i2c_dev *qup, struct i2c_msg *msg)
goto err;
qup->blk.pos++;
+
+ /* Handle SMBus block read length */
+ if (qup_i2c_check_msg_len(msg) && (msg->len == 1)) {
+ if (msg->buf[0] > I2C_SMBUS_BLOCK_MAX) {
+ ret = -EPROTO;
+ goto err;
+ }
+ msg->len += msg->buf[0];
+ qup->pos = 0;
+ qup_i2c_set_blk_data(qup, msg);
+ /* set tag length for block read */
+ qup->blk.tx_tag_len = 2;
+ qup_i2c_set_read_mode_v2(qup, msg->buf[0]);
+ }
} while (qup->blk.pos < qup->blk.count);
err:
@@ -1210,6 +1263,11 @@ static int qup_i2c_xfer(struct i2c_adapter *adap,
goto out;
}
+ if (qup_i2c_check_msg_len(&msgs[idx])) {
+ ret = -EINVAL;
+ goto out;
+ }
+
if (msgs[idx].flags & I2C_M_RD)
ret = qup_i2c_read_one(qup, &msgs[idx]);
else
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v6 1/2] i2c: qup: add ACPI support
From: Austin Christ @ 2016-10-11 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476203277-6893-1-git-send-email-austinwc@codeaurora.org>
From: Naveen Kaje <nkaje@codeaurora.org>
Add support to get the device parameters from ACPI. Assume
that the clocks are managed by firmware.
Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
Signed-off-by: Austin Christ <austinwc@codeaurora.org>
Reviewed-by: Sricharan R <sricharan@codeaurora.org>
---
drivers/i2c/busses/i2c-qup.c | 58 ++++++++++++++++++++++++++++++++------------
1 file changed, 42 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 041050e..bf0957e 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -14,6 +14,7 @@
*
*/
+#include <linux/acpi.h>
#include <linux/atomic.h>
#include <linux/clk.h>
#include <linux/delay.h>
@@ -132,6 +133,10 @@
/* Max timeout in ms for 32k bytes */
#define TOUT_MAX 300
+/* Default values. Use these if FW query fails */
+#define DEFAULT_CLK_FREQ 100000
+#define DEFAULT_SRC_CLK 20000000
+
struct qup_i2c_block {
int count;
int pos;
@@ -1356,14 +1361,13 @@ static void qup_i2c_disable_clocks(struct qup_i2c_dev *qup)
static int qup_i2c_probe(struct platform_device *pdev)
{
static const int blk_sizes[] = {4, 16, 32};
- struct device_node *node = pdev->dev.of_node;
struct qup_i2c_dev *qup;
unsigned long one_bit_t;
struct resource *res;
u32 io_mode, hw_ver, size;
int ret, fs_div, hs_div;
- int src_clk_freq;
- u32 clk_freq = 100000;
+ u32 src_clk_freq = DEFAULT_SRC_CLK;
+ u32 clk_freq = DEFAULT_CLK_FREQ;
int blocks;
qup = devm_kzalloc(&pdev->dev, sizeof(*qup), GFP_KERNEL);
@@ -1374,7 +1378,11 @@ static int qup_i2c_probe(struct platform_device *pdev)
init_completion(&qup->xfer);
platform_set_drvdata(pdev, qup);
- of_property_read_u32(node, "clock-frequency", &clk_freq);
+ ret = device_property_read_u32(qup->dev, "clock-frequency", &clk_freq);
+ if (ret) {
+ dev_notice(qup->dev, "using default clock-frequency %d",
+ DEFAULT_CLK_FREQ);
+ }
if (of_device_is_compatible(pdev->dev.of_node, "qcom,i2c-qup-v1.1.1")) {
qup->adap.algo = &qup_i2c_algo;
@@ -1456,20 +1464,30 @@ nodma:
return qup->irq;
}
- qup->clk = devm_clk_get(qup->dev, "core");
- if (IS_ERR(qup->clk)) {
- dev_err(qup->dev, "Could not get core clock\n");
- return PTR_ERR(qup->clk);
- }
+ if (has_acpi_companion(qup->dev)) {
+ ret = device_property_read_u32(qup->dev,
+ "src-clock-hz", &src_clk_freq);
+ if (ret) {
+ dev_notice(qup->dev, "using default src-clock-hz %d",
+ DEFAULT_SRC_CLK);
+ }
+ ACPI_COMPANION_SET(&qup->adap.dev, ACPI_COMPANION(qup->dev));
+ } else {
+ qup->clk = devm_clk_get(qup->dev, "core");
+ if (IS_ERR(qup->clk)) {
+ dev_err(qup->dev, "Could not get core clock\n");
+ return PTR_ERR(qup->clk);
+ }
- qup->pclk = devm_clk_get(qup->dev, "iface");
- if (IS_ERR(qup->pclk)) {
- dev_err(qup->dev, "Could not get iface clock\n");
- return PTR_ERR(qup->pclk);
+ qup->pclk = devm_clk_get(qup->dev, "iface");
+ if (IS_ERR(qup->pclk)) {
+ dev_err(qup->dev, "Could not get iface clock\n");
+ return PTR_ERR(qup->pclk);
+ }
+ qup_i2c_enable_clocks(qup);
+ src_clk_freq = clk_get_rate(qup->clk);
}
- qup_i2c_enable_clocks(qup);
-
/*
* Bootloaders might leave a pending interrupt on certain QUP's,
* so we reset the core before registering for interrupts.
@@ -1516,7 +1534,6 @@ nodma:
size = QUP_INPUT_FIFO_SIZE(io_mode);
qup->in_fifo_sz = qup->in_blk_sz * (2 << size);
- src_clk_freq = clk_get_rate(qup->clk);
fs_div = ((src_clk_freq / clk_freq) / 2) - 3;
hs_div = 3;
qup->clk_ctl = (hs_div << 8) | (fs_div & 0xff);
@@ -1641,6 +1658,14 @@ static const struct of_device_id qup_i2c_dt_match[] = {
};
MODULE_DEVICE_TABLE(of, qup_i2c_dt_match);
+#if IS_ENABLED(CONFIG_ACPI)
+static const struct acpi_device_id qup_i2c_acpi_match[] = {
+ { "QCOM8010"},
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, qup_i2c_acpi_match);
+#endif
+
static struct platform_driver qup_i2c_driver = {
.probe = qup_i2c_probe,
.remove = qup_i2c_remove,
@@ -1648,6 +1673,7 @@ static struct platform_driver qup_i2c_driver = {
.name = "i2c_qup",
.pm = &qup_i2c_qup_pm_ops,
.of_match_table = qup_i2c_dt_match,
+ .acpi_match_table = ACPI_PTR(qup_i2c_acpi_match),
},
};
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox