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