Linux 4.20-rc1

Linux 4.20-rc1

[Linus Torvalds]

So I did debate calling it 5.0, but if we all help each other, I'm
sure we can count to 20. It's a nice round number, and I didn't want
to make a pattern of it. I think 5.0 happens next year, because then I
*really* run out of fingers and toes.

Anyway, 4.20-rc1 is tagged and pushed out, and the merge window is
over. This was a fairly big merge window, but it didn't break any
records, just solid. And things look pretty regular, with about 70% of
the patch is driver updates (gpu drivers are looming large as usual,
but there's changes all over). The rest is arch updates (x86, arm64,
arm, powerpc and the new C-SKY architecture), header files,
networking, core mm and kernel, and tooling.

In fact, tooling is quite noticeable. A fair amount of selftest
changes, but also various perf tooling updates.

There's a vfs pull request I declined and it might still go in later
in a slightly reduced form, but apart from that I think everything got
merged. We had one pull request that almost missed the merge windows
due to a silly change in my email setup, but I verified that nothing
else had happened to hit that special case.

One thing I _would_ like to point out as the merge window closes: I
tend to delay some pull requests that I want to take a closer look at
until the second week of the merge window when things are calming
down, and that _really_ means that I'd like to get all the normal pull
requests in the first week of the two-week merge window. And most
people really followed that, but by Wednesday this week I had gotten a
big frustrated that I kept getting new pull requests when I wanted to
really just spend most of the day looking through the ones that
deserved a bit of extra attention.

And yes, people generally kind of know about this and I really do get
*most* pull requests early. But I'm considering trying to make that a
more explicit rule that I will literally stop taking new pull requests
some time during the second week unless you have a good reason for why
it was delayed.

Because yes, the merge window is two weeks, but it's two weeks partly
exactly _because_ people (not just me) sometimes need extra time to
resolve any possible issues, not because regular everyday pull
requests should spread out over the whole two weeks. The development
for things meant for the next release should have been done by the
time the merge window opens.

Anyway, let's see. Maybe it won't be needed. It hasn't become a
problem, it just was starting to feel a bit tight there.

Oh, and I did try to do the reply emails. And I'm _entirely_ sure that
I must have missed acknowledging emails for a few pull requests. I'm
hoping that by the time the next merge window rolls around, we'll just
have new automation for it, so that everybody just automatically gets
notified when their pull request hit mainline. In the meantime, you
have a good chance - but not a guarantee - that I'll send a "Pulled"
ack email when I start processing a pull request.

And as usual for rc1, the log below is just the list of people I
pulled from with a one-liner "mergelog". Very much a high-level
summary of merges, for details you need to look into the git tree..

                    Linus

---
Al Viro (8):
    tty ioctl updates
    vfs fixes
    compat_ioctl fixes
    alpha syscall glue updates
    more ->lookup() cleanups
    AFS updates
    misc vfs updates
    9p fix

Alex Williamson (1):
    VFIO updates

Alexandre Belloni (1):
    RTC updates

Andrew Morton (3):
    updates
    more updates
    more updates

Arnd Bergmann (4):
    ARM SoC device tree updates
    ARM SoC defconfig updates
    ARM SoC driver updates
    ARM SoC platform updates

Bartlomiej Zolnierkiewicz (1):
    fbdev updates

Benson Leung (1):
    chrome-platform updates

Bjorn Andersson (2):
    remoteproc updates
    rpmsg updates

Bjorn Helgaas (1):
    PCI updates

Bob Peterson (1):
    gfs2 updates

Boris Brezillon (1):
    mtd updates

Borislav Petkov (2):
    EDAC updates
    more EDAC updates

Bruce Fields (1):
    nfsd updates

Catalin Marinas (2):
    arm64 updates
    more arm64 updates

Christoph Hellwig (3):
    dma mapping updates
    more dma-mapping updates
    dma-mapping fix

