Messages in this thread | | | From | Anson Huang <> | Subject | RE: [PATCH] firmware: imx: Skip return value check for some special SCU firmware APIs | Date | Sun, 29 Sep 2019 01:12:57 +0000 |
| |
Hi, Leonard/Marco I think we should get aligned first, my original thought is to let SCU API caller NOT aware of those special APIs, so have to do the special handling in imx_scu_call_rpc(). And the short loop check has to be used which would impact the performance a little bit I think. But Leonard stated the caller should know the SCU FW API's usage, if so, then I think the special callers can just skip the return value check, adding a comment to describe the reason, would it be much more easier than changing the imx_scu_call_rpc()? Or any other suggestion?
Anson
> On 27.09.2019 12:06, Marco Felsch wrote: > > Hi Anson, Leonard, > > > > On 19-09-27 01:20, Anson Huang wrote: > >> Hi, Leonard > >> > >>> On 2019-09-26 1:06 PM, Marco Felsch wrote: > >>>> On 19-09-26 08:03, Anson Huang wrote: > >>>>>> On 19-09-25 18:07, Anson Huang wrote: > >>>>>>> The SCU firmware does NOT always have return value stored in > >>>>>>> message header's function element even the API has response > >>>>>>> data, those special APIs are defined as void function in SCU > >>>>>>> firmware, so they should be treated as return success always. > >>>>>>> > >>>>>>> +static const struct imx_sc_rpc_msg whitelist[] = { > >>>>>>> + { .svc = IMX_SC_RPC_SVC_MISC, .func = > >>>>>> IMX_SC_MISC_FUNC_UNIQUE_ID }, > >>>>>>> + { .svc = IMX_SC_RPC_SVC_MISC, .func = > >>>>>>> +IMX_SC_MISC_FUNC_GET_BUTTON_STATUS }, }; > >>>>>> > >>>>>> Is this going to be extended in the near future? I see some > >>>>>> upcoming problems here if someone uses a different > >>>>>> scu-fw<->kernel combination as nxp would suggest. > >>>>> > >>>>> Could be, but I checked the current APIs, ONLY these 2 will be > >>>>> used in Linux kernel, so I ONLY add these 2 APIs for now. > >>>> > >>>> Okay. > >>>> > >>>>> However, after rethink, maybe we should add another imx_sc_rpc API > >>>>> for those special APIs? To avoid checking it for all the APIs > >>>>> called which > >>> may impact some performance. > >>>>> Still under discussion, if you have better idea, please advise, thanks! > >>> > >>> My suggestion is to refactor the code and add a new API for the this > >>> "no error value" convention. Internally they can call a common > >>> function with flags. > >> > >>>> Adding a special api shouldn't be the right fix. Imagine if someone > >>>> (not a nxp-developer) wants to add a new driver. How could he be > >>>> expected to know which api he should use. The better abbroach would > >>>> be to fix the scu-fw instead of adding quirks.. > >> > >> Yes, fixing SCU FW is the best solution, but we have talked to SCU FW > >> owner, the SCU FW released has been finalized, so the API > >> implementation can NOT be changed, but they will pay attention to > >> this issue for new added APIs later. That means the number of APIs having > this issue a very limited. > > > > This means those APIs which already have this bug will not be fixed? > > IMHO this sounds a bit weird since this is a changeable peace of code > > ;) > > It's not a bug, it's a documented feature ;) > > >>> Right now developers who want to make SCFW calls in upstream need to > >>> define the message struct in their driver based on protocol > documentation. > >>> This includes: > >>> > >>> * Binary layout of the message (a packed struct) > >>> * If the message has a response (already a bool flag) > >>> * If an error code is returned (this patch adds support for it) > > > > Why should I specify if a error code is returned? > > Because you're already defining the message struct and you're already > specifying if a response is required. > > The assumption is that anyone adding a SCFW call to a driver is already > looking at SCFW documentation which describes the binary message format. > > -- > Regards, > Leonard
| |