Commit graph

65589 commits

Author SHA1 Message Date
John Hubbard
4fae927978 phy: fix build breakage: add PHY_MODE_SATA
Commit 49e54187ae ("ata: libahci_platform: comply to PHY framework") uses
the PHY_MODE_SATA, but that enum had not yet been added. This caused a
build failure for me, with today's linux.git.

Also, there is a potentially conflicting (mis-named) PHY_MODE_SATA, hiding
in the Marvell Berlin SATA PHY driver.

Fix the build by:

    1) Renaming Marvell's defined value to a more scoped name,
       in order to avoid any potential conflicts: PHY_BERLIN_MODE_SATA.

    2) Adding the missing enum, which was going to be added anyway as part
       of [1].

[1] https://lkml.kernel.org/r/20190108163124.6409-3-miquel.raynal@bootlin.com

Fixes: 49e54187ae ("ata: libahci_platform: comply to PHY framework")

Cc: Grzegorz Jaszczyk <jaz@semihalf.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2019-01-16 18:00:54 +05:30
Andy Shevchenko
b33a02aadc i2c: acpi: Move I2C bits from acpi.h to i2c.h
As discussed previously the best location for certain bus related bits,
e.g. I2C, is its own realm of the headers.

In order to uncontaminate acpi.h move the I2C bits to i2c.h.

There is no functional change intended.

Link: https://lkml.org/lkml/2018/11/28/744
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2019-01-15 23:20:02 +01:00
Vincent Guittot
8a62ffe275 PM-runtime: Add new interface to get accounted time
Some drivers (like i915/drm) needs to get the accounted suspended time.
pm_runtime_suspended_time() will return the suspended accounted time
in ns unit.

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-15 22:47:24 +01:00
Linus Torvalds
e8746440bf Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Pull networking fixes from David Miller:

 1) Fix regression in multi-SKB responses to RTM_GETADDR, from Arthur
    Gautier.

 2) Fix ipv6 frag parsing in openvswitch, from Yi-Hung Wei.

 3) Unbounded recursion in ipv4 and ipv6 GUE tunnels, from Stefano
    Brivio.

 4) Use after free in hns driver, from Yonglong Liu.

 5) icmp6_send() needs to handle the case of NULL skb, from Eric
    Dumazet.

 6) Missing rcu read lock in __inet6_bind() when operating on mapped
    addresses, from David Ahern.

 7) Memory leak in tipc-nl_compat_publ_dump(), from Gustavo A. R. Silva.

 8) Fix PHY vs r8169 module loading ordering issues, from Heiner
    Kallweit.

 9) Fix bridge vlan memory leak, from Ido Schimmel.

10) Dev refcount leak in AF_PACKET, from Jason Gunthorpe.

11) Infoleak in ipv6_local_error(), flow label isn't completely
    initialized. From Eric Dumazet.

12) Handle mv88e6390 errata, from Andrew Lunn.

13) Making vhost/vsock CID hashing consistent, from Zha Bin.

14) Fix lack of UMH cleanup when it unexpectedly exits, from Taehee Yoo.

15) Bridge forwarding must clear skb->tstamp, from Paolo Abeni.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (87 commits)
  bnxt_en: Fix context memory allocation.
  bnxt_en: Fix ring checking logic on 57500 chips.
  mISDN: hfcsusb: Use struct_size() in kzalloc()
  net: clear skb->tstamp in bridge forwarding path
  net: bpfilter: disallow to remove bpfilter module while being used
  net: bpfilter: restart bpfilter_umh when error occurred
  net: bpfilter: use cleanup callback to release umh_info
  umh: add exit routine for UMH process
  isdn: i4l: isdn_tty: Fix some concurrency double-free bugs
  vhost/vsock: fix vhost vsock cid hashing inconsistent
  net: stmmac: Prevent RX starvation in stmmac_napi_poll()
  net: stmmac: Fix the logic of checking if RX Watchdog must be enabled
  net: stmmac: Check if CBS is supported before configuring
  net: stmmac: dwxgmac2: Only clear interrupts that are active
  net: stmmac: Fix PCI module removal leak
  tools/bpf: fix bpftool map dump with bitfields
  tools/bpf: test btf bitfield with >=256 struct member offset
  bpf: fix bpffs bitfield pretty print
  net: ethernet: mediatek: fix warning in phy_start_aneg
  tcp: change txhash on SYN-data timeout
  ...
2019-01-16 05:13:36 +12:00
Thomas Gleixner
16118794ed posix-cpu-timers: Remove private interval storage
Posix CPU timers store the interval in private storage for historical
reasons (it_interval used to be a non scalar representation on 32bit
systems). This is gone and there is no reason for duplicated storage
anymore.

Use it_interval everywhere.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>
Link: https://lkml.kernel.org/r/20190111133500.945255655@linutronix.de
2019-01-15 16:36:13 +01:00
Leon Romanovsky
73f5a82bb3 RDMA/mad: Reduce MAD scope to mlx5_ib only
Management Datagram Interface (MAD) is applicable
only when physical port is Infiniband. It makes MAD
command logic to be completely unrelated to eth/core
parts of mlx5.

Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
2019-01-15 10:02:29 +02:00
Cornelia Huck
d1c1dad89e virtio: document virtio_config_ops restrictions
Some transports (e.g. virtio-ccw) implement virtio operations that
seem to be a simple read/write as something more involved that
cannot be done from an atomic context.

Give at least a hint about that.

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-01-14 20:15:17 -05:00
Cornelia Huck
b89a07c437 virtio: fix virtio_config_ops description
- get_features has returned 64 bits since commit d025477368
  ("virtio: add support for 64 bit features.")
- properly mark all optional callbacks

Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
2019-01-14 20:15:17 -05:00
Linus Torvalds
9deb9e1637 - New Device Support
- Add support for Power Supply to AXP813
    - Add support for GPIO, ADC, AC and Battery Power Supply to AXP803
    - Add support for UART to Exynos LPASS
 
  - Fix-ups
    - Use supplied MACROS; ti_am335x_tscadc
    - Trivial spelling/whitespace/alignment; tmio, axp20x, rave-sp
    - Regmap changes; bd9571mwv, wm5110-tables
    - Kconfig dependencies; MFD_AT91_USART
    - Supply shared data for child-devices; madera-core
    - Use new of_node_name_eq() API call; max77620, stmpe
    - Use managed resources (devm_*); tps65218
    - Comment descriptions; ingenic-tcu
    - Coding style; madera-core
 
  - Bug Fixes
    - Fix section mismatches; twl-core, db8500-prcmu
    - Correct error path related issues; mt6397-core, ab8500-core, mc13xxx-core
    - IRQ related fixes; tps6586x
    - Ensure proper initialisation sequence; qcom_rpm
    - Repair potential memory leak; cros_ec_dev
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAlwt0eMACgkQUa+KL4f8
 d2EiXBAApGil4yvMMczlCThaq9scR2e3PrwhKCWszbo+QO1QzM/0Tyo88D5sXUj5
 UxBIIU8lBC8rP9vkNkAob+UwNZZfuDB/iCEQ3PezbuXFxH6tglRMXzodtevQj4Nf
 LAfOa5OFjHZo9CgG03wqzOEqeS84CvKtOhvKZzG1iaFUExbT5HHCt1G+F4GdMoLf
 lkYNnQCk8Hv90NCwHobT6tl/hiz0ztVN//Xd94saQmrJc2SXviflAv9RxncKA8b0
 ESVgaZf+x4A+KyXzE3bUfffpZL/0rwq72yG6W7SQ8aO5QGdVjt1qYu8yMm0GFQOv
 2f7kkChnS54rFaSUFFO6PExy0Pz32/yTIu7iJrhR4R76TVFIYke2tNDJHjpYSlBf
 MPmnz4kZg7SUl9W+MGfCcGCsw8+vTeDgoQiLf+Xy6n78LNOx9AV2seYeraxC9njP
 xn3vKTX83A5RC/thmcdBFG7LE0uER2y0+S3oodBveGRHWEizZ701iKjwlZiK/51v
 MBMgjuOiu8eIlJK7hKYyv0rAAgWFoiIarOin6mTfq/cQxR3jU+U3jCenAxwcZ2VD
 9o5wE7O7zA/4z1nc3uG0o2tGoE6FH7sGot1+d4lyqaHUhYQUIyvUAl9dUnH323rO
 Bl9cCFU7pI4PQTyGHVNfJH8AHar9AQGbEfEWekC9Nl36MEY0ThE=
 =BwG/
 -----END PGP SIGNATURE-----

Merge tag 'mfd-next-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd

Pull MFD updates from Lee Jones:
 "New Device Support
   - Add support for Power Supply to AXP813
   - Add support for GPIO, ADC, AC and Battery Power Supply to AXP803
   - Add support for UART to Exynos LPASS

  Fix-ups:
   - Use supplied MACROS; ti_am335x_tscadc
   - Trivial spelling/whitespace/alignment; tmio, axp20x, rave-sp
   - Regmap changes; bd9571mwv, wm5110-tables
   - Kconfig dependencies; MFD_AT91_USART
   - Supply shared data for child-devices; madera-core
   - Use new of_node_name_eq() API call; max77620, stmpe
   - Use managed resources (devm_*); tps65218
   - Comment descriptions; ingenic-tcu
   - Coding style; madera-core

  Bug Fixes:
   - Fix section mismatches; twl-core, db8500-prcmu
   - Correct error path related issues; mt6397-core, ab8500-core, mc13xxx-core
   - IRQ related fixes; tps6586x
   - Ensure proper initialisation sequence; qcom_rpm
   - Repair potential memory leak; cros_ec_dev"

* tag 'mfd-next-4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (25 commits)
  mfd: exynos-lpass: Enable UART module support
  mfd: mc13xxx: Fix a missing check of a register-read failure
  mfd: cros_ec: Add commands to control codec
  mfd: madera: Remove spurious semicolon in while loop
  mfd: rave-sp: Fix typo in rave_sp_checksum comment
  mfd: ingenic-tcu: Fix bit field description in header
  mfd: tps65218: Use devm_regmap_add_irq_chip and clean up error path in probe()
  mfd: Use of_node_name_eq() for node name comparisons
  mfd: cros_ec_dev: Add missing mfd_remove_devices() call in remove
  mfd: axp20x: Add supported cells for AXP803
  mfd: axp20x: Re-align MFD cell entries
  mfd: axp20x: Add AC power supply cell for AXP813
  mfd: wm5110: Add missing ASRC rate register
  mfd: qcom_rpm: write fw_version to CTRL_REG
  mfd: tps6586x: Handle interrupts on suspend
  mfd: madera: Add shared data for accessory detection
  mfd: at91-usart: Add platform dependency
  mfd: bd9571mwv: Add volatile register to make DVFS work
  mfd: ab8500-core: Return zero in get_register_interruptible()
  mfd: tmio: Typo s/use use/use/
  ...
2019-01-15 06:24:36 +12:00
Cyrill Gorcunov
19ba9ecf24 XArray: Fix typo in comment
Seems copy and paste typo, not a big deal but still
for consistency sake better to fix.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: Matthew Wilcox <willy@infradead.org>
2019-01-14 12:52:16 -05:00
Shunyong Yang
98a455d91e ACPI / tables: table override from built-in initrd
In some scenario, we need to build initrd with kernel in a single image.
This can simplify system deployment process by downloading the whole system
once, such as in IC verification.

This patch adds support to override ACPI tables from built-in initrd.

Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com>
[ rjw: Minor cleanups ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-14 11:42:18 +01:00
Dmitry Torokhov
4116941b7a Linux 4.20
-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAlwgIJYeHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG0F4H/jwv83AI9qxd4Zsj
 geztCq0w1Vc48Gz/yDvl5MxZ74//q7Wz01qRTKisMNJla+Z0VuUReL12w0BGT0ko
 ZwPqrvPtM04pA7A6J+vLM8t6k7Ck0q7xC3z/Y9eN5qxtC7yOX/X8RziiXBmyMzM5
 nVpFYQwlk9/hSUHjPwMgf2dV32vNYl3FEph3g6nrqQLLdtsHiii9N8rC+cAU2jKg
 sZ8Cp6REYYxt9LWEilsGof+oLnH+oUkXecB7WKKvSaAVHqR20xdpZ3ZvRcVyLfQ4
 XCXBu8PIYYBWsa/iwuu0h4NuosGzEYbWOjnXKozOaV2KoqCT/Rk1egKIgb55EpyA
 kFH4wfc=
 =WAE7
 -----END PGP SIGNATURE-----

Merge tag 'v4.20' into next

Merge with mainline to bring in the new APIs.
2019-01-13 22:35:32 -08:00
Linus Torvalds
dbc3c09b81 ARM: SoC fixes
A bigger batch than I anticipated this week, for two reasons:
 
  - Some fallout on Davinci from board file -> DTB conversion, that also
  includes a few longer-standing fixes (i.e. not recent regressions).
 
  - drivers/reset material that has been in linux-next for a while, but
  didn't get sent to us until now for a variety of reasons (maintainer out
  sick, holidays, etc). There's a functional dependency in there such that
  one platform (Altera's SoCFPGA) won't boot without one of the patches;
  instead of reverting the patch that got merged, I looked at this set
  and decided it was small enough that I'll pick it up anyway. If you
  disagree I can revisit with a smaller set.
 
 That being said, there's also a handful of the usual stuff:
 
  - Fix for a crash on Armada 7K/8K when the kernel touches PSCI-reserved
  memory
  - Fix for PCIe reset on Macchiatobin (Armada 8K development board, what
  this email is sent from in fact :)
  - Enable a few new-merged modules for Amlogic in arm64 defconfig
  - Error path fixes on Integrator
  - Build fix for Renesas and Qualcomm
  - Initialization fix for Renesas RZ/G2E
 
  + A few more fixlets.
 -----BEGIN PGP SIGNATURE-----
 
 iQJDBAABCAAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAlw7hv0PHG9sb2ZAbGl4
 b20ubmV0AAoJEIwa5zzehBx3rrYP/ixwKcLu9mEW9pbTmQw9m/vAGRgah4b+prT2
 KNWfphwPEfFjzEE1zNwnELEJMip3Sq0s9vEbju6VHeaUeLBfGQl7160HtLK7isHX
 nnJOgz0r1jDJbXmbijbcQEYLagnxV6bwh30skCx/HjUGd/IgTAsFJ2zXtaQNob2u
 QAlCp7E21eVleNnoRkU+tGys+8+JooS6QXzi3hhvqnwQAuAMRAa05C36jtYPnNcg
 jpLtBcxgtngHprqxfNCNpsiAsacWL1K62B3atY77+wl0Fv25pH0q67e+YAtaXLDP
 iRd79pmZ803C8guAAUantxjRWoog4wCf1o97EEMpqfeY0Q4bdUAgn3+ZCG+rYTIW
 tQFm8KqYvdo29Aub6ytNnhC+VzYLCrApDkEhBKEq92J2weBvq0cnw3JmGsTeeiWX
 uS6ittI6VAQOXzgZ5uOrnLFlpqgGb9BZt8aCzXzwbffApNVj6CUtuYXTE4PJNLB1
 yeO7IIrCXupTnJklNUrveWjfNhs2bJ6RN2OgifDhxEZBDd8PH9JJKmRfi/mSo7u+
 5O1d2UoeL6NFKDlaqvEy5mzgD2z0dA5VEcnY663khu0UxRpp8Vm1z5D+Ay/23D6W
 BrF1GVafcrX374tgqKF78k+z++WRuqE7ThhHR0SQQpM9I+3CYdl6BlqghwqN2P5a
 bhm5RFIK
 =qjfZ
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC fixes from Olof Johansson:
 "A bigger batch than I anticipated this week, for two reasons:

   - Some fallout on Davinci from board file -> DTB conversion, that
     also includes a few longer-standing fixes (i.e. not recent
     regressions).

   - drivers/reset material that has been in linux-next for a while, but
     didn't get sent to us until now for a variety of reasons
     (maintainer out sick, holidays, etc). There's a functional
     dependency in there such that one platform (Altera's SoCFPGA) won't
     boot without one of the patches; instead of reverting the patch
     that got merged, I looked at this set and decided it was small
     enough that I'll pick it up anyway. If you disagree I can revisit
     with a smaller set.

  That being said, there's also a handful of the usual stuff:

   - Fix for a crash on Armada 7K/8K when the kernel touches
     PSCI-reserved memory

   - Fix for PCIe reset on Macchiatobin (Armada 8K development board,
     what this email is sent from in fact :)

   - Enable a few new-merged modules for Amlogic in arm64 defconfig

   - Error path fixes on Integrator

   - Build fix for Renesas and Qualcomm

   - Initialization fix for Renesas RZ/G2E

  .. plus a few more fixlets"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (28 commits)
  ARM: integrator: impd1: use struct_size() in devm_kzalloc()
  qcom-scm: Include <linux/err.h> header
  gpio: pl061: handle failed allocations
  ARM: dts: kirkwood: Fix polarity of GPIO fan lines
  arm64: dts: marvell: mcbin: fix PCIe reset signal
  arm64: dts: marvell: armada-ap806: reserve PSCI area
  ARM: dts: da850-lcdk: Correct the sound card name
  ARM: dts: da850-lcdk: Correct the audio codec regulators
  ARM: dts: da850-evm: Correct the sound card name
  ARM: dts: da850-evm: Correct the audio codec regulators
  ARM: davinci: omapl138-hawk: fix label names in GPIO lookup entries
  ARM: davinci: dm644x-evm: fix label names in GPIO lookup entries
  ARM: davinci: dm355-evm: fix label names in GPIO lookup entries
  ARM: davinci: da850-evm: fix label names in GPIO lookup entries
  ARM: davinci: da830-evm: fix label names in GPIO lookup entries
  arm64: defconfig: enable modules for amlogic s400 sound card
  reset: uniphier-glue: Add AHCI reset control support in glue layer
  dt-bindings: reset: uniphier: Add AHCI core reset description
  reset: uniphier-usb3: Rename to reset-uniphier-glue
  dt-bindings: reset: uniphier: Replace the expression of USB3 with generic peripherals
  ...
2019-01-14 10:34:14 +12:00
Olof Johansson
465612178b Late reset controller changes for v5.0
This adds missing deassert functionality to the ARC HSDK reset driver,
 fixes some indentation and grammar issues in the kernel docs, adds a
 helper to count the number of resets on a device for the non-DT case
 as well, adds an early reset driver for SoCFPGA and simple reset driver
 support for Stratix10, and generalizes the uniphier USB3 glue layer
 reset to also cover AHCI.
 -----BEGIN PGP SIGNATURE-----
 
 iI0EABYIADUWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCXDTOiBcccC56YWJlbEBw
 ZW5ndXRyb25peC5kZQAKCRDVhaclGDdiwMnMAP9u9pJr0g6t/8NwiDNQGYIupFMQ
 vH3hIUP7pwkELeN36AEAuFJG66r1Y96icDQCLn9x6vxwgTDmJGgGHM3CWEftsQI=
 =vFwq
 -----END PGP SIGNATURE-----

Merge tag 'reset-for-5.0-rc2' of git://git.pengutronix.de/git/pza/linux into fixes

Late reset controller changes for v5.0

This adds missing deassert functionality to the ARC HSDK reset driver,
fixes some indentation and grammar issues in the kernel docs, adds a
helper to count the number of resets on a device for the non-DT case
as well, adds an early reset driver for SoCFPGA and simple reset driver
support for Stratix10, and generalizes the uniphier USB3 glue layer
reset to also cover AHCI.

* tag 'reset-for-5.0-rc2' of git://git.pengutronix.de/git/pza/linux:
  reset: uniphier-glue: Add AHCI reset control support in glue layer
  dt-bindings: reset: uniphier: Add AHCI core reset description
  reset: uniphier-usb3: Rename to reset-uniphier-glue
  dt-bindings: reset: uniphier: Replace the expression of USB3 with generic peripherals
  ARM: socfpga: dts: document "altr,stratix10-rst-mgr" binding
  reset: socfpga: add an early reset driver for SoCFPGA
  reset: fix null pointer dereference on dev by dev_name
  reset: Add reset_control_get_count()
  reset: Improve reset controller kernel docs
  ARC: HSDK: improve reset driver

Signed-off-by: Olof Johansson <olof@lixom.net>
2019-01-12 22:06:54 -08:00
John Hubbard
e170672040 phy: fix build breakage: add PHY_MODE_SATA
Commit 49e54187ae ("ata: libahci_platform: comply to PHY framework") uses
the PHY_MODE_SATA, but that enum had not yet been added. This caused a
build failure for me, with today's linux.git.

Also, there is a potentially conflicting (mis-named) PHY_MODE_SATA, hiding
in the Marvell Berlin SATA PHY driver.

Fix the build by:

    1) Renaming Marvell's defined value to a more scoped name,
       in order to avoid any potential conflicts: PHY_BERLIN_MODE_SATA.

    2) Adding the missing enum, which was going to be added anyway as part
       of [1].

