* [PATCH v2 5/8] iio: stm32-adc: pass iio device as arg for the interrupt handler
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
This changes the argument for the interrupt handler to be the IIO device
instead of the state-struct.
Since there will be some changes to how iio_priv_to_dev() is implemented,
it could be that the helper becomes a bit slower, as it will be hidden away
in the IIO core.
The iio_priv() call will still be fast enough, as it will return a void
pointer from the public IIO device structure. So it's better to switch the
order.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/stm32-adc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
index 80c3f963527b..34885387fbdb 100644
--- a/drivers/iio/adc/stm32-adc.c
+++ b/drivers/iio/adc/stm32-adc.c
@@ -1227,8 +1227,8 @@ static int stm32_adc_read_raw(struct iio_dev *indio_dev,
static irqreturn_t stm32_adc_threaded_isr(int irq, void *data)
{
- struct stm32_adc *adc = data;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = data;
+ struct stm32_adc *adc = iio_priv(indio_dev);
const struct stm32_adc_regspec *regs = adc->cfg->regs;
u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg);
@@ -1240,8 +1240,8 @@ static irqreturn_t stm32_adc_threaded_isr(int irq, void *data)
static irqreturn_t stm32_adc_isr(int irq, void *data)
{
- struct stm32_adc *adc = data;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = data;
+ struct stm32_adc *adc = iio_priv(indio_dev);
const struct stm32_adc_regspec *regs = adc->cfg->regs;
u32 status = stm32_adc_readl(adc, regs->isr_eoc.reg);
@@ -1882,7 +1882,7 @@ static int stm32_adc_probe(struct platform_device *pdev)
ret = devm_request_threaded_irq(&pdev->dev, adc->irq, stm32_adc_isr,
stm32_adc_threaded_isr,
- 0, pdev->name, adc);
+ 0, pdev->name, indio_dev);
if (ret) {
dev_err(&pdev->dev, "failed to request IRQ\n");
return ret;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/8] iio: stm32-dfsdm-adc: pass iio device as arg for the interrupt handler
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
This changes the argument for the interrupt handler to be the IIO device
instead of the state-struct.
Since there will be some changes to how iio_priv_to_dev() is implemented,
it could be that the helper becomes a bit slower, as it will be hidden away
in the IIO core.
The iio_priv() call will still be fast enough, as it will return a void
pointer from the public IIO device structure. So it's better to switch the
order.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/adc/stm32-dfsdm-adc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
index 76a60d93fe23..28ef02887bd3 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -1313,8 +1313,8 @@ static const struct iio_info stm32_dfsdm_info_adc = {
static irqreturn_t stm32_dfsdm_irq(int irq, void *arg)
{
- struct stm32_dfsdm_adc *adc = arg;
- struct iio_dev *indio_dev = iio_priv_to_dev(adc);
+ struct iio_dev *indio_dev = arg;
+ struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
struct regmap *regmap = adc->dfsdm->regmap;
unsigned int status, int_en;
@@ -1603,7 +1603,7 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
return irq;
ret = devm_request_irq(dev, irq, stm32_dfsdm_irq,
- 0, pdev->name, adc);
+ 0, pdev->name, iio);
if (ret < 0) {
dev_err(dev, "Failed to request IRQ\n");
return ret;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 6/8] iio: core: wrap IIO device into an iio_dev_opaque object
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
There are plenty of bad designs we want to discourage or not have to review
manually usually about accessing private (marked as [INTERN]) fields of
'struct iio_dev'.
Sometimes users copy drivers that are not always the best examples.
A better idea is to hide those fields into the framework.
For 'struct iio_dev' this is a 'struct iio_dev_opaque' which wraps a public
'struct iio_dev' object.
In the next series, some fields will be moved to this new struct, each with
it's own rework.
This rework will not be complete-able for a while, as many fields need some
drivers to be reworked in order to finalize them (e.g. 'indio_dev->mlock').
But some fields can already be moved, and in time, all of them may get
there (in the 'struct iio_dev_opaque' object).
Since a lot of drivers also call 'iio_priv()', in order to preserve
fast-paths (where this matters), the public iio_dev object will have a
'priv' field that will have the pointer to the private information already
computed. The reference returned by this field should be guaranteed to be
cacheline aligned.
As for the 'iio_priv_to_dev()' helper, this needs to be hidden away. There
aren't many users of this helper, and arguably drivers shouldn't need to
use it in any fast-paths, as they can maintain a reference to the IIO
device.
The opaque parts will be moved into the 'include/linux/iio/iio-opaque.h'
header. Should the hidden information be required for some debugging or
some special needs, it can be made available via this header.
Otherwise, only the IIO core files should include this file.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/industrialio-core.c | 27 ++++++++++++++++++++++-----
include/linux/iio/iio-opaque.h | 17 +++++++++++++++++
include/linux/iio/iio.h | 11 +++++------
3 files changed, 44 insertions(+), 11 deletions(-)
create mode 100644 include/linux/iio/iio-opaque.h
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 462d3e810013..a1b29e0f8fd6 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -25,6 +25,7 @@
#include <linux/debugfs.h>
#include <linux/mutex.h>
#include <linux/iio/iio.h>
+#include <linux/iio/iio-opaque.h>
#include "iio_core.h"
#include "iio_core_trigger.h"
#include <linux/iio/sysfs.h>
@@ -164,6 +165,15 @@ static const char * const iio_chan_info_postfix[] = {
[IIO_CHAN_INFO_THERMOCOUPLE_TYPE] = "thermocouple_type",
};
+struct iio_dev *iio_priv_to_dev(void *priv)
+{
+ struct iio_dev_opaque *iio_dev_opaque =
+ (struct iio_dev_opaque *)((char *)priv -
+ ALIGN(sizeof(struct iio_dev_opaque), IIO_ALIGN));
+ return &iio_dev_opaque->indio_dev;
+}
+EXPORT_SYMBOL_GPL(iio_priv_to_dev);
+
/**
* iio_find_channel_from_si() - get channel from its scan index
* @indio_dev: device
@@ -1476,6 +1486,8 @@ static void iio_device_unregister_sysfs(struct iio_dev *indio_dev)
static void iio_dev_release(struct device *device)
{
struct iio_dev *indio_dev = dev_to_iio_dev(device);
+ struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
+
if (indio_dev->modes & INDIO_ALL_TRIGGERED_MODES)
iio_device_unregister_trigger_consumer(indio_dev);
iio_device_unregister_eventset(indio_dev);
@@ -1484,7 +1496,7 @@ static void iio_dev_release(struct device *device)
iio_buffer_put(indio_dev->buffer);
ida_simple_remove(&iio_ida, indio_dev->id);
- kfree(indio_dev);
+ kfree(iio_dev_opaque);
}
struct device_type iio_device_type = {
@@ -1498,10 +1510,11 @@ struct device_type iio_device_type = {
**/
struct iio_dev *iio_device_alloc(int sizeof_priv)
{
+ struct iio_dev_opaque *iio_dev_opaque;
struct iio_dev *dev;
size_t alloc_size;
- alloc_size = sizeof(struct iio_dev);
+ alloc_size = sizeof(struct iio_dev_opaque);
if (sizeof_priv) {
alloc_size = ALIGN(alloc_size, IIO_ALIGN);
alloc_size += sizeof_priv;
@@ -1509,10 +1522,14 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
/* ensure 32-byte alignment of whole construct ? */
alloc_size += IIO_ALIGN - 1;
- dev = kzalloc(alloc_size, GFP_KERNEL);
- if (!dev)
+ iio_dev_opaque = kzalloc(alloc_size, GFP_KERNEL);
+ if (!iio_dev_opaque)
return NULL;
+ dev = &iio_dev_opaque->indio_dev;
+ dev->priv = (char *)iio_dev_opaque +
+ ALIGN(sizeof(struct iio_dev_opaque), IIO_ALIGN);
+
dev->dev.groups = dev->groups;
dev->dev.type = &iio_device_type;
dev->dev.bus = &iio_bus_type;
@@ -1526,7 +1543,7 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
if (dev->id < 0) {
/* cannot use a dev_err as the name isn't available */
pr_err("failed to get device id\n");
- kfree(dev);
+ kfree(iio_dev_opaque);
return NULL;
}
dev_set_name(&dev->dev, "iio:device%d", dev->id);
diff --git a/include/linux/iio/iio-opaque.h b/include/linux/iio/iio-opaque.h
new file mode 100644
index 000000000000..1375674f14cd
--- /dev/null
+++ b/include/linux/iio/iio-opaque.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _INDUSTRIAL_IO_OPAQUE_H_
+#define _INDUSTRIAL_IO_OPAQUE_H_
+
+/**
+ * struct iio_dev_opaque - industrial I/O device opaque information
+ * @indio_dev: public industrial I/O device information
+ */
+struct iio_dev_opaque {
+ struct iio_dev indio_dev;
+};
+
+#define to_iio_dev_opaque(indio_dev) \
+ container_of(indio_dev, struct iio_dev_opaque, indio_dev)
+
+#endif
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 5f9f439a4f01..e82693db6578 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -522,6 +522,7 @@ struct iio_buffer_setup_ops {
* @flags: [INTERN] file ops related flags including busy flag.
* @debugfs_dentry: [INTERN] device specific debugfs dentry.
* @cached_reg_addr: [INTERN] cached register address for debugfs reads.
+ * @priv: [DRIVER] reference to driver's private information
*/
struct iio_dev {
int id;
@@ -571,6 +572,7 @@ struct iio_dev {
char read_buf[20];
unsigned int read_buf_len;
#endif
+ void *priv;
};
const struct iio_chan_spec
@@ -678,16 +680,13 @@ static inline void *iio_device_get_drvdata(struct iio_dev *indio_dev)
#define IIO_ALIGN L1_CACHE_BYTES
struct iio_dev *iio_device_alloc(int sizeof_priv);
+/* The information at this reference is guaranteed to be cacheline aligned */
static inline void *iio_priv(const struct iio_dev *indio_dev)
{
- return (char *)indio_dev + ALIGN(sizeof(struct iio_dev), IIO_ALIGN);
+ return indio_dev->priv;
}
-static inline struct iio_dev *iio_priv_to_dev(void *priv)
-{
- return (struct iio_dev *)((char *)priv -
- ALIGN(sizeof(struct iio_dev), IIO_ALIGN));
-}
+struct iio_dev *iio_priv_to_dev(void *priv);
void iio_device_free(struct iio_dev *indio_dev);
struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 7/8] iio: core: simplify alloc alignment code
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
There was a recent discussion about this code:
https://lore.kernel.org/linux-iio/20200322165317.0b1f0674@archlinux/
This looks like a good time to rework this, since any issues about it
should pop-up under testing, because the iio_dev is having a bit of an
overhaul and stuff being moved to iio_dev_priv.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/industrialio-core.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index a1b29e0f8fd6..7671d36efae7 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -1514,13 +1514,9 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
struct iio_dev *dev;
size_t alloc_size;
- alloc_size = sizeof(struct iio_dev_opaque);
- if (sizeof_priv) {
- alloc_size = ALIGN(alloc_size, IIO_ALIGN);
- alloc_size += sizeof_priv;
- }
- /* ensure 32-byte alignment of whole construct ? */
- alloc_size += IIO_ALIGN - 1;
+ alloc_size = ALIGN(sizeof(struct iio_dev_opaque), IIO_ALIGN);
+ if (sizeof_priv)
+ alloc_size += ALIGN(sizeof_priv, IIO_ALIGN);
iio_dev_opaque = kzalloc(alloc_size, GFP_KERNEL);
if (!iio_dev_opaque)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 8/8] iio: core: move debugfs data on the private iio dev info
From: Alexandru Ardelean @ 2020-05-14 13:17 UTC (permalink / raw)
To: linux-iio, linux-arm-kernel, linux-stm32, linux-kernel
Cc: alexandre.belloni, alexandre.torgue, ludovic.desroches, ak,
mcoquelin.stm32, eugen.hristev, Alexandru Ardelean, jic23
In-Reply-To: <20200514131710.84201-1-alexandru.ardelean@analog.com>
This change moves all iio_dev debugfs fields to the iio_dev_priv object.
It's not the biggest advantage yet (to the whole thing of abstractization)
but it's a start.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/iio/industrialio-core.c | 40 ++++++++++++++++++++++-----------
include/linux/iio/iio-opaque.h | 10 +++++++++
include/linux/iio/iio.h | 13 +----------
3 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 7671d36efae7..26bef5032810 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -174,6 +174,13 @@ struct iio_dev *iio_priv_to_dev(void *priv)
}
EXPORT_SYMBOL_GPL(iio_priv_to_dev);
+struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
+{
+ struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
+ return iio_dev_opaque->debugfs_dentry;
+}
+EXPORT_SYMBOL_GPL(iio_get_debugfs_dentry);
+
/**
* iio_find_channel_from_si() - get channel from its scan index
* @indio_dev: device
@@ -317,35 +324,37 @@ static ssize_t iio_debugfs_read_reg(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
struct iio_dev *indio_dev = file->private_data;
+ struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
unsigned val = 0;
int ret;
if (*ppos > 0)
return simple_read_from_buffer(userbuf, count, ppos,
- indio_dev->read_buf,
- indio_dev->read_buf_len);
+ iio_dev_opaque->read_buf,
+ iio_dev_opaque->read_buf_len);
ret = indio_dev->info->debugfs_reg_access(indio_dev,
- indio_dev->cached_reg_addr,
+ iio_dev_opaque->cached_reg_addr,
0, &val);
if (ret) {
dev_err(indio_dev->dev.parent, "%s: read failed\n", __func__);
return ret;
}
- indio_dev->read_buf_len = snprintf(indio_dev->read_buf,
- sizeof(indio_dev->read_buf),
- "0x%X\n", val);
+ iio_dev_opaque->read_buf_len = snprintf(iio_dev_opaque->read_buf,
+ sizeof(iio_dev_opaque->read_buf),
+ "0x%X\n", val);
return simple_read_from_buffer(userbuf, count, ppos,
- indio_dev->read_buf,
- indio_dev->read_buf_len);
+ iio_dev_opaque->read_buf,
+ iio_dev_opaque->read_buf_len);
}
static ssize_t iio_debugfs_write_reg(struct file *file,
const char __user *userbuf, size_t count, loff_t *ppos)
{
struct iio_dev *indio_dev = file->private_data;
+ struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
unsigned reg, val;
char buf[80];
int ret;
@@ -360,10 +369,10 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
switch (ret) {
case 1:
- indio_dev->cached_reg_addr = reg;
+ iio_dev_opaque->cached_reg_addr = reg;
break;
case 2:
- indio_dev->cached_reg_addr = reg;
+ iio_dev_opaque->cached_reg_addr = reg;
ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
val, NULL);
if (ret) {
@@ -387,23 +396,28 @@ static const struct file_operations iio_debugfs_reg_fops = {
static void iio_device_unregister_debugfs(struct iio_dev *indio_dev)
{
- debugfs_remove_recursive(indio_dev->debugfs_dentry);
+ struct iio_dev_opaque *iio_dev_opaque = to_iio_dev_opaque(indio_dev);
+ debugfs_remove_recursive(iio_dev_opaque->debugfs_dentry);
}
static void iio_device_register_debugfs(struct iio_dev *indio_dev)
{
+ struct iio_dev_opaque *iio_dev_opaque;
+
if (indio_dev->info->debugfs_reg_access == NULL)
return;
if (!iio_debugfs_dentry)
return;
- indio_dev->debugfs_dentry =
+ iio_dev_opaque = to_iio_dev_opaque(indio_dev);
+
+ iio_dev_opaque->debugfs_dentry =
debugfs_create_dir(dev_name(&indio_dev->dev),
iio_debugfs_dentry);
debugfs_create_file("direct_reg_access", 0644,
- indio_dev->debugfs_dentry, indio_dev,
+ iio_dev_opaque->debugfs_dentry, indio_dev,
&iio_debugfs_reg_fops);
}
#else
diff --git a/include/linux/iio/iio-opaque.h b/include/linux/iio/iio-opaque.h
index 1375674f14cd..b3f234b4c1e9 100644
--- a/include/linux/iio/iio-opaque.h
+++ b/include/linux/iio/iio-opaque.h
@@ -6,9 +6,19 @@
/**
* struct iio_dev_opaque - industrial I/O device opaque information
* @indio_dev: public industrial I/O device information
+ * @debugfs_dentry: device specific debugfs dentry
+ * @cached_reg_addr: cached register address for debugfs reads
+ * @read_buf: read buffer to be used for the initial reg read
+ * @read_buf_len: data length in @read_buf
*/
struct iio_dev_opaque {
struct iio_dev indio_dev;
+#if defined(CONFIG_DEBUG_FS)
+ struct dentry *debugfs_dentry;
+ unsigned cached_reg_addr;
+ char read_buf[20];
+ unsigned int read_buf_len;
+#endif
};
#define to_iio_dev_opaque(indio_dev) \
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index e82693db6578..a52a9f688b35 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -520,8 +520,6 @@ struct iio_buffer_setup_ops {
* @groups: [INTERN] attribute groups
* @groupcounter: [INTERN] index of next attribute group
* @flags: [INTERN] file ops related flags including busy flag.
- * @debugfs_dentry: [INTERN] device specific debugfs dentry.
- * @cached_reg_addr: [INTERN] cached register address for debugfs reads.
* @priv: [DRIVER] reference to driver's private information
*/
struct iio_dev {
@@ -566,12 +564,6 @@ struct iio_dev {
int groupcounter;
unsigned long flags;
-#if defined(CONFIG_DEBUG_FS)
- struct dentry *debugfs_dentry;
- unsigned cached_reg_addr;
- char read_buf[20];
- unsigned int read_buf_len;
-#endif
void *priv;
};
@@ -708,10 +700,7 @@ static inline bool iio_buffer_enabled(struct iio_dev *indio_dev)
* @indio_dev: IIO device structure for device
**/
#if defined(CONFIG_DEBUG_FS)
-static inline struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
-{
- return indio_dev->debugfs_dentry;
-}
+struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev);
#else
static inline struct dentry *iio_get_debugfs_dentry(struct iio_dev *indio_dev)
{
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: ARM: static kernel in vmalloc space
From: afzal mohammed @ 2020-05-14 13:35 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Russell King, Linux ARM, linux-kernel@vger.kernel.org
In-Reply-To: <CAK8P3a2PNZY-9L9+SFDLtrp731ZGo6Nbs-7jY6E2PwWXa0kfKw@mail.gmail.com>
Hi,
On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> > 1. SoC w/ LPAE
> > 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc,
> > kmap, fixmap & vectors
> Right, these kind of go together because pre-LPAE cannot do the
> same TTBR1 split, and they more frequently have conflicting
> static mappings.
>
> It's clearly possible to do something very similar for older chips
> (v6 or v7 without LPAE, possibly even v5), it just gets harder
> while providing less benefit.
Yes, lets have it only for LPAE
> > 3. TTBR0 (low 3768MB) for user space & lowmem (kernel lowmem to have
> hardcoded 3840/256 split is likely the best compromise of all the
hmm,i swallowed 72MB ;)
> > 4. for user space to/from copy
> > a. pin user pages
> > b. kmap user page (can't corresponding lowmem be used instead ?)
> - In the long run, there is no need for kmap()/kmap_atomic() after
> highmem gets removed from the kernel, but for the next few years
> we should still assume that highmem can be used, in order to support
> systems like the 8GB highbank, armadaxp, keystone2 or virtual
> machines. For lowmem pages (i.e. all pages when highmem is
> disabled), kmap_atomic() falls back to page_address() anyway,
> so there is no much overhead.
Here i have some confusion - iiuc, VMSPLIT_4G_4G is meant to help
platforms having RAM > 768M and <= 4GB disable high memory and still
be able to access full RAM, so high memory shouldn't come into picture,
right ?. And for the above platforms it can continue current VMPSLIT
option (the default 3G/1G), no ?, as VMSPLIT_4G_4G can't help complete
8G to be accessible from lowmem.
So if we make VMSPLIT_4G_4G, depends on !HIGH_MEMORY (w/ mention of
caveat in Kconfig help that this is meant for platforms w/ <=4GB), then
we can do copy_{from,to}_user the same way currently do, and no need to
do the user page pinning & kmap, right ?
Only problem i see is Kernel compiled w/ VMSPLIT_4G_4G not suitable
for >4GB machines, but anyway iiuc, it is was not meant for those
machines. And it is not going to affect our current multiplatform
setup as LPAE is not defined in multi_v7.
Regards
afzal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/15] Fix STM32 DT issues on v5.7-rc4
From: Alexandre Torgue @ 2020-05-14 13:42 UTC (permalink / raw)
To: Benjamin Gaignard, linus.walleij, robh+dt, mcoquelin.stm32,
gregkh
Cc: devicetree, linux-usb, linux-kernel, linux-gpio, linux-stm32,
linux-arm-kernel
In-Reply-To: <20200513145935.22493-1-benjamin.gaignard@st.com>
Hi Benjamin
On 5/13/20 4:59 PM, Benjamin Gaignard wrote:
> This series fixes issues hight lighted by dtbs_check on STM32 devicetrees.
> The patches has been developped on top of v5.7-rc4 tag.
>
> Benjamin Gaignard (15):
> ARM: dts: stm32: remove useless interrupt-names property on stm32f429
> ARM: dts: stm32: update pwm pinctrl node names for stm32f4
> ARM: dts: stm32: update led nodes names for stm32f249-disco
> ARM: dts: stm32: update led nodes names for stm32f469-disco
> ARM: dts: stm32: remove useless interrupt-names property on stm32f746
> ARM: dts: stm32: update led nodes names for stm32f429-eval
> ARM: dts: stm32: update led nodes names for stm32f769-disco
> ARM: dts: stm32: update led nodes names for stm32f746-eval
> ARM: dts: stm32: remove useless interrupt-names property on stm32f743
> ARM: dts: stm32: Update nodes names for stm32h743 pinctrl
> ARM: dts: stm32: Update nodes names for stm32mp15 pinctrl
> ARM: dts: stm32: Add missing #address and #size cells on spi node for
> stm32mp151
> ARM: dts: stm32: update led nodes names for stm32f746-eval
> dt-bindings: pinctrl: stm32: Add missing interrupts property
> dt-bindings: usb: dwc2: Fix issues for stm32mp15x SoC
For dts(i) part, it looks good to me. I let Rob to review before taking
the whole series.
thanks
alex
>
> .../devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 3 +++
> Documentation/devicetree/bindings/usb/dwc2.yaml | 6 ++++--
> arch/arm/boot/dts/stm32429i-eval.dts | 8 ++++----
> arch/arm/boot/dts/stm32746g-eval.dts | 8 ++++----
> arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 4 ++--
> arch/arm/boot/dts/stm32f429-disco.dts | 4 ++--
> arch/arm/boot/dts/stm32f429.dtsi | 1 -
> arch/arm/boot/dts/stm32f469-disco.dts | 8 ++++----
> arch/arm/boot/dts/stm32f746.dtsi | 1 -
> arch/arm/boot/dts/stm32f769-disco.dts | 4 ++--
> arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 10 +++++-----
> arch/arm/boot/dts/stm32h743.dtsi | 1 -
> arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 6 +++---
> arch/arm/boot/dts/stm32mp151.dtsi | 2 ++
> arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 2 +-
> 15 files changed, 36 insertions(+), 32 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 19/38] drm: panfrost: fix common struct sg_table related issues
From: Rob Herring @ 2020-05-14 13:51 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Tomeu Vizoso, Bartlomiej Zolnierkiewicz, David Airlie,
linux-kernel@vger.kernel.org, dri-devel, linaro-mm-sig,
Linux IOMMU, Daniel Vetter, Robin Murphy, Christoph Hellwig,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200513133245.6408-19-m.szyprowski@samsung.com>
On Wed, May 13, 2020 at 8:33 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
>
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
>
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
>
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Steven Price <steven.price@arm.com>
> ---
> For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
> vs. orig_nents misuse' thread:
> https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprowski@samsung.com/T/
> ---
> drivers/gpu/drm/panfrost/panfrost_gem.c | 4 ++--
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 +++----
> 2 files changed, 5 insertions(+), 6 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: mm: make act_mm() respect THREAD_SIZE_ORDER
From: Linus Walleij @ 2020-05-14 13:57 UTC (permalink / raw)
To: Russell King
Cc: Linus Walleij, Florian Fainelli, Ard Biesheuvel, linux-arm-kernel
Recent work with KASan exposed the folling hard-coded bitmask
in arch/arm/mm/proc-macros.S:
bic \rd, sp, #8128
bic \rd, \rd, #63
This forms the bitmask 0x1FFF that is coinciding with
(PAGE_SIZE << THREAD_SIZE_ORDER) - 1, this code was assuming
that THREAD_SIZE is always 8K (8192).
As KASan was increasing THREAD_SIZE_ORDER to 2, I ran into
this bug.
Fix it by this little oneline suggested by Ard:
bic \rd, sp, #(4095 << THREAD_SIZE_ORDER) & ~63
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I'm sending this as a separate preparatory fix as it is
a nice fix in its own right. I am now testing KASan on
ARMv4 and ARMv5 and with some minimal busybox userspace
it is quite possible to run it on even really small
devices like the Gemini-based routers and NAS from
D-Link.
---
arch/arm/mm/proc-macros.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
index 5461d589a1e2..ba100b2d0ac2 100644
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -30,7 +30,7 @@
* act_mm - get current->active_mm
*/
.macro act_mm, rd
- bic \rd, sp, #8128
+ bic \rd, sp, #(4095 << THREAD_SIZE_ORDER) & ~63
bic \rd, \rd, #63
ldr \rd, [\rd, #TI_TASK]
.if (TSK_ACTIVE_MM > IMM12_MASK)
--
2.25.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [GIT PULL] Qualcomm ARM64 DT fixes for v5.7
From: Bjorn Andersson @ 2020-05-14 14:00 UTC (permalink / raw)
To: arm-soc, soc
Cc: Arnd Bergmann, linux-arm-msm, Andy Gross, Srinivas Kandagatla,
Kevin Hilman, Olof Johansson, LAKML
In-Reply-To: <20200429052932.GA2627045@builder.lan>
Arnd, Olof?
On Tue, Apr 28, 2020 at 10:28 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
>
> Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git tags/qcom-arm64-fixes-for-5.7
>
> for you to fetch changes up to 7710f80ecd9c74544a22557ab581cf603e713f51:
>
> arm64: dts: qcom: db820c: fix audio configuration (2020-04-22 19:26:14 -0700)
>
> ----------------------------------------------------------------
> Qualcomm ARM64 DT fixes for v5.7
>
> This reduces the (hard coded) CPU voltage to a safe level on MSM8996 and
> updates the audio nodes on db820c, db845c and c630 to reflect audio
> changes that landed late in the cycle.
>
> ----------------------------------------------------------------
> Bjorn Andersson (1):
> arm64: dts: qcom: msm8996: Reduce vdd_apc voltage
>
> Srinivas Kandagatla (3):
> arm64: qcom: c630: fix asm dai setup
> arm64: dts: qcom: db845c: fix asm dai setup
> arm64: dts: qcom: db820c: fix audio configuration
>
> arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 23 +++++++++++++++++++---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
> arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 3 ---
> .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 2 --
> 4 files changed, 22 insertions(+), 8 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 5/5] drm/panel: Add ilitek ili9341 driver
From: Linus Walleij @ 2020-05-14 14:07 UTC (permalink / raw)
To: dillon min
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre TORGUE, Dave Airlie, Michael Turquette,
linux-kernel@vger.kernel.org, open list:DRM PANEL DRIVERS,
linux-clk, Stephen Boyd, Rob Herring, thierry.reding@gmail.com,
Maxime Coquelin, Daniel Vetter, Sam Ravnborg, linux-stm32,
Linux ARM
In-Reply-To: <CAL9mu0LVsePqifEC+-FR+NxvuZT3UGpU86KhzaTqb7w_Px0z2g@mail.gmail.com>
On Thu, May 14, 2020 at 12:22 PM dillon min <dillon.minfei@gmail.com> wrote:
> > > + /* Gamma */
> > > + mipi_dbi_command(dbi, ILI9341_3GAMMA_EN, 0x00);
> > > + mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
> > > + mipi_dbi_command(dbi, ILI9341_PGAMMA,
> > > + 0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
> > > + 0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
> > > + mipi_dbi_command(dbi, ILI9341_NGAMMA,
> > > + 0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
> > > + 0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
> >
> > It seems to be copies of the stuff above, but why is there a different
> > gamma if you use DBI?
> for dbi interface, currently i just copy the code from tiny/ili9341.c.
> as so many boards use this driver now, like raspberry pi, etc
> i'm afraid it's will not work after modification. so, just leave the
> original code there.
OK if you move it to ili9341_config it will be clear which panels
need this gamma and which panels need another gamma.
I think there should be one ili9341_config for the new st,*
variant and one for the old DBI variant.
> anther question:
> is there any panel driver have dbi & dpi or dpi & dsi supported? which
> i mean support
> two different panel interface in one driver.
> thanks
Usually you split the driver in three files becuase a driver can
only list one initcall, and also it makes it modularized.
There is nothing in-tree but look at my branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=ux500-skomer-v5.7-rc1
You see how I split up the s6e63m0 driver in one SPI part
and one DSI part:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=ux500-skomer-v5.7-rc1&id=6c0e1fb5df5fa8fa857dee65f6c0f54d06d158a7
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/commit/?h=ux500-skomer-v5.7-rc1&id=cfbf562cc709b53b62f5fbc7fedf176ffa17b088
The overall idea should work the same with DBI.
Yours,
Linus Walleij
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: stm32: enable l3gd20 on stm32429-disco board
From: Alexandre Torgue @ 2020-05-14 14:09 UTC (permalink / raw)
To: dillon.minfei, robh+dt, mcoquelin.stm32, broonie, p.zabel
Cc: devicetree, dillonhua, linux-kernel, linux-spi, linux-stm32,
linux-arm-kernel
In-Reply-To: <1589269010-18472-3-git-send-email-dillon.minfei@gmail.com>
Hi Dillon
On 5/12/20 9:36 AM, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> L3gd20, st mems motion sensor, 3-axis digital output gyroscope,
> connect to stm32f429 via spi5
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
>
> Hi Alexandre,
>
> V2:
> 1, insert blank line at stm32f420-disco.dts line 143
> 2, add more description about l3gd20 in commit message
>
> V1:
> enable l3gd20 dts binding on stm32f429-disco
>
> thanks.
>
> dillon,
>
> arch/arm/boot/dts/stm32f429-disco.dts | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
> index 30c0f67..1bfb903 100644
> --- a/arch/arm/boot/dts/stm32f429-disco.dts
> +++ b/arch/arm/boot/dts/stm32f429-disco.dts
> @@ -49,6 +49,8 @@
> #include "stm32f429.dtsi"
> #include "stm32f429-pinctrl.dtsi"
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/gpio/gpio.h>
>
> / {
> model = "STMicroelectronics STM32F429i-DISCO board";
> @@ -127,3 +129,26 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&spi5 {
> + status = "okay";
> + pinctrl-0 = <&spi5_pins>;
> + pinctrl-names = "default";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cs-gpios = <&gpioc 1 GPIO_ACTIVE_LOW>;
> + dmas = <&dma2 3 2 0x400 0x0>,
> + <&dma2 4 2 0x400 0x0>;
> + dma-names = "rx", "tx";
> +
You added this spi5 node in this patch but also in the display series. I
will have issue to merge. Even if I could fix it easily, as you are
going to resend, the good practice could be to have several patches in
one series: one patch for spi5 controller, another for gyro and another
for display.
And also same remark than Linus did in display series move DMA to soc
dtsi file please.
> + l3gd20: l3gd20@0 {
> + compatible = "st,l3gd20-gyro";
> + spi-max-frequency = <10000000>;
> + st,drdy-int-pin = <2>;
> + interrupt-parent = <&gpioa>;
> + interrupts = <1 IRQ_TYPE_EDGE_RISING>,
> + <2 IRQ_TYPE_EDGE_RISING>;
> + reg = <0>;
> + status = "okay";
> + };
> +};
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64: defconfig: Enable Qualcomm SC7180 pinctrl and gcc
From: Robert Foss @ 2020-05-14 14:10 UTC (permalink / raw)
To: bjorn.andersson
Cc: Anson.Huang, catalin.marinas, linux-kernel, Robert Foss,
marcin.juszkiewicz, dinguyen, will, maxime, linux-arm-msm, olof,
leonard.crestez, shawnguo, linux-arm-kernel
In-Reply-To: <20200116045457.2489704-1-bjorn.andersson@linaro.org>
> Enable the Qualcomm SC7180 pinctrl and gcc driver, in order to allow the
> kernel to boot to console.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: drop Thumb-2 workaround for ancient binutils
From: Linus Walleij @ 2020-05-14 14:13 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: Arnd Bergmann, Russell King, Linux ARM, Dave Martin
In-Reply-To: <20200507093349.25313-1-ardb@kernel.org>
On Thu, May 7, 2020 at 11:33 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> The CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11 workaround addresses an issue
> which was fixed before the oldest supported binutils (2.23 at this time)
> were released. So we can remove it now.
>
> Cc: Dave Martin <Dave.Martin@arm.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Makes sense.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] cpuidle: psci: Fixup execution order when entering a domain idle state
From: Sudeep Holla @ 2020-05-14 14:20 UTC (permalink / raw)
To: Ulf Hansson
Cc: Lorenzo Pieralisi, Benjamin Gaignard, linux-pm, Stephen Boyd,
Daniel Lezcano, Rafael J . Wysocki, Lina Iyer, Bjorn Andersson,
Sudeep Holla, linux-arm-kernel
In-Reply-To: <20200511133346.21706-1-ulf.hansson@linaro.org>
On Mon, May 11, 2020 at 03:33:46PM +0200, Ulf Hansson wrote:
> Moving forward, platforms are going to need to execute specific "last-man"
> operations before a domain idle state can be entered.
I need to dig the thread details, but I remember commenting on one of
the similar discussion. It was something to do with voting which wasn't
necessary at all. I am interested in the details here.
> In one way or the other, these operations needs to be triggered while
> walking the hierarchical topology via runtime PM and genpd, as it's at that
> point the last-man becomes known.
>
> Moreover, executing last-man operations needs to be done after the CPU PM
> notifications are sent through cpu_pm_enter(), as otherwise it's likely
> that some notifications would fail. Therefore, let's re-order the sequence
> in psci_enter_domain_idle_state(), so cpu_pm_enter() gets called prior
> pm_runtime_put_sync().
>
More details on why notifications fail ?
> Fixes: ce85aef570df ("cpuidle: psci: Manage runtime PM in the idle path")
> Reported-by: Lina Iyer <ilina@codeaurora.org>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/cpuidle/cpuidle-psci.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/cpuidle-psci.c b/drivers/cpuidle/cpuidle-psci.c
> index bae9140a65a5..d0fb585073c6 100644
> --- a/drivers/cpuidle/cpuidle-psci.c
> +++ b/drivers/cpuidle/cpuidle-psci.c
> @@ -58,6 +58,10 @@ static int psci_enter_domain_idle_state(struct cpuidle_device *dev,
> u32 state;
> int ret;
>
> + ret = cpu_pm_enter();
> + if (ret)
> + return -1;
> +
This change is ignoring the retention case psci_enter_state handles and
this may affect performance by doing unnecessary save/restore.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] usb: gadget: u_serial: fix coverity warning: negative index at array
From: Alan Stern @ 2020-05-14 14:22 UTC (permalink / raw)
To: Macpaul Lin
Cc: Stan Lu, Felipe Balbi, Mediatek WSD Upstream, Greg Kroah-Hartman,
linux-usb, linux-kernel, Michał Mirosław,
Sergey Organov, Matthias Brugger, linux-mediatek, Macpaul Lin,
linux-arm-kernel
In-Reply-To: <1589443500-3990-1-git-send-email-macpaul.lin@mediatek.com>
On Thu, May 14, 2020 at 04:05:00PM +0800, Macpaul Lin wrote:
> This issue has been reported by coverity scanner.
> Replace "int portnum" by "unsigned int", this void negative index at
> array.
Can you please explain this more fully? Why does coverity think the
code might use a negative array index? Is there some possibility that
the portnum value might actually be negative?
It's noticeable that your patch doesn't actually change any values, only
the type. This means that if the code was buggy before, it's still
buggy. Alternatively, if the code wasn't buggy before then coverity got
a false positive, so no change should be needed.
Alan Stern
> Signed-off-by: Stan Lu <stan.lu@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
> drivers/usb/gadget/function/u_serial.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_serial.c b/drivers/usb/gadget/function/u_serial.c
> index 8167d37..53951f2 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -587,7 +587,7 @@ static int gs_start_io(struct gs_port *port)
> */
> static int gs_open(struct tty_struct *tty, struct file *file)
> {
> - int port_num = tty->index;
> + unsigned int port_num = tty->index;
> struct gs_port *port;
> int status = 0;
>
> @@ -1211,7 +1211,7 @@ int gserial_alloc_line_no_console(unsigned char *line_num)
> struct gs_port *port;
> struct device *tty_dev;
> int ret;
> - int port_num;
> + unsigned int port_num;
>
> coding.dwDTERate = cpu_to_le32(9600);
> coding.bCharFormat = 8;
> --
> 1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] firmware: psci: support SMCCC v1.2 for SMCCC conduit
From: Sudeep Holla @ 2020-05-14 14:24 UTC (permalink / raw)
To: Etienne Carriere
Cc: mark.rutland, lorenzo.pieralisi, maz, linux-kernel, steven.price,
alexios.zavras, Sudeep Holla, tglx, will, linux-arm-kernel
In-Reply-To: <20200514082109.27573-2-etienne.carriere@linaro.org>
On Thu, May 14, 2020 at 10:21:09AM +0200, Etienne Carriere wrote:
> Update PSCI driver to support SMCCC v1.2 reported by secure firmware
> and indirectly make SMCCC conduit properly set when so. TF-A release
> v2.3 implements and reports SMCCC v1.2 since commit [1].
>
> Link: [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=e34cc0cedca6e229847c232fe58d37fad2610ce9
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> ---
> drivers/firmware/psci/psci.c | 14 ++++++++++----
> include/linux/psci.h | 1 +
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 2937d44b5df4..80cf73bea4b0 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -409,11 +409,17 @@ static void __init psci_init_smccc(void)
> feature = psci_features(ARM_SMCCC_VERSION_FUNC_ID);
>
> if (feature != PSCI_RET_NOT_SUPPORTED) {
> - u32 ret;
> - ret = invoke_psci_fn(ARM_SMCCC_VERSION_FUNC_ID, 0, 0, 0);
> - if (ret == ARM_SMCCC_VERSION_1_1) {
> + ver = invoke_psci_fn(ARM_SMCCC_VERSION_FUNC_ID, 0, 0, 0);
> +
> + switch (ver) {
> + case ARM_SMCCC_VERSION_1_1:
> psci_ops.smccc_version = SMCCC_VERSION_1_1;
> - ver = ret;
> + break;
> + case ARM_SMCCC_VERSION_1_2:
> + psci_ops.smccc_version = SMCCC_VERSION_1_2;
> + break;
> + default:
> + break;
> }
> }
>
> diff --git a/include/linux/psci.h b/include/linux/psci.h
> index a67712b73b6c..c7d99b7f34ed 100644
> --- a/include/linux/psci.h
> +++ b/include/linux/psci.h
> @@ -24,6 +24,7 @@ bool psci_has_osi_support(void);
> enum smccc_version {
> SMCCC_VERSION_1_0,
> SMCCC_VERSION_1_1,
> + SMCCC_VERSION_1_2,
I took approach to kill this completely [1] instead of having to keep
expanding it for ever.
--
Regards,
Sudeep
[1] https://lore.kernel.org/linux-arm-kernel/20200506164411.3284-5-sudeep.holla@arm.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 4/4] ARM: dts: stm32: Split Avenger96 into DHCOR SoM and Avenger96 board
From: Alexandre Torgue @ 2020-05-14 14:27 UTC (permalink / raw)
To: Marek Vasut, linux-arm-kernel
Cc: Patrick Delaunay, linux-stm32, Patrice Chotard, Maxime Coquelin,
Manivannan Sadhasivam
In-Reply-To: <20200513181020.8225-4-marex@denx.de>
Hi Marek
On 5/13/20 8:10 PM, Marek Vasut wrote:
> The Avenger96 is in fact an assembly of DH Electronics DHCOR SoM on top
> of an Avenger96 reference board. The DHCOR SoM can be populated with any
> STM32MP15xx. Split the DTs to reflect this such that the common SoM and
> Avenger96 parts are now in stm32mp15xx-dhcor-*dtsi and a specific example
> implementation of STM32MP157A SoM and Avenger96 board is separated into
> stm32mp157a-dhcor-*dts* . The stm32mp157a-avenger96.dts is retained for
> the sake of backward naming compatibility.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: linux-stm32@st-md-mailman.stormreply.com
> To: linux-arm-kernel@lists.infradead.org
> ---
> V2: - Drop the stm32mp157a-dhcor-som.dtsi , as it was just include statements
> - Add comment about what SoM+Board combination is currently supported
> V3: No change
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/stm32mp157a-avenger96.dts | 618 +-----------------
> .../boot/dts/stm32mp157a-dhcor-avenger96.dts | 38 ++
> .../boot/dts/stm32mp15xx-dhcor-avenger96.dtsi | 401 ++++++++++++
> .../arm/boot/dts/stm32mp15xx-dhcor-io1v8.dtsi | 23 +
> arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi | 209 ++++++
> 6 files changed, 675 insertions(+), 615 deletions(-)
> create mode 100644 arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dts
> create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcor-io1v8.dtsi
> create mode 100644 arch/arm/boot/dts/stm32mp15xx-dhcor-som.dtsi
>
Series applied on stm32-next.
Regards
Alex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
From: Chun-Kuang Hu @ 2020-05-14 14:28 UTC (permalink / raw)
To: Enric Balletbo Serra
Cc: Chun-Kuang Hu, Nicolas Boichat, Daniel Vetter, David Airlie,
linux-kernel, dri-devel, Matthias Brugger,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
Philipp Zabel, Hsin-Yi Wang, Enric Balletbo i Serra,
Collabora Kernel ML, Sam Ravnborg, Linux ARM
In-Reply-To: <CAFqH_53h=3OXzwLnw1XT3rHYkMPOPNFBdQdPeFmNubN9qq_Twg@mail.gmail.com>
Hi, Enric:
Enric Balletbo Serra <eballetbo@gmail.com> 於 2020年5月14日 週四 上午12:41寫道：
>
> Hi Chun-Kuang,
>
> Missatge de Enric Balletbo i Serra <enric.balletbo@collabora.com> del
> dia dv., 1 de maig 2020 a les 17:25:
> >
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector operations across
> > multiple bridges when necessary, instead of having the last bridge in
> > the chain creating the connector and handling all connector operations
> > internally.
> >
> > Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> A gentle ping on this, I think that this one is the only one that
> still needs a review in the series.
This is what I reply in patch v3:
I think the panel is wrapped into next_bridge here,
if (panel) {
dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
so the next_bridge is a panel_bridge, in its attach function
panel_bridge_attach(),
according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
it would create connector and attach connector to panel.
I'm not sure this flag would exist or not, but for both case, it's strange.
If exist, you create connector in this patch but no where to attach
connector to panel.
If not exist, the next_brige would create one connector and this brige
would create another connector.
I think in your case, mtk_dsi does not directly connect to a panel, so
I need a exact explain. Or someone could test this on a
directly-connect-panel platform.
Regards,
Chun-Kuang.
>
> Thanks,
> Enric
>
> > ---
> >
> > Changes in v4: None
> > Changes in v3:
> > - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart)
> >
> > Changes in v2: None
> >
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 4f3bd095c1ee..471fcafdf348 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -17,6 +17,7 @@
> >
> > #include <drm/drm_atomic_helper.h>
> > #include <drm/drm_bridge.h>
> > +#include <drm/drm_bridge_connector.h>
> > #include <drm/drm_mipi_dsi.h>
> > #include <drm/drm_of.h>
> > #include <drm/drm_panel.h>
> > @@ -183,6 +184,7 @@ struct mtk_dsi {
> > struct drm_encoder encoder;
> > struct drm_bridge bridge;
> > struct drm_bridge *next_bridge;
> > + struct drm_connector *connector;
> > struct phy *phy;
> >
> > void __iomem *regs;
> > @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> > */
> > dsi->encoder.possible_crtcs = 1;
> >
> > - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
> > + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> > + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> > if (ret)
> > goto err_cleanup_encoder;
> >
> > + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> > + if (IS_ERR(dsi->connector)) {
> > + DRM_ERROR("Unable to create bridge connector\n");
> > + ret = PTR_ERR(dsi->connector);
> > + goto err_cleanup_encoder;
> > + }
> > + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> > +
> > return 0;
> >
> > err_cleanup_encoder:
> > --
> > 2.26.2
> >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: fix SMCCC_RET_NOT_SUPPORTED management
From: Sudeep Holla @ 2020-05-14 14:29 UTC (permalink / raw)
To: Etienne Carriere; +Cc: linux-kernel, linux-arm-kernel, Sudeep Holla
In-Reply-To: <20200514082428.27864-1-etienne.carriere@linaro.org>
On Thu, May 14, 2020 at 10:24:28AM +0200, Etienne Carriere wrote:
> Fix management of argument a0 output value of arm_smccc_1_1_invoke() that
> should consider only SMCCC_RET_NOT_SUPPORTED as reporting an unsupported
> function ID as correctly stated in the inline comment.
>
I agree on the comment part, but ...
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> ---
> drivers/firmware/arm_scmi/smc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
> index 49bc4b0e8428..637ad439545f 100644
> --- a/drivers/firmware/arm_scmi/smc.c
> +++ b/drivers/firmware/arm_scmi/smc.c
> @@ -115,7 +115,7 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
> mutex_unlock(&scmi_info->shmem_lock);
>
> /* Only SMCCC_RET_NOT_SUPPORTED is valid error code */
> - if (res.a0)
> + if (res.a0 == SMCCC_RET_NOT_SUPPORTED)
> return -EOPNOTSUPP;
Now this will return 0 for all values other than SMCCC_RET_NOT_SUPPORTED.
Is that what we need ? Or do you see non-zero res.a0 for a success case ?
If later, we need some fixing, otherwise it is safer to leave it as is
IMO.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 02/13] arm64: kprobes: Drop open-coded exception fixup
From: Oliver Swede @ 2020-05-14 14:32 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas; +Cc: Robin Murphy, linux-kernel, linux-arm-kernel
In-Reply-To: <20200514143227.605-1-oli.swede@arm.com>
From: Robin Murphy <robin.murphy@arm.com>
The short-circuit call to fixup_exception() from kprobe_fault_handler()
poses a problem now that the former wants to consume the fault address
too, since the common kprobes API offers us no way to pass it through.
Fortunately, however, it works out to be unnecessary:
- uaccess instructions themselves are not probeable, so at most we
should only ever expect to take a fixable fault from the pre or post
handlers.
- the pre and post handler run with preemption disabled, thus for any
fault they may cause, an unhandled return from kprobe_page_fault()
will proceed directly to __do_kernel_fault() thanks to the
faulthandler_disabled() check.
- __do_kernel_fault() will immediately call fixup_exception() unless
we're in an EL1 instruction abort, and if we've somehow taken one of
those on what we think is the middle of a uaccess routine, then the
world is already very on fire.
Thus we can reasonably drop the call from kprobe_fault_handler() and
leave uaccess fixups to the regular flow.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Oliver Swede <oli.swede@arm.com>
---
arch/arm64/kernel/probes/kprobes.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index d1c95dcf1d78..771635360110 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -334,13 +334,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
*/
if (cur->fault_handler && cur->fault_handler(cur, regs, fsr))
return 1;
-
- /*
- * In case the user-specified fault handler returned
- * zero, try to fix up.
- */
- if (fixup_exception(regs))
- return 1;
}
return 0;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 00/13] arm64: Optimise and update memcpy, user copy and string routines
From: Oliver Swede @ 2020-05-14 14:32 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas; +Cc: Robin Murphy, linux-kernel, linux-arm-kernel
Hi, I have been working on a fix for this branch. The initial
version of this patchset imported new optimizations from Linaro's
cortex-strings project, and converted the instructions to the
macro equivalents in the usercopy template, in order to allow
each of the helper usercopy functions to use expansions that
insert exception table entries for exclusively the instructions
that could potentially fault during a copy.
The 'cortex-strings' repository has since been renamed to
'optimized-routines' (this is public on GitHub at
https://github.com/ARM-software/optimized-routines),
and has been updated with further optimizations of various
library functions, and this includes a newer memcpy
implementation.
The address of page faults is exposed to the faulting instructions'
corresponding fixup code, and in v2 a fixup routine to correspond
to the previous copy algorithm was also implemented in a way that
utilized the fault address to try and efficiently calculate the
number of bytes that failed to copy. It returned the distance
between the fault and the end of the buffer, however this fixup
in [PATCH v2 2/14] had some issues due to the out-of-order nature
of the copy algorithm, and was flagged by the LTP testcase of the
preadv2() syscall (which makes multiple calls to copy_to_user).
This was due to preadv2() reporting SUCCESS for an invalid
destination address, NULL, where it expected EFAULT, because a
nonzero return value was calculated (indicating that some bytes
were copied) due to the fault not occurring at the start of the
buffer.
In this version I have imported the very latest optimized memcpy
routine, and re-written the fixup to use multiple routines that
encapsulate various properties of the algorithm (this is
explained in more detail in patches 11/13, 12/13, 13/13).
The aim is to return the exact number of bytes that haven't copied
when a fault occurs in copy_{to, in, from}_user, and to enable the
fixups to be modular so that they could be re-written without too
much trouble in the future if the copy algorithm was to be updated
again.
Initial testing indicates that the backtracking performed in the
fixup routines is accurate, and I am working on a separate
patchset containing more concise selftests that indirectly
call the usercopy functions via read()/write() - this will help
to ease the verification of expected behaviour.
I am going to post updated benchmark results, as the ~27% increase
in speed measured by Sam with the previous 'cortex-strings' memcpy
is no longer applicable due to the more recent replacement from
'optimized-routines', which should hopefully be even more efficient
and improve this further.
v1: https://lore.kernel.org/linux-arm-kernel/cover.1571073960.git.robin.murphy@arm.com/
v2: https://lore.kernel.org/linux-arm-kernel/cover.1571421836.git.robin.murphy@arm.com/
Changes since v2:
* Adds Robin's separate patch that fixes a compilation issue with KProbes fixup [1]
* Imports the most recent memcpy implementation by updating Sam's patch
(and moves this patch to occur after the cortex-strings importing so
that it's closer to the patches containing its corresponding fixups)
* Uses the stack to preserve the initial parameters
* Replaces the usercopy fixup routine in v2 with multiple longer
fixups that each make use of the fault address to return the exact
number of bytes that haven't yet copied.
[1] https://lore.kernel.org/linux-arm-kernel/e70f7b9de7e601b9e4a6fedad8eaf64d304b1637.1571326276.git.robin.murphy@arm.com/
Many thanks,
Oliver
Oliver Swede (4):
arm64: Store the arguments to copy_*_user on the stack
arm64: Use additional memcpy macros and fixups
arm64: Add fixup routines for usercopy load exceptions
arm64: Add fixup routines for usercopy store exceptions
Robin Murphy (2):
arm64: Tidy up _asm_extable_faultaddr usage
arm64: kprobes: Drop open-coded exception fixup
Sam Tebbs (7):
arm64: Allow passing fault address to fixup handlers
arm64: Import latest optimization of memcpy
arm64: Import latest version of Cortex Strings' memcmp
arm64: Import latest version of Cortex Strings' memmove
arm64: Import latest version of Cortex Strings' strcmp
arm64: Import latest version of Cortex Strings' strlen
arm64: Import latest version of Cortex Strings' strncmp
arch/arm64/include/asm/alternative.h | 36 ---
arch/arm64/include/asm/assembler.h | 13 +
arch/arm64/include/asm/extable.h | 10 +-
arch/arm64/kernel/probes/kprobes.c | 7 -
arch/arm64/lib/copy_from_user.S | 272 +++++++++++++++++--
arch/arm64/lib/copy_in_user.S | 287 ++++++++++++++++++--
arch/arm64/lib/copy_template.S | 377 +++++++++++++++------------
arch/arm64/lib/copy_template_user.S | 50 ++++
arch/arm64/lib/copy_to_user.S | 273 +++++++++++++++++--
arch/arm64/lib/copy_user_fixup.S | 277 ++++++++++++++++++++
arch/arm64/lib/memcmp.S | 333 +++++++++--------------
arch/arm64/lib/memcpy.S | 128 +++++++--
arch/arm64/lib/memmove.S | 232 ++++++-----------
arch/arm64/lib/strcmp.S | 272 ++++++++-----------
arch/arm64/lib/strlen.S | 247 ++++++++++++------
arch/arm64/lib/strncmp.S | 363 ++++++++++++--------------
arch/arm64/mm/extable.c | 13 +-
arch/arm64/mm/fault.c | 2 +-
18 files changed, 2073 insertions(+), 1119 deletions(-)
create mode 100644 arch/arm64/lib/copy_template_user.S
create mode 100644 arch/arm64/lib/copy_user_fixup.S
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 01/13] arm64: Allow passing fault address to fixup handlers
From: Oliver Swede @ 2020-05-14 14:32 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas; +Cc: Robin Murphy, linux-kernel, linux-arm-kernel
In-Reply-To: <20200514143227.605-1-oli.swede@arm.com>
From: Sam Tebbs <sam.tebbs@arm.com>
Extend fixup_exception() to optionally place the faulting address in a
register when returning to a fixup handler. Since A64 instructions must
be 4-byte-aligned, we can mimic the IA-64 implementation and encode a
flag in the lower bits of the offset field to indicate handlers which
expect an address. This will allow us to use more efficient offset
addressing modes in usercopy routines, rather than updating the base
register on every access just for the sake of inferring where a fault
occurred in order to compute the return value upon failure.
The choice of x15 is somewhat arbitrary, but with the consideration that
as the highest-numbered temporary register with no possible 'special'
role in the ABI, it is most likely not used by hand-written assembly
code, and thus a minimally-invasive option for imported routines.
Signed-off-by: Sam Tebbs <sam.tebbs@arm.com>
[ rm: split into separate patch, use UL(), expand commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Oliver Swede <oli.swede@arm.com>
---
arch/arm64/include/asm/assembler.h | 9 +++++++++
arch/arm64/include/asm/extable.h | 10 +++++++++-
arch/arm64/mm/extable.c | 13 +++++++++----
arch/arm64/mm/fault.c | 2 +-
4 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index 0bff325117b4..7017aeb4b29a 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -18,6 +18,7 @@
#include <asm/cpufeature.h>
#include <asm/cputype.h>
#include <asm/debug-monitors.h>
+#include <asm/extable.h>
#include <asm/page.h>
#include <asm/pgtable-hwdef.h>
#include <asm/ptrace.h>
@@ -129,6 +130,14 @@ alternative_endif
.popsection
.endm
+/*
+ * Emit an entry into the exception table.
+ * The fixup handler will receive the faulting address in x15
+ */
+ .macro _asm_extable_faultaddr, from, to
+ _asm_extable \from, \to + FIXUP_WITH_ADDR
+ .endm
+
#define USER(l, x...) \
9999: x; \
_asm_extable 9999b, l
diff --git a/arch/arm64/include/asm/extable.h b/arch/arm64/include/asm/extable.h
index 56a4f68b262e..4c4955f2bb44 100644
--- a/arch/arm64/include/asm/extable.h
+++ b/arch/arm64/include/asm/extable.h
@@ -2,6 +2,12 @@
#ifndef __ASM_EXTABLE_H
#define __ASM_EXTABLE_H
+#include <linux/const.h>
+
+#define FIXUP_WITH_ADDR UL(1)
+
+#ifndef __ASSEMBLY__
+
/*
* The exception table consists of pairs of relative offsets: the first
* is the relative offset to an instruction that is allowed to fault,
@@ -22,5 +28,7 @@ struct exception_table_entry
#define ARCH_HAS_RELATIVE_EXTABLE
-extern int fixup_exception(struct pt_regs *regs);
+extern int fixup_exception(struct pt_regs *regs, unsigned long addr);
+
+#endif
#endif
diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c
index 81e694af5f8c..e6578c2814b5 100644
--- a/arch/arm64/mm/extable.c
+++ b/arch/arm64/mm/extable.c
@@ -6,13 +6,18 @@
#include <linux/extable.h>
#include <linux/uaccess.h>
-int fixup_exception(struct pt_regs *regs)
+int fixup_exception(struct pt_regs *regs, unsigned long addr)
{
const struct exception_table_entry *fixup;
fixup = search_exception_tables(instruction_pointer(regs));
- if (fixup)
- regs->pc = (unsigned long)&fixup->fixup + fixup->fixup;
-
+ if (fixup) {
+ unsigned long offset = fixup->fixup;
+ if (offset & FIXUP_WITH_ADDR) {
+ regs->regs[15] = addr;
+ offset &= ~FIXUP_WITH_ADDR;
+ }
+ regs->pc = (unsigned long)&fixup->fixup + offset;
+ }
return fixup != NULL;
}
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index c9cedc0432d2..2c648343ab40 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -297,7 +297,7 @@ static void __do_kernel_fault(unsigned long addr, unsigned int esr,
* Are we prepared to handle this kernel fault?
* We are almost certainly not prepared to handle instruction faults.
*/
- if (!is_el1_instruction_abort(esr) && fixup_exception(regs))
+ if (!is_el1_instruction_abort(esr) && fixup_exception(regs, addr))
return;
if (WARN_RATELIMIT(is_spurious_el1_translation_fault(addr, esr, regs),
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 03/13] arm64: Import latest version of Cortex Strings' memcmp
From: Oliver Swede @ 2020-05-14 14:32 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas; +Cc: Robin Murphy, linux-kernel, linux-arm-kernel
In-Reply-To: <20200514143227.605-1-oli.swede@arm.com>
From: Sam Tebbs <sam.tebbs@arm.com>
Import the latest version of Cortex Strings' memcmp function.
The upstream source is src/aarch64/memcmp.S as of commit f77e4c932b4f
in https://git.linaro.org/toolchain/cortex-strings.git.
Signed-off-by: Sam Tebbs <sam.tebbs@arm.com>
[ rm: update attribution, expand commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Oliver Swede <oli.swede@arm.com>
---
arch/arm64/lib/memcmp.S | 333 ++++++++++++++--------------------------
1 file changed, 117 insertions(+), 216 deletions(-)
diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
index c0671e793ea9..580dd0b12ccb 100644
--- a/arch/arm64/lib/memcmp.S
+++ b/arch/arm64/lib/memcmp.S
@@ -1,13 +1,12 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
- * Copyright (C) 2013 ARM Ltd.
- * Copyright (C) 2013 Linaro.
+ * Copyright (c) 2013, 2018 Linaro Limited. All rights reserved.
+ * Copyright (c) 2017 ARM Ltd. All rights reserved.
*
- * This code is based on glibc cortex strings work originally authored by Linaro
- * be found @
+ * This code is based on glibc Cortex Strings work originally authored by
+ * Linaro, found at:
*
- * http://bazaar.launchpad.net/~linaro-toolchain-dev/cortex-strings/trunk/
- * files/head:/src/aarch64/
+ * https://git.linaro.org/toolchain/cortex-strings.git
*/
#include <linux/linkage.h>
@@ -25,223 +24,125 @@
* x0 - a compare result, maybe less than, equal to, or greater than ZERO
*/
+#define L(l) .L ## l
+
/* Parameters and result. */
-src1 .req x0
-src2 .req x1
-limit .req x2
-result .req x0
+#define src1 x0
+#define src2 x1
+#define limit x2
+#define result w0
/* Internal variables. */
-data1 .req x3
-data1w .req w3
-data2 .req x4
-data2w .req w4
-has_nul .req x5
-diff .req x6
-endloop .req x7
-tmp1 .req x8
-tmp2 .req x9
-tmp3 .req x10
-pos .req x11
-limit_wd .req x12
-mask .req x13
+#define data1 x3
+#define data1w w3
+#define data1h x4
+#define data2 x5
+#define data2w w5
+#define data2h x6
+#define tmp1 x7
+#define tmp2 x8
SYM_FUNC_START_WEAK_PI(memcmp)
- cbz limit, .Lret0
- eor tmp1, src1, src2
- tst tmp1, #7
- b.ne .Lmisaligned8
- ands tmp1, src1, #7
- b.ne .Lmutual_align
- sub limit_wd, limit, #1 /* limit != 0, so no underflow. */
- lsr limit_wd, limit_wd, #3 /* Convert to Dwords. */
- /*
- * The input source addresses are at alignment boundary.
- * Directly compare eight bytes each time.
- */
-.Lloop_aligned:
- ldr data1, [src1], #8
- ldr data2, [src2], #8
-.Lstart_realigned:
- subs limit_wd, limit_wd, #1
- eor diff, data1, data2 /* Non-zero if differences found. */
- csinv endloop, diff, xzr, cs /* Last Dword or differences. */
- cbz endloop, .Lloop_aligned
-
- /* Not reached the limit, must have found a diff. */
- tbz limit_wd, #63, .Lnot_limit
-
- /* Limit % 8 == 0 => the diff is in the last 8 bytes. */
- ands limit, limit, #7
- b.eq .Lnot_limit
- /*
- * The remained bytes less than 8. It is needed to extract valid data
- * from last eight bytes of the intended memory range.
- */
- lsl limit, limit, #3 /* bytes-> bits. */
- mov mask, #~0
-CPU_BE( lsr mask, mask, limit )
-CPU_LE( lsl mask, mask, limit )
- bic data1, data1, mask
- bic data2, data2, mask
-
- orr diff, diff, mask
- b .Lnot_limit
-
-.Lmutual_align:
- /*
- * Sources are mutually aligned, but are not currently at an
- * alignment boundary. Round down the addresses and then mask off
- * the bytes that precede the start point.
- */
- bic src1, src1, #7
- bic src2, src2, #7
- ldr data1, [src1], #8
- ldr data2, [src2], #8
- /*
- * We can not add limit with alignment offset(tmp1) here. Since the
- * addition probably make the limit overflown.
- */
- sub limit_wd, limit, #1/*limit != 0, so no underflow.*/
- and tmp3, limit_wd, #7
- lsr limit_wd, limit_wd, #3
- add tmp3, tmp3, tmp1
- add limit_wd, limit_wd, tmp3, lsr #3
- add limit, limit, tmp1/* Adjust the limit for the extra. */
-
- lsl tmp1, tmp1, #3/* Bytes beyond alignment -> bits.*/
- neg tmp1, tmp1/* Bits to alignment -64. */
- mov tmp2, #~0
- /*mask off the non-intended bytes before the start address.*/
-CPU_BE( lsl tmp2, tmp2, tmp1 )/*Big-endian.Early bytes are at MSB*/
- /* Little-endian. Early bytes are at LSB. */
-CPU_LE( lsr tmp2, tmp2, tmp1 )
-
- orr data1, data1, tmp2
- orr data2, data2, tmp2
- b .Lstart_realigned
-
- /*src1 and src2 have different alignment offset.*/
-.Lmisaligned8:
- cmp limit, #8
- b.lo .Ltiny8proc /*limit < 8: compare byte by byte*/
-
- and tmp1, src1, #7
- neg tmp1, tmp1
- add tmp1, tmp1, #8/*valid length in the first 8 bytes of src1*/
- and tmp2, src2, #7
- neg tmp2, tmp2
- add tmp2, tmp2, #8/*valid length in the first 8 bytes of src2*/
- subs tmp3, tmp1, tmp2
- csel pos, tmp1, tmp2, hi /*Choose the maximum.*/
-
- sub limit, limit, pos
- /*compare the proceeding bytes in the first 8 byte segment.*/
-.Ltinycmp:
- ldrb data1w, [src1], #1
- ldrb data2w, [src2], #1
- subs pos, pos, #1
- ccmp data1w, data2w, #0, ne /* NZCV = 0b0000. */
- b.eq .Ltinycmp
- cbnz pos, 1f /*diff occurred before the last byte.*/
- cmp data1w, data2w
- b.eq .Lstart_align
-1:
- sub result, data1, data2
- ret
-
-.Lstart_align:
- lsr limit_wd, limit, #3
- cbz limit_wd, .Lremain8
-
- ands xzr, src1, #7
- b.eq .Lrecal_offset
- /*process more leading bytes to make src1 aligned...*/
- add src1, src1, tmp3 /*backwards src1 to alignment boundary*/
- add src2, src2, tmp3
- sub limit, limit, tmp3
- lsr limit_wd, limit, #3
- cbz limit_wd, .Lremain8
- /*load 8 bytes from aligned SRC1..*/
- ldr data1, [src1], #8
- ldr data2, [src2], #8
-
- subs limit_wd, limit_wd, #1
- eor diff, data1, data2 /*Non-zero if differences found.*/
- csinv endloop, diff, xzr, ne
- cbnz endloop, .Lunequal_proc
- /*How far is the current SRC2 from the alignment boundary...*/
- and tmp3, tmp3, #7
-
-.Lrecal_offset:/*src1 is aligned now..*/
- neg pos, tmp3
-.Lloopcmp_proc:
- /*
- * Divide the eight bytes into two parts. First,backwards the src2
- * to an alignment boundary,load eight bytes and compare from
- * the SRC2 alignment boundary. If all 8 bytes are equal,then start
- * the second part's comparison. Otherwise finish the comparison.
- * This special handle can garantee all the accesses are in the
- * thread/task space in avoid to overrange access.
- */
- ldr data1, [src1,pos]
- ldr data2, [src2,pos]
- eor diff, data1, data2 /* Non-zero if differences found. */
- cbnz diff, .Lnot_limit
-
- /*The second part process*/
- ldr data1, [src1], #8
- ldr data2, [src2], #8
- eor diff, data1, data2 /* Non-zero if differences found. */
- subs limit_wd, limit_wd, #1
- csinv endloop, diff, xzr, ne/*if limit_wd is 0,will finish the cmp*/
- cbz endloop, .Lloopcmp_proc
-.Lunequal_proc:
- cbz diff, .Lremain8
-
-/* There is difference occurred in the latest comparison. */
-.Lnot_limit:
-/*
-* For little endian,reverse the low significant equal bits into MSB,then
-* following CLZ can find how many equal bits exist.
-*/
-CPU_LE( rev diff, diff )
-CPU_LE( rev data1, data1 )
-CPU_LE( rev data2, data2 )
-
- /*
- * The MS-non-zero bit of DIFF marks either the first bit
- * that is different, or the end of the significant data.
- * Shifting left now will bring the critical information into the
- * top bits.
- */
- clz pos, diff
- lsl data1, data1, pos
- lsl data2, data2, pos
- /*
- * We need to zero-extend (char is unsigned) the value and then
- * perform a signed subtraction.
- */
- lsr data1, data1, #56
- sub result, data1, data2, lsr #56
+ subs limit, limit, 8
+ b.lo L(less8)
+
+ ldr data1, [src1], 8
+ ldr data2, [src2], 8
+ cmp data1, data2
+ b.ne L(return)
+
+ subs limit, limit, 8
+ b.gt L(more16)
+
+ ldr data1, [src1, limit]
+ ldr data2, [src2, limit]
+ b L(return)
+
+L(more16):
+ ldr data1, [src1], 8
+ ldr data2, [src2], 8
+ cmp data1, data2
+ bne L(return)
+
+ /* Jump directly to comparing the last 16 bytes for 32 byte (or less)
+ strings. */
+ subs limit, limit, 16
+ b.ls L(last_bytes)
+
+ /* We overlap loads between 0-32 bytes at either side of SRC1 when we
+ try to align, so limit it only to strings larger than 128 bytes. */
+ cmp limit, 96
+ b.ls L(loop16)
+
+ /* Align src1 and adjust src2 with bytes not yet done. */
+ and tmp1, src1, 15
+ add limit, limit, tmp1
+ sub src1, src1, tmp1
+ sub src2, src2, tmp1
+
+ /* Loop performing 16 bytes per iteration using aligned src1.
+ Limit is pre-decremented by 16 and must be larger than zero.
+ Exit if <= 16 bytes left to do or if the data is not equal. */
+ .p2align 4
+L(loop16):
+ ldp data1, data1h, [src1], 16
+ ldp data2, data2h, [src2], 16
+ subs limit, limit, 16
+ ccmp data1, data2, 0, hi
+ ccmp data1h, data2h, 0, eq
+ b.eq L(loop16)
+
+ cmp data1, data2
+ bne L(return)
+ mov data1, data1h
+ mov data2, data2h
+ cmp data1, data2
+ bne L(return)
+
+ /* Compare last 1-16 bytes using unaligned access. */
+L(last_bytes):
+ add src1, src1, limit
+ add src2, src2, limit
+ ldp data1, data1h, [src1]
+ ldp data2, data2h, [src2]
+ cmp data1, data2
+ bne L(return)
+ mov data1, data1h
+ mov data2, data2h
+ cmp data1, data2
+
+ /* Compare data bytes and set return value to 0, -1 or 1. */
+L(return):
+#ifndef __AARCH64EB__
+ rev data1, data1
+ rev data2, data2
+#endif
+ cmp data1, data2
+L(ret_eq):
+ cset result, ne
+ cneg result, result, lo
ret
-.Lremain8:
- /* Limit % 8 == 0 =>. all data are equal.*/
- ands limit, limit, #7
- b.eq .Lret0
-
-.Ltiny8proc:
- ldrb data1w, [src1], #1
- ldrb data2w, [src2], #1
- subs limit, limit, #1
-
- ccmp data1w, data2w, #0, ne /* NZCV = 0b0000. */
- b.eq .Ltiny8proc
- sub result, data1, data2
- ret
-.Lret0:
- mov result, #0
+ .p2align 4
+ /* Compare up to 8 bytes. Limit is [-8..-1]. */
+L(less8):
+ adds limit, limit, 4
+ b.lo L(less4)
+ ldr data1w, [src1], 4
+ ldr data2w, [src2], 4
+ cmp data1w, data2w
+ b.ne L(return)
+ sub limit, limit, 4
+L(less4):
+ adds limit, limit, 4
+ beq L(ret_eq)
+L(byte_loop):
+ ldrb data1w, [src1], 1
+ ldrb data2w, [src2], 1
+ subs limit, limit, 1
+ ccmp data1w, data2w, 0, ne /* NZCV = 0b0000. */
+ b.eq L(byte_loop)
+ sub result, data1w, data2w
ret
SYM_FUNC_END_PI(memcmp)
EXPORT_SYMBOL_NOKASAN(memcmp)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 04/13] arm64: Import latest version of Cortex Strings' memmove
From: Oliver Swede @ 2020-05-14 14:32 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas; +Cc: Robin Murphy, linux-kernel, linux-arm-kernel
In-Reply-To: <20200514143227.605-1-oli.swede@arm.com>
From: Sam Tebbs <sam.tebbs@arm.com>
Import the latest version of Cortex Strings' memmove function.
The upstream source is src/aarch64/memmove.S as of commit 99b01ddb8e41
in https://git.linaro.org/toolchain/cortex-strings.git.
Signed-off-by: Sam Tebbs <sam.tebbs@arm.com>
[ rm: update attribution, expand commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Oliver Swede <oli.swede@arm.com>
---
arch/arm64/lib/memmove.S | 232 +++++++++++++--------------------------
1 file changed, 78 insertions(+), 154 deletions(-)
diff --git a/arch/arm64/lib/memmove.S b/arch/arm64/lib/memmove.S
index 02cda2e33bde..d0977d0ad745 100644
--- a/arch/arm64/lib/memmove.S
+++ b/arch/arm64/lib/memmove.S
@@ -1,13 +1,12 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
- * Copyright (C) 2013 ARM Ltd.
- * Copyright (C) 2013 Linaro.
+ * Copyright (c) 2013 Linaro Limited. All rights reserved.
+ * Copyright (c) 2015 ARM Ltd. All rights reserved.
*
- * This code is based on glibc cortex strings work originally authored by Linaro
- * be found @
+ * This code is based on glibc Cortex Strings work originally authored by
+ * Linaro, found at:
*
- * http://bazaar.launchpad.net/~linaro-toolchain-dev/cortex-strings/trunk/
- * files/head:/src/aarch64/
+ * https://git.linaro.org/toolchain/cortex-strings.git
*/
#include <linux/linkage.h>
@@ -25,165 +24,90 @@
* Returns:
* x0 - dest
*/
-dstin .req x0
-src .req x1
-count .req x2
-tmp1 .req x3
-tmp1w .req w3
-tmp2 .req x4
-tmp2w .req w4
-tmp3 .req x5
-tmp3w .req w5
-dst .req x6
+/* Parameters and result. */
+#define dstin x0
+#define src x1
+#define count x2
+#define srcend x3
+#define dstend x4
+#define tmp1 x5
+#define A_l x6
+#define A_h x7
+#define B_l x8
+#define B_h x9
+#define C_l x10
+#define C_h x11
+#define D_l x12
+#define D_h x13
+#define E_l count
+#define E_h tmp1
-A_l .req x7
-A_h .req x8
-B_l .req x9
-B_h .req x10
-C_l .req x11
-C_h .req x12
-D_l .req x13
-D_h .req x14
+/* All memmoves up to 96 bytes are done by memcpy as it supports overlaps.
+ Larger backwards copies are also handled by memcpy. The only remaining
+ case is forward large copies. The destination is aligned, and an
+ unrolled loop processes 64 bytes per iteration.
+*/
- .weak memmove
+ .weak memmove
SYM_FUNC_START_ALIAS(__memmove)
SYM_FUNC_START_PI(memmove)
- cmp dstin, src
- b.lo __memcpy
- add tmp1, src, count
- cmp dstin, tmp1
- b.hs __memcpy /* No overlap. */
+ sub tmp1, dstin, src
+ cmp count, 96
+ ccmp tmp1, count, 2, hi
+ b.hs __memcpy
- add dst, dstin, count
- add src, src, count
- cmp count, #16
- b.lo .Ltail15 /*probably non-alignment accesses.*/
+ cbz tmp1, 3f
+ add dstend, dstin, count
+ add srcend, src, count
- ands tmp2, src, #15 /* Bytes to reach alignment. */
- b.eq .LSrcAligned
- sub count, count, tmp2
- /*
- * process the aligned offset length to make the src aligned firstly.
- * those extra instructions' cost is acceptable. It also make the
- * coming accesses are based on aligned address.
- */
- tbz tmp2, #0, 1f
- ldrb tmp1w, [src, #-1]!
- strb tmp1w, [dst, #-1]!
-1:
- tbz tmp2, #1, 2f
- ldrh tmp1w, [src, #-2]!
- strh tmp1w, [dst, #-2]!
-2:
- tbz tmp2, #2, 3f
- ldr tmp1w, [src, #-4]!
- str tmp1w, [dst, #-4]!
-3:
- tbz tmp2, #3, .LSrcAligned
- ldr tmp1, [src, #-8]!
- str tmp1, [dst, #-8]!
-
-.LSrcAligned:
- cmp count, #64
- b.ge .Lcpy_over64
+ /* Align dstend to 16 byte alignment so that we don't cross cache line
+ boundaries on both loads and stores. There are at least 96 bytes
+ to copy, so copy 16 bytes unaligned and then align. The loop
+ copies 64 bytes per iteration and prefetches one iteration ahead. */
- /*
- * Deal with small copies quickly by dropping straight into the
- * exit block.
- */
-.Ltail63:
- /*
- * Copy up to 48 bytes of data. At this point we only need the
- * bottom 6 bits of count to be accurate.
- */
- ands tmp1, count, #0x30
- b.eq .Ltail15
- cmp tmp1w, #0x20
- b.eq 1f
- b.lt 2f
- ldp A_l, A_h, [src, #-16]!
- stp A_l, A_h, [dst, #-16]!
+ and tmp1, dstend, 15
+ ldp D_l, D_h, [srcend, -16]
+ sub srcend, srcend, tmp1
+ sub count, count, tmp1
+ ldp A_l, A_h, [srcend, -16]
+ stp D_l, D_h, [dstend, -16]
+ ldp B_l, B_h, [srcend, -32]
+ ldp C_l, C_h, [srcend, -48]
+ ldp D_l, D_h, [srcend, -64]!
+ sub dstend, dstend, tmp1
+ subs count, count, 128
+ b.ls 2f
+ nop
1:
- ldp A_l, A_h, [src, #-16]!
- stp A_l, A_h, [dst, #-16]!
-2:
- ldp A_l, A_h, [src, #-16]!
- stp A_l, A_h, [dst, #-16]!
+ stp A_l, A_h, [dstend, -16]
+ ldp A_l, A_h, [srcend, -16]
+ stp B_l, B_h, [dstend, -32]
+ ldp B_l, B_h, [srcend, -32]
+ stp C_l, C_h, [dstend, -48]
+ ldp C_l, C_h, [srcend, -48]
+ stp D_l, D_h, [dstend, -64]!
+ ldp D_l, D_h, [srcend, -64]!
+ subs count, count, 64
+ b.hi 1b
-.Ltail15:
- tbz count, #3, 1f
- ldr tmp1, [src, #-8]!
- str tmp1, [dst, #-8]!
-1:
- tbz count, #2, 2f
- ldr tmp1w, [src, #-4]!
- str tmp1w, [dst, #-4]!
+ /* Write the last full set of 64 bytes. The remainder is at most 64
+ bytes, so it is safe to always copy 64 bytes from the start even if
+ there is just 1 byte left. */
2:
- tbz count, #1, 3f
- ldrh tmp1w, [src, #-2]!
- strh tmp1w, [dst, #-2]!
-3:
- tbz count, #0, .Lexitfunc
- ldrb tmp1w, [src, #-1]
- strb tmp1w, [dst, #-1]
-
-.Lexitfunc:
- ret
-
-.Lcpy_over64:
- subs count, count, #128
- b.ge .Lcpy_body_large
- /*
- * Less than 128 bytes to copy, so handle 64 bytes here and then jump
- * to the tail.
- */
- ldp A_l, A_h, [src, #-16]
- stp A_l, A_h, [dst, #-16]
- ldp B_l, B_h, [src, #-32]
- ldp C_l, C_h, [src, #-48]
- stp B_l, B_h, [dst, #-32]
- stp C_l, C_h, [dst, #-48]
- ldp D_l, D_h, [src, #-64]!
- stp D_l, D_h, [dst, #-64]!
-
- tst count, #0x3f
- b.ne .Ltail63
- ret
-
- /*
- * Critical loop. Start at a new cache line boundary. Assuming
- * 64 bytes per line this ensures the entire loop is in one line.
- */
- .p2align L1_CACHE_SHIFT
-.Lcpy_body_large:
- /* pre-load 64 bytes data. */
- ldp A_l, A_h, [src, #-16]
- ldp B_l, B_h, [src, #-32]
- ldp C_l, C_h, [src, #-48]
- ldp D_l, D_h, [src, #-64]!
-1:
- /*
- * interlace the load of next 64 bytes data block with store of the last
- * loaded 64 bytes data.
- */
- stp A_l, A_h, [dst, #-16]
- ldp A_l, A_h, [src, #-16]
- stp B_l, B_h, [dst, #-32]
- ldp B_l, B_h, [src, #-32]
- stp C_l, C_h, [dst, #-48]
- ldp C_l, C_h, [src, #-48]
- stp D_l, D_h, [dst, #-64]!
- ldp D_l, D_h, [src, #-64]!
- subs count, count, #64
- b.ge 1b
- stp A_l, A_h, [dst, #-16]
- stp B_l, B_h, [dst, #-32]
- stp C_l, C_h, [dst, #-48]
- stp D_l, D_h, [dst, #-64]!
+ ldp E_l, E_h, [src, 48]
+ stp A_l, A_h, [dstend, -16]
+ ldp A_l, A_h, [src, 32]
+ stp B_l, B_h, [dstend, -32]
+ ldp B_l, B_h, [src, 16]
+ stp C_l, C_h, [dstend, -48]
+ ldp C_l, C_h, [src]
+ stp D_l, D_h, [dstend, -64]
+ stp E_l, E_h, [dstin, 48]
+ stp A_l, A_h, [dstin, 32]
+ stp B_l, B_h, [dstin, 16]
+ stp C_l, C_h, [dstin]
+3: ret
- tst count, #0x3f
- b.ne .Ltail63
- ret
SYM_FUNC_END_PI(memmove)
EXPORT_SYMBOL(memmove)
SYM_FUNC_END_ALIAS(__memmove)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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