From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22B0F3DEAD2 for ; Tue, 9 Jun 2026 11:43:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781005407; cv=none; b=HoLgOaGZ3bG6oG+v7rprHQ2TnsQJyG07wSM4jjUzFZA6uluITjH8tPutIy3UycaOMfCCbIrVOXF/Y/ogN168pNN9fFGUY3SEcgVo8cWBY1ZmZHxW/tvV3UdwKnniwymhkOOqoO/IoNLeVWxt4gkFK+BoGxFSCntYaGS+WG7g3oc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781005407; c=relaxed/simple; bh=etwaOqfrv80LIP7Sx6oI0au3Ah0IMLiJ6WXRs3bOmiA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j+OTfi4PDO1qISG7yLljTwb4vGuRDT1ZUlricdMY6DzUTHiHCyCiiXGnv/ookqyVT7wRdtdY4U+hkEISVIgxoSLAvB4YKoqxtP1rMoEyESnZz0v2zaVIIL5AWVRxCxKZ9nXNi12fT6Dx6VfRzaDsgv6FAPK1ov9QN2jUwL9HoXQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=emJEdqc2; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="emJEdqc2" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-45eeea039ebso2838528f8f.1 for ; Tue, 09 Jun 2026 04:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1781005404; x=1781610204; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=LpMpBpNcZIgzsuu0bBQY/Gbp97K5pRk23WWL6Y8u5xg=; b=emJEdqc2FLqXlTxg+bu034XpgQ7GH0KbZX+MFVHqoQX7wkTvz+F4tmDHnqBfQGxP6x jBZ9R7AaCb5UKkwuRGynuVPW28WNrOCwW9YcbMWQV5bFigsitriWMADllsG8Ffsi4HUH vlYDcQhva7FOE7JgsbykrOIVWPeuemLIDJ/SU7OdTgIw9k0AdQFPjFYaItNEtCYd1hr8 5e1HG0nIbsipIq67DQ3NRMwVleznVpbDlvao2jKwsU3TwgcQP6sljZMX11ZSRNV7KZ/B w6eC+KAd8l3cnnKkr654Z2r9RzBrHw6j0967nQ2Ej/uk4TDRYEqEsigznA+uqB57kbUd /NeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781005404; x=1781610204; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LpMpBpNcZIgzsuu0bBQY/Gbp97K5pRk23WWL6Y8u5xg=; b=EWpuDZ3MYoNv0u4Bo+/uBu1scsJbOsprm0EX33x4/EH5Wifm//VN000qT8qPLWvomy Lh62OABvDtvrlKkCgJAUpGmdi1J0vS8ek4NrcAzHF1GRpbhXNPdz783w62r+oyZV/ywM TZMN/QPoWNISj26o/X/XtDzbME3SkdQMcMSm6e9rlpLcdc+dZJOQ2L3UXkuBjwIa4Gkq MG1lVqErynalStr9XQ+GCZemUWjl4HPT3T7nBkJs35IKkR9ZvqQj43xrg9oSGwAFnx98 gc1iQmlhSPOiYweU3OQvcxLZaoIFuEAPNDCd34mA0gotJO/EggAN9M+rePaNu1H2ZjHX kQyw== X-Forwarded-Encrypted: i=1; AFNElJ/T95r7lsNZeN9ZjJcC4xFIRfFPK72f8sEjdXtuoHMQdKlF925Qwe5rcfMJfnw+U1QunGwMTfGPABq660Y=@vger.kernel.org X-Gm-Message-State: AOJu0YyP8cK5b16oLL4SC4ObyIz6eb9RE6rxq/oAkk3viTJpv1Fh2Z6U 5z0bf1IRVx/N4dMgSItNUEb6JrIOqppC5TWRx2TWRPYLhrqZJwR/+e00kux3wraOes0= X-Gm-Gg: Acq92OEYNAHqH4eo9tbyw0w+ngU3hVZojIlxwxYz/lhBKCIURrDknSUR5fehtdARKzp cwyhdR3firzycslUeQEMLbQxgnoXYi2qNW5B6zw/LobKozBqft/WQ4O6BBEordMf4cMoc/uNcQ8 ZS/FIscfqbK4T34IrI0POAkXKInI0wuy6J4kgXr8dEYPlqO5aHkqQxMBnRzDTMJYxLx8QKXUqaO GsIcfe8FGbasLyR25uCHaCGyvYNRGOn+SYFC+eoiNL/xVrINhtnK60qbCamGlLwazHoy0FAwpuS yuhMolDQIsi11lNKUC2lE33fTHV1jLO0hzqeDl8qVqAz9Oj8Fjewa84FILXNvuLTwAf53kGOfvi EfaPBOyC9NaXSNSNzyHFfEaqvhh6n71uKEPLjpCE1oh2gEq51mGOZNDqyDrmpQIxIKaiMoxf37t PVtrBFIo94AL697xDxvZ/3MHFLA2NNP77zni8yz5wIf/n9EQ== X-Received: by 2002:a05:6000:2994:10b0:460:3233:f991 with SMTP id ffacd0b85a97d-4603233f9e2mr21994861f8f.40.1781005404400; Tue, 09 Jun 2026 04:43:24 -0700 (PDT) Received: from linaro.org ([2a02:2454:ff23:4410:59bf:7aa6:43c0:c58b]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2dcbe3sm57355924f8f.8.2026.06.09.04.43.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2026 04:43:23 -0700 (PDT) Date: Tue, 9 Jun 2026 13:43:17 +0200 From: Stephan Gerhold To: Mukesh Ojha Cc: Bjorn Andersson , Mathieu Poirier , Matthias Brugger , AngeloGioacchino Del Regno , linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH 2/3] remoteproc: abort subdev stop sequence on first failure Message-ID: References: <20260609102254.2671238-1-mukesh.ojha@oss.qualcomm.com> <20260609102254.2671238-3-mukesh.ojha@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260609102254.2671238-3-mukesh.ojha@oss.qualcomm.com> On Tue, Jun 09, 2026 at 03:52:52PM +0530, Mukesh Ojha wrote: > If a subdevice fails to stop, it indicates broken communication with the > DSP. Continuing to stop further subdevices against an unresponsive > remote processor could close rpmsg devices that could remove the memory > mapping from HLOS and in case if remote processor touches those memory > can result in SMMU fault. > > Change rproc_stop_subdevices() to return int and abort on the first > failing subdev. Propagate the error through rproc_stop() and > __rproc_detach() so callers are aware the teardown did not complete > cleanly. > > Signed-off-by: Mukesh Ojha But what would callers do about this? If you abort the teardown sequence half-way through you now have an inconsistent half-stopped state that neither a new call to stop() nor a new call to start() could recover from. That doesn't sound much better than the SMMU fault. Or am I missing something here? I would expect that we should either be able to tolerate the SMMU faults with the resets involved in the remoteproc stop/start sequence, or that DMA gets cancelled by the remoteproc stop sequence, before the buffers are unmapped. Perhaps the order of our stop sequence is just wrong? Can we unmap the buffers in the subdev unprepare() callback? Thanks, Stephan