Re: [PATCH] powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash
Michael Ellerman m...@ellerman.id.au writes:
The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
PAGE_SIZE.
However when built with a 4K PAGE_SIZE there is an additional config
option which can be enabled, PPC_HAS_HASH_64K, which means the kernel
also knows how to hash a 64K page even though the base PAGE_SIZE is 4K.
This is used in one obscure configuration, to support 64K pages for SPU
local store on the Cell processor when the rest of the kernel is using
4K pages.
In this configuration, pte_pagesize_index() is defined to just pass
through its arguments to get_slice_psize(). However pte_pagesize_index()
is called for both user and kernel addresses, whereas get_slice_psize()
only knows how to handle user addresses.
This has been broken forever, however until recently it happened to
work. That was because in get_slice_psize() the large kernel address
would cause the right shift of the slize mask to return zero.
However in commit 7aa0727f3302 powerpc/mm: Increase the slice range to
64TB, the get_slice_psize() code was changed so that instead of a right
shift we do an array lookup based on the address. When passed a kernel
address this means we index way off the end of the slice array and
return random junk.
That is only fatal if we happen to hit something non-zero, but when we
do return a non-zero value we confuse the MMU code and eventually cause
a check stop.
This fix is ugly, but simple. When we're called for a kernel address we
return 4K, which is always correct in this configuration, otherwise we
use the slice mask.
Fixes: 7aa0727f3302 (powerpc/mm: Increase the slice range to 64TB)
Reported-by: Cyril Bur cyril...@gmail.com
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/include/asm/pgtable-ppc64.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h
b/arch/powerpc/include/asm/pgtable-ppc64.h
index 3bb7488bd24b..330ae1d81662 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -135,7 +135,15 @@
#define pte_iterate_hashed_end() } while(0)
#ifdef CONFIG_PPC_HAS_HASH_64K
-#define pte_pagesize_index(mm, addr, pte)get_slice_psize(mm, addr)
+#define pte_pagesize_index(mm, addr, pte)\
+ ({ \
+ unsigned int psize; \
+ if (is_kernel_addr(addr)) \
+ psize = MMU_PAGE_4K;\
+ else\
+ psize = get_slice_psize(mm, addr); \
+ psize; \
+ })
#else
#define pte_pagesize_index(mm, addr, pte)MMU_PAGE_4K
#endif
That is confusing, because we enable PPC_HASH_HAS_64K for 64K page size
too. why not
psize = mmu_virtual_psize;
But that leave another question. What if kernel address used 16MB
mapping ? Or are we going to get a call for pte_pagesize_index, only for
vmalloc area of the kernel ? In any case, this need more comment
explaining the caller and possibly DEBUG_VM WARN_ON() to catch wrong
users ?
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 11/20] tty/hvc: xen: Use xen page definition
On 09/07/15 21:42, Julien Grall wrote: The console ring is always based on the page granularity of Xen. [...] --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -392,7 +392,7 @@ static int xencons_connect_backend(struct xenbus_device *dev, if (xen_pv_domain()) mfn = virt_to_mfn(info-intf); else - mfn = __pa(info-intf) PAGE_SHIFT; + mfn = __pa(info-intf) XEN_PAGE_SHIFT; Change this to gfn = xen_page_to_gfn(virt_to_page(info-intf)); and drop the if()? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: add sleep and deep sleep support
In sleep PM mode, the clocks of e500 core and unused IP blocks is
turned off. IP blocks which are allowed to wake up the processor
are still running.
Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode
in addtion to the sleep PM mode.
While in deep sleep PM mode, additionally, the power supply is
removed from e500 core and most IP blocks. Only the blocks needed
to wake up the chip out of deep sleep are ON.
This patch supports 32-bit and 36-bit address space.
The sleep mode is equal to the Standby state in Linux. The deep sleep
mode is equal to the Suspend-to-RAM state of Linux Power Management.
Command to enter sleep mode.
echo standby /sys/power/state
Command to enter deep sleep mode.
echo mem /sys/power/state
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
---
arch/powerpc/include/asm/cacheflush.h | 5 +
arch/powerpc/platforms/85xx/Makefile| 3 +
arch/powerpc/platforms/85xx/pmc_deepsleep.S | 645
arch/powerpc/sysdev/fsl_pmc.c | 146 ++-
arch/powerpc/sysdev/fsl_soc.h | 5 +
5 files changed, 785 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/platforms/85xx/pmc_deepsleep.S
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 30b35ff..9ec4c31 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -31,6 +31,11 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
extern void __flush_disable_L1(void);
+#ifdef CONFIG_FSL_BOOKE
+extern void flush_dcache_L1(void);
+#else
+#define flush_dcache_L1() do { } while (0)
+#endif
extern void flush_icache_range(unsigned long, unsigned long);
extern void flush_icache_user_range(struct vm_area_struct *vma,
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index 1fe7fb9..d187253 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -2,6 +2,9 @@
# Makefile for the PowerPC 85xx linux kernel.
#
obj-$(CONFIG_SMP) += smp.o
+ifneq ($(CONFIG_PPC_E500MC),y)
+obj-$(CONFIG_SUSPEND) += pmc_deepsleep.o
+endif
obj-y += common.o
diff --git a/arch/powerpc/platforms/85xx/pmc_deepsleep.S
b/arch/powerpc/platforms/85xx/pmc_deepsleep.S
new file mode 100644
index 000..57fd4f4
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/pmc_deepsleep.S
@@ -0,0 +1,645 @@
+/*
+ * Enter and leave deep sleep/sleep state on MPC85xx
+ *
+ * Author: Scott Wood scottw...@freescale.com
+ *
+ * Copyright 2006-2015 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include asm/page.h
+#include asm/ppc_asm.h
+#include asm/reg.h
+#include asm/asm-offsets.h
+
+#define SS_TB 0x00
+#define SS_HID 0x08 /* 2 HIDs */
+#define SS_IAC 0x10 /* 2 IACs */
+#define SS_DAC 0x18 /* 2 DACs */
+#define SS_DBCR0x20 /* 3 DBCRs */
+#define SS_PID 0x2c /* 3 PIDs */
+#define SS_SPRG0x38 /* 8 SPRGs */
+#define SS_IVOR0x58 /* 20 interrupt vectors */
+#define SS_TCR 0xa8
+#define SS_BUCSR 0xac
+#define SS_L1CSR 0xb0 /* 2 L1CSRs */
+#define SS_MSR 0xb8
+#define SS_USPRG 0xbc
+#define SS_GPREG 0xc0 /* r12-r31 */
+#define SS_LR 0x110
+#define SS_CR 0x114
+#define SS_SP 0x118
+#define SS_CURRENT 0x11c
+#define SS_IVPR0x120
+#define SS_BPTR0x124
+
+
+#define STATE_SAVE_SIZE 0x128
+
+ .section .data
+ .align 5
+mpc85xx_sleep_save_area:
+ .space STATE_SAVE_SIZE
+ccsrbase_low:
+ .long 0
+ccsrbase_high:
+ .long 0
+powmgtreq:
+ .long 0
+
+ .section .text
+
+ /* r3 = virtual address of L2 controller, WIMG = 01xx */
+flush_disable_L2:
+ /* It's a write-through cache, so only invalidation is needed. */
+ mbar
+ isync
+ lwz r4, 0(r3)
+ li r5, 1
+ rlwimi r4, r5, 30, 0xc000
+ stw r4, 0(r3)
+
+ /* Wait for the invalidate to finish */
+1: lwz r4, 0(r3)
+ andis. r4, r4, 0x4000
+ bne 1b
+ mbar
+
+ blr
+
+ /* r3 = virtual address of L2 controller, WIMG = 01xx */
+invalidate_enable_L2:
+ mbar
+ isync
+ lwz r4, 0(r3)
+ li r5, 3
+ rlwimi r4, r5, 30, 0xc000
+ stw r4, 0(r3)
+
+ /* Wait for the invalidate to finish */
+1: lwz r4, 0(r3)
+ andis. r4, r4, 0x4000
+ bne 1b
+ mbar
+
+ blr
+
+ /*
+* r3 = high word of physical
Re: powerpc/corenet: enable eSDHC
On Mon, 2015-07-20 at 01:43 -0500, Lu Yangbo-B47093 wrote: OK, thanks. Assuming no similar issues when testing, I'll apply this patch the next time I do a batch of patch application. Any thoughts regarding better error handling? -Scott Do you mean SD test? I just mean that I will verify that enabling the option doesn't make things worse. Actually SD patches needing to sent to upstream are tested on Li Yang's Linux tree. I thought you said the patch was already merged. And the JIRA ticket is QORIQLU-19. Don't reference internal tickets on upstream lists. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1010rdb:update dts for pcie interrupt-map
On Mon, 2015-07-20 at 15:32 +0800, Zhao Qiang wrote: From: Zhao Qiang b45...@freescale.com p1010rdb-pb use the irq[4:5] for inta and intb to pcie, it is active-high, so set it. What about revisions of p1010rdb other than pb? Signed-off-by: Zhao Qiang b45...@freescale.com Change-Id: I29db41b4a8b5a67c18151099884edda6de4d9d1a Reviewed-on: http://git.am.freescale.net:8181/9915 Tested-by: Review Code-CDREVIEW cdrev...@freescale.com Reviewed-by: Xiaobo Xie x@freescale.com Reviewed-by: Jose Rivera german.riv...@freescale.com Get rid of the gerrit crud. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
On 07/24/2015 07:39 AM, Eric B Munson wrote: On Thu, 23 Jul 2015, Ralf Baechle wrote: On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: You haven't wired it up properly on powerpc, but I haven't mentioned it because I'd rather we did it. cheers It looks like I will be spinning a V5, so I will drop all but the x86 system calls additions in that version. The MIPS bits are looking good however, so Acked-by: Ralf Baechle r...@linux-mips.org With my ack, will you keep them or maybe carry them as a separate patch? I will keep the MIPS additions as a separate patch in the series, though I have dropped two of the new syscalls after some discussion. So I will not include your ack on the new patch. Eric Hi Eric, next-20150724 still has some failures due to this patch set. Are those being looked at (I know parisc builds fail, but there may be others) ? Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
On Fri, 24 Jul 2015, Guenter Roeck wrote: On 07/24/2015 07:39 AM, Eric B Munson wrote: On Thu, 23 Jul 2015, Ralf Baechle wrote: On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: You haven't wired it up properly on powerpc, but I haven't mentioned it because I'd rather we did it. cheers It looks like I will be spinning a V5, so I will drop all but the x86 system calls additions in that version. The MIPS bits are looking good however, so Acked-by: Ralf Baechle r...@linux-mips.org With my ack, will you keep them or maybe carry them as a separate patch? I will keep the MIPS additions as a separate patch in the series, though I have dropped two of the new syscalls after some discussion. So I will not include your ack on the new patch. Eric Hi Eric, next-20150724 still has some failures due to this patch set. Are those being looked at (I know parisc builds fail, but there may be others) ? Thanks, Guenter Guenter, Yes, the next respin will drop all new arch syscall entries except x86[_64] and MIPS. I will leave it up to arch maintainers to add the entries. Eric signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mm: rename and document alloc_pages_exact_node
On 07/23/2015 10:27 PM, David Rientjes wrote: On Thu, 23 Jul 2015, Christoph Lameter wrote: The only possible downside would be existing users of alloc_pages_node() that are calling it with an offline node. Since it's a VM_BUG_ON() that would catch that, I think it should be changed to a VM_WARN_ON() and eventually fixed up because it's nonsensical. VM_BUG_ON() here should be avoided. The offline node thing could be addresses by using numa_mem_id()? I was concerned about any callers that were passing an offline node, not NUMA_NO_NODE, today. One of the alloc-node functions has a VM_BUG_ON() for it, the other silently calls node_zonelist() on it. I suppose the final alloc_pages_node() implementation could be if (nid == NUMA_NO_NODE || VM_WARN_ON(!node_online(nid))) nid = numa_mem_id(); VM_BUG_ON(nid 0 || nid = MAX_NUMNODES); return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask)); though. I've posted v2 based on David's and Christoph's suggestions (thanks) but to avoid spamming everyone until we agree on the final interface, it's marked as RFC and excludes the arch people from CC: http://marc.info/?l=linux-kernelm=143774920902608w=2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB board support
On Wed, 2015-07-22 at 05:49 -0500, Jain Priyanka-B32167 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, July 17, 2015 10:37 PM
To: Jain Priyanka-B32167
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB
board support
On Fri, 2015-07-17 at 01:17 -0500, Jain Priyanka-B32167 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Friday, July 17, 2015 1:06 AM
To: Jain Priyanka-B32167
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add
T1040D4RDB/T1042D4RDB board support
+i2c@118100{
+ mux@77{
+ compatible = nxp,pca9546;
+ reg = 0x77;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+ };
A mux with no nodes under it (and yet it has #address-cells/#size-
cells)?
What is it multiplexing?
[Priyanka]: PCA9546 is i2c mux device , to which other i2c devices
(up-to 8
) can be further connected on output channels On T104xD4RDB,
channel 0, 1, 3 line are connected to PEX device, Channel 2 to
hdmi interface (initialization is done in u-boot only), other
channels are
grounded.
So, as such Linux is not using the second level I2C devices
connected on this MUX device. So, I have not shown next level
hierarchy.
Should I replace 'mux' with some other name? . Please suggest.
The device tree describes the hardware, not just what Linux uses...
but what I don't understand is why you describe the mux at all if
you're not going to describe what goes underneath it.
[Jain Priyanka-B32167] : Is below looks OK?
i2c@118100{
+ i2c@77{
+ compatible = nxp,pca9546;
+ reg = 0x77;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+ };
Where in my above comment did it appear that I was complaining about the
node name?
[Jain Priyanka-B32167]
From what I understand:
PCA9546 is a mux device and it would be good if we were able to present the
I2C devices on output lines as subnodes like in case of B4qds board and
then 'mux' name would have make more sense.
The name mux makes more sense regardless.
But in case of T1040D4RDB board, output i2c lines are going to PEX slots,
PCI connector. I am not aware of how to represents them as sub-nodes in dts.
OK, so you're saying the i2c devices are pluggable (and I'm assuming by PEX
slots you just mean that the physical slot is repurposed, not that the PCI
express protocol is involved)? Making a non-runtime-enumerable bus be
pluggable seems like a bad idea, but if that's really what has been done,
there needs to be a device tree that represents the entire system, not just
the motherboard. This could be done either via a dts file that /include/s
the motherboard dts, or via firmware dtb edits. The dts for the motherboard
should include the mux node with a comment explaining what the situation is.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V5 0/7] Allow user to request memory to be locked on page fault
mlock() allows a user to control page out of program memory, but this comes at the cost of faulting in the entire mapping when it is allocated. For large mappings where the entire area is not necessary this is not ideal. Instead of forcing all locked pages to be present when they are allocated, this set creates a middle ground. Pages are marked to be placed on the unevictable LRU (locked) when they are first used, but they are not faulted in by the mlock call. This series introduces a new mlock() system call that takes a flags argument along with the start address and size. This flags argument gives the caller the ability to request memory be locked in the traditional way, or to be locked after the page is faulted in. A new MCL flag is added to mirror the lock on fault behavior from mlock() in mlockall(). Finally, a flag for mmap() is added that allows a user to specify that the covered are should not be paged out, but only after the memory has been used the first time. There are two main use cases that this set covers. The first is the security focussed mlock case. A buffer is needed that cannot be written to swap. The maximum size is known, but on average the memory used is significantly less than this maximum. With lock on fault, the buffer is guaranteed to never be paged out without consuming the maximum size every time such a buffer is created. The second use case is focussed on performance. Portions of a large file are needed and we want to keep the used portions in memory once accessed. This is the case for large graphical models where the path through the graph is not known until run time. The entire graph is unlikely to be used in a given invocation, but once a node has been used it needs to stay resident for further processing. Given these constraints we have a number of options. We can potentially waste a large amount of memory by mlocking the entire region (this can also cause a significant stall at startup as the entire file is read in). We can mlock every page as we access them without tracking if the page is already resident but this introduces large overhead for each access. The third option is mapping the entire region with PROT_NONE and using a signal handler for SIGSEGV to mprotect(PROT_READ) and mlock() the needed page. Doing this page at a time adds a significant performance penalty. Batching can be used to mitigate this overhead, but in order to safely avoid trying to mprotect pages outside of the mapping, the boundaries of each mapping to be used in this way must be tracked and available to the signal handler. This is precisely what the mm system in the kernel should already be doing. For mlock(MLOCK_ONFAULT) and mmap(MAP_LOCKONFAULT) the user is charged against RLIMIT_MEMLOCK as if mlock(MLOCK_LOCKED) or mmap(MAP_LOCKED) was used, so when the VMA is created not when the pages are faulted in. For mlockall(MCL_ONFAULT) the user is charged as if MCL_FUTURE was used. This decision was made to keep the accounting checks out of the page fault path. To illustrate the benefit of this set I wrote a test program that mmaps a 5 GB file filled with random data and then makes 15,000,000 accesses to random addresses in that mapping. The test program was run 20 times for each setup. Results are reported for two program portions, setup and execution. The setup phase is calling mmap and optionally mlock on the entire region. For most experiments this is trivial, but it highlights the cost of faulting in the entire region. Results are averages across the 20 runs in milliseconds. mmap with mlock(MLOCK_LOCKED) on entire range: Setup avg: 8228.666 Processing avg: 8274.257 mmap with mlock(MLOCK_LOCKED) before each access: Setup avg: 0.113 Processing avg: 90993.552 mmap with PROT_NONE and signal handler and batch size of 1 page: With the default value in max_map_count, this gets ENOMEM as I attempt to change the permissions, after upping the sysctl significantly I get: Setup avg: 0.058 Processing avg: 69488.073 mmap with PROT_NONE and signal handler and batch size of 8 pages: Setup avg: 0.068 Processing avg: 38204.116 mmap with PROT_NONE and signal handler and batch size of 16 pages: Setup avg: 0.044 Processing avg: 29671.180 mmap with mlock(MLOCK_ONFAULT) on entire range: Setup avg: 0.189 Processing avg: 17904.899 The signal handler in the batch cases faulted in memory in two steps to avoid having to know the start and end of the faulting mapping. The first step covers the page that caused the fault as we know that it will be possible to lock. The second step speculatively tries to mlock and mprotect the batch size - 1 pages that follow. There may be a clever way to avoid this without having the program track each mapping to be covered by this handeler in a globally accessible structure, but I could not find it. It should be noted that with a large enough batch size this two step fault handler can still cause the program to crash if it
[PATCH V5 5/7] mm: mmap: Add mmap flag to request VM_LOCKONFAULT
The cost of faulting in all memory to be locked can be very high when working with large mappings. If only portions of the mapping will be used this can incur a high penalty for locking. Now that we have the new VMA flag for the locked but not present state, expose it as an mmap option like MAP_LOCKED - VM_LOCKED. Signed-off-by: Eric B Munson emun...@akamai.com Cc: Michal Hocko mho...@suse.cz Cc: Vlastimil Babka vba...@suse.cz Cc: Paul Gortmaker paul.gortma...@windriver.com Cc: Chris Metcalf cmetc...@ezchip.com Cc: Guenter Roeck li...@roeck-us.net Cc: linux-al...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-m...@linux-mips.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: sparcli...@vger.kernel.org Cc: linux-xte...@linux-xtensa.org Cc: linux...@kvack.org Cc: linux-a...@vger.kernel.org Cc: linux-...@vger.kernel.org --- arch/alpha/include/uapi/asm/mman.h | 1 + arch/mips/include/uapi/asm/mman.h| 1 + arch/parisc/include/uapi/asm/mman.h | 1 + arch/powerpc/include/uapi/asm/mman.h | 1 + arch/sparc/include/uapi/asm/mman.h | 1 + arch/tile/include/uapi/asm/mman.h| 1 + arch/xtensa/include/uapi/asm/mman.h | 1 + include/linux/mman.h | 3 ++- include/uapi/asm-generic/mman.h | 1 + kernel/events/core.c | 3 ++- mm/mmap.c| 8 ++-- 11 files changed, 18 insertions(+), 4 deletions(-) diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h index 77ae8db..3f80ca4 100644 --- a/arch/alpha/include/uapi/asm/mman.h +++ b/arch/alpha/include/uapi/asm/mman.h @@ -30,6 +30,7 @@ #define MAP_NONBLOCK 0x4 /* do not block on IO */ #define MAP_STACK 0x8 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x10/* create a huge page mapping */ +#define MAP_LOCKONFAULT0x20/* Lock pages after they are faulted in, do not prefault */ #define MS_ASYNC 1 /* sync memory asynchronously */ #define MS_SYNC2 /* synchronous memory sync */ diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h index 71ed81d..905c1ea 100644 --- a/arch/mips/include/uapi/asm/mman.h +++ b/arch/mips/include/uapi/asm/mman.h @@ -48,6 +48,7 @@ #define MAP_NONBLOCK 0x2 /* do not block on IO */ #define MAP_STACK 0x4 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x8 /* create a huge page mapping */ +#define MAP_LOCKONFAULT0x10/* Lock pages after they are faulted in, do not prefault */ /* * Flags for msync diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h index c0871ce..c4695f6 100644 --- a/arch/parisc/include/uapi/asm/mman.h +++ b/arch/parisc/include/uapi/asm/mman.h @@ -24,6 +24,7 @@ #define MAP_NONBLOCK 0x2 /* do not block on IO */ #define MAP_STACK 0x4 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x8 /* create a huge page mapping */ +#define MAP_LOCKONFAULT0x10/* Lock pages after they are faulted in, do not prefault */ #define MS_SYNC1 /* synchronous memory sync */ #define MS_ASYNC 2 /* sync memory asynchronously */ diff --git a/arch/powerpc/include/uapi/asm/mman.h b/arch/powerpc/include/uapi/asm/mman.h index f93f7eb..40a3fda 100644 --- a/arch/powerpc/include/uapi/asm/mman.h +++ b/arch/powerpc/include/uapi/asm/mman.h @@ -31,5 +31,6 @@ #define MAP_NONBLOCK 0x1 /* do not block on IO */ #define MAP_STACK 0x2 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x4 /* create a huge page mapping */ +#define MAP_LOCKONFAULT0x8 /* Lock pages after they are faulted in, do not prefault */ #endif /* _UAPI_ASM_POWERPC_MMAN_H */ diff --git a/arch/sparc/include/uapi/asm/mman.h b/arch/sparc/include/uapi/asm/mman.h index 8cd2ebc..f66efa6 100644 --- a/arch/sparc/include/uapi/asm/mman.h +++ b/arch/sparc/include/uapi/asm/mman.h @@ -26,6 +26,7 @@ #define MAP_NONBLOCK 0x1 /* do not block on IO */ #define MAP_STACK 0x2 /* give out an address that is best suited for process/thread stacks */ #define MAP_HUGETLB0x4 /* create a huge page mapping */ +#define MAP_LOCKONFAULT0x8 /* Lock pages after they are faulted in, do not prefault */ #endif /* _UAPI__SPARC_MMAN_H__ */ diff --git a/arch/tile/include/uapi/asm/mman.h b/arch/tile/include/uapi/asm/mman.h index acdd013..800e5c3 100644 --- a/arch/tile/include/uapi/asm/mman.h +++ b/arch/tile/include/uapi/asm/mman.h @@ -29,6 +29,7 @@ #define MAP_DENYWRITE 0x0800 /* ETXTBSY */ #define
[PATCH V5 4/7] mm: mlock: Add mlock flags to enable VM_LOCKONFAULT usage
The previous patch introduced a flag that specified pages in a VMA should be placed on the unevictable LRU, but they should not be made present when the area is created. This patch adds the ability to set this state via the new mlock system calls. We add MLOCK_ONFAULT for mlock2 and MCL_ONFAULT for mlockall. MLOCK_ONFAULT will set the VM_LOCKONFAULT flag as well as the VM_LOCKED flag for the target region. MCL_CURRENT and MCL_ONFAULT are used to lock current mappings. With MCL_CURRENT all pages are made present and with MCL_ONFAULT they are locked when faulted in. When specified with MCL_FUTURE all new mappings will be marked with VM_LOCKONFAULT. Currently, mlockall() clears all VMA lock flags and then sets the requested flags. For instance, if a process has MCL_FUTURE and MCL_CURRENT set, but they want to clear MCL_FUTURE this would be accomplished by calling mlockall(MCL_CURRENT). This still holds with the introduction of MCL_ONFAULT. Each call to mlockall() resets all VMA flags to the values specified in the current call. The new mlock2 system call behaves in the same way. If a region is locked with MLOCK_ONFAULT and a user wants to force it to be populated now, a second call to mlock2(MLOCK_LOCKED) will accomplish this. munlock() will unconditionally clear both vma flags. munlockall() unconditionally clears for VMA flags on all VMAs and in the mm-def_flags field. Signed-off-by: Eric B Munson emun...@akamai.com Cc: Michal Hocko mho...@suse.cz Cc: Vlastimil Babka vba...@suse.cz Cc: Jonathan Corbet cor...@lwn.net Cc: Kirill A. Shutemov kir...@shutemov.name Cc: linux-al...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-m...@linux-mips.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: sparcli...@vger.kernel.org Cc: linux-xte...@linux-xtensa.org Cc: linux-a...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux...@kvack.org --- Changes from V4: * Split addition of VMA flag Changes from V3: * Do extensive search for VM_LOCKED and ensure that VM_LOCKONFAULT is also handled where appropriate arch/alpha/include/uapi/asm/mman.h | 2 ++ arch/mips/include/uapi/asm/mman.h| 2 ++ arch/parisc/include/uapi/asm/mman.h | 2 ++ arch/powerpc/include/uapi/asm/mman.h | 2 ++ arch/sparc/include/uapi/asm/mman.h | 2 ++ arch/tile/include/uapi/asm/mman.h| 3 +++ arch/xtensa/include/uapi/asm/mman.h | 2 ++ include/uapi/asm-generic/mman.h | 2 ++ mm/mlock.c | 41 9 files changed, 45 insertions(+), 13 deletions(-) diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h index ec72436..77ae8db 100644 --- a/arch/alpha/include/uapi/asm/mman.h +++ b/arch/alpha/include/uapi/asm/mman.h @@ -37,8 +37,10 @@ #define MCL_CURRENT 8192 /* lock all currently mapped pages */ #define MCL_FUTURE 16384 /* lock all additions to address space */ +#define MCL_ONFAULT32768 /* lock all pages that are faulted in */ #define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ +#define MLOCK_ONFAULT 0x02/* Lock pages in range after they are faulted in, do not prefault */ #define MADV_NORMAL0 /* no further special treatment */ #define MADV_RANDOM1 /* expect random page references */ diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h index 67c1cdf..71ed81d 100644 --- a/arch/mips/include/uapi/asm/mman.h +++ b/arch/mips/include/uapi/asm/mman.h @@ -61,11 +61,13 @@ */ #define MCL_CURRENT1 /* lock all current mappings */ #define MCL_FUTURE 2 /* lock all future mappings */ +#define MCL_ONFAULT4 /* lock all pages that are faulted in */ /* * Flags for mlock */ #define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ +#define MLOCK_ONFAULT 0x02/* Lock pages in range after they are faulted in, do not prefault */ #define MADV_NORMAL0 /* no further special treatment */ #define MADV_RANDOM1 /* expect random page references */ diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h index daab994..c0871ce 100644 --- a/arch/parisc/include/uapi/asm/mman.h +++ b/arch/parisc/include/uapi/asm/mman.h @@ -31,8 +31,10 @@ #define MCL_CURRENT1 /* lock all current mappings */ #define MCL_FUTURE 2 /* lock all future mappings */ +#define MCL_ONFAULT4 /* lock all pages that are faulted in */ #define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ +#define MLOCK_ONFAULT 0x02/* Lock pages in range after they are faulted in, do not prefault */ #define MADV_NORMAL 0 /* no further special treatment */ #define MADV_RANDOM 1 /* expect random
Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls
On Thu, 23 Jul 2015, Ralf Baechle wrote: On Wed, Jul 22, 2015 at 10:15:01AM -0400, Eric B Munson wrote: You haven't wired it up properly on powerpc, but I haven't mentioned it because I'd rather we did it. cheers It looks like I will be spinning a V5, so I will drop all but the x86 system calls additions in that version. The MIPS bits are looking good however, so Acked-by: Ralf Baechle r...@linux-mips.org With my ack, will you keep them or maybe carry them as a separate patch? I will keep the MIPS additions as a separate patch in the series, though I have dropped two of the new syscalls after some discussion. So I will not include your ack on the new patch. Eric signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V5 2/7] mm: mlock: Add new mlock system call
With the refactored mlock code, introduce a new system call for mlock. The new call will allow the user to specify what lock states are being added. mlock2 is trivial at the moment, but a follow on patch will add a new mlock state making it useful. Signed-off-by: Eric B Munson emun...@akamai.com Cc: Michal Hocko mho...@suse.cz Cc: Vlastimil Babka vba...@suse.cz Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: Catalin Marinas catalin.mari...@arm.com Cc: Stephen Rothwell s...@canb.auug.org.au Cc: Guenter Roeck li...@roeck-us.net Cc: linux-al...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: adi-buildroot-de...@lists.sourceforge.net Cc: linux-cris-ker...@axis.com Cc: linux-i...@vger.kernel.org Cc: linux-m...@lists.linux-m68k.org Cc: linux-am33-l...@redhat.com Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: linux-xte...@linux-xtensa.org Cc: linux-...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org --- Changes from V4: * Drop all architectures except x86[_64] from this patch, MIPS is added later in the series. All others will be left to their maintainers. Changes from V3: * Do a (hopefully) complete job of adding the new system calls arch/alpha/include/uapi/asm/mman.h | 2 ++ arch/mips/include/uapi/asm/mman.h | 5 + arch/parisc/include/uapi/asm/mman.h| 2 ++ arch/powerpc/include/uapi/asm/mman.h | 2 ++ arch/sparc/include/uapi/asm/mman.h | 2 ++ arch/tile/include/uapi/asm/mman.h | 5 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/include/uapi/asm/mman.h| 5 + include/linux/syscalls.h | 2 ++ include/uapi/asm-generic/mman.h| 2 ++ include/uapi/asm-generic/unistd.h | 4 +++- kernel/sys_ni.c| 1 + mm/mlock.c | 9 + 14 files changed, 42 insertions(+), 1 deletion(-) diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h index 0086b47..ec72436 100644 --- a/arch/alpha/include/uapi/asm/mman.h +++ b/arch/alpha/include/uapi/asm/mman.h @@ -38,6 +38,8 @@ #define MCL_CURRENT 8192 /* lock all currently mapped pages */ #define MCL_FUTURE 16384 /* lock all additions to address space */ +#define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ + #define MADV_NORMAL0 /* no further special treatment */ #define MADV_RANDOM1 /* expect random page references */ #define MADV_SEQUENTIAL2 /* expect sequential page references */ diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h index cfcb876..67c1cdf 100644 --- a/arch/mips/include/uapi/asm/mman.h +++ b/arch/mips/include/uapi/asm/mman.h @@ -62,6 +62,11 @@ #define MCL_CURRENT1 /* lock all current mappings */ #define MCL_FUTURE 2 /* lock all future mappings */ +/* + * Flags for mlock + */ +#define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ + #define MADV_NORMAL0 /* no further special treatment */ #define MADV_RANDOM1 /* expect random page references */ #define MADV_SEQUENTIAL 2 /* expect sequential page references */ diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h index 294d251..daab994 100644 --- a/arch/parisc/include/uapi/asm/mman.h +++ b/arch/parisc/include/uapi/asm/mman.h @@ -32,6 +32,8 @@ #define MCL_CURRENT1 /* lock all current mappings */ #define MCL_FUTURE 2 /* lock all future mappings */ +#define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ + #define MADV_NORMAL 0 /* no further special treatment */ #define MADV_RANDOM 1 /* expect random page references */ #define MADV_SEQUENTIAL 2 /* expect sequential page references */ diff --git a/arch/powerpc/include/uapi/asm/mman.h b/arch/powerpc/include/uapi/asm/mman.h index 6ea26df..189e85f 100644 --- a/arch/powerpc/include/uapi/asm/mman.h +++ b/arch/powerpc/include/uapi/asm/mman.h @@ -23,6 +23,8 @@ #define MCL_CURRENT 0x2000 /* lock all currently mapped pages */ #define MCL_FUTURE 0x4000 /* lock all additions to address space */ +#define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ + #define MAP_POPULATE 0x8000 /* populate (prefault) pagetables */ #define MAP_NONBLOCK 0x1 /* do not block on IO */ #define MAP_STACK 0x2 /* give out an address that is best suited for process/thread stacks */ diff --git a/arch/sparc/include/uapi/asm/mman.h
Re: [PATCH v2] powerpc/dts: Add and fix 1588 timer node for eTSEC
On Mon, 2015-07-20 at 01:33 -0500, Lu Yangbo-B47093 wrote:
On Wed, 2015-07-15 at 21:37 -0500, Lu Yangbo-B47093 wrote:
Any comments?
Thanks.
Sorry, I must have missed this on my last time through the patch queue.
I see you've decimalized the fiper and max-adj properties, which is
good... but does it really make sense for tmr-add? I'm not familiar with
what this value represents, but the numbers look more natural as hex (e.g.
0xaaab versus 2863311531).
Yes, the fiper value would be writed into fiper registers. And max-adj
value would be used in ptp driver in driver/ptp/.
But you insisted that values should be in decimalism in the v1 patch... :)
See the history :)
I didn't insist on decimals for *everything*, just where it makes sense, and
that it goes in a register doesn't *automatically* mean that it doesn't
make sense.
# history ##
+ ptp_clock@b0e00{
+ compatible = fsl,etsec-ptp;
+ reg = 0xb0e00 0xb0;
+ interrupts = 68 2 0 0 69 2 0 0;
+ fsl,tclk-period = 5;
+ fsl,tmr-prsc= 2;
+ fsl,tmr-add = 0xcccd;
+ fsl,tmr-fiper1 = 0x3b9ac9fb;
+ fsl,tmr-fiper2 = 0x00018696;
+ fsl,max-adj = 24999;
Please don't use hex for numbers that make more sense as decimal.
[Lu Yangbo-B47093] The hex value is register value, I think it's better
to use hex.
Whether it goes into a register doesn't matter. Hex values are useful for
values which are subdivided into various bitfields, or whose hex
representation is simpler than decimal. I'm not familiar with the details
of this hardware, but I doubt the former is the case for 0x3b9ac9fb ==
95 or 0x18696 == 0.
-Scott
##
diff --git a/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
b/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
index c21d1c7..363172d 100644
--- a/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
+++ b/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
@@ -215,12 +215,12 @@
};
ptp_clock@24e00{
- fsl,tclk-period = 5;
- fsl,tmr-prsc = 200;
- fsl,tmr-add = 0xCCCD;
- fsl,tmr-fiper1 = 0x3B9AC9FB;
- fsl,tmr-fiper2 = 0x0001869B;
- fsl,max-adj = 24999;
+ fsl,tclk-period = 5;
+ fsl,tmr-prsc= 2;
+ fsl,tmr-add = 2863311531;
+ fsl,tmr-fiper1 = 5;
+ fsl,tmr-fiper2 = 0;
+ fsl,max-adj = 2;
};
And here, you're changing the value of fsl,tmr-add and fsl,max-adj. Why?
The old values maybe not calculated base on the default eTSEC system clock
value.
1588 timer couldn’t be adjusted correctly by old values.
Explain in the changelog what was wrong with the old values (don't just say
Fix 1588 timer node in file).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 02/10] dpaa_eth: add support for DPAA Ethernet
-Original Message-
From: Joe Perches [mailto:j...@perches.com]
On Wed, 2015-07-22 at 19:16 +0300, Madalin Bucur wrote:
This introduces the Freescale Data Path Acceleration Architecture
(DPAA) Ethernet driver (dpaa_eth) that builds upon the DPAA QMan,
BMan, PAMU and FMan drivers to deliver Ethernet connectivity on
the Freescale DPAA QorIQ platforms.
trivia:
+static void __hot _dpa_tx_conf(struct net_device *net_dev,
+ const struct dpa_priv_s *priv,
+ struct dpa_percpu_priv_s *percpu_priv,
+ const struct qm_fd *fd,
+ u32 fqid)
+{
[]
+static struct dpa_bp * __cold
+dpa_priv_bp_probe(struct device *dev)
Do the __hot and __cold markings really matter?
Some of them may be questionable.
Some may be, yes. I need to go through all of them.
+static int __init dpa_load(void)
+{
[]
+ err = platform_driver_register(dpa_driver);
+ if (unlikely(err 0)) {
+ pr_err(KBUILD_MODNAME
+ : %s:%hu:%s(): platform_driver_register() = %d\n,
+ KBUILD_BASENAME .c, __LINE__, __func__, err);
+ }
+
+ pr_debug(KBUILD_MODNAME : %s:%s() -\n,
+KBUILD_BASENAME .c, __func__);
Perhaps these should use pr_fmt
Agree.
+static void __exit dpa_unload(void)
+{
+ pr_debug(KBUILD_MODNAME : - %s:%s()\n,
+KBUILD_BASENAME .c, __func__);
dynamic debug has __func__ available and perhaps
the function tracer might be used instead.
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.h
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.h
[]
+#define __hot
curious.
Maybe it'd be good to add a real __hot to compiler.h
They're mostly there to make readers aware the code is critical, any
changes could mess performance.
+struct dpa_buffer_layout_s {
+ u16 priv_data_size;
+ boolparse_results;
+ booltime_stamp;
+ boolhash_results;
+ u16 data_align;
+};
+struct dpa_fq {
+ struct qman_fq fq_base;
+ struct list_head list;
+ struct net_device *net_dev;
some inconsistent indentation here and there
Yes, I've tried to align the style but given the many editors along the time
the code existed
there still are areas out of sync.
+struct dpa_bp {
+ struct bman_pool*pool;
+ u8 bpid;
+ struct device *dev;
+ union {
+ /* The buffer pools used for the private ports are initialized
+* with target_count buffers for each CPU; at runtime the
+* number of buffers per CPU is constantly brought back to
this
+* level
+*/
+ int target_count;
+ /* The configured value for the number of buffers in the
pool,
+* used for shared port buffer pools
+*/
+ int config_count;
+ };
Anonymous unions are relatively rare
We liked the direct access to members...
In this particular case the use is a bit excessive, we can do without it.
+ struct {
+ /**
Maybe the /** style should be avoided
Will fix.
+* All egress queues to a given net device belong to one
+* (and the same) congestion group.
+*/
+ struct qman_cgr cgr;
+ } cgr_data;
[]
+int dpa_stop(struct net_device *net_dev)
+{
[]
+ err = mac_dev-stop(mac_dev);
+ if (unlikely(err 0))
+ netif_err(priv, ifdown, net_dev, mac_dev-stop() = %d\n,
+ err);
Some of the likely/unlikely uses may not
be useful/necessary.
In this particular case it's gratuitous, I'll go through all of them.
+
+ for_each_port_device(i, mac_dev-port_dev) {
+ error = fm_port_disable(
+ fm_port_drv_handle(mac_dev-
port_dev[i]));
+ err = error ? error : err;
if (error)
err = error;
is more obvious to me.
Yes, it's more readable.
Thank you,
Madalin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 03/10] dpaa_eth: add configurable bpool thresholds
-Original Message- From: Joe Perches [mailto:j...@perches.com] On Wed, 2015-07-22 at 19:16 +0300, Madalin Bucur wrote: Allow the user to tweak the refill threshold and the total number of buffers in the buffer pool. The provided values are for one CPU. Any value in making these module parameters instead? I expect one would (hardly ever) change these to improve some corner cases then use them with the new values. It may help in the tuning process but afterwards the bloat to the bootcmd would probably be a nuisance. +config FSL_DPAA_ETH_MAX_BUF_COUNT + int Maximum number of buffers in private bpool + range 64 2048 + default 128 + ---help--- + The maximum number of buffers to be by default allocated in the DPAA-Ethernet private port's + buffer pool. One needn't normally modify this, as it has probably been tuned for performance + already. This cannot be lower than DPAA_ETH_REFILL_THRESHOLD. + +config FSL_DPAA_ETH_REFILL_THRESHOLD + int Private bpool refill threshold + range 32 FSL_DPAA_ETH_MAX_BUF_COUNT + default 80 + ---help--- + The DPAA-Ethernet driver will start replenishing buffer pools whose count + falls below this threshold. This must be related to DPAA_ETH_MAX_BUF_COUNT. One needn't normally + modify this value unless one has very specific performance reasons. + config FSL_DPAA_CS_THRESHOLD_1G hex Egress congestion threshold on 1G ports range 0x1000 0x1000 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
Moin,
On Fri, Jul 24, 2015 at 02:56:26PM +1200, Michael Schmitz wrote:
here's what Finn asked me to run as tests:
# dmesg | grep this_id nvram.out
# cat /proc/driver/nvram nvram.out
# hexdump -C /dev/nvram nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram nvram.out
It seems I could successfully reset the nvram under TOS with bootconf.
Here is nvram.out, using the new kernel you sent me:
root@garkin:~uname -a
Linux garkin 4.2.0-rc2-atari-269994-gc1e9d12 #327 Fri Jul 24 19:34:44 NZST 2015
m68k GNU/Linux
PS it seems LVM is working with this kernel as well!
Christian
[7.00] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base
0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { },
options { REAL_DMA SUPPORT_TAGS }
Checksum status : valid
Boot preference : unspecified
SCSI arbitration : on
SCSI host ID : 7
OS language : English (US)
Keyboard language: English (UK)
Date format : YYÿDDÿMM, 24h clock
Boot delay : 10s
Video mode : ?? colors, 80 columns, VGA PAL monitor
overscan, compat. mode off, line doubling
00 00 ff ff ff ff 00 03 13 ff 0a ff ff ff 01 7f ||
0010 87 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0030 e1 1e |..|
0032
3b5801864975cf23bcacb52f648e74cc /dev/nvram
3b5801864975cf23bcacb52f648e74cc /tmp/nvram
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/iommu: Support hybrid iommu/direct DMA ops for coherent_mask dma_mask
Ben, It looks like this patch has bit rot. I have a system now where I can test the latest version. Any chance you can rediff and resend and I can test? Thanks, Brian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/iommu: Support hybrid iommu/direct DMA ops for coherent_mask dma_mask
On Fri, 2015-07-24 at 14:55 -0500, Brian King wrote: Ben, It looks like this patch has bit rot. I have a system now where I can test the latest version. Any chance you can rediff and resend and I can test? It's in next: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/log/?h=next Or just grab linux-next. So please test it, but hopefully it works :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-pci: fix pcie range issue for some P1/P2 boards
On Wed, 2015-07-22 at 18:08 +0800, Zhiqiang Hou wrote: From: Hou Zhiqiang b48...@freescale.com You CCed this to b21...@freescale.com. Who is that? It would be nice to use friendly e-mail addresses, but at least include the name along with the e-mail address. I suggest CCing the people who added these device trees. Impact board list: P1020MBG-PC. P1022DS, P2020RDB All above boards have its PCIE memory range less than 0xbfff_, If you mean that the physical address of the memory region is = 0xbfff_, I don't see the relevance. but in dts its boundary value was 0xe000. Both of them was maped to the same boundary 0xe000 which was Overlapped and crossed. By boundary do you mean the PCIe bus address? Why is it a problem for these independent PCIe root complexes to have the same PCIe bus addresses? Cpu will access the illicit memery addr and detect error then lead to cpu stall. So update dts for these boards. What is illicit about it? Why isn't the problem seen in the 36-bit device trees, which do the same thing? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v8 1/3] powerpc/powernv: Add OPAL interfaces for accessing and modifying system LED states
From: Anshuman Khandual khand...@linux.vnet.ibm.com
This patch registers the following two new OPAL interfaces calls
for the platform LED subsystem. With the help of these new OPAL calls,
the kernel will be able to get or set the state of various individual
LEDs on the system at any given location code which is passed through
the LED specific device tree nodes.
(1) OPAL_LEDS_GET_INDICATOR opal_leds_get_ind
(2) OPAL_LEDS_SET_INDICATOR opal_leds_set_ind
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/opal-api.h| 25 -
arch/powerpc/include/asm/opal.h| 4
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 ++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index e9e4c52..8f8c45f 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -154,7 +154,9 @@
#define OPAL_FLASH_WRITE 111
#define OPAL_FLASH_ERASE 112
#define OPAL_PRD_MSG 113
-#define OPAL_LAST 113
+#define OPAL_LEDS_GET_INDICATOR114
+#define OPAL_LEDS_SET_INDICATOR115
+#define OPAL_LAST 115
/* Device tree flags */
@@ -756,6 +758,27 @@ struct opal_i2c_request {
__be64 buffer_ra; /* Buffer real address */
};
+/* LED Mode */
+#define POWERNV_LED_MODE_LIGHT_PATHlightpath
+#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight
+
+/* LED type */
+#define POWERNV_LED_TYPE_IDENTIFY identify
+#define POWERNV_LED_TYPE_FAULT fault
+#define POWERNV_LED_TYPE_ATTENTION attention
+
+enum OpalSlotLedType {
+ OPAL_SLOT_LED_TYPE_ID = 0, /* IDENTIFY LED */
+ OPAL_SLOT_LED_TYPE_FAULT = 1, /* FAULT LED */
+ OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+ OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+ OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+ OPAL_SLOT_LED_STATE_ON = 1 /* LED is ON */
+};
+
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 958e941..3233e6d 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -195,6 +195,10 @@ int64_t opal_ipmi_recv(uint64_t interface, struct
opal_ipmi_msg *msg,
int64_t opal_i2c_request(uint64_t async_token, uint32_t bus_id,
struct opal_i2c_request *oreq);
int64_t opal_prd_msg(struct opal_prd_msg *msg);
+int64_t opal_leds_get_ind(char *loc_code, __be64 *led_mask,
+ __be64 *led_value, __be64 *max_led_type);
+int64_t opal_leds_set_ind(uint64_t token, char *loc_code, const u64 led_mask,
+ const u64 led_value, __be64 *max_led_type);
int64_t opal_flash_read(uint64_t id, uint64_t offset, uint64_t buf,
uint64_t size, uint64_t token);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index d6a7b82..34c2734 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -297,3 +297,5 @@ OPAL_CALL(opal_flash_read,
OPAL_FLASH_READ);
OPAL_CALL(opal_flash_write,OPAL_FLASH_WRITE);
OPAL_CALL(opal_flash_erase,OPAL_FLASH_ERASE);
OPAL_CALL(opal_prd_msg,OPAL_PRD_MSG);
+OPAL_CALL(opal_leds_get_ind, OPAL_LEDS_GET_INDICATOR);
+OPAL_CALL(opal_leds_set_ind, OPAL_LEDS_SET_INDICATOR);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v8 3/3] leds/powernv: Add driver for PowerNV platform
This patch implements LED driver for PowerNV platform using the existing
generic LED class framework.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
We register classdev structures for all individual LEDs detected on the
system through LED specific device tree nodes. Device tree nodes specify
what all kind of LEDs present on the same location code. It registers
LED classdev structure for each of them.
All the system LEDs can be found in the same regular path /sys/class/leds/.
We don't use LED colors. We use LED node and led-types property to form
LED classdev. Our LEDs have names in this format.
location_code:attention|identify|fault
Any positive brightness value would turn on the LED and a zero value would
turn off the LED. The driver will return LED_FULL (255) for any turned on
LED and LED_OFF (0) for any turned off LED.
As per the LED class framework, the 'brightness_set' function should not
sleep. Hence these functions have been implemented through global work
queue tasks which might sleep on OPAL async call completion.
The platform level implementation of LED get and set state has been
achieved through OPAL calls. These calls are made available for the
driver by exporting from architecture specific codes.
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
---
.../devicetree/bindings/leds/leds-powernv.txt | 26 ++
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-powernv.c| 350 +
4 files changed, 388 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-powernv.txt
create mode 100644 drivers/leds/leds-powernv.c
diff --git a/Documentation/devicetree/bindings/leds/leds-powernv.txt
b/Documentation/devicetree/bindings/leds/leds-powernv.txt
new file mode 100644
index 000..6665569
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-powernv.txt
@@ -0,0 +1,26 @@
+Device Tree binding for LEDs on IBM Power Systems
+-
+
+Required properties:
+- compatible : Should be ibm,opal-v3-led.
+- led-mode : Should be lightpath or guidinglight.
+
+Each location code of FRU/Enclosure must be expressed in the
+form of a sub-node.
+
+Required properties for the sub nodes:
+- led-types : Supported LED types (attention/identify/fault) provided
+ in the form of string array.
+
+Example:
+
+leds {
+ compatible = ibm,opal-v3-led;
+ led-mode = lightpath;
+
+ U78C9.001.RST0027-P1-C1 {
+ led-types = identify, fault;
+ };
+ ...
+ ...
+};
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9ad35f7..f218cc3a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -560,6 +560,17 @@ config LEDS_BLINKM
This option enables support for the BlinkM RGB LED connected
through I2C. Say Y to enable support for the BlinkM LED.
+config LEDS_POWERNV
+ tristate LED support for PowerNV Platform
+ depends on LEDS_CLASS
+ depends on PPC_POWERNV
+ depends on OF
+ help
+ This option enables support for the system LEDs present on
+ PowerNV platforms. Say 'y' to enable this support in kernel.
+ To compile this driver as a module, choose 'm' here: the module
+ will be called leds-powernv.
+
config LEDS_SYSCON
bool LED support for LEDs on system controllers
depends on LEDS_CLASS=y
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8d6a24a..6a943d1 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
+obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
new file mode 100644
index 000..9799de5
--- /dev/null
+++ b/drivers/leds/leds-powernv.c
@@ -0,0 +1,350 @@
+/*
+ * PowerNV LED Driver
+ *
+ * Copyright IBM Corp. 2015
+ *
+ * Author: Vasant Hegde hegdevas...@linux.vnet.ibm.com
+ * Author: Anshuman Khandual khand...@linux.vnet.ibm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under
[PATCH v8 0/3] LED driver for PowerNV platform
The following series implements LED driver for PowerNV platform.
PowerNV platform has below type of LEDs:
- System attention
Indicates there is a problem with the system that needs attention.
- Identify
Helps the user locate/identify a particular FRU or resource in the
system.
- Fault
Indicates there is a problem with the FRU or resource at the
location with which the indicator is associated.
On PowerNV (Non Virtualized) platform OPAL firmware provides LED information
to host via device tree (location code and LED type). During init we check
for 'ibm,opal/leds' node in device tree to enable LED driver. And we use
OPAL API's to get/set LEDs.
Note that on PowerNV platform firmware can activate fault LED, if it can isolate
the problem. Also one can modify the LEDs using service processor interface.
None
of these involes kernel. Hence we retain LED state in unload path.
Sample LED device tree output:
--
leds {
compatible = ibm,opal-v3-led;
led-mode = lightpath;
U78C9.001.RST0027-P1-C1 {
led-types = identify, fault;
};
...
...
}
Sample sysfs output:
.
├── U78CB.001.WZS008R-A1:fault
│ ├── brightness
│ ├── device - ../../../opal_leds
│ ├── max_brightness
│ ├── power
│ │ ├── async
│ │ ├── autosuspend_delay_ms
│ │ ├── control
│ │ ├── runtime_active_kids
│ │ ├── runtime_active_time
│ │ ├── runtime_enabled
│ │ ├── runtime_status
│ │ ├── runtime_suspended_time
│ │ └── runtime_usage
│ ├── subsystem - ../../../../../class/leds
│ ├── trigger
│ └── uevent
├── U78CB.001.WZS008R-A1:identify
│ ├── brightness
│ ├── device - ../../../opal_leds
│ ├── max_brightness
│ ├── power
│ │ ├── async
│ │ ├── autosuspend_delay_ms
│ │ ├── control
│ │ ├── runtime_active_kids
│ │ ├── runtime_active_time
│ │ ├── runtime_enabled
│ │ ├── runtime_status
│ │ ├── runtime_suspended_time
│ │ └── runtime_usage
│ ├── subsystem - ../../../../../class/leds
│ ├── trigger
│ └── uevent
patch 1/2: PowerNV architecture specific code. This adds necessary
OPAL APIs.
patch 2/2: Create LED platform device and export OPAL symbols
patch 3/3: Actual LED driver implemenation for PowerNV platform.
Note:
- This patchset depends on Jacek's patchset
https://lkml.org/lkml/2015/7/17/151 (Remove work queues from LED class
drivers)
- This version of patchset is based on top of v4.2-rc2.
Previous patchset:
v7: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-July/131533.html
v6: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-July/131328.html
v5: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-July/130602.html
v4: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-April/128028.html
v3: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-April/127702.html
v2: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/126301.html
v1: https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-March/125705.html
Changes in v8:
- Added powernv_led_common structure for common variables
- Removed unused variable 'value'
- Fixed locking issue
Changes in v7:
- Club powernv_led_data powernv_leds_priv into single structure
- Removed num_leds powernv_leds_count()
- Replaced per LED mutex with global mutex
- Removed driver specific workqueue. Instead this version uses new
global workqueue.
Changes in v6:
- Added loc_code and type to powernv_led_data structure instead of parsing
them from led classdev name.
- Fixed documentation issues.
- Fixed mutex_destry issue
- Replaced led_classdev_register with devm_led_classdev_register
Changes in v5:
- Rebased on top of Linus tree
- Renamed led as leds and updated documentation
- As Ben and Arnd suggested, removed phandle from documenation
- As Ben suggested removed led-loc device tree property
- As Jacek suggested, added back compatible property to documentation
Changes in v4:
- Updated macros to reflect platform.
- s/u64/__be64/g for big endian data we get from firmware
- Addressed review comments from Jacek. Major once are:
Removed list in powernv_led_data structure
s/kzalloc/devm_kzalloc/
Removed compatible property from documentation
s/powernv_led_set_queue/powernv_brightness_set/
- Removed LED specific brightness_set/get function. Instead this version
uses single function to queue all LED set/get requests. Later we use
LED name to detect LED type and value.
- Removed hardcoded LED type used in previous version. Instead we use
led-types property to form LED classdev.
Changes in v3:
- Addressed review comments from Jacek. Major once are:
Replaced spin lock and mutex and removed redundant structures
Replaced pr_* with dev_*
Moved OPAL platform sepcific part to separate patch
Moved repteated code to common function
Added
[PATCH v8 2/3] powerpc/powernv: Create LED platform device
This patch adds platform devices for leds. Also export LED related
OPAL API's so that led driver can use these APIs.
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/platforms/powernv/opal.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index f084afa..6839358 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -648,7 +648,7 @@ static void opal_init_heartbeat(void)
static int __init opal_init(void)
{
- struct device_node *np, *consoles;
+ struct device_node *np, *consoles, *leds;
int rc;
opal_node = of_find_node_by_path(/ibm,opal);
@@ -689,6 +689,13 @@ static int __init opal_init(void)
/* Setup a heatbeat thread if requested by OPAL */
opal_init_heartbeat();
+ /* Create leds platform devices */
+ leds = of_find_node_by_path(/ibm,opal/leds);
+ if (leds) {
+ of_platform_device_create(leds, opal_leds, NULL);
+ of_node_put(leds);
+ }
+
/* Create opal kobject under /sys/firmware */
rc = opal_sysfs_init();
if (rc == 0) {
@@ -841,3 +848,6 @@ EXPORT_SYMBOL_GPL(opal_rtc_write);
EXPORT_SYMBOL_GPL(opal_tpo_read);
EXPORT_SYMBOL_GPL(opal_tpo_write);
EXPORT_SYMBOL_GPL(opal_i2c_request);
+/* Export these symbols for PowerNV LED class driver */
+EXPORT_SYMBOL_GPL(opal_leds_get_ind);
+EXPORT_SYMBOL_GPL(opal_leds_set_ind);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] mmc: sdhci-of-esdhc: add workaround for T4240 incorrect HOSTVER value
On Tue, 2015-07-21 at 15:02 +0200, Ulf Hansson wrote: On 21 July 2015 at 11:45, Yangbo Lu yangbo...@freescale.com wrote: For T4240-R1.0-R2.0, the HOSTVER register has incorrcet vender version value and sdhc spec version value. This will break down the ADMA data transfer. So add workaround to get right value VVN=0x13, SVN = 0x1. So T4240-R1.0-R2.0 is the version of the controller, right? If I understand correct you are checking what CPU/SoC you are running on, to figure out which controller version you are using, as that can't be fetched (trusted) from the registers of the esdhc controller itself!? Instead, you could deal with this directly in the DTS files. I assume you have some DTS file for each SoC/board variant, right? No, we do not have a separate DTS file for each revision of an SoC -- and if we did, we'd constantly have people using the wrong one. In principle, in your DTS file specific for the board/SoC that holds the T4240-R1.0-R2.0 version of the controller, should add a specific esdhc DT property to indicate this errata. No, because (in addition to the above issue about chip revisions) the device tree is stable ABI and errata are often discovered after device trees are deployed. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/85xx: add 'cpu-rev' property for cpus node
On Tue, 2015-07-21 at 17:45 +0800, Yangbo Lu wrote: Add 'cpu-rev' property for cpus node to support getting cpu revision from dts, since it's not good to get cpu revision using powerpc specific function(like SVR_REV()) in common drivers. No. Don't modify the device tree within Linux without a really good reason (e.g. platform code to fix up a broken device tree). Why not just read SVR from guts, which works on both PPC and ARM? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
On Fri, 24 Jul 2015, Christian T. Steigies wrote:
Moin,
On Fri, Jul 24, 2015 at 02:56:26PM +1200, Michael Schmitz wrote:
here's what Finn asked me to run as tests:
# dmesg | grep this_id nvram.out
# cat /proc/driver/nvram nvram.out
# hexdump -C /dev/nvram nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram nvram.out
It seems I could successfully reset the nvram under TOS with bootconf.
Here is nvram.out, using the new kernel you sent me:
root@garkin:~uname -a
Linux garkin 4.2.0-rc2-atari-269994-gc1e9d12 #327 Fri Jul 24 19:34:44 NZST
2015 m68k GNU/Linux
PS it seems LVM is working with this kernel as well!
Christian
[7.00] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base
0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags {
}, options { REAL_DMA SUPPORT_TAGS }
Checksum status : valid
Boot preference : unspecified
SCSI arbitration : on
SCSI host ID : 7
OS language : English (US)
Keyboard language: English (UK)
Date format : YY?DD?MM, 24h clock
Boot delay : 10s
Video mode : ?? colors, 80 columns, VGA PAL monitor
overscan, compat. mode off, line doubling
00 00 ff ff ff ff 00 03 13 ff 0a ff ff ff 01 7f ||
0010 87 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0030 e1 1e |..|
0032
3b5801864975cf23bcacb52f648e74cc /dev/nvram
3b5801864975cf23bcacb52f648e74cc /tmp/nvram
Thanks for helping with this, Christian. I'll add your name in Tested-by
tags on the relevant patches. These are rudimentary tests but combined
with my own testing on m68k, ppc32 and x86, coverage is quite good. Some
testing on ppc64 is still lacking though.
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
Hi Christian,
good to know this worked - for the record (Finn), this is the kernel
with Finn's patch applied.
I'll build the missing LVM module so Christian can run the tests on the
unpatched kernel as well.
Thanks for testing!
Michael
Am 25.07.15 um 07:07 schrieb Christian T. Steigies:
Moin,
On Fri, Jul 24, 2015 at 02:56:26PM +1200, Michael Schmitz wrote:
here's what Finn asked me to run as tests:
# dmesg | grep this_id nvram.out
# cat /proc/driver/nvram nvram.out
# hexdump -C /dev/nvram nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram nvram.out
It seems I could successfully reset the nvram under TOS with bootconf.
Here is nvram.out, using the new kernel you sent me:
root@garkin:~uname -a
Linux garkin 4.2.0-rc2-atari-269994-gc1e9d12 #327 Fri Jul 24 19:34:44 NZST 2015
m68k GNU/Linux
PS it seems LVM is working with this kernel as well!
Christian
[7.00] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base
0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { },
options { REAL_DMA SUPPORT_TAGS }
Checksum status : valid
Boot preference : unspecified
SCSI arbitration : on
SCSI host ID : 7
OS language : English (US)
Keyboard language: English (UK)
Date format : YYÿDDÿMM, 24h clock
Boot delay : 10s
Video mode : ?? colors, 80 columns, VGA PAL monitor
overscan, compat. mode off, line doubling
00 00 ff ff ff ff 00 03 13 ff 0a ff ff ff 01 7f ||
0010 87 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0030 e1 1e |..|
0032
3b5801864975cf23bcacb52f648e74cc /dev/nvram
3b5801864975cf23bcacb52f648e74cc /tmp/nvram
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/iommu: Support hybrid iommu/direct DMA ops for coherent_mask dma_mask
On Fri, 2015-07-24 at 14:55 -0500, Brian King wrote: Ben, It looks like this patch has bit rot. I have a system now where I can test the latest version. Any chance you can rediff and resend and I can test? Hrm, Michael didn't upstream it ? Ok, I'll have a look on monday. (ping me if I don't). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
On Sat, 2015-07-25 at 10:35 +1000, Finn Thain wrote: On Fri, 24 Jul 2015, Christian T. Steigies wrote: 3b5801864975cf23bcacb52f648e74cc /dev/nvram 3b5801864975cf23bcacb52f648e74cc /tmp/nvram Thanks for helping with this, Christian. I'll add your name in Tested-by tags on the relevant patches. These are rudimentary tests but combined with my own testing on m68k, ppc32 and x86, coverage is quite good. Some testing on ppc64 is still lacking though. *Blush* I'll try and get to it next week promise! cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
