Linux-RISC-V Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] clocksource: clint: Export clint_time_val for modules
@ 2020-09-30  6:56 Palmer Dabbelt
  2020-10-02  6:49 ` get_cycles from modular code in jitterentropy, was " Christoph Hellwig
  0 siblings, 1 reply; 13+ messages in thread
From: Palmer Dabbelt @ 2020-09-30  6:56 UTC (permalink / raw)
  To: linux-riscv; +Cc: Palmer Dabbelt, kernel-team, kernel test robot

clint_time_val will soon be used by the RISC-V implementation of
random_get_entropy(), which is a static inline function that may be used by
modules (at least CRYPTO_JITTERENTROPY=m).

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
---
 drivers/clocksource/timer-clint.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/timer-clint.c b/drivers/clocksource/timer-clint.c
index d17367dee02c..6cfe2ab73eb0 100644
--- a/drivers/clocksource/timer-clint.c
+++ b/drivers/clocksource/timer-clint.c
@@ -38,6 +38,7 @@ static unsigned int clint_timer_irq;
 
 #ifdef CONFIG_RISCV_M_MODE
 u64 __iomem *clint_time_val;
+EXPORT_SYMBOL(clint_time_val);
 #endif
 
 static void clint_send_ipi(const struct cpumask *target)
-- 
2.28.0.709.gb0816b6eb0-goog


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* get_cycles from modular code in jitterentropy, was Re: [PATCH] clocksource: clint: Export clint_time_val for modules
  2020-09-30  6:56 [PATCH] clocksource: clint: Export clint_time_val for modules Palmer Dabbelt
@ 2020-10-02  6:49 ` Christoph Hellwig
  2020-10-02  6:55   ` Stephan Mueller
  2020-10-04 18:48   ` [PATCH] crypto: jitterentropy - bind statically into kernel Stephan Müller
  0 siblings, 2 replies; 13+ messages in thread
From: Christoph Hellwig @ 2020-10-02  6:49 UTC (permalink / raw)
  To: Palmer Dabbelt
  Cc: kernel test robot, smueller, linux-kernel, linux-crypto,
	linux-riscv, kernel-team

On Tue, Sep 29, 2020 at 11:56:18PM -0700, Palmer Dabbelt wrote:
> clint_time_val will soon be used by the RISC-V implementation of
> random_get_entropy(), which is a static inline function that may be used by
> modules (at least CRYPTO_JITTERENTROPY=m).

At very least this needs to be an EXPORT_SYMBOL_GPL.  But I really don't
think modules have any business using get_cycles, so I'd much rather
fix CRYPTO_JITTERENTROPY to be required to be build in.

