Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 2 Nov 2023 15:04:43 +0000 | From | Cristian Marussi <> | Subject | Re: [RFC v5 2/5] drivers: firmware: scmi: Introduce scmi_get_max_msg_size function |
| |
On Thu, Nov 02, 2023 at 01:57:24PM +0000, Oleksii Moisieiev wrote: > Hi Cristian, >
Hi,
> 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. >
Yes I am aware of that.
> 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. >
Yes that is correct, my understanding is that the transmitter is in charge of building a message whose payload can fit into the maximum message size allowed by the underlying configured transport.
> Given this constraint, it seems we might not require additional helper > functions. We could potentially just verify against msg_max_size. >
Indeed for that reason the scmi_get_max_msg_size that you introduced is just enough since it allows you to peek into the transport and get the max_msg_size...the misunderstanding is around the fact that I was simply meaning that you should plug it into some new helper_ops so that yo can call it like:
max_msg = ph->hops->get_max_msg_size(ph);
(like iterators or get_extended_name)
Because in this way you could use it also when the protocol is build as a loadable module, thing that now it is possible only for vendor defined protocols, but we could also easily switch all the base protocols to be selectable via Kconfig and =m in the future (if ever)
Your helper is fine by itself it is just that it cannot be called by a protocol defined to loaded as a module because the symbol is not exported and, indeed, we introduced the ph->hops thing just for this reason, i.e. to have a set of common protocol utilities that can be called even from loadable modules protocols without the need to export every single symbol.
The reference to iterators and extended_name was misleading probably...my bad...or I am still missing something :D
Thanks, Cristian
| ![\](/images/icornerr.gif) |