Corey Minyard (1):
    IPMI updates

Dan Williams (1):
    libnvdimm updates

Darren Hart (1):
    x86 platform driver updates

Dave Airlie (2):
    drm updates
    drm fixes

Dave Chinner (1):
    vfs dedup fixes

David Kleikamp (1):
    jfs updates

David Miller (8):
    sparc updates
    networking updates
    sparc fix
    sparc fixes
    networking fixes
    networking fixes
    sparc fixes
    networking fixes

David Sterba (2):
    btrfs updates
    more btrfs updates

Dennis Zhou (1):
    percpu fixes

Dmitry Torokhov (1):
    input updates

Dominik Brodowski (1):
    pcmcia fixes

Dominique Martinet (1):
    9p updates

Eduardo Valentin (1):
    thermal SoC updates

Eric Biederman (1):
    siginfo updates

Geert Uytterhoeven (1):
    m68k updates

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

Greg Ungerer (1):
    m68k nommu fix

Guenter Roeck (1):
    hwmon updates

Guo Ren (2):
    C-SKY architecture port
    csky dtb fixups

Helge Deller (2):
    parisc updates
    parisc updates

Herbert Xu (1):
    crypto updates

Ilya Dryomov (1):
    ceph updates

Ingo Molnar (22):
    RCU updates
    EFI updates
    locking and misc x86 updates
    perf updates
    RAS updates
    scheduler updates
    x86 apic updates
    x86 asm updates
    x86 boot updates
    x86 build update
    x86 cpu updates
    x86 grub2 updates
    x86 hyperv updates
    x86 mm updates
    x86 paravirt updates
    x86 platform updates
    x86 pti updates
    x86 vdso updates
    irq fixes
    perf updates and fixes
    x86 fixes
    scheduler fixes

Jacek Anaszewski (2):
    LED updates
    LED fix

Jaegeuk Kim (1):
    f2fs updates

James Bottomley (2):
    SCSI updates
    more SCSI updates

James Morris (6):
    security subsystem updates
    integrity updates
    TPM updates
    smack updates
    LoadPin updates
    keys updates

Jan Kara (2):
    fsnotify updates
    ext2 and udf updates

Jason Gunthorpe (1):
    rdma updates

Jassi Brar (1):
    mailbox updates

Jens Axboe (4):
    block layer updates
    libata updates
    more block layer updates
    block layer fixes

Jiri Kosina (1):
    HID updates

Joerg Roedel (1):
    IOMMU updates

John Johansen (1):
    apparmor updates

Jon Mason (1):
    NTB updates

Jonathan Corbet (1):
    documentation updates

Juergen Gross (1):
    xen fixes

Kees Cook (3):
    pstore updates
    VLA removal
    stackleak gcc plugin

Konrad Rzeszutek Wilk (1):
    xen swiotlb fix

Lee Jones (2):
    MFD updates
    backlight updates

Linus Walleij (2):
    pin control updates
    GPIO updates

Mark Brown (3):
    regmap updates
    spi updates
    regulator updates

Mark Salter (1):
    c6x update

Martin Schwidefsky (1):
    s390 updates

Masahiro Yamada (2):
    Kbuild updates
    Kbuild updates

Matthew Wilcox (1):
    XArray conversion

Mauro Carvalho Chehab (2):
    media updates
    new experimental media request API

Max Filippov (1):
    Xtensa fixes and cleanups

Michael Ellerman (2):
    powerpc updates
    powerpc fixes

Michael Tsirkin (1):
    virtio/vhost updates

Miguel Ojeda (1):
    compiler attribute updates

Mike Marshall (1):
    orangefs updates

Mike Snitzer (1):
    device mapper updates

Miklos Szeredi (2):
    fuse updates
    overlayfs updates

Nicolas Pitre (1):
    cramfs fixes

Olof Johansson (1):
    ARM SoC fixes

Palmer Dabbelt (3):
    RISC-V updates
    more RISC-V updates
    RISC-V defconfig update

Paul Burton (2):
    MIPS fixes
    MIPS updates

Paul Moore (1):
    SELinux updates

Petr Mladek (1):
    printk updates

Radim Krčmář (1):
    KVM updates

Rafael Wysocki (4):
    power management updates
    ACPI updates
    more power management updates
    more ACPI updates

Richard Weinberger (2):
    UML updates
    UBIFS updates

Rob Herring (2):
    Devicetree updates
    Devicetree fixes

Russell King (1):
    ARM updates

Sebastian Reichel (1):
    power supply and reset updates

Shaohua Li (1):
    md updates

Shuah Khan (1):
    kselftest updates

Stephen Boyd (1):
    clk updates

Steve French (2):
    cifs updates
    cifs fixes and updates

Steven Rostedt (2):
    tracing fixes
    tracing updates

Takashi Iwai (2):
    sound updates
    sound fixes

Ted Ts'o (1):
    ext4 updates

Tejun Heo (1):
    cgroup updates

Thierry Reding (1):
    pwm updates

Thomas Gleixner (3):
    timekeeping updates
    irq updates
    more timer updates

Tony Luck (1):
    ia64 updates

Trond Myklebust (2):
    NFS client updates
    NFS client bugfixes

Ulf Hansson (1):
    MMC updates

Vinod Koul (1):
    dmaengine updates

Wim Van Sebroeck (1):
    watchdog updates

Wolfram Sang (2):
    i2c updates
    i2c fixes

Zhang Rui (1):
    thermal management updates

System not booting since dm changes? (was Linux 4.20-rc1)

[Michael Ellerman]

Linus Torvalds <torvalds@linux-foundation.org> writes:
...
> Mike Snitzer (1):
>     device mapper updates

Hi Mike,

Replying here because I can't find the device-mapper pull or the patch
in question on LKML. I guess I should be subscribed to dm-devel.

We have a box that doesn't boot any more, bisect points at one of:

  cef6f55a9fb4 Mike Snitzer       dm table: require that request-based DM be layered on blk-mq devices 
  953923c09fe8 Mike Snitzer       dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED 
  6a23e05c2fe3 Jens Axboe         dm: remove legacy request-based IO path 


It's a Power8 system running Rawhide, it does have multipath, but I'm
told it was setup by the Fedora installer, ie. nothing fancy.

The symptom is the system can't find its root filesystem and drops into
the initramfs shell. The dmesg includes a bunch of errors like below:

  [   43.263460] localhost multipathd[1344]: sdb: fail to get serial
  [   43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
  [   43.268762] localhost multipathd[1344]: uevent trigger error
  [   43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
  [   43.282096] localhost kernel: device-mapper: table: unable to determine table type
  [   43.275898] localhost multipathd[1344]: sdd: fail to get serial
  [   43.282597] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdd
  [   43.282642] localhost multipathd[1344]: uevent trigger error
  [   43.286540] localhost multipathd[1344]: sdc: fail to get serial
  [   43.296366] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
  [   43.296392] localhost kernel: device-mapper: table: unable to determine table type
  [   43.292218] localhost multipathd[1344]: mpathb: failed in domap for addition of new path sdc
  [   43.292218] localhost multipathd[1344]: uevent trigger error
  [   43.306193] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
  [   43.306212] localhost kernel: device-mapper: table: unable to determine table type
  [  150.523303] localhost dracut-initqueue[1325]: Warning: dracut-initqueue timeout - starting timeout scripts


There's more info here if you want it:
  https://github.com/linuxppc/linux/issues/203


Any ideas what's going wrong here?

cheers

Re: System not booting since dm changes? (was Linux 4.20-rc1)

[Mike Snitzer]

On Mon, Nov 05 2018 at  5:25am -0500,
Michael Ellerman <mpe@ellerman.id.au> wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> ...
> > Mike Snitzer (1):
> >     device mapper updates
> 
> Hi Mike,
> 
> Replying here because I can't find the device-mapper pull or the patch
> in question on LKML. I guess I should be subscribed to dm-devel.
> 
> We have a box that doesn't boot any more, bisect points at one of:
> 
>   cef6f55a9fb4 Mike Snitzer       dm table: require that request-based DM be layered on blk-mq devices 
>   953923c09fe8 Mike Snitzer       dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED 
>   6a23e05c2fe3 Jens Axboe         dm: remove legacy request-based IO path 
> 
> 
> It's a Power8 system running Rawhide, it does have multipath, but I'm
> told it was setup by the Fedora installer, ie. nothing fancy.
> 
> The symptom is the system can't find its root filesystem and drops into
> the initramfs shell. The dmesg includes a bunch of errors like below:
> 
>   [   43.263460] localhost multipathd[1344]: sdb: fail to get serial
>   [   43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
>   [   43.268762] localhost multipathd[1344]: uevent trigger error
>   [   43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
...
>
> Any ideas what's going wrong here?

"table load rejected: not all devices are blk-mq request-stackable"
speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).

You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
CONFIG_SCSI_MQ_DEFAULT in your kernel config)

Mike

Re: System not booting since dm changes? (was Linux 4.20-rc1)

[Satheesh Rajendran]

On Mon, Nov 05, 2018 at 08:51:57AM -0500, Mike Snitzer wrote:
> On Mon, Nov 05 2018 at  5:25am -0500,
> Michael Ellerman <mpe@ellerman.id.au> wrote:
> 
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> > ...
> > > Mike Snitzer (1):
> > >     device mapper updates
> > 
> > Hi Mike,
> > 
> > Replying here because I can't find the device-mapper pull or the patch
> > in question on LKML. I guess I should be subscribed to dm-devel.
> > 
> > We have a box that doesn't boot any more, bisect points at one of:
> > 
> >   cef6f55a9fb4 Mike Snitzer       dm table: require that request-based DM be layered on blk-mq devices 
> >   953923c09fe8 Mike Snitzer       dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED 
> >   6a23e05c2fe3 Jens Axboe         dm: remove legacy request-based IO path 
> > 
> > 
> > It's a Power8 system running Rawhide, it does have multipath, but I'm
> > told it was setup by the Fedora installer, ie. nothing fancy.
> > 
> > The symptom is the system can't find its root filesystem and drops into
> > the initramfs shell. The dmesg includes a bunch of errors like below:
> > 
> >   [   43.263460] localhost multipathd[1344]: sdb: fail to get serial
> >   [   43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
> >   [   43.268762] localhost multipathd[1344]: uevent trigger error
> >   [   43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
> ...
> >
> > Any ideas what's going wrong here?
> 
> "table load rejected: not all devices are blk-mq request-stackable"
> speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).
> 
> You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
> CONFIG_SCSI_MQ_DEFAULT in your kernel config)

Thanks Mike!, above solution worked and the system booted fine now:-)

# uname -r
4.20.0-rc1+
# cat /proc/cmdline 
root=/dev/mapper/fedora_ltc--test--ci2-root ro rd.lvm.lv=fedora_ltc-test-ci2/root rd.lvm.lv=fedora_ltc-test-ci2/swap scsi_mod.use_blk_mq=Y

CONFIG_SCSI_MQ_DEFAULT kernel was not set in my kernel config, will set in future runs.

Thanks Michael!

Regards,
-Satheesh.

> 
> Mike
> 

Re: System not booting since dm changes? (was Linux 4.20-rc1)

[Jens Axboe]

On 11/5/18 7:35 AM, Satheesh Rajendran wrote:
> On Mon, Nov 05, 2018 at 08:51:57AM -0500, Mike Snitzer wrote:
>> On Mon, Nov 05 2018 at  5:25am -0500,
>> Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>> ...
>>>> Mike Snitzer (1):
>>>>     device mapper updates
>>>
>>> Hi Mike,
>>>
>>> Replying here because I can't find the device-mapper pull or the patch
>>> in question on LKML. I guess I should be subscribed to dm-devel.
>>>
>>> We have a box that doesn't boot any more, bisect points at one of:
>>>
>>>   cef6f55a9fb4 Mike Snitzer       dm table: require that request-based DM be layered on blk-mq devices 
>>>   953923c09fe8 Mike Snitzer       dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED 
>>>   6a23e05c2fe3 Jens Axboe         dm: remove legacy request-based IO path 
>>>
>>>
>>> It's a Power8 system running Rawhide, it does have multipath, but I'm
>>> told it was setup by the Fedora installer, ie. nothing fancy.
>>>
>>> The symptom is the system can't find its root filesystem and drops into
>>> the initramfs shell. The dmesg includes a bunch of errors like below:
>>>
>>>   [   43.263460] localhost multipathd[1344]: sdb: fail to get serial
>>>   [   43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
>>>   [   43.268762] localhost multipathd[1344]: uevent trigger error
>>>   [   43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
>> ...
>>>
>>> Any ideas what's going wrong here?
>>
>> "table load rejected: not all devices are blk-mq request-stackable"
>> speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).
>>
>> You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
>> CONFIG_SCSI_MQ_DEFAULT in your kernel config)
> 
> Thanks Mike!, above solution worked and the system booted fine now:-)

This quirk will go away for the next kernel, fwiw, since the non-mq
path for SCSI will be dropped as well.

-- 
Jens Axboe

Re: Linux 4.20-rc1

[Darren Hart]

On Sun, Nov 04, 2018 at 04:12:45PM -0800, Linus Torvalds wrote:

> 
> Because yes, the merge window is two weeks, but it's two weeks partly
> exactly _because_ people (not just me) sometimes need extra time to
> resolve any possible issues, not because regular everyday pull
> requests should spread out over the whole two weeks. The development
> for things meant for the next release should have been done by the
> time the merge window opens.
> 
> Anyway, let's see. Maybe it won't be needed. It hasn't become a
> problem, it just was starting to feel a bit tight there.

I'm curious what others find to be the cause of hitting the second half
of the merge window. For my part, I have traditionally monitored the
tail end of the RC period waiting for the version tag to land. Other
times, like this time, work and travel get hectic, and I realize later
than I should that it was time to send in the PR.

I imagine many of us have just written notification scripts for version
tags, or emails from you matching certain subject patterns - but for my
part, a more predictable end of the RC period and/or an explicit email
to maintainers listed in the MAINTAINER file would be helpful. Would you
consider adding a step to your git tag process to scan the MAINTAINERS
file and send us a "Ready your PRs!" email with a note about preferring
to get these during the first week wherever possible? This seems like it
could be easily automated, easily filtered by those that might not want
it, and reduces the number of times you have to explain your preference
as new maintainers come and go.

-- 
Darren Hart
VMware Open Source Technology Center

Re: System not booting since dm changes? (was Linux 4.20-rc1)

[Michael Ellerman]

Mike Snitzer <snitzer@redhat.com> writes:
> On Mon, Nov 05 2018 at  5:25am -0500,
> Michael Ellerman <mpe@ellerman.id.au> wrote:
>
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> ...
>> > Mike Snitzer (1):
>> >     device mapper updates
>> 
>> Hi Mike,
>> 
>> Replying here because I can't find the device-mapper pull or the patch
>> in question on LKML. I guess I should be subscribed to dm-devel.
>> 
>> We have a box that doesn't boot any more, bisect points at one of:
>> 
>>   cef6f55a9fb4 Mike Snitzer       dm table: require that request-based DM be layered on blk-mq devices 
>>   953923c09fe8 Mike Snitzer       dm: rename DM_TYPE_MQ_REQUEST_BASED to DM_TYPE_REQUEST_BASED 
>>   6a23e05c2fe3 Jens Axboe         dm: remove legacy request-based IO path 
>> 
>> 
>> It's a Power8 system running Rawhide, it does have multipath, but I'm
>> told it was setup by the Fedora installer, ie. nothing fancy.
>> 
>> The symptom is the system can't find its root filesystem and drops into
>> the initramfs shell. The dmesg includes a bunch of errors like below:
>> 
>>   [   43.263460] localhost multipathd[1344]: sdb: fail to get serial
>>   [   43.268762] localhost multipathd[1344]: mpatha: failed in domap for addition of new path sdb
>>   [   43.268762] localhost multipathd[1344]: uevent trigger error
>>   [   43.282065] localhost kernel: device-mapper: table: table load rejected: not all devices are blk-mq request-stackable
> ...
>>
>> Any ideas what's going wrong here?
>
> "table load rejected: not all devices are blk-mq request-stackable"
> speaks to the fact that you aren't using blk-mq for scsi (aka scsi-mq).
>
> You need to use scsi_mod.use_blk_mq=Y on the kernel commandline (or set
> CONFIG_SCSI_MQ_DEFAULT in your kernel config)

Thanks.

Looks like CONFIG_SCSI_MQ_DEFAULT is default y, so new configs should
pick that up by default. We must have had an old .config that didn't get
that update.

cheers

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

[Stephen Rothwell]

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

Hi all,

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

(No merge commits counted, next-20181019 was the last linux-next before
the merge window opened.)

Commits in v4.20-rc1 (relative to v4.19):          12125
Commits in next-20181019:                          11296
Commits with the same SHA1:                        10466
Commits with the same patch_id:                      526 (1)
Commits with the same subject line:                   56 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20181019:     11048 91%

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

Top ten first word of commit summary:

     86 net
     60 powerpc
     56 perf
     54 media
     36 drm
     33 pci
     32 thermal
     32 bpf
     23 ubifs
     21 selftests

Top ten authors:

     36 hans.verkuil@cisco.com
     28 darrick.wong@oracle.com
     28 acme@redhat.com
     25 dhowells@redhat.com
     24 s.hauer@pengutronix.de
     23 christophe.leroy@c-s.fr
     21 kishon@ti.com
     21 davem@davemloft.net
     21 daniel@iogearbox.net
     21 bvanassche@acm.org

Top ten commiters:

    161 davem@davemloft.net
     72 mpe@ellerman.id.au
     65 acme@redhat.com
     54 mchehab+samsung@kernel.org
     41 edubezval@gmail.com
     33 lorenzo.pieralisi@arm.com
     32 broonie@kernel.org
     31 hch@lst.de
     31 ast@kernel.org
     29 richard@nod.at

There are also 250 commits in next-20181019 that didn't make it into
v4.20-rc1.

Top ten first word of commit summary:

     28 vfs
     21 mm
     18 leaking_addresses
     14 arm
     11 nfc
     10 interconnect
     10 btrfs
      9 xtensa
      7 arm-soc
      6 drm

Top ten authors:

     38 dhowells@redhat.com
     19 akpm@linux-foundation.org
     18 me@tobin.cc
     11 arnd@arndb.de
      9 jcmvbkbc@gmail.com
      9 georgi.djakov@linaro.org
      7 nborisov@suse.com
      6 hannes@cmpxchg.org
      5 wens@csie.org
      5 sfr@canb.auug.org.au

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

Top ten commiters:

     75 sfr@canb.auug.org.au
     40 dhowells@redhat.com
     18 me@tobin.cc
     13 georgi.djakov@linaro.org
     11 sameo@linux.intel.com
     10 dsterba@suse.com
      9 shuah@kernel.org
      9 jcmvbkbc@gmail.com
      7 paulmck@linux.vnet.ibm.com
      7 maxime.ripard@bootlin.com

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

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]