On 28/07/15 15:05, Boris Ostrovsky wrote:
> On 07/28/2015 06:29 AM, Andrew Cooper wrote:
>>
After forward-porting my virtio patches, I got this thing to run on
Xen. After several tries, I got:
[ 53.985707] [ cut here ]
[ 53.986314] kernel BUG at
In some early boot circumstances, it may be necessary to copy
from RAM outside the kernel linear mapping to mapped RAM. The
need to relocate an initrd is one example in the x86 code. This
patch creates a helper function based on current x86 code.
Signed-off-by: Mark Salter
---
include/asm-generi
When booting an arm64 kernel w/initrd using UEFI/grub, use of mem= will likely
cut off part or all of the initrd. This leaves it outside the kernel linear
map which leads to failure when unpacking. The x86 code has a similar need to
relocate an initrd outside of mapped memory in some cases.
The cu
In our effort to support vendors writing drivers for their own
sensors we introduce IIO documentation in DocBook format.
It documents Industrial I/O core including IIO devices, buffers, triggers and
triggered buffers. It also offers a short list of online resources
for the IIO subsystem.
This is
On 7/26/2015 6:27 PM, Sungbae Yoo wrote:
> So, Do you agree to allow the process to change its own labels?
No. This requires CAP_MAC_ADMIN. Smack is mandatory access control.
Being in a namespace (as they are implemented today) is not sufficient.
>
> Now, init process(eg. systemd) can't be runnin
On Tue, Jul 28, 2015 at 11:32:57AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jul 28, 2015 at 04:30:18PM +0200, Jiri Olsa escreveu:
> > On Tue, Jul 28, 2015 at 11:21:32AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Jul 28, 2015 at 04:10:06PM +0200, Jiri Olsa escreveu:
> > > > On Mon,
On 28 July 2015 at 16:33, Marek Vasut wrote:
> On Tuesday, July 28, 2015 at 11:07:57 AM, Michal Suchanek wrote:
>> This 1.8V SPI NOR flash is found on ARM Chromebook XE303C and reads
>> something like 25LQ32VIG in the middle.
>>
>> Signed-off-by: Michal Suchanek
>> ---
>> drivers/mtd/spi-nor/spi
On Tue, 2015-07-28 at 11:41 +0100, Robin Murphy wrote:
> On 28/07/15 11:03, Joerg Roedel wrote:
> > On Mon, Jul 27, 2015 at 04:57:32PM -0700, Ashutosh Dixit wrote:
> > > From: Harish Chegondi
> > >
> > > This patch converts iova.c into a library, moving it from
> > > drivers/iommu/ to lib/, and e
On 07/24/2015 04:43 PM, Bjorn Helgaas wrote:
> I regularly see faults like this on an APM X-Gene:
>
> U-Boot 2013.04-mustang_sw_1.14.14 (Dec 16 2014 - 15:59:33)
> CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
>32 KB ICACHE, 32 KB DCACHE
>SOC 2000MHz IOBAXI 400MHz AXI
On Tuesday, July 28, 2015 at 04:36:29 PM, Michal Suchanek wrote:
> On 28 July 2015 at 16:33, Marek Vasut wrote:
> > On Tuesday, July 28, 2015 at 11:07:57 AM, Michal Suchanek wrote:
> >> This 1.8V SPI NOR flash is found on ARM Chromebook XE303C and reads
> >> something like 25LQ32VIG in the middle.
On Tue, Jul 28, 2015 at 02:27:42PM +, Shenwei Wang wrote:
> > > +static int gpcv2_wakeup_source_save(void) {
> > > + struct imx_gpcv2_irq *cd;
> >
> > We generally name variables in an abbrev of the types to make them
> > intuitive. I
> > tried hard to map "cd" to "imx_gpcv2_irq" and failed.
On Tue, 28 Jul 2015, Rob Herring wrote:
> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones wrote:
> > These OPPs are used in ST's CPUFreq implementation.
> >
> > Signed-off-by: Lee Jones
> > ---
> >
> > Changelog:
> > - None, new patch
> >
> > Documentation/devicetree/bindings/power/opp-st.txt | 76
The commit b44754d8262d3aab8 ("ring_buffer: Allow to exit the ring
buffer benchmark immediately") added a hack into ring_buffer_producer()
that set @kill_test when kthread_should_stop() returned true. It improved
the situation a lot. It stopped the kthread in most cases because
the producer spent m
Kthreads are currently implemented as an infinite loop. Each
has its own variant of checks for terminating, freezing,
awakening. In many cases it is unclear to say in which state
it is and sometimes it is done a wrong way.
The plan is to convert kthreads into kthread_worker or workqueues
API. It a
The kthread worker API will be used for kthreads that need to modify
the scheduling policy.
This patch adds a function that allows to make it easily, safe way,
and hides implementation details. It might even help to get rid
of an init work.
It uses @sched_priority as a parameter instead of struct
kthread worker API will be used for kthreads that need to modify
the scheduling priority.
This patch adds a function that allows to make it easily, safe way,
and hides implementation details. It might even help to get rid
of an init work.
Signed-off-by: Petr Mladek
---
include/linux/kthread.h
It looks strange to initialize the completions repeatedly.
This patch uses static initialization. It simplifies the code
and even helps to get rid of two memory barriers.
Signed-off-by: Petr Mladek
---
kernel/trace/ring_buffer_benchmark.c | 12 ++--
1 file changed, 2 insertions(+), 10 d
This patch allows to make kthread worker freezable via a new @flags
parameter. It will allow to avoid an init work in some kthreads.
It currently does not affect the function of kthread_worker_fn()
but it might help to do some optimization or fixes eventually.
I currently do not know about any ot
Kthread workers are currently created using the classic kthread API,
namely kthread_run(). kthread_worker_fn() is passed as the @threadfn
parameter.
This patch defines create_kthread_worker_on_node() and
create_kthread_worker() functions that hide implementation details.
It enforces using kthread
Most kthreads are sleeping lots of time. They do some job either
in regular intervals or when there is an event. Many of them combine
the two approaches.
The job is either a "single" operation, e.g. check and make a huge page.
Or the kthread is serving several requests, e.g. handling several NFS
c
After clk core supports mx7d type clocks, we don't have to enable all clock
by default anymore, this patch series remove the enable all clocks code and
only enable set of minimum required clocks instead.
This patch series depends on:
[PATCH V3 0/5] clk: support clocks which requires parent clock o
I would like to make cleaner kthread worker API and hide the definition
of struct kthread_worker. It will prevent any custom hacks and make
the API more secure.
This patch provides an API to check if the worker has been created
and hides the implementation details.
Signed-off-by: Petr Mladek
---
Kthreads are currently implemented as an infinite loop. Each
has its own variant of checks for terminating, freezing,
awakening. In many cases it is unclear to say in which state
it is and sometimes it is done a wrong way.
The plan is to convert kthreads into kthread_worker or workqueues
API. It a
kthread_create_on_node() implements a bunch of logic to create
the kthread. It is already called by kthread_create_on_cpu().
We are going to add a new API that will allow to standardize kthreads
and define safe points for termination, freezing, parking, and even
signal handling. It will want to ca
Some IMX SoC like i.MX7D requires using clk_OPS_PARENT_ON flags,
adding the corresponding clock APIs variants for easy use.
Signed-off-by: Dong Aisheng
---
drivers/clk/imx/clk.h | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/clk/imx/clk.h b/drivers/
On Sun 2015-06-21 13:20:34, Pali Rohár wrote:
> This patch adds dm message commands and option strings to optionally wipe key
> from dm-crypt device before entering suspend or hibernate state.
>
> Before key is wiped dm device must be suspended. To prevent race conditions
> with
> I/O and userspa
Formerly clk core does not support imx7d clock type well that all
its clock operations requires the parent clock on.
Therefore we enabled all clocks by default in clock driver
initialization for other module clocks operate well.
After patch 'clk: imx7d: using api with flag CLK_OPS_PARENT_ON',
clk
i.MX7D requires all clocks operations including enable/disable,
rate change and re-parent with its parent clock on.
Changing to the correct APIs to tell clk core such requirement.
Signed-off-by: Dong Aisheng
---
drivers/clk/imx/clk-imx7d.c | 712 ++--
1 fi
Hi,
Maxime Ripard schrieb am 28.07.2015 14:49:
> I don't feel like holding patches that were posted before you did
> because you did them some time ago and never submitted them is
> reasonnable and / or encouraging for new submitters of patches.
>
> I'd really like to get more sunxi-people contri
>> + converters (DACs), that functionality is also supported.
>
>
> I wouldn't necessarily treat DACs and ADCs differently here. Maybe something
> like:
>
> The main purpose of the Industrial I/O subsystem (IIO) is to provide
> support for devices that in some sense perform either analog
move imx_clk_gate_x api into one place for better code maintenance.
Signed-off-by: Dong Aisheng
---
drivers/clk/imx/clk.h | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
index 1049b0c..cda8756 1006
On Freescale i.MX7D platform, all clocks operations, including
enable/disable, rate change and re-parent, requires its parent clock on.
Current clock core can not support it well.
This patch adding flag CLK_OPS_PARENT_ON to handle this special case in
clock core that enable its parent clock firstly
The current kthread worker users call flush() and stop() explicitly.
The new function will make it easier and will do it better.
Note that flush() does not guarantee that the queue is empty. drain()
is more safe. It returns when the queue is empty. Also is causes
that queue() ignores unexpected wo
Kthreads are currently implemented as an infinite loop. Each
has its own variant of checks for terminating, freezing,
awakening. In many cases it is unclear to say in which state
it is and sometimes it is done a wrong way.
The plan is to convert kthreads into kthread_worker or workqueues
API. It a
efi_call() is a callable non-leaf function which doesn't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
---
arch/x86/platform/efi/efi_stub_64.S | 3 +++
1 file changed, 3 insertion
> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: 2015年7月28日 9:39
> To: Wang Shenwei-B38339
> Cc: shawn@linaro.org; t...@linutronix.de; ja...@lakedaemon.net; Huang
> Yongcai-B20788; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject:
Kthreads are currently implemented as an infinite loop. Each
has its own variant of checks for terminating, freezing,
awakening. Sometimes, it is hard to say if they are done
correctly. They are also harder to maintain if there is
a generic problem found in the area.
I have proposed a so-called kt
stackvalidate reports the following false positive warnings:
stackvalidate: arch/x86/xen/enlighten.o: xen_cpuid()+0x41: can't find jump
dest instruction at .text+0x108
stackvalidate: arch/x86/xen/enlighten.o: xen_setup_gdt.constprop.23()+0x2e:
kernel entry/exit from callable instruction
The
flush_kthread_worker() returns when the currently queued works are proceed.
But some other works might have been queued in the meantime.
This patch adds drain_kthread_work() that is inspired by drain_workqueue().
It returns when the queue is completely empty. Also it affects the behavior
of queue_
clmul_ghash_mul() and clmul_ghash_update() are callable non-leaf
functions which don't honor CONFIG_FRAME_POINTER, which can result in
bad stack traces.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/ghash-clmulni-intel_asm.S
swsusp_arch_suspend() and restore_registers() are callable non-leaf
functions which don't honor CONFIG_FRAME_POINTER, which can result in
bad stack traces. Also they aren't annotated as ELF callable functions
which can confuse tooling.
Create a stack frame for them when CONFIG_FRAME_POINTER is en
On Tuesday 28 July 2015 16:44:19 Pavel Machek wrote:
> On Sun 2015-06-21 13:20:34, Pali Rohár wrote:
> > This patch adds dm message commands and option strings to optionally wipe
> > key
> > from dm-crypt device before entering suspend or hibernate state.
> >
> > Before key is wiped dm device mus
do_suspend_lowlevel() is a callable non-leaf function which doesn't
honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/acpi/wakeup_64.S | 3 +++
1 file changed, 3 i
On Tue, Jul 28, 2015 at 03:10:13PM +0100, Pawel Moll wrote:
> When building with a prefix ending with a slash, for example:
>
> $ make prefix=/usr/local/
>
> one of the perf tests fail to compile due to BUILD_STR macro mishandling
> bindir_SQ string containing with two slashes:
>
> -
Thunk functions are callable non-leaf functions that don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces. Also they
aren't annotated as ELF callable functions which can confuse tooling.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled and
add the ELF function t
If a PVOP call macro is inlined at the beginning of a function, gcc can
insert the call instruction before setting up a stack frame, which
breaks frame pointer convention if CONFIG_FRAME_POINTER is enabled and
can result in a bad stack trace.
Force a stack frame to be created by listing the stack
This is v8 of the compile-time stack validation patch set, based on the
tip/master branch.
The frame pointer macros are still called FRAME and ENDFRAME because I
don't think we converged on anything else yet. Otherwise I tried to
address all the other review comments from v7.
v7 can be found her
rwsem.S has several callable non-leaf functions which don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
---
arch/x86/lib/rwsem.S | 11 ++-
1 file changed, 10 insertions
Paravirt thunk functions aren't aligned, which can impact performance
and is inconsistent with gcc-generated functions.
Align them at 16-byte boundaries to be consistent with gcc functions.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/paravirt.h | 1 +
1 file changed, 1 insertion(+)
Add C versions of the FRAME and ENDFRAME macros which can be used to
create a stack frame in inline assembly.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/frame.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/frame.h b/ar
stackvalidate reports the following warning:
stackvalidate: arch/x86/crypto/crc32c-pcl-intel-asm_64.o: crc_pcl()+0x11dd:
can't decode instruction
It gets confused when trying to decode jump_table data. Move jump_table
to the .rodata section which is a more appropriate home for read-only
data.
On 07/28/2015 10:35 AM, Andrew Cooper wrote:
On 28/07/15 15:05, Boris Ostrovsky wrote:
On 07/28/2015 06:29 AM, Andrew Cooper wrote:
After forward-porting my virtio patches, I got this thing to run on
Xen. After several tries, I got:
[ 53.985707] [ cut here ]
[ 53.9
vide() is a callable function, but is missing the ELF function type,
which confuses tools like stackvalidate.
Properly annotate it to be a callable function. The generated code is
unchanged.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/cpu/amd.c | 5 -
1 file changed, 4 insertions(+),
stackvalidate reports a false positive warning for the ljmp instruction
in machine_real_restart(). Normally, ljmp isn't allowed in a function,
but this is a special case where it's jumping into real mode.
Add the jumps to a whitelist which tells stackvalidate to ignore them.
Signed-off-by: Josh
A function created with the PV_CALLEE_SAVE_REGS_THUNK macro doesn't set
up a new stack frame before the call instruction, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace. Also, the thunk functions aren't annotated as ELF
callable functio
Hi,
On 07/28/2015 04:29 PM, Michal Suchanek wrote:
Hello,
the NAND chips on Cubietech boards are not known to Linux.
I used Petros Angelatos' patch from sunxi experimental tree for one chip and
added another chip.
I hope it's ok to send both patches to avoid merge conflict.
I do not think t
This adds a CONFIG_STACK_VALIDATION option which enables a host tool
named stackvalidate which runs at compile time. It analyzes every .o
file and ensures the validity of its stack metadata. It enforces a set
of rules on asm code and C inline assembly code so that stack traces can
be reliable.
C
stackvalidate reports the following warning:
stackvalidate: arch/x86/crypto/aesni-intel_asm.o: _aesni_inc_init(): can't
find starting instruction
stackvalidate gets confused when it tries to disassemble the following
data in the .text section:
.Lbswap_mask:
.byte 15, 14, 13, 12, 1
On Tue, Jul 28, 2015 at 09:37:03AM -, Michal Suchanek wrote:
> The SPI transfers can mysteriously fail so add more debug prints about
> SPI parameters set by the driver.
>
> The hardware specific SPI driver is the only place where the programmed
> SPI parameters are known so there is no other
If a hypercall is inlined at the beginning of a function, gcc can insert
the call instruction before setting up a stack frame, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace.
Force a stack frame to be created if CONFIG_FRAME_POINTER is
On Fri, Jul 24, 2015 at 12:47:39PM +0100, David Vrabel wrote:
> Add add_memory_resource() to add memory using an existing "System RAM"
> resource. This is useful if the memory region is being located by
> finding a free resource slot with allocate_resource().
>
> Xen guests will make use of this i
The FRAME/ENDFRAME asm macros for setting up and restoring the frame
pointer aren't currently being used. However, they will be needed soon
to help asm functions to comply with stackvalidate.
Make the code more readable and improve the comments.
Signed-off-by: Josh Poimboeuf
---
arch/x86/inclu
Add new stackvalidate ignore macros: STACKVALIDATE_IGNORE_INSN and
STACKVALIDATE_IGNORE_FUNC. These can be used to tell stackvalidate to
skip validation of an instruction or a function, respectively.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stackvalidate.h | 45 +++
Tell stackvalidate to skip validation of the following code:
- boot image
- vdso image
- kexec purgatory
- realmode
- efi libstub
They all run outside the kernel's normal mode of operation and they
don't affect runtime kernel stack traces, so they're free to skirt the
stackvalidate rules.
Signed
On Tue, Jul 28, 2015 at 06:18:05PM +0530, Bhaktipriya Shridhar wrote:
> This patch fixes:
> 1.Fixes comments that are over 80-characters either by:
> -breaking up comment lines, into multi-line comments (kernel style) or
> -shortening comments (Done in 7 places):
> - Chan
On Wed, Jul 01, 2015 at 03:21:04PM -0700, Vikas Shivappa wrote:
Please edit this document to have consistent spacing. Its really hard to
read this. Every time I spot a misplaced space my brain stumbles and I
need to restart.
> diff --git a/Documentation/cgroups/rdt.txt b/Documentation/cgroups/rdt
Hi,
Maxime Ripard schrieb am 28.07.2015 14:55:
>> > I plan to submit this for 4.3.
>>
>> Ok, then I guess we can drop my patch.
>
> Please don't.
Ok.
> It was used in mainline, and reverted because it was not stable
> enough.
Well, the explanation given was, it was not stable because of the mi
Update the eTSEC bindings document with missing info on
properties that are already in use for the PPC platforms:
* "tbi-phy" property;
* "fsl,etsec2" compatibility string;
Signed-off-by: Claudiu Manoil
---
v2 - none;
v3 - added "tbi-handle" documentation;
- fixed typo ("fsl,etsec2" is the cor
From: Joerg Roedel
Since the conversion to default domains the
iommu_attach_device function only works for devices with
their own group. But this isn't always true for current
IOMMUv2 capable devices, so use iommu_attach_group instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_v2
Hi Mark,
As a heads-up, it looks like you missed a space when sending this; Arnd
and Ard got merged into:
"Arnd Bergmann --cc=Ard Biesheuvel"
I've corrected that for this reply.
On Tue, Jul 28, 2015 at 03:32:39PM +0100, Mark Salter wrote:
> When booting an arm64 kernel w/initrd using UEFI/grub
Hi,
here are a couple of fixes for the AMD IOMMU driver for
issues found recently. The issues were introduced by the
default-domain conversion in this development cycle. I plan
to send these fixes upstream by the end of the week.
Please review!
Thanks,
Joerg
Joerg Roedel (5):
iommu/a
This enables the available eTSEC ethernet ports for the
ls1021aqds and ls1021atwr boards.
For the QDS, SGMII connections (via riser cards) are assumed
for the eTSEC0 and eTSEC1 ports as default configuration.
Signed-off-by: Alison Wang
Signed-off-by: Claudiu Manoil
---
v2, v3 - none;
arch/arm/
On 28 July 2015 at 16:38, Marek Vasut wrote:
> On Tuesday, July 28, 2015 at 04:36:29 PM, Michal Suchanek wrote:
>> On 28 July 2015 at 16:33, Marek Vasut wrote:
>> > On Tuesday, July 28, 2015 at 11:07:57 AM, Michal Suchanek wrote:
>> >> This 1.8V SPI NOR flash is found on ARM Chromebook XE303C and
aesni-intel_asm.S has several callable non-leaf functions which don't
honor CONFIG_FRAME_POINTER, which can result in bad stack traces.
Create stack frames for them when CONFIG_FRAME_POINTER is enabled.
Signed-off-by: Josh Poimboeuf
---
arch/x86/crypto/aesni-intel_asm.S | 19 +++
On Tue, 28 Jul 2015, Matt Fleming wrote:
> On Tue, 28 Jul, at 12:37:21PM, Lee Jones wrote:
> >
> > The driver shouldn't be called that either.
> >
> > You are the only one. What makes iTCO 'special'?
>
> I don't know, I didn't write it. It looks like Wim did ~9 years ago, so
> it must have made
From: Joerg Roedel
In passthrough mode (iommu=pt) all devices are identity
mapped. If a device does not support 64bit DMA it might
still need remapping. Make sure swiotlb is initialized to
provide this remapping.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 8 +++-
1 file ch
From: Joerg Roedel
Since devices with IOMMUv2 functionality might be in the
same group as devices without it, allow those devices in
IOMMUv2 domains too.
Otherwise attaching the group with the IOMMUv2 device to the
domain will fail.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 1
From: Joerg Roedel
Some AMD systems also have non-PCI devices which can do DMA.
Those can't be handled by the AMD IOMMU, as the hardware can
only handle PCI. These devices would end up with no dma_ops,
as neither the per-device nor the global dma_ops will get
set. SWIOTLB provides global dma_ops
Hi,
Maxime Ripard schrieb am 28.07.2015 14:55:
>> IMHO for a common maximum opp that's a good approach. But for the lowest
>> frequency setting, it would seem more logical to me, to raise the voltage
>> to a point where all boards will run fine with them, unless those boards
>> cannot handle the
Add basic support for all the eTSEC controllers on the
ls1021a SoC. Second interrupt group register blocks
and their corresponding Rx/Tx/Err interrupt sources are
included as well for each eTSEC node.
Signed-off-by: Alison Wang
Signed-off-by: Claudiu Manoil
---
v2: various findings, added 2nd i
Add support for UPISEMI us5182d als and proximity sensor.
Supports raw readings.
Signed-off-by: Adriana Reus
---
drivers/iio/light/Kconfig | 10 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/us5182d.c | 539
3 files changed, 550 insertio
On Tue, Jul 28, 2015 at 09:19:40PM +0800, Dong Aisheng wrote:
> This patch series adds support in clock framework for clocks which operations
> requires its parent clock is on.
>
> Such clock type is initially met on Freescale i.MX7D platform that all clocks
> operations, including enable/disable,
From: Joerg Roedel
Remove the AMD IOMMU driver implementation for passthrough
mode and rely on the new iommu core features for that.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 58 ++
drivers/iommu/amd_iommu_init.c | 10 +---
2 f
After the commit introducing convertion between DMA and guest address,
all the callers of pfn_to_mfn are expecting to get a GFN (Guest Frame
Number). On ARM, all the guests are auto-translated so the GFN is equal
to the Linux PFN (Pseudo-physical Frame Number).
The current implementation may retur
Hi all,
This patch series aims to use the memory terminologies described in
include/linux/mm.h [1] for Linux xen code.
Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM a
The PV driver xen-fbfront is only dealing with GFN and not MFN. Rename
all the occurence of MFN to GFN.
Also take the opportunity to replace to usage of pfn_to_gfn by
page_to_pfn.
Signed-off-by: Julien Grall
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: David Vrabel
Cc: linux-fb
On Tue, 2015-07-28 at 15:59 +0100, Mark Rutland wrote:
> Hi Mark,
>
> As a heads-up, it looks like you missed a space when sending this; Arnd
> and Ard got merged into:
>
> "Arnd Bergmann --cc=Ard Biesheuvel" <
> ard.biesheu...@linaro.org>
>
> I've corrected that for this reply.
Oops. Thanks.
All the caller of xen_tmem_{get,put}_page have a struct page * in hand
and call pfn_to_gfn for the only benefits of these 2 functions.
Rather than passing the pfn in parameter, pass directly the page and use
directly page_to_gfn.
Signed-off-by: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Boris O
The swiotlb is required when programming a DMA address on ARM when a
device is not protected by an IOMMU.
In this case, the DMA address should always be equal to the machine address.
For DOM0 memory, Xen ensure it by have an identity mapping between the
guest address and host address. However, whe
On 07/28/2015 03:42 AM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.45 release.
> There are 124 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should b
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This brough some misimplementation of helpers on ARM and make the
developper confused the expected behavior.
For instance, with pfn_to_mfn, we expect to g
ARM guests are assimilated to HVM guest on ARM. The current
implementation is assuming a 1:1 mapping which is only true for DOM0 and
may not be at all in the future.
Furthermore, all the helpers but arbitrary_virt_to_machine are used in
x86 specific code (or only compiled for).
The helper arbitra
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.
Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.
Signed-off-by: Julien Grall
Cc: Greg Kroah-Hartman
Cc: Jiri
The privcmd code is mixing the usage of GFN and MFN within the same
functions which make the code difficult to understand when you only work
with auto-translated guests.
The privcmd driver is only dealing with GFN so replace all the mention
of MFN into GFN.
The ioctl structure used to map foreign
Hi Hans,
On Tue, 28 Jul 2015 16:49:58 +0200
Hans de Goede wrote:
> Hi,
>
> On 07/28/2015 04:29 PM, Michal Suchanek wrote:
> > Hello,
> >
> > the NAND chips on Cubietech boards are not known to Linux.
> >
> > I used Petros Angelatos' patch from sunxi experimental tree for one chip and
> > added
On 07/28/2015 03:49 PM, Eric B Munson wrote:
On Tue, 28 Jul 2015, Michal Hocko wrote:
[...]
The only
remaining question I have is should we have 2 new mlockall flags so that
the caller can explicitly set VM_LOCKONFAULT in the mm->def_flags vs
locking all current VMAs on fault. I ask because
Hi,
Hans de Goede schrieb am 28.07.2015 16:24:
> I've no problem with Timo submitting a cleaned up version of his
> patch and you taking that instead. I just wanted to point out that
> I do have a similar patch pending.
Ok, I will do that. It might take a couple of days, though, as I will be movi
On Tue, 2015-07-28 at 16:28 +0200, Heiko Stübner wrote:
> Hi,
>
> could you streamline the prefixes a bit perhaps? I.e. so far I've
> seen
>
> rk_spdif_dev
> spdif_runtime_suspend
> rockchip_snd_txctrl
> rockchip_spdif_hw_params
>
> I guess rockchip_spdif_* or rk_spdif_* for everything might ma
On Tue, 28 Jul 2015 17:10:13 +0200
Boris Brezillon wrote:
> Hi Hans,
>
> On Tue, 28 Jul 2015 16:49:58 +0200
> Hans de Goede wrote:
>
> > Hi,
> >
> > On 07/28/2015 04:29 PM, Michal Suchanek wrote:
> > > Hello,
> > >
> > > the NAND chips on Cubietech boards are not known to Linux.
> > >
> > > I
> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: 2015年7月28日 9:31
> To: Wang Shenwei-B38339
> Cc: ja...@lakedaemon.net; Huang Yongcai-B20788;
> linux-kernel@vger.kernel.org; t...@linutronix.de; shawn@linaro.org;
> linux-arm-ker...@lists.infradead.org
> Subjec
1 - 100 of 1106 matches
Mail list logo
