[PATCH 4.5/20] Docs: dt: document ARM SMMUv3 generic binding usage

2016-09-09 Thread Robin Murphy
Now that we've ratified SMMUv3's use of the generic binding, document it. CC: Rob Herring CC: Mark Rutland Signed-off-by: Robin Murphy --- Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt | 8 +++- 1 file changed, 7

[PATCH 22/20] iommu/arm-smmu: Fall back to global bypass

2016-09-09 Thread Robin Murphy
Unlike SMMUv2, SMMUv3 has no easy way to bypass unknown stream IDs, other than allocating and filling in the entire stream table with bypass entries, which for some configurations would waste *gigabytes* of RAM. Otherwise, all transactions on unknown stream IDs will simply be aborted with a

[PATCH 21/20] drm/exynos: Fix iommu_dma_init_domain prototype change

2016-09-09 Thread Robin Murphy
When adding an extra argument to a function, one really should try a bit harder to catch *all* the callers... CC: Marek Szyprowski CC: Inki Dae CC: David Airlie CC: dri-de...@lists.freedesktop.org Signed-off-by: Robin Murphy

Re: [PATCH v6 00/20] Generic DT bindings for PCI IOMMUs and ARM SMMU

2016-09-09 Thread Will Deacon
Hi Robin, On Tue, Sep 06, 2016 at 04:33:33PM +0100, Robin Murphy wrote: > Here's v6 to address last week's comments. For the sake of honesty I've > left Lorenzo's tested-by off everything I've changed since, and Eric's > reviewed-by off patch 19 having non-trivially reworked the guts of it. > >

Re: [RFC PATCH v2 13/20] x86: Decrypt trampoline area if memory encryption is active

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:57PM -0500, Tom Lendacky wrote: > When Secure Memory Encryption is enabled, the trampoline area must not > be encrypted. A cpu running in real mode will not be able to decrypt s/cpu/CPU/... always :-) > memory that has been encrypted because it will not be able to

Re: [RFC PATCH v2 12/20] x86: Add support for changing memory encryption attribute

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:49PM -0500, Tom Lendacky wrote: > This patch adds support to be change the memory encryption attribute for > one or more memory pages. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/cacheflush.h |3 + >

Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:38PM -0500, Tom Lendacky wrote: > BOOT data (such as EFI related data) is not encyrpted when the system is > booted and needs to be accessed as non-encrypted. Add support to the > early_memremap API to identify the type of data being accessed so that > the proper

Re: [RFC PATCH v2 10/20] x86: Insure that memory areas are encrypted when possible

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:23PM -0500, Tom Lendacky wrote: > Encrypt memory areas in place when possible (e.g. zero page, etc.) so > that special handling isn't needed afterwards. > > Signed-off-by: Tom Lendacky > --- > arch/x86/kernel/head64.c | 93 >

Re: [PATCH v6.1] iommu/dma: Add support for mapping MSIs

2016-09-09 Thread Marc Zyngier
Hi Robin, On 07/09/16 10:55, Robin Murphy wrote: > When an MSI doorbell is located downstream of an IOMMU, attaching > devices to a DMA ops domain and switching on translation leads to a rude > shock when their attempt to write to the physical address returned by > the irqchip driver faults (or

Re: [PATCH v6.1] iommu/dma: Add support for mapping MSIs

2016-09-09 Thread Thomas Gleixner
On Wed, 7 Sep 2016, Robin Murphy wrote: > - Rework map_page() helper function plus insane lookup logic into > straightforward get_page() helper > - Use phys_addr_t to further simplify address matching > - Fix the bit where I neglected to actually round the doorbell > address to a page boundary

Re: Stability connection problems in ath9k kernel 4.7

2016-09-09 Thread Valerio Passini
On venerdì 9 settembre 2016 10:38:32 CEST Joerg Roedel wrote: > Hi Valerio, > > On Thu, Sep 08, 2016 at 09:07:56PM +0200, Valerio Passini wrote: > > I'm hoping having done it right and I can try your first suggestion, but I > > really cannot solve this problem by myself: sorry, I have no

[PATCH v5 12/14] drivers: acpi: iort: replace rid map type with type mask

2016-09-09 Thread Lorenzo Pieralisi
IORT tables provide data that allow the kernel to carry out device ID mappings between endpoints and system components (eg interrupt controllers, IOMMUs). When the mapping for a given device ID is carried out, the translation mechanism is done on a per-subsystem basis rather than a component

[PATCH v5 14/14] drivers: acpi: iort: introduce iort_iommu_configure

2016-09-09 Thread Lorenzo Pieralisi
DT based systems have a generic kernel API to configure IOMMUs for devices (ie of_iommu_configure()). On ARM based ACPI systems, the of_iommu_configure() equivalent can be implemented atop ACPI IORT kernel API, with the corresponding functions to map device identifiers to IOMMUs and retrieve the

[PATCH v5 13/14] drivers: acpi: iort: add single mapping function

2016-09-09 Thread Lorenzo Pieralisi
The current IORT id mapping API requires components to provide an input requester ID (a Bus-Device-Function (BDF) identifier for PCI devices) to translate an input identifier to an output identifier through an IORT range mapping. Named components do not have an identifiable source ID therefore

[PATCH v5 06/14] drivers: acpi: implement acpi_dma_configure

2016-09-09 Thread Lorenzo Pieralisi
On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This

[PATCH v5 08/14] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions

2016-09-09 Thread Lorenzo Pieralisi
Current ARM SMMUv3 probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU v3 driver features. In order to allow probing the ARM SMMUv3 with other firmwares than DT, this patch splits the ARM SMMUv3 init functions into DT and HW specific

[PATCH v5 11/14] drivers: iommu: arm-smmu: add IORT configuration

2016-09-09 Thread Lorenzo Pieralisi
In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU components. Add static configuration

[PATCH v5 05/14] drivers: iommu: make iommu_fwspec OF agnostic

2016-09-09 Thread Lorenzo Pieralisi
The iommu_fwspec structure, used to hold per device iommu configuration data is not OF specific and therefore can be moved to a generic and OF independent compilation unit. In particular, the iommu_fwspec handling hinges on the device_node pointer to identify the IOMMU device associated with the

[PATCH v5 09/14] drivers: iommu: arm-smmu-v3: add IORT configuration

2016-09-09 Thread Lorenzo Pieralisi
In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU v3 components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU v3 components. Add static

[PATCH v5 07/14] drivers: acpi: iort: add support for ARM SMMU platform devices creation

2016-09-09 Thread Lorenzo Pieralisi
In ARM ACPI systems, IOMMU components are specified through static IORT table entries. In order to create platform devices for the corresponding ARM SMMU components, IORT kernel code should be made able to parse IORT table entries and create platform devices dynamically. This patch adds the

[PATCH v5 04/14] drivers: acpi: iort: add support for IOMMU fwnode registration

2016-09-09 Thread Lorenzo Pieralisi
The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world) components that allow creating the kernel data structures required to probe and initialize the IOMMU devices. This patch provides support in the IORT kernel code to register IOMMU components and their respective fwnode.

