On Mon, Sep 03, 2018 at 08:57:36AM +0000, A.s. Dong wrote:

Hi Sascha,

quoted

-----Original Message-----
From: A.s. Dong
Sent: Wednesday, August 29, 2018 4:35 PM
To: Sascha Hauer <s.hauer@pengutronix.de>

[...]

quoted

quoted

quoted

The original point is to separate the SCU service API implementation
from the client drivers. Client drivers don't have to know the
internal details of the API implementation, they just use the
service API provided by SCU firmware. API implementation and client
users will be

maintained independently.

I would buy this argument if the 'API implementation' was more than a
shim layer that directly translates between function arguments and a

message struct.

quoted

With this you effectively can't change the API implementation without
changing the API you provide to the client drivers.

In reality, the API implementation could change without changing the API
prototype.
The API is defined in a more generic way and less possible to change.
But the internal implementation is allowed to change if the firmware updates.
e.g. protocol params layout and size and etc.

This way give us a clear separation between API internals and client users
which are more like to be maintained independently.
And it may also help if we want to support old firmware due to API internal
implementation changes. (And note that SCU firmware supports many
functions, distribute them into various drivers may cause a bit mess. Some of
them may get troubles on finding a proper place to put.)

Examples?

quoted

So aren't those more valuable comparing to move SCU APIs into client drivers?
And current kernel users (arm scpi/scmi, ti sci) already do like this... why not
i.MX?

Sorry if I still not get your point.
Please help clarify a bit more if I missed something..

Please let me know if you still believe moving SCU API implementation into
each client driver is a more reasonable way to go, then i will do it as I trust
your professionality.

Yes, I still think that. I still think the 1:1 mapping between messages
and function calls is an unnecessary overhead.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |