| Message ID | 20230530233643.4044823-1-quic_bjorande@quicinc.com |
|---|---|
| Headers | show |
| Series | soc: qcom: rmtfs: Support dynamic allocation | expand |
On 31/05/2023 01:08, Caleb Connolly wrote: > > > On 31/05/2023 00:36, Bjorn Andersson wrote: >> In some configurations, the exact placement of the rmtfs shared memory >> region isn't so strict. The DeviceTree author can then choose to use the >> "size" property and rely on the OS for placement (in combination with >> "alloc-ranges", if desired). >> >> But on some platforms the rmtfs memory region may not be allocated >> adjacent to regions allocated by other clients. Add support for >> discarding the first and last 4k block in the region, if >> qcom,use-guard-pages is specified in DeviceTree. > > Oh nice! ... Bit eager on the enter key there >> >> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> >> --- >> >> Changes since v1: >> - Drop the dma_alloc_coherent() based approach and just add support for >> the guard pages. >> >> drivers/soc/qcom/rmtfs_mem.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/drivers/soc/qcom/rmtfs_mem.c b/drivers/soc/qcom/rmtfs_mem.c >> index f83811f51175..28238974d913 100644 >> --- a/drivers/soc/qcom/rmtfs_mem.c >> +++ b/drivers/soc/qcom/rmtfs_mem.c >> @@ -213,6 +213,16 @@ static int qcom_rmtfs_mem_probe(struct platform_device *pdev) >> goto put_device; >> } >> >> + /* >> + * If requested, discard the first and last 4k block in order to ensure >> + * that the rmtfs region isn't adjacent to other protected regions. >> + */ >> + if (of_property_present(node, "qcom,use-guard-pages")) { >> + rmtfs_mem->addr += SZ_4K; >> + rmtfs_mem->base += SZ_4K; >> + rmtfs_mem->size -= 2 * SZ_4K; >> + } >> + >> cdev_init(&rmtfs_mem->cdev, &qcom_rmtfs_mem_fops); >> rmtfs_mem->cdev.owner = THIS_MODULE; >> >
On Tue, May 30, 2023 at 04:36:42PM -0700, Bjorn Andersson wrote: > In some configurations, the exact placement of the rmtfs shared memory > region isn't so strict. The DeviceTree author can then choose to use the > "size" property and rely on the OS for placement (in combination with > "alloc-ranges", if desired). > > But on some platforms the rmtfs memory region may not be allocated > adjacent to regions allocated by other clients. Add support for > discarding the first and last 4k block in the region, if > qcom,use-guard-pages is specified in DeviceTree. > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > > Changes since v1: > - Drop the dma_alloc_coherent() based approach and just add support for > the guard pages. > > drivers/soc/qcom/rmtfs_mem.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/soc/qcom/rmtfs_mem.c b/drivers/soc/qcom/rmtfs_mem.c > index f83811f51175..28238974d913 100644 > --- a/drivers/soc/qcom/rmtfs_mem.c > +++ b/drivers/soc/qcom/rmtfs_mem.c > @@ -213,6 +213,16 @@ static int qcom_rmtfs_mem_probe(struct platform_device *pdev) > goto put_device; > } > > + /* > + * If requested, discard the first and last 4k block in order to ensure > + * that the rmtfs region isn't adjacent to other protected regions. > + */ > + if (of_property_present(node, "qcom,use-guard-pages")) { > + rmtfs_mem->addr += SZ_4K; > + rmtfs_mem->base += SZ_4K; > + rmtfs_mem->size -= 2 * SZ_4K; > + } It probably doesn't make a big difference in practice but I would say there is no need to even memremap() the guard pages. If you adjust the ->addr and ->size before the memremap() then you don't need to modify the ->base at all. Thanks, Stephan