Merged TI feature rpmsg into ti-linux-4.19.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg

* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  Revert "HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots"
  ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
  ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
  ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y-intg

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

Merge branch 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Add required DT support for early-booted IPU on am57x and dra7xx
platforms and revert previous hack for using CMA pools.

* 'topic/4.19/dra7-late-attach' of git://git.ti.com/rpmsg/remoteproc:
  Revert "HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots"
  ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
  ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
  ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
  ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

Revert "HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots"

This reverts commit ed2d95b1520770319b74c58d69d0e5116f9dccdc.

This patch must be reverted to enable IPU early boot when configured
as default in SPL config.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

Merged TI feature platform_base into ti-linux-4.19.y

TI-Feature: platform_base
TI-Branch: platform-ti-linux-4.19.y

* 'platform-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform:
  clk: ti: clockdomain: fix static checker warning
  clk: ti: autoidle: add checks against NULL pointer reference
  ARM: omap2+: hwmod: fix static checker warnings
  ARM: dts: dra71-evm: mark ldo0 regulator as always on

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

clk: ti: clockdomain: fix static checker warning

Fix a memory leak induced by not calling clk_put after doing of_clk_get.

Reported-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

clk: ti: autoidle: add checks against NULL pointer reference

The clk pointer passed to omap2_clk_(deny|allow)_idle can be NULL, so
add checks for this.

Reported-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: omap2+: hwmod: fix static checker warnings

Fix following static checker found issues for omap hwmod core:

1) setup_reset may return r which is unitialized
2) couple of potential memory leaks within omap_hwmod_allocate_module
3) possible NULL pointer access within omap_hwmod_get_pwrdm

Reported-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>

ARM: dts: dra71-evm: mark ldo0 regulator as always on

LDO0 regulator must remain enabled always on dra71-evm boards. Disabling
this violates the data manual and will damage the device over time.

Reported-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>

Merged TI feature audio-display into ti-linux-4.19.y

TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y

* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display: (26 commits)
  arm64: dts: ti: k3-j721e: Disable MHDP in SoC- and enable in board-dt
  arm64: dts: ti: k3-j721: cleanup DP connector data
  arm64: dts: ti: k3-j721: move DP routing and pinmux to board DT file
  phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver
  Revert "HACK: phy: ti: j721e-wiz: override WIZ settings for DP"
  arm64: dts: ti: k3-j721e-proc-board-tps65917: Update wiz lane<n>-mode props
  arm64: dts: ti: k3-j721e-common-proc-board: Update wiz lane<n>-mode props
  dt-bindings: phy: ti,phy-j721e-wiz: Add "lane<n>-mode" properties
  dt-bindings: phy: Add PHY_TYPE_DP definition
  arm64: dts: ti: k3-j721e-main: Update wiz node compatible strings
  phy: ti: j721e-wiz: Use "ti,j721e-wiz-10g" or "ti,j721e-wiz-16g" compatible
  dt-bindings: phy: ti,phy-j721e-wiz: Add *-10g and *-16g to compatible
  drm/bridge: cdns-mhdp: Add error handling for phy_configure() function.
  drm/bridge: cdns-mhdp: Set correct value in framer config register.
  drm/bridge: cdns-mhdp: Add support for SSC handling.
  drm/bridge: cdns-mhdp: Add function to get max number of lanes.
  drm/bridge: cdns-mhdp: Remove extra phy configuration calls.
  drm/bridge: cdns-mhdp: Add separate function to improve code redability.
  drm/bridge: cdns-mhdp: Fix to read correct DPCD registers for DP 1.4+ devices
  drm/bridge: cdns-mhdp: Remove setting register DP_SET_POWER twice.
  ...

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'ti-linux-4.19.y-dp-wiz' into audio_display-ti-linux-4.19.y

Wiz DP HACK cleanup.

* ti-linux-4.19.y-dp-wiz:
  arm64: dts: ti: k3-j721e: Disable MHDP in SoC- and enable in board-dt
  arm64: dts: ti: k3-j721: cleanup DP connector data
  arm64: dts: ti: k3-j721: move DP routing and pinmux to board DT file
  phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver
  Revert "HACK: phy: ti: j721e-wiz: override WIZ settings for DP"
  arm64: dts: ti: k3-j721e-proc-board-tps65917: Update wiz lane<n>-mode props
  arm64: dts: ti: k3-j721e-common-proc-board: Update wiz lane<n>-mode props
  dt-bindings: phy: ti,phy-j721e-wiz: Add "lane<n>-mode" properties
  dt-bindings: phy: Add PHY_TYPE_DP definition
  arm64: dts: ti: k3-j721e-main: Update wiz node compatible strings
  phy: ti: j721e-wiz: Use "ti,j721e-wiz-10g" or "ti,j721e-wiz-16g" compatible
  dt-bindings: phy: ti,phy-j721e-wiz: Add *-10g and *-16g to compatible

arm64: dts: ti: k3-j721e: Disable MHDP in SoC- and enable in board-dt

The DisplayPort IP is not usable without pinmuxing and DisplayPort
connector, so lets disable it in SoC dt and enable in board dt files.

Signed-off-by: Jyri Sarha <jsarha@ti.com>

arm64: dts: ti: k3-j721: cleanup DP connector data

Clean up the DP connector data by fixing bad indent, remove the comment,
and adding connector label.

There is no binding for connectors yet, so this data is not used.
However, in mainline a connector binding has been sent for review, and
while it doesn't yet have DP support, this binding has been made to be
compatible in style with the proposed one.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

arm64: dts: ti: k3-j721: move DP routing and pinmux to board DT file

We should not setup DP routes in the SoC dt file, but in the board dt
file. Nor should we set the pinctrl in SoC dt, especially if the
property is referring to a setting that is found in the board DT file.

Fix this by removing the ports and pinctrl settings from mhdp node in
k3-j721e-main.dtsi, and moving these to the board dt files. Also
remove obsolete TODO pinmux comment.

Signed-off-by: Jyri Sarha <jsarha@ti.com>

phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver

For DisplayPort use we need to set WIZ_CONFIG_LANECTL register's
P_STANDARD_MODE bits to "mode 3". In the DisplayPort use also the
P_ENABLE bits of the same register are set to P_ENABLE instead of
P_ENABLE_FORCE, so that the DisplayPort driver can enable and disable
the lane as needed. The DisplayPort mode is selected according to
lane<n>-mode -property. All other values of lane<n>-mode -property but
PHY_TYPE_DP will set P_STANDARD_MODE bits to 0 and P_ENABLE bits to
force enable.

History

This patch replaces the earlier hard coded hack for DisplayPort use
and uses new "port-use" dts property to select use mode for each lane
separately.

It appears the only mandatory part of the earlier hack was setting a
different mode for all the DP lanes. Also the LANECTL P0_FORCE_ENABLE
for lane 0 is changed to P0_ENABLE. The both settings appear to work,
but using P0_FORCE_ENABLE may prevent lane reset from the controller
to take effect.

With this patch the DisplayPort still works, but all the register do
not have the same values as before.

Here is the diff between wiz setting before and after this patch:

Register                   | Earlier    | Now        | Functional change
WIZ_SERDES_TOP_CTRL 0x408  | 0x30000000 | 0xb8000000 | Ext ref clk only [1]
WIZ_SERDES_RST      0x40c  | 0x39000000 | 0x31000000 | Ext ref clk only [2]
WIZ_LANECTL(0)      0x480  | 0x70000000 | 0x80000000 | Force enable, align.. [3]
WIZ_LANECTL(1)      0x4c0  | 0x80000000 | 0x80000000 |
WIZ_LANECTL(2)      0x500  | 0x80000000 | 0x80000000 |
WIZ_LANECTL(3)      0x540  | 0x80000000 | 0x80000000 |
WIZ_LANEDIV(0)      0x484  | 0x00010001 | 0x00000000 | The divider is unused
WIZ_LANEDIV(1)      0x4c4  | 0x00010001 | 0x00000000 | The divider is unused
WIZ_LANEDIV(2)      0x504  | 0x00010001 | 0x00000000 | The divider is unused
WIZ_LANEDIV(3)      0x544  | 0x00010001 | 0x00000000 | The divider is unused

The above is before Wiz is taken out of reset (0x40c bit 31).

[1] Bits 31-30 sets external PMA common differential reference clock
    mode. Setting 10 is for under 100Mhz rates (the old 00 is for greater
    than 100MHz rates). J721E evm uses internal reference clock.

[2] Bit 27 disables termination for the external PMA common differential
    reference clock. J721E evm uses internal reference clock.

[3] Bit 29 is auto align to 8B10B comma characters and 28 is auto
    sequence the RAW interface according to the configuration
    settings, neither should affect DisplayPort behavior. Bit 31 is
    normal enable and 30 is force enable.

Signed-off-by: Jyri Sarha <jsarha@ti.com>

Revert "HACK: phy: ti: j721e-wiz: override WIZ settings for DP"

This reverts commit 0aff9875e09c8bdd507be2a1188b4b024a642a57.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>

arm64: dts: ti: k3-j721e-proc-board-tps65917: Update wiz lane<n>-mode props

Update lane<n>-mode properties in wiz nodes according to the lane use
on tps65917 processor board.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>

arm64: dts: ti: k3-j721e-common-proc-board: Update wiz lane<n>-mode props

Update lane<n>-mode properties in wiz nodes according to the lane use
on common processor board.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>

dt-bindings: phy: ti,phy-j721e-wiz: Add "lane<n>-mode" properties

Add binding documentation for an optional "lane<n>-mode" properties. The
new property statically assings lane usage for each lane of the wrapped
SERDES.

Signed-off-by: Jyri Sarha <jsarha@ti.com>

dt-bindings: phy: Add PHY_TYPE_DP definition

Add definition for DisplayPort phy type.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>

arm64: dts: ti: k3-j721e-main: Update wiz node compatible strings

There is now separate compatible strings for Torrent and Sierra wiz
wrappers. "ti,j721e-wiz-10g" is for Torrent Wiz and "ti,j721e-wiz-16g"
is for Sierra Wiz.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>

phy: ti: j721e-wiz: Use "ti,j721e-wiz-10g" or "ti,j721e-wiz-16g" compatible

Update compatible strings according to the latest binding document.
The Wiz wrappers for Sierra and Torrent have some subtle differences
so separate compatible properties for them is justified.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>

dt-bindings: phy: ti,phy-j721e-wiz: Add *-10g and *-16g to compatible

Add "ti,j721e-wiz-10g" compatible for Torrent wrapper and change
Sierra wrapper compatible to "ti,j721e-wiz-16g". The Torrent and Sierra
phy wiz-wrappers have some subtle differences, so it is better to have
separate compatible properties for them too.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>

Merged TI feature platform_base into ti-linux-4.19.y

TI-Feature: platform_base
TI-Branch: platform-ti-linux-4.19.y

* 'platform-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/platform:
  ti_config_fragments: v8_baseport: Enable watchdog
  arm64: dts: ti: k3-j721e-main: Add MAIN domain watchdog entries
  watchdog: Add K3 RTI watchdog support
  dt-bindings: watchdog: Add support for TI K3 RTI watchdog
  watchdog: add support for resetting keepalive timers at start

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge branch 'ti-linux-4.19.y-cdns-fixes' into audio_display-ti-linux-4.19.y

c-t-collab branches cdns-dp-lt-fixes-v2 and  cdns-phy-torrent-v2 rebased.

* ti-linux-4.19.y-cdns-fixes:
  drm/bridge: cdns-mhdp: Add error handling for phy_configure() function.
  drm/bridge: cdns-mhdp: Set correct value in framer config register.
  drm/bridge: cdns-mhdp: Add support for SSC handling.
  drm/bridge: cdns-mhdp: Add function to get max number of lanes.
  drm/bridge: cdns-mhdp: Remove extra phy configuration calls.
  drm/bridge: cdns-mhdp: Add separate function to improve code redability.
  drm/bridge: cdns-mhdp: Fix to read correct DPCD registers for DP 1.4+ devices
  drm/bridge: cdns-mhdp: Remove setting register DP_SET_POWER twice.
  dt-bindings: phy: Update Cadence MHDP PHY bindings
  ti_config_fragments: Update Kconfig option for Cadence DP PHY driver
  arm64: dts: ti: k3-j721e-main: Update dp-phy compatible string
  phy: ti: j721e-wiz: Update dp-phy compatible string
  phy: phy-cadence-torrent: Rename DP PHY terms in Cadence Torrent PHY driver
  phy: phy-cadence-dp: Rename DP PHY driver to have a more generic name.

ti_config_fragments: v8_baseport: Enable watchdog

Enable RTI watchdog support for K3 SoCs.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

arm64: dts: ti: k3-j721e-main: Add MAIN domain watchdog entries

Add DT entries for main domain watchdog0 and 1 instances.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

watchdog: Add K3 RTI watchdog support

Texas Instruments K3 SoCs contain an RTI (Real Time Interrupt) module
which can be used as a watchdog. This IP provides a support for
windowed watchdog mode, in which the watchdog must be petted within
a certain time window. If it is petted either too soon, or too late,
a watchdog error will be triggered.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

dt-bindings: watchdog: Add support for TI K3 RTI watchdog

TI K3 SoCs contain an RTI (Real Time Interrupt) module which can be
used to implement a windowed watchdog functionality.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

watchdog: add support for resetting keepalive timers at start

Current watchdog core pets the timer always after the initial keepalive
time has expired from boot-up. This is incorrect for certain timers that
don't like to be petted immediately when they are started, if they have
not been running over the boot.

To allow drivers to reset their keepalive timers during startup, add
a new watchdog flag to the api, WDOG_RESET_KEEPALIVE.

Signed-off-by: Tero Kristo <t-kristo@ti.com>

drm/bridge: cdns-mhdp: Add error handling for phy_configure() function.

phy_configure() returns a value and may fail. Check the return value
and add error handling.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/bridge: cdns-mhdp: Set correct value in framer config register.

wr_vhsync_fall bit in register DP_FRAMER_GLOBAL_CONFIG_p should always
be set to 1 as per recommendation.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/bridge: cdns-mhdp: Add support for SSC handling.

Add proper handling for SSC, remove hardcoding.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/bridge: cdns-mhdp: Add function to get max number of lanes.

Add separate function to get max number of lanes. Also, during channel
equalization phase of link training, for fallback case in which training
is unsuccessful and link rate is lowered, at this stage, restore lane
count to max number of lanes supported.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/bridge: cdns-mhdp: Remove extra phy configuration calls.

In function mhdp_link_training, for fallback cases where training is
unsuccessful, remove phy configuration calls, as we are restarting
the link training procedure. So phy confiigure will be executed in
function mhdp_link_training_init().

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/bridge: cdns-mhdp: Add separate function to improve code redability.

Add separate function to fill sink capabilities.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/bridge: cdns-mhdp: Fix to read correct DPCD registers for DP 1.4+ devices

DP 1.4 introduced a DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT bit in
DP_TRAINING_AUX_RD_INTERVAL register. If set, DPCD registers from
DP_DPCD_REV to DP_ADAPTER_CAP should be retrieved starting from
DP_DPCD_REV_EXTENDED. All registers are copied except DP_DPCD_REV,
DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT which represent the
"true capabilities" of DPRX device.

Original DP_DPCD_REV, DP_MAX_LINK_RATE and DP_DOWNSTREAMPORT_PRESENT
might falsely return lower capabilities to avoid interoperability
issues with some of the existing DP Source devices that malfunction
when they discover the higher capabilities within those three
registers.

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/bridge: cdns-mhdp: Remove setting register DP_SET_POWER twice.

Function cdns_mhdp_link_up() configures register DP_SET_POWER. It also
calls drm_dp_link_power_up() which internally configures the same
register. So remove setting DP_SET_POWER explicitly from function
cdns_mhdp_link_up().

Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

Merged TI feature audio-display into ti-linux-4.19.y

TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y

* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display:
  drm/bridge: tc358767: fix max_tu_symbol value
  drm/tidss: fix probe-time memleak
  drm/tidss: remove empty function

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

dt-bindings: phy: Update Cadence MHDP PHY bindings

Update compatible string from "cdns,dp-phy" to "cdns,torrent-phy"
in accordance with changes in Cadence Torrent Phy driver.

Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

ti_config_fragments: Update Kconfig option for Cadence DP PHY driver

Update Kconfig option for Cadence PHY driver from CONFIG_PHY_CADENCE_DP to
CONFIG_PHY_TORRENT in accordance with the changes done in Cadence Torrent
Phy driver Kconfig.

Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

arm64: dts: ti: k3-j721e-main: Update dp-phy compatible string

Update compatible string from "cdns,dp-phy" to "cdns,torrent-phy"
in accordance with the changes done in Cadence Torrent Phy driver.

Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

phy: ti: j721e-wiz: Update dp-phy compatible string

Update compatible string from "cdns,dp-phy" to "cdns,torrent-phy"
in accordance with changes done in Cadence Torrent Phy driver.

Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

phy: phy-cadence-torrent: Rename DP PHY terms in Cadence Torrent PHY driver

 Rename DP PHY terms used in driver to use more generic torrent phy
 nomenclature.
 - Change driver compatible from "cdns,dp-phy" to "cdns,torrent-phy"
 - Change private data struct cdns_dp_phy to cdns_torrent_phy
 - Change module description and registration accordingly
 - Generic torrent functions have prefix cdns_torrent_phy_*
 - Functions specific to Torrent phy for DP are prefixed as
   cdns_torrent_dp_*

Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

phy: phy-cadence-dp: Rename DP PHY driver to have a more generic name.

Rename Cadence DP PHY driver from phy-cadence-dp to phy-cadence-torrent
to make it more generic for future use. However, currently the driver
supports Torrent PHY for DisplayPort protocol only. Modifiy Makefile and
Kconfig accordingly.

Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

Merge branch 'ti/4.19-pull-2' of https://bitbucket.itg.ti.com/scm/~a0400822/linux into audio_display-ti-linux-4.19.y

Display patches for .05, part 2

* 'ti/4.19-pull-2' of https://bitbucket.itg.ti.com/scm/~a0400822/linux:
  drm/bridge: tc358767: fix max_tu_symbol value
  drm/tidss: fix probe-time memleak
  drm/tidss: remove empty function

Merged TI feature audio-display into ti-linux-4.19.y

TI-Feature: audio-display
TI-Branch: audio_display-ti-linux-4.19.y

* 'audio_display-ti-linux-4.19.y' of ssh://bitbucket.itg.ti.com/lcpdpublicdom/audio-display: (29 commits)
  drm/tidss: dispc7: Change all const static to static const to silence W=1
  drm/tidss: dispc7: Fix W=1 warnings from dispc6_vp_mode_valid()
  drm/tidss: dispc6: Remove unsused fir coefs to fix W=1 warnings
  drm/tidss: dispc6: Fix W=1 warnings from dispc6_vp_mode_valid()
  drm/tidss: scale_coefs: Remove unused coefs_null to silence W=1
  drm/tidss: WB: fix error reporting in tidss_wb_init
  drm/tidss: WB: remove unnecessary kernel trace
  media: i2c: ov5640: fix potential null pointer dereference
  drm/tidss: dispc7: Drop redundant and uneeded max_pclk and min_pclk
  drm/tidss: dispc7: Implement VP bus format specific limits
  drm/tidss: dispc7: More explicit enum and struct member name
  drm/tidss: dispc7: Ensure output width is divisible by 2
  drm/bridge: cdns-mhdp: Check link status if HPD interrupt is received
  drm/bridge: cdns-mhdp: Protect firmware mailbox messaging with mutex
  drm/bridge: cdns-mhdp: Add missing resource deallocations
  drm/bridge: cdns-mhdp: Print error if DP link BW isn't enough for mode
  drm/bridge: cdns-mhdp: Add simple mode_valid()
  drm/bridge: sii902x: fix missing static
  drm/omap: hdmi4: fix use of uninitialized var
  drm/tidss: cleanup dma related settings
  ...

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merged TI feature rpmsg into ti-linux-4.19.y

TI-Feature: rpmsg
TI-Branch: rpmsg-ti-linux-4.19.y-intg

* 'rpmsg-ti-linux-4.19.y-intg' of git://git.ti.com/rpmsg/rpmsg:
  remoteproc/k3-r5: initialize TCM memories for ECC

Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>

Merge tag 'v4.19.79' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-4.19.y

This is the 4.19.79 stable release

* tag 'v4.19.79' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (627 commits)
  Linux 4.19.79
  nl80211: validate beacon head
  cfg80211: Use const more consistently in for_each_element macros
  cfg80211: add and use strongly typed element iteration macros
  staging: erofs: detect potential multiref due to corrupted images
  staging: erofs: add two missing erofs_workgroup_put for corrupted images
  staging: erofs: some compressed cluster should be submitted for corrupted images
  staging: erofs: fix an error handling in erofs_readdir()
  coresight: etm4x: Use explicit barriers on enable/disable
  vfs: Fix EOVERFLOW testing in put_compat_statfs64
  arm64/speculation: Support 'mitigations=' cmdline option
  arm64: Use firmware to detect CPUs that are not affected by Spectre-v2
  arm64: Force SSBS on context switch
  arm64: ssbs: Don't treat CPUs with SSBS as unaffected by SSB
  arm64: add sysfs vulnerability show for speculative store bypass
  arm64: add sysfs vulnerability show for spectre-v2
  arm64: Always enable spectre-v2 vulnerability detection
  arm64: Advertise mitigation of Spectre-v2, or lack thereof
  arm64: Provide a command line to disable spectre_v2 mitigation
  arm64: Always enable ssb vulnerability detection
  ...

Signed-off-by: Dan Murphy <dmurphy@ti.com>

Merge branch 'audio_display-ti-linux-2019.05' into audio_display-ti-linux-4.19.y

* audio_display-ti-linux-2019.05: (29 commits)
  drm/tidss: dispc7: Change all const static to static const to silence W=1
  drm/tidss: dispc7: Fix W=1 warnings from dispc6_vp_mode_valid()
  drm/tidss: dispc6: Remove unsused fir coefs to fix W=1 warnings
  drm/tidss: dispc6: Fix W=1 warnings from dispc6_vp_mode_valid()
  drm/tidss: scale_coefs: Remove unused coefs_null to silence W=1
  drm/tidss: WB: fix error reporting in tidss_wb_init
  drm/tidss: WB: remove unnecessary kernel trace
  media: i2c: ov5640: fix potential null pointer dereference
  drm/tidss: dispc7: Drop redundant and uneeded max_pclk and min_pclk
  drm/tidss: dispc7: Implement VP bus format specific limits
  drm/tidss: dispc7: More explicit enum and struct member name
  drm/tidss: dispc7: Ensure output width is divisible by 2
  drm/bridge: cdns-mhdp: Check link status if HPD interrupt is received
  drm/bridge: cdns-mhdp: Protect firmware mailbox messaging with mutex
  drm/bridge: cdns-mhdp: Add missing resource deallocations
  drm/bridge: cdns-mhdp: Print error if DP link BW isn't enough for mode
  drm/bridge: cdns-mhdp: Add simple mode_valid()
  drm/bridge: sii902x: fix missing static
  drm/omap: hdmi4: fix use of uninitialized var
  drm/tidss: cleanup dma related settings
  ...

drm/bridge: tc358767: fix max_tu_symbol value

max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not
what the spec says. The spec says:

roundup ((input active video bandwidth in bytes/output active video
bandwidth in bytes) * tu_size)

It is not quite clear what the above means, but calculating
max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and
fixes the issues seen.

This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes &
1.62Gbps was pretty bad for me).

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190924131702.9988-1-tomi.valkeinen@ti.com

drm/tidss: fix probe-time memleak

If tidss_modeset_init fails, which happens easily due to deferred
probing, drm_mode_config_cleanup() is not called and we leak lots of DRM
objects.

Fix this by adding the proper error handling, and for consistency, add
tidss_modeset_cleanup() which is the mirror for tidss_modeset_init().

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/tidss: remove empty function

tidss_modeset_init_properties() is empty, and called during modeset
init. Drop the useless function.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Merge branch 'rpmsg-ti-linux-4.19.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.19.y-intg

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

Merge branch 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.19.y

Pull in the am65x topic branch that includes a fix for initializing TCM
memories for ECC.

* 'topic/4.19/am65x' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/k3-r5: initialize TCM memories for ECC

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>

Linux 4.19.79

nl80211: validate beacon head

commit f88eb7c0d002a67ef31aeb7850b42ff69abc46dc upstream.

We currently don't validate the beacon head, i.e. the header,
fixed part and elements that are to go in front of the TIM
element. This means that the variable elements there can be
malformed, e.g. have a length exceeding the buffer size, but
most downstream code from this assumes that this has already
been checked.

Add the necessary checks to the netlink policy.

Cc: stable@vger.kernel.org
Fixes: ed1b6cc7f80f ("cfg80211/nl80211: add beacon settings")
Link: https://lore.kernel.org/r/1569009255-I7ac7fbe9436e9d8733439eab8acbbd35e55c74ef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cfg80211: Use const more consistently in for_each_element macros

commit 7388afe09143210f555bdd6c75035e9acc1fab96 upstream.

Enforce the first argument to be a correct type of a pointer to struct
element and avoid unnecessary typecasts from const to non-const pointers
(the change in validate_ie_attr() is needed to make this part work). In
addition, avoid signed/unsigned comparison within for_each_element() and
mark struct element packed just in case.

Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cfg80211: add and use strongly typed element iteration macros

commit 0f3b07f027f87a38ebe5c436490095df762819be upstream.

Rather than always iterating elements from frames with pure
u8 pointers, add a type "struct element" that encapsulates
the id/datalen/data format of them.

Then, add the element iteration macros
 * for_each_element
 * for_each_element_id
 * for_each_element_extid

which take, as their first 'argument', such a structure and
iterate through a given u8 array interpreting it as elements.

While at it and since we'll need it, also add
 * for_each_subelement
 * for_each_subelement_id
 * for_each_subelement_extid

which instead of taking data/length just take an outer element
and use its data/datalen.

Also add for_each_element_completed() to determine if any of
the loops above completed, i.e. it was able to parse all of
the elements successfully and no data remained.

Use for_each_element_id() in cfg80211_find_ie_match() as the
first user of this.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: erofs: detect potential multiref due to corrupted images

commit e12a0ce2fa69798194f3a8628baf6edfbd5c548f upstream.

As reported by erofs-utils fuzzer, currently, multiref
(ondisk deduplication) hasn't been supported for now,
we should forbid it properly.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc: <stable@vger.kernel.org> # 4.19+
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Link: https://lore.kernel.org/r/20190821140152.229648-1-gaoxiang25@huawei.com
[ Gao Xiang: Since earlier kernels don't define EFSCORRUPTED,
             let's use EIO instead. ]
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: erofs: add two missing erofs_workgroup_put for corrupted images

commit 138e1a0990e80db486ab9f6c06bd5c01f9a97999 upstream.

As reported by erofs-utils fuzzer, these error handling
path will be entered to handle corrupted images.

Lack of erofs_workgroup_puts will cause unmounting
unsuccessfully.

Fix these return values to EFSCORRUPTED as well.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc: <stable@vger.kernel.org> # 4.19+
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Link: https://lore.kernel.org/r/20190819103426.87579-4-gaoxiang25@huawei.com
[ Gao Xiang: Older kernel versions don't have length validity check
             and EFSCORRUPTED, thus backport pageofs check for now. ]
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: erofs: some compressed cluster should be submitted for corrupted images

commit ee45197c807895e156b2be0abcaebdfc116487c8 upstream.

As reported by erofs_utils fuzzer, a logical page can belong
to at most 2 compressed clusters, if one compressed cluster
is corrupted, but the other has been ready in submitting chain.

The chain needs to submit anyway in order to keep the page
working properly (page unlocked with PG_error set, PG_uptodate
not set).

Let's fix it now.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc: <stable@vger.kernel.org> # 4.19+
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Link: https://lore.kernel.org/r/20190819103426.87579-2-gaoxiang25@huawei.com
[ Gao Xiang: Manually backport to v4.19.y stable. ]
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: erofs: fix an error handling in erofs_readdir()

commit acb383f1dcb4f1e79b66d4be3a0b6f519a957b0d upstream.

Richard observed a forever loop of erofs_read_raw_page() [1]
which can be generated by forcely setting ->u.i_blkaddr
to 0xdeadbeef (as my understanding block layer can
handle access beyond end of device correctly).

After digging into that, it seems the problem is highly
related with directories and then I found the root cause
is an improper error handling in erofs_readdir().

Let's fix it now.

[1] https://lore.kernel.org/r/1163995781.68824.1566084358245.JavaMail.zimbra@nod.at/

Reported-by: Richard Weinberger <richard@nod.at>
Fixes: 3aa8ec716e52 ("staging: erofs: add directory operations")
Cc: <stable@vger.kernel.org> # 4.19+
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Link: https://lore.kernel.org/r/20190818125457.25906-1-hsiangkao@aol.com
[ Gao Xiang: Since earlier kernels don't define EFSCORRUPTED,
             let's use original error code instead. ]
Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coresight: etm4x: Use explicit barriers on enable/disable

commit 1004ce4c255fc3eb3ad9145ddd53547d1b7ce327 upstream.

Synchronization is recommended before disabling the trace registers
to prevent any start or stop points being speculative at the point
of disabling the unit (section 7.3.77 of ARM IHI 0064D).

Synchronization is also recommended after programming the trace
registers to ensure all updates are committed prior to normal code
resuming (section 4.3.7 of ARM IHI 0064D).

Let's ensure these syncronization points are present in the code
and clearly commented.

Note that we could rely on the barriers in CS_LOCK and
coresight_disclaim_device_unlocked or the context switch to user
space - however coresight may be of use in the kernel.

On armv8 the mb macro is defined as dsb(sy) - Given that the etm4x is
only used on armv8 let's directly use dsb(sy) instead of mb(). This
removes some ambiguity and makes it easier to correlate the code with
the TRM.

Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
[Fixed capital letter for "use" in title]
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20190829202842.580-11-mathieu.poirier@linaro.org
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfs: Fix EOVERFLOW testing in put_compat_statfs64

commit cc3a7bfe62b947b423fcb2cfe89fcba92bf48fa3 upstream.

Today, put_compat_statfs64() disallows nearly any field value over
2^32 if f_bsize is only 32 bits, but that makes no sense.
compat_statfs64 is there for the explicit purpose of providing 64-bit
fields for f_files, f_ffree, etc.  And f_bsize is always only 32 bits.

As a result, 32-bit userspace gets -EOVERFLOW for i.e.  large file
counts even with -D_FILE_OFFSET_BITS=64 set.

In reality, only f_bsize and f_frsize can legitimately overflow
(fields like f_type and f_namelen should never be large), so test
only those fields.

This bug was discussed at length some time ago, and this is the proposal
Al suggested at https://lkml.org/lkml/2018/8/6/640.  It seemed to get
dropped amid the discussion of other related changes, but this
part seems obviously correct on its own, so I've picked it up and
sent it, for expediency.

Fixes: 64d2ab32efe3 ("vfs: fix put_compat_statfs64() does not handle errors")
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64/speculation: Support 'mitigations=' cmdline option

commit a111b7c0f20e13b54df2fa959b3dc0bdf1925ae6 upstream.

Configure arm64 runtime CPU speculation bug mitigations in accordance
with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
v2, and Speculative Store Bypass.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
[will: reorder checks so KASLR implies KPTI and SSBS is affected by cmdline]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Use firmware to detect CPUs that are not affected by Spectre-v2

commit 517953c2c47f9c00a002f588ac856a5bc70cede3 upstream.

The SMCCC ARCH_WORKAROUND_1 service can indicate that although the
firmware knows about the Spectre-v2 mitigation, this particular
CPU is not vulnerable, and it is thus not necessary to call
the firmware on this CPU.

Let's use this information to our benefit.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Force SSBS on context switch

[ Upstream commit cbdf8a189a66001c36007bf0f5c975d0376c5c3a ]

On a CPU that doesn't support SSBS, PSTATE[12] is RES0.  In a system
where only some of the CPUs implement SSBS, we end-up losing track of
the SSBS bit across task migration.

To address this issue, let's force the SSBS bit on context switch.

Fixes: 8f04e8e6e29c ("arm64: ssbd: Add support for PSTATE.SSBS rather than trapping to EL3")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
[will: inverted logic and added comments]
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: ssbs: Don't treat CPUs with SSBS as unaffected by SSB

[ Upstream commit eb337cdfcd5dd3b10522c2f34140a73a4c285c30 ]

SSBS provides a relatively cheap mitigation for SSB, but it is still a
mitigation and its presence does not indicate that the CPU is unaffected
by the vulnerability.

Tweak the mitigation logic so that we report the correct string in sysfs.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: add sysfs vulnerability show for speculative store bypass

[ Upstream commit 526e065dbca6df0b5a130b84b836b8b3c9f54e21 ]

Return status based on ssbd_state and __ssb_safe. If the
mitigation is disabled, or the firmware isn't responding then
return the expected machine state based on a whitelist of known
good cores.

Given a heterogeneous machine, the overall machine vulnerability
defaults to safe but is reset to unsafe when we miss the whitelist
and the firmware doesn't explicitly tell us the core is safe.
In order to make that work we delay transitioning to vulnerable
until we know the firmware isn't responding to avoid a case
where we miss the whitelist, but the firmware goes ahead and
reports the core is not vulnerable. If all the cores in the
machine have SSBS, then __ssb_safe will remain true.

Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: add sysfs vulnerability show for spectre-v2

[ Upstream commit d2532e27b5638bb2e2dd52b80b7ea2ec65135377 ]

Track whether all the cores in the machine are vulnerable to Spectre-v2,
and whether all the vulnerable cores have been mitigated. We then expose
this information to userspace via sysfs.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Always enable spectre-v2 vulnerability detection

[ Upstream commit 8c1e3d2bb44cbb998cb28ff9a18f105fee7f1eb3 ]

Ensure we are always able to detect whether or not the CPU is affected
by Spectre-v2, so that we can later advertise this to userspace.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Advertise mitigation of Spectre-v2, or lack thereof

[ Upstream commit 73f38166095947f3b86b02fbed6bd592223a7ac8 ]

We currently have a list of CPUs affected by Spectre-v2, for which
we check that the firmware implements ARCH_WORKAROUND_1. It turns
out that not all firmwares do implement the required mitigation,
and that we fail to let the user know about it.

Instead, let's slightly revamp our checks, and rely on a whitelist
of cores that are known to be non-vulnerable, and let the user know
the status of the mitigation in the kernel log.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Provide a command line to disable spectre_v2 mitigation

[ Upstream commit e5ce5e7267ddcbe13ab9ead2542524e1b7993e5a ]

There are various reasons, such as benchmarking, to disable spectrev2
mitigation on a machine. Provide a command-line option to do so.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Always enable ssb vulnerability detection

[ Upstream commit d42281b6e49510f078ace15a8ea10f71e6262581 ]

Ensure we are always able to detect whether or not the CPU is affected
by SSB, so that we can later advertise this to userspace.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
[will: Use IS_ENABLED instead of #ifdef]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: enable generic CPU vulnerabilites support

[ Upstream commit 61ae1321f06c4489c724c803e9b8363dea576da3 ]

Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2,
meltdown and store-bypass.

Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: add sysfs vulnerability show for meltdown

[ Upstream commit 1b3ccf4be0e7be8c4bd8522066b6cbc92591e912 ]

We implement page table isolation as a mitigation for meltdown.
Report this to userspace via sysfs.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Add sysfs vulnerability show for spectre-v1

[ Upstream commit 3891ebccace188af075ce143d8b072b65e90f695 ]

spectre-v1 has been mitigated and the mitigation is always active.
Report this to userspace via sysfs

Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: fix SSBS sanitization

[ Upstream commit f54dada8274643e3ff4436df0ea124aeedc43cae ]

In valid_user_regs() we treat SSBS as a RES0 bit, and consequently it is
unexpectedly cleared when we restore a sigframe or fiddle with GPRs via
ptrace.

This patch fixes valid_user_regs() to account for this, updating the
function to refer to the latest ARM ARM (ARM DDI 0487D.a). For AArch32
tasks, SSBS appears in bit 23 of SPSR_EL1, matching its position in the
AArch32-native PSR format, and we don't need to translate it as we have
to for DIT.

There are no other bit assignments that we need to account for today.
As the recent documentation describes the DIT bit, we can drop our
comment regarding DIT.

While removing SSBS from the RES0 masks, existing inconsistent
whitespace is corrected.

Fixes: d71be2b6c0e19180 ("arm64: cpufeature: Detect SSBS and advertise to userspace")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: docs: Document SSBS HWCAP

[ Upstream commit ee91176120bd584aa10c564e7e9fdcaf397190a1 ]

We advertise the MRS/MSR instructions for toggling SSBS at EL0 using an
HWCAP, so document it along with the others.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: arm64: Set SCTLR_EL2.DSSBS if SSBD is forcefully disabled and !vhe

[ Upstream commit 7c36447ae5a090729e7b129f24705bb231a07e0b ]

When running without VHE, it is necessary to set SCTLR_EL2.DSSBS if SSBD
has been forcefully disabled on the kernel command-line.

Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: ssbd: Add support for PSTATE.SSBS rather than trapping to EL3

[ Upstream commit 8f04e8e6e29c93421a95b61cad62e3918425eac7 ]

On CPUs with support for PSTATE.SSBS, the kernel can toggle the SSBD
state without needing to call into firmware.

This patch hooks into the existing SSBD infrastructure so that SSBS is
used on CPUs that support it, but it's all made horribly complicated by
the very real possibility of big/little systems that don't uniformly
provide the new capability.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

riscv: Avoid interrupts being erroneously enabled in handle_exception()

[ Upstream commit c82dd6d078a2bb29d41eda032bb96d05699a524d ]

When the handle_exception function addresses an exception, the interrupts
will be unconditionally enabled after finishing the context save. However,
It may erroneously enable the interrupts if the interrupts are disabled
before entering the handle_exception.

For example, one of the WARN_ON() condition is satisfied in the scheduling
where the interrupt is disabled and rq.lock is locked. The WARN_ON will
trigger a break exception and the handle_exception function will enable the
interrupts before entering do_trap_break function. During the procedure, if
a timer interrupt is pending, it will be taken when interrupts are enabled.
In this case, it may cause a deadlock problem if the rq.lock is locked
again in the timer ISR.

Hence, the handle_exception() can only enable interrupts when the state of
sstatus.SPIE is 1.

This patch is tested on HiFive Unleashed board.

Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
[paul.walmsley@sifive.com: updated to apply]
Fixes: bcae803a21317 ("RISC-V: Enable IRQ during exception handling")
Cc: David Abdurachmanov <david.abdurachmanov@sifive.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

perf stat: Reset previous counts on repeat with interval

[ Upstream commit b63fd11cced17fcb8e133def29001b0f6aaa5e06 ]

When using 'perf stat' with repeat and interval option, it shows wrong
values for events.

The wrong values will be shown for the first interval on the second and
subsequent repetitions.

Without the fix:

  # perf stat -r 3 -I 2000 -e faults -e sched:sched_switch -a sleep 5

     2.000282489                 53      faults
     2.000282489                513      sched:sched_switch
     4.005478208              3,721      faults
     4.005478208              2,666      sched:sched_switch
     5.025470933                395      faults
     5.025470933              1,307      sched:sched_switch
     2.009602825 1,84,46,74,40,73,70,95,47,520      faults  <------
     2.009602825 1,84,46,74,40,73,70,95,49,568      sched:sched_switch  <------
     4.019612206              4,730      faults
     4.019612206              2,746      sched:sched_switch
     5.039615484              3,953      faults
     5.039615484              1,496      sched:sched_switch
     2.000274620 1,84,46,74,40,73,70,95,47,520      faults <------
     2.000274620 1,84,46,74,40,73,70,95,47,520      sched:sched_switch <------
     4.000480342              4,282      faults
     4.000480342              2,303      sched:sched_switch
     5.000916811              1,322      faults
     5.000916811              1,064      sched:sched_switch
  #

prev_raw_counts is allocated when using intervals. This is used when
calculating the difference in the counts of events when using interval.

The current counts are stored in prev_raw_counts to calculate the
differences in the next iteration.

On the first interval of the second and subsequent repetitions,
prev_raw_counts would be the values stored in the last interval of the
previous repetitions, while the current counts will only be for the
first interval of the current repetition.

Hence there is a possibility of events showing up as big number.

Fix this by resetting prev_raw_counts whenever perf stat repeats the
command.

With the fix:

  # perf stat -r 3 -I 2000 -e faults -e sched:sched_switch -a sleep 5

     2.019349347              2,597      faults
     2.019349347              2,753      sched:sched_switch
     4.019577372              3,098      faults
     4.019577372              2,532      sched:sched_switch
     5.019415481              1,879      faults
     5.019415481              1,356      sched:sched_switch
     2.000178813              8,468      faults
     2.000178813              2,254      sched:sched_switch
     4.000404621              7,440      faults
     4.000404621              1,266      sched:sched_switch
     5.040196079              2,458      faults
     5.040196079                556      sched:sched_switch
     2.000191939              6,870      faults
     2.000191939              1,170      sched:sched_switch
     4.000414103                541      faults
     4.000414103                902      sched:sched_switch
     5.000809863                450      faults
     5.000809863                364      sched:sched_switch
  #

Committer notes:

This was broken since the cset introducing the --interval feature, i.e.
--repeat + --interval wasn't tested at that point, add the Fixes tag so
that automatic scripts can pick this up.

Fixes: 13370a9b5bb8 ("perf stat: Add interval printing")
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: stable@vger.kernel.org # v3.9+
Link: http://lore.kernel.org/lkml/20190904094738.9558-2-srikar@linux.vnet.ibm.com
[ Fixed up conflicts with libperf, i.e. some perf_{evsel,evlist} lost the 'perf' prefix ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

perf tools: Fix segfault in cpu_cache_level__read()

[ Upstream commit 0216234c2eed1367a318daeb9f4a97d8217412a0 ]

We release wrong pointer on error path in cpu_cache_level__read
function, leading to segfault:

  (gdb) r record ls
  Starting program: /root/perf/tools/perf/perf record ls
  ...
  [ perf record: Woken up 1 times to write data ]
  double free or corruption (out)

  Thread 1 "perf" received signal SIGABRT, Aborted.
  0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
  (gdb) bt
  #0  0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
  #1  0x00007ffff7443bac in abort () from /lib64/power9/libc.so.6
  #2  0x00007ffff74af8bc in __libc_message () from /lib64/power9/libc.so.6
  #3  0x00007ffff74b92b8 in malloc_printerr () from /lib64/power9/libc.so.6
  #4  0x00007ffff74bb874 in _int_free () from /lib64/power9/libc.so.6
  #5  0x0000000010271260 in __zfree (ptr=0x7fffffffa0b0) at ../../lib/zalloc..
  #6  0x0000000010139340 in cpu_cache_level__read (cache=0x7fffffffa090, cac..
  #7  0x0000000010143c90 in build_caches (cntp=0x7fffffffa118, size=<optimiz..
  ...

Releasing the proper pointer.

Fixes: 720e98b5faf1 ("perf tools: Add perf data cache feature")
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: stable@vger.kernel.org: # v4.6+
Link: http://lore.kernel.org/lkml/20190912105235.10689-1-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

tick: broadcast-hrtimer: Fix a race in bc_set_next

[ Upstream commit b9023b91dd020ad7e093baa5122b6968c48cc9e0 ]

When a cpu requests broadcasting, before starting the tick broadcast
hrtimer, bc_set_next() checks if the timer callback (bc_handler) is active
using hrtimer_try_to_cancel(). But hrtimer_try_to_cancel() does not provide
the required synchronization when the callback is active on other core.

The callback could have already executed tick_handle_oneshot_broadcast()
and could have also returned. But still there is a small time window where
the hrtimer_try_to_cancel() returns -1. In that case bc_set_next() returns
without doing anything, but the next_event of the tick broadcast clock
device is already set to a timeout value.

In the race condition diagram below, CPU #1 is running the timer callback
and CPU #2 is entering idle state and so calls bc_set_next().

In the worst case, the next_event will contain an expiry time, but the
hrtimer will not be started which happens when the racing callback returns
HRTIMER_NORESTART. The hrtimer might never recover if all further requests
from the CPUs to subscribe to tick broadcast have timeout greater than the
next_event of tick broadcast clock device. This leads to cascading of
failures and finally noticed as rcu stall warnings

Here is a depiction of the race condition

CPU #1 (Running timer callback)                   CPU #2 (Enter idle
                                                  and subscribe to
                                                  tick broadcast)
---------------------                             ---------------------

__run_hrtimer()                                   tick_broadcast_enter()

  bc_handler()                                      __tick_broadcast_oneshot_control()

    tick_handle_oneshot_broadcast()

      raw_spin_lock(&tick_broadcast_lock);

      dev->next_event = KTIME_MAX;                  //wait for tick_broadcast_lock
      //next_event for tick broadcast clock
      set to KTIME_MAX since no other cores
      subscribed to tick broadcasting

      raw_spin_unlock(&tick_broadcast_lock);

    if (dev->next_event == KTIME_MAX)
      return HRTIMER_NORESTART
    // callback function exits without
       restarting the hrtimer                      //tick_broadcast_lock acquired
                                                   raw_spin_lock(&tick_broadcast_lock);

                                                   tick_broadcast_set_event()

                                                     clockevents_program_event()

                                                       dev->next_event = expires;

                                                       bc_set_next()

                                                         hrtimer_try_to_cancel()
                                                         //returns -1 since the timer
                                                         callback is active. Exits without
                                                         restarting the timer
  cpu_base->running = NULL;

The comment that hrtimer cannot be armed from within the callback is
wrong. It is fine to start the hrtimer from within the callback. Also it is
safe to start the hrtimer from the enter/exit idle code while the broadcast
handler is active. The enter/exit idle code and the broadcast handler are
synchronized using tick_broadcast_lock. So there is no need for the
existing try to cancel logic. All this can be removed which will eliminate
the race condition as well.

Fixes: 5d1638acb9f6 ("tick: Introduce hrtimer based broadcast")
Originally-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Balasubramani Vivekanandan <balasubramani_vivekanandan@mentor.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20190926135101.12102-2-balasubramani_vivekanandan@mentor.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

tools lib traceevent: Do not free tep->cmdlines in add_new_comm() on failure

[ Upstream commit e0d2615856b2046c2e8d5bfd6933f37f69703b0b ]

If the re-allocation of tep->cmdlines succeeds, then the previous
allocation of tep->cmdlines will be freed. If we later fail in
add_new_comm(), we must not free cmdlines, and also should assign
tep->cmdlines to the new allocation. Otherwise when freeing tep, the
tep->cmdlines will be pointing to garbage.

Fixes: a6d2a61ac653a ("tools lib traceevent: Remove some die() calls")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: linux-trace-devel@vger.kernel.org
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20190828191819.970121417@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/book3s64/radix: Rename CPU_FTR_P9_TLBIE_BUG feature flag

commit 09ce98cacd51fcd0fa0af2f79d1e1d3192f4cbb0 upstream.

Rename the #define to indicate this is related to store vs tlbie
ordering issue. In the next patch, we will be adding another feature
flag that is used to handles ERAT flush vs tlbie ordering issue.

Fixes: a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190924035254.24612-2-aneesh.kumar@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

powerpc/pseries: Fix cpu_hotplug_lock acquisition in resize_hpt()

[ Upstream commit c784be435d5dae28d3b03db31753dd7a18733f0c ]

The calls to arch_add_memory()/arch_remove_memory() are always made
with the read-side cpu_hotplug_lock acquired via memory_hotplug_begin().
On pSeries, arch_add_memory()/arch_remove_memory() eventually call
resize_hpt() which in turn calls stop_machine() which acquires the
read-side cpu_hotplug_lock again, thereby resulting in the recursive
acquisition of this lock.

In the absence of CONFIG_PROVE_LOCKING, we hadn't observed a system
lockup during a memory hotplug operation because cpus_read_lock() is a
per-cpu rwsem read, which, in the fast-path (in the absence of the
writer, which in our case is a CPU-hotplug operation) simply
increments the read_count on the semaphore. Thus a recursive read in
the fast-path doesn't cause any problems.

However, we can hit this problem in practice if there is a concurrent
CPU-Hotplug operation in progress which is waiting to acquire the
write-side of the lock. This will cause the second recursive read to
block until the writer finishes. While the writer is blocked since the
first read holds the lock. Thus both the reader as well as the writers
fail to make any progress thereby blocking both CPU-Hotplug as well as
Memory Hotplug operations.

Memory-Hotplug CPU-Hotplug
CPU 0 CPU 1
------                                  ------

1. down_read(cpu_hotplug_lock.rw_sem)
   [memory_hotplug_begin]
2. down_write(cpu_hotplug_lock.rw_sem)
[cpu_up/cpu_down]
3. down_read(cpu_hotplug_lock.rw_sem)
   [stop_machine()]

Lockdep complains as follows in these code-paths.

 swapper/0/1 is trying to acquire lock:
 (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: stop_machine+0x2c/0x60

but task is already holding lock:
(____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: mem_hotplug_begin+0x20/0x50

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(cpu_hotplug_lock.rw_sem);
   lock(cpu_hotplug_lock.rw_sem);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 3 locks held by swapper/0/1:
  #0: (____ptrval____) (&dev->mutex){....}, at: __driver_attach+0x12c/0x1b0
  #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: mem_hotplug_begin+0x20/0x50
  #2: (____ptrval____) (mem_hotplug_lock.rw_sem){++++}, at: percpu_down_write+0x54/0x1a0

stack backtrace:
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc5-58373-gbc99402235f3-dirty #166
 Call Trace:
   dump_stack+0xe8/0x164 (unreliable)
   __lock_acquire+0x1110/0x1c70
   lock_acquire+0x240/0x290
   cpus_read_lock+0x64/0xf0
   stop_machine+0x2c/0x60
   pseries_lpar_resize_hpt+0x19c/0x2c0
   resize_hpt_for_hotplug+0x70/0xd0
   arch_add_memory+0x58/0xfc
   devm_memremap_pages+0x5e8/0x8f0
   pmem_attach_disk+0x764/0x830
   nvdimm_bus_probe+0x118/0x240
   really_probe+0x230/0x4b0
   driver_probe_device+0x16c/0x1e0
   __driver_attach+0x148/0x1b0
   bus_for_each_dev+0x90/0x130
   driver_attach+0x34/0x50
   bus_add_driver+0x1a8/0x360
   driver_register+0x108/0x170
   __nd_driver_register+0xd0/0xf0
   nd_pmem_driver_init+0x34/0x48
   do_one_initcall+0x1e0/0x45c
   kernel_init_freeable+0x540/0x64c
   kernel_init+0x2c/0x160
   ret_from_kernel_thread+0x5c/0x68

Fix this issue by
  1) Requiring all the calls to pseries_lpar_resize_hpt() be made
     with cpu_hotplug_lock held.

  2) In pseries_lpar_resize_hpt() invoke stop_machine_cpuslocked()
     as a consequence of 1)

  3) To satisfy 1), in hpt_order_set(), call mmu_hash_ops.resize_hpt()
     with cpu_hotplug_lock held.

Fixes: dbcf929c0062 ("powerpc/pseries: Add support for hash table resizing")
Cc: stable@vger.kernel.org # v4.11+
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/1557906352-29048-1-git-send-email-ego@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

nbd: fix crash when the blksize is zero

[ Upstream commit 553768d1169a48c0cd87c4eb4ab57534ee663415 ]

This will allow the blksize to be set zero and then use 1024 as
default.

Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Xiubo Li <xiubli@redhat.com>
[fix to use goto out instead of return in genl_connect]
Signed-off-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: nVMX: Fix consistency check on injected exception error code

[ Upstream commit 567926cca99ba1750be8aae9c4178796bf9bb90b ]

Current versions of Intel's SDM incorrectly state that "bits 31:15 of
the VM-Entry exception error-code field" must be zero.  In reality, bits
31:16 must be zero, i.e. error codes are 16-bit values.

The bogus error code check manifests as an unexpected VM-Entry failure
due to an invalid code field (error number 7) in L1, e.g. when injecting
a #GP with error_code=0x9f00.

Nadav previously reported the bug[*], both to KVM and Intel, and fixed
the associated kvm-unit-test.

[*] https://patchwork.kernel.org/patch/11124749/

Reported-by: Nadav Amit <namit@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: PPC: Book3S HV: XIVE: Free escalation interrupts before disabling the VP

[ Upstream commit 237aed48c642328ff0ab19b63423634340224a06 ]

When a vCPU is brought done, the XIVE VP (Virtual Processor) is first
disabled and then the event notification queues are freed. When freeing
the queues, we check for possible escalation interrupts and free them
also.

But when a XIVE VP is disabled, the underlying XIVE ENDs also are
disabled in OPAL. When an END (Event Notification Descriptor) is
disabled, its ESB pages (ESn and ESe) are disabled and loads return all
1s. Which means that any access on the ESB page of the escalation
interrupt will return invalid values.

When an interrupt is freed, the shutdown handler computes a 'saved_p'
field from the value returned by a load in xive_do_source_set_mask().
This value is incorrect for escalation interrupts for the reason
described above.

This has no impact on Linux/KVM today because we don't make use of it
but we will introduce in future changes a xive_get_irqchip_state()
handler. This handler will use the 'saved_p' field to return the state
of an interrupt and 'saved_p' being incorrect, softlockup will occur.

Fix the vCPU cleanup sequence by first freeing the escalation interrupts
if any, then disable the XIVE VP and last free the queues.

Fixes: 90c73795afa2 ("KVM: PPC: Book3S HV: Add a new KVM device for the XIVE native exploitation mode")
Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190806172538.5087-1-clg@kaod.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/radeon: Bail earlier when radeon.cik_/si_support=0 is passed

