On Fri, 2015-10-02 at 17:00 -0500, Segher Boessenkool wrote:
> On Sat, Oct 03, 2015 at 12:37:35AM +0300, Denis Kirjanov wrote:
> > >> -0: tlbie r4; \
> > >> +0: tlbie r4, 0; \
> > >
> > > This isn't correct. With POWER7 and later (wh
Hi Nishanth,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please
ignore]
config: sparc64-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~
Hi Nishanth,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please
ignore]
config: powerpc-defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bi
Hi Nishanth,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please
ignore]
config: arm64-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/b
On Fri, 2015-09-25 at 12:14 +1000, Michael Ellerman wrote:
> This struct is unused, which is now a build error with gcc 6:
>
> error: 'os_area_db_id_video_mode' defined but not used
>
> There doesn't seem to be any good reason to keep it around so remove it,
> it's in the history if anyone need
On 10/02/2015 03:00 PM, Segher Boessenkool wrote:
On Sat, Oct 03, 2015 at 12:37:35AM +0300, Denis Kirjanov wrote:
-0: tlbie r4; \
+0: tlbie r4, 0; \
This isn't correct. With POWER7 and later (which this compile
is, since it's on
On Sat, Oct 03, 2015 at 12:37:35AM +0300, Denis Kirjanov wrote:
> >> -0: tlbie r4; \
> >> +0: tlbie r4, 0; \
> >
> > This isn't correct. With POWER7 and later (which this compile
> > is, since it's on LE), the tlbie instruction takes
On 03.10.2015 [07:35:09 +1000], Benjamin Herrenschmidt wrote:
> On Fri, 2015-10-02 at 14:04 -0700, Nishanth Aravamudan wrote:
> > Right, I did start with your advice and tried that approach, but it
> > turned out I was wrong about the actual issue at the time. The problem
> > for NVMe isn't actuall
On Fri, 2015-10-02 at 14:04 -0700, Nishanth Aravamudan wrote:
> Right, I did start with your advice and tried that approach, but it
> turned out I was wrong about the actual issue at the time. The problem
> for NVMe isn't actually the starting address alignment (which it can
> handle not being alig
On 10/2/15, Peter Bergner wrote:
> On Fri, 2015-10-02 at 22:03 +0300, Denis Kirjanov wrote:
>> arch/powerpc/kernel/swsusp_asm64.S: Assembler messages:
>>> arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand
>>> scripts/Makefile.build:294: recipe for target
>>> 'arch/powerpc/kernel/swsus
On 03.10.2015 [06:51:06 +1000], Benjamin Herrenschmidt wrote:
> On Fri, 2015-10-02 at 13:09 -0700, Nishanth Aravamudan wrote:
>
> > 1) add a generic dma_get_page_shift implementation that just returns
> > PAGE_SHIFT
>
> So you chose to return the granularity of the iommu to the driver
> rather th
Ping?
Don't thing I ever saw anything happen with this patch. On another note
I notice in retrospect the patch subject isn't really stated in
imperative mood. Maybe it would be better as:
powerpc/pseries: make hibernation/migration honor topology update policy
-Tyrel
On 05/05/2015 10:53 AM, Tyr
On Fri, 2015-10-02 at 13:09 -0700, Nishanth Aravamudan wrote:
> 1) add a generic dma_get_page_shift implementation that just returns
> PAGE_SHIFT
So you chose to return the granularity of the iommu to the driver
rather than providing a way for the driver to request a specific
alignment for DMA ma
We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).
The NVMe device driver, though, assumes that the DMA alignment for the
PR
When DDW (Dynamic DMA Windows) are present for a device, we have stored
the TCE (Translation Control Entry) size in a special device tree
property. Check if we have enabled DDW for the device and return the TCE
size from that property if present. If the property isn't present,
fallback to looking t
The IOMMU page size is not always stored in struct iommu on Power.
Specifically if a device is configured for DDW (Dynamic DMA Windows aka.
64-bit direct DMA), the used TCE (Translation Control Entry) size is
stored in a special device property created at run-time by the DDW
configuration code. DDW
On Power, the kernel's page size can differ from the IOMMU's page size,
so we need to override the generic implementation, which always returns
the kernel's page size. Lookup the IOMMU's page size from struct
iommu_table, if available. Fallback to the kernel's page size,
otherwise.
Signed-off-by:
On Fri, 2015-10-02 at 22:03 +0300, Denis Kirjanov wrote:
> arch/powerpc/kernel/swsusp_asm64.S: Assembler messages:
>> arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand
>> scripts/Makefile.build:294: recipe for target
>> 'arch/powerpc/kernel/swsusp_asm64.o' failed
>> make[1]: *** [arch/
Drivers like NVMe need to be able to determine the page size used for
DMA transfers. Add a new API that defaults to return PAGE_SHIFT on all
architectures.
Signed-off-by: Nishanth Aravamudan
diff --git a/include/asm-generic/dma-mapping-common.h
b/include/asm-generic/dma-mapping-common.h
index b
We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).
The NVMe device driver, though, assumes that the DMA alignment for the
P
On 10/2/15, Laura Abbott wrote:
> Hi,
>
> We received a report (https://bugzilla.redhat.com/show_bug.cgi?id=1267395)
> of bad assembly
> when compiling on powerpc with little endian
>
> [labbott@labbott-redhat-machine linux_upstream]$ make ARCH=powerpc
> CROSS_COMPILE=powerpc64-linux-gnu-
>CHK
On Fri, Oct 02, 2015 at 10:39:47AM -0700, Nishanth Aravamudan wrote:
> Ok, I'm happy to do that instead -- what I struggled with is that I
> don't have enough knowledge of the various architectures to provide the
> right default implementation. It should be sufficient for the default to
> return PA
On 02.10.2015 [10:25:44 -0700], Christoph Hellwig wrote:
> Hi Nishanth,
>
> please expose this value through the generic DMA API instead of adding
> architecture specific hacks to drivers.
Ok, I'm happy to do that instead -- what I struggled with is that I
don't have enough knowledge of the vario
Hi Nishanth,
please expose this value through the generic DMA API instead of adding
architecture specific hacks to drivers.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).
The NVMe device driver, though, assumes that the DMA alignment for the
PR
We will leverage this macro in the NVMe driver, which needs to know the
configured IOMMU page shift to properly configure its device's page
size.
Signed-off-by: Nishanth Aravamudan
---
Given this is available, it seems reasonable to expose -- and it doesn't
really make sense to make the driver d
We received a bug report recently when DDW (64-bit direct DMA on Power)
is not enabled for NVMe devices. In that case, we fall back to 32-bit
DMA via the IOMMU, which is always done via 4K TCEs (Translation Control
Entries).
The NVMe device driver, though, assumes that the DMA alignment for the
PR
Hi James,
This series has been fairly well vetted. With cxlflash being a new driver the
majority
of these patches fix critical bugs. Is there anything else you're looking for
in order to
get this set pulled into 4.3-rc?
-matt
> On Oct 1, 2015, at 10:52 AM, Matthew R. Ochs
> wrote:
>
> This
Hi,
We received a report (https://bugzilla.redhat.com/show_bug.cgi?id=1267395) of
bad assembly
when compiling on powerpc with little endian
[labbott@labbott-redhat-machine linux_upstream]$ make ARCH=powerpc
CROSS_COMPILE=powerpc64-linux-gnu-
CHK include/config/kernel.release
CHK in
This avoid errors like
unsigned int usize = 1 << 30;
int size = 1 << 30;
unsigned long addr = 64UL << 30 ;
value = _ALIGN_DOWN(addr, usize); -> 0
value = _ALIGN_DOWN(addr, size); -> 0x10
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/boot/page
This moves the initialisation of the num_procs to before the SPA
allocation.
Signed-off-by: Christophe Lombard
---
drivers/misc/cxl/native.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/native.c b/drivers/misc/cxl/native.c
index b37f2e8..d2e75c8 100644
---
On 1.10.2015 17:55, Matthew R. Ochs wrote:
> Found during code inspection, that the following functions are not
> being used outside of the file where they are defined. Make them static.
>
> int cxlflash_send_cmd(struct afu *, struct afu_cmd *);
> void cxlflash_wait_resp(struct afu *, struct afu_cm
On 1.10.2015 17:55, Matthew R. Ochs wrote:
> Limbo is not an accurate representation of this state and is
> also not consistent with the terminology that other drivers
> use to represent this concept. Rename the state and and its
> associated waitq to 'reset'.
>
> Signed-off-by: Matthew R. Ochs
>
On 1.10.2015 17:55, Matthew R. Ochs wrote:
> During an EEH freeze event, certain CXL services should not be
> called until after the hardware reset has taken place. Doing so
> can result in unnecessary failures and possibly cause other ill
> effects by triggering hardware accesses. This translates
On 1.10.2015 17:55, Matthew R. Ochs wrote:
> The context encode mask covers more than 32-bits, making it
> a long integer. This should be noted by appending the ULL
> width suffix to the mask.
>
> Signed-off-by: Matthew R. Ochs
> Signed-off-by: Manoj N. Kumar
> Reviewed-by: Brian King
> Reviewed
On 1.10.2015 17:55, Matthew R. Ochs wrote:
> Using sizeof(bool) is considered poor form for various reasons and
> sparse warns us of that. Correct by changing type from bool to u8.
>
> Signed-off-by: Matthew R. Ochs
> Signed-off-by: Manoj N. Kumar
> Reviewed-by: Brian King
> Reviewed-by: Daniel
On 1.10.2015 17:55, Matthew R. Ochs wrote:
> If the same virtual LUN is accessed over multiple cards, only accesses
> made over the first card will be valid. Accesses made over the second
> card will go to the wrong LUN causing data corruption.
>
> This is because the global LUN's mode word was bei
On 1.10.2015 17:55, Matthew R. Ochs wrote:
> When a LUN is removed, the sdev that is associated with the LUN
> remains intact until its reference count drops to 0. In order
> to prevent an sdev from being removed while a context is still
> associated with it, obtain an additional reference per-cont
On 1.10.2015 17:54, Matthew R. Ochs wrote:
> From: Manoj Kumar
>
> The timeout value for read capacity is too small. Certain devices
> may take longer to respond and thus the command may prematurely
> timeout. Additionally the literal used for the timeout is stale.
>
> Update the timeout to 30 sec
On 1.10.2015 17:54, Matthew R. Ochs wrote:
> From: Manoj Kumar
>
> Magic numbers are not meaningful and can create confusion. As a
> remedy, replace them with descriptive literals.
>
> Replace 512 with literal MAX_SECTOR_UNIT.
> Replace 5 with literal CMD_RETRIES.
>
> Signed-off-by: Matthew R. Och
On 1.10.2015 17:54, Matthew R. Ochs wrote:
> From: Manoj Kumar
>
> If two concurrent MANAGE_LUN ioctls are issued with the same
> WWID parameter, it would result in an incorrect value of port_sel.
>
> This is because port_sel is modified without any locks being
> held. If the first caller stalls a
On 08/19/2015 12:01 PM, Wei Yang wrote:
In original design, it tries to group VFs to enable more number of VFs in the
system, when VF BAR is bigger than 64MB. This design has a flaw in which one
error on a VF will interfere other VFs in the same group.
This patch series change this design by usi
On 08/19/2015 12:01 PM, Wei Yang wrote:
When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
sparse.
This patch restructures the patch to allocate sparse PE# for VFs when M64
This patch restructures the code ;)
BAR is set to Single PE mode. Also it rename the offset to pe_
On 08/19/2015 12:01 PM, Wei Yang wrote:
Each VF could have 6 BARs at most. When the total BAR size exceeds the
gate, after expanding it will also exhaust the M64 Window.
This patch limits the boundary by checking the total VF BAR size instead of
the individual BAR.
The gate is the biggest segm
On 08/19/2015 12:01 PM, Wei Yang wrote:
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BARs in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
A
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, October 02, 2015 4:01 AM
>
> On Thu, Sep 24, 2015 at 06:00:12PM +0300, Madalin Bucur wrote:
> > Introduce managed counterparts for alloc_percpu() and free_percpu().
> > Add devm_alloc_percpu() and devm_free_percpu() into the ma
On 08/19/2015 12:01 PM, Wei Yang wrote:
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is extended with number of
roundup_pow_of_two(total_vfs) or number of max PE number (256), the total
size could be calculated by (vfs_expanded * VF_
On 08/19/2015 12:01 PM, Wei Yang wrote:
On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
a SRIOV device's IOV BAR is not 64bit-prefetchable, this is not assigned
from 64bit prefetchable window, which means M64 BAR can't work on it.
Please change the commit log to expl
On 9/17/15, Catalin Marinas wrote:
> On Wed, Sep 16, 2015 at 10:26:14PM +0300, Denis Kirjanov wrote:
>> During the MSI bitmap test on boot kmemleak spews the following trace:
>>
>> unreferenced object 0xc0016e86c900 (size 64):
>> comm "swapper/0", pid 1, jiffies 4294893173 (age 518.024s)
>
On 9/8/15, Michael Ellerman wrote:
> On Mon, 2015-09-07 at 13:39 +0300, Denis Kirjanov wrote:
>> On 9/7/15, Michael Ellerman wrote:
>> > On Mon, 2015-09-07 at 10:30 +0300, Denis Kirjanov wrote:
>> >> On 6/19/15, Benjamin Herrenschmidt wrote:
>> >> > On Thu, 2015-06-18 at 17:34 +0300, Denis Kirja
On Fri, 2015-10-02 at 17:47 +1000, Michael Ellerman wrote:
> On Fri, 2015-25-09 at 04:01:40 UTC, Michael Neuling wrote:
> > powerpc has a link register (lr) used for calling functions. We "bl
> > " to call a function, and "blr" to return back to the call
> > site.
>
>
>
> > For the benchmark in
On Thu, 2015-13-08 at 07:11:18 UTC, Michael Ellerman wrote:
> For no reason other than it looks ugly.
>
> Signed-off-by: Michael Ellerman
Applied to powerpc next.
https://git.kernel.org/powerpc/c/26cd835ef8bdc9ca6db03374
cheers
___
Linuxppc-dev maili
On Fri, 2015-07-08 at 03:05:42 UTC, Michael Ellerman wrote:
> Andy Lutomirski says:
>
> Some dynamic loaders may be slightly faster if a GNU hash is
> available.
>
> This is unlikely to have any measurable effect on the time it takes
> to resolve vdso symbols (since there are so few of th
On Sun, 2015-06-09 at 23:58:00 UTC, Boqun Feng wrote:
> Currently, little endian is only supported on powernv and pseries,
> however, Kconfigs still allow us to include other platforms in a LE
> kernel, this may result in space wasting or even build error if some
> BE-only platforms always assume t
On Thu, 2015-13-08 at 07:07:54 UTC, Michael Ellerman wrote:
> From: Anshuman Khandual
>
> This patch defines macros for the three bolted SLB indexes we use.
> Switch the functions that take the indexes as an argument to use the
> enum.
>
> Signed-off-by: Anshuman Khandual
> Signed-off-by: Micha
On Thu, 2015-03-09 at 07:50:56 UTC, "Aneesh Kumar K.V" wrote:
> This add helper virt_to_pfn and remove the opencoded usage of the
> same.
>
> Signed-off-by: Aneesh Kumar K.V
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/65d3223a853ac8598694064c
cheers
__
On Mon, 2015-14-09 at 21:36:35 UTC, Geoff Levand wrote:
> Refresh and remove obsolete CONFIG_EXT3_FS.
>
> Signed-off-by: Geoff Levand
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/336382c78b926af7f3b22f73
cheers
___
Linuxppc-dev m
On Mon, 2015-14-09 at 19:35:04 UTC, Colin King wrote:
> On the unlikely event that drv is null, the current code will
> perform a null pointer dereference with it when printing a dev_dbg
> message. Instead, the BUG_ON check on drv should be performed
> before we emit the dev_dbg message.
>
> Sign
On Wed, 2015-23-09 at 05:40:35 UTC, Michael Ellerman wrote:
> Based directly on ppc64_defconfig using merge_config.
>
> Signed-off-by: Michael Ellerman
Applied to powerpc next.
https://git.kernel.org/powerpc/c/2adc48a691866fbb3134dd3a
cheers
___
Linu
On Fri, 2015-25-09 at 04:01:40 UTC, Michael Neuling wrote:
> powerpc has a link register (lr) used for calling functions. We "bl
> " to call a function, and "blr" to return back to the call site.
> For the benchmark in tools/testing/selftests/powerpc/benchmarks/gettimeofday.c
> POWER8:
> 6
On Mon, 2015-14-09 at 19:35:04 UTC, Rudhresh Kumar J wrote:
> Fixed a coding style issue.
>
> Signed-off-by: Rudhresh Kumar J
> Signed-off-by: Geoff Levand
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/12a509336701132f521c8fc2
cheers
___
On Wed, 2015-23-09 at 05:40:34 UTC, Michael Ellerman wrote:
> Arch Makefiles can set KBUILD_DEFCONFIG to tell kbuild the name of the
> defconfig that should be built by default.
>
> However currently there is an assumption that KBUILD_DEFCONFIG points to
> a file at arch/$(SRCARCH)/configs/$(KBUIL
On Fri, 2015-25-09 at 04:01:39 UTC, Michael Neuling wrote:
> This adds a benchmark directory to the powerpc selftests and adds a
> gettimeofday() benchmark to it.
>
> Suggested-by: Michael Ellerman
> Signed-off-by: Michael Neuling
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc
63 matches
Mail list logo
