[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJsYDVLEggVBAm2zXe1V7jeAAwXACHrEj6UgiL9Wc-cNq=Zuww@mail.gmail.com>
Date: Sun, 20 Dec 2020 16:51:50 +0800
From: Chuanhong Guo <gch981213@...il.com>
To: Bert Vermeulen <bert@...t.com>
Cc: Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Mark Brown <broonie@...nel.org>, john.garry@...wei.com,
Boris Brezillon <bbrezillon@...nel.org>,
vadivel.muruganx.ramuthevar@...ux.intel.com,
open list <linux-kernel@...r.kernel.org>,
linux-mtd@...ts.infradead.org
Subject: Re: [PATCH] Add spi-nor driver for Realtek RTL838x/RTL839x switch SoCs
Hi!
On Sun, Dec 20, 2020 at 7:01 AM Bert Vermeulen <bert@...t.com> wrote:
>
> On 12/16/20 9:30 AM, Tudor.Ambarus@...rochip.com wrote:
> > On 12/15/20 11:46 PM, Bert Vermeulen wrote:
> >> This driver supports the spiflash core in all RTL838x/RTL839x SoCs,
> >> and likely some older models as well (RTL8196C).
> >>
> > Can we use SPIMEM and move this under drivers/spi/ instead?
>
> I wasn't aware spimem was the thing to use for new drivers. I will rewrite
> the driver to that API.
Are there any limitations preventing this from being implemented as a
generic SPI controller?
spi-nor and spi-mem are designed for controllers which can only perform
spi-mem/spi-nor specific transfers. I can't find such limitations from
your current driver code.
BTW I found a SPI controller driver for RTL8196C here: [0]
It seems pretty similar to the controller you are working on.
[0]: https://github.com/hackpascal/lede-rtl8196c/blob/realtek/target/linux/realtek/files/drivers/spi/spi-realtek.c
--
Regards,
Chuanhong Guo
Powered by blists - more mailing lists