This function does not build on 32-bit targets when the compiler
fails to reduce DIV_ROUND_UP() into a shift:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by xe_migrate.c
>>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive vmlinux.a
There are two instances in this function. Change the first to
use an open-coded shift with the same behavior, and the second
one to a 32-bit calculation, which is sufficient here as the size
is never more than 2^32 pages (16TB).
Fixes: 237412e453 ("drm/xe: Enable 32bits build")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226124736.1272949-3-arnd@kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 1408784b59)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
When the driver is built-in but the tests are in loadable modules,
the helpers don't actually get put into the driver:
ERROR: modpost: "xe_kunit_helper_alloc_xe_device" [drivers/gpu/drm/xe/tests/xe_test.ko] undefined!
Change the Makefile to ensure they are always part of the driver
even when the rest of the kunit tests are in loadable modules.
Fixes: 5095d13d75 ("drm/xe/kunit: Define helper functions to allocate fake xe device")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226124736.1272949-1-arnd@kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 0e6fec6da2)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
This contains two fixes to make the MGBE Ethernet devices found on
Tegra234 work properly.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmXY2ekACgkQ3SOs138+
s6GI7xAAmXPB8boojnCr+WQmh6L1akDS8qHicDS7frL/ySf7quZ0mxM8lYwn2DEh
fGl62amo3s8Qqm+IRcMw/H4gA51U7XSOglxpxpY3KpgghysQgxuSJ7NbYZYLaUyn
dnr3dLvesEbChJGgcOHTBKo75oa2gd0tWST69csNMZbp1FKUHq4DeF77j3NBLeYb
9UIZ1rXSo9VqKNBKrlPwaNdTWVoC4xOmIVkGLvJNlIuNN1+IfhZyxRNuHWoWp6Co
vWDqrAoIIYWfzNWeizm7unvWepRZfLx6fKBlLghifpQ7aRvcJeOKcSXDe8wW7Qz4
sWCtCHnNjuCnGD6UVyUY8MaYx3P3og1/vt8ywLa8MJblYQ6ki/RAsIyXdxJea3ZD
A1r6UEypDtj14WKHhIFvluMSxBlPDHFYU8cyBGXcE4EqKYZwXSpU6TMiyrVz86Iw
PEoBIj9wvRxaf5LdEYccuGZj+z8awC0syS0uDHVN1oa2KZASgKJrhyrQQHzI0t7F
n6tiBh7xaDIHhyCCmLZiqwHf9zBEjiA1a4sZBFcQGTuXwoaePGb9DO8vwSkRNQa2
2GjWaPbfvOFhznOE+6bn6gEa9ymkQLATPnaM7ENiLfnsIFeF1zpG/MSoR+eK/Img
sq4r8+dHwkZpC8iVQv6ix1X9fk8XizKeNiG4iuABPmdX/+bf+Os=
=b7sU
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXl2c0ACgkQYKtH/8kJ
UidOrw//WAoCu3ExvDZRQYD8JpiIuQ7kv35ABz83TeM8xcLCvxJMxEs9+h8BthRA
vrRpLh2clYD42xixQisD2ac4fxHvHgzssbuvlbj+lzE+TTKy3j5MAv/7OiR94GCy
yu2VSBd3ST45lN9XPnxN+R2fwP1rdn2ByfKrODUB0gCgbG6cCNVh+Ba3mbABwbN2
RaJ6eEH15bqZ/BKtuCpIPkf0M4AzSLRY4cjLKm6cOPGe2J515vUn9/1gqUDlXZyB
4lsiGwlpDJTey6szHxqzPFPMb+nLQJK7GM5tVq3s24DoJ2XFD6mhJSrpa5PYAVdB
5DF68fBNar+Oas9TYE3KOIVy6M1wat1ga5zaQIMwXmQHeHnyv32Gt4iEVGF6AUBC
v69Mj/VJ8NMGUTLd5S9tQ6ZQcl1TUC0SMHaavyVfbWxcIJ94u1sz5vheU0JGBcMW
DHsvVCZerv2q7IjhZ+DT0xyW6jCsWwqvmi0pj+3X+MiWt5k3tiK41HOCriX/IAwk
dYhwwMH+FbZTjoROG7UVc9I2SRGg6XP1FQ7/CCYidPoDcajii9UvaiVgXxQtzyEe
F3UahafQ5xMO0YLrDjgTp9Y/JscRbW0tI9LEQDx6QH3YAVmGR302jnWtNVA8SRoL
Mgs4lGKa45GuyvPbp7ToW/WjI2F0xtV33PmH0oU8vTbJqyyzJ5U=
=Ad8s
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-6.8-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
arm64: tegra: Device tree fixes for v6.8
This contains two fixes to make the MGBE Ethernet devices found on
Tegra234 work properly.
* tag 'tegra-for-6.8-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Fix Tegra234 MGBE power-domains
arm64: tegra: Set the correct PHY mode for MGBE
Link: https://lore.kernel.org/r/20240226144536.1525704-1-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Update MAINTAINERS to use a public mailing list for NXP i.MX
development.
- Re-enable CONFIG_BACKLIGHT_CLASS_DEVICE in imx_v6_v7_defconfig to fix
a backlight regression.
- Remove DSI port endpoints from i.MX7 SoC DTSI to fix a display
regression.
- Fix LDB clocks property for i.MX8MP device tree.
- Fix TC9595 reset GPIO on DH i.MX8M Plus DHCOM SoM.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmXbTckUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM78BQf9GRuY8jwenOGOoUFksUJrZzl6a/nl
glYzNyq4t4i91xDE9rU+GtoQe+DjWgKYftiR2pgHNv/uCKIPO+6D4yfLG/eyQet9
Z1kknUg6kUndiOaWaZ3FiiY3JUoUWHjaXw2REY8ksyVpRQ2fVtSOI2IeFtqIqFuQ
X1Fx7slntIcbGpbc3iGzZVTi7+ucShYjaVUWUd588iayQsXyHLqz/RxYRVlaErYF
BElc5Nm+Auw+8Mr+jz2Q71dn+qOI806V+IvqrTGX8PauCk9WsF/TsYcm6MzrhgKh
4N+NNpqLY11Ty9i+K6OS6qE77jVZ9xxe2UUk0qfa8xWujIGFlLpl3e8q8A==
=0xer
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXl2ZwACgkQYKtH/8kJ
UietfhAAgm1N4FQRIeWC38uzbR/MN4O29zXEOPNdAYnUdwB8r5gizrViFzsss8al
EnHDkYzm3k1dnWyRw/gF1BWXLF2lUim2d9ohjYUD3i/HjmLFN4W8vyz0eKUtZrDb
WAM7Bz9J5QKM+jsi93nXbWznoNArUKjIltwveka0VAS1Mn1HEgcY27as5rPzH3qV
iWykR6eOMbpCaVQAS1dAt6woa8kvyJGvxnHNtpE/Ac+KeZXjCjHulY7/RK7ZpeHM
JtufwjzmBltJ3a6G1vergUsH4FIGMJNMBCEKq9cWrSz1gxov1FxOTiokzCp7pQd/
p8q5xU7NNe0kLosXTxIW2j8rYarQVHy0EaiqwzNi3rwvLBucTc9bbB/B4eEiG6Nm
HB75/FMu54Xbt/Nt7ov+mgpD62ZjMpypyxsRoiffse170RyyiIqoQvWtSSQML/ef
E0jnv7P+4/Dh9/NxM1I5+RXlfz8b3v8bA5AxINwpiEXYPnNwRX5gxFFF/qQwLVD5
P3botb12Ly0gnJBCc84d+G4/BYlrzG/ktNIPlih6XaDXdnzjQkDpRnHAWWKYAeBp
WwiIu5mL+CHlplYlwgep2tBkZeoSJCVUih32YxKeJRYFCmJcufaGvOIO3FcpostE
1zCnF58PDk6J4XApjx+2oihRoIwmJ1gQ/9FswzNBMT76H49csIg=
=3Eab
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.8, round 2:
- Update MAINTAINERS to use a public mailing list for NXP i.MX
development.
- Re-enable CONFIG_BACKLIGHT_CLASS_DEVICE in imx_v6_v7_defconfig to fix
a backlight regression.
- Remove DSI port endpoints from i.MX7 SoC DTSI to fix a display
regression.
- Fix LDB clocks property for i.MX8MP device tree.
- Fix TC9595 reset GPIO on DH i.MX8M Plus DHCOM SoM.
* tag 'imx-fixes-6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: imx8mp: Fix LDB clocks property
arm64: dts: imx8mp: Fix TC9595 reset GPIO on DH i.MX8M Plus DHCOM SoM
MAINTAINERS: Use a proper mailinglist for NXP i.MX development
ARM: dts: imx7: remove DSI port endpoints
ARM: imx_v6_v7_defconfig: Restore CONFIG_BACKLIGHT_CLASS_DEVICE
Link: https://lore.kernel.org/r/ZdtPJzdenRybI+Bq@dragon
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This marks an additional GPIO as protected on SM8650 devices, to avoid
a system reset caused by a security violation with some firmware
versions.
It also adds the missing interconnect-names, which resolves a regression
where one of the I2C busses on SM6115 devices would no longer probe in
Linux.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmXaqtsVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FztYP/0zH8fB4JBYTxsPwO7/ZYuwPgWuF
HjfNIfmNyPq87u2GV3BXtTGIXNBZIJeC6gW9HJWYj67OaCJHWebZqwXbSFTveDr8
G60OwT4vO5SoEFgDv+y1Q5xlWZ1eurzplu/shH1J+aGzj3RSoBsZ/8wcmEszVQ8x
FO0pkPyrQY8I2kEfyYyAM1Q1rQe4STESP1ijEcZBFKdRRxQIyR/nxdz8V22wbmrf
kImpzCGX+IJj0Lu3klvsKwZVBLfksOiijRXDzangpoEW/Lnwjk2AWWYGNm/J3vCx
cfplkWVLGydPmNsoMlCghGA3Qq17lmD8nlXJLOVk14wa/urf4J6gZ03lu8vS9k/A
bAetQCqrPHq7FsGspxR/uZXjF2/9Zk2w+J7ASuhpu3cbssCJT7upBP7kexc2mjPv
ASgPpxtFhIdRoqNhQ/6dB/LTxIc0qv7OXKuXtqz0TpSiOtF2vGBpCjInAsmfNfWH
sSgJ8FtX6Iov4q7QWEt5zn4bdM4kRjaOipe98qGzSXW+BLVQm8ALx/G4WKemTS6i
+hIt5MJExhrvrNsbknCwvEAzBwmxO456N6vwMbgXJBdED/JtVDbCcgVjiq65ityZ
PY8gakw9u5oIvBTYWrRdVm9SJe/LBWxhIYNuWpSEuJh8tW6k4DH5oghxisKC7xt7
QzAjQhR9Aa7OUn6V
=XtCr
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXl2W4ACgkQYKtH/8kJ
UidKTg//eshErspYoVmC9lMU+8vdrDD0rYdGX21OM7aHBMhp1iy5bbprQ7/BEfST
i7s83FzgpcTxes8FltEQW6u/uev/WrLCfQ77MF2aI/RC8awkMmKRSVjOjMedl/3C
aCrtIQJI8bMY4x9fLJPnSVG523wf5ekVWXiH6j4lY7zWGbecS0B4eL2vYC/RWXVT
WiF2g6/IUjxkYXk8mAxEbUA5SL1m92zjwUc39jRJQrVmVTb/zoVJr5rEIdXZ/El+
9/CK56Vg75ajGWQNwt2APyQR65NxH1nIgktYwiz9HcBK47fifnM8lpD0709HvT7c
8V8hZ0Tn7q2NbfCM3eCn2IoRgSFYPPtHFw3B/TakTW3ZxQUYYkdRyixNiulaAOkJ
sjcDuxYhQ2CsnAfhgblXd06Oqd/GlMTUFOyGxsydnWY73san2L3eWchczzAHSVoH
/IiiW0Q0QGiL0RjUDGvppxfBC7kzOWgfABp2jWPkwHU1yaVfNsLrUgh+EsDevS3m
C+d9/kYVVjgu1hTQGgTXPVMPVeDt1Weyuv6sYIlf6KnNchMXOFJfYzTXgYwxBtaU
CsAC23HSBV3EkuuRte3cbGrvyLTJsMOBEQ98zNHCa0Y9yVkdY5zWqDpi6qizX1KJ
si2Py/LwK68a+WdljcP05K/vMuqxNN7oV5w8DSSxC0O881Y6AAE=
=30J9
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM64 DeviceTree fixes for 6.8
This marks an additional GPIO as protected on SM8650 devices, to avoid
a system reset caused by a security violation with some firmware
versions.
It also adds the missing interconnect-names, which resolves a regression
where one of the I2C busses on SM6115 devices would no longer probe in
Linux.
* tag 'qcom-arm64-fixes-for-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: sm6115: Fix missing interconnect-names
arm64: dts: qcom: sm8650-mtp: add gpio74 as reserved gpio
arm64: dts: qcom: sm8650-qrd: add gpio74 as reserved gpio
Link: https://lore.kernel.org/r/20240225025205.479589-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
StarFive StarLink PMU support monitoring L3 memory system PMU events.
Add documentation to describe StarFive StarLink PMU support and it's
usage.
Signed-off-by: Ji Sheng Teoh <jisheng.teoh@starfivetech.com>
Link: https://lore.kernel.org/r/20240229072720.3987876-4-jisheng.teoh@starfivetech.com
Signed-off-by: Will Deacon <will@kernel.org>
One of the "port" and "bdf" target filter interface must be set, and
the related events should preferably used in the same group.
Update the usage in the documentation.
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-9-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
The function xxx_find_related_event() scan all working events to find
related events. During this process, we also can find the idle counters.
If not found related events, return the first idle counter to simplify
the code.
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-8-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
If we use two events with the same filter and related event type
(see the following example), the driver check whether they are related
events and are in the same group, otherwise the function
hisi_pcie_pmu_find_related_event() return -EINVAL, then the 2nd event
cannot count but the 1st event is running, although the PCIe PMU has
other idle counters.
In this case, The perf event scheduler will make the two events to
multiplex a counter, if the user use the formula
(1st event_value / 2nd event_value) to calculate the bandwidth, he/she
won't get the correct value, because they are not counting at the
same period.
This patch tries to fix this by making the related events to use
different idle counters if they are not in the same event group.
And finally, I'm going to say. The related events are best used in the
same group [1]. There are two ways to know if they are related events.
a) By event name, such as the latency events "xxx_latency, xxx_cnt" or
bandwidth events "xxx_flux, xxx_time".
b) By event type, such as "event=0xXXXX, event=0x1XXXX".
Use group to count the related events:
[1] -e "{pmu_name/xxx_latency,port=1/,pmu_name/xxx_cnt,port=1/}"
example:
1st event: hisi_pcie0_core1/event=0x804,port=1
2nd event: hisi_pcie0_core1/event=0x10804,port=1
test cmd:
perf stat -e hisi_pcie0_core1/event=0x804,port=1/ \
-e hisi_pcie0_core1/event=0x10804,port=1/
before patch:
25,281 hisi_pcie0_core1/event=0x804,port=1/ (49.91%)
470,598 hisi_pcie0_core1/event=0x10804,port=1/ (50.09%)
after patch:
24,147 hisi_pcie0_core1/event=0x804,port=1/
474,558 hisi_pcie0_core1/event=0x10804,port=1/
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huwei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-7-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
The PMU can monitor traffic of certain target Root Port or downstream
target Endpoint. User can specify the target filter by the "port" or
"bdf" option respectively. The PMU can only monitor the Root Port or
Endpoint on the same PCIe core so the value of "port" or "bdf" should
be valid and will be checked by the driver.
Currently at least and only one of "port" and "bdf" option must be set.
If "port" filter is not set or is set explicitly to zero (default),
driver will regard the user specifies a "bdf" option since "port" option
is a bitmask of the target Root Ports and zero is not a valid
value.
If user not explicitly set "port" or "bdf" filter, the driver uses "bdf"
default value (zero) to set target filter, but driver will skip the
check of bdf=0, although it's a valid value (meaning 0000:000:00.0).
Then the user just gets zero.
Therefore, we need to check if both "port" and "bdf" are invalid, then
return failure and report warning.
Testing:
before the patch:
0 hisi_pcie0_core1/rx_mrd_flux/
0 hisi_pcie0_core1/rx_mrd_flux,port=0/
24,124 hisi_pcie0_core1/rx_mrd_flux,port=1/
0 hisi_pcie0_core1/rx_mrd_flux,bdf=0/
0 hisi_pcie0_core1/rx_mrd_flux,port=0x800/
<not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=1/
24,132 hisi_pcie0_core1/rx_mrd_flux,bdf=0x1700/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x0/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1/
24,138 hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1700/
24,126 hisi_pcie0_core1/rx_mrd_flux,port=0x1,bdf=0x0/
after the patch:
<not supported> hisi_pcie0_core1/rx_mrd_flux/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0/
24,153 hisi_pcie0_core1/rx_mrd_flux,port=1/
0 hisi_pcie0_core1/rx_mrd_flux,port=0x800/
<not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=0/
<not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=1/
24,117 hisi_pcie0_core1/rx_mrd_flux,bdf=0x1700/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x0/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1/
24,120 hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1700/
24,123 hisi_pcie0_core1/rx_mrd_flux,port=0x1,bdf=0x0/
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-6-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
A typical PCIe transaction is consisted of various TLP packets in both
direction. For counting bandwidth only memory read events are exported
currently. Add memory write and completion counting events of both
direction to complete the bandwidth counting.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-5-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
The metric counting shows incorrect results if the events in the
metric group using the same event but different filter options.
This is because we only judge the event code to decide whether
the event in the metric group should share the same hardware
counter, but ignore the settings of the filter.
For example, on a platform of 2 ports 0x1 and 0x2 but only port
0x1 has a downstream PCIe NVME device. The metric counting
shows both ports have the same counts because we misassign these
two events to one same hardware counter:
[root@localhost perf-iostat]# ./perf stat -e '{hisi_pcie0_core1/event=0x0104,port=0x2/,hisi_pcie0_core1/event=0x0104,port=0x1/}'
Performance counter stats for 'system wide':
7907484924 hisi_pcie0_core1/event=0x0104,port=0x2/
7907484924 hisi_pcie0_core1/event=0x0104,port=0x1/
10.153863691 seconds time elapsed
Fix this by using the whole config rather than the event only
to judge whether two events are the same and should share the
same hardware counter. With this patch, the metric counting in
the above case tends to be corrected:
[root@localhost perf-iostat]# ./perf stat -e '{hisi_pcie0_core1/event=0x0104,port=0x2/,hisi_pcie0_core1/event=0x0104,port=0x1/}'
Performance counter stats for 'system wide':
0 hisi_pcie0_core1/event=0x0104,port=0x2/
8123122077 hisi_pcie0_core1/event=0x0104,port=0x1/
10.152875631 seconds time elapsed
Fixes: 8404b0fbc7 ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-4-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Factor out retrieving of the register value for the
corresponding event from hisi_pcie_config_event_ctrl() into a
new function hisi_pcie_pmu_get_event_ctrl_val() allowing future
reuse.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-3-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
hisi_pcie_pmu_{config,clear}_filter() are config/clear HISI_PCIE_EVENT_CTRL
register which contains not only the filter but also the event code. The
function names are bit misleading. Rename it to
hisi_pcie_pmu_{config,clear}_event_ctrl() to reflects their functions
more accurately.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-2-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
HiSilicon UC PMU v2 suffers the erratum 162700402 that the PMU counter
cannot be set due to the lack of clock under power saving mode. This will
lead to error or inaccurate counts. The clock can be enabled by the PMU
global enabling control.
This patch tries to fix this by set the UC PMU enable before set event
period to turn on the clock, and then restore the UC PMU configuration.
The counter register can hold its value without a clock.
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Reviewed-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/20240227125231.53127-1-hejunhao3@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
A series of kerneldoc warning fixes for omaps from Randy.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAmXcarYRHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXO8/xAAt6QX98EnRQfjJVQFoSJ1/aKF4wUiMPDS
Gef40TP6zsYBdri2+h88RQg/dmchCDOgZ+4IOMlDN+iTKLOuIImOw8AmYRMp3CsK
E/fFgJhD7ZcNVGl83ZrmuiX67ekEENba6H0kHVVR/VvVfTMjBjqNUMJH13qkPWvd
/9liMMuTCJAlwctnJG6GSIqGJznqUPyiBLN77D9S/5LR5aetSF8Tii9yiMDsIBL2
7r4Ex7vrbSH2bmFBgPBdCw4Nrdcv0ddprUNfnYNmePbbZNQay7gme3byfTg6Ib9A
0qh6WNhStF4z3P7a4dC6XKQgSMLtMHxTdW+9LYPrkZm1jc+V9u4nLxA4bDaILjlk
4S3k/EhJ6a1Rt61kurBHZ5Mr6sKGEBpYsvMhQGSOvdv+xAiUHy7er2mNwN84pOuI
7pnY7TCXdcrRX1t3bwSpWe+tda+G5YhlcVNjvrjisgkdaJE8SniJy4wVfQKXh6Co
HHshqQJnqxwFb599vj2BrgWHP5yeaIwLfil3N03HoMDDnQFfrij7sozjZ20mqrnB
gIODNTyP99EqSdCpAFJQschHQMOvuqqLosNZNM/pO7xexoXw5ilNBxRaHx9lpmiH
vmd7OR9ppsGNLrs+X7AiNeSo/j1r5UIxF2TXu0TCqh7hSzqXbtqpQYAHYrCBXCRa
ijPhsSPfdao=
=8GBw
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXl1yUACgkQYKtH/8kJ
Uid74xAAywFgPAmSskA71LpfGTnXUx6HN+OXY72LpLtX6f/PXFGaEI2co4H81mMc
5CgIr0NncMCg/i1SAjyIOxgDs4SWSfG1gsGw07aeoKqt6hJQay9lnO7HlF0oOHSm
pKIvASS4pLNTqKAdp9cQ/wfvbaz4LdYsVrmPhfrIjSlc7s1f2MTh747sPFA5HQQx
uMbW1qFydmfMcRaJvleEnQ6PmP2g/uBZckRX3w9R+EzFhye1X2ZBDOF7qXSjlJ9J
NLcWhrdtwEX/x6KjczHfgil43OG1+z535MXn83sI2sHJIC34NuuxPk9ZOYAbUGqW
i1MKk7U4CV6EU2b7+uzo5OKTxVZdDbV+dI+bs8NYl/0mXK1ZwuItXb8xE5UrnvnY
5kX5+lo1xl6OiOQF+Kl7ld+EZ+Du+UAlDmKemuxVQbsXFxj1Ef7cG1bkwdDdjQl8
eTmcHyHvE2WCLuegmYfzPo0hPxVAPvoQa208fLX0gc63yWh0rQVRCP0VWW44485b
Y/EfNYT7hmr+8N/A3lWkUMPM8Tq68K+DcVYY1XVkMp4CfK5cgu1E1JHy4T676B5c
l5OftL3voze/ann7zKjrymnk2OITV3w4YEab/I4BBdw5Vy6vJrsPzERtDsRFieNW
BJXg+GQDt4uk8Om1YEfugUGoM3ZnYPbZ1y1oYcMbzq44ghWy9rk=
=fPqJ
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v6.9/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into soc/arm
Kerneldoc warning fixes for omaps for v6.9
A series of kerneldoc warning fixes for omaps from Randy.
* tag 'omap-for-v6.9/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: fix kernel-doc warnings
ARM: OMAP2+: fix kernel-doc warnings
ARM: OMAP2+: fix a kernel-doc warning
ARM: OMAP2+: PRM: fix kernel-doc warnings
ARM: OMAP2+: prm44xx: fix a kernel-doc warning
ARM: OMAP2+: pmic-cpcap: fix kernel-doc warnings
ARM: OMAP2+: hwmod: fix kernel-doc warnings
ARM: OMAP2+: hwmod: remove misuse of kernel-doc
ARM: OMAP2+: CMINST: use matching function name in kernel-doc
ARM: OMAP2+: cm33xx: use matching function name in kernel-doc
ARM: OMAP2+: clock: fix a function name in kernel-doc
ARM: OMAP2+: clockdomain: fix kernel-doc warnings
ARM: OMAP2+: am33xx-restart: fix function name in kernel-doc
Link: https://lore.kernel.org/r/pull-1708944095-4485@atomide.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In current ping-pong design, xdp_hw_metadata will wait until the packet
transmission completely done, then only start to receive the next packet.
The current sleep interval is 10ms, which is unnecessary large. Typically,
a NIC does not need such a long time to transmit a packet. Furthermore,
during this 10ms sleep time, the app is unable to receive incoming packets.
Therefore, this commit reduce sleep interval to 10us, so that
xdp_hw_metadata is able to support periodic packets with shorter interval.
10us * 500 = 5ms should be enough for packet transmission and status
retrieval.
Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20240303083225.1184165-2-yoong.siang.song@intel.com
The pointer data is being assigned a value that is not being
read afterwards, it is being re-assigned later inside a do-while
loop. The assignment is redundant and can be removed.
Cleans up clang scan warning:
drivers/usb/serial/keyspan.c:924:2: warning: Value stored to 'data'
is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
The variable cflag is being assigned a value that is not being read
afterwards, it is being re-assigned later on. The assignment is
redundant and can be removed.
Cleans up clang scan warning:
drivers/usb/serial/ftdi_sio.c:2613:15: warning: Value stored to 'cflag'
during its initialization is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Settle on three "flavors" of uprobe/uretprobe, installed on different
kinds of instruction: nop, push, and ret. All three are testing
different internal code paths emulating or single-stepping instructions,
so are interesting to compare and benchmark separately.
To ensure `push rbp` instruction we ensure that uprobe_target_push() is
not a leaf function by calling (global __weak) noop function and
returning something afterwards (if we don't do that, compiler will just
do a tail call optimization).
Also, we need to make sure that compiler isn't skipping frame pointer
generation, so let's add `-fno-omit-frame-pointers` to Makefile.
Just to give an idea of where we currently stand in terms of relative
performance of different uprobe/uretprobe cases vs a cheap syscall
(getpgid()) baseline, here are results from my local machine:
$ benchs/run_bench_uprobes.sh
base : 1.561 ± 0.020M/s
uprobe-nop : 0.947 ± 0.007M/s
uprobe-push : 0.951 ± 0.004M/s
uprobe-ret : 0.443 ± 0.007M/s
uretprobe-nop : 0.471 ± 0.013M/s
uretprobe-push : 0.483 ± 0.004M/s
uretprobe-ret : 0.306 ± 0.007M/s
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20240301214551.1686095-1-andrii@kernel.org
The variable divisor is being assigned a value that is not being
read afterward, it is being re-assigned later in both paths of an if
statement. The assignment is redundant and can be removed.
Cleans up clang scan warning:
drivers/usb/serial/oti6858.c:412:2: warning: Value stored to 'divisor'
is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
If a link is deactivated, we really cannot sustain any
TDLS connections on that link any more. With the API
now changed, fix this issue and remove TDLS connections.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://msgid.link/20240228095719.a7dd812c37bf.I3474dbde79e9e7a539d47f6f81f32e6c3e459080@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a link does CSA, or if it changes SMPS mode, we need to
drop the TDLS peers, but we really should drop them only on
the affected link. Fix that.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://msgid.link/20240228095719.00d1d793f5b8.Ia9971316c6b3922dd371d64ac2198f91ed5ad9d2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Unify all the CSA handling, including handling of a beacon
after the CSA, into ieee80211_sta_process_chanswitch().
The CRC of the beacon will change due to changes in the
CSA/ECSA elements, so there's really no need to have the
'beacon after CSA' handling before the CRC processing or
to change the beacon_crc_valid value here.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228095719.e269c0e02905.I9dc68ff1e84d51349822bc7d3b33b578fcf8e360@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When doing CSA in multi-link, there really isn't a need to
stop transmissions entirely. Add a feature flag for drivers
to indicate they can handle quiet in CSA (be it by parsing
themselves, or by implementing drv_pre_channel_switch()),
to make that possible.
Also clean up the csa_block_tx handling: it clearly cannot
handle multi-link due to the way queues are stopped, move
it to the sdata. Drivers should be doing it themselves for
working properly during CSA in MLO anyway. Also rename it
to indicate that it reflects TX was blocked at mac80211.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228095719.258439191541.I2469d206e2bf5cb244cfde2b4bbc2ae6d1cd3dd9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Pass the link conf to the abort_channel_switch driver
method so the driver can handle things correctly.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228095718.27f621106ddd.Iadd3d69b722ffe5934779a32a0e4e596a4e33ed4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For CSA to work correctly in multi-link scenarios, pass
the link_id to the relevant callbacks.
While at it, unify/deduplicate the tracing for them.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://msgid.link/20240228095718.b7726635c054.I0be5d00af4acb48cfbd23a9dbf067f9aeb66469d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the function btf__load_vmlinux_btf, the debug message incorrectly
refers to 'path' instead of 'sysfs_btf_path'.
Signed-off-by: Chen Shen <peterchenshen@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/bpf/20240302062218.3587-1-peterchenshen@gmail.com
If we just want to determine the length of the fragmented
data, we basically need the same logic, and really we want
it to be _literally_ the same logic, so it cannot be out
of sync in any way.
Allow calling cfg80211_defragment_element() without an output
buffer, where it then just returns the required output size.
Also add this to the tests, just to exercise it, using the
pre-calculated length to really do the defragmentation, which
checks that this is sufficient.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://msgid.link/20240228095718.6d6565b9e3f2.Ib441903f4b8644ba04b1c766f90580ee6f54fc66@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We're always using "scratch + len - pos", so we don't need
to subtract here to calculate the remaining length. Remove
the unnecessary subtraction.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://msgid.link/20240228094902.44e07cfa9e63.I7a9758fb9bc6b726aac49804f2f05cd521bc4128@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Using the scratch buffer (without advancing it) here in the
mlme.c code seems somewhat wrong, defragment the reconfig
multi-link element already when parsing. This might be a bit
more work in certain cases, but makes the whole thing more
regular.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228094902.92936a3ce216.I4b736ce4fdc199fa1d6b00d00032f448c873a8b4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We shouldn't assign elems->ml_basic{,len} before defragmentation,
and we don't need elems->ml_reconf{,len} at all since we don't do
defragmentation. Clean that up a bit. This does require always
defragmention even when it may not be needed, but that's easier
to reason about.
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228094902.e0115da4d2a6.I89a80f7387eabef8df3955485d4a583ed024c5b1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We sometimes need to check if a link is active, and this
is complicated by the fact that active_links has no bits
set when the vif isn't (acting as) an MLD. Add a small
new helper ieee80211_vif_link_active() to make that a bit
easier, and use it in a few places.
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228094901.688760aff5f7.I06892a503f5ecb9563fbd678d35d08daf7a044b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
At this point, since it's taken from elems->ml_basic which
is stored only if it's of type basic, we don't really need
to check again if it's basic.
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240228094901.ad1d4a09a6eb.Ib96fa75b1a6db21dd4182dcfa11fe9aff78fa3ed@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
./drivers/bus/bt1-apb.c: linux/clk.h is included more than once.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8312
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Acked-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
