Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9f50e6c7-5c85-f70f-a5fe-19923d28f770@gmail.com>
Date:   Thu, 20 Jul 2023 21:27:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v4 3/4] firmware: qcom_scm: Add support for Qualcomm
 Secure Execution Environment SCM interface
Content-Language: en-US
To:     Johan Hovold <johan@kernel.org>
Cc:     Bjorn Andersson <andersson@kernel.org>,
        Andy Gross <agross@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        Ilias Apalodimas <ilias.apalodimas@linaro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Sudeep Holla <sudeep.holla@arm.com>,
        Steev Klimaszewski <steev@kali.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230528230351.168210-1-luzmaximilian@gmail.com>
 <20230528230351.168210-4-luzmaximilian@gmail.com>
 <ZJwjWoxm3GDkJ0cm@hovoldconsulting.com>
 <ZJwspnWhpOCJ88WP@hovoldconsulting.com>
From:   Maximilian Luz <luzmaximilian@gmail.com>
In-Reply-To: <ZJwspnWhpOCJ88WP@hovoldconsulting.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 6/28/23 14:50, Johan Hovold wrote:
> On Wed, Jun 28, 2023 at 02:11:07PM +0200, Johan Hovold wrote:
>> On Mon, May 29, 2023 at 01:03:50AM +0200, Maximilian Luz wrote:
> 
>>> @@ -1496,6 +1903,12 @@ static int qcom_scm_probe(struct platform_device *pdev)
>>>   
>>>   	__get_convention();
>>>   
>>> +	ret = qcom_scm_qseecom_init();
>>> +	if (ret < 0) {
>>> +		__scm = NULL;
>>
>> So as I mentioned in my reply to 2/4, you can still have clients
>> registered here when you clear the __scm pointer which they rely on
>> after an error.
>>
>> Not sure how best to handle this, but perhaps registering a qseecom
>> platform device here and have it's driver probe defer until scm is
>> available would work?
>>
>> That way you could also separate out the qseecom implementation in a
>> separate file (driver) rather than having the ifdef above.
> 
> An alternative may be to just warn and continue if
> qcom_scm_qseecom_init() fails. It should never return -EPROBE_DEFER
> anyway, right?

You're correct. That would be the simplest option. Any error returned by
qcom_scm_qseecom_init() comes from the client registration part
(qseecom_client_register()) and is either -ENOMEM or whatever
auxiliary_device_[init|add]() returns. As far as I can tell, the latter
errors out either on invalid inputs or on OOM, so it should be completely
fine to just warn about it failing.

Regards
Max