[PATCH 00/12] F(x)tec Pro1X feature expansion
This patch series expand F(x)tec Pro1X (QX1050) device tree to support various components of the device. Most notably: + SD Card slot + Touchscreen + MDSS, DRM display panel + WLAN (ATH10K) + Hall sensor and camera button This patch series has been tested on Buildroot Linux with TQFTPSERV and RMTFS present in userspace. Signed-off-by: Dang Huynh --- Dang Huynh (12): arm64: dts: qcom: sm6115-pro1x: Add Hall Switch and Camera Button arm64: dts: qcom: sm6115-pro1x: Add PCA9534 IO Expander arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen arm64: dts: qcom: sm6115-pro1x: Add Caps Lock LED arm64: dts: qcom: sm6115-pro1x: Enable SD card slot arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU arm64: dts: qcom: sm6115-pro1x: Hook up USB3 SS arm64: dts: qcom: sm6115-pro1x: Update copyright year arm64: dts: qcom: sm6115-pro1x: Add PMI632 Type-C property arm64: dts: qcom: sm6115-pro1x: Enable RGB LED arm64: dts: qcom: sm6115-pro1x: Enable remoteprocs arm64: dts: qcom: sm6115-pro1x: Enable ATH10K WLAN arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 316 +++- 1 file changed, 306 insertions(+), 10 deletions(-) --- base-commit: 41c196e567fb1ea97f68a2ffb7faab451cd90854 change-id: 20240722-qx1050-feature-expansion-7f6a2682f2ea Best regards, -- Dang Huynh
[PATCH 01/12] arm64: dts: qcom: sm6115-pro1x: Add Hall Switch and Camera Button
The Pro1X has a flip keyboard and a single-state camera button.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 4a30024aa48f..5b7dd54be6b6 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -34,9 +34,24 @@ framebuffer0: framebuffer@5c00 {
gpio-keys {
compatible = "gpio-keys";
-
- pinctrl-0 = <&vol_up_n>;
pinctrl-names = "default";
+ pinctrl-0 = <&hall_sensor_n>, <&key_camera_n>, <&vol_up_n>;
+
+ hall-switch {
+ label = "Hall Switch";
+ linux,input-type = ;
+ linux,code = ;
+ gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ debounce-interval = <90>;
+ wakeup-source;
+ };
+
+ key-camera {
+ label = "Camera Button";
+ linux,code = ;
+ gpios = <&tlmm 18 GPIO_ACTIVE_LOW>;
+ debounce-interval = <15>;
+ };
key-volume-up {
label = "Volume Up";
@@ -212,6 +227,20 @@ &sleep_clk {
&tlmm {
gpio-reserved-ranges = <0 4>, <14 4>;
+
+ hall_sensor_n: hall-sensor-n {
+ pins = "gpio96";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ key_camera_n: key-camera-n {
+ pins = "gpio18";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
};
&ufs_mem_hc {
--
2.45.2
[PATCH 02/12] arm64: dts: qcom: sm6115-pro1x: Add PCA9534 IO Expander
F(x)tec Pro1X comes with PCA9534 IO Expander, it is used for enabling
touch screen VDD/VDDIO and keyboard's caps lock LED.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 5b7dd54be6b6..43b4bee72dd8 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -69,6 +69,23 @@ &dispcc {
status = "disabled";
};
+&gpi_dma0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+ /* Clock frequency was not specified downstream, let's park it to 100
KHz */
+ clock-frequency = <10>;
+
+ pca9534: gpio@21 {
+ compatible = "nxp,pca9534";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
&pm6125_gpios {
vol_up_n: vol-up-n-state {
pins = "gpio5";
@@ -88,6 +105,10 @@ &pon_resin {
status = "okay";
};
+&qupv3_id_0 {
+ status = "okay";
+};
+
&rpm_requests {
regulators-0 {
compatible = "qcom,rpm-pm6125-regulators";
--
2.45.2
[PATCH 03/12] arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen
The Fxtec Pro1X touchscreen uses Goodix GT9286 chip.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 49 +
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 43b4bee72dd8..d91d31646b29 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -62,6 +62,20 @@ key-volume-up {
wakeup-source;
};
};
+
+ ts_vdd_supply: ts-vdd-supply {
+ compatible = "regulator-fixed";
+ regulator-name = "ts_vdd_supply";
+ gpio = <&pca9534 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ ts_vddio_supply: ts-vddio-supply {
+ compatible = "regulator-fixed";
+ regulator-name = "ts_vddio_supply";
+ gpio = <&pca9534 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&dispcc {
@@ -86,6 +100,27 @@ pca9534: gpio@21 {
};
};
+&i2c2 {
+ status = "okay";
+ /* Clock frequency was not specified downstream, let's park it to 100
KHz */
+ clock-frequency = <10>;
+
+ touchscreen@14 {
+ compatible = "goodix,gt9286";
+ reg = <0x14>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_int_n>, <&ts_rst_n>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
+
+ irq-gpios = <&tlmm 80 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&tlmm 71 GPIO_ACTIVE_HIGH>;
+ AVDD28-supply = <&ts_vdd_supply>;
+ VDDIO-supply = <&ts_vddio_supply>;
+ };
+};
+
&pm6125_gpios {
vol_up_n: vol-up-n-state {
pins = "gpio5";
@@ -262,6 +297,20 @@ key_camera_n: key-camera-n {
drive-strength = <2>;
bias-pull-up;
};
+
+ ts_int_n: ts-int-n {
+ pins = "gpio80";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ ts_rst_n: ts-rst-n {
+ pins = "gpio71";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
};
&ufs_mem_hc {
--
2.45.2
[PATCH 04/12] arm64: dts: qcom: sm6115-pro1x: Add Caps Lock LED
The Pro1X has a caps lock LED on the keyboard.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index d91d31646b29..60c046fe8e52 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -8,6 +8,7 @@
#include "sm6115.dtsi"
#include "pm6125.dtsi"
#include
+#include
/ {
model = "F(x)tec Pro1X (QX1050)";
@@ -63,6 +64,16 @@ key-volume-up {
};
};
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ capslock-led {
+ color = ;
+ function = LED_FUNCTION_CAPSLOCK;
+ gpios = <&pca9534 1 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
ts_vdd_supply: ts-vdd-supply {
compatible = "regulator-fixed";
regulator-name = "ts_vdd_supply";
--
2.45.2
[PATCH 05/12] arm64: dts: qcom: sm6115-pro1x: Enable SD card slot
Fxtec Pro1X has two card slots and allow either 2xSIM cards or
1xSIM, 1xSD Card configuration.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 31 +
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 60c046fe8e52..42567545f56d 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -187,6 +187,7 @@ pm6125_l4a: l4 {
pm6125_l5a: l5 {
regulator-min-microvolt = <1648000>;
regulator-max-microvolt = <3056000>;
+ regulator-allow-set-load;
};
pm6125_l6a: l6 {
@@ -288,6 +289,36 @@ pm6125_l24a: l24 {
};
};
+&sdc2_state_off {
+ cd-pins {
+ pins = "gpio88";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&sdc2_state_on {
+ cd-pins {
+ pins = "gpio88";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+};
+
+&sdhc_2 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&sdc2_state_on>;
+ pinctrl-1 = <&sdc2_state_off>;
+
+ cd-gpios = <&tlmm 88 GPIO_ACTIVE_LOW>;
+
+ vmmc-supply = <&pm6125_l22a>;
+ vqmmc-supply = <&pm6125_l5a>;
+ status = "okay";
+};
+
&sleep_clk {
clock-frequency = <32764>;
};
--
2.45.2
[PATCH 06/12] arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU
Fxtec Pro1x uses the same display (BOE BF060Y8M-AJ0) as Pro1.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 60 +++--
1 file changed, 56 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 42567545f56d..6148cc258164 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -89,13 +89,16 @@ ts_vddio_supply: ts-vddio-supply {
};
};
-&dispcc {
- /* HACK: disable until a panel driver is ready to retain simplefb */
- status = "disabled";
+&gpi_dma0 {
+ status = "okay";
};
-&gpi_dma0 {
+&gpu {
status = "okay";
+
+ zap-shader {
+ firmware-name = "qcom/sm6115/Fxtec/QX1050/a610_zap.mbn";
+ };
};
&i2c1 {
@@ -132,6 +135,42 @@ touchscreen@14 {
};
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&pm6125_l18a>;
+ status = "okay";
+
+ panel: panel@0 {
+ compatible = "boe,bf060y8m-aj0";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 82 GPIO_ACTIVE_LOW>;
+
+ vddio-supply = <&pm6125_l9a>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdss_dsi_n &panel_en_n>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+};
+
+&mdss_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&panel_in>;
+};
+
+&mdss_dsi0_phy {
+ status = "okay";
+};
+
&pm6125_gpios {
vol_up_n: vol-up-n-state {
pins = "gpio5";
@@ -340,6 +379,19 @@ key_camera_n: key-camera-n {
bias-pull-up;
};
+ mdss_dsi_n: mdss-dsi-n {
+ pins = "gpio82";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ panel_en_n: panel-en-n {
+ pins = "gpio65";
+ function = "gpio";
+ bias-disable;
+ };
+
ts_int_n: ts-int-n {
pins = "gpio80";
function = "gpio";
--
2.45.2
[PATCH 07/12] arm64: dts: qcom: sm6115-pro1x: Hook up USB3 SS
The F(x)tec Pro1X supports USB 3.0 through it's USB-C port.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 6148cc258164..a32fc27bc783 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -428,7 +428,6 @@ &usb {
&usb_dwc3 {
/delete-property/ usb-role-switch;
- maximum-speed = "high-speed";
dr_mode = "peripheral";
};
@@ -439,6 +438,12 @@ &usb_hsphy {
status = "okay";
};
+&usb_qmpphy {
+ vdda-phy-supply = <&pm6125_l4a>;
+ vdda-pll-supply = <&pm6125_l12a>;
+ status = "okay";
+};
+
&xo_board {
clock-frequency = <1920>;
};
--
2.45.2
[PATCH 08/12] arm64: dts: qcom: sm6115-pro1x: Update copyright year
It's 2024, let's update the copyright year. Signed-off-by: Dang Huynh --- arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts index a32fc27bc783..6e9e4d9f8250 100644 --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts @@ -1,6 +1,6 @@ // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) /* - * Copyright (c) 2023, Dang Huynh + * Copyright (c) 2023 - 2024, Dang Huynh */ /dts-v1/; -- 2.45.2
[PATCH 09/12] arm64: dts: qcom: sm6115-pro1x: Add PMI632 Type-C property
The USB-C port is used for powering external devices and transfer
data from/to them.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 51 +++--
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 6e9e4d9f8250..88df28fc8c7e 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -7,8 +7,10 @@
#include "sm6115.dtsi"
#include "pm6125.dtsi"
+#include "pmi632.dtsi"
#include
#include
+#include
/ {
model = "F(x)tec Pro1X (QX1050)";
@@ -181,6 +183,46 @@ vol_up_n: vol-up-n-state {
};
};
+&pmi632_typec {
+ status = "okay";
+
+ connector {
+ compatible = "usb-c-connector";
+
+ power-role = "dual";
+ data-role = "dual";
+ self-powered;
+
+ typec-power-opmode = "default";
+ pd-disable;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ pmi632_hs_in: endpoint {
+ remote-endpoint = <&usb_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ pmi632_ss_in: endpoint {
+ remote-endpoint = <&usb_qmpphy_out>;
+ };
+ };
+ };
+ };
+};
+
+&pmi632_vbus {
+ regulator-min-microamp = <50>;
+ regulator-max-microamp = <100>;
+ status = "okay";
+};
+
&pon_pwrkey {
status = "okay";
};
@@ -426,9 +468,8 @@ &usb {
status = "okay";
};
-&usb_dwc3 {
- /delete-property/ usb-role-switch;
- dr_mode = "peripheral";
+&usb_dwc3_hs {
+ remote-endpoint = <&pmi632_hs_in>;
};
&usb_hsphy {
@@ -444,6 +485,10 @@ &usb_qmpphy {
status = "okay";
};
+&usb_qmpphy_out {
+ remote-endpoint = <&pmi632_ss_in>;
+};
+
&xo_board {
clock-frequency = <1920>;
};
--
2.45.2
[PATCH 10/12] arm64: dts: qcom: sm6115-pro1x: Enable RGB LED
This device has an RGB LED. It is used for notifications.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 27 +
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 88df28fc8c7e..b434241a95b2 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -183,6 +183,33 @@ vol_up_n: vol-up-n-state {
};
};
+&pmi632_lpg {
+ status = "okay";
+
+ multi-led {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = ;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = ;
+ };
+
+ led@3 {
+ reg = <3>;
+ color = ;
+ };
+ };
+};
+
&pmi632_typec {
status = "okay";
--
2.45.2
[PATCH 11/12] arm64: dts: qcom: sm6115-pro1x: Enable remoteprocs
Enable [A,C]DSP and MPSS remote processor on this device.
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index b434241a95b2..14d4f533f741 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -263,6 +263,21 @@ &qupv3_id_0 {
status = "okay";
};
+&remoteproc_adsp {
+ firmware-name = "qcom/sm6115/Fxtec/QX1050/adsp.mbn";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm6115/Fxtec/QX1050/cdsp.mbn";
+ status = "okay";
+};
+
+&remoteproc_mpss {
+ firmware-name = "qcom/sm6115/Fxtec/QX1050/modem.mbn";
+ status = "okay";
+};
+
&rpm_requests {
regulators-0 {
compatible = "qcom,rpm-pm6125-regulators";
--
2.45.2
[PATCH 12/12] arm64: dts: qcom: sm6115-pro1x: Enable ATH10K WLAN
Enable onboard Wi-Fi on the F(x)tec Pro1X.
For reference, HW/SW identifies as:
qmi chip_id 0x120 chip_family 0x4007 board_id 0xff soc_id 0x4067
qmi fw_version 0x324103d6 fw_build_timestamp 2021-12-02 08:20
fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.4-00982-QCAHLSWMTPLZ-1
Signed-off-by: Dang Huynh
---
arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
index 14d4f533f741..c148ebd1c8b4 100644
--- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
+++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
@@ -531,6 +531,17 @@ &usb_qmpphy_out {
remote-endpoint = <&pmi632_ss_in>;
};
+&wifi {
+ status = "okay";
+
+ vdd-0.8-cx-mx-supply = <&pm6125_l8a>;
+ vdd-1.8-xo-supply = <&pm6125_l16a>;
+ vdd-1.3-rfa-supply = <&pm6125_l17a>;
+ vdd-3.3-ch0-supply = <&pm6125_l23a>;
+
+ qcom,ath10k-calibration-variant = "Fxtec_QX1050";
+};
+
&xo_board {
clock-frequency = <1920>;
};
--
2.45.2
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Fri, Jul 19, 2024 at 9:19 AM Michael S. Tsirkin wrote: > > On Fri, Jul 19, 2024 at 09:02:29AM +0800, Jason Wang wrote: > > On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote: > > > > > > On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin > > > wrote: > > > > > > > > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote: > > > > > On Wed, Jul 10, 2024 at 11:03 AM Jason Wang > > > > > wrote: > > > > > > > > > > > > On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote: > > > > > > > > This patch synchronize operstate with admin state per RFC2863. > > > > > > > > > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > > synchronize with the config change work. This allows propagate > > > > > > > > status > > > > > > > > correctly to stacked devices like: > > > > > > > > > > > > > > > > ip link add link enp0s3 macvlan0 type macvlan > > > > > > > > ip link set link enp0s3 down > > > > > > > > ip link show > > > > > > > > > > > > > > > > Before this patch: > > > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast > > > > > > > > state DOWN mode DEFAULT group default qlen 1000 > > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > > .. > > > > > > > > 5: macvlan0@enp0s3: > > > > > > > > mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen > > > > > > > > 1000 > > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > > > > > After this patch: > > > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast > > > > > > > > state DOWN mode DEFAULT group default qlen 1000 > > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > > ... > > > > > > > > 5: macvlan0@enp0s3: > > > > > > > > mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group > > > > > > > > default qlen 1000 > > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > > > I think that the commit log is confusing. It seems to say that > > > > > > > the issue fixed is synchronizing state with hardware > > > > > > > config change. > > > > > > > But your example does not show any > > > > > > > hardware change. Isn't this example really just > > > > > > > a side effect of setting carrier off on close? > > > > > > > > > > > > The main goal for this patch is to make virtio-net follow RFC2863. > > > > > > The > > > > > > main thing that is missed is to synchronize the operstate with admin > > > > > > state, if we do this, we get several good results, one of the > > > > > > obvious > > > > > > one is to allow virtio-net to propagate status to the upper layer, > > > > > > for > > > > > > example if the admin state of the lower virtio-net is down it should > > > > > > be propagated to the macvlan on top, so I give the example of using > > > > > > a > > > > > > stacked device. I'm not we had others but the commit log is probably > > > > > > too small to say all of it. > > > > > > > > > > Michael, any more comments on this? > > > > > > > > > > Thans > > > > > > > > > > > > Still don't get it, sorry. > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > > synchronize with the config change work. > > > > What does this sentence mean? What is not synchronized with config > > > > change that needs to be? > > > > > > I meant, > > > > > > 1) maclvan depends on the linkwatch to transfer operstate from the > > > lower device to itself. > > > 2) ndo_open()/close() will not trigger the linkwatch so we need to do > > > it by ourselves in virtio-net to make sure macvlan get the correct > > > opersate > > > 3) consider config change work can change the state so ndo_close() > > > needs to synchronize with it > > > > > > Thanks > > > > Michael, are you fine with the above or I miss something there? > > > > Thanks > > > I don't understand 3. config change can always trigger. > what I do not like is all these reads from config space > that now trigger on open/close. previously we did > read > - on probe > - after probe, if config changed > > > and that made sense. Ok, not sure I get you all but I will post a new version to see. Thanks > > -- > MST >
Re: [PATCH V2 3/7] vhost-vdpa: VHOST_NEW_OWNER
On Thu, Jul 18, 2024 at 2:28 AM Steven Sistare
wrote:
>
> On 7/16/2024 1:16 AM, Jason Wang wrote:
> > On Mon, Jul 15, 2024 at 10:27 PM Steven Sistare
> > wrote:
> >>
> >> On 7/14/2024 10:26 PM, Jason Wang wrote:
> >>> On Fri, Jul 12, 2024 at 9:19 PM Steve Sistare
> >>> wrote:
>
> Add an ioctl to transfer file descriptor ownership and pinned memory
> accounting from one process to another.
>
> This is more efficient than VHOST_RESET_OWNER followed by
> VHOST_SET_OWNER,
> as that would unpin all physical pages, requiring them to be repinned in
> the new process. That would cost multiple seconds for large memories,
> and
> be incurred during a virtual machine's pause time during live update.
>
> Signed-off-by: Steve Sistare
> ---
> drivers/vhost/vdpa.c | 41 ++
> drivers/vhost/vhost.c | 15 ++
> drivers/vhost/vhost.h | 1 +
> include/uapi/linux/vhost.h | 10 ++
> 4 files changed, 67 insertions(+)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index b49e5831b3f0..5cf55ca4ec02 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -632,6 +632,44 @@ static long vhost_vdpa_resume(struct vhost_vdpa *v)
> return ret;
> }
>
> +static long vhost_vdpa_new_owner(struct vhost_vdpa *v)
> +{
> + int r;
> + struct vhost_dev *vdev = &v->vdev;
> + struct mm_struct *mm_old = vdev->mm;
> + struct mm_struct *mm_new = current->mm;
> + long pinned_vm = v->pinned_vm;
> + unsigned long lock_limit = PFN_DOWN(rlimit(RLIMIT_MEMLOCK));
> +
> + if (!mm_old)
> + return -EINVAL;
> + mmgrab(mm_old);
> +
> + if (!v->vdpa->use_va &&
> + pinned_vm + atomic64_read(&mm_new->pinned_vm) > lock_limit) {
> + r = -ENOMEM;
> + goto out;
> + }
> >>>
> >>> So this seems to allow an arbitrary process to execute this. Seems to be
> >>> unsafe.
> >>>
> >>> I wonder if we need to add some checks here, maybe PID or other stuff
> >>> to only allow the owner process to do this.
> >>
> >> The original owner must send the file descriptor to the new owner.
> >
> > This seems not to be in the steps you put in the cover letter.
>
> It's there:
>"The vdpa device descriptor, fd, remains open across the exec."
>
> But, I can say more about how fd visibility constitutes permission to changer
> owner in this commit message.
Yes, that would be great.
>
> >> That constitutes permission to take ownership.
> >
> > This seems like a relaxed version of the reset_owner:
> >
> > Currently, reset_owner have the following check:
>
> Not relaxed, just different. A process cannot do anything with fd if it
> is not the owner, *except* for becoming the new owner. Holding the fd is
> like holding a key.
I meant it kind of "defeats" the effort of VHOST_NET_RESET_OWNER ...
Thanks
>
> - Steve
>
> > /* Caller should have device mutex */
> > long vhost_dev_check_owner(struct vhost_dev *dev)
> > {
> > /* Are you the owner? If not, I don't think you mean to do that */
> > return dev->mm == current->mm ? 0 : -EPERM;
> > }
> > EXPORT_SYMBOL_GPL(vhost_dev_check_owner);
> >
> > It means even if the fd is passed to some other process, the reset
> > owner won't work there.
> >
> > Thanks
> >
> >>
> + r = vhost_vdpa_bind_mm(v, mm_new);
> + if (r)
> + goto out;
> +
> + r = vhost_dev_new_owner(vdev);
> + if (r) {
> + vhost_vdpa_bind_mm(v, mm_old);
> + goto out;
> + }
> +
> + if (!v->vdpa->use_va) {
> + atomic64_sub(pinned_vm, &mm_old->pinned_vm);
> + atomic64_add(pinned_vm, &mm_new->pinned_vm);
> + }
> +
> +out:
> + mmdrop(mm_old);
> + return r;
> +}
> +
> static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, unsigned int
> cmd,
> void __user *argp)
> {
> @@ -876,6 +914,9 @@ static long vhost_vdpa_unlocked_ioctl(struct file
> *filep,
> case VHOST_VDPA_RESUME:
> r = vhost_vdpa_resume(v);
> break;
> + case VHOST_NEW_OWNER:
> + r = vhost_vdpa_new_owner(v);
> + break;
> default:
> r = vhost_dev_ioctl(&v->vdev, cmd, argp);
> if (r == -ENOIOCTLCMD)
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index b60955682474..ab40ae50552f 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -963,6 +96
Re: [PATCH 08/12] arm64: dts: qcom: sm6115-pro1x: Update copyright year
On 22/07/2024 09:10, Dang Huynh wrote: > It's 2024, let's update the copyright year. > > Signed-off-by: Dang Huynh > --- > arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > index a32fc27bc783..6e9e4d9f8250 100644 > --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) > /* > - * Copyright (c) 2023, Dang Huynh > + * Copyright (c) 2023 - 2024, Dang Huynh Please squash it. I don't think copyright update has a merit on its own. Best regards, Krzysztof
Re: [PATCH 02/17] MIPS: sgi-ip27: make NODE_DATA() the same as on all other architectures
On Fri, Jul 19, 2024 at 03:38:52PM +0100, Jonathan Cameron wrote:
> On Wed, 17 Jul 2024 16:32:59 +0200
> David Hildenbrand wrote:
>
> > On 16.07.24 13:13, Mike Rapoport wrote:
> > > From: "Mike Rapoport (Microsoft)"
> > >
> > > sgi-ip27 is the only system that defines NODE_DATA() differently than
> > > the rest of NUMA machines.
> > >
> > > Add node_data array of struct pglist pointers that will point to
> > > __node_data[node]->pglist and redefine NODE_DATA() to use node_data
> > > array.
> > >
> > > This will allow pulling declaration of node_data to the generic mm code
> > > in the next commit.
> > >
> > > Signed-off-by: Mike Rapoport (Microsoft)
> > > ---
> > > arch/mips/include/asm/mach-ip27/mmzone.h | 5 -
> > > arch/mips/sgi-ip27/ip27-memory.c | 5 -
> > > 2 files changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/mips/include/asm/mach-ip27/mmzone.h
> > > b/arch/mips/include/asm/mach-ip27/mmzone.h
> > > index 08c36e50a860..629c3f290203 100644
> > > --- a/arch/mips/include/asm/mach-ip27/mmzone.h
> > > +++ b/arch/mips/include/asm/mach-ip27/mmzone.h
> > > @@ -22,7 +22,10 @@ struct node_data {
> > >
> > > extern struct node_data *__node_data[];
> > >
> > > -#define NODE_DATA(n) (&__node_data[(n)]->pglist)
> > > #define hub_data(n) (&__node_data[(n)]->hub)
> > >
> > > +extern struct pglist_data *node_data[];
> > > +
> > > +#define NODE_DATA(nid) (node_data[nid])
> > > +
> > > #endif /* _ASM_MACH_MMZONE_H */
> > > diff --git a/arch/mips/sgi-ip27/ip27-memory.c
> > > b/arch/mips/sgi-ip27/ip27-memory.c
> > > index b8ca94cfb4fe..c30ef6958b97 100644
> > > --- a/arch/mips/sgi-ip27/ip27-memory.c
> > > +++ b/arch/mips/sgi-ip27/ip27-memory.c
> > > @@ -34,8 +34,10 @@
> > > #define SLOT_PFNSHIFT (SLOT_SHIFT - PAGE_SHIFT)
> > > #define PFN_NASIDSHFT (NASID_SHFT - PAGE_SHIFT)
> > >
> > > -struct node_data *__node_data[MAX_NUMNODES];
> > > +struct pglist_data *node_data[MAX_NUMNODES];
> > > +EXPORT_SYMBOL(node_data);
> > >
> > > +struct node_data *__node_data[MAX_NUMNODES];
> > > EXPORT_SYMBOL(__node_data);
> > >
> > > static u64 gen_region_mask(void)
> > > @@ -361,6 +363,7 @@ static void __init node_mem_init(nasid_t node)
> > >*/
> > > __node_data[node] = __va(slot_freepfn << PAGE_SHIFT);
> > > memset(__node_data[node], 0, PAGE_SIZE);
> > > + node_data[node] = &__node_data[node]->pglist;
> > >
> > > NODE_DATA(node)->node_start_pfn = start_pfn;
> > > NODE_DATA(node)->node_spanned_pages = end_pfn - start_pfn;
> >
> > I was assuming we could get rid of __node_data->pglist.
> >
> > But now I am confused where that is actually set.
>
> It looks nasty...
Nasty indeed :)
> Cast in arch_refresh_nodedata() takes incoming pg_data_t * and casts it
> to the local version of struct node_data * which I think is this one
>
> struct node_data {
> struct pglist_data pglist; (which is pg_data_t pglist)
> struct hub_data hub;
> };
>
> https://elixir.bootlin.com/linux/v6.10/source/arch/mips/sgi-ip27/ip27-memory.c#L432
>
> Now that pg_data_t is allocated by
> arch_alloc_nodedata() which might be fine (though types could be handled in a
> more
> readable fashion via some container_of() magic.
> https://elixir.bootlin.com/linux/v6.10/source/arch/mips/sgi-ip27/ip27-memory.c#L427
>
> However that call is:
> pg_data_t * __init arch_alloc_nodedata(int nid)
> {
> return memblock_alloc(sizeof(pg_data_t), SMP_CACHE_BYTES);
> }
>
> So doesn't seem to allocate enough space to me as should be sizeof(struct
> node_data)
Well, it's there to silence a compiler error (commit f8f9f21c7848 ("MIPS:
Fix build error for loongson64 and sgi-ip27")), but this is not a proper
fix :(
Luckily nothing calls cpumask_of_node() for offline nodes...
> Worth cleaning up whilst here? Proper handling of types would definitely
> help.
Worth cleanup indeed, but I'd rather drop arch_alloc_nodedata() on MIPS
altogether.
> Jonathan
--
Sincerely yours,
Mike.
Re: [PATH v4 2/3] vdpa_sim_net: Add the support of set mac address
On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa_sim_net, the driver will write the MAC address
> to the config space, and other devices can implement
> their own functions to support this.
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> index cfe962911804..936e33e5021a 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> @@ -414,6 +414,25 @@ static void vdpasim_net_get_config(struct vdpasim
> *vdpasim, void *config)
> net_config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
> }
>
> +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *config)
> +{
> + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> + struct virtio_net_config *vio_config = vdpasim->config;
> +
> + mutex_lock(&vdpasim->mutex);
> +
> + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
> + mutex_unlock(&vdpasim->mutex);
> + return 0;
> + }
> +
> + mutex_unlock(&vdpasim->mutex);
Do we need to protect:
case VIRTIO_NET_CTRL_MAC_ADDR_SET:
read = vringh_iov_pull_iotlb(&cvq->vring, &cvq->in_iov,
vio_config->mac, ETH_ALEN);
if (read == ETH_ALEN)
status = VIRTIO_NET_OK;
break;
As both are modifying vio_config?
Thanks
> + return -EINVAL;
> +}
> +
> static void vdpasim_net_setup_config(struct vdpasim *vdpasim,
> const struct vdpa_dev_set_config *config)
> {
> @@ -510,7 +529,8 @@ static void vdpasim_net_dev_del(struct vdpa_mgmt_dev
> *mdev,
>
> static const struct vdpa_mgmtdev_ops vdpasim_net_mgmtdev_ops = {
> .dev_add = vdpasim_net_dev_add,
> - .dev_del = vdpasim_net_dev_del
> + .dev_del = vdpasim_net_dev_del,
> + .dev_set_attr = vdpasim_net_set_attr
> };
>
> static struct virtio_device_id id_table[] = {
> --
> 2.45.0
>
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> index ecfc16151d61..415b527a9c72 100644
> --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> *v_mdev, struct vdpa_device *
> destroy_workqueue(wq);
> mgtdev->ndev = NULL;
> }
> +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *add_config)
> +{
> + struct mlx5_vdpa_dev *mvdev;
> + struct mlx5_vdpa_net *ndev;
> + struct mlx5_core_dev *mdev;
> + struct virtio_net_config *config;
> + struct mlx5_core_dev *pfmdev;
> + int err = -EOPNOTSUPP;
> +
> + mvdev = to_mvdev(dev);
> + ndev = to_mlx5_vdpa_ndev(mvdev);
> + mdev = mvdev->mdev;
> + config = &ndev->config;
> +
> + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> + if (!err)
> + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
> + }
> + return err;
Similar to net simulator, how could be serialize the modification to
mac address:
1) from vdpa tool
2) via control virtqueue
Thanks
> +}
>
> static const struct vdpa_mgmtdev_ops mdev_ops = {
> .dev_add = mlx5_vdpa_dev_add,
> .dev_del = mlx5_vdpa_dev_del,
> + .dev_set_attr = mlx5_vdpa_set_attr,
> };
>
> static struct virtio_device_id id_table[] = {
> --
> 2.45.0
>
Re: [PATCH 06/17] x86/numa: simplify numa_distance allocation
On Fri, Jul 19, 2024 at 05:28:49PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:35 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Allocation of numa_distance uses memblock_phys_alloc_range() to limit
> > allocation to be below the last mapped page.
> >
> > But NUMA initializaition runs after the direct map is populated and
>
> initialization (one too many 'i's)
Thanks.
> > there is also code in setup_arch() that adjusts memblock limit to
> > reflect how much memory is already mapped in the direct map.
> >
> > Simplify the allocation of numa_distance and use plain memblock_alloc().
> > This makes the code clearer and ensures that when numa_distance is not
> > allocated it is always NULL.
> Doesn't this break the comment in numa_set_distance() kernel-doc?
> "
> * If such table cannot be allocated, a warning is printed and further
> * calls are ignored until the distance table is reset with
> * numa_reset_distance().
> "
>
> Superficially that looks to be to avoid repeatedly hitting the
> singleton bit at the top of numa_set_distance() as SRAT or similar
> parsing occurs.
I believe it's there to avoid allocation of numa_distance in the middle of
distance parsing (SLIT or DT numa-distance-map).
If the allocation fails for the first element in the table, the
numa_distance and numa_distance_cnt remain zero and node_distance() falls
back to
return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
It's different from arch_numa that always tries to allocate MAX_NUMNODES *
MAX_NUMNODES for numa_distance and treats the allocation failure as a
failure to initialize NUMA.
I like the general approach x86 uses more, i.e. in case distance parsing
fails in some way NUMA is still initialized with probably suboptimal
distances between nodes.
I'm going to restore that "singleton" behavior for now and will look into
making this all less cumbersome later.
> > Signed-off-by: Mike Rapoport (Microsoft)
> > ---
> > arch/x86/mm/numa.c | 12 +++-
> > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > index 5e1dde26674b..ab2d4ecef786 100644
> > --- a/arch/x86/mm/numa.c
> > +++ b/arch/x86/mm/numa.c
> > @@ -319,8 +319,7 @@ void __init numa_reset_distance(void)
> > {
> > size_t size = numa_distance_cnt * numa_distance_cnt *
> > sizeof(numa_distance[0]);
> >
> > - /* numa_distance could be 1LU marking allocation failure, test cnt */
> > - if (numa_distance_cnt)
> > + if (numa_distance)
> > memblock_free(numa_distance, size);
> > numa_distance_cnt = 0;
> > numa_distance = NULL; /* enable table creation */
> > @@ -331,7 +330,6 @@ static int __init numa_alloc_distance(void)
> > nodemask_t nodes_parsed;
> > size_t size;
> > int i, j, cnt = 0;
> > - u64 phys;
> >
> > /* size the new table and allocate it */
> > nodes_parsed = numa_nodes_parsed;
> > @@ -342,16 +340,12 @@ static int __init numa_alloc_distance(void)
> > cnt++;
> > size = cnt * cnt * sizeof(numa_distance[0]);
> >
> > - phys = memblock_phys_alloc_range(size, PAGE_SIZE, 0,
> > -PFN_PHYS(max_pfn_mapped));
> > - if (!phys) {
> > + numa_distance = memblock_alloc(size, PAGE_SIZE);
> > + if (!numa_distance) {
> > pr_warn("Warning: can't allocate distance table!\n");
> > - /* don't retry until explicitly reset */
> > - numa_distance = (void *)1LU;
> > return -ENOMEM;
> > }
> >
> > - numa_distance = __va(phys);
> > numa_distance_cnt = cnt;
> >
> > /* fill with the default distances */
>
>
--
Sincerely yours,
Mike.
Re: [PATH v4 2/3] vdpa_sim_net: Add the support of set mac address
On Mon, 22 Jul 2024 at 15:48, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa_sim_net, the driver will write the MAC address
> > to the config space, and other devices can implement
> > their own functions to support this.
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > index cfe962911804..936e33e5021a 100644
> > --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > @@ -414,6 +414,25 @@ static void vdpasim_net_get_config(struct vdpasim
> > *vdpasim, void *config)
> > net_config->status = cpu_to_vdpasim16(vdpasim,
> > VIRTIO_NET_S_LINK_UP);
> > }
> >
> > +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> > + struct vdpa_device *dev,
> > + const struct vdpa_dev_set_config *config)
> > +{
> > + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> > + struct virtio_net_config *vio_config = vdpasim->config;
> > +
> > + mutex_lock(&vdpasim->mutex);
> > +
> > + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
> > + mutex_unlock(&vdpasim->mutex);
> > + return 0;
> > + }
> > +
> > + mutex_unlock(&vdpasim->mutex);
>
> Do we need to protect:
>
> case VIRTIO_NET_CTRL_MAC_ADDR_SET:
> read = vringh_iov_pull_iotlb(&cvq->vring, &cvq->in_iov,
> vio_config->mac, ETH_ALEN);
> if (read == ETH_ALEN)
> status = VIRTIO_NET_OK;
> break;
>
> As both are modifying vio_config?
>
> Thanks
>
i have added a lock for this; CVQ also needs to take this lock to
change the MAC address.I thinks maybe this can protect?
Do you mean I need to compare the mac address from the vdpa_tool and
mac address in vio_config?
this vdpa tool should not be used after the guest load, if this is
different this is also acceptable
thanks
Cindy
> > + return -EINVAL;
> > +}
> > +
> > static void vdpasim_net_setup_config(struct vdpasim *vdpasim,
> > const struct vdpa_dev_set_config
> > *config)
> > {
> > @@ -510,7 +529,8 @@ static void vdpasim_net_dev_del(struct vdpa_mgmt_dev
> > *mdev,
> >
> > static const struct vdpa_mgmtdev_ops vdpasim_net_mgmtdev_ops = {
> > .dev_add = vdpasim_net_dev_add,
> > - .dev_del = vdpasim_net_dev_del
> > + .dev_del = vdpasim_net_dev_del,
> > + .dev_set_attr = vdpasim_net_set_attr
> > };
> >
> > static struct virtio_device_id id_table[] = {
> > --
> > 2.45.0
> >
>
Re: [PATH v4 2/3] vdpa_sim_net: Add the support of set mac address
On Mon, Jul 22, 2024 at 3:57 PM Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 15:48, Jason Wang wrote:
> >
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa_sim_net, the driver will write the MAC address
> > > to the config space, and other devices can implement
> > > their own functions to support this.
> > >
> > > Signed-off-by: Cindy Lu
> > > ---
> > > drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +-
> > > 1 file changed, 21 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > index cfe962911804..936e33e5021a 100644
> > > --- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
> > > @@ -414,6 +414,25 @@ static void vdpasim_net_get_config(struct vdpasim
> > > *vdpasim, void *config)
> > > net_config->status = cpu_to_vdpasim16(vdpasim,
> > > VIRTIO_NET_S_LINK_UP);
> > > }
> > >
> > > +static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
> > > + struct vdpa_device *dev,
> > > + const struct vdpa_dev_set_config *config)
> > > +{
> > > + struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
> > > + struct virtio_net_config *vio_config = vdpasim->config;
> > > +
> > > + mutex_lock(&vdpasim->mutex);
> > > +
> > > + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
> > > + mutex_unlock(&vdpasim->mutex);
> > > + return 0;
> > > + }
> > > +
> > > + mutex_unlock(&vdpasim->mutex);
> >
> > Do we need to protect:
> >
> > case VIRTIO_NET_CTRL_MAC_ADDR_SET:
> > read = vringh_iov_pull_iotlb(&cvq->vring, &cvq->in_iov,
> > vio_config->mac, ETH_ALEN);
> > if (read == ETH_ALEN)
> > status = VIRTIO_NET_OK;
> > break;
> >
> > As both are modifying vio_config?
> >
> > Thanks
> >
> i have added a lock for this; CVQ also needs to take this lock to
> change the MAC address.I thinks maybe this can protect?
Right, I miss that it is done in the vdpasim_net_work().
> Do you mean I need to compare the mac address from the vdpa_tool and
> mac address in vio_config?
> this vdpa tool should not be used after the guest load, if this is
> different this is also acceptable
> thanks
The patch looks good then.
Acked-by: Jason Wang
Thanks
> Cindy
>
> > > + return -EINVAL;
> > > +}
> > > +
> > > static void vdpasim_net_setup_config(struct vdpasim *vdpasim,
> > > const struct vdpa_dev_set_config
> > > *config)
> > > {
> > > @@ -510,7 +529,8 @@ static void vdpasim_net_dev_del(struct vdpa_mgmt_dev
> > > *mdev,
> > >
> > > static const struct vdpa_mgmtdev_ops vdpasim_net_mgmtdev_ops = {
> > > .dev_add = vdpasim_net_dev_add,
> > > - .dev_del = vdpasim_net_dev_del
> > > + .dev_del = vdpasim_net_dev_del,
> > > + .dev_set_attr = vdpasim_net_set_attr
> > > };
> > >
> > > static struct virtio_device_id id_table[] = {
> > > --
> > > 2.45.0
> > >
> >
>
Re: [PATCH 12/17] mm: introduce numa_memblks
On Fri, Jul 19, 2024 at 07:16:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:41 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
> > options to let x86 select it in its Kconfig.
> >
> > This code will be later reused by arch_numa.
> >
> > No functional changes.
> >
> > Signed-off-by: Mike Rapoport (Microsoft)
> Hi Mike,
>
> My only real concern in here is there are a few places where
> the lifted code makes changes to memblocks that are x86 only today.
> I need to do some more digging to work out if those are safe
> in all cases.
>
> Jonathan
>
>
>
> > +/**
> > + * numa_cleanup_meminfo - Cleanup a numa_meminfo
> > + * @mi: numa_meminfo to clean up
> > + *
> > + * Sanitize @mi by merging and removing unnecessary memblks. Also check
> > for
> > + * conflicts and clear unused memblks.
> > + *
> > + * RETURNS:
> > + * 0 on success, -errno on failure.
> > + */
> > +int __init numa_cleanup_meminfo(struct numa_meminfo *mi)
> > +{
> > + const u64 low = 0;
>
> Given always zero, why not just use that value inline?
Actually it seems to me that it should be memblock_start_of_DRAM().
The blocks outside system memory are moved to numa_reserved_meminfo, so
AFAIU on arm64/riscv such blocks can be below the RAM.
> > + const u64 high = PFN_PHYS(max_pfn);
> > + int i, j, k;
> > +
> > + /* first, trim all entries */
> > + for (i = 0; i < mi->nr_blks; i++) {
> > + struct numa_memblk *bi = &mi->blk[i];
> > +
> > + /* move / save reserved memory ranges */
> > + if (!memblock_overlaps_region(&memblock.memory,
> > + bi->start, bi->end - bi->start)) {
> > + numa_move_tail_memblk(&numa_reserved_meminfo, i--, mi);
> > + continue;
> > + }
> > +
> > + /* make sure all non-reserved blocks are inside the limits */
> > + bi->start = max(bi->start, low);
> > +
> > + /* preserve info for non-RAM areas above 'max_pfn': */
> > + if (bi->end > high) {
> > + numa_add_memblk_to(bi->nid, high, bi->end,
> > + &numa_reserved_meminfo);
> > + bi->end = high;
> > + }
> > +
> > + /* and there's no empty block */
> > + if (bi->start >= bi->end)
> > + numa_remove_memblk_from(i--, mi);
> > + }
> > +
> > + /* merge neighboring / overlapping entries */
> > + for (i = 0; i < mi->nr_blks; i++) {
> > + struct numa_memblk *bi = &mi->blk[i];
> > +
> > + for (j = i + 1; j < mi->nr_blks; j++) {
> > + struct numa_memblk *bj = &mi->blk[j];
> > + u64 start, end;
> > +
> > + /*
> > +* See whether there are overlapping blocks. Whine
> > +* about but allow overlaps of the same nid. They
> > +* will be merged below.
> > +*/
> > + if (bi->end > bj->start && bi->start < bj->end) {
> > + if (bi->nid != bj->nid) {
> > + pr_err("node %d [mem %#010Lx-%#010Lx]
> > overlaps with node %d [mem %#010Lx-%#010Lx]\n",
> > + bi->nid, bi->start, bi->end - 1,
> > + bj->nid, bj->start, bj->end - 1);
> > + return -EINVAL;
> > + }
> > + pr_warn("Warning: node %d [mem %#010Lx-%#010Lx]
> > overlaps with itself [mem %#010Lx-%#010Lx]\n",
> > + bi->nid, bi->start, bi->end - 1,
> > + bj->start, bj->end - 1);
> > + }
> > +
> > + /*
> > +* Join together blocks on the same node, holes
> > +* between which don't overlap with memory on other
> > +* nodes.
> > +*/
> > + if (bi->nid != bj->nid)
> > + continue;
> > + start = min(bi->start, bj->start);
> > + end = max(bi->end, bj->end);
> > + for (k = 0; k < mi->nr_blks; k++) {
> > + struct numa_memblk *bk = &mi->blk[k];
> > +
> > + if (bi->nid == bk->nid)
> > + continue;
> > + if (start < bk->end && end > bk->start)
> > + break;
> > + }
> > + if (k < mi->nr_blks)
> > + continue;
> > + pr_info("NUMA: Node %d [mem %#010Lx-%#010Lx] + [mem
> > %#010Lx-%#010Lx] -> [mem %#010Lx-%#010Lx]\n",
> > + bi->nid, bi->start, bi->en
Re: [PATCH 15/17] mm: make numa_memblks more self-contained
On Fri, Jul 19, 2024 at 07:07:12PM +0100, Jonathan Cameron wrote: > On Tue, 16 Jul 2024 14:13:44 +0300 > Mike Rapoport wrote: > > > From: "Mike Rapoport (Microsoft)" > > > > Introduce numa_memblks_init() and move some code around to avoid several > > global variables in numa_memblks. > > Hi Mike, > > Adding the effectively always on memblock_force_top_down > deserves a comment on why. I assume because you are going to do > something with it later? > > There also seems to be more going on in here such as the change to > get_pfn_range_for_nid() Perhaps break this up so each > change can have an explanation. I'll split this into several commits. -- Sincerely yours, Mike.
Re: [PATCH 00/17] mm: introduce numa_memblks
On Fri, Jul 19, 2024 at 02:33:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:29 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Hi,
> >
> > Following the discussion about handling of CXL fixed memory windows on
> > arm64 [1] I decided to bite the bullet and move numa_memblks from x86 to
> > the generic code so they will be available on arm64/riscv and maybe on
> > loongarch sometime later.
> >
> > While it could be possible to use memblock to describe CXL memory windows,
> > it currently lacks notion of unpopulated memory ranges and numa_memblks
> > does implement this.
> >
> > Another reason to make numa_memblks generic is that both arch_numa (arm64
> > and riscv) and loongarch use trimmed copy of x86 code although there is no
> > fundamental reason why the same code cannot be used on all these platforms.
> > Having numa_memblks in mm/ will make it's interaction with ACPI and FDT
> > more consistent and I believe will reduce maintenance burden.
> >
> > And with generic numa_memblks it is (almost) straightforward to enable NUMA
> > emulation on arm64 and riscv.
> >
> > The first 5 commits in this series are cleanups that are not strictly
> > related to numa_memblks.
> >
> > Commits 6-11 slightly reorder code in x86 to allow extracting numa_memblks
> > and NUMA emulation to the generic code.
> >
> > Commits 12-14 actually move the code from arch/x86/ to mm/ and commit 15
> > does some aftermath cleanups.
> >
> > Commit 16 switches arch_numa to numa_memblks.
> >
> > Commit 17 enables usage of phys_to_target_node() and
> > memory_add_physaddr_to_nid() with numa_memblks.
>
> Hi Mike,
>
> I've lightly tested with emulated CXL + Generic Ports and Generic
> Initiators as well as more normal cpus and memory via qemu on arm64 and it's
> looking good.
>
> From my earlier series, patch 4 is probably still needed to avoid
> presenting nodes with nothing in them at boot (but not if we hotplug
> memory then remove it again in which case they disappear)
> https://lore.kernel.org/all/20240529171236.32002-5-jonathan.came...@huawei.com/
> However that was broken/inconsistent before your rework so I can send that
> patch separately.
I'd appreciate it :)
> Thanks for getting this sorted! I should get time to do more extensive
> testing and review in next week or so.
Thanks, you may want to wait for v2, I'm planning to send it this week.
> Jonathan
>
> >
> > [1]
> > https://lore.kernel.org/all/20240529171236.32002-1-jonathan.came...@huawei.com/
> >
> > Mike Rapoport (Microsoft) (17):
> > mm: move kernel/numa.c to mm/
> > MIPS: sgi-ip27: make NODE_DATA() the same as on all other
> > architectures
> > MIPS: loongson64: rename __node_data to node_data
> > arch, mm: move definition of node_data to generic code
> > arch, mm: pull out allocation of NODE_DATA to generic code
> > x86/numa: simplify numa_distance allocation
> > x86/numa: move FAKE_NODE_* defines to numa_emu
> > x86/numa_emu: simplify allocation of phys_dist
> > x86/numa_emu: split __apicid_to_node update to a helper function
> > x86/numa_emu: use a helper function to get MAX_DMA32_PFN
> > x86/numa: numa_{add,remove}_cpu: make cpu parameter unsigned
> > mm: introduce numa_memblks
> > mm: move numa_distance and related code from x86 to numa_memblks
> > mm: introduce numa_emulation
> > mm: make numa_memblks more self-contained
> > arch_numa: switch over to numa_memblks
> > mm: make range-to-target_node lookup facility a part of numa_memblks
> >
> > arch/arm64/include/asm/Kbuild | 1 +
> > arch/arm64/include/asm/mmzone.h | 13 -
> > arch/arm64/include/asm/topology.h | 1 +
> > arch/loongarch/include/asm/Kbuild | 1 +
> > arch/loongarch/include/asm/mmzone.h | 16 -
> > arch/loongarch/include/asm/topology.h | 1 +
> > arch/loongarch/kernel/numa.c | 21 -
> > arch/mips/include/asm/mach-ip27/mmzone.h | 1 -
> > .../mips/include/asm/mach-loongson64/mmzone.h | 4 -
> > arch/mips/loongson64/numa.c | 20 +-
> > arch/mips/sgi-ip27/ip27-memory.c | 2 +-
> > arch/powerpc/include/asm/mmzone.h | 6 -
> > arch/powerpc/mm/numa.c| 26 +-
> > arch/riscv/include/asm/Kbuild | 1 +
> > arch/riscv/include/asm/mmzone.h | 13 -
> > arch/riscv/include/asm/topology.h | 4 +
> > arch/s390/include/asm/Kbuild | 1 +
> > arch/s390/include/asm/mmzone.h| 17 -
> > arch/s390/kernel/numa.c | 3 -
> > arch/sh/include/asm/mmzone.h | 3 -
> > arch/sh/mm/init.c | 7 +-
> > arch/sh/mm/numa.c | 3 -
> > arch/sparc/include/asm/mmzone.h | 4 -
> > arch/sparc/mm/init_64.c | 11 +-
> > arch/x86/Kconfig
Re: [PATCH 00/15] Implement MODVERSIONS for Rust
On 7/15/24 22:39, Sami Tolvanen wrote:
> On Wed, Jul 10, 2024 at 7:30 AM Petr Pavlu wrote:
>> On 6/17/24 19:58, Sami Tolvanen wrote:
>>> The first 12 patches of this series add a small tool for computing
>>> symbol versions from DWARF, called gendwarfksyms. When passed a list
>>> of exported symbols, the tool generates an expanded type string
>>> for each symbol, and computes symbol CRCs similarly to genksyms.
>>> gendwarfksyms is written in C and uses libdw to process DWARF, mainly
>>> because of the existing support for C host tools that use elfutils
>>> (e.g., objtool).
>>
>> In addition to calculating CRCs of exported symbols, genksyms has other
>> features which I think are important.
>>
>> Firstly, the genksyms tool has a human-readable storage format for input
>> data used in the calculation of symbol CRCs. Setting the make variable
>> KBUILD_SYMTYPES enables dumping this data and storing it in *.symtypes
>> files.
>>
>> When a developer later modifies the kernel and wants to check if some
>> symbols have changed, they can take these files and feed them as
>> *.symref back to genksyms. This allows the tool to provide an actual
>> reason why some symbols have changed, instead of just printing that
>> their CRCs are different.
>>
>> Is there any plan to add the same functionality to gendwarfksyms, or do
>> you envison that people will use libabigail, Symbol-Type Graph, or
>> another tool for making this type of comparison?
>
> gendwarfksyms also uses human-readable input for the CRC calculations,
> and it prints out the input strings with the --debug option. I plan to
> hook this up to KBUILD_SYMTYPES in v2. It should be convenient enough
> to simply compare the pretty-printed output with diff, so I'm not sure
> if a built-in comparison option is needed. Any other DWARF analysis
> tool can be used to spot the differences too, as you mentioned.
>From my perspective, I'm okay if gendwarfksyms doesn't provide
functionality to compare a new object file with its reference symtypes
file.
As mentioned, genksyms has this functionality but I actually think the
way it works is not ideal. Its design is to operate on one compilation
unit at the time. This has the advantage that a comparison of each file
is performed in parallel during the build, simply because of the make
job system. On the other hand, it has two problems.
The first one is that genksyms doesn't provide a comparison of the
kernel as a whole. This means that the tool gives rather scattered and
duplicated output about changed structs in the build log. Ideally, one
would like to see a single compact report about what changed at the end
of the build.
The second problem is the handling of symtypes files. This data is large
and if one wants to store them in a Git repository together with the
kernel source, it is advisable to first compress/consolidate it in some
way. This is trivial because these files typically contain many
duplicates. However, the issue is that to feed the data back to
genksyms, they need to be unpacked during each build which can take some
time.
I think a better approach is to have a tool that can be given
a consolidated symtypes file as one input and can compare it with all
new symtypes files produced during a kernel build. An example of a tool
that takes this approach is the kabi Python script in UEK [1].
A few months ago, I also started working on a tool inspired by this
script. The goal is to have similar functionality but hopefully with
a much faster implementation. Hence, this tool is written in a compiled
language (Rust at the moment) and should also become multi-threaded. I'm
hoping to find some time to make progress on it and make the code
public. It could later be added to the upstream kernel to replace the
comparison functionality implemented by genksyms, if there is interest.
So as mentioned, I'm fine if gendwarfksyms doesn't have this
functionality. However, for distributions that rely on the symtypes
format, I'd be interested in having gendwarfksyms output its dump data
in this format as well.
For example, instead of producing:
gendwarfksyms: process_exported_symbols: _some_mangled_func_name (@ XYZ)
subprogram(
[formal parameters...]
)
-> structure_type core::result::Result<(), core::fmt::Error> {
[a description of the structure...]
};
.. the output could be something like this:
S#'core::result::Result<(), core::fmt::Error>' structure_type
core::result::Result<(), core::fmt::Error> { [a description of the
structure...] }
_some_mangled_func_name subprogram _some_mangled_func_name ( [formal
parameters...] ) -> S#'core::result::Result<(), core::fmt::Error>'
>> Secondly, when distributions want to maintain stable kABI, they need to
>> be able to deal with patch backports that add new members to structures.
>> One common approach is to have placeholders in important structures
>> which can be later replaced by the new members as needed. __GENKSYMS__
>> ifdefs are then used at the C source level to hide
Re: [PATCH 01/12] arm64: dts: qcom: sm6115-pro1x: Add Hall Switch and Camera Button
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Pro1X has a flip keyboard and a single-state camera button.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 33
> +++--
> 1 file changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index 4a30024aa48f..5b7dd54be6b6 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -34,9 +34,24 @@ framebuffer0: framebuffer@5c00 {
>
> gpio-keys {
> compatible = "gpio-keys";
> -
> - pinctrl-0 = <&vol_up_n>;
> pinctrl-names = "default";
> + pinctrl-0 = <&hall_sensor_n>, <&key_camera_n>, <&vol_up_n>;
Please don't reorder these
looks good otherwise
Konrad
Re: [PATCH 02/12] arm64: dts: qcom: sm6115-pro1x: Add PCA9534 IO Expander
On 22.07.2024 9:10 AM, Dang Huynh wrote: > F(x)tec Pro1X comes with PCA9534 IO Expander, it is used for enabling > touch screen VDD/VDDIO and keyboard's caps lock LED. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 03/12] arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Fxtec Pro1X touchscreen uses Goodix GT9286 chip.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 49
> +
> 1 file changed, 49 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index 43b4bee72dd8..d91d31646b29 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -62,6 +62,20 @@ key-volume-up {
> wakeup-source;
> };
> };
> +
> + ts_vdd_supply: ts-vdd-supply {
> + compatible = "regulator-fixed";
> + regulator-name = "ts_vdd_supply";
> + gpio = <&pca9534 3 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + ts_vddio_supply: ts-vddio-supply {
> + compatible = "regulator-fixed";
> + regulator-name = "ts_vddio_supply";
> + gpio = <&pca9534 2 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
I suppose you don't know the voltages for these?
> };
>
> &dispcc {
> @@ -86,6 +100,27 @@ pca9534: gpio@21 {
> };
> };
>
> +&i2c2 {
> + status = "okay";
> + /* Clock frequency was not specified downstream, let's park it to 100
> KHz */
> + clock-frequency = <10>;
> +
> + touchscreen@14 {
> + compatible = "goodix,gt9286";
> + reg = <0x14>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_int_n>, <&ts_rst_n>;
reverse order, shift these down below supplies
> +
> + interrupt-parent = <&tlmm>;
> + interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
interrupts-extended
Konrad
Re: [PATCH 04/12] arm64: dts: qcom: sm6115-pro1x: Add Caps Lock LED
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Pro1X has a caps lock LED on the keyboard.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index d91d31646b29..60c046fe8e52 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -8,6 +8,7 @@
> #include "sm6115.dtsi"
> #include "pm6125.dtsi"
> #include
> +#include
>
> / {
> model = "F(x)tec Pro1X (QX1050)";
> @@ -63,6 +64,16 @@ key-volume-up {
> };
> };
>
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + capslock-led {
> + color = ;
> + function = LED_FUNCTION_CAPSLOCK;
> + gpios = <&pca9534 1 GPIO_ACTIVE_HIGH>;
You may want to take a look at msm8998-fxtec-pro1.dts which has a
bit more properties describing it
Konrad
Re: [PATCH 03/12] arm64: dts: qcom: sm6115-pro1x: Add Goodix Touchscreen
> On 22.07.2024 9:10 AM, Dang Huynh wrote:
> > +
> > + ts_vdd_supply: ts-vdd-supply {
> > + compatible = "regulator-fixed";
> > + regulator-name = "ts_vdd_supply";
> > + gpio = <&pca9534 3 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > + ts_vddio_supply: ts-vddio-supply {
> > + compatible = "regulator-fixed";
> > + regulator-name = "ts_vddio_supply";
> > + gpio = <&pca9534 2 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
>
> I suppose you don't know the voltages for these?
>
Nope, no schematics to verify.
Re: [PATCH 06/12] arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> Fxtec Pro1x uses the same display (BOE BF060Y8M-AJ0) as Pro1.
>
> Signed-off-by: Dang Huynh
> ---
[...]
> + panel: panel@0 {
> + compatible = "boe,bf060y8m-aj0";
> + reg = <0>;
> +
> + reset-gpios = <&tlmm 82 GPIO_ACTIVE_LOW>;
> +
> + vddio-supply = <&pm6125_l9a>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdss_dsi_n &panel_en_n>;
pinctrl-n
pinctrl-names
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&mdss_dsi0_out>;
> + };
> + };
> + };
> +};
> +
> +&mdss_dsi0_out {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&panel_in>;
> +};
> +
> +&mdss_dsi0_phy {
> + status = "okay";
No power supplies?
Konrad
Re: [PATCH 10/12] arm64: dts: qcom: sm6115-pro1x: Enable RGB LED
On 22.07.2024 9:10 AM, Dang Huynh wrote: > This device has an RGB LED. It is used for notifications. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 12/12] arm64: dts: qcom: sm6115-pro1x: Enable ATH10K WLAN
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> Enable onboard Wi-Fi on the F(x)tec Pro1X.
>
> For reference, HW/SW identifies as:
> qmi chip_id 0x120 chip_family 0x4007 board_id 0xff soc_id 0x4067
> qmi fw_version 0x324103d6 fw_build_timestamp 2021-12-02 08:20
> fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.4-00982-QCAHLSWMTPLZ-1
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> index 14d4f533f741..c148ebd1c8b4 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> +++ b/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
> @@ -531,6 +531,17 @@ &usb_qmpphy_out {
> remote-endpoint = <&pmi632_ss_in>;
> };
>
> +&wifi {
> + status = "okay";
status goes last
Konrad
[PATCH 0/2] module: Split modules_install compression and in-kernel decompression
Allow enabling the in-kernel module decompression support separately, without requiring to enable also the automatic compression during 'make modules_install'. Petr Pavlu (2): module: Split modules_install compression and in-kernel decompression module: Clean up the description of MODULE_SIG_ kernel/module/Kconfig| 77 scripts/Makefile.modinst | 2 ++ 2 files changed, 41 insertions(+), 38 deletions(-) base-commit: 933069701c1b507825b514317d4edd5d3fd9d417 -- 2.35.3
[PATCH 1/2] module: Split modules_install compression and in-kernel decompression
The kernel configuration allows specifying a module compression mode. If one is selected then each module gets compressed during 'make modules_install' and additionally one can also enable support for a respective direct in-kernel decompression support. This means that the decompression support cannot be enabled without the automatic compression. Some distributions, such as the (open)SUSE family, use a signer service for modules. A build runs on a worker machine but signing is done by a separate locked-down server that is in possession of the signing key. The build invokes 'make modules_install' to create a modules tree, collects information about the modules, asks the signer service for their signature, appends each signature to the respective module and compresses all modules. When using this arrangment, the 'make modules_install' step produces unsigned+uncompressed modules and the distribution's own build recipe takes care of signing and compression later. The signing support can be currently enabled without automatically signing modules during 'make modules_install'. However, the in-kernel decompression support can be selected only after first enabling automatic compression during this step. To allow only enabling the in-kernel decompression support without the automatic compression during 'make modules_install', separate the compression options similarly to the signing options, as follows: > Enable loadable module support [*] Module compression Module compression type (GZIP) ---> [*] Automatically compress all modules [ ] Support in-kernel module decompression * "Module compression" (MODULE_COMPRESS) is a new main switch for the compression/decompression support. It replaces MODULE_COMPRESS_NONE. * "Module compression type" (MODULE_COMPRESS_) chooses the compression type, one of GZ, XZ, ZSTD. * "Automatically compress all modules" (MODULE_COMPRESS_ALL) is a new option to enable module compression during 'make modules_install'. It defaults to Y. * "Support in-kernel module decompression" (MODULE_DECOMPRESS) enables in-kernel decompression. Signed-off-by: Petr Pavlu --- kernel/module/Kconfig| 61 scripts/Makefile.modinst | 2 ++ 2 files changed, 33 insertions(+), 30 deletions(-) diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig index 4047b6d48255..bb7f7930fef6 100644 --- a/kernel/module/Kconfig +++ b/kernel/module/Kconfig @@ -278,64 +278,65 @@ config MODULE_SIG_HASH default "sha3-384" if MODULE_SIG_SHA3_384 default "sha3-512" if MODULE_SIG_SHA3_512 -choice - prompt "Module compression mode" +config MODULE_COMPRESS + bool "Module compression" help - This option allows you to choose the algorithm which will be used to - compress modules when 'make modules_install' is run. (or, you can - choose to not compress modules at all.) - - External modules will also be compressed in the same way during the - installation. - - For modules inside an initrd or initramfs, it's more efficient to - compress the whole initrd or initramfs instead. - + Enable module compression to reduce on-disk size of module binaries. This is fully compatible with signed modules. - Please note that the tool used to load modules needs to support the - corresponding algorithm. module-init-tools MAY support gzip, and kmod - MAY support gzip, xz and zstd. + The tool used to work with modules needs to support the selected + compression type. kmod MAY support gzip, xz and zstd. Other tools + might have a limited selection of the supported types. - Your build system needs to provide the appropriate compression tool - to compress the modules. + Note that for modules inside an initrd or initramfs, it's more + efficient to compress the whole ramdisk instead. - If in doubt, select 'None'. + If unsure, say N. -config MODULE_COMPRESS_NONE - bool "None" +choice + prompt "Module compression type" + depends on MODULE_COMPRESS help - Do not compress modules. The installed modules are suffixed - with .ko. + Choose the supported algorithm for module compression. config MODULE_COMPRESS_GZIP bool "GZIP" help - Compress modules with GZIP. The installed modules are suffixed - with .ko.gz. + Support modules compressed with GZIP. The installed modules are + suffixed with .ko.gz. config MODULE_COMPRESS_XZ bool "XZ" help - Compress modules with XZ. The installed modules are suffixed - with .ko.xz. + Support modules compressed with XZ. The installed modules are + suffixed with .ko.xz. config MODULE_COMPRESS_ZSTD bool "ZSTD" help - Compress modules with ZSTD. The installed modules are suffixed -
[PATCH 2/2] module: Clean up the description of MODULE_SIG_
The MODULE_SIG_ config choice has an inconsistent prompt styled as a question and lengthy option names. Simplify the prompt and option names to be consistent with other module options. Signed-off-by: Petr Pavlu --- kernel/module/Kconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig index bb7f7930fef6..ccdbd1bc12aa 100644 --- a/kernel/module/Kconfig +++ b/kernel/module/Kconfig @@ -228,7 +228,7 @@ comment "Do not forget to sign required modules with scripts/sign-file" depends on MODULE_SIG_FORCE && !MODULE_SIG_ALL choice - prompt "Which hash algorithm should modules be signed with?" + prompt "Hash algorithm to sign modules" depends on MODULE_SIG || IMA_APPRAISE_MODSIG help This determines which sort of hashing algorithm will be used during @@ -238,31 +238,31 @@ choice the signature on that module. config MODULE_SIG_SHA1 - bool "Sign modules with SHA-1" + bool "SHA-1" select CRYPTO_SHA1 config MODULE_SIG_SHA256 - bool "Sign modules with SHA-256" + bool "SHA-256" select CRYPTO_SHA256 config MODULE_SIG_SHA384 - bool "Sign modules with SHA-384" + bool "SHA-384" select CRYPTO_SHA512 config MODULE_SIG_SHA512 - bool "Sign modules with SHA-512" + bool "SHA-512" select CRYPTO_SHA512 config MODULE_SIG_SHA3_256 - bool "Sign modules with SHA3-256" + bool "SHA3-256" select CRYPTO_SHA3 config MODULE_SIG_SHA3_384 - bool "Sign modules with SHA3-384" + bool "SHA3-384" select CRYPTO_SHA3 config MODULE_SIG_SHA3_512 - bool "Sign modules with SHA3-512" + bool "SHA3-512" select CRYPTO_SHA3 endchoice -- 2.35.3
Re: [PATCH 06/12] arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU
> > +&mdss_dsi0_phy {
> > + status = "okay";
>
> No power supplies?
>
> Konrad
Doesn't seem to be defined anywhere on downstream, may be hardware controlled.
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > to set the mac address
> >
> > Tested in ConnectX-6 Dx device
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index ecfc16151d61..415b527a9c72 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> > *v_mdev, struct vdpa_device *
> > destroy_workqueue(wq);
> > mgtdev->ndev = NULL;
> > }
> > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > + struct vdpa_device *dev,
> > + const struct vdpa_dev_set_config *add_config)
> > +{
> > + struct mlx5_vdpa_dev *mvdev;
> > + struct mlx5_vdpa_net *ndev;
> > + struct mlx5_core_dev *mdev;
> > + struct virtio_net_config *config;
> > + struct mlx5_core_dev *pfmdev;
Reverse xmas tree?
> > + int err = -EOPNOTSUPP;
> > +
> > + mvdev = to_mvdev(dev);
> > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > + mdev = mvdev->mdev;
> > + config = &ndev->config;
> > +
You still need to take the ndev->reslock.
> > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > + if (!err)
> > + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
What is the expected behaviour when the device is in use?
> > + }
> > + return err;
>
> Similar to net simulator, how could be serialize the modification to
> mac address:
>
> 1) from vdpa tool
> 2) via control virtqueue
>
> Thanks
>
> > +}
> >
> > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > .dev_add = mlx5_vdpa_dev_add,
> > .dev_del = mlx5_vdpa_dev_del,
> > + .dev_set_attr = mlx5_vdpa_set_attr,
> > };
> >
> > static struct virtio_device_id id_table[] = {
> > --
> > 2.45.0
> >
>
Thanks,
Dragos
[PATCH 0/4] MSM8953/MSM8976 ASoC support
Introduce support for basic sound card setup on MSM8953/MSM8976 platforms, document new compatibles and introduce support for more dais. Most of code is sourced from msm8953-mainline fork over github with some changes implemented by me,some basic changes are mentioned in each patch. Adam Skladowski (1): ASoC: dt-bindings: qcom,sm8250: Add msm8953/msm8976-qdsp6-sndcard Vladimir Lypak (3): ASoC: qcom: apq8016_sbc.c: Add Quinary support ASoC: msm8916-wcd-analog: add cajon and cajon v2 support ASoC: qcom: apq8016_sbc: Add support for msm8953/msm8976 SoC .../bindings/sound/qcom,sm8250.yaml | 28 ++- sound/soc/codecs/msm8916-wcd-analog.c | 63 +- sound/soc/qcom/apq8016_sbc.c | 82 ++- 3 files changed, 164 insertions(+), 9 deletions(-) -- 2.45.2
[PATCH 1/4] ASoC: qcom: apq8016_sbc.c: Add Quinary support
From: Vladimir Lypak
Add support for configuring Quinary Mi2S interface
it will be used on MSM8953 and MSM8976 platform.
Signed-off-by: Vladimir Lypak
[Adam: Split from MSM8953 support patch,add msg]
Signed-off-by: Adam Skladowski
---
sound/soc/qcom/apq8016_sbc.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c
index 3023cf180a75..8971f4f5d339 100644
--- a/sound/soc/qcom/apq8016_sbc.c
+++ b/sound/soc/qcom/apq8016_sbc.c
@@ -20,12 +20,13 @@
#include "common.h"
#include "qdsp6/q6afe.h"
-#define MI2S_COUNT (MI2S_QUATERNARY + 1)
+#define MI2S_COUNT (MI2S_QUINARY + 1)
struct apq8016_sbc_data {
struct snd_soc_card card;
void __iomem *mic_iomux;
void __iomem *spkr_iomux;
+ void __iomem *quin_iomux;
struct snd_soc_jack jack;
bool jack_setup;
int mi2s_clk_count[MI2S_COUNT];
@@ -86,6 +87,12 @@ static int apq8016_dai_init(struct snd_soc_pcm_runtime *rtd,
int mi2s)
SPKR_CTL_TLMM_DATA1_EN | SPKR_CTL_TLMM_WS_OUT_SEL_SEC |
SPKR_CTL_TLMM_WS_EN_SEL_SEC, pdata->spkr_iomux);
break;
+ case MI2S_QUINARY:
+ /* Configure Quinary MI2S */
+ if (!pdata->quin_iomux)
+ return -ENOENT;
+ writel(readl(pdata->quin_iomux) | 0x01, pdata->quin_iomux);
+ break;
case MI2S_TERTIARY:
writel(readl(pdata->mic_iomux) | MIC_CTRL_TER_WS_SLAVE_SEL |
MIC_CTRL_TLMM_SCLK_EN,
@@ -177,6 +184,9 @@ static int qdsp6_dai_get_lpass_id(struct snd_soc_dai
*cpu_dai)
case QUATERNARY_MI2S_RX:
case QUATERNARY_MI2S_TX:
return MI2S_QUATERNARY;
+ case QUINARY_MI2S_RX:
+ case QUINARY_MI2S_TX:
+ return MI2S_QUINARY;
default:
return -EINVAL;
}
@@ -320,6 +330,10 @@ static int apq8016_sbc_platform_probe(struct
platform_device *pdev)
if (IS_ERR(data->spkr_iomux))
return PTR_ERR(data->spkr_iomux);
+ data->quin_iomux = devm_platform_ioremap_resource_byname(pdev,
"quin-iomux");
+ if (IS_ERR(data->quin_iomux))
+ return PTR_ERR(data->quin_iomux);
+
snd_soc_card_set_drvdata(card, data);
add_ops(card);
--
2.45.2
[PATCH 2/4] ASoC: msm8916-wcd-analog: add cajon and cajon v2 support
From: Vladimir Lypak
Add regs overrides for Cajon(PM8952) and Cajon v2(PM8953) codecs.
Signed-off-by: Vladimir Lypak
[Adam: Add Cajon support,add msg]
Co-developed-by: Adam Skladowski
Signed-off-by: Adam Skladowski
---
sound/soc/codecs/msm8916-wcd-analog.c | 63 +--
1 file changed, 60 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/msm8916-wcd-analog.c
b/sound/soc/codecs/msm8916-wcd-analog.c
index 9ca381812975..daf65f5d4e99 100644
--- a/sound/soc/codecs/msm8916-wcd-analog.c
+++ b/sound/soc/codecs/msm8916-wcd-analog.c
@@ -250,6 +250,7 @@
SPKR_DRV_CAL_EN | SPKR_DRV_SETTLE_EN | \
SPKR_DRV_FW_EN | SPKR_DRV_BOOST_SET | \
SPKR_DRV_CMFB_SET | SPKR_DRV_GAIN_SET)
+#define CDC_A_SPKR_ANA_BIAS_SET(0xf1B3)
#define CDC_A_SPKR_OCP_CTL (0xf1B4)
#define CDC_A_SPKR_PWRSTG_CTL (0xf1B5)
#define SPKR_PWRSTG_CTL_DAC_EN_MASKBIT(0)
@@ -264,12 +265,15 @@
#define CDC_A_SPKR_DRV_DBG (0xf1B7)
#define CDC_A_CURRENT_LIMIT(0xf1C0)
+#define CDC_A_BYPASS_MODE (0xf1C2)
#define CDC_A_BOOST_EN_CTL (0xf1C3)
#define CDC_A_SLOPE_COMP_IP_ZERO (0xf1C4)
#define CDC_A_SEC_ACCESS (0xf1D0)
#define CDC_A_PERPH_RESET_CTL3 (0xf1DA)
#define CDC_A_PERPH_RESET_CTL4 (0xf1DB)
+#define CDC_A_RX_EAR_STATUS(0xf1A1)
+
#define MSM8916_WCD_ANALOG_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 |\
SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_48000)
#define MSM8916_WCD_ANALOG_FORMATS (SNDRV_PCM_FMTBIT_S16_LE |\
@@ -715,6 +719,50 @@ static const struct reg_default wcd_reg_defaults_2_0[] = {
{CDC_A_MASTER_BIAS_CTL, 0x30},
};
+static const struct reg_default wcd_reg_defaults_cajon[] = {
+ {CDC_A_RX_COM_OCP_CTL, 0xD1},
+ {CDC_A_RX_COM_OCP_COUNT, 0xFF},
+ {CDC_D_SEC_ACCESS, 0xA5},
+ {CDC_D_PERPH_RESET_CTL3, 0x0F},
+ {CDC_A_TX_1_2_OPAMP_BIAS, 0x4C},
+ {CDC_A_NCP_FBCTRL, 0xA8},
+ {CDC_A_NCP_VCTRL, 0xA4},
+ {CDC_A_SPKR_DRV_CTL, 0x69},
+ {CDC_A_SPKR_DRV_DBG, 0x01},
+ {CDC_A_SEC_ACCESS, 0xA5},
+ {CDC_A_PERPH_RESET_CTL3, 0x0F},
+ {CDC_A_CURRENT_LIMIT, 0x82},
+ {CDC_A_SPKR_ANA_BIAS_SET, 0x41},
+ {CDC_A_SPKR_DAC_CTL, 0x03},
+ {CDC_A_SPKR_OCP_CTL, 0xE1},
+ {CDC_A_RX_HPH_BIAS_PA, 0xFA},
+ {CDC_A_MASTER_BIAS_CTL, 0x30},
+ {CDC_A_MICB_1_INT_RBIAS, 0x00},
+};
+
+static const struct reg_default wcd_reg_defaults_cajon_2_0[] = {
+ {CDC_A_RX_COM_OCP_CTL, 0xD1},
+ {CDC_A_RX_COM_OCP_COUNT, 0xFF},
+ {CDC_D_SEC_ACCESS, 0xA5},
+ {CDC_D_PERPH_RESET_CTL3, 0x0F},
+ {CDC_A_TX_1_2_OPAMP_BIAS, 0x4C},
+ {CDC_A_NCP_FBCTRL, 0xA8},
+ {CDC_A_NCP_VCTRL, 0xA4},
+ {CDC_A_SPKR_DRV_CTL, 0x69},
+ {CDC_A_SPKR_DRV_DBG, 0x01},
+ {CDC_A_SEC_ACCESS, 0xA5},
+ {CDC_A_PERPH_RESET_CTL3, 0x0F},
+ {CDC_A_CURRENT_LIMIT, 0xA2},
+ {CDC_A_BYPASS_MODE, 0x18},
+ {CDC_A_SPKR_ANA_BIAS_SET, 0x41},
+ {CDC_A_SPKR_DAC_CTL, 0x03},
+ {CDC_A_SPKR_OCP_CTL, 0xE1},
+ {CDC_A_RX_HPH_BIAS_PA, 0xFA},
+ {CDC_A_RX_EAR_STATUS, 0x10},
+ {CDC_A_MASTER_BIAS_CTL, 0x30},
+ {CDC_A_MICB_1_INT_RBIAS, 0x00},
+};
+
static int pm8916_wcd_analog_probe(struct snd_soc_component *component)
{
struct pm8916_wcd_analog_priv *priv = dev_get_drvdata(component->dev);
@@ -738,9 +786,18 @@ static int pm8916_wcd_analog_probe(struct
snd_soc_component *component)
snd_soc_component_write(component, CDC_D_PERPH_RESET_CTL4, 0x01);
snd_soc_component_write(component, CDC_A_PERPH_RESET_CTL4, 0x01);
- for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_2_0); reg++)
- snd_soc_component_write(component,
wcd_reg_defaults_2_0[reg].reg,
- wcd_reg_defaults_2_0[reg].def);
+ if (priv->codec_version == 4)
+ for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_cajon_2_0);
reg++)
+ snd_soc_component_write(component,
wcd_reg_defaults_cajon_2_0[reg].reg,
+ wcd_reg_defaults_cajon_2_0[reg].def);
+ else if (priv->codec_version == 3)
+ for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_cajon); reg++)
+ snd_soc_component_write(component,
wcd_reg_defaults_cajon[reg].reg,
+ wcd_reg_defaults_cajon[reg].def);
+ else
+ for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_2_0); reg++)
+ snd_soc_component_write(component,
wcd_reg_defaults_2_0[reg].reg,
+ wcd_reg_defaults_2_0[reg].def);
priv->component = component;
--
2.45.2
[PATCH 3/4] ASoC: dt-bindings: qcom,sm8250: Add msm8953/msm8976-qdsp6-sndcard
Document MSM8953/MSM8976 QDSP6 cards. Signed-off-by: Adam Skladowski --- .../bindings/sound/qcom,sm8250.yaml | 28 +-- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index b2e15ebbd1bc..3b5f8adba725 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -29,6 +29,8 @@ properties: - enum: - qcom,apq8016-sbc-sndcard - qcom,msm8916-qdsp6-sndcard + - qcom,msm8953-qdsp6-sndcard + - qcom,msm8976-qdsp6-sndcard - qcom,qcm6490-idp-sndcard - qcom,qcs6490-rb3gen2-sndcard - qcom,qrb5165-rb5-sndcard @@ -144,10 +146,30 @@ allOf: - model - reg - reg-names -else: + - if: + properties: +compatible: + contains: +enum: + - qcom,msm8953-qdsp6-sndcard + - qcom,msm8976-qdsp6-sndcard +then: properties: -reg: false -reg-names: false +reg: + items: +- description: Microphone I/O mux register address +- description: Speaker I/O mux register address +- description: Quinary Mi2S I/O mux register address +reg-names: + items: +- const: mic-iomux +- const: spkr-iomux +- const: quin-iomux + required: +- compatible +- model +- reg +- reg-names additionalProperties: false -- 2.45.2
[PATCH 4/4] ASoC: qcom: apq8016_sbc: Add support for msm8953/msm8976 SoC
From: Vladimir Lypak
Introduce support for audio card on MSM8953/MSM8976 platform.
Main difference between those two is Q6AFE CLK API supported by firmware
which influence way we enable digital codec clock.
Either inside machine driver or outside via q6afe-clocks driver.
Signed-off-by: Vladimir Lypak
[Adam: Add MSM8976, rename functions, add mclk setting,add msg]
Co-developed-by: Adam Skladowski
Signed-off-by: Adam Skladowski
---
sound/soc/qcom/apq8016_sbc.c | 66 ++--
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c
index 8971f4f5d339..51efefefe0a1 100644
--- a/sound/soc/qcom/apq8016_sbc.c
+++ b/sound/soc/qcom/apq8016_sbc.c
@@ -22,6 +22,11 @@
#define MI2S_COUNT (MI2S_QUINARY + 1)
+enum afe_clk_api {
+ Q6AFE_CLK_V1,
+ Q6AFE_CLK_V2
+};
+
struct apq8016_sbc_data {
struct snd_soc_card card;
void __iomem *mic_iomux;
@@ -29,6 +34,8 @@ struct apq8016_sbc_data {
void __iomem *quin_iomux;
struct snd_soc_jack jack;
bool jack_setup;
+ enum afe_clk_api q6afe_clk_ver;
+ bool dig_cdc_mclk_en;
int mi2s_clk_count[MI2S_COUNT];
};
@@ -192,6 +199,28 @@ static int qdsp6_dai_get_lpass_id(struct snd_soc_dai
*cpu_dai)
}
}
+static int qdsp6_get_clk_id(struct apq8016_sbc_data *data, int mi2s_id)
+{
+ if (data->q6afe_clk_ver == Q6AFE_CLK_V2) {
+ switch (mi2s_id) {
+ case MI2S_PRIMARY:
+ return Q6AFE_LPASS_CLK_ID_PRI_MI2S_IBIT;
+ case MI2S_SECONDARY:
+ return Q6AFE_LPASS_CLK_ID_SEC_MI2S_IBIT;
+ case MI2S_TERTIARY:
+ return Q6AFE_LPASS_CLK_ID_TER_MI2S_IBIT;
+ case MI2S_QUATERNARY:
+ return Q6AFE_LPASS_CLK_ID_QUAD_MI2S_IBIT;
+ case MI2S_QUINARY:
+ return Q6AFE_LPASS_CLK_ID_QUI_MI2S_IBIT;
+ default:
+ break;
+ }
+ }
+ /* If AFE CLK isn't V2 return V1 */
+ return LPAIF_BIT_CLK;
+}
+
static int msm8916_qdsp6_dai_init(struct snd_soc_pcm_runtime *rtd)
{
struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
@@ -214,8 +243,16 @@ static int msm8916_qdsp6_startup(struct snd_pcm_substream
*substream)
if (++data->mi2s_clk_count[mi2s] > 1)
return 0;
+ /*
+* On newer legacy SoC (MSM8976) lpass codec clocks are not available
in gcc region
+* so we have to request clock from machine driver using V1 API)
+*/
+ if (data->q6afe_clk_ver == Q6AFE_CLK_V1 && data->dig_cdc_mclk_en ==
true)
+ ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_DIG_CLK,
DEFAULT_MCLK_RATE, 0);
+ if (ret)
+ dev_err(card->dev, "Failed to enable LPAIF dig clk: %d\n", ret);
- ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_BIT_CLK, MI2S_BCLK_RATE, 0);
+ ret = snd_soc_dai_set_sysclk(cpu_dai, qdsp6_get_clk_id(data, mi2s),
MI2S_BCLK_RATE, 0);
if (ret)
dev_err(card->dev, "Failed to enable LPAIF bit clk: %d\n", ret);
return ret;
@@ -236,9 +273,15 @@ static void msm8916_qdsp6_shutdown(struct
snd_pcm_substream *substream)
if (--data->mi2s_clk_count[mi2s] > 0)
return;
- ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_BIT_CLK, 0, 0);
+ ret = snd_soc_dai_set_sysclk(cpu_dai, qdsp6_get_clk_id(data, mi2s), 0,
0);
if (ret)
dev_err(card->dev, "Failed to disable LPAIF bit clk: %d\n",
ret);
+
+ if (data->q6afe_clk_ver == Q6AFE_CLK_V1 && data->dig_cdc_mclk_en ==
true)
+ ret = snd_soc_dai_set_sysclk(cpu_dai, LPAIF_DIG_CLK, 0, 0);
+ if (ret)
+ dev_err(card->dev, "Failed to disable LPAIF dig clk: %d\n",
ret);
+
}
static const struct snd_soc_ops msm8916_qdsp6_be_ops = {
@@ -279,6 +322,23 @@ static void msm8916_qdsp6_add_ops(struct snd_soc_card
*card)
}
}
+static void msm8953_qdsp6_add_ops(struct snd_soc_card *card)
+{
+ struct apq8016_sbc_data *pdata = snd_soc_card_get_drvdata(card);
+
+ pdata->q6afe_clk_ver = Q6AFE_CLK_V2;
+ msm8916_qdsp6_add_ops(card);
+}
+
+static void msm8976_qdsp6_add_ops(struct snd_soc_card *card)
+{
+ struct apq8016_sbc_data *pdata = snd_soc_card_get_drvdata(card);
+
+ pdata->q6afe_clk_ver = Q6AFE_CLK_V1;
+ pdata->dig_cdc_mclk_en = true;
+ msm8916_qdsp6_add_ops(card);
+}
+
static const struct snd_kcontrol_new apq8016_sbc_snd_controls[] = {
SOC_DAPM_PIN_SWITCH("Headphone Jack"),
SOC_DAPM_PIN_SWITCH("Mic Jack"),
@@ -343,6 +403,8 @@ static int apq8016_sbc_platform_probe(struct
platform_device *pdev)
static const struct of_device_id apq8016_sbc_device_id[] __maybe_unused = {
{ .compatible = "qcom,apq8016-sbc-sndcard", .data = apq8016_sbc_add_ops
},
{ .compatible = "qcom,msm8
Re: [PATCH 06/12] arm64: dts: qcom: sm6115-pro1x: Enable MDSS and GPU
On 22.07.2024 11:17 AM, Dang Huynh wrote:
>>> +&mdss_dsi0_phy {
>>> + status = "okay";
>>
>> No power supplies?
>>
>> Konrad
>
> Doesn't seem to be defined anywhere on downstream, may be hardware controlled.
my downstream suggests L1b
Konrad
Re: [PATCH 1/2] module: Split modules_install compression and in-kernel decompression
On Mon, Jul 22, 2024 at 6:07 PM Petr Pavlu wrote: > > The kernel configuration allows specifying a module compression mode. If > one is selected then each module gets compressed during > 'make modules_install' and additionally one can also enable support for > a respective direct in-kernel decompression support. This means that the > decompression support cannot be enabled without the automatic compression. > > Some distributions, such as the (open)SUSE family, use a signer service for > modules. A build runs on a worker machine but signing is done by a separate > locked-down server that is in possession of the signing key. The build > invokes 'make modules_install' to create a modules tree, collects > information about the modules, asks the signer service for their signature, > appends each signature to the respective module and compresses all modules. > > When using this arrangment, the 'make modules_install' step produces > unsigned+uncompressed modules and the distribution's own build recipe takes > care of signing and compression later. > > The signing support can be currently enabled without automatically signing > modules during 'make modules_install'. However, the in-kernel decompression > support can be selected only after first enabling automatic compression > during this step. > > To allow only enabling the in-kernel decompression support without the > automatic compression during 'make modules_install', separate the > compression options similarly to the signing options, as follows: > > > Enable loadable module support > [*] Module compression > Module compression type (GZIP) ---> > [*] Automatically compress all modules > [ ] Support in-kernel module decompression > > * "Module compression" (MODULE_COMPRESS) is a new main switch for the > compression/decompression support. It replaces MODULE_COMPRESS_NONE. > * "Module compression type" (MODULE_COMPRESS_) chooses the > compression type, one of GZ, XZ, ZSTD. > * "Automatically compress all modules" (MODULE_COMPRESS_ALL) is a new > option to enable module compression during 'make modules_install'. It > defaults to Y. > * "Support in-kernel module decompression" (MODULE_DECOMPRESS) enables > in-kernel decompression. > > Signed-off-by: Petr Pavlu > --- My preference is to add CONFIG_MODULE_DECOMPRESS_GZIP CONFIG_MODULE_DECOMPRESS_XZ CONFIG_MODULE_DECOMPRESS_ZSTD instead of CONFIG_MODULE_COMPRESS_ALL. For example, if MODULE_DECOMPRESS config MODULE_DECOMPRESS_GZIP bool "Support in-kernel GZIP decompression for module" default MODULE_COMPRESS_GZIP config MODULE_DECOMPRESS_XZ bool "Support in-kernel XZ decompression for module" default MODULE_COMPRESS_XZ config MODULE_DECOMPRESS_ZSTD bool "Support in-kernel ZSTD decompression for module" default MODULE_COMPRESS_ZSTD endif OR, maybe config MODULE_DECOMPRESS_GZIP bool "Support in-kernel GZIP decompression for module" select MODULE_DECOMPRESS config MODULE_DECOMPRESS_XZ bool "Support in-kernel XZ decompression for module" select MODULE_DECOMPRESS config MODULE_DECOMPRESS_ZSTD bool "Support in-kernel ZSTD decompression for module" select MODULE_DECOMPRESS config MODULE_DECOMPRESS bool You can toggle MODULE_COMPRESS_GZIP and MODULE_DECOMPRESS_GZIP independently Of course, the current kernel/module/decompress.c does not work when multiple (or zero) CONFIG_MODULE_DECOMPRESS_* is enabled. It needs a little modification. I will wait for Lius's comment. > kernel/module/Kconfig| 61 > scripts/Makefile.modinst | 2 ++ > 2 files changed, 33 insertions(+), 30 deletions(-) > > diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig > index 4047b6d48255..bb7f7930fef6 100644 > --- a/kernel/module/Kconfig > +++ b/kernel/module/Kconfig > @@ -278,64 +278,65 @@ config MODULE_SIG_HASH > default "sha3-384" if MODULE_SIG_SHA3_384 > default "sha3-512" if MODULE_SIG_SHA3_512 > > -choice > - prompt "Module compression mode" > +config MODULE_COMPRESS > + bool "Module compression" > help > - This option allows you to choose the algorithm which will be used to > - compress modules when 'make modules_install' is run. (or, you can > - choose to not compress modules at all.) > - > - External modules will also be compressed in the same way during the > - installation. > - > - For modules inside an initrd or initramfs, it's more efficient to > - compress the whole initrd or initramfs instead. > - > + Enable module compression to reduce on-disk size of module binaries. > This is fully compatible with signed modules. > > - Please note that the tool used to load modules needs to support the > - corresponding algorithm. module-init-tools MAY support gzip, and > kmod > - MAY support gzip, xz and zstd. > +
Re: [PATCH 07/12] arm64: dts: qcom: sm6115-pro1x: Hook up USB3 SS
On 22.07.2024 9:10 AM, Dang Huynh wrote: > The F(x)tec Pro1X supports USB 3.0 through it's USB-C port. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 09/12] arm64: dts: qcom: sm6115-pro1x: Add PMI632 Type-C property
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The USB-C port is used for powering external devices and transfer
> data from/to them.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konradqmpphy_out {
> + remote-endpoint = <&pmi632_ss_in>;
> +};
> +
> &xo_board {
> clock-frequency = <1920>;
> };
>
Re: [PATCH 11/12] arm64: dts: qcom: sm6115-pro1x: Enable remoteprocs
On 22.07.2024 9:10 AM, Dang Huynh wrote: > Enable [A,C]DSP and MPSS remote processor on this device. > > Signed-off-by: Dang Huynh > --- Reviewed-by: Konrad Dybcio Konrad
Re: tracing: user events UAF crash report
On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause wrote: > > Hi Steven, Ajay, > > [ @Cc list: I found out issues with tracefs have been reported / > attempted to get fixed in the past, so you may be interested. ] > > I noticed, the user events ftrace selftest is crashing every now and > then in our automated tests. Digging into, I found that the following > is triggering the issue very reliable: > > - in one shell, as root: > # while true; do ./kselftest/user_events/ftrace_test; done > > - in a second shell, again as root: > # cd /sys/kernel/tracing > # while true; do cat events/user_events/__test_event/format; done > 2>/dev/null > Tried to reproduced on 6.10.0-rc7-100.ph5+, only getting repeated output as: # while true; do cat events/user_events/__test_event/format; done 2>/dev/null print fmt: "" name: __test_event ID: 2390 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; # while true; do ./kselftest/user_events/ftrace_test; done TAP version 13 1..6 # Starting 6 tests from 1 test cases. # RUN user.register_events ... #OK user.register_events ok 1 user.register_events # RUN user.write_events ... #OK user.write_events ok 2 user.write_events # RUN user.write_empty_events ... #OK user.write_empty_events ok 3 user.write_empty_events # RUN user.write_fault ... #OK user.write_fault ok 4 user.write_fault # RUN user.write_validator ... #OK user.write_validator ok 5 user.write_validator # RUN user.print_fmt ... #OK user.print_fmt ok 6 user.print_fmt # PASSED: 6 / 6 tests passed. # Totals: pass:6 fail:0 xfail:0 xpass:0 skip:0 error:0 Am I missing any step? > Ignoring that the selftest fails for half of its tests -- which is a > regression and therefore yet another bug, I guess -- this triggers an > access fault (GFP/PF/NULL deref) after a few iterations, usually within > a minute, mostly mere seconds. With KASAN enabled it generates a splat > almost instantly, like following: > > [ 23.790955] > == > [ 23.791692] BUG: KASAN: slab-use-after-free in f_show+0x43b/0x470 > [ 23.792244] Read of size 8 at addr 888007076878 by task cat/755 > [ 23.792753] > [ 23.792947] CPU: 1 PID: 755 Comm: cat Tainted: G D N > 6.10.0-vanilla-dirty #30 > [ 23.793563] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 > [ 23.794280] Call Trace: > [ 23.794470] > [ 23.794642] dump_stack_lvl+0x66/0xa0 > [ 23.794909] print_report+0xd0/0x630 > [ 23.795180] ? f_show+0x43b/0x470 > [ 23.795415] ? __virt_addr_valid+0x208/0x3f0 > [ 23.795700] ? f_show+0x43b/0x470 > [ 23.795935] kasan_report+0xd8/0x110 > [ 23.796183] ? f_show+0x43b/0x470 > [ 23.796418] f_show+0x43b/0x470 > [ 23.796645] seq_read_iter+0x418/0x11e0 > [ 23.796907] ? __page_table_check_ptes_set+0x166/0x1a0 > [ 23.797280] seq_read+0x261/0x350 > [ 23.797537] ? lock_release+0x453/0x600 > [ 23.797819] ? __pfx_seq_read+0x10/0x10 > [ 23.798103] ? set_ptes.isra.0+0x11b/0x150 > [ 23.798402] vfs_read+0x171/0x9e0 > [ 23.798657] ? lock_acquire+0x408/0x4b0 > [ 23.798970] ? __pfx_vfs_read+0x10/0x10 > [ 23.799267] ? lock_release+0x453/0x600 > [ 23.799549] ? do_user_addr_fault+0x45b/0x8b0 > [ 23.799862] ? __pfx_lock_release+0x10/0x10 > [ 23.800162] ? __pfx___up_read+0x10/0x10 > [ 23.800448] ksys_read+0xdd/0x1a0 > [ 23.800704] ? __pfx_ksys_read+0x10/0x10 > [ 23.801007] ? do_user_addr_fault+0x465/0x8b0 > [ 23.801341] do_syscall_64+0x66/0x130 > [ 23.801615] entry_SYSCALL_64_after_hwframe+0x71/0x79 > [ 23.801959] RIP: 0033:0x7f1fdb9df40e > [ 23.802230] Code: c0 e9 b6 fe ff ff 50 48 8d 3d 2e 08 0b 00 e8 69 01 02 00 > 66 0f 1f 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d > 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28 > [ 23.803352] RSP: 002b:7fff86d62658 EFLAGS: 0246 ORIG_RAX: > > [ 23.803848] RAX: ffda RBX: 0002 RCX: > 7f1fdb9df40e > [ 23.804302] RDX: 0002 RSI: 7f1fdb8d3000 RDI: > 0003 > [ 23.804753] RBP: 7f1fdb8d3000 R08: 7f1fdb8d2010 R09: > > [ 23.805239] R10: fbc5 R11: 0246 R12: > > [ 23.805694] R13: 0003 R14: 0002 R15: > 0002 > [ 23.806153] > [ 23.806352] > [ 23.806518] Allocated by task 753: > [ 23.806781] kasan_save_stack+0x20/0x40 > [ 23.807094] kasan_save_track+0x14/0x30 > [ 23.807377] __kasan_kmalloc+0x8f/0xa0 > [ 23.807656] user_event_parse_cmd+0
Re: [PATCH 1/4] ASoC: qcom: apq8016_sbc.c: Add Quinary support
On Mon, Jul 22, 2024 at 11:51:05AM GMT, Adam Skladowski wrote: > From: Vladimir Lypak > > Add support for configuring Quinary Mi2S interface > it will be used on MSM8953 and MSM8976 platform. > > Signed-off-by: Vladimir Lypak > [Adam: Split from MSM8953 support patch,add msg] > Signed-off-by: Adam Skladowski > --- > sound/soc/qcom/apq8016_sbc.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/qcom/apq8016_sbc.c b/sound/soc/qcom/apq8016_sbc.c > index 3023cf180a75..8971f4f5d339 100644 > --- a/sound/soc/qcom/apq8016_sbc.c > +++ b/sound/soc/qcom/apq8016_sbc.c > @@ -320,6 +330,10 @@ static int apq8016_sbc_platform_probe(struct > platform_device *pdev) > if (IS_ERR(data->spkr_iomux)) > return PTR_ERR(data->spkr_iomux); > > + data->quin_iomux = devm_platform_ioremap_resource_byname(pdev, > "quin-iomux"); This should probably handle -ENOENT (or -ENODEV?) case and set the pointer to NULL. > + if (IS_ERR(data->quin_iomux)) > + return PTR_ERR(data->quin_iomux); > + > snd_soc_card_set_drvdata(card, data); > > add_ops(card); > -- > 2.45.2 > -- With best wishes Dmitry
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 22 Jul 2024 at 15:49, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > to set the mac address
> >
> > Tested in ConnectX-6 Dx device
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index ecfc16151d61..415b527a9c72 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
> > *v_mdev, struct vdpa_device *
> > destroy_workqueue(wq);
> > mgtdev->ndev = NULL;
> > }
> > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > + struct vdpa_device *dev,
> > + const struct vdpa_dev_set_config *add_config)
> > +{
> > + struct mlx5_vdpa_dev *mvdev;
> > + struct mlx5_vdpa_net *ndev;
> > + struct mlx5_core_dev *mdev;
> > + struct virtio_net_config *config;
> > + struct mlx5_core_dev *pfmdev;
> > + int err = -EOPNOTSUPP;
> > +
> > + mvdev = to_mvdev(dev);
> > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > + mdev = mvdev->mdev;
> > + config = &ndev->config;
> > +
> > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > + if (!err)
> > + memcpy(config->mac, add_config->net.mac, ETH_ALEN);
> > + }
> > + return err;
>
> Similar to net simulator, how could be serialize the modification to
> mac address:
>
> 1) from vdpa tool
> 2) via control virtqueue
>
> Thanks
>
sure. Wiil do
thanks
cindy
> > +}
> >
> > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > .dev_add = mlx5_vdpa_dev_add,
> > .dev_del = mlx5_vdpa_dev_del,
> > + .dev_set_attr = mlx5_vdpa_set_attr,
> > };
> >
> > static struct virtio_device_id id_table[] = {
> > --
> > 2.45.0
> >
>
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
>
> On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > to set the mac address
> > >
> > > Tested in ConnectX-6 Dx device
> > >
> > > Signed-off-by: Cindy Lu
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > 1 file changed, 25 insertions(+)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index ecfc16151d61..415b527a9c72 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > destroy_workqueue(wq);
> > > mgtdev->ndev = NULL;
> > > }
> > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > + struct vdpa_device *dev,
> > > + const struct vdpa_dev_set_config
> > > *add_config)
> > > +{
> > > + struct mlx5_vdpa_dev *mvdev;
> > > + struct mlx5_vdpa_net *ndev;
> > > + struct mlx5_core_dev *mdev;
> > > + struct virtio_net_config *config;
> > > + struct mlx5_core_dev *pfmdev;
> Reverse xmas tree?
>
will fix this
> > > + int err = -EOPNOTSUPP;
> > > +
> > > + mvdev = to_mvdev(dev);
> > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > + mdev = mvdev->mdev;
> > > + config = &ndev->config;
> > > +
> You still need to take the ndev->reslock.
>
sure, will do
> > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > + if (!err)
> > > + memcpy(config->mac, add_config->net.mac,
> > > ETH_ALEN);
> What is the expected behaviour when the device is in use?
>
if the err is 0 then copy the Mac address to config
will change this code to make it more clear
Thanks
Cindy
> > > + }
> > > + return err;
> >
> > Similar to net simulator, how could be serialize the modification to
> > mac address:
> >
> > 1) from vdpa tool
> > 2) via control virtqueue
> >
> > Thanks
> >
> > > +}
> > >
> > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > .dev_add = mlx5_vdpa_dev_add,
> > > .dev_del = mlx5_vdpa_dev_del,
> > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > };
> > >
> > > static struct virtio_device_id id_table[] = {
> > > --
> > > 2.45.0
> > >
> >
> Thanks,
> Dragos
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> >
> > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > >
> > > > Add the function to support setting the MAC address.
> > > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > > to set the mac address
> > > >
> > > > Tested in ConnectX-6 Dx device
> > > >
> > > > Signed-off-by: Cindy Lu
> > > > ---
> > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > > 1 file changed, 25 insertions(+)
> > > >
> > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > index ecfc16151d61..415b527a9c72 100644
> > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > > destroy_workqueue(wq);
> > > > mgtdev->ndev = NULL;
> > > > }
> > > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > > + struct vdpa_device *dev,
> > > > + const struct vdpa_dev_set_config
> > > > *add_config)
> > > > +{
> > > > + struct mlx5_vdpa_dev *mvdev;
> > > > + struct mlx5_vdpa_net *ndev;
> > > > + struct mlx5_core_dev *mdev;
> > > > + struct virtio_net_config *config;
> > > > + struct mlx5_core_dev *pfmdev;
> > Reverse xmas tree?
> >
> will fix this
> > > > + int err = -EOPNOTSUPP;
> > > > +
> > > > + mvdev = to_mvdev(dev);
> > > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > > + mdev = mvdev->mdev;
> > > > + config = &ndev->config;
> > > > +
> > You still need to take the ndev->reslock.
> >
> sure, will do
> > > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > > + if (!err)
> > > > + memcpy(config->mac, add_config->net.mac,
> > > > ETH_ALEN);
> > What is the expected behaviour when the device is in use?
> >
> if the err is 0 then copy the Mac address to config
> will change this code to make it more clear
> Thanks
> Cindy
sorry for the misunderstanding. The VDPA tool does not support
changing the MAC address after the guest is loaded. I think I can add
a check for VIRTIO_CONFIG_S_DRIVER_OK here?
Thanks
cindy
> > > > + }
> > > > + return err;
> > >
> > > Similar to net simulator, how could be serialize the modification to
> > > mac address:
> > >
> > > 1) from vdpa tool
> > > 2) via control virtqueue
> > >
> > > Thanks
> > >
> > > > +}
> > > >
> > > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > > .dev_add = mlx5_vdpa_dev_add,
> > > > .dev_del = mlx5_vdpa_dev_del,
> > > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > > };
> > > >
> > > > static struct virtio_device_id id_table[] = {
> > > > --
> > > > 2.45.0
> > > >
> > >
> > Thanks,
> > Dragos
Re: [PATCH 4/4] ASoC: qcom: apq8016_sbc: Add support for msm8953/msm8976 SoC
Hi Adam,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.10]
[also build test WARNING on linus/master next-20240722]
[cannot apply to broonie-sound/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Adam-Skladowski/ASoC-qcom-apq8016_sbc-c-Add-Quinary-support/20240722-181331
base: v6.10
patch link:
https://lore.kernel.org/r/20240722095147.3372-5-a39.skl%40gmail.com
patch subject: [PATCH 4/4] ASoC: qcom: apq8016_sbc: Add support for
msm8953/msm8976 SoC
config: s390-allmodconfig
(https://download.01.org/0day-ci/archive/20240722/20240718.nkjhmm5n-...@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project
ad154281230d83ee551e12d5be48bb956ef47ed3)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240722/20240718.nkjhmm5n-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/20240718.nkjhmm5n-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from sound/soc/qcom/apq8016_sbc.c:6:
In file included from include/linux/device.h:32:
In file included from include/linux/device/driver.h:21:
In file included from include/linux/module.h:19:
In file included from include/linux/elf.h:6:
In file included from arch/s390/include/asm/elf.h:173:
In file included from arch/s390/include/asm/mmu_context.h:11:
In file included from arch/s390/include/asm/pgalloc.h:18:
In file included from include/linux/mm.h:2258:
include/linux/vmstat.h:500:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
500 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
501 |item];
|
include/linux/vmstat.h:507:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
507 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
508 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:514:36: warning: arithmetic between different
enumeration types ('enum node_stat_item' and 'enum lru_list')
[-Wenum-enum-conversion]
514 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
| ~~~ ^ ~~~
include/linux/vmstat.h:519:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
519 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
520 |NR_VM_NUMA_EVENT_ITEMS +
|~~
include/linux/vmstat.h:528:43: warning: arithmetic between different
enumeration types ('enum zone_stat_item' and 'enum numa_stat_item')
[-Wenum-enum-conversion]
528 | return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
|~ ^
529 |NR_VM_NUMA_EVENT_ITEMS +
|~~
In file included from sound/soc/qcom/apq8016_sbc.c:9:
In file included from include/linux/io.h:14:
In file included from arch/s390/include/asm/io.h:93:
include/asm-generic/io.h:548:31: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
548 | val = __raw_readb(PCI_IOBASE + addr);
| ~~ ^
include/asm-generic/io.h:561:61: warning: performing pointer arithmetic on a
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
561 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE +
addr));
| ~~ ^
include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro
'__le16_to_cpu'
37 | #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
| ^
include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16'
Re: [PATCH v2] remoteproc: xlnx: add sram support
Good morning,
On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
> power-domains. Platform management firmware is responsible
> to operate these power-domains.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v2:
> - Expand commit message with power-domains related information.
>
> drivers/remoteproc/xlnx_r5_remoteproc.c | 131
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 596f3ffb8935..52ddd42b09e0 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -56,6 +56,17 @@ struct mem_bank_data {
> char *bank_name;
> };
>
> +/**
> + * struct zynqmp_sram_bank - sram bank description
> + *
> + * @sram_res: sram address region information
> + * @da: device address of sram
> + */
> +struct zynqmp_sram_bank {
> + struct resource sram_res;
> + u32 da;
> +};
> +
> /**
> * struct mbox_info
> *
> @@ -120,6 +131,8 @@ static const struct mem_bank_data
> zynqmp_tcm_banks_lockstep[] = {
> * struct zynqmp_r5_core
> *
> * @rsc_tbl_va: resource table virtual address
> + * @sram: Array of sram memories assigned to this core
> + * @num_sram: number of sram for this core
> * @dev: device of RPU instance
> * @np: device node of RPU instance
> * @tcm_bank_count: number TCM banks accessible to this RPU
> @@ -131,6 +144,8 @@ static const struct mem_bank_data
> zynqmp_tcm_banks_lockstep[] = {
> */
> struct zynqmp_r5_core {
> void __iomem *rsc_tbl_va;
> + struct zynqmp_sram_bank **sram;
I suggest making @sram an array rather than an array of pointers - it would
simplify function zynqmp_r5_get_sram_banks().
> + int num_sram;
> struct device *dev;
> struct device_node *np;
> int tcm_bank_count;
> @@ -494,6 +509,40 @@ static int add_mem_regions_carveout(struct rproc *rproc)
> return 0;
> }
>
> +static int add_sram_carveouts(struct rproc *rproc)
> +{
> + struct zynqmp_r5_core *r5_core = rproc->priv;
> + struct rproc_mem_entry *rproc_mem;
> + struct zynqmp_sram_bank *sram;
> + dma_addr_t dma_addr;
> + size_t len;
> + int da, i;
> +
> + for (i = 0; i < r5_core->num_sram; i++) {
> + sram = r5_core->sram[i];
> +
> + dma_addr = (dma_addr_t)sram->sram_res.start;
> + len = resource_size(&sram->sram_res);
> + da = sram->da;
> +
> + /* Register associated reserved memory regions */
> + rproc_mem = rproc_mem_entry_init(&rproc->dev, NULL,
> + (dma_addr_t)dma_addr,
> + len, da,
> + zynqmp_r5_mem_region_map,
> + zynqmp_r5_mem_region_unmap,
> + sram->sram_res.name);
> +
> + rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, da, len);
> +
> + dev_dbg(&rproc->dev, "sram carveout %s addr=%llx, da=0x%x,
> size=0x%lx",
> + sram->sram_res.name, dma_addr, da, len);
> + }
> +
> + return 0;
> +}
> +
> /*
> * tcm_mem_unmap()
> * @rproc: single R5 core's corresponding rproc instance
> @@ -669,6 +718,12 @@ static int zynqmp_r5_rproc_prepare(struct rproc *rproc)
> return ret;
> }
>
> + ret = add_sram_carveouts(rproc);
> + if (ret) {
> + dev_err(&rproc->dev, "failed to get sram carveout %d\n", ret);
> + return ret;
> + }
> +
> return 0;
> }
>
> @@ -881,6 +936,78 @@ static struct zynqmp_r5_core
> *zynqmp_r5_add_rproc_core(struct device *cdev)
> return ERR_PTR(ret);
> }
>
> +static int zynqmp_r5_get_sram_banks(struct zynqmp_r5_core *r5_core)
> +{
> + struct zynqmp_sram_bank **sram, *sram_data;
> + struct device_node *np = r5_core->np;
> + struct device *dev = r5_core->dev;
> + struct device_node *sram_np;
> + int num_sram, i, ret;
> + u64 abs_addr, size;
> +
> + /* "sram" is optional proprty. Do not fail, if unavailable. */
s/proprty/property
> + if (!of_find_property(r5_core->np, "sram", NULL))
> + return 0;
> +
> + num_sram = of_property_count_elems_of_size(np, "sram", sizeof(phandle));
> + if (num_sram <= 0) {
Any reason this is "<" rather than "<=" ?
> + dev_err(dev, "Invalid sram property, ret = %d\n",
> + num_sram);
> + return -EINVAL;
> + }
> +
> + sram = devm_kcalloc(dev, num_sram,
> + sizeof(struct zynqmp_sram_bank *), GFP_KERNEL);
> + if (!sram)
> +
[PATCH bpf-next] bpf: allow bpf_current_task_under_cgroup() with BPF_CGROUP_*
From: Matteo Croce
The helper bpf_current_task_under_cgroup() currently is only allowed for
tracing programs.
Allow its usage also in the BPF_CGROUP_* program types.
Move the code from kernel/trace/bpf_trace.c to kernel/bpf/cgroup.c,
so it compiles also without CONFIG_BPF_EVENTS.
Signed-off-by: Matteo Croce
---
include/linux/bpf.h | 1 +
kernel/bpf/cgroup.c | 25 +
kernel/trace/bpf_trace.c | 27 ++-
3 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 4f1d4a97b9d1..4000fd161dda 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -3188,6 +3188,7 @@ extern const struct bpf_func_proto
bpf_sock_hash_update_proto;
extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
extern const struct bpf_func_proto bpf_get_current_ancestor_cgroup_id_proto;
extern const struct bpf_func_proto bpf_get_cgroup_classid_curr_proto;
+extern const struct bpf_func_proto bpf_current_task_under_cgroup_proto;
extern const struct bpf_func_proto bpf_msg_redirect_hash_proto;
extern const struct bpf_func_proto bpf_msg_redirect_map_proto;
extern const struct bpf_func_proto bpf_sk_redirect_hash_proto;
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 8ba73042a239..b99add9570e6 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -2308,6 +2308,29 @@ static const struct bpf_func_proto
bpf_get_netns_cookie_sockopt_proto = {
};
#endif
+BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
+{
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct cgroup *cgrp;
+
+ if (unlikely(idx >= array->map.max_entries))
+ return -E2BIG;
+
+ cgrp = READ_ONCE(array->ptrs[idx]);
+ if (unlikely(!cgrp))
+ return -EAGAIN;
+
+ return task_under_cgroup_hierarchy(current, cgrp);
+}
+
+const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
+ .func = bpf_current_task_under_cgroup,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_CONST_MAP_PTR,
+ .arg2_type = ARG_ANYTHING,
+};
+
static const struct bpf_func_proto *
cg_sockopt_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
@@ -2581,6 +2604,8 @@ cgroup_current_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
case BPF_FUNC_get_cgroup_classid:
return &bpf_get_cgroup_classid_curr_proto;
#endif
+ case BPF_FUNC_current_task_under_cgroup:
+ return &bpf_current_task_under_cgroup_proto;
default:
return NULL;
}
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index cd098846e251..ea5cdd122024 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -798,29 +798,6 @@ const struct bpf_func_proto bpf_task_pt_regs_proto = {
.ret_btf_id = &bpf_task_pt_regs_ids[0],
};
-BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
-{
- struct bpf_array *array = container_of(map, struct bpf_array, map);
- struct cgroup *cgrp;
-
- if (unlikely(idx >= array->map.max_entries))
- return -E2BIG;
-
- cgrp = READ_ONCE(array->ptrs[idx]);
- if (unlikely(!cgrp))
- return -EAGAIN;
-
- return task_under_cgroup_hierarchy(current, cgrp);
-}
-
-static const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
- .func = bpf_current_task_under_cgroup,
- .gpl_only = false,
- .ret_type = RET_INTEGER,
- .arg1_type = ARG_CONST_MAP_PTR,
- .arg2_type = ARG_ANYTHING,
-};
-
struct send_signal_irq_work {
struct irq_work irq_work;
struct task_struct *task;
@@ -1548,8 +1525,6 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
return &bpf_get_numa_node_id_proto;
case BPF_FUNC_perf_event_read:
return &bpf_perf_event_read_proto;
- case BPF_FUNC_current_task_under_cgroup:
- return &bpf_current_task_under_cgroup_proto;
case BPF_FUNC_get_prandom_u32:
return &bpf_get_prandom_u32_proto;
case BPF_FUNC_probe_write_user:
@@ -1578,6 +1553,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
return &bpf_cgrp_storage_get_proto;
case BPF_FUNC_cgrp_storage_delete:
return &bpf_cgrp_storage_delete_proto;
+ case BPF_FUNC_current_task_under_cgroup:
+ return &bpf_current_task_under_cgroup_proto;
#endif
case BPF_FUNC_send_signal:
return &bpf_send_signal_proto;
--
2.45.2
Re: [PATCH bpf-next] bpf: allow bpf_current_task_under_cgroup() with BPF_CGROUP_*
On Mon, Jul 22, 2024 at 11:21 AM wrote:
>
> From: Matteo Croce
>
> The helper bpf_current_task_under_cgroup() currently is only allowed for
> tracing programs.
> Allow its usage also in the BPF_CGROUP_* program types.
> Move the code from kernel/trace/bpf_trace.c to kernel/bpf/cgroup.c,
> so it compiles also without CONFIG_BPF_EVENTS.
>
> Signed-off-by: Matteo Croce
> ---
> include/linux/bpf.h | 1 +
> kernel/bpf/cgroup.c | 25 +
> kernel/trace/bpf_trace.c | 27 ++-
> 3 files changed, 28 insertions(+), 25 deletions(-)
>
It seems fine to allow this, but also note that we have
bpf_task_under_cgroup() kfunc, which you might want to check if it is
allowed where you need it as well.
And the latter one is defined in kernel/bpf/helpers.c, so I'd move
this one next to it to keep them close.
pw-bot: cr
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 4f1d4a97b9d1..4000fd161dda 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -3188,6 +3188,7 @@ extern const struct bpf_func_proto
> bpf_sock_hash_update_proto;
> extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
> extern const struct bpf_func_proto bpf_get_current_ancestor_cgroup_id_proto;
> extern const struct bpf_func_proto bpf_get_cgroup_classid_curr_proto;
> +extern const struct bpf_func_proto bpf_current_task_under_cgroup_proto;
> extern const struct bpf_func_proto bpf_msg_redirect_hash_proto;
> extern const struct bpf_func_proto bpf_msg_redirect_map_proto;
> extern const struct bpf_func_proto bpf_sk_redirect_hash_proto;
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 8ba73042a239..b99add9570e6 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -2308,6 +2308,29 @@ static const struct bpf_func_proto
> bpf_get_netns_cookie_sockopt_proto = {
> };
> #endif
>
> +BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
> +{
> + struct bpf_array *array = container_of(map, struct bpf_array, map);
> + struct cgroup *cgrp;
> +
> + if (unlikely(idx >= array->map.max_entries))
> + return -E2BIG;
> +
> + cgrp = READ_ONCE(array->ptrs[idx]);
> + if (unlikely(!cgrp))
> + return -EAGAIN;
> +
> + return task_under_cgroup_hierarchy(current, cgrp);
> +}
> +
> +const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
> + .func = bpf_current_task_under_cgroup,
> + .gpl_only = false,
> + .ret_type = RET_INTEGER,
> + .arg1_type = ARG_CONST_MAP_PTR,
> + .arg2_type = ARG_ANYTHING,
> +};
> +
> static const struct bpf_func_proto *
> cg_sockopt_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> {
> @@ -2581,6 +2604,8 @@ cgroup_current_func_proto(enum bpf_func_id func_id,
> const struct bpf_prog *prog)
> case BPF_FUNC_get_cgroup_classid:
> return &bpf_get_cgroup_classid_curr_proto;
> #endif
> + case BPF_FUNC_current_task_under_cgroup:
> + return &bpf_current_task_under_cgroup_proto;
> default:
> return NULL;
> }
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index cd098846e251..ea5cdd122024 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -798,29 +798,6 @@ const struct bpf_func_proto bpf_task_pt_regs_proto = {
> .ret_btf_id = &bpf_task_pt_regs_ids[0],
> };
>
> -BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
> -{
> - struct bpf_array *array = container_of(map, struct bpf_array, map);
> - struct cgroup *cgrp;
> -
> - if (unlikely(idx >= array->map.max_entries))
> - return -E2BIG;
> -
> - cgrp = READ_ONCE(array->ptrs[idx]);
> - if (unlikely(!cgrp))
> - return -EAGAIN;
> -
> - return task_under_cgroup_hierarchy(current, cgrp);
> -}
> -
> -static const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
> - .func = bpf_current_task_under_cgroup,
> - .gpl_only = false,
> - .ret_type = RET_INTEGER,
> - .arg1_type = ARG_CONST_MAP_PTR,
> - .arg2_type = ARG_ANYTHING,
> -};
> -
> struct send_signal_irq_work {
> struct irq_work irq_work;
> struct task_struct *task;
> @@ -1548,8 +1525,6 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
> struct bpf_prog *prog)
> return &bpf_get_numa_node_id_proto;
> case BPF_FUNC_perf_event_read:
> return &bpf_perf_event_read_proto;
> - case BPF_FUNC_current_task_under_cgroup:
> - return &bpf_current_task_under_cgroup_proto;
> case BPF_FUNC_get_prandom_u32:
> return &bpf_get_prandom_u32_proto;
> case BPF_FUNC_probe_write_user:
> @@ -1578,6 +1553,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
> struct bpf_prog
Re: tracing: user events UAF crash report
On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Subject: [PATCH] eventfs: Don't return NULL in eventfs_create_dir()
>
> Commit 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry") added another check, testing if the parent was freed after
> we released the mutex. If so, the function returns NULL. However, all
> callers expect it to either return a valid pointer or an error pointer,
> at least since commit 5264a2f4bb3b ("tracing: Fix a NULL vs IS_ERR() bug
> in event_subsystem_dir()"). Returning NULL will therefore fail the error
> condition check in the caller.
>
> Fix this by substituting the NULL return value with a fitting error
> pointer.
>
> Fixes: 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry")
> Cc: Dan Carpenter
> Signed-off-by: Mathias Krause
This will not get into the workflow without being sent as a normal patch.
Please send it and Cc those listed in MAINTAINERS (see get_maintainers.pl).
-- Steve
> ---
> fs/tracefs/event_inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
> index 5d88c184f0fc..a9c28a1d5dc8 100644
> --- a/fs/tracefs/event_inode.c
> +++ b/fs/tracefs/event_inode.c
> @@ -736,7 +736,7 @@ struct eventfs_inode *eventfs_create_dir(const char
> *name, struct eventfs_inode
> /* Was the parent freed? */
> if (list_empty(&ei->list)) {
> cleanup_ei(ei);
> - ei = NULL;
> + ei = ERR_PTR(-EBUSY);
> }
> return ei;
[PATCH bpf-next v2 0/2] bpf: enable some functions in cgroup programs
From: Matteo Croce Enable some BPF kfuncs and the helper bpf_current_task_under_cgroup() for program types BPF_CGROUP_*. These will be used by systemd-networkd: https://github.com/systemd/systemd/pull/32212 Matteo Croce (2): bpf: enable generic kfuncs for BPF_CGROUP_* programs bpf: allow bpf_current_task_under_cgroup() with BPF_CGROUP_* include/linux/bpf.h | 1 + kernel/bpf/cgroup.c | 2 ++ kernel/bpf/helpers.c | 29 + kernel/trace/bpf_trace.c | 27 ++- 4 files changed, 34 insertions(+), 25 deletions(-) -- 2.45.2
[PATCH bpf-next v2 1/2] bpf: enable generic kfuncs for BPF_CGROUP_* programs
From: Matteo Croce These kfuncs are enabled even in BPF_PROG_TYPE_TRACING, so they should be safe also in BPF_CGROUP_* programs. Signed-off-by: Matteo Croce --- kernel/bpf/helpers.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index b5f0adae8293..23b782641077 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -3051,6 +3051,12 @@ static int __init kfunc_init(void) ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_XDP, &generic_kfunc_set); ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS, &generic_kfunc_set); ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL, &generic_kfunc_set); + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SKB, &generic_kfunc_set); + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCK, &generic_kfunc_set); + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_DEVICE, &generic_kfunc_set); + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCK_ADDR, &generic_kfunc_set); + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SYSCTL, &generic_kfunc_set); + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCKOPT, &generic_kfunc_set); ret = ret ?: register_btf_id_dtor_kfuncs(generic_dtors, ARRAY_SIZE(generic_dtors), THIS_MODULE); -- 2.45.2
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, Jul 22, 2024 at 10:48 PM Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
> >
> > On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> > >
> > > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > > >
> > > > > Add the function to support setting the MAC address.
> > > > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > > > to set the mac address
> > > > >
> > > > > Tested in ConnectX-6 Dx device
> > > > >
> > > > > Signed-off-by: Cindy Lu
> > > > > ---
> > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > > > 1 file changed, 25 insertions(+)
> > > > >
> > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > index ecfc16151d61..415b527a9c72 100644
> > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > > > destroy_workqueue(wq);
> > > > > mgtdev->ndev = NULL;
> > > > > }
> > > > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > > > + struct vdpa_device *dev,
> > > > > + const struct vdpa_dev_set_config
> > > > > *add_config)
> > > > > +{
> > > > > + struct mlx5_vdpa_dev *mvdev;
> > > > > + struct mlx5_vdpa_net *ndev;
> > > > > + struct mlx5_core_dev *mdev;
> > > > > + struct virtio_net_config *config;
> > > > > + struct mlx5_core_dev *pfmdev;
> > > Reverse xmas tree?
> > >
> > will fix this
> > > > > + int err = -EOPNOTSUPP;
> > > > > +
> > > > > + mvdev = to_mvdev(dev);
> > > > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > > > + mdev = mvdev->mdev;
> > > > > + config = &ndev->config;
> > > > > +
> > > You still need to take the ndev->reslock.
> > >
> > sure, will do
> > > > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > > > + if (!err)
> > > > > + memcpy(config->mac, add_config->net.mac,
> > > > > ETH_ALEN);
> > > What is the expected behaviour when the device is in use?
> > >
> > if the err is 0 then copy the Mac address to config
> > will change this code to make it more clear
> > Thanks
> > Cindy
> sorry for the misunderstanding. The VDPA tool does not support
> changing the MAC address after the guest is loaded. I think I can add
> a check for VIRTIO_CONFIG_S_DRIVER_OK here?
Still racy, and I think we probably don't worry about that case. It's
the fault of the mgmt layer not us.
Thanks
> Thanks
> cindy
> > > > > + }
> > > > > + return err;
> > > >
> > > > Similar to net simulator, how could be serialize the modification to
> > > > mac address:
> > > >
> > > > 1) from vdpa tool
> > > > 2) via control virtqueue
> > > >
> > > > Thanks
> > > >
> > > > > +}
> > > > >
> > > > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > > > .dev_add = mlx5_vdpa_dev_add,
> > > > > .dev_del = mlx5_vdpa_dev_del,
> > > > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > > > };
> > > > >
> > > > > static struct virtio_device_id id_table[] = {
> > > > > --
> > > > > 2.45.0
> > > > >
> > > >
> > > Thanks,
> > > Dragos
>
[PATCH bpf-next v2 2/2] bpf: allow bpf_current_task_under_cgroup() with BPF_CGROUP_*
From: Matteo Croce
The helper bpf_current_task_under_cgroup() currently is only allowed for
tracing programs.
Allow its usage also in the BPF_CGROUP_* program types.
Move the code from kernel/trace/bpf_trace.c to kernel/bpf/helpers.c,
so it compiles also without CONFIG_BPF_EVENTS.
This will be used in systemd-networkd to monitor the sysctl writes,
and filter it's own writes from others:
https://github.com/systemd/systemd/pull/32212
Signed-off-by: Matteo Croce
---
include/linux/bpf.h | 1 +
kernel/bpf/cgroup.c | 2 ++
kernel/bpf/helpers.c | 23 +++
kernel/trace/bpf_trace.c | 27 ++-
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 4f1d4a97b9d1..4000fd161dda 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -3188,6 +3188,7 @@ extern const struct bpf_func_proto
bpf_sock_hash_update_proto;
extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
extern const struct bpf_func_proto bpf_get_current_ancestor_cgroup_id_proto;
extern const struct bpf_func_proto bpf_get_cgroup_classid_curr_proto;
+extern const struct bpf_func_proto bpf_current_task_under_cgroup_proto;
extern const struct bpf_func_proto bpf_msg_redirect_hash_proto;
extern const struct bpf_func_proto bpf_msg_redirect_map_proto;
extern const struct bpf_func_proto bpf_sk_redirect_hash_proto;
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 8ba73042a239..e7113d700b87 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -2581,6 +2581,8 @@ cgroup_current_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
case BPF_FUNC_get_cgroup_classid:
return &bpf_get_cgroup_classid_curr_proto;
#endif
+ case BPF_FUNC_current_task_under_cgroup:
+ return &bpf_current_task_under_cgroup_proto;
default:
return NULL;
}
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index 23b782641077..eaa3ce14028a 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -2457,6 +2457,29 @@ __bpf_kfunc long bpf_task_under_cgroup(struct
task_struct *task,
return ret;
}
+BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
+{
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct cgroup *cgrp;
+
+ if (unlikely(idx >= array->map.max_entries))
+ return -E2BIG;
+
+ cgrp = READ_ONCE(array->ptrs[idx]);
+ if (unlikely(!cgrp))
+ return -EAGAIN;
+
+ return task_under_cgroup_hierarchy(current, cgrp);
+}
+
+const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
+ .func = bpf_current_task_under_cgroup,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_CONST_MAP_PTR,
+ .arg2_type = ARG_ANYTHING,
+};
+
/**
* bpf_task_get_cgroup1 - Acquires the associated cgroup of a task within a
* specific cgroup1 hierarchy. The cgroup1 hierarchy is identified by its
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index cd098846e251..ea5cdd122024 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -798,29 +798,6 @@ const struct bpf_func_proto bpf_task_pt_regs_proto = {
.ret_btf_id = &bpf_task_pt_regs_ids[0],
};
-BPF_CALL_2(bpf_current_task_under_cgroup, struct bpf_map *, map, u32, idx)
-{
- struct bpf_array *array = container_of(map, struct bpf_array, map);
- struct cgroup *cgrp;
-
- if (unlikely(idx >= array->map.max_entries))
- return -E2BIG;
-
- cgrp = READ_ONCE(array->ptrs[idx]);
- if (unlikely(!cgrp))
- return -EAGAIN;
-
- return task_under_cgroup_hierarchy(current, cgrp);
-}
-
-static const struct bpf_func_proto bpf_current_task_under_cgroup_proto = {
- .func = bpf_current_task_under_cgroup,
- .gpl_only = false,
- .ret_type = RET_INTEGER,
- .arg1_type = ARG_CONST_MAP_PTR,
- .arg2_type = ARG_ANYTHING,
-};
-
struct send_signal_irq_work {
struct irq_work irq_work;
struct task_struct *task;
@@ -1548,8 +1525,6 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
return &bpf_get_numa_node_id_proto;
case BPF_FUNC_perf_event_read:
return &bpf_perf_event_read_proto;
- case BPF_FUNC_current_task_under_cgroup:
- return &bpf_current_task_under_cgroup_proto;
case BPF_FUNC_get_prandom_u32:
return &bpf_get_prandom_u32_proto;
case BPF_FUNC_probe_write_user:
@@ -1578,6 +1553,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
return &bpf_cgrp_storage_get_proto;
case BPF_FUNC_cgrp_storage_delete:
return &bpf_cgrp_storage_delete_proto;
+ case BPF_FUNC_
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Mon, Jul 22, 2024 at 5:45 PM Dragos Tatulea wrote:
>
> On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > to set the mac address
> > >
> > > Tested in ConnectX-6 Dx device
> > >
> > > Signed-off-by: Cindy Lu
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > 1 file changed, 25 insertions(+)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index ecfc16151d61..415b527a9c72 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > destroy_workqueue(wq);
> > > mgtdev->ndev = NULL;
> > > }
> > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > + struct vdpa_device *dev,
> > > + const struct vdpa_dev_set_config
> > > *add_config)
> > > +{
> > > + struct mlx5_vdpa_dev *mvdev;
> > > + struct mlx5_vdpa_net *ndev;
> > > + struct mlx5_core_dev *mdev;
> > > + struct virtio_net_config *config;
> > > + struct mlx5_core_dev *pfmdev;
> Reverse xmas tree?
>
> > > + int err = -EOPNOTSUPP;
> > > +
> > > + mvdev = to_mvdev(dev);
> > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > + mdev = mvdev->mdev;
> > > + config = &ndev->config;
> > > +
> You still need to take the ndev->reslock.
>
> > > + if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > + if (!err)
> > > + memcpy(config->mac, add_config->net.mac,
> > > ETH_ALEN);
> What is the expected behaviour when the device is in use?
Should be a fault of the mgmt layer, so I think we probably don't need
to worry about that.
Thanks
>
> > > + }
> > > + return err;
> >
> > Similar to net simulator, how could be serialize the modification to
> > mac address:
> >
> > 1) from vdpa tool
> > 2) via control virtqueue
> >
> > Thanks
> >
> > > +}
> > >
> > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > .dev_add = mlx5_vdpa_dev_add,
> > > .dev_del = mlx5_vdpa_dev_del,
> > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > };
> > >
> > > static struct virtio_device_id id_table[] = {
> > > --
> > > 2.45.0
> > >
> >
> Thanks,
> Dragos
Re: [PATH v4 3/3] vdpa/mlx5: Add the support of set mac address
On Tue, 23 Jul 2024 at 09:28, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 10:48 PM Cindy Lu wrote:
> >
> > On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
> > >
> > > On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> > > >
> > > > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > > > >
> > > > > > Add the function to support setting the MAC address.
> > > > > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > > > > to set the mac address
> > > > > >
> > > > > > Tested in ConnectX-6 Dx device
> > > > > >
> > > > > > Signed-off-by: Cindy Lu
> > > > > > ---
> > > > > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 25 +
> > > > > > 1 file changed, 25 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > index ecfc16151d61..415b527a9c72 100644
> > > > > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > > > > @@ -3785,10 +3785,35 @@ static void mlx5_vdpa_dev_del(struct
> > > > > > vdpa_mgmt_dev *v_mdev, struct vdpa_device *
> > > > > > destroy_workqueue(wq);
> > > > > > mgtdev->ndev = NULL;
> > > > > > }
> > > > > > +static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
> > > > > > + struct vdpa_device *dev,
> > > > > > + const struct vdpa_dev_set_config
> > > > > > *add_config)
> > > > > > +{
> > > > > > + struct mlx5_vdpa_dev *mvdev;
> > > > > > + struct mlx5_vdpa_net *ndev;
> > > > > > + struct mlx5_core_dev *mdev;
> > > > > > + struct virtio_net_config *config;
> > > > > > + struct mlx5_core_dev *pfmdev;
> > > > Reverse xmas tree?
> > > >
> > > will fix this
> > > > > > + int err = -EOPNOTSUPP;
> > > > > > +
> > > > > > + mvdev = to_mvdev(dev);
> > > > > > + ndev = to_mlx5_vdpa_ndev(mvdev);
> > > > > > + mdev = mvdev->mdev;
> > > > > > + config = &ndev->config;
> > > > > > +
> > > > You still need to take the ndev->reslock.
> > > >
> > > sure, will do
> > > > > > + if (add_config->mask & (1 <<
> > > > > > VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> > > > > > + pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
> > > > > > + err = mlx5_mpfs_add_mac(pfmdev, config->mac);
> > > > > > + if (!err)
> > > > > > + memcpy(config->mac, add_config->net.mac,
> > > > > > ETH_ALEN);
> > > > What is the expected behaviour when the device is in use?
> > > >
> > > if the err is 0 then copy the Mac address to config
> > > will change this code to make it more clear
> > > Thanks
> > > Cindy
> > sorry for the misunderstanding. The VDPA tool does not support
> > changing the MAC address after the guest is loaded. I think I can add
> > a check for VIRTIO_CONFIG_S_DRIVER_OK here?
>
> Still racy, and I think we probably don't worry about that case. It's
> the fault of the mgmt layer not us.
>
> Thanks
>
Sure, Thanks Jason. will send a new version soon
Thanks
cindy
> > Thanks
> > cindy
> > > > > > + }
> > > > > > + return err;
> > > > >
> > > > > Similar to net simulator, how could be serialize the modification to
> > > > > mac address:
> > > > >
> > > > > 1) from vdpa tool
> > > > > 2) via control virtqueue
> > > > >
> > > > > Thanks
> > > > >
> > > > > > +}
> > > > > >
> > > > > > static const struct vdpa_mgmtdev_ops mdev_ops = {
> > > > > > .dev_add = mlx5_vdpa_dev_add,
> > > > > > .dev_del = mlx5_vdpa_dev_del,
> > > > > > + .dev_set_attr = mlx5_vdpa_set_attr,
> > > > > > };
> > > > > >
> > > > > > static struct virtio_device_id id_table[] = {
> > > > > > --
> > > > > > 2.45.0
> > > > > >
> > > > >
> > > > Thanks,
> > > > Dragos
> >
>
Re: [PATCH 1/2] x86/tdx: Add prctl to allow userlevel TDX hypercalls
Thanks for the review, Kirill. On Mon, Jul 08, 2024 at 03:19:54PM +0300, Kirill A . Shutemov wrote: > Hm. Per-thread flag is odd. I think it should be per-process. This is the only point I might need some clarification on. I agree there doesn't seem to be much value in allowing per-thread control, but I don't see any precedence for setting per-process flags through arch_prctl or similar interfaces. Am I missing something?
[PATH v5 0/3] vdpa: support set mac address from vdpa tool
Add support for setting the MAC address using the VDPA tool. This feature will allow setting the MAC address using the VDPA tool. For example, in vdpa_sim_net, the implementation sets the MAC address to the config space. However, for other drivers, they can implement their own function, not limited to the config space. Changelog v2 - Changed the function name to prevent misunderstanding - Added check for blk device - Addressed the comments Changelog v3 - Split the function of the net device from vdpa_nl_cmd_dev_attr_set_doit - Add a lock for the network device's dev_set_attr operation - Address the comments Changelog v4 - Address the comments - Add a lock for the vdap_sim?_net device's dev_set_attr operation Changelog v5 - Address the comments Cindy Lu (3): vdpa: support set mac address from vdpa tool vdpa_sim_net: Add the support of set mac address vdpa/mlx5: Add the support of set mac address drivers/vdpa/mlx5/net/mlx5_vnet.c| 28 ++ drivers/vdpa/vdpa.c | 84 drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +++- include/linux/vdpa.h | 9 +++ include/uapi/linux/vdpa.h| 1 + 5 files changed, 143 insertions(+), 1 deletion(-) -- 2.45.0
[PATH v5 1/3] vdpa: support set mac address from vdpa tool
Add new UAPI to support the mac address from vdpa tool
Function vdpa_nl_cmd_dev_attr_set_doit() will get the
new MAC address from the vdpa tool and then set it to the device.
The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
Here is example:
root@L1# vdpa -jp dev config show vdpa0
{
"config": {
"vdpa0": {
"mac": "82:4d:e9:5d:d7:e6",
"link ": "up",
"link_announce ": false,
"mtu": 1500
}
}
}
root@L1# vdpa dev set name vdpa0 mac 00:11:22:33:44:55
root@L1# vdpa -jp dev config show vdpa0
{
"config": {
"vdpa0": {
"mac": "00:11:22:33:44:55",
"link ": "up",
"link_announce ": false,
"mtu": 1500
}
}
}
Signed-off-by: Cindy Lu
---
drivers/vdpa/vdpa.c | 84 +++
include/linux/vdpa.h | 9 +
include/uapi/linux/vdpa.h | 1 +
3 files changed, 94 insertions(+)
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index 8d391947eb8d..07d61ee62839 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -1361,6 +1361,85 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
sk_buff *skb, struct genl_info
return err;
}
+static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
+ struct genl_info *info)
+{
+ struct vdpa_dev_set_config set_config = {};
+ const u8 *macaddr;
+ struct vdpa_mgmt_dev *mdev = vdev->mdev;
+ struct nlattr **nl_attrs = info->attrs;
+ int err = -EINVAL;
+
+ if (!vdev->mdev)
+ return -EINVAL;
+
+ down_write(&vdev->cf_lock);
+ if ((mdev->supported_features & BIT_ULL(VIRTIO_NET_F_MAC)) &&
+ nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
+ set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
+ macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
+
+ if (is_valid_ether_addr(macaddr)) {
+ memcpy(set_config.net.mac, macaddr, ETH_ALEN);
+ if (mdev->ops->dev_set_attr) {
+ err = mdev->ops->dev_set_attr(mdev, vdev,
+ &set_config);
+ } else {
+ NL_SET_ERR_MSG_FMT_MOD(info->extack,
+ "device not supported");
+ }
+ } else {
+ NL_SET_ERR_MSG_FMT_MOD(info->extack,
+ "Invalid MAC address");
+ }
+ }
+ up_write(&vdev->cf_lock);
+ return err;
+}
+static int vdpa_nl_cmd_dev_attr_set_doit(struct sk_buff *skb,
+struct genl_info *info)
+{
+ const char *name;
+ int err = 0;
+ struct device *dev;
+ struct vdpa_device *vdev;
+ u64 classes;
+
+ if (!info->attrs[VDPA_ATTR_DEV_NAME])
+ return -EINVAL;
+
+ name = nla_data(info->attrs[VDPA_ATTR_DEV_NAME]);
+
+ down_write(&vdpa_dev_lock);
+ dev = bus_find_device(&vdpa_bus, NULL, name, vdpa_name_match);
+ if (!dev) {
+ NL_SET_ERR_MSG_MOD(info->extack, "device not found");
+ err = -ENODEV;
+ goto dev_err;
+ }
+ vdev = container_of(dev, struct vdpa_device, dev);
+ if (!vdev->mdev) {
+ NL_SET_ERR_MSG_MOD(
+ info->extack,
+ "Fail to find the specified management device");
+ err = -EINVAL;
+ goto mdev_err;
+ }
+ classes = vdpa_mgmtdev_get_classes(vdev->mdev, NULL);
+ if (classes & BIT_ULL(VIRTIO_ID_NET)) {
+ err = vdpa_dev_net_device_attr_set(vdev, info);
+ } else {
+ NL_SET_ERR_MSG_FMT_MOD(info->extack, "%s device not supported",
+ name);
+ }
+
+mdev_err:
+ put_device(dev);
+dev_err:
+ up_write(&vdpa_dev_lock);
+ return err;
+}
+
static int vdpa_dev_config_dump(struct device *dev, void *data)
{
struct vdpa_device *vdev = container_of(dev, struct vdpa_device, dev);
@@ -1497,6 +1576,11 @@ static const struct genl_ops vdpa_nl_ops[] = {
.doit = vdpa_nl_cmd_dev_stats_get_doit,
.flags = GENL_ADMIN_PERM,
},
+ {
+ .cmd = VDPA_CMD_DEV_ATTR_SET,
+ .doit = vdpa_nl_cmd_dev_attr_set_doit,
+ .flags = GENL_ADMIN_PERM,
+ },
};
static struct genl_family vdpa_nl_family __ro_after_init = {
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 7977ca03ac7a..3511156c10db 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -582,11 +582,20 @@ void vdpa_set_status(struct vdpa_device *vdev, u8 status);
* @dev: vdpa device to remove
* Driver
[PATH v5 2/3] vdpa_sim_net: Add the support of set mac address
Add the function to support setting the MAC address.
For vdpa_sim_net, the driver will write the MAC address
to the config space, and other devices can implement
their own functions to support this.
Signed-off-by: Cindy Lu
---
drivers/vdpa/vdpa_sim/vdpa_sim_net.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
index cfe962911804..936e33e5021a 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim_net.c
@@ -414,6 +414,25 @@ static void vdpasim_net_get_config(struct vdpasim
*vdpasim, void *config)
net_config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
}
+static int vdpasim_net_set_attr(struct vdpa_mgmt_dev *mdev,
+ struct vdpa_device *dev,
+ const struct vdpa_dev_set_config *config)
+{
+ struct vdpasim *vdpasim = container_of(dev, struct vdpasim, vdpa);
+ struct virtio_net_config *vio_config = vdpasim->config;
+
+ mutex_lock(&vdpasim->mutex);
+
+ if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
+ memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
+ mutex_unlock(&vdpasim->mutex);
+ return 0;
+ }
+
+ mutex_unlock(&vdpasim->mutex);
+ return -EINVAL;
+}
+
static void vdpasim_net_setup_config(struct vdpasim *vdpasim,
const struct vdpa_dev_set_config *config)
{
@@ -510,7 +529,8 @@ static void vdpasim_net_dev_del(struct vdpa_mgmt_dev *mdev,
static const struct vdpa_mgmtdev_ops vdpasim_net_mgmtdev_ops = {
.dev_add = vdpasim_net_dev_add,
- .dev_del = vdpasim_net_dev_del
+ .dev_del = vdpasim_net_dev_del,
+ .dev_set_attr = vdpasim_net_set_attr
};
static struct virtio_device_id id_table[] = {
--
2.45.0
[PATH v5 3/3] vdpa/mlx5: Add the support of set mac address
Add the function to support setting the MAC address.
For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
to set the mac address
Tested in ConnectX-6 Dx device
Signed-off-by: Cindy Lu
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index ecfc16151d61..7fce952d650f 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -3785,10 +3785,38 @@ static void mlx5_vdpa_dev_del(struct vdpa_mgmt_dev
*v_mdev, struct vdpa_device *
destroy_workqueue(wq);
mgtdev->ndev = NULL;
}
+static int mlx5_vdpa_set_attr(struct vdpa_mgmt_dev *v_mdev,
+ struct vdpa_device *dev,
+ const struct vdpa_dev_set_config *add_config)
+{
+ struct virtio_net_config *config;
+ struct mlx5_core_dev *pfmdev;
+ struct mlx5_vdpa_dev *mvdev;
+ struct mlx5_vdpa_net *ndev;
+ struct mlx5_core_dev *mdev;
+ int err = -EINVAL;
+
+ mvdev = to_mvdev(dev);
+ ndev = to_mlx5_vdpa_ndev(mvdev);
+ mdev = mvdev->mdev;
+ config = &ndev->config;
+
+ down_write(&ndev->reslock);
+ if (add_config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
+ pfmdev = pci_get_drvdata(pci_physfn(mdev->pdev));
+ err = mlx5_mpfs_add_mac(pfmdev, config->mac);
+ if (0 == err)
+ memcpy(config->mac, add_config->net.mac, ETH_ALEN);
+ }
+
+ up_write(&ndev->reslock);
+ return err;
+}
static const struct vdpa_mgmtdev_ops mdev_ops = {
.dev_add = mlx5_vdpa_dev_add,
.dev_del = mlx5_vdpa_dev_del,
+ .dev_set_attr = mlx5_vdpa_set_attr,
};
static struct virtio_device_id id_table[] = {
--
2.45.0
Re: [PATCH 04/17] arch, mm: move definition of node_data to generic code
On Tue, 16 Jul 2024, Mike Rapoport wrote:\n From: "Mike Rapoport (Microsoft)" Every architecture that supports NUMA defines node_data in the same way: struct pglist_data *node_data[MAX_NUMNODES]; No reason to keep multiple copies of this definition and its forward declarations, especially when such forward declaration is the only thing in include/asm/mmzone.h for many architectures. Add definition and declaration of node_data to generic code and drop architecture-specific versions. Signed-off-by: Mike Rapoport (Microsoft) Nice cleanup. Acked-by: Davidlohr Bueso
Re: [PATH v5 1/3] vdpa: support set mac address from vdpa tool
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
>
> Add new UAPI to support the mac address from vdpa tool
> Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> new MAC address from the vdpa tool and then set it to the device.
>
> The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
>
> Here is example:
> root@L1# vdpa -jp dev config show vdpa0
> {
> "config": {
> "vdpa0": {
> "mac": "82:4d:e9:5d:d7:e6",
> "link ": "up",
> "link_announce ": false,
> "mtu": 1500
> }
> }
> }
>
> root@L1# vdpa dev set name vdpa0 mac 00:11:22:33:44:55
>
> root@L1# vdpa -jp dev config show vdpa0
> {
> "config": {
> "vdpa0": {
> "mac": "00:11:22:33:44:55",
> "link ": "up",
> "link_announce ": false,
> "mtu": 1500
> }
> }
> }
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/vdpa.c | 84 +++
> include/linux/vdpa.h | 9 +
> include/uapi/linux/vdpa.h | 1 +
> 3 files changed, 94 insertions(+)
>
> diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> index 8d391947eb8d..07d61ee62839 100644
> --- a/drivers/vdpa/vdpa.c
> +++ b/drivers/vdpa/vdpa.c
> @@ -1361,6 +1361,85 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
> sk_buff *skb, struct genl_info
> return err;
> }
>
> +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> + struct genl_info *info)
> +{
> + struct vdpa_dev_set_config set_config = {};
> + const u8 *macaddr;
> + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> + struct nlattr **nl_attrs = info->attrs;
> + int err = -EINVAL;
> +
> + if (!vdev->mdev)
> + return -EINVAL;
It looks like the caller has already done this check?
> +
> + down_write(&vdev->cf_lock);
> + if ((mdev->supported_features & BIT_ULL(VIRTIO_NET_F_MAC)) &&
This is not a virtio feature, so I don't get why we need to check
VIRTIO_NET_F_MAC.
> + nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
> + set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
> + macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
> +
> + if (is_valid_ether_addr(macaddr)) {
> + memcpy(set_config.net.mac, macaddr, ETH_ALEN);
> + if (mdev->ops->dev_set_attr) {
> + err = mdev->ops->dev_set_attr(mdev, vdev,
> + &set_config);
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> + "device not
> supported");
"Device does not support setting mac address" ?
> + }
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> + "Invalid MAC address");
> + }
> + }
> + up_write(&vdev->cf_lock);
> + return err;
> +}
> +static int vdpa_nl_cmd_dev_attr_set_doit(struct sk_buff *skb,
> +struct genl_info *info)
> +{
> + const char *name;
> + int err = 0;
> + struct device *dev;
> + struct vdpa_device *vdev;
> + u64 classes;
> +
> + if (!info->attrs[VDPA_ATTR_DEV_NAME])
> + return -EINVAL;
> +
> + name = nla_data(info->attrs[VDPA_ATTR_DEV_NAME]);
> +
> + down_write(&vdpa_dev_lock);
> + dev = bus_find_device(&vdpa_bus, NULL, name, vdpa_name_match);
> + if (!dev) {
> + NL_SET_ERR_MSG_MOD(info->extack, "device not found");
> + err = -ENODEV;
> + goto dev_err;
> + }
> + vdev = container_of(dev, struct vdpa_device, dev);
> + if (!vdev->mdev) {
> + NL_SET_ERR_MSG_MOD(
> + info->extack,
> + "Fail to find the specified management device");
> + err = -EINVAL;
> + goto mdev_err;
> + }
> + classes = vdpa_mgmtdev_get_classes(vdev->mdev, NULL);
> + if (classes & BIT_ULL(VIRTIO_ID_NET)) {
> + err = vdpa_dev_net_device_attr_set(vdev, info);
> + } else {
> + NL_SET_ERR_MSG_FMT_MOD(info->extack, "%s device not
> supported",
> + name);
> + }
> +
> +mdev_err:
> + put_device(dev);
> +dev_err:
> + up_write(&vdpa_dev_lock);
> + return err;
> +}
> +
> static int vdpa_dev_config_dump(struct device *dev, void *data)
> {
> struct vdpa_device *vdev = container_of(dev, struct vdpa_device, dev);
> @@ -1497,6 +1576,11 @@ static const struct genl_ops vdpa_nl_ops[] = {
> .doit = vdpa_nl_cmd_dev_stats_get_doit,
> .flags = GENL_ADMIN_PERM,
> },
> + {
>
Re: [PATH v5 2/3] vdpa_sim_net: Add the support of set mac address
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote: > > Add the function to support setting the MAC address. > For vdpa_sim_net, the driver will write the MAC address > to the config space, and other devices can implement > their own functions to support this. > > Signed-off-by: Cindy Lu Acked-by: Jason Wang Thanks
Re: [PATH v5 3/3] vdpa/mlx5: Add the support of set mac address
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote: > > Add the function to support setting the MAC address. > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac > to set the mac address > > Tested in ConnectX-6 Dx device > > Signed-off-by: Cindy Lu Acked-by: Jason Wang Thanks
Re: [PATH v5 1/3] vdpa: support set mac address from vdpa tool
On Tue, 23 Jul 2024 at 14:01, Jason Wang wrote:
>
> On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
> >
> > Add new UAPI to support the mac address from vdpa tool
> > Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> > new MAC address from the vdpa tool and then set it to the device.
> >
> > The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
> >
> > Here is example:
> > root@L1# vdpa -jp dev config show vdpa0
> > {
> > "config": {
> > "vdpa0": {
> > "mac": "82:4d:e9:5d:d7:e6",
> > "link ": "up",
> > "link_announce ": false,
> > "mtu": 1500
> > }
> > }
> > }
> >
> > root@L1# vdpa dev set name vdpa0 mac 00:11:22:33:44:55
> >
> > root@L1# vdpa -jp dev config show vdpa0
> > {
> > "config": {
> > "vdpa0": {
> > "mac": "00:11:22:33:44:55",
> > "link ": "up",
> > "link_announce ": false,
> > "mtu": 1500
> > }
> > }
> > }
> >
> > Signed-off-by: Cindy Lu
> > ---
> > drivers/vdpa/vdpa.c | 84 +++
> > include/linux/vdpa.h | 9 +
> > include/uapi/linux/vdpa.h | 1 +
> > 3 files changed, 94 insertions(+)
> >
> > diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
> > index 8d391947eb8d..07d61ee62839 100644
> > --- a/drivers/vdpa/vdpa.c
> > +++ b/drivers/vdpa/vdpa.c
> > @@ -1361,6 +1361,85 @@ static int vdpa_nl_cmd_dev_config_get_doit(struct
> > sk_buff *skb, struct genl_info
> > return err;
> > }
> >
> > +static int vdpa_dev_net_device_attr_set(struct vdpa_device *vdev,
> > + struct genl_info *info)
> > +{
> > + struct vdpa_dev_set_config set_config = {};
> > + const u8 *macaddr;
> > + struct vdpa_mgmt_dev *mdev = vdev->mdev;
> > + struct nlattr **nl_attrs = info->attrs;
> > + int err = -EINVAL;
> > +
> > + if (!vdev->mdev)
> > + return -EINVAL;
>
> It looks like the caller has already done this check?
>
sure, will remove this
> > +
> > + down_write(&vdev->cf_lock);
> > + if ((mdev->supported_features & BIT_ULL(VIRTIO_NET_F_MAC)) &&
>
> This is not a virtio feature, so I don't get why we need to check
> VIRTIO_NET_F_MAC.
>
will remove this
> > + nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]) {
> > + set_config.mask |= BIT_ULL(VDPA_ATTR_DEV_NET_CFG_MACADDR);
> > + macaddr = nla_data(nl_attrs[VDPA_ATTR_DEV_NET_CFG_MACADDR]);
> > +
> > + if (is_valid_ether_addr(macaddr)) {
> > + memcpy(set_config.net.mac, macaddr, ETH_ALEN);
> > + if (mdev->ops->dev_set_attr) {
> > + err = mdev->ops->dev_set_attr(mdev, vdev,
> > + &set_config);
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> > + "device not
> > supported");
>
> "Device does not support setting mac address" ?
>
sure, will change this
Thanks
cindy
> > + }
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack,
> > + "Invalid MAC address");
> > + }
> > + }
> > + up_write(&vdev->cf_lock);
> > + return err;
> > +}
> > +static int vdpa_nl_cmd_dev_attr_set_doit(struct sk_buff *skb,
> > +struct genl_info *info)
> > +{
> > + const char *name;
> > + int err = 0;
> > + struct device *dev;
> > + struct vdpa_device *vdev;
> > + u64 classes;
> > +
> > + if (!info->attrs[VDPA_ATTR_DEV_NAME])
> > + return -EINVAL;
> > +
> > + name = nla_data(info->attrs[VDPA_ATTR_DEV_NAME]);
> > +
> > + down_write(&vdpa_dev_lock);
> > + dev = bus_find_device(&vdpa_bus, NULL, name, vdpa_name_match);
> > + if (!dev) {
> > + NL_SET_ERR_MSG_MOD(info->extack, "device not found");
> > + err = -ENODEV;
> > + goto dev_err;
> > + }
> > + vdev = container_of(dev, struct vdpa_device, dev);
> > + if (!vdev->mdev) {
> > + NL_SET_ERR_MSG_MOD(
> > + info->extack,
> > + "Fail to find the specified management device");
> > + err = -EINVAL;
> > + goto mdev_err;
> > + }
> > + classes = vdpa_mgmtdev_get_classes(vdev->mdev, NULL);
> > + if (classes & BIT_ULL(VIRTIO_ID_NET)) {
> > + err = vdpa_dev_net_device_attr_set(vdev, info);
> > + } else {
> > + NL_SET_ERR_MSG_FMT_MOD(info->extack, "%s device not
> > supported",
> > + name);
> > + }
> > +
> > +mdev_err:
> > + put_device(dev);
> > +dev_err:
> > + up_write(&v
[PATCH v2 0/5] kallsyms: Emit symbol for holes in text and fix weak function issue
Background of this patch set can be found in v1:
https://lore.kernel.org/all/20240613133711.2867745-1-zhengyeji...@huawei.com/
Here add a reproduction to show the impact to livepatch:
1. Add following hack to make livepatch-sample.ko do patch on do_one_initcall()
which has an overriden weak function behind in vmlinux, then print the
actually used __fentry__ location:
diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
index 90408500e5a3..20b75e7b1771 100644
--- a/kernel/livepatch/patch.c
+++ b/kernel/livepatch/patch.c
@@ -173,6 +173,8 @@ static int klp_patch_func(struct klp_func *func)
unsigned long ftrace_loc;
ftrace_loc = ftrace_location((unsigned long)func->old_func);
+ pr_info("%s: old_func=%pS ftrace_loc=%pS (%lx)\n", __func__,
+ func->old_func, (void *)ftrace_loc, ftrace_loc);
if (!ftrace_loc) {
pr_err("failed to find location for function '%s'\n",
func->old_name);
diff --git a/samples/livepatch/livepatch-sample.c
b/samples/livepatch/livepatch-sample.c
index cd76d7ebe598..c6e8e78e23b8 100644
--- a/samples/livepatch/livepatch-sample.c
+++ b/samples/livepatch/livepatch-sample.c
@@ -38,7 +38,7 @@ static int livepatch_cmdline_proc_show(struct seq_file *m,
void *v)
static struct klp_func funcs[] = {
{
- .old_name = "cmdline_proc_show",
+ .old_name = "do_one_initcall",
.new_func = livepatch_cmdline_proc_show,
}, { }
};
2. We can see the size of do_one_initcall() is 0x27e:
$ nm -nS vmlinux | grep do_one_initcall
810021e0 027e T do_one_initcall
3. Insert the livepatch ko, the expected ftrace_loc is
do_one_initcall+0x4/0x27e but
actually do_one_initcall+0x294/0x2c0 which is invalid, also its size is
inaccurate.
Then this livepatch can not properly work!!!
# insmod livepatch-sample.ko
[ 17.942451] livepatch: klp_patch_func: old_func=do_one_initcall+0x0/0x2c0
ftrace_loc=do_one_initcall+0x294/0x2c0 (81002474)
#
# cat /sys/kernel/tracing/available_filter_functions_addrs | grep
81002474
81002474 __ftrace_invalid_address___660
After this patch, this issue is gone:
# insmod livepatch-sample.ko
[ 42.408632] livepatch: klp_patch_func: old_func=do_one_initcall+0x0/0x27e
ftrace_loc=do_one_initcall+0x4/0x27e (810021e4)
# cat /sys/kernel/tracing/available_filter_functions_addrs | grep
810021e4
810021e4 do_one_initcall
# cat /sys/kernel/tracing/enabled_functions
do_one_initcall (1) I M tramp: 0xa002
(klp_ftrace_handler+0x0/0x258)->klp_ftrace_handler+0x0/0x258
Changes:
v1->v2:
- Drop patch which titled "kallsyms: Optimize multiple times of realloc() to
one time of malloc()"
as suggested by Masahiro;
Link:
https://lore.kernel.org/all/CAK7LNAQkSnZ1nVXiZH9kg52H-A_=urcsv-w7wgxvunmghgx...@mail.gmail.com/
- Changes in PATCH 1/5:
- Change may_exist_hole_after_symbol() to has_hole() and return bool type;
- User realloc instead of malloc another table in emit_hole_symbols();
Link:
https://lore.kernel.org/all/CAK7LNAQaLc6aDK85qQtPHoCkQSGyL-TxXjpgJTfehe2Q1=j...@mail.gmail.com/
- Use empty symbol type/name as a special case to represent the hole
instead of
using symbol "t__hole_symbol_X";
Link:
https://lore.kernel.org/all/cak7lnarir5z9hprg932t7yjrwqkx_qz7wkmbxx7ito2w5yj...@mail.gmail.com/
- Changes in PATCH 3/5:
- Now name of hole symbol is NULL, so if __fentry__ is located in a hole,
kallsyms_lookup() find an NULL name then will return 0, so drop the
needless kallsyms_is_hole_symbol().
Zheng Yejian (5):
kallsyms: Emit symbol at the holes in the text
module: kallsyms: Determine exact function size
ftrace: Skip invalid __fentry__ in ftrace_process_locs()
ftrace: Fix possible out-of-bound issue in ftrace_process_locs()
ftrace: Revert the FTRACE_MCOUNT_MAX_OFFSET workaround
arch/powerpc/include/asm/ftrace.h | 7 --
arch/x86/include/asm/ftrace.h | 7 --
include/linux/module.h| 14 +++
kernel/module/kallsyms.c | 42 ++--
kernel/trace/ftrace.c | 171 ++
scripts/kallsyms.c| 95 -
scripts/link-vmlinux.sh | 4 +-
scripts/mksysmap | 2 +-
8 files changed, 173 insertions(+), 169 deletions(-)
--
2.25.1
[PATCH v2 2/5] module: kallsyms: Determine exact function size
When a weak type function is overridden, its symbol will be removed
from the symbol table, but its code will not been removed. It will
cause find_kallsyms_symbol() to compute a larger function size than
it actually is, just because symbol of its following weak function is
removed.
To fix this issue, check that given address is within the size of
the function found.
Signed-off-by: Zheng Yejian
---
include/linux/module.h | 7 +++
kernel/module/kallsyms.c | 19 +--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 4213d8993cd8..0299d79433ae 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -599,6 +599,13 @@ static inline unsigned long kallsyms_symbol_value(const
Elf_Sym *sym)
}
#endif
+#ifndef HAVE_ARCH_KALLSYMS_SYMBOL_TYPE
+static inline unsigned int kallsyms_symbol_type(const Elf_Sym *sym)
+{
+ return ELF_ST_TYPE(sym->st_info);
+}
+#endif
+
/* FIXME: It'd be nice to isolate modules during init, too, so they
aren't used before they (may) fail. But presently too much code
(IDE & SCSI) require entry into the module during init.*/
diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
index bf65e0c3c86f..cce4f81b9933 100644
--- a/kernel/module/kallsyms.c
+++ b/kernel/module/kallsyms.c
@@ -262,6 +262,7 @@ static const char *find_kallsyms_symbol(struct module *mod,
unsigned long nextval, bestval;
struct mod_kallsyms *kallsyms = rcu_dereference_sched(mod->kallsyms);
struct module_memory *mod_mem;
+ const Elf_Sym *sym;
/* At worse, next value is at end of module */
if (within_module_init(addr, mod))
@@ -278,9 +279,10 @@ static const char *find_kallsyms_symbol(struct module *mod,
* starts real symbols at 1).
*/
for (i = 1; i < kallsyms->num_symtab; i++) {
- const Elf_Sym *sym = &kallsyms->symtab[i];
- unsigned long thisval = kallsyms_symbol_value(sym);
+ unsigned long thisval;
+ sym = &kallsyms->symtab[i];
+ thisval = kallsyms_symbol_value(sym);
if (sym->st_shndx == SHN_UNDEF)
continue;
@@ -292,6 +294,13 @@ static const char *find_kallsyms_symbol(struct module *mod,
is_mapping_symbol(kallsyms_symbol_name(kallsyms, i)))
continue;
+ if (kallsyms_symbol_type(sym) == STT_FUNC &&
+ addr >= thisval && addr < thisval + sym->st_size) {
+ best = i;
+ bestval = thisval;
+ nextval = thisval + sym->st_size;
+ goto found;
+ }
if (thisval <= addr && thisval > bestval) {
best = i;
bestval = thisval;
@@ -303,6 +312,12 @@ static const char *find_kallsyms_symbol(struct module *mod,
if (!best)
return NULL;
+ sym = &kallsyms->symtab[best];
+ if (kallsyms_symbol_type(sym) == STT_FUNC && sym->st_size &&
+ addr >= kallsyms_symbol_value(sym) + sym->st_size)
+ return NULL;
+
+found:
if (size)
*size = nextval - bestval;
if (offset)
--
2.25.1
[PATCH v2 5/5] ftrace: Revert the FTRACE_MCOUNT_MAX_OFFSET workaround
After patch titled "ftrace: Skip invalid __fentry__ in
ftrace_process_locs()", __fentry__ locations in overridden weak function
have been checked and skipped, then all records in ftrace_pages are
valid, the FTRACE_MCOUNT_MAX_OFFSET workaround can be reverted, include:
1. commit b39181f7c690 ("ftrace: Add FTRACE_MCOUNT_MAX_OFFSET to avoid
adding weak function")
2. commit 7af82ff90a2b ("powerpc/ftrace: Ignore weak functions")
3. commit f6834c8c59a8 ("powerpc/ftrace: Fix dropping weak symbols with
older toolchains")
Signed-off-by: Zheng Yejian
---
arch/powerpc/include/asm/ftrace.h | 7 --
arch/x86/include/asm/ftrace.h | 7 --
kernel/trace/ftrace.c | 141 +-
3 files changed, 2 insertions(+), 153 deletions(-)
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index 559560286e6d..328cf55acfb7 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -8,13 +8,6 @@
#define MCOUNT_ADDR((unsigned long)(_mcount))
#define MCOUNT_INSN_SIZE 4 /* sizeof mcount call */
-/* Ignore unused weak functions which will have larger offsets */
-#if defined(CONFIG_MPROFILE_KERNEL) ||
defined(CONFIG_ARCH_USING_PATCHABLE_FUNCTION_ENTRY)
-#define FTRACE_MCOUNT_MAX_OFFSET 16
-#elif defined(CONFIG_PPC32)
-#define FTRACE_MCOUNT_MAX_OFFSET 8
-#endif
-
#ifndef __ASSEMBLY__
extern void _mcount(void);
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 0152a81d9b4a..6a3a4a8830dc 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -9,13 +9,6 @@
# define MCOUNT_ADDR ((unsigned long)(__fentry__))
#define MCOUNT_INSN_SIZE 5 /* sizeof mcount call */
-/* Ignore unused weak functions which will have non zero offsets */
-#ifdef CONFIG_HAVE_FENTRY
-# include
-/* Add offset for endbr64 if IBT enabled */
-# define FTRACE_MCOUNT_MAX_OFFSET ENDBR_INSN_SIZE
-#endif
-
#ifdef CONFIG_DYNAMIC_FTRACE
#define ARCH_SUPPORTS_FTRACE_OPS 1
#endif
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 6947be8801d9..37510c591498 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -49,8 +49,6 @@
#define FTRACE_NOCLEAR_FLAGS (FTRACE_FL_DISABLED | FTRACE_FL_TOUCHED | \
FTRACE_FL_MODIFIED)
-#define FTRACE_INVALID_FUNCTION"__ftrace_invalid_address__"
-
#define FTRACE_WARN_ON(cond) \
({ \
int ___r = cond;\
@@ -4208,105 +4206,6 @@ static void add_trampoline_func(struct seq_file *m,
struct ftrace_ops *ops,
seq_printf(m, " ->%pS", ptr);
}
-#ifdef FTRACE_MCOUNT_MAX_OFFSET
-/*
- * Weak functions can still have an mcount/fentry that is saved in
- * the __mcount_loc section. These can be detected by having a
- * symbol offset of greater than FTRACE_MCOUNT_MAX_OFFSET, as the
- * symbol found by kallsyms is not the function that the mcount/fentry
- * is part of. The offset is much greater in these cases.
- *
- * Test the record to make sure that the ip points to a valid kallsyms
- * and if not, mark it disabled.
- */
-static int test_for_valid_rec(struct dyn_ftrace *rec)
-{
- char str[KSYM_SYMBOL_LEN];
- unsigned long offset;
- const char *ret;
-
- ret = kallsyms_lookup(rec->ip, NULL, &offset, NULL, str);
-
- /* Weak functions can cause invalid addresses */
- if (!ret || offset > FTRACE_MCOUNT_MAX_OFFSET) {
- rec->flags |= FTRACE_FL_DISABLED;
- return 0;
- }
- return 1;
-}
-
-static struct workqueue_struct *ftrace_check_wq __initdata;
-static struct work_struct ftrace_check_work __initdata;
-
-/*
- * Scan all the mcount/fentry entries to make sure they are valid.
- */
-static __init void ftrace_check_work_func(struct work_struct *work)
-{
- struct ftrace_page *pg;
- struct dyn_ftrace *rec;
-
- mutex_lock(&ftrace_lock);
- do_for_each_ftrace_rec(pg, rec) {
- test_for_valid_rec(rec);
- } while_for_each_ftrace_rec();
- mutex_unlock(&ftrace_lock);
-}
-
-static int __init ftrace_check_for_weak_functions(void)
-{
- INIT_WORK(&ftrace_check_work, ftrace_check_work_func);
-
- ftrace_check_wq = alloc_workqueue("ftrace_check_wq", WQ_UNBOUND, 0);
-
- queue_work(ftrace_check_wq, &ftrace_check_work);
- return 0;
-}
-
-static int __init ftrace_check_sync(void)
-{
- /* Make sure the ftrace_check updates are finished */
- if (ftrace_check_wq)
- destroy_workqueue(ftrace_check_wq);
- return 0;
-}
-
-late_initcall_sync(ftrace_check_sync);
-subsys_initcall(ftrace_check_for_weak_functions);
-
-static int print_rec(struct seq_file *m, unsigned long ip)
-{
- unsigned long offset;
- char str[KSYM_SYMBOL_LEN];
- char *modname;
- const char *ret;
-
- ret = kall
[PATCH v2 3/5] ftrace: Skip invalid __fentry__ in ftrace_process_locs()
ftrace_location() was changed to not only return the __fentry__ location
when called for the __fentry__ location, but also when called for the
sym+0 location after commit aebfd12521d9 ("x86/ibt,ftrace: Search for
__fentry__ location"). That is, if sym+0 location is not __fentry__,
ftrace_location() would find one over the entire size of the sym.
However, there is case that more than one __fentry__ exist in the sym
range (described below) and ftrace_location() would find wrong __fentry__
location by binary searching, which would cause its users like livepatch/
kprobe/bpf to not work properly on this sym!
The case is that, based on current compiler behavior, suppose:
- function A is followed by weak function B1 in same binary file;
- weak function B1 is overridden by function B2;
Then in the final binary file:
- symbol B1 will be removed from symbol table while its instructions are
not removed;
- __fentry__ of B1 will be still in __mcount_loc table;
- function size of A is computed by substracting the symbol address of
A from its next symbol address (see kallsyms_lookup_size_offset()),
but because symbol info of B1 is removed, the next symbol of A is
originally the next symbol of B1. See following example, function
sizeof A will be (symbol_address_C - symbol_address_A):
symbol_address_A
symbol_address_B1 (Not in symbol table)
symbol_address_C
The weak function issue has been discovered in commit b39181f7c690
("ftrace: Add FTRACE_MCOUNT_MAX_OFFSET to avoid adding weak function")
but it didn't resolve the issue in ftrace_location().
To solve the issue, with Peter's suggestions, in previous patches, all
holes in the text have been found and filled with specail symbols, also
the same case with module weak function has been handled. Then check and
skip __fentry__ that locate in the holes.
Also in this patch, introduce module_kallsyms_find_symbol() to check if
a __fentry__ locate in a valid function of the given module. It is needed
because other symbol lookup functions like module_address_lookup() will
find module of the passed address first, but as ftrace_process_locs() is
called, the module has not been fully loaded, so those lookup functions
can not work.
Fixes: aebfd12521d9 ("x86/ibt,ftrace: Search for __fentry__ location")
Signed-off-by: Zheng Yejian
---
include/linux/module.h | 7 +++
kernel/module/kallsyms.c | 23 +--
kernel/trace/ftrace.c| 12 +++-
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index 0299d79433ae..4f5dd018e33d 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -962,6 +962,8 @@ int module_get_kallsym(unsigned int symnum, unsigned long
*value, char *type,
unsigned long module_kallsyms_lookup_name(const char *name);
unsigned long find_kallsyms_symbol_value(struct module *mod, const char *name);
+int module_kallsyms_find_symbol(struct module *mod, unsigned long addr,
+ unsigned long *size, unsigned long *offset);
#else /* CONFIG_MODULES && CONFIG_KALLSYMS */
@@ -1006,6 +1008,11 @@ static inline unsigned long
find_kallsyms_symbol_value(struct module *mod,
return 0;
}
+static inline int module_kallsyms_find_symbol(struct module *mod, unsigned
long addr,
+ unsigned long *size, unsigned
long *offset)
+{
+ return 0;
+}
#endif /* CONFIG_MODULES && CONFIG_KALLSYMS */
#endif /* _LINUX_MODULE_H */
diff --git a/kernel/module/kallsyms.c b/kernel/module/kallsyms.c
index cce4f81b9933..71b3ed25cd40 100644
--- a/kernel/module/kallsyms.c
+++ b/kernel/module/kallsyms.c
@@ -253,10 +253,10 @@ static const char *kallsyms_symbol_name(struct
mod_kallsyms *kallsyms, unsigned
* Given a module and address, find the corresponding symbol and return its
name
* while providing its size and offset if needed.
*/
-static const char *find_kallsyms_symbol(struct module *mod,
- unsigned long addr,
- unsigned long *size,
- unsigned long *offset)
+static const char *__find_kallsyms_symbol(struct module *mod,
+ unsigned long addr,
+ unsigned long *size,
+ unsigned long *offset)
{
unsigned int i, best = 0;
unsigned long nextval, bestval;
@@ -326,6 +326,17 @@ static const char *find_kallsyms_symbol(struct module *mod,
return kallsyms_symbol_name(kallsyms, best);
}
+int module_kallsyms_find_symbol(struct module *mod, unsigned long addr,
+ unsigned long *size, unsigned long *offset)
+{
+ const char *ret;
+
+ preempt_disable();
+ ret = __find_kallsyms_symbol(mod, addr, size, offset);
+ preempt_enable();
+ return !!ret;
+}
+
void * __weak de
[PATCH v2 4/5] ftrace: Fix possible out-of-bound issue in ftrace_process_locs()
In ftrace_process_locs(), a series pages are prepared and linked in
start_pg, then fentry records are skipped or added, then unused pages
are freed.
However, assume that all records are skipped, currently the start_pg
will still be in list of ftrace_pages_start but without any record.
Then in ftrace_free_mem() index record by (pg->index - 1) will be out
of bound.
To fix this issue, properly handle with unused start_pg and add
WARN_ON_ONCE() where the records need to be indexed.
Fixes: 26efd79c4624 ("ftrace: Fix possible warning on checking all pages used
in ftrace_process_locs()")
Signed-off-by: Zheng Yejian
---
kernel/trace/ftrace.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index fff5d3466c41..6947be8801d9 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -7087,10 +7087,22 @@ static int ftrace_process_locs(struct module *mod,
rec->ip = addr;
}
- if (pg->next) {
+ if (pg->index == 0) {
+ /* No record is added on the current page, so it's unused */
+ pg_unuse = pg;
+ } else if (pg->next) {
+ /* Current page has records, so it's next page is unused */
pg_unuse = pg->next;
pg->next = NULL;
}
+ /*
+* Even the start_pg hasn't been used, that means, no record has
+* been added, so restore state of ftrace_pages and just go out.
+*/
+ if (pg_unuse == start_pg) {
+ ftrace_pages->next = NULL;
+ goto out;
+ }
/* Assign the last page to ftrace_pages */
ftrace_pages = pg;
@@ -7306,6 +7318,8 @@ void ftrace_release_mod(struct module *mod)
*/
last_pg = &ftrace_pages_start;
for (pg = ftrace_pages_start; pg; pg = *last_pg) {
+ /* The page should have at lease one record */
+ WARN_ON_ONCE(!pg->index);
rec = &pg->records[0];
if (within_module(rec->ip, mod)) {
/*
@@ -7685,6 +7699,8 @@ void ftrace_free_mem(struct module *mod, void *start_ptr,
void *end_ptr)
mod_map = allocate_ftrace_mod_map(mod, start, end);
for (pg = ftrace_pages_start; pg; last_pg = &pg->next, pg = *last_pg) {
+ /* The page should have at lease one record */
+ WARN_ON_ONCE(!pg->index);
if (end < pg->records[0].ip ||
start >= (pg->records[pg->index - 1].ip + MCOUNT_INSN_SIZE))
continue;
--
2.25.1
[PATCH v2 1/5] kallsyms: Emit symbol at the holes in the text
When a weak type function is overridden, its symbol will be removed
from the symbol table, but its code will not be removed. Besides,
due to lacking of size for kallsyms, kernel compute function size by
substracting its symbol address from its next symbol address (see
kallsyms_lookup_size_offset()). These will cause that size of some
function is computed to be larger than it actually is, just because
symbol of its following weak function is removed.
This issue also causes multiple __fentry__ locations to be counted in
the same function scope, and eventually causes ftrace_location() to find
wrong __fentry__ location. It was reported in
Link:
https://lore.kernel.org/all/20240607115211.734845-1-zhengyeji...@huawei.com/
Peter suggested to change scipts/kallsyms.c to emit readily
identifiable symbol names for all the weak junk.
So in this patch:
1. Pass size info to scripts/kallsyms (see mksysmap());
2. Traverse sorted function symbols, if one function address plus its
size less than next function address, it means there's a hole, with
Masahiro's suggestion, then emit a symbol there of which type and
name are both empty to represent the hole.
Suggested-by: Peter Zijlstra
Suggested-by: Masahiro Yamada
Signed-off-by: Zheng Yejian
---
scripts/kallsyms.c | 94 +++--
scripts/link-vmlinux.sh | 4 +-
scripts/mksysmap| 2 +-
3 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 47978efe4797..cf64c20a8292 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -34,6 +34,7 @@
struct sym_entry {
unsigned long long addr;
+ unsigned long long size;
unsigned int len;
unsigned int seq;
unsigned int start_pos;
@@ -72,7 +73,6 @@ static int token_profit[0x1];
static unsigned char best_table[256][2];
static unsigned char best_table_len[256];
-
static void usage(void)
{
fprintf(stderr, "Usage: kallsyms [--all-symbols] [--absolute-percpu] "
@@ -128,8 +128,16 @@ static struct sym_entry *read_symbol(FILE *in, char **buf,
size_t *buf_len)
size_t len;
ssize_t readlen;
struct sym_entry *sym;
+ unsigned long long size = 0;
errno = 0;
+ /*
+* Example of expected symbol format:
+* 1. symbol with size info:
+*8170 01d7 T __startup_64
+* 2. symbol without size info:
+*02a0 A text_size
+*/
readlen = getline(buf, buf_len, in);
if (readlen < 0) {
if (errno) {
@@ -143,9 +151,24 @@ static struct sym_entry *read_symbol(FILE *in, char **buf,
size_t *buf_len)
(*buf)[readlen - 1] = 0;
addr = strtoull(*buf, &p, 16);
+ if (*buf == p || *p++ != ' ') {
+ fprintf(stderr, "line format error: unable to parse address\n");
+ exit(EXIT_FAILURE);
+ }
+
+ if (*p == '0') {
+ char *str = p;
+
+ size = strtoull(str, &p, 16);
+ if (str == p || *p++ != ' ') {
+ fprintf(stderr, "line format error: unable to parse
size\n");
+ exit(EXIT_FAILURE);
+ }
+ }
- if (*buf == p || *p++ != ' ' || !isascii((type = *p++)) || *p++ != ' ')
{
- fprintf(stderr, "line format error\n");
+ type = *p++;
+ if (!isascii(type) || *p++ != ' ') {
+ fprintf(stderr, "line format error: unable to parse type\n");
exit(EXIT_FAILURE);
}
@@ -180,6 +203,7 @@ static struct sym_entry *read_symbol(FILE *in, char **buf,
size_t *buf_len)
exit(EXIT_FAILURE);
}
sym->addr = addr;
+ sym->size = size;
sym->len = len;
sym->sym[0] = type;
strcpy(sym_name(sym), name);
@@ -788,6 +812,69 @@ static void sort_symbols(void)
qsort(table, table_cnt, sizeof(table[0]), compare_symbols);
}
+static bool has_hole(const struct sym_entry *se1, const struct sym_entry *se2)
+{
+ char type = se1->sym[0];
+
+ /* Only check text symbol or weak symbol */
+ if (type != 't' && type != 'T' &&
+ type != 'w' && type != 'W')
+ return 0;
+ /* Symbol without size has no hole */
+ if (!se1->size)
+ return 0;
+ return se1->addr + se1->size < se2->addr;
+}
+
+static struct sym_entry *gen_hole_symbol(const struct sym_entry *se)
+{
+ struct sym_entry *sym;
+
+ /* Use empty symbol type/name as a special case to represent the hole */
+ sym = malloc(sizeof(*sym) + 1);
+ if (!sym) {
+ fprintf(stderr, "unable to allocate memory for hole symbol\n");
+ exit(EXIT_FAILURE);
+ }
+ sym->addr = se->addr + se->size;
+ sym->size = 0;
+ sym->len = 1;
+ sym->sym[0] = '\0';
+ sym->percpu_absolute = 0;
+ return sym;
+}
+
+s
