[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201021132433.GI2628@hirez.programming.kicks-ass.net>
Date: Wed, 21 Oct 2020 15:24:33 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc: Borislav Petkov <bp@...en8.de>,
Sultan Alsawaf <sultan@...neltoast.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
kitsunyan <kitsunyan@...mail.cc>,
"Brown, Len" <len.brown@...el.com>, X86 ML <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] x86/msr: do not warn on writes to OC_MAILBOX
On Tue, Oct 20, 2020 at 10:21:48AM -0700, Srinivas Pandruvada wrote:
> On Mon, 2020-10-19 at 19:15 +0200, Borislav Petkov wrote:
> These command id are model specific. There is no guarantee that even
> meaning changes. So I don't think we should write any code in kernel
> which can't stick.
>
>
> > In any case, my point is that we could have a sysfs interface for
> > those userspace-suppliable values like the undervolt value at
> > [31:21],
> > dunno if the index can be inferred by the kernel automatically or
> > enumerated and the commands we should issue ourselves depending on
> > the
> > functionality, etc.
Why not have a full undervolt driver. That is, don't expose OC_MAILBOX
_at_all_, but have a model specific driver that provides undervolt
capabilities.
Someone is now maintaining this thing in userspace, might as well do it
as a kernel driver and keep all the icky bits inside.
Powered by blists - more mailing lists