Message-ID: <873fff36-7556-95f3-19e8-d172e8b4e47d@quicinc.com>
Date:   Mon, 6 Feb 2023 09:38:29 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH v9 10/27] gunyah: rsc_mgr: Add VM lifecycle RPC
To:     Alex Elder <elder@linaro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Bjorn Andersson <quic_bjorande@quicinc.com>,
        Murali Nalajala <quic_mnalajal@quicinc.com>
CC:     Trilok Soni <quic_tsoni@quicinc.com>,
        Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>,
        Carl van Schaik <quic_cvanscha@quicinc.com>,
        Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>,
        Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>,
        "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Bagas Sanjaya <bagasdotme@gmail.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
        Jassi Brar <jassisinghbrar@gmail.com>,
        Sudeep Holla <sudeep.holla@arm.com>,
        <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>
References: <20230120224627.4053418-1-quic_eberman@quicinc.com>
 <20230120224627.4053418-11-quic_eberman@quicinc.com>
 <4db1c760-10d9-3a22-106a-dda141dd5381@linaro.org>
 <4a584563-1fb7-22fa-5e16-e0cf5e88b76b@linaro.org>
Content-Language: en-US
From:   Elliot Berman <quic_eberman@quicinc.com>
In-Reply-To: <4a584563-1fb7-22fa-5e16-e0cf5e88b76b@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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.