> 
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
> ---
>  drivers/clocksource/timer-clint.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clocksource/timer-clint.c b/drivers/clocksource/timer-clint.c
> index d17367dee02c..6cfe2ab73eb0 100644
> --- a/drivers/clocksource/timer-clint.c
> +++ b/drivers/clocksource/timer-clint.c
> @@ -38,6 +38,7 @@ static unsigned int clint_timer_irq;
>  
>  #ifdef CONFIG_RISCV_M_MODE
>  u64 __iomem *clint_time_val;
> +EXPORT_SYMBOL(clint_time_val);
>  #endif
>  
>  static void clint_send_ipi(const struct cpumask *target)
> -- 
> 2.28.0.709.gb0816b6eb0-goog
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
---end quoted text---

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: get_cycles from modular code in jitterentropy, was Re: [PATCH] clocksource: clint: Export clint_time_val for modules
  2020-10-02  6:49 ` get_cycles from modular code in jitterentropy, was " Christoph Hellwig
@ 2020-10-02  6:55   ` Stephan Mueller
  2020-10-04 18:48   ` [PATCH] crypto: jitterentropy - bind statically into kernel Stephan Müller
  1 sibling, 0 replies; 13+ messages in thread
From: Stephan Mueller @ 2020-10-02  6:55 UTC (permalink / raw)
  To: Palmer Dabbelt, Christoph Hellwig
  Cc: linux-kernel, linux-riscv, kernel-team, kernel test robot, linux-crypto

Am Freitag, 2. Oktober 2020, 08:49:05 CEST schrieb Christoph Hellwig:

Hi Christoph,

> On Tue, Sep 29, 2020 at 11:56:18PM -0700, Palmer Dabbelt wrote:
> > clint_time_val will soon be used by the RISC-V implementation of
> > random_get_entropy(), which is a static inline function that may be used
> > by
> > modules (at least CRYPTO_JITTERENTROPY=m).
> 
> At very least this needs to be an EXPORT_SYMBOL_GPL.  But I really don't
> think modules have any business using get_cycles, so I'd much rather
> fix CRYPTO_JITTERENTROPY to be required to be build in.

Changing CRYPTO_JITTERENTROPY from tistate to bool should be no problem.

I will provide a patch.

Ciao
Stephan



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-02  6:49 ` get_cycles from modular code in jitterentropy, was " Christoph Hellwig
  2020-10-02  6:55   ` Stephan Mueller
@ 2020-10-04 18:48   ` Stephan Müller
  2020-10-04 21:16     ` Ard Biesheuvel
  1 sibling, 1 reply; 13+ messages in thread
From: Stephan Müller @ 2020-10-04 18:48 UTC (permalink / raw)
  To: Palmer Dabbelt, Christoph Hellwig
  Cc: linux-kernel, linux-riscv, kernel-team, kernel test robot, linux-crypto

The RISC-V architecture is about to implement the callback
random_get_entropy with a function that is not exported to modules.
Thus, the Jitter RNG is changed to be only bound statically into the
kernel removing the option to compile it as module.

Reported-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 094ef56ab7b4..5b20087b117f 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1853,7 +1853,7 @@ config CRYPTO_DRBG
 endif	# if CRYPTO_DRBG_MENU
 
 config CRYPTO_JITTERENTROPY
-	tristate "Jitterentropy Non-Deterministic Random Number Generator"
+	bool "Jitterentropy Non-Deterministic Random Number Generator"
 	select CRYPTO_RNG
 	help
 	  The Jitterentropy RNG is a noise that is intended
-- 
2.26.2





_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-04 18:48   ` [PATCH] crypto: jitterentropy - bind statically into kernel Stephan Müller
@ 2020-10-04 21:16     ` Ard Biesheuvel
  2020-10-04 22:05       ` Palmer Dabbelt
  2020-10-05  6:19       ` Christoph Hellwig
  0 siblings, 2 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2020-10-04 21:16 UTC (permalink / raw)
  To: Stephan Müller
  Cc: kernel test robot, Palmer Dabbelt, Linux Kernel Mailing List,
	Christoph Hellwig, Linux Crypto Mailing List, linux-riscv,
	Android Kernel Team

On Sun, 4 Oct 2020 at 20:48, Stephan Müller <smueller@chronox.de> wrote:
>
> The RISC-V architecture is about to implement the callback
> random_get_entropy with a function that is not exported to modules.

Why is that? Wouldn't it be better to export the symbol instead?

> Thus, the Jitter RNG is changed to be only bound statically into the
> kernel removing the option to compile it as module.
>
> Reported-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
>  crypto/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 094ef56ab7b4..5b20087b117f 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -1853,7 +1853,7 @@ config CRYPTO_DRBG
>  endif  # if CRYPTO_DRBG_MENU
>
>  config CRYPTO_JITTERENTROPY
> -       tristate "Jitterentropy Non-Deterministic Random Number Generator"
> +       bool "Jitterentropy Non-Deterministic Random Number Generator"
>         select CRYPTO_RNG
>         help
>           The Jitterentropy RNG is a noise that is intended
> --
> 2.26.2
>
>
>
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-04 21:16     ` Ard Biesheuvel
@ 2020-10-04 22:05       ` Palmer Dabbelt
  2020-10-05  6:19       ` Christoph Hellwig
  1 sibling, 0 replies; 13+ messages in thread
From: Palmer Dabbelt @ 2020-10-04 22:05 UTC (permalink / raw)
  To: ardb
  Cc: lkp, smueller, linux-kernel, Christoph Hellwig, linux-crypto,
	linux-riscv, kernel-team

