linux-kernel - Re: [RFC v5 2/5] drivers: firmware: scmi: Introduce scmi_get_max_msg

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: <9c9660c1-ab64-4186-917d-2007d88ce7c7@epam.com>
Date:   Thu, 2 Nov 2023 13:57:24 +0000
From:   Oleksii Moisieiev <Oleksii_Moisieiev@...m.com>
To:     Cristian Marussi <cristian.marussi@....com>
CC:     "sudeep.holla@....com" <sudeep.holla@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [RFC v5 2/5] drivers: firmware: scmi: Introduce
 scmi_get_max_msg_size function

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
>