Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
  • Abel Vesa Abel Vesa abel.vesa
  • Alexey Klimov Alexey Klimov alexey.klimov
  • Bartosz Golaszewski Bartosz Golaszewski bartosz_golaszewski
  • Bryan O'Donoghue Bryan O'Donoghue bryan.odonoghue
  • Casey Connolly Casey Connolly casey_connolly
  • Chetan Sharma Chetan Sharma chetan_sharma
  • Christopher Obbard Christopher Obbard christopher.obbard
  • CodeLinaro CodeLinaro codelinaro
  • Dmitry Baryshkov Dmitry Baryshkov dmitry.baryshkov
  • Ettore Chimenti Ettore Chimenti ettore.chimenti
  • Eugen Hristev Eugen Hristev eugen.hristev
  • Joshua Sickmeyer Joshua Sickmeyer joshua.sickmeyer
  • Jun Nie Jun Nie jun_nie
  • Krzysztof Krzysztof krzysztof.kozlowski
  • Mani Sadhasivam Mani Sadhasivam manivannan.sadhasivam
  • Neil Armstrong Neil Armstrong neil.armstrong
  • Paul Neuhardt Paul Neuhardt paul.neuhardt
  • QCLT Bot Service Account QCLT Bot Service Account qclt-bot
  • Rui Silva Rui Silva rui_silva
  • Srini Kandagatla Srini Kandagatla srinivas.kandagatla
20 authors
  1. Aug 09, 2018
    • Hans de Goede's avatar
      platform/x86: Add ACPI i2c-multi-instantiate pseudo driver · e64e8498
      Hans de Goede authored 
      
On systems with ACPI instantiated i2c-clients, normally there is 1 fw_node
per i2c-device and that fw-node contains 1 I2cSerialBus resource for that 1
i2c-device.

But in some rare cases the manufacturer has decided to describe multiple
i2c-devices in a single ACPI fwnode with multiple I2cSerialBus resources.

An earlier attempt to fix this in the i2c-core resulted in a lot of extra
code to support this corner-case.

This commit introduces a new i2c-multi-instantiate driver which fixes this
in a different way. This new driver can be built as a module which will
only loaded on affected systems.

This driver will instantiate a new i2c-client per I2cSerialBus resource,
using the driver_data from the acpi_device_id it is binding to to tell it
which chip-type (and optional irq-resource) to use when instantiating.

Note this driver depends on a platform device being instantiated for the
ACPI fwnode, see the i2c_multi_instantiate_ids list of ACPI device-ids in
drivers/acpi/scan.c: acpi_device_enumeration_by_parent().

Acked-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: default avatarWolfram Sang <wsa@the-dreams.de>
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e64e8498
  3. Jul 24, 2018
  5. Jul 21, 2018
  7. Jul 18, 2018
  9. Jul 10, 2018
  11. Jul 09, 2018
  13. Jul 06, 2018
  15. Jul 05, 2018
  17. Jul 04, 2018
  19. Jun 28, 2018
  21. Jun 27, 2018
  23. Jun 23, 2018
  25. Jun 22, 2018
  27. Jun 19, 2018
  29. Jun 18, 2018
  31. Jun 15, 2018
  33. Jun 14, 2018
    • Christoph Hellwig's avatar
      dma-mapping: move all DMA mapping code to kernel/dma · cf65a0f6
      Christoph Hellwig authored 
      
Currently the code is split over various files with dma- prefixes in the
lib/ and drives/base directories, and the number of files keeps growing.
Move them into a single directory to keep the code together and remove
the file name prefixes.  To match the irq infrastructure this directory
is placed under the kernel/ directory.

Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      cf65a0f6
  35. Jun 11, 2018
  37. Jun 10, 2018
  39. Jun 08, 2018
  41. Jun 06, 2018
    • Mathieu Desnoyers's avatar
      rseq/selftests: Provide Makefile, scripts, gitignore · ccba8b64
      Mathieu Desnoyers authored 
      
A run_param_test.sh script runs many variants of the parametrizable
tests.

Wire up the rseq Makefile, add directory entry into MAINTAINERS file.

Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Watson <davejwatson@fb.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: linux-kselftest@vger.kernel.org
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Chris Lameter <cl@linux.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Hunter <ahh@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ben Maurer <bmaurer@fb.com>
Cc: linux-api@vger.kernel.org
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lkml.kernel.org/r/20180602124408.8430-17-mathieu.desnoyers@efficios.com
      ccba8b64
    • Mathieu Desnoyers's avatar
      rseq: Introduce restartable sequences system call · d7822b1e
      Mathieu Desnoyers authored 
      Expose a new system call allowing each thread to register one userspace
memory area to be used as an ABI between kernel and user-space for two
purposes: user-space restartable sequences and quick access to read the
current CPU number value from user-space.

* Restartable sequences (per-cpu atomics)

Restartables sequences allow user-space to perform update operations on
per-cpu data without requiring heavy-weight atomic operations.

The restartable critical sections (percpu atomics) work has been started
by Paul Turner and Andrew Hunter. It lets the kernel handle restart of
critical sections. [1] [2] The re-implementation proposed here brings a
few simplifications to the ABI which facilitates porting to other
architectures and speeds up the user-space fast path.

Here are benchmarks of various rseq use-cases.

Test hardware:

arm32: ARMv7 Processor rev 4 (v7l) "Cubietruck", 2-core
x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading

The following benchmarks were all performed on a single thread.

* Per-CPU statistic counter increment

                getcpu+atomic (ns/op)    rseq (ns/op)    speedup
arm32:                344.0                 31.4          11.0
x86-64:                15.3                  2.0           7.7

* LTTng-UST: write event 32-bit header, 32-bit payload into tracer
             per-cpu buffer

                getcpu+atomic (ns/op)    rseq (ns/op)    speedup
arm32:               2502.0                 2250.0         1.1
x86-64:               117.4                   98.0         1.2

* liburcu percpu: lock-unlock pair, dereference, read/compare word

                getcpu+atomic (ns/op)    rseq (ns/op)    speedup
arm32:                751.0                 128.5          5.8
x86-64:                53.4                  28.6          1.9

* jemalloc memory allocator adapted to use rseq

Using rseq with per-cpu memory pools in jemalloc at Facebook (based on
rseq 2016 implementation):

The production workload response-time has 1-2% gain avg. latency, and
the P99 overall latency drops by 2-3%.

* Reading the current CPU number

Speeding up reading the current CPU number on which the caller thread is
running is done by keeping the current CPU number up do date within the
cpu_id field of the memory area registered by the thread. This is done
by making scheduler preemption set the TIF_NOTIFY_RESUME flag on the
current thread. Upon return to user-space, a notify-resume handler
updates the current CPU value within the registered user-space memory
area. User-space can then read the current CPU number directly from
memory.

Keeping the current cpu id in a memory area shared between kernel and
user-space is an improvement over current mechanisms available to read
the current CPU number, which has the following benefits over
alternative approaches:

- 35x speedup on ARM vs system call through glibc
- 20x speedup on x86 compared to calling glibc, which calls vdso
  executing a "lsl" instruction,
- 14x speedup on x86 compared to inlined "lsl" instruction,
- Unlike vdso approaches, this cpu_id value can be read from an inline
  assembly, which makes it a useful building block for restartable
  sequences.
- The approach of reading the cpu id through memory mapping shared
  between kernel and user-space is portable (e.g. ARM), which is not the
  case for the lsl-based x86 vdso.

On x86, yet another possible approach would be to use the gs segment
selector to point to user-space per-cpu data. This approach performs
similarly to the cpu id cache, but it has two disadvantages: it is
not portable, and it is incompatible with existing applications already
using the gs segment selector for other purposes.

Benchmarking various approaches for reading the current CPU number:

ARMv7 Processor rev 4 (v7l)
Machine model: Cubietruck
- Baseline (empty loop):                                    8.4 ns
- Read CPU from rseq cpu_id:                               16.7 ns
- Read CPU from rseq cpu_id (lazy register):               19.8 ns
- glibc 2.19-0ubuntu6.6 getcpu:                           301.8 ns
- getcpu system call:                                     234.9 ns

x86-64 Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz:
- Baseline (empty loop):                                    0.8 ns
- Read CPU from rseq cpu_id:                                0.8 ns
- Read CPU from rseq cpu_id (lazy register):                0.8 ns
- Read using gs segment selector:                           0.8 ns
- "lsl" inline assembly:                                   13.0 ns
- glibc 2.19-0ubuntu6 getcpu:                              16.6 ns
- getcpu system call:                                      53.9 ns

- Speed (benchmark taken on v8 of patchset)

Running 10 runs of hackbench -l 100000 seems to indicate, contrary to
expectations, that enabling CONFIG_RSEQ slightly accelerates the
scheduler:

Configuration: 2 sockets * 8-core Intel(R) Xeon(R) CPU E5-2630 v3 @
2.40GHz (directly on hardware, hyperthreading disabled in BIOS, energy
saving disabled in BIOS, turboboost disabled in BIOS, cpuidle.off=1
kernel parameter), with a Linux v4.6 defconfig+localyesconfig,
restartable sequences series applied.

* CONFIG_RSEQ=n

avg.:      41.37 s
std.dev.:   0.36 s

* CONFIG_RSEQ=y

avg.:      40.46 s
std.dev.:   0.33 s

- Size

On x86-64, between CONFIG_RSEQ=n/y, the text size increase of vmlinux is
567 bytes, and the data size increase of vmlinux is 5696 bytes.

[1] https://lwn.net/Articles/650333/
[2] http://www.linuxplumbersconf.org/2013/ocw/system/presentations/1695/original/LPC%20-%20PerCpu%20Atomics.pdf



Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Watson <davejwatson@fb.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Chris Lameter <cl@linux.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Andrew Hunter <ahh@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Ben Maurer <bmaurer@fb.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-api@vger.kernel.org
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20151027235635.16059.11630.stgit@pjt-glaptop.roam.corp.google.com
Link: http://lkml.kernel.org/r/20150624222609.6116.86035.stgit@kitami.mtv.corp.google.com
Link: https://lkml.kernel.org/r/20180602124408.8430-3-mathieu.desnoyers@efficios.com
      d7822b1e
  43. Jun 05, 2018
    • Greg Kroah-Hartman's avatar
      staging: lustre: delete the filesystem from the tree. · be65f9ed
      Greg Kroah-Hartman authored 
      
The Lustre filesystem has been in the kernel tree for over 5 years now.
While it has been an endless source of enjoyment for new kernel
developers learning how to do basic codingstyle cleanups, as well as an
semi-entertaining source of bewilderment from the vfs developers any
time they have looked into the codebase to try to figure out how to port
their latest api changes to this filesystem, it has not really moved
forward into the "this is in shape to get out of staging" despite many
half-completed attempts.

And getting code out of staging is the main goal of that portion of the
kernel tree.  Code should not stagnate and it feels like having this
code in staging is only causing the development cycle of the filesystem
to take longer than it should.  There is a whole separate out-of-tree
copy of this codebase where the developers work on it, and then random
changes are thrown over the wall at staging at some later point in time.
This dual-tree development model has never worked, and the state of this
codebase is proof of that.

So, let's just delete the whole mess.  Now the lustre developers can go
off and work in their out-of-tree codebase and not have to worry about
providing valid changelog entries and breaking their patches up into
logical pieces.  They can take the time they have spend doing those
types of housekeeping chores and get the codebase into a much better
shape, and it can be submitted for inclusion into the real part of the
kernel tree when ready.

Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: Andreas Dilger <andreas.dilger@intel.com>
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be65f9ed
    • Josh Poimboeuf's avatar
      MAINTAINERS: add Josh Poimboeuf as faddr2line maintainer · 2562c011
      Josh Poimboeuf authored 
      
... so I finally get credit for my greatest accomplishment.

And, less importantly, so get_maintainer.pl will actually CC me on
future patches.

Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2562c011
  45. Jun 04, 2018
    • Palmer Dabbelt's avatar
      MAINTAINERS: Update Albert's email, he's back at Berkeley · 9c521764
      Palmer Dabbelt authored 
      
When I was adding a MAINTAINERS entry for SiFive's drivers I realized
that Albert's email is out of date -- he's gone back to Berkeley, so his
SiFive email is technically defunct.  This patch updates his entry to a
current email address, hosted at Berkeley.

Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      9c521764
    • Palmer Dabbelt's avatar
      MAINTAINERS: Add myself as a maintainer for SiFive's drivers · 3ed45d7f
      Palmer Dabbelt authored 
      
There aren't actually any files in the tree that match these patterns
right now, but we've just started submitting our drivers so I thought it
would be good to make sure there's at least someone at SiFive who's
listed as maintaining them.  I'm leaving the RISC-V lists on here
because:

* As of today, all the RISC-V ASICs that people can actually buy are
  from SiFive -- though hopefully there'll be more soon!
* The RTL for many of our devices is open source, so I anticipate these
  devices might make they way chips from other vendors.
* We may standardize some of these devices as part of a RISC-V
  specification at some point in the future.

I'm a bit swamped right now so I might not be the most active maintainer
of these drivers, but I think it'd be good to make sure someone who has
hardware access gets CC'd on updates to our drivers just as a sanity
check.  Hopefully that's an OK way to handle this.

Signed-off-by: default avatarPalmer Dabbelt <palmer@sifive.com>
      3ed45d7f
    • Jeff Kirsher's avatar
      Documentation: e1000: Update kernel documentation · 228046e7
      Jeff Kirsher authored 
      
Updated the e1000.txt kernel documentation with the latest information.

Also convert the text file to reStructuredText (RST) format, since the
Linux kernel documentation now uses this format for documentation.

Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      228046e7
    • Jeff Kirsher's avatar
      Documentation: e100: Update the Intel 10/100 driver doc · 85d63445
      Jeff Kirsher authored 
      
Over the years, several of the links have changed or are no longer valid
so update them.  In addition, the default values were incorrect for a
couple of parameters.

Converted the text file to the reStructuredText (RST) format, since the
Linux kernel documentation now uses this format for documentation.

Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      85d63445