Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 25 Apr 2022 08:20:03 -0700 (PDT)
Subject:     Re: [PATCH v6 08/17] riscv: use fallback for random_get_entropy() instead of zero
In-Reply-To: <CAHmME9qosSq+3RYtBCMiS6yCaiZcJtaBW=8StMTACEkr3hVSow@mail.gmail.com>
CC:     linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        tglx@linutronix.de, Arnd Bergmann <arnd@arndb.de>,
        Paul Walmsley <paul.walmsley@sifive.com>
From:   Palmer Dabbelt <palmer@dabbelt.com>
To:     Jason@zx2c4.com
Message-ID: <mhng-fb5b48c2-4e08-4e41-9f28-88e216df40ab@palmer-mbp2014>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Mon, 25 Apr 2022 08:02:49 PDT (-0700), Jason@zx2c4.com wrote:
> Hi Palmer,
>
> On Mon, Apr 25, 2022 at 4:55 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> Fine for me if this goes in via some other tree, but also happy to take
>> it via the RISC-V tree if you'd like.
>
> I'm going to take this series through the random.git tree, as I've got
> things that build on top of it for random.c slated for 5.19.
>
>> IMO we could just call this a
>> fix, maybe
>>
>> Fixes: aa9887608e77 ("RISC-V: Check clint_time_val before use")
>>
>> (but that just brought this back, so there's likely older kernels broken
>> too).  Shouldn't be breaking any real hardware, though, so no rush on my
>> end.
>
> That'd be fine with me, but it'd involve also backporting the
> timekeeping patch, which adds a new API, so maybe we better err on the
> side of caution with that new code.

wFM.  Like I said this isn't going to break any existing hardware, and 
anyone trying to ship something without the timers is likely going to be 
in for way more trouble than this so will probably be stuck with newer 
kernels anyway.

>> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
>> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
>
> Thanks for the review.
>
>> Makes sense: we had an architecturally-mandated timer at the time, but
>> we don't any more.
>
> That's too bad. Out of curiosity, what happened? Was that deemed too
> expensive for certain types of chips that western digital wanted to
> produce for their hard drives, or some really constrained use case
> like that?

No idea, but it was at the beginning of the "everything is 
optional"-ification of the ISA so I'm guessing it's just part of that.