Highlights:
---------
Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
register to the framework to offer firewall services such as access
granting.
This series of patches is a new approach on the previous STM32 system
bus, history is available here:
https://lore.kernel.org/lkml/20230127164040.1047583/
The need for such framework arises from the fact that there are now
multiple hardware firewalls implemented across multiple products.
Drivers are shared between different products, using the same code.
When it comes to firewalls, the purpose mostly stays the same: Protect
hardware resources. But the implementation differs, and there are
multiple types of firewalls: peripheral, memory, ...
Some hardware firewall controllers such as the RIFSC implemented on
STM32MP2x platforms may require to take ownership of a resource before
being able to use it, hence the requirement for firewall services to
take/release the ownership of such resources.
On the other hand, hardware firewall configurations are becoming
more and more complex. These mecanisms prevent platform crashes
or other firewall-related incoveniences by denying access to some
resources.
The stm32 firewall framework offers an API that is defined in
firewall controllers drivers to best fit the specificity of each
firewall.
For every peripherals protected by either the ETZPC or the RIFSC, the
firewall framework checks the firewall controlelr registers to see if
the peripheral's access is granted to the Linux kernel. If not, the
peripheral is configured as secure, the node is marked populated,
so that the driver is not probed for that device.
The firewall framework relies on the access-controller device tree
binding. It is used by peripherals to reference a domain access
controller. In this case a firewall controller. The bus uses the ID
referenced by the access-controller property to know where to look
in the firewall to get the security configuration for the peripheral.
This allows a device tree description rather than a hardcoded peripheral
table in the bus driver.
The STM32 ETZPC device is responsible for filtering accesses based on
security level, or co-processor isolation for any resource connected
to it.
The RIFSC is responsible for filtering accesses based on Compartment
ID / security level / privilege level for any resource connected to
it.
-----BEGIN PGP SIGNATURE-----
iQJRBAABCgA7FiEEctl9+nxzUSUqdELdf5rJavIecIUFAmYqUUkdHGFsZXhhbmRy
ZS50b3JndWVAZm9zcy5zdC5jb20ACgkQf5rJavIecIWolxAAqUHuLzXyrsCGfPG9
L5J8dUIeRk6lsQgO62EtS/hsUL5NhlwSiShtNilGw0t2TDCj0LpSMccwDjHoC1DE
9ks6aj0lO4dBl/d6fQm+4Vn85KiKfKYXW3J9w+6ZtG7pRly9jbmlrELqBIbL+MjU
/mmPdKM5y/l9KO6vxiua+EtDdd0pZksZLFtms23VoiFgkQ+2heoJ297QGfrWwxzv
UZg/UnWpQYB10dp93WL97vTdBZR4iUwEJNcip7xM65iBwSkuc9Y3gz0TZTO0ivZJ
BRsNc/9BJYEV3kNxRJGyf7JeufsaG3meHVxw9sOYi2hMe75pDAANYxvsCYt6NHjL
i+zugtcM5v//Ksw+HbD1rvRuhEWjFUotCeXJb+RaiY0Sy3HVlKG0WJm2Ybgzlbf+
vahskAHJxG0NFhPVpktQ/+gh8IU8Gy0PwyErdihhWKCiYBp8xHxW7IF7JtqlXQQS
KQ4r0Ez/fgGmLQqDobskE+OgaFIuI5QrjH7S/VvxYh0xxZOBK89EmxK7pO3fki0v
EFcTE/82HWfJo/bRCoq2Yzrh2omjR9ICsxDtVe4nILzjhaLChBz5lITyRO+/+Lr3
6u/oO09tlQYEK4YzH2Kw0xGtpY7Xfmm4wC+zDTRXKBM3Vp1IoTchHssLS4nZbScq
ZHJHRPMCX98FdVH3BLX7OSexJys=
=/Cu0
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYwAI4ACgkQYKtH/8kJ
UicByw//VzXycIdrOzZeInbrhs0D/7pmb31U1NaAwtK3Y90lxBi5AlB4MKUrM+oq
x/cxqmmW1RsBc2m1iEuJWkqXS+XJHGptHKAHUqVhI9bIuBZqmGddvcP93Ml9egcN
OL/Kd/OS4Q07EYc/Md6XrRBo2zJcHT57jGH8fKBmX4eAKfPYo7xgbq5k/0LoCq/i
cgfQdKeDsR6tTrHyJI0p/+EgS5uglUnIJBm1aLDk883UKH4/EQSR+dpvYsogBcbd
UnH78QeUymCOYzWylHJHeWFgDnn9NiJy/oCQx7wMc6PVUhcd0l1FXvM7XUeDy7iW
aNJpgYU8cTx9IYPGBbZJ13NX0+X4QACKpDjJZG90/y4Q4YEn5l/Di9rmv4HYhZgr
gwYD4EHewKB3PVtmCCUQpurSblshoo9bPWEaR3NFD1mSu46Jb11/zgIQ4oBagixV
MjiaaP3+Rpz1X0Zo5HSq9F0k4A/SddOo2zjMn3af/77nENsR3yEmPWgL20T+nv9P
deJ/LqE6mGVFI0c4E2K03Y85wldN6xXyhvCEqlHtK2X4l5JMe+0Vnak+VICZ0jQw
K/ihBRbifMH7g4GQUjpJUoUAvoyeSJ2jhMF8QV7bk76b6HeRFRYKOpQLnj29v/nd
MF2rKJwFYqJDF3d2a90I3E8c7huKnqWHQWinKu2Y2NkmH/tqtcI=
=mgY+
-----END PGP SIGNATURE-----
Merge tag 'stm32-bus-firewall-for-v6.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/drivers
STM32 Firewall bus for v6.10, round 1
Highlights:
---------
Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
register to the framework to offer firewall services such as access
granting.
This series of patches is a new approach on the previous STM32 system
bus, history is available here:
https://lore.kernel.org/lkml/20230127164040.1047583/
The need for such framework arises from the fact that there are now
multiple hardware firewalls implemented across multiple products.
Drivers are shared between different products, using the same code.
When it comes to firewalls, the purpose mostly stays the same: Protect
hardware resources. But the implementation differs, and there are
multiple types of firewalls: peripheral, memory, ...
Some hardware firewall controllers such as the RIFSC implemented on
STM32MP2x platforms may require to take ownership of a resource before
being able to use it, hence the requirement for firewall services to
take/release the ownership of such resources.
On the other hand, hardware firewall configurations are becoming
more and more complex. These mecanisms prevent platform crashes
or other firewall-related incoveniences by denying access to some
resources.
The stm32 firewall framework offers an API that is defined in
firewall controllers drivers to best fit the specificity of each
firewall.
For every peripherals protected by either the ETZPC or the RIFSC, the
firewall framework checks the firewall controlelr registers to see if
the peripheral's access is granted to the Linux kernel. If not, the
peripheral is configured as secure, the node is marked populated,
so that the driver is not probed for that device.
The firewall framework relies on the access-controller device tree
binding. It is used by peripherals to reference a domain access
controller. In this case a firewall controller. The bus uses the ID
referenced by the access-controller property to know where to look
in the firewall to get the security configuration for the peripheral.
This allows a device tree description rather than a hardcoded peripheral
table in the bus driver.
The STM32 ETZPC device is responsible for filtering accesses based on
security level, or co-processor isolation for any resource connected
to it.
The RIFSC is responsible for filtering accesses based on Compartment
ID / security level / privilege level for any resource connected to
it.
* tag 'stm32-bus-firewall-for-v6.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32:
bus: stm32_firewall: fix off by one in stm32_firewall_get_firewall()
bus: etzpc: introduce ETZPC firewall controller driver
bus: rifsc: introduce RIFSC firewall controller driver
of: property: fw_devlink: Add support for "access-controller"
firewall: introduce stm32_firewall framework
dt-bindings: bus: document ETZPC
dt-bindings: bus: document RIFSC
dt-bindings: treewide: add access-controllers description
dt-bindings: document generic access controllers
Link: https://lore.kernel.org/r/7dc64226-5429-4ab7-a8c8-6053b12e3cf5@foss.st.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Add the check for obtaining complete port attribute in the HCCS driver
- Replace MAILBOX dependency with PCC for the HCCS driver
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEQeMYD8qOQTc1R/snC8hXbtmJZlwFAmYpvTMVHHh1d2VpNUBo
aXNpbGljb24uY29tAAoJEAvIV27ZiWZcm5AP/0/9N7W48vsLHiWzFYUEbe0XK7DY
ELG83+NhZylWYnYeBj6nxlldvJrWA5dtH+5kfDfR+jllhEi14dLVSF3k7uJ9rNiP
J1NZrU9oO1BZHPv77/Grg+41+qP3FTCusUasch0OviBuexyf7XPnq5mVPYhX8cie
DEEC+X3S2NEFdCqh1C7y41ecjHkmawLbmpvQ1bnGumka8y8SdOd86JTwOOoxBHe7
xqrFh8CzRzCDQF4BKU3HLG54mUGTjrFlGsTmI4wHGOQnYFv0dzZn4NnaOLdpLJxm
lmxgLfkESsPhZ9yHwQmgX5MIWqkKeuwXiuM4Ecp1blvMkyM0Pma8BPHNdylZZdP7
AKEaAjFQrHodSUSHGTMD++PFg5uV3MgwOJTTwP8gz8edvJ9C0v2aPFZ4m7NGMZj7
Ums7kqAfix0EBI+dWQZkxrmKYSy6GOLp6u74iTWfRDf4kmbOKuyNdNYaIKkW0wdO
Dfl2rsYDqKeEDmw18FCIK+BU5TaUMYdN5JmME/+Ah5pnHWuVtB6uciswzBAFYn09
eYt1tW+aPxXIIqZJsmk/D8RGVnFcX+gXvWoD7Qia6xOFz6NQb+MCeGnCZgsORqvo
2tNJChIyPOxEO01NuW6pI5mxhK038zljXlU4luSCy7nE397GaIjcFpbV+9nQJL1o
CLSeIRM0kIRCsW5N
=hOU5
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYwADoACgkQYKtH/8kJ
UicshBAAhEmPzN+q5BDz8S5e/VAgSwor/mxtKbCWTev8Ema1OsrnDpE3KcX8ydOy
5q9u5vGyv8iOIeEzBzbue71uvjyHHv9ooi733fBftCkbh5DYM/LJ5VkJZ962p8bo
t9S6mpcyqkx7Dzl6+LHN40s7KOB2QUXgRL25uMF80niyrdt8UCGra5GXi03kwtEJ
tKhO+/frg2ibposOek+14tet5daE46nkAWuvKuXgC+lXYkzSrEdbuqNFAoHmz2kF
0/MAPbCUcMmIIPaT5zLd87TFrdFhPWxg0wipG0fdzl642Sxye/I0Saw7pSLAHp3i
eMuvhL5jhgeQRcJeOexPlunMJg4x6LBT9+vx/8dw0dJUt+Ujy1bzWh0NDFrols36
KAa/XZCr2/p41ohNtxu+x5y4Ii1JAfe8KKQojWD/kLt782tWyl3uGavNUj62JwS/
FxDXWcPZjX91uJ23qDQvoTLTAPIrnS8o9UE5PRO5JzsdVb99MQ4k9l5cUDYlQptW
Ju7oc+yE6C5O5s61YsOzeXRDWlya5/OWeeDPYvLZHwxajQirQJlT7ZsocFLxkD9w
AepfdxpgWbeHUo7NTaeY2vr+EN+x1eoBrIS1p2UlosKv0BeRQjUIZ9+ikkQNwFwk
2ChTqjJ69F0fovw8ocFa5ufbbi0YDM4V596gWLdUV/z61jT8GmI=
=ypb3
-----END PGP SIGNATURE-----
Merge tag 'hisi-drivers-for-6.10' of https://github.com/hisilicon/linux-hisi into soc/drivers
HiSilicon driver updates for v6.10
- Add the check for obtaining complete port attribute in the HCCS driver
- Replace MAILBOX dependency with PCC for the HCCS driver
* tag 'hisi-drivers-for-6.10' of https://github.com/hisilicon/linux-hisi:
soc: hisilicon: kunpeng_hccs: replace MAILBOX dependency with PCC
soc: hisilicon: kunpeng_hccs: Add the check for obtaining complete port attribute
Link: https://lore.kernel.org/r/662A3EDE.5070708@hisilicon.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Identify the new RZ/V2H (R9A09G057) SoC,
- Enable support for the TMU (Timer Unit) on R-Car Gen2 SoCs.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCZhj+tQAKCRCKwlD9ZEnx
cNkQAP0ZRtdqElbqYvGGHInhpabdkc2+EJQInXrpzP0xDAi8oAD/XHXbfYDv4kRX
sgplvCaUqUM2ORWp9qxTAohcL8+xvAM=
=rtx1
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYv/7wACgkQYKtH/8kJ
UidWqRAAgAkuBHaaPWQfVfuTHkdQf5+GD9rPSAgAM3Co0p1wtUYW50tut1k3fqmv
Qfr/X1rRtObozxcLH5upnWgkw3K4L6VXvKA+wZK+dPBPdWoeymMLOWRL0bCeBufI
f2aQ9Dpd67/xrZEWKO89Ezo/csX8MbpQxaDdkXPzj2MReuXAkZKqoa3zrbLnyZs+
fOKi0qAzaKaKreTDJZ00orip/v0GC83z9UVUppk4a2qIn9ggk0+ah48q1zufEMfG
oeae+XeBtZ7Wzt3D9zbcRiW9ZPQgZ8k3vB93tXjO88METMMNNx/6tvFOXf6LE/kK
fLAeXcrUOwQI/OzZwXWdQeCvexHAth6NU7nJ/sCBpIdP99ksGITp3KfksEONvCvP
UUIfiBWOPhj0C5oNdvxEwnIiCOhiVufcVTfz3e2+UsK84L941Xi/ZLaEV0VBSvtI
zwNTZAjKC/u1ewzwHkwEze8uhoHZ3QMlMnMV50SPmpwIzCihmy8up307z0Q2LBH1
dLMYljF2r38MZk3jezZ5B1CSyZyQPtuuLMsUdhA8BO+mTY31AwFkWHDTiI29TiyU
fsNnDNSDco641mH6IlrlbYA2iVlqCRLvu7/0RE4M7lmu1OEFIGASDqzfpZS9Y/r4
iYX1qiXFx3grKKXa+mabMwcgRTAe2489X3Yg3GDQgfJWPd5s7JE=
=7Fri
-----END PGP SIGNATURE-----
Merge tag 'renesas-drivers-for-v6.10-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/drivers
Renesas driver updates for v6.10
- Identify the new RZ/V2H (R9A09G057) SoC,
- Enable support for the TMU (Timer Unit) on R-Car Gen2 SoCs.
* tag 'renesas-drivers-for-v6.10-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
soc: renesas: Enable TMU support on R-Car Gen2
soc: renesas: Add identification support for RZ/V2H SoC
Link: https://lore.kernel.org/r/cover.1712915532.git.geert+renesas@glider.be
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Assign the pmu->dev parent to be the platform device for MMDC driver,
so that it doesn't appear directly under /sys/devices/.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmYuB6gUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM6AUAgAhnECenqTrSqCUFl5KxFlV37dXzAk
IU2s+B2KM5vG7zsaZrXUL9vs3Fo54gRT1nOcC1qj1LX/1L+QTdFM6/kM5WbQDATy
vu5TSmyXugukHWSY6FtmU3rl6hpXAmAc3M2ILZ5/xA8ZQiiuElJyXd5bg8SNwUpe
3T4Uxs3zmGsfCzf9KzBT3DxWh22g/b15wej/ttQK8f7U5rJoP/QxisRxx6Zc0LH3
xbyDJ4EsMK0KeyLVOFUln08PzATLZ7VaOhp7kZK4yaQ0ZqXZl7uoDhMfaz/Gk/iU
aSxg9BME42X7yqEX08l8DHzxNio3AJQU/Vu63JYe2tmCabq6bHaWUAT68g==
=4TmG
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYv/2cACgkQYKtH/8kJ
Uidugg/7BCO5QOUPj1tG525EqstP1w/oa0PE3enMuZxntb7uh7lrT5tqgSV3FFB5
i+Pwi+DqGOTDsZhohXOF7be0Co2h1Z9OAjQJ6gE1r/LCglXRkZgmLLhEtxrgjXYq
ebk9KA3MCxzxlwor7A7ojjBRWeDUKJS9whIxXGJpA3PyjubpnM4NZ9is7/tHc9Yk
k6SSaHo/IQXpzmg04z5bpBBJZJo47uwKT69Dwtxlcunsg7I7uzXkTbSu2dkB1azs
KGR/IcnQqt0PFSwM37zPAGCcpIW+Vq4XJD7f2eu2Yi0k2PL1JDLdSTpzbFvd3giF
NV5Iv/MwgsT5D0oQc/i23T25Io5Zfjyr9ZKzaPAVXmKVGHngGTrTDp+xCCHj5gcW
juHr5xd8AIgLA7lP4mhuHeHMyqZRslLkAY39LF6OQqcmuEeU1/HKclZOjw0Xa5mz
hZiGYCbdALFlJ3/X0fZcFbYostxmwoLwLm8Dbg7iix5nH8ggJ3lS6Eg5mphK0F7B
F3jZbRJWet0JgQLVreWA9OXPwejygJtm+4RR30vat00XssI+iHyR2m4lfr9X2Cm2
SLELFlPcyiebGDIkg0CcnLPmmwyQJSEadeBnRiQCpxirBzJBv1WbBXqI7aY7OeBH
Uvl1qPIKWXsTQoK+mzRIq6EmXT5PIGt4eDSHodtmHYnsaNmnOK8=
=7jI/
-----END PGP SIGNATURE-----
Merge tag 'imx-soc-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/arm
i.MX SoC changes for 6.10:
- Assign the pmu->dev parent to be the platform device for MMDC driver,
so that it doesn't appear directly under /sys/devices/.
* tag 'imx-soc-6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: imx: Assign parents for mmdc event_source devices
Link: https://lore.kernel.org/r/20240428121247.10370-1-shawnguo2@yeah.net
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTFp0I1jqZrAX+hPRXbK58LschIgwUCZi9+AAAKCRDbK58LschI
g0nEAP487m7L0nLVriC2oIOWsi29tklW3etm6DO7gmGRGIHgrgEAnMyV1xBj3bGj
v6jJwDcybCym1hLx+1x1JCZ4eoAFswE=
=xbna
-----END PGP SIGNATURE-----
Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
Daniel Borkmann says:
====================
pull-request: bpf-next 2024-04-29
We've added 147 non-merge commits during the last 32 day(s) which contain
a total of 158 files changed, 9400 insertions(+), 2213 deletions(-).
The main changes are:
1) Add an internal-only BPF per-CPU instruction for resolving per-CPU
memory addresses and implement support in x86 BPF JIT. This allows
inlining per-CPU array and hashmap lookups
and the bpf_get_smp_processor_id() helper, from Andrii Nakryiko.
2) Add BPF link support for sk_msg and sk_skb programs, from Yonghong Song.
3) Optimize x86 BPF JIT's emit_mov_imm64, and add support for various
atomics in bpf_arena which can be JITed as a single x86 instruction,
from Alexei Starovoitov.
4) Add support for passing mark with bpf_fib_lookup helper,
from Anton Protopopov.
5) Add a new bpf_wq API for deferring events and refactor sleepable
bpf_timer code to keep common code where possible,
from Benjamin Tissoires.
6) Fix BPF_PROG_TEST_RUN infra with regards to bpf_dummy_struct_ops programs
to check when NULL is passed for non-NULLable parameters,
from Eduard Zingerman.
7) Harden the BPF verifier's and/or/xor value tracking,
from Harishankar Vishwanathan.
8) Introduce crypto kfuncs to make BPF programs able to utilize the kernel
crypto subsystem, from Vadim Fedorenko.
9) Various improvements to the BPF instruction set standardization doc,
from Dave Thaler.
10) Extend libbpf APIs to partially consume items from the BPF ringbuffer,
from Andrea Righi.
11) Bigger batch of BPF selftests refactoring to use common network helpers
and to drop duplicate code, from Geliang Tang.
12) Support bpf_tail_call_static() helper for BPF programs with GCC 13,
from Jose E. Marchesi.
13) Add bpf_preempt_{disable,enable}() kfuncs in order to allow a BPF
program to have code sections where preemption is disabled,
from Kumar Kartikeya Dwivedi.
14) Allow invoking BPF kfuncs from BPF_PROG_TYPE_SYSCALL programs,
from David Vernet.
15) Extend the BPF verifier to allow different input maps for a given
bpf_for_each_map_elem() helper call in a BPF program, from Philo Lu.
16) Add support for PROBE_MEM32 and bpf_addr_space_cast instructions
for riscv64 and arm64 JITs to enable BPF Arena, from Puranjay Mohan.
17) Shut up a false-positive KMSAN splat in interpreter mode by unpoison
the stack memory, from Martin KaFai Lau.
18) Improve xsk selftest coverage with new tests on maximum and minimum
hardware ring size configurations, from Tushar Vyavahare.
19) Various ReST man pages fixes as well as documentation and bash completion
improvements for bpftool, from Rameez Rehman & Quentin Monnet.
20) Fix libbpf with regards to dumping subsequent char arrays,
from Quentin Deslandes.
* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (147 commits)
bpf, docs: Clarify PC use in instruction-set.rst
bpf_helpers.h: Define bpf_tail_call_static when building with GCC
bpf, docs: Add introduction for use in the ISA Internet Draft
selftests/bpf: extend BPF_SOCK_OPS_RTT_CB test for srtt and mrtt_us
bpf: add mrtt and srtt as BPF_SOCK_OPS_RTT_CB args
selftests/bpf: dummy_st_ops should reject 0 for non-nullable params
bpf: check bpf_dummy_struct_ops program params for test runs
selftests/bpf: do not pass NULL for non-nullable params in dummy_st_ops
selftests/bpf: adjust dummy_st_ops_success to detect additional error
bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable
selftests/bpf: Add ring_buffer__consume_n test.
bpf: Add bpf_guard_preempt() convenience macro
selftests: bpf: crypto: add benchmark for crypto functions
selftests: bpf: crypto skcipher algo selftests
bpf: crypto: add skcipher to bpf crypto
bpf: make common crypto API for TC/XDP programs
bpf: update the comment for BTF_FIELDS_MAX
selftests/bpf: Fix wq test.
selftests/bpf: Use make_sockaddr in test_sock_addr
selftests/bpf: Use connect_to_addr in test_sock_addr
...
====================
Link: https://lore.kernel.org/r/20240429131657.19423-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
As specified by the datasheet we should write the value 0x3 (enable
plus tracking gain) into the MU_CNT1 register during the MU lock phase.
Currently we were only setting the enable bit (bit 0) as the tracking
gain default value is already set to 1. While we should be mostly fine
in assuming the tracking gain will have the value it should, better to
explicitly write it. On top of that the datasheet also states to
re-attempt the writes in case the lock fails which we were not doing for
the tracking gain bit.
Lastly, the recommended value for the MU phase slope lock (bit 6) is 0
but for some reason the default value is 1 and hence, we were not
changing it accordingly.
Note there was no problem with the MU lock mechanism so this is not
being treated as a fix but rather an improvement.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240429-ad9739a-improv-v1-1-c076a06a697d@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_interruptible_timeout() causing patterns like:
timeout = wait_for_completion_interruptible_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20240429113313.68359-9-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_interruptible_timeout() causing patterns like:
timeout = wait_for_completion_interruptible_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20240429113313.68359-8-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_interruptible_timeout() causing patterns like:
timeout = wait_for_completion_interruptible_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20240429113313.68359-7-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_interruptible_timeout() causing patterns like:
timeout = wait_for_completion_interruptible_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20240429113313.68359-6-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_interruptible_timeout() causing patterns like:
timeout = wait_for_completion_interruptible_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20240429113313.68359-5-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_interruptible_timeout() causing patterns like:
timeout = wait_for_completion_interruptible_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20240429113313.68359-4-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_timeout() causing patterns like:
timeout = wait_for_completion_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/20240429113313.68359-3-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is a confusing pattern in the kernel to use a variable named 'timeout' to
store the result of wait_for_completion_timeout() causing patterns like:
timeout = wait_for_completion_timeout(...)
if (!timeout) return -ETIMEDOUT;
with all kinds of permutations. Use 'time_left' as a variable to make the code
self explaining.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240429113313.68359-2-wsa+renesas@sang-engineering.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The RESET GPIO pinmux should be part of MDIO bus node
so that they can be in the right state before the PHY
can be probed via MDIO bus scan.
The GPIO pin should be setup with PIN_INPUT so that
input circuitry is enabled in case software wants to
check pin status. Without this, incorrect status is shown
in /sys/kernel/debug/gpio.
Add GPIO reset for the Gigabit Ethernet PHY. As per
RTL8211F datasheet, reset assert width is 10ms and
PHY registers can be access accessed after 50ms of
reset deassert.
Fixes: f5a731f078 ("arm64: dts: ti: Add k3-am625-beagleplay")
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Link: https://lore.kernel.org/r/20240305-b4-for-v6-9-am65-beagleplay-ethernet-reset-v2-1-2bf463a7bf13@kernel.org
Signed-off-by: Nishanth Menon <nm@ti.com>
This loop definition removes the need for manual releasing of the
fwnode_handle in early exit paths (here an error path) allow
simplification of the code and reducing the chance of future
modifications not releasing fwnode_handle correctly.
Co-developed-by: Luiza Soezima <lbrsoezima@usp.br>
Signed-off-by: Luiza Soezima <lbrsoezima@usp.br>
Co-developed-by: Sabrina Araujo <sabrinaaraujo@usp.br>
Signed-off-by: Sabrina Araujo <sabrinaaraujo@usp.br>
Signed-off-by: Lincoln Yuji <lincolnyuji@usp.br>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20240429132233.6266-1-lincolnyuji@usp.br
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Ext4 security labels are enabled, as the expectation of setcap being
functional is widespread.
SC7280 display and GPU clock controllers are enabled, to make available
related functionality. The driver for the Novatek display panel found in
QCM6490 IDP is enabled. The X1E80100 sound card and reset-gpio drivers
are enabled to provide the necessary drivers for this. The regulator
driver providing VBUS power on a few different platforms is enabled.
ath12k is present on several recent platforms, so this is enabled as
well.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmYtJagVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FnZAP/05pEfWRALsYqXIRMOr/TJaEzDaK
C8vRDvEvKTWY3wjgha4U92UNeZrSHLoPAQYC2lQ6MKIGd7neYW3E3WfH5Jrn/vHt
VwUGTYUSzfuoKdHiYPzsPGXhIRvAXiHXF8PjVGniXiBC3u+ZTaxkug8/6MJFrTEI
977zoPux5UIu91pMY8fJUhmUsczkbPUocCAwEYTIApnz+w+GLtRmU6MW/IqoG8gG
/CVZz3/bNXl+dEJTyveqKDlrD676sA2xkIMYB0X97vPbO2zS7zX9DmopOpZd5sZK
064nwygE/XHMLuA7hTxyp/BcIHe3246kwDLGGNutNWPcBQZMdAyiL3iFBReagZND
NPibr8zvOy6h05XyIJjIZleoY3au+/3n75Kr23CF+VFroAQBXKS7sHdHa7CQz7XO
kHgkqVjFnfUR38OUtNja09tEQnsiQHpUO/zbulpu8vbD+XCmn0bgTBDGbufRex8y
mhhR0Pj4rVILSWa/V9nIqIOkCtkHBXrE5FaZ7ZcKyB+3oN3Pe/ki22MIu11d1oqd
RCVAdV8UiQN4yHIBx66EfemTmJuGJJkPqDvnZFTL/6E7ms4lHj2ASCRdxqTeoo1+
RWmJmP0jJmmTmMAZJBx1sO800YNSN3nDaZ8G8PO1iMYspHcyL/qcE90mgu/rS6Eo
8JVqOryu8ASj8Z+7
=Eliq
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmYv+88ACgkQYKtH/8kJ
UifBGBAArZrHB3HHCnegywQ8BMxKNAenFzAinI7Ax0iJqc5YwJijC2QABQyuKO2C
HMVQnIhjrNQEf5nD7ueav0Aa1swt4h9axaiQgO5VWTUnMvyxMSMIIRruibpXy9TO
yzEWlyZ3yeeVh2WLQwbtrxHBfay82aRTZyplB+qZtvD3xqA7p465IKpIiWBcH9te
LM/CqxpKu4xui0JYybZEYqQNNVhQArqjmqI4im+XTAMFKIuT3SQHtdQVT97kvw6s
GRB/douim1AwV5Adr1iSMv9mhaGlW0R9oZJ6oKXJa5KRHjTVZGYG66XBm4SuQsdd
/8dt1+phGhHqNEl8S7m4I0Yh8qWl94l+QsID4D2G0W49eI4diS34835CjxHENHRP
V20kO0Axxv/ISBSbDcytGFY6i8jq9xjplIoaf4Epj1d7MyodHXMWwfwWm50xWEBG
KiGljmlzxt/b9kxsW6adLgID+AEgxP03q8iBgeNnTTkfV/QIC7LM4KfXBz9qADgg
Dzj3yHNA3bIi9RzOsV0vzUSSUAPAEYD1n42H99dtgylg12v4Oz0Z9bTF+HjmCDsW
N5LktcLwooNUo4LgV+L0bqAeaq6FfESs0RRRxPcfTM9yjt5TByOvFTe0VVZ8xEFd
NXMhxjWKgMH+CNNJKbCCc3mO4/JMaH6yQ48g4pSulNw+ACVNdUs=
=CgrU
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/defconfig
Qualcomm Arm64 Defconfig updates for v6.10
Ext4 security labels are enabled, as the expectation of setcap being
functional is widespread.
SC7280 display and GPU clock controllers are enabled, to make available
related functionality. The driver for the Novatek display panel found in
QCM6490 IDP is enabled. The X1E80100 sound card and reset-gpio drivers
are enabled to provide the necessary drivers for this. The regulator
driver providing VBUS power on a few different platforms is enabled.
ath12k is present on several recent platforms, so this is enabled as
well.
* tag 'qcom-arm64-defconfig-for-6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: enable REGULATOR_QCOM_USB_VBUS
arm64: defconfig: enable ext4 security labels
arm64: defconfig: qcom: enable X1E80100 sound card
arm64: defconfig: build ath12k as a module
arm64: defconfig: Enable sc7280 display and gpu clock controllers
arm64: defconfig: enable reset-gpio driver as module
arm64: defconfig: enable Novatek NT36672E DSI Panel driver
Link: https://lore.kernel.org/r/20240427162037.1431822-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Octal permissions are preferred over the symbolics ones
for readbility. This ceases warning message pointed by checkpatch.
Co-developed-by: Bruna Lopes <brunaafl@usp.br>
Signed-off-by: Bruna Lopes <brunaafl@usp.br>
Signed-off-by: Gustavo Rodrigues <ogustavo@usp.br>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240428194326.2836387-4-ogustavo@usp.br
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add a blank line before if statement to avoid warning messages pointed by
checkpatch.
Co-developed-by: Bruna Lopes <brunaafl@usp.br>
Signed-off-by: Bruna Lopes <brunaafl@usp.br>
Signed-off-by: Gustavo Rodrigues <ogustavo@usp.br>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240428194326.2836387-3-ogustavo@usp.br
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Prefer 'unsigned int' instead of bare use of 'unsigned' declarations to
to improve code readbility. This ceases one of the warning messages
pointed by checkpatch.
Co-developed-by: Bruna Lopes <brunaafl@usp.br>
Signed-off-by: Bruna Lopes <brunaafl@usp.br>
Signed-off-by: Gustavo Rodrigues <ogustavo@usp.br>
Reviewed-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240428194326.2836387-2-ogustavo@usp.br
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Switching to the _scoped() version removes the need for manual
calling of fwnode_handle_put() in the paths where the code
exits the loop early. In this case that's all in error paths.
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Reviewed-by: Marius Cristea <marius.cristea@microchip.com>
Link: https://lore.kernel.org/r/20240428174020.1832825-2-jic23@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Drop the @selector from the kernel code, data, and TSS builders and
instead hardcode the respective selector in the helper. Accepting a
selector but not a base makes the selector useless, e.g. the data helper
can't create per-vCPU for FS or GS, and so loading GS with KERNEL_DS is
the only logical choice.
And for code and TSS, there is no known reason to ever want multiple
segments, e.g. there are zero plans to support 32-bit kernel code (and
again, that would require more than just the selector).
If KVM selftests ever do add support for per-vCPU segments, it'd arguably
be more readable to add a dedicated helper for building/setting the
per-vCPU segment, and move the common data segment code to an inner
helper.
Lastly, hardcoding the selector reduces the probability of setting the
wrong selector in the vCPU versus what was created by the VM in the GDT.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-19-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Initialize x86's various segments in the GDT during creation of relevant
VMs instead of waiting until vCPUs come along. Re-installing the segments
for every vCPU is both wasteful and confusing, as is installing KERNEL_DS
multiple times; NOT installing KERNEL_DS for GS is icing on the cake.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-18-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Add a proper #define for the TSS selector instead of open coding 0x18 and
hoping future developers don't use that selector for something else.
Opportunistically rename the code and data selector macros to shorten the
names, align the naming with the kernel's scheme, and capture that they
are *kernel* segments.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-17-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Allocate x86's per-VM TSS at creation of a non-barebones VM. Like the
GDT, the TSS is needed to actually run vCPUs, i.e. every non-barebones VM
is all but guaranteed to allocate the TSS sooner or later.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-16-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Now that the per-VM, on-demand allocation logic in kvm_setup_gdt() and
vcpu_init_descriptor_tables() is gone, fold them into vcpu_init_sregs().
Note, both kvm_setup_gdt() and vcpu_init_descriptor_tables() configured the
GDT, which is why it looks like kvm_setup_gdt() disappears.
Opportunistically delete the pointless zeroing of the IDT limit (it was
being unconditionally overwritten by vcpu_init_descriptor_tables()).
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-15-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Replace the switch statement on vm->mode in x86's vcpu_init_sregs()'s with
a simple assert that the VM has a 48-bit virtual address space. A switch
statement is both overkill and misleading, as the existing code incorrectly
implies that VMs with LA57 would need different to configuration for the
LDT, TSS, and flat segments. In all likelihood, the only difference that
would be needed for selftests is CR4.LA57 itself.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-14-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Allocate the GDT during creation of non-barebones VMs instead of waiting
until the first vCPU is created, as the whole point of non-barebones VMs
is to be able to run vCPUs, i.e. the GDT is going to get allocated no
matter what.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-13-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Map x86's exception handlers at VM creation, not vCPU setup, as the
mapping is per-VM, i.e. doesn't need to be (re)done for every vCPU.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-12-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Initialize the IDT and exception handlers for all non-barebones VMs and
vCPUs on x86. Forcing tests to manually configure the IDT just to save
8KiB of memory is a terrible tradeoff, and also leads to weird tests
(multiple tests have deliberately relied on shutdown to indicate success),
and hard-to-debug failures, e.g. instead of a precise unexpected exception
failure, tests see only shutdown.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-11-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Rename vcpu_setup() to be more descriptive and precise, there is a whole
lot of "setup" that is done for a vCPU that isn't in said helper.
No functional change intended.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-10-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Move x86's various descriptor table helpers in processor.c up above
kvm_arch_vm_post_create() and vcpu_setup() so that the helpers can be
made static and invoked from the aforementioned functions.
No functional change intended.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-9-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Explicitly clobber the guest IDT in the "delete memslot" test, which
expects the deleted memslot to result in either a KVM emulation error, or
a triple fault shutdown. A future change to the core selftests library
will configuring the guest IDT and exception handlers by default, i.e.
will install a guest #PF handler and put the guest into an infinite #NPF
loop (the guest hits a !PRESENT SPTE when trying to vector a #PF, and KVM
reinjects the #PF without fixing the #NPF, because there is no memslot).
Note, it's not clear whether or not KVM's behavior is reasonable in this
case, e.g. arguably KVM should try (and fail) to emulate in response to
the #NPF. But barring a goofy/broken userspace, this scenario will likely
never happen in practice. Punt the KVM investigation to the future.
Link: https://lore.kernel.org/r/20240314232637.2538648-8-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Rework platform_info_test to actually handle and verify the expected #GP
on RDMSR when the associated KVM capability is disabled. Currently, the
test _deliberately_ doesn't handle the #GP, and instead lets it escalated
to a triple fault shutdown.
In addition to verifying that KVM generates the correct fault, handling
the #GP will be necessary (without even more shenanigans) when a future
change to the core KVM selftests library configures the IDT and exception
handlers by default (the test subtly relies on the IDT limit being '0').
Link: https://lore.kernel.org/r/20240314232637.2538648-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
As a first step toward gracefully handling the expected #GP on RDMSR in
platform_info_test, move the test's assert on the non-faulting RDMSR
result into the guest itself. This will allow using a unified flow for
the host userspace side of things.
Link: https://lore.kernel.org/r/20240314232637.2538648-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Fix an off-by-one bug in the initialization of the GDT limit, which as
defined in the SDM is inclusive, not exclusive.
Note, vcpu_init_descriptor_tables() gets the limit correct, it's only
vcpu_setup() that is broken, i.e. only tests that _don't_ invoke
vcpu_init_descriptor_tables() can have problems. And the fact that KVM
effectively initializes the GDT twice will be cleaned up in the near
future.
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
[sean: rewrite changelog]
Link: https://lore.kernel.org/r/20240314232637.2538648-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Now that kvm_vm_arch exists, move the GDT, IDT, and TSS fields to x86's
implementation, as the structures are firmly x86-only.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Move the base types unique to KVM selftests out of kvm_util.h and into a
new header, kvm_util_types.h. This will allow kvm_util_arch.h, i.e. core
arch headers, to reference common types, e.g. vm_vaddr_t and vm_paddr_t.
No functional change intended.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Effectively revert the movement of code from kvm_util.h => kvm_util_base.h,
as the TL;DR of the justification for the move was to avoid #idefs and/or
circular dependencies between what ended up being ucall_common.h and what
was (and now again, is), kvm_util.h.
But avoiding #ifdef and circular includes is trivial: don't do that. The
cost of removing kvm_util_base.h is a few extra includes of ucall_common.h,
but that cost is practically nothing. On the other hand, having a "base"
version of a header that is really just the header itself is confusing,
and makes it weird/hard to choose names for headers that actually are
"base" headers, e.g. to hold core KVM selftests typedefs.
For all intents and purposes, this reverts commit
7d9a662ed9.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://lore.kernel.org/r/20240314232637.2538648-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
To make sure that we have the best timings on the serial data interface
we should calibrate it. This means going through the device supported
values and see for which ones we get a successful result. To do that, we
use a prbs test pattern both in the IIO backend and in the frontend
devices. Then for each of the test points we see if there are any
errors. Note that the backend is responsible to look for those errors.
As calibrating the interface also requires that the data format is disabled
(the one thing being done in ad9467_setup()), ad9467_setup() was removed
and configuring the data fomat is now part of the calibration process.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-7-6361fc3ba1cc@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Implement the new IIO backend APIs for calibrating the data
digital interfaces.
While at it, removed the tabs in 'struct adi_axi_adc_state' and used
spaces for the members.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-6-6361fc3ba1cc@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
In one of the following patches, we'll have some new functionality that
requires reads/writes on registers bigger than 0x8000. Hence, as this is
an highly flexible core, don't bother in setting 'max_register' and
remove it from regmap_config.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-5-6361fc3ba1cc@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is in preparation for supporting interface tuning in one for the
devices using the axi-adc backend. The new added interfaces are all
needed for that calibration:
* iio_backend_test_pattern_set();
* iio_backend_chan_status();
* iio_backend_iodelay_set();
* iio_backend_data_sample_trigger().
Interface tuning is the process of going through a set of known points
(typically by the frontend), change some clk or data delays (or both)
and send/receive some known signal (so called test patterns in this
change). The receiving end (either frontend or the backend) is
responsible for validating the signal and see if it's good or not. The
goal for all of this is to come up with ideal delays at the data
interface level so we can have a proper, more reliable data transfer.
Also note that for some devices we can change the sampling rate
(which typically means changing some reference clock) and that can
affect the data interface. In that case, it's import to run the tuning
algorithm again as the values we had before may no longer be the best (or
even valid) ones.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-2-6361fc3ba1cc@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Using tabs and maintaining the start of the docs aligned is a pain and
may lead to lot's of unrelated changes when adding new members. Hence,
let#s change things now and just have a simple space after the member
name.
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-1-6361fc3ba1cc@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We can only access the IP core registers if the bus clock is enabled. As
such we need to get and enable it and not rely on anyone else to do it.
Note this clock is a very fundamental one that is typically enabled
pretty early during boot. Independently of that, we should really rely on
it to be enabled.
Fixes: ef04070692 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-4-6361fc3ba1cc@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add a required clock property as we can't access the device registers if
the AXI bus clock is not properly enabled.
Note this clock is a very fundamental one that is typically enabled
pretty early during boot. Independently of that, we should really rely on
it to be enabled.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Fixes: 96553a44e9 ("dt-bindings: iio: adc: add bindings doc for AXI ADC driver")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-3-6361fc3ba1cc@analog.com
Cc: <Stable@ver.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
