Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230320152319.665592-1-loic.poulain@linaro.org>
 <20230330114242.GC434339@google.com> <242a5400-b5e6-4707-af88-1d695e114f78@app.fastmail.com>
In-Reply-To: <242a5400-b5e6-4707-af88-1d695e114f78@app.fastmail.com>
From:   Loic Poulain <loic.poulain@linaro.org>
Date:   Thu, 30 Mar 2023 15:22:47 +0200
Message-ID: <CAMZdPi8ZMfLTHaEn2LbXvuen=Rb68KrWJmgbq9Miou_RDi=Btg@mail.gmail.com>
Subject: Re: [PATCH] mfd: syscon: Use of_io_request_and_map() for IO mapping
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Lee Jones <lee@kernel.org>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Arnd,

On Thu, 30 Mar 2023 at 14:45, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Mar 30, 2023, at 13:42, Lee Jones wrote:
> > On Mon, 20 Mar 2023, Loic Poulain wrote:
> >
> >> Use of_io_request_and_map() instead of of_iomap() so that the
> >> region is reserved and protected, i.e reported in /proc/iomem
> >> and not accessible from user side (CONFIG_IO_STRICT_DEVMEM).
> >>
> >> Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
> >> ---
> >>  drivers/mfd/syscon.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> >> index bdb2ce7ff03b..7e6d4edda118 100644
> >> --- a/drivers/mfd/syscon.c
> >> +++ b/drivers/mfd/syscon.c
> >> @@ -60,7 +60,7 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_clk)
> >>              goto err_map;
> >>      }
> >>
> >> -    base = of_iomap(np, 0);
> >> +    base = of_io_request_and_map(np, 0, NULL);
> >>      if (!base) {
> >>              ret = -ENOMEM;
> >>              goto err_map;
> >
> > Looks sane though.
> >
> > Arnd, do you have an opinion?
>
> Thanks for pinging me. I would indeed expect this to cause
> problems, as syscon mappings are likely to be used in a way
> that is not entirely clean, with other devices defining
> overlapping ranges.

Isn't syscon exactly here to address that collision/overlapping issue?
From a syscon perspective, it seems to be handled correctly at least
since the mapping is only setup once, with the first user device (in
syscon_node_to_regmap). Or are you thinking about non syscon devices
overlapping the syscon area?


>
> For any other driver, the change makes a lot of sense after
> checking the DT file, but for syscon in particular I don't
> think it's even realistic to check all users.
>
>      Arnd