Received-SPF: pass (google.com: domain of linux-kernel+bounces-184480-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <a944418a-1699-44fa-bdfc-2e57129adea1@quicinc.com>
Date: Mon, 20 May 2024 21:08:51 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 5/7] dt-bindings: remoteproc: qcom,pas: Add hwlocks
To: Krzysztof Kozlowski <krzk@kernel.org>,
        Bjorn Andersson
	<andersson@kernel.org>,
        Baolin Wang <baolin.wang@linux.alibaba.com>,
        Peter
 Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>,
        Will Deacon
	<will@kernel.org>, Waiman Long <longman@redhat.com>,
        Boqun Feng
	<boqun.feng@gmail.com>, Jonathan Corbet <corbet@lwn.net>,
        Mathieu Poirier
	<mathieu.poirier@linaro.org>,
        Rob Herring <robh@kernel.org>,
        Krzysztof
 Kozlowski <krzk+dt@kernel.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>,
        Konrad Dybcio
	<konrad.dybcio@linaro.org>
CC: <linux-remoteproc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-doc@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
        <devicetree@vger.kernel.org>
References: <20240516-hwspinlock-bust-v1-0-47a90a859238@quicinc.com>
 <20240516-hwspinlock-bust-v1-5-47a90a859238@quicinc.com>
 <3521519f-34b8-472d-be37-f0e64bba24fc@kernel.org>
Content-Language: en-US
From: Chris Lew <quic_clew@quicinc.com>
In-Reply-To: <3521519f-34b8-472d-be37-f0e64bba24fc@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit


On 5/19/2024 10:36 AM, Krzysztof Kozlowski wrote:
> On 17/05/2024 00:58, Chris Lew wrote:
>> Add hwlocks property to describe the hwspinlock that remoteproc can try
>> to bust on behalf of the remoteproc's smem.
> 
> Sorry, as you wrote, the lock is part of smem, not here. Drivers do not
> crash, so if your crashes as you imply in the cover letter, then first
> fix the driver.
>

Hi Krzysztof,

Sorry for the confusion, I dont think I meant that the smem driver will 
ever crash. The referred to crash in the cover letter is a crash in the 
firmware running on the remoteproc. The remoteproc could crash for any 
unexpected reason, related or unrelated to smem, while holding the tcsr 
mutex. I want to ensure that all resources that a remoteproc might be 
using are released as part of remoteproc stop.

The SMEM driver manages the lock/unlock operations on the tcsr mutex 
from the Linux CPU's perspective. This case is for cleaning up from the 
remote side's perspective.

In this case it's the hwspinlock used to synchronize SMEM, but it's 
conceivable that firmware running on the remoteproc has additional locks 
that need to be busted in order for the system to continue executing 
until the firmware is reinitialized.

We did consider tying this to the SMEM instance, but the entitiy 
relating to firmware is the remoteproc instance.

> Best regards,
> Krzysztof
>