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
