ation
> is already contained at the top of the file in the comments.
>
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: patc...@opensource.cirrus.com
> Acked-by: Linus Walleij
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
es
> Cc: patc...@opensource.cirrus.com
> Acked-by: Linus Walleij
> Signed-off-by: Paul Gortmaker
> ---
> -static int wm8350_i2c_remove(struct i2c_client *i2c)
> -{
> - struct wm8350 *wm8350 = i2c_get_clientdata(i2c);
> -
> - wm8350_device_exit(wm8350);
This is the only caller of this function so you probably want to
remove it in the next patch as we did for the 831x stuff.
Thanks,
Charles
r non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Acked-by: Linus Walleij
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
gt; Previous demodularizaion work has made wm831x_device_exit() no longer
> used, so it is also removed from the 831x core code.
>
> Cc: Lee Jones
> Cc: Charles Keepax
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
de.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Acked-by: Linus Walleij
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
s, good spot.
But apart from those additional two patches, series
also looks good to me:
Reviewed-by: Charles Keepax
Thanks,
Charles
s, good spot.
But apart from those additional two patches, series
also looks good to me:
Reviewed-by: Charles Keepax
Thanks,
Charles
On Thu, Dec 06, 2018 at 12:47:46PM +0100, Linus Walleij wrote:
> On Thu, Dec 6, 2018 at 11:34 AM Charles Keepax
> wrote:
> > On Thu, Dec 06, 2018 at 09:58:30AM +0100, Linus Walleij wrote:
> > > On Wed, Dec 5, 2018 at 4:33 PM Charles Keepax
> > > wrote:
> > &g
On Thu, Dec 06, 2018 at 12:47:46PM +0100, Linus Walleij wrote:
> On Thu, Dec 6, 2018 at 11:34 AM Charles Keepax
> wrote:
> > On Thu, Dec 06, 2018 at 09:58:30AM +0100, Linus Walleij wrote:
> > > On Wed, Dec 5, 2018 at 4:33 PM Charles Keepax
> > > wrote:
> > &g
On Thu, Dec 06, 2018 at 09:58:30AM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 4:33 PM Charles Keepax
> wrote:
> > On Wed, Dec 05, 2018 at 03:42:06PM +0100, Linus Walleij wrote:
> > > On Wed, Dec 5, 2018 at 2:43 PM Charles Keepax
> > > wrote:
> > &g
On Thu, Dec 06, 2018 at 09:58:30AM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 4:33 PM Charles Keepax
> wrote:
> > On Wed, Dec 05, 2018 at 03:42:06PM +0100, Linus Walleij wrote:
> > > On Wed, Dec 5, 2018 at 2:43 PM Charles Keepax
> > > wrote:
> > &g
On Wed, Dec 05, 2018 at 03:42:06PM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 2:43 PM Charles Keepax
> wrote:
> > On Wed, Dec 05, 2018 at 01:47:12PM +0100, Linus Walleij wrote:
> > > @@ -775,10 +779,13 @@ static int max8973_probe(stru
On Wed, Dec 05, 2018 at 03:42:06PM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 2:43 PM Charles Keepax
> wrote:
> > On Wed, Dec 05, 2018 at 01:47:12PM +0100, Linus Walleij wrote:
> > > @@ -775,10 +779,13 @@ static int max8973_probe(stru
IOD_OUT_HIGH);
My comment on v2 still stands here, the GPIO is not passed to
the regulator core on this path. Very sorry it took me so long
to review v2 (been one of those wonderful weeks at this end)
and then I managed to perfectly time reviewing it to the exact
second you sent v3.
I think apart from this the series looks good to me though.
Thanks,
Charles
IOD_OUT_HIGH);
My comment on v2 still stands here, the GPIO is not passed to
the regulator core on this path. Very sorry it took me so long
to review v2 (been one of those wonderful weeks at this end)
and then I managed to perfectly time reviewing it to the exact
second you sent v3.
I think apart from this the series looks good to me though.
Thanks,
Charles
On Wed, Dec 05, 2018 at 12:48:47PM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 12:36 PM Charles Keepax
> wrote:
> > On Sun, Dec 02, 2018 at 11:23:07PM -0500, Paul Gortmaker wrote:
> > > The solution to #4 is similar - we delete the ".remove"
On Wed, Dec 05, 2018 at 12:48:47PM +0100, Linus Walleij wrote:
> On Wed, Dec 5, 2018 at 12:36 PM Charles Keepax
> wrote:
> > On Sun, Dec 02, 2018 at 11:23:07PM -0500, Paul Gortmaker wrote:
> > > The solution to #4 is similar - we delete the ".remove"
ul here this path actually never passes the GPIO
to the regulator core. I suspect you want to leave this one as a
devm_
> if (IS_ERR(gpiod))
> return PTR_ERR(gpiod);
> if (gpiod)
> @@ -798,6 +805,8 @@ static int max8973_probe(struct i2c_client *client,
>
> ret = max8973_init_dcdc(max, pdata);
> if (ret < 0) {
> + if (gpiod)
> + gpiod_put(gpiod);
And make this use config.ena_gpiod instead.
Thanks,
Charles
ul here this path actually never passes the GPIO
to the regulator core. I suspect you want to leave this one as a
devm_
> if (IS_ERR(gpiod))
> return PTR_ERR(gpiod);
> if (gpiod)
> @@ -798,6 +805,8 @@ static int max8973_probe(struct i2c_client *client,
>
> ret = max8973_init_dcdc(max, pdata);
> if (ret < 0) {
> + if (gpiod)
> + gpiod_put(gpiod);
And make this use config.ena_gpiod instead.
Thanks,
Charles
ation
> is already contained at the top of the file in the comments.
>
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
ation
> is already contained at the top of the file in the comments.
>
> Cc: Lee Jones
> Cc: Mark Brown
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
>
> We replace module.h with init.h and export.h ; the latter since the
> file does export some symbols.
>
> Cc: Linus Walleij
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
>
> We replace module.h with init.h and export.h ; the latter since the
> file does export some symbols.
>
> Cc: Linus Walleij
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
> -static int wm8350_i2c_remove(struct i2c_client *i2c)
> -{
> - struct wm8350 *wm8350 = i2c_get_clientdata(i2c);
> -
> - wm8350_device_exit(wm8350);
> -
> - return 0;
> -}
Likewise here it removes the only caller of wm8350_device_exit.
Thanks,
Charles
patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
> -static int wm8350_i2c_remove(struct i2c_client *i2c)
> -{
> - struct wm8350 *wm8350 = i2c_get_clientdata(i2c);
> -
> - wm8350_device_exit(wm8350);
> -
> - return 0;
> -}
Likewise here it removes the only caller of wm8350_device_exit.
Thanks,
Charles
tches remove the only callers of wm831x_device_exit, so I
guess we should probably remove that function too?
Thanks,
Charles
tches remove the only callers of wm831x_device_exit, so I
guess we should probably remove that function too?
Thanks,
Charles
d is not the only reason one might ever unbind a
driver. So are we sure we want to remove the option to unbind
these drivers? Certainly for testing it is sometimes useful.
Thanks,
Charles
d is not the only reason one might ever unbind a
driver. So are we sure we want to remove the option to unbind
these drivers? Certainly for testing it is sometimes useful.
Thanks,
Charles
ents.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
ents.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
we could still update the binding if that comes
out of the review as a preferred option. Apologies for missing
such a glaring issue in my testing.
Thanks,
Charles
Charles Keepax (2):
regulator: Factor out location of init data OF node
regulator: Allow regulator nodes to c
we could still update the binding if that comes
out of the review as a preferred option. Apologies for missing
such a glaring issue in my testing.
Thanks,
Charles
Charles Keepax (2):
regulator: Factor out location of init data OF node
regulator: Allow regulator nodes to c
To support future additions factor out the location of the OF node
containing the init data for the regulator from the code that parses the
init data.
Signed-off-by: Charles Keepax
---
drivers/regulator/of_regulator.c | 64 +++-
1 file changed, 37 insertions
Currently it is expected that regulator init data will be defined as a
series of sub-nodes from the node that bound in the driver. Add support
for a node to both bind in a driver and contain init data for that
regulator.
Signed-off-by: Charles Keepax
---
drivers/regulator/of_regulator.c | 8
To support future additions factor out the location of the OF node
containing the init data for the regulator from the code that parses the
init data.
Signed-off-by: Charles Keepax
---
drivers/regulator/of_regulator.c | 64 +++-
1 file changed, 37 insertions
Currently it is expected that regulator init data will be defined as a
series of sub-nodes from the node that bound in the driver. Add support
for a node to both bind in a driver and contain init data for that
regulator.
Signed-off-by: Charles Keepax
---
drivers/regulator/of_regulator.c | 8
re the GPIO would need to be freed on which error paths, I
am not sure it is immediately obvious to me but I suspect it will
need to be freed in some cases.
Thanks,
Charles
re the GPIO would need to be freed on which error paths, I
am not sure it is immediately obvious to me but I suspect it will
need to be freed in some cases.
Thanks,
Charles
ases. If only a single regulator has requested the GPIO then
all the error paths after the call to regulator_ena_gpio_request
in regulator_register will free the GPIO. Although this is not the
case if more than one regulator has requested the GPIO.
Thanks,
charles
ases. If only a single regulator has requested the GPIO then
all the error paths after the call to regulator_ena_gpio_request
in regulator_register will free the GPIO. Although this is not the
case if more than one regulator has requested the GPIO.
Thanks,
charles
quot;, 0,
> + gflags,
> + "tps65090");
> if (IS_ERR(rpdata->gpiod))
> return ERR_CAST(rpdata->gpiod);
> if (!rpdata->gpiod)
This one needs some handling to avoid leaking the gpio too.
Thanks,
Charles
quot;, 0,
> + gflags,
> + "tps65090");
> if (IS_ERR(rpdata->gpiod))
> return ERR_CAST(rpdata->gpiod);
> if (!rpdata->gpiod)
This one needs some handling to avoid leaking the gpio too.
Thanks,
Charles
; + gpiod_put(rdata->ext_control_gpiod);
> + rdata--;
> + j--;
> + }
> + return ret;
> }
These looks like it handles the error paths in
s5m8767_pmic_dt_parse_pdata, however there are still all the
error paths between the call to that function and the call to
regulator_register that need to be handled as well.
Thanks,
Charles
; + gpiod_put(rdata->ext_control_gpiod);
> + rdata--;
> + j--;
> + }
> + return ret;
> }
These looks like it handles the error paths in
s5m8767_pmic_dt_parse_pdata, however there are still all the
error paths between the call to that function and the call to
regulator_register that need to be handled as well.
Thanks,
Charles
ode,
> + pdata->gpiod_ren[n] =
> + gpiod_get_from_of_node(da9211_matches[i].of_node,
This driver has a lot of error paths that will leak the GPIO with
this change.
Thanks,
Charles
> "enable",
> 0,
> GPIOD_OUT_HIGH | GPIOD_FLAGS_BIT_NONEXCLUSIVE,
> --
> 2.19.1
ode,
> + pdata->gpiod_ren[n] =
> + gpiod_get_from_of_node(da9211_matches[i].of_node,
This driver has a lot of error paths that will leak the GPIO with
this change.
Thanks,
Charles
> "enable",
> 0,
> GPIOD_OUT_HIGH | GPIOD_FLAGS_BIT_NONEXCLUSIVE,
> --
> 2.19.1
Signed-off-by: Charles Keepax
---
drivers/mfd/wm5110-tables.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
index 1ee68bd440fb..16c6e2accfaa 100644
--- a/drivers/mfd/wm5110-tables.c
+++ b/drivers/mfd/wm5110-tables.c
@@ -1618,6
Signed-off-by: Charles Keepax
---
drivers/mfd/wm5110-tables.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
index 1ee68bd440fb..16c6e2accfaa 100644
--- a/drivers/mfd/wm5110-tables.c
+++ b/drivers/mfd/wm5110-tables.c
@@ -1618,6
On Mon, Nov 26, 2018 at 02:16:45PM -0600, Rob Herring wrote:
> On Tue, Nov 20, 2018 at 02:16:26PM +0000, Charles Keepax wrote:
> > Lochnagar is an evaluation and development board for Cirrus
> > Logic Smart CODEC and Amp devices. It allows the connection of
> > most Cirrus
On Mon, Nov 26, 2018 at 02:16:45PM -0600, Rob Herring wrote:
> On Tue, Nov 20, 2018 at 02:16:26PM +0000, Charles Keepax wrote:
> > Lochnagar is an evaluation and development board for Cirrus
> > Logic Smart CODEC and Amp devices. It allows the connection of
> > most Cirrus
don't have any objections to it as a solution.
Thanks,
Charles
don't have any objections to it as a solution.
Thanks,
Charles
On Mon, Nov 26, 2018 at 02:54:28PM +, Mark Brown wrote:
> On Mon, Nov 26, 2018 at 02:30:28PM +0000, Charles Keepax wrote:
>
> > Would there perhaps be milage in looking at just making
> > the regulator core request the GPIO, rather than the end
> > drivers? Gives
On Mon, Nov 26, 2018 at 02:54:28PM +, Mark Brown wrote:
> On Mon, Nov 26, 2018 at 02:30:28PM +0000, Charles Keepax wrote:
>
> > Would there perhaps be milage in looking at just making
> > the regulator core request the GPIO, rather than the end
> > drivers? Gives
On Mon, Nov 26, 2018 at 02:09:27PM +, Mark Brown wrote:
> On Mon, Nov 26, 2018 at 01:00:01PM +0000, Charles Keepax wrote:
> > On Fri, Nov 23, 2018 at 01:25:22PM +, Mark Brown wrote:
>
> > > help the multiple users find each other somehow. I think what we want
>
On Mon, Nov 26, 2018 at 02:09:27PM +, Mark Brown wrote:
> On Mon, Nov 26, 2018 at 01:00:01PM +0000, Charles Keepax wrote:
> > On Fri, Nov 23, 2018 at 01:25:22PM +, Mark Brown wrote:
>
> > > help the multiple users find each other somehow. I think what we want
>
On Fri, Nov 23, 2018 at 01:25:22PM +, Mark Brown wrote:
> On Fri, Nov 23, 2018 at 10:57:29AM +0000, Charles Keepax wrote:
>
> > It's fixing something in the case of two regulators using the
> > same GPIO. The direction this patch chain takes is that the end
> &g
On Fri, Nov 23, 2018 at 01:25:22PM +, Mark Brown wrote:
> On Fri, Nov 23, 2018 at 10:57:29AM +0000, Charles Keepax wrote:
>
> > It's fixing something in the case of two regulators using the
> > same GPIO. The direction this patch chain takes is that the end
> &g
On Fri, Nov 23, 2018 at 10:40:57AM +0100, Linus Walleij wrote:
> On Thu, Nov 22, 2018 at 6:30 PM Charles Keepax
> wrote:
>
> > Currently, a GPIO can be requested multiple times when the
> > NONEXCLUSIVE flag is set, however it must still be freed a single
> > time. Th
On Fri, Nov 23, 2018 at 10:40:57AM +0100, Linus Walleij wrote:
> On Thu, Nov 22, 2018 at 6:30 PM Charles Keepax
> wrote:
>
> > Currently, a GPIO can be requested multiple times when the
> > NONEXCLUSIVE flag is set, however it must still be freed a single
> > time. Th
On Fri, Nov 23, 2018 at 05:00:57PM +0800, kbuild test robot wrote:
> Hi Charles,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on ljones-mfd/for-mfd-next]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181122]
> [
On Fri, Nov 23, 2018 at 05:00:57PM +0800, kbuild test robot wrote:
> Hi Charles,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on ljones-mfd/for-mfd-next]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181122]
> [
2e ("regulator: core: Support passing an initialized GPIO
> enable descriptor")
> Cc: Marek Szyprowski
> Cc: Charles Keepax
> Reported-by: Marek Szyprowski
> Reported-by: Charles Keepax
> Signed-off-by: Linus Walleij
> ---
> Mark: I will rebase my v7 series fo
2e ("regulator: core: Support passing an initialized GPIO
> enable descriptor")
> Cc: Marek Szyprowski
> Cc: Charles Keepax
> Reported-by: Marek Szyprowski
> Reported-by: Charles Keepax
> Signed-off-by: Linus Walleij
> ---
> Mark: I will rebase my v7 series fo
makes more sense to handle the shared GPIO
in the core.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
drivers/regulator/wm8994-regulator.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/wm8994-regulator.c
b/drivers/regula
makes more sense to handle the shared GPIO
in the core.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
drivers/regulator/wm8994-regulator.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/wm8994-regulator.c
b/drivers/regula
add some basic reference
counting into the core. Currently, this is fairly primitive but
so is the support for the NONEXCLUSIVE flag and the implementation
covers those use-cases.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
drivers/gpio/gpiolib.c | 13 -
drivers
add some basic reference
counting into the core. Currently, this is fairly primitive but
so is the support for the NONEXCLUSIVE flag and the implementation
covers those use-cases.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
drivers/gpio/gpiolib.c | 13 -
drivers
as they normally would.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
drivers/regulator/core.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index dbe2f2e6e6254..9da7d27c7145e 100644
as they normally would.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
drivers/regulator/core.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index dbe2f2e6e6254..9da7d27c7145e 100644
On Thu, Nov 22, 2018 at 04:47:20PM +0100, Linus Walleij wrote:
> On Thu, Nov 22, 2018 at 3:19 PM Linus Walleij
> wrote:
> > On Wed, Nov 21, 2018 at 11:13 AM Charles Keepax
> > wrote:
> >
> > > The regulator core takes over managing the lifetime of the ena
On Thu, Nov 22, 2018 at 04:47:20PM +0100, Linus Walleij wrote:
> On Thu, Nov 22, 2018 at 3:19 PM Linus Walleij
> wrote:
> > On Wed, Nov 21, 2018 at 11:13 AM Charles Keepax
> > wrote:
> >
> > > The regulator core takes over managing the lifetime of the ena
e" in order to
> possibly remove any confusion.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
e" in order to
> possibly remove any confusion.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
ents.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
ents.
>
> Cc: Lee Jones
> Cc: patc...@opensource.cirrus.com
> Signed-off-by: Paul Gortmaker
> ---
Acked-by: Charles Keepax
Thanks,
Charles
On Wed, Nov 21, 2018 at 11:42:06AM +0100, Marek Szyprowski wrote:
> On 2018-11-21 11:13, Charles Keepax wrote:
> Linus, Mark: Similar issue is probably in the other regulator drivers,
> which use enable GPIO allocated by devm_gpio_get*(). This driver is
> simply the first one, which
On Wed, Nov 21, 2018 at 11:42:06AM +0100, Marek Szyprowski wrote:
> On 2018-11-21 11:13, Charles Keepax wrote:
> Linus, Mark: Similar issue is probably in the other regulator drivers,
> which use enable GPIO allocated by devm_gpio_get*(). This driver is
> simply the first one, which
The regulator core takes over managing the lifetime of the enable GPIO
once the regulator is registered. As such we shouldn't register the
enable GPIO using devm, or it will be freed twice.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
Again only build tested.
Thanks
The regulator core takes over managing the lifetime of the enable GPIO
once the regulator is registered. As such we shouldn't register the
enable GPIO using devm, or it will be freed twice.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
Again only build tested.
Thanks
On Wed, Nov 21, 2018 at 10:26:30AM +0100, Marek Szyprowski wrote:
> On 2018-11-20 18:25, Marek Szyprowski wrote:
> > On 2018-11-20 18:01, Charles Keepax wrote:
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:2421
> > regula
On Wed, Nov 21, 2018 at 10:26:30AM +0100, Marek Szyprowski wrote:
> On 2018-11-20 18:25, Marek Szyprowski wrote:
> > On 2018-11-20 18:01, Charles Keepax wrote:
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:2421
> > regula
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
> >On 2018-11-20 17:16, Richard Fitzgerald wrote:
> >>On 20/11/18 15:56, Marek Szyprowski wrote:
> >>>On 2018-11-20 16:36, Charles Keepax wrote:
> >&
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
> >On 2018-11-20 17:16, Richard Fitzgerald wrote:
> >>On 20/11/18 15:56, Marek Szyprowski wrote:
> >>>On 2018-11-20 16:36, Charles Keepax wrote:
> >&
We need to manage the life time of the enable GPIO against the regulator
device but the OF node lives on the parent MFD device. As such we can't
use the devm functions which assume the same device will be used for
both.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
This patch
We need to manage the life time of the enable GPIO against the regulator
device but the OF node lives on the parent MFD device. As such we can't
use the devm functions which assume the same device will be used for
both.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
This patch
On Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote:
> > On 2018-11-20 15:47, Charles Keepax wrote:
> > > On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> > >> On 2018
On Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote:
> > On 2018-11-20 15:47, Charles Keepax wrote:
> > > On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> > >> On 2018
On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote:
> Hi Charles,
>
> On 2018-11-20 15:47, Charles Keepax wrote:
> > On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> >> On 2018-05-17 18:41, Mark Brown wrote:
> >>> Subj
On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote:
> Hi Charles,
>
> On 2018-11-20 15:47, Charles Keepax wrote:
> > On Tue, Nov 20, 2018 at 02:43:32PM +0100, Marek Szyprowski wrote:
> >> On 2018-05-17 18:41, Mark Brown wrote:
> >>> Subj
"wlf,ldo1ena", GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("GPION", 4,
> > + "wlf,ldo2ena", GPIO_ACTIVE_HIGH),
> > + { },
> > },
> > };
If its being done through a board file I guess you will need the
equivalent of this.
Thanks,
Charles
"wlf,ldo1ena", GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("GPION", 4,
> > + "wlf,ldo2ena", GPIO_ACTIVE_HIGH),
> > + { },
> > },
> > };
If its being done through a board file I guess you will need the
equivalent of this.
Thanks,
Charles
Based on review comments on the MFD driver, move the child drivers for
the Lochnagar MFD over to binding through device tree.
Signed-off-by: Charles Keepax
---
Changes since v4:
- Split out regulator binding for each regulator
Thanks,
Charles
drivers/regulator/lochnagar-regulator.c | 48
Based on review comments on the MFD driver, move the child drivers for
the Lochnagar MFD over to binding through device tree.
Signed-off-by: Charles Keepax
---
Changes since v4:
- Split out regulator binding for each regulator
Thanks,
Charles
drivers/regulator/lochnagar-regulator.c | 48
the board
controller chip on the Lochnagar board.
Signed-off-by: Charles Keepax
---
.../bindings/regulator/cirrus,lochnagar.txt| 82 ++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt
diff --git
the board
controller chip on the Lochnagar board.
Signed-off-by: Charles Keepax
---
.../bindings/regulator/cirrus,lochnagar.txt| 82 ++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt
diff --git
the board
controller chip on the Lochnagar board.
Signed-off-by: Charles Keepax
---
.../devicetree/bindings/clock/cirrus,lochnagar.txt | 89 ++
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/cirrus,lochnagar.txt
diff --git
the board
controller chip on the Lochnagar board.
Signed-off-by: Charles Keepax
---
.../devicetree/bindings/clock/cirrus,lochnagar.txt | 89 ++
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/cirrus,lochnagar.txt
diff --git
the board
controller chip on the Lochnagar board.
The Lochnagar can take several input clocks from the host system,
provides several of its own clock sources, and provides extensive
routing options for those clocks to be supplied to the attached
CODEC/Amp device.
Signed-off-by: Charles Keepax
401 - 500 of 3625 matches
Mail list logo
