2019-05-19 21:51:31 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2013-04-30 07:17:12 +08:00
|
|
|
/*
|
|
|
|
* Generic on-chip SRAM allocation driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Philipp Zabel, Pengutronix
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/clk.h>
|
2016-09-22 06:09:38 +08:00
|
|
|
#include <linux/delay.h>
|
2015-06-01 20:30:00 +08:00
|
|
|
#include <linux/genalloc.h>
|
2013-04-30 07:17:12 +08:00
|
|
|
#include <linux/io.h>
|
2014-02-25 19:46:34 +08:00
|
|
|
#include <linux/list_sort.h>
|
2023-07-18 22:31:01 +08:00
|
|
|
#include <linux/of.h>
|
2015-06-01 20:30:00 +08:00
|
|
|
#include <linux/of_address.h>
|
2013-04-30 07:17:12 +08:00
|
|
|
#include <linux/platform_device.h>
|
2016-09-22 06:09:38 +08:00
|
|
|
#include <linux/regmap.h>
|
2013-04-30 07:17:12 +08:00
|
|
|
#include <linux/slab.h>
|
2016-09-22 06:09:38 +08:00
|
|
|
#include <linux/mfd/syscon.h>
|
|
|
|
#include <soc/at91/atmel-secumod.h>
|
2013-04-30 07:17:12 +08:00
|
|
|
|
2017-01-13 04:52:18 +08:00
|
|
|
#include "sram.h"
|
2015-06-01 20:29:58 +08:00
|
|
|
|
2017-01-13 04:52:18 +08:00
|
|
|
#define SRAM_GRANULARITY 32
|
2014-02-25 19:46:34 +08:00
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
static ssize_t sram_read(struct file *filp, struct kobject *kobj,
|
|
|
|
struct bin_attribute *attr,
|
|
|
|
char *buf, loff_t pos, size_t count)
|
|
|
|
{
|
|
|
|
struct sram_partition *part;
|
|
|
|
|
|
|
|
part = container_of(attr, struct sram_partition, battr);
|
|
|
|
|
|
|
|
mutex_lock(&part->lock);
|
2015-10-19 01:57:09 +08:00
|
|
|
memcpy_fromio(buf, part->base + pos, count);
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
mutex_unlock(&part->lock);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t sram_write(struct file *filp, struct kobject *kobj,
|
|
|
|
struct bin_attribute *attr,
|
|
|
|
char *buf, loff_t pos, size_t count)
|
|
|
|
{
|
|
|
|
struct sram_partition *part;
|
|
|
|
|
|
|
|
part = container_of(attr, struct sram_partition, battr);
|
|
|
|
|
|
|
|
mutex_lock(&part->lock);
|
2015-10-19 01:57:09 +08:00
|
|
|
memcpy_toio(part->base + pos, buf, count);
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
mutex_unlock(&part->lock);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_add_pool(struct sram_dev *sram, struct sram_reserve *block,
|
|
|
|
phys_addr_t start, struct sram_partition *part)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
part->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
|
|
|
|
NUMA_NO_NODE, block->label);
|
|
|
|
if (IS_ERR(part->pool))
|
|
|
|
return PTR_ERR(part->pool);
|
|
|
|
|
|
|
|
ret = gen_pool_add_virt(part->pool, (unsigned long)part->base, start,
|
|
|
|
block->size, NUMA_NO_NODE);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(sram->dev, "failed to register subpool: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_add_export(struct sram_dev *sram, struct sram_reserve *block,
|
|
|
|
phys_addr_t start, struct sram_partition *part)
|
|
|
|
{
|
|
|
|
sysfs_bin_attr_init(&part->battr);
|
|
|
|
part->battr.attr.name = devm_kasprintf(sram->dev, GFP_KERNEL,
|
|
|
|
"%llx.sram",
|
|
|
|
(unsigned long long)start);
|
|
|
|
if (!part->battr.attr.name)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
part->battr.attr.mode = S_IRUSR | S_IWUSR;
|
|
|
|
part->battr.read = sram_read;
|
|
|
|
part->battr.write = sram_write;
|
|
|
|
part->battr.size = block->size;
|
|
|
|
|
|
|
|
return device_create_bin_file(sram->dev, &part->battr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_add_partition(struct sram_dev *sram, struct sram_reserve *block,
|
|
|
|
phys_addr_t start)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct sram_partition *part = &sram->partition[sram->partitions];
|
|
|
|
|
|
|
|
mutex_init(&part->lock);
|
2021-07-15 18:34:23 +08:00
|
|
|
|
|
|
|
if (sram->config && sram->config->map_only_reserved) {
|
|
|
|
void __iomem *virt_base;
|
|
|
|
|
|
|
|
if (sram->no_memory_wc)
|
|
|
|
virt_base = devm_ioremap_resource(sram->dev, &block->res);
|
|
|
|
else
|
|
|
|
virt_base = devm_ioremap_resource_wc(sram->dev, &block->res);
|
|
|
|
|
|
|
|
if (IS_ERR(virt_base)) {
|
|
|
|
dev_err(sram->dev, "could not map SRAM at %pr\n", &block->res);
|
|
|
|
return PTR_ERR(virt_base);
|
|
|
|
}
|
|
|
|
|
|
|
|
part->base = virt_base;
|
|
|
|
} else {
|
|
|
|
part->base = sram->virt_base + block->start;
|
|
|
|
}
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
|
|
|
|
if (block->pool) {
|
|
|
|
ret = sram_add_pool(sram, block, start, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
if (block->export) {
|
|
|
|
ret = sram_add_export(sram, block, start, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2017-01-13 04:52:20 +08:00
|
|
|
if (block->protect_exec) {
|
|
|
|
ret = sram_check_protect_exec(sram, block, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = sram_add_pool(sram, block, start, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
sram_add_protect_exec(part);
|
|
|
|
}
|
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
sram->partitions++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void sram_free_partitions(struct sram_dev *sram)
|
|
|
|
{
|
|
|
|
struct sram_partition *part;
|
|
|
|
|
|
|
|
if (!sram->partitions)
|
|
|
|
return;
|
|
|
|
|
|
|
|
part = &sram->partition[sram->partitions - 1];
|
|
|
|
for (; sram->partitions; sram->partitions--, part--) {
|
|
|
|
if (part->battr.size)
|
|
|
|
device_remove_bin_file(sram->dev, &part->battr);
|
|
|
|
|
|
|
|
if (part->pool &&
|
|
|
|
gen_pool_avail(part->pool) < gen_pool_size(part->pool))
|
|
|
|
dev_err(sram->dev, "removed pool while SRAM allocated\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-04-09 02:28:34 +08:00
|
|
|
static int sram_reserve_cmp(void *priv, const struct list_head *a,
|
|
|
|
const struct list_head *b)
|
2014-02-25 19:46:34 +08:00
|
|
|
{
|
|
|
|
struct sram_reserve *ra = list_entry(a, struct sram_reserve, list);
|
|
|
|
struct sram_reserve *rb = list_entry(b, struct sram_reserve, list);
|
|
|
|
|
|
|
|
return ra->start - rb->start;
|
|
|
|
}
|
|
|
|
|
2015-06-01 20:29:59 +08:00
|
|
|
static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
|
2013-04-30 07:17:12 +08:00
|
|
|
{
|
2015-06-01 20:29:59 +08:00
|
|
|
struct device_node *np = sram->dev->of_node, *child;
|
2014-02-25 19:46:34 +08:00
|
|
|
unsigned long size, cur_start, cur_size;
|
|
|
|
struct sram_reserve *rblocks, *block;
|
|
|
|
struct list_head reserve_list;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
unsigned int nblocks, exports = 0;
|
|
|
|
const char *label;
|
2015-06-01 20:29:59 +08:00
|
|
|
int ret = 0;
|
2013-04-30 07:17:12 +08:00
|
|
|
|
2014-02-25 19:46:34 +08:00
|
|
|
INIT_LIST_HEAD(&reserve_list);
|
|
|
|
|
2013-06-10 22:43:53 +08:00
|
|
|
size = resource_size(res);
|
2013-04-30 07:17:12 +08:00
|
|
|
|
2014-02-25 19:46:34 +08:00
|
|
|
/*
|
|
|
|
* We need an additional block to mark the end of the memory region
|
|
|
|
* after the reserved blocks from the dt are processed.
|
|
|
|
*/
|
|
|
|
nblocks = (np) ? of_get_available_child_count(np) + 1 : 1;
|
treewide: kzalloc() -> kcalloc()
The kzalloc() function has a 2-factor argument form, kcalloc(). This
patch replaces cases of:
kzalloc(a * b, gfp)
with:
kcalloc(a * b, gfp)
as well as handling cases of:
kzalloc(a * b * c, gfp)
with:
kzalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kzalloc_array(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kzalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kzalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kzalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kzalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kzalloc
+ kcalloc
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kzalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kzalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kzalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kzalloc(sizeof(THING) * C2, ...)
|
kzalloc(sizeof(TYPE) * C2, ...)
|
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(C1 * C2, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * E2
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-13 05:03:40 +08:00
|
|
|
rblocks = kcalloc(nblocks, sizeof(*rblocks), GFP_KERNEL);
|
2015-06-01 20:29:54 +08:00
|
|
|
if (!rblocks)
|
|
|
|
return -ENOMEM;
|
2013-04-30 07:17:12 +08:00
|
|
|
|
2014-02-25 19:46:34 +08:00
|
|
|
block = &rblocks[0];
|
|
|
|
for_each_available_child_of_node(np, child) {
|
|
|
|
struct resource child_res;
|
|
|
|
|
|
|
|
ret = of_address_to_resource(child, 0, &child_res);
|
|
|
|
if (ret < 0) {
|
2015-06-01 20:29:58 +08:00
|
|
|
dev_err(sram->dev,
|
2017-07-19 05:43:15 +08:00
|
|
|
"could not get address for node %pOF\n",
|
|
|
|
child);
|
2014-02-25 19:46:34 +08:00
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (child_res.start < res->start || child_res.end > res->end) {
|
2015-06-01 20:29:58 +08:00
|
|
|
dev_err(sram->dev,
|
2017-07-19 05:43:15 +08:00
|
|
|
"reserved block %pOF outside the sram area\n",
|
|
|
|
child);
|
2014-02-25 19:46:34 +08:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
|
|
|
|
block->start = child_res.start - res->start;
|
|
|
|
block->size = resource_size(&child_res);
|
2021-07-15 18:34:23 +08:00
|
|
|
block->res = child_res;
|
2014-02-25 19:46:34 +08:00
|
|
|
list_add_tail(&block->list, &reserve_list);
|
|
|
|
|
2023-03-10 22:47:12 +08:00
|
|
|
block->export = of_property_read_bool(child, "export");
|
|
|
|
block->pool = of_property_read_bool(child, "pool");
|
|
|
|
block->protect_exec = of_property_read_bool(child, "protect-exec");
|
2017-01-13 04:52:20 +08:00
|
|
|
|
|
|
|
if ((block->export || block->pool || block->protect_exec) &&
|
|
|
|
block->size) {
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
exports++;
|
|
|
|
|
|
|
|
label = NULL;
|
|
|
|
ret = of_property_read_string(child, "label", &label);
|
|
|
|
if (ret && ret != -EINVAL) {
|
|
|
|
dev_err(sram->dev,
|
2017-07-19 05:43:15 +08:00
|
|
|
"%pOF has invalid label name\n",
|
|
|
|
child);
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
if (!label)
|
2023-04-21 05:17:35 +08:00
|
|
|
block->label = devm_kasprintf(sram->dev, GFP_KERNEL,
|
2023-06-22 15:45:20 +08:00
|
|
|
"%s", of_node_full_name(child));
|
2023-04-21 05:17:35 +08:00
|
|
|
else
|
|
|
|
block->label = devm_kstrdup(sram->dev,
|
|
|
|
label, GFP_KERNEL);
|
2016-12-03 17:29:28 +08:00
|
|
|
if (!block->label) {
|
|
|
|
ret = -ENOMEM;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
goto err_chunks;
|
2016-12-03 17:29:28 +08:00
|
|
|
}
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
|
|
|
|
dev_dbg(sram->dev, "found %sblock '%s' 0x%x-0x%x\n",
|
|
|
|
block->export ? "exported " : "", block->label,
|
|
|
|
block->start, block->start + block->size);
|
|
|
|
} else {
|
|
|
|
dev_dbg(sram->dev, "found reserved block 0x%x-0x%x\n",
|
|
|
|
block->start, block->start + block->size);
|
|
|
|
}
|
2014-02-25 19:46:34 +08:00
|
|
|
|
|
|
|
block++;
|
|
|
|
}
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
child = NULL;
|
2014-02-25 19:46:34 +08:00
|
|
|
|
|
|
|
/* the last chunk marks the end of the region */
|
|
|
|
rblocks[nblocks - 1].start = size;
|
|
|
|
rblocks[nblocks - 1].size = 0;
|
|
|
|
list_add_tail(&rblocks[nblocks - 1].list, &reserve_list);
|
|
|
|
|
|
|
|
list_sort(NULL, &reserve_list, sram_reserve_cmp);
|
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
if (exports) {
|
treewide: devm_kzalloc() -> devm_kcalloc()
The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc().
This patch replaces cases of:
devm_kzalloc(handle, a * b, gfp)
with:
devm_kcalloc(handle, a * b, gfp)
as well as handling cases of:
devm_kzalloc(handle, a * b * c, gfp)
with:
devm_kzalloc(handle, array3_size(a, b, c), gfp)
as it's slightly less ugly than:
devm_kcalloc(handle, array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
devm_kzalloc(handle, 4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
Some manual whitespace fixes were needed in this patch, as Coccinelle
really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...".
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
expression HANDLE;
type TYPE;
expression THING, E;
@@
(
devm_kzalloc(HANDLE,
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
devm_kzalloc(HANDLE,
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression HANDLE;
expression COUNT;
typedef u8;
typedef __u8;
@@
(
devm_kzalloc(HANDLE,
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(char) * COUNT
+ COUNT
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
expression HANDLE;
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
expression HANDLE;
identifier SIZE, COUNT;
@@
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression HANDLE;
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
devm_kzalloc(HANDLE,
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression HANDLE;
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
devm_kzalloc(HANDLE,
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
expression HANDLE;
identifier STRIDE, SIZE, COUNT;
@@
(
devm_kzalloc(HANDLE,
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
devm_kzalloc(HANDLE,
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression HANDLE;
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
|
devm_kzalloc(HANDLE,
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
devm_kzalloc(HANDLE,
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
devm_kzalloc(HANDLE,
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
devm_kzalloc(HANDLE,
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression HANDLE;
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
devm_kzalloc(HANDLE, sizeof(THING) * C2, ...)
|
devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...)
|
devm_kzalloc(HANDLE, C1 * C2 * C3, ...)
|
devm_kzalloc(HANDLE, C1 * C2, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- (E1) * E2
+ E1, E2
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- (E1) * (E2)
+ E1, E2
, ...)
|
- devm_kzalloc
+ devm_kcalloc
(HANDLE,
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-13 05:07:58 +08:00
|
|
|
sram->partition = devm_kcalloc(sram->dev,
|
|
|
|
exports, sizeof(*sram->partition),
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
GFP_KERNEL);
|
|
|
|
if (!sram->partition) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
}
|
2014-02-25 19:46:34 +08:00
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
cur_start = 0;
|
2014-02-25 19:46:34 +08:00
|
|
|
list_for_each_entry(block, &reserve_list, list) {
|
|
|
|
/* can only happen if sections overlap */
|
|
|
|
if (block->start < cur_start) {
|
2015-06-01 20:29:58 +08:00
|
|
|
dev_err(sram->dev,
|
2014-02-25 19:46:34 +08:00
|
|
|
"block at 0x%x starts after current offset 0x%lx\n",
|
|
|
|
block->start, cur_start);
|
|
|
|
ret = -EINVAL;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
sram_free_partitions(sram);
|
2014-02-25 19:46:34 +08:00
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
|
2017-01-13 04:52:20 +08:00
|
|
|
if ((block->export || block->pool || block->protect_exec) &&
|
|
|
|
block->size) {
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
ret = sram_add_partition(sram, block,
|
|
|
|
res->start + block->start);
|
|
|
|
if (ret) {
|
|
|
|
sram_free_partitions(sram);
|
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-25 19:46:34 +08:00
|
|
|
/* current start is in a reserved block, so continue after it */
|
|
|
|
if (block->start == cur_start) {
|
|
|
|
cur_start = block->start + block->size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* allocate the space between the current starting
|
|
|
|
* address and the following reserved block, or the
|
|
|
|
* end of the region.
|
|
|
|
*/
|
|
|
|
cur_size = block->start - cur_start;
|
|
|
|
|
2021-07-15 18:34:23 +08:00
|
|
|
if (sram->pool) {
|
|
|
|
dev_dbg(sram->dev, "adding chunk 0x%lx-0x%lx\n",
|
|
|
|
cur_start, cur_start + cur_size);
|
2015-06-01 20:29:58 +08:00
|
|
|
|
2021-07-15 18:34:23 +08:00
|
|
|
ret = gen_pool_add_virt(sram->pool,
|
|
|
|
(unsigned long)sram->virt_base + cur_start,
|
|
|
|
res->start + cur_start, cur_size, -1);
|
|
|
|
if (ret < 0) {
|
|
|
|
sram_free_partitions(sram);
|
|
|
|
goto err_chunks;
|
|
|
|
}
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
}
|
2014-02-25 19:46:34 +08:00
|
|
|
|
|
|
|
/* next allocation after this reserved block */
|
|
|
|
cur_start = block->start + block->size;
|
|
|
|
}
|
|
|
|
|
2018-09-16 21:08:45 +08:00
|
|
|
err_chunks:
|
|
|
|
of_node_put(child);
|
2014-02-25 19:46:34 +08:00
|
|
|
kfree(rblocks);
|
|
|
|
|
2015-06-01 20:29:59 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-09-22 06:09:38 +08:00
|
|
|
static int atmel_securam_wait(void)
|
|
|
|
{
|
|
|
|
struct regmap *regmap;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-secumod");
|
|
|
|
if (IS_ERR(regmap))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
return regmap_read_poll_timeout(regmap, AT91_SECUMOD_RAMRDY, val,
|
|
|
|
val & AT91_SECUMOD_RAMRDY_READY,
|
|
|
|
10000, 500000);
|
|
|
|
}
|
|
|
|
|
2021-07-15 18:34:23 +08:00
|
|
|
static const struct sram_config atmel_securam_config = {
|
|
|
|
.init = atmel_securam_wait,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SYSRAM contains areas that are not accessible by the
|
|
|
|
* kernel, such as the first 256K that is reserved for TZ.
|
|
|
|
* Accesses to those areas (including speculative accesses)
|
|
|
|
* trigger SErrors. As such we must map only the areas of
|
|
|
|
* SYSRAM specified in the device tree.
|
|
|
|
*/
|
|
|
|
static const struct sram_config tegra_sysram_config = {
|
|
|
|
.map_only_reserved = true,
|
|
|
|
};
|
|
|
|
|
2016-09-22 06:09:38 +08:00
|
|
|
static const struct of_device_id sram_dt_ids[] = {
|
|
|
|
{ .compatible = "mmio-sram" },
|
2021-07-15 18:34:23 +08:00
|
|
|
{ .compatible = "atmel,sama5d2-securam", .data = &atmel_securam_config },
|
|
|
|
{ .compatible = "nvidia,tegra186-sysram", .data = &tegra_sysram_config },
|
|
|
|
{ .compatible = "nvidia,tegra194-sysram", .data = &tegra_sysram_config },
|
2021-12-08 22:05:41 +08:00
|
|
|
{ .compatible = "nvidia,tegra234-sysram", .data = &tegra_sysram_config },
|
2016-09-22 06:09:38 +08:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2015-06-01 20:29:59 +08:00
|
|
|
static int sram_probe(struct platform_device *pdev)
|
|
|
|
{
|
2021-07-15 18:34:23 +08:00
|
|
|
const struct sram_config *config;
|
2015-06-01 20:29:59 +08:00
|
|
|
struct sram_dev *sram;
|
|
|
|
int ret;
|
2021-05-25 18:37:11 +08:00
|
|
|
struct resource *res;
|
2023-03-02 17:12:51 +08:00
|
|
|
struct clk *clk;
|
2021-07-15 18:34:23 +08:00
|
|
|
|
|
|
|
config = of_device_get_match_data(&pdev->dev);
|
2015-06-01 20:29:59 +08:00
|
|
|
|
|
|
|
sram = devm_kzalloc(&pdev->dev, sizeof(*sram), GFP_KERNEL);
|
|
|
|
if (!sram)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
sram->dev = &pdev->dev;
|
2021-07-15 18:34:23 +08:00
|
|
|
sram->no_memory_wc = of_property_read_bool(pdev->dev.of_node, "no-memory-wc");
|
|
|
|
sram->config = config;
|
|
|
|
|
|
|
|
if (!config || !config->map_only_reserved) {
|
|
|
|
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
if (sram->no_memory_wc)
|
|
|
|
sram->virt_base = devm_ioremap_resource(&pdev->dev, res);
|
|
|
|
else
|
|
|
|
sram->virt_base = devm_ioremap_resource_wc(&pdev->dev, res);
|
|
|
|
if (IS_ERR(sram->virt_base)) {
|
|
|
|
dev_err(&pdev->dev, "could not map SRAM registers\n");
|
|
|
|
return PTR_ERR(sram->virt_base);
|
|
|
|
}
|
2015-06-01 20:29:59 +08:00
|
|
|
|
2021-07-15 18:34:23 +08:00
|
|
|
sram->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
|
|
|
|
NUMA_NO_NODE, NULL);
|
|
|
|
if (IS_ERR(sram->pool))
|
|
|
|
return PTR_ERR(sram->pool);
|
2019-10-22 16:43:15 +08:00
|
|
|
}
|
2015-06-01 20:29:59 +08:00
|
|
|
|
2023-03-02 17:12:51 +08:00
|
|
|
clk = devm_clk_get_optional_enabled(sram->dev, NULL);
|
|
|
|
if (IS_ERR(clk))
|
|
|
|
return PTR_ERR(clk);
|
2015-06-01 20:29:54 +08:00
|
|
|
|
2019-10-22 16:43:15 +08:00
|
|
|
ret = sram_reserve_regions(sram,
|
|
|
|
platform_get_resource(pdev, IORESOURCE_MEM, 0));
|
2018-07-03 18:05:48 +08:00
|
|
|
if (ret)
|
2023-03-02 17:12:51 +08:00
|
|
|
return ret;
|
2018-07-03 18:05:48 +08:00
|
|
|
|
2013-04-30 07:17:12 +08:00
|
|
|
platform_set_drvdata(pdev, sram);
|
|
|
|
|
2021-07-15 18:34:23 +08:00
|
|
|
if (config && config->init) {
|
|
|
|
ret = config->init();
|
2016-09-22 06:09:38 +08:00
|
|
|
if (ret)
|
2018-07-03 18:05:48 +08:00
|
|
|
goto err_free_partitions;
|
2016-09-22 06:09:38 +08:00
|
|
|
}
|
|
|
|
|
2021-07-15 18:34:23 +08:00
|
|
|
if (sram->pool)
|
|
|
|
dev_dbg(sram->dev, "SRAM pool: %zu KiB @ 0x%p\n",
|
|
|
|
gen_pool_size(sram->pool) / 1024, sram->virt_base);
|
2013-04-30 07:17:12 +08:00
|
|
|
|
|
|
|
return 0;
|
2018-07-03 18:05:47 +08:00
|
|
|
|
2018-07-03 18:05:48 +08:00
|
|
|
err_free_partitions:
|
|
|
|
sram_free_partitions(sram);
|
2018-07-03 18:05:47 +08:00
|
|
|
|
|
|
|
return ret;
|
2013-04-30 07:17:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_remove(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct sram_dev *sram = platform_get_drvdata(pdev);
|
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-22 04:52:46 +08:00
|
|
|
sram_free_partitions(sram);
|
|
|
|
|
2021-07-15 18:34:23 +08:00
|
|
|
if (sram->pool && gen_pool_avail(sram->pool) < gen_pool_size(sram->pool))
|
2015-06-01 20:29:58 +08:00
|
|
|
dev_err(sram->dev, "removed while SRAM allocated\n");
|
2013-04-30 07:17:12 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct platform_driver sram_driver = {
|
|
|
|
.driver = {
|
|
|
|
.name = "sram",
|
2016-11-22 22:30:54 +08:00
|
|
|
.of_match_table = sram_dt_ids,
|
2013-04-30 07:17:12 +08:00
|
|
|
},
|
|
|
|
.probe = sram_probe,
|
|
|
|
.remove = sram_remove,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init sram_init(void)
|
|
|
|
{
|
|
|
|
return platform_driver_register(&sram_driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
postcore_initcall(sram_init);
|