All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Ananthu C V <ananthu.cv@oss.qualcomm.com>
Cc: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org
Subject: Re: [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation
Date: Fri, 3 Jul 2026 16:47:44 +0200	[thread overview]
Message-ID: <c19a1f1d-2413-4b6a-811d-ad425b6cbca1@kernel.org> (raw)
In-Reply-To: <akfIu0V3XxQoV_Mw@hu-anancv-lv.qualcomm.com>

On 03/07/2026 16:35, Ananthu C V wrote:
> Hi Krzysztof,
> 
> On Fri, Jul 03, 2026 at 02:44:41PM +0200, Krzysztof Kozlowski wrote:
>> On 03/07/2026 14:31, Ananthu C V wrote:
>>> Most Qualcomm platforms feature Gunyah hypervisor, which typically
>>> handles Stage 2 IOMMU configuration. Additionally, SHM bridge setup
>>> is required to enable memory protection for both remoteproc metadata
>>> and its memory regions. When the aforementioned hypervisor is absent,
>>> the operating system must perform these configurations instead. We've
>>> been relying on the iommu property being present for this, but for
>>> remoteprocs that are already running like SoCCP the mappings are already
>>> in place, and any attempt to recreate them while active would lead to smmu
>>> faults and a non-functional remoteproc. Fix this by adding a needs_tzmem
>>> flag which ensures tzmem and SHM bridge setup is performed independent to
>>> the iommu property being present.
>>
>> Looks awfully like LLM written and considering obvious problem, this
>> feels vibe coded.
>>
>> According to current docs YOU SHOULD add vibe-coding tag to the commit
>> when doing that.
> 
> Part of the commit message is based on 5c720260e840, and the rest is all written
> and readjusted manually. Every single line of change in the code also is fully
> handwritten - well, typed - by me. I don't know where the feeling came from, but
> please be relieved to know that there has been no involvement of AI here.
> 
>>>  static const struct of_device_id qcom_pas_of_match[] = {
>>>  	{ .compatible = "qcom,eliza-adsp-pas", .data = &sm8550_adsp_resource },
>>> +	{ .compatible = "qcom,glymur-soccp-pas", .data = &glymur_soccp_resource },
>>
>> Please run scripts/checkpatch.pl on the patches and fix reported
>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>> patches and (probably) fix more warnings. Some warnings can be ignored,
>> especially from --strict run, but the code here looks like it needs a
>> fix. Feel free to get in touch if the warning is not clear.
> 
> I ran checkpatch well over twenty times before posting the series, and I did
> it a few more times after seeing your reply. I did not run into any problems,
> and as such I cannot understand the problem here.
> 
> I could not paste this into an external pastebin from my work pc due to policy
> reasons, so please forgive me for sharing this extended paste here:


There is no qcom,glymur-soccp-pas documented here. It was in separate
patchset which is already bringing confusion - the documentation goes
with the user. If you keep things separate, expect such comments and no
reviews.

Best regards,
Krzysztof

  reply	other threads:[~2026-07-03 14:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03 12:31 [PATCH v4 0/3] Add remoteproc PAS loader for SoCCP on Glymur DT Ananthu C V
2026-07-03 12:31 ` [PATCH v4 1/3] remoteproc: qcom: pas: add needs_tzmem flag to force shmbridge creation Ananthu C V
2026-07-03 12:42   ` sashiko-bot
2026-07-03 12:44   ` Krzysztof Kozlowski
2026-07-03 14:35     ` Ananthu C V
2026-07-03 14:47       ` Krzysztof Kozlowski [this message]
2026-07-05 22:26   ` Bjorn Andersson
2026-07-06  6:50     ` Ananthu C V
2026-07-03 12:31 ` [PATCH v4 2/3] arm64: dts: qcom: fix SoCCP memory mappings for Glymur Ananthu C V
2026-07-03 12:37   ` sashiko-bot
2026-07-03 14:39     ` Ananthu C V
2026-07-05 22:27   ` Bjorn Andersson
2026-07-07  8:46     ` Ananthu C V
2026-07-03 12:31 ` [PATCH v4 3/3] arm64: dts: qcom: add SoCCP DT node " Ananthu C V
2026-07-03 12:41   ` sashiko-bot
2026-07-03 14:42     ` Ananthu C V
2026-07-05 22:41   ` Bjorn Andersson
2026-07-06  6:52     ` Ananthu C V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c19a1f1d-2413-4b6a-811d-ad425b6cbca1@kernel.org \
    --to=krzk@kernel.org \
    --cc=ananthu.cv@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.