[PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Opensource [Anthony Olech]]

Add support for a new BC variant of the DA9053 PMIC.

There is one difference between it and the AA, BA and BB.

This patch also corrects a typing mistake in one of the BA
name strings that was incorrectly typed as "ab".

Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
---

This patch is relative to linux-next repository tag next-20140219

This patch depends on patch number 1 of this patch
series being applied first or it will not compile.

 drivers/mfd/da9052-i2c.c |    5 ++++-
 drivers/mfd/da9052-spi.c |    1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c
index c319c4e..6da8ec8 100644
--- a/drivers/mfd/da9052-i2c.c
+++ b/drivers/mfd/da9052-i2c.c
@@ -75,6 +75,7 @@ static int da9052_i2c_fix(struct da9052 *da9052, unsigned char reg)
 					   DA9052_PARK_REGISTER,
 					   &val);
 		break;
+	case DA9053_BC:
 	default:
 		/*
 		 * For other chips parking of I2C register
@@ -114,6 +115,7 @@ static const struct i2c_device_id da9052_i2c_id[] = {
 	{"da9053-aa", DA9053_AA},
 	{"da9053-ba", DA9053_BA},
 	{"da9053-bb", DA9053_BB},
+	{"da9053-bc", DA9053_BC},
 	{}
 };
 
@@ -121,8 +123,9 @@ static const struct i2c_device_id da9052_i2c_id[] = {
 static const struct of_device_id dialog_dt_ids[] = {
 	{ .compatible = "dlg,da9052", .data = &da9052_i2c_id[0] },
 	{ .compatible = "dlg,da9053-aa", .data = &da9052_i2c_id[1] },
-	{ .compatible = "dlg,da9053-ab", .data = &da9052_i2c_id[2] },
+	{ .compatible = "dlg,da9053-ba", .data = &da9052_i2c_id[2] },
 	{ .compatible = "dlg,da9053-bb", .data = &da9052_i2c_id[3] },
+	{ .compatible = "dlg,da9053-bc", .data = &da9052_i2c_id[4] },
 	{ /* sentinel */ }
 };
 #endif
diff --git a/drivers/mfd/da9052-spi.c b/drivers/mfd/da9052-spi.c
index 0680bcb..17666b4 100644
--- a/drivers/mfd/da9052-spi.c
+++ b/drivers/mfd/da9052-spi.c
@@ -71,6 +71,7 @@ static struct spi_device_id da9052_spi_id[] = {
 	{"da9053-aa", DA9053_AA},
 	{"da9053-ba", DA9053_BA},
 	{"da9053-bb", DA9053_BB},
+	{"da9053-bc", DA9053_BC},
 	{}
 };
 
-- 
end-of-patch 2/3 for PATCH V1

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Lee Jones]

> Add support for a new BC variant of the DA9053 PMIC.
> 
> There is one difference between it and the AA, BA and BB.
> 
> This patch also corrects a typing mistake in one of the BA
> name strings that was incorrectly typed as "ab".
> 
> Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
> ---
> 
> This patch is relative to linux-next repository tag next-20140219

That's not generally a good idea.

Please use a Mainline version (inc. -rcs).

> This patch depends on patch number 1 of this patch
> series being applied first or it will not compile.
> 
>  drivers/mfd/da9052-i2c.c |    5 ++++-
>  drivers/mfd/da9052-spi.c |    1 +
>  2 files changed, 5 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

RE: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Opensource [Anthony Olech]]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1784 bytes --]

> -----Original Message-----
> From: Lee Jones [mailto:lee.jones@linaro.org]
> Sent: 25 February 2014 08:57
> To: Opensource [Anthony Olech]
> Cc: Samuel Ortiz; Liam Girdwood; linux-kernel@vger.kernel.org; Mark
> Brown; David Dajun Chen
> Subject: Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant
> > Add support for a new BC variant of the DA9053 PMIC.
> > There is one difference between it and the AA, BA and BB.
> > This patch also corrects a typing mistake in one of the BA name
> > strings that was incorrectly typed as "ab".
> > Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
> > ---
> >
> > This patch is relative to linux-next repository tag next-20140219
> 
> That's not generally a good idea.
> Please use a Mainline version (inc. -rcs).

Hi Lee,

thanks for applying the patch.

I can rebase against any tagged version in a public git repository, but in the past
I was advised to use linux-next instead of the mainline. At this moment in time
the latest tag in git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
is 'v3.14-rc4'

Are you recommending that tag as the one to rebase (and test of course) against?

many thanks
Tony Olech

> > This patch depends on patch number 1 of this patch series being
> > applied first or it will not compile.
> >
> >  drivers/mfd/da9052-i2c.c |    5 ++++-
> >  drivers/mfd/da9052-spi.c |    1 +
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> Applied, thanks.
> 
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source
> software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Lee Jones]

