1. 17 4月, 2018 1 次提交
  2. 07 2月, 2018 8 次提交
  3. 06 2月, 2018 1 次提交
    • M
      powerpc, membarrier: Skip memory barrier in switch_mm() · 3ccfebed
      Mathieu Desnoyers 提交于
      Allow PowerPC to skip the full memory barrier in switch_mm(), and
      only issue the barrier when scheduling into a task belonging to a
      process that has registered to use expedited private.
      
      Threads targeting the same VM but which belong to different thread
      groups is a tricky case. It has a few consequences:
      
      It turns out that we cannot rely on get_nr_threads(p) to count the
      number of threads using a VM. We can use
      (atomic_read(&mm->mm_users) == 1 && get_nr_threads(p) == 1)
      instead to skip the synchronize_sched() for cases where the VM only has
      a single user, and that user only has a single thread.
      
      It also turns out that we cannot use for_each_thread() to set
      thread flags in all threads using a VM, as it only iterates on the
      thread group.
      
      Therefore, test the membarrier state variable directly rather than
      relying on thread flags. This means
      membarrier_register_private_expedited() needs to set the
      MEMBARRIER_STATE_PRIVATE_EXPEDITED flag, issue synchronize_sched(), and
      only then set MEMBARRIER_STATE_PRIVATE_EXPEDITED_READY which allows
      private expedited membarrier commands to succeed.
      membarrier_arch_switch_mm() now tests for the
      MEMBARRIER_STATE_PRIVATE_EXPEDITED flag.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andrea Parri <parri.andrea@gmail.com>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Avi Kivity <avi@scylladb.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Cc: David Sehr <sehr@google.com>
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maged Michael <maged.michael@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-api@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/20180129202020.8515-3-mathieu.desnoyers@efficios.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3ccfebed
  4. 05 2月, 2018 2 次提交
  5. 02 2月, 2018 1 次提交
  6. 01 2月, 2018 1 次提交
  7. 31 1月, 2018 5 次提交
  8. 29 1月, 2018 1 次提交
  9. 27 1月, 2018 4 次提交
  10. 26 1月, 2018 1 次提交
  11. 25 1月, 2018 7 次提交
  12. 23 1月, 2018 1 次提交
    • M
      MIPS: ranchu: Add Ranchu as a new generic-based board · f2d0b0d5
      Miodrag Dinic 提交于
      Provide amendments to the MIPS generic platform framework so that
      the new generic-based board Ranchu can be chosen to be built.
      
      The Ranchu board is intended to be used by Android emulator. The name
      "Ranchu" originates from Android development community. "Goldfish" and
      "Ranchu" are terms used for two generations of virtual boards used by
      Android emulator. The name "Ranchu" is a newer one among the two, and
      this patch deals with Ranchu. However, for historical reasons, some
      devices/drivers still contain the name "Goldfish".
      
      MIPS Ranchu machine includes a number of Goldfish devices. The support
      for Virtio devices is also included. Ranchu board supports up to 16
      Virtio devices which can be attached using Virtio MMIO Bus. This is
      summarized in the following picture:
      
             ABUS
              ||----MIPS CPU
              ||       |                    IRQs
              ||----Goldfish PIC------------(32)--------
              ||                     | | | | | | | | |
              ||----Goldfish TTY------ | | | | | | | |
              ||                       | | | | | | | |
              ||----Goldfish RTC-------- | | | | | | |
              ||                         | | | | | | |
              ||----Goldfish FB----------- | | | | | |
              ||                           | | | | | |
              ||----Goldfish Events--------- | | | | |
              ||                             | | | | |
              ||----Goldfish Audio------------ | | | |
              ||                               | | | |
              ||----Goldfish Battery------------ | | |
              ||                                 | | |
              ||----Android PIPE------------------ | |
              ||                                   | |
              ||----Virtio MMIO Bus                | |
              ||    |    |    |                    | |
              ||    |    |   (virtio-block)--------- |
              ||   (16)  |                           |
              ||    |   (virtio-net)------------------
      
      Device Tree is created on the QEMU side based on the information about
      devices IO map and IRQ numbers. Kernel will load this DTB using UHI
      boot protocol DTB handover mode.
      Signed-off-by: NMiodrag Dinic <miodrag.dinic@mips.com>
      Signed-off-by: NGoran Ferenc <goran.ferenc@mips.com>
      Signed-off-by: NAleksandar Markovic <aleksandar.markovic@mips.com>
      Reviewed-by: NJames Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/18138/Signed-off-by: NJames Hogan <jhogan@kernel.org>
      f2d0b0d5
  13. 22 1月, 2018 1 次提交
  14. 19 1月, 2018 1 次提交
  15. 18 1月, 2018 1 次提交
  16. 16 1月, 2018 3 次提交
    • F
      MAINTAINERS: Add NuBus subsystem entry · 2334b1ac
      Finn Thain 提交于
      This is legacy code but it might as well have an official maintainer.
      
      Cc: linux-m68k@lists.linux-m68k.org
      Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      2334b1ac
    • R
      MAINTAINERS: Remove from module & paravirt maintenance · ed875ea1
      Rusty Russell 提交于
      It's been 20 years since I became a kernel maintainer, so despite how
      much I'm loving my new career, this patch elicits deep feelings[0].
      
      I went to 1997 USENIX, my first conference.  I remember[1] standing
      around with Alan Cox, Linus, Ted Ts'o and David Miller as they wrote
      the code for the BKL on a napkin.  I listened in awe as this
      homeless-looking guy described porting Linux to the Ultrasparc, and
      then described how he then proceeded to beat Solaris on *every single*
      lmbench microbenchmark.[2]
      
      A lot of it I didn't understand, but I got home knowing that I had to
      work with this random bunch of hackers.  I had some firewalling hacks
      which I turned into ipchains, and sent it to DaveM with a config
      option to switch between the old ipfwadm code and my new code.  He
      liked it so much he replaced ipfwadm entirely, and I woke up one day
      as kernel firewall maintainer[3].
      
      I found someone to fund my work the next year, and suddenly I was
      doing my dream job full time.  I flew myself around Australia visiting
      every LUG to convince them to come to the first Australian Linux
      conference.  And of course, DaveM was top of my list for speakers.
      
      There was so much work to do on the kernel; everywhere you'd look
      there was code which could be simplified, improved.  I read the module
      code and was so horrified at its complexity that I rewrote it, not
      realizing how epic that would be.  Of course I broke lots of things;
      halfway through the patch series I broke SCSI, so Linus applied up to
      that point and we had half a module subsystem for a while; I was
      literally in the airport in Tokyo on my way to Spain when he applied
      it, too.  Every arch maintainer woke up to find they had to implement
      a whack of complex relocation code, and I got a lot of grumbling.[5]
      
      But one person disagreed with my approach so much and so continuously
      that I developed a dread of reading my mail every morning: eventually
      I wrote a filter to send their mail to a separate mbox, which I've
      still never read and don't intend to.
      
      But mainly, it was a huge amount of fun.  I got to hack, and geek out
      with hackers all around the world.  When I flew into San Jose for the
      first time, DaveM offered to pick me up: turns out he had a two seater
      so I rode squashed under the rear glass on the overside parcel shelf
      to see the sights (Sun campus, Berkeley).  Back home, I moved to
      Canberra to join the legendary group of hackers at OzLabs.
      
      The mailing list changed: I gradually learned not to be an asshole
      (unless, y'know, it was *really* funny, and eventually not even then).
      Most of my peers trended the same way.  The kernel itself became more
      formal, more complex, and giant overarching changes became far, far
      fewer.  There are still horrible APIs (the return value of
      copy_to/from_user, using the same type for list heads and elements, to
      name two[7]), but the modern calculus of disruptive changes means
      sometimes we simply step over the broken paving stones instead of
      repairing them.
      
      I built a team around netfilter, then handed maintenence off to Harald
      Welte and ceased contributing: I wanted him to own it entirely.  I was
      more nervous handing module maintenance over to someone I've never
      even met or spoken to, but it's clear now that with Jessica Yu I have
      scored 2 for 2.  I'm as proud of choosing them as of any individual
      piece of kernel code[8].
      
      To my fellow maintainers: stay harsh on code and don't be afraid to
      say "No" or "Why?"; there really are more bad ideas than good ones,
      and complexity is such a bright candle for us hacker-moths.  But be
      gentle, kind and forgiving of your peers: respect from people you
      respect is really the only reward that sticks[9].
      
      Farewell all, and I look forward to crossing your paths again!
      Rusty.
      
      [0] Which means I'm now going maudle for NINE paragraphs! And no TLDR, bwahaha!
      [1] OK, I remember this.  Reality may differ.
      [2] There's no recording of this talk, but it was the best technical
          talk anyone has ever given on anything[1].
      [3] On the internet, nobody knows you barely passed Computer Networking![4]
      [4] OTOH I topped COBOL/Database programming, so I have no idea what happened.
      [5] Except DaveM.  I'd written test reloc code for sparc/spac64, but
          he didn't know that so he just cheerfully reimplemented it.[6]
      [6] Those reading this post closely may suspect that I have a massive
          hackercrush on David S. Miller.  Those reading the code closely, of course,
          already feel that way themselves.
      [7] But set_bit finally takes a long!  Seriously...
      [8] Though the ARRAY_SIZE macro and the poetry in lguest are a close second.
      [9] Actually, bitcoin is a nice reward too; it's like crystalized machine
          sweat!
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJessica Yu <jeyu@kernel.org>
      ed875ea1
    • L
      net: ethernet: Add a driver for Gemini gigabit ethernet · 4d5ae32f
      Linus Walleij 提交于
      The Gemini ethernet has been around for years as an out-of-tree
      patch used with the NAS boxen and routers built on StorLink
      SL3512 and SL3516, later Storm Semiconductor, later Cortina
      Systems. These ASICs are still being deployed and brand new
      off-the-shelf systems using it can easily be acquired.
      
      The full name of the IP block is "Net Engine and Gigabit
      Ethernet MAC" commonly just called "GMAC".
      
      The hardware block contains a common TCP Offload Enginer (TOE)
      that can be used by both MACs. The current driver does not use
      it.
      
      Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
      Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d5ae32f
  17. 15 1月, 2018 1 次提交