kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
1,233,462 commits 117 branches 5,827 tags 6.3 GiB
Commit graph

1,233,462 commits

This branch
This branch
All branches
Author SHA1 Message Date
Arnd Bergmann
94d310e178 ASPEED device tree updates for 6.7 
- New machine:
 
   * Facebook's Minevra, as Chassis Management Controller using the
     AST2600
 
  - Updates to Ampere's Mt Mitchell and Mt Jade systems, and IBM's
    Bonnell
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQRz6FSYRMHvZ436fLaBQBa54y6+yAUCZSyNCQAKCRCBQBa54y6+
 yKsyAP0f/RYaNG3c2afpEjqci7/ek8u8Ts9sVazEprgwZsrhrQEA2TpCyLS3PJ3H
 CTuBEj1FZkepPzOzpNzVsKY0MkIBPQs=
 =KbHd
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUtQ6UACgkQYKtH/8kJ
 UicL1hAAnzoh/+JNqwWfgHcDT0Q/QKDUrrXgowmZW6XLHMJGer88mJO018Z2SyTO
 3xavqK40xwD3ynZ6vrXewF3ti2SClyD08bg5ojru912QWxYyBetEYNulcnu0myRv
 KBaZgwKhAFaEomIEZsnXjLuJNNvqtiYkXQBwMxBvgK7PbRwYStVOsPY9jxWUPbCR
 LV3OCA6KIhZQKzd5bMv1SvIozUK69V/HTL9Yt+ug1D/CGp/Qtg7/FyL3XlNKMM32
 DFxaAlHyn4h1KWnSSGQaF7MfTm75XYZ1IykOBgM9J8ffcKv8cuIKW5FOtZb3mdeh
 kAKLArpFlnGdtskAjhG9hIrkkZ+auiX+rvVP8HDIjFAhIoL0f4YRfc8YJzTxi6O7
 Z6qxPn4iQaAus+qS3/qfGZeZZa4shR714qzxgVNZO9XKKUEV1YXFypWhQpz2NRln
 yv5yFvWx+ASv8gm6w3g7QiYh56u3B/BLRLsYGjcnei1FsTMTDemRLa7os59/Lwjw
 GyDQbOeScPToW1kOqeK3sJCNKWqZjv50ZlMrv9i2gcXnPdf1MEzwJ+8tI9TBM/mN
 uNyEOMFT+ThwW1kNK+jXGlF3Y7S3l66u7ycDYIvDz/zKLu5KnWdrK228ahiu8eWO
 KA+fC4RYtxDHENJmnQObv18fHYlR3NXra0r8vJ7w5Zkp8ODpzxQ=
 =+yks
 -----END PGP SIGNATURE-----

Merge tag 'aspeed-6.7-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into soc/dt

ASPEED device tree updates for 6.7

 - New machine:

  * Facebook's Minevra, as Chassis Management Controller using the
    AST2600

 - Updates to Ampere's Mt Mitchell and Mt Jade systems, and IBM's
   Bonnell

* tag 'aspeed-6.7-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc:
  ARM: dts: aspeed: mtmitchell: Add I2C NVMe alias port
  ARM: dts: aspeed: mtmitchell: Remove redundant ADC configurations
  ARM: dts: aspeed: mtmitchell: Add inlet temperature sensor
  ARM: dts: aspeed: mtjade: Add the gpio-hog
  ARM: dts: aspeed: mtjade, mtmitchell: Add new gpio-line-names
  ARM: dts: aspeed: mtjade, mtmitchell: Update gpio-line-names
  ARM: dts: aspeed: Minerva: Add Facebook Minerva CMC board
  dt-bindings: arm: aspeed: document board compatibles
  ARM: dts: aspeed: bonnell: Add reserved memory for TPM event log

Link: https://lore.kernel.org/r/CACPK8XebMAQvgQTRH+KoaTFg7CzRkS79Fz3Kn8p4mbaezWGkUQ@mail.gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
 2023-10-16 16:07:33 +02:00
Nicolin Chen
266dcae34d iommufd/selftest: Rework TEST_LENGTH to test min_size explicitly 
TEST_LENGTH passing ".size = sizeof(struct _struct) - 1" expects -EINVAL
from "if (ucmd.user_size < op->min_size)" check in iommufd_fops_ioctl().
This has been working when min_size is exactly the size of the structure.

However, if the size of the structure becomes larger than min_size, i.e.
the passing size above is larger than min_size, that min_size sanity no
longer works.

Since the first test in TEST_LENGTH() was to test that min_size sanity
routine, rework it to support a min_size calculation, rather than using
the full size of the structure.

Link: https://lore.kernel.org/r/20231015074648.24185-1-nicolinc@nvidia.com
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
 2023-10-16 11:05:51 -03:00
Imre Deak
02c8d561db drm/i915/dp: Remove unused DSC caps from intel_dp 
The previous patches converted all users of the DSC DPCD caps to look
these up from the connector, so remove the version stored in intel_dp.

A follow-up patchset will read out the MST connector specific
capabilities in intel_dp_add_mst_connector() ->
intel_dp_mst_read_decompression_port_dsc_caps().

v2:
- Rebased on intel_edp_get_dsc_sink_cap() addition in the patchset.
v3:
- Rebased on read-out fix for eDP in the patchset.

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231011171606.2540078-3-imre.deak@intel.com
 2023-10-16 17:01:58 +03:00
Imre Deak
d19daffc89 drm/i915/dp_mst: Use connector DSC DPCD in intel_dp_mst_mode_valid_ctx() 
Use the connector's DSC DPCD capabilities in
intel_dp_mst_mode_valid_ctx().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-19-imre.deak@intel.com
 2023-10-16 17:01:53 +03:00
Imre Deak
2bd3d20ffa drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_config() 
Use the connector's DSC DPCD capabilities in
intel_dp_dsc_compute_config().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-18-imre.deak@intel.com
 2023-10-16 17:01:48 +03:00
Imre Deak
031c19b52c drm/i915/dp: Use connector DSC DPCD in intel_dp_mode_valid() 
Use the connector's DSC DPCD capabilities in intel_dp_mode_valid().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-17-imre.deak@intel.com
 2023-10-16 17:01:41 +03:00
Imre Deak
7bca1b801e drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_get_slice_count() 
Use the connector's DSC DPCD capabilities in
intel_dp_dsc_get_slice_count().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-16-imre.deak@intel.com
 2023-10-16 17:01:38 +03:00
Imre Deak
926b726c3d drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_supports_format() 
Use the connector's DSC DPCD capabilities in
intel_dp_dsc_supports_format().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-15-imre.deak@intel.com
 2023-10-16 17:01:33 +03:00
Imre Deak
2c4907c2e6 drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_params() 
Use the connector's DSC DPCD capabilities in
intel_dp_dsc_compute_params().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-14-imre.deak@intel.com
 2023-10-16 17:01:29 +03:00
Imre Deak
11a33d6b26 drm/i915/dp: Pass only the required DSC DPCD to intel_dp_sink_dsc_version_minor() 
intel_dp_sink_dsc_version_minor() only requires the DSC DPCD, so pass
only this to the function.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-13-imre.deak@intel.com
 2023-10-16 17:01:25 +03:00
Imre Deak
6a60a8fa7c drm/i915/dp: Pass only the required i915 to intel_dp_source_dsc_version_minor() 
intel_dp_source_dsc_version_minor() only requires the i915 pointer, so pass
only this to the function.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-12-imre.deak@intel.com
 2023-10-16 17:01:22 +03:00
Imre Deak
cc81951d9a drm/i915/dp: Pass connector DSC DPCD to drm_dp_dsc_sink_supported_input_bpcs() 
Use the connector's DSC DPCD capabilities in
drm_dp_dsc_sink_supported_input_bpcs().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-11-imre.deak@intel.com
 2023-10-16 17:01:17 +03:00
Imre Deak
bb414c941b drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_max_sink_compressed_bppx16() 
Use the connector's DSC DPCD capabilities in
intel_dp_dsc_max_sink_compressed_bppx16().

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-10-imre.deak@intel.com
 2023-10-16 17:01:12 +03:00
Imre Deak
0d8665e068 drm/i915/dp: Use connector DSC DPCD in intel_dp_supports_dsc() 
Use the connector's DSC DPCD capabilities in intel_dp_supports_dsc().

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-9-imre.deak@intel.com
 2023-10-16 17:01:07 +03:00