[1] https://lkml.kernel.org/r/20190108163124.6409-3-miquel.raynal@bootlin.com

Fixes: 49e54187ae ("ata: libahci_platform: comply to PHY framework")

Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: Grzegorz Jaszczyk <jaz@semihalf.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-12 21:07:14 -08:00
Linus Torvalds
66c56cfa64 remove dma_zalloc_coherent
We've always had a weird situation around dma_zalloc_coherent.  To
 safely support mapping the allocations to userspace major architectures
 like x86 and arm have always zeroed allocations from dma_alloc_coherent,
 but a couple other architectures were missing that zeroing either always
 or in corner cases.  Then later we grew anothe dma_zalloc_coherent
 interface to explicitly request zeroing, but that just added __GFP_ZERO
 to the allocation flags, which for some allocators that didn't end
 up using the page allocator ended up being a no-op and still not
 zeroing the allocations.
 
 So for this merge window I fixed up all remaining architectures to zero
 the memory in dma_alloc_coherent, and made dma_zalloc_coherent a no-op
 wrapper around dma_alloc_coherent, which fixes all of the above issues.
 
 dma_zalloc_coherent is now pointless and can go away, and Luis helped
 me writing a cocchinelle script and patch series to kill it, which I
 think we should apply now just after -rc1 to finally settle these
 issue.
 -----BEGIN PGP SIGNATURE-----
 
 iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAlw6LV0LHGhjaEBsc3Qu
 ZGUACgkQD55TZVIEUYPd1hAAshbVLVIUg750CQoKD5sk44/IW7klkQUnzcp9ueOY
 /GIYS/ils8q9DSITAyMJxHKpjt1EEVlavWLvYLlfpkDfLaVGMUJu+zKGaolhU5F6
 OuldJKZV6tWrC7zGVl+09y5CAyelVxLyuD09I+QYnHUIO9ljgZHB2+W3ezOFxBRD
 FjrQRuFY6Xpr1F42zWc4aJrgACffH761pLx3fbJlIs8aEInWKqDbuyL6Lg71BRXh
 kHKt0DQxFxklyQmqaYyDesujjXUysweAFLNxgN9GSrlWBR8GE3qJpsSrIzjX5k8w
 WKzbypYqVQepI3zYCN5EoCAoiHBFZXPSNHCoXAH6tHjYwgQ3uoDpzxEKJOEykO4i
 1+kcJh3ArQZA/BsMBf3I/CNMsxvBuC3/QKFMcs/7pKx1ABoumSBSIpqB4pG4NU+o
 fxRBHKjqbILufWKReb2PuRXiPpddwuo0vg70U0FK2aWZrClRYEpBdExPKrBUAG34
 WtQCGA0YFXV/kAgPPmOvnPlwpYM2ZrVLVl5Ct2diR5QaLee3o1GiStQm0LuspRzk
 HSzVyCYdKRxH4zkEBzKUn/PuyYLoMRyPP4PQ3R/xlQrFqvv6FeiGYnow89+1JpUp
 2qWg5vU1aLM7/WXnyVGDED3T42eZREi/uMPQIADXqRIVC7e43/eKcLF06n0lIWh9
 usg=
 =VIBB
 -----END PGP SIGNATURE-----

Merge tag 'remove-dma_zalloc_coherent-5.0' of git://git.infradead.org/users/hch/dma-mapping

Pull dma_zalloc_coherent() removal from Christoph Hellwig:
 "We've always had a weird situation around dma_zalloc_coherent. To
  safely support mapping the allocations to userspace major
  architectures like x86 and arm have always zeroed allocations from
  dma_alloc_coherent, but a couple other architectures were missing that
  zeroing either always or in corner cases.

  Then later we grew anothe dma_zalloc_coherent interface to explicitly
  request zeroing, but that just added __GFP_ZERO to the allocation
  flags, which for some allocators that didn't end up using the page
  allocator ended up being a no-op and still not zeroing the
  allocations.

  So for this merge window I fixed up all remaining architectures to
  zero the memory in dma_alloc_coherent, and made dma_zalloc_coherent a
  no-op wrapper around dma_alloc_coherent, which fixes all of the above
  issues.

  dma_zalloc_coherent is now pointless and can go away, and Luis helped
  me writing a cocchinelle script and patch series to kill it, which I
  think we should apply now just after -rc1 to finally settle these
  issue"

* tag 'remove-dma_zalloc_coherent-5.0' of git://git.infradead.org/users/hch/dma-mapping:
  dma-mapping: remove dma_zalloc_coherent()
  cross-tree: phase out dma_zalloc_coherent() on headers
  cross-tree: phase out dma_zalloc_coherent()
2019-01-12 10:52:40 -08:00
Eric W. Biederman
ee17e5d620 signal: Make siginmask safe when passed a signal of 0
Eric Biggers reported:
> The following commit, which went into v4.20, introduced undefined behavior when
> sys_rt_sigqueueinfo() is called with sig=0:
>
> commit 4ce5f9c9e7
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date:   Tue Sep 25 12:59:31 2018 +0200
>
>     signal: Use a smaller struct siginfo in the kernel
>
> In sig_specific_sicodes(), used from known_siginfo_layout(), the expression
> '1ULL << ((sig)-1)' is undefined as it evaluates to 1ULL << 4294967295.
>
> Reproducer:
>
> #include <signal.h>
> #include <sys/syscall.h>
> #include <unistd.h>
>
> int main(void)
> {
> 	siginfo_t si = { .si_code = 1 };
> 	syscall(__NR_rt_sigqueueinfo, 0, 0, &si);
> }
>
> UBSAN report for v5.0-rc1:
>
> UBSAN: Undefined behaviour in kernel/signal.c:2946:7
> shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
> CPU: 2 PID: 346 Comm: syz_signal Not tainted 5.0.0-rc1 #25
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x70/0xa5 lib/dump_stack.c:113
>  ubsan_epilogue+0xd/0x40 lib/ubsan.c:159
>  __ubsan_handle_shift_out_of_bounds+0x12c/0x170 lib/ubsan.c:425
>  known_siginfo_layout+0xae/0xe0 kernel/signal.c:2946
>  post_copy_siginfo_from_user kernel/signal.c:3009 [inline]
>  __copy_siginfo_from_user+0x35/0x60 kernel/signal.c:3035
>  __do_sys_rt_sigqueueinfo kernel/signal.c:3553 [inline]
>  __se_sys_rt_sigqueueinfo kernel/signal.c:3549 [inline]
>  __x64_sys_rt_sigqueueinfo+0x31/0x70 kernel/signal.c:3549
>  do_syscall_64+0x4c/0x1b0 arch/x86/entry/common.c:290
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x433639
> Code: c4 18 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 27 00 00 c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fffcb289fc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000081
> RAX: ffffffffffffffda RBX: 00000000004002e0 RCX: 0000000000433639
> RDX: 00007fffcb289fd0 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 00000000006b2018 R08: 000000000000004d R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401560
> R13: 00000000004015f0 R14: 0000000000000000 R15: 0000000000000000

I have looked at the other callers of siginmask and they all appear to
in locations where sig can not be zero.

