linux-kernel - Re: [PATCH v7 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 29 Jan 2019 05:43:39 +0100
From:   Marek Vasut <marek.vasut@...il.com>
To:     masonccyang@...c.com.tw
Cc:     bbrezillon@...nel.org, broonie@...nel.org,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Simon Horman <horms@...ge.net.au>, juliensu@...c.com.tw,
        linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-spi@...r.kernel.org, sergei.shtylyov@...entembedded.com,
        zhengxunli@...c.com.tw
Subject: Re: [PATCH v7 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller
 driver

On 1/29/19 3:26 AM, masonccyang@...c.com.tw wrote:
> Hi Marek,

Hi,

>> >> "Marek Vasut" <marek.vasut@...il.com>
>> >> >> >> > +module_platform_driver(rpc_spi_driver);
>> >> >> >>
>> >> >> >> RPC is not a SPI controller, it's a SPI and HF controller.
>> >> >> >>
>> >> >> >> Also, how difficult will it be to add the HF support ?
>> >> >> >
>> >> >> > One of my customers needs RPC SPI driver for our company's
>> >> >> > Octal-Flash,MX25UW51245G.
>> >> >> > We don't have HF product and hope you could understanding.
>> >> >>
>> >> >> I am worried that when we need to add RPC HF support (which is
> what all
>> >> >> boards but the D3 Draak use), we will have to rewrite the entire
> driver
>> >> >> and/or convert it to MFD and that would be a tremendous
>> > undertaking. I'd
>> >> >> prefer to have the driver ready for the HF addition before it's
>> > accepted
>> >> >> upstream.
>> >> >>
>> >> >
>> >> > I think maybe your concerned would be happened only if HF driver
>> > goes with
>> >> > spi-mem layer.
>> >> >
>> >> > A comment for HF from Daniel Fishman. FYR.
>> >> >
>> >> > https://www.quora.com/What-is-a-hyper-flash-memory-and-how-is-it-
>> >> different-from-normal-flash-memory
>> >>
>> >> I have a decent idea what HF and SPI NOR are, since I wrote the RPC
>> >> driver for both HF and SPI mode for U-Boot (as I mentioned earlier).
>> >>
>> >> The HF in Linux would use the CFI NOR part of MTD framework. My concern
>> >> is that when we need to add HF support into this driver, this driver
>> >> will have to be basically rewritten, since the architecture won't allow
>> >> for that. I'd like to avoid that, since the majority of Gen3 boards,
>> >> expect for the D3 Draak, use RPC in HF mode.
>> >
>> > FYI~
>> >
>> > MX25UW51245g(64MByte Octa)                      S26KL512S(64MByte HF)
>> >    8 IO                                                  8 IO
>> > 200MHz DDR@...v                                   166MHz DDR@...v
>> >
>> > support Read-while-write                       Not support
>> > good for OTA,etc
>> > powerful application
>>
>> What does that mean ?
> 
> I have no idea why would you say "since the majority of Gen3 boards use
> RPC in HF mode" ?

Well, the H3/M3W/M3N S-X(S) and the H3/M3 ULCB and E3 Ebisu all boot
from HF. Only the D3 Draak uses QSPI NOR.

> So far as I know that HF is provided by Cypress only and
> any mass production product use the component which is provided by only
> one provider
> will be a big risk.
> 
> Compare to HF, there are more provider of SPI/Octa could support the
> mass production product
> as their second provider.
> 
> In addition, from the technical points of view, mx25uw51245g is more
> powerful than HF and
> good for complicate user application, i.e., OTA and so on.

Did you consider protocol overhead too ? I don't think you can compare
them just by raw numbers of pins and bus frequency.

Note that over-the-air update (if that's what you mean by OTA) is
completely separate from the underlying storage device.

> I think customer have more choice for their flash memory component.
Note that none of this is really relevant to my concerns above regarding
HF support. This driver should be implemented as MFD driver and the SPI
part should use the MFD core part , just like the future HF part.

-- 
Best regards,
Marek Vasut