linux-kernel - Re: [PATCH] media: venus: firmware: Use of_reserved_mem

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZHTyNA7CCQft-_HP@gerhold.net>
Date:   Mon, 29 May 2023 20:43:00 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>
Cc:     Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
        Vikash Garodia <quic_vgarodia@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: venus: firmware: Use of_reserved_mem_lookup()

On Mon, May 29, 2023 at 08:36:27PM +0200, Konrad Dybcio wrote:
> On 29.05.2023 20:16, Stephan Gerhold wrote:
> > Reserved memory can be either looked up using the generic function
> > of_address_to_resource() or using the special of_reserved_mem_lookup().
> > The latter has the advantage that it ensures that the referenced memory
> > region was really reserved and is not e.g. status = "disabled".
> > 
> > of_reserved_mem also supports allocating reserved memory dynamically at
> > boot time. This works only when using of_reserved_mem_lookup() since
> > there won't be a fixed address in the device tree.
> > 
> > Switch the code to use of_reserved_mem_lookup(). There is no functional
> > difference for static reserved memory allocations.
> > 
> > Signed-off-by: Stephan Gerhold <stephan@...hold.net>
> > ---
> > See e.g. [1] for an example of dynamically allocated reserved memory.
> > (This patch does *not* depend on [1] and is useful without as well...)
> > 
> > [1]: https://lore.kernel.org/linux-arm-msm/20230510-dt-resv-bottom-up-v1-5-3bf68873dbed@gerhold.net/
> > ---
> Reviewed-by: Konrad Dybcio <konrad.dybcio@...aro.org>
> 
> >  drivers/media/platform/qcom/venus/firmware.c | 24 +++++++++++++-----------
> >  1 file changed, 13 insertions(+), 11 deletions(-)
> > 
> [...]
> 
> > -	mem_va = memremap(r.start, *mem_size, MEMREMAP_WC);
> > +	mem_va = memremap(*mem_phys, *mem_size, MEMREMAP_WC);
> >  	if (!mem_va) {
> > -		dev_err(dev, "unable to map memory region: %pR\n", &r);
> > +		dev_err(dev, "unable to map memory region %pa size %#zx\n", mem_phys, *mem_size);
> Nit : I'm not sure which is more useful, but many mapping functions
> seem to prefer printing
> 
> start, start+size-1
> 
> instead of 
> 
> start, size
> 
> on failure.
> 

Shrug, both is fine for me. I just used this because the qcom remoteproc
usages of of_address_to_resource() that I also patched already seemed to
log it similar to this.

If someone wants me to resend this with start, start+size-1 as suggested
by Konrad (or something else) then just let me know. :)

Thanks,
Stephan