* Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function
From: Yu-cheng Yu @ 2019-06-14 15:25 UTC (permalink / raw)
To: Dave Hansen, Andy Lutomirski
Cc: Peter Zijlstra, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
linux-kernel, linux-doc, linux-mm, linux-arch, linux-api,
Arnd Bergmann, Balbir Singh, Borislav Petkov, Cyrill Gorcunov,
Dave Hansen, Eugene Syromiatnikov, Florian Weimer, H.J. Lu,
Jann Horn, Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pavel Machek, Randy Dunlap, Ravi V. Shankar,
Vedvyas Shanbhogue, Dave Martin
In-Reply-To: <ea5e333f-8cd6-8396-635f-a9dc580d5364@intel.com>
On Mon, 2019-06-10 at 15:59 -0700, Dave Hansen wrote:
> On 6/10/19 3:40 PM, Yu-cheng Yu wrote:
> > Ok, we will go back to do_mmap() with MAP_PRIVATE, MAP_NORESERVE and
> > VM_DONTDUMP. The bitmap will cover only 48-bit address space.
>
> Could you make sure to discuss the downsides of only doing a 48-bit
> address space?
The downside is that we cannot load legacy lib's above 48-bit address space, but
currently ld-linux does not do that. Should ld-linux do that in the future,
dlopen() fails. Considering CRIU migration, we probably need to do this anyway?
> What are the reasons behind and implications of VM_DONTDUMP?
The bitmap is very big.
In GDB, it should be easy to tell why a control-protection fault occurred
without the bitmap.
Yu-cheng
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Mauro Carvalho Chehab @ 2019-06-14 15:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jani Nikula, Linux Doc Mailing List, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet
In-Reply-To: <20190614140603.GB7234@kroah.com>
Em Fri, 14 Jun 2019 16:06:03 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Fri, Jun 14, 2019 at 04:42:20PM +0300, Jani Nikula wrote:
> > On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > >
> > > As we don't want a generic Sphinx extension to execute commands,
> > > change the one proposed to Markus to call the abi_book.pl
> > > script.
> > >
> > > Use a script to parse the Documentation/ABI directory and output
> > > it at the admin-guide.
> >
> > We had a legacy kernel-doc perl script so we used that instead of
> > rewriting it in python. Just to keep it bug-for-bug compatible with the
> > past. That was the only reason.
> >
> > I see absolutely zero reason to add a new perl monstrosity with a python
> > extension to call it. All of this could be better done in python,
> > directly.
> >
> > Please don't complicate the documentation build. I know you know we all
> > worked hard to take apart the old DocBook Rube Goldberg machine to
> > replace it with Sphinx. Please don't turn the Sphinx build to another
> > complicated mess.
> >
> > My strong preferences are, in this order:
> >
> > 1) Convert the ABI documentation to reStructuredText
>
> What would that exactly look like? What would it require for new
> developers for when they write new entries? Why not rely on a helper
> script, that allows us to validate things better?
Funny enough, this e-mail arrived here after Greg's reply, and my
reply over his one :-)
-
With regards to the script, my idea is to have it run on a new
"validate" mode, when the Kernel is built with COMPILE_TEST:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=abi_patches_v4
NB: the last patch is not yet... somehow, the building system is not
passing CONFIG_WARN_ABI_ERRORS to Documentation/Makefile. I'm
debugging it.
Personally, I would prefer to keep it the way it is, with two
additions:
1) I would add a SPDX header at the fist line of each file there;
2) It would make sense to have a new field - or indicator - to let
add ReST markups at the description.
The advantage of using a parseable ABI file is that it is possible
to parse it, for example, to search for a symbol:
$ ./scripts/get_abi.pl voltage_max
/sys/class/power_supply/<supply_name>/voltage_max
-------------------------------------------------
Date: January 2008
Contact: linux-pm@vger.kernel.org
Defined on file: Documentation/ABI/testing/sysfs-class-power
Description:
Reports the maximum VBUS voltage the supply can support.
Access: Read
Valid values: Represented in microvolts
...
>
> > 2) Have the python extension read the ABI files directly, without an
> > extra pipeline.
>
> He who writes the script, get's to dictate the language of the script :)
No idea about how much time it would take if written in python,
but this perl script is really fast:
$ time ./scripts/get_abi.pl search voltage_max >/dev/null
real 0m0,139s
user 0m0,132s
sys 0m0,006s
That's the time it takes here (SSD disks) to read all files under
Documentation/ABI, parse them and seek for a string.
That's about half of the time a python script takes to just import the
the sphinx modules and print its version, running at the same machine:
$ time sphinx-build --version >/dev/null
real 0m0,224s
user 0m0,199s
sys 0m0,024s
> Personally, this looks sane to me, I'm going to apply the ABI fixups to
> my tree at least, and then see how the script works out. The script can
> always be replaced with a different one in a different language at a
> later point in time of people think it really mattes.
Thanks,
Mauro
^ permalink raw reply
* [PATCH v2] media: docs: v4l2-controls: fix sentence rendered in a nonsense way
From: Luca Ceresoli @ 2019-06-14 15:14 UTC (permalink / raw)
To: linux-media
Cc: Luca Ceresoli, Mauro Carvalho Chehab, Hans Verkuil, linux-kernel,
linux-doc
This sentence renders as:
> Since such compound controls need to expose more information about
> themselves than is possible with ioctls VIDIOC_QUERYCTRL,
> VIDIOC_QUERY_EXT_CTRL and VIDIOC_QUERYMENU the VIDIOC_QUERY_EXT_CTRL
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
> ioctl was added.
This does not make sense. Fix by providing an explicit link text. This
results in:
> Since such compound controls need to expose more information about
> themselves than is possible with VIDIOC_QUERYCTRL the
> VIDIOC_QUERY_EXT_CTRL ioctl was added.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
Documentation/media/uapi/v4l/extended-controls.rst | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 0e9787072a41..655362483730 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -85,11 +85,10 @@ be able to see such compound controls. In other words, these controls
with compound types should only be used programmatically.
Since such compound controls need to expose more information about
-themselves than is possible with
-:ref:`VIDIOC_QUERYCTRL` the
-:ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
-particular, this ioctl gives the dimensions of the N-dimensional array
-if this control consists of more than one element.
+themselves than is possible with :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>`
+the :ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
+particular, this ioctl gives the dimensions of the N-dimensional array if
+this control consists of more than one element.
.. note::
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 1/9] media: docs: v4l2-controls: fix sentence rendered in a nonsense way
From: Luca Ceresoli @ 2019-06-14 15:16 UTC (permalink / raw)
To: Hans Verkuil, linux-media; +Cc: Mauro Carvalho Chehab, linux-kernel, linux-doc
In-Reply-To: <069ac18c-7b9e-652a-1ff8-35fca09e6538@xs4all.nl>
Hi Hans,
On 14/06/19 09:14, Hans Verkuil wrote:
> On 6/13/19 4:18 PM, Luca Ceresoli wrote:
>> This sentence renders as:
>>
>>> Since such compound controls need to expose more information about
>>> themselves than is possible with ioctls VIDIOC_QUERYCTRL,
>>> VIDIOC_QUERY_EXT_CTRL and VIDIOC_QUERYMENU the VIDIOC_QUERY_EXT_CTRL
>> ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
>>> ioctl was added.
>>
>> This does not make sense. Fix by providing an explicit link text. This
>> results in:
>>
>>> Since such compound controls need to expose more information about
>>> themselves than is possible with VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU
>>> the VIDIOC_QUERY_EXT_CTRL ioctl was added.
>>
>> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
>> ---
>> Documentation/media/uapi/v4l/extended-controls.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
>> index 24274b398e63..0968aa9cd167 100644
>> --- a/Documentation/media/uapi/v4l/extended-controls.rst
>> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
>> @@ -86,7 +86,7 @@ with compound types should only be used programmatically.
>>
>> Since such compound controls need to expose more information about
>> themselves than is possible with
>> -:ref:`VIDIOC_QUERYCTRL` the
>> +:ref:`VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>` the
>
> This should just refer to VIDIOC_QUERYCTRL, not QUERYMENU. So this
> becomes: :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>`
Thanks for your prompt review. v2 on its way with this patch only, since
you already added the other ones in your latest pull request.
--
Luca
^ permalink raw reply
* Re: [PATCH v3] Add a document on rebasing and merging
From: Jonathan Corbet @ 2019-06-14 14:25 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: open list:DOCUMENTATION, LKML, Theodore Ts'o,
Geert Uytterhoeven, David Rientjes, Jani Nikula, Michael Ellerman
In-Reply-To: <CACT4Y+avfTeZTmhti=7nEadthZZpTnOCTdEuG2S7PovmAMkhZQ@mail.gmail.com>
On Fri, 14 Jun 2019 11:59:03 +0200
Dmitry Vyukov <dvyukov@google.com> wrote:
> I will appreciate if you elaborate a bit on this "scale of the
> project". I wondered about reasons for having the current hierarchy of
> trees and complex merging for a while, but wasn't able to find any
> rationale. What exactly scale do you mean? I know a number of projects
> that are comparable to Linux kernel, with the largest being 2 orders
> of magnitude larger than kernel both in terms of code size and rate of
> change, that use single tree and linear history.
I'm not sure what projects you're talking about, so it's hard to compare.
During the 5.2 merge window, Linus did 209 pulls, bringing in just over
12,000 changesets, from on the order of 1600 developers. Even if, at the
beginning of the window, each of those pulls was set up to be a
fast-forward, they would no longer be positioned that way once the first
pull was done.
Are you really saying that subsystem maintainers should be continuously
rebasing their trees to avoid merges at the top level? Do you see how
much work that would take, how badly it would obscure the development
history, and how many bugs it would introduce? Or perhaps I misunderstood
what you're arguing for?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Jonathan Corbet @ 2019-06-14 14:15 UTC (permalink / raw)
To: Markus Heiser
Cc: Jani Nikula, Mauro Carvalho Chehab, Linux Doc Mailing List,
Greg Kroah-Hartman, Mauro Carvalho Chehab, Mauro Carvalho Chehab,
linux-kernel
In-Reply-To: <2955920a-3d6a-8e41-e8fe-b7db3cefed8b@darmarit.de>
On Fri, 14 Jun 2019 16:10:31 +0200
Markus Heiser <markus.heiser@darmarit.de> wrote:
> I agree with Jani. No matter how the decision ends, since I can't help here, I'd
> rather not show up in the copyright.
Is there something specific you are asking us to do here?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Jonathan Corbet @ 2019-06-14 14:14 UTC (permalink / raw)
To: Jani Nikula
Cc: Greg Kroah-Hartman, Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel
In-Reply-To: <87lfy4uuzs.fsf@intel.com>
On Fri, 14 Jun 2019 17:00:55 +0300
Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Fri, 14 Jun 2019, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> >> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> >> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >> >
> >> > Add a script to parse the Documentation/ABI files and produce
> >> > an output with all entries inside an ABI (sub)directory.
> >> >
> >> > Right now, it outputs its contents on ReST format. It shouldn't
> >> > be hard to make it produce other kind of outputs, since the ABI
> >> > file parser is implemented in separate than the output generator.
> >>
> >> Hum, or just convert the ABI files to rst directly.
> >
> > And what would that look like?
>
> That pretty much depends on the requirements we want to set on both the
> ABI source files and the generated output. Obviously the requirements
> can be conflicting; might be hard to produce fancy output if the input
> is very limited.
The real question, I guess, is: is there anything else that depends on the
current format of those files? That could make reformatting them harder.
Otherwise it seems like Jani's fieldlist idea might have some potential.
We could consider a *really* simple preprocessing step if we really wanted
("prepend a colon on relevant lines and join with the following line if
need be") to keep the current format nearly unchanged.
jon
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Markus Heiser @ 2019-06-14 14:10 UTC (permalink / raw)
To: Jani Nikula, Mauro Carvalho Chehab, Linux Doc Mailing List,
Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <87o930uvur.fsf@intel.com>
Am 14.06.19 um 15:42 schrieb Jani Nikula:
> On Thu, 13 Jun 2019, Mauro Carvalho Chehab<mchehab+samsung@kernel.org> wrote:
>> From: Mauro Carvalho Chehab<mchehab@s-opensource.com>
>>
>> As we don't want a generic Sphinx extension to execute commands,
>> change the one proposed to Markus to call the abi_book.pl
>> script.
>>
>> Use a script to parse the Documentation/ABI directory and output
>> it at the admin-guide.
> We had a legacy kernel-doc perl script so we used that instead of
> rewriting it in python. Just to keep it bug-for-bug compatible with the
> past. That was the only reason.
>
> I see absolutely zero reason to add a new perl monstrosity with a python
> extension to call it. All of this could be better done in python,
> directly.
>
> Please don't complicate the documentation build. I know you know we all
> worked hard to take apart the old DocBook Rube Goldberg machine to
> replace it with Sphinx. Please don't turn the Sphinx build to another
> complicated mess.
>
> My strong preferences are, in this order:
>
> 1) Convert the ABI documentation to reStructuredText
>
> 2) Have the python extension read the ABI files directly, without an
> extra pipeline.
>
I agree with Jani. No matter how the decision ends, since I can't help here, I'd
rather not show up in the copyright.
-- Markus --
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Greg Kroah-Hartman @ 2019-06-14 14:06 UTC (permalink / raw)
To: Jani Nikula
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <87o930uvur.fsf@intel.com>
On Fri, Jun 14, 2019 at 04:42:20PM +0300, Jani Nikula wrote:
> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >
> > As we don't want a generic Sphinx extension to execute commands,
> > change the one proposed to Markus to call the abi_book.pl
> > script.
> >
> > Use a script to parse the Documentation/ABI directory and output
> > it at the admin-guide.
>
> We had a legacy kernel-doc perl script so we used that instead of
> rewriting it in python. Just to keep it bug-for-bug compatible with the
> past. That was the only reason.
>
> I see absolutely zero reason to add a new perl monstrosity with a python
> extension to call it. All of this could be better done in python,
> directly.
>
> Please don't complicate the documentation build. I know you know we all
> worked hard to take apart the old DocBook Rube Goldberg machine to
> replace it with Sphinx. Please don't turn the Sphinx build to another
> complicated mess.
>
> My strong preferences are, in this order:
>
> 1) Convert the ABI documentation to reStructuredText
What would that exactly look like? What would it require for new
developers for when they write new entries? Why not rely on a helper
script, that allows us to validate things better?
> 2) Have the python extension read the ABI files directly, without an
> extra pipeline.
He who writes the script, get's to dictate the language of the script :)
Personally, this looks sane to me, I'm going to apply the ABI fixups to
my tree at least, and then see how the script works out. The script can
always be replaced with a different one in a different language at a
later point in time of people think it really mattes.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Mauro Carvalho Chehab @ 2019-06-14 13:58 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jani Nikula, Linux Doc Mailing List, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet
In-Reply-To: <20190614133933.GA1076@kroah.com>
Em Fri, 14 Jun 2019 15:39:33 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> > On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > >
> > > Add a script to parse the Documentation/ABI files and produce
> > > an output with all entries inside an ABI (sub)directory.
> > >
> > > Right now, it outputs its contents on ReST format. It shouldn't
> > > be hard to make it produce other kind of outputs, since the ABI
> > > file parser is implemented in separate than the output generator.
> >
> > Hum, or just convert the ABI files to rst directly.
Converting ABI files to rst could be easily done using a modified
version of my script (plus the produced files will likely need some
manual review).
There is a drawback though: we'll lose the capability of being able
to parse ABI files via an script, as people would be freed to use a
different syntax.
We could minimize it by using things like:
:What:
:Kernel Version:
...
> And what would that look like?
That's the big question :-)
If you prefer something like that, I can write the patches.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Jani Nikula @ 2019-06-14 14:00 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <20190614133933.GA1076@kroah.com>
On Fri, 14 Jun 2019, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
>> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>> >
>> > Add a script to parse the Documentation/ABI files and produce
>> > an output with all entries inside an ABI (sub)directory.
>> >
>> > Right now, it outputs its contents on ReST format. It shouldn't
>> > be hard to make it produce other kind of outputs, since the ABI
>> > file parser is implemented in separate than the output generator.
>>
>> Hum, or just convert the ABI files to rst directly.
>
> And what would that look like?
That pretty much depends on the requirements we want to set on both the
ABI source files and the generated output. Obviously the requirements
can be conflicting; might be hard to produce fancy output if the input
is very limited.
At the bare minimum, you could convert the files to contain
reStructuredText field lists [1]. Add a colon at the start of the field
name, and make sure field bodies (values) are not empty.
Conversion of a file selected at random; I've only added ":" and "N/A".
diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu
index 33c133e2a631..34c218b344fb 100644
--- a/Documentation/ABI/stable/sysfs-devices-system-cpu
+++ b/Documentation/ABI/stable/sysfs-devices-system-cpu
@@ -1,19 +1,20 @@
-What: /sys/devices/system/cpu/dscr_default
-Date: 13-May-2014
-KernelVersion: v3.15.0
-Contact:
-Description: Writes are equivalent to writing to
+:What: /sys/devices/system/cpu/dscr_default
+:Date: 13-May-2014
+:KernelVersion: v3.15.0
+:Contact: N/A
+:Description: Writes are equivalent to writing to
/sys/devices/system/cpu/cpuN/dscr on all CPUs.
Reads return the last written value or 0.
This value is not a global default: it is a way to set
all per-CPU defaults at the same time.
-Values: 64 bit unsigned integer (bit field)
+:Values: 64 bit unsigned integer (bit field)
-What: /sys/devices/system/cpu/cpu[0-9]+/dscr
-Date: 13-May-2014
-KernelVersion: v3.15.0
-Contact:
-Description: Default value for the Data Stream Control Register (DSCR) on
+
+:What: /sys/devices/system/cpu/cpu[0-9]+/dscr
+:Date: 13-May-2014
+:KernelVersion: v3.15.0
+:Contact: N/A
+:Description: Default value for the Data Stream Control Register (DSCR) on
a CPU.
This default value is used when the kernel is executing and
for any process that has not set the DSCR itself.
@@ -22,4 +23,4 @@ Description: Default value for the Data Stream Control Register (DSCR) on
on any CPU where it executes (overriding the value described
here).
If set by a process it will be inherited by child processes.
-Values: 64 bit unsigned integer (bit field)
+:Values: 64 bit unsigned integer (bit field)
---
Of course, you'd still need to add higher level files to include the ABI
files.
At the other end, you could add structure and syntax to your heart's
content, and make the output fancier too.
BR,
Jani.
[1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#field-lists
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply related
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Greg Kroah-Hartman @ 2019-06-14 13:39 UTC (permalink / raw)
To: Jani Nikula
Cc: Mauro Carvalho Chehab, Linux Doc Mailing List,
Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <87r27wuwc3.fsf@intel.com>
On Fri, Jun 14, 2019 at 04:31:56PM +0300, Jani Nikula wrote:
> On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >
> > Add a script to parse the Documentation/ABI files and produce
> > an output with all entries inside an ABI (sub)directory.
> >
> > Right now, it outputs its contents on ReST format. It shouldn't
> > be hard to make it produce other kind of outputs, since the ABI
> > file parser is implemented in separate than the output generator.
>
> Hum, or just convert the ABI files to rst directly.
And what would that look like?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 12/14] doc-rst: add ABI documentation to the admin-guide book
From: Jani Nikula @ 2019-06-14 13:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mauro Carvalho Chehab
In-Reply-To: <9da2a7f6ff57d9d53dcbb964eb310f7956522870.1560477540.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> As we don't want a generic Sphinx extension to execute commands,
> change the one proposed to Markus to call the abi_book.pl
> script.
>
> Use a script to parse the Documentation/ABI directory and output
> it at the admin-guide.
We had a legacy kernel-doc perl script so we used that instead of
rewriting it in python. Just to keep it bug-for-bug compatible with the
past. That was the only reason.
I see absolutely zero reason to add a new perl monstrosity with a python
extension to call it. All of this could be better done in python,
directly.
Please don't complicate the documentation build. I know you know we all
worked hard to take apart the old DocBook Rube Goldberg machine to
replace it with Sphinx. Please don't turn the Sphinx build to another
complicated mess.
My strong preferences are, in this order:
1) Convert the ABI documentation to reStructuredText
2) Have the python extension read the ABI files directly, without an
extra pipeline.
BR,
Jani.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/admin-guide/abi-obsolete.rst | 10 ++
> Documentation/admin-guide/abi-removed.rst | 4 +
> Documentation/admin-guide/abi-stable.rst | 13 ++
> Documentation/admin-guide/abi-testing.rst | 19 +++
> Documentation/admin-guide/abi.rst | 11 ++
> Documentation/admin-guide/index.rst | 1 +
> Documentation/conf.py | 2 +-
> Documentation/sphinx/kernel_abi.py | 155 +++++++++++++++++++++
> 8 files changed, 214 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/admin-guide/abi-obsolete.rst
> create mode 100644 Documentation/admin-guide/abi-removed.rst
> create mode 100644 Documentation/admin-guide/abi-stable.rst
> create mode 100644 Documentation/admin-guide/abi-testing.rst
> create mode 100644 Documentation/admin-guide/abi.rst
> create mode 100644 Documentation/sphinx/kernel_abi.py
>
> diff --git a/Documentation/admin-guide/abi-obsolete.rst b/Documentation/admin-guide/abi-obsolete.rst
> new file mode 100644
> index 000000000000..cda9168445a5
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-obsolete.rst
> @@ -0,0 +1,10 @@
> +ABI obsolete symbols
> +====================
> +
> +Documents interfaces that are still remaining in the kernel, but are
> +marked to be removed at some later point in time.
> +
> +The description of the interface will document the reason why it is
> +obsolete and when it can be expected to be removed.
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/obsolete
> diff --git a/Documentation/admin-guide/abi-removed.rst b/Documentation/admin-guide/abi-removed.rst
> new file mode 100644
> index 000000000000..497978fc9632
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-removed.rst
> @@ -0,0 +1,4 @@
> +ABI removed symbols
> +===================
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/removed
> diff --git a/Documentation/admin-guide/abi-stable.rst b/Documentation/admin-guide/abi-stable.rst
> new file mode 100644
> index 000000000000..7495d7a35048
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-stable.rst
> @@ -0,0 +1,13 @@
> +ABI stable symbols
> +==================
> +
> +Documents the interfaces that the developer has defined to be stable.
> +
> +Userspace programs are free to use these interfaces with no
> +restrictions, and backward compatibility for them will be guaranteed
> +for at least 2 years.
> +
> +Most interfaces (like syscalls) are expected to never change and always
> +be available.
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/stable
> diff --git a/Documentation/admin-guide/abi-testing.rst b/Documentation/admin-guide/abi-testing.rst
> new file mode 100644
> index 000000000000..5c886fc50b9e
> --- /dev/null
> +++ b/Documentation/admin-guide/abi-testing.rst
> @@ -0,0 +1,19 @@
> +ABI testing symbols
> +===================
> +
> +Documents interfaces that are felt to be stable,
> +as the main development of this interface has been completed.
> +
> +The interface can be changed to add new features, but the
> +current interface will not break by doing this, unless grave
> +errors or security problems are found in them.
> +
> +Userspace programs can start to rely on these interfaces, but they must
> +be aware of changes that can occur before these interfaces move to
> +be marked stable.
> +
> +Programs that use these interfaces are strongly encouraged to add their
> +name to the description of these interfaces, so that the kernel
> +developers can easily notify them if any changes occur.
> +
> +.. kernel-abi:: $srctree/Documentation/ABI/testing
> diff --git a/Documentation/admin-guide/abi.rst b/Documentation/admin-guide/abi.rst
> new file mode 100644
> index 000000000000..3b9645c77469
> --- /dev/null
> +++ b/Documentation/admin-guide/abi.rst
> @@ -0,0 +1,11 @@
> +=====================
> +Linux ABI description
> +=====================
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + abi-stable
> + abi-testing
> + abi-obsolete
> + abi-removed
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 8001917ee012..20c3020fd73c 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -16,6 +16,7 @@ etc.
> README
> kernel-parameters
> devices
> + abi
>
> This section describes CPU vulnerabilities and their mitigations.
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 7ace3f8852bd..598256fb5c98 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,7 @@ needs_sphinx = '1.3'
> # Add any Sphinx extension module names here, as strings. They can be
> # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
> # ones.
> -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig']
> +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig', 'kernel_abi']
>
> # The name of the math extension changed on Sphinx 1.4
> if (major == 1 and minor > 3) or (major > 1):
> diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py
> new file mode 100644
> index 000000000000..32ce90775d96
> --- /dev/null
> +++ b/Documentation/sphinx/kernel_abi.py
> @@ -0,0 +1,155 @@
> +# -*- coding: utf-8; mode: python -*-
> +u"""
> + kernel-abi
> + ~~~~~~~~~~
> +
> + Implementation of the ``kernel-abi`` reST-directive.
> +
> + :copyright: Copyright (C) 2016 Markus Heiser
> + :copyright: Copyright (C) 2016 Mauro Carvalho Chehab
> + :license: GPL Version 2, June 1991 see Linux/COPYING for details.
> +
> + The ``kernel-abi`` (:py:class:`KernelCmd`) directive calls the
> + scripts/get_abi.pl script to parse the Kernel ABI files.
> +
> + Overview of directive's argument and options.
> +
> + .. code-block:: rst
> +
> + .. kernel-abi:: <ABI directory location>
> + :debug:
> +
> + The argument ``<ABI directory location>`` is required. It contains the
> + location of the ABI files to be parsed.
> +
> + ``debug``
> + Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
> + what reST is generated.
> +
> +"""
> +
> +import sys
> +import os
> +from os import path
> +import subprocess
> +
> +from sphinx.ext.autodoc import AutodocReporter
> +
> +from docutils import nodes
> +from docutils.parsers.rst import Directive, directives
> +from docutils.statemachine import ViewList
> +from docutils.utils.error_reporting import ErrorString
> +
> +
> +__version__ = '1.0'
> +
> +# We can't assume that six is installed
> +PY3 = sys.version_info[0] == 3
> +PY2 = sys.version_info[0] == 2
> +if PY3:
> + # pylint: disable=C0103, W0622
> + unicode = str
> + basestring = str
> +
> +def setup(app):
> +
> + app.add_directive("kernel-abi", KernelCmd)
> + return dict(
> + version = __version__
> + , parallel_read_safe = True
> + , parallel_write_safe = True
> + )
> +
> +class KernelCmd(Directive):
> +
> + u"""KernelABI (``kernel-abi``) directive"""
> +
> + required_arguments = 1
> + optional_arguments = 0
> + has_content = False
> + final_argument_whitespace = True
> +
> + option_spec = {
> + "debug" : directives.flag
> + }
> +
> + def warn(self, message, **replace):
> + replace["fname"] = self.state.document.current_source
> + replace["line_no"] = replace.get("line_no", self.lineno)
> + message = ("%(fname)s:%(line_no)s: [kernel-abi WARN] : " + message) % replace
> + self.state.document.settings.env.app.warn(message, prefix="")
> +
> + def run(self):
> +
> + doc = self.state.document
> + if not doc.settings.file_insertion_enabled:
> + raise self.warning("docutils: file insertion disabled")
> +
> + env = doc.settings.env
> + cwd = path.dirname(doc.current_source)
> + cmd = "get_abi.pl rest --dir "
> + cmd += self.arguments[0]
> +
> + srctree = path.abspath(os.environ["srctree"])
> +
> + fname = cmd
> +
> + # extend PATH with $(srctree)/scripts
> + path_env = os.pathsep.join([
> + srctree + os.sep + "scripts",
> + os.environ["PATH"]
> + ])
> + shell_env = os.environ.copy()
> + shell_env["PATH"] = path_env
> + shell_env["srctree"] = srctree
> +
> + lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env)
> + nodeList = self.nestedParse(lines, fname)
> + return nodeList
> +
> + def runCmd(self, cmd, **kwargs):
> + u"""Run command ``cmd`` and return it's stdout as unicode."""
> +
> + try:
> + proc = subprocess.Popen(
> + cmd
> + , stdout = subprocess.PIPE
> + , stderr = subprocess.PIPE
> + , universal_newlines = True
> + , **kwargs
> + )
> + out, err = proc.communicate()
> + if err:
> + self.warn(err)
> + if proc.returncode != 0:
> + raise self.severe(
> + u"command '%s' failed with return code %d"
> + % (cmd, proc.returncode)
> + )
> + except OSError as exc:
> + raise self.severe(u"problems with '%s' directive: %s."
> + % (self.name, ErrorString(exc)))
> + return unicode(out)
> +
> + def nestedParse(self, lines, fname):
> + content = ViewList()
> + node = nodes.section()
> +
> + if "debug" in self.options:
> + code_block = "\n\n.. code-block:: rst\n :linenos:\n"
> + for l in lines.split("\n"):
> + code_block += "\n " + l
> + lines = code_block + "\n\n"
> +
> + for c, l in enumerate(lines.split("\n")):
> + content.append(l, fname, c)
> +
> + buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
> + self.state.memo.title_styles = []
> + self.state.memo.section_level = 0
> + self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter)
> + try:
> + self.state.nested_parse(content, 0, node, match_titles=1)
> + finally:
> + self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
> + return node.children
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 05/14] scripts: add an script to parse the ABI files
From: Jani Nikula @ 2019-06-14 13:31 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Mauro Carvalho Chehab
In-Reply-To: <196fb3c497546f923bf5d156c3fddbe74a4913bc.1560477540.git.mchehab+samsung@kernel.org>
On Thu, 13 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> Add a script to parse the Documentation/ABI files and produce
> an output with all entries inside an ABI (sub)directory.
>
> Right now, it outputs its contents on ReST format. It shouldn't
> be hard to make it produce other kind of outputs, since the ABI
> file parser is implemented in separate than the output generator.
Hum, or just convert the ABI files to rst directly.
BR,
Jani.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> scripts/get_abi.pl | 212 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 212 insertions(+)
> create mode 100755 scripts/get_abi.pl
>
> diff --git a/scripts/get_abi.pl b/scripts/get_abi.pl
> new file mode 100755
> index 000000000000..f7c9944a833c
> --- /dev/null
> +++ b/scripts/get_abi.pl
> @@ -0,0 +1,212 @@
> +#!/usr/bin/perl
> +
> +use strict;
> +use Pod::Usage;
> +use Getopt::Long;
> +use File::Find;
> +use Fcntl ':mode';
> +
> +my $help;
> +my $man;
> +my $debug;
> +
> +GetOptions(
> + "debug|d+" => \$debug,
> + 'help|?' => \$help,
> + man => \$man
> +) or pod2usage(2);
> +
> +pod2usage(1) if $help;
> +pod2usage(-exitstatus => 0, -verbose => 2) if $man;
> +
> +pod2usage(2) if (scalar @ARGV != 1);
> +
> +my ($prefix) = @ARGV;
> +
> +require Data::Dumper if ($debug);
> +
> +my %data;
> +
> +#
> +# Displays an error message, printing file name and line
> +#
> +sub parse_error($$$$) {
> + my ($file, $ln, $msg, $data) = @_;
> +
> + print STDERR "file $file#$ln: $msg at\n\t$data";
> +}
> +
> +#
> +# Parse an ABI file, storing its contents at %data
> +#
> +sub parse_abi {
> + my $file = $File::Find::name;
> +
> + my $mode = (stat($file))[2];
> + return if ($mode & S_IFDIR);
> + return if ($file =~ m,/README,);
> +
> + my $name = $file;
> + $name =~ s,.*/,,;
> +
> + my $type = $file;
> + $type =~ s,.*/(.*)/.*,$1,;
> +
> + my $what;
> + my $new_what;
> + my $tag;
> + my $ln;
> +
> + print STDERR "Opening $file\n" if ($debug > 1);
> + open IN, $file;
> + while(<IN>) {
> + $ln++;
> + if (m/^(\S+):\s*(.*)/i) {
> + my $new_tag = lc($1);
> + my $content = $2;
> +
> + if (!($new_tag =~ m/(what|date|kernelversion|contact|description|users)/)) {
> + if ($tag eq "description") {
> + $data{$what}->{$tag} .= "\n$content";;
> + $data{$what}->{$tag} =~ s/\n+$//;
> + next;
> + } else {
> + parse_error($file, $ln, "tag '$tag' is invalid", $_);
> + }
> + }
> +
> + if ($new_tag =~ m/what/) {
> + if ($tag =~ m/what/) {
> + $what .= ", " . $content;
> + } else {
> + $what = $content;
> + $new_what = 1;
> + }
> + $tag = $new_tag;
> + next;
> + }
> +
> + $tag = $new_tag;
> +
> + if ($new_what) {
> + $new_what = 0;
> +
> + $data{$what}->{type} = $type;
> + $data{$what}->{file} = $name;
> + print STDERR "\twhat: $what\n" if ($debug > 1);
> + }
> +
> + if (!$what) {
> + parse_error($file, $ln, "'What:' should come first:", $_);
> + next;
> + }
> + $data{$what}->{$tag} = $content;
> + next;
> + }
> +
> + # Silently ignore any headers before the database
> + next if (!$tag);
> +
> + if (m/^\s*(.*)/) {
> + $data{$what}->{$tag} .= "\n$1";
> + $data{$what}->{$tag} =~ s/\n+$//;
> + next;
> + }
> +
> + # Everything else is error
> + parse_error($file, $ln, "Unexpected line:", $_);
> + }
> + close IN;
> +}
> +
> +# Outputs the output on ReST format
> +sub output_rest {
> + foreach my $what (sort keys %data) {
> + my $type = $data{$what}->{type};
> + my $file = $data{$what}->{file};
> +
> + my $w = $what;
> + $w =~ s/([\(\)\_\-\*\=\^\~\\])/\\$1/g;
> +
> + print "$w\n\n";
> + print "- defined on file $file (type: $type)\n\n::\n\n";
> +
> + my $desc = $data{$what}->{description};
> + $desc =~ s/^\s+//;
> +
> + # Remove title markups from the description, as they won't work
> + $desc =~ s/\n[\-\*\=\^\~]+\n/\n/g;
> +
> + # put everything inside a code block
> + $desc =~ s/\n/\n /g;
> +
> +
> + if (!($desc =~ /^\s*$/)) {
> + print " $desc\n\n";
> + } else {
> + print " DESCRIPTION MISSING\n\n";
> + }
> + }
> +}
> +
> +#
> +# Parses all ABI files located at $prefix dir
> +#
> +find({wanted =>\&parse_abi, no_chdir => 1}, $prefix);
> +
> +print STDERR Data::Dumper->Dump([\%data], [qw(*data)]) if ($debug);
> +
> +#
> +# Outputs an ReST file with the ABI contents
> +#
> +output_rest
> +
> +
> +__END__
> +
> +=head1 NAME
> +
> +abi_book.pl - parse the Linux ABI files and produce a ReST book.
> +
> +=head1 SYNOPSIS
> +
> +B<abi_book.pl> [--debug] <ABI_DIR>]
> +
> +=head1 OPTIONS
> +
> +=over 8
> +
> +=item B<--debug>
> +
> +Put the script in verbose mode, useful for debugging. Can be called multiple
> +times, to increase verbosity.
> +
> +=item B<--help>
> +
> +Prints a brief help message and exits.
> +
> +=item B<--man>
> +
> +Prints the manual page and exits.
> +
> +=back
> +
> +=head1 DESCRIPTION
> +
> +Parse the Linux ABI files from ABI DIR (usually located at Documentation/ABI)
> +and produce a ReST book containing the Linux ABI.
> +
> +=head1 BUGS
> +
> +Report bugs to Mauro Carvalho Chehab <mchehab@s-opensource.com>
> +
> +=head1 COPYRIGHT
> +
> +Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab@s-opensource.com>.
> +
> +License GPLv2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>.
> +
> +This is free software: you are free to change and redistribute it.
> +There is NO WARRANTY, to the extent permitted by law.
> +
> +=cut
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
From: Guenter Roeck @ 2019-06-14 12:37 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-watchdog@vger.kernel.org, Wim Van Sebroeck, Jonathan Corbet,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Esben Haabendal, Jerry Hoemann, Rasmus Villemoes
In-Reply-To: <56280052-9437-9813-a24e-125abb876762@prevas.dk>
On 6/14/19 1:41 AM, Rasmus Villemoes wrote:
> On 07/06/2019 20.38, Guenter Roeck wrote:
>> On Wed, Jun 05, 2019 at 02:06:44PM +0000, Rasmus Villemoes wrote:
>>> When the watchdog device is not open by userspace, the kernel takes
>>> care of pinging it. When the open_timeout feature is in use, we should
>>> ensure that the hardware fires close to open_timeout seconds after the
>>> kernel has assumed responsibility for the device.
>>>
>>> To do this, simply reuse the logic that is already in place for
>>> ensuring the same thing when userspace is responsible for regularly
>>> pinging the device:
>>>
>>> - When watchdog_active(wdd), this patch doesn't change anything.
>>>
>>> - When !watchdoc_active(wdd), the "virtual timeout" should be taken to
>>
>> s/watchdoc_active/watchdog_active/
>>
>> otherwise
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Thanks! Wim, can you fix up if/when applying, or do you prefer I resend?
>
I made the change when applying the patch to my watchdog-next branch,
and Wim usually picks up patches from there, so we should be good.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Sumit Garg @ 2019-06-14 10:41 UTC (permalink / raw)
To: Sasha Levin
Cc: peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <CAFA6WYMOjgHRw9RVrjherNo0ZNbTtEonPwSFFC0dT4CZO=A1NQ@mail.gmail.com>
On Wed, 5 Jun 2019 at 16:39, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Wed, 5 Jun 2019 at 01:39, Sasha Levin <sashal@kernel.org> wrote:
> >
> > On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
> > >On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
> > >> + /* Open context with TEE driver */
> > >> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
> > >> + NULL);
> > >> + if (IS_ERR(pvt_data->ctx)) {
> > >> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
> > >
> > >Is this well tested? I see this misleading error multiple times as
> > >follows although TEE driver works pretty well.
> >
> > Yes, this was all functionally tested.
>
> Can you share your build instructions and testing approach?
>
> >
> > Why is this error message misleading? I'd be happy to fix it.
>
But still this message should be updated to represent correct status.
Maybe something like:
dev_warn(dev, "waiting for OP-TEE to be alive\n");
> IIUC, here you are trying to resolve dependency with OP-TEE driver
> using "-EPROBE_DEFER". So user shouldn't be prompted with error
> messages until OP-TEE driver comes up.
>
> BTW, for me this OP-TEE driver dependency seems not to work, boot is
> simply stuck waiting for device. Probably the reason being this fTPM
> driver is a platform driver and OP-TEE NOT a platform driver.
>
Apologies for the noise here. It works as expected.
-Sumit
> >
> > >Module built with "CONFIG_TCG_FTPM_TEE=y"
> > >
> > >[ 1.436878] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> > >[ 1.509471] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> > >[ 1.517268] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> > >[ 1.525596] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
> >
> > Does the TEE have the fTPM implementation and such? Could you provide
> > details about your testing environment (hardware, fTPM verions, etc)?
> >
>
> I just did a sanity check on my arm64 machine (Developerbox), just
> adding following DT node and enabled CONFIG_TCG_FTPM_TEE=y:
>
> + tpm@0 {
> + compatible = "microsoft,ftpm";
> + };
>
> Basically with no fTPM TA, I expected the driver to fail during
> "tee_client_open_session()" call with TA not found error and boot
> should continue. But it fails during "tee_client_open_context()" which
> opens a context with OP-TEE driver and has nothing to do with fTPM TA.
>
> -Sumit
>
> > --
> > Thanks,
> > Sasha
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Ilias Apalodimas @ 2019-06-14 10:34 UTC (permalink / raw)
To: Sasha Levin
Cc: Sumit Garg, peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <20190613171141.GL1513@sasha-vm>
Hi Sasha,
On Thu, Jun 13, 2019 at 01:11:41PM -0400, Sasha Levin wrote:
> On Wed, Jun 05, 2019 at 04:39:36PM +0530, Sumit Garg wrote:
> >On Wed, 5 Jun 2019 at 01:39, Sasha Levin <sashal@kernel.org> wrote:
> >>
> >>On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
> >>>On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
> >>>> + /* Open context with TEE driver */
> >>>> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
> >>>> + NULL);
> >>>> + if (IS_ERR(pvt_data->ctx)) {
> >>>> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
> >>>
> >>>Is this well tested? I see this misleading error multiple times as
> >>>follows although TEE driver works pretty well.
> >>
> >>Yes, this was all functionally tested.
I did test as well with a DeveloperBox, i can confirm the driver is loading (but
i have no fTPM support on the OP-TEE side for now)
apalos@mule:~>sudo dmesg | grep optee
[sudo] password for apalos:
[ 5.035801] optee: probing for conduit method from DT.
[ 5.041045] optee: revision 3.2 (53bf1c38)
[ 5.041772] optee: initialized driver
apalos@mule:~>sudo dmesg | grep tpm
[ 5.000674] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
[ 5.101655] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_session failed,
err=ffff000c
[ 5.109703] ftpm-tee: probe of tpm@0 failed with error -22
The error -22 is nice since the probe eventually failed (no fTPM support in
secure world). Can we slightly change the
'ftpm_tee_probe:tee_client_open_context failed' and indicate this is not a real
error since the probe gets deferred untill Secure world is alive?
By the way there is *real* interest for this functionality. I expect to run it
on a number of Arm boards once i get some free time.
> >Can you share your build instructions and testing approach?
>
> Yes: it looks like you got all the kernel bits, but not the firmware.
> There are instructions for it here: https://github.com/microsoft/ms-tpm-20-ref
>
> Once it's running, you can test it by running your favorite TPM usecases
> through /dev/tpm0.
>
> --
> Thanks,
> Sasha
Thanks
/Ilias
^ permalink raw reply
* Re: [PATCH v3] Add a document on rebasing and merging
From: Dmitry Vyukov @ 2019-06-14 9:59 UTC (permalink / raw)
To: Jonathan Corbet
Cc: open list:DOCUMENTATION, LKML, Theodore Ts'o,
Geert Uytterhoeven, David Rientjes, Jani Nikula, Michael Ellerman
In-Reply-To: <20190612094503.120f699a@lwn.net>
On Wed, Jun 12, 2019 at 5:45 PM Jonathan Corbet <corbet@lwn.net> wrote:
>
> Every merge window seems to involve at least one episode where subsystem
> maintainers don't manage their trees as Linus would like. Document the
> expectations so that at least he has something to point people to.
>
> Acked-by: David Rientjes <rientjes@google.com>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> ---
> I intend to apply this version unless somebody really screams.
>
> Changes in v3
> - Fill out discussion on back merges and topic branches as suggested by
> Jani.
>
> Changes in v2:
> - Try to clear up "reparenting" v. "history modification"
> - Make the "don't rebase public branches" rule into more of a guideline
> - Fix typos noted by Geert
> - Rename the document to better reflect its contents
>
> Documentation/maintainer/index.rst | 1 +
> .../maintainer/rebasing-and-merging.rst | 226 ++++++++++++++++++
> 2 files changed, 227 insertions(+)
> create mode 100644 Documentation/maintainer/rebasing-and-merging.rst
>
> diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst
> index 2a14916930cb..56e2c09dfa39 100644
> --- a/Documentation/maintainer/index.rst
> +++ b/Documentation/maintainer/index.rst
> @@ -10,5 +10,6 @@ additions to this manual.
> :maxdepth: 2
>
> configure-git
> + rebasing-and-merging
> pull-requests
>
> diff --git a/Documentation/maintainer/rebasing-and-merging.rst b/Documentation/maintainer/rebasing-and-merging.rst
> new file mode 100644
> index 000000000000..5da9da7a2c51
> --- /dev/null
> +++ b/Documentation/maintainer/rebasing-and-merging.rst
> @@ -0,0 +1,226 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +====================
> +Rebasing and merging
> +====================
> +
> +Maintaining a subsystem, as a general rule, requires a familiarity with the
> +Git source-code management system. Git is a powerful tool with a lot of
> +features; as is often the case with such tools, there are right and wrong
> +ways to use those features. This document looks in particular at the use
> +of rebasing and merging. Maintainers often get in trouble when they use
> +those tools incorrectly, but avoiding problems is not actually all that
> +hard.
> +
> +One thing to be aware of in general is that, unlike many other projects,
> +the kernel community is not scared by seeing merge commits in its
> +development history. Indeed, given the scale of the project, avoiding
> +merges would be nearly impossible.
Hi Jonathan,
I will appreciate if you elaborate a bit on this "scale of the
project". I wondered about reasons for having the current hierarchy of
trees and complex merging for a while, but wasn't able to find any
rationale. What exactly scale do you mean? I know a number of projects
that are comparable to Linux kernel, with the largest being 2 orders
of magnitude larger than kernel both in terms of code size and rate of
change, that use single tree and linear history. So these scales do
not seem to inherently require multiple trees and non-linear history.
Maybe this is already documented somewhere?
Thanks
^ permalink raw reply
* Re: [PATCH v10 3/3] watchdog: make the device time out at open_deadline when open_timeout is used
From: Rasmus Villemoes @ 2019-06-14 8:41 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-watchdog@vger.kernel.org, Wim Van Sebroeck, Jonathan Corbet,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Esben Haabendal, Jerry Hoemann, Rasmus Villemoes
In-Reply-To: <20190607183827.GA32475@roeck-us.net>
On 07/06/2019 20.38, Guenter Roeck wrote:
> On Wed, Jun 05, 2019 at 02:06:44PM +0000, Rasmus Villemoes wrote:
>> When the watchdog device is not open by userspace, the kernel takes
>> care of pinging it. When the open_timeout feature is in use, we should
>> ensure that the hardware fires close to open_timeout seconds after the
>> kernel has assumed responsibility for the device.
>>
>> To do this, simply reuse the logic that is already in place for
>> ensuring the same thing when userspace is responsible for regularly
>> pinging the device:
>>
>> - When watchdog_active(wdd), this patch doesn't change anything.
>>
>> - When !watchdoc_active(wdd), the "virtual timeout" should be taken to
>
> s/watchdoc_active/watchdog_active/
>
> otherwise
>
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Thanks! Wim, can you fix up if/when applying, or do you prefer I resend?
Rasmus
^ permalink raw reply
* Re: [PATCH 01/14] ABI: fix some syntax issues at the ABI database
From: Rafael J. Wysocki @ 2019-06-14 8:30 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Mauro Carvalho Chehab, Linux Kernel Mailing List, Jonathan Corbet,
Andreas Klinger, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Frederic Barrat,
Andrew Donnellan, Sebastian Reichel, Kees Cook, Anton Vorontsov,
Colin Cross, Tony Luck, linux-iio, linuxppc-dev, Linux PM
In-Reply-To: <b908fc6555df8cae3e4c734b2d5f6284c46a5f14.1560477540.git.mchehab+samsung@kernel.org>
On Fri, Jun 14, 2019 at 4:04 AM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> On those three files, the ABI representation described at
> README are violated.
>
> - at sysfs-bus-iio-proximity-as3935:
> a ':' character is missing after "What"
>
> - at sysfs-class-devfreq:
> there's a typo at Description
>
> - at sysfs-class-cxl, it is using the ":" character at a
> file preamble, causing it to be misinterpreted as a
> tag.
>
> - On the other files, instead of "What", they use "Where".
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> Documentation/ABI/testing/pstore | 2 +-
> .../sysfs-bus-event_source-devices-format | 2 +-
> .../ABI/testing/sysfs-bus-i2c-devices-hm6352 | 6 ++---
> .../ABI/testing/sysfs-bus-iio-distance-srf08 | 4 ++--
> .../testing/sysfs-bus-iio-proximity-as3935 | 4 ++--
> .../ABI/testing/sysfs-bus-pci-devices-cciss | 22 +++++++++----------
> .../testing/sysfs-bus-usb-devices-usbsevseg | 12 +++++-----
> Documentation/ABI/testing/sysfs-class-cxl | 6 ++---
> Documentation/ABI/testing/sysfs-class-devfreq | 2 +-
> .../ABI/testing/sysfs-class-powercap | 2 +-
> Documentation/ABI/testing/sysfs-kernel-fscaps | 2 +-
> .../ABI/testing/sysfs-kernel-vmcoreinfo | 2 +-
> 12 files changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore
> index 5fca9f5e10a3..8d6e48f4e8ef 100644
> --- a/Documentation/ABI/testing/pstore
> +++ b/Documentation/ABI/testing/pstore
> @@ -1,4 +1,4 @@
> -Where: /sys/fs/pstore/... (or /dev/pstore/...)
> +What: /sys/fs/pstore/... (or /dev/pstore/...)
> Date: March 2011
> Kernel Version: 2.6.39
> Contact: tony.luck@intel.com
> diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
> index 77f47ff5ee02..b6f8748e0200 100644
> --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
> +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
> @@ -1,4 +1,4 @@
> -Where: /sys/bus/event_source/devices/<dev>/format
> +What: /sys/bus/event_source/devices/<dev>/format
> Date: January 2012
> Kernel Version: 3.3
> Contact: Jiri Olsa <jolsa@redhat.com>
> diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352
> index feb2e4a87075..29bd447e50a0 100644
> --- a/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352
> +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352
> @@ -1,18 +1,18 @@
> -Where: /sys/bus/i2c/devices/.../heading0_input
> +What: /sys/bus/i2c/devices/.../heading0_input
> Date: April 2010
> Kernel Version: 2.6.36?
> Contact: alan.cox@intel.com
> Description: Reports the current heading from the compass as a floating
> point value in degrees.
>
> -Where: /sys/bus/i2c/devices/.../power_state
> +What: /sys/bus/i2c/devices/.../power_state
> Date: April 2010
> Kernel Version: 2.6.36?
> Contact: alan.cox@intel.com
> Description: Sets the power state of the device. 0 sets the device into
> sleep mode, 1 wakes it up.
>
> -Where: /sys/bus/i2c/devices/.../calibration
> +What: /sys/bus/i2c/devices/.../calibration
> Date: April 2010
> Kernel Version: 2.6.36?
> Contact: alan.cox@intel.com
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-distance-srf08 b/Documentation/ABI/testing/sysfs-bus-iio-distance-srf08
> index 0a1ca1487fa9..a133fd8d081a 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio-distance-srf08
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-distance-srf08
> @@ -1,4 +1,4 @@
> -What /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity
> +What: /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity
> Date: January 2017
> KernelVersion: 4.11
> Contact: linux-iio@vger.kernel.org
> @@ -6,7 +6,7 @@ Description:
> Show or set the gain boost of the amp, from 0-31 range.
> default 31
>
> -What /sys/bus/iio/devices/iio:deviceX/sensor_max_range
> +What: /sys/bus/iio/devices/iio:deviceX/sensor_max_range
> Date: January 2017
> KernelVersion: 4.11
> Contact: linux-iio@vger.kernel.org
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
> index 9a17ab5036a4..c59d95346341 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
> @@ -1,4 +1,4 @@
> -What /sys/bus/iio/devices/iio:deviceX/in_proximity_input
> +What: /sys/bus/iio/devices/iio:deviceX/in_proximity_input
> Date: March 2014
> KernelVersion: 3.15
> Contact: Matt Ranostay <matt.ranostay@konsulko.com>
> @@ -6,7 +6,7 @@ Description:
> Get the current distance in meters of storm (1km steps)
> 1000-40000 = distance in meters
>
> -What /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity
> +What: /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity
> Date: March 2014
> KernelVersion: 3.15
> Contact: Matt Ranostay <matt.ranostay@konsulko.com>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
> index 53d99edd1d75..eb449169c30b 100644
> --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
> +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
> @@ -1,66 +1,66 @@
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/model
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/model
> Date: March 2009
> Kernel Version: 2.6.30
> Contact: iss_storagedev@hp.com
> Description: Displays the SCSI INQUIRY page 0 model for logical drive
> Y of controller X.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/rev
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/rev
> Date: March 2009
> Kernel Version: 2.6.30
> Contact: iss_storagedev@hp.com
> Description: Displays the SCSI INQUIRY page 0 revision for logical
> drive Y of controller X.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/unique_id
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/unique_id
> Date: March 2009
> Kernel Version: 2.6.30
> Contact: iss_storagedev@hp.com
> Description: Displays the SCSI INQUIRY page 83 serial number for logical
> drive Y of controller X.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/vendor
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/vendor
> Date: March 2009
> Kernel Version: 2.6.30
> Contact: iss_storagedev@hp.com
> Description: Displays the SCSI INQUIRY page 0 vendor for logical drive
> Y of controller X.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/block:cciss!cXdY
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/block:cciss!cXdY
> Date: March 2009
> Kernel Version: 2.6.30
> Contact: iss_storagedev@hp.com
> Description: A symbolic link to /sys/block/cciss!cXdY
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/rescan
> +What: /sys/bus/pci/devices/<dev>/ccissX/rescan
> Date: August 2009
> Kernel Version: 2.6.31
> Contact: iss_storagedev@hp.com
> Description: Kicks of a rescan of the controller to discover logical
> drive topology changes.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/lunid
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/lunid
> Date: August 2009
> Kernel Version: 2.6.31
> Contact: iss_storagedev@hp.com
> Description: Displays the 8-byte LUN ID used to address logical
> drive Y of controller X.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/raid_level
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/raid_level
> Date: August 2009
> Kernel Version: 2.6.31
> Contact: iss_storagedev@hp.com
> Description: Displays the RAID level of logical drive Y of
> controller X.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/usage_count
> +What: /sys/bus/pci/devices/<dev>/ccissX/cXdY/usage_count
> Date: August 2009
> Kernel Version: 2.6.31
> Contact: iss_storagedev@hp.com
> Description: Displays the usage count (number of opens) of logical drive Y
> of controller X.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/resettable
> +What: /sys/bus/pci/devices/<dev>/ccissX/resettable
> Date: February 2011
> Kernel Version: 2.6.38
> Contact: iss_storagedev@hp.com
> @@ -71,7 +71,7 @@ Description: Value of 1 indicates the controller can honor the reset_devices
> a dump device, as kdump requires resetting the device in order
> to work reliably.
>
> -Where: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
> +What: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
> Date: July 2011
> Kernel Version: 3.0
> Contact: iss_storagedev@hp.com
> diff --git a/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg b/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg
> index 70d00dfa443d..f6199b314196 100644
> --- a/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg
> +++ b/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg
> @@ -1,12 +1,12 @@
> -Where: /sys/bus/usb/.../powered
> +What: /sys/bus/usb/.../powered
> Date: August 2008
> Kernel Version: 2.6.26
> Contact: Harrison Metzger <harrisonmetz@gmail.com>
> Description: Controls whether the device's display will powered.
> A value of 0 is off and a non-zero value is on.
>
> -Where: /sys/bus/usb/.../mode_msb
> -Where: /sys/bus/usb/.../mode_lsb
> +What: /sys/bus/usb/.../mode_msb
> +What: /sys/bus/usb/.../mode_lsb
> Date: August 2008
> Kernel Version: 2.6.26
> Contact: Harrison Metzger <harrisonmetz@gmail.com>
> @@ -16,7 +16,7 @@ Description: Controls the devices display mode.
> for an 8 character display the values are
> MSB 0x08; LSB 0xFF.
>
> -Where: /sys/bus/usb/.../textmode
> +What: /sys/bus/usb/.../textmode
> Date: August 2008
> Kernel Version: 2.6.26
> Contact: Harrison Metzger <harrisonmetz@gmail.com>
> @@ -25,13 +25,13 @@ Description: Controls the way the device interprets its text buffer.
> hex: each character is between 0-15
> ascii: each character is between '0'-'9' and 'A'-'F'.
>
> -Where: /sys/bus/usb/.../text
> +What: /sys/bus/usb/.../text
> Date: August 2008
> Kernel Version: 2.6.26
> Contact: Harrison Metzger <harrisonmetz@gmail.com>
> Description: The text (or data) for the device to display
>
> -Where: /sys/bus/usb/.../decimals
> +What: /sys/bus/usb/.../decimals
> Date: August 2008
> Kernel Version: 2.6.26
> Contact: Harrison Metzger <harrisonmetz@gmail.com>
> diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
> index bbbabffc682a..fc7c6f7c21b3 100644
> --- a/Documentation/ABI/testing/sysfs-class-cxl
> +++ b/Documentation/ABI/testing/sysfs-class-cxl
> @@ -1,6 +1,6 @@
> -Note: Attributes that are shared between devices are stored in the directory
> -pointed to by the symlink device/.
> -Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
> +Please notice that attributes that are shared between devices are stored in
> +the directory pointed to by the symlink device/.
> +For example, the real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
> /sys/class/cxl/afu0.0s/device/irqs_max, i.e. /sys/class/cxl/afu0.0/irqs_max.
>
>
> diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq
> index ee39acacf6f8..01196e19afca 100644
> --- a/Documentation/ABI/testing/sysfs-class-devfreq
> +++ b/Documentation/ABI/testing/sysfs-class-devfreq
> @@ -47,7 +47,7 @@ Description:
> What: /sys/class/devfreq/.../trans_stat
> Date: October 2012
> Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
> -Descrtiption:
> +Description:
> This ABI shows the statistics of devfreq behavior on a
> specific device. It shows the time spent in each state and
> the number of transitions between states.
> diff --git a/Documentation/ABI/testing/sysfs-class-powercap b/Documentation/ABI/testing/sysfs-class-powercap
> index db3b3ff70d84..f333a0ccc29b 100644
> --- a/Documentation/ABI/testing/sysfs-class-powercap
> +++ b/Documentation/ABI/testing/sysfs-class-powercap
> @@ -147,6 +147,6 @@ What: /sys/class/powercap/.../<power zone>/enabled
> Date: September 2013
> KernelVersion: 3.13
> Contact: linux-pm@vger.kernel.org
> -Description
> +Description:
> This allows to enable/disable power capping at power zone level.
> This applies to current power zone and its children.
> diff --git a/Documentation/ABI/testing/sysfs-kernel-fscaps b/Documentation/ABI/testing/sysfs-kernel-fscaps
> index 50a3033b5e15..bcff34665192 100644
> --- a/Documentation/ABI/testing/sysfs-kernel-fscaps
> +++ b/Documentation/ABI/testing/sysfs-kernel-fscaps
> @@ -2,7 +2,7 @@ What: /sys/kernel/fscaps
> Date: February 2011
> KernelVersion: 2.6.38
> Contact: Ludwig Nussel <ludwig.nussel@suse.de>
> -Description
> +Description:
> Shows whether file system capabilities are honored
> when executing a binary
>
> diff --git a/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo b/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
> index 7bd81168e063..1f1087a5f075 100644
> --- a/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
> +++ b/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
> @@ -4,7 +4,7 @@ KernelVersion: 2.6.24
> Contact: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
> Kexec Mailing List <kexec@lists.infradead.org>
> Vivek Goyal <vgoyal@redhat.com>
> -Description
> +Description:
> Shows physical address and size of vmcoreinfo ELF note.
> First value contains physical address of note in hex and
> second value contains the size of note in hex. This ELF
> --
> 2.21.0
>
^ permalink raw reply
* Re: [RFC 0/7] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-06-14 8:17 UTC (permalink / raw)
To: Mimi Zohar
Cc: Casey Schaufler, keyrings, linux-integrity, linux-security-module,
Jens Wiklander, corbet, dhowells, jejb, Jarkko Sakkinen, jmorris,
serge, Ard Biesheuvel, Daniel Thompson, linux-doc,
Linux Kernel Mailing List, tee-dev
In-Reply-To: <1560470593.4805.109.camel@linux.ibm.com>
Thanks Mimi for your comments.
On Fri, 14 Jun 2019 at 05:33, Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Thu, 2019-06-13 at 09:40 -0700, Casey Schaufler wrote:
> > On 6/13/2019 3:30 AM, Sumit Garg wrote:
> > > Add support for TEE based trusted keys where TEE provides the functionality
> > > to seal and unseal trusted keys using hardware unique key. Also, this is
> > > an alternative in case platform doesn't possess a TPM device.
> > >
> > > This series also adds some TEE features like:
> >
> > Please expand the acronym TEE on first use. That will
> > help people who don't work with it on a daily basis
> > understand what you're going on about.
>
> Thanks, Casey.
>
> "[6/7] doc: keys: Document usage of TEE based Trusted Keys" refers to
> the kernel tee documentation, but that documentation is limited to
> userspace interaction with the tee.
>
Thanks for pointing this out. I will update documentation to include
TEE bus approach and communication apis for kernel clients.
BTW, the interface is similar as with user-space. Only difference is
instead of IOCTL's from user-space, there are wrapper apis to
communicate with TEE.
Also, in case someone is interested to learn about TEE technology,
this webinar [1] could be one of starting points.
> A trusted key is a random number generated and sealed(encrypted) by
> the TPM, so that only the TPM may unseal it. The sealing key never
> leaves the TPM. The sealed, trusted key may be exported to userspace.
Understood.
> In the tee case, can the "sealing" key ever leave the tee?
No, the "sealing" key never leaves TEE. Its basically a Hardware
Unique Key (HUK) tied to a particular SoC.
> Can the
> sealed, trusted key, exported to userspace, be unsealed by the tee?
You mean using user-space interface to TEE? If yes, then answer is
"no" as user-space can't communicate with this TEE service as its
accessible to kernel clients only (see patch [2]).
In case you meant loading exported trusted key blob via "keyctl", then
"yes" this driver can unseal the trusted key. Have a look at examples
I have listed in documentation patch [3]. Also, this approach works
well across power cycles too.
> Are the tee security protections similar to those of the TPM? How do
> they compare?
>
Let me try to compare both environments. Regarding TEE, I will refer
to OP-TEE [4] as one of its implementation.
TPM:
1. External hardware.
2. Sealing key resides inside TPM.
3. Communicates via SPI, I2C etc.
OP-TEE:
1. On chip, trusted execution environment enforced via ARM TrustZone.
2. Sealing key is unique to a particular SoC provided by secure fuses,
secure crypto engine etc.
3. Communicates via Secure Monitor Calls (SMCs [5]).
[1] https://globalplatform.org/resource-publication/webinar-an-introduction-to-tee-technology/
[2] [RFC 3/7] tee: add private login method for kernel clients
[3] [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys
[4] https://optee.readthedocs.io/general/about.html
[5] http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
-Sumit
> Mimi
>
> >
> > >
> > > Patch #1, #2 enables support for registered kernel shared memory with TEE.
> > >
> > > Patch #3 enables support for private kernel login method required for
> > > cases like trusted keys where we don't wan't user-space to directly access
> > > TEE service to retrieve trusted key contents.
> > >
> > > Rest of the patches from #4 to #7 adds support for TEE based trusted keys.
> > >
> > > This patch-set has been tested with OP-TEE based pseudo TA which can be
> > > found here [1].
> > >
> > > Looking forward to your valuable feedback/suggestions.
>
^ permalink raw reply
* Re: [RFC 2/7] tee: enable support to register kernel memory
From: Jens Wiklander @ 2019-06-14 8:16 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, corbet,
dhowells, jejb, jarkko.sakkinen, zohar, jmorris, serge,
ard.biesheuvel, daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-3-git-send-email-sumit.garg@linaro.org>
On Thu, Jun 13, 2019 at 04:00:28PM +0530, Sumit Garg wrote:
> Enable support to register kernel memory reference with TEE. This change
> will allow TEE bus drivers to register memory references.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Thanks,
Jens
^ permalink raw reply
* Re: [RFC 1/7] tee: optee: allow kernel pages to register as shm
From: Jens Wiklander @ 2019-06-14 8:15 UTC (permalink / raw)
To: Sumit Garg
Cc: keyrings, linux-integrity, linux-security-module, corbet,
dhowells, jejb, jarkko.sakkinen, zohar, jmorris, serge,
ard.biesheuvel, daniel.thompson, linux-doc, linux-kernel, tee-dev
In-Reply-To: <1560421833-27414-2-git-send-email-sumit.garg@linaro.org>
On Thu, Jun 13, 2019 at 04:00:27PM +0530, Sumit Garg wrote:
> Kernel pages are marked as normal type memory only so allow kernel pages
> to be registered as shared memory with OP-TEE.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Thanks,
Jens
^ permalink raw reply
* Re: [PATCH 01/14] ABI: fix some syntax issues at the ABI database
From: Andrew Donnellan @ 2019-06-14 7:20 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Andreas Klinger, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Frederic Barrat, Sebastian Reichel, Kees Cook, Anton Vorontsov,
Colin Cross, Tony Luck, linux-iio, linuxppc-dev, linux-pm
In-Reply-To: <b908fc6555df8cae3e4c734b2d5f6284c46a5f14.1560477540.git.mchehab+samsung@kernel.org>
On 14/6/19 12:04 pm, Mauro Carvalho Chehab wrote:
> diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
> index bbbabffc682a..fc7c6f7c21b3 100644
> --- a/Documentation/ABI/testing/sysfs-class-cxl
> +++ b/Documentation/ABI/testing/sysfs-class-cxl
> @@ -1,6 +1,6 @@
> -Note: Attributes that are shared between devices are stored in the directory
> -pointed to by the symlink device/.
> -Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
> +Please notice that attributes that are shared between devices are stored in
Would prefer "Please note" over "Please notice".
Acked-by: Andrew Donnellan <ajd@linux.ibm.com> # cxl
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 1/9] media: docs: v4l2-controls: fix sentence rendered in a nonsense way
From: Hans Verkuil @ 2019-06-14 7:14 UTC (permalink / raw)
To: Luca Ceresoli, linux-media; +Cc: Mauro Carvalho Chehab, linux-kernel, linux-doc
In-Reply-To: <20190613141826.26775-1-luca@lucaceresoli.net>
On 6/13/19 4:18 PM, Luca Ceresoli wrote:
> This sentence renders as:
>
>> Since such compound controls need to expose more information about
>> themselves than is possible with ioctls VIDIOC_QUERYCTRL,
>> VIDIOC_QUERY_EXT_CTRL and VIDIOC_QUERYMENU the VIDIOC_QUERY_EXT_CTRL
> ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
>> ioctl was added.
>
> This does not make sense. Fix by providing an explicit link text. This
> results in:
>
>> Since such compound controls need to expose more information about
>> themselves than is possible with VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU
>> the VIDIOC_QUERY_EXT_CTRL ioctl was added.
>
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
> ---
> Documentation/media/uapi/v4l/extended-controls.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
> index 24274b398e63..0968aa9cd167 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -86,7 +86,7 @@ with compound types should only be used programmatically.
>
> Since such compound controls need to expose more information about
> themselves than is possible with
> -:ref:`VIDIOC_QUERYCTRL` the
> +:ref:`VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>` the
This should just refer to VIDIOC_QUERYCTRL, not QUERYMENU. So this
becomes: :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>`
Regards,
Hans
> :ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
> particular, this ioctl gives the dimensions of the N-dimensional array
> if this control consists of more than one element.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox