redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity
remarkable-linux/drivers/misc/sram.h

59 lines
1.2 KiB
C
Raw Permalink Normal View History

misc: sram: Split sram data structures into local header In preparation of a coming file split of the sram driver, move the common data structures into a local header file that can be shared between files related to the sram driver. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 13:52:18 -07:00
/*
* Defines for the SRAM driver
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#ifndef __SRAM_H
#define __SRAM_H
struct sram_partition {
void __iomem *base;
struct gen_pool *pool;
struct bin_attribute battr;
struct mutex lock;
struct list_head list;
};
struct sram_dev {
struct device *dev;
void __iomem *virt_base;
struct gen_pool *pool;
struct clk *clk;
struct sram_partition *partition;
u32 partitions;
};
struct sram_reserve {
struct list_head list;
u32 start;
u32 size;
bool export;
bool pool;
misc: sram: Integrate protect-exec reserved sram area type Introduce a new "protect-exec" reserved sram area type which is makes use of the the existing functionality provided for the "pool" sram region type for use with the genalloc framework and with the added requirement that it be maintained as read-only and executable while allowing for an arbitrary number of drivers to share the space. This introduces a common way to maintain a region of sram as read-only and executable and also introduces a helper function, sram_exec_copy, which allows for copying data to this protected region while maintaining locking to avoid conflicts between multiple users of the same space. A region of memory that is marked with the "protect-exec" flag in the device tree also has the requirement of providing a page aligned block of memory so that the page attribute manipulation does not affect surrounding regions. Also, selectively enable this only for builds that support set_memory_* calls, for now just ARM, through the use of Kconfig. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 13:52:20 -07:00
bool protect_exec;
misc: sram: Split sram data structures into local header In preparation of a coming file split of the sram driver, move the common data structures into a local header file that can be shared between files related to the sram driver. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 13:52:18 -07:00
const char *label;
};
misc: sram: Introduce support code for protect-exec sram type Some platforms, like many ARM SoCs, require the ability to run code from on-chip memory like SRAM for tasks like reconfiguring the SDRAM controller or entering low-power sleep modes. In order to do this we must be able to allocate memory that the code can be copied to but then change the mapping to be read-only and executable so that no memory is both writable and executable at the same time to avoid opening any unneccesary security holes. By using the existing "pool" partition type that the SRAM driver allows we can create a memory space that will already be exposed by the genalloc framework to allow for allocating memory but we must extend this to meet the executable requirements. By making use of various set_memory_* APIs we can change the attributes of pages to make them writable for code upload but then read-only and executable when we want to actually run code. Because SRAM is a shared resource we need a centralized manager of these set memory calls. Because the SRAM driver itself is responsible for allocating the memory we can introduce a sram_copy_exec API for the driver that works like memcpy but also manages the page attributes and locking to allow multiple users of the same SRAM space to all copy their code over independent of other each before starting execution. It is maintained in a separate file from the core SRAM driver to allow it to be selectively built depending on whether or not a platform has the appropriate set_memory_* APIs. A future patch will integrate it with the core SRAM driver. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 13:52:19 -07:00
#ifdef CONFIG_SRAM_EXEC
int sram_check_protect_exec(struct sram_dev *sram, struct sram_reserve *block,
struct sram_partition *part);
int sram_add_protect_exec(struct sram_partition *part);
#else
static inline int sram_check_protect_exec(struct sram_dev *sram,
struct sram_reserve *block,
struct sram_partition *part)
{
return -ENODEV;
}
static inline int sram_add_protect_exec(struct sram_partition *part)
{
return -ENODEV;
}
#endif /* CONFIG_SRAM_EXEC */
misc: sram: Split sram data structures into local header In preparation of a coming file split of the sram driver, move the common data structures into a local header file that can be shared between files related to the sram driver. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-12 13:52:18 -07:00
#endif /* __SRAM_H */