On Sun, 04 Oct 2020 14:16:10 PDT (-0700), ardb@kernel.org wrote:
> On Sun, 4 Oct 2020 at 20:48, Stephan Müller <smueller@chronox.de> wrote:
>>
>> The RISC-V architecture is about to implement the callback
>> random_get_entropy with a function that is not exported to modules.
>
> Why is that? Wouldn't it be better to export the symbol instead?

It's static inline (in our timex.h), so I thought we didn't need to export the
symbol?  Did this just arise because clint_time_val wasn't exported?  That was
fixed before the random_get_entropy() change landed in Linus' tree, so as far
as I know we should be OK here.

If I broke something here it seem better to fix this in the RISC-V port than by
just banning modular compilation of jitterentropy, as that seems like a useful
feature to me.

>> Thus, the Jitter RNG is changed to be only bound statically into the
>> kernel removing the option to compile it as module.
>>
>> Reported-by: Christoph Hellwig <hch@infradead.org>
>> Signed-off-by: Stephan Mueller <smueller@chronox.de>
>> ---
>>  crypto/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/crypto/Kconfig b/crypto/Kconfig
>> index 094ef56ab7b4..5b20087b117f 100644
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -1853,7 +1853,7 @@ config CRYPTO_DRBG
>>  endif  # if CRYPTO_DRBG_MENU
>>
>>  config CRYPTO_JITTERENTROPY
>> -       tristate "Jitterentropy Non-Deterministic Random Number Generator"
>> +       bool "Jitterentropy Non-Deterministic Random Number Generator"
>>         select CRYPTO_RNG
>>         help
>>           The Jitterentropy RNG is a noise that is intended
>> --
>> 2.26.2
>>
>>
>>
>>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-04 21:16     ` Ard Biesheuvel
  2020-10-04 22:05       ` Palmer Dabbelt
@ 2020-10-05  6:19       ` Christoph Hellwig
  2020-10-05  6:24         ` Ard Biesheuvel
  1 sibling, 1 reply; 13+ messages in thread
From: Christoph Hellwig @ 2020-10-05  6:19 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: kernel test robot, Stephan M??ller, Palmer Dabbelt,
	Linux Kernel Mailing List, Christoph Hellwig,
	Linux Crypto Mailing List, linux-riscv, Android Kernel Team

On Sun, Oct 04, 2020 at 11:16:10PM +0200, Ard Biesheuvel wrote:
> On Sun, 4 Oct 2020 at 20:48, Stephan M??ller <smueller@chronox.de> wrote:
> >
> > The RISC-V architecture is about to implement the callback
> > random_get_entropy with a function that is not exported to modules.
> 
> Why is that? Wouldn't it be better to export the symbol instead?

