[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4febd50da7e5007a2797e0f4c969fa5edd0bf725.camel@fb.com>
Date: Thu, 17 Feb 2022 11:47:21 +0000
From: Dmitrii Okunev <xaionaro@...com>
To: "pavel@....cz" <pavel@....cz>,
"qiaowei.ren@...el.com" <qiaowei.ren@...el.com>
CC: "matthew.garrett@...ula.com" <matthew.garrett@...ula.com>,
"greg@...ah.com" <greg@...ah.com>,
"xiaoyan.zhang@...el.com" <xiaoyan.zhang@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"platform-driver-x86@...r.kernel.org"
<platform-driver-x86@...r.kernel.org>,
"gang.wei@...el.com" <gang.wei@...el.com>,
Jonathan McDowell <noodles@...com>
Subject: [discuss] Improve and merge a driver proposed in 2013: sysfs
interfaces to access TXT config space
Hello!
As far as I see the patch wasn't merged. And I see that this is the
only unsolved thread in the discussion:
On Thu, 2013-05-16 at 18:03 +0200, Pavel Machek wrote:
> On Tue 2013-05-14 01:24:43, Qiaowei Ren wrote:
> > These interfaces are located in
> > /sys/devices/platform/intel_txt/config,
> > and including totally 37 files, providing access to Intel TXT
> > configuration registers.
>
> This looks like very wrong interface... equivalent of /dev/mem.
As an active user of these registers I hope it will be merged, so I
would like to improve this patch (or rewrite it from scratch) to make
that happen. Otherwise one have to do hackery around `/dev/mem`, which
also creates problems with proper access control.
To be able to improve the patch, could somebody clarify why exactly
this is a "very wrong interface"?
> > +What: /sys/devices/platform/intel_txt/config/STS_raw
> > +Date: May 2013
> > +KernelVersion: 3.9
> > +Contact: "Qiaowei Ren" <qiaowei.ren@...el.com>
> > +Description: TXT.STS is the general status register. This read-
> > only register
> > + is used by AC modules and the MLE to get the status
> > of various
> > + Intel TXT features.
>
> This is not enough to allow people to understand what this
> does/should
> do, nor does it allow (for example) ARM people to implement something
> compatible.
>
> Is there specific reason why "better" interface is impossible?
I would love to reuse Intel's public documentation [1] to provide a
proper description (with bit layout of the value).
[1] https://cdrdv2.intel.com/v1/dl/getContent/315168
> [...], nor does it allow (for example) ARM people to
> implement something compatible.
Do I understand correctly that a proper documentation of the registers
solves the problem?
> Is there specific reason why "better" interface is impossible?
What are specific problems with the current interface?
Best regards,
Dmitrii Okunev.
Powered by blists - more mailing lists