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
Attachment:
signature.asc
Description: PGP signature