I have looked at the code generation of adding an extra test against
zero and gcc was able with a simple decrement instruction to combine
the two tests together. So the at most adding this test cost a single
cpu cycle.  In practice that decrement instruction was already present
as part of the mask comparison, so the only change was when the
instruction was executed.

So given that it is cheap, and obviously correct to update siginmask
to verify the signal is not zero.  Fix this issue there to avoid any
future problems.

Reported-by: Eric Biggers <ebiggers@kernel.org>
Fixes: 4ce5f9c9e7 ("signal: Use a smaller struct siginfo in the kernel")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2019-01-12 11:48:20 -06:00
Taehee Yoo
71a8508402 net: bpfilter: disallow to remove bpfilter module while being used
The bpfilter.ko module can be removed while functions of the bpfilter.ko
are executing. so panic can occurred. in order to protect that, locks can
be used. a bpfilter_lock protects routines in the
__bpfilter_process_sockopt() but it's not enough because __exit routine
can be executed concurrently.

Now, the bpfilter_umh can not run in parallel.
So, the module do not removed while it's being used and it do not
double-create UMH process.
The members of the umh_info and the bpfilter_umh_ops are protected by
the bpfilter_umh_ops.lock.

test commands:
   while :
   do
	iptables -I FORWARD -m string --string ap --algo kmp &
	modprobe -rv bpfilter &
   done

splat looks like:
[  298.623435] BUG: unable to handle kernel paging request at fffffbfff807440b
[  298.628512] #PF error: [normal kernel read fault]
[  298.633018] PGD 124327067 P4D 124327067 PUD 11c1a3067 PMD 119eb2067 PTE 0
[  298.638859] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[  298.638859] CPU: 0 PID: 2997 Comm: iptables Not tainted 4.20.0+ #154
[  298.638859] RIP: 0010:__mutex_lock+0x6b9/0x16a0
[  298.638859] Code: c0 00 00 e8 89 82 ff ff 80 bd 8f fc ff ff 00 0f 85 d9 05 00 00 48 8b 85 80 fc ff ff 48 bf 00 00 00 00 00 fc ff df 48 c1 e8 03 <80> 3c 38 00 0f 85 1d 0e 00 00 48 8b 85 c8 fc ff ff 49 39 47 58 c6
[  298.638859] RSP: 0018:ffff88810e7777a0 EFLAGS: 00010202
[  298.638859] RAX: 1ffffffff807440b RBX: ffff888111bd4d80 RCX: 0000000000000000
[  298.638859] RDX: 1ffff110235ff806 RSI: ffff888111bd5538 RDI: dffffc0000000000
[  298.638859] RBP: ffff88810e777b30 R08: 0000000080000002 R09: 0000000000000000
[  298.638859] R10: 0000000000000000 R11: 0000000000000000 R12: fffffbfff168a42c
[  298.638859] R13: ffff888111bd4d80 R14: ffff8881040e9a05 R15: ffffffffc03a2000
[  298.638859] FS:  00007f39e3758700(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000
[  298.638859] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  298.638859] CR2: fffffbfff807440b CR3: 000000011243e000 CR4: 00000000001006f0
[  298.638859] Call Trace:
[  298.638859]  ? mutex_lock_io_nested+0x1560/0x1560
[  298.638859]  ? kasan_kmalloc+0xa0/0xd0
[  298.638859]  ? kmem_cache_alloc+0x1c2/0x260
[  298.638859]  ? __alloc_file+0x92/0x3c0
[  298.638859]  ? alloc_empty_file+0x43/0x120
[  298.638859]  ? alloc_file_pseudo+0x220/0x330
[  298.638859]  ? sock_alloc_file+0x39/0x160
[  298.638859]  ? __sys_socket+0x113/0x1d0
[  298.638859]  ? __x64_sys_socket+0x6f/0xb0
[  298.638859]  ? do_syscall_64+0x138/0x560
[  298.638859]  ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  298.638859]  ? __alloc_file+0x92/0x3c0
[  298.638859]  ? init_object+0x6b/0x80
[  298.638859]  ? cyc2ns_read_end+0x10/0x10
[  298.638859]  ? cyc2ns_read_end+0x10/0x10
[  298.638859]  ? hlock_class+0x140/0x140
[  298.638859]  ? sched_clock_local+0xd4/0x140
[  298.638859]  ? sched_clock_local+0xd4/0x140
[  298.638859]  ? check_flags.part.37+0x440/0x440
[  298.638859]  ? __lock_acquire+0x4f90/0x4f90
[  298.638859]  ? set_rq_offline.part.89+0x140/0x140
[ ... ]

Fixes: d2ba09c17a ("net: add skeleton of bpfilter kernel module")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-11 18:05:41 -08:00
Taehee Yoo
61fbf5933d net: bpfilter: restart bpfilter_umh when error occurred
The bpfilter_umh will be stopped via __stop_umh() when the bpfilter
error occurred.
The bpfilter_umh() couldn't start again because there is no restart
routine.

The section of the bpfilter_umh_{start/end} is no longer .init.rodata
because these area should be reused in the restart routine. hence
the section name is changed to .bpfilter_umh.

The bpfilter_ops->start() is restart callback. it will be called when
bpfilter_umh is stopped.
The stop bit means bpfilter_umh is stopped. this bit is set by both
start and stop routine.

Before this patch,
Test commands:
   $ iptables -vnL
   $ kill -9 <pid of bpfilter_umh>
   $ iptables -vnL
   [  480.045136] bpfilter: write fail -32
   $ iptables -vnL

All iptables commands will fail.

After this patch,
Test commands:
   $ iptables -vnL
   $ kill -9 <pid of bpfilter_umh>
   $ iptables -vnL
   $ iptables -vnL

Now, all iptables commands will work.

Fixes: d2ba09c17a ("net: add skeleton of bpfilter kernel module")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-11 18:05:41 -08:00
Taehee Yoo
5b4cb650e5 net: bpfilter: use cleanup callback to release umh_info
Now, UMH process is killed, do_exit() calls the umh_info->cleanup callback
to release members of the umh_info.
This patch makes bpfilter_umh's cleanup routine to use the
umh_info->cleanup callback.

Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-11 18:05:41 -08:00
Taehee Yoo
73ab1cb2de umh: add exit routine for UMH process
A UMH process which is created by the fork_usermode_blob() such as
bpfilter needs to release members of the umh_info when process is
terminated.
But the do_exit() does not release members of the umh_info. hence module
which uses UMH needs own code to detect whether UMH process is
terminated or not.
But this implementation needs extra code for checking the status of
UMH process. it eventually makes the code more complex.

The new PF_UMH flag is added and it is used to identify UMH processes.
The exit_umh() does not release members of the umh_info.
Hence umh_info->cleanup callback should release both members of the
umh_info and the private data.

Suggested-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-11 18:05:40 -08:00
Ioana Ciornei
afb7742281 bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate
Allocatable devices can be acquired by drivers on the fsl-mc bus using
the fsl_mc_portal_allocate or fsl_mc_object_allocate functions. Add a
device link between the consumer device and the supplier device so that
proper resource management is achieved.
Also, adding a link between these devices ensures that a proper unbind
order is respected (ie before the supplier device is unbound from its
respective driver all consumer devices will be notified and unbound
first).

Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
2019-01-11 15:06:54 -06:00
Linus Torvalds
f87092c433 A patch to allow setting abort_on_full and a fix for an old "rbd unmap"
edge case, marked for stable.
 -----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCAAxFiEEydHwtzie9C7TfviiSn/eOAIR84sFAlw4yfETHGlkcnlvbW92
 QGdtYWlsLmNvbQAKCRBKf944AhHzi9loB/4iTBs/c5vI8oXSi+n4IAAG/LunP8Ff
 HfxMr7Mpbpp0cLdzmJWO63Wejii95w7IkdepJTF5VlpH6dwJDUL6jSAyAXPO1a2G
 phZHmnGYjFBKLGPftCZmGQCJeYeS9JJyRgTC4IZECVkQRiPRGXn8cAbEqMYOy6Am
 mXmy0u4Me3RJTpcOCqaPPugontvtsZdfqvwVE2dGqXTj9Kh1hfum5ddrvf1CXugQ
 MpXzW3mJCMMfcXlZOCVuQInKqPT4HRhTpzJxdECiJTxBXDQUd6e0ekOXmKW6jOYk
 ZpNVnXHGee0uvzwQC0/VMWkRF6d+pOsYFQkDlX79h04rqnoBkUNc2Doe
 =dJev
 -----END PGP SIGNATURE-----

Merge tag 'ceph-for-5.0-rc2' of git://github.com/ceph/ceph-client

Pull ceph updates from Ilya Dryomov:
 "A patch to allow setting abort_on_full and a fix for an old "rbd
  unmap" edge case, marked for stable"

* tag 'ceph-for-5.0-rc2' of git://github.com/ceph/ceph-client:
  rbd: don't return 0 on unmap if RBD_DEV_FLAG_REMOVING is set
  ceph: use vmf_error() in ceph_filemap_fault()
  libceph: allow setting abort_on_full for rbd
2019-01-11 12:17:30 -08:00
Jason Baron
e1452b607c livepatch: Add atomic replace
Sometimes we would like to revert a particular fix. Currently, this
is not easy because we want to keep all other fixes active and we
could revert only the last applied patch.

One solution would be to apply new patch that implemented all
the reverted functions like in the original code. It would work
as expected but there will be unnecessary redirections. In addition,
it would also require knowing which functions need to be reverted at
build time.

Another problem is when there are many patches that touch the same
functions. There might be dependencies between patches that are
not enforced on the kernel side. Also it might be pretty hard to
actually prepare the patch and ensure compatibility with the other
patches.

Atomic replace && cumulative patches:

A better solution would be to create cumulative patch and say that
it replaces all older ones.

This patch adds a new "replace" flag to struct klp_patch. When it is
enabled, a set of 'nop' klp_func will be dynamically created for all
functions that are already being patched but that will no longer be
modified by the new patch. They are used as a new target during
the patch transition.

The idea is to handle Nops' structures like the static ones. When
the dynamic structures are allocated, we initialize all values that
are normally statically defined.

The only exception is "new_func" in struct klp_func. It has to point
to the original function and the address is known only when the object
(module) is loaded. Note that we really need to set it. The address is
used, for example, in klp_check_stack_func().

Nevertheless we still need to distinguish the dynamically allocated
structures in some operations. For this, we add "nop" flag into
struct klp_func and "dynamic" flag into struct klp_object. They
need special handling in the following situations:

  + The structures are added into the lists of objects and functions
    immediately. In fact, the lists were created for this purpose.

  + The address of the original function is known only when the patched
    object (module) is loaded. Therefore it is copied later in
    klp_init_object_loaded().

  + The ftrace handler must not set PC to func->new_func. It would cause
    infinite loop because the address points back to the beginning of
    the original function.

  + The various free() functions must free the structure itself.

Note that other ways to detect the dynamic structures are not considered
safe. For example, even the statically defined struct klp_object might
include empty funcs array. It might be there just to run some callbacks.

Also note that the safe iterator must be used in the free() functions.
Otherwise already freed structures might get accessed.

Special callbacks handling:

The callbacks from the replaced patches are _not_ called by intention.
It would be pretty hard to define a reasonable semantic and implement it.

It might even be counter-productive. The new patch is cumulative. It is
supposed to include most of the changes from older patches. In most cases,
it will not want to call pre_unpatch() post_unpatch() callbacks from
the replaced patches. It would disable/break things for no good reasons.
Also it should be easier to handle various scenarios in a single script
in the new patch than think about interactions caused by running many
scripts from older patches. Not to say that the old scripts even would
not expect to be called in this situation.

Removing replaced patches:

One nice effect of the cumulative patches is that the code from the
older patches is no longer used. Therefore the replaced patches can
be removed. It has several advantages:

  + Nops' structs will no longer be necessary and might be removed.
    This would save memory, restore performance (no ftrace handler),
    allow clear view on what is really patched.

  + Disabling the patch will cause using the original code everywhere.
    Therefore the livepatch callbacks could handle only one scenario.
    Note that the complication is already complex enough when the patch
    gets enabled. It is currently solved by calling callbacks only from
    the new cumulative patch.

  + The state is clean in both the sysfs interface and lsmod. The modules
    with the replaced livepatches might even get removed from the system.

Some people actually expected this behavior from the beginning. After all
a cumulative patch is supposed to "completely" replace an existing one.
It is like when a new version of an application replaces an older one.

This patch does the first step. It removes the replaced patches from
the list of patches. It is safe. The consistency model ensures that
they are no longer used. By other words, each process works only with
the structures from klp_transition_patch.

The removal is done by a special function. It combines actions done by
__disable_patch() and klp_complete_transition(). But it is a fast
track without all the transaction-related stuff.

Signed-off-by: Jason Baron <jbaron@akamai.com>
[pmladek@suse.com: Split, reuse existing code, simplified]
Signed-off-by: Petr Mladek <pmladek@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-01-11 20:51:24 +01:00
Jason Baron
20e5502595 livepatch: Use lists to manage patches, objects and functions
Currently klp_patch contains a pointer to a statically allocated array of
struct klp_object and struct klp_objects contains a pointer to a statically
allocated array of klp_func. In order to allow for the dynamic allocation
of objects and functions, link klp_patch, klp_object, and klp_func together
via linked lists. This allows us to more easily allocate new objects and
functions, while having the iterator be a simple linked list walk.

The static structures are added to the lists early. It allows to add
the dynamically allocated objects before klp_init_object() and
klp_init_func() calls. Therefore it reduces the further changes
to the code.

This patch does not change the existing behavior.

Signed-off-by: Jason Baron <jbaron@akamai.com>
[pmladek@suse.com: Initialize lists before init calls]
Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-01-11 20:51:24 +01:00
Petr Mladek
958ef1e39d livepatch: Simplify API by removing registration step
The possibility to re-enable a registered patch was useful for immediate
patches where the livepatch module had to stay until the system reboot.
The improved consistency model allows to achieve the same result by
unloading and loading the livepatch module again.

Also we are going to add a feature called atomic replace. It will allow
to create a patch that would replace all already registered patches.
The aim is to handle dependent patches more securely. It will obsolete
the stack of patches that helped to handle the dependencies so far.
Then it might be unclear when a cumulative patch re-enabling is safe.

It would be complicated to support the many modes. Instead we could
actually make the API and code easier to understand.

Therefore, remove the two step public API. All the checks and init calls
are moved from klp_register_patch() to klp_enabled_patch(). Also the patch
is automatically freed, including the sysfs interface when the transition
to the disabled state is completed.

As a result, there is never a disabled patch on the top of the stack.
Therefore we do not need to check the stack in __klp_enable_patch().
And we could simplify the check in __klp_disable_patch().

Also the API and logic is much easier. It is enough to call
klp_enable_patch() in module_init() call. The patch can be disabled
by writing '0' into /sys/kernel/livepatch/<patch>/enabled. Then the module
can be removed once the transition finishes and sysfs interface is freed.

The only problem is how to free the structures and kobjects safely.
The operation is triggered from the sysfs interface. We could not put
the related kobject from there because it would cause lock inversion
between klp_mutex and kernfs locks, see kn->count lockdep map.

Therefore, offload the free task to a workqueue. It is perfectly fine:

  + The patch can no longer be used in the livepatch operations.

  + The module could not be removed until the free operation finishes
    and module_put() is called.

  + The operation is asynchronous already when the first
    klp_try_complete_transition() fails and another call
    is queued with a delay.

Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-01-11 20:51:24 +01:00
Petr Mladek
68007289bf livepatch: Don't block the removal of patches loaded after a forced transition
module_put() is currently never called in klp_complete_transition() when
klp_force is set. As a result, we might keep the reference count even when
klp_enable_patch() fails and klp_cancel_transition() is called.

This might give the impression that a module might get blocked in some
strange init state. Fortunately, it is not the case. The reference count
is ignored when mod->init fails and erroneous modules are always removed.

Anyway, this might be confusing. Instead, this patch moves
the global klp_forced flag into struct klp_patch. As a result,
we block only modules that might still be in use after a forced
transition. Newly loaded livepatches might be eventually completely
removed later.

It is not a big deal. But the code is at least consistent with
the reality.

Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-01-11 20:51:24 +01:00
Petr Mladek
0430f78bf3 livepatch: Consolidate klp_free functions
The code for freeing livepatch structures is a bit scattered and tricky:

  + direct calls to klp_free_*_limited() and kobject_put() are
    used to release partially initialized objects

  + klp_free_patch() removes the patch from the public list
    and releases all objects except for patch->kobj

  + object_put(&patch->kobj) and the related wait_for_completion()
    are called directly outside klp_mutex; this code is duplicated;

Now, we are going to remove the registration stage to simplify the API
and the code. This would require handling more situations in
klp_enable_patch() error paths.

More importantly, we are going to add a feature called atomic replace.
It will need to dynamically create func and object structures. We will
want to reuse the existing init() and free() functions. This would
create even more error path scenarios.

This patch implements more straightforward free functions:

  + checks kobj_added flag instead of @limit[*]

  + initializes patch->list early so that the check for empty list
    always works

  + The action(s) that has to be done outside klp_mutex are done
    in separate klp_free_patch_finish() function. It waits only
    when patch->kobj was really released via the _start() part.

The patch does not change the existing behavior.

[*] We need our own flag to track that the kobject was successfully
    added to the hierarchy.  Note that kobj.state_initialized only
    indicates that kobject has been initialized, not whether is has
    been added (and needs to be removed on cleanup).

Signed-off-by: Petr Mladek <pmladek@suse.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Jessica Yu <jeyu@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Jason Baron <jbaron@akamai.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-01-11 20:51:23 +01:00
Petr Mladek
19514910d0 livepatch: Change unsigned long old_addr -> void *old_func in struct klp_func
The address of the to be patched function and new function is stored
in struct klp_func as:

	void *new_func;
	unsigned long old_addr;

The different naming scheme and type are derived from the way
the addresses are set. @old_addr is assigned at runtime using
kallsyms-based search. @new_func is statically initialized,
for example:

  static struct klp_func funcs[] = {
	{
		.old_name = "cmdline_proc_show",
		.new_func = livepatch_cmdline_proc_show,
	}, { }
  };

This patch changes unsigned long old_addr -> void *old_func. It removes
some confusion when these address are later used in the code. It is
motivated by a followup patch that adds special NOP struct klp_func
where we want to assign func->new_func = func->old_addr respectively
func->new_func = func->old_func.

This patch does not modify the existing behavior.

Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
Acked-by: Alice Ferrazzi <alice.ferrazzi@gmail.com>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-01-11 20:51:23 +01:00
Linus Torvalds
e8af37f3f4 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
 "A 32-bit build fix, CONFIG_RETPOLINE fixes and rename CONFIG_RESCTRL
  to CONFIG_X86_RESCTRL"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE
  x86/cache: Rename config option to CONFIG_X86_RESCTRL
  samples/seccomp: Fix 32-bit build
