On Sat, 28 Oct 2023 10:41:44 +0900
Masami Hiramatsu (Google) wrote:
> Hi,
>
> On Fri, 27 Oct 2023 16:31:26 -0700
> Andrii Nakryiko wrote:
>
> > Recent changes to count number of matching symbols when creating
> > a kprobe event failed to take into account kernel modules. As such, it
> >
Hi,
On Fri, 27 Oct 2023 16:31:26 -0700
Andrii Nakryiko wrote:
> Recent changes to count number of matching symbols when creating
> a kprobe event failed to take into account kernel modules. As such, it
> breaks kprobes on kernel module symbols, by assuming there is no match.
>
> Fix this my
On Fri, 27 Oct 2023 16:37:29 -0700
Song Liu wrote:
> On Fri, Oct 27, 2023 at 4:31 PM Andrii Nakryiko wrote:
> >
> > Recent changes to count number of matching symbols when creating
> > a kprobe event failed to take into account kernel modules. As such, it
> > breaks kprobes on kernel module
On Fri, Oct 27, 2023 at 4:31 PM Andrii Nakryiko wrote:
>
> Recent changes to count number of matching symbols when creating
> a kprobe event failed to take into account kernel modules. As such, it
> breaks kprobes on kernel module symbols, by assuming there is no match.
>
> Fix this my calling
Recent changes to count number of matching symbols when creating
a kprobe event failed to take into account kernel modules. As such, it
breaks kprobes on kernel module symbols, by assuming there is no match.
Fix this my calling module_kallsyms_on_each_symbol() in addition to
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
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 --
>
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
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
---
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
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
---
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
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
---
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
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
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
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
---
| 19 ++
6 files changed, 300 insertions(+), 15 deletions(-)
---
base-commit: 6a0dad42244c987e3c12bfae728199e360acf079
change-id: 20231027-sc7280-remoteprocs-048208cc1e13
Best regards,
--
Luca Weiss
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'
> >
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
/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
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
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
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
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
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
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
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.
>
>
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(-)
to get rproc\n");
- return -EINVAL;
+ ath11k_dbg(ab, ATH11K_DBG_AHB, "failed to get rproc,
deferring\n");
+ return -EPROBE_DEFER;
}
ab_ahb->tgt_rproc = prproc;
---
base-commit: 2ef7141596eed0b4b45ef18b3626f428a6b0a822
change-id: 2023102
30 matches
Mail list logo
