Messages in this thread | | | Date | Thu, 19 May 2022 11:13:54 +0200 | Subject | Re: [PATCH v4 1/2] drivers/s390/char: Add Ultravisor io device | From | Janosch Frank <> |
| |
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.
| |