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 12:17:28 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        Jassi Brar <jassisinghbrar@...il.com>,
        cristian.marussi@....com, peng.fan@....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:11 PM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> On 14-01-20, 10:56, Arnd Bergmann wrote:
> > My point was that you cannot mix __iomem accesses with pointer
> > accesses. As I understood it, the current version uses a pointer to a
>
> The current version is stupid as I misunderstood the whole __iomem
> thing and just dropped it :)
>
> > hardware mailbox with structured data, so you have to use ioremap()
> > to get a token you can pass into ioread(), but (some of) the new
> > transport types would just be backed by regular RAM, on which this
> > is not a well-defined operation and you have to use memremap()
> > and memcpy() instead.
>
> 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?

      Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