On 8/12/24 11:01, Cristian Marussi wrote:
OK, I will think about more about what needs to be done here, but in
general, do you agree this is an acceptable approach to support "odd" SRAMs?
Yes, but one question comes up in my mind upfront (maybe similar to Rob remarks):
is this not, in theory, something general that should be somehow addressed transparently
by the core SRAM code when dealing with such odd SRAM, since SCMI is
indeed only onne of the possible users ?
(not saying to do this in this series that deals with SCMI related issues....)
Anyway, I'll have a though too about the SCMI core transport possible changes that I
mentiond above, soon-ish... (I tried something already today, hoping to solve it quickly
...with poor results :D)
What do you think about keeping the status quo with the scmi_shared_mem
singleton and instead introduce a per-shmem scmi_shared_mem_io_ops which
would contain function pointers to read from/write to the shared memory?
This would keep the scmi_shared_mem read-only and a singleton and the
transport would be responsible for storing and passing that set of
function pointers around, post setup_iomap() where the determination
would have been done.
--
Florian
