iommu_group_get_for_dev determines the iommu group for the PCI device and adds
the device to the group.
In the PAMU driver we were again adding the device to the same group without
checking
if the device already had an iommu group. This resulted in the following
warning.
sysfs: cannot create du
On Wed, 2014-09-03 at 22:36 -0400, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > >
> > > > So in the meantime the at
LS1 is arm cpu and it has qe ip block.
move qe code from platform directory to public directory.
QE is an IP block integrates several comunications peripheral
controllers. It can implement a variety of applications, such
as uart, usb and tdm and so on.
Signed-off-by: Zhao Qiang
---
Changes for v
On 03/09/14 13:02, Nishanth Aravamudan wrote:
On 27.08.2014 [17:34:00 +0800], Li Zhong wrote:
As Nish suggested, it makes more sense to init the numa node informatiion
for present cpus at boottime, which could also avoid WARN_ON(1) in
numa_setup_cpu().
Hit this on a Power8 LPAR. With the patch
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> >
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the cachin
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> >
> > > So in the meantime the attached patch should work, it just silently ignore
> > > the cachin
On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
>
> > So in the meantime the attached patch should work, it just silently ignore
> > the caching attribute request on non x86 instead of pretending that things
> > are
On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> So in the meantime the attached patch should work, it just silently ignore
> the caching attribute request on non x86 instead of pretending that things
> are setup as expected and then latter the radeon ou nouveau hw unsetting
> the snoop b
On Wed, 2014-09-03 at 21:55 -0400, Jerome Glisse wrote:
> So i think we need to get a platform flags and or set_pages_array_wc|uc
> needs to fail and this would fallback to cached mapping if the fallback
> code still works. So if your arch properly return and error for those
> cache changing functi
On Wed, Sep 03, 2014 at 09:55:53PM -0400, Jerome Glisse wrote:
> On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> > Hi folks !
> >
> > I've been tracking down some problems with the recent DRI on powerpc and
> > stumbled upon something that doesn't look right, and not nece
On Thu, Sep 04, 2014 at 10:12:27AM +1000, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> I've been tracking down some problems with the recent DRI on powerpc and
> stumbled upon something that doesn't look right, and not necessarily
> only for us.
>
> Now it's possible that I haven't fully unders
[ +cc linux-arch, Tony Luck,
On 07/12/2014 02:13 PM, Oleg Nesterov wrote:
> Hello,
>
> I am not sure I should ask here, but since Documentation/memory-barriers.txt
> mentions load/store tearing perhaps my question is not completely off-topic...
>
> I am fighting with mysterious RHEL bug, it can
Hi folks !
I've been tracking down some problems with the recent DRI on powerpc and
stumbled upon something that doesn't look right, and not necessarily
only for us.
Now it's possible that I haven't fully understood the code here and I
also don't know to what extent some of that behaviour is nece
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> Apologies for hijacking this thread but I need to extend this discussion
> somewhat regarding what a compiler might do with adjacent fields in a
> structure.
>
> The tty subsystem defines a large aggregate structure, struct tty_struct.
> I
On Mon, Aug 11, 2014 at 12:48:08PM +0530, Priyanka Jain wrote:
> T1040/T1042RDB is Freescale Reference Design Board.
> The board can support both T1040/T1042 QorIQ Power Architecture™ processor.
>
> T1040/T1042RDB board Overview
> ---
> - SERDES Connections, 8 lanes supporting:
On Fri, Jul 18, 2014 at 03:34:52PM +0530, Nikhil Badola wrote:
> Modifies get_dma_ops() implementation on ppc arch to check null condition
> for dev->archdata.dma_ops; returns common dma_direct_ops structure in
> case its NULL
>
> Signed-off-by: Nikhil Badola
> ---
> arch/powerpc/include/asm/dma
On Tue, 2014-08-05 at 16:37 -0500, Scott Wood wrote:
> On Tue, 2014-08-05 at 15:52 +0200, Martijn de Gouw wrote:
> > Add support for mapping and unmapping of inbound rapidio windows.
> >
> > Signed-off-by: Martijn de Gouw
>
> Could you elaborate in the changelog on what this fixes or makes
> pos
From: Sudeep Holla
This patch adds initial support for providing processor cache information
to userspace through sysfs interface. This is based on already existing
implementations(x86, ia64, s390 and powerpc) and hence the interface is
intended to be fully compatible.
The main purpose of this g
From: Sudeep Holla
This series adds a generic cacheinfo support similar to topology. The
implementation is based on x86 cacheinfo support. Currently x86, powerpc,
ia64 and s390 have their own implementations. While adding similar support
to ARM and ARM64, here is the attempt to make it generic qu
From: Sudeep Holla
This patch removes the redundant sysfs cacheinfo code by making use of
the newly introduced generic cacheinfo infrastructure.
Signed-off-by: Sudeep Holla
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/cacheinfo.c | 8
On 27.08.2014 [17:34:01 +0800], Li Zhong wrote:
> this patches changes some error handling logics in numa_setup_cpu(),
> when cpu node is not found, so:
>
> if the cpu is possible, but not present, -1 is kept in numa_cpu_lookup_table,
> so later, if the cpu is added, we could set correct numa info
On 09/02/2014 09:13 AM, Ulf Hansson wrote:
On 1 September 2014 17:32, Tomeu Vizoso wrote:
In preparation to change the public API to return a per-user clk structure,
remove any usage of this public API from the clock implementations.
The reason for having this in a separate commit from the one
Firmware-assisted dump (fadump) kernel code is not LE compliant. The
below patch tries to fix this issue. Tested this patch with upstream
kernel. Did some sanity testing for the LE fadump vmcore generated.
Below output shows crash tool successfully opening LE fadump vmcore.
# crash $vmlin
The IP is shared on PPC and ARM, this rename it to qoriq for better
represention, and this also add the CLK_OF_DECLARE support for being
initialized by of_clk_init() on ARM.
Signed-off-by: Jingchang Lu
---
changes in v3:
generate the patch with -M -C option
changes in v2:
rename the driver nam
Il 02/09/2014 18:13, Laurent Dufour ha scritto:
> fc95ca7284bc54953165cba76c3228bd2cdb9591 introduces a memset in
> kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
> allocates.
>
> However, the size argument passed to memset is computed from a signed value
> and its signed bit i
25 matches
Mail list logo