2019-01-11 09:07:19 -08:00
Linus Torvalds
f4f31fff32 Power management updates for 5.0-rc2
- Prevent integer overflows from occurring on 32-bit when
    converting milliseconds to nanoseconds in the runtime PM
    framework and update comments that still refer to jiffies
    in it (Vincent Guittot, Ladislav Michl).
 
  - Fix the SCMI cpufreq driver to always use the same frequency
    units for arch_set_freq_scale() and make the scale-invariant
    load tracking acutally work with this driver (Quentin Perret).
 
  - Fix freeing of dynamic OPPs in the SCPI and SCMI cpufreq drivers
    broken during the 4.20 defelopment cycle (Viresh Kumar).
 
  - Prevent the cpufreq core from attempting to return the current
    frequency of offline CPUs (Sudeep Holla).
 
  - Add devfreq suspend and resume hooks (missed previously) to the
    PM core to make the recently added system suspend and resume
    support in devfreq actually work (Lukasz Luba).
 
  - Update MAINTAINERS entries for cpufreq and cpuidle, mostly to add
    references to new/current documentation to them (Rafael Wysocki).
 
  - Fix a recently broken reference to cpuidle documentation (Otto
    Sabart).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJcOGt/AAoJEILEb/54YlRxSBcQAIhnPvUQz+ZqLbJ4tM/LYuAH
 m2qGV82UNoyfJc4O3eppvqfr6kra0lRK+SRBYJENjVBC4tzrpDr8UlZZ6ilwobQe
 KdybpUzFPmSCiROvwkwyXITSA6Z4kI1+mAZKn2HuV+q3u0O2ABQltU3S4veN0dfP
 +YRap+3BhGP4Pz9g7uzWwe2YS2o5ng9RDgGDhNQ18tSw9T7TnXVJBuqYsBlCi1au
 dWaY1kiswDLfXdEqJUJoFyjTwJxJir8wYtgEcYRhtBTNDrD8j0AoaFcrxd3yP9qd
 I2sGnxvpvndnPczJ0fJHdz83XonivLSEQsSc+Fe/fhqt1izrli4ZSZO4DPPMrU47
 n6kGX0miDUGKSvYcU+R/0b3i85X3Na4OHcVvuwjmba3Hdq6C64LmGDMvu1CJy2Qs
 juIiHgDa+gG7/80u3S+ekDq7u9C/1WS75X6wCON7aS5mnaP+FagC/dOxkNmDxYsi
 FwZZJhP/fxx12OjV2UYxKgVeRzw+2x8mgnNIlFa+MqsTRG6239Ii/lr/WPdXPklk
 2UdwLRkxNw69K3Q/m0LrmSx9AxmtwBGp24dvAf2bxjIYC4SL6eK9RXFjS4sWoE+T
 NXG4j2FHMMDptX9YGs9OlBm2GoJOb/pwJfvO52dGmIRuix1jT5Z1hM6sZjgt+mns
 YNr06bu2x2jGeZGu9O9Y
 =Z7S7
 -----END PGP SIGNATURE-----

Merge tag 'pm-5.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management updates from Rafael Wysocki:
 "These fix fallout after starting to use hrtimers in the runtime PM
  framework, fix a few cpufreq issues, fix a recently broken reference
  to cpuidle documentation, update MAINTAINERS entries for cpufreq and
  cpuidle and make the recently added system suspend and resume support
  in devfreq actually work.

  Specifics:

   - Prevent integer overflows from occurring on 32-bit when converting
     milliseconds to nanoseconds in the runtime PM framework and update
     comments that still refer to jiffies in it (Vincent Guittot,
     Ladislav Michl).

   - Fix the SCMI cpufreq driver to always use the same frequency units
     for arch_set_freq_scale() and make the scale-invariant load
     tracking acutally work with this driver (Quentin Perret).

   - Fix freeing of dynamic OPPs in the SCPI and SCMI cpufreq drivers
     broken during the 4.20 defelopment cycle (Viresh Kumar).

   - Prevent the cpufreq core from attempting to return the current
     frequency of offline CPUs (Sudeep Holla).

   - Add devfreq suspend and resume hooks (missed previously) to the PM
     core to make the recently added system suspend and resume support
     in devfreq actually work (Lukasz Luba).

   - Update MAINTAINERS entries for cpufreq and cpuidle, mostly to add
     references to new/current documentation to them (Rafael Wysocki).

   - Fix a recently broken reference to cpuidle documentation (Otto
     Sabart)"

* tag 'pm-5.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM-runtime: Fix autosuspend_delay on 32bits arch
  PM-runtime: Fix 'jiffies' in comments after switch to hrtimers
  cpufreq: scmi: Fix frequency invariance in slow path
  doc: trace: fix reference to cpuidle documentation file
  cpufreq: check if policy is inactive early in __cpufreq_get()
  cpufreq: scpi/scmi: Fix freeing of dynamic OPPs
  cpuidle / Documentation: Update cpuidle MAINTAINERS entry
  cpufreq / Documentation: Update cpufreq MAINTAINERS entry
  PM: sleep: call devfreq suspend/resume
2019-01-11 09:01:43 -08:00
Jacob Pan
5b438f4ba3 iommu/vt-d: Support page request in scalable mode
VT-d Rev3.0 has made a few changes to the page request interface,

1. widened PRQ descriptor from 128 bits to 256 bits;
2. removed streaming response type;
3. introduced private data that requires page response even the
   request is not last request in group (LPIG).

This is a supplement to commit 1c4f88b7f1 ("iommu/vt-d: Shared
virtual address in scalable mode") and makes the svm code compliant
with VT-d Rev3.0.

Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Liu Yi L <yi.l.liu@intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Fixes: 1c4f88b7f1 ("iommu/vt-d: Shared virtual address in scalable mode")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-01-11 13:10:03 +01:00
Rafael J. Wysocki
343e60e52a Merge branches 'pm-cpuidle', 'pm-cpufreq' and 'pm-sleep'
* pm-cpuidle:
  doc: trace: fix reference to cpuidle documentation file
  cpuidle / Documentation: Update cpuidle MAINTAINERS entry

* pm-cpufreq:
  cpufreq: scmi: Fix frequency invariance in slow path
  cpufreq: check if policy is inactive early in __cpufreq_get()
  cpufreq: scpi/scmi: Fix freeing of dynamic OPPs
  cpufreq / Documentation: Update cpufreq MAINTAINERS entry

* pm-sleep:
  PM: sleep: call devfreq suspend/resume
2019-01-11 10:09:51 +01:00
Eric Biggers
bec9ba7f37 crypto: cipher - remove struct cipher_desc
'struct cipher_desc' is unused.  Remove it.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-01-11 14:16:55 +08:00
Fabio Estevam
2076607a20 qcom-scm: Include <linux/err.h> header
Since commit e6f6d63ed1 ("drm/msm: add headless gpu device for imx5")
the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
error when building imx_v6_v7_defconfig:

In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use in this function)
  return -ENODEV;

Include the <linux/err.h> header file to fix this problem.

Reported-by: kernelci.org bot <bot@kernelci.org>
Fixes: e6f6d63ed1 ("drm/msm: add headless gpu device for imx5")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
2019-01-10 17:04:45 -06:00
Rob Herring
8ce5f84157 of: Remove struct device_node.type pointer
Now that all users of device_node.type pointer have been removed in
favor of accessor functions, we can remove it.

Cc: Frank Rowand <frowand.list@gmail.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
2019-01-10 16:24:44 -06:00
Micah Morton
c1a85a00ea LSM: generalize flag passing to security_capable
This patch provides a general mechanism for passing flags to the
security_capable LSM hook. It replaces the specific 'audit' flag that is
used to tell security_capable whether it should log an audit message for
the given capability check. The reason for generalizing this flag
passing is so we can add an additional flag that signifies whether
security_capable is being called by a setid syscall (which is needed by
the proposed SafeSetID LSM).

Signed-off-by: Micah Morton <mortonm@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.morris@microsoft.com>
2019-01-10 14:16:06 -08:00
Rafał Miłecki
5a1c18b761 bcma: keep a direct pointer to the struct device
Accessing struct device is pretty useful/common so having a direct
pointer:
1) Simplifies some code
2) Makes bcma_bus_get_host_dev() unneeded
3) Allows further improvements like using dev_* printing helpers

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-01-10 13:39:18 +02:00
Uwe Kleine-König
5d0a4c1189 pwm: Rearrange structures to group members by purpose
In pwm_ops there are a few callbacks that are not supposed to be used by
new drivers. Group them at the end of the structure and add a comment.

Similarily for struct pwm_chip group the members that drivers shouldn't
care about at the end and mark them as internal with another comment.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-01-10 09:35:00 +01:00
Uwe Kleine-König
cc2d224777 pwm: Drop per-chip dbg_show callback
This callback was introduced in commit 62099abf67 ("pwm: Add debugfs
interface") in 2012 and up to now there is not a single user. So drop
this unused code.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[thierry.reding@gmail.com: remove kerneldoc for ->dbg_show()]
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2019-01-10 09:34:12 +01:00
Bartosz Golaszewski
19e99de9a5 ARM: davinci: remove dead code related to MAC address reading
There are no more users of davinci_get_mac_addr(). Remove it.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-01-10 13:58:00 +05:30
Peter Hutterer
ee46967fc6 HID: core: replace the collection tree pointers with indices
Previously, the pointer to the parent collection was stored. If a device
exceeds 16 collections (HID_DEFAULT_NUM_COLLECTIONS), the array to store
the collections is reallocated, the pointer to the parent collection becomes
invalid.

Replace the pointers with an index-based lookup into the collections array.

Fixes: c53431eb69 ("HID: core: store the collections as a basic tree")
Reported-by: Pandruvada, Srinivas <srinivas.pandruvada@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Kyle Pelton <kyle.d.pelton@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2019-01-10 07:08:18 +01:00
Rafał Miłecki
321c46b915
MIPS: BCM47XX: Setup struct device for the SoC
So far we never had any device registered for the SoC. This resulted in
some small issues that we kept ignoring like:
1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing)
2) Lack of proper tree in the /sys/devices/
3) mips_dma_alloc_coherent() silently handling empty coherent_dma_mask