[PATCH v5 00/14] ACPI IORT ARM SMMU support

2016-09-09 Thread Lorenzo Pieralisi
This patch series is v5 of a previous posting: https://lkml.org/lkml/2016/8/15/394 v4 -> v5 - Added SMMUv1/v2 support - Rebased against v4.8-rc5 and dependencies series - Consolidated IORT platform devices creation v3 -> v4 - Added single mapping API (for IORT

[PATCH v5 02/14] drivers: iommu: implement arch_{set/get}_iommu_fwspec API

2016-09-09 Thread Lorenzo Pieralisi
The iommu fwspec configuration mechanism currently relies on the arch specific struct dev_archdata.iommu member to stash the struct iommu_fwspec pointer set-up for streamid translation. The struct dev_archdata.iommu member is arch specific and is not present on all arches that make use of the

[PATCH v5 03/14] drivers: acpi: iort: introduce linker section for IORT entries probing

2016-09-09 Thread Lorenzo Pieralisi
Since commit e647b532275b ("ACPI: Add early device probing infrastructure") the kernel has gained the infrastructure that allows adding linker script section entries to execute ACPI driver callbacks (ie probe routines) for all subsystems that register a table entry in the respective kernel section

[PATCH v5 01/14] drivers: iommu: add FWNODE_IOMMU fwnode type

2016-09-09 Thread Lorenzo Pieralisi
On systems booting with a device tree, every struct device is associated with a struct device_node, that represents its DT representation. The device node can be used in generic kernel contexts (eg IRQ translation, IOMMU streamid mapping), to retrieve the properties associated with the device and

Re: [PATCH] iommu/arm-smmu: Disable interrupts whilst holding the cmdq lock

2016-09-09 Thread Jean-Philippe Brucker
Hi Will, On 09/09/16 14:50, Will Deacon wrote: > The cmdq lock is taken whenever we issue comments into the command queue, s/comments/commands/ > which can occur in IRQ context (as a result if unmap) or in process s/if/of/ > context (as a result of a threaded IRQ handler or device probe). >

[PATCH] iommu/arm-smmu: Disable interrupts whilst holding the cmdq lock

2016-09-09 Thread Will Deacon
The cmdq lock is taken whenever we issue comments into the command queue, which can occur in IRQ context (as a result if unmap) or in process context (as a result of a threaded IRQ handler or device probe). This can lead to a theoretical deadlock if the interrupt handler performing the unmap hits

RE: [PATCH 4/8] of: dma: Split of_configure_dma() into mask and ops configuration

2016-09-09 Thread Sricharan
Hi Magnus, >On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote: >> From: Laurent Pinchart >> >> The of_configure_dma() function configures both the DMA masks and ops. >> Moving DMA ops configuration to probe time would thus

Re: Stability connection problems in ath9k kernel 4.7

2016-09-09 Thread Joerg Roedel
Hi Valerio, On Thu, Sep 08, 2016 at 09:07:56PM +0200, Valerio Passini wrote: > I'm hoping having done it right and I can try your first suggestion, but I > really cannot solve this problem by myself: sorry, I have no capabilities in > programming in any known and unknown computer language.

Re: [PATCH 4/8] of: dma: Split of_configure_dma() into mask and ops configuration

2016-09-09 Thread Magnus Damm
On Tue, Aug 9, 2016 at 7:49 AM, Sricharan R wrote: > From: Laurent Pinchart > > The of_configure_dma() function configures both the DMA masks and ops. > Moving DMA ops configuration to probe time would thus also delay >