On 18-02-17, 02:36, Rafael J. Wysocki wrote:
> +CPU Initialization
> +==
> +
> +Next, the scaling driver's ``->init()`` callback is invoked with the policy
> +pointer of the new CPU passed to it as the argument. If the policy object
> +pointed to by it is new
The callbacks don't
On Thu, Feb 16, 2017 at 09:43:19AM -0600, Tom Lendacky wrote:
> This patch adds support to the early boot code to use Secure Memory
> Encryption (SME). Support is added to update the early pagetables with
> the memory encryption mask and to encrypt the kernel in place.
>
> The routines to set the
On Monday, February 20, 2017 03:26:08 PM Viresh Kumar wrote:
> On 18-02-17, 02:36, Rafael J. Wysocki wrote:
> > +CPU Initialization
> > +==
> > +
>
>
> > +Next, the scaling driver's ``->init()`` callback is invoked with the policy
> > +pointer of the new CPU passed to it as the ar
From: Rafael J. Wysocki
There is a better way to represent structure references than it was
done in device.rst by commit 730c4c053012 (PM / sleep / docs: Convert
PM notifiers document to reST), which is to use "struct name" as a
link caption (e.g. :c:type:`struct device `). That will
cause sphin
From: Rafael J. Wysocki
The format of the structure references in device_link.rst is
incorrect, because it doesn't cause proper references to the
struct data types to be generated (for struct dev_pm_domain in
particular).
Fix that by using the :c:type:`struct name ` convention
for encoding refer
Hi Jon,
These two patches fix references to struct data types in two documents that
did those things more or less incorrectly.
Both of them fix existing commits, one in the mainline and one in your tree.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
t
On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
Let's not write it like some technical document: "Secu
On Thu, Feb 16, 2017 at 09:43:48AM -0600, Tom Lendacky wrote:
> Add to the early_memremap support to be able to specify encrypted and
early_memremap()
Please append "()" to function names in your commit messages text.
> decrypted mappings with and without write-protection. The use of
> write-pro
On Thu, Feb 16, 2017 at 09:43:58AM -0600, Tom Lendacky wrote:
> Add support to be able to either encrypt or decrypt data in place during
> the early stages of booting the kernel. This does not change the memory
> encryption attribute - it is used for ensuring that data present in either
> an encryp
On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote:
> Adding general kernel support for memory encryption includes:
> - Modify and create some page table macros to include the Secure Memory
> Encryption (SME) memory encryption mask
> - Modify and create some macros for calculating physi
I ran a script like the one below to make the various Sphinx and
DocBook documentations targets for v4.10 on my Fedora 25 desktop
make O=/tmp/sphinx-out DOCBOOKS="" htmldocs
make O=/tmp/sphinx-out DOCBOOKS="" latexdocs
make O=/tmp/sphinx-out DOCBOOKS="" pdfdocs
make O=/tmp/sphinx-out DOCBOOKS="" e
On Thu, Feb 16, 2017 at 09:44:11AM -0600, Tom Lendacky wrote:
> The boot data and command line data are present in memory in a decrypted
> state and are copied early in the boot process. The early page fault
> support will map these areas as encrypted, so before attempting to copy
> them, add decr
On Thu, Feb 16, 2017 at 09:44:30AM -0600, Tom Lendacky wrote:
> This patch adds support to return the E820 type associated with an address
s/This patch adds/Add/
> range.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/e820/api.h |2 ++
> arch/x86/include/asm/e820/types.h |
On Mon, 20 Feb 2017 12:19:24 -0700
Jim Davis wrote:
> pdfdocs (Sphinx or DocBook) has been broken for some time, while
> psdocs hasn't worked in ages. The errors with the Sphinx htmldocs and
> epubdocs targets seem to be some Python issue:
pdfdocs works for me. With Fedora, there are a thousan
On Mon, 20 Feb 2017 15:23:29 +0100
"Rafael J. Wysocki" wrote:
> These two patches fix references to struct data types in two documents that
> did those things more or less incorrectly.
>
> Both of them fix existing commits, one in the mainline and one in your tree.
I've applied them both, and w
On Monday, February 20, 2017 02:58:27 PM Rafael J. Wysocki wrote:
> On Monday, February 20, 2017 03:26:08 PM Viresh Kumar wrote:
> > On 18-02-17, 02:36, Rafael J. Wysocki wrote:
> > > +CPU Initialization
> > > +==
> > > +
> >
> >
> > > +Next, the scaling driver's ``->init()`` call
From: Rafael J. Wysocki
The user/admin documentation of cpufreq is badly outdated. It
conains stale and/or inaccurate information along with things
that are not particularly useful. Also, some of the important
pieces are missing from it.
For this reason, add a new user/admin document for cpufr
On 20-02-17, 14:58, Rafael J. Wysocki wrote:
> Yes, it is called for new and inactive policies.
>
> For new policies it has to populate policy->cpus (because otherwise the core
> doesn't know what CPUs should be there), which quite arguably doesn't have
> to (or even doesn't need to) be done for i
18 matches
Mail list logo