Imre Deak
987c945ab2 drm/i915/dp: Use connector DSC DPCD in intel_dp_supports_fec() 
Use the connector's DSC DPCD capabilities in intel_dp_supports_fec().

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-8-imre.deak@intel.com
 2023-10-16 17:01:02 +03:00
Imre Deak
f52bbfe2ac drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_max_bpp() 
Use the connector's DSC DPCD capabilities in intel_dp_dsc_compute_max_bpp()
instead of the version stored in the encoder.

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-7-imre.deak@intel.com
 2023-10-16 17:00:58 +03:00
Imre Deak
102c8013b6 drm/i915/dp: Use connector DSC DPCD in i915_dsc_fec_support_show() 
Use the connector's DSC DPCD capabilities in i915_dsc_fec_support_show()
instead of the version stored in the encoder. Atm the two are identical,
but a follow-up patch will store the (MST) connector specific version
in the connector.

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-6-imre.deak@intel.com
 2023-10-16 17:00:53 +03:00
Imre Deak
829d8a1943 drm/i915/dp: Use i915/intel connector local variables in i915_dsc_fec_support_show() 
Cache the i915 specific device and connector pointers in
i915_dsc_fec_support_show().

v2:
- s/Cahce/Cache typo in commit log. (Stan)

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231006133727.1822579-5-imre.deak@intel.com
 2023-10-16 17:00:45 +03:00
Imre Deak
808b43fa7e drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX 
Similarly to eDP and SST-DP connectors read out the DSC capabilities for
MST connectors as well. Atm these will match the root port's DSC caps
and only used after a follow-up change enables the decompression for
each stream separately (vs. the current way of enabling it only globally
in the first branch device downstream of the root port).

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231010112504.2156789-3-imre.deak@intel.com
 2023-10-16 17:00:36 +03:00
Imre Deak
7389829f21 drm/i915/dp: Store DSC DPCD capabilities in the connector 
In an MST topology the DSC capabilities are specific to each connector,
retrieved either from the sink if it decompresses the stream, or from a
branch device between the source and the sink in case this branch device
does the decompression. Accordingly each connector needs to cache its
own DSC DPCD and FEC capabilities, along with the AUX device through
which the decompression can be enabled. This patch prepares for that by
storing the capabilities and the DSC AUX device in the connector, for
now these just matching the version stored in intel_dp. The follow-up
patches will convert all users to look up these in the connector instead
of intel_dp, after which the intel_dp copies are removed.

v2:
- Rebased on intel_edp_get_dsc_sink_cap() addition in previous patch.
v3:
- Rebased on read-out fix for eDP in previous patch.

Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231011171606.2540078-2-imre.deak@intel.com
 2023-10-16 17:00:31 +03:00
Imre Deak
90780a633c drm/i915/dp: Sanitize DPCD revision check in intel_dp_get_dsc_sink_cap() 
Check only the eDP or the DP specific DPCD revision depending on the
sink type. Pass the corresponding revision to the function, which allows
getting the DSC caps of a branch device (in an MST topology, which has
its own DPCD and so DPCD revision).

While at it use DP_DPCD_REV_14 instead of open coding it and for clarity
add a separate function to read out the DSC capability on eDP.

v2:
- Use DP_DPCD_REV_14 instead of open coding it. (Stan)
- Check EDP_DCPD_REV/DPCD_REV in a clearer way. (Ville)
v3:
- Fix the read-out for eDP in intel_dp_detect().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231011171606.2540078-1-imre.deak@intel.com
 2023-10-16 17:00:22 +03:00
Arnd Bergmann
6fd3e8682b Qualcomm ARM DeviceTree updates for v6.7 
RPM master stats is introduced for MSM8226 and MSM8974. The PCIe PHY of
 SDX55 is transitioned to the new binding. The hall sensor on the Samsung
 Galaxy Tab 4 is inverted.
 
 A number of fixes reported from DeviceTree validation are fixed.
 -----BEGIN PGP SIGNATURE-----
 
 iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmUsT2cVHGFuZGVyc3Nv
 bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FcqoQAIT+4aJlfy8qeEPG8u3TJOsQHV9F
 KXu9afQs40IwQIMdIkT6B7rvq8HWxsXmASWFY7aJjPuBtDdj9IycJpgAds3B3nEp
 HtZW6h99ZBIn0mF2wI7Z4Ul7oKsn5ppEPg3OUQvw67X2xQEgFRajFOJLKk6oFAaP
 rZsH5F5Ww1zT426FKDj1+IeR6Br+1PTZtOBhnGCD0nEZZsKka18W9XAo1sIX0ELI
 eZUF6zEUCTEztekyPOZvCEME6OUyE+awGxT8HAyZUjvzwQ4UX3vD4To8V3F/yIBZ
 fCzDHNbSYn0X75+DkWjVI0wHGjXEOx2L/ZijMm7477LrpLDywNXsSdK39IWvdbRz
 nsMykKnBmfppppgVa25RRgtbvppWYd5IYkNMun8UjMxvdU3k28s6yFK5BzNMyDvP
 cJEBBFApL1Og2yJrWMmhyByAPg+zwPNovGno13gXI/8oZQnzhT4zzv0e19MHYRqa
 kZzU0hw6RC0FCmWTXAQyCitsPAxzVL8pYeBiyG+BF9LbOB1mQSQWy262yBwoF7Kn
 3VPYqybPzwREONObrO6BlpLKXBNXp/gwhYWPk09UaoLyuOGXXRQwsQGDcJCvQbtI
 bGyN6KTIxk+XpqKnI7dZhhde9hpHVIQK+S4Cfgqdo1aJNTawk9ZMsDS3TItVHFHI
 FGxlB/xEAc0tByjj
 =Wkrx
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUtP3EACgkQYKtH/8kJ
 Uiewfw//QcQleXnc4ULV9OccCsNJGHBiWM7pvpzCHzMLHMhpiqtg+nEB/Eq1HwoD
 o58yGjm7lbFwK5wNRqMBcCGnYMr5/yLIchVkquNr1sV6MI3iahN7wT+TxN0+N/TM
 Pqtovq+NlpxELJN5Q9BGrXjrWn4aERBK75yqUmCRwmZ+ZeHT0/A2PxwJm3ai/Wcp
 YxFu8A2FCnSIT6FeQam+IdIqTeHLyGmmcUI3MDgeZkL+HycmGUsrmkm+RaqzHK6G
 9wjbPdbg+HxQcSLhy5cuzdPwfZqaJCI9DjWhaYzvlK6XgW+YTY7lfdZBIhhfWnzf
 bfGSCleonEKTTNI50SozT02u9T0AMCl0TvLIkB4DJgCn9Pd2+IQzp8GGX1n+iUSf
 D3NEL/kR+CvGhuVk7jRN3Oy+Hf+9/dlZq+0m5QMWEAaX1T0A8uyIaEIH+oPxG1BS
 to/+4XF+avFt+klieIbGnJ9wHlPFPte6fxTT9syuiT52duHec6BPkYMDIm7n1OrF
 /9P4/uhXyeq/EgHUhk4TL4Q1v+qUbBGbJEUGwv7wQWTO2lTANuKbQeXIO8511smr
 N5ImOFZcOvBj9gDZ1Cq8KCSI55aMJT3TYilk1bmEI1JVykD/oa+PVX5pmpGff0Bp
 ieYIcuQ8ndG0T2Sfkuel0pWYXwr+kYxhI9KEWafp8cSKqt3epoU=
 =UL5s
 -----END PGP SIGNATURE-----

Merge tag 'qcom-dts-for-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt

Qualcomm ARM DeviceTree updates for v6.7

RPM master stats is introduced for MSM8226 and MSM8974. The PCIe PHY of
SDX55 is transitioned to the new binding. The hall sensor on the Samsung
Galaxy Tab 4 is inverted.

A number of fixes reported from DeviceTree validation are fixed.

* tag 'qcom-dts-for-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  ARM: dts: qcom: ipq8064: move keys and leds out of soc node
  ARM: dts: qcom: mdm9615: populate vsdcc fixed regulator
  ARM: dts: qcom: apq8060: drop incorrect regulator-type
  ARM: dts: qcom: apq8064: drop incorrect regulator-type
  ARM: dts: qcom: sdx65: fix SDHCI clocks order
  ARM: dts: qcom: apq8064: drop label property from DSI
  ARM: qcom: msm8974: Add rpm-master-stats node
  ARM: qcom: msm8226: Add rpm-master-stats node
  ARM: dts: qcom: apq8026-samsung-matisse-wifi: Fix inverted hall sensor
  ARM: dts: qcom: drop incorrect cell-index from SPMI
  ARM: dts: qcom-sdx55: switch PCIe QMP PHY to new style of bindings

Link: https://lore.kernel.org/r/20231015204558.855987-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
 2023-10-16 15:49:37 +02:00
Yazen Ghannam
1bae0cfe4a x86/mce: Cleanup mce_usable_address() 
Move Intel-specific checks into a helper function.

Explicitly use "bool" for return type.

No functional change intended.

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230613141142.36801-4-yazen.ghannam@amd.com
 2023-10-16 15:37:01 +02:00
Yazen Ghannam
48da1ad8ba x86/mce: Define amd_mce_usable_address() 
Currently, all valid MCA_ADDR values are assumed to be usable on AMD
systems. However, this is not correct in most cases. Notifiers expecting
usable addresses may then operate on inappropriate values.

Define a helper function to do AMD-specific checks for a usable memory
address. List out all known cases.

  [ bp: Tone down the capitalized words. ]

Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230613141142.36801-3-yazen.ghannam@amd.com
 2023-10-16 15:31:32 +02:00
Arnd Bergmann
68f1d4198c Qualcomm ARM64 DeviceTree updates for v6.7 
The SM7125 platform is introduced, with support for Xiaomi Redmi Note 9
 Pro. Support for Fairphone 5, on QCM6490, and BQ Aquaris M5, on MSM8939,
 are introduced.
 
 With the various QMP PHY bindings having been refactored, SC7180,
 SC7280, SDM845, SM8150, and SM8250 are transitioned to the new USB/DP
 combo PHY binding. IPQ6018, IPQ8074 MSM8998, SC7280, SC8180X, SDM845,
 SM8150, SM8250, and SM8450 are transitioned to the new PCIe PHY binding,
 and SC8180X is transitioned to the new UFS phy binding.
 
 The UFS power supply situation is clarified, and a range of boards
 across MSM8996, MSM8998, SM4250, SM6115, SM6125, SM8350, SM8450, and
 SM8550 receives corrections for this.
 
 On IPQ5018 watchdog support is introduced, and the SCM driver has SDI
 (debug image) enabled - so that it can be disabled. On IPQ5332 USB is
 enabled. The hwspinlock identifier is corrected across IPQ5332, IPQ6018,
 IPQ8074 and IPQ9574.
 
 The reserved-memory ranges for the remoteprocs on MSM8916 boards are
 refactored, to reduce the amount of duplicated boilerplate definitions.
 A number of nodes are transitioned to be disabled by default, to
 facilitate new boards.
 Samsung Galaxy Tab A 8.0 and Samsung Galaxy Tab A 9.7 gains display
 support, and the latter capacitive keys. Samsung Galaxy J5 gains
 accelerometer support. The Dragonboard 410c gains missing ADC7533
 regulator definition, and an overlay forcing the board to operate in
 host mode, for automation purposes.
 
 On MSM8976, the outgoing IPC bits for modem and wcss are corrected, and
 reserved-memory regions are updated.
 
 Incorrect reserved-memory regions are also corrected for MSM8992 and
 MSM8994 devices.
 
 The QRB2210 RB1 board gets debug UART moved per hardware update.
 regulator voltage ranges are corrected, remoteprocs are enabled, USB
 SuperSpeed PHY is enabled, and GPIO LEDs are introduced for Bluetooth,
 WiFi and a user LED.
 
 Interrupts are described for the SGMII PHYs on SA8775P Ride platform,
 and the inline crypto engine is introduced for UFS.
 
 On SC7180 the audio DSP remoteproc is introduced. Additional SKUs of the
 Lazor boards are added.The RT5682 audio codec part is reorganized to be
 easier to maintain. On Trogdor devices, the touchscreen and display
 panels are linked to improve the power cycling behavior across the two.
 
 On SC7280 the cpuidle states are rewritten to support OS-initiated PCSI
 mode. LMH interrupts are added, to receive feedback when throttling
 occurs. The embedded usb debugger (EUD) description  and the dummy
 usb-c-connector node is removed, as this is not correctly described. The
 USB3 pipe clock input of the global clock controller is properly
 described.
 
 Modem remoteproc is introduced on SDM630, and the SDM670 PDC mapping is
 corrected.
 
 On the SDM845 MTP PCIe support is introduced. The volumn down and reset
 buttons are defined. Remoteproc firmware names and the WiFI
 configuration is corrected.
 On Sony Xperia XZ2, XZ2 Compact, and XZ3 GPIO lines names are provided
 for TLMM and PMICs. The camera regulators are also added.
 
 Display hardware blocks are added to SM6125, and enabled on Sony Xperia
 10 II.
 
 The ref clock is wired up to PCIe PHY on SM8150.
 
 On SM8250/QRB5165, and the RB5 board, the DisplayPort controller and the
 TCPM is introduced, with all the plumbing to get USB role and
 orientation switching, as well as DisplayPort altmode to work.
 Interconnects and power-domains are also described for the QUPs on this
 platform.
 
 Previously ignored PMICs are described for the SM8350 Hardware
 Development Kit (HDK), and PMR735a regulators are introduced. The
 pinctrl state for uart18 is corrected.
 
 On SM8450 HDK audio routes are corrected, to enable the analog
 microphones on the board. The addition of the PRNG is reverted, in favor
 of an upcoming additon of a true RNG.
 
 Constants are replaced with QCOM_SCM_VMID_* defines on a variety of
 boards.
 
 The SM8550 QRD board gets Bluetooth support, and the camera clock
 controller is described.
 
 Additionally, a number of fixes are introduced in a variety of platforms
 and boards, to align with Devicetree bindings.
 -----BEGIN PGP SIGNATURE-----
 
 iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmUsOR4VHGFuZGVyc3Nv
 bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FGQwP/j4xZY9E2lwB50BCFU7xtHSLHyf/
 HcUx6HjtUwvXj1ernoKLEykp6Vzpp+vn2mpuBmTYzXmi96rC8kQ9Ai/uNTt7IU1J
 xta08EoYDYyjXUoyQdjOav2VFJ60BK18pM4FIHECmx8zzoFkVzV1+rgH7ry1JX0I
 RV+NgTRNb3WphP7QCQk6iMIF4BUbiRp5FdqdpyxgxrHLFfhhvHeT1S+cqZ7DQ0nZ
 k72UuTeVyXXfihouJS2wnky69eA83YmOpBYoRvdBOvBtUS2GgCwcmCH4nXlDbzF+
 GkvVw5mmRmyXhpDK5bDhBsqJzbh0IDrjWMw/rgL356ZBAsc7hmlyA3s512L0qggj
 c5lj2VYKU3ebZwab4IhdO5zShXPyyqmkrRzRblMi5NXanK+2Dypt8a88N/djSwxJ
 3EH2rs4R2pRHITxH7u3J9qsqTFUR8jFanw/MJQvQHXLSAJJF6zpwinOsio7jup5x
 uMx3Ty1wNKMpzR0GGmfRkd0UEyQN0+yPDPesPIbr2B3I6ZMAXmHD+eLhpbL5Riw9
 DZAAzaEeERTRNaZ7GMC3g7jxwdnjrC5q8f7MKPYfvUjkQdMLzhH3GZmm3o4fN5Bo
 rDVx7alUOblvLViBZBfQIbw5GX+Yq38ow4KxeKTnT0WOaXchZxISKeeu7Gn8I+2j
 DgG7/KMpjbzmKDRM
 =zgxm
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUtOv0ACgkQYKtH/8kJ
 UifMew/+MWcU1rn8D9083g00Hb9mqeCSNUp9o6B2AL0DZea9ABjWs/IQo5suRnMe
 TxQgnkgA+0nVCdfmF3spcMJ39D3gzaWnHGeMr1LsGsbMRmXVfBcWzpgkpRB2k2iE
 PxcpLpVWrrIjwhqtqcy8X4BGaDaVRA7jFGh810/tF9Avp74ndq4lXYNhf2/MmvuW
 iqGztm0n2Qua97dbP/Lyg4zmMMUT9i7QiuToxeJZuqg36am0OkXynsNT8wmwQuO2
 pvz9ul2sofIq677VUTMZgxmDl4QM4h+/qkeUwaBjvFOpEtaqjwynBcf1RBCzmMsj
 5/pWzypNUh0ELSbGiiDpwlTh9Blq4BY8Lt1tOXFBHXVe5Nee2KS79IVTcLxOFM0i
 e1K68r3kw/yzFwCgKBCfP3qzRCmUHeTDI0KTrL3erPMAhIB06TKlgNn+QPot2dti
 SkBj/zyXAtfxh6NYPKSQHKvJsun9BsO5ZML0Wo58U+hSm1W53zYmjMVKEJJux3N7
 31OECKmqzipo3PLEc0rcMJ0HMmPQR+YdGpfXP3IaDiT6o2Ea2LN4kSavCOrUbnec
 asg6LHcuDvmbarfBSfDeSAEcI4c6ZCs9LXTStkiB/K17sOZvFW1UO1pQmChK5EVA
 K8nSBBgeL1RnGTXM7IGJTbI9WJi00+mDS5gG5Kwq9x7GxsDtWuk=
 =9WsA
 -----END PGP SIGNATURE-----

Merge tag 'qcom-arm64-for-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt

Qualcomm ARM64 DeviceTree updates for v6.7

The SM7125 platform is introduced, with support for Xiaomi Redmi Note 9
Pro. Support for Fairphone 5, on QCM6490, and BQ Aquaris M5, on MSM8939,
are introduced.

With the various QMP PHY bindings having been refactored, SC7180,
SC7280, SDM845, SM8150, and SM8250 are transitioned to the new USB/DP
combo PHY binding. IPQ6018, IPQ8074 MSM8998, SC7280, SC8180X, SDM845,
SM8150, SM8250, and SM8450 are transitioned to the new PCIe PHY binding,
and SC8180X is transitioned to the new UFS phy binding.

The UFS power supply situation is clarified, and a range of boards
across MSM8996, MSM8998, SM4250, SM6115, SM6125, SM8350, SM8450, and
SM8550 receives corrections for this.

On IPQ5018 watchdog support is introduced, and the SCM driver has SDI
(debug image) enabled - so that it can be disabled. On IPQ5332 USB is
enabled. The hwspinlock identifier is corrected across IPQ5332, IPQ6018,
IPQ8074 and IPQ9574.

The reserved-memory ranges for the remoteprocs on MSM8916 boards are
refactored, to reduce the amount of duplicated boilerplate definitions.
A number of nodes are transitioned to be disabled by default, to
facilitate new boards.
Samsung Galaxy Tab A 8.0 and Samsung Galaxy Tab A 9.7 gains display
support, and the latter capacitive keys. Samsung Galaxy J5 gains
accelerometer support. The Dragonboard 410c gains missing ADC7533
regulator definition, and an overlay forcing the board to operate in
host mode, for automation purposes.

On MSM8976, the outgoing IPC bits for modem and wcss are corrected, and
reserved-memory regions are updated.

Incorrect reserved-memory regions are also corrected for MSM8992 and
MSM8994 devices.

The QRB2210 RB1 board gets debug UART moved per hardware update.
regulator voltage ranges are corrected, remoteprocs are enabled, USB
SuperSpeed PHY is enabled, and GPIO LEDs are introduced for Bluetooth,
WiFi and a user LED.

Interrupts are described for the SGMII PHYs on SA8775P Ride platform,
and the inline crypto engine is introduced for UFS.

On SC7180 the audio DSP remoteproc is introduced. Additional SKUs of the
Lazor boards are added.The RT5682 audio codec part is reorganized to be
easier to maintain. On Trogdor devices, the touchscreen and display
panels are linked to improve the power cycling behavior across the two.

On SC7280 the cpuidle states are rewritten to support OS-initiated PCSI
mode. LMH interrupts are added, to receive feedback when throttling
occurs. The embedded usb debugger (EUD) description  and the dummy
usb-c-connector node is removed, as this is not correctly described. The
USB3 pipe clock input of the global clock controller is properly
described.

Modem remoteproc is introduced on SDM630, and the SDM670 PDC mapping is
corrected.

On the SDM845 MTP PCIe support is introduced. The volumn down and reset
buttons are defined. Remoteproc firmware names and the WiFI
configuration is corrected.
On Sony Xperia XZ2, XZ2 Compact, and XZ3 GPIO lines names are provided
for TLMM and PMICs. The camera regulators are also added.

Display hardware blocks are added to SM6125, and enabled on Sony Xperia
10 II.

The ref clock is wired up to PCIe PHY on SM8150.

On SM8250/QRB5165, and the RB5 board, the DisplayPort controller and the
TCPM is introduced, with all the plumbing to get USB role and
orientation switching, as well as DisplayPort altmode to work.
Interconnects and power-domains are also described for the QUPs on this
platform.

Previously ignored PMICs are described for the SM8350 Hardware
Development Kit (HDK), and PMR735a regulators are introduced. The
pinctrl state for uart18 is corrected.

On SM8450 HDK audio routes are corrected, to enable the analog
microphones on the board. The addition of the PRNG is reverted, in favor
of an upcoming additon of a true RNG.

Constants are replaced with QCOM_SCM_VMID_* defines on a variety of
boards.

The SM8550 QRD board gets Bluetooth support, and the camera clock
controller is described.

Additionally, a number of fixes are introduced in a variety of platforms
and boards, to align with Devicetree bindings.

* tag 'qcom-arm64-for-6.7' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (148 commits)
  arm64: dts: qcom: apq8016-sbc: Add missing ADV7533 regulators
  ARM: dts: qcom: sdx65-mtp: Specify PM7250B SID to use
  arm64: dts: qcom: apq8016-sbc: Add overlay for usb host mode
  arm64: dts: qcom: qcm6490: Add device-tree for Fairphone 5
  dt-bindings: arm: qcom: Add QCM6490 Fairphone 5
  arm64: dts: qcom: pm8350c: Add flash led node
  arm64: dts: qcom: pm7250b: make SID configurable
  arm64: dts: qcom: sc7280: Mark some nodes as 'reserved'
  arm64: dts: qcom: msm8939: Fix iommu local address range
  arm64: dts: qcom: ipq5018: indicate that SDI should be disabled
  arm64: dts: qcom: msm8976: Fix ipc bit shifts
  arm64: dts: qcom: msm8976: Split lpass region
  arm64: dts: qcom: pm8150l: Add wled node
  arm64: dts: qcom: sa8775p: enable the inline crypto engine
  arm64: dts: qcom: msm8916/39: Fix venus memory size
  arm64: dts: qcom: msm8916/39: Move mpss_mem size to boards
  arm64: dts: qcom: msm8916/39: Disable unneeded firmware reservations
  arm64: dts: qcom: msm8939: Reserve firmware memory dynamically
  arm64: dts: qcom: msm8916: Reserve MBA memory dynamically
  arm64: dts: qcom: msm8916: Reserve firmware memory dynamically
  ...

Link: https://lore.kernel.org/r/20231015191107.854658-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
 2023-10-16 15:30:37 +02:00
Marek Marczykowski-Górecki
2c269f42d0 xen-pciback: Consider INTx disabled when MSI/MSI-X is enabled 
Linux enables MSI-X before disabling INTx, but keeps MSI-X masked until
the table is filled. Then it disables INTx just before clearing MASKALL
bit. Currently this approach is rejected by xen-pciback.
According to the PCIe spec, device cannot use INTx when MSI/MSI-X is
enabled (in other words: enabling MSI/MSI-X implicitly disables INTx).

Change the logic to consider INTx disabled if MSI/MSI-X is enabled. This
applies to three places:
 - checking currently enabled interrupts type,
 - transition to MSI/MSI-X - where INTx would be implicitly disabled,
 - clearing INTx disable bit - which can be allowed even if MSI/MSI-X is
   enabled, as device should consider INTx disabled anyway in that case

Fixes: 5e29500eba ("xen-pciback: Allow setting PCI_MSIX_FLAGS_MASKALL too")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20231016131348.1734721-1-marmarek@invisiblethingslab.com
Signed-off-by: Juergen Gross <jgross@suse.com>
 2023-10-16 15:20:31 +02:00
Viresh Kumar
f0d7db7b33 xen: privcmd: Add support for ioeventfd 
Virtio guests send VIRTIO_MMIO_QUEUE_NOTIFY notification when they need
to notify the backend of an update to the status of the virtqueue. The
backend or another entity, polls the MMIO address for updates to know
when the notification is sent.

It works well if the backend does this polling by itself. But as we move
towards generic backend implementations, we end up implementing this in
a separate user-space program.

Generally, the Virtio backends are implemented to work with the Eventfd
based mechanism. In order to make such backends work with Xen, another
software layer needs to do the polling and send an event via eventfd to
the backend once the notification from guest is received. This results
in an extra context switch.

This is not a new problem in Linux though. It is present with other
hypervisors like KVM, etc. as well. The generic solution implemented in
the kernel for them is to provide an IOCTL call to pass the address to
poll and eventfd, which lets the kernel take care of polling and raise
an event on the eventfd, instead of handling this in user space (which
involves an extra context switch).

This patch adds similar support for xen.

Inspired by existing implementations for KVM, etc..

This also copies ioreq.h header file (only struct ioreq and related
macros) from Xen's source tree (Top commit 5d84f07fe6bf ("xen/pci: drop
remaining uses of bool_t")).

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/b20d83efba6453037d0c099912813c79c81f7714.1697439990.git.viresh.kumar@linaro.org
Signed-off-by: Juergen Gross <jgross@suse.com>
 2023-10-16 15:18:33 +02:00
Viresh Kumar
9e90e58c11 xen: evtchn: Allow shared registration of IRQ handers 
Currently the handling of events is supported either in the kernel or
userspace, but not both.

In order to support fast delivery of interrupts from the guest to the
backend, we need to handle the Queue notify part of Virtio protocol in
kernel and the rest in userspace.

Update the interrupt handler registration flag to IRQF_SHARED for event
channels, which would allow multiple entities to bind their interrupt
handler for the same event channel port.

Also increment the reference count of irq_info when multiple entities
try to bind event channel to irqchip, so the unbinding happens only
after all the users are gone.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/99b1edfd3147c6b5d22a5139dab5861e767dc34a.1697439990.git.viresh.kumar@linaro.org
Signed-off-by: Juergen Gross <jgross@suse.com>
 2023-10-16 15:18:33 +02:00
Viresh Kumar
767e33ca47 xen: irqfd: Use _IOW instead of the internal _IOC() macro 
_IOC() an internal helper that we should not use in driver code.  In
particular, we got the data direction wrong here, which breaks a number
of tools, as having "_IOC_NONE" should never be paired with a nonzero
size.

Use _IOW() instead.

Fixes: f8941e6c4c ("xen: privcmd: Add support for irqfd")
Reported-by: Arnd Bergmann <arnd@kernel.org>
Closes: https://lore.kernel.org/all/268a2031-63b8-4c7d-b1e5-8ab83ca80b4a@app.fastmail.com/
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/599ca6f1b9dd2f0e6247ea37bee3ea6827404b6d.1697439990.git.viresh.kumar@linaro.org
Signed-off-by: Juergen Gross <jgross@suse.com>
 2023-10-16 15:18:33 +02:00
Viresh Kumar
8dd765a5d7 xen: Make struct privcmd_irqfd's layout architecture independent 
Using indirect pointers in an ioctl command argument means that the
layout is architecture specific, in particular we can't use the same one
from 32-bit compat tasks. The general recommendation is to have __u64
members and use u64_to_user_ptr() to access it from the kernel if we are
unable to avoid the pointers altogether.

Fixes: f8941e6c4c ("xen: privcmd: Add support for irqfd")
Reported-by: Arnd Bergmann <arnd@kernel.org>
Closes: https://lore.kernel.org/all/268a2031-63b8-4c7d-b1e5-8ab83ca80b4a@app.fastmail.com/
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/a4ef0d4a68fc858b34a81fd3f9877d9b6898eb77.1697439990.git.viresh.kumar@linaro.org
Signed-off-by: Juergen Gross <jgross@suse.com>
 2023-10-16 15:18:33 +02:00
Gustavo A. R. Silva
d3a2b6b48f xen/xenbus: Add __counted_by for struct read_buffer and use struct_size() 
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).

While there, use struct_size() helper, instead of the open-coded
version, to calculate the size for the allocation of the whole
flexible structure, including of course, the flexible-array member.

This code was found with the help of Coccinelle, and audited and
fixed manually.

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Link: https://lore.kernel.org/r/ZSRMosLuJJS5Y/io@work
Signed-off-by: Juergen Gross <jgross@suse.com>
 2023-10-16 15:18:33 +02:00
Juergen Gross
44961b81a9 xenbus: fix error exit in xenbus_init() 
In case an error occurs in xenbus_init(), xen_store_domain_type should
be set to XS_UNKNOWN.

Fix one instance where this action is missing.

Fixes: 5b3353949e ("xen: add support for initializing xenstore later as HVM domain")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/r/202304200845.w7m4kXZr-lkp@intel.com/
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Link: https://lore.kernel.org/r/20230822091138.4765-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
 2023-10-16 15:18:33 +02:00
Mark Rutland
e8d4006dc2 arm64: Remove cpus_have_const_cap() 
There are no longer any users of cpus_have_const_cap(), and therefore it
can be removed.

Remove cpus_have_const_cap(). At the same time, remove
__cpus_have_const_cap(), as this is a trivial wrapper of
alternative_has_cap_unlikely(), which can be used directly instead.

The comment for __system_matches_cap() is updated to no longer refer to
cpus_have_const_cap(). As we have a number of ways to check the cpucaps,
the specific suggestions are removed.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:07 +01:00
Mark Rutland
47759eca76 arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_REPEAT_TLBI 
In arch_tlbbatch_should_defer() we use cpus_have_const_cap() to check
for ARM64_WORKAROUND_REPEAT_TLBI, but this is not necessary and
alternative_has_cap_*() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The cpus_have_const_cap() check in arch_tlbbatch_should_defer() is an
optimization to avoid some redundant work when the
ARM64_WORKAROUND_REPEAT_TLBI cpucap is detected and forces the immediate
use of TLBI + DSB ISH. In the window between detecting the
ARM64_WORKAROUND_REPEAT_TLBI cpucap and patching alternatives this is
not a big concern and there's no need to optimize this window at the
expsense of subsequent usage at runtime.

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime. The ARM64_WORKAROUND_REPEAT_TLBI cpucap is added to
cpucap_is_possible() so that code can be elided entirely when this is
not possible without requiring ifdeffery or IS_ENABLED() checks at each
usage.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:07 +01:00
Mark Rutland
0d48058ef8 arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_NVIDIA_CARMEL_CNP 
In has_useable_cnp() we use cpus_have_const_cap() to check for
ARM64_WORKAROUND_NVIDIA_CARMEL_CNP, but this is not necessary and
cpus_have_cap() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

We use has_useable_cnp() to determine whether we have the system-wide
ARM64_HAS_CNP cpucap. Due to the structure of the cpufeature code, we
call has_useable_cnp() in two distinct cases:

1) When finalizing system capabilities, setup_system_capabilities() will
   call has_useable_cnp() with SCOPE_SYSTEM to determine whether all
   CPUs have the feature. This is called after we've detected any local
   cpucaps including ARM64_WORKAROUND_NVIDIA_CARMEL_CNP, but prior to
   patching alternatives.

   If the ARM64_WORKAROUND_NVIDIA_CARMEL_CNP was detected, we will not
   detect ARM64_HAS_CNP.

2) After finalizing system capabilties, verify_local_cpu_capabilities()
   will call has_useable_cnp() with SCOPE_LOCAL_CPU to verify that CPUs
   have CNP if we previously detected it.

   Note that if ARM64_WORKAROUND_NVIDIA_CARMEL_CNP was detected, we will
   not have detected ARM64_HAS_CNP.

For case 1 we must check the system_cpucaps bitmap as this occurs prior
to patching the alternatives. For case 2 we'll only call
has_useable_cnp() once per subsequent onlining of a CPU, and as this
isn't a fast path it's not necessary to optimize for this case.

This patch replaces the use of cpus_have_const_cap() with
cpus_have_cap(), which will only generate the bitmap test and avoid
generating an alternative sequence, resulting in slightly simpler annd
smaller code being generated. The ARM64_WORKAROUND_NVIDIA_CARMEL_CNP
cpucap is added to cpucap_is_possible() so that code can be elided
entirely when this is not possible.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:07 +01:00
Mark Rutland
a98a5eac4d arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_CAVIUM_23154 
In gic_read_iar() we use cpus_have_const_cap() to check for
ARM64_WORKAROUND_CAVIUM_23154 but this is not necessary and
alternative_has_cap_*() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_WORKAROUND_CAVIUM_23154 cpucap is detected and patched early
on the boot CPU before the GICv3 driver is initialized and hence before
gic_read_iar() is ever called. Thus it is not necessary to use
cpus_have_const_cap(), and alternative_has_cap() is equivalent.

In addition, arm64's gic_read_iar() lives in irq-gic-v3.c purely for
historical reasons. It was originally added prior to 32-bit arm support
in commit:

  6d4e11c5e2 ("irqchip/gicv3: Workaround for Cavium ThunderX erratum 23154")

When support for 32-bit arm was added, 32-bit arm's gic_read_iar()
implementation was placed in <asm/arch_gicv3.h>, but the arm64 version
was kept within irq-gic-v3.c as it depended on a static key local to
irq-gic-v3.c and it was easier to add ifdeffery, which is what we did in
commit:

  7936e914f7 ("irqchip/gic-v3: Refactor the arm64 specific parts")

Subsequently the static key was replaced with a cpucap in commit:

  a4023f6827 ("arm64: Add hypervisor safe helper for checking constant capabilities")

Since that commit there has been no need to keep arm64's gic_read_iar()
in irq-gic-v3.c.

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime. For consistency, move the arm64-specific gic_read_iar()
implementation over to arm64's <asm/arch_gicv3.h>. The
ARM64_WORKAROUND_CAVIUM_23154 cpucap is added to cpucap_is_possible() so
that code can be elided entirely when this is not possible.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:07 +01:00
Mark Rutland
412cb3801d arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_2645198 
We use cpus_have_const_cap() to check for ARM64_WORKAROUND_2645198 but
this is not necessary and alternative_has_cap() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_WORKAROUND_2645198 cpucap is detected and patched before any
userspace translation table exist, and the workaround is only necessary
when manipulating usrspace translation tables which are in use. Thus it
is not necessary to use cpus_have_const_cap(), and alternative_has_cap()
is equivalent.

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime.  The ARM64_WORKAROUND_2645198 cpucap is added to
cpucap_is_possible() so that code can be elided entirely when this is
not possible, and redundant IS_ENABLED() checks are removed.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:07 +01:00
Mark Rutland
48b57d9199 arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_1742098 
In elf_hwcap_fixup() we use cpus_have_const_cap() to check for
ARM64_WORKAROUND_1742098, but this is not necessary and cpus_have_cap()
would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_WORKAROUND_1742098 cpucap is detected and patched before
elf_hwcap_fixup() can run, and hence it is not necessary to use
cpus_have_const_cap(). We run cpus_have_const_cap() at most twice: once
after finalizing system cpucaps, and potentially once more after
detecting mismatched CPUs which support AArch32 at EL0. Due to this,
it's not necessary to optimize for many calls to elf_hwcap_fixup(), and
it's fine to use cpus_have_cap().

This patch replaces the use of cpus_have_const_cap() with
cpus_have_cap(), which will only generate the bitmap test and avoid
generating an alternative sequence, resulting in slightly simpler annd
smaller code being generated. For consistenct with other cpucaps, the
ARM64_WORKAROUND_1742098 cpucap is added to cpucap_is_possible() so that
code can be elided when this is not possible. However, as we only define
compat_elf_hwcap2 when CONFIG_COMPAT=y, some ifdeffery is still required
within user_feature_fixup() to avoid build errors when CONFIG_COMPAT=n.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:06 +01:00
Mark Rutland
d1e40f8222 arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_1542419 
We use cpus_have_const_cap() to check for ARM64_WORKAROUND_1542419 but
this is not necessary and cpus_have_final_cap() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_WORKAROUND_1542419 cpucap is detected and patched before any
userspace code can run, and the both __do_compat_cache_op() and
ctr_read_handler() are only reachable from exceptions taken from
userspace. Thus it is not necessary for either to use
cpus_have_const_cap(), and cpus_have_final_cap() is equivalent.

This patch replaces the use of cpus_have_const_cap() with
cpus_have_final_cap(), which will avoid generating code to test the
system_cpucaps bitmap and should be better for all subsequent calls at
runtime. Using cpus_have_final_cap() clearly documents that we do not
expect this code to run before cpucaps are finalized, and will make it
easier to spot issues if code is changed in future to allow these
functions to be reached earlier.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:06 +01:00
Mark Rutland
0a285dfe87 arm64: Avoid cpus_have_const_cap() for ARM64_WORKAROUND_843419 
In count_plts() and is_forbidden_offset_for_adrp() we use
cpus_have_const_cap() to check for ARM64_WORKAROUND_843419, but this is
not necessary and cpus_have_final_cap() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

It's not possible to load a module in the window between detecting the
ARM64_WORKAROUND_843419 cpucap and patching alternatives. The module VA
range limits are initialized much later in module_init_limits() which is
a subsys_initcall, and module loading cannot happen before this. Hence
it's not necessary for count_plts() or is_forbidden_offset_for_adrp() to
use cpus_have_const_cap().

This patch replaces the use of cpus_have_const_cap() with
cpus_have_final_cap() which will avoid generating code to test the
system_cpucaps bitmap and should be better for all subsequent calls at
runtime. Using cpus_have_final_cap() clearly documents that we do not
expect this code to run before cpucaps are finalized, and will make it
easier to spot issues if code is changed in future to allow modules to
be loaded earlier. The ARM64_WORKAROUND_843419 cpucap is added to
cpucap_is_possible() so that code can be elided entirely when this is not
possible, and redundant IS_ENABLED() checks are removed.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:06 +01:00
Mark Rutland
c2ef5f1e15 arm64: Avoid cpus_have_const_cap() for ARM64_UNMAP_KERNEL_AT_EL0 
In arm64_kernel_unmapped_at_el0() we use cpus_have_const_cap() to check
for ARM64_UNMAP_KERNEL_AT_EL0, but this is only necessary so that
arm64_get_bp_hardening_vector() and this_cpu_set_vectors() can run prior
to alternatives being patched. Otherwise this is not necessary and
alternative_has_cap_*() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_UNMAP_KERNEL_AT_EL0 cpucap is a system-wide feature that is
detected and patched before any translation tables are created for
userspace. In the window between detecting the ARM64_UNMAP_KERNEL_AT_EL0
cpucap and patching alternatives, most users of
arm64_kernel_unmapped_at_el0() do not need to know that the cpucap has
been detected:

* As KVM is initialized after cpucaps are finalized, no usaef of
  arm64_kernel_unmapped_at_el0() in the KVM code is reachable during
  this window.

* The arm64_mm_context_get() function in arch/arm64/mm/context.c is only
  called after the SMMU driver is brought up after alternatives have
  been patched. Thus this can safely use cpus_have_final_cap() or
  alternative_has_cap_*().

  Similarly the asids_update_limit() function is called after
  alternatives have been patched as an arch_initcall, and this can
  safely use cpus_have_final_cap() or alternative_has_cap_*().

  Similarly we do not expect an ASID rollover to occur between cpucaps
  being detected and patching alternatives. Thus
  set_reserved_asid_bits() can safely use cpus_have_final_cap() or
  alternative_has_cap_*().

* The __tlbi_user() and __tlbi_user_level() macros are not used during
  this window, and only need to invalidate additional entries once
  userspace translation tables have been active on a CPU. Thus these can
  safely use alternative_has_cap_*().

* The xen_kernel_unmapped_at_usr() function is not used during this
  window as it is only used in a late_initcall. Thus this can safely use
  cpus_have_final_cap() or alternative_has_cap_*().

* The arm64_get_meltdown_state() function is not used during this
  window. It only used by arm64_get_meltdown_state() and KVM code, both
  of which are only used after cpucaps have been finalized. Thus this
  can safely use cpus_have_final_cap() or alternative_has_cap_*().

* The tls_thread_switch() uses arm64_kernel_unmapped_at_el0() as an
  optimization to avoid zeroing tpidrro_el0 when KPTI is enabled
  and this will be trampled by the KPTI trampoline. It doesn't matter if
  this continues to zero the register during the window between
  detecting the cpucap and patching alternatives, so this can safely use
  alternative_has_cap_*().

* The sdei_arch_get_entry_point() and do_sdei_event() functions aren't
  reachable at this time as the SDEI driver is registered later by
  acpi_init() -> acpi_ghes_init() -> sdei_init(), where acpi_init is a
  subsys_initcall. Thus these can safely use cpus_have_final_cap() or
  alternative_has_cap_*().

* The uses under drivers/ aren't reachable at this time as the drivers
  are registered later:

  - TRBE is registered via module_init()
  - SMMUv3 is registred via module_driver()
  - SPE is registred via module_init()

* The arm64_get_bp_hardening_vector() and this_cpu_set_vectors()
  functions need to run on boot CPUs prior to patching alternatives.
  As these are only called during the onlining of a CPU, it's fine to
  perform a system_cpucaps bitmap test using cpus_have_cap().

This patch modifies this_cpu_set_vectors() to use cpus_have_cap(), and
replaced all other use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime. The ARM64_UNMAP_KERNEL_AT_EL0 cpucap is added to
cpucap_is_possible() so that code can be elided entirely when this is
not possible.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:06 +01:00
Mark Rutland
a76521d160 arm64: Avoid cpus_have_const_cap() for ARM64_{SVE,SME,SME2,FA64} 
In system_supports_{sve,sme,sme2,fa64}() we use cpus_have_const_cap() to
check for the relevant cpucaps, but this is only necessary so that
sve_setup() and sme_setup() can run prior to alternatives being patched,
and otherwise alternative_has_cap_*() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

All of system_supports_{sve,sme,sme2,fa64}() will return false prior to
system cpucaps being detected. In the window between system cpucaps being
detected and patching alternatives, we need system_supports_sve() and
system_supports_sme() to run to initialize SVE and SME properties, but
all other users of system_supports_{sve,sme,sme2,fa64}() don't depend on
the relevant cpucap becoming true until alternatives are patched:

* No KVM code runs until after alternatives are patched, and so this can
  safely use cpus_have_final_cap() or alternative_has_cap_*().

* The cpuid_cpu_online() callback in arch/arm64/kernel/cpuinfo.c is
  registered later from cpuinfo_regs_init() as a device_initcall, and so
  this can safely use cpus_have_final_cap() or alternative_has_cap_*().

* The entry, signal, and ptrace code isn't reachable until userspace has
  run, and so this can safely use cpus_have_final_cap() or
  alternative_has_cap_*().

* Currently perf_reg_validate() will un-reserve the PERF_REG_ARM64_VG
  pseudo-register before alternatives are patched, and before
  sve_setup() has run. If a sampling event is created early enough, this
  would allow perf_ext_reg_value() to sample (the as-yet uninitialized)
  thread_struct::vl[] prior to alternatives being patched.

  It would be preferable to defer this until alternatives are patched,
  and this can safely use alternative_has_cap_*().

* The context-switch code will run during this window as part of
  stop_machine() used during alternatives_patch_all(), and potentially
  for other work if other kernel threads are created early. No threads
  require the use of SVE/SME/SME2/FA64 prior to alternatives being
  patched, and it would be preferable for the related context-switch
  logic to take effect after alternatives are patched so that ths is
  guaranteed to see a consistent system-wide state (e.g. anything
  initialized by sve_setup() and sme_setup().

  This can safely ues alternative_has_cap_*().

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime. The sve_setup() and sme_setup() functions are modified to
use cpus_have_cap() directly so that they can observe the cpucaps being
set prior to alternatives being patched.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:06 +01:00
Mark Rutland
af64543977 arm64: Avoid cpus_have_const_cap() for ARM64_SPECTRE_V2 
In arm64_apply_bp_hardening() we use cpus_have_const_cap() to check for
ARM64_SPECTRE_V2 , but this is not necessary and alternative_has_cap_*()
would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The cpus_have_const_cap() check in arm64_apply_bp_hardening() is
intended to avoid the overhead of looking up and invoking a per-cpu
function pointer when no branch predictor hardening is required. The
arm64_apply_bp_hardening() function itself is called in two distinct
flows:

1) When handling certain exceptions taken from EL0, where the PC could
   be a TTBR1 address and hence might have trained a branch predictor.

   As cpucaps are detected and alternatives are patched long before it
   is possible to execute userspace, it is not necessary to use
   cpus_have_const_cap() for these cases, and cpus_have_final_cap() or
   alternative_has_cap() would be preferable.

2) When switching between tasks in check_and_switch_context().

   This can be called before cpucaps are detected and alternatives are
   patched, but this is long before the kernel mounts filesystems or
   accepts any input. At this stage the kernel hasn't loaded any secrets
   and there is no potential for hostile branch predictor training. Once
   cpucaps have been finalized and alternatives have been patched,
   switching tasks will invalidate any prior predictions. Hence it is
   not necessary to use cpus_have_const_cap() for this case.

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:05 +01:00
Mark Rutland
bc75d0c0f3 arm64: Avoid cpus_have_const_cap() for ARM64_SSBS 
In ssbs_thread_switch() we use cpus_have_const_cap() to check for
ARM64_SSBS, but this is not necessary and alternative_has_cap_*() would
be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The cpus_have_const_cap() check in ssbs_thread_switch() is an
optimization to avoid the overhead of
spectre_v4_enable_task_mitigation() where all CPUs implement SSBS and
naturally preserve the SSBS bit in SPSR_ELx. In the window between
detecting the ARM64_SSBS system-wide and patching alternative branches
it is benign to continue to call spectre_v4_enable_task_mitigation().

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:05 +01:00
Mark Rutland
94324bcbc9 arm64: Avoid cpus_have_const_cap() for ARM64_MTE 
In system_supports_mte() we use cpus_have_const_cap() to check for
ARM64_MTE, but this is not necessary and cpus_have_final_boot_cap()
would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_MTE cpucap is a boot cpu feature which is detected and patched
early on the boot CPU under smp_prepare_boot_cpu(). In the window
between detecting the ARM64_MTE cpucap and patching alternatives,
nothing depends on the ARM64_MTE cpucap:

* The kasan_hw_tags_enabled() helper depends upon the kasan_flag_enabled
  static key, which is initialized later in kasan_init_hw_tags() after
  alternatives have been applied.

* No KVM code is called during this window, and KVM is not initialized
  until after system cpucaps have been detected and patched. KVM code
  can safely use cpus_have_final_cap() or alternative_has_cap_*().

* We don't context-switch prior to patching boot alternatives, and thus
  mte_thread_switch() is not reachable during this window. Thus, we can
  safely use cpus_have_final_boot_cap() or alternative_has_cap_*() in
  the context-switch code.

* IRQ and FIQ are masked during this window, and we can only take SError
  and Debug exceptions. SError exceptions are fatal at this point in
  time, and we do not expect to take Debug exceptions, thus:

  - It's fine to lave TCO set for exceptions taken during this window,
    and mte_disable_tco_entry() doesn't need to do anything.

  - We don't need to detect and report asynchronous tag cehck faults
    during this window, and neither mte_check_tfsr_entry() nor
    mte_check_tfsr_exit() need to do anything.

  Since we want to report any SErrors taken during thiw window, these
  cannot safely use cpus_have_final_boot_cap() or cpus_have_final_cap(),
  but these can safely use alternative_has_cap_*().

* The __set_pte_at() function is not used during this window. It is
  possible for this to be used on kernel mappings prior to boot cpucaps
  being finalized, so this cannot safely use cpus_have_final_boot_cap()
  or cpus_have_final_cap(), but this can safely use
  alternative_has_cap_*().

* No userspace translation tables have been created yet, and swap has
  not been initialized yet. Thus swapping is not possible and none of
  the following are called:

  - arch_thp_swp_supported()
  - arch_prepare_to_swap()
  - arch_swap_invalidate_page()
  - arch_swap_invalidate_area()
  - arch_swap_restore()

  These can safely use system_has_final_cap() or
  alternative_has_cap_*().

* The elfcore functions are only reachable after userspace is brought
  up, which happens after system cpucaps have been detected and patched.
  Thus the elfcore code can safely use cpus_have_final_cap() or
  alternative_has_cap_*().

* Hibernation is only possible after userspace is brought up, which
  happens after system cpucaps have been detected and patched. Thus the
  hibernate code can safely use cpus_have_final_cap() or
  alternative_has_cap_*().

* The set_tagged_addr_ctrl() function is only reachable after userspace
  is brought up, which happens after system cpucaps have been detected
  and patched. Thus this can safely use cpus_have_final_cap() or
  alternative_has_cap_*().

* The copy_user_highpage() and copy_highpage() functions are not used
  during this window, and can safely use alternative_has_cap_*().

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which avoid generating code to test the
system_cpucaps bitmap and should be better for all subsequent calls at
runtime.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:05 +01:00
Mark Rutland
b54b525764 arm64: Avoid cpus_have_const_cap() for ARM64_HAS_TLB_RANGE 
We use cpus_have_const_cap() to check for ARM64_HAS_TLB_RANGE, but this
is not necessary and alternative_has_cap_*() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

In the window between detecting the ARM64_HAS_TLB_RANGE cpucap and
patching alternative branches, we do not perform any TLB invalidation,
and even if we were to perform TLB invalidation here it would not be
functionally necessary to optimize this by using range invalidation.
Hence there's no need to use cpus_have_const_cap(), and
alternative_has_cap_unlikely() is sufficient.

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:05 +01:00
Mark Rutland
4c73056e32 arm64: Avoid cpus_have_const_cap() for ARM64_HAS_WFXT 
In __delay() we use cpus_have_const_cap() to check for ARM64_HAS_WFXT,
but this is not necessary and alternative_has_cap() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The cpus_have_const_cap() check in __delay() is an optimization to use
WFIT and WFET in preference to busy-polling the counter and/or using
regular WFE and relying upon the architected timer event stream. It is
not necessary to apply this optimization in the window between detecting
the ARM64_HAS_WFXT cpucap and patching alternatives.

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:05 +01:00
Mark Rutland
1963d9660d arm64: Avoid cpus_have_const_cap() for ARM64_HAS_RNG 
In __cpu_has_rng() we use cpus_have_const_cap() to check for
ARM64_HAS_RNG, but this is not necessary and alternative_has_cap_*()
would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

In the window between detecting the ARM64_HAS_RNG cpucap and patching
alternative branches, nothing which calls __cpu_has_rng() can run, and
hence it's not necessary to use cpus_have_const_cap().

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:05 +01:00
Mark Rutland
4e00f1d9b7 arm64: Avoid cpus_have_const_cap() for ARM64_HAS_EPAN 
We use cpus_have_const_cap() to check for ARM64_HAS_EPAN but this is not
necessary and alternative_has_cap() or cpus_have_cap() would be
preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_HAS_EPAN cpucap is used to affect two things:

1) The permision bits used for userspace executable mappings, which are
   chosen by adjust_protection_map(), which is an arch_initcall. This is
   called after the ARM64_HAS_EPAN cpucap has been detected and
   alternatives have been patched, and before any userspace translation
   tables exist.

2) The handling of faults taken from (user or kernel) accesses to
   userspace executable mappings in do_page_fault(). Userspace
   translation tables are created after adjust_protection_map() is
   called, and hence after the ARM64_HAS_EPAN cpucap has been detected
   and alternatives have been patched.

Neither of these run until after ARM64_HAS_EPAN cpucap has been detected
and alternatives have been patched, and hence there's no need to use
cpus_have_const_cap(). Since adjust_protection_map() is only executed
once at boot time it would be best for it to use cpus_have_cap(), and
since do_page_fault() is executed frequently it would be best for it to
use alternatives_have_cap_unlikely().

This patch replaces the uses of cpus_have_const_cap() with
cpus_have_cap() and alternative_has_cap_unlikely(), which will avoid
generating redundant code, and should be better for all subsequent calls
at runtime. The ARM64_HAS_EPAN cpucap is added to cpucap_is_possible()
so that code can be elided entirely when this is not possible.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:04 +01:00
Mark Rutland
53d62e995d arm64: Avoid cpus_have_const_cap() for ARM64_HAS_PAN 
In system_uses_hw_pan() we use cpus_have_const_cap() to check for
ARM64_HAS_PAN, but this is only necessary so that the
system_uses_ttbr0_pan() check in setup_cpu_features() can run prior to
alternatives being patched, and otherwise this is not necessary and
alternative_has_cap_*() would be preferable.

For historical reasons, cpus_have_const_cap() is more complicated than
it needs to be. Before cpucaps are finalized, it will perform a bitmap
test of the system_cpucaps bitmap, and once cpucaps are finalized it
will use an alternative branch. This used to be necessary to handle some
race conditions in the window between cpucap detection and the
subsequent patching of alternatives and static branches, where different
branches could be out-of-sync with one another (or w.r.t. alternative
sequences). Now that we use alternative branches instead of static
branches, these are all patched atomically w.r.t. one another, and there
are only a handful of cases that need special care in the window between
cpucap detection and alternative patching.

Due to the above, it would be nice to remove cpus_have_const_cap(), and
migrate callers over to alternative_has_cap_*(), cpus_have_final_cap(),
or cpus_have_cap() depending on when their requirements. This will
remove redundant instructions and improve code generation, and will make
it easier to determine how each callsite will behave before, during, and
after alternative patching.

The ARM64_HAS_PAN cpucap is used by system_uses_hw_pan() and
system_uses_ttbr0_pan() depending on whether CONFIG_ARM64_SW_TTBR0_PAN
is selected, and:

* We only use system_uses_hw_pan() directly in __sdei_handler(), which
  isn't reachable until after alternatives have been patched, and for
  this it is safe to use alternative_has_cap_*().

* We use system_uses_ttbr0_pan() in a few places:

  - In check_and_switch_context() and cpu_uninstall_idmap(), which will
    defer installing a translation table into TTBR0 when the
    ARM64_HAS_PAN cpucap is not detected.

    Prior to patching alternatives, all CPUs will be using init_mm with
    the reserved ttbr0 translation tables install in TTBR0, so these can
    safely use alternative_has_cap_*().

  - In update_saved_ttbr0(), which will only save the active TTBR0 into
    a per-thread variable when the ARM64_HAS_PAN cpucap is not detected.

    Prior to patching alternatives, all CPUs will be using init_mm with
    the reserved ttbr0 translation tables install in TTBR0, so these can
    safely use alternative_has_cap_*().

  - In efi_set_pgd(), which will handle check_and_switch_context()
    deferring the installation of TTBR0 when TTBR0 PAN is detected.

    The EFI runtime services are not initialized until after
    alternatives have been patched, and so this can safely use
    alternative_has_cap_*() or cpus_have_final_cap().

  - In uaccess_ttbr0_disable() and uaccess_ttbr0_enable(), where we'll
    avoid installing/uninstalling a translation table in TTBR0 when
    ARM64_HAS_PAN is detected.

    Prior to patching alternatives we will not perform any uaccess and
    will not call uaccess_ttbr0_disable() or uaccess_ttbr0_enable(), and
    so these can safely use alternative_has_cap_*() or
    cpus_have_final_cap().

  - In is_el1_permission_fault() where we will consider a translation
    fault on a TTBR0 address to be a permission fault when ARM64_HAS_PAN
    is not detected *and* we have set the PAN bit in the SPSR (which
    tells us that in the interrupted context, TTBR0 pointed at the
    reserved zero ttbr).

    In the window between detecting system cpucaps and patching
    alternatives we should not perform any accesses to TTBR0 addresses,
    and no userspace translation tables exist until after patching
    alternatives. Thus it is safe for this to use alternative_has_cap*().

This patch replaces the use of cpus_have_const_cap() with
alternative_has_cap_unlikely(), which will avoid generating code to test
the system_cpucaps bitmap and should be better for all subsequent calls
at runtime.

So that the check for TTBR0 PAN in setup_cpu_features() can run prior to
alternatives being patched, the call to system_uses_ttbr0_pan() is
replaced with an explicit check of the ARM64_HAS_PAN bit in the
system_cpucaps bitmap.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
 2023-10-16 14:17:04 +01:00