[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0af05149-78f5-8639-4a23-84edda0073ea@cogentembedded.com>
Date: Wed, 11 Dec 2019 19:20:51 +0300
From: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To: Chris Brandt <Chris.Brandt@...esas.com>,
Rob Herring <robh+dt@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Cc: Mark Rutland <mark.rutland@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Mason Yang <masonccyang@...c.com.tw>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>
Subject: Re: [PATCH RFC 0/2] Add Renesas RPC-IF support
On 12/11/2019 05:33 PM, Chris Brandt wrote:
>> Here's a set of 2 patches against Linus' repo. Renesas Reduced Pin Count
>> Interface (RPC-IF) allows a SPI flash or HyperFlash connected to the SoC to
>> be accessed via the external address space read mode or the manual mode.
>
> Looking at this driver, all it is are APIs. Meaning another driver is
> needed to sit in between the MTD layer and this HW driver layer.
>
> In the driver that I did, if the "RPC" HW is going to be used to control
> a SPI Flash device, it registered a spi controller and then the MTD
> layer could access the device
Via the SPI-to-MTD sublayer for (at least) direct mapping -- grep for "dirmap"
in drivers/mtd/spi-nor/spi-nor.c...
> just like any other SPI controller driver. No
> additional drivers are needed.
Then why do we have *struct* spi_controller_mem_ops? Do All drivers implement
such ops?
[...]
MBR, Sergei
Powered by blists - more mailing lists