Re: [PATCH RFT 0/2/2] mtd: hyperbus: add Renesas RPC-IF driver

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Vignesh Raghavendra <vigneshr@ti.com>,
	"Behme Dirk (CM/ESO2)" <dirk.behme@de.bosch.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH RFT 0/2/2] mtd: hyperbus: add Renesas RPC-IF driver
Date: Thu, 20 Feb 2020 21:30:55 +0300	[thread overview]
Message-ID: <d6fd2da7-d1c4-0148-258c-826d8a7da469@cogentembedded.com> (raw)
In-Reply-To: <aef44eb7-78df-8505-ad37-d67fd499532e@ti.com>

On 02/18/2020 02:11 PM, Vignesh Raghavendra wrote:

[...]
>>> Looking around, there seems to be more than one SPI controllers, apart
>>> from Renesas, which also support SPI NOR and HyperFlash protocol within
>>> a single IP block. E.g.: Cadence xSPI controller [1]. Therefore, we need
>>> a generic framework to support these kind of controllers.
>>>
>>> One way would be to extend spi_mem_op to support above template along
>>> with a new field to distinguish SPI NOR vs HyperFlash protocol. HyperBus
>>> core can then register a spi_device and use spi-mem ops to talk to
>>> controller driver.
>>> So, I suggest making Renesas RPC-IF backend a full fledged spi-mem
>>> driver (instead of driver/memory) and use extended spi_mem_op to support
>>> HyperFlash.
>>
>>
>> From Renesas Hyperflash user point of view, I wonder if a two step
>> approach would be possible and acceptable, here?
>>
>> Being a user of the Renesas Hyperflash, I want a driver for that. And,
>> of course, I want it "now" ;)
>>
>> So I wonder if it would be a valid option to have a functioning Renesas
>> Hypeflash driver, first. And in a second step abstract that in a more
>> generic way to support additional controllers. While in parallel having
>> a functional driver for the Renesas people, already.
> 
> AFAICS, the backend driver is not merged and is still in RFC phase.

   It was still marked RFC back in December and I haven't received any
feedback since, other than Dirk's request. Where have you been? Well,
I should have CCed linux-mtd back then... :-/

> Therefore I don't see any benefit of two step approach here. Besides
> you'll have to throw away this new driver (hyperbus/rpc-if.c) entirely
> later on.

   Why did you create this directory for, anyway? :-/

> How difficult is it to rewrite backend to be spi-mem driver? There is
> already has a spi_mem_ops frontend implementation, so I don't see much
> of an issue.

   Really? This may be not much of an issue with coding this but it's
certainly time consuming (I'm sure there's s/th to think about yet in
this case)? My management (and also me, so far) believes I'm in the
final stage with these drivers... what should I say to my boss now?

> Extending hyperbus core to use spi-mem should also straight forward
> Would involve moving this patch into core file.

   Seriously, only "moving"?

>> Is the support for [1] a more or less theoretical one, at the moment? Or
>> are there users of that which need support "now", too?
> 
> Its not theoretical, I do see patches for xSPI controller here:
> https://patchwork.kernel.org/cover/11354193/

   Which (surprise!) only adds support for the SPI part...

> So, its best to sort this out now so as to avoid possible backward
> compatibility issues (especially with DT bindings)

   What DT issues do you mean exactly? I think that other than changing
the "home" dir for the bindings, there'd little to change. The "front ends"
don't deal with the DT probing...

> Regards
> Vignesh

MBR, Sergei

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/