Re: [PATCH v9 10/27] gunyah: rsc_mgr: Add VM lifecycle RPC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2/6/2023 7:41 AM, Alex Elder wrote:
On 2/2/23 6:46 AM, Srinivas Kandagatla wrote:
+    ret = gh_rm_call(rm, message_id, &req_payload, sizeof(req_payload), &resp, &resp_size);
+    if (!ret && resp_size) {

Am struggling to understand these type of checks in success case, when a command is not expecting any response why are we checking for response here, This sounds like a bug in either RM or hypervisor.

Or Is this something that happens due to some firmware behaviour?
Could you elobrate on this.

What I think you're talking about is error checking even when
it's very clear something "can't happen."  It's a pattern I've
seen in Qualcomm downstream code, and I believe sometimes it
is done as "best practice" to avoid warnings from security scans.
(I might be wrong about this though.)

That's right reasoning.


I think your underlying point though is that we can just assume
success means "truly successful," so there's no reason to do any
additional sanity checks.  We *assume* the hardware is doing the
correct thing (if it's not, we might as well assume it does
*nothing* right). >
So as a very general statement, I think all checks of this type
should go away (and I think Srini would agree).


I'll remove the checks.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux