> > > 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
On Wed, Feb 26, 2014 at 09:32:03AM +, 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
> > > 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
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
On Wed, Feb 26, 2014 at 09:32:03AM +, 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
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
On Tue, Feb 25, 2014 at 12:40:50PM +, 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
> > 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
On Tue, Feb 25, 2014 at 11:50:36AM +, 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
> > > 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
> > > ---
> > >
> >
> -Original Message-
> From: Lee Jones [mailto:lee.jo...@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: da90
> 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
> ---
>
> This patch is
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.opensou...@diasemi.com
---
-Original Message-
From: Lee Jones [mailto:lee.jo...@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
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.opensou...@diasemi.com
On Tue, Feb 25, 2014 at 11:50:36AM +, 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
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
On Tue, Feb 25, 2014 at 12:40:50PM +, 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
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
---
This patch is relative to linux-next
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.opensou...@diasemi.com
---
This
20 matches
Mail list logo
