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

[Maximilian Luz]

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