Kernel 4.19 came with a lot of DMA changes and caused a regression on
bcm47xx. Starting with the commit f8c55dc6e8 ("MIPS: use generic dma
noncoherent ops for simple noncoherent platforms") DMA coherent
allocations just fail. Example:
[    1.114914] bgmac_bcma bcma0:2: Allocation of TX ring 0x200 failed
[    1.121215] bgmac_bcma bcma0:2: Unable to alloc memory for DMA
[    1.127626] bgmac_bcma: probe of bcma0:2 failed with error -12
[    1.133838] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded

The bgmac driver also triggers a WARNING:
[    0.959486] ------------[ cut here ]------------
[    0.964387] WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 bgmac_enet_probe+0x1b4/0x5c4
[    0.973751] Modules linked in:
[    0.976913] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.9 #0
[    0.982750] Stack : 804a0000 804597c4 00000000 00000000 80458fd8 8381bc2c 838282d4 80481a47
[    0.991367]         8042e3ec 00000001 804d38f0 00000204 83980000 00000065 8381bbe0 6f55b24f
[    0.999975]         00000000 00000000 80520000 00002018 00000000 00000075 00000007 00000000
[    1.008583]         00000000 80480000 000ee811 00000000 00000000 00000000 80432c00 80248db8
[    1.017196]         00000009 00000204 83980000 803ad7b0 00000000 801feeec 00000000 804d0000
[    1.025804]         ...
[    1.028325] Call Trace:
[    1.030875] [<8000aef8>] show_stack+0x58/0x100
[    1.035513] [<8001f8b4>] __warn+0xe4/0x118
[    1.039708] [<8001f9a4>] warn_slowpath_null+0x48/0x64
[    1.044935] [<80248db8>] bgmac_enet_probe+0x1b4/0x5c4
[    1.050101] [<802498e0>] bgmac_probe+0x558/0x590
[    1.054906] [<80252fd0>] bcma_device_probe+0x38/0x70
[    1.060017] [<8020e1e8>] really_probe+0x170/0x2e8
[    1.064891] [<8020e714>] __driver_attach+0xa4/0xec
[    1.069784] [<8020c1e0>] bus_for_each_dev+0x58/0xb0
[    1.074833] [<8020d590>] bus_add_driver+0xf8/0x218
[    1.079731] [<8020ef24>] driver_register+0xcc/0x11c
[    1.084804] [<804b54cc>] bgmac_init+0x1c/0x44
[    1.089258] [<8000121c>] do_one_initcall+0x7c/0x1a0
[    1.094343] [<804a1d34>] kernel_init_freeable+0x150/0x218
[    1.099886] [<803a082c>] kernel_init+0x10/0x104
[    1.104583] [<80005878>] ret_from_kernel_thread+0x14/0x1c
[    1.110107] ---[ end trace f441c0d873d1fb5b ]---

This patch setups a "struct device" (and passes it to the bcma) which
allows fixing all the mentioned problems. It'll also require a tiny bcma
patch which will follow through the wireless tree & its maintainer.

Fixes: f8c55dc6e8 ("MIPS: use generic dma noncoherent ops for simple noncoherent platforms")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-wireless@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org # v4.19+
2019-01-09 13:21:02 -08:00
Dave Airlie
8c1a765bc6 drm-misc-next for 5.1:
UAPI Changes:
 
 Cross-subsystem Changes:
   - Turn dma-buf fence sequence numbers into 64 bit numbers
 
 Core Changes:
   - Move to a common helper for the DP MST hotplug for radeon, i915 and
     amdgpu
   - i2c improvements for drm_dp_mst
   - Removal of drm_syncobj_cb
   - Introduction of an helper to create and attach the TV margin properties
 
 Driver Changes:
   - Improve cache flushes for v3d
   - Reflection support for vc4
   - HDMI overscan support for vc4
   - Add implicit fencing support for rockchip and sun4i
   - Switch to generic fbdev emulation for virtio
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXDOTqAAKCRDj7w1vZxhR
 xZ8QAQD4j8m9Ea3bzY5Rr8BYUx1k+Cjj6Y6abZmot2rSvdyOHwD+JzJFIFAPZjdd
 uOKhLnDlubaaoa6OGPDQShjl9p3gyQE=
 =WQGO
 -----END PGP SIGNATURE-----

Merge tag 'drm-misc-next-2019-01-07-1' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

drm-misc-next for 5.1:

UAPI Changes:

Cross-subsystem Changes:
  - Turn dma-buf fence sequence numbers into 64 bit numbers

Core Changes:
  - Move to a common helper for the DP MST hotplug for radeon, i915 and
    amdgpu
  - i2c improvements for drm_dp_mst
  - Removal of drm_syncobj_cb
  - Introduction of an helper to create and attach the TV margin properties

Driver Changes:
  - Improve cache flushes for v3d
  - Reflection support for vc4
  - HDMI overscan support for vc4
  - Add implicit fencing support for rockchip and sun4i
  - Switch to generic fbdev emulation for virtio

Signed-off-by: Dave Airlie <airlied@redhat.com>

[airlied: applied amdgpu merge fixup]
From: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190107180333.amklwycudbsub3s5@flea
2019-01-10 05:58:52 +10:00
Dexuan Cui
ba50bf1ce9 Drivers: hv: vmbus: Check for ring when getting debug info
fc96df16a1 is good and can already fix the "return stack garbage" issue,
but let's also improve hv_ringbuffer_get_debuginfo(), which would silently
return stack garbage, if people forget to check channel->state or
ring_info->ring_buffer, when using the function in the future.

Having an error check in the function would eliminate the potential risk.

Add a Fixes tag to indicate the patch depdendency.

Fixes: fc96df16a1 ("Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels")
Cc: stable@vger.kernel.org
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-01-09 14:20:47 -05:00
Martin Sperl
412e603732
spi: core: avoid waking pump thread from spi_sync instead run teardown delayed
When spi_sync is running alone with no other spi devices connected
to the bus the worker thread is woken during spi_finalize_current_message
to run the teardown code every time.

This is totally unnecessary in the case that there is no message queued.

On a multi-core system this results in one wakeup of the thread for each
spi_message processed via spi_sync where in most cases the teardown does
not happen as the hw is already in use.

This patch now delays the teardown by 1 second by using a separate
kthread_delayed_work for the teardown.

This avoids waking the kthread too often.

For spi_sync transfers in a tight loop (say 40k messages/s) this
avoids the penalty of waking the worker thread 40k times/s.
On a rasperry pi 3 with 4 cores the results in 32% of a single core
only to find out that there is nothing in the queue and it can go back
to sleep.

With this patch applied the spi-worker is woken exactly once: after
the load finishes and the spi bus is idle for 1 second.

I believe I have also seen situations where during a spi_sync loop
the worker thread (triggered by the last message finished) is slightly
faster and _wins_ the race to process the message, so we are actually
running the kthread and letting it do some work...

This is also no longer observed with this patch applied as.

Tested with a new CAN controller driver for the mcp2517fd which
uses spi_sync for interrupt handling and spi_async for scheduling
of can frames for transmission (in a different thread)

Some statistics when receiving 100000 CAN frames with the mcp25xxfd driver
on a Raspberry pi 3:

without the patch:
------------------
root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done
(spi0)                    5
(irq/94-mcp25xxf)         0
root@raspcm3:~# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 821960  13592  50848    0    0    80     2 1986  105  1  2 97  0  0
 0  0      0 821968  13592  50876    0    0     0     0 8046   30  0  0 100  0  0
 0  0      0 821936  13592  50876    0    0     0     0 8032   24  0  0 100  0  0
 0  0      0 821936  13592  50876    0    0     0     0 8035   30  0  0 100  0  0
 0  0      0 821936  13592  50876    0    0     0     0 8033   22  0  0 100  0  0
 2  0      0 821936  13592  50876    0    0     0     0 11598 7129  0  3 97  0  0
 1  0      0 821872  13592  50876    0    0     0     0 37741 59003  0 31 69  0  0
 2  0      0 821840  13592  50876    0    0     0     0 37762 59078  0 29 71  0  0
 2  0      0 821776  13592  50876    0    0     0     0 37593 58792  0 28 72  0  0
 1  0      0 821744  13592  50876    0    0     0     0 37642 58881  0 30 70  0  0
 2  0      0 821680  13592  50876    0    0     0     0 37490 58602  0 27 73  0  0
 1  0      0 821648  13592  50876    0    0     0     0 37412 58418  0 29 71  0  0
 1  0      0 821584  13592  50876    0    0     0     0 37337 58288  0 27 73  0  0
 1  0      0 821552  13592  50876    0    0     0     0 37584 58774  0 27 73  0  0
 0  0      0 821520  13592  50876    0    0     0     0 18363 20566  0  9 91  0  0
 0  0      0 821520  13592  50876    0    0     0     0 8037   32  0  0 100  0  0
 0  0      0 821520  13592  50876    0    0     0     0 8031   23  0  0 100  0  0
 0  0      0 821520  13592  50876    0    0     0     0 8034   26  0  0 100  0  0
 0  0      0 821520  13592  50876    0    0     0     0 8033   24  0  0 100  0  0
^C
root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done
(spi0)                  228
(irq/94-mcp25xxf)       794
root@raspcm3:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 17:         34          0          0          0  ARMCTRL-level   1 Edge      3f00b880.mailbox
 27:          1          0          0          0  ARMCTRL-level  35 Edge      timer
 33:    1416870          0          0          0  ARMCTRL-level  41 Edge      3f980000.usb, dwc2_hsotg:usb1
 34:          1          0          0          0  ARMCTRL-level  42 Edge      vc4
 35:          0          0          0          0  ARMCTRL-level  43 Edge      3f004000.txp
 40:       1753          0          0          0  ARMCTRL-level  48 Edge      DMA IRQ
 42:         11          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ
 44:         11          0          0          0  ARMCTRL-level  52 Edge      DMA IRQ
 45:          0          0          0          0  ARMCTRL-level  53 Edge      DMA IRQ
 66:          0          0          0          0  ARMCTRL-level  74 Edge      vc4 crtc
 69:          0          0          0          0  ARMCTRL-level  77 Edge      vc4 crtc
 70:          0          0          0          0  ARMCTRL-level  78 Edge      vc4 crtc
 77:         20          0          0          0  ARMCTRL-level  85 Edge      3f205000.i2c, 3f804000.i2c, 3f805000.i2c
 78:       6346          0          0          0  ARMCTRL-level  86 Edge      3f204000.spi
 80:        205          0          0          0  ARMCTRL-level  88 Edge      mmc0
 81:        493          0          0          0  ARMCTRL-level  89 Edge      uart-pl011
 89:          0          0          0          0  bcm2836-timer   0 Edge      arch_timer
 90:       4291       3821       2180       1649  bcm2836-timer   1 Edge      arch_timer
 94:      14289          0          0          0  pinctrl-bcm2835  16 Level     mcp25xxfd
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0          0          0          0  Timer broadcast interrupts
IPI2:       3645     242371       7919       1328  Rescheduling interrupts
IPI3:        112        543        273        194  Function call interrupts
IPI4:          0          0          0          0  CPU stop interrupts
IPI5:          1          0          0          0  IRQ work interrupts
IPI6:          0          0          0          0  completion interrupts
Err:          0

top shows 93% for the mcp25xxfd interrupt handler, 31% for spi0.

with the patch:
---------------
root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done
(spi0)                    0
(irq/94-mcp25xxf)         0
root@raspcm3:~# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 0  0      0 804768  13584  62628    0    0     0     0 8038   24  0  0 100  0  0
 0  0      0 804768  13584  62628    0    0     0     0 8042   25  0  0 100  0  0
 1  0      0 804704  13584  62628    0    0     0     0 9603 2967  0 20 80  0  0
 1  0      0 804672  13584  62628    0    0     0     0 9828 3380  0 24 76  0  0
 1  0      0 804608  13584  62628    0    0     0     0 9823 3375  0 23 77  0  0
 1  0      0 804608  13584  62628    0    0     0    12 9829 3394  0 23 77  0  0
 1  0      0 804544  13584  62628    0    0     0     0 9816 3362  0 22 78  0  0
 1  0      0 804512  13584  62628    0    0     0     0 9817 3367  0 23 77  0  0
 1  0      0 804448  13584  62628    0    0     0     0 9822 3370  0 22 78  0  0
 1  0      0 804416  13584  62628    0    0     0     0 9815 3367  0 23 77  0  0
 0  0      0 804352  13584  62628    0    0     0    84 9222 2250  0 14 86  0  0
 0  0      0 804352  13592  62620    0    0     0    24 8131  209  0  0 93  7  0
 0  0      0 804320  13592  62628    0    0     0     0 8041   27  0  0 100  0  0
 0  0      0 804352  13592  62628    0    0     0     0 8040   26  0  0 100  0  0
root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done
(spi0)                    0
(irq/94-mcp25xxf)       767
root@raspcm3:~# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 17:         29          0          0          0  ARMCTRL-level   1 Edge      3f00b880.mailbox
 27:          1          0          0          0  ARMCTRL-level  35 Edge      timer
 33:    1024412          0          0          0  ARMCTRL-level  41 Edge      3f980000.usb, dwc2_hsotg:usb1
 34:          1          0          0          0  ARMCTRL-level  42 Edge      vc4
 35:          0          0          0          0  ARMCTRL-level  43 Edge      3f004000.txp
 40:       1773          0          0          0  ARMCTRL-level  48 Edge      DMA IRQ
 42:         11          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ
 44:         11          0          0          0  ARMCTRL-level  52 Edge      DMA IRQ
 45:          0          0          0          0  ARMCTRL-level  53 Edge      DMA IRQ
 66:          0          0          0          0  ARMCTRL-level  74 Edge      vc4 crtc
 69:          0          0          0          0  ARMCTRL-level  77 Edge      vc4 crtc
 70:          0          0          0          0  ARMCTRL-level  78 Edge      vc4 crtc
 77:         20          0          0          0  ARMCTRL-level  85 Edge      3f205000.i2c, 3f804000.i2c, 3f805000.i2c
 78:       6417          0          0          0  ARMCTRL-level  86 Edge      3f204000.spi
 80:        237          0          0          0  ARMCTRL-level  88 Edge      mmc0
 81:        489          0          0          0  ARMCTRL-level  89 Edge      uart-pl011
 89:          0          0          0          0  bcm2836-timer   0 Edge      arch_timer
 90:       4048       3704       2383       1892  bcm2836-timer   1 Edge      arch_timer
 94:      14287          0          0          0  pinctrl-bcm2835  16 Level     mcp25xxfd
IPI0:          0          0          0          0  CPU wakeup interrupts
IPI1:          0          0          0          0  Timer broadcast interrupts
IPI2:       2361       2948       7890       1616  Rescheduling interrupts
IPI3:         65        617        301        166  Function call interrupts
IPI4:          0          0          0          0  CPU stop interrupts
IPI5:          1          0          0          0  IRQ work interrupts
IPI6:          0          0          0          0  completion interrupts
Err:          0
top shows 91% for the mcp25xxfd interrupt handler, 0% for spi0

So we see that spi0 is no longer getting scheduled wasting CPU cycles
There are a lot less context switches and corresponding Rescheduling interrupts
All of these show that this improves efficiency of the system and reduces
CPU utilization.

Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-09 19:16:18 +00:00
Bartosz Golaszewski
03c87b95ac
regulator: provide rdev_get_regmap()
Provide a helper allowing to access regulator's regmap.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-09 18:36:44 +00:00
Eric Anholt
670c672608 soc: bcm: bcm2835-pm: Add support for power domains under a new binding.
This provides a free software alternative to raspberrypi-power.c's
firmware calls to manage power domains.  It also exposes a reset line,
where previously the vc4 driver had to try to force power off the
domain in order to trigger a reset.

Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
2019-01-09 16:55:09 +01:00
Eric Anholt
5e6acc3e67 bcm2835-pm: Move bcm2835-watchdog's DT probe to an MFD.
The PM block that the wdt driver was binding to actually has multiple
features we want to expose (power domains, reset, watchdog).  Move the
DT attachment to a MFD driver and make WDT probe against MFD.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
2019-01-09 16:55:06 +01:00
Linus Walleij
f3186dd876
spi: Optionally use GPIO descriptors for CS GPIOs
This augments the SPI core to optionally use GPIO descriptors
for chip select on a per-master-driver opt-in basis.

Drivers using this will rely on the SPI core to look up
GPIO descriptors associated with the device, such as
when using device tree or board files with GPIO descriptor
tables.

When getting descriptors from the device tree, this will in
turn activate the code in gpiolib that was
added in commit 6953c57ab1
("gpio: of: Handle SPI chipselect legacy bindings")
which means that these descriptors are aware of the active
low semantics that is the default for SPI CS GPIO lines
and we can assume that all of these are "active high" and
thus assign SPI_CS_HIGH to all CS lines on the DT path.

The previously used gpio_set_value() would call down into
gpiod_set_raw_value() and ignore the polarity inversion
semantics.

It seems like many drivers go to great lengths to set up the
CS GPIO line as non-asserted, respecting SPI_CS_HIGH. We pull
this out of the SPI drivers and into the core, and by simply
requesting the line as GPIOD_OUT_LOW when retrieveing it from
the device and relying on the gpiolib to handle any inversion
semantics. This way a lot of code can be simplified and
removed in each converted driver.

The end goal after dealing with each driver in turn, is to
delete the non-descriptor path (of_spi_register_master() for
example) and let the core deal with only descriptors.

The different SPI drivers have complex interactions with the
core so we cannot simply change them all over, we need to use
a stepwise, bisectable approach so that each driver can be
converted and fixed in isolation.

This patch has the intended side effect of adding support for
ACPI GPIOs as it starts relying on gpiod_get_*() to get
the GPIO handle associated with the device.

Cc: Linuxarm <linuxarm@huawei.com>
Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Fangjian (Turing) <f.fangjian@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-09 12:39:25 +00:00