linux-kernel - Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type

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]

Date:   Tue, 14 Jan 2020 17:41:57 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        cristian.marussi@....com, peng.fan@....com,
        Sudeep Holla <sudeep.holla@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of
 transport type

On Tue, Jan 14, 2020 at 12:17:28PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 14, 2020 at 12:11 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
> >

> >
> > Okay, I think I understand that a bit now. So here are the things
> > which I may need to do now:
> >
> > - Maybe move payload to struct scmi_mailbox structure, as that is the
> >   transport dependent structure..
> >
> > - Do ioremap, etc in mailbox.c only instead of driver.c
> >
> > - Provide more ops in struct scmi_transport_ops to provide read/write
> >   helpers to the payload and implement the ones based on
> >   ioread/iowrite in mailbox.c ..
> >
> > Am I thinking in the right direction now ?
>
> That sounds about right. What I'm still not sure about is whether the
> current kernel code is actually correct and should use iomeap()
> in the first place. Can you confirm that all current hardware
> implementations actually use MMIO type registers here rather than
> just rely on a buffer in RAM?
>

I remember we had this discussion in the past and was trying to dig up
the archive. I found it [1]. At that time and even today, I don't have
knowledge of any upstream platform using memory other than SRAM and
hence I found it safe to retain ioremap as is.

But I agree in general, this abstraction will allow us to add shmem of
other memory types like RAM. However, it's difficult to have understanding
and representation of the memory type used by the platform firmware say
in DT or even ACPI.

--
Regards,
Sudeep

[1] https://www.spinics.net/lists/arm-kernel/msg647292.html