lkml.org 
[lkml]   [2016]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 0/4] pwm: add support for ChromeOS EC PWM
On Tue, Jul 19, 2016 at 08:37:17AM +0100, Lee Jones wrote:
> On Mon, 18 Jul 2016, Thierry Reding wrote:
>
> > On Mon, Jul 18, 2016 at 02:24:26PM +0100, Lee Jones wrote:
> > > On Mon, 18 Jul 2016, Thierry Reding wrote:
> > >
> > > > On Mon, Jul 18, 2016 at 09:49:28AM +0100, Lee Jones wrote:
> > > > > On Fri, 15 Jul 2016, Brian Norris wrote:
> > > > > > This is the 4th (and final?) version of my series to support the new ChromeOS
> > > > > > EC PWM API, so we can control, e.g., a PWM backlight when its PWM is attached
> > > > > > to the EC. It uses Boris's latest "atomic" hooks for the PWM API (i.e., the
> > > > > > ->apply() callback), which were recently merged.
> > > > > >
> > > > > > Pulled and adapted the cros_ec_cmd_xfer_status() helper from this patch, with
> > > > > > some minor modifications:
> > > > > >
> > > > > > https://lkml.org/lkml/2016/4/12/342
> > > > > >
> > > > > > Note that after some style bikeshedding, I proposed to put off rewriting the
> > > > > > entire cros_ec_commands.h header at the moment, due to the shared nature of
> > > > > > this file. Follow up here:
> > > > > >
> > > > > > https://bugs.chromium.org/p/chromium/issues/detail?id=621123
> > > > > >
> > > > > > As this touches MFD (sort of), drivers/platform/chrome/, and drivers/pwm/, I'm
> > > > > > still not sure who it should all go through: Lee, Thierry, or Olof?
> > > > >
> > > > > I usually take this type of submission through the MFD tree, although
> > > > > it's too late in the day to make it into v4.8.
> > > > >
> > > > > Which Acks are you missing?
> > > >
> > > > I'm willing to take this through the PWM tree if you're okay with the
> > > > MFD changes. I can put the MFD changes into a separate branch and you
> > > > could pull that in if you needed to resolve any dependencies, which I
> > > > think would be quite unlikely if you've already closed your tree.
> > >
> > > Are you saying that you're willing to take these straight into the
> > > merge-window, with no soak in -next?
> >
> > There's still a bit of time to let it soak in -next, but I'm not overly
> > concerned given that this is purely additions of code, so there can't be
> > any regressions.
>
> No problem my side then. Apply away.
>
> Before doing so, can you see if there are any clashes with my
> mfd-for-next branch? If conflicts occur, please construct an
> immutable tag I can pull from. That way, I can base my branch on it
> and deal with the fallout myself.

It merges cleanly into your mfd-for-next branch, so I've gone and
applied patches 1 and 2 to a for-4.8/mfd branch, which I can provide a
stable tag from if you still need it, and patches 3 and 4 to the
for-4.8/drivers branch.

Thanks,
Thierry
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-07-25 17:01    [W:1.054 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site