Re: [RFC PATCH v4 21/28] x86: Check for memory encryption on the APs

On 2/27/2017 12:17 PM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:46:47AM -0600, Tom Lendacky wrote: Add support to check if memory encryption is active in the kernel and that it has been enabled on the AP. If memory encryption is active in the kernel but has not been enabled on the AP,

Re: [RFC PATCH v4 16/28] x86: Add support for changing memory encryption attribute

On 2/22/2017 12:52 PM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:45:35AM -0600, Tom Lendacky wrote: Add support for changing the memory encryption attribute for one or more memory pages. "This will be useful when we, , for example." Yup, will expand on the "why".

Re: [PATCH 6/6] drm/doc: atomic overview, with graph

Daniel Vetter writes: > I want to split up a few more things and document some details better > (like how exactly to subclass drm_atomic_state). And maybe also split > up the helpers a bit per-topic, but this should be a ok-ish start for > better atomic overview. > > One

Re: [PATCH 4/6] drm/doc: Consistent kerneldoc include order

Daniel Vetter writes: > First overview text (if there is any), then headers (since generally > you want to start out with the data structures), then all the other > stuff with functions. > > Most of this is pre-shpinx, since with the old docbook only the "sphinx"

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

On 2/27/2017 11:52 AM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:46:19AM -0600, Tom Lendacky wrote: Add warnings to let the user know when bounce buffers are being used for DMA when SME is active. Since the bounce buffers are not in encrypted memory, these notifications are to allow

Re: [PATCH 5/6] drm/doc: diagram for mode objects and properties

Daniel Vetter writes: > Resulted in confusion a few times in the past. > > Cc: Laurent Pinchart > Cc: Manasi Navare > Signed-off-by: Daniel Vetter > --- >

Re: [RFC PATCH v4 05/28] x86: Add Secure Memory Encryption (SME) support

On 2/25/2017 9:29 AM, Borislav Petkov wrote: On Thu, Feb 16, 2017 at 09:43:07AM -0600, Tom Lendacky wrote: Add support for Secure Memory Encryption (SME). This initial support provides a Kconfig entry to build the SME support into the kernel and defines the memory encryption mask that will be

Re: [RFC PATCH v4 11/28] x86: Add support to determine the E820 type of an address

On 2/20/2017 2:09 PM, Borislav Petkov wrote: 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 ---

[PATCH v6 0/4] Application Data Integrity feature introduced by SPARC M7

SPARC M7 processor adds additional metadata for memory address space that can be used to secure access to regions of memory. This additional metadata is implemented as a 4-bit tag attached to each cacheline size block of memory. A task can set a tag on any number of such blocks. Access to such

[PATCH v6 4/4] sparc64: Add support for ADI (Application Data Integrity)

ADI is a new feature supported on SPARC M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

On Tue, Feb 28, 2017 at 10:11:56AM -0700, Logan Gunthorpe wrote: > In any case, I also wish we could have had this discussion 3 months ago > when we posted the RFC and not when I have people pushing to get this > merged. Relax, there is no rush here, no deadlines, etc. Moving the files to a

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

On Tue, Feb 28, 2017 at 04:17:52PM +0100, Peter Rosin wrote: > Hi! > > The status of this series [1] is that Rob Herring has acked/reviewed all > devicetree changes, so I suppose that's ok. Jonathan Cameron has acked > the additions to the iio subsystem and reviewed the new iio driver. > Wolfram

[PATCH 3/6] drm/doc: Add KMS overview graphs

Oh, the shiny and pretties! Cc: Laurent Pinchart Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 4 ++ Documentation/gpu/drm-kms.rst | 132 ++ 2 files changed, 136

[PATCH 1/6] doc: Explain light-handed markup preference a bit better

We already had a super-short blurb, but worth extending it I think: We're still pretty far away from anything like a consensus, but there's clearly a lot of people who prefer an as-light as possible approach to converting existing .txt files to .rst. Make sure this is properly taken into account

[PATCH 5/6] drm/doc: diagram for mode objects and properties

Resulted in confusion a few times in the past. Cc: Laurent Pinchart Cc: Manasi Navare Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst | 22 ++ 1 file changed, 22

[PATCH 4/6] drm/doc: Consistent kerneldoc include order

First overview text (if there is any), then headers (since generally you want to start out with the data structures), then all the other stuff with functions. Most of this is pre-shpinx, since with the old docbook only the overview stuff was pulled in directly. Everything else was put in a

[PATCH 2/6] docs-rst: automatically convert Graphviz and SVG images

From: Markus Heiser This patch brings scalable figure, image handling and a concept to embed *render* markups: * DOT (http://www.graphviz.org) * SVG For image handling use the 'image' replacement:: .. kernel-image:: svg_image.svg :alt:simple SVG

[PATCH 6/6] drm/doc: atomic overview, with graph

I want to split up a few more things and document some details better (like how exactly to subclass drm_atomic_state). And maybe also split up the helpers a bit per-topic, but this should be a ok-ish start for better atomic overview. One thing I failed at is getting DOT to layout the overview

[PATCH 0/6] more kernel-doc patches

Hi all, Finally gotten around to polish and flush these out. I think Markus' kfigure/kimage/krender support is now simplified a lot (at least as much as I managed with my python/sphinx noob-ness), and also rebase the doc patch about the light markup approach we've discussed a while ago.

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

> This driver doesn't have anything to do with the PCI core, other than > using the pci_register_driver() interface (just like all other drivers > for PCI-connected devices), so drivers/pci doesn't really feel like > the right place for it. Putting it in drivers/pci leads to the sort > of

Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes

Hi! The status of this series [1] is that Rob Herring has acked/reviewed all devicetree changes, so I suppose that's ok. Jonathan Cameron has acked the additions to the iio subsystem and reviewed the new iio driver. Wolfram Sang has acked the i2c-mux driver. That's acks or reviews from the

Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver

Hi Logan, On Sat, Feb 25, 2017 at 11:53:13PM -0700, Logan Gunthorpe wrote: > ... > This is a continuation of the RFC we posted lasted month [1] which > proposes a management driver for Microsemi's Switchtec line of PCI > switches. This hardware is still looking to be used in the Open > Compute

Re: [RFC PATCH v4 26/28] x86: Allow kexec to be used with SME

On Thu, Feb 16, 2017 at 09:47:55AM -0600, Tom Lendacky wrote: > Provide support so that kexec can be used to boot a kernel when SME is > enabled. > > Support is needed to allocate pages for kexec without encryption. This > is needed in order to be able to reboot in the kernel in the same manner