linux-kernel - Re: [PATCH RFC 2/2] memory: add Renesas RPC-IF 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <cba1e2ec-4896-23ef-ef7b-0f80d4310127@de.bosch.com>
Date:   Mon, 24 Feb 2020 06:46:23 +0100
From:   "Behme Dirk (CM/ESO2)" <dirk.behme@...bosch.com>
To:     Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
CC:     <devicetree@...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>,
        Chris Brandt <chris.brandt@...esas.com>,
        <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH RFC 2/2] memory: add Renesas RPC-IF driver

On 22.02.2020 21:42, Sergei Shtylyov wrote:
> On 02/10/2020 01:21 PM, Behme Dirk (CM/ESO2) wrote:
> 
>>> Add the memory driver for Renesas RPC-IF which registers either SPI or
>>> HyperFLash device depending on the contents of the device tree subnode.
>>> It also provides the absract "back end" device APIs that can be used by
>>> the "front end" SPI/MTD drivers to talk to the real hardware.
>>>
>>> Based on the original patch by Mason Yang <masonccyang@...c.com.tw>.
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
>>
>>
>> FYI, please find below [1] the changes I did locally on this driver. It seems to read & write successfully on my custom M3 (R8A7796) device, now.
> 
>     Not for me...
>     BTW, your patch had whitespace ruined, I had to apply it by hand, you'd better
> attach the patches, not paste. :-/


Ok. There are other mailing lists complaining about attachments ;)

Even better, maybe we should put what we have so far publicly anywhere, 
e.g. github.


>> Best regards
>>
>> Dirk
>>
>> [1]
>>
>>  From d72b805cc461ab1e9747c973e9be84e7abb8f828 Mon Sep 17 00:00:00 2001
>> From: Dirk Behme <dirk.behme@...bosch.com>
>> Date: Tue, 4 Feb 2020 08:39:31 +0100
>> Subject: [PATCH] memory: renesas-rpc-if: Correct the STRTIM and some other
>>   clean up
>>
>> This is required to make the driver work correctly in my M3 environment.
>>
>> Signed-off-by: Dirk Behme <dirk.behme@...bosch.com>
>> ---
>>   drivers/memory/renesas-rpc-if.c | 42 ++++++++++++++++++++-------------
>>   1 file changed, 25 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c
>> index 04be92b64bfa..f4356b066384 100644
>> --- a/drivers/memory/renesas-rpc-if.c
>> +++ b/drivers/memory/renesas-rpc-if.c
> [...]
>> @@ -513,19 +525,15 @@ ssize_t rpcif_dirmap_read(struct rpcif *rpc, u64 offs, size_t len, void *buf)
>>       pm_runtime_get_sync(rpc->dev);
>>
>>       regmap_update_bits(rpc->regmap, RPCIF_CMNCR, RPCIF_CMNCR_MD, 0);
>> -    regmap_write(rpc->regmap, RPCIF_DRCR,
>> -             RPCIF_DRCR_RBURST(32) | RPCIF_DRCR_RBE);
>> -    regmap_write(rpc->regmap, RPCIF_DRCMR, rpc->command);
>> -    regmap_write(rpc->regmap, RPCIF_DREAR,
>> -             RPCIF_DREAR_EAV(offs >> 25) | RPCIF_DREAR_EAC(1));
>> -    regmap_write(rpc->regmap, RPCIF_DROPR, rpc->option);
>> -    regmap_write(rpc->regmap, RPCIF_DRENR,
>> -             rpc->enable & ~RPCIF_SMENR_SPIDE(0xF));
>> -    regmap_write(rpc->regmap, RPCIF_DRDMCR, rpc->dummy);
>> -    regmap_write(rpc->regmap, RPCIF_DRDRENR, rpc->ddr);
> 
>     The driver somehow works only with this left in place (with 2 bytes eaten
> as before), otherwise all the flash reads all 0xff (via dirmap).


Do you boot from hyperflash?

The system I'm using for testing boots from hyperflash. So most probably 
all registers I don't touch in the driver are put into a reasonable 
state by the boot code, already. If you don't boot from hyperflash, that 
at least would explain our different behavior.

Best regards

Dirk