lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 8 Feb 2017 17:55:04 -0800 From: Bjorn Andersson <bjorn.andersson@...aro.org> To: Loic Pallardy <loic.pallardy@...com> Cc: ohad@...ery.com, lee.jones@...aro.org, linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org, kernel@...inux.com, patrice.chotard@...com, hugues.fruchet@...com, peter.griffin@...aro.org Subject: Re: [PATCH v3 4/4] remoteproc: core: don't allocate carveout if pa or da are defined On Tue 31 Jan 04:35 PST 2017, Loic Pallardy wrote: > Remoteproc doesn't check if firmware requests fixed > addresses for carveout regions. > Current assumption is that platform specific driver is in > charge of coprocessor specific memory region allocation and > remoteproc core doesn't have to handle them. > If a da or a pa is specified in firmware resource table, remoteproc > core doesn't have to perform any allocation. > Access to carveout will be done thanks to rproc_da_to_pa function, > which will provide virtual address on carveout region allocated > by platform specific driver. > > Signed-off-by: Loic Pallardy <loic.pallardy@...com> > --- > No change since V1 > > drivers/remoteproc/remoteproc_core.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c > index 90b05c7..dd63ceed 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -622,6 +622,11 @@ static int rproc_handle_carveout(struct rproc *rproc, > dev_dbg(dev, "carveout rsc: name: %s, da 0x%x, pa 0x%x, len 0x%x, flags 0x%x\n", > rsc->name, rsc->da, rsc->pa, rsc->len, rsc->flags); > > + if (rsc->pa != FW_RSC_ADDR_ANY || rsc->da != FW_RSC_ADDR_ANY) { For devices with an IOMMU it's valid to specify "da" and have the allocated region mapped there. So this is not correct. Regards, Bjorn
Powered by blists - more mailing lists