[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]

Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being an userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

nfp: flower: fix memory leak in nfp_flower_spawn_vnic_reprs

[ Upstream commit 8ce39eb5a67aee25d9f05b40b673c95b23502e3e ]

In nfp_flower_spawn_vnic_reprs in the loop if initialization or the
allocations fail memory is leaked. Appropriate releases are added.

Fixes: b94524529741 ("nfp: flower: add per repr private data for LAG offload")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>

perf unwind: Fix libunwind build failure on i386 systems

[ Upstream commit 26acf400d2dcc72c7e713e1f55db47ad92010cc2 ]

Naresh Kamboju reported, that on the i386 build pr_err()
doesn't get defined properly due to header ordering:

  perf-in.o: In function `libunwind__x86_reg_id':
  tools/perf/util/libunwind/../../arch/x86/util/unwind-libunwind.c:109:
  undefined reference to `pr_err'

Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

kernel/elfcore.c: include proper prototypes

[ Upstream commit 0f74914071ab7e7b78731ed62bf350e3a344e0a5 ]

When building with W=1, gcc properly complains that there's no prototypes:

  CC      kernel/elfcore.o
kernel/elfcore.c:7:17: warning: no previous prototype for 'elf_core_extra_phdrs' [-Wmissing-prototypes]
    7 | Elf_Half __weak elf_core_extra_phdrs(void)
      |                 ^~~~~~~~~~~~~~~~~~~~
kernel/elfcore.c:12:12: warning: no previous prototype for 'elf_core_write_extra_phdrs' [-Wmissing-prototypes]
   12 | int __weak elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~
kernel/elfcore.c:17:12: warning: no previous prototype for 'elf_core_write_extra_data' [-Wmissing-prototypes]
   17 | int __weak elf_core_write_extra_data(struct coredump_params *cprm)
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~
kernel/elfcore.c:22:15: warning: no previous prototype for 'elf_core_extra_data_size' [-Wmissing-prototypes]
   22 | size_t __weak elf_core_extra_data_size(void)
      |               ^~~~~~~~~~~~~~~~~~~~~~~~

Provide the include file so gcc is happy, and we don't have potential code drift

Link: http://lkml.kernel.org/r/29875.1565224705@turing-police
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

perf build: Add detection of java-11-openjdk-devel package

[ Upstream commit 815c1560bf8fd522b8d93a1d727868b910c1cc24 ]

With Java 11 there is no seperate JRE anymore.

Details:

  https://coderanch.com/t/701603/java/JRE-JDK

Therefore the detection of the JRE needs to be adapted.

This change works for s390 and x86.  I have not tested other platforms.

Committer testing:

Continues to work with the OpenJDK 8:

  $ rm -f ~acme/lib64/libperf-jvmti.so
  $ rpm -qa | grep jdk-devel
  java-1.8.0-openjdk-devel-1.8.0.222.b10-0.fc30.x86_64
  $ git log --oneline -1
  a51937170f33 (HEAD -> perf/core) perf build: Add detection of java-11-openjdk-devel package
  $ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; make -C tools/perf O=/tmp/build/perf install > /dev/null 2>1
  $ ls -la ~acme/lib64/libperf-jvmti.so
  -rwxr-xr-x. 1 acme acme 230744 Sep 24 16:46 /home/acme/lib64/libperf-jvmti.so
  $

Suggested-by: Andreas Krebbel <krebbel@linux.ibm.com>
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Link: http://lore.kernel.org/lkml/20190909114116.50469-4-tmricht@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/core: Fix migration to invalid CPU in __set_cpus_allowed_ptr()

[ Upstream commit 714e501e16cd473538b609b3e351b2cc9f7f09ed ]

An oops can be triggered in the scheduler when running qemu on arm64:

 Unable to handle kernel paging request at virtual address ffff000008effe40
 Internal error: Oops: 96000007 [#1] SMP
 Process migration/0 (pid: 12, stack limit = 0x00000000084e3736)
 pstate: 20000085 (nzCv daIf -PAN -UAO)
 pc : __ll_sc___cmpxchg_case_acq_4+0x4/0x20
 lr : move_queued_task.isra.21+0x124/0x298
 ...
 Call trace:
  __ll_sc___cmpxchg_case_acq_4+0x4/0x20
  __migrate_task+0xc8/0xe0
  migration_cpu_stop+0x170/0x180
  cpu_stopper_thread+0xec/0x178
  smpboot_thread_fn+0x1ac/0x1e8
  kthread+0x134/0x138
  ret_from_fork+0x10/0x18

__set_cpus_allowed_ptr() will choose an active dest_cpu in affinity mask to
migrage the process if process is not currently running on any one of the
CPUs specified in affinity mask. __set_cpus_allowed_ptr() will choose an
invalid dest_cpu (dest_cpu >= nr_cpu_ids, 1024 in my virtual machine) if
CPUS in an affinity mask are deactived by cpu_down after cpumask_intersects
check. cpumask_test_cpu() of dest_cpu afterwards is overflown and may pass if
corresponding bit is coincidentally set. As a consequence, kernel will
access an invalid rq address associate with the invalid CPU in
migration_cpu_stop->__migrate_task->move_queued_task and the Oops occurs.

The reproduce the crash:

  1) A process repeatedly binds itself to cpu0 and cpu1 in turn by calling
  sched_setaffinity.

  2) A shell script repeatedly does "echo 0 > /sys/devices/system/cpu/cpu1/online"
  and "echo 1 > /sys/devices/system/cpu/cpu1/online" in turn.

  3) Oops appears if the invalid CPU is set in memory after tested cpumask.

Signed-off-by: KeMeng Shi <shikemeng@huawei.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/1568616808-16808-1-git-send-email-shikemeng@huawei.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/membarrier: Fix private expedited registration check

[ Upstream commit fc0d77387cb5ae883fd774fc559e056a8dde024c ]

Fix a logic flaw in the way membarrier_register_private_expedited()
handles ready state checks for private expedited sync core and private
expedited registrations.

If a private expedited membarrier registration is first performed, and
then a private expedited sync_core registration is performed, the ready
state check will skip the second registration when it really should not.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Kirill Tkhai <tkhai@yandex.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190919173705.2181-2-mathieu.desnoyers@efficios.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

sched/membarrier: Call sync_core only before usermode for same mm

[ Upstream commit 2840cf02fae627860156737e83326df354ee4ec6 ]

When the prev and next task's mm change, switch_mm() provides the core
serializing guarantees before returning to usermode. The only case
where an explicit core serialization is needed is when the scheduler
keeps the same mm for prev and next.

Suggested-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Kirill Tkhai <tkhai@yandex.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul E. McKenney <paulmck@linux.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190919173705.2181-4-mathieu.desnoyers@efficios.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>