[PATCH] drm/i915/guc: Fix doc reference to intel_guc_fw.c
Sphinx complains that it can't find intel_guc_loader.c, and rightly so:
The file has been renamed.
Fixes: e8668bbcb0f9 ("drm/i915/guc: Rename intel_guc_loader.c to
intel_guc_fw.c")
Cc: Michal Wajdeczko
Signed-off-by: Jonathan Neuschäfer
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 2e7ee0313c1c..e21698e16534 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -341,10 +341,10 @@ GuC
GuC-specific firmware loader
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:doc: GuC-specific firmware loader
-.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_loader.c
+.. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fw.c
:internal:
GuC-based command submission
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] genericirq.rst: Remove :c:func:`...` in code blocks
In code blocks, :c:func:`...` annotations don't result in
cross-references. Instead, they are rendered verbatim. Remove these
broken annotations, and mark function calls with parentheses() again.
Fixes: 76d40fae1351 ("genericirq.rst: add cross-reference links and use
monospaced fonts")
Signed-off-by: Jonathan Neuschäfer
---
Documentation/core-api/genericirq.rst | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/core-api/genericirq.rst
b/Documentation/core-api/genericirq.rst
index 0054bd48be84..4da67b65cecf 100644
--- a/Documentation/core-api/genericirq.rst
+++ b/Documentation/core-api/genericirq.rst
@@ -225,9 +225,9 @@ interrupts.
The following control flow is implemented (simplified excerpt)::
-:c:func:`desc->irq_data.chip->irq_mask_ack`;
+desc->irq_data.chip->irq_mask_ack();
handle_irq_event(desc->action);
-:c:func:`desc->irq_data.chip->irq_unmask`;
+desc->irq_data.chip->irq_unmask();
Default Fast EOI IRQ flow handler
@@ -239,7 +239,7 @@ which only need an EOI at the end of the handler.
The following control flow is implemented (simplified excerpt)::
handle_irq_event(desc->action);
-:c:func:`desc->irq_data.chip->irq_eoi`;
+desc->irq_data.chip->irq_eoi();
Default Edge IRQ flow handler
@@ -251,15 +251,15 @@ interrupts.
The following control flow is implemented (simplified excerpt)::
if (desc->status & running) {
-:c:func:`desc->irq_data.chip->irq_mask_ack`;
+desc->irq_data.chip->irq_mask_ack();
desc->status |= pending | masked;
return;
}
-:c:func:`desc->irq_data.chip->irq_ack`;
+desc->irq_data.chip->irq_ack();
desc->status |= running;
do {
if (desc->status & masked)
-:c:func:`desc->irq_data.chip->irq_unmask`;
+desc->irq_data.chip->irq_unmask();
desc->status &= ~pending;
handle_irq_event(desc->action);
} while (status & pending);
@@ -293,10 +293,10 @@ simplified version without locking.
The following control flow is implemented (simplified excerpt)::
if (desc->irq_data.chip->irq_ack)
-:c:func:`desc->irq_data.chip->irq_ack`;
+desc->irq_data.chip->irq_ack();
handle_irq_event(desc->action);
if (desc->irq_data.chip->irq_eoi)
-:c:func:`desc->irq_data.chip->irq_eoi`;
+desc->irq_data.chip->irq_eoi();
EOI Edge IRQ flow handler
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] MAINTAINERS: regulator: Add Documentation/power/regulator/
On Sun, Nov 19, 2017 at 06:09:06AM +0100, Jonathan Neuschäfer wrote: > Signed-off-by: Jonathan Neuschäfer > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) Ping. Should I resend this series with Cc: linux-doc@vger.kernel.org? > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2811a211632c..a644d41e088c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -14447,6 +14447,7 @@ W:http://www.slimlogic.co.uk/?p=48 > T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > S: Supported > F: Documentation/devicetree/bindings/regulator/ > +F: Documentation/power/regulator/ > F: drivers/regulator/ > F: include/dt-bindings/regulator/ > F: include/linux/regulator/ > -- > 2.11.0 > signature.asc Description: PGP signature
Re: [PATCH] linux-next: ftrace/docs: Fix spelling typos in ftrace-users.rst
On Tue, 28 Nov 2017 12:26:13 +0900 Masanari Iida wrote: > This patch corrects some spelling typo in ftrace-users.rst > > Signed-off-by: Masanari Iida > --- > Documentation/trace/ftrace-uses.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/trace/ftrace-uses.rst > b/Documentation/trace/ftrace-uses.rst > index 8494a801d341..9df5ee15859a 100644 > --- a/Documentation/trace/ftrace-uses.rst > +++ b/Documentation/trace/ftrace-uses.rst > @@ -12,7 +12,7 @@ Written for: 4.14 > Introduction > > > -The ftrace infrastructure was originially created to attach callbacks to the > +The ftrace infrastructure was originally created to attach callbacks to the > beginning of functions in order to record and trace the flow of the kernel. > But callbacks to the start of a function can have other use cases. Either > for live kernel patching, or for security monitoring. This document describes > @@ -29,7 +29,7 @@ going to idle, during CPU bring up and takedown, or going > to user space. > This requires extra care to what can be done inside a callback. A callback > can be called outside the protective scope of RCU. > > -The ftrace infrastructure has some protections agains recursions and RCU > +The ftrace infrastructure has some protections against recursions and RCU > but one must still be very careful how they use the callbacks. > > Acked-by: Steven Rostedt (VMware) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] doc: add maintainer book
On Mon, Nov 27, 2017 at 07:01:23PM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 28 Nov 2017 07:53:03 +1100
> "Tobin C. Harding" escreveu:
>
> > On Mon, Nov 27, 2017 at 04:57:30PM -0200, Mauro Carvalho Chehab wrote:
> > > Em Sat, 25 Nov 2017 08:44:19 +1100
> > > "Tobin C. Harding" escreveu:
> > >
> > > > There is currently very little documentation in the kernel on maintainer
> > > > level tasks. In particular there are no documents on creating pull
> > > > requests to submit to Linus.
> > > >
> > > > Quoting Greg Kroah-Hartman on LKML:
> > > >
> > > > Anyway, this actually came up at the kernel summit / maintainer
> > > > meeting a few weeks ago, in that "how do I make a
> > > > good pull request to Linus" is something we need to document.
> > > >
> > > > Here's what I do, and it seems to work well, so maybe we should turn
> > > > it into the start of the documentation for how to do it.
> > > >
> > > > (quote references: kernel summit, Europe 2017)
> > > >
> > > > Create a new kernel documentation book 'how to be a maintainer'
> > > > (suggested by Jonathan Corbet). Add chapters on 'configuring git' and
> > > > 'creating a pull request'.
> > > >
> > > > Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
> > > > in discussion on LKML. This is stated at the start of one of the
> > > > chapters and the original email thread is referenced in
> > > > 'pull-requests.rst'.
> > > >
> > > > Signed-off-by: Tobin C. Harding
> > > > ---
> > > >
> > > > v2:
> > > > - Change title of book, suggested by Dan Williams.
> > > >
> > > > thanks,
> > > > Tobin.
> > > >
> > > > Documentation/index.rst| 1 +
> > > > Documentation/maintainer/conf.py | 10 ++
> > > > Documentation/maintainer/configure-git.rst | 34 ++
> > > > Documentation/maintainer/index.rst | 10 ++
> > > > Documentation/maintainer/pull-requests.rst | 178
> > > > +
> > > > 5 files changed, 233 insertions(+)
> > > > create mode 100644 Documentation/maintainer/conf.py
> > > > create mode 100644 Documentation/maintainer/configure-git.rst
> > > > create mode 100644 Documentation/maintainer/index.rst
> > > > create mode 100644 Documentation/maintainer/pull-requests.rst
> > > >
> > > > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > > > index cb7f1ba5b3b1..a4fb34dddcf3 100644
> > > > --- a/Documentation/index.rst
> > > > +++ b/Documentation/index.rst
> > > > @@ -52,6 +52,7 @@ merged much easier.
> > > > dev-tools/index
> > > > doc-guide/index
> > > > kernel-hacking/index
> > > > + maintainer/index
> > > >
> > > > Kernel API documentation
> > > >
> > > > diff --git a/Documentation/maintainer/conf.py
> > > > b/Documentation/maintainer/conf.py
> > > > new file mode 100644
> > > > index ..81e9eb7a7884
> > > > --- /dev/null
> > > > +++ b/Documentation/maintainer/conf.py
> > > > @@ -0,0 +1,10 @@
> > > > +# -*- coding: utf-8; mode: python -*-
> > > > +
> > > > +project = 'Linux Kernel Development Documentation'
> > > > +
> > > > +tags.add("subproject")
> > > > +
> > > > +latex_documents = [
> > > > +('index', 'maintainer.tex', 'Linux Kernel Development
> > > > Documentation',
> > > > + 'The kernel development community', 'manual'),
> > > > +]
> > > > diff --git a/Documentation/maintainer/configure-git.rst
> > > > b/Documentation/maintainer/configure-git.rst
> > > > new file mode 100644
> > > > index ..780d2c84
> > > > --- /dev/null
> > > > +++ b/Documentation/maintainer/configure-git.rst
> > > > @@ -0,0 +1,34 @@
> > > > +.. _configuregit:
> > > > +
> > > > +Configure Git
> > > > +=
> > > > +
> > > > +This chapter describes maintainer level git configuration.
> > > > +
> > > > +Tagged branches used in
> > > > :ref:`Documentation/maintainer/pull-requests.rst
> > > > +` should be signed with the developers public GPG key.
> > > > Signed
> > > > +tags can be created by passing the ``-u`` flag to ``git tag``. However,
> > > > +since you would *usually* use the same key for the same project, you
> > > > can
> > > > +set it once with
> > > > +::
> > > > +
> > > > + git config user.signingkey "keyname"
> > > > +
> > > > +Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by
> > > > hand:
> > > > +::
> > > > +
> > > > + [user]
> > > > + name = Jane Developer
> > > > + email = j...@domain.org
> > > > + signingkey = j...@domain.org
> > > > +
> > > > +You may need to tell ``git`` to use ``gpg2``
> > > > +::
> > > > +
> > > > + [gpg]
> > > > + program = /path/to/gpg2
> > > > +
> > > > +You may also like to tell ``gpg`` which ``tty`` to use (add to your
> > > > shell rc file)
> > > > +::
> > > > +
> > > > + export GPG_TTY=$(tty)
> > > > diff --git a/Documentation/maintainer/index.rst
> > > > b/Documentation/maintainer/index.rst
> > > > ne
Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy
On 11/27/2017 04:42 PM, Tejun Heo wrote: > Hello, Waiman. > > On Mon, Nov 27, 2017 at 04:19:57PM -0500, Waiman Long wrote: >>> Let's start just with [e]cpus and [e]mems. The flags interface looks >>> fine but the implementations of these features are really bad and >>> cgroup2 doesn't migrate resources for other controllers either anyway. >> That is added because the mem_migrate feature is used in libvirt, I >> think. I am thinking of add a "[EXPERIMENTAL]" tag to the flags to >> indicate that it is subject to change. > I see. Do you happen to know what it's used for and why that's > necessary just so that we can evaluate it better? I'm not quite sure > what adding [EXPERIMENTAL] tag would achieve. If we expose the > feature and people use it, we just have to keep it anyway. The mem_migrate feature will probably enforce better NUMA locality as the vCPU may move from one physical CPU to another if it is not pinned. I want to add the experimental tag more in the sense that we are going to add to the list of the flags in the future than removing an existing one. Well, I guess we can just say it in the text instead of adding a tag. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy
Hello, Waiman. On Mon, Nov 27, 2017 at 04:19:57PM -0500, Waiman Long wrote: > > Let's start just with [e]cpus and [e]mems. The flags interface looks > > fine but the implementations of these features are really bad and > > cgroup2 doesn't migrate resources for other controllers either anyway. > > That is added because the mem_migrate feature is used in libvirt, I > think. I am thinking of add a "[EXPERIMENTAL]" tag to the flags to > indicate that it is subject to change. I see. Do you happen to know what it's used for and why that's necessary just so that we can evaluate it better? I'm not quite sure what adding [EXPERIMENTAL] tag would achieve. If we expose the feature and people use it, we just have to keep it anyway. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy
On 11/27/2017 04:04 PM, Tejun Heo wrote: > Hello, Waiman. > > Sorry about the long delay. > > On Fri, Oct 06, 2017 at 05:10:30PM -0400, Waiman Long wrote: >> +Cpuset Interface Files >> +~~ >> + >> + cpuset.cpus >> +A read-write multiple values file which exists on non-root >> +cgroups. >> + >> +It lists the CPUs allowed to be used by tasks within this >> +cgroup. The CPU numbers are comma-separated numbers or >> +ranges. For example: >> + >> + # cat cpuset.cpus >> + 0-4,6,8-10 >> + >> +An empty value indicates that the cgroup is using the same >> +setting as the nearest cgroup ancestor with a non-empty >> +"cpuset.cpus" or all the available CPUs if none is found. >> + >> +The value of "cpuset.cpus" stays constant until the next update >> +and won't be affected by any CPU hotplug events. >> + >> + cpuset.effective_cpus > Can we do cpuset.ecpus in the fashion of euid, egid..? Sure. >> + cpuset.effective_mems > Ditto. Sure. >> + cpuset.flags >> +A read-write multiple values file which exists on non-root >> +cgroups. >> + >> +It lists the flags that are set (with a '+' prefix) and those >> +that are not set (with a '-' prefix). The currently supported >> +flag is: >> + >> + mem_migrate >> +When it is not set, an allocated memory page will >> +stay in whatever node it was allocated independent >> +of changes in "cpuset.mems". >> + >> +When it is set, tasks with memory pages not in >> +"cpuset.mems" will have those pages migrated over to >> +memory nodes specified in "cpuset.mems". Any changes >> +to "cpuset.mems" will cause pages in nodes that are >> +no longer valid to be migrated over to the newly >> +valid nodes. > Let's start just with [e]cpus and [e]mems. The flags interface looks > fine but the implementations of these features are really bad and > cgroup2 doesn't migrate resources for other controllers either anyway. That is added because the mem_migrate feature is used in libvirt, I think. I am thinking of add a "[EXPERIMENTAL]" tag to the flags to indicate that it is subject to change. Cheers, Longman -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy
Hello, Waiman. Sorry about the long delay. On Fri, Oct 06, 2017 at 05:10:30PM -0400, Waiman Long wrote: > +Cpuset Interface Files > +~~ > + > + cpuset.cpus > + A read-write multiple values file which exists on non-root > + cgroups. > + > + It lists the CPUs allowed to be used by tasks within this > + cgroup. The CPU numbers are comma-separated numbers or > + ranges. For example: > + > + # cat cpuset.cpus > + 0-4,6,8-10 > + > + An empty value indicates that the cgroup is using the same > + setting as the nearest cgroup ancestor with a non-empty > + "cpuset.cpus" or all the available CPUs if none is found. > + > + The value of "cpuset.cpus" stays constant until the next update > + and won't be affected by any CPU hotplug events. > + > + cpuset.effective_cpus Can we do cpuset.ecpus in the fashion of euid, egid..? > + cpuset.effective_mems Ditto. > + cpuset.flags > + A read-write multiple values file which exists on non-root > + cgroups. > + > + It lists the flags that are set (with a '+' prefix) and those > + that are not set (with a '-' prefix). The currently supported > + flag is: > + > + mem_migrate > + When it is not set, an allocated memory page will > + stay in whatever node it was allocated independent > + of changes in "cpuset.mems". > + > + When it is set, tasks with memory pages not in > + "cpuset.mems" will have those pages migrated over to > + memory nodes specified in "cpuset.mems". Any changes > + to "cpuset.mems" will cause pages in nodes that are > + no longer valid to be migrated over to the newly > + valid nodes. Let's start just with [e]cpus and [e]mems. The flags interface looks fine but the implementations of these features are really bad and cgroup2 doesn't migrate resources for other controllers either anyway. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] doc: add maintainer book
Em Tue, 28 Nov 2017 07:53:03 +1100
"Tobin C. Harding" escreveu:
> On Mon, Nov 27, 2017 at 04:57:30PM -0200, Mauro Carvalho Chehab wrote:
> > Em Sat, 25 Nov 2017 08:44:19 +1100
> > "Tobin C. Harding" escreveu:
> >
> > > There is currently very little documentation in the kernel on maintainer
> > > level tasks. In particular there are no documents on creating pull
> > > requests to submit to Linus.
> > >
> > > Quoting Greg Kroah-Hartman on LKML:
> > >
> > > Anyway, this actually came up at the kernel summit / maintainer
> > > meeting a few weeks ago, in that "how do I make a
> > > good pull request to Linus" is something we need to document.
> > >
> > > Here's what I do, and it seems to work well, so maybe we should turn
> > > it into the start of the documentation for how to do it.
> > >
> > > (quote references: kernel summit, Europe 2017)
> > >
> > > Create a new kernel documentation book 'how to be a maintainer'
> > > (suggested by Jonathan Corbet). Add chapters on 'configuring git' and
> > > 'creating a pull request'.
> > >
> > > Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
> > > in discussion on LKML. This is stated at the start of one of the
> > > chapters and the original email thread is referenced in
> > > 'pull-requests.rst'.
> > >
> > > Signed-off-by: Tobin C. Harding
> > > ---
> > >
> > > v2:
> > > - Change title of book, suggested by Dan Williams.
> > >
> > > thanks,
> > > Tobin.
> > >
> > > Documentation/index.rst| 1 +
> > > Documentation/maintainer/conf.py | 10 ++
> > > Documentation/maintainer/configure-git.rst | 34 ++
> > > Documentation/maintainer/index.rst | 10 ++
> > > Documentation/maintainer/pull-requests.rst | 178
> > > +
> > > 5 files changed, 233 insertions(+)
> > > create mode 100644 Documentation/maintainer/conf.py
> > > create mode 100644 Documentation/maintainer/configure-git.rst
> > > create mode 100644 Documentation/maintainer/index.rst
> > > create mode 100644 Documentation/maintainer/pull-requests.rst
> > >
> > > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > > index cb7f1ba5b3b1..a4fb34dddcf3 100644
> > > --- a/Documentation/index.rst
> > > +++ b/Documentation/index.rst
> > > @@ -52,6 +52,7 @@ merged much easier.
> > > dev-tools/index
> > > doc-guide/index
> > > kernel-hacking/index
> > > + maintainer/index
> > >
> > > Kernel API documentation
> > >
> > > diff --git a/Documentation/maintainer/conf.py
> > > b/Documentation/maintainer/conf.py
> > > new file mode 100644
> > > index ..81e9eb7a7884
> > > --- /dev/null
> > > +++ b/Documentation/maintainer/conf.py
> > > @@ -0,0 +1,10 @@
> > > +# -*- coding: utf-8; mode: python -*-
> > > +
> > > +project = 'Linux Kernel Development Documentation'
> > > +
> > > +tags.add("subproject")
> > > +
> > > +latex_documents = [
> > > +('index', 'maintainer.tex', 'Linux Kernel Development Documentation',
> > > + 'The kernel development community', 'manual'),
> > > +]
> > > diff --git a/Documentation/maintainer/configure-git.rst
> > > b/Documentation/maintainer/configure-git.rst
> > > new file mode 100644
> > > index ..780d2c84
> > > --- /dev/null
> > > +++ b/Documentation/maintainer/configure-git.rst
> > > @@ -0,0 +1,34 @@
> > > +.. _configuregit:
> > > +
> > > +Configure Git
> > > +=
> > > +
> > > +This chapter describes maintainer level git configuration.
> > > +
> > > +Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst
> > > +` should be signed with the developers public GPG key.
> > > Signed
> > > +tags can be created by passing the ``-u`` flag to ``git tag``. However,
> > > +since you would *usually* use the same key for the same project, you can
> > > +set it once with
> > > +::
> > > +
> > > + git config user.signingkey "keyname"
> > > +
> > > +Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by
> > > hand:
> > > +::
> > > +
> > > + [user]
> > > + name = Jane Developer
> > > + email = j...@domain.org
> > > + signingkey = j...@domain.org
> > > +
> > > +You may need to tell ``git`` to use ``gpg2``
> > > +::
> > > +
> > > + [gpg]
> > > + program = /path/to/gpg2
> > > +
> > > +You may also like to tell ``gpg`` which ``tty`` to use (add to your
> > > shell rc file)
> > > +::
> > > +
> > > + export GPG_TTY=$(tty)
> > > diff --git a/Documentation/maintainer/index.rst
> > > b/Documentation/maintainer/index.rst
> > > new file mode 100644
> > > index ..fa84ac9cae39
> > > --- /dev/null
> > > +++ b/Documentation/maintainer/index.rst
> > > @@ -0,0 +1,10 @@
> > > +==
> > > +Kernel Maintainer Handbook
> > > +==
> > > +
> > > +.. toctree::
> > > + :maxdepth: 2
> > > +
> > > + configure-git
> > > + pull-requests
> > > +
> > > diff --git a/Documentation/main
Re: [PATCH v2] doc: add maintainer book
On Mon, Nov 27, 2017 at 04:57:30PM -0200, Mauro Carvalho Chehab wrote:
> Em Sat, 25 Nov 2017 08:44:19 +1100
> "Tobin C. Harding" escreveu:
>
> > There is currently very little documentation in the kernel on maintainer
> > level tasks. In particular there are no documents on creating pull
> > requests to submit to Linus.
> >
> > Quoting Greg Kroah-Hartman on LKML:
> >
> > Anyway, this actually came up at the kernel summit / maintainer
> > meeting a few weeks ago, in that "how do I make a
> > good pull request to Linus" is something we need to document.
> >
> > Here's what I do, and it seems to work well, so maybe we should turn
> > it into the start of the documentation for how to do it.
> >
> > (quote references: kernel summit, Europe 2017)
> >
> > Create a new kernel documentation book 'how to be a maintainer'
> > (suggested by Jonathan Corbet). Add chapters on 'configuring git' and
> > 'creating a pull request'.
> >
> > Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
> > in discussion on LKML. This is stated at the start of one of the
> > chapters and the original email thread is referenced in
> > 'pull-requests.rst'.
> >
> > Signed-off-by: Tobin C. Harding
> > ---
> >
> > v2:
> > - Change title of book, suggested by Dan Williams.
> >
> > thanks,
> > Tobin.
> >
> > Documentation/index.rst| 1 +
> > Documentation/maintainer/conf.py | 10 ++
> > Documentation/maintainer/configure-git.rst | 34 ++
> > Documentation/maintainer/index.rst | 10 ++
> > Documentation/maintainer/pull-requests.rst | 178
> > +
> > 5 files changed, 233 insertions(+)
> > create mode 100644 Documentation/maintainer/conf.py
> > create mode 100644 Documentation/maintainer/configure-git.rst
> > create mode 100644 Documentation/maintainer/index.rst
> > create mode 100644 Documentation/maintainer/pull-requests.rst
> >
> > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > index cb7f1ba5b3b1..a4fb34dddcf3 100644
> > --- a/Documentation/index.rst
> > +++ b/Documentation/index.rst
> > @@ -52,6 +52,7 @@ merged much easier.
> > dev-tools/index
> > doc-guide/index
> > kernel-hacking/index
> > + maintainer/index
> >
> > Kernel API documentation
> >
> > diff --git a/Documentation/maintainer/conf.py
> > b/Documentation/maintainer/conf.py
> > new file mode 100644
> > index ..81e9eb7a7884
> > --- /dev/null
> > +++ b/Documentation/maintainer/conf.py
> > @@ -0,0 +1,10 @@
> > +# -*- coding: utf-8; mode: python -*-
> > +
> > +project = 'Linux Kernel Development Documentation'
> > +
> > +tags.add("subproject")
> > +
> > +latex_documents = [
> > +('index', 'maintainer.tex', 'Linux Kernel Development Documentation',
> > + 'The kernel development community', 'manual'),
> > +]
> > diff --git a/Documentation/maintainer/configure-git.rst
> > b/Documentation/maintainer/configure-git.rst
> > new file mode 100644
> > index ..780d2c84
> > --- /dev/null
> > +++ b/Documentation/maintainer/configure-git.rst
> > @@ -0,0 +1,34 @@
> > +.. _configuregit:
> > +
> > +Configure Git
> > +=
> > +
> > +This chapter describes maintainer level git configuration.
> > +
> > +Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst
> > +` should be signed with the developers public GPG key. Signed
> > +tags can be created by passing the ``-u`` flag to ``git tag``. However,
> > +since you would *usually* use the same key for the same project, you can
> > +set it once with
> > +::
> > +
> > + git config user.signingkey "keyname"
> > +
> > +Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand:
> > +::
> > +
> > + [user]
> > + name = Jane Developer
> > + email = j...@domain.org
> > + signingkey = j...@domain.org
> > +
> > +You may need to tell ``git`` to use ``gpg2``
> > +::
> > +
> > + [gpg]
> > + program = /path/to/gpg2
> > +
> > +You may also like to tell ``gpg`` which ``tty`` to use (add to your shell
> > rc file)
> > +::
> > +
> > + export GPG_TTY=$(tty)
> > diff --git a/Documentation/maintainer/index.rst
> > b/Documentation/maintainer/index.rst
> > new file mode 100644
> > index ..fa84ac9cae39
> > --- /dev/null
> > +++ b/Documentation/maintainer/index.rst
> > @@ -0,0 +1,10 @@
> > +==
> > +Kernel Maintainer Handbook
> > +==
> > +
> > +.. toctree::
> > + :maxdepth: 2
> > +
> > + configure-git
> > + pull-requests
> > +
> > diff --git a/Documentation/maintainer/pull-requests.rst
> > b/Documentation/maintainer/pull-requests.rst
> > new file mode 100644
> > index ..0ca9f9bfd679
> > --- /dev/null
> > +++ b/Documentation/maintainer/pull-requests.rst
> > @@ -0,0 +1,178 @@
> > +.. _pullrequests:
> > +
> > +Creating Pull Requests
> > +==
> > +
> > +This chapter d
Re: [PATCH v5 11/11] intel_sgx: driver documentation
+ Cc: KVM, Paolo and Radim On Mon, 2017-11-27 at 09:03 -0800, Sean Christopherson wrote: > On Tue, 2017-11-21 at 01:08 +0200, Jarkko Sakkinen wrote: > > > > On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote: > > > > > > > > > This is architecural. From the cursory read of that series it seems there > > > are two parts to it: > > > > > > 1) The actual core handling, which should be in arch/x86 because that > > > hardly qualifies as a 'platform' device driver. > > > > > > 2) The user space interface, which can be separated out perhaps. > > > > > > I don't know how intertwingled they are, but that's hard to tell from the > > > actual patches w/o doing a deep inspection. Jarkko should be able to > > > answer > > > that. > > > > > > Thanks, > > > > > > tglx > > Darren, tglx, > > > > You can leave user space device as separate module as sgx_ioctl.c merely > > calls stuff that I have inside sgx_encl.c. VMA creation is bound to file > > operations. > > > > My questions would be: > > > > 1. What is your recommendation on the deployment under arch/x86? > > 2. Which parts should be compilable as a LKM? Only the user interface > > or both parts? > > > > /Jarkko > To enable KVM and a cgroup for EPC accounting, at a minimum arch/x86 needs to > manage the EPC pages (alloc/free/lrus/reclaim/etc...) and LE hash MSRs. IMO, > ideally everything else would be left in the device driver, e.g. anything > involving ENCLS. Keeping the majority of the driver out of arch/x86 minimizes > the footprint in arch/x86 and thereby the size of KVM's dependency required to > virtualize SGX, and allows the various SGX pieces, e.g. arch, driver and KVM, > to evolve more independently. > > Preferably the arch/x86 code would not be a loadable module, e.g. to simplify > KVM support. > > I have a branch based on Jarkko's patches (I believe it's up-to-date with v5) > that implements what I described. I'd be happy to send RFC patches if that > would help. > > > Branches for those interested: > > https://github.com/sean-jc/linux.git sgx/arch - move core EPC to arch/x86 > https://github.com/sean-jc/linux.git sgx/kvm - KVM support for SGX > https://github.com/sean-jc/linux.git sgx/lc - KVM support for Launch > Control > https://github.com/sean-jc/linux.git sgx/cgroup - EPC cgroup > > > branch relationships: > > Jarkko's patches > | > | > sgx/arch > /\ > sgx/kvmsgx/cgroup > / > sgx/lc -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] doc: add maintainer book
Em Sat, 25 Nov 2017 08:44:19 +1100
"Tobin C. Harding" escreveu:
> There is currently very little documentation in the kernel on maintainer
> level tasks. In particular there are no documents on creating pull
> requests to submit to Linus.
>
> Quoting Greg Kroah-Hartman on LKML:
>
> Anyway, this actually came up at the kernel summit / maintainer
> meeting a few weeks ago, in that "how do I make a
> good pull request to Linus" is something we need to document.
>
> Here's what I do, and it seems to work well, so maybe we should turn
> it into the start of the documentation for how to do it.
>
> (quote references: kernel summit, Europe 2017)
>
> Create a new kernel documentation book 'how to be a maintainer'
> (suggested by Jonathan Corbet). Add chapters on 'configuring git' and
> 'creating a pull request'.
>
> Most of the content was written by Linus Torvalds and Greg Kroah-Hartman
> in discussion on LKML. This is stated at the start of one of the
> chapters and the original email thread is referenced in
> 'pull-requests.rst'.
>
> Signed-off-by: Tobin C. Harding
> ---
>
> v2:
> - Change title of book, suggested by Dan Williams.
>
> thanks,
> Tobin.
>
> Documentation/index.rst| 1 +
> Documentation/maintainer/conf.py | 10 ++
> Documentation/maintainer/configure-git.rst | 34 ++
> Documentation/maintainer/index.rst | 10 ++
> Documentation/maintainer/pull-requests.rst | 178
> +
> 5 files changed, 233 insertions(+)
> create mode 100644 Documentation/maintainer/conf.py
> create mode 100644 Documentation/maintainer/configure-git.rst
> create mode 100644 Documentation/maintainer/index.rst
> create mode 100644 Documentation/maintainer/pull-requests.rst
>
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index cb7f1ba5b3b1..a4fb34dddcf3 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -52,6 +52,7 @@ merged much easier.
> dev-tools/index
> doc-guide/index
> kernel-hacking/index
> + maintainer/index
>
> Kernel API documentation
>
> diff --git a/Documentation/maintainer/conf.py
> b/Documentation/maintainer/conf.py
> new file mode 100644
> index ..81e9eb7a7884
> --- /dev/null
> +++ b/Documentation/maintainer/conf.py
> @@ -0,0 +1,10 @@
> +# -*- coding: utf-8; mode: python -*-
> +
> +project = 'Linux Kernel Development Documentation'
> +
> +tags.add("subproject")
> +
> +latex_documents = [
> +('index', 'maintainer.tex', 'Linux Kernel Development Documentation',
> + 'The kernel development community', 'manual'),
> +]
> diff --git a/Documentation/maintainer/configure-git.rst
> b/Documentation/maintainer/configure-git.rst
> new file mode 100644
> index ..780d2c84
> --- /dev/null
> +++ b/Documentation/maintainer/configure-git.rst
> @@ -0,0 +1,34 @@
> +.. _configuregit:
> +
> +Configure Git
> +=
> +
> +This chapter describes maintainer level git configuration.
> +
> +Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst
> +` should be signed with the developers public GPG key. Signed
> +tags can be created by passing the ``-u`` flag to ``git tag``. However,
> +since you would *usually* use the same key for the same project, you can
> +set it once with
> +::
> +
> + git config user.signingkey "keyname"
> +
> +Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand:
> +::
> +
> + [user]
> + name = Jane Developer
> + email = j...@domain.org
> + signingkey = j...@domain.org
> +
> +You may need to tell ``git`` to use ``gpg2``
> +::
> +
> + [gpg]
> + program = /path/to/gpg2
> +
> +You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc
> file)
> +::
> +
> + export GPG_TTY=$(tty)
> diff --git a/Documentation/maintainer/index.rst
> b/Documentation/maintainer/index.rst
> new file mode 100644
> index ..fa84ac9cae39
> --- /dev/null
> +++ b/Documentation/maintainer/index.rst
> @@ -0,0 +1,10 @@
> +==
> +Kernel Maintainer Handbook
> +==
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + configure-git
> + pull-requests
> +
> diff --git a/Documentation/maintainer/pull-requests.rst
> b/Documentation/maintainer/pull-requests.rst
> new file mode 100644
> index ..0ca9f9bfd679
> --- /dev/null
> +++ b/Documentation/maintainer/pull-requests.rst
> @@ -0,0 +1,178 @@
> +.. _pullrequests:
> +
> +Creating Pull Requests
> +==
> +
> +This chapter describes how maintainers can create and submit pull requests
> +to other maintainers. This is useful for transferring changes from one
> +maintainers tree to another maintainers tree.
> +
> +This document was written by Tobin C. Harding (who at that time, was not an
> +experienced maintainer) primarily from comments made by Greg Kroah-Hartman
> +and L
Re: [PATCH v5 11/11] intel_sgx: driver documentation
On Tue, 2017-11-21 at 01:08 +0200, Jarkko Sakkinen wrote: > On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote: > > > > This is architecural. From the cursory read of that series it seems there > > are two parts to it: > > > > 1) The actual core handling, which should be in arch/x86 because that > > hardly qualifies as a 'platform' device driver. > > > > 2) The user space interface, which can be separated out perhaps. > > > > I don't know how intertwingled they are, but that's hard to tell from the > > actual patches w/o doing a deep inspection. Jarkko should be able to answer > > that. > > > > Thanks, > > > > tglx > Darren, tglx, > > You can leave user space device as separate module as sgx_ioctl.c merely > calls stuff that I have inside sgx_encl.c. VMA creation is bound to file > operations. > > My questions would be: > > 1. What is your recommendation on the deployment under arch/x86? > 2. Which parts should be compilable as a LKM? Only the user interface > or both parts? > > /Jarkko To enable KVM and a cgroup for EPC accounting, at a minimum arch/x86 needs to manage the EPC pages (alloc/free/lrus/reclaim/etc...) and LE hash MSRs. IMO, ideally everything else would be left in the device driver, e.g. anything involving ENCLS. Keeping the majority of the driver out of arch/x86 minimizes the footprint in arch/x86 and thereby the size of KVM's dependency required to virtualize SGX, and allows the various SGX pieces, e.g. arch, driver and KVM, to evolve more independently. Preferably the arch/x86 code would not be a loadable module, e.g. to simplify KVM support. I have a branch based on Jarkko's patches (I believe it's up-to-date with v5) that implements what I described. I'd be happy to send RFC patches if that would help. Branches for those interested: https://github.com/sean-jc/linux.git sgx/arch - move core EPC to arch/x86 https://github.com/sean-jc/linux.git sgx/kvm - KVM support for SGX https://github.com/sean-jc/linux.git sgx/lc - KVM support for Launch Control https://github.com/sean-jc/linux.git sgx/cgroup - EPC cgroup branch relationships: Jarkko's patches | | sgx/arch /\ sgx/kvmsgx/cgroup / sgx/lc -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/2] thunderbolt: Make pathname to force_power shorter
On Fri, Oct 20, 2017 at 09:49:37PM +0300, Andy Shevchenko wrote: > WMI is the bus inside kernel, so, we may access the GUID via > /sys/bus/wmi instead of doing this through /sys/devices path. > > Signed-off-by: Andy Shevchenko Applied with Mario's ACK. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
