Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1121473pxb; Wed, 15 Sep 2021 23:30:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfth2fsAuHJidPOOgoqBfrFXLvudEwhuG3BK+pkoGXQ2XLUg4b3c0WHju+sjvzGSF9Sb95 X-Received: by 2002:a5e:a913:: with SMTP id c19mr3023828iod.31.1631773837229; Wed, 15 Sep 2021 23:30:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631773837; cv=none; d=google.com; s=arc-20160816; b=T8GcCEvfS++aIbXU4lMWxua+H/5+ns9exMWgEeqQaaWMIjZqDWx4nMaqyJQc6MBduD lyk7eDImLrqhLUV6dYTir+jSSjplfkHUVlkyX9PWgVjQVqIZtpJVhsieNZhk1hKhkEfB UzZ5PzXU7Pk8YW3vq4XRCggmHHYH2xNdEl8I5QJlM6Et/8RLrhmTAMzYFi9SAndx/rJY I+uQokLC0K/XbyPvBPTiZTS4+kNKyj6tvFIcPJ+V9O9T6Jvf+NNS8JAfsmOytEi4qj6p quqQ9I9zByCv+rCwaQBBQ1I5jP13eLF2aiLuOVIvkVtOJjr8TtYrQrLDSASMhCxvDQGp 1CuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :sender:dkim-signature; bh=14otI/FRn3T6TCrE2iGF/EbKmUQaHDuaRWzxyWGJRJI=; b=durFaqZ8R+Huwiu0tZqhReou5+aQB9z95RcBmz/cgjzmmhxwIPi8Uw0DjHLGtFnyNb k7GPZiDipSWjJxpfkKJImSONxw9A1vUb2lj89snp8rJnSdGcapebxsciYY/U9ljaOtd0 UMDkDd64lBhqaXWkmlP2xPG0p1x3K9JpIvEbFpV0FQc1xHfHFbx7R6qLH1TkE3hBbrRc VC1de5eM9xAsgIGFKWBap2YibItHOuQsVy5Orex14ExghMRTWAnhLhIvuAHV7KBfpO8D OSyyMdIXJ9GF9fyRM2+nYE0XXSBaW4yqhHeDey9vh24ehTW3qev/F/MsteQCbKxQaxR0 8Rng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=JJcGsVLS; 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 x8si2119287jaq.91.2021.09.15.23.30.24; Wed, 15 Sep 2021 23:30:37 -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=pass header.i=@mg.codeaurora.org header.s=smtp header.b=JJcGsVLS; 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 S234492AbhIPGbA (ORCPT + 99 others); Thu, 16 Sep 2021 02:31:00 -0400 Received: from m43-7.mailgun.net ([69.72.43.7]:42102 "EHLO m43-7.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231255AbhIPGa6 (ORCPT ); Thu, 16 Sep 2021 02:30:58 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1631773778; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=14otI/FRn3T6TCrE2iGF/EbKmUQaHDuaRWzxyWGJRJI=; b=JJcGsVLS57WfRuxOV5uOV+1pPCxhazNDrfIl5FGV0iWeUvALB3wYeBPMK5pKeDGJ7Cb52csv rzadfxBAk9ZL1RgkOfSgvhBR66tmhuENtgfBq0IHIZ1aY8l6Jj0Jvi0JsFr7cYuPpwUQ7dAZ pjPCgqLNWN1N9yVoU3UiOXnhafk= X-Mailgun-Sending-Ip: 69.72.43.7 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-n03.prod.us-west-2.postgun.com with SMTP id 6142e451b585cc7d2466e0ac (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 16 Sep 2021 06:29:37 GMT Sender: dikshita=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id B0627C43616; Thu, 16 Sep 2021 06:29:37 +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=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00 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: dikshita) by smtp.codeaurora.org (Postfix) with ESMTPSA id D2D0AC4338F; Thu, 16 Sep 2021 06:29:36 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Sep 2021 11:59:36 +0530 From: dikshita@codeaurora.org To: Stephen Boyd Cc: Stanimir Varbanov , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, jim.cromie@gmail.com, Joe Perches , Jason Baron , Greg Kroah-Hartman , linux-media-owner@vger.kernel.org, Akinobu Mita Subject: Re: [PATCH v5 2/3] venus: Add a debugfs file for SSR trigger In-Reply-To: References: <20200730095350.13925-1-stanimir.varbanov@linaro.org> <20200730095350.13925-3-stanimir.varbanov@linaro.org> <159718256557.1360974.458611240360821676@swboyd.mtv.corp.google.com> <8c1fdf2d0807f07ec57b232497b405f1@codeaurora.org> Message-ID: <53a38a24cca0b6f1c2a3120f14dfc865@codeaurora.org> X-Sender: dikshita@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-09-16 01:09, Stephen Boyd wrote: > Quoting dikshita@codeaurora.org (2021-09-15 02:13:09) >> Hi Stephen, >> >> Reviving the discussion on this change as we need to pull this in. >> >> As per your suggestion, I explored the fault injection framework to >> implement this functionality. >> But I don't think that meets our requirements. >> >> We need a way to trigger subsystem restart from the client-side, it's >> not derived from the driver. > > Just to confirm, this is all for debugging purposes right? > yes, correct. this is for debugging purposes. We need this to simulate an error on FW side. In a normal scenario, when FW runs into error, sys error is triggered from FW as result of which a sequence of commands are followed for restarting the system. using this feature, we are trying to simulate this error on FW i.e we are forcing the FW to run into an error. >> >> while fault injection framework enables the driver to trigger an >> injection >> when a specific event occurs for eg: page allocation failure or memory >> access failure. >> >> So, IMO, we will have to use custom debugfs only. > > Can you use DECLARE_FAULT_ATTR()? Or you need it to be active instead > of > passive, i.e. it shouldn't wait for should_fail() to return true, but > actively trigger something on the remoteproc? > yes, it doesn't need to wait for should_fail() to return true. the client/user should be able to trigger this subsystem restart(SSR) at any point of time when a session is running. It's totally client-driven. >> >> Please feel free to correct me in case my understanding of the >> framework >> is wrong. >> > > I presume the fault injection framework could get a new feature that > lets the fault be injected immediately upon writing the debugfs file. > My goal is to consolidate this sort of logic into one place and then > put > it behind some config option that distros can disable so the kernel > isn't bloated with debug features that end users will never care about.