Re: [PATCH v3 1/8] memory: tegra: Add API for retrieving carveout bounds

[Jon Hunter]

On 04/11/2022 15:48, Krzysztof Kozlowski wrote:
> On 04/11/2022 11:46, Jon Hunter wrote:
> > On 04/11/2022 15:35, Krzysztof Kozlowski wrote:
> > > On 04/11/2022 11:33, Jon Hunter wrote:
> > > > Hi Thierry, Krzysztof,
> > > >
> > > > On 24/10/2022 14:15, Thierry Reding wrote:
> > > > > On Tue, Sep 20, 2022 at 11:11:56AM +0300, Mikko Perttunen wrote:
> > > > > > From: Mikko Perttunen <mperttunen@xxxxxxxxxx>
> > > > > >
> > > > > > On Tegra234 NVDEC firmware is loaded from a secure carveout, where it
> > > > > > has been loaded by a bootloader. When booting NVDEC, we need to tell it
> > > > > > the address of this firmware, which we can determine by checking the
> > > > > > starting address of the carveout. As such, add an MC API to query the
> > > > > > bounds of carveouts, and add related information on Tegra234.
> > > > > >
> > > > > > Signed-off-by: Mikko Perttunen <mperttunen@xxxxxxxxxx>
> > > > > > ---
> > > > > > v2:
> > > > > > - Add check for 64-bit phys_addr_t. In practice phys_addr_t
> > > > > >      is always 64 bits where this runs, but it avoids warnings in
> > > > > >      compile test.
> > > > > > ---
> > > > > >     drivers/memory/tegra/mc.c       | 25 +++++++++++++++++++++++++
> > > > > >     drivers/memory/tegra/tegra234.c |  5 +++++
> > > > > >     include/soc/tegra/mc.h          | 11 +++++++++++
> > > > > >     3 files changed, 41 insertions(+)
> > > > >
> > > > > Krzysztof,
> > > > >
> > > > > I've applied this to the same tree as the patch that uses it for now.
> > > > > Let me know if you want me to put this on a separate stable branch for
> > > > > you to pull in.
> > > >
> > > > Any update on this?
> > >
> > > What kind of update do you expect?
> >
> > Ha! I guess I should be more explicit :-)
> >
> > Well, I would like to see this change in -next and so I was hoping that
> > you would respond to the above to indicate how you would like to pull
> > this in.
>
> The change will be in next via Thierry. I do not have to pull this in.
>
> The maintainer which applies patches is responsible for:
> 1. Having his tree in linux-next,
> 2. Sending the patches to upstream maintainer (e.g. arm-soc, Linus)
> later in pull request.
>
> There is no job for me here, if I agree with Thierry. There would be a
> job if I needed a separate stable branch, but that I did not decide
> yet... Do you think I need to pull it? If so, why?


No. Like I said I just want to get this into -next for testing. I had 
_wrongly_ assumed that Thierry was waiting on feedback from you. I see 
this is not the case and so let me check with Thierry where this is.

Jon

--
nvpublic