linux-kernel - Re: [PATCH v4 2/2] firmware: arm_scmi: Support 'reg-io-width' property for shared memory

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]

Message-ID: <04050b73-eb16-440f-acd7-986b1f39a6c9@broadcom.com>
Date: Thu, 24 Oct 2024 09:45:25 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: linux-arm-kernel@...ts.infradead.org, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Cristian Marussi <cristian.marussi@....com>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
 "open list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE"
 <arm-scmi@...r.kernel.org>, justin.chen@...adcom.com, opendmb@...il.com,
 Florian Fainelli <f.fainelli@...il.com>, kapil.hali@...adcom.com,
 bcm-kernel-feedback-list@...adcom.com, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v4 2/2] firmware: arm_scmi: Support 'reg-io-width'
 property for shared memory

On 10/24/24 04:05, Sudeep Holla wrote:
> Gentle ping! Not sure if my earlier email got into spam or didn't land
> in lore/ML. Just thought of checking again.

You did not land in spam, just being quite busy.

> 
> On Fri, Oct 18, 2024 at 01:57:09PM +0100, Sudeep Holla wrote:
>> On Tue, Sep 03, 2024 at 04:40:00PM +0100, Sudeep Holla wrote:
>>> On Tue, Aug 27, 2024 at 11:24:50AM -0700, Florian Fainelli wrote:
>>>> Some shared memory areas might only support a certain access width,
>>>> such as 32-bit, which memcpy_{from,to}_io() does not adhere to at least
>>>> on ARM64 by making both 8-bit and 64-bit accesses to such memory.
>>>>
>>>> Update the shmem layer to support reading from and writing to such
>>>> shared memory area using the specified I/O width in the Device Tree. The
>>>> various transport layers making use of the shmem.c code are updated
>>>> accordingly to pass the I/O accessors that they store.
>>>>
>>>
>>> This looks good to me now, much simpler. I will push this to -next soon,
>>> but it won't be for v6.12. I have already sent PR for that. I want this
>>> to be in -next for longer just to see if anyone has any comments and
>>> doesn't break any platform(which it shouldn't anyways).
>>>
>>> Just hoping if anyone looks at it and have feedback once it is in -next.
>>> I will apply formally at v6.12-rc1 and report back if no one complains
>>> until then.
>>>
>>
>> Hi Florian,
>>
>> Just thought I will check with you if the content is -next are fine as I now
>> recall I did the rebase as this patch was original posted before the rework
>> of transport as modules were merged. Please confirm if you are happy with the
>> rebase as you see in -next. I also had to rebase it on recent fixes that
>> Justin added as there were trivial conflicts.
>>
>> Another thing I wanted to check is if [1] series has any impact on this.
>> IIUC no, but it would be good to give a go in terms of testing just in case
>> that as well lands in -next.

linux-next as of today (2024-10-24) still works good on the affected 
platform, thanks for asking!
-- 
Florian