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 11:03:34 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Jassi Brar <jassisinghbrar@...il.com>,
        cristian.marussi@....com, peng.fan@....com,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        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 02:56:15PM +0530, Viresh Kumar wrote:

[...]

> The scmi protocol requires a block of shared memory which is
> represented by struct scmi_shared_mem, and payload is this memory
> block itself. This block of memory is accessed throughout driver.c
> file using ioread/write commands. If payload is transport specific, so
> will be those accesses, isn't it ? Are you suggesting to move all this
> to mailbox.c (the transport specific file) instead ? I am sorry, but I
> am not able to understand how exactly you want me to reorder code here
> :(
>

I don't have complete understanding of the requirements yet, but we may
have to make scmi_shared_mem transport specific vaguely based on virtio
requirements. I must have more info once I have discussion with them
soon. I will reply to this thread after that. More likely by end of this
week. Thanks for your patience, we are still trying to make sure we
have gathered all the requirements.

> @Sudeep: I had a question for you though. Looks like we are doing
> ioremap() of this payload for every channel's tx/rx, why ? Why is the
> same memory area mapped that way ? Can we just map the area once for
> scmi block ?
>

Though it may be part of same block of memory on most of the platforms,
it is not mandatory. It can be scattered. VirtIO based transport might
have something like that.

--
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