[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161024175320.GO17252@sirena.org.uk>
Date: Mon, 24 Oct 2016 18:53:20 +0100
From: Mark Brown <broonie@...nel.org>
To: ahaslam@...libre.com
Cc: gregkh@...uxfoundation.org, johan@...nel.org, robh+dt@...nel.org,
nsekhar@...com, stern@...land.harvard.edu, khilman@...libre.com,
sshtylyov@...mvista.com, david@...hnology.com,
manjunath.goudar@...aro.org, abailon@...libre.com,
linux-usb@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH/RFT v2 09/17] regulator: fixed: Add over current event
On Mon, Oct 24, 2016 at 06:46:26PM +0200, ahaslam@...libre.com wrote:
> + if (ret) {
> + pr_err("Failed to request irq: %d\n", ret);
dev_err()
> +++ b/include/linux/regulator/consumer.h
> @@ -74,6 +74,10 @@
> * the most noisy and may not be able to handle fast load
> * switching.
> *
> + * OVERCURRENT Regulator has detected an overcurrent condition, and
> + * may be limiting the supply output.
> + *
> + *
> * NOTE: Most regulators will only support a subset of these modes. Some
> * will only just support NORMAL.
> *
> @@ -84,6 +88,7 @@
> #define REGULATOR_MODE_NORMAL 0x2
> #define REGULATOR_MODE_IDLE 0x4
> #define REGULATOR_MODE_STANDBY 0x8
> +#define REGULATOR_MODE_OVERCURRENT 0x10
This is adding a new core feature with a new mode and should have been
split out of the driver specific change with a spearate changelog. Why
does it make sense to report this as a mode, we don't report other error
conditions as modes but instead use REGULATOR_STATUS_ with the
get_status() operation?
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists