Re: [PATCH v4 3/4] firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface

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

 



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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux