Re: [PATCH 1/3] dt-bindings: remoteproc: qcom,sm8550-pas: document the SM8650 PAS
On 25/10/2023 09:35, Neil Armstrong wrote: > Document the DSP Peripheral Authentication Service on the SM8650 Platform. > > Signed-off-by: Neil Armstrong > --- > .../bindings/remoteproc/qcom,sm8550-pas.yaml | 41 > +- > 1 file changed, 40 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > index 58120829fb06..316371c8ee6e 100644 > --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml > @@ -19,6 +19,9 @@ properties: >- qcom,sm8550-adsp-pas >- qcom,sm8550-cdsp-pas >- qcom,sm8550-mpss-pas > + - qcom,sm8650-adsp-pas > + - qcom,sm8650-cdsp-pas > + - qcom,sm8650-mpss-pas > >reg: > maxItems: 1 > @@ -49,6 +52,7 @@ properties: >- description: Memory region for main Firmware authentication >- description: Memory region for Devicetree Firmware authentication >- description: DSM Memory region > + - description: DSM Memory region 2 > > required: >- compatible > @@ -63,6 +67,7 @@ allOf: >enum: > - qcom,sm8550-adsp-pas > - qcom,sm8550-cdsp-pas > +- qcom,sm8650-adsp-pas > then: >properties: > interrupts: > @@ -71,7 +76,25 @@ allOf: >maxItems: 5 > memory-region: >maxItems: 2 > -else: > + - if: > + properties: > +compatible: > + enum: > +- qcom,sm8650-cdsp-pas > +then: > + properties: > +interrupts: > + minItems: 5 maxItems > +interrupt-names: > + minItems: 5 maxItems > +memory-region: > + minItems: 3 maxItems: 3 > + - if: > + properties: > +compatible: > + enum: > +- qcom,sm8550-mpss-pas > +then: >properties: > interrupts: >minItems: 6 > @@ -79,12 +102,26 @@ allOf: >minItems: 6 > memory-region: >minItems: 3 You need to add here maxItems. > + - if: > + properties: > +compatible: > + enum: > +- qcom,sm8650-mpss-pas > +then: I am not sure if keeping it in the same binding as sm8550 avoids that much duplication. Best regards, Krzysztof
Re: [PATCH v4 3/4] ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 10.1 LTE (SM-T535)
On 26/10/2023 15:24, Stefan Hansson wrote: > Add a device tree for the Samsung Galaxy Tab 4 10.1 (SM-T535) LTE tablet > based on the MSM8926 platform. > > The common dtsi is also modified to describe the widest constraints, > which required modifications to the matisse-wifi dts. > > Signed-off-by: Stefan Hansson Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v4 1/4] ARM: dts: qcom: samsung-matisse-common: Add initial common device tree
On 26/10/2023 15:24, Stefan Hansson wrote:
> According to the dts from the kernel source code released by Samsung,
> matissewifi and matisselte only have minor differences in hardware, so
> use a shared dtsi to reduce duplicated code. Additionally, this should
> make adding support for matisse3g easier should someone want to do that
> at a later point.
>
> As such, add a common device tree for all matisse devices by Samsung
> based on the matissewifi dts. Support for matisselte will be introduced
> in a later patch in this series and will use the common dtsi as well.
>
> Signed-off-by: Stefan Hansson
> ---
> .../qcom-apq8026-samsung-matisse-wifi.dts | 595 +++---
> ... qcom-msm8226-samsung-matisse-common.dtsi} | 66 --
> 2 files changed, 76 insertions(+), 585 deletions(-)
> rewrite arch/arm/boot/dts/qcom/qcom-apq8026-samsung-matisse-wifi.dts (85%)
> copy arch/arm/boot/dts/qcom/{qcom-apq8026-samsung-matisse-wifi.dts =>
> qcom-msm8226-samsung-matisse-common.dtsi} (86%)
Thanks. For me this diff is much more readable - I clearly see what was
removed from final DTSI file thus what I should expect in DTS file.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Re: [PATCH v4 4/4] ARM: dts: qcom: samsung-matisse-common: Add UART
On 26/10/2023 15:24, Stefan Hansson wrote: > This was not enabled in the matisse-wifi tree. Without this, it is not > possible to use the USB port for serial debugging via a "Carkit debug > cable". > > Signed-off-by: Stefan Hansson Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] wifi: ath11k: Defer on rproc_get failure
Luca Weiss writes: > If we already have gotten the rproc_handle (meaning the "qcom,rproc" > property is defined in the devicetree), it's a valid state that the > remoteproc module hasn't probed yet so we should defer probing instead > of just failing to probe. > > This resolves a race condition when the ath11k driver probes and fails > before the wpss remoteproc driver has probed, like the following: > > [6.232360] ath11k 17a10040.wifi: failed to get rproc > [6.232366] ath11k 17a10040.wifi: failed to get rproc: -22 > [6.232478] ath11k: probe of 17a10040.wifi failed with error -22 >... > [6.252415] remoteproc remoteproc2: 8a0.remoteproc is available > [6.252776] remoteproc remoteproc2: powering up 8a0.remoteproc > [6.252781] remoteproc remoteproc2: Booting fw image > qcom/qcm6490/fairphone5/wpss.mdt, size 7188 > > So, defer the probe if we hit that so we can retry later once the wpss > remoteproc is available. > > Signed-off-by: Luca Weiss Did you test this on a real device? If yes, what ath11k hardware and firmware did you use? We use Tested-on tag to document that: https://wireless.wiki.kernel.org/en/users/drivers/ath11k/submittingpatches#tested-on_tag I can add that in the pending branch if you provide the info. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] tracing/kprobes: Fix the description of variable length arguments
On 10/27/2023 9:43 AM, Yujie Liu wrote:
Fix the following kernel-doc warnings:
kernel/trace/trace_kprobe.c:1029: warning: Excess function parameter 'args'
description in '__kprobe_event_gen_cmd_start'
kernel/trace/trace_kprobe.c:1097: warning: Excess function parameter 'args'
description in '__kprobe_event_add_fields'
Refer to the usage of variable length arguments elsewhere in the kernel
code, "@..." is the proper way to express it in the description.
Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation functions")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202310190437.pai6lyjf-...@intel.com/
Signed-off-by: Yujie Liu
Not related to this patch, but I see order of the argument as well is
not proper in the document of the __kprobe_event_gen_cmd_start(),
if you can fix that too.
LGTM, Thanks for this.
Reviewed-by: Mukesh Ojha
-Mukesh
---
kernel/trace/trace_kprobe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index a8fef6ab0872..95c5b0668cb7 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1007,7 +1007,7 @@ EXPORT_SYMBOL_GPL(kprobe_event_cmd_init);
* @name: The name of the kprobe event
* @loc: The location of the kprobe event
* @kretprobe: Is this a return probe?
- * @args: Variable number of arg (pairs), one pair for each field
+ * @...: Variable number of arg (pairs), one pair for each field
*
* NOTE: Users normally won't want to call this function directly, but
* rather use the kprobe_event_gen_cmd_start() wrapper, which automatically
@@ -1080,7 +1080,7 @@ EXPORT_SYMBOL_GPL(__kprobe_event_gen_cmd_start);
/**
* __kprobe_event_add_fields - Add probe fields to a kprobe command from arg
list
* @cmd: A pointer to the dynevent_cmd struct representing the new event
- * @args: Variable number of arg (pairs), one pair for each field
+ * @...: Variable number of arg (pairs), one pair for each field
*
* NOTE: Users normally won't want to call this function directly, but
* rather use the kprobe_event_add_fields() wrapper, which
Re: [PATCH] wifi: ath11k: Defer on rproc_get failure
On Fri Oct 27, 2023 at 10:25 AM CEST, Kalle Valo wrote:
> Luca Weiss writes:
>
> > If we already have gotten the rproc_handle (meaning the "qcom,rproc"
> > property is defined in the devicetree), it's a valid state that the
> > remoteproc module hasn't probed yet so we should defer probing instead
> > of just failing to probe.
> >
> > This resolves a race condition when the ath11k driver probes and fails
> > before the wpss remoteproc driver has probed, like the following:
> >
> > [6.232360] ath11k 17a10040.wifi: failed to get rproc
> > [6.232366] ath11k 17a10040.wifi: failed to get rproc: -22
> > [6.232478] ath11k: probe of 17a10040.wifi failed with error -22
> >...
> > [6.252415] remoteproc remoteproc2: 8a0.remoteproc is available
> > [6.252776] remoteproc remoteproc2: powering up 8a0.remoteproc
> > [6.252781] remoteproc remoteproc2: Booting fw image
> > qcom/qcm6490/fairphone5/wpss.mdt, size 7188
> >
> > So, defer the probe if we hit that so we can retry later once the wpss
> > remoteproc is available.
> >
> > Signed-off-by: Luca Weiss
>
> Did you test this on a real device? If yes, what ath11k hardware and firmware
> did you use? We use Tested-on tag to document that:
>
> https://wireless.wiki.kernel.org/en/users/drivers/ath11k/submittingpatches#tested-on_tag
Hi,
Yes I tested this on qcm6490-fairphone-fp5 including some extra patches
for wpss-pas remoteproc support (nothing special, just adding it to the
existing PAS driver) and wifi enablement in dts.
I built this line from info from the dmesg, hope it's okay:
Tested-on: wcn6750 hw1.0 AHB WLAN.MSL.1.0.1-01264-QCAMSLSWPLZ-1.37886.3
And thinking about it, a Fixes tag would also be appropriate for this
patch.
The code was moved to a different file in commit ba929d6fe31a ("ath11k:
Remove rproc references from common core layer") but I think this tag
should be correct.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
>
> I can add that in the pending branch if you provide the info.
Thanks!
Regards
Luca
Re: [PATCH RFC 00/37] Add support for arm64 MTE dynamic tag storage reuse
On Wed, Oct 25, 2023 at 05:52:58PM +0900, Hyesoo Yu wrote: > If we only avoid using ALLOC_CMA for __GFP_TAGGED, would we still be able to > use > the next iteration even if the hardware does not support "tag of tag" ? It depends on how the next iteration looks like. The plan was not to support this so that we avoid another complication where a non-tagged page is mprotect'ed to become tagged and it would need to be migrated out of the CMA range. Not sure how much code it would save. > I am not sure every vendor will support tag of tag, since there is no > information > related to that feature, like in the Google spec document. If you are aware of any vendors not supporting this, please direct them to the Arm support team, it would be very useful information for us. Thanks. -- Catalin
Re: [PATCH v5] module: Add CONFIG_MODULE_DISABLE_INIT_FREE option
Hi Joey,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Joey-Jiao/module-Add-CONFIG_MODULE_DISABLE_INIT_FREE-option/20231017-115509
base: https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git
modules-next
patch link:
https://lore.kernel.org/r/20231013062711.28852-1-quic_jiangenj%40quicinc.com
patch subject: [PATCH v5] module: Add CONFIG_MODULE_DISABLE_INIT_FREE option
config: x86_64-randconfig-161-20231026
(https://download.01.org/0day-ci/archive/20231027/202310271751.28pkvu4k-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-12) 11.3.0
reproduce:
(https://download.01.org/0day-ci/archive/20231027/202310271751.28pkvu4k-...@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
| Reported-by: Dan Carpenter
| Closes: https://lore.kernel.org/r/202310271751.28pkvu4k-...@intel.com/
smatch warnings:
kernel/module/main.c:2608 do_init_module() warn: possible memory leak of
'freeinit'
vim +/freeinit +2608 kernel/module/main.c
c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2517
c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2518
freeinit = kmalloc(sizeof(*freeinit), GFP_KERNEL);
c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2519 if
(!freeinit) {
c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2520
ret = -ENOMEM;
c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2521
goto fail;
c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2522 }
ac3b4328392344 kernel/module/main.c Song Liu 2023-02-06 2523
freeinit->init_text = mod->mem[MOD_INIT_TEXT].base;
ac3b4328392344 kernel/module/main.c Song Liu 2023-02-06 2524
freeinit->init_data = mod->mem[MOD_INIT_DATA].base;
ac3b4328392344 kernel/module/main.c Song Liu 2023-02-06 2525
freeinit->init_rodata = mod->mem[MOD_INIT_RODATA].base;
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2526
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2527
do_mod_ctors(mod);
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2528 /*
Start the module */
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2529 if
(mod->init != NULL)
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2530
ret = do_one_initcall(mod->init);
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2531 if (ret
< 0) {
c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2532
goto fail_free_freeinit;
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2533 }
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2534 if (ret
> 0) {
bddb12b32f90c5 kernel/module.c Andrew Morton2013-11-12 2535
pr_warn("%s: '%s'->init suspiciously returned %d, it should "
bddb12b32f90c5 kernel/module.c Andrew Morton2013-11-12 2536
"follow 0/-E convention\n"
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2537
"%s: loading module anyway...\n",
bddb12b32f90c5 kernel/module.c Andrew Morton2013-11-12 2538
__func__, mod->name, ret, __func__);
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2539
dump_stack();
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2540 }
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2541
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2542 /* Now
it's a first class citizen! */
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2543
mod->state = MODULE_STATE_LIVE;
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2544
blocking_notifier_call_chain(&module_notify_list,
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2545
MODULE_STATE_LIVE, mod);
34e1169d996ab1 kernel/module.c Kees Cook2012-10-16 2546
38dc717e97153e kernel/module.c Jessica Yu 2020-11-27 2547 /*
Delay uevent until module has finished its init routine */
38dc717e97153e kernel/module.c Jessica Yu 2020-11-27 2548
kobject_uevent(&mod->mkobj.kobj, KOBJ_ADD);
38dc717e97153e kernel/module.c Jessica Yu 2020-11-27 2549
774a1221e862b3 kernel/module.c Tejun Heo2013-01-15 2550 /*
774a1221e862b3 kernel/module.c Tejun Heo2013-01-15 2551* We
need to finish all async code before the module init sequence
67d6212afda218 kernel/module.c Igor Pylypiv 2022-01-27 2552* is
do
Re: [PATCH v5] module: Add CONFIG_MODULE_DISABLE_INIT_FREE option
On Fri, Oct 27, 2023 at 03:00:00PM +0300, Dan Carpenter wrote: > 607c543f939d8c kernel/module.c Andrii Nakryiko 2020-11-20 2579 #ifdef > CONFIG_DEBUG_INFO_BTF_MODULES > 607c543f939d8c kernel/module.c Andrii Nakryiko 2020-11-20 2580 > /* .BTF is not SHF_ALLOC and will get removed, so sanitize pointer */ > 607c543f939d8c kernel/module.c Andrii Nakryiko 2020-11-20 2581 > mod->btf_data = NULL; > 607c543f939d8c kernel/module.c Andrii Nakryiko 2020-11-20 2582 #endif > c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2583 > /* > c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2584 > * We want to free module_init, but be aware that kallsyms may be > 0be964be0d4508 kernel/module.c Peter Zijlstra 2015-05-27 2585 > * walking this with preempt disabled. In all the failure paths, we > cb2f55369d3a9e kernel/module.c Paul E. McKenney 2018-11-06 2586 > * call synchronize_rcu(), but we don't want to slow down the success > 1a7b7d9220819a kernel/module.c Rick Edgecombe 2019-04-25 2587 > * path. module_memfree() cannot be called in an interrupt, so do the > 1a7b7d9220819a kernel/module.c Rick Edgecombe 2019-04-25 2588 > * work and call synchronize_rcu() in a work queue. > 1a7b7d9220819a kernel/module.c Rick Edgecombe 2019-04-25 2589 > * > ae646f0b9ca135 kernel/module.c Jeffrey Hugo 2018-05-11 2590 > * Note that module_alloc() on most architectures creates W+X page > ae646f0b9ca135 kernel/module.c Jeffrey Hugo 2018-05-11 2591 > * mappings which won't be cleaned up until do_free_init() runs. Any > ae646f0b9ca135 kernel/module.c Jeffrey Hugo 2018-05-11 2592 > * code such as mark_rodata_ro() which depends on those mappings to > ae646f0b9ca135 kernel/module.c Jeffrey Hugo 2018-05-11 2593 > * be cleaned up needs to sync with the queued work - ie > cb2f55369d3a9e kernel/module.c Paul E. McKenney 2018-11-06 2594 > * rcu_barrier() > c749637909eea5 kernel/module.c Rusty Russell2015-01-20 2595 > */ > 36022a47582048 kernel/module/main.c Joey Jiao2023-10-13 2596 > if (!IS_ENABLED(CONFIG_MODULE_DISABLE_INIT_FREE) && > 36022a47582048 kernel/module/main.c Joey Jiao2023-10-13 2597 > llist_add(&freeinit->node, &init_free_list)) > > Let's not allocate freeinit if CONFIG_MODULE_DISABLE_INIT_FREE is not > enabled. Wait. It's the other way around actually. freeinit isn't used if CONFIG_MODULE_DISABLE_INIT_FREE is enabled. regards, dan carpenter
Re: [PATCH] tracing/kprobes: Fix the description of variable length arguments
On Fri, 27 Oct 2023 14:10:44 +0530
Mukesh Ojha wrote:
>
>
> On 10/27/2023 9:43 AM, Yujie Liu wrote:
> > Fix the following kernel-doc warnings:
> >
> > kernel/trace/trace_kprobe.c:1029: warning: Excess function parameter 'args'
> > description in '__kprobe_event_gen_cmd_start'
> > kernel/trace/trace_kprobe.c:1097: warning: Excess function parameter 'args'
> > description in '__kprobe_event_add_fields'
> >
> > Refer to the usage of variable length arguments elsewhere in the kernel
> > code, "@..." is the proper way to express it in the description.
> >
> > Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation
> > functions")
> > Reported-by: kernel test robot
> > Closes:
> > https://lore.kernel.org/oe-kbuild-all/202310190437.pai6lyjf-...@intel.com/
> > Signed-off-by: Yujie Liu
>
> Not related to this patch, but I see order of the argument as well is
> not proper in the document of the __kprobe_event_gen_cmd_start(),
> if you can fix that too.
>
> LGTM, Thanks for this.
> Reviewed-by: Mukesh Ojha
Thanks! let me pick this!
>
> -Mukesh
>
> > ---
> > kernel/trace/trace_kprobe.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> > index a8fef6ab0872..95c5b0668cb7 100644
> > --- a/kernel/trace/trace_kprobe.c
> > +++ b/kernel/trace/trace_kprobe.c
> > @@ -1007,7 +1007,7 @@ EXPORT_SYMBOL_GPL(kprobe_event_cmd_init);
> >* @name: The name of the kprobe event
> >* @loc: The location of the kprobe event
> >* @kretprobe: Is this a return probe?
> > - * @args: Variable number of arg (pairs), one pair for each field
> > + * @...: Variable number of arg (pairs), one pair for each field
> >*
> >* NOTE: Users normally won't want to call this function directly, but
> >* rather use the kprobe_event_gen_cmd_start() wrapper, which
> > automatically
> > @@ -1080,7 +1080,7 @@ EXPORT_SYMBOL_GPL(__kprobe_event_gen_cmd_start);
> > /**
> >* __kprobe_event_add_fields - Add probe fields to a kprobe command from
> > arg list
> >* @cmd: A pointer to the dynevent_cmd struct representing the new event
> > - * @args: Variable number of arg (pairs), one pair for each field
> > + * @...: Variable number of arg (pairs), one pair for each field
> >*
> >* NOTE: Users normally won't want to call this function directly, but
> >* rather use the kprobe_event_add_fields() wrapper, which
--
Masami Hiramatsu (Google)
[PATCH 0/9] Remoteprocs (ADSP, CDSP, WPSS) for SC7280
This series adds support for the ADSP, CDSP and WPSS remoteprocs found on SC7280. And finally enable them and WiFi on the QCM6490-based Fairphone 5 smartphone. The first two patches are fixes for the MPSS to fix some dt validation issues. They're included in this series to avoid conflicts with the later patches and keep it simpler. Please note, that the ChromeOS-based devices using SC7280 need different driver and dts support, similar to how there's already qcom,sc7280-mpss-pas for "standard" firmware and there's qcom,sc7280-mss-pil for ChromeOS firmware. I'm aware of the series also adding SC7280 ADSP support with the last revision sent in June this year. https://lore.kernel.org/linux-arm-msm/20230616103534.4031331-1-quic_m...@quicinc.com/ However there's some differences since that series added the "pil" variant for ChromeOS, not "pas" for standard firmware. Also it seems on ChromeOS devices gpr+q6apm+q6prm is used. On my device it appears to be instead apr+q6afe+q6asm+q6adm but I don't add either in this series to keep it a bit simpler, and I couldn't test much of that yet. Signed-off-by: Luca Weiss --- Luca Weiss (9): dt-bindings: remoteproc: qcom: sc7180-pas: Fix SC7280 MPSS PD-names arm64: dts: qcom: sc7280: Remove unused second MPSS reg dt-bindings: remoteproc: qcom: sc7180-pas: Add SC7280 compatibles remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS arm64: dts: qcom: sc7280: Use WPSS PAS instead of PIL arm64: dts: qcom: sc7280: Add ADSP node arm64: dts: qcom: sc7280: Add CDSP node arm64: dts: qcom: qcm6490-fairphone-fp5: Enable various remoteprocs arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi .../bindings/remoteproc/qcom,sc7180-pas.yaml | 21 ++ arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 24 +++ arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 24 ++- .../boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi| 2 + arch/arm64/boot/dts/qcom/sc7280.dtsi | 225 +++-- drivers/remoteproc/qcom_q6v5_pas.c | 19 ++ 6 files changed, 300 insertions(+), 15 deletions(-) --- base-commit: 6a0dad42244c987e3c12bfae728199e360acf079 change-id: 20231027-sc7280-remoteprocs-048208cc1e13 Best regards, -- Luca Weiss
[PATCH 1/9] dt-bindings: remoteproc: qcom: sc7180-pas: Fix SC7280 MPSS PD-names
The power domains for MPSS on SC7280 are actually named CX and MSS, and
not CX and MX. Adjust the name which also aligns the bindings with the
dts and fixes validation.
Fixes: 8bb92d6fd0b3 ("dt-bindings: remoteproc: qcom,sc7180-pas: split into
separate file")
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
index f10f329677d8..6f0bd6fa5d26 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml
@@ -114,11 +114,11 @@ allOf:
power-domains:
items:
- description: CX power domain
-- description: MX power domain
+- description: MSS power domain
power-domain-names:
items:
- const: cx
-- const: mx
+- const: mss
unevaluatedProperties: false
--
2.42.0
[PATCH 4/9] remoteproc: qcom_q6v5_pas: Add SC7280 ADSP, CDSP & WPSS
Add support for the ADSP, CDSP and WPSS remoteprocs found on the SC7280
SoC using the q6v5-pas driver.
This driver can be used on regular LA ("Linux Android") based releases,
however the SC7280 ChromeOS devices need different driver support due to
firmware differences.
Signed-off-by: Luca Weiss
---
drivers/remoteproc/qcom_q6v5_pas.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index 913a5d2068e8..a9dd58608052 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -1165,6 +1165,22 @@ static const struct adsp_data sm8550_mpss_resource = {
.region_assign_idx = 2,
};
+static const struct adsp_data sc7280_wpss_resource = {
+ .crash_reason_smem = 626,
+ .firmware_name = "wpss.mdt",
+ .pas_id = 6,
+ .auto_boot = true,
+ .proxy_pd_names = (char*[]){
+ "cx",
+ "mx",
+ NULL
+ },
+ .load_state = "wpss",
+ .ssr_name = "wpss",
+ .sysmon_name = "wpss",
+ .ssctl_id = 0x19,
+};
+
static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,msm8226-adsp-pil", .data = &adsp_resource_init},
{ .compatible = "qcom,msm8953-adsp-pil", .data =
&msm8996_adsp_resource},
@@ -1178,7 +1194,10 @@ static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,qcs404-wcss-pas", .data = &wcss_resource_init },
{ .compatible = "qcom,sc7180-adsp-pas", .data = &sm8250_adsp_resource},
{ .compatible = "qcom,sc7180-mpss-pas", .data = &mpss_resource_init},
+ { .compatible = "qcom,sc7280-adsp-pas", .data = &sm8350_adsp_resource},
+ { .compatible = "qcom,sc7280-cdsp-pas", .data = &sm6350_cdsp_resource},
{ .compatible = "qcom,sc7280-mpss-pas", .data = &mpss_resource_init},
+ { .compatible = "qcom,sc7280-wpss-pas", .data = &sc7280_wpss_resource},
{ .compatible = "qcom,sc8180x-adsp-pas", .data = &sm8150_adsp_resource},
{ .compatible = "qcom,sc8180x-cdsp-pas", .data = &sm8150_cdsp_resource},
{ .compatible = "qcom,sc8180x-mpss-pas", .data =
&sc8180x_mpss_resource},
--
2.42.0
[PATCH 5/9] arm64: dts: qcom: sc7280: Use WPSS PAS instead of PIL
The wpss-pil driver wants to manage too many resources that cannot be
touched with standard Qualcomm firmware.
Use the compatible from the PAS driver and move the ChromeOS-specific
bits to sc7280-chrome-common.dtsi.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 19 ++-
arch/arm64/boot/dts/qcom/sc7280.dtsi | 15 +++
2 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
index cd491e4d..eb55616e0892 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
@@ -95,8 +95,25 @@ spi_flash: flash@0 {
};
&remoteproc_wpss {
- status = "okay";
+ compatible = "qcom,sc7280-wpss-pil";
+ clocks = <&gcc GCC_WPSS_AHB_BDG_MST_CLK>,
+<&gcc GCC_WPSS_AHB_CLK>,
+<&gcc GCC_WPSS_RSCP_CLK>,
+<&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "ahb_bdg",
+ "ahb",
+ "rscp",
+ "xo";
+
+ resets = <&aoss_reset AOSS_CC_WCSS_RESTART>,
+<&pdc_reset PDC_WPSS_SYNC_RESET>;
+ reset-names = "restart", "pdc_sync";
+
+ qcom,halt-regs = <&tcsr_1 0x17000>;
+
firmware-name = "ath11k/WCN6750/hw1.0/wpss.mdt";
+
+ status = "okay";
};
&scm {
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 0d9cc44066ce..23bb6c41fca3 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3579,7 +3579,7 @@ qspi: spi@88dc000 {
};
remoteproc_wpss: remoteproc@8a0 {
- compatible = "qcom,sc7280-wpss-pil";
+ compatible = "qcom,sc7280-wpss-pas";
reg = <0 0x08a0 0 0x1>;
interrupts-extended = <&intc GIC_SPI 587
IRQ_TYPE_EDGE_RISING>,
@@ -3591,12 +3591,8 @@ remoteproc_wpss: remoteproc@8a0 {
interrupt-names = "wdog", "fatal", "ready", "handover",
"stop-ack", "shutdown-ack";
- clocks = <&gcc GCC_WPSS_AHB_BDG_MST_CLK>,
-<&gcc GCC_WPSS_AHB_CLK>,
-<&gcc GCC_WPSS_RSCP_CLK>,
-<&rpmhcc RPMH_CXO_CLK>;
- clock-names = "ahb_bdg", "ahb",
- "rscp", "xo";
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
power-domains = <&rpmhpd SC7280_CX>,
<&rpmhpd SC7280_MX>;
@@ -3609,11 +3605,6 @@ remoteproc_wpss: remoteproc@8a0 {
qcom,smem-states = <&wpss_smp2p_out 0>;
qcom,smem-state-names = "stop";
- resets = <&aoss_reset AOSS_CC_WCSS_RESTART>,
-<&pdc_reset PDC_WPSS_SYNC_RESET>;
- reset-names = "restart", "pdc_sync";
-
- qcom,halt-regs = <&tcsr_1 0x17000>;
status = "disabled";
--
2.42.0
[PATCH 6/9] arm64: dts: qcom: sc7280: Add ADSP node
Add the node for the ADSP found on the SC7280 SoC, using standard
Qualcomm firmware.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 69
1 file changed, 69 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 23bb6c41fca3..cc153f4e6979 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3578,6 +3578,75 @@ qspi: spi@88dc000 {
status = "disabled";
};
+ remoteproc_adsp: remoteproc@370 {
+ compatible = "qcom,sc7280-adsp-pas";
+ reg = <0 0x0370 0 0x100>;
+
+ interrupts-extended = <&pdc 6 IRQ_TYPE_LEVEL_HIGH>,
+ <&adsp_smp2p_in 0
IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1
IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2
IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3
IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 7
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ power-domains = <&rpmhpd SC7280_LCX>,
+ <&rpmhpd SC7280_LMX>;
+ power-domain-names = "lcx", "lmx";
+
+ memory-region = <&adsp_mem>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_LPASS
+
IPCC_MPROC_SIGNAL_GLINK_QMP
+
IRQ_TYPE_EDGE_RISING>;
+
+ mboxes = <&ipcc IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "lpass";
+ qcom,remote-pid = <2>;
+
+ fastrpc {
+ compatible = "qcom,fastrpc";
+ qcom,glink-channels =
"fastrpcglink-apps-dsp";
+ label = "adsp";
+ qcom,non-secure-domain;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compute-cb@3 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <3>;
+ iommus = <&apps_smmu 0x1803
0x0>;
+ };
+
+ compute-cb@4 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <4>;
+ iommus = <&apps_smmu 0x1804
0x0>;
+ };
+
+ compute-cb@5 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <&apps_smmu 0x1805
0x0>;
+ };
+ };
+ };
+ };
+
remoteproc_wpss: remoteproc@8a0 {
compatible = "qcom,sc7280-wpss-pas";
reg = <0 0x08a0 0 0x1>;
--
2.42.0
[PATCH 8/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable various remoteprocs
Enable the ADSP, CDSP, MPSS and WPSS that are found on the SoC.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index cc092735ce17..d65eef30091b 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -490,6 +490,26 @@ &qupv3_id_1 {
status = "okay";
};
+&remoteproc_adsp {
+ firmware-name = "qcom/qcm6490/fairphone5/adsp.mdt";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcm6490/fairphone5/cdsp.mdt";
+ status = "okay";
+};
+
+&remoteproc_mpss {
+ firmware-name = "qcom/qcm6490/fairphone5/modem.mdt";
+ status = "okay";
+};
+
+&remoteproc_wpss {
+ firmware-name = "qcom/qcm6490/fairphone5/wpss.mdt";
+ status = "okay";
+};
+
&sdc2_clk {
drive-strength = <16>;
bias-disable;
--
2.42.0
[PATCH 9/9] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable WiFi
Now that the WPSS remoteproc is enabled, enable wifi so we can use it.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index d65eef30091b..e7e20f73cbe6 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -713,3 +713,7 @@ &venus {
firmware-name = "qcom/qcm6490/fairphone5/venus.mbn";
status = "okay";
};
+
+&wifi {
+ status = "okay";
+};
--
2.42.0
[PATCH 3/9] dt-bindings: remoteproc: qcom: sc7180-pas: Add SC7280 compatibles
Add the compatibles and constraints for the ADSP, CDSP and WPSS found on the SC7280 SoC. Signed-off-by: Luca Weiss --- .../bindings/remoteproc/qcom,sc7180-pas.yaml| 21 + 1 file changed, 21 insertions(+) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml index 6f0bd6fa5d26..c054b84fdcd5 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-pas.yaml @@ -18,7 +18,10 @@ properties: enum: - qcom,sc7180-adsp-pas - qcom,sc7180-mpss-pas + - qcom,sc7280-adsp-pas + - qcom,sc7280-cdsp-pas - qcom,sc7280-mpss-pas + - qcom,sc7280-wpss-pas reg: maxItems: 1 @@ -75,6 +78,7 @@ allOf: compatible: enum: - qcom,sc7180-adsp-pas +- qcom,sc7280-adsp-pas then: properties: power-domains: @@ -120,6 +124,23 @@ allOf: - const: cx - const: mss + - if: + properties: +compatible: + enum: +- qcom,sc7280-cdsp-pas +- qcom,sc7280-wpss-pas +then: + properties: +power-domains: + items: +- description: CX power domain +- description: MX power domain +power-domain-names: + items: +- const: cx +- const: mx + unevaluatedProperties: false examples: -- 2.42.0
[PATCH 7/9] arm64: dts: qcom: sc7280: Add CDSP node
Add the node for the ADSP found on the SC7280 SoC, using standard
Qualcomm firmware.
The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4
yupik.dtsi since the other areas also seem to match that file there,
though I cannot be sure there.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 +
arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +
2 files changed, 143 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
index eb55616e0892..6e5a9d4c1fda 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
@@ -29,6 +29,11 @@ adsp_mem: memory@8670 {
no-map;
};
+ cdsp_mem: memory@88f0 {
+ reg = <0x0 0x88f0 0x0 0x1e0>;
+ no-map;
+ };
+
camera_mem: memory@8ad0 {
reg = <0x0 0x8ad0 0x0 0x50>;
no-map;
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index cc153f4e6979..e15646289bf7 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3815,6 +3815,144 @@ nsp_noc: interconnect@a0c {
qcom,bcm-voters = <&apps_bcm_voter>;
};
+ remoteproc_cdsp: remoteproc@a30 {
+ compatible = "qcom,sc7280-cdsp-pas";
+ reg = <0 0x0a30 0 0x1>;
+
+ interrupts-extended = <&intc GIC_SPI 578
IRQ_TYPE_LEVEL_HIGH>,
+ <&cdsp_smp2p_in 0
IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 1
IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 2
IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 3
IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 7
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>;
+ clock-names = "xo";
+
+ power-domains = <&rpmhpd SC7280_CX>,
+ <&rpmhpd SC7280_MX>;
+ power-domain-names = "cx", "mx";
+
+ interconnects = <&nsp_noc MASTER_CDSP_PROC 0 &mc_virt
SLAVE_EBI1 0>;
+
+ memory-region = <&cdsp_mem>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&cdsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts-extended = <&ipcc IPCC_CLIENT_CDSP
+
IPCC_MPROC_SIGNAL_GLINK_QMP
+
IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_CDSP
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "cdsp";
+ qcom,remote-pid = <5>;
+
+ fastrpc {
+ compatible = "qcom,fastrpc";
+ qcom,glink-channels =
"fastrpcglink-apps-dsp";
+ label = "cdsp";
+ qcom,non-secure-domain;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ compute-cb@1 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <1>;
+ iommus = <&apps_smmu 0x11a1
0x0420>,
+<&apps_smmu 0x1181
0x0420>;
+ };
+
+ compute-cb@2 {
+ compatible =
"qcom,fastrpc-compute-cb";
+ reg = <2>;
+ iommus = <&apps_smmu 0x11a2
0x0420>,
+<&apps_smmu 0x1182
0x0420>;
+ };
+
+ compute-cb@3 {
+ compatible =
"qcom,fastrpc-compute-cb";
+
[PATCH 2/9] arm64: dts: qcom: sc7280: Remove unused second MPSS reg
The bindings for sc7280-mpss-pas neither expects a second reg nor a
reg-names property, which is only required by the sc7280-mss-pil
bindings.
Move it to sc7280-herobrine-lte-sku.dtsi, the only place where that
other compatible is used.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi | 2 ++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi
index 95505549adcc..203274c10532 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-lte-sku.dtsi
@@ -33,6 +33,8 @@ &ipa {
&remoteproc_mpss {
compatible = "qcom,sc7280-mss-pil";
+ reg = <0 0x0408 0 0x1>, <0 0x0418 0 0x48>;
+ reg-names = "qdsp6", "rmb";
clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
<&gcc GCC_MSS_OFFLINE_AXI_CLK>,
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 5db468d1a06e..0d9cc44066ce 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2848,8 +2848,7 @@ adreno_smmu: iommu@3da {
remoteproc_mpss: remoteproc@408 {
compatible = "qcom,sc7280-mpss-pas";
- reg = <0 0x0408 0 0x1>, <0 0x0418 0 0x48>;
- reg-names = "qdsp6", "rmb";
+ reg = <0 0x0408 0 0x1>;
interrupts-extended = <&intc GIC_SPI 264
IRQ_TYPE_LEVEL_HIGH>,
<&modem_smp2p_in 0
IRQ_TYPE_EDGE_RISING>,
--
2.42.0
Re: [PATCH v2] bus: mhi: host: Add tracing support
On 10/23/2023 1:11 AM, Krishna Chaitanya Chundru wrote:
On 10/20/2023 8:33 PM, Jeffrey Hugo wrote:
On 10/13/2023 3:52 AM, Krishna chaitanya chundru wrote:
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
This feels redundant to me. A few lines ago we included internal.h,
and internal.h includes trace/events/mhi_host.h
As Steve mentioned, this is mandatory step for creating trace points &
trace events.
I understand this creates the trace points, and that needs to be done in
C code. It dtill seems redundant because we are including the header
twice (and I am aware trace has the special multi-header read
functionality for this).
The duplicate include still feels weird, but I have not come up with a
better way to structure this.
+
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;
+}
This seems to be poorly named since we are using the iommu_base which
suggests we are converting to an IOVA.
Why do we need this though? This seems like it might be a security
issue, or at the very least, not preferred, and I'm struggling to
figure out what value this provides to you are I when looking at the log.
I will rename the function to reflect it is converting to IOVA.
We MHI TRE we write the IOVA address, to correlate between TRE events in
the MHI ring and event we are processing we want to log the IOVA address.
As we are logging only IOVA address which is provided in the devicetree
and not the original physical address we are not expecting any security
issues here.
Correct me if I was wrong.
The IOVA is not provided by DT, it is a runtime allocated value provided
by the IOMMU, if present. If not present, then it is a physical address.
Remember, x86 does not use devicetree.
While the IOVA (with an iommu) is not technically a physical address,
but is treated as such by the device. I can imagine an attacker doing
bad things if they get a hold of the value.
Still, you haven't indicated why this is useful.
+
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
Re: [PATCH 4/5] kbuild: unify vdso_install rules
On Mon, Oct 09, 2023 at 09:42:09PM +0900, Masahiro Yamada wrote: > Currently, there is no standard implementation for vdso_install, > leading to various issues: [...] > arch/arm64/Makefile| 9 ++ > arch/arm64/kernel/vdso/Makefile| 10 -- > arch/arm64/kernel/vdso32/Makefile | 10 -- For arm64: Acked-by: Catalin Marinas
Re: [PATCH 4/5] kbuild: unify vdso_install rules
On Mon, Oct 09, 2023 at 09:42:09PM +0900, Masahiro Yamada wrote: > arch/arm/Makefile | 7 +--- > arch/arm/vdso/Makefile | 25 -- Acked-by: Russell King (Oracle) Thanks! -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
