lkml.org 
[lkml]   [2022]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v4 1/2] drivers/s390/char: Add Ultravisor io device
From
On 5/19/22 07:37, Heiko Carstens wrote:
> On Wed, May 18, 2022 at 03:45:27PM +0200, Janosch Frank wrote:
>>>> + The device is only available if the Ultravisor
>>>> + Facility (158) is present.
>>>
>>> Is there a reason why this is default "y"? If you think this should be
>>> compiled into the kernel if used, then why allow to make it a module
>>> at all?
>>> Instead you could get rid of a couple if lines of code.
>>
>> There was a lot of discussion around this already and the "Y" was chosen as
>> auto-loading this is a pain and therefore the SCLP and CHSC-Misc set it to Y
>> and we took that as an example (Steffen spoke to Peter to get guidance).
>>
>> I'm sure that we want the possibility to have this as a module. Personally
>> I'd choose "m" over "y" since the module is only useful for a very small
>> amount of users.
>
> Why not simply use module_cpu_feature_match() to implement auto module
> loading like we do it for the crypto modules? That would require that
> either the uv facility is represented within elf hwcaps, or
> alternatively the s390 implementation of cpu_feature() needs to be
> changed to work with cpu facilities instead of hwcap bits.
> (see arch/s390/include/asm/cpufeature.h)
>
> This doesn't look too difficult. Or was there a reason not to go this route?

I'd guess we looked into the wrong direction for auto-load.

We'll look into that for 5.20 but we'll take this patch with the "m"
tristate for 5.19.

Thanks for the pointer and review.

\
 
 \ /
  Last update: 2022-05-19 11:15    [W:0.074 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site