get_cycles is a low-level time keeping detail that really should not
be exported, and at least for RISC-V this would be the only modular
user.  Once that is sorted out I'll audit other common architectures
to drop the export, as it isn't something that should be used in ramdom
driver code.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-05  6:19       ` Christoph Hellwig
@ 2020-10-05  6:24         ` Ard Biesheuvel
  2020-10-05  6:40           ` Stephan Mueller
  0 siblings, 1 reply; 13+ messages in thread
From: Ard Biesheuvel @ 2020-10-05  6:24 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: kernel test robot, Stephan M??ller, Palmer Dabbelt,
	Linux Kernel Mailing List, Linux Crypto Mailing List,
	linux-riscv, Android Kernel Team

On Mon, 5 Oct 2020 at 08:19, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Sun, Oct 04, 2020 at 11:16:10PM +0200, Ard Biesheuvel wrote:
> > On Sun, 4 Oct 2020 at 20:48, Stephan M??ller <smueller@chronox.de> wrote:
> > >
> > > The RISC-V architecture is about to implement the callback
> > > random_get_entropy with a function that is not exported to modules.
> >
> > Why is that? Wouldn't it be better to export the symbol instead?
>
> get_cycles is a low-level time keeping detail that really should not
> be exported, and at least for RISC-V this would be the only modular
> user.  Once that is sorted out I'll audit other common architectures
> to drop the export, as it isn't something that should be used in ramdom
> driver code.

Fair enough.

But this means we should fix the jitterentropy driver rather than
sidestepping the issue by only allowing it to be built in a way where
we don't happen to notice that the symbol in question is not meant for
general consumption.

If jitterentropy is a special case, we could put a alternate
non-'static inline' version of random_get_entropy() in the core
kernel, and only export it if JITTER_ENTROPY is built as a module in
the first place. But I'd prefer it if jitterentropy switches to an API
that is suitable for driver consumption.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-05  6:24         ` Ard Biesheuvel
@ 2020-10-05  6:40           ` Stephan Mueller
  2020-10-05  6:44             ` Christoph Hellwig
  2020-10-05  6:44             ` Ard Biesheuvel
  0 siblings, 2 replies; 13+ messages in thread
From: Stephan Mueller @ 2020-10-05  6:40 UTC (permalink / raw)
  To: Christoph Hellwig, Ard Biesheuvel
  Cc: kernel test robot, Palmer Dabbelt, Linux Kernel Mailing List,
	Linux Crypto Mailing List, linux-riscv, Android Kernel Team

Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:

Hi Ard,

> If jitterentropy is a special case, we could put a alternate
> non-'static inline' version of random_get_entropy() in the core
> kernel, and only export it if JITTER_ENTROPY is built as a module in
> the first place. But I'd prefer it if jitterentropy switches to an API
> that is suitable for driver consumption.

Which API do you have in mind? In user space, I use 
clock_gettime(CLOCK_REALTIME) which also considers the clock source.

Thanks
Stephan



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-05  6:40           ` Stephan Mueller
@ 2020-10-05  6:44             ` Christoph Hellwig
  2020-10-05  6:44             ` Ard Biesheuvel
  1 sibling, 0 replies; 13+ messages in thread
From: Christoph Hellwig @ 2020-10-05  6:44 UTC (permalink / raw)
  To: Stephan Mueller
  Cc: kernel test robot, Palmer Dabbelt, Linux Kernel Mailing List,
	Christoph Hellwig, Thomas Gleixner, Linux Crypto Mailing List,
	linux-riscv, Android Kernel Team, Ard Biesheuvel

[adding Thomas]

On Mon, Oct 05, 2020 at 08:40:25AM +0200, Stephan Mueller wrote:
> > If jitterentropy is a special case, we could put a alternate
> > non-'static inline' version of random_get_entropy() in the core
> > kernel, and only export it if JITTER_ENTROPY is built as a module in
> > the first place. But I'd prefer it if jitterentropy switches to an API
> > that is suitable for driver consumption.
> 
> Which API do you have in mind? In user space, I use 
> clock_gettime(CLOCK_REALTIME) which also considers the clock source.

We could probably add a kernel_clock_gettime which contains the
clock_gettime syscal implementation minus the put_timespec64.  Thomas,
is this something that fits your timekeeping vision?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-05  6:40           ` Stephan Mueller
  2020-10-05  6:44             ` Christoph Hellwig
@ 2020-10-05  6:44             ` Ard Biesheuvel
  2020-10-05  6:56               ` Christoph Hellwig
  2020-10-05  7:45               ` Stephan Mueller
  1 sibling, 2 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2020-10-05  6:44 UTC (permalink / raw)
  To: Stephan Mueller
  Cc: kernel test robot, Palmer Dabbelt, Linux Kernel Mailing List,
	Christoph Hellwig, Linux Crypto Mailing List, linux-riscv,
	Android Kernel Team

On Mon, 5 Oct 2020 at 08:40, Stephan Mueller <smueller@chronox.de> wrote:
>
> Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:
>
> Hi Ard,
>
> > If jitterentropy is a special case, we could put a alternate
> > non-'static inline' version of random_get_entropy() in the core
> > kernel, and only export it if JITTER_ENTROPY is built as a module in
> > the first place. But I'd prefer it if jitterentropy switches to an API
> > that is suitable for driver consumption.
>
> Which API do you have in mind? In user space, I use
> clock_gettime(CLOCK_REALTIME) which also considers the clock source.
>

AFAICT, that call is backed by ktime_get_real_ts64(), which is already
being exported to modules.

Could you please check whether that works for your driver?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-05  6:44             ` Ard Biesheuvel
@ 2020-10-05  6:56               ` Christoph Hellwig
  2020-10-05  7:45               ` Stephan Mueller
  1 sibling, 0 replies; 13+ messages in thread
From: Christoph Hellwig @ 2020-10-05  6:56 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: kernel test robot, Stephan Mueller, Palmer Dabbelt,
	Linux Kernel Mailing List, Christoph Hellwig,
	Linux Crypto Mailing List, linux-riscv, Android Kernel Team,
	Thomas Gleixner

On Mon, Oct 05, 2020 at 08:44:39AM +0200, Ard Biesheuvel wrote:
> On Mon, 5 Oct 2020 at 08:40, Stephan Mueller <smueller@chronox.de> wrote:
> >
> > Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > > If jitterentropy is a special case, we could put a alternate
> > > non-'static inline' version of random_get_entropy() in the core
> > > kernel, and only export it if JITTER_ENTROPY is built as a module in
> > > the first place. But I'd prefer it if jitterentropy switches to an API
> > > that is suitable for driver consumption.
> >
> > Which API do you have in mind? In user space, I use
> > clock_gettime(CLOCK_REALTIME) which also considers the clock source.
> >
> 
> AFAICT, that call is backed by ktime_get_real_ts64(), which is already
> being exported to modules.

Indeed. No need for my earlier idea..

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] crypto: jitterentropy - bind statically into kernel
  2020-10-05  6:44             ` Ard Biesheuvel
  2020-10-05  6:56               ` Christoph Hellwig
@ 2020-10-05  7:45               ` Stephan Mueller
  1 sibling, 0 replies; 13+ messages in thread
From: Stephan Mueller @ 2020-10-05  7:45 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: kernel test robot, Palmer Dabbelt, Linux Kernel Mailing List,
	Christoph Hellwig, Linux Crypto Mailing List, linux-riscv,
	Android Kernel Team

Am Montag, 5. Oktober 2020, 08:44:39 CEST schrieb Ard Biesheuvel:

Hi Ard,

> On Mon, 5 Oct 2020 at 08:40, Stephan Mueller <smueller@chronox.de> wrote:
> > Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:
> > 
> > Hi Ard,
> > 
> > > If jitterentropy is a special case, we could put a alternate
> > > non-'static inline' version of random_get_entropy() in the core
> > > kernel, and only export it if JITTER_ENTROPY is built as a module in
> > > the first place. But I'd prefer it if jitterentropy switches to an API
> > > that is suitable for driver consumption.
> > 
> > Which API do you have in mind? In user space, I use
> > clock_gettime(CLOCK_REALTIME) which also considers the clock source.
> 
> AFAICT, that call is backed by ktime_get_real_ts64(), which is already
> being exported to modules.
> 
> Could you please check whether that works for your driver?

Yes, will do. Thanks.

Ciao
Stephan



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-30  6:56 [PATCH] clocksource: clint: Export clint_time_val for modules Palmer Dabbelt
2020-10-02  6:49 ` get_cycles from modular code in jitterentropy, was " Christoph Hellwig
2020-10-02  6:55   ` Stephan Mueller
2020-10-04 18:48   ` [PATCH] crypto: jitterentropy - bind statically into kernel Stephan Müller
2020-10-04 21:16     ` Ard Biesheuvel
2020-10-04 22:05       ` Palmer Dabbelt
2020-10-05  6:19       ` Christoph Hellwig
2020-10-05  6:24         ` Ard Biesheuvel
2020-10-05  6:40           ` Stephan Mueller
2020-10-05  6:44             ` Christoph Hellwig
2020-10-05  6:44             ` Ard Biesheuvel
2020-10-05  6:56               ` Christoph Hellwig
2020-10-05  7:45               ` Stephan Mueller

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git