Eric points out that our current suggested way of handling
EMSGSIZE errors ((err == -EMSGSIZE) ? skb->len : err) will
break if we didn't fit even a single object into the buffer
provided by the user. This should not happen for well behaved
applications, but we can fix that, and free netlink families
from dealing with that completely by moving error handling
into the core.
Let's assume from now on that all EMSGSIZE errors in dumps are
because we run out of skb space. Families can now propagate
the error nla_put_*() etc generated and not worry about any
return value magic. If some family really wants to send EMSGSIZE
to user space, assuming it generates the same error on the next
dump iteration the skb->len should be 0, and user space should
still see the EMSGSIZE.
This should simplify families and prevent mistakes in return
values which lead to DONE being forced into a separate recv()
call as discovered by Ido some time ago.
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Enable HDCP for Xe by defining functions which take care of
interaction of HDCP as a client with the GSC CS interface.
Add intel_hdcp_gsc_message to Makefile and add corresponding
changes to xe_hdcp_gsc.c to make it build.
--v2
-add kfree at appropriate place [Daniele]
-remove useless define [Daniele]
-move host session logic to xe_gsc_submit.c [Daniele]
-call xe_gsc_check_and_update_pending directly in an if condition
[Daniele]
-use xe_device instead of drm_i915_private [Daniele]
--v3
-use xe prefix for newly exposed function [Daniele]
-remove client specific defines from intel_gsc_mtl_header [Daniele]
-add missing kfree() [Daniele]
-have NULL check for hdcp_message in finish function [Daniele]
-dont have too many variable declarations in the same line [Daniele]
--v4
-don't point the hdcp_message structure in xe_device to anything
until it properly gets initialized [Daniele]
--v5
-Squash commits for buildability
--v6
-Order includes alphabetically [Lucas]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240306024247.1857881-6-suraj.kandpal@intel.com
Expose gsc_proxy_init_done so that we can check if gsc proxy has
been initialized or not.
--v2
-Check if GSC FW is enabled before taking forcewake ref [Daniele]
--v3
-Directly call proxy check function inside if condition
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240306024247.1857881-5-suraj.kandpal@intel.com
Use xe_device struct instead of drm_i915_private so as to not
cause confusion and comply with Xe standards as drm_i915_private is
xe_device under the hood.
--v2
-Fix commit message [Daniele]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240306024247.1857881-4-suraj.kandpal@intel.com
Move intel_hdcp_gsc_message definition into intel_hdcp_gsc.c
so that intel_hdcp_gsc_message can be redefined for xe as needed.
--v2
-Correct commit message to reflect what patch is actually doing [Arun]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240306024741.1858039-2-suraj.kandpal@intel.com
This fixes a "defined but not used"-warning in SPM driver when kernel is
built without regulator support, and corrects a couple of kernel-doc
issues in aoss and geni-se drivers.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmXn4QEVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FU0oQAK85IzmIeso/NfydQUfdmE6EE+xM
vlCCteYJG68Y38uxiQnyx7jCyj8czIt4oZ+t3GoduIiUFJ/6ACV2yNJMMRSWixIc
fXMM0HU+zgfeRyCXx9diuobbahVNFPjkjKF7y9vog7fL5uQSirXD/MwFu7/o3SZf
2UtDp2JTKexbo1/DNlIbB8OM0tzCFS55rodE7Rw6tZGaa8mt5D9lTS6wtnsyftM4
IyRBk53R8yeDO1fnitW6si/RSDBeT7yauy1MfOR7Ofo5xkBhHHcyCGIfa3+6pUtz
waDnXTd1nTcFvJTwoAgVw1XWVm60YAm76NZYyUOzntsBS5D03MQX+ao3AKvdjxIa
OUdts6EWqJtdoY7Y/UJbPpO5cZ/10r1z+Mka+9tG6UjTUv2xnxUc6ND/7pFGwmLo
2m7VS8eAcNw2OogrOjNtdR1jS/Fd57lXq8KPbSEgm+r8yw7GE2jJEsM1mbLTo+O+
CABdHKnDmDWePuLOT1qP0cR72QwVI5ERaZjMdwbdgqMsWp/KmmETLtb5N5PoTXnQ
vj70YBE2WYL/YNzc03BJe4rH1EvSSGzb5BKwEAYnnfx6HSsJHqyfQBJV6cGCFl3u
sloRMClPG19CS+eQtHhLCC4SfiH5o7iRYmCZCeyKqmqlvevaBvbflmELgb8xpxry
YiwXKkTOc5UcW1Ez
=3ZwG
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXoEKIACgkQYKtH/8kJ
Uifl6Q//YmyyNOucScttDSu/Nf2NlYo/FT7Rl8mrZgK1Aa6k35l+OfYn2qnJG6o6
O4tsx6JTAWKqbJNa1pCfqeLR98LZRaKx05ZXmR7cAOa33BtZZt5q+oG7KayO9/Qu
e7Pp26qOE4k89am+a10A3V3Qiy/QNjXGMx4Ihv1y+forbpWi6n/eiUn9i2IWcIkd
HmCkkxkLmI7P/q1cN8g9m1FMnC+C6kw8M3jz3Ok7JEgwkJu91sRMOuQbLaHgwJiC
OdEOdtNFLMzoBEJObTZkR1crgNd3uJ9zMrKoTsRu6QzSgovJ2LO0z8yqOfM613iY
hj706gcWBSnK4eBnmMFFWYDQGzVmqqfJnCvuBzGi312uC2IDom762sx0Ha5I49PV
p69IESO6R3aE7wp5AC9cwYlOxWF8PKhnd+FtOr+fM/xfyETJLcPJxvZk5VllIgUN
MHXY3k9bsKNXOa0h2B8gxe+Sm5/YTKQd7ToIIM6pBVOqWXckzdq5L/wiFk4f3/hk
2RoAwqGAdbzTMVKGoN5LMNcsOmZxSEXL7a1KO1EcXM9wq8o1tfXQUFdrqb6VpT3I
tVxN0P7mJ3aQalo9K0fJB+R8ImgDAhuZ2HFEALpZ0ve/H00cOL+8bt3kS7g2GhGb
mbkAUfiq3kfwUH1MCx9yfKdGyMBT/jD1jfTC9rsiblDWVbrl5wg=
=+egw
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-6.9-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers
A few Qualcomm driver fixes for v6.9
This fixes a "defined but not used"-warning in SPM driver when kernel is
built without regulator support, and corrects a couple of kernel-doc
issues in aoss and geni-se drivers.
* tag 'qcom-drivers-for-6.9-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: aoss: add missing kerneldoc for qmp members
soc: qcom: geni-se: drop unused kerneldoc struct geni_wrapper param
soc: qcom: spm: fix building with CONFIG_REGULATOR=n
Link: https://lore.kernel.org/r/20240306032120.5036-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This corrects the orientation of the panel of Xiaomi Pad 5 Pro, and
corrects a typo in the size of the SPMI channel register size in both
SM8550 and SM8650.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmXn35EVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FBnQP/A3y0bVnLcunnL87RMQTu8nIzfuP
8ZAbMInLJTyvF3icEUAAg6btU5bkjMDOfQpNxZUoGfcnz/HKJLWh/satl4SAEqZ4
Gv1+YJiZ69pGw1whGmpEosx8r0Cj20jrp52na0YCCEpdRn6mnCo0DyLcvWEyOYOp
XGp/bCmdy8Zydjj4ImiaY3aWABNSUIH3aVChbk29qPZglPHxipIY8fuLsOwo48FN
ZphWaXryurrhyVgLhsRCsAXF8raqn4PIrdk+fTDka1XEakVTxF+fUevzNGH1QHLT
3Xl9hEQeA4+Eks0cnATm49zuSOg+FVswawo/7XosAn1nYNMEgvC7Hz0GrLF0UfN+
9gc03ZHGPPbSHCZBHr0oA2eXyy0beS51pZqAD9bbBwtCdS6UooO2HZAnOgbYCtMC
XbtQbEFkAGa+6WdWaNmoGQfD6xpMEyOgozE8sw9B/ecQof2ZL0otzy/kaqSOheI5
RvWeCA+9whLG875dtBU1LKXytSSw+T0EkfPl7AIOdXbEwLtLshLPaWdLAdP4D8+A
BvJLbrhTLexFwEX1/3DPTXd01pxzyhyin/fumsjQoGG+gwK3oQ8x61tSFCiAUJGA
z7K/Ti5YdJqJhKaCmSR7TvgKB1qCoGL3MyLJMiqptBDnhV/2+3RTvH9mCEUuvxbu
TD5+L8VSvqoL/nTc
=dtx7
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXoEGUACgkQYKtH/8kJ
UieohBAAnZszQVLmVuKSorb1dwfcAvKj8UQzEzX/PlcydVv0M7NdAMacIo/BdI3/
2ZpsvjVLG0xUEDmDFriPCjh62Chw6HceqeM+0doY19sXYSoTkxFNCmt4r5yU+CmT
xXhOf1homc8t4evEKxkyLaB4bAUPeBoWkt2/fF4DwqoCbG03rmYPL3/ExNe7RtnC
KcsVhH1o2/v8032/YdBIutD3/enBrIPD7UgTr/YZ6sb8xWEH/xwLD8g6aZsncLri
g4VuszjOTQrbvOwiXck7sDf+i8KT8+rKUjPDiggGZStCDpCN7fQmW/Yz48Za3LTT
Ust3f/GhJFWnDRZOumE78TrQFFsBRmkVDUnIOdChyHuUh/9CFboJsjwqoPrIsISW
Bv4pbG9VVrxOkB1G72nEONb+evu2+WYX3LsaXfAENBL9cYSmrrE4xl5dIqGQoQ58
XhgRPQ5Drch7+uPrFZ+EdRTfil+Xl3StnOvqSPPV2LGUdzUuQmf4mk3GoijWvX0S
pIVCSH3vPagt+I0ak0KjvJPH7BdnOIKQuZw+3q+o78Fyx2YwnT5yr8uYHAvzCd/z
zd3qUfMyZyUXo8L91mjcJAAiT9RtsR0G1VSX3BGbJed6e/kBZUPa/zREcSFCPySH
r9+fyA7wiOS+6Zub4X+Fp1GF0I2wdkpAIEau5BIpaRLq3BxHKds=
=0Ani
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-6.9-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
A few Qualcomm Arm64 DeviceTree fixes for v6.9
This corrects the orientation of the panel of Xiaomi Pad 5 Pro, and
corrects a typo in the size of the SPMI channel register size in both
SM8550 and SM8650.
* tag 'qcom-arm64-for-6.9-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: sm8250-xiaomi-elish: set rotation
arm64: dts: qcom: sm8650: Fix SPMI channels size
arm64: dts: qcom: sm8550: Fix SPMI channels size
Link: https://lore.kernel.org/r/20240306031451.4545-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A single minor fix for an oversized allocation due to sizeof() misuse by
yours truly that came in since I sent my last fixes PR.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZed5RAAKCRB4tDGHoIJi
0qRIAQCeMKuoQNOHXQtC3u5FKGcpsZPctEnbhg2pWK6ZOwdqjwEAsEJLqApFw4cG
oB9cR3O3mtN49aOBM3w700Hafykv9Ak=
=oU9U
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXoEEAACgkQYKtH/8kJ
Uic1PRAAr/Fc1qOB6gp05NPqXDuHvFGU/qYCMINss8n33mXuyfG3HnR8YBoybEnH
mm0cpVn1VqsJbixiM1d07/luRfBZXiMCQw55UNwbU7PVyBHc9at9QnruYX4uFRsZ
V6AgTkni1QDDMYANFgvs9dJv+r4Ul1gusqSj/z71an/A6d2fmsVXlFkH7ZXsGhGR
PJR5NDLjuqJIR2kGKC23QvrQWY+Kuf90+6FExVOc/3ZnUS5Eg0QrbBf1vd8JYz+o
wNR/IeHO9anvoe1tSNJDpHDdCKl+88SiJGjUcMI/H4ncdkGslBuErzBB2cwRHWWC
JHD4ZbAB5qFNHaZqUTAuHkAyMdZEPxibDdtW084thD8X7vFJe27JuRXfMJTHWRKt
jemhC9mcZ/lEM1neShSZe7jdQLzzjEEdNSDe4dcMihstGu3yHDXuhzzf6AxXh5bU
GvihHMQ4ENnNSUgSDC6FcW+HOaakBL728JE6ySAIP/7mSICF9MVasyT+NO0DLTEC
67rmGoealy2c//dmtcslYDQzeFbaNtL4FpLVkc1uFotQ5FFHsXzbwkETAZOWZwbL
0nT5OnpdixwB2389RbAwXVrpstrgjYxRwKehNGa8LgIxKcsYVtROLRiwTs474g6a
PsYTW7GfCJg+SsT1A4cZ7sV8lP3cn5WwewZ+0lRjSTmdWgIQ294=
=OVem
-----END PGP SIGNATURE-----
Merge tag 'riscv-firmware-for-v6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes
RISC-V firmware drivers for v6.9
A single minor fix for an oversized allocation due to sizeof() misuse by
yours truly that came in since I sent my last fixes PR.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-firmware-for-v6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
firmware: microchip: Fix over-requested allocation size
Link: https://lore.kernel.org/r/20240305-vicinity-dumpling-8943ef26f004@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Microchip:
Missing bus clocks for the CAN controllers spotted during the creation
of a driver for the controllers and a specific compatible for the SiFive
PDMA block on PolarFire SoC.
Starfive:
PWM nodes for the jh7100 and jh7110. Camera subsystem support for the
latter. Most notably however is the addition of ethernet support for the
jh7110 which finally allows people to use the network on the OG VisionFive
and on the Beagle-V Starlight board. This was made possible by the
non-standard cache management operations support added for the RZ/Five
which could be extended to the ccache present on the jh7100.
bindings:
Additional clarification for what the reg property represents for cpus
and two opencores PWM binding changes - the original addition and an
added compatible. The latter is here as the driver patch was not ready
but the PWM maintainer told me to go ahead and merge it.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZed3VgAKCRB4tDGHoIJi
0rfBAP9n6/i9bitGfqZHXKc1CpqwIWb8sw28OC4u6UWaNEzSmQEA0R0bagMcfVDi
szpu4+58Bk4hbd/6lOwacdskEUp0bwU=
=gBjh
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXoD90ACgkQYKtH/8kJ
Uicd9hAAny3U0DB36GMakjIJJkBMSrrbIydydt9mSdkOjsgAt6qUUpBahbMjGE3+
U688dtHOMlsZ0ZubVngN+xYtI6xOXP9SU0+P3u/reCQ8SSZnbtndtwmRFd8ZHJFT
Nx5MSl71SzzSL7E3vT638VlZvcq0a5fcUKPZql40iLUnY0iJ6IdcU8cZLWoqkOZF
R2zhCUGzLuRrAZF9nPgAKGHwPskq1gqWMMCnLf6NIgaxfjf8POuGAgJBVJ1CYg0P
kSzXUrEphjD+IpCbffkGJ1epq1+SbYfYo6P9MisiWbv8/xvoZ+VJnbTb+NLg3Wuo
i8B5uFOBi65rLCCErDDYNr2huESHHC8IN9ndvRG/eXTaLek4WhJ1cxXDPHBzN9OF
DMKKgSeRZnMj/EQ0jQQPK0I9KymVdy+qwAhAr0DKEzGSiiu1hVlxfvspq+EzW9DR
O9v2+hRCALpripRGf7wVG+16HtzvbbH1hHGABb4YTl3rf0bSqXTt84wIQ9MBSe+e
nFsCnOdA5zNBN3gtiKlbYQE/jiTYCeyqfCJOwXlw83KKSGJfNG+mTOR/vhpVOAbq
Djb6dEemeYxZ95P5PFSqm7GOttZWI3vthyWpPeF1qfGuZ6g55+zZyZHsVKevkWzd
54Z/rpLdUBeDRkwNLa9W0r/5oZOLNccKhkS9Qy6umjSsBXa14qA=
=0UyT
-----END PGP SIGNATURE-----
Merge tag 'riscv-dt-for-v6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/late
RISC-V Devicetrees for v6.9
Microchip:
Missing bus clocks for the CAN controllers spotted during the creation
of a driver for the controllers and a specific compatible for the SiFive
PDMA block on PolarFire SoC.
Starfive:
PWM nodes for the jh7100 and jh7110. Camera subsystem support for the
latter. Most notably however is the addition of ethernet support for the
jh7110 which finally allows people to use the network on the OG VisionFive
and on the Beagle-V Starlight board. This was made possible by the
non-standard cache management operations support added for the RZ/Five
which could be extended to the ccache present on the jh7100.
bindings:
Additional clarification for what the reg property represents for cpus
and two opencores PWM binding changes - the original addition and an
added compatible. The latter is here as the driver patch was not ready
but the PWM maintainer told me to go ahead and merge it.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-dt-for-v6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
riscv: dts: starfive: jh7110: Add camera subsystem nodes
dt-bindings: pwm: opencores: Add compatible for StarFive JH8100
dt-bindings: riscv: cpus: reg matches hart ID
riscv: dts: microchip: add specific compatible for mpfs pdma
riscv: dts: microchip: add missing CAN bus clocks
riscv: dts: starfive: beaglev-starlight: Setup phy reset gpio
riscv: dts: starfive: visionfive-v1: Setup ethernet phy
riscv: dts: starfive: jh7100-common: Setup pinmux and enable gmac
riscv: dts: starfive: jh7100: Add sysmain and gmac DT nodes
riscv: dts: starfive: jh7110: Add PWM node and pins configuration
riscv: dts: starfive: jh7100: Add PWM node and pins configuration
dt-bindings: pwm: Add bindings for OpenCores PWM Controller
Link: https://lore.kernel.org/r/20240305-iodine-moneywise-53797ae9bf6e@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This reduces the link speed of the PCIe bus with WiFi-card connected on the
Lenovo ThinkPad X13s and the Qualcomm Compute Reference Device, avoid
link errors and initialization issues reported by users.
It also reverts the enablement of MPM on MSM8996, which is reported to
prevent boards on this platform from booting for some users.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmXn3tYVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FoccP/3W+e1BQWPq6ux2c2yDScu7eH2SV
K/Rdrnszt9gbEZgFeXJIo9ZWfq0sOnuRcAgk9WJ8nmwTeV7zaIQRvIdmfJYexRDr
Vq/fDzthl4KgX6vTi2AAcAEjFGACEvFWrwXvllCOnStiPrtvg97JY7dFuCLu2RGQ
LhhqJYk6pkDlg/m2O2LKJTjVzLYaUaYYqmuMvWN6jfYZ0mYIHAIKfVcbRKXoutqE
TTKCRAS8LGBfQ7JIvDHS6Pmedh4fchGDsoOA1GxmbESBjabhKCliSWv/p0K4Yyi6
4fHU9XEhpyjp2jqqKP/pQIjxQwk8PyUCLACOMH8ODJkkcIxarAFdOrf6kGEFA7nh
J1yGTOZhZfM1Icsv/7VryRFjGykkCX+peFrIdl51zN9Hxb+2zMO7X/TZjjesZD5f
0olU0V/7K12wMpYkL9oXzqNff3nBe7vJDIqkZIT8ZA9gCe0ya9oCrG0JwyxgRxka
G8NZVW9QJpAMEDKiNgvM+GqYYFblxBM5w4kKr8traIBMZM7HlJyEoOvsC91M9YNv
EVepO7UEVD3VFbB3HeD6Qdu6ndChviv5Mj2wwqKAEvUH2w+ZknoC5UTNDvv0jxyU
RmYRVyQ9+Ng9wd8lWLRV81QH3L7rqTty7Gj+Xpp9jBLYXR6Qg3cO9hs3CRdoChUy
oRtwJCSctL0T7tLT
=RFVJ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXoDAEACgkQYKtH/8kJ
Uifk3BAAxfXhYwDb2fI7qQuP10WbDSkTFs4Y7l8xsn1K9gZYMESf2G2IXzBbo/42
xx00+U4KWlWxx9sFY5vEHRXuaPDdNAWEsW6ncUVnchGv1ilQd7Rho0O2DgHZtGY+
XrAAoC8ZbXI2CJYVUVPT303Tu8H48IMtmsWEZckgGfVdvak2o8nKB45QZsXRsamv
NsOVx8NEmFEeR7+By81c/SHBXpILvXqj7Nrw029/81o6NWSJowz8DCSMzXOX0byF
DusPKGoDlOA0C3QC5NcRLUK6XVlrCvxelUCEH5IWlKAkQkaDDAHQYxTE4EIIvK8a
KGqHyC/+5BjzT3PuuDCH15DJvg/scHQvIt/xchS4BbjheW2c7opMtZhWzSTN6INZ
/TQMwyKfUdbdGDxGIt7GPsLg12PmeDgmIlNYiL66u2JVQhaXIXa97l1ol9lKs1gw
B1VN/HgdkGP9XVev5xr4K1VyKIRJYV0+MEhnUpNRI591tPREy9mSJZXigncIou9e
8qvKKdMgdp8h5ErHehQyvu2yGxVp/v8ARMD5a4TRVNAx+97zftrxDEISt7EYgEDg
uZrBsbw0TOXsNJS5dxrGR7PvgYp9aEdBXxQReQSrHRd76nT1/kCgB28hShHz0VoX
u6EcZWHhNuHB6HS88nK4W2mEDuGWZCFXOb2yTlTM7pMlsNXcKkQ=
=OVcf
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-6.8-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
A few more Qualcomm Arm64 DeviceTree fixes for v6.8
This reduces the link speed of the PCIe bus with WiFi-card connected on the
Lenovo ThinkPad X13s and the Qualcomm Compute Reference Device, avoid
link errors and initialization issues reported by users.
It also reverts the enablement of MPM on MSM8996, which is reported to
prevent boards on this platform from booting for some users.
* tag 'qcom-arm64-fixes-for-6.8-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
Revert "arm64: dts: qcom: msm8996: Hook up MPM"
arm64: dts: qcom: sc8280xp-x13s: limit pcie4 link speed
arm64: dts: qcom: sc8280xp-crd: limit pcie4 link speed
Link: https://lore.kernel.org/r/20240306031208.4218-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Make use of the newly added callbacks:
- rate_limit_get()
- fast_switch_rate_limit()
to populate policies's `transition_delay_us`, defined as the
'Preferred average time interval between consecutive
invocations of the driver to set the frequency for this policy.'
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Arm SCMI spec. v3.2, s4.5.3.12 PERFORMANCE_DESCRIBE_FASTCHANNEL
defines a per-domain rate_limit for performance requests:
"""
Rate Limit in microseconds, indicating the minimum time
required between successive requests. A value of 0
indicates that this field is not applicable or supported
on the platform.
""""
The field is first defined in SCMI v2.0.
Add support to fetch this value and advertise it through
a fast_switch_rate_limit() callback.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Arm SCMI spec. v3.2, s4.5.3.4 PERFORMANCE_DOMAIN_ATTRIBUTES
defines a per-domain rate_limit for performance requests:
"""
Rate Limit in microseconds, indicating the minimum time
required between successive requests. A value of 0
indicates that this field is not supported by the
platform. This field does not apply to FastChannels.
""""
The field is first defined in SCMI v1.0.
Add support to fetch this value and advertise it through
a rate_limit_get() callback.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
The UEFI loads a lite variant of the ADSP firmware to support charging
use cases. The kernel needs to unload and reload it with the firmware
that has full feature support for audio. This patch arbitarily shutsdown
the lite firmware before loading the full firmware.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20240212-x1e80100-remoteproc-v2-3-604614367f38@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add support for PIL loading on ADSP and CDSP on X1E80100 SoCs.
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20240212-x1e80100-remoteproc-v2-2-604614367f38@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Document the aDSP and cDSP Peripheral Authentication Service on the
X1E80100 Platform.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20240212-x1e80100-remoteproc-v2-1-604614367f38@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
For loops with multiple initializers and increments are hard to read
and reason about, simplify this by using the looping index to index
into the hwspinlock array.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240208165114.63148-4-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
This will unregister the HW spinlock on module exit automatically for us,
currently we manually unregister which can be error-prone if not done in
the right order. This also allows us to remove the remove callback.
Do that here.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240208165114.63148-3-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
This disables runtime PM on module exit automatically for us, currently
we manually disable runtime PM which can be error-prone if not done
in the right order or missed in some exit path. This also allows us
to simplify the probe exit path and remove callbacks. Do that here.
While here, as we can now return right after registering our hwspinlock,
simply return directly and remove the extra debug message.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240208165114.63148-2-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
We do not use the OF node anymore, nor does it matter how
we got to probe, so remove the check for of_node.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240208165114.63148-1-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-7-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-6-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-5-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-4-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-3-afd@ti.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
dtschema package defines firmware-name as string-array, so individual
bindings should not make it a string but instead just narrow the number
of expected firmware file names.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240115182031.1610088-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
dtschema defines label as string, so $ref in other bindings is
redundant.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20240226122854.86197-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Correct indentation of several struct adsp_data instances to always use
a single TAB character instead of two.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20240304-qcom-pd-mapper-v3-4-6858fa1ac1c8@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
selftest harness uses various exit codes to signal test
results. Avoid calling exit() directly, otherwise tests
may get broken by harness refactoring (like the commit
under Fixes). SKIP() will instruct the harness that the
test shouldn't run, it used to not be the case, but that
has been fixed. So just return, no need to exit.
Note that for hmm-tests this actually changes the result
from pass to skip. Which seems fair, the test is skipped,
after all.
Reported-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/all/05f7bf89-04a5-4b65-bf59-c19456aeb1f0@sirena.org.uk
Fixes: a724707976 ("selftests: kselftest_harness: use KSFT_* exit codes")
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://lore.kernel.org/r/20240304233621.646054-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Oleksij Rempel says:
====================
net: ethernet: Rework EEE
with Andrew's permission I'll continue mainlining this patches:
==============================================================
Most MAC drivers get EEE wrong. The API to the PHY is not very
obvious, which is probably why. Rework the API, pushing most of the
EEE handling into phylib core, leaving the MAC drivers to just
enable/disable support for EEE in there change_link call back.
MAC drivers are now expect to indicate to phylib if they support
EEE. This will allow future patches to configure the PHY to advertise
no EEE link modes when EEE is not supported. The information could
also be used to enable SmartEEE if the PHY supports it.
With these changes, the uAPI configuration eee_enable becomes a global
on/off. tx-lpi must also be enabled before EEE is enabled. This fits
the discussion here:
https://lore.kernel.org/netdev/af880ce8-a7b8-138e-1ab9-8c89e662eecf@gmail.com/T/
This patchset puts in place all the infrastructure, and converts one
MAC driver to the new API. Following patchsets will convert other MAC
drivers, extend support into phylink, and when all MAC drivers are
converted to the new scheme, clean up some unneeded code.
====================
Link: https://lore.kernel.org/r/20240302195306.3207716-1-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The enabling/disabling of EEE in the MAC should happen as a result of
auto negotiation. So move the enable/disable into
fec_enet_adjust_link() which gets called by phylib when there is a
change in link status.
fec_enet_set_eee() now just stores away the LPI timer value.
Everything else is passed to phylib, so it can correctly setup the
PHY.
fec_enet_get_eee() relies on phylib doing most of the work,
the MAC driver just adds the LPI timer value.
Call phy_support_eee() if the quirk is present to indicate the MAC
actually supports EEE.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> (On iMX8MP debix)
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Wei Fang <wei.fang@nxp.com>
Link: https://lore.kernel.org/r/20240302195306.3207716-8-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
FEC is about to get its EEE code re-written. To allow this, move
fec_enet_eee_mode_set() before fec_enet_adjust_link() which will
need to call it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Wei Fang <wei.fang@nxp.com>
Link: https://lore.kernel.org/r/20240302195306.3207716-7-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In order for EEE to operate, both the MAC and the PHY need to support
it, similar to how pause works. With some exception - a number of PHYs
have SmartEEE or AutoGrEEEn support in order to provide some EEE-like
power savings with non-EEE capable MACs.
Copy the pause concept and add the call phy_support_eee() which the MAC
makes after connecting the PHY to indicate it supports EEE. phylib will
then advertise EEE when auto-neg is performed.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20240302195306.3207716-6-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MAC driver changes its EEE hardware configuration in its
adjust_link callback. This is called when auto-neg
completes. Disabling EEE via eee_enabled false will trigger an
autoneg, and as a result the adjust_link callback will be called with
phydev->enable_tx_lpi set to false. Similarly, eee_enabled set to true
and with a change of advertised link modes will result in a new
autoneg, and a call the adjust_link call.
If set_eee is called with only a change to tx_lpi_enabled which does
not trigger an auto-neg, it is necessary to call the adjust_link
callback so that the MAC is reconfigured to take this change into
account.
When setting phydev->enable_tx_lpi, take both eee_enabled and
tx_lpi_enabled into account, so the MAC drivers just needs to act on
phydev->enable_tx_lpi and not the whole EEE configuration.
The same check should be done for tx_lpi_timer too.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240302195306.3207716-5-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Have phylib keep track of the EEE configuration. This simplifies the
MAC drivers, in that they don't need to store it.
Future patches to phylib will also make use of this information to
further simplify the MAC drivers.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20240302195306.3207716-4-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
MAC drivers which support EEE need to know the results of the EEE
auto-neg in order to program the hardware to perform EEE or not. The
oddly named phy_init_eee() can be used to determine this, it returns 0
if EEE should be used, or a negative error code,
e.g. -EOPPROTONOTSUPPORT if the PHY does not support EEE or negotiate
resulted in it not being used.
However, many MAC drivers get this wrong. Add phydev->enable_tx_lpi
which indicates the result of the autoneg for EEE, including if EEE is
administratively disabled with ethtool. The MAC driver can then access
this in the same way as link speed and duplex in the adjust link
callback. If enable_tx_lpi is true, the MAC should send low power
indications and does not need to consider anything else with respect
to EEE.
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20240302195306.3207716-3-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add helpers that phylib and phylink can use to manage EEE configuration
and determine whether the MAC should be permitted to use LPI based on
that configuration.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20240302195306.3207716-2-o.rempel@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This bug was noticed while re-implementing parts of the kernel
driver in userspace using spidev. The goal was to enable some
of the errata workarounds that Microchip describes in their
errata sheet [1].
Both the errata sheet and the regular datasheet of e.g. the KSZ8795
imply that you need to do this for indirect register accesses:
- write a 16-bit value to a control register pair (this value
consists of the indirect register table, and the offset inside
the table)
- either read or write an 8-bit value from the data storage
register (indicated by REG_IND_BYTE in the kernel)
The current implementation has the order swapped. It can be
proven, by reading back some indirect register with known content
(the EEE register modified in ksz8_handle_global_errata() is one of
these), that this implementation does not work.
Private discussion with Oleksij Rempel of Pengutronix has revealed
that the workaround was apparantly never tested on actual hardware.
[1] https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/KSZ87xx-Errata-DS80000687C.pdf
Signed-off-by: Tobias Jakobi (Compleo) <tobias.jakobi.compleo@gmail.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Fixes: 7b6e6235b6 ("net: dsa: microchip: ksz8795: handle eee specif erratum")
Link: https://lore.kernel.org/r/20240304154135.161332-1-tobias.jakobi.compleo@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This function is used with the set_eee() ethtool operation. Certain
fields of struct ethtool_keee() are relevant only for the get_eee()
operation. In addition, in case of the ioctl interface, we have no
guarantee that userspace sends sane values in struct ethtool_eee.
Therefore explicitly ignore all fields not needed for set_eee().
This protects from drivers trying to use unchecked and unreliable
data, relying on specific userspace behavior.
Note: Such unsafe driver behavior has been found and fixed in the
tg3 driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/ad7ee11e-eb7a-4975-9122-547e13a161d8@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Older versions of GCC really want to know the full definition
of the type involved in rcu_assign_pointer().
struct dpll_pin is defined in a local header, net/core can't
reach it. Move all the netdev <> dpll code into dpll, where
the type is known. Otherwise we'd need multiple function calls
to jump between the compilation units.
This is the same problem the commit under fixes was trying to address,
but with rcu_assign_pointer() not rcu_dereference().
Some of the exports are not needed, networking core can't
be a module, we only need exports for the helpers used by
drivers.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/all/35a869c8-52e8-177-1d4d-e57578b99b6@linux-m68k.org/
Fixes: 640f41ed33 ("dpll: fix build failure due to rcu_dereference_check() on unknown type")
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240305013532.694866-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
While testing for places where zero-sized destinations were still showing
up in the kernel, sock_copy() and inet_reqsk_clone() were found, which
are using very specific memcpy() offsets for both avoiding a portion of
struct sock, and copying beyond the end of it (since struct sock is really
just a common header before the protocol-specific allocation). Instead
of trying to unravel this historical lack of container_of(), just switch
to unsafe_memcpy(), since that's effectively what was happening already
(memcpy() wasn't checking 0-sized destinations while the code base was
being converted away from fake flexible arrays).
Avoid the following false positive warning with future changes to
CONFIG_FORTIFY_SOURCE:
memcpy: detected field-spanning write (size 3068) of destination "&nsk->__sk_common.skc_dontcopy_end" at net/core/sock.c:2057 (size 0)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240304212928.make.772-kees@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Commit 3e2f544dd8 ("net: get stats64 if device if driver is
configured") moved the callback to dev_get_tstats64() to net core, so,
unless the driver is doing some custom stats collection, it does not
need to set .ndo_get_stats64.
Since this driver is now relying in NETDEV_PCPU_STAT_TSTATS, then, it
doesn't need to set the dev_get_tstats64() generic .ndo_get_stats64
function pointer.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://lore.kernel.org/r/20240304183810.1474883-2-leitao@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
With commit 34d21de99c ("net: Move {l,t,d}stats allocation to core and
convert veth & vrf"), stats allocation could be done on net core
instead of in this driver.
With this new approach, the driver doesn't have to bother with error
handling (allocation failure checking, making sure free happens in the
right spot, etc). This is core responsibility now.
Remove the allocation in the tun/tap driver and leverage the network
core allocation instead.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://lore.kernel.org/r/20240304183810.1474883-1-leitao@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of i915. So just remove the platform check
completely and keep the code simple.
v2: Add extra comment (review feedback from Rodrigo).
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240223202846.1532176-1-John.C.Harrison@Intel.com
Some CSR registers like CRMD/PRMD are saved during enter VM mode now.
However they are not restored for actual use, so saving for these CSR
registers can be removed.
Reviewed-by: Tianrui Zhao <zhaotianrui@loongson.cn>
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
LoongArch VCPUs have their own separate HW timers. SW timer is to wake
up blocked vcpu thread, rather than HW timer emulation. When blocking
vcpu scheduled out, SW timer is used to wakeup blocked vcpu thread and
injects timer interrupt. It does not care about whether guest timer is
in period mode or oneshot mode, and SW timer needs not to be restarted
since vcpu has been woken.
This patch does not restart SW timer when it is expired.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
SW timer is enabled when vcpu thread is scheduled out, and it is to wake
up vcpu from blocked queue. If vcpu thread is scheduled out but is not
blocked, such as it is preempted by other threads, it is not necessary
to enable SW timer. Since vcpu thread is still on running queue if it is
preempted and SW timer is only to wake up vcpu on blocking queue, so SW
timer is not useful in this situation.
This patch enables SW timer only when vcpu is scheduled out and is
blocking.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Supported CPUCFG information comes from function _kvm_get_cpucfg_mask().
A bit should be zero if it is reserved by HW or if it is not supported
by KVM.
Also LoongArch software page table walk feature defined in CPUCFG2_LSPW
is supported by KVM, it should be enabled by default.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Forcewakes are not required for communication with the GuC via CTB
as it is a memory based interfaced. Acquring forcewakes takes
considerable time. With that, do not grab a forcewake when issuing a
GGTT TLB invalidation via the GuC.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240229194520.200642-1-matthew.brost@intel.com
