[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190613172738.GO5316@sirena.org.uk>
Date: Thu, 13 Jun 2019 18:27:38 +0100
From: Mark Brown <broonie@...nel.org>
To: Nisha Kumari <nishakumari@...eaurora.org>
Cc: bjorn.andersson@...aro.org, robh+dt@...nel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
agross@...nel.org, lgirdwood@...il.com, mark.rutland@....com,
david.brown@...aro.org, linux-kernel@...r.kernel.org,
kgunda@...eaurora.org, rnayak@...eaurora.org
Subject: Re: [PATCH 4/4] regulator: adding interrupt handling in labibb
regulator
On Wed, Jun 12, 2019 at 04:30:52PM +0530, Nisha Kumari wrote:
> +static void labibb_sc_err_recovery_work(void *_labibb)
> +{
> + int ret;
> + struct qcom_labibb *labibb = (struct qcom_labibb *)_labibb;
> +
> + labibb->ibb_vreg.vreg_enabled = 0;
> + labibb->lab_vreg.vreg_enabled = 0;
> +
> + ret = qcom_ibb_regulator_enable(labibb->lab_vreg.rdev);
The driver should *never* enable the regulator itself, it should only do
this if the core told it to.
> + /*
> + * The SC(short circuit) fault would trigger PBS(Portable Batch
> + * System) to disable regulators for protection. This would
> + * cause the SC_DETECT status being cleared so that it's not
> + * able to get the SC fault status.
> + * Check if LAB/IBB regulators are enabled in the driver but
> + * disabled in hardware, this means a SC fault had happened
> + * and SCP handling is completed by PBS.
> + */
Let the core worry about this, the driver should just report the problem
to the core like all other devices do (and this driver doesn't...).
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists