Skip to content

L
linux
Switch branch/tag
  1. 12 Apr, 2019 3 commits
  3. 11 Apr, 2019 3 commits
    • Heiko Stuebner's avatar
      ARM: dts: rockchip: bulk convert gpios to their constant counterparts · 07f08d9c
      Heiko Stuebner authored 
      Rockchip SoCs use 2 different numbering schemes. Where the gpio-
controllers just count 0-31 for their 32 gpios, the underlying
iomux controller splits these into 4 separate entities A-D.

Device-schematics always use these iomux-values to identify pins,
so to make mapping schematics to devicetree easier Andy Yan introduced
named constants for the pins but so far we only used them on new
additions.

Using a sed-script created by Emil Renner Berthing bulk-convert
the remaining raw gpio numbers into their descriptive counterparts
and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x
mappings:

/rockchip,pins *=/bcheck
b # to end of script
:append-next-line
N
:check
/^[^;]*$/bappend-next-line
s/<RK_GPIO\([0-9]\) /<\1 /g
s/<\([^ ][^ ]*  *\)0 /<\1RK_PA0 /g
s/<\([^ ][^ ]*  *\)1 /<\1RK_PA1 /g
s/<\([^ ][^ ]*  *\)2 /<\1RK_PA2 /g
s/<\([^ ][^ ]*  *\)3 /<\1RK_PA3 /g
s/<\([^ ][^ ]*  *\)4 /<\1RK_PA4 /g
s/<\([^ ][^ ]*  *\)5 /<\1RK_PA5 /g
s/<\([^ ][^ ]*  *\)6 /<\1RK_PA6 /g
s/<\([^ ][^ ]*  *\)7 /<\1RK_PA7 /g
s/<\([^ ][^ ]*  *\)8 /<\1RK_PB0 /g
s/<\([^ ][^ ]*  *\)9 /<\1RK_PB1 /g
s/<\([^ ][^ ]*  *\)10 /<\1RK_PB2 /g
s/<\([^ ][^ ]*  *\)11 /<\1RK_PB3 /g
s/<\([^ ][^ ]*  *\)12 /<\1RK_PB4 /g
s/<\([^ ][^ ]*  *\)13 /<\1RK_PB5 /g
s/<\([^ ][^ ]*  *\)14 /<\1RK_PB6 /g
s/<\([^ ][^ ]*  *\)15 /<\1RK_PB7 /g
s/<\([^ ][^ ]*  *\)16 /<\1RK_PC0 /g
s/<\([^ ][^ ]*  *\)17 /<\1RK_PC1 /g
s/<\([^ ][^ ]*  *\)18 /<\1RK_PC2 /g
s/<\([^ ][^ ]*  *\)19 /<\1RK_PC3 /g
s/<\([^ ][^ ]*  *\)20 /<\1RK_PC4 /g
s/<\([^ ][^ ]*  *\)21 /<\1RK_PC5 /g
s/<\([^ ][^ ]*  *\)22 /<\1RK_PC6 /g
s/<\([^ ][^ ]*  *\)23 /<\1RK_PC7 /g
s/<\([^ ][^ ]*  *\)24 /<\1RK_PD0 /g
s/<\([^ ][^ ]*  *\)25 /<\1RK_PD1 /g
s/<\([^ ][^ ]*  *\)26 /<\1RK_PD2 /g
s/<\([^ ][^ ]*  *\)27 /<\1RK_PD3 /g
s/<\([^ ][^ ]*  *\)28 /<\1RK_PD4 /g
s/<\([^ ][^ ]*  *\)29 /<\1RK_PD5 /g
s/<\([^ ][^ ]*  *\)30 /<\1RK_PD6 /g
s/<\([^ ][^ ]*  *\)31 /<\1RK_PD7 /g
s/<\([^ ][^ ]*  *[^ ][^ ]*  *\)0 /<\1RK_FUNC_GPIO /g
s/<\([^ ][^ ]*  *[^ ][^ ]*  *\)RK_FUNC_\([1-9]\) /<\1\2 /g
Suggested-by: default avatarEmil Renner Berthing <esmil@mailme.dk>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      07f08d9c
    • Matthias Kaehlcke's avatar
      ARM: dts: rockchip: Add BT_EN to the power sequence for veyron · 280fa349
      Matthias Kaehlcke authored 
      Add GPIO D5 (BT_ENABLE_L) as reset-GPIO to the power sequence for the
Bluetooth/WiFi module. On devices with a Broadcom module the signal
needs to be asserted to use Bluetooth.

Note that BT_ENABLE_L is a misnomer in the schematics, the signal
actually is active-high.
Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      280fa349
    • Matthias Kaehlcke's avatar
      ARM: dts: rockchip: Remove unnecessary setting of UART0 SCLK rate on veyron · 2f60eb2f
      Matthias Kaehlcke authored 
      Some veyron devices have a Bluetooth controller connected on UART0.
The UART needs to operate at a high speed, however setting the clock
rate at initialization has no practical effect. During initialization
user space adjusts the UART baudrate multiple times, which ends up
changing the SCLK rate. After a successful initiatalization the clk
is running at the desired speed (48MHz).

Remove the unnecessary clock rate configuration from the DT.
Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      2f60eb2f
  5. 31 Mar, 2019 2 commits
  7. 27 Mar, 2019 2 commits
  9. 25 Mar, 2019 4 commits
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Add vdd_logic to rk3288-veyron · 864c2fee
      Douglas Anderson authored 
      The vdd_logic rail controls the voltage supplied to misc logic on
rk3288, including the voltage supplied to the memory controller.  The
vcc logic is implemented by a PWM regulator.

Right now there are no consumers of vdd_logic on veyron but if anyone
ever wants to try to add DDR Freq they'd need it.

Note that in the downstream Chrome OS kernel the PWM regulator has
a voltage table with these points:
  1350000 0%
  1300000 10%
  1250000 20%
  1200000 31%
  1150000 41%
  1125000 46%
  1100000 52%
  1050000 62%
  1000000 72%
   950000 83%

The DDR Freq driver in the downstream kernel only uses some of those
points, namely:
  DDR3:  1200000, 1150000, 1100000, 1050000
  LPDDR:          1150000, 1100000, 1050000

When adapting the downstream kernel to upstream I have opted to switch
to using the "continuous" mode of the PWM regulator driver.  This was
the only way I could get the upstream driver to achieve _exactly_ the
same voltages as the downstream driver could.  Specifically note that
the old driver in downstream Chrome OS 3.14 _didn't_ have the
DIV_ROUND_CLOSEST_ULL() in the Rockchip PLL driver.  That means if I
use the same (downstream) table I might end up with a duty cycle
that's 1 larger than was used downstream, leading to a slightly
different voltage.  Due to the way the rounding worked I couldn't even
just adjust the "percent" by 1 for a given voltage level--certain duty
cycles just aren't achievable with the upstream math for voltage
tables.

Using continuous mode you can achieve the exact same duty cycle by
simply adjusting the voltage you use by a tad bit.  The voltages that
are equivalent to the ones used in the downstream kernel's table are:
  1350000, 1304472, 1255691, 1200407, 1154878,
  1128862, 1099593, 1050813, 1005285, 950000

Note that the top/bottom voltage is exactly the same just due to the
way that continuous mode is calculated and the fact that I used those
as anchors.  I didn't make any attempt to do the resistor math (as was
done on rk3399-gru).

If anyone ever gets DDRFreq working on veyron upstream they should
thus adjust the voltage specified in the DDRFreq operating points
slightly (as per the above) to obtain the existing/tested values.  AKA
you'd use:
  DDR3:  1200407, 1154878, 1099593, 1050813
  LPDDR:          1154878, 1099593, 1050813

A few other notes:
- The "period" here (1994) is different than the "period" downstream
  (2000) for similar reasons: there's a DIV_ROUND_CLOSEST_ULL() that
  wasn't downstream.  With 1994 upstream comes up with the same value
  (0x94) to program into the hardware that downstream put there.  As
  far as I can tell 0x94 actually means 1993.27.
- The duty cycle unit of 0x94 was picked by just matching the period
  which nicely allows us to insert 0x7b as that value to program into
  the hardware for 950mV.  The 0x7b was found by observing what the
  downstream kernel calculated (not that the system can actually run
  with vdd_log at 950 mV).
- The downstream kernel can also be seen to program a different value
  into the CTRL field.  Upstream achieves 0x0b and downstream 0x1b.
  This is because the upstream commit bc834d7b ("pwm: rockchip:
  Move the configuration of polarity") fixed a bug by adding "ctrl &=
  ~PWM_POLARITY_MASK".  Downstream accidentally left bit 4 set.
  Luckily this bit doesn't matter--it's only used when the PWM goes
  inactive (AKA if it's in oneshot mode or is disabled) and we don't
  do that for the PWM regulator.

I measured the voltage of vdd_log while adjusting it and found that
with the upstream kernel voltage difference between requested and
actual was 9.2 mV at 950 mV and 13.4 mV at 1350 mV with in-between
voltages consistently showing ~1% error.  This error is likely
expected as voltage can be seen to sag a bit when more load is put on
the rail.
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      864c2fee
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Add dvs-gpios to rk3288-veyron-jerry · 21f843ff
      Douglas Anderson authored 
      When the rk3288-jerry device tree was first submitted we left out the
dvs-gpios because I pointed out that the property "dvs-gpios" wasn't
yet supported upstream [1].  Soon after that the property was added in
commit bad47ad2 ("regulator: rk808: fixed the overshoot when
adjust voltage").  ...but we forgot to go back and add the property to
the jerry device tree file.  Let's do so now.

NOTE: without this patch, jerry is likely still stable (thanks to the
fallback of making many small jumps in the rk808 regulator code) but
it'll take quite a bit longer to make voltage transitions.

[1] https://lore.kernel.org/linux-arm-kernel/CAD=FV=WwFgjzbk9xF5TU_ie6UnHQMyrZ176D4+jJTWWOoaKC2Q@mail.gmail.com/

Fixes: f3ee390e ("ARM: dts: rockchip: add veyron-jerry board")
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      21f843ff
    • Douglas Anderson's avatar
      ARM: dts: rockchip: Add rk3288-veyron-jerry rev 10-15 · 0c4cac5e
      Douglas Anderson authored 
      As far as I can tell/remember rev10 was originally created to support
making a SKU of jerry that had a different LCD.  rev11-rev15 were
added to give some wiggle room for future builds.  Downstream has a
separate device tree for rev10-rev15 (compared to rev3-rev7) with the
expectation that differences relating to the LCD would be accounted
for there but nothing was ever added to the rev10-rev15 making it
identical to the rev3-rev7 one.

It's likely nothing actually shipped with rev10-rev15 but they are
listed in the downstream kernel's device tree and it seems like it
should add a little safety if we match them here just in case
something actually shipped with one of these revisions and that device
will break if we don't claim support.
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      0c4cac5e
    • Douglas Anderson's avatar
      dt-bindings: ARM: dts: rockchip: Add rk3288-veyron-jerry rev 10-15 · 4e92348d
      Douglas Anderson authored 
      As far as I can tell/remember rev10 was originally created to support
making a SKU of jerry that had a different LCD.  rev11-rev15 were
added to give some wiggle room for future builds.  Downstream has a
separate device tree for rev10-rev15 (compared to rev3-rev7) with the
expectation that differences relating to the LCD would be accounted
for there but nothing was ever added to the rev10-rev15 making it
identical to the rev3-rev7 one.

It's likely nothing actually shipped with rev10-rev15 but they are
listed in the downstream kernel's device tree and it seems like it
should add a little safety if we match them here just in case
something actually shipped with one of these revisions and that device
will break if we don't claim support.
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      4e92348d
  11. 21 Mar, 2019 1 commit
  13. 18 Mar, 2019 4 commits
  15. 17 Mar, 2019 14 commits
  17. 16 Mar, 2019 7 commits
    • Linus Torvalds's avatar
      Merge tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux · a9dce667
      Linus Torvalds authored 
      Pull pidfd system call from Christian Brauner:
 "This introduces the ability to use file descriptors from /proc/<pid>/
  as stable handles on struct pid. Even if a pid is recycled the handle
  will not change. For a start these fds can be used to send signals to
  the processes they refer to.

  With the ability to use /proc/<pid> fds as stable handles on struct
  pid we can fix a long-standing issue where after a process has exited
  its pid can be reused by another process. If a caller sends a signal
  to a reused pid it will end up signaling the wrong process.

  With this patchset we enable a variety of use cases. One obvious
  example is that we can now safely delegate an important part of
  process management - sending signals - to processes other than the
  parent of a given process by sending file descriptors around via scm
  rights and not fearing that the given process will have been recycled
  in the meantime. It also allows for easy testing whether a given
  process is still alive or not by sending signal 0 to a pidfd which is
  quite handy.

  There has been some interest in this feature e.g. from systems
  management (systemd, glibc) and container managers. I have requested
  and gotten comments from glibc to make sure that this syscall is
  suitable for their needs as well. In the future I expect it to take on
  most other pid-based signal syscalls. But such features are left for
  the future once they are needed.

  This has been sitting in linux-next for quite a while and has not
  caused any issues. It comes with selftests which verify basic
  functionality and also test that a recycled pid cannot be signaled via
  a pidfd.

  Jon has written about a prior version of this patchset. It should
  cover the basic functionality since not a lot has changed since then:

      https://lwn.net/Articles/773459/

  The commit message for the syscall itself is extensively documenting
  the syscall, including it's functionality and extensibility"

* tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
  selftests: add tests for pidfd_send_signal()
  signal: add pidfd_send_signal() syscall
      a9dce667
    • Linus Torvalds's avatar
      Merge tag 'devdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · f67e3fb4
      Linus Torvalds authored 
      Pull device-dax updates from Dan Williams:
 "New device-dax infrastructure to allow persistent memory and other
  "reserved" / performance differentiated memories, to be assigned to
  the core-mm as "System RAM".

  Some users want to use persistent memory as additional volatile
  memory. They are willing to cope with potential performance
  differences, for example between DRAM and 3D Xpoint, and want to use
  typical Linux memory management apis rather than a userspace memory
  allocator layered over an mmap() of a dax file. The administration
  model is to decide how much Persistent Memory (pmem) to use as System
  RAM, create a device-dax-mode namespace of that size, and then assign
  it to the core-mm. The rationale for device-dax is that it is a
  generic memory-mapping driver that can be layered over any "special
  purpose" memory, not just pmem. On subsequent boots udev rules can be
  used to restore the memory assignment.

  One implication of using pmem as RAM is that mlock() no longer keeps
  data off persistent media. For this reason it is recommended to enable
  NVDIMM Security (previously merged for 5.0) to encrypt pmem contents
  at rest. We considered making this recommendation an actively enforced
  requirement, but in the end decided to leave it as a distribution /
  administrator policy to allow for emulation and test environments that
  lack security capable NVDIMMs.

  Summary:

   - Replace the /sys/class/dax device model with /sys/bus/dax, and
     include a compat driver so distributions can opt-in to the new ABI.

   - Allow for an alternative driver for the device-dax address-range

   - Introduce the 'kmem' driver to hotplug / assign a device-dax
     address-range to the core-mm.

   - Arrange for the device-dax target-node to be onlined so that the
     newly added memory range can be uniquely referenced by numa apis"

NOTE! I'm not entirely happy with the whole "PMEM as RAM" model because
we currently have special - and very annoying rules in the kernel about
accessing PMEM only with the "MC safe" accessors, because machine checks
inside the regular repeat string copy functions can be fatal in some
(not described) circumstances.

And apparently the PMEM modules can cause that a lot more than regular
RAM.  The argument is that this happens because PMEM doesn't necessarily
get scrubbed at boot like RAM does, but that is planned to be added for
the user space tooling.

Quoting Dan from another email:
 "The exposure can be reduced in the volatile-RAM case by scanning for
  and clearing errors before it is onlined as RAM. The userspace tooling
  for that can be in place before v5.1-final. There's also runtime
  notifications of errors via acpi_nfit_uc_error_notify() from
  background scrubbers on the DIMM devices. With that mechanism the
  kernel could proactively clear newly discovered poison in the volatile
  case, but that would be additional development more suitable for v5.2.

  I understand the concern, and the need to highlight this issue by
  tapping the brakes on feature development, but I don't see PMEM as RAM
  making the situation worse when the exposure is also there via DAX in
  the PMEM case. Volatile-RAM is arguably a safer use case since it's
  possible to repair pages where the persistent case needs active
  application coordination"

* tag 'devdax-for-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  device-dax: "Hotplug" persistent memory for use like normal RAM
  mm/resource: Let walk_system_ram_range() search child resources
  mm/memory-hotplug: Allow memory resources to be children
  mm/resource: Move HMM pr_debug() deeper into resource code
  mm/resource: Return real error codes from walk failures
  device-dax: Add a 'modalias' attribute to DAX 'bus' devices
  device-dax: Add a 'target_node' attribute
  device-dax: Auto-bind device after successful new_id
  acpi/nfit, device-dax: Identify differentiated memory with a unique numa-node
  device-dax: Add /sys/class/dax backwards compatibility
  device-dax: Add support for a dax override driver
  device-dax: Move resource pinning+mapping into the common driver
  device-dax: Introduce bus + driver model
  device-dax: Start defining a dax bus model
  device-dax: Remove multi-resource infrastructure
  device-dax: Kill dax_region base
  device-dax: Kill dax_region ida
      f67e3fb4
    • Linus Torvalds's avatar
      Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 477558d7
      Linus Torvalds authored 
      Pull more SCSI updates from James Bottomley:
 "This is the final round of mostly small fixes and performance
  improvements to our initial submit.

  The main regression fix is the ia64 simscsi build failure which was
  missed in the serial number elimination conversion"

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (24 commits)
  scsi: ia64: simscsi: use request tag instead of serial_number
  scsi: aacraid: Fix performance issue on logical drives
  scsi: lpfc: Fix error codes in lpfc_sli4_pci_mem_setup()
  scsi: libiscsi: Hold back_lock when calling iscsi_complete_task
  scsi: hisi_sas: Change SERDES_CFG init value to increase reliability of HiLink
  scsi: hisi_sas: Send HARD RESET to clear the previous affiliation of STP target port
  scsi: hisi_sas: Set PHY linkrate when disconnected
  scsi: hisi_sas: print PHY RX errors count for later revision of v3 hw
  scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO
  scsi: hisi_sas: Change return variable type in phy_up_v3_hw()
  scsi: qla2xxx: check for kstrtol() failure
  scsi: lpfc: fix 32-bit format string warning
  scsi: lpfc: fix unused variable warning
  scsi: target: tcmu: Switch to bitmap_zalloc()
  scsi: libiscsi: fall back to sendmsg for slab pages
  scsi: qla2xxx: avoid printf format warning
  scsi: lpfc: resolve static checker warning in lpfc_sli4_hba_unset
  scsi: lpfc: Correct __lpfc_sli_issue_iocb_s4 lockdep check
  scsi: ufs: hisi: fix ufs_hba_variant_ops passing
  scsi: qla2xxx: Fix panic in qla_dfs_tgt_counters_show
  ...
      477558d7
    • Linus Torvalds's avatar
      Merge tag 'for-5.1/block-post-20190315' of git://git.kernel.dk/linux-block · 11efae35
      Linus Torvalds authored 
      Pull more block layer changes from Jens Axboe:
 "This is a collection of both stragglers, and fixes that came in after
  I finalized the initial pull. This contains:

   - An MD pull request from Song, with a few minor fixes

   - Set of NVMe patches via Christoph

   - Pull request from Konrad, with a few fixes for xen/blkback

   - pblk fix IO calculation fix (Javier)

   - Segment calculation fix for pass-through (Ming)

   - Fallthrough annotation for blkcg (Mathieu)"

* tag 'for-5.1/block-post-20190315' of git://git.kernel.dk/linux-block: (25 commits)
  blkcg: annotate implicit fall through
  nvme-tcp: support C2HData with SUCCESS flag
  nvmet: ignore EOPNOTSUPP for discard
  nvme: add proper write zeroes setup for the multipath device
  nvme: add proper discard setup for the multipath device
  nvme: remove nvme_ns_config_oncs
  nvme: disable Write Zeroes for qemu controllers
  nvmet-fc: bring Disconnect into compliance with FC-NVME spec
  nvmet-fc: fix issues with targetport assoc_list list walking
  nvme-fc: reject reconnect if io queue count is reduced to zero
  nvme-fc: fix numa_node when dev is null
  nvme-fc: use nr_phys_segments to determine existence of sgl
  nvme-loop: init nvmet_ctrl fatal_err_work when allocate
  nvme: update comment to make the code easier to read
  nvme: put ns_head ref if namespace fails allocation
  nvme-trace: fix cdw10 buffer overrun
  nvme: don't warn on block content change effects
  nvme: add get-feature to admin cmds tracer
  md: Fix failed allocation of md_register_thread
  It's wrong to add len to sector_nr in raid10 reshape twice
  ...
      11efae35
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-5.1-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs · 465c209d
      Linus Torvalds authored 
      Pull NFS client bugfixes from Trond Myklebust:
 "Highlights include:

  Bugfixes:
   - Fix an Oops in SUNRPC back channel tracepoints
   - Fix a SUNRPC client regression when handling oversized replies
   - Fix the minimal size for SUNRPC reply buffer allocation
   - rpc_decode_header() must always return a non-zero value on error
   - Fix a typo in pnfs_update_layout()

  Cleanup:
   - Remove redundant check for the reply length in call_decode()"

* tag 'nfs-for-5.1-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  SUNRPC: Remove redundant check for the reply length in call_decode()
  SUNRPC: Handle the SYSTEM_ERR rpc error
  SUNRPC: rpc_decode_header() must always return a non-zero value on error
  SUNRPC: Use the ENOTCONN error on socket disconnect
  SUNRPC: Fix the minimal size for reply buffer allocation
  SUNRPC: Fix a client regression when handling oversized replies
  pNFS: Fix a typo in pnfs_update_layout
  fix null pointer deref in tracepoints in back channel
      465c209d
    • Linus Torvalds's avatar
      Merge tag 'powerpc-5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · a9c55d58
      Linus Torvalds authored 
      Pull powerpc fixes from Michael Ellerman:
 "One fix to prevent runtime allocation of 16GB pages when running in a
  VM (as opposed to bare metal), because it doesn't work.

  A small fix to our recently added KCOV support to exempt some more
  code from being instrumented.

  Plus a few minor build fixes, a small dead code removal and a
  defconfig update.

  Thanks to: Alexey Kardashevskiy, Aneesh Kumar K.V, Christophe Leroy,
  Jason Yan, Joel Stanley, Mahesh Salgaonkar, Mathieu Malaterre"

* tag 'powerpc-5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/64s: Include <asm/nmi.h> header file to fix a warning
  powerpc/powernv: Fix compile without CONFIG_TRACEPOINTS
  powerpc/mm: Disable kcov for SLB routines
  powerpc: remove dead code in head_fsl_booke.S
  powerpc/configs: Sync skiroot defconfig
  powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration
      a9c55d58
    • Linus Torvalds's avatar
      Merge branch 'work.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 92497350
      Linus Torvalds authored 
      Pull vfs mount infrastructure fix from Al Viro:
 "Fixup for sysfs braino.

  Capabilities checks for sysfs mount do include those on netns, but
  only if CONFIG_NET_NS is enabled. Sorry, should've caught that
  earlier..."

* 'work.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  fix sysfs_init_fs_context() in !CONFIG_NET_NS case
      92497350
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7