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