> > > Add support for a new BC variant of the DA9053 PMIC.
> > > There is one difference between it and the AA, BA and BB.
> > > This patch also corrects a typing mistake in one of the BA name
> > > strings that was incorrectly typed as "ab".
> > > Signed-off-by: Anthony Olech <anthony.olech.opensource@diasemi.com>
> > > ---
> > >
> > > This patch is relative to linux-next repository tag next-20140219
> > 
> > That's not generally a good idea.
> > Please use a Mainline version (inc. -rcs).
> 
> Hi Lee,
> 
> thanks for applying the patch.
> 
> I can rebase against any tagged version in a public git repository, but in the past
> I was advised to use linux-next instead of the mainline. At this moment in time
> the latest tag in git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> is 'v3.14-rc4'
> 
> Are you recommending that tag as the one to rebase (and test of course) against?

I am. The trouble with basing your patches against -next is that it's
not stable, in that it is rebuilt every day. If your patches are
dependant on commits which haven't reached Mainline yet, then you
should rebase on the subsystem tree which they are contained in. All
patches in -next should be based on an -rc or a released kernel version.

> > > This patch depends on patch number 1 of this patch series being
> > > applied first or it will not compile.
> > >
> > >  drivers/mfd/da9052-i2c.c |    5 ++++-
> > >  drivers/mfd/da9052-spi.c |    1 +
> > >  2 files changed, 5 insertions(+), 1 deletion(-)
> > 
> > Applied, thanks.
> > 

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Tue, Feb 25, 2014 at 11:50:36AM +0000, Lee Jones wrote:

> I am. The trouble with basing your patches against -next is that it's
> not stable, in that it is rebuilt every day. If your patches are
> dependant on commits which haven't reached Mainline yet, then you
> should rebase on the subsystem tree which they are contained in. All
> patches in -next should be based on an -rc or a released kernel version.

The advice here is usually that sending against -next is a good proxy
for sending against the individual tree without having to figure out all
the different trees - almost all of the time the effect is the same.
This only applies when sending patches via e-mail, for git pulls it's an
absolute no of course.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Lee Jones]

> > I am. The trouble with basing your patches against -next is that it's
> > not stable, in that it is rebuilt every day. If your patches are
> > dependant on commits which haven't reached Mainline yet, then you
> > should rebase on the subsystem tree which they are contained in. All
> > patches in -next should be based on an -rc or a released kernel version.
> 
> The advice here is usually that sending against -next is a good proxy
> for sending against the individual tree without having to figure out all
> the different trees - almost all of the time the effect is the same.
> This only applies when sending patches via e-mail, for git pulls it's an
> absolute no of course.

Good point. But it's worth reiterating that this should only be done
if you have dependencies which haven't yet reached Mainline. 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Tue, Feb 25, 2014 at 12:40:50PM +0000, Lee Jones wrote:

> > The advice here is usually that sending against -next is a good proxy
> > for sending against the individual tree without having to figure out all
> > the different trees - almost all of the time the effect is the same.
> > This only applies when sending patches via e-mail, for git pulls it's an
> > absolute no of course.

> Good point. But it's worth reiterating that this should only be done
> if you have dependencies which haven't yet reached Mainline. 

It can be worth doing anyway with a subsystem that's actively developed
since sometimees the dependencies are the other way - the APIs in Linus'
tree may have gone away.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Lee Jones]

> > > The advice here is usually that sending against -next is a good proxy
> > > for sending against the individual tree without having to figure out all
> > > the different trees - almost all of the time the effect is the same.
> > > This only applies when sending patches via e-mail, for git pulls it's an
> > > absolute no of course.
> 
> > Good point. But it's worth reiterating that this should only be done
> > if you have dependencies which haven't yet reached Mainline. 
> 
> It can be worth doing anyway with a subsystem that's actively developed
> since sometimees the dependencies are the other way - the APIs in Linus'
> tree may have gone away.

Then what happens if the tree that your patch finally gets sucked into
is pulled before the one you've written your code against? I'd say
basing your code on -next is generally a bad idea.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

On Wed, Feb 26, 2014 at 09:32:03AM +0000, Lee Jones wrote:

> > It can be worth doing anyway with a subsystem that's actively developed
> > since sometimees the dependencies are the other way - the APIs in Linus'
> > tree may have gone away.

> Then what happens if the tree that your patch finally gets sucked into
> is pulled before the one you've written your code against? I'd say
> basing your code on -next is generally a bad idea.

Submitters should defintely at the very least be checking against the
subsystem tree (since that's what they're really submitting against) -
it's always annoying when someone submits code that either doesn't
apply or fails to build with the current tree.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH V1 2/3] MFD: da9052: Add new DA9053 BC chip variant

[Lee Jones]

> > > It can be worth doing anyway with a subsystem that's actively developed
> > > since sometimees the dependencies are the other way - the APIs in Linus'
> > > tree may have gone away.
> 
> > Then what happens if the tree that your patch finally gets sucked into
> > is pulled before the one you've written your code against? I'd say
> > basing your code on -next is generally a bad idea.
> 
> Submitters should defintely at the very least be checking against the
> subsystem tree (since that's what they're really submitting against) -
> it's always annoying when someone submits code that either doesn't
> apply or fails to build with the current tree.

+1

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog