[PATCH] macintosh/via-pmu68k: Initialize PMU driver with setup_arch and arch_initcall

[Finn Thain]

The PMU watchdog will power down the system if the kernel is slow
to start up, e.g. due to unpacking a large initrd. The powerpc
version of this driver (via-pmu.c) has a solution for the same
problem. It uses this call sequence:

setup_arch
find_via_pmu
init_pmu
...
arch_initcall
via_pmu_start

Bring via-pmu68k.c into line with via-pmu.c to fix this issue.

Cc: Geert Uytterhoeven 
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 arch/m68k/mac/config.c |  4 ++
 drivers/macintosh/via-pmu68k.c | 89 +-
 2 files changed, 65 insertions(+), 28 deletions(-)

diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 95d548d8cc8a..17d9380aa7e6 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -906,6 +907,9 @@ static void __init mac_identify(void)
 #ifdef CONFIG_ADB_CUDA
find_via_cuda();
 #endif
+#ifdef CONFIG_ADB_PMU68K
+   find_via_pmu();
+#endif
 }
 
 static void __init mac_report_hardware(void)
diff --git a/drivers/macintosh/via-pmu68k.c b/drivers/macintosh/via-pmu68k.c
index 25465fb91ec9..7d9c4baf8c11 100644
--- a/drivers/macintosh/via-pmu68k.c
+++ b/drivers/macintosh/via-pmu68k.c
@@ -109,6 +109,7 @@ static int pmu_autopoll(int devs);
 void pmu_poll(void);
 static int pmu_reset_bus(void);
 
+static int init_pmu(void);
 static void pmu_start(void);
 static void send_byte(int x);
 static void recv_byte(void);
@@ -171,23 +172,76 @@ static s8 pmu_data_len[256][2] = {
 /*f8*/ {-1,-1},{-1,-1},{-1,-1},{-1,-1},{-1,-1},{-1,-1},{-1,-1},{-1,-1},
 };
 
-int pmu_probe(void)
+int __init find_via_pmu(void)
 {
-   if (macintosh_config->adb_type == MAC_ADB_PB1) {
+   switch (macintosh_config->adb_type) {
+   case MAC_ADB_PB1:
pmu_kind = PMU_68K_V1;
-   } else if (macintosh_config->adb_type == MAC_ADB_PB2) {
+   break;
+   case MAC_ADB_PB2:
pmu_kind = PMU_68K_V2;
-   } else {
+   break;
+   default:
+   pmu_kind = PMU_UNKNOWN;
return -ENODEV;
}
 
pmu_state = idle;
 
+   if (!init_pmu())
+   goto fail_init;
+
+   pr_info("adb: PMU 68K driver v0.5 for Unified ADB\n");
+
+   return 1;
+
+fail_init:
+   pmu_kind = PMU_UNKNOWN;
return 0;
 }
 
-static int 
-pmu_init(void)
+static int pmu_probe(void)
+{
+   if (pmu_kind == PMU_UNKNOWN)
+   return -ENODEV;
+   return 0;
+}
+
+static int pmu_init(void)
+{
+   if (pmu_kind == PMU_UNKNOWN)
+   return -ENODEV;
+   return 0;
+}
+
+static int __init via_pmu_start(void)
+{
+   if (pmu_kind == PMU_UNKNOWN)
+   return -ENODEV;
+
+   if (request_irq(IRQ_MAC_ADB_SR, pmu_interrupt, 0, "PMU_SR",
+   pmu_interrupt)) {
+   pr_err("%s: can't get SR irq\n", __func__);
+   return -ENODEV;
+   }
+   if (request_irq(IRQ_MAC_ADB_CL, pmu_interrupt, 0, "PMU_CL",
+   pmu_interrupt)) {
+   pr_err("%s: can't get CL irq\n", __func__);
+   free_irq(IRQ_MAC_ADB_SR, pmu_interrupt);
+   return -ENODEV;
+   }
+
+   pmu_fully_inited = 1;
+
+   /* Enable backlight */
+   pmu_enable_backlight(1);
+
+   return 0;
+}
+
+arch_initcall(via_pmu_start);
+
+static int __init init_pmu(void)
 {
int timeout;
volatile struct adb_request req;
@@ -238,28 +292,7 @@ pmu_init(void)
bright_req_2.complete = 1;
bright_req_3.complete = 1;
 
-   if (request_irq(IRQ_MAC_ADB_SR, pmu_interrupt, 0, "pmu-shift",
-   pmu_interrupt)) {
-   printk(KERN_ERR "pmu_init: can't get irq %d\n",
-   IRQ_MAC_ADB_SR);
-   return -EAGAIN;
-   }
-   if (request_irq(IRQ_MAC_ADB_CL, pmu_interrupt, 0, "pmu-clock",
-   pmu_interrupt)) {
-   printk(KERN_ERR "pmu_init: can't get irq %d\n",
-   IRQ_MAC_ADB_CL);
-   free_irq(IRQ_MAC_ADB_SR, pmu_interrupt);
-   return -EAGAIN;
-   }
-
-   pmu_fully_inited = 1;
-   
-   /* Enable backlight */
-   pmu_enable_backlight(1);
-
-   printk("adb: PMU 68K driver v0.5 for Unified ADB.\n");
-
-   return 0;
+   return 1;
 }
 
 int
-- 
2.13.6

Re: [PATCH 00/26] KVM: PPC: Book3S PR: Transaction memory support on PR KVM

[Simon Guo]

Hi Paul,
On Tue, Jan 23, 2018 at 04:38:32PM +1100, Paul Mackerras wrote:
> On Thu, Jan 11, 2018 at 06:11:13PM +0800, wei.guo.si...@gmail.com wrote:
> > From: Simon Guo 
> > 
> > In current days, many OS distributions have utilized transaction
> > memory functionality. In PowerPC, HV KVM supports TM. But PR KVM
> > does not.
> > 
> > The drive for the transaction memory support of PR KVM is the
> > openstack Continuous Integration testing - They runs a HV(hypervisor)
> > KVM(as level 1) and then run PR KVM(as level 2) on top of that.
> > 
> > This patch set add transaction memory support on PR KVM.
> 
> Thanks for the patch set.  It mostly looks good, though I have some
> comments on the individual patches.
> 
> I don't see where you are implementing support for userspace accessing
> the TM checkpointed register values using the GET_ONE_REG/SET_ONE_REG
> API.  This would mean that you couldn't migrate a guest that was in
> the middle of a transaction.  We will need to have the one_reg API
> access to the TM checkpoint implemented, though there will be a
> difficulty in that kvmppc_get_one_reg() and kvmppc_set_one_reg() are
> called with the vcpu context loaded.  With your scheme of having the
> TM checkpoint stored in the CPU while the vcpu context is loaded, the
> values you want to access in kvmppc_get/set_one_reg are inaccessible
> since they're stored in the CPU.  You would have to arrange for
> kvmppc_get/set_one_reg to be called without the vcpu context loaded
> (recent patches in the kvm next branch probably make that easier) or
> else explicitly unload and reload the vcpu context in those functions.
> (This is easier in HV KVM since the checkpoint is not in the CPU at
> the point of doing kvmppc_get/set_one_reg.)
Thanks for point it out. I didn't think about it before and will 
investigate. 

I plan to work out this PR KVM HTM kvmppc_get/set_one_reg() 
(and the KVM_SET_REGS you mentioned in another mail) with seperate 
patch/patch set, so that the reworked V2 of current patches can be 
sent out in parallel. In case it is not appropriate for you, please 
let me know.

> 
> There is also complexity added because it's possible for the guest to
> have TM, FP, VEC and VSX all enabled from its point of view but to
> have FP/VEC/VSX not actually enabled in the hardware when the guest is
> running.  As you note in your patch descriptions, this means that the
> guest can do tbegin and create a checkpoint with bogus values for the
> FP/VEC/VSX registers.  Rather than trying to detect and fix up this
> situation after the fact, I would suggest that if the guest has TM
> enabled then we make sure that the real FP/VEC/VSX bits in the MSR
> match what the guest thinks it has.  That way we would avoid the bogus
> checkpoint problem.  (There is still the possibility of getting bogus
> checkpointed FP/VEC/VSX registers if the guest does tbegin with the
> FP/VEC/VSX bits clear in the MSR, but that is the guest's problem to
> deal with.)
Good idea. I will look into kvmppc_set_msr_pr() / kvmppc_giveup_ext()
to simplify the solution.

Thanks for your review and time.

BR,
- Simon

Re: [PATCH] powerpc: Add POWER9 copy_page() loop

[Michael Ellerman]

Anton Blanchard  writes:

> From: Anton Blanchard 
>
> Add a POWER9 optimised copy_page() loop. This loop uses the new D form
> vector loads and stores, and uses dcbz to pre zero the destination.
>
...
> +
> +#ifdef CONFIG_ALTIVEC
> + mflrr0
> + std r3,-STACKFRAMESIZE+STK_REG(R31)(r1)
> + std r4,-STACKFRAMESIZE+STK_REG(R30)(r1)
> + std r0,16(r1)
> + stdur1,-STACKFRAMESIZE(r1)
> + bl  enter_vmx_copy
> + cmpwi   r3,0
> + ld  r0,STACKFRAMESIZE+16(r1)
> + ld  r3,STK_REG(R31)(r1)
> + ld  r4,STK_REG(R30)(r1)
> + addir1,r1,STACKFRAMESIZE
> + mtlrr0
> +
> + li  r0,((PAGE_SIZE/128)-2)
> + mtctr   r0
> +
> + li  r8,256
> +
> + beq .Lnonvmx_copy
> +
> + .balign 16
> +1:   dcbzr8,r3
> + lxv vs32,0(r4)
> + lxv vs33,16(r4)

Unfortunately this doesn't build:

  arch/powerpc/lib/copypage_power9.S: Assembler messages:
  arch/powerpc/lib/copypage_power9.S:66: Error: unrecognized opcode: `lxv'
  arch/powerpc/lib/copypage_power9.S:67: Error: unrecognized opcode: `lxv'
  arch/powerpc/lib/copypage_power9.S:68: Error: unrecognized opcode: `stxv'
  arch/powerpc/lib/copypage_power9.S:69: Error: unrecognized opcode: `stxv'


Presumably we need to a .long macro version for older toolchains?

cheers

Re: [PATCH V2] powerpc/kernel: Add 'ibm, thread-groups' property for CPU allocation

[Michael Ellerman]

Michael Bringmann  writes:

> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index b15bae2..0a49231 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -303,6 +306,71 @@ static void __init check_cpu_feature_properties(unsigned 
> long node)
>   }
>  }
>  
> +static void __init early_init_setup_thread_group_mask(unsigned long node,
> + cpumask_t *thread_group_mask)
> +{
> + const __be32 *thrgrp;
> + int len, rc = 0;
> + u32 cc_type = 0, no_split = 0, thr_per_split = 0;
> + int j, k;
> +
> + cpumask_clear(thread_group_mask);
> +
> + thrgrp = of_get_flat_dt_prop(node, "ibm,thread-groups", );
> + if (!thrgrp)
> + return;

This breaks booting on all my systems.

cheers

Re: [PATCH v2 2/5] powerpc/32: Fix hugepage allocation on 8xx at hint address

[Michael Ellerman]

"Aneesh Kumar K.V"  writes:

> Christophe Leroy  writes:
>
>> On the 8xx, the page size is set in the PMD entry and applies to
>> all pages of the page table pointed by the said PMD entry.
>>
...
>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
>> index a9b9083c5e49..79e1378ee303 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -553,9 +553,11 @@ unsigned long hugetlb_get_unmapped_area(struct file 
>> *file, unsigned long addr,
>>  struct hstate *hstate = hstate_file(file);
>>  int mmu_psize = shift_to_mmu_psize(huge_page_shift(hstate));
>>  
>> +#ifdef CONFIG_PPC_RADIX_MMU
>>  if (radix_enabled())
>>  return radix__hugetlb_get_unmapped_area(file, addr, len,
>> pgoff, flags);
>> +#endif
>
> if (0) didn't remove the following radix__hugetlb_get_unmapped_area for
> you? 

It will remove the call, but you still need at least a prototype, or an
empty static inline.

cheers

Re: [PATCH v2 12/13] ocxl: Documentation

[Michael Ellerman]

Frederic Barrat  writes:

> Le 25/01/2018 à 14:17, Greg KH a écrit :
>> On Tue, Jan 23, 2018 at 12:31:47PM +0100, Frederic Barrat wrote:
>>> ocxl.rst gives a quick, high-level view of opencapi.
>>>
>>> Update ioctl-number.txt to reflect ioctl numbers being used by the
>>> ocxl driver
>>>
>>> Signed-off-by: Frederic Barrat 
>>> ---
>>>   Documentation/ABI/testing/sysfs-class-ocxl |  35 +++
>>>   Documentation/accelerators/ocxl.rst| 160 
>>> +
>>>   Documentation/ioctl/ioctl-number.txt   |   1 +
>>>   3 files changed, 196 insertions(+)
>>>   create mode 100644 Documentation/ABI/testing/sysfs-class-ocxl
>>>   create mode 100644 Documentation/accelerators/ocxl.rst
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-class-ocxl 
>>> b/Documentation/ABI/testing/sysfs-class-ocxl
>>> new file mode 100644
>>> index ..ac11deb71235
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-class-ocxl
>>> @@ -0,0 +1,35 @@
>>> +What:   /sys/class/ocxl//afu_version
>>> +Date:   January 2018
>>> +Contact:linuxppc-dev@lists.ozlabs.org
>>> +Description:read only
>>> +Version of the AFU, in the format :
>>> +   Reflects what is read in the configuration space of the AFU
>> 
>> Odd mix of tabs and spaces in this file, please just use tabs.
>
> Oops! Will fix.

I've already applied it to my test tree, I'll fix it up.

cheers

Re: [PATCH RESEND V2 ] powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove

[Michael Ellerman]

Nathan Fontenot  writes:

> When DLPAR removing a CPU, the unmapping of the cpu from a node in
> unmap_cpu_from_node() should also invalidate the CPUs entry in the
> numa_cpu_lookup_table. There is not a guarantee that on a subsequent
> DLPAR add of the CPU the associativity will be the same and thus
> could be in a different node. Invalidating the entry in the
> numa_cpu_lookup_table causes the associativity to be read from the
> device tree at the time of the add.

This last part seems to contradict the change log of commit d4edc5b6c480
("powerpc: Fix the setup of CPU-to-Node mappings during CPU online"),
which seems to say that we shouldn't be looking at the device tree.

Can you explain to me what I'm missing?

Also when did this break, always? Which commit should I mark this as
fixing?

cheers

Re: [PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack

[Jonathan Neuschäfer]

On Wed, Jan 24, 2018 at 12:23:05PM +1100, Michael Ellerman wrote:
> Jonathan Neuschäfer  writes:
[...]
> > Do you have any pointer on how to implement discontiguous memory
> > support? CONFIG_ARCH_SPARSEMEM_ENABLE seems relevant.
> 
> I'm not really sure what the key impediment to it working is.
> 
> You don't need to go all the way to SPARSEMEM, there is DISCONTIGMEM
> which IIUI is quite a bit simpler.
> 
> I'd actually be interested to know what happens (ie. breaks) if you just
> add the two memblocks and leave the hole in between. Is it the generic
> code that breaks or is it something in the powerpc code? If it's the
> later maybe we can do a small fix/hack to work around that.

Ok, I did some experimentation.

First, I made wii_memory_fixups return early, before actually doing
anything[1].

[0.00] __ioremap(): phys addr 0xc003000 is RAM lr flipper_pic_init
[0.00] flipper-pic: controller at 0x0c003000 mapped to 0x  (null)
[0.00] Unable to handle kernel paging request for data at address 
0x0004

* __ioremap_caller detects overlap with RAM like this: p < 
virt_to_phys(high_memory)
* flipper_pic_init gets NULL from ioremap, but doesn't check for NULL


Then I hacked up __ioremap_caller to use memblock_is_map_memory[2],
because it considers memblocks correctly. The result was that the system
boots further, but then enters the sleep mode where the power LED shines
yellow. In this mode the ARM runs but the PPC doesn't. The same thing
would happen if GPIO 3 ("DC_DC"[3]) was pulled low. These are the last few
lines:

[0.770324] io scheduler mq-deadline registered
[0.772472] io scheduler kyber registered

I don't know what exactly is triggering this effect.


Thanks for your help,
Jonathan Neuschäfer


[1]: diff --git a/arch/powerpc/platforms/embedded6xx/wii.c 
b/arch/powerpc/platforms/embedded6xx/wii.c
index 6e6db1e16d71..cddd5606a63d 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -81,6 +81,9 @@ void __init wii_memory_fixups(void)
BUG_ON(memblock.memory.cnt != 2);
BUG_ON(!page_aligned(p[0].base) || !page_aligned(p[1].base));
 
+   /* don't fix the memory map */
+   return;
+
/* trim unaligned tail */
memblock_remove(ALIGN(p[1].base + p[1].size, PAGE_SIZE),
(phys_addr_t)ULLONG_MAX);
[2]: diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index f6c7f54c0515..bff581003c50 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -154,8 +154,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, 
unsigned long flags,
 * Don't allow anybody to remap normal RAM that we're using.
 * mem_init() sets high_memory so only do the check after that.
 */
-   if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
-   !(__allow_ioremap_reserved && memblock_is_region_reserved(p, 
size))) {
+   if (slab_is_available() && memblock_is_map_memory(p)) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
   (unsigned long long)p, __builtin_return_address(0));
return NULL;
[3]: http://wiibrew.org/wiki/Hardware/Hollywood_GPIOs


signature.asc
Description: PGP signature