kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-10-16 22:39:48 +00:00
Code Issues Releases Packages Activity
linux/drivers/misc/sram.c

456 lines
11 KiB
Raw Permalink Normal View History

misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: sram: sort and clean up included headers Most of the included header files are already included as dependencies. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:30:00 +03:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: sort and clean up included headers Most of the included header files are already included as dependencies. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:30:00 +03:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
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 14:52:18 -06:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
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 14:52:18 -06:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
misc: sram: partition base address belongs to __iomem space The change fixes a warning found by sparse: drivers/misc/sram.c:134:20: warning: incorrect type in assignment (different address spaces) drivers/misc/sram.c:134:20: expected void *base drivers/misc/sram.c:134:20: got void [noderef] <asn:2>* Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-18 20:57:09 +03: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-21 23:52:46 +03:00
misc: sram: partition base address belongs to __iomem space The change fixes a warning found by sparse: drivers/misc/sram.c:134:20: warning: incorrect type in assignment (different address spaces) drivers/misc/sram.c:134:20: expected void *base drivers/misc/sram.c:134:20: got void [noderef] <asn:2>* Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-10-18 20:57:09 +03: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-21 23:52:46 +03:00
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 14:52:20 -06: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
Misc: sram: Remove unneeded check Patch removes unneeded check for resource since devm_ioremap_resource do all for us. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-10 18:43:53 +04:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
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-12 14:03:40 -07:00
misc: sram: fix enabled clock leak on error path If devm_gen_pool_create() fails, the previously enabled sram->clk is not disabled on probe() exit. Because reserved block logic relies only on information from device tree, there is no need to get and enable device clock in advance, especially because not provided clock is not considered as an error, so it is safe to place devm_clk_get() at the end of probe(). No functional change. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:54 +03:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-18 16:43:15 -05:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-18 16:43:15 -05:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
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 14:52:20 -06: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-21 23:52:46 +03:00
misc: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-18 16:43:15 -05: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-21 23:52:46 +03:00
misc: set error code when devm_kstrdup fails In function sram_reserve_regions(), the value of return variable ret should be negative on failures. However, the value of ret may be 0 even if the call to devm_kstrdup() returns a NULL pointer. This patch explicitly assigns "-ENOMEM" to ret on the path that devm_kstrdup() fails. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188651 Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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-21 23:52:46 +03:00
misc: set error code when devm_kstrdup fails In function sram_reserve_regions(), the value of return variable ret should be negative on failures. However, the value of ret may be 0 even if the call to devm_kstrdup() returns a NULL pointer. This patch explicitly assigns "-ENOMEM" to ret on the path that devm_kstrdup() fails. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188651 Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
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-12 14:07:58 -07: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
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 14:52:20 -06: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03: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-21 23:52:46 +03:00
misc: sram: implement reserved sram areas This implements support for defining reserved areas as subnodes, to keep the genpool from using these. Suggested-by: Rob Herring <robherring2@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-25 12:46:34 +01:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
misc: sram: add optional ioremap without write combining Some SRAM users may require non-bufferable access to the memory, which is impossible, because devm_ioremap_wc() is used for setting sram->virt_base. This commit adds optional flag 'no-memory-wc', which allow to choose remap method, using DT property. Documentation is updated accordingly. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-14 09:38:56 +01:00
misc: sram: fix check of devm_ioremap*() return value Both devm_ioremap() and devm_ioremap_wc() functions return either a pointer to valid iomem region or NULL, check for IS_ERR() is improper and may result in oops on error path. Now on error -ENOMEM is returned. Fixes: 0ab163ad1ea0 ("misc: sram: switch to ioremap_wc from ioremap") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-23 04:52:45 +02:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
genalloc: add name arg to gen_pool_get() and devm_gen_pool_create() This change modifies gen_pool_get() and devm_gen_pool_create() client interfaces adding one more argument "name" of a gen_pool object. Due to implementation gen_pool_get() is capable to retrieve only one gen_pool associated with a device even if multiple gen_pools are created, fortunately right at the moment it is sufficient for the clients, hence provide NULL as a valid argument on both producer devm_gen_pool_create() and consumer gen_pool_get() sides. Because only one created gen_pool per device is addressable, explicitly add a restriction to devm_gen_pool_create() to create only one gen_pool per device, this implies two possible error codes returned by the function, account it on client side (only misc/sram). This completes client side changes related to genalloc updates. [akpm@linux-foundation.org: gen_pool_get() cleanup] Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-09-04 15:47:43 -07:00
misc: sram: move reserved block logic out of probe function No functional change, but now previously overloaded sram_probe() is greatly simplified and perceptible, reserved regions logic also has its own space. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:59 +03:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: sram: fix enabled clock leak on error path If devm_gen_pool_create() fails, the previously enabled sram->clk is not disabled on probe() exit. Because reserved block logic relies only on information from device tree, there is no need to get and enable device clock in advance, especially because not provided clock is not considered as an error, so it is safe to place devm_clk_get() at the end of probe(). No functional change. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:54 +03:00
misc: sram: enable clock before registering regions Make sure to enable the clock before registering regions and exporting partitions to user space at which point we must be prepared for I/O. Fixes: ee895ccdf776 ("misc: sram: fix enabled clock leak on error path") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-03 12:05:48 +02:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: sram: enable clock before registering regions Make sure to enable the clock before registering regions and exporting partitions to user space at which point we must be prepared for I/O. Fixes: ee895ccdf776 ("misc: sram: fix enabled clock leak on error path") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-03 12:05:48 +02:00
misc: sram: add Atmel securam support The Atmel secure SRAM is connected to a security module and may be erased automatically under certain conditions. For that reason, it is necessary to wait for the security module to flag that SRAM accesses are allowed before accessing it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22 00:09:38 +02:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: fix resource leaks in probe error path Make sure to disable clocks and deregister any exported partitions before returning on late probe errors. Note that since commit ee895ccdf776 ("misc: sram: fix enabled clock leak on error path"), partitions are deliberately exported before enabling the clock so we stick to that logic here. A follow up patch will address this. Fixes: 2ae2e28852f2 ("misc: sram: add Atmel securam support") Cc: stable <stable@vger.kernel.org> # 4.9 Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-03 12:05:47 +02:00
misc: sram: enable clock before registering regions Make sure to enable the clock before registering regions and exporting partitions to user space at which point we must be prepared for I/O. Fixes: ee895ccdf776 ("misc: sram: fix enabled clock leak on error path") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-03 12:05:48 +02:00
misc: sram: fix resource leaks in probe error path Make sure to disable clocks and deregister any exported partitions before returning on late probe errors. Note that since commit ee895ccdf776 ("misc: sram: fix enabled clock leak on error path"), partitions are deliberately exported before enabling the clock so we stick to that logic here. A follow up patch will address this. Fixes: 2ae2e28852f2 ("misc: sram: add Atmel securam support") Cc: stable <stable@vger.kernel.org> # 4.9 Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-03 12:05:47 +02:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07: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-21 23:52:46 +03:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: add private struct device and virt_base members No functional change, this is a preceding change to simplify separation of reserved partition handling logic from probe() function. Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-06-01 15:29:58 +03:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00
misc: sram: remove useless #ifdef A recent patch added a new function that is now unused whenever CONFIG_OF is disabled: drivers/misc/sram.c:342:12: error: 'atmel_securam_wait' defined but not used [-Werror=unused-function] There is actually no reason for the #ifdef, because the driver currently cannot be used in a meaningful way without CONFIG_OF, and there is no compile-time dependency. Removing that #ifdef and the respective of_match_ptr() avoids the warning and simplifies the driver slightly. Fixes: 2ae2e28852f2 ("misc: sram: add Atmel securam support") Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2016-11-22 15:30:54 +01:00
misc: generic on-chip SRAM allocation driver This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. [akpm@linux-foundation.org: fix Kconfig text, make sram_init static] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Michal Simek <monstr@monstr.eu> Cc: Dong Aisheng <dong.aisheng@linaro.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Huang Shijie <shijie8@gmail.com> Cc: Javier Martin <javier.martin@vista-silicon.com> Cc: Matt Porter <mporter@ti.com> Cc: Michal Simek <monstr@monstr.eu> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29 16:17:12 -07:00