Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp231699ybg; Tue, 2 Jun 2020 22:34:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPROi8WvlNZQlsbYdCDCJ5s7ysGmd2+OOw4IDu76s5WJyYA9VQJSV3OdIe4o9ZHc0FISSI X-Received: by 2002:a17:906:805a:: with SMTP id x26mr21612695ejw.458.1591162471049; Tue, 02 Jun 2020 22:34:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591162471; cv=none; d=google.com; s=arc-20160816; b=qR5gTuq0tYo2DwfKV/h8+lGLXVvnEVIvER9wPeiB20il103bor8pOdHFijstkV4kio HoxsSz1aIY52emvChctO9at2KpPiSeDAZ0pXIAuoQ2pmfmZpHLNWAfPw8uoUjDEAzvi1 o7h8CmXkORLnuUznqvj8ISgOFc6/dxumwaQGXSzTtc9raSxrNO2+MI2ew1nD0pgh9vy9 BhjGG0mjh/F+kmLLfW+qc9l5OC74xrl1QjT6Lln+XAfujLqGflEF9wlIxha93nH7+106 jVKRsGBpEiMxDoUIjX1lHABmyYC4yTjbPfarexsMes274tHuAlhbt/ruWjzMWujQFZCD W8Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=zzTfxHouLE9jM7tdzGJeF4YIRqLBMDbYhT7bqTud5lA=; b=mwyE7U1kgMeZ79E3fG16AYAR6RK8V9RXf61ag6Xm04v/qWxXGeV9GnvWOpKZsc/O0z jfQXCSvMRKjD45pfhR5Ggw+vyI3+qgTO5DfZld1cdhrN9cQ1VkmHpJf+3GmVoGCCVURF mX1XLgqfMjq37M/f97yPgUuIoWnRgZoTmI8Kd024KdP8ieMP0t1T3p1U3W4XRoWbE5bW Eq0tOQ9TR7185ZgtV2teLaPOy0EabxLpECxubrPCbLYaCCzfdLy8/cVD1JTf0OcJyLKv n4tE+TPU31VoMfu/9ebHsdJ2jUBX/cJI67tRxzbApBGan7VClm6vFSvsD1+S/K7YPrfD 14hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=HjN+k7NA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id mc22si547349ejb.655.2020.06.02.22.34.07; Tue, 02 Jun 2020 22:34:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=HjN+k7NA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725867AbgFCFaB (ORCPT + 99 others); Wed, 3 Jun 2020 01:30:01 -0400 Received: from mail27.static.mailgun.info ([104.130.122.27]:34148 "EHLO mail27.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbgFCFaA (ORCPT ); Wed, 3 Jun 2020 01:30:00 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1591162199; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=zzTfxHouLE9jM7tdzGJeF4YIRqLBMDbYhT7bqTud5lA=; b=HjN+k7NAO6+naM1LLZP9DXtKT2uvWLnLxbbMExhc5GJo7OiXNIfnnDA1TvwPTmK+fTT0pkwz maFyoqPylMIRLfsBTLiVmoIf+VBYEcGGaT/jyK7sWRrQ7XgpUPh0TKT5fMh5f8FrI7bnccGQ GXpVZ7/UcXvggocVP7bcQOnyGts= X-Mailgun-Sending-Ip: 104.130.122.27 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n12.prod.us-west-2.postgun.com with SMTP id 5ed7354746d39fc0a2950d7c (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Wed, 03 Jun 2020 05:29:43 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id EA77CC433CB; Wed, 3 Jun 2020 05:29:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=2.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sibis) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5441DC433C6; Wed, 3 Jun 2020 05:29:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Jun 2020 10:59:42 +0530 From: Sibi Sankar To: Evan Green Cc: Bjorn Andersson , Andy Gross , linux-arm-msm , linux-remoteproc@vger.kernel.org, LKML , Ohad Ben Cohen , rohitkr@codeaurora.org, stable@vger.kernel.org, linux-kernel-owner@vger.kernel.org Subject: Re: [PATCH 1/2] remoteproc: qcom: q6v5: Update running state before requesting stop In-Reply-To: References: <20200602163257.26978-1-sibis@codeaurora.org> Message-ID: <6392c800b0be1cbabb8a241cf518ab4b@codeaurora.org> X-Sender: sibis@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Evan, Thanks for taking time to review the series. On 2020-06-02 23:14, Evan Green wrote: > On Tue, Jun 2, 2020 at 9:33 AM Sibi Sankar > wrote: >> >> Sometimes the stop triggers a watchdog rather than a stop-ack. Update >> the running state to false on requesting stop to skip the watchdog >> instead. >> >> Error Logs: >> $ echo stop > /sys/class/remoteproc/remoteproc0/state >> ipa 1e40000.ipa: received modem stopping event >> remoteproc-modem: watchdog received: sys_m_smsm_mpss.c:291:APPS force >> stop >> qcom-q6v5-mss 4080000.remoteproc-modem: port failed halt >> ipa 1e40000.ipa: received modem offline event >> remoteproc0: stopped remote processor 4080000.remoteproc-modem >> >> Fixes: 3b415c8fb263 ("remoteproc: q6v5: Extract common resource >> handling") >> Cc: stable@vger.kernel.org >> Signed-off-by: Sibi Sankar >> --- > > Are you sure you want to tolerate this behavior from MSS? This is a > graceful shutdown, modem shouldn't have a problem completing the > proper handshake. If they do, isn't that a bug on the modem side? The graceful shutdown is achieved though sysmon (enabled using CONFIG_QCOM_SYSMON). When sysmon is enabled we get a shutdown-ack when we try to stop the modem, post which request stop is a basically a nop. Request stop is done to force stop the modem during failure cases (like rmtfs is not running and so on) and we do want to mask the wdog that we get during this scenario ( The locking already prevents the servicing of the wdog during shutdown, the check just prevents the scheduling of crash handler and err messages associated with it). Also this check was always present and was missed during common q6v5 resource helper migration, hence the unused running state in mss driver. > > I just worry this will mask real issues that happen during graceful > shutdown. > -Evan -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.