Centos-kernel-stream-9/drivers/misc/sram.h

65 lines
1.2 KiB
C
Raw Permalink Normal View History

/* SPDX-License-Identifier: GPL-2.0-only */
/*
* Defines for the SRAM driver
*/
#ifndef __SRAM_H
#define __SRAM_H
misc: sram: Only map reserved areas in Tegra SYSRAM Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2129151 Tested: This set has been tested on NXP imx8m and NVIDIA Jetson Xavier NX with simple boot tests, along with the CI loop. NB: this patch set alone is insufficient to boot Orin. commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae Author: Mikko Perttunen <mperttunen@nvidia.com> Date: Thu Jul 15 13:34:23 2021 +0300 misc: sram: Only map reserved areas in Tegra SYSRAM On Tegra186 and later, a portion of the SYSRAM may be reserved for use by TZ. Non-TZ memory accesses to this portion, including speculative accesses, trigger SErrors that bring down the system. This does also happen in practice occasionally (due to speculative accesses). To fix the issue, add a flag to the SRAM driver to only map the device tree-specified reserved areas depending on a flag set based on the compatibility string. This would not affect non-Tegra systems that rely on the entire thing being memory mapped. If 64K pages are being used, we cannot exactly map the 4K regions that are placed in SYSRAM - ioremap code instead aligns to closest 64K pages. However, since in practice the non-accessible memory area is 64K aligned, these mappings do not overlap with the non-accessible memory area and things work out. Reviewed-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://lore.kernel.org/r/20210715103423.1811101-1-mperttunen@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-11-16 00:35:41 +00:00
struct sram_config {
int (*init)(void);
bool map_only_reserved;
};
struct sram_partition {
void __iomem *base;
struct gen_pool *pool;
struct bin_attribute battr;
struct mutex lock;
struct list_head list;
};
struct sram_dev {
misc: sram: Only map reserved areas in Tegra SYSRAM Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2129151 Tested: This set has been tested on NXP imx8m and NVIDIA Jetson Xavier NX with simple boot tests, along with the CI loop. NB: this patch set alone is insufficient to boot Orin. commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae Author: Mikko Perttunen <mperttunen@nvidia.com> Date: Thu Jul 15 13:34:23 2021 +0300 misc: sram: Only map reserved areas in Tegra SYSRAM On Tegra186 and later, a portion of the SYSRAM may be reserved for use by TZ. Non-TZ memory accesses to this portion, including speculative accesses, trigger SErrors that bring down the system. This does also happen in practice occasionally (due to speculative accesses). To fix the issue, add a flag to the SRAM driver to only map the device tree-specified reserved areas depending on a flag set based on the compatibility string. This would not affect non-Tegra systems that rely on the entire thing being memory mapped. If 64K pages are being used, we cannot exactly map the 4K regions that are placed in SYSRAM - ioremap code instead aligns to closest 64K pages. However, since in practice the non-accessible memory area is 64K aligned, these mappings do not overlap with the non-accessible memory area and things work out. Reviewed-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://lore.kernel.org/r/20210715103423.1811101-1-mperttunen@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-11-16 00:35:41 +00:00
const struct sram_config *config;
struct device *dev;
void __iomem *virt_base;
misc: sram: Only map reserved areas in Tegra SYSRAM Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2129151 Tested: This set has been tested on NXP imx8m and NVIDIA Jetson Xavier NX with simple boot tests, along with the CI loop. NB: this patch set alone is insufficient to boot Orin. commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae Author: Mikko Perttunen <mperttunen@nvidia.com> Date: Thu Jul 15 13:34:23 2021 +0300 misc: sram: Only map reserved areas in Tegra SYSRAM On Tegra186 and later, a portion of the SYSRAM may be reserved for use by TZ. Non-TZ memory accesses to this portion, including speculative accesses, trigger SErrors that bring down the system. This does also happen in practice occasionally (due to speculative accesses). To fix the issue, add a flag to the SRAM driver to only map the device tree-specified reserved areas depending on a flag set based on the compatibility string. This would not affect non-Tegra systems that rely on the entire thing being memory mapped. If 64K pages are being used, we cannot exactly map the 4K regions that are placed in SYSRAM - ioremap code instead aligns to closest 64K pages. However, since in practice the non-accessible memory area is 64K aligned, these mappings do not overlap with the non-accessible memory area and things work out. Reviewed-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://lore.kernel.org/r/20210715103423.1811101-1-mperttunen@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-11-16 00:35:41 +00:00
bool no_memory_wc;
struct gen_pool *pool;
struct clk *clk;
struct sram_partition *partition;
u32 partitions;
};
struct sram_reserve {
struct list_head list;
u32 start;
u32 size;
misc: sram: Only map reserved areas in Tegra SYSRAM Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2129151 Tested: This set has been tested on NXP imx8m and NVIDIA Jetson Xavier NX with simple boot tests, along with the CI loop. NB: this patch set alone is insufficient to boot Orin. commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae Author: Mikko Perttunen <mperttunen@nvidia.com> Date: Thu Jul 15 13:34:23 2021 +0300 misc: sram: Only map reserved areas in Tegra SYSRAM On Tegra186 and later, a portion of the SYSRAM may be reserved for use by TZ. Non-TZ memory accesses to this portion, including speculative accesses, trigger SErrors that bring down the system. This does also happen in practice occasionally (due to speculative accesses). To fix the issue, add a flag to the SRAM driver to only map the device tree-specified reserved areas depending on a flag set based on the compatibility string. This would not affect non-Tegra systems that rely on the entire thing being memory mapped. If 64K pages are being used, we cannot exactly map the 4K regions that are placed in SYSRAM - ioremap code instead aligns to closest 64K pages. However, since in practice the non-accessible memory area is 64K aligned, these mappings do not overlap with the non-accessible memory area and things work out. Reviewed-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://lore.kernel.org/r/20210715103423.1811101-1-mperttunen@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae) Signed-off-by: Al Stone <ahs3@redhat.com>
2022-11-16 00:35:41 +00:00
struct resource res;
bool export;
bool pool;
bool protect_exec;
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 20:52:19 +00: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 */
#endif /* __SRAM_H */