Linux 4.12-rc1

Linux 4.12-rc1

[Linus Torvalds]

So I'm doing this one day early, because I don't like last-minute pull
requests during the merge window anyway, and tomorrow is mother's day,
so I may end up being roped into various happenings.

Besides, this has actually been a pretty large merge window, so
despite there technically being time for one more day of pulls, I
actually do have enough changes already. So there.

Despite it being fairly large, it has (so far) been pretty smooth. I
don't think I personally saw any breakage at all, which is always
nice. Usually I end up having something break, or trigger some silly
build failure that really should have been noticed before it even got
to me, but so far things are looking good.

Famous last words.

The diffstat for this release looks a bit odd, because it's absolutely
dominated by the new AMD Vega10 header files that have all the
register definitions in them. In fact, that's almost exactly half the
lines of diff in just that.  And if you ignore that part, the new
Intel Atom IPU driver ends up being a noticeable part of the rest.

But if you ignore those two big additions, the statistics look pretty
normal. Two thirds drivers, with the rest being arch updates,
documentation updates and "misc" (filesystems, networking, header
updates, core files).

One thing worth noting - I haven't uploaded diffs or tar-balls for
this rc. Those should now be automagically generated by kernel.org for
the rc's, but that also means that they won't be signed by my key. If
you really care about signing, get the git repo and check the tag.

Go test.

                       Linus

---

Al Viro (7):
    uaccess unification updates
    iov_iter updates
    splice updates
    fs/compat.c cleanups
    vfs fix
    misc vfs updates
    misc vfs updates

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andrew Morton (3):
    misc updates
    more updates
    misc fixes

Arnd Bergmann (1):
    TEE driver infrastructure and OP-TEE drivers

Bartlomiej Zolnierkiewicz (1):
    fbdev updates

Bjorn Helgaas (1):
    PCI updates

Bob Peterson (1):
    GFS2 updates

Borislav Petkov (1):
    EDAC updates

Brian Norris (1):
    MTD updates

Bruce Fields (1):
    nfsd updates

Catalin Marinas (2):
    arm64 updates
    more arm64 updates

Chris Mason (1):
    btrfs updates

Corey Minyard (1):
    IPMI updates

Dan Williams (2):
    libnvdimm updates
    libnvdimm fixes

Darren Hart (1):
    x86 platform-drivers update

Darrick Wong (1):
    xfs updates

Dave Airlie (4):
    drm u pdates
    drm tegra updates
    drm CoC pointer
    drm fixes

David Howells (1):
    hw lockdown support

David Millar (1):
    networking updates

David Miller (4):
    networking fixes
    networking fixes
    sparc updates
    IDE updates

Dmitry Torokhov (2):
    input subsystem updates
    some more input subsystem updates

Doug Ledford (2):
    rdma updates
    more rdma updates

Eric Biederman (1):
    namespace updates

Geert Uytterhoeven (1):
    m68k updates

Greg KH (5):
    USB updates
    driver core updates
    char/misc driver updates
    staging/IIO updates
    tty/serial updates

Guenter Roeck (1):
    hwmon updates

Hans-Christian Noren Egtvedt (1):
    AVR32 removal

Herbert Xu (1):
    crypto updates

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (21):
    EFI updates
    scheduler updates
    locking updates
    perf updates
    RAS updates
    x86 boot updates
    x86 cpu updates
    x86 apic updates
    x86 asm updates
    x86 build update
    x86 cleanups
    x86 debug updates
    x86 irq update
    x86 platform updates
    x86 vdso updates
    x86 mm updates
    RCU updates
    x86 fixes
    stackprotector fixlet
    timer fix
    perf updates/fixes

Jacek Anaszewski (1):
    LED updates

Jaegeuk Kim (1):
    f2fs updates

James Bottomley (1):
    SCSI updates

James Hogan (2):
    metag updates
    MIPS updates

James Morris (1):
    security subsystem updates

Jan Kara (2):
    fsnotify updates
    quota, reiserfs, udf and ext2 updates

Jassi Brar (1):
    mailbox updates

Jens Axboe (4):
    block layer updates
    second round of block layer updates
    block fixes and updates
    block fixes

Jessica Yu (1):
    modules updates

Jiri Kosina (3):
    HID subsystem updates
    livepatch updates
    trivial tree updates

Joerg Roedel (1):
    IOMMU updates

Jonathan Corbet (2):
    documentation update
    more documentation updates

Juergen Gross (2):
    xen updates
    xen fixes

Kees Cook (2):
    pstore updates
    hardened usercopy updates

Lee Jones (2):
    backlight update
    MFD updates

Ley Foon Tan (1):
    nios2 updates

Linus Walleij (2):
    pin control updates
    GPIO updates

Luis de Bethencourt (1):
    befs fix

Mark Brown (2):
    regulator updates
    spi updates

Martin Schwidefsky (1):
    s390 updates

Masahiro Yamada (3):
    Kbuild updates
    misc Kbuild updates
    Kbuild UAPI updates

Mauro Carvalho Chehab (1):
    media updates

Max Filippov (1):
    Xtensa updates

Michael Ellerman (2):
    powerpc updates
    more powerpc updates

Michael Tsirkin (1):
    virtio updates

Mike Marshall (1):
    orangefs updates

Mike Snitzer (3):
    device mapper updates
    additional device mapper updates
    device mapper fixes

Miklos Szeredi (2):
    fuse updates
    overlayfs update

Nicholas Bellinger (1):
    SCSI target updates

Olof Johansson (7):
    misc ARM SoC fixes
    ARM SoC platform updates
    ARM Device-tree updates
    ARM: SoC defconfig updates
    ARM SoC driver updates
    ARM SoC 64-bit changes
    ARM 64-bit DT updates

Paolo Bonzini (2):
    KVM updates
    more KVM updates

Paul Moore (1):
    audit updates

Petr Mladek (1):
    printk updates

Rafael Wysocki (5):
    power management updates
    ACPI updates
    generic device properties framework updates
    more power management updates
    more ACPI updates

Richard Weinberger (2):
    UML fixes
    UBI/UBIFS updates

Rob Herring (1):
    DeviceTree updates

Russell King (1):
    ARM updates

Sebastian Reichel (3):
    power supply and reset updates
    HSI fix
    more power-supply updates

Shaohua Li (1):
    MD updates

Shuah Khan (1):
    kselftest updates

Stafford Horne (1):
    initramfs fix

Stephen Boyd (1):
    clk updates

Steve French (2):
    CIFS fixes
    cifs fixes

Steven Rostedt (3):
    tracing updates
    more tracing updates
    tracing fix

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (2):
    ext4 updates
    fscrypt updates

Tejun Heo (3):
    libata updates
    workqueue update
    cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Gleixner (2):
    irq updates
    timer updates

Trond Myklebust (1):
    NFS client updates

Ulf Hansson (1):
    MMC updates

Vineet Gupta (1):
    ARC updates

Vinod Koul (1):
    dmaengine updates

Wilfram Sang (1):
    i2c updates

Zhang Rui (1):
    thermal management updates

Re: Linux 4.12-rc1 (file locations)

[Randy Dunlap]

On 05/13/17 13:57, Linus Torvalds wrote:
> One thing worth noting - I haven't uploaded diffs or tar-balls for
> this rc. Those should now be automagically generated by kernel.org for
> the rc's, but that also means that they won't be signed by my key. If
> you really care about signing, get the git repo and check the tag.


There was some delay (don't know how much), but a bigger problem is
the file(s) locations and (new) directory structure for them.

Can the generated files please be put in the same places that (most or
all) previous releases have used?

Oh, and the patch file (on https://kernel.org) is a text file, not a
zipped file (as in previous releases).


thanks.
-- 
~Randy

Re: Linux 4.12-rc1 (file locations)

[Linus Torvalds]

On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

I will leave this to Konstantin.. There may well be practical reasons
for the movement.

> Oh, and the patch file (on https://kernel.org) is a text file, not a
> zipped file (as in previous releases).

Well, if you use a browser, the normal browser compression (behind
your back) should be in effect. So you won't actually be wasting the
bandwidth.

If you use wget, you have to manually ask for it. Quoting Konstantin
from an earlier discussion:

> Yes, this is implemented on the http protocol level -- but you have to
> tell wget to request it:
>
> wget -O test.patch.gz \
>  --header="accept-encoding: gzip" \
>  https://git.kernel.org/...
>
> Browsers do the requesting and ungzipping automatically, but not cmdline
> tools.

so the capability is there, it's just not done as several individual
files any more.

                 Linus

[Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[Linus Torvalds via RT]

On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

I will leave this to Konstantin.. There may well be practical reasons
for the movement.

> Oh, and the patch file (on https://kernel.org) is a text file, not a
> zipped file (as in previous releases).

Well, if you use a browser, the normal browser compression (behind
your back) should be in effect. So you won't actually be wasting the
bandwidth.

If you use wget, you have to manually ask for it. Quoting Konstantin
from an earlier discussion:

> Yes, this is implemented on the http protocol level -- but you have to
> tell wget to request it:
>
> wget -O test.patch.gz \
>  --header="accept-encoding: gzip" \
>  https://git.kernel.org/...
>
> Browsers do the requesting and ungzipping automatically, but not cmdline
> tools.

so the capability is there, it's just not done as several individual
files any more.

                 Linus

Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[François Valenduc]

Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit :
> On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> Can the generated files please be put in the same places that (most or
>> all) previous releases have used?
> 
> I will leave this to Konstantin.. There may well be practical reasons
> for the movement.
> 
>> Oh, and the patch file (on https://kernel.org) is a text file, not a
>> zipped file (as in previous releases).
> 
> Well, if you use a browser, the normal browser compression (behind
> your back) should be in effect. So you won't actually be wasting the
> bandwidth.
> 
> If you use wget, you have to manually ask for it. Quoting Konstantin
> from an earlier discussion:
> 
>> Yes, this is implemented on the http protocol level -- but you have to
>> tell wget to request it:
>>
>> wget -O test.patch.gz \
>>  --header="accept-encoding: gzip" \
>>  https://git.kernel.org/...
>>
>> Browsers do the requesting and ungzipping automatically, but not cmdline
>> tools.
> 
> so the capability is there, it's just not done as several individual
> files any more.
> 
>                  Linus
> 
> 
It doesn't work with Firefox-53.0. After quite a long time while firefox
uses 100% of CPU, I finally get a text file and not a gzip file of the
patch for 4.12-rc1. It was almost instantaneous previously. I don't see
this as a progress.

Best regards,

François Valenduc

Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[François Valenduc via RT]

Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit :
> On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>> Can the generated files please be put in the same places that (most or
>> all) previous releases have used?
> 
> I will leave this to Konstantin.. There may well be practical reasons
> for the movement.
> 
>> Oh, and the patch file (on https://kernel.org) is a text file, not a
>> zipped file (as in previous releases).
> 
> Well, if you use a browser, the normal browser compression (behind
> your back) should be in effect. So you won't actually be wasting the
> bandwidth.
> 
> If you use wget, you have to manually ask for it. Quoting Konstantin
> from an earlier discussion:
> 
>> Yes, this is implemented on the http protocol level -- but you have to
>> tell wget to request it:
>>
>> wget -O test.patch.gz \
>>  --header="accept-encoding: gzip" \
>>  https://git.kernel.org/...
>>
>> Browsers do the requesting and ungzipping automatically, but not cmdline
>> tools.
> 
> so the capability is there, it's just not done as several individual
> files any more.
> 
>                  Linus
> 
> 
It doesn't work with Firefox-53.0. After quite a long time while firefox
uses 100% of CPU, I finally get a text file and not a gzip file of the
patch for 4.12-rc1. It was almost instantaneous previously. I don't see
this as a progress.

Best regards,

François Valenduc

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-15 14:34:56, francoisvalenduc@gmail.com wrote:
> It doesn't work with Firefox-53.0. After quite a long time while
> firefox
> uses 100% of CPU, I finally get a text file and not a gzip file of the
> patch for 4.12-rc1. It was almost instantaneous previously. I don't
> see
> this as a progress.

Firefox will request a gzip version of the patch, download it and then ungzip it for you and display it in the browser. If you'd rather not display that, please use a commandline tool like wget or curl to get the patch.

We are trying to identify who are the people who still need to download patches as opposed to using git directly, and what their use-case scenario is.

Regards,
-- 
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec

Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Christian Kujau]

On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalenduc@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It was almost instantaneous previously. I don't
> > see
> > this as a progress.
> 
> Firefox will request a gzip version of the patch, download it and then ungzip 
> it for you and display it in the browser. If you'd rather not display 
> that, please use a commandline tool like wget or curl to get the patch.

Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main 
page makes Firefox 53 freeze for a few minutes, and then display (!) the 
text file (85 MB!) in full. Wow.

> We are trying to identify who are the people who still need to download
> patches as opposed to using git directly, and what their use-case 

I never use the links on the kernel.org main page to download patches, but 
still: can those be changed to say ".gz" or something, so that $browser 
won't _display_ it by default but _download_ it instead?

Thanks,
Christian.
-- 
BOFH excuse #435:

Internet shut down due to maintenance

Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Christian Kujau via RT]

On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalenduc@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It was almost instantaneous previously. I don't
> > see
> > this as a progress.
> 
> Firefox will request a gzip version of the patch, download it and then ungzip 
> it for you and display it in the browser. If you'd rather not display 
> that, please use a commandline tool like wget or curl to get the patch.

Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main 
page makes Firefox 53 freeze for a few minutes, and then display (!) the 
text file (85 MB!) in full. Wow.

> We are trying to identify who are the people who still need to download
> patches as opposed to using git directly, and what their use-case 

I never use the links on the kernel.org main page to download patches, but 
still: can those be changed to say ".gz" or something, so that $browser 
won't _display_ it by default but _download_ it instead?

Thanks,
Christian.
-- 
BOFH excuse #435:

Internet shut down due to maintenance

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-24 14:42:54, lists@nerdbynature.de wrote:
> > We are trying to identify who are the people who still need to
> > download
> >  patches as opposed to using git directly, and what their use-case
> 
> I never use the links on the kernel.org main page to download patches,
> but
> still: can those be changed to say ".gz" or something, so that
> $browser
> won't _display_ it by default but _download_ it instead?

We'll enable that the moment cgit supports that -- but it currently doesn't. I have an RFE open with cgit upstream.

Regards,
-- 
Konstantin Ryabitsev
Linux Foundation Projects

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-15 11:42:48, torvalds@linux-foundation.org wrote:
> so the capability is there, it's just not done as several individual
> files any more.

I've published a news item explaining the new process and the reasoning behind not providing these automatically generated tarballs and patches as part of the cryptographically verifiable /pub tree:

https://www.kernel.org/rc-tarballs-and-patches-starting-with-412-rc1.html

Regards,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
Linux Foundation Projects
Montréal, Québec

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-14 13:59:22, rdunlap@infradead.org wrote:
> On 05/13/17 13:57, Linus Torvalds wrote:
> > One thing worth noting - I haven't uploaded diffs or tar-balls for
> > this rc. Those should now be automagically generated by kernel.org for
> > the rc's, but that also means that they won't be signed by my key. If
> > you really care about signing, get the git repo and check the tag.
> 
> 
> There was some delay (don't know how much), but a bigger problem is
> the file(s) locations and (new) directory structure for them.

This is intentional to indicate the transient autogenerated nature of these files. They don't exist in the /pub tree and therefore it is misleading to rewrite URLs to place them there.

> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

Not unless there is a convincing reason to do so (and please feel free to provide it, as this is not a final change and can always be undone should the counter-arguments be convincing).

Regards,
-- 
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec

linux-next: stats (Was: Linux 4.12-rc1)

[Stephen Rothwell]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20170502 was the first linux-next after
the merge window opened.)

Commits in v4.12-rc1 (relative to v4.11):          12920
Commits in next-20170502:                          12432
Commits with the same SHA1:                        11772
Commits with the same patch_id:                      331 (1)
Commits with the same subject line:                   41 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20170502:     12144 93%

Some breakdown of the list of extra commits (relative to next-20170502)
in -rc1:

Top ten first word of commit summary:

    143 drm
     55 kvm
     38 annotate
     23 net
     20 powerpc
     20 ib
     14 perf
     13 x86
     13 arm64
     12 target

Top ten authors:

     39 dhowells@redhat.com
     32 rex.zhu@amd.com
     24 eric.auger@redhat.com
     14 ray.huang@amd.com
     14 christian.koenig@amd.com
     12 alexander.deucher@amd.com
     11 osandov@fb.com
     11 idryomov@gmail.com
     11 cdall@linaro.org
     11 axboe@fb.com

Top ten commiters:

    132 alexander.deucher@amd.com
    105 davem@davemloft.net
     38 dhowells@redhat.com
     38 axboe@fb.com
     37 cdall@linaro.org
     31 idryomov@gmail.com
     26 torvalds@linux-foundation.org
     25 nab@linux-iscsi.org
     24 pbonzini@redhat.com
     22 mpe@ellerman.id.au

There are also 288 commits in next-20170502 that didn't make it into
v4.12-rc1.

Top ten first word of commit summary:

     23 arm
     19 mm
     18 watchdog
     13 rcu
      9 srcu
      9 rcutorture
      9 btrfs
      8 rcuperf
      8 arm64
      7 fault-inject

Top ten authors:

     45 paulmck@linux.vnet.ibm.com
     19 akpm@linux-foundation.org
     18 alexandre.belloni@free-electrons.com
     15 tglx@linutronix.de
     15 bigeasy@linutronix.de
     11 peda@axentia.se
      9 quwenruo@cn.fujitsu.com
      6 olof@lixom.net
      6 akinobu.mita@gmail.com
      5 kernel@networkimprov.net

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

     66 sfr@canb.auug.org.au
     47 paulmck@linux.vnet.ibm.com
     34 tglx@linutronix.de
     23 linux@roeck-us.net
     14 alexandre.belloni@free-electrons.com
     11 peda@axentia.se
      9 quwenruo@cn.fujitsu.com
      8 olof@lixom.net
      7 sre@kernel.org
      5 mathieu.poirier@linaro.org

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Sebastian Reichel]

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

Hi,

On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> There are also 288 commits in next-20170502 that didn't make it into
> v4.12-rc1.
> 
> [...]
>
> Top ten commiters:
> 
>      66 sfr@canb.auug.org.au
>      47 paulmck@linux.vnet.ibm.com
>      34 tglx@linutronix.de
>      23 linux@roeck-us.net
>      14 alexandre.belloni@free-electrons.com
>      11 peda@axentia.se
>       9 quwenruo@cn.fujitsu.com
>       8 olof@lixom.net
>       7 sre@kernel.org
>       5 mathieu.poirier@linaro.org

Did you compile the list today? I started adding content for 4.13
after Linus tagged v4.12-rc1 and my power-supply for-next branch
curently has exactly 7 patches.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Stephen Rothwell]

Hi Sebastian,

On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel <sre@kernel.org> wrote:
>
> On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> > There are also 288 commits in next-20170502 that didn't make it into
> > v4.12-rc1.
> > 
> > [...]
> >
> > Top ten commiters:
> > 
> >      66 sfr@canb.auug.org.au
> >      47 paulmck@linux.vnet.ibm.com
> >      34 tglx@linutronix.de
> >      23 linux@roeck-us.net
> >      14 alexandre.belloni@free-electrons.com
> >      11 peda@axentia.se
> >       9 quwenruo@cn.fujitsu.com
> >       8 olof@lixom.net
> >       7 sre@kernel.org
> >       5 mathieu.poirier@linaro.org  
> 
> Did you compile the list today? I started adding content for 4.13
> after Linus tagged v4.12-rc1 and my power-supply for-next branch
> curently has exactly 7 patches.

As I said above these are commits that were in linux-next on May 2nd
but were not in v4.12-rc1:

99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support
ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support
a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods
7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery documentation
fb38342a5ae6 power: supply: core: add power_supply_battery_info and API
bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units
ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding

There can be various reasons that they didn't make it in and, in fact,
these are not in yesterday's linux-next either.
-- 
Cheers,
Stephen Rothwell

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Sebastian Reichel]

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

Hi Stephen,

On Tue, May 16, 2017 at 07:32:09AM +1000, Stephen Rothwell wrote:
> On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel <sre@kernel.org> wrote:
> > On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> > > There are also 288 commits in next-20170502 that didn't make it into
> > > v4.12-rc1.
> > > 
> > > [...]
> > >
> > > Top ten commiters:
> > > 
> > >      66 sfr@canb.auug.org.au
> > >      47 paulmck@linux.vnet.ibm.com
> > >      34 tglx@linutronix.de
> > >      23 linux@roeck-us.net
> > >      14 alexandre.belloni@free-electrons.com
> > >      11 peda@axentia.se
> > >       9 quwenruo@cn.fujitsu.com
> > >       8 olof@lixom.net
> > >       7 sre@kernel.org
> > >       5 mathieu.poirier@linaro.org  
> > 
> > Did you compile the list today? I started adding content for 4.13
> > after Linus tagged v4.12-rc1 and my power-supply for-next branch
> > curently has exactly 7 patches.
> 
> As I said above these are commits that were in linux-next on May 2nd
> but were not in v4.12-rc1

oh, I missed that.

> 99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support
> ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support
> a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods
> 7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery documentation
> fb38342a5ae6 power: supply: core: add power_supply_battery_info and API
> bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units
> ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding
> 
> There can be various reasons that they didn't make it in and, in fact,
> these are not in yesterday's linux-next either.

Thanks, I forgot about those when I wrote my mail. The patch author
asked me to drop them for 4.12 due to some problems.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]