From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751972AbdHGQXe (ORCPT ); Mon, 7 Aug 2017 12:23:34 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:35745 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751443AbdHGQXb (ORCPT ); Mon, 7 Aug 2017 12:23:31 -0400 Date: Mon, 7 Aug 2017 09:23:27 -0700 From: Bjorn Andersson To: Christoph Hellwig Cc: Rob Herring , Frank Rowand , Andy Gross , David Brown , Mark Rutland , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org Subject: Re: [PATCH v2 4/5] soc: qcom: Remote FS memory driver Message-ID: <20170807162327.GH29306@minitux> References: <20170803025754.19101-1-bjorn.andersson@linaro.org> <20170803025754.19101-5-bjorn.andersson@linaro.org> <20170805095804.GA14401@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170805095804.GA14401@infradead.org> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 05 Aug 02:58 PDT 2017, Christoph Hellwig wrote: > On Wed, Aug 02, 2017 at 07:57:53PM -0700, Bjorn Andersson wrote: > > The rfsa driver is used for allocating and exposing regions of shared > > memory with remote processors for the purpose of exchanging sector-data > > between the remote filesystem service and its clients. > > Please explain which remote fs this is for, and submit said file system > for inclu??ion. > In the NAND-era of Qualcomm platforms the modem firmware had direct access to the storage media, but with the move to eMMC and the transition of Linux/Android to become the "primary OS" this access was lost. Remaining in the modem firmware is a file system (EFS) for parameter storage et al, but the block layer was replaced with a block-access protocol, "conveniently" called RemoteFS. The protocol is based on a chunk of RAM and a set of messages to transfer sector-data between the storage device and the chunk of RAM. Up until this patch the user space tool that implements the message handler just mapped the reserved memory region though /dev/mem, but this requires /dev/mem access and for the later platforms we need to make a call into TrustZone to provide the remote permission to access this memory region. So we need some code in the kernel to represent this. > Else: NAK as the scheme looks completely brain dead and bonkers. I can rework the commit message in an attempt to better explain the setup and hope you/people find it slightly less bonkers. Does this sound reasonable? Regards, Bjorn