Re: [PATCH 4/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7325 thermals
On 13.10.2023 10:09, Luca Weiss wrote:
> Configure the thermals for the QUIET_THERM, CAM_FLASH_THERM, MSM_THERM
> and RFC_CAM_THERM thermistors connected to PM7325.
>
> With this PMIC the software communication to the ADC is going through
> PMK7325 (= PMK8350).
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 117
> +
> 1 file changed, 117 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 2c01f799a6b2..d0b1e4e507ff 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -9,6 +9,7 @@
> #define PM7250B_SID 8
> #define PM7250B_SID1 9
>
> +#include
> #include
> #include
> #include
> @@ -137,6 +138,20 @@ afvdd_2p8: regulator-afvdd-2p8 {
> };
>
> thermal-zones {
> + camera-thermal {
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + thermal-sensors = <_adc_tm 2>;
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
are
> + rear-cam-thermal {
> + temperature = <125000>;
you
> + sdm-skin-thermal {
> + temperature = <125000>;
sure
about these temps?
Konrad
Re: [PATCH 2/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7250B thermals
On 13.10.2023 10:09, Luca Weiss wrote:
> Configure the thermals for the CHARGER_SKIN_THERM and USB_CONN_THERM
> thermistors connected to PM7250B.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 66
> ++
> 1 file changed, 66 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 2de0b8c26c35..7fe19b556e6a 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -134,6 +134,36 @@ afvdd_2p8: regulator-afvdd-2p8 {
> enable-active-high;
> vin-supply = <_bob>;
> };
> +
> + thermal-zones {
> + chg-skin-thermal {
skin
> + polling-delay-passive = <0>;
> + polling-delay = <0>;
> + thermal-sensors = <_adc_tm 0>;
> +
> + trips {
> + active-config0 {
> + temperature = <125000>;
125
hmm..
Konrad
Re: [PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails
On 13.10.2023 15:56, Luca Weiss wrote: > It can be useful to know with which return value the retimer_set call > failed, so include this info in the dev_err print. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH v2] ACPI: NFIT: Fix local use of devm_*()
Wilczynski, Michal wrote: > > > On 10/13/2023 7:05 PM, Dan Williams wrote: > > Wilczynski, Michal wrote: > >> On 10/13/2023 6:38 PM, Dan Williams wrote: > >>> Michal Wilczynski wrote: > devm_*() family of functions purpose is managing memory attached to a > device. So in general it should only be used for allocations that should > last for the whole lifecycle of the device. > >>> No, this assertion is not accurate, if it were strictly true then > >>> devm_kfree() should be deleted. This patch is only a cleanup to switch > >>> the automatic cleanup pattern from devm to the new cleanup.h helpers. > >> The memory in question is only used locally in a function, so there is no > >> reason > >> to use devm_*() family of functions. I think devm_kfree() is more for > >> special > >> cases where the memory is meant to be used for the whole lifecycle of > >> device, > >> but some special case occurs and it's not and it needs to be freed. > >> > >> This is an incorrect API usage. Would you propose to change all memory > >> allocations currently being done to devm_*() family simply because > >> devm_kfree() > >> exists ? > > Michal, please work with someone else to get these cleanups upstream, I > > am done with this thread. > > I'm really sorry if I offended you, I didn't mean to. Hey, it happens. I am not offended, just frustrated. Going forward, my advice for anyone doing advocacy for a patch set is to be clear about "what happens if upstream does not take this patch?". When you view it from that angle the patch changelog that would have received an immediate Reviewed-by with no additional comment from me is something along the lines of: "The new cleanup.h facilities that arrived in v6.5-rc1 can replace the the usage of devm semantics in acpi_nfit_init_interleave_set(). That routine appears to only be using devm to avoid goto statements. The new __free() annotation at variable declaration time can achieve the same effect more efficiently. There is no end user visible side effects of this patch, I was motivated to send this cleanup to practice using the new helpers." As Linus mentions, subtlety is difficult to convey in mailing list interactions, and you may not have picked up on it, but the frustration for me began with the claim of a memory leak that turned out to be false. That was the prompt to consider "what other claims should I be careful about now that the fundamental justification for touching this old code has gone away." So if you want to try again with the justification of the patch limited to a cleanup, we can move forward.
Re: [PATCH] dt-bindings: Drop kernel copy of common reserved-memory bindings
On Fri, 13 Oct 2023 at 13:45, Rob Herring wrote: > > The common reserved-memory bindings have recently been copied from the > kernel tree into dtschema. The preference is to host common, stable > bindings in dtschema. As reserved-memory is documented in the DT Spec, > it meets the criteria. > > The v2023.09 version of dtschema is what contains the reserved-memory > schemas we depend on, so bump the minimum version to that. Otherwise, > references to these schemas will generate errors. > > Signed-off-by: Rob Herring > --- > Documentation/devicetree/bindings/Makefile| 2 +- > .../remoteproc/renesas,rcar-rproc.yaml| 2 +- > .../bindings/reserved-memory/framebuffer.yaml | 52 - > .../reserved-memory/memory-region.yaml| 40 > .../reserved-memory/reserved-memory.txt | 2 +- > .../reserved-memory/reserved-memory.yaml | 181 -- > .../reserved-memory/shared-dma-pool.yaml | 97 -- > .../bindings/sound/mediatek,mt8188-afe.yaml | 2 +- > 8 files changed, 4 insertions(+), 374 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/memory-region.yaml > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml > delete mode 100644 > Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml > Reviewed-by: Simon Glass
[PATCH 2/2] arm64: dts: qcom: msm8939-longcheer-l9100: Enable RGB LED
l9100 uses KTD2026 LED driver. Add it to the device tree.
Signed-off-by: André Apitzsch
---
.../boot/dts/qcom/msm8939-longcheer-l9100.dts | 51 ++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
index 6802714fda3f..4eb33e36a8eb 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-longcheer-l9100.dts
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -120,6 +121,46 @@ usb_id: usb-id {
};
+_i2c2 {
+ status = "okay";
+
+ led-controller@30 {
+ compatible = "kinetic,ktd2026";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin-supply = <_l17>;
+ vio-supply = <_l6>;
+
+ pinctrl-0 = <_led_default>;
+ pinctrl-names = "default";
+
+ multi-led {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = ;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = ;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = ;
+ };
+ };
+ };
+};
+
_i2c3 {
status = "okay";
@@ -184,6 +225,16 @@ _uart2 {
status = "okay";
};
+_gpios {
+ status_led_default: status-led-default-state {
+ pins = "gpio3";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ power-source = ;
+ bias-disable;
+ output-high;
+ };
+};
+
_mpps {
pwm_out: mpp4-state {
pins = "mpp4";
--
2.42.0
[PATCH 0/2] arm64: dts: qcom: longcheer l8910 and l9100: Enable RGB LED
With the driver for ktd2026 recently applied to linux-leds[1], the LED can be enabled on longcheer l8910 and l9100. [1] https://lore.kernel.org/all/20231002-ktd202x-v6-0-26be8eefe...@apitzsch.eu/ Signed-off-by: André Apitzsch --- André Apitzsch (2): arm64: dts: qcom: msm8916-longcheer-l8910: Enable RGB LED arm64: dts: qcom: msm8939-longcheer-l9100: Enable RGB LED .../boot/dts/qcom/msm8916-longcheer-l8910.dts | 51 ++ .../boot/dts/qcom/msm8939-longcheer-l9100.dts | 51 ++ 2 files changed, 102 insertions(+) --- base-commit: beb63bee4857fd3661305eecd025a7c26c56 change-id: 20231013-bq_leds-0d8a9b15ec6a Best regards, -- André Apitzsch
[PATCH 1/2] arm64: dts: qcom: msm8916-longcheer-l8910: Enable RGB LED
l8910 uses KTD2026 LED driver. Add it to the device tree.
Tested-by: Stephan Gerhold
Signed-off-by: André Apitzsch
---
.../boot/dts/qcom/msm8916-longcheer-l8910.dts | 51 ++
1 file changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
index 41cadb906b98..68258cf4205f 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
/ {
model = "BQ Aquaris X5 (Longcheer L8910)";
@@ -74,6 +75,46 @@ usb_id: usb-id {
};
};
+_i2c2 {
+ status = "okay";
+
+ led-controller@30 {
+ compatible = "kinetic,ktd2026";
+ reg = <0x30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vin-supply = <_l17>;
+ vio-supply = <_l6>;
+
+ pinctrl-0 = <_led_default>;
+ pinctrl-names = "default";
+
+ multi-led {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = ;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = ;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = ;
+ };
+ };
+ };
+};
+
_i2c3 {
status = "okay";
@@ -107,6 +148,16 @@ _uart2 {
status = "okay";
};
+_gpios {
+ status_led_default: status-led-default-state {
+ pins = "gpio3";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ power-source = ;
+ bias-disable;
+ output-high;
+ };
+};
+
_resin {
status = "okay";
linux,code = ;
--
2.42.0
[PATCH] dt-bindings: Drop kernel copy of common reserved-memory bindings
The common reserved-memory bindings have recently been copied from the
kernel tree into dtschema. The preference is to host common, stable
bindings in dtschema. As reserved-memory is documented in the DT Spec,
it meets the criteria.
The v2023.09 version of dtschema is what contains the reserved-memory
schemas we depend on, so bump the minimum version to that. Otherwise,
references to these schemas will generate errors.
Signed-off-by: Rob Herring
---
Documentation/devicetree/bindings/Makefile| 2 +-
.../remoteproc/renesas,rcar-rproc.yaml| 2 +-
.../bindings/reserved-memory/framebuffer.yaml | 52 -
.../reserved-memory/memory-region.yaml| 40
.../reserved-memory/reserved-memory.txt | 2 +-
.../reserved-memory/reserved-memory.yaml | 181 --
.../reserved-memory/shared-dma-pool.yaml | 97 --
.../bindings/sound/mediatek,mt8188-afe.yaml | 2 +-
8 files changed, 4 insertions(+), 374 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
delete mode 100644
Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
diff --git a/Documentation/devicetree/bindings/Makefile
b/Documentation/devicetree/bindings/Makefile
index 8b395893bd85..3e886194b043 100644
--- a/Documentation/devicetree/bindings/Makefile
+++ b/Documentation/devicetree/bindings/Makefile
@@ -6,7 +6,7 @@ DT_MK_SCHEMA ?= dt-mk-schema
DT_SCHEMA_LINT = $(shell which yamllint || \
echo "warning: python package 'yamllint' not installed, skipping" >&2)
-DT_SCHEMA_MIN_VERSION = 2022.3
+DT_SCHEMA_MIN_VERSION = 2023.9
PHONY += check_dtschema_version
check_dtschema_version:
diff --git
a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
index 4bea679a0f61..5c280117dc93 100644
--- a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml
@@ -31,7 +31,7 @@ properties:
remoteproc device. This is variable and describes the memories shared
with
the remote processor (e.g. remoteproc firmware and carveouts, rpmsg
vrings, ...).
- (see ../reserved-memory/reserved-memory.yaml)
+ (see reserved-memory/reserved-memory.yaml in dtschema project)
required:
- compatible
diff --git a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
b/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
deleted file mode 100644
index 851ec24d6142..
--- a/Documentation/devicetree/bindings/reserved-memory/framebuffer.yaml
+++ /dev/null
@@ -1,52 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/reserved-memory/framebuffer.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: /reserved-memory framebuffer node
-
-maintainers:
- - devicetree-s...@vger.kernel.org
-
-allOf:
- - $ref: reserved-memory.yaml
-
-properties:
- compatible:
-const: framebuffer
-description: >
- This indicates a region of memory meant to be used as a framebuffer for
- a set of display devices. It can be used by an operating system to keep
- the framebuffer from being overwritten and use it as the backing memory
- for a display device (such as simple-framebuffer).
-
-unevaluatedProperties: false
-
-examples:
- - |
-/ {
-compatible = "foo";
-model = "foo";
-#address-cells = <1>;
-#size-cells = <1>;
-
-chosen {
-framebuffer {
-compatible = "simple-framebuffer";
-memory-region = <>;
-};
-};
-
-reserved-memory {
-#address-cells = <1>;
-#size-cells = <1>;
-ranges;
-
-fb: framebuffer@8000 {
-compatible = "framebuffer";
-reg = <0x8000 0x007e9000>;
-};
-};
-};
-...
diff --git
a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
b/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
deleted file mode 100644
index 592f180e6b0d..
--- a/Documentation/devicetree/bindings/reserved-memory/memory-region.yaml
+++ /dev/null
@@ -1,40 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Reserved Memory Region
-
-maintainers:
- - devicetree-s...@vger.kernel.org
-
-description: |
- Regions in the /reserved-memory node may be referenced by other device
- nodes by adding a memory-region property to the device node.
-
Re: [PATCH bpf-next] bpf: change syscall_nr type to int in struct syscall_tp_t
Hello:
This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko :
On Fri, 13 Oct 2023 07:42:19 +0200 you wrote:
> linux-rt-devel tree contains a patch (b1773eac3f29c ("sched: Add support
> for lazy preemption")) that adds an extra member to struct trace_entry.
> This causes the offset of args field in struct trace_event_raw_sys_enter
> be different from the one in struct syscall_trace_enter:
>
> struct trace_event_raw_sys_enter {
> struct trace_entry ent; /* 012 */
>
> [...]
Here is the summary with links:
- [bpf-next] bpf: change syscall_nr type to int in struct syscall_tp_t
https://git.kernel.org/bpf/bpf-next/c/ba8ea72388a1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [RFC PATCH bpf-next] bpf: change syscall_nr type to int in struct syscall_tp_t
On Fri, Oct 13, 2023 at 7:00 AM Steven Rostedt wrote: > > On Fri, 13 Oct 2023 08:01:34 +0200 > Artem Savkov wrote: > > > > But looking at [0] and briefly reading some of the discussions you, > > > Steven, had. I'm just wondering if it would be best to avoid > > > increasing struct trace_entry altogether? It seems like preempt_count > > > is actually a 4-bit field in trace context, so it doesn't seem like we > > > really need to allocate an entire byte for both preempt_count and > > > preempt_lazy_count. Why can't we just combine them and not waste 8 > > > extra bytes for each trace event in a ring buffer? > > > > > > [0] > > > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?id=b1773eac3f29cbdcdfd16e0339f1a164066e9f71 > > > > I agree that avoiding increase in struct trace_entry size would be very > > desirable, but I have no knowledge whether rt developers had reasons to > > do it like this. > > > > Nevertheless I think the issue with verifier running against a wrong > > struct still needs to be addressed. > > Correct. My Ack is based on the current way things are done upstream. > It was just that linux-rt showed the issue, where the code was not as > robust as it should have been. To me this was a correctness issue, not > an issue that had to do with how things are done in linux-rt. I think we should at least add some BUILD_BUG_ON() that validates offsets in syscall_tp_t matches the ones in syscall_trace_enter and syscall_trace_exit, to fail more loudly if there is any mismatch in the future. WDYT? > > As for the changes in linux-rt, they are not upstream yet. I'll have my > comments on that code when that happens. Ah, ok, cool. I'd appreciate you cc'ing b...@vger.kernel.org in that discussion, thank you! > > -- Steve
Re: [PATCH v3 2/6] ACPI: AC: Use string_choices API instead of ternary operator
On Wed, Oct 11, 2023 at 10:34 AM Michal Wilczynski
wrote:
>
> Use modern string_choices API instead of manually determining the
> output using ternary operator.
>
> Suggested-by: Andy Shevchenko
> Reviewed-by: Andy Shevchenko
> Signed-off-by: Michal Wilczynski
> ---
> drivers/acpi/ac.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
> index 83d45c681121..f809f6889b4a 100644
> --- a/drivers/acpi/ac.c
> +++ b/drivers/acpi/ac.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -243,8 +244,8 @@ static int acpi_ac_add(struct acpi_device *device)
> goto err_release_ac;
> }
>
> - pr_info("%s [%s] (%s)\n", acpi_device_name(device),
> - acpi_device_bid(device), ac->state ? "on-line" : "off-line");
> + pr_info("%s [%s] (%s-line)\n", acpi_device_name(device),
> + acpi_device_bid(device), str_on_off(ac->state));
>
> ac->battery_nb.notifier_call = acpi_ac_battery_notify;
> register_acpi_notifier(>battery_nb);
> --
Applied as 6.7 material, thanks!
Re: [PATCH v3 1/6] ACPI: AC: Remove unnecessary checks
On Wed, Oct 11, 2023 at 10:34 AM Michal Wilczynski
wrote:
>
> Remove unnecessary checks for NULL for variables that can't be NULL at
> the point they're checked for it. Defensive programming is discouraged
> in the kernel.
>
> Signed-off-by: Michal Wilczynski
> ---
> drivers/acpi/ac.c | 27 ---
> 1 file changed, 4 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
> index aac3e561790c..83d45c681121 100644
> --- a/drivers/acpi/ac.c
> +++ b/drivers/acpi/ac.c
> @@ -131,9 +131,6 @@ static void acpi_ac_notify(acpi_handle handle, u32 event,
> void *data)
> struct acpi_device *device = data;
> struct acpi_ac *ac = acpi_driver_data(device);
>
> - if (!ac)
> - return;
> -
> switch (event) {
> default:
> acpi_handle_debug(device->handle, "Unsupported event
> [0x%x]\n",
> @@ -216,12 +213,8 @@ static const struct dmi_system_id ac_dmi_table[]
> __initconst = {
> static int acpi_ac_add(struct acpi_device *device)
> {
> struct power_supply_config psy_cfg = {};
> - int result = 0;
> - struct acpi_ac *ac = NULL;
> -
> -
> - if (!device)
> - return -EINVAL;
> + struct acpi_ac *ac;
> + int result;
>
> ac = kzalloc(sizeof(struct acpi_ac), GFP_KERNEL);
> if (!ac)
> @@ -275,16 +268,9 @@ static int acpi_ac_add(struct acpi_device *device)
> #ifdef CONFIG_PM_SLEEP
> static int acpi_ac_resume(struct device *dev)
> {
> - struct acpi_ac *ac;
> + struct acpi_ac *ac = acpi_driver_data(to_acpi_device(dev));
> unsigned int old_state;
>
> - if (!dev)
> - return -EINVAL;
> -
> - ac = acpi_driver_data(to_acpi_device(dev));
> - if (!ac)
> - return -EINVAL;
> -
> old_state = ac->state;
> if (acpi_ac_get_state(ac))
> return 0;
> @@ -299,12 +285,7 @@ static int acpi_ac_resume(struct device *dev)
>
> static void acpi_ac_remove(struct acpi_device *device)
> {
> - struct acpi_ac *ac = NULL;
> -
> - if (!device || !acpi_driver_data(device))
> - return;
> -
> - ac = acpi_driver_data(device);
> + struct acpi_ac *ac = acpi_driver_data(device);
>
> acpi_dev_remove_notify_handler(device, ACPI_ALL_NOTIFY,
>acpi_ac_notify);
> --
Applied as 6.7 material with edits in the subject and changelog, thanks!
Re: [PATCH v2] ACPI: NFIT: Fix local use of devm_*()
On 10/13/2023 7:05 PM, Dan Williams wrote: > Wilczynski, Michal wrote: >> On 10/13/2023 6:38 PM, Dan Williams wrote: >>> Michal Wilczynski wrote: devm_*() family of functions purpose is managing memory attached to a device. So in general it should only be used for allocations that should last for the whole lifecycle of the device. >>> No, this assertion is not accurate, if it were strictly true then >>> devm_kfree() should be deleted. This patch is only a cleanup to switch >>> the automatic cleanup pattern from devm to the new cleanup.h helpers. >> The memory in question is only used locally in a function, so there is no >> reason >> to use devm_*() family of functions. I think devm_kfree() is more for special >> cases where the memory is meant to be used for the whole lifecycle of device, >> but some special case occurs and it's not and it needs to be freed. >> >> This is an incorrect API usage. Would you propose to change all memory >> allocations currently being done to devm_*() family simply because >> devm_kfree() >> exists ? > Michal, please work with someone else to get these cleanups upstream, I > am done with this thread. I'm really sorry if I offended you, I didn't mean to. Michał
Re: [PATCH v2] ACPI: NFIT: Fix local use of devm_*()
Wilczynski, Michal wrote: > On 10/13/2023 6:38 PM, Dan Williams wrote: > > Michal Wilczynski wrote: > >> devm_*() family of functions purpose is managing memory attached to a > >> device. So in general it should only be used for allocations that should > >> last for the whole lifecycle of the device. > > No, this assertion is not accurate, if it were strictly true then > > devm_kfree() should be deleted. This patch is only a cleanup to switch > > the automatic cleanup pattern from devm to the new cleanup.h helpers. > > The memory in question is only used locally in a function, so there is no > reason > to use devm_*() family of functions. I think devm_kfree() is more for special > cases where the memory is meant to be used for the whole lifecycle of device, > but some special case occurs and it's not and it needs to be freed. > > This is an incorrect API usage. Would you propose to change all memory > allocations currently being done to devm_*() family simply because > devm_kfree() > exists ? Michal, please work with someone else to get these cleanups upstream, I am done with this thread.
Re: [PATCH v2] ACPI: NFIT: Fix local use of devm_*()
On 10/13/2023 6:38 PM, Dan Williams wrote: > Michal Wilczynski wrote: >> devm_*() family of functions purpose is managing memory attached to a >> device. So in general it should only be used for allocations that should >> last for the whole lifecycle of the device. > No, this assertion is not accurate, if it were strictly true then > devm_kfree() should be deleted. This patch is only a cleanup to switch > the automatic cleanup pattern from devm to the new cleanup.h helpers. The memory in question is only used locally in a function, so there is no reason to use devm_*() family of functions. I think devm_kfree() is more for special cases where the memory is meant to be used for the whole lifecycle of device, but some special case occurs and it's not and it needs to be freed. This is an incorrect API usage. Would you propose to change all memory allocations currently being done to devm_*() family simply because devm_kfree() exists ? Why introduce extra overhead if you don't have to ? > > I am all for modernizing code over time, but patches that make > assertions of "memory leaks" and "incorrect API usage" in code that has > been untouched for almost a decade demand more scrutiny than what > transpired here. I understand that it's not necessarily a big problem, and the code works perfectly, I can change the phrasing if you don't like it, but still the cleanup.h helpers don't really care that much what functions they call to allocate/free. They are meant to care about the scope - like constructor destructor in C++ - you can call anything there. So this commit changes 2 things: - change family of function to allocate from devm_kcalloc() to kcalloc() - use scope based mechanism to call those functions Thanks a lot for your review ! Michał
Re: [PATCH v2] ACPI: NFIT: Fix local use of devm_*()
Michal Wilczynski wrote: > devm_*() family of functions purpose is managing memory attached to a > device. So in general it should only be used for allocations that should > last for the whole lifecycle of the device. No, this assertion is not accurate, if it were strictly true then devm_kfree() should be deleted. This patch is only a cleanup to switch the automatic cleanup pattern from devm to the new cleanup.h helpers. I am all for modernizing code over time, but patches that make assertions of "memory leaks" and "incorrect API usage" in code that has been untouched for almost a decade demand more scrutiny than what transpired here.
[PATCH v4 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP
From: Iuliana Prodan
Add the reserve-memory nodes used by DSP when the rpmsg
feature is enabled.
Signed-off-by: Iuliana Prodan
---
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 22
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index fa37ce89f8d3..b677ad8ef042 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -125,6 +125,28 @@
};
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ dsp_vdev0vring0: vdev0vring0@942f {
+ reg = <0 0x942f 0 0x8000>;
+ no-map;
+ };
+
+ dsp_vdev0vring1: vdev0vring1@942f8000 {
+ reg = <0 0x942f8000 0 0x8000>;
+ no-map;
+ };
+
+ dsp_vdev0buffer: vdev0buffer@9430 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x9430 0 0x10>;
+ no-map;
+ };
+ };
};
{
--
2.17.1
[PATCH v4 1/2] remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op
From: Iuliana Prodan
Add the .find_loaded_rsc_table operation for i.MX DSP.
We need it for inter-process communication between DSP
and main core.
This callback is used to find the resource table (defined
in remote processor linker script) where the address of the
vrings along with the other allocated resources (carveouts etc)
are stored.
If this is not found, the vrings are not allocated and
the IPC between cores will not work.
Signed-off-by: Iuliana Prodan
Reviewed-by: Daniel Baluta
---
drivers/remoteproc/imx_dsp_rproc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/imx_dsp_rproc.c
b/drivers/remoteproc/imx_dsp_rproc.c
index 8fcda9b74545..a1c62d15f16c 100644
--- a/drivers/remoteproc/imx_dsp_rproc.c
+++ b/drivers/remoteproc/imx_dsp_rproc.c
@@ -940,6 +940,7 @@ static const struct rproc_ops imx_dsp_rproc_ops = {
.kick = imx_dsp_rproc_kick,
.load = imx_dsp_rproc_elf_load_segments,
.parse_fw = imx_dsp_rproc_parse_fw,
+ .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
.sanity_check = rproc_elf_sanity_check,
.get_boot_addr = rproc_elf_get_boot_addr,
};
--
2.17.1
[PATCH v4 0/2] Rpmsg support for i.MX DSP with resource table
From: Iuliana Prodan These patches are needed in order to support rpmsg on DSP when a resource table is available. Changes since v3: - add reserve-memory nodes in imx8mp-evk.dts rather than .dtsi (patch 2/2) Changes since v2: - add newline between nodes in dtsi (patch 2/2) Changes since v1: - add missing bracket in dtsi (patch 2/2) Iuliana Prodan (2): remoteproc: imx_dsp_rproc: add mandatory find_loaded_rsc_table op arm64: dts: imx8mp: add reserve-memory nodes for DSP arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 22 drivers/remoteproc/imx_dsp_rproc.c | 1 + 2 files changed, 23 insertions(+) -- 2.17.1
[PATCH 2/2] usb: typec: add support for PTN36502 redriver
Add a driver for the NXP PTN36502 Type-C USB 3.1 Gen 1 and DisplayPort
v1.2 combo redriver.
Signed-off-by: Luca Weiss
---
drivers/usb/typec/mux/Kconfig| 10 +
drivers/usb/typec/mux/Makefile | 1 +
drivers/usb/typec/mux/ptn36502.c | 421 +++
3 files changed, 432 insertions(+)
diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig
index 65da61150ba7..816b9bd08355 100644
--- a/drivers/usb/typec/mux/Kconfig
+++ b/drivers/usb/typec/mux/Kconfig
@@ -46,4 +46,14 @@ config TYPEC_MUX_NB7VPQ904M
Say Y or M if your system has a On Semiconductor NB7VPQ904M Type-C
redriver chip found on some devices with a Type-C port.
+config TYPEC_MUX_PTN36502
+ tristate "NXP PTN36502 Type-C redriver driver"
+ depends on I2C
+ depends on DRM || DRM=n
+ select DRM_PANEL_BRIDGE if DRM
+ select REGMAP_I2C
+ help
+ Say Y or M if your system has a NXP PTN36502 Type-C redriver chip
+ found on some devices with a Type-C port.
+
endmenu
diff --git a/drivers/usb/typec/mux/Makefile b/drivers/usb/typec/mux/Makefile
index 76196096ef41..9d6a5557b0bd 100644
--- a/drivers/usb/typec/mux/Makefile
+++ b/drivers/usb/typec/mux/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_TYPEC_MUX_GPIO_SBU)+= gpio-sbu-mux.o
obj-$(CONFIG_TYPEC_MUX_PI3USB30532)+= pi3usb30532.o
obj-$(CONFIG_TYPEC_MUX_INTEL_PMC) += intel_pmc_mux.o
obj-$(CONFIG_TYPEC_MUX_NB7VPQ904M) += nb7vpq904m.o
+obj-$(CONFIG_TYPEC_MUX_PTN36502) += ptn36502.o
diff --git a/drivers/usb/typec/mux/ptn36502.c b/drivers/usb/typec/mux/ptn36502.c
new file mode 100644
index ..91684a856f3a
--- /dev/null
+++ b/drivers/usb/typec/mux/ptn36502.c
@@ -0,0 +1,421 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * NXP PTN36502 Type-C driver
+ *
+ * Copyright (C) 2023 Luca Weiss
+ *
+ * Based on NB7VPQ904M driver:
+ * Copyright (C) 2023 Dmitry Baryshkov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PTN36502_CHIP_ID_REG 0x00
+#define PTN36502_CHIP_ID 0x02
+
+#define PTN36502_CHIP_REVISION_REG 0x01
+#define PTN36502_CHIP_REVISION_BASE(val) FIELD_GET(GENMASK(7,
4), (val))
+#define PTN36502_CHIP_REVISION_METAL(val) FIELD_GET(GENMASK(3,
0), (val))
+
+#define PTN36502_DP_LINK_CTRL_REG 0x06
+#define PTN36502_DP_LINK_CTRL_LANES_2 (2 << 2)
+#define PTN36502_DP_LINK_CTRL_LANES_4 (3 << 2)
+#define PTN36502_DP_LINK_CTRL_LINK_RATE_5_4GBPS(2 << 0)
+
+/* Registers for lane 0 (0x07) to lane 3 (0x0a) have the same layout */
+#define PTN36502_DP_LANE_CTRL_REG(n) (0x07 + (n))
+#define PTN36502_DP_LANE_CTRL_RX_GAIN_3DB (2<<4)
+#define PTN36502_DP_LANE_CTRL_TX_SWING_800MVPPD(2<<2)
+#define PTN36502_DP_LANE_CTRL_PRE_EMPHASIS_3_5DB (1<<0)
+
+#define PTN36502_MODE_CTRL1_REG0x0b
+#define PTN36502_MODE_CTRL1_PLUG_ORIENT_REVERSE(1<<5)
+#define PTN36502_MODE_CTRL1_AUX_CROSSBAR_SW_ON (1<<3)
+#define PTN36502_MODE_CTRL1_MODE_OFF (0<<0)
+#define PTN36502_MODE_CTRL1_MODE_USB_ONLY (1<<0)
+#define PTN36502_MODE_CTRL1_MODE_USB_DP(2<<0)
+#define PTN36502_MODE_CTRL1_MODE_DP(3<<0)
+
+#define PTN36502_DEVICE_CTRL_REG 0x0d
+#define PTN36502_DEVICE_CTRL_AUX_MONITORING_EN (1<<7)
+
+struct ptn36502 {
+ struct i2c_client *client;
+ struct regulator *vdd18_supply;
+ struct regmap *regmap;
+ struct typec_switch_dev *sw;
+ struct typec_retimer *retimer;
+
+ struct typec_switch *typec_switch;
+
+ struct drm_bridge bridge;
+
+ struct mutex lock; /* protect non-concurrent retimer & switch */
+
+ enum typec_orientation orientation;
+ unsigned long mode;
+ unsigned int svid;
+};
+
+static int ptn36502_set(struct ptn36502 *ptn)
+{
+ bool reverse = (ptn->orientation == TYPEC_ORIENTATION_REVERSE);
+ unsigned int ctrl1_val = 0;
+ unsigned int lane_ctrl_val = 0;
+ unsigned int link_ctrl_val = 0;
+
+ switch (ptn->mode) {
+ case TYPEC_STATE_SAFE:
+ /* Deep power saving state */
+ regmap_write(ptn->regmap, PTN36502_MODE_CTRL1_REG,
+PTN36502_MODE_CTRL1_MODE_OFF);
+ return 0;
+
+ case TYPEC_STATE_USB:
+ /*
+* Normal Orientation (CC1)
+* A -> USB RX
+* B -> USB TX
+* C -> X
+* D -> X
+* Flipped Orientation (CC2)
+* A -> X
+* B -> X
+* C -> USB TX
+* D -> USB RX
+*/
[PATCH 1/2] dt-bindings: usb: add NXP PTN36502 Type-C redriver bindings
Document bindings for this Type-C USB 3.1 Gen 1 and DisplayPort v1.2
combo redriver.
The PTN36502 can also run in GPIO mode where it is configured
differently, without any I2C connection, but this is not supported yet.
Signed-off-by: Luca Weiss
---
.../devicetree/bindings/usb/nxp,ptn36502.yaml | 94 ++
1 file changed, 94 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
new file mode 100644
index ..eee548ac1abe
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nxp,ptn36502.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nxp,ptn36502.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PTN36502 Type-C USB 3.1 Gen 1 and DisplayPort v1.2 combo redriver
+
+maintainers:
+ - Luca Weiss
+
+properties:
+ compatible:
+enum:
+ - nxp,ptn36502
+
+ reg:
+maxItems: 1
+
+ vdd18-supply:
+description: Power supply for VDD18 pin
+
+ retimer-switch:
+description: Flag the port as possible handle of SuperSpeed signals
retiming
+type: boolean
+
+ orientation-switch:
+description: Flag the port as possible handler of orientation switching
+type: boolean
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Super Speed (SS) Output endpoint to the Type-C connector
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Super Speed (SS) Input endpoint from the Super-Speed PHY
+
+ port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Sideband Use (SBU) AUX lines endpoint to the Type-C connector for
the purpose of
+ handling altmode muxing and orientation switching.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+typec-mux@1a {
+compatible = "nxp,ptn36502";
+reg = <0x1a>;
+
+vdd18-supply = <_redrive_1v8>;
+
+retimer-switch;
+orientation-switch;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+usb_con_ss: endpoint {
+remote-endpoint = <_con_ss>;
+};
+};
+port@1 {
+reg = <1>;
+phy_con_ss: endpoint {
+remote-endpoint = <_phy_ss>;
+};
+};
+port@2 {
+reg = <2>;
+usb_con_sbu: endpoint {
+remote-endpoint = <_dp_aux>;
+};
+};
+};
+};
+};
+...
--
2.42.0
[PATCH 0/2] Add driver for NXP PTN36502 Type-C redriver
The NXP PTN36502 is used in the Fairphone 5 smartphone, add a driver for it so we can soon enable DisplayPort over USB-C on this phone. Signed-off-by: Luca Weiss --- Luca Weiss (2): dt-bindings: usb: add NXP PTN36502 Type-C redriver bindings usb: typec: add support for PTN36502 redriver .../devicetree/bindings/usb/nxp,ptn36502.yaml | 94 + drivers/usb/typec/mux/Kconfig | 10 + drivers/usb/typec/mux/Makefile | 1 + drivers/usb/typec/mux/ptn36502.c | 421 + 4 files changed, 526 insertions(+) --- base-commit: e3b18f7200f45d66f7141136c25554ac1e82009b change-id: 20231013-ptn36502-5a87e507d36c Best regards, -- Luca Weiss
Re: [RFC PATCH bpf-next] bpf: change syscall_nr type to int in struct syscall_tp_t
On Fri, 13 Oct 2023 08:01:34 +0200 Artem Savkov wrote: > > But looking at [0] and briefly reading some of the discussions you, > > Steven, had. I'm just wondering if it would be best to avoid > > increasing struct trace_entry altogether? It seems like preempt_count > > is actually a 4-bit field in trace context, so it doesn't seem like we > > really need to allocate an entire byte for both preempt_count and > > preempt_lazy_count. Why can't we just combine them and not waste 8 > > extra bytes for each trace event in a ring buffer? > > > > [0] > > https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?id=b1773eac3f29cbdcdfd16e0339f1a164066e9f71 > > > > I agree that avoiding increase in struct trace_entry size would be very > desirable, but I have no knowledge whether rt developers had reasons to > do it like this. > > Nevertheless I think the issue with verifier running against a wrong > struct still needs to be addressed. Correct. My Ack is based on the current way things are done upstream. It was just that linux-rt showed the issue, where the code was not as robust as it should have been. To me this was a correctness issue, not an issue that had to do with how things are done in linux-rt. As for the changes in linux-rt, they are not upstream yet. I'll have my comments on that code when that happens. -- Steve
[PATCH] soc: qcom: pmic_glink_altmode: Print error when retimer setup fails
It can be useful to know with which return value the retimer_set call failed, so include this info in the dev_err print. Signed-off-by: Luca Weiss --- drivers/soc/qcom/pmic_glink_altmode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c index 9569d999391d..136713e1155e 100644 --- a/drivers/soc/qcom/pmic_glink_altmode.c +++ b/drivers/soc/qcom/pmic_glink_altmode.c @@ -168,7 +168,7 @@ static void pmic_glink_altmode_enable_dp(struct pmic_glink_altmode *altmode, ret = typec_retimer_set(port->typec_retimer, >retimer_state); if (ret) - dev_err(altmode->dev, "failed to setup retimer to DP\n"); + dev_err(altmode->dev, "failed to setup retimer to DP: %d\n", ret); } static void pmic_glink_altmode_enable_usb(struct pmic_glink_altmode *altmode, --- base-commit: e3b18f7200f45d66f7141136c25554ac1e82009b change-id: 20231013-glink-altmode-ret-3911e6c1eab5 Best regards, -- Luca Weiss
Re: [PATCH 2/3] usb: typec: fsa4480: Add support to swap SBU orientation
On 13/10/2023 13:38, Luca Weiss wrote:
On some hardware designs the AUX+/- lanes are connected reversed to
SBU1/2 compared to the expected design by FSA4480.
Made more complicated, the otherwise compatible Orient-Chip OCP96011
expects the lanes to be connected reversed compared to FSA4480.
* FSA4480 block diagram shows AUX+ connected to SBU2 and AUX- to SBU1.
* OCP96011 block diagram shows AUX+ connected to SBU1 and AUX- to SBU2.
So if OCP96011 is used as drop-in for FSA4480 then the orientation
handling in the driver needs to be reversed to match the expectation of
the OCP96011 hardware.
Support parsing the data-lanes parameter in the endpoint node to swap
this in the driver.
The parse_data_lanes_mapping function is mostly taken from nb7vpq904m.c.
I see the inspiration :-)
Signed-off-by: Luca Weiss
---
drivers/usb/typec/mux/fsa4480.c | 81 +
1 file changed, 81 insertions(+)
diff --git a/drivers/usb/typec/mux/fsa4480.c b/drivers/usb/typec/mux/fsa4480.c
index e0ee1f621abb..6ee467c96fb6 100644
--- a/drivers/usb/typec/mux/fsa4480.c
+++ b/drivers/usb/typec/mux/fsa4480.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -60,6 +61,7 @@ struct fsa4480 {
unsigned int svid;
u8 cur_enable;
+ bool swap_sbu_lanes;
};
static const struct regmap_config fsa4480_regmap_config = {
@@ -76,6 +78,9 @@ static int fsa4480_set(struct fsa4480 *fsa)
u8 enable = FSA4480_ENABLE_DEVICE;
u8 sel = 0;
+ if (fsa->swap_sbu_lanes)
+ reverse = !reverse;
+
/* USB Mode */
if (fsa->mode < TYPEC_STATE_MODAL ||
(!fsa->svid && (fsa->mode == TYPEC_MODE_USB2 ||
@@ -179,12 +184,84 @@ static int fsa4480_mux_set(struct typec_mux_dev *mux,
struct typec_mux_state *st
return ret;
}
+enum {
+ NORMAL_LANE_MAPPING,
+ INVERT_LANE_MAPPING,
+};
+
+#define DATA_LANES_COUNT 2
+
+static const int supported_data_lane_mapping[][DATA_LANES_COUNT] = {
+ [NORMAL_LANE_MAPPING] = { 0, 1 },
+ [INVERT_LANE_MAPPING] = { 1, 0 },
+};
+
+static int fsa4480_parse_data_lanes_mapping(struct fsa4480 *fsa)
+{
+ struct device_node *ep;
+ u32 data_lanes[DATA_LANES_COUNT];
+ int ret, i, j;
+
+ ep = of_graph_get_next_endpoint(fsa->client->dev.of_node, NULL);
+ if (!ep)
+ return 0;
+
+ ret = of_property_count_u32_elems(ep, "data-lanes");
+ if (ret == -EINVAL)
+ /* Property isn't here, consider default mapping */
+ goto out_done;
+ if (ret < 0)
+ goto out_error;
+
+ if (ret != DATA_LANES_COUNT) {
+ dev_err(>client->dev, "expected 2 data lanes\n");
+ ret = -EINVAL;
+ goto out_error;
+ }
+
+ ret = of_property_read_u32_array(ep, "data-lanes", data_lanes,
DATA_LANES_COUNT);
+ if (ret)
+ goto out_error;
+
+ for (i = 0; i < ARRAY_SIZE(supported_data_lane_mapping); i++) {
+ for (j = 0; j < DATA_LANES_COUNT; j++) {
+ if (data_lanes[j] != supported_data_lane_mapping[i][j])
+ break;
+ }
+
+ if (j == DATA_LANES_COUNT)
+ break;
+ }
+
+ switch (i) {
+ case NORMAL_LANE_MAPPING:
+ break;
+ case INVERT_LANE_MAPPING:
+ fsa->swap_sbu_lanes = true;
+ dev_info(>client->dev, "using inverted data lanes
mapping\n");
+ break;
+ default:
+ dev_err(>client->dev, "invalid data lanes mapping\n");
+ ret = -EINVAL;
+ goto out_error;
+ }
+
+out_done:
+ ret = 0;
+
+out_error:
+ of_node_put(ep);
+
+ return ret;
+}
It's probbaly slighly over engineered for 2 lanes, and at some point
this could go into an helper somewhere because we will need it for all
SBU muxes and redrivers/retimers.
+
static int fsa4480_probe(struct i2c_client *client)
{
struct device *dev = >dev;
struct typec_switch_desc sw_desc = { };
struct typec_mux_desc mux_desc = { };
struct fsa4480 *fsa;
+ int ret;
fsa = devm_kzalloc(dev, sizeof(*fsa), GFP_KERNEL);
if (!fsa)
@@ -193,6 +270,10 @@ static int fsa4480_probe(struct i2c_client *client)
fsa->client = client;
mutex_init(>lock);
+ ret = fsa4480_parse_data_lanes_mapping(fsa);
+ if (ret)
+ return ret;
+
fsa->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(fsa->regmap))
return dev_err_probe(dev, PTR_ERR(fsa->regmap), "failed to
initialize regmap\n");
But since I did the same in nb7vpq904m, and the SBU can be inverted, LGTM
Reviewed-by: Neil Armstrong
Neil
[PATCH v2] ACPI: NFIT: Optimize nfit_mem_cmp() for efficiency
The original code used conditional branching in the nfit_mem_cmp function to compare two values and return -1, 1, or 0 based on the result. However, the list_sort comparison function only needs results <0, >0, or =0. This patch optimizes the code to make the comparison branchless, improving efficiency and reducing code size. This change reduces the number of comparison operations from 1-2 to a single subtraction operation, thereby saving the number of instructions. Signed-off-by: Kuan-Wei Chiu --- v1 -> v2: - Add explicit type cast in case the sizes of u32 and int differ. drivers/acpi/nfit/core.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c index f96bf32cd368..563a32eba888 100644 --- a/drivers/acpi/nfit/core.c +++ b/drivers/acpi/nfit/core.c @@ -1138,11 +1138,7 @@ static int nfit_mem_cmp(void *priv, const struct list_head *_a, handleA = __to_nfit_memdev(a)->device_handle; handleB = __to_nfit_memdev(b)->device_handle; - if (handleA < handleB) - return -1; - else if (handleA > handleB) - return 1; - return 0; + return (int)handleA - (int)handleB; } static int nfit_mem_init(struct acpi_nfit_desc *acpi_desc) -- 2.25.1
Re: [PATCH v7 00/13] selftests/sgx: Fix compilation errors
On 10.10.23 14:11, Jarkko Sakkinen wrote: Dave, since there was already sort of talk about detaching this code from kernel tree so that Jo could work on "pure C" runtime would it make sense to dual-license this first in the kernel tree? E.g. Jo could send a patch once this is merged with a new SPDX platter and we can then ack that? Just a proposal, with the emphasis on minimal amount of work required from each party. Also this would help with possible (and likely) bug fixes, i.e. minimal friction on fixing the same bug. Later on of course, we can consider adding "libsgx-dev" as depedency similarly as today there's a few dependencies like libelf-dev. I'm open for alternative proposals, just throwing something that came up mind. Pitching in here: from my side, I'd also be fine to develop this bare-sgx "pure C" runtime under GPLv2 as is. FWIW, I'd be mostly interested in and see most immediate use cases for such a runtime in research purposes (e.g., low-level benchmarking; rapid prototyping attacks/defenses; etc) and a copyleft license would be a good fit there IMHO. This is not to say that I'm principally opposed to a more permissive (dual) license, especially if there would be a good use case for that. But it seems to me that it may be non-trivial to build on the existing code base and re-license that, whereas GPLv2 would allow to fork immediately and also have any overlapping bug fixes seamlessly merged back upstream as you pointed out. Also open to hearing alternative proposals of course! Best, Jo
Re: [PATCH v7 00/13] selftests/sgx: Fix compilation errors
On 10.10.23 11:44, Jarkko Sakkinen wrote: Folks (sorry for top posting): I've now taken my old NUC7 out of the dust and tested the series :-) Tested-by: Jarkko Sakkinen Thanks for testing this Jarkko! Not sure on next steps, do you want me to re-post the series with the Tested-by tag for all commits or will you add that? Let me know if something from my side is needed. Off-topic: I wish both Intel and AMD straighten up and deliver some "home friendly" development hardware for the latest stuff. Just my stance but the biggest quality risk I see in both TDX and SNP is that the patches are made by an enterprise and reviewed (properly) *only* by other huge enterprises. Yes, I totally agree on this. It is really unfortunate that things like SGX are not (anymore) available on home consumer hardware and you have to buy expensive servers for this, which also change every new CPU generation. Having some kind of "developer boards" like is more the case in embedded systems would be a great and very welcome evolution, if only it were to happen.. I skim status of both from time to time but yeah not much attachment or motivation to do more than that as you either need a cloud access or partnership with Intel or AMD. "Indie" style seems to be disliked these days... You can extrapolate from this that there must be a bunch of maintainers around the Linux kernel that feel the same. Not saying that particularly my contribution would be that important. Sort of even if let's say Intel would provide me a partner access I might not be that interested because I prefer my own (physical) computers. I also understand this and share the concern. FWIW for some things (e.g., uarch attack research) remote access does also not really hold up to bare-metal access IMO. Best, Jo
[PATCH 3/3] dt-bindings: usb: fsa4480: Add compatible for OCP96011
The Orient-Chip OCP96011 is generally compatible with the FSA4480, add a compatible for it with the fallback on fsa4480. However the AUX/SBU connections are expected to be swapped compared to FSA4480, so document this in the data-lanes description. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml index 86f6d633c2fb..f9410eb76a62 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml @@ -11,8 +11,12 @@ maintainers: properties: compatible: -enum: - - fcs,fsa4480 +oneOf: + - const: fcs,fsa4480 + - items: + - enum: + - ocs,ocp96011 + - const: fcs,fsa4480 reg: maxItems: 1 @@ -53,16 +57,22 @@ properties: - const: 0 - const: 1 description: | - Default AUX/SBU layout + Default AUX/SBU layout (FSA4480) - AUX+ connected to SBU2 - AUX- connected to SBU1 + Default AUX/SBU layout (OCP96011) + - AUX+ connected to SBU1 + - AUX- connected to SBU2 - items: - const: 1 - const: 0 description: | - Swapped AUX/SBU layout + Swapped AUX/SBU layout (FSA4480) - AUX+ connected to SBU1 - AUX- connected to SBU2 + Swapped AUX/SBU layout (OCP96011) + - AUX+ connected to SBU2 + - AUX- connected to SBU1 required: - compatible -- 2.42.0
[PATCH 2/3] usb: typec: fsa4480: Add support to swap SBU orientation
On some hardware designs the AUX+/- lanes are connected reversed to
SBU1/2 compared to the expected design by FSA4480.
Made more complicated, the otherwise compatible Orient-Chip OCP96011
expects the lanes to be connected reversed compared to FSA4480.
* FSA4480 block diagram shows AUX+ connected to SBU2 and AUX- to SBU1.
* OCP96011 block diagram shows AUX+ connected to SBU1 and AUX- to SBU2.
So if OCP96011 is used as drop-in for FSA4480 then the orientation
handling in the driver needs to be reversed to match the expectation of
the OCP96011 hardware.
Support parsing the data-lanes parameter in the endpoint node to swap
this in the driver.
The parse_data_lanes_mapping function is mostly taken from nb7vpq904m.c.
Signed-off-by: Luca Weiss
---
drivers/usb/typec/mux/fsa4480.c | 81 +
1 file changed, 81 insertions(+)
diff --git a/drivers/usb/typec/mux/fsa4480.c b/drivers/usb/typec/mux/fsa4480.c
index e0ee1f621abb..6ee467c96fb6 100644
--- a/drivers/usb/typec/mux/fsa4480.c
+++ b/drivers/usb/typec/mux/fsa4480.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -60,6 +61,7 @@ struct fsa4480 {
unsigned int svid;
u8 cur_enable;
+ bool swap_sbu_lanes;
};
static const struct regmap_config fsa4480_regmap_config = {
@@ -76,6 +78,9 @@ static int fsa4480_set(struct fsa4480 *fsa)
u8 enable = FSA4480_ENABLE_DEVICE;
u8 sel = 0;
+ if (fsa->swap_sbu_lanes)
+ reverse = !reverse;
+
/* USB Mode */
if (fsa->mode < TYPEC_STATE_MODAL ||
(!fsa->svid && (fsa->mode == TYPEC_MODE_USB2 ||
@@ -179,12 +184,84 @@ static int fsa4480_mux_set(struct typec_mux_dev *mux,
struct typec_mux_state *st
return ret;
}
+enum {
+ NORMAL_LANE_MAPPING,
+ INVERT_LANE_MAPPING,
+};
+
+#define DATA_LANES_COUNT 2
+
+static const int supported_data_lane_mapping[][DATA_LANES_COUNT] = {
+ [NORMAL_LANE_MAPPING] = { 0, 1 },
+ [INVERT_LANE_MAPPING] = { 1, 0 },
+};
+
+static int fsa4480_parse_data_lanes_mapping(struct fsa4480 *fsa)
+{
+ struct device_node *ep;
+ u32 data_lanes[DATA_LANES_COUNT];
+ int ret, i, j;
+
+ ep = of_graph_get_next_endpoint(fsa->client->dev.of_node, NULL);
+ if (!ep)
+ return 0;
+
+ ret = of_property_count_u32_elems(ep, "data-lanes");
+ if (ret == -EINVAL)
+ /* Property isn't here, consider default mapping */
+ goto out_done;
+ if (ret < 0)
+ goto out_error;
+
+ if (ret != DATA_LANES_COUNT) {
+ dev_err(>client->dev, "expected 2 data lanes\n");
+ ret = -EINVAL;
+ goto out_error;
+ }
+
+ ret = of_property_read_u32_array(ep, "data-lanes", data_lanes,
DATA_LANES_COUNT);
+ if (ret)
+ goto out_error;
+
+ for (i = 0; i < ARRAY_SIZE(supported_data_lane_mapping); i++) {
+ for (j = 0; j < DATA_LANES_COUNT; j++) {
+ if (data_lanes[j] != supported_data_lane_mapping[i][j])
+ break;
+ }
+
+ if (j == DATA_LANES_COUNT)
+ break;
+ }
+
+ switch (i) {
+ case NORMAL_LANE_MAPPING:
+ break;
+ case INVERT_LANE_MAPPING:
+ fsa->swap_sbu_lanes = true;
+ dev_info(>client->dev, "using inverted data lanes
mapping\n");
+ break;
+ default:
+ dev_err(>client->dev, "invalid data lanes mapping\n");
+ ret = -EINVAL;
+ goto out_error;
+ }
+
+out_done:
+ ret = 0;
+
+out_error:
+ of_node_put(ep);
+
+ return ret;
+}
+
static int fsa4480_probe(struct i2c_client *client)
{
struct device *dev = >dev;
struct typec_switch_desc sw_desc = { };
struct typec_mux_desc mux_desc = { };
struct fsa4480 *fsa;
+ int ret;
fsa = devm_kzalloc(dev, sizeof(*fsa), GFP_KERNEL);
if (!fsa)
@@ -193,6 +270,10 @@ static int fsa4480_probe(struct i2c_client *client)
fsa->client = client;
mutex_init(>lock);
+ ret = fsa4480_parse_data_lanes_mapping(fsa);
+ if (ret)
+ return ret;
+
fsa->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(fsa->regmap))
return dev_err_probe(dev, PTR_ERR(fsa->regmap), "failed to
initialize regmap\n");
--
2.42.0
[PATCH 1/3] dt-bindings: usb: fsa4480: Add data-lanes property to endpoint
Allow specifying data-lanes to reverse the SBU muxing orientation where necessary by the hardware design. Signed-off-by: Luca Weiss --- .../devicetree/bindings/usb/fcs,fsa4480.yaml | 29 +- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml index f6e7a5c1ff0b..86f6d633c2fb 100644 --- a/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml +++ b/Documentation/devicetree/bindings/usb/fcs,fsa4480.yaml @@ -32,10 +32,37 @@ properties: type: boolean port: -$ref: /schemas/graph.yaml#/properties/port +$ref: /schemas/graph.yaml#/$defs/port-base description: A port node to link the FSA4480 to a TypeC controller for the purpose of handling altmode muxing and orientation switching. +unevaluatedProperties: false + +properties: + endpoint: +$ref: /schemas/graph.yaml#/$defs/endpoint-base +unevaluatedProperties: false + +properties: + data-lanes: +$ref: /schemas/types.yaml#/definitions/uint32-array +description: + Specifies how the AUX+/- lines are connected to SBU1/2. +oneOf: + - items: + - const: 0 + - const: 1 +description: | + Default AUX/SBU layout + - AUX+ connected to SBU2 + - AUX- connected to SBU1 + - items: + - const: 1 + - const: 0 +description: | + Swapped AUX/SBU layout + - AUX+ connected to SBU1 + - AUX- connected to SBU2 required: - compatible -- 2.42.0
[PATCH 0/3] Handle reversed SBU orientation for FSA4480
Short reason: Without swapping the SBU lanes, on QCM6490 Fairphone 5 the DisplayPort-over-USB-C doesn't work. The Orient-Chip OCP96011 used in this phone is generally compatible with FSA4480 but has a difference how AUX+/- should be connected to SBU1/2. Long explanation, with my current understanding: * FSA4480 block diagram shows AUX+ connected to SBU2 and AUX- to SBU1. * OCP96011 block diagram shows AUX+ connected to SBU1 and AUX- to SBU2 (it's not 100% clear though in the picture but makes sense with the observed behavior) * Fairphone 5 schematics have AUX+ connected to SBU2 and AUX- to SBU1, which would be correct for FSA4480 but since OCP96011 is used (which expects it to be the other way around) the Linux driver needs to reverse it. If AUX+ would be connected to SBU1 and AUX- to SBU2 as shown in the OCP96011 block diagram, then no driver/dts change would be needed. Not sure if I've implemented the best solution in this patch. Other solutions I could think of are: * Add some custom boolean property to the node, e.g. 'fsa,swap-sbu' * Reverse when ocs,ocp96011 compatible is used. This would be incorrect since when following the OCP96011 block diagram no reversing would be needed, as explained above. However I think the current solution with data-lanes in the endpoint is the best fit and is also already used for a similar purpose in another USB mux driver. Signed-off-by: Luca Weiss --- Luca Weiss (3): dt-bindings: usb: fsa4480: Add data-lanes property to endpoint usb: typec: fsa4480: Add support to swap SBU orientation dt-bindings: usb: fsa4480: Add compatible for OCP96011 .../devicetree/bindings/usb/fcs,fsa4480.yaml | 43 +++- drivers/usb/typec/mux/fsa4480.c| 81 ++ 2 files changed, 121 insertions(+), 3 deletions(-) --- base-commit: e3b18f7200f45d66f7141136c25554ac1e82009b change-id: 20231013-fsa4480-swap-9b0f76d73c19 Best regards, -- Luca Weiss
Re: [PATCH] bus: mhi: host: Add tracing support
On 10/6/2023 4:10 AM, Bjorn Andersson wrote:
On Thu, Oct 05, 2023 at 03:55:20PM +0530, Krishna chaitanya chundru wrote:
This change adds ftrace support for following:
1. mhi_intvec_threaded_handler
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker
This is not the best "problem description".
Usage:
echo 1 > /sys/kernel/debug/tracing/events/mhi_host/enable
cat /sys/kernel/debug/tracing/trace
This does not need to be included in the commit message, how to use the
tracing framework is documented elsewhere.
Removed this now.
[..]
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..499590437e9b 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -491,11 +491,10 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number,
void *priv)
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
- dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
- TO_MHI_EXEC_STR(mhi_cntrl->ee),
- mhi_state_str(mhi_cntrl->dev_state),
- TO_MHI_EXEC_STR(ee), mhi_state_str(state));
+ trace_mhi_intvec_threaded_handler(mhi_cntrl->mhi_dev->name, TO_MHI_EXEC_STR(mhi_cntrl->ee),
+ mhi_state_str(mhi_cntrl->dev_state),
+ TO_MHI_EXEC_STR(ee),
mhi_state_str(state));
All these helper functions that translates a state to a string, pass the
raw state into the trace event and use __print_symbolic() in your
TP_printk() instead.
This will allow you to read the state, but you can have tools act of the
numerical value.
(This comment applies to all the trace events)
changed the events as you suggested.
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
[..]
diff --git a/include/trace/events/mhi_host.h b/include/trace/events/mhi_host.h
[..]
+
+TRACE_EVENT(mhi_pm_st_worker,
Why is this trace event called "worker", isn't the event a
"mhi_pm_state_transition"?
Don't just name your trace event based on the function that triggers
them, but what they represent and make sure they carry useful
information to understand the system.
If you want to trace the flow through your functions, you can use e.g.
ftrace.
Regards,
Bjorn
Changed as you suggested.
- KC
[PATCH v2] bus: mhi: host: Add tracing support
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_threaded_handler
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_update_channel_state
6. mhi_tryset_pm_state
7. mhi_pm_st_worker
Signed-off-by: Krishna chaitanya chundru
---
Changes in v2:
- Passing the raw state into the trace event and using __print_symbolic() as
suggested by bjorn.
- Change mhi_pm_st_worker to mhi_pm_st_transition as suggested by bjorn.
- Fixed the kernel test rebot issues.
- Link to v1:
https://lore.kernel.org/r/20231005-ftrace_support-v1-1-23a2f394f...@quicinc.com
---
MAINTAINERS | 1 +
drivers/bus/mhi/host/init.c | 3 +
drivers/bus/mhi/host/internal.h | 1 +
drivers/bus/mhi/host/main.c | 32 +++--
drivers/bus/mhi/host/pm.c | 6 +-
include/trace/events/mhi_host.h | 287
6 files changed, 317 insertions(+), 13 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 35977b269d5e..4339c668a6ab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13862,6 +13862,7 @@ F: Documentation/mhi/
F: drivers/bus/mhi/
F: drivers/pci/endpoint/functions/pci-epf-mhi.c
F: include/linux/mhi.h
+F: include/trace/events/mhi_host.h
MICROBLAZE ARCHITECTURE
M: Michal Simek
diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c
index f78aefd2d7a3..3afa90a204fd 100644
--- a/drivers/bus/mhi/host/init.c
+++ b/drivers/bus/mhi/host/init.c
@@ -20,6 +20,9 @@
#include
#include "internal.h"
+#define CREATE_TRACE_POINTS
+#include
+
static DEFINE_IDA(mhi_controller_ida);
const char * const mhi_ee_str[MHI_EE_MAX] = {
diff --git a/drivers/bus/mhi/host/internal.h b/drivers/bus/mhi/host/internal.h
index 2e139e76de4c..a80a317a59a9 100644
--- a/drivers/bus/mhi/host/internal.h
+++ b/drivers/bus/mhi/host/internal.h
@@ -7,6 +7,7 @@
#ifndef _MHI_INT_H
#define _MHI_INT_H
+#include
#include "../common.h"
extern struct bus_type mhi_bus_type;
diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
index dcf627b36e82..fcdb728ba49f 100644
--- a/drivers/bus/mhi/host/main.c
+++ b/drivers/bus/mhi/host/main.c
@@ -246,6 +246,11 @@ static void *mhi_to_virtual(struct mhi_ring *ring,
dma_addr_t addr)
return (addr - ring->iommu_base) + ring->base;
}
+dma_addr_t mhi_to_physical(struct mhi_ring *ring, void *addr)
+{
+ return (addr - ring->base) + ring->iommu_base;
+}
+
static void mhi_add_ring_element(struct mhi_controller *mhi_cntrl,
struct mhi_ring *ring)
{
@@ -491,11 +496,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number,
void *priv)
state = mhi_get_mhi_state(mhi_cntrl);
ee = mhi_get_exec_env(mhi_cntrl);
- dev_dbg(dev, "local ee: %s state: %s device ee: %s state: %s\n",
- TO_MHI_EXEC_STR(mhi_cntrl->ee),
- mhi_state_str(mhi_cntrl->dev_state),
- TO_MHI_EXEC_STR(ee), mhi_state_str(state));
+ trace_mhi_intvec_threaded_handler(mhi_cntrl->mhi_dev->name,
mhi_cntrl->ee,
+ mhi_cntrl->dev_state, ee, state);
if (state == MHI_STATE_SYS_ERR) {
dev_dbg(dev, "System error detected\n");
pm_state = mhi_tryset_pm_state(mhi_cntrl,
@@ -832,6 +835,12 @@ int mhi_process_ctrl_ev_ring(struct mhi_controller
*mhi_cntrl,
while (dev_rp != local_rp) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
+ trace_mhi_process_ctrl_ev_ring(mhi_cntrl->mhi_dev->name,
+ mhi_to_physical(ev_ring,
local_rp),
+ local_rp->ptr,
local_rp->dword[0],
+ local_rp->dword[1],
+ MHI_TRE_GET_EV_STATE(local_rp));
+
switch (type) {
case MHI_PKT_TYPE_BW_REQ_EVENT:
{
@@ -997,6 +1006,9 @@ int mhi_process_data_event_ring(struct mhi_controller
*mhi_cntrl,
while (dev_rp != local_rp && event_quota > 0) {
enum mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
+ trace_mhi_process_data_event_ring(mhi_cntrl->mhi_dev->name,
local_rp->ptr,
+ local_rp->dword[0],
local_rp->dword[1]);
+
chan = MHI_TRE_GET_EV_CHID(local_rp);
WARN_ON(chan >= mhi_cntrl->max_chan);
@@ -1235,6 +1247,9 @@ int mhi_gen_tre(struct mhi_controller *mhi_cntrl, struct
mhi_chan *mhi_chan,
mhi_tre->dword[0] = MHI_TRE_DATA_DWORD0(info->len);
mhi_tre->dword[1] = MHI_TRE_DATA_DWORD1(bei, eot, eob, chain);
+ trace_mhi_gen_tre(mhi_cntrl->mhi_dev->name, mhi_chan->chan,
+ mhi_to_physical(tre_ring,
Re: [PATCH v3 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP
Hi Iuliana,
Am Freitag, 13. Oktober 2023, 10:35:17 CEST schrieb Iuliana Prodan:
> Hi Alexander,
>
> On 10/11/2023 8:37 AM, Alexander Stein wrote:
> > Hi Iuliana,
> >
> > Am Dienstag, 10. Oktober 2023, 11:09:29 CEST schrieb Iuliana Prodan (OSS):
> >> From: Iuliana Prodan
> >>
> >> Add the reserve-memory nodes used by DSP when the rpmsg
> >> feature is enabled.
> >>
> >> Signed-off-by: Iuliana Prodan
> >> ---
> >>
> >> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >> b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
> >> cc406bb338fe..22815b3ea890 100644
> >> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> >> @@ -211,6 +211,22 @@
> >>
> >>reg = <0 0x9240 0 0x200>;
> >>no-map;
> >>
> >>};
> >>
> >> +
> >> + dsp_vdev0vring0: vdev0vring0@942f {
> >> + reg = <0 0x942f 0 0x8000>;
> >> + no-map;
> >> + };
> >> +
> >> + dsp_vdev0vring1: vdev0vring1@942f8000 {
> >> + reg = <0 0x942f8000 0 0x8000>;
> >> + no-map;
> >> + };
> >> +
> >> + dsp_vdev0buffer: vdev0buffer@9430 {
> >> + compatible = "shared-dma-pool";
> >> + reg = <0 0x9430 0 0x10>;
> >> + no-map;
> >> + };
> >
> > Please configure these reserved memories on board level. Not every i.MX8MP
> > based board uses this DSP or has these memory addresses available.
>
> Will it be ok in imx8mp-evk.dts?
If that is the board using the DSP and the reserved memory, then yes.
Best regards,
Alexander
> Thanks,
> Iulia
>
> > Best regards,
> > Alexander
> >
> >>};
> >>
> >>pmu {
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
Re: [PATCH 1/4] iio: adc: Add PM7325 PMIC7 ADC bindings
On 13/10/2023 10:54, Luca Weiss wrote: >> We expect the bindings to be dual licensed. What was the license of the >> original work? > > Yes, just GPL-2.0-only: > https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/LA.UM.9.14.1.r1-08600-QCM6490.QSSI13.0/include/dt-bindings/iio/qcom%2Cspmi-adc7-pm7325.h > > Unfortunately it's the same situation with all the other header files > like this one. > > $ grep SPDX include/dt-bindings/iio/qcom,spmi-adc7-* > include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h:/* SPDX-License-Identifier: > GPL-2.0-only */ > include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h:/* > SPDX-License-Identifier: GPL-2.0-only */ > include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h:/* > SPDX-License-Identifier: GPL-2.0-only */ > include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h:/* > SPDX-License-Identifier: GPL-2.0-only */ > include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h:/* > SPDX-License-Identifier: GPL-2.0-only */ > > If you know someone at Qualcomm to ask nicely to relicense those (plus > ones that will presumably be added later), that'd be appreciated. We could relicense Qualcomm stuff but this was transferred to Linux Foundation. :/ Best regards, Krzysztof
[PATCH v2] ACPI: NFIT: Fix local use of devm_*()
devm_*() family of functions purpose is managing memory attached to a
device. So in general it should only be used for allocations that should
last for the whole lifecycle of the device. This is not the case for
acpi_nfit_init_interleave_set(). There are two allocations that are only
used locally in this function.
Fix this by switching from devm_kcalloc() to kcalloc(), and adding
modern scope based rollback. This is similar to C++ RAII and is
preferred way for handling local memory allocations.
Reported-by: Andy Shevchenko
Suggested-by: Dave Jiang
Suggested-by: Andy Shevchenko
Reviewed-by: Dave Jiang
Reviewed-by: Andy Shevchenko
Signed-off-by: Michal Wilczynski
---
v2:
- removed first commit from the patchset, as the commit couldn't
be marked as a fix
- squashed those commits together, since the second one were
mostly overwriting the previous one
drivers/acpi/nfit/core.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 3826f49d481b..67a844a705c4 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2257,26 +2257,23 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
struct nd_region_desc *ndr_desc,
struct acpi_nfit_system_address *spa)
{
+ u16 nr = ndr_desc->num_mappings;
+ struct nfit_set_info2 *info2 __free(kfree) =
+ kcalloc(nr, sizeof(*info2), GFP_KERNEL);
+ struct nfit_set_info *info __free(kfree) =
+ kcalloc(nr, sizeof(*info), GFP_KERNEL);
struct device *dev = acpi_desc->dev;
struct nd_interleave_set *nd_set;
- u16 nr = ndr_desc->num_mappings;
- struct nfit_set_info2 *info2;
- struct nfit_set_info *info;
int i;
+ if (!info || !info2)
+ return -ENOMEM;
+
nd_set = devm_kzalloc(dev, sizeof(*nd_set), GFP_KERNEL);
if (!nd_set)
return -ENOMEM;
import_guid(_set->type_guid, spa->range_guid);
- info = devm_kcalloc(dev, nr, sizeof(*info), GFP_KERNEL);
- if (!info)
- return -ENOMEM;
-
- info2 = devm_kcalloc(dev, nr, sizeof(*info2), GFP_KERNEL);
- if (!info2)
- return -ENOMEM;
-
for (i = 0; i < nr; i++) {
struct nd_mapping_desc *mapping = _desc->mapping[i];
struct nvdimm *nvdimm = mapping->nvdimm;
@@ -2337,8 +2334,6 @@ static int acpi_nfit_init_interleave_set(struct
acpi_nfit_desc *acpi_desc,
}
ndr_desc->nd_set = nd_set;
- devm_kfree(dev, info);
- devm_kfree(dev, info2);
return 0;
}
--
2.41.0
Re: [PATCH 1/4] iio: adc: Add PM7325 PMIC7 ADC bindings
On Fri Oct 13, 2023 at 10:38 AM CEST, Krzysztof Kozlowski wrote: > On 13/10/2023 10:09, Luca Weiss wrote: > > Add the defines for the ADC channels found on the PM7325. The list is > > taken from downstream msm-5.4 and adjusted for mainline. > > Please use subject prefixes matching the subsystem. You can get them for > example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory > your patch is touching. Seems very inconsistent (git log --oneline include/dt-bindings/iio/qcom,*) but I guess this would fit better? dt-bindings: iio: adc: Add PM7325 PMIC7 ADC bindings Will update for v2. > > > > > Signed-off-by: Luca Weiss > > --- > > include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h | 69 > > + > > 1 file changed, 69 insertions(+) > > > > diff --git a/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > > b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > > new file mode 100644 > > index ..96908014e09e > > --- /dev/null > > +++ b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > > @@ -0,0 +1,69 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > We expect the bindings to be dual licensed. What was the license of the > original work? Yes, just GPL-2.0-only: https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/LA.UM.9.14.1.r1-08600-QCM6490.QSSI13.0/include/dt-bindings/iio/qcom%2Cspmi-adc7-pm7325.h Unfortunately it's the same situation with all the other header files like this one. $ grep SPDX include/dt-bindings/iio/qcom,spmi-adc7-* include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h:/* SPDX-License-Identifier: GPL-2.0-only */ include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h:/* SPDX-License-Identifier: GPL-2.0-only */ include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h:/* SPDX-License-Identifier: GPL-2.0-only */ include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h:/* SPDX-License-Identifier: GPL-2.0-only */ include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h:/* SPDX-License-Identifier: GPL-2.0-only */ If you know someone at Qualcomm to ask nicely to relicense those (plus ones that will presumably be added later), that'd be appreciated. Regards Luca > > > +/* > > + * Copyright (c) 2020 The Linux Foundation. All rights reserved. > > + */ > > > > Best regards, > Krzysztof
Re: [PATCH 1/4] iio: adc: Add PM7325 PMIC7 ADC bindings
On 13/10/2023 10:09, Luca Weiss wrote: > Add the defines for the ADC channels found on the PM7325. The list is > taken from downstream msm-5.4 and adjusted for mainline. Please use subject prefixes matching the subsystem. You can get them for example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your patch is touching. > > Signed-off-by: Luca Weiss > --- > include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h | 69 > + > 1 file changed, 69 insertions(+) > > diff --git a/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > new file mode 100644 > index ..96908014e09e > --- /dev/null > +++ b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h > @@ -0,0 +1,69 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ We expect the bindings to be dual licensed. What was the license of the original work? > +/* > + * Copyright (c) 2020 The Linux Foundation. All rights reserved. > + */ Best regards, Krzysztof
Re: [PATCH v3 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP
Hi Alexander,
On 10/11/2023 8:37 AM, Alexander Stein wrote:
Hi Iuliana,
Am Dienstag, 10. Oktober 2023, 11:09:29 CEST schrieb Iuliana Prodan (OSS):
From: Iuliana Prodan
Add the reserve-memory nodes used by DSP when the rpmsg
feature is enabled.
Signed-off-by: Iuliana Prodan
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi index
cc406bb338fe..22815b3ea890 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -211,6 +211,22 @@
reg = <0 0x9240 0 0x200>;
no-map;
};
+
+ dsp_vdev0vring0: vdev0vring0@942f {
+ reg = <0 0x942f 0 0x8000>;
+ no-map;
+ };
+
+ dsp_vdev0vring1: vdev0vring1@942f8000 {
+ reg = <0 0x942f8000 0 0x8000>;
+ no-map;
+ };
+
+ dsp_vdev0buffer: vdev0buffer@9430 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x9430 0 0x10>;
+ no-map;
+ };
Please configure these reserved memories on board level. Not every i.MX8MP
based board uses this DSP or has these memory addresses available.
Will it be ok in imx8mp-evk.dts?
Thanks,
Iulia
Best regards,
Alexander
};
pmu {
[PATCH 4/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7325 thermals
Configure the thermals for the QUIET_THERM, CAM_FLASH_THERM, MSM_THERM
and RFC_CAM_THERM thermistors connected to PM7325.
With this PMIC the software communication to the ADC is going through
PMK7325 (= PMK8350).
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 117 +
1 file changed, 117 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 2c01f799a6b2..d0b1e4e507ff 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -9,6 +9,7 @@
#define PM7250B_SID 8
#define PM7250B_SID1 9
+#include
#include
#include
#include
@@ -137,6 +138,20 @@ afvdd_2p8: regulator-afvdd-2p8 {
};
thermal-zones {
+ camera-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 2>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
chg-skin-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
@@ -165,6 +180,48 @@ active-config0 {
};
};
+ quiet-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ rear-cam-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 4>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ sdm-skin-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 3>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
xo-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
@@ -538,6 +595,34 @@ xo-therm@0 {
qcom,ratiometric;
qcom,hw-settle-time-us = <200>;
};
+
+ quiet-therm@1 {
+ reg = <1>;
+ io-channels = <_vadc PM7325_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ cam-flash-therm@2 {
+ reg = <2>;
+ io-channels = <_vadc PM7325_ADC7_AMUX_THM2_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ sdm-skin-therm@3 {
+ reg = <3>;
+ io-channels = <_vadc PM7325_ADC7_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ wide-rfc-therm@4 {
+ reg = <4>;
+ io-channels = <_vadc PM7325_ADC7_AMUX_THM4_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
};
_rtc {
@@ -554,6 +639,38 @@ channel@44 {
qcom,pre-scaling = <1 1>;
label = "pmk8350_xo_therm";
};
+
+ channel@144 {
+ reg = ;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_quiet_therm";
+ };
+
+ channel@145 {
+ reg = ;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_cam_flash_therm";
+ };
+
+ channel@146 {
+ reg = ;
+
[PATCH 3/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PMK7325 thermals
Configure the thermals for the XO_THERM line connected to PMK7325 (named
in software PMK8350).
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 7fe19b556e6a..2c01f799a6b2 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -9,6 +9,7 @@
#define PM7250B_SID 8
#define PM7250B_SID1 9
+#include
#include
#include
#include
@@ -163,6 +164,20 @@ active-config0 {
};
};
};
+
+ xo-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
};
};
@@ -514,10 +529,33 @@ led-0 {
};
};
+_adc_tm {
+ status = "okay";
+
+ xo-therm@0 {
+ reg = <0>;
+ io-channels = <_vadc PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
_rtc {
status = "okay";
};
+_vadc {
+ status = "okay";
+
+ channel@44 {
+ reg = ;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pmk8350_xo_therm";
+ };
+};
+
_pwrkey {
status = "okay";
};
--
2.42.0
[PATCH 2/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7250B thermals
Configure the thermals for the CHARGER_SKIN_THERM and USB_CONN_THERM
thermistors connected to PM7250B.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 66 ++
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 2de0b8c26c35..7fe19b556e6a 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -134,6 +134,36 @@ afvdd_2p8: regulator-afvdd-2p8 {
enable-active-high;
vin-supply = <_bob>;
};
+
+ thermal-zones {
+ chg-skin-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ conn-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
};
_rsc {
@@ -425,6 +455,42 @@ {
status = "okay";
};
+_adc {
+ channel@4d {
+ reg = ;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "charger_skin_therm";
+ };
+
+ channel@4f {
+ reg = ;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "conn_therm";
+ };
+};
+
+_adc_tm {
+ status = "okay";
+
+ charger-skin-therm@0 {
+ reg = <0>;
+ io-channels = <_adc ADC5_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ conn-therm@1 {
+ reg = <1>;
+ io-channels = <_adc ADC5_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
_gpios {
volume_down_default: volume-down-default-state {
pins = "gpio6";
--
2.42.0
[PATCH 0/4] Add Fairphone 5 thermals (PMK7325, PM7250B, PM7325)
Configure the necessary components to register some thermal zones in Linux for the different thermistors found on the Fairphone 5. The names for the thermal zones and ADCs were taken from the downstream kernel but double checked against hardware schematics. Signed-off-by: Luca Weiss --- Luca Weiss (4): iio: adc: Add PM7325 PMIC7 ADC bindings arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7250B thermals arm64: dts: qcom: qcm6490-fairphone-fp5: Add PMK7325 thermals arm64: dts: qcom: qcm6490-fairphone-fp5: Add PM7325 thermals arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 221 + include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h| 69 +++ 2 files changed, 290 insertions(+) --- base-commit: 7c0d0c1272e82888aa01017818d00245d452b895 change-id: 20231013-fp5-thermals-2b318c859dd4 Best regards, -- Luca Weiss
[PATCH 1/4] iio: adc: Add PM7325 PMIC7 ADC bindings
Add the defines for the ADC channels found on the PM7325. The list is taken from downstream msm-5.4 and adjusted for mainline. Signed-off-by: Luca Weiss --- include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h | 69 + 1 file changed, 69 insertions(+) diff --git a/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h new file mode 100644 index ..96908014e09e --- /dev/null +++ b/include/dt-bindings/iio/qcom,spmi-adc7-pm7325.h @@ -0,0 +1,69 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2020 The Linux Foundation. All rights reserved. + */ + +#ifndef _DT_BINDINGS_QCOM_SPMI_VADC_PM7325_H +#define _DT_BINDINGS_QCOM_SPMI_VADC_PM7325_H + +#ifndef PM7325_SID +#define PM7325_SID 1 +#endif + +#include + +/* ADC channels for PM7325_ADC for PMIC7 */ +#define PM7325_ADC7_REF_GND(PM7325_SID << 8 | ADC7_REF_GND) +#define PM7325_ADC7_1P25VREF (PM7325_SID << 8 | ADC7_1P25VREF) +#define PM7325_ADC7_VREF_VADC (PM7325_SID << 8 | ADC7_VREF_VADC) +#define PM7325_ADC7_DIE_TEMP (PM7325_SID << 8 | ADC7_DIE_TEMP) + +#define PM7325_ADC7_AMUX_THM1 (PM7325_SID << 8 | ADC7_AMUX_THM1) +#define PM7325_ADC7_AMUX_THM2 (PM7325_SID << 8 | ADC7_AMUX_THM2) +#define PM7325_ADC7_AMUX_THM3 (PM7325_SID << 8 | ADC7_AMUX_THM3) +#define PM7325_ADC7_AMUX_THM4 (PM7325_SID << 8 | ADC7_AMUX_THM4) +#define PM7325_ADC7_AMUX_THM5 (PM7325_SID << 8 | ADC7_AMUX_THM5) +#define PM7325_ADC7_GPIO1 (PM7325_SID << 8 | ADC7_GPIO1) +#define PM7325_ADC7_GPIO2 (PM7325_SID << 8 | ADC7_GPIO2) +#define PM7325_ADC7_GPIO3 (PM7325_SID << 8 | ADC7_GPIO3) +#define PM7325_ADC7_GPIO4 (PM7325_SID << 8 | ADC7_GPIO4) + +/* 30k pull-up1 */ +#define PM7325_ADC7_AMUX_THM1_30K_PU (PM7325_SID << 8 | ADC7_AMUX_THM1_30K_PU) +#define PM7325_ADC7_AMUX_THM2_30K_PU (PM7325_SID << 8 | ADC7_AMUX_THM2_30K_PU) +#define PM7325_ADC7_AMUX_THM3_30K_PU (PM7325_SID << 8 | ADC7_AMUX_THM3_30K_PU) +#define PM7325_ADC7_AMUX_THM4_30K_PU (PM7325_SID << 8 | ADC7_AMUX_THM4_30K_PU) +#define PM7325_ADC7_AMUX_THM5_30K_PU (PM7325_SID << 8 | ADC7_AMUX_THM5_30K_PU) +#define PM7325_ADC7_GPIO1_30K_PU (PM7325_SID << 8 | ADC7_GPIO1_30K_PU) +#define PM7325_ADC7_GPIO2_30K_PU (PM7325_SID << 8 | ADC7_GPIO2_30K_PU) +#define PM7325_ADC7_GPIO3_30K_PU (PM7325_SID << 8 | ADC7_GPIO3_30K_PU) +#define PM7325_ADC7_GPIO4_30K_PU (PM7325_SID << 8 | ADC7_GPIO4_30K_PU) + +/* 100k pull-up2 */ +#define PM7325_ADC7_AMUX_THM1_100K_PU (PM7325_SID << 8 | ADC7_AMUX_THM1_100K_PU) +#define PM7325_ADC7_AMUX_THM2_100K_PU (PM7325_SID << 8 | ADC7_AMUX_THM2_100K_PU) +#define PM7325_ADC7_AMUX_THM3_100K_PU (PM7325_SID << 8 | ADC7_AMUX_THM3_100K_PU) +#define PM7325_ADC7_AMUX_THM4_100K_PU (PM7325_SID << 8 | ADC7_AMUX_THM4_100K_PU) +#define PM7325_ADC7_AMUX_THM5_100K_PU (PM7325_SID << 8 | ADC7_AMUX_THM5_100K_PU) +#define PM7325_ADC7_GPIO1_100K_PU (PM7325_SID << 8 | ADC7_GPIO1_100K_PU) +#define PM7325_ADC7_GPIO2_100K_PU (PM7325_SID << 8 | ADC7_GPIO2_100K_PU) +#define PM7325_ADC7_GPIO3_100K_PU (PM7325_SID << 8 | ADC7_GPIO3_100K_PU) +#define PM7325_ADC7_GPIO4_100K_PU (PM7325_SID << 8 | ADC7_GPIO4_100K_PU) + +/* 400k pull-up3 */ +#define PM7325_ADC7_AMUX_THM1_400K_PU (PM7325_SID << 8 | ADC7_AMUX_THM1_400K_PU) +#define PM7325_ADC7_AMUX_THM2_400K_PU (PM7325_SID << 8 | ADC7_AMUX_THM2_400K_PU) +#define PM7325_ADC7_AMUX_THM3_400K_PU (PM7325_SID << 8 | ADC7_AMUX_THM3_400K_PU) +#define PM7325_ADC7_AMUX_THM4_400K_PU (PM7325_SID << 8 | ADC7_AMUX_THM4_400K_PU) +#define PM7325_ADC7_AMUX_THM5_400K_PU (PM7325_SID << 8 | ADC7_AMUX_THM5_400K_PU) +#define PM7325_ADC7_GPIO1_400K_PU (PM7325_SID << 8 | ADC7_GPIO1_400K_PU) +#define PM7325_ADC7_GPIO2_400K_PU (PM7325_SID << 8 | ADC7_GPIO2_400K_PU) +#define PM7325_ADC7_GPIO3_400K_PU (PM7325_SID << 8 | ADC7_GPIO3_400K_PU) +#define PM7325_ADC7_GPIO4_400K_PU (PM7325_SID << 8 | ADC7_GPIO4_400K_PU) + +/* 1/3 Divider */ +#define PM7325_ADC7_GPIO4_DIV3 (PM7325_SID << 8 | ADC7_GPIO4_DIV3) + +#define PM7325_ADC7_VPH_PWR(PM7325_SID << 8 | ADC7_VPH_PWR) + +#endif /* _DT_BINDINGS_QCOM_SPMI_VADC_PM7325_H */ -- 2.42.0
[PATCH v5] module: Add CONFIG_MODULE_DISABLE_INIT_FREE option
Syzkaller uses the _RET_IP_ (also known as pc) to decode covered file/function/line, and it employs pc ^ hash(prev_pc) (referred to as signal) to indicate covered edge. If the pc for the same file/line keeps changing across reboots, syzkaller will report incorrect coverage data. Additionally, even if kaslr can be disabled, we cannot get the same covered edge for module because both pc and prev_pc have changed, thus altering pc ^ hash(prev_pc). To facilitate syzkaller coverage, it is crucial for both the core kernel and modules to maintain at the same addresses across reboots. So, the following steps are necessary: - In userspace: 1) To maintain an uninterrupted loading sequence, it is recommended to execute modprobe commands by loading one module at a time, to avoid any interference from the scheduler. 2) Avoid unloading any module during fuzzing. - In kernel: 1) Disable CONFIG_RANDOMIZE_BASE to load the core kernel at the same address consistently. 2) To ensure deterministic module loading at the same address, enabling CONFIG_MODULE_DISABLE_INIT_FREE prevents the asynchronous freeing of init sections. Without this option, there is a possibility that the next module could be loaded into previous freed init pages of a previous loaded module. It is important to note that this option is intended for fuzzing tests only and should not be set as the default configuration in production builds. Signed-off-by: Joey Jiao --- kernel/module/Kconfig | 13 + kernel/module/main.c | 3 ++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig index 33a2e991f608..d0df0b5997b0 100644 --- a/kernel/module/Kconfig +++ b/kernel/module/Kconfig @@ -389,4 +389,17 @@ config MODULES_TREE_LOOKUP def_bool y depends on PERF_EVENTS || TRACING || CFI_CLANG +config MODULE_DISABLE_INIT_FREE + bool "Disable freeing of init sections" + default n + depends on !RANDOMIZE_BASE + help + By default, the kernel frees init sections after module is fully + loaded. + + Enabling MODULE_DISABLE_INIT_FREE allows users to prevent the freeing + of init sections. It is particularly helpful for syzkaller fuzzing, + ensuring that the module consistently loads at the same address + across reboots. + endif # MODULES diff --git a/kernel/module/main.c b/kernel/module/main.c index 98fedfdb8db5..d226df3a6cf6 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -2593,7 +2593,8 @@ static noinline int do_init_module(struct module *mod) * be cleaned up needs to sync with the queued work - ie * rcu_barrier() */ - if (llist_add(>node, _free_list)) + if (!IS_ENABLED(CONFIG_MODULE_DISABLE_INIT_FREE) && + llist_add(>node, _free_list)) schedule_work(_free_wq); mutex_unlock(_mutex); -- 2.42.0
Re: [RFC PATCH bpf-next] bpf: change syscall_nr type to int in struct syscall_tp_t
On Thu, Oct 12, 2023 at 04:32:51PM -0700, Andrii Nakryiko wrote:
> On Thu, Oct 12, 2023 at 6:43 AM Steven Rostedt wrote:
> >
> > On Thu, 12 Oct 2023 13:45:50 +0200
> > Artem Savkov wrote:
> >
> > > linux-rt-devel tree contains a patch (b1773eac3f29c ("sched: Add support
> > > for lazy preemption")) that adds an extra member to struct trace_entry.
> > > This causes the offset of args field in struct trace_event_raw_sys_enter
> > > be different from the one in struct syscall_trace_enter:
> > >
> > > struct trace_event_raw_sys_enter {
> > > struct trace_entry ent; /* 012 */
> > >
> > > /* XXX last struct has 3 bytes of padding */
> > > /* XXX 4 bytes hole, try to pack */
> > >
> > > long int id; /*16 8 */
> > > long unsigned int args[6]; /*2448 */
> > > /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
> > > char __data[]; /*72 0 */
> > >
> > > /* size: 72, cachelines: 2, members: 4 */
> > > /* sum members: 68, holes: 1, sum holes: 4 */
> > > /* paddings: 1, sum paddings: 3 */
> > > /* last cacheline: 8 bytes */
> > > };
> > >
> > > struct syscall_trace_enter {
> > > struct trace_entry ent; /* 012 */
> > >
> > > /* XXX last struct has 3 bytes of padding */
> > >
> > > intnr; /*12 4 */
> > > long unsigned int args[]; /*16 0 */
> > >
> > > /* size: 16, cachelines: 1, members: 3 */
> > > /* paddings: 1, sum paddings: 3 */
> > > /* last cacheline: 16 bytes */
> > > };
> > >
> > > This, in turn, causes perf_event_set_bpf_prog() fail while running bpf
> > > test_profiler testcase because max_ctx_offset is calculated based on the
> > > former struct, while off on the latter:
> > >
> > > 10488 if (is_tracepoint || is_syscall_tp) {
> > > 10489 int off =
> > > trace_event_get_offsets(event->tp_event);
> > > 10490
> > > 10491 if (prog->aux->max_ctx_offset > off)
> > > 10492 return -EACCES;
> > > 10493 }
> > >
> > > What bpf program is actually getting is a pointer to struct
> > > syscall_tp_t, defined in kernel/trace/trace_syscalls.c. This patch fixes
> > > the problem by aligning struct syscall_tp_t with with struct
> > > syscall_trace_(enter|exit) and changing the tests to use these structs
> > > to dereference context.
> > >
> > > Signed-off-by: Artem Savkov
> >
>
> I think these changes make sense regardless, can you please resend the
> patch without RFC tag so that our CI can run tests for it?
Ok, didn't know it was set up like that.
> > Thanks for doing a proper fix.
> >
> > Acked-by: Steven Rostedt (Google)
>
> But looking at [0] and briefly reading some of the discussions you,
> Steven, had. I'm just wondering if it would be best to avoid
> increasing struct trace_entry altogether? It seems like preempt_count
> is actually a 4-bit field in trace context, so it doesn't seem like we
> really need to allocate an entire byte for both preempt_count and
> preempt_lazy_count. Why can't we just combine them and not waste 8
> extra bytes for each trace event in a ring buffer?
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?id=b1773eac3f29cbdcdfd16e0339f1a164066e9f71
I agree that avoiding increase in struct trace_entry size would be very
desirable, but I have no knowledge whether rt developers had reasons to
do it like this.
Nevertheless I think the issue with verifier running against a wrong
struct still needs to be addressed.
--
Regards,
Artem
