Re: [RFC v5 2/5] drivers: firmware: scmi: Introduce scmi_get_max_msg_size function

[Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>]

Hi Cristian,

Just found an interesting note in the PINCTRL_CONFIG_SET command 
description:

The maximum value of this field is limited by
the transport used. The agent needs to specify
this field such that the entire command can be
accommodated within the transport chosen.

Furthermore, I observed the absence of a skip_configs parameter.

 From my understanding, this implies that the maximum number of 
configurations should not exceed the msg_max_size allowed by the 
protocol, enabling the transmission of only one message to the SCMI 
server at a time.

Given this constraint, it seems we might not require additional helper 
functions. We could potentially just verify against msg_max_size.

Best regards,
Oleksii

On 02.11.23 09:29, Cristian Marussi wrote:
> On Fri, Oct 27, 2023 at 06:28:09AM +0000, Oleksii Moisieiev wrote:
>> Current SCMI implementation supports only receiving arrays from the
>> SCMI server and provides helpers to process received data. It uses
>> msg_max_size value to determine maximum message size that can be
>> transmitted via selected protocol. When sending arrays to SCMI server
>> this value should be checked by the Client driver to prevent
>> overflowing protocol buffers.
>> That's why scmi_get_max_msg_size call was introduced.
>>
> 
> Hi Oleksii,
> 
> indeed given the new variable sized v3.2 SCMI requests (instead of
> responses) this common helper is now needed for the protocols to be
> able to properly size and chunk their command requests, BUT this is
> a new core helper that has potentially to be available to any future
> protocol so it has to be exposed as a common helpers in helpers_ops
> (like iterators or extended_name helpers), if NOT this common method
> won't be available to protocols when compiled as distinct loadable
> modules (vendor-modules can be defined and built as LKM)
> 
> Thanks,
> Cristian
>