Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3721046ybb; Tue, 31 Mar 2020 10:39:48 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsPUPVMF4rVnTtYKErw9mvqfGDWrSYsCxbuRCfNowPvlSXN4hzOhxTb19NEhKNT4PSsW3uz X-Received: by 2002:aca:5e0b:: with SMTP id s11mr2718783oib.111.1585676388144; Tue, 31 Mar 2020 10:39:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585676388; cv=none; d=google.com; s=arc-20160816; b=KjXNhoeclVvP544ICKgxGwKLUBDrZoWFkgf4HvLJtw39L5Gf1qHzGC+6UobtLHLovU xzsEiQYa8scvzWWVaz0QquzNRAeXKWYUz1/ynE4ftZbiD9ne2Az/7rx89J+aZou4+6u1 zDNZNye9VrRzYT8+DjxxmJKYrFt/V4lciGjEBXG1AvJsDtC46ytvw8USqzAFYvlM0etZ 2W8DvtDAMcEAoMofndD9PQHBz9Xhbw7II4Jf/8M6KcOVYJsvzMdr9DZIMAWMFbJRM7CE WSNcNS2KBK0hIbUUifTPPH37lIRMyxi+ZVQreE4XCW1np1CUw3vb16vaXRRzqs0klnAr AE2Q== 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=A68oC8U79UBpdukiOxjd0RuIgv72CKAYZ4hNjVAU4J4=; b=d2BLfNSpsb8GFpa48LLB++DASzB0DRyYDcpTqp4Xx+HI06ctCeu9U15Vehf8DigFZC joB4TExtnGreA4gE8FT3f76rtlLyO7EacRSLMI3P70KhRv/faMmeAYV2zH3RcI0jp7C8 TCX7M3wdg8/moh9VHjB1TytdKNpLpNdMWGmMCnQnMhFbJXlbTo90Q5eEqJD94zwxtB6O paVKKe8WNCU975L4E7djumFTpPwk0jgrvSR1917spmOyY8jY15H1npjl/DDESV2tn5km x1eEhZbS52yXq0P5cf9LROQTcpCFqo5C9bylaRBy2E+mepRVn2olK01pZUviaY9LPpWm 34yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=UFKNoN4+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u207si7166802oia.176.2020.03.31.10.39.35; Tue, 31 Mar 2020 10:39:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@mg.codeaurora.org header.s=smtp header.b=UFKNoN4+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726977AbgCaRi3 (ORCPT + 99 others); Tue, 31 Mar 2020 13:38:29 -0400 Received: from mail26.static.mailgun.info ([104.130.122.26]:57343 "EHLO mail26.static.mailgun.info" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725958AbgCaRi3 (ORCPT ); Tue, 31 Mar 2020 13:38:29 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1585676308; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=A68oC8U79UBpdukiOxjd0RuIgv72CKAYZ4hNjVAU4J4=; b=UFKNoN4+pwVUJFK2PSmSqN1RtpSyw0PIHS7Hi34ZLeRlUytymE9Hias6I7mNkjs4LHl3qaVD EAniWV0GbD6wU4x/dYWiXarG8X8rAJwG328kANsCBuW2iDSglh+y1C69jbhjKyNrG8IJeQ5b T6sQvRRKnEcWYBQuhMsh986wtJ0= X-Mailgun-Sending-Ip: 104.130.122.26 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 mxa.mailgun.org with ESMTP id 5e838013.7f249de50e30-smtp-out-n01; Tue, 31 Mar 2020 17:38:27 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 6F137C43637; Tue, 31 Mar 2020 17:38:26 +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: rishabhb) by smtp.codeaurora.org (Postfix) with ESMTPSA id C0B3BC433F2; Tue, 31 Mar 2020 17:38:24 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 31 Mar 2020 10:38:24 -0700 From: rishabhb@codeaurora.org To: Mathieu Poirier Cc: Bjorn Andersson , Linux Kernel Mailing List , linux-remoteproc , Ohad Ben-Cohen , psodagud@codeaurora.org, tsoni@codeaurora.org, Siddharth Gupta , linux-remoteproc-owner@vger.kernel.org Subject: Re: [PATCH 1/2] remoteproc: Add userspace char device driver In-Reply-To: References: <1585241440-7572-1-git-send-email-rishabhb@codeaurora.org> <1585241440-7572-2-git-send-email-rishabhb@codeaurora.org> <20200330221245.GA17782@xps15> <20200330224554.GD215915@minitux> Message-ID: <30f8b41df8831d19ce6efd0a28862708@codeaurora.org> X-Sender: rishabhb@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 On 2020-03-31 09:47, Mathieu Poirier wrote: > On Mon, 30 Mar 2020 at 16:45, Bjorn Andersson > wrote: >> >> On Mon 30 Mar 15:12 PDT 2020, Mathieu Poirier wrote: >> [..] >> > > + struct rproc *rproc; >> > > + >> > > + rproc = container_of(inode->i_cdev, struct rproc, char_dev); >> > > + if (!rproc) >> > > + return -EINVAL; >> > > + >> > > + rproc_shutdown(rproc); >> > >> > The scenario I see here is that a userspace program will call >> > open(/dev/rproc_xyz, SOME_OPTION) when it is launched. The file stays open >> > until either the application shuts down, in which case it calls close() or it >> > crashes. In that case the system will automatically close all file descriptors >> > that were open by the application, which will also call rproc_shutdown(). >> > >> > To me the same functionality can be achieved with the current functionality >> > provided by sysfs. >> > >> > When the application starts it needs to read >> > "/sys/class/remoteproc/remoteprocX/state". If the state is "offline" then >> > "start" should be written to "/sys/.../state". If the state is "running" the >> > application just crashed and got restarted. In which case it needs to stop the >> > remote processor and start it again. >> > >> >> A case when this would be useful is the Qualcomm modem, which relies >> on >> disk access through a "remote file system service" [1]. >> >> Today we register the service (a few layers ontop of rpmsg/GLINK) then >> find the modem remoteproc and write "start" into the state sysfs file. >> >> When we get a signal for termination we write "stop" into state to >> stop >> the remoteproc before exiting. >> >> There is however no way for us to indicate to the modem that rmtfs >> just >> died, e.g. a kill -9 on the process will result in the modem continue >> and the next IO request will fail which in most cases will be fatal. I have this scenario written down in the cover letter for this patchset "[PATCH 0/2] Add character device interface to remoteproc" I'll add it to the commit text as well. > > The modem will crash when attempting an IO while rmtfs is down? > >> >> So instead having rmtfs holding /dev/rproc_foo open would upon its >> termination cause the modem to be stopped automatically, and as the >> system respawns rmtfs the modem would be started anew and the two >> sides >> would be synced up again. > > I have a better idea of what is going on now - thanks for writing this > up. > > I would make this feature a kernel configurable option as some people > may not want it. I also think having "/dev/remoteprocX" is fine, so > no need to change anything currently visible in sysfs. Ok. Makes sense. > > Mathieu > >> >> [1] https://github.com/andersson/rmtfs >> >> Regards, >> Bjorn