* [PATCH RESEND 3/4] powerpc/vas: Remove a stray line in Makefile
From: Sukadev Bhattiprolu @ 2018-02-10 3:49 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1518234567-24869-1-git-send-email-sukadev@linux.vnet.ibm.com>
Remove a bogus line from arch/powerpc/platforms/powernv/Makefile that
was added by commit ece4e51 ("powerpc/vas: Export HVWC to debugfs").
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index 6c9d519..703a350 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -16,5 +16,4 @@ obj-$(CONFIG_OPAL_PRD) += opal-prd.o
obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
obj-$(CONFIG_PPC_MEMTRACE) += memtrace.o
obj-$(CONFIG_PPC_VAS) += vas.o vas-window.o vas-debug.o
-obj-$(CONFIG_PPC_FTW) += nx-ftw.o
obj-$(CONFIG_OCXL_BASE) += ocxl.o
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] powerpc/vas: Fix cleanup when VAS is not configured
From: Sukadev Bhattiprolu @ 2018-02-10 3:49 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
In-Reply-To: <1518234567-24869-1-git-send-email-sukadev@linux.vnet.ibm.com>
When VAS is not configured in the system, make sure to remove
the VAS debugfs directory and unregister the platform driver.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/vas-debug.c | 5 +++++
arch/powerpc/platforms/powernv/vas.c | 5 ++++-
arch/powerpc/platforms/powernv/vas.h | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/vas-debug.c b/arch/powerpc/platforms/powernv/vas-debug.c
index b4de4c6..e6e4067 100644
--- a/arch/powerpc/platforms/powernv/vas-debug.c
+++ b/arch/powerpc/platforms/powernv/vas-debug.c
@@ -207,3 +207,8 @@ void vas_init_dbgdir(void)
if (IS_ERR(vas_debugfs))
vas_debugfs = NULL;
}
+
+void vas_cleanup_dbgdir(void)
+{
+ debugfs_remove_recursive(vas_debugfs);
+}
diff --git a/arch/powerpc/platforms/powernv/vas.c b/arch/powerpc/platforms/powernv/vas.c
index aebbe95..f83e27d8 100644
--- a/arch/powerpc/platforms/powernv/vas.c
+++ b/arch/powerpc/platforms/powernv/vas.c
@@ -169,8 +169,11 @@ static int __init vas_init(void)
found++;
}
- if (!found)
+ if (!found) {
+ platform_driver_unregister(&vas_driver);
+ vas_cleanup_dbgdir();
return -ENODEV;
+ }
pr_devel("Found %d instances\n", found);
diff --git a/arch/powerpc/platforms/powernv/vas.h b/arch/powerpc/platforms/powernv/vas.h
index ae0100f..2645613 100644
--- a/arch/powerpc/platforms/powernv/vas.h
+++ b/arch/powerpc/platforms/powernv/vas.h
@@ -406,6 +406,7 @@ extern struct mutex vas_mutex;
extern struct vas_instance *find_vas_instance(int vasid);
extern void vas_init_dbgdir(void);
+extern void vas_cleanup_dbgdir(void);
extern void vas_instance_init_dbgdir(struct vas_instance *vinst);
extern void vas_window_init_dbgdir(struct vas_window *win);
extern void vas_window_free_dbgdir(struct vas_window *win);
--
2.7.4
^ permalink raw reply related
* [PATCH RESEND 1/4] powerpc/vas: Fix order of cleanup in debugfs dir
From: Sukadev Bhattiprolu @ 2018-02-10 3:49 UTC (permalink / raw)
To: Michael Ellerman
Cc: Benjamin Herrenschmidt, mikey, hbabu, linuxppc-dev, linux-kernel
Fix the order of cleanup to ensure we free the name buffer in case
of an error creating 'hvwc' or 'info' files.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/vas-debug.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/vas-debug.c b/arch/powerpc/platforms/powernv/vas-debug.c
index ca22f1e..b4de4c6 100644
--- a/arch/powerpc/platforms/powernv/vas-debug.c
+++ b/arch/powerpc/platforms/powernv/vas-debug.c
@@ -166,13 +166,13 @@ void vas_window_init_dbgdir(struct vas_window *window)
return;
-free_name:
- kfree(window->dbgname);
- window->dbgname = NULL;
-
remove_dir:
debugfs_remove_recursive(window->dbgdir);
window->dbgdir = NULL;
+
+free_name:
+ kfree(window->dbgname);
+ window->dbgname = NULL;
}
void vas_instance_init_dbgdir(struct vas_instance *vinst)
--
2.7.4
^ permalink raw reply related
* [PATCH] powerpc/npu-dma.c: Fix crash after __mmu_notifier_register failure
From: Mark Hairgrove @ 2018-02-10 3:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alistair Popple, Mark Hairgrove
pnv_npu2_init_context wasn't checking the return code from
__mmu_notifier_register. If __mmu_notifier_register failed, the
npu_context was still assigned to the mm and the caller wasn't given any
indication that things went wrong. Later on pnv_npu2_destroy_context would
be called, which in turn called mmu_notifier_unregister and dropped
mm->mm_count without having incremented it in the first place. This led to
various forms of corruption like mm use-after-free and mm double-free.
__mmu_notifier_register can fail with EINTR if a signal is pending, so
this case can be frequent.
This patch calls opal_npu_destroy_context on the failure paths, and makes
sure not to assign mm->context.npu_context until past the failure points.
Signed-off-by: Mark Hairgrove <mhairgrove@nvidia.com>
---
arch/powerpc/platforms/powernv/npu-dma.c | 32 +++++++++++++++++++----------
1 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c
index f6cbc1a..48c73aa 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -677,6 +677,11 @@ struct npu_context *pnv_npu2_init_context(struct pci_dev *gpdev,
/* No nvlink associated with this GPU device */
return ERR_PTR(-ENODEV);
+ nvlink_dn = of_parse_phandle(npdev->dev.of_node, "ibm,nvlink", 0);
+ if (WARN_ON(of_property_read_u32(nvlink_dn, "ibm,npu-link-index",
+ &nvlink_index)))
+ return ERR_PTR(-ENODEV);
+
if (!mm || mm->context.id == 0) {
/*
* Kernel thread contexts are not supported and context id 0 is
@@ -704,25 +709,30 @@ struct npu_context *pnv_npu2_init_context(struct pci_dev *gpdev,
*/
npu_context = mm->context.npu_context;
if (!npu_context) {
+ rc = -ENOMEM;
npu_context = kzalloc(sizeof(struct npu_context), GFP_KERNEL);
- if (!npu_context)
- return ERR_PTR(-ENOMEM);
+ if (npu_context) {
+ kref_init(&npu_context->kref);
+ npu_context->mm = mm;
+ npu_context->mn.ops = &nv_nmmu_notifier_ops;
+ rc = __mmu_notifier_register(&npu_context->mn, mm);
+ }
+
+ if (rc) {
+ kfree(npu_context);
+ opal_npu_destroy_context(nphb->opal_id, mm->context.id,
+ PCI_DEVID(gpdev->bus->number,
+ gpdev->devfn));
+ return ERR_PTR(rc);
+ }
mm->context.npu_context = npu_context;
- npu_context->mm = mm;
- npu_context->mn.ops = &nv_nmmu_notifier_ops;
- __mmu_notifier_register(&npu_context->mn, mm);
- kref_init(&npu_context->kref);
} else {
- kref_get(&npu_context->kref);
+ WARN_ON(!kref_get_unless_zero(&npu_context->kref));
}
npu_context->release_cb = cb;
npu_context->priv = priv;
- nvlink_dn = of_parse_phandle(npdev->dev.of_node, "ibm,nvlink", 0);
- if (WARN_ON(of_property_read_u32(nvlink_dn, "ibm,npu-link-index",
- &nvlink_index)))
- return ERR_PTR(-ENODEV);
npu_context->npdev[npu->index][nvlink_index] = npdev;
if (!nphb->npu.nmmu_flush) {
--
1.7.2.5
^ permalink raw reply related
* Re: [RFC][PATCH bpf 1/2] bpf: allow 64-bit offsets for bpf function calls
From: Alexei Starovoitov @ 2018-02-10 0:38 UTC (permalink / raw)
To: Naveen N. Rao, daniel, Sandipan Das; +Cc: linuxppc-dev, mpe, netdev
In-Reply-To: <1518194739.ublbsk69cm.naveen@linux.ibm.com>
On 2/9/18 8:54 AM, Naveen N. Rao wrote:
> Naveen N. Rao wrote:
>> Alexei Starovoitov wrote:
>>> On 2/8/18 4:03 AM, Sandipan Das wrote:
>>>> The imm field of a bpf_insn is a signed 32-bit integer. For
>>>> JIT-ed bpf-to-bpf function calls, it stores the offset from
>>>> __bpf_call_base to the start of the callee function.
>>>>
>>>> For some architectures, such as powerpc64, it was found that
>>>> this offset may be as large as 64 bits because of which this
>>>> cannot be accomodated in the imm field without truncation.
>>>>
>>>> To resolve this, we additionally use the aux data within each
>>>> bpf_prog associated with the caller functions to store the
>>>> addresses of their respective callees.
>>>>
>>>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
>>>> ---
>>>> kernel/bpf/verifier.c | 39 ++++++++++++++++++++++++++++++++++++++-
>>>> 1 file changed, 38 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>>> index 5fb69a85d967..52088b4ca02f 100644
>>>> --- a/kernel/bpf/verifier.c
>>>> +++ b/kernel/bpf/verifier.c
>>>> @@ -5282,6 +5282,19 @@ static int jit_subprogs(struct
>>>> bpf_verifier_env *env)
>>>> * run last pass of JIT
>>>> */
>>>> for (i = 0; i <= env->subprog_cnt; i++) {
>>>> + u32 flen = func[i]->len, callee_cnt = 0;
>>>> + struct bpf_prog **callee;
>>>> +
>>>> + /* for now assume that the maximum number of bpf function
>>>> + * calls that can be made by a caller must be at most the
>>>> + * number of bpf instructions in that function
>>>> + */
>>>> + callee = kzalloc(sizeof(func[i]) * flen, GFP_KERNEL);
>>>> + if (!callee) {
>>>> + err = -ENOMEM;
>>>> + goto out_free;
>>>> + }
>>>> +
>>>> insn = func[i]->insnsi;
>>>> for (j = 0; j < func[i]->len; j++, insn++) {
>>>> if (insn->code != (BPF_JMP | BPF_CALL) ||
>>>> @@ -5292,6 +5305,26 @@ static int jit_subprogs(struct
>>>> bpf_verifier_env *env)
>>>> insn->imm = (u64 (*)(u64, u64, u64, u64, u64))
>>>> func[subprog]->bpf_func -
>>>> __bpf_call_base;
>>>> +
>>>> + /* the offset to the callee from __bpf_call_base
>>>> + * may be larger than what the 32 bit integer imm
>>>> + * can accomodate which will truncate the higher
>>>> + * order bits
>>>> + *
>>>> + * to avoid this, we additionally utilize the aux
>>>> + * data of each caller function for storing the
>>>> + * addresses of every callee associated with it
>>>> + */
>>>> + callee[callee_cnt++] = func[subprog];
>>>
>>> can you share typical /proc/kallsyms ?
>>> Are you saying that kernel and kernel modules are allocated from
>>> address spaces that are always more than 32-bit apart?
>>
>> Yes. On ppc64, kernel text is linearly mapped from 0xc000000000000000,
>> while vmalloc'ed area starts from 0xd000000000000000 (for radix, this is
>> different, but still beyond a 32-bit offset).
>>
>>> That would mean that all kernel calls into modules are far calls
>>> and the other way around form .ko into kernel?
>>> Performance is probably suffering because every call needs to be built
>>> with full 64-bit offset. No ?
>>
>> Possibly, and I think Michael can give a better perspective, but I think
>> this is due to our ABI. For inter-module calls, we need to setup the TOC
>> pointer (or the address of the function being called with ABIv2),
>> which would require us to load a full address regardless.
>
> Thinking more about this, as an optimization, for bpf-to-bpf calls, we
> could detect a near call and just emit a relative branch since we don't
> care about TOC with BPF. But, this will depend on whether the different
> BPF functions are close enough (within 32MB) of one another.
so that will be just an optimization. Understood.
How about instead of doing callee = kzalloc(sizeof(func[i]) * flen..
we keep insn->off pointing to subprog and move
prog->aux->func = func;
before the last JIT pass.
Then you won't need to alloc this extra array.
^ permalink raw reply
* Re: [PATCH] pseries: Fix build break for SPLPAR=n and CPU hotplug
From: Tyrel Datwyler @ 2018-02-09 22:33 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev; +Cc: mwb
In-Reply-To: <151820002192.57762.14326361815004034389.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
On 02/09/2018 10:13 AM, Nathan Fontenot wrote:
> Build break fix for SPLPAR=n builds and CPU hotplug.
>
> arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `.dlpar_online_cpu':
> hotplug-cpu.c:(.text+0xc40): undefined reference to `.find_and_online_cpu_nid'
>
> Move the declaration of find_and_online_cpu_nid() to topology.h where
> we can define it as a no-op for SPLAPR=n builds.
>
> Fixes: e67e02a ("powerpc/pseries: Fix cpu hotplug crash with memoryless nodes")
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> ---
Reviewed-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
^ permalink raw reply
* Re: powerpc/pci: Use of_irq_parse_and_map_pci() helper
From: Rob Herring @ 2018-02-09 22:23 UTC (permalink / raw)
To: Mathieu Malaterre
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev
In-Reply-To: <CA+7wUszna8NoXLvpjJM7piveywBux33qFgA-mkV_yteACHsunw@mail.gmail.com>
On Fri, Feb 9, 2018 at 4:01 PM, Mathieu Malaterre <malat@debian.org> wrote:
> Hi Rob,
>
> I can no longer boot my old Mac Mini G4 using a custom config. After a
> tedious bisect it appears that (*). Since Mac Mini does not provide
> any serial port I cannot provide a kernel message dump (wish there was
> some kind of null modem serial cable). All I can see is some crazy
> stuff going on with ATA DMA/66 & DMA/100.
>
> Is there anything suspicious in this commit which may prevent this
> machine to boot ?
Yes, it's broken. You need this patch[1]. Sorry for the breakage.
Rob
[1] https://patchwork.kernel.org/patch/10208267/
^ permalink raw reply
* powerpc/pci: Use of_irq_parse_and_map_pci() helper
From: Mathieu Malaterre @ 2018-02-09 22:01 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev
Hi Rob,
I can no longer boot my old Mac Mini G4 using a custom config. After a
tedious bisect it appears that (*). Since Mac Mini does not provide
any serial port I cannot provide a kernel message dump (wish there was
some kind of null modem serial cable). All I can see is some crazy
stuff going on with ATA DMA/66 & DMA/100.
Is there anything suspicious in this commit which may prevent this
machine to boot ?
Thanks much,
(*)
$ git bisect good
59f47eff03a08cd2d91310f1c15a5343fa0071e5 is the first bad commit
commit 59f47eff03a08cd2d91310f1c15a5343fa0071e5
Author: Rob Herring <robh@kernel.org>
Date: Thu Jan 4 15:12:14 2018 -0600
powerpc/pci: Use of_irq_parse_and_map_pci() helper
Instead of calling both of_irq_parse_pci() and irq_create_of_mapping(),
call of_irq_parse_and_map_pci(), which does the same thing. This will allow
making of_irq_parse_pci() a private, static function.
This changes the logic slightly in that the fallback path will also be
taken if irq_create_of_mapping() fails internally.
Signed-off-by: Rob Herring <robh@kernel.org>
[bhelgaas: fold in virq init from Stephen Rothwell <sfr@canb.auug.org.au>]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
:040000 040000 b979406deb8957af240d659be1e76ed75fa43288
ec3c127fe30428955e2ad1d716c9be2adbd2623d M arch
^ permalink raw reply
* Re: powerpc-linux-gnu-ld: cannot open linker script file arch/powerpc/boot/zImage.coff.lds: No such file or directory
From: Segher Boessenkool @ 2018-02-09 20:56 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: linuxppc-dev
In-Reply-To: <CA+7wUsybiroxTP8tuvANuAKYKQjNQ8ayNtQDL=1jBV3uZJe-ow@mail.gmail.com>
On Fri, Feb 09, 2018 at 04:55:20PM +0100, Mathieu Malaterre wrote:
> >> $ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
> >> $ make O=ppc6xx ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
> >
> > Works fine for me (exact same arch and defconfig). Two differences:
> > 1) I also set CROSS_COMPILE during the config step;
> > 2) I don't build zImage, just the default (but manual "make zImage"
> > afterwards works fine).
>
> Could you run command (2) a second time on your system.
That works fine, also with -j$BIG .
> $ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
> $ make O=ppc6xx ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
> -> ok so far
> $ make O=ppc6xx -j4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
Ah. I configure with O=, but then cd to that dir and build without O= .
Also not in a subdir of the kernel source tree.
make ARCH=$ARCH CROSS_COMPILE=$TARGET- -C $KERNEL_SRC O=$PWD $DEFCONFIG
make ARCH=$ARCH CROSS_COMPILE=$TARGET- $MAKEOPTS
(everything run in the build dir).
Segher
^ permalink raw reply
* [PATCH] pseries: Fix build break for SPLPAR=n and CPU hotplug
From: Nathan Fontenot @ 2018-02-09 18:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mpe, mwb
Build break fix for SPLPAR=n builds and CPU hotplug.
arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `.dlpar_online_cpu':
hotplug-cpu.c:(.text+0xc40): undefined reference to `.find_and_online_cpu_nid'
Move the declaration of find_and_online_cpu_nid() to topology.h where
we can define it as a no-op for SPLAPR=n builds.
Fixes: e67e02a ("powerpc/pseries: Fix cpu hotplug crash with memoryless nodes")
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/topology.h | 9 +++++++++
arch/powerpc/platforms/pseries/hotplug-cpu.c | 3 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 88187c285c70..4c5704a14f0d 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -105,6 +105,15 @@ extern int timed_topology_update(int nsecs);
#endif /* CONFIG_PPC_SPLPAR */
#endif /* CONFIG_HOTPLUG_CPU || CONFIG_NEED_MULTIPLE_NODES */
+#if defined(CONFIG_PPC_SPLPAR)
+int find_and_online_cpu_nid(int cpu);
+#else
+static inline int find_and_online_cpu_nid(int cpu)
+{
+ return 0;
+}
+#endif
+
#include <asm-generic/topology.h>
#ifdef CONFIG_SMP
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index dceb51454d8d..ca6e363c2d75 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -36,6 +36,7 @@
#include <asm/xics.h>
#include <asm/xive.h>
#include <asm/plpar_wrappers.h>
+#include <asm/topology.h>
#include "pseries.h"
#include "offline_states.h"
@@ -340,8 +341,6 @@ static void pseries_remove_processor(struct device_node *np)
cpu_maps_update_done();
}
-extern int find_and_online_cpu_nid(int cpu);
-
static int dlpar_online_cpu(struct device_node *dn)
{
int rc = 0;
^ permalink raw reply related
* Re: [PATCH kernel v3] powerpc/pci: Fix broken INTx configuration via OF
From: Bjorn Helgaas @ 2018-02-09 18:07 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linuxppc-dev, Benjamin Herrenschmidt, Bjorn Helgaas,
Michael Ellerman, Rob Herring, linux-pci
In-Reply-To: <20180209062358.33457-1-aik@ozlabs.ru>
On Fri, Feb 09, 2018 at 05:23:58PM +1100, Alexey Kardashevskiy wrote:
> Commit 59f47eff03a0 ("powerpc/pci: Use of_irq_parse_and_map_pci() helper")
> replaced of_irq_parse_pci() + irq_create_of_mapping() with
> of_irq_parse_and_map_pci() but this change lost virq returned by
> irq_create_of_mapping() so virq remained zero causing INTx
> misconfiguration.
>
> This fixes pci_read_irq_line() not to loose a virq returned by
> of_irq_parse_and_map_pci().
s/not to loose a/to not lose the/
> Fixes: 59f47eff03a0 "powerpc/pci: Use of_irq_parse_and_map_pci() helper"
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
I'm fine with this version.
Since you started applying a previous version, Michael, I'll assume
you will handle this unless you tell me otherwise. One way or another
it would be good to get this in before -rc1.
> ---
> Changes:
> v3:
> * change virq from unsigned to int as of_irq_parse_and_map_pci returns int
> and even though it only returns non-negative values now, this may change
> in the future
>
> v2:
> * changed the condition from <=0 to !=0 as by design
> of_irq_parse_and_map_pci() can only return 0 for an error and virq>0.
> ---
> arch/powerpc/kernel/pci-common.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index ae2ede4..446c796 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -362,7 +362,7 @@ struct pci_controller* pci_find_hose_for_OF_device(struct device_node* node)
> */
> static int pci_read_irq_line(struct pci_dev *pci_dev)
> {
> - unsigned int virq = 0;
> + int virq;
>
> pr_debug("PCI: Try to map irq for %s...\n", pci_name(pci_dev));
>
> @@ -370,7 +370,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
> memset(&oirq, 0xff, sizeof(oirq));
> #endif
> /* Try to get a mapping from the device-tree */
> - if (!of_irq_parse_and_map_pci(pci_dev, 0, 0)) {
> + virq = of_irq_parse_and_map_pci(pci_dev, 0, 0);
> + if (virq <= 0) {
> u8 line, pin;
>
> /* If that fails, lets fallback to what is in the config
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v3 2/4] gpio: Add GPIO driver for Nintendo Wii
From: Jonathan Neuschäfer @ 2018-02-09 16:58 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Neuschäfer, Linux Kernel Mailing List, Joel Stanley,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT,
open list:GPIO SUBSYSTEM, devicetree, Albert Herranz,
Segher Boessenkool, Linus Walleij
In-Reply-To: <CAHp75Vf=Z7DTMvbacLN+E-hScBD3ZNpnf6Ch+5xm=JNbX2cbVg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
On Fri, Feb 09, 2018 at 05:30:55PM +0200, Andy Shevchenko wrote:
> On Fri, Feb 9, 2018 at 2:07 PM, Jonathan Neuschäfer
> <j.neuschaefer@gmx.net> wrote:
> > The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> > that supports a configurable number of pins (up to 32), interrupts, and
> > some special mechanisms to share the controller between the system's
> > security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> > not supported.
> >
> > This patch adds a basic driver for this GPIO controller. Interrupt
> > support will come in a later patch.
> >
> > This patch is based on code developed by Albert Herranz and the GameCube
> > Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> > available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> > has grown quite dissimilar.
> >
>
> Fine to me, though one comment below.
> In any case,
>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Thank you.
[...]
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index d6a8e851ad13..47606dfe06cc 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -229,6 +229,15 @@ config GPIO_GRGPIO
> > Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
> > VHDL IP core library.
> >
> > +config GPIO_HLWD
> > + tristate "Nintendo Wii (Hollywood) GPIO"
>
> > + depends on OF_GPIO
>
> You may get rid of it if...
[ Even if this driver isn't switched to the unified device property API,
I think "depends on OF" would be enough here, because it doesn't use
the code that's guarded by CONFIG_OF_GPIO (gpiolib-of.c), but this
applies to other drivers (e.g. gpio-aspeed, gpio-bcm-kona) as well, so
this would ideally be a bigger cleanup patch. ]
> > + res = of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios);
>
> ...if you switch to unified device property API.
I don't think this change is worth making, unless/until the of_property
API is deprecated. I'm rather sure this GPIO controller won't appear in
an ACPI-based system.
Thanks,
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH bpf 1/2] bpf: allow 64-bit offsets for bpf function calls
From: Naveen N. Rao @ 2018-02-09 16:54 UTC (permalink / raw)
To: Alexei Starovoitov, daniel, Sandipan Das; +Cc: linuxppc-dev, mpe, netdev
In-Reply-To: <1518112079.b4po0pmm3v.naveen@linux.ibm.com>
Naveen N. Rao wrote:
> Alexei Starovoitov wrote:
>> On 2/8/18 4:03 AM, Sandipan Das wrote:
>>> The imm field of a bpf_insn is a signed 32-bit integer. For
>>> JIT-ed bpf-to-bpf function calls, it stores the offset from
>>> __bpf_call_base to the start of the callee function.
>>>
>>> For some architectures, such as powerpc64, it was found that
>>> this offset may be as large as 64 bits because of which this
>>> cannot be accomodated in the imm field without truncation.
>>>
>>> To resolve this, we additionally use the aux data within each
>>> bpf_prog associated with the caller functions to store the
>>> addresses of their respective callees.
>>>
>>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
>>> ---
>>> kernel/bpf/verifier.c | 39 ++++++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 38 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index 5fb69a85d967..52088b4ca02f 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -5282,6 +5282,19 @@ static int jit_subprogs(struct bpf_verifier_env =
*env)
>>> * run last pass of JIT
>>> */
>>> for (i =3D 0; i <=3D env->subprog_cnt; i++) {
>>> + u32 flen =3D func[i]->len, callee_cnt =3D 0;
>>> + struct bpf_prog **callee;
>>> +
>>> + /* for now assume that the maximum number of bpf function
>>> + * calls that can be made by a caller must be at most the
>>> + * number of bpf instructions in that function
>>> + */
>>> + callee =3D kzalloc(sizeof(func[i]) * flen, GFP_KERNEL);
>>> + if (!callee) {
>>> + err =3D -ENOMEM;
>>> + goto out_free;
>>> + }
>>> +
>>> insn =3D func[i]->insnsi;
>>> for (j =3D 0; j < func[i]->len; j++, insn++) {
>>> if (insn->code !=3D (BPF_JMP | BPF_CALL) ||
>>> @@ -5292,6 +5305,26 @@ static int jit_subprogs(struct bpf_verifier_env =
*env)
>>> insn->imm =3D (u64 (*)(u64, u64, u64, u64, u64))
>>> func[subprog]->bpf_func -
>>> __bpf_call_base;
>>> +
>>> + /* the offset to the callee from __bpf_call_base
>>> + * may be larger than what the 32 bit integer imm
>>> + * can accomodate which will truncate the higher
>>> + * order bits
>>> + *
>>> + * to avoid this, we additionally utilize the aux
>>> + * data of each caller function for storing the
>>> + * addresses of every callee associated with it
>>> + */
>>> + callee[callee_cnt++] =3D func[subprog];
>>=20
>> can you share typical /proc/kallsyms ?
>> Are you saying that kernel and kernel modules are allocated from
>> address spaces that are always more than 32-bit apart?
>=20
> Yes. On ppc64, kernel text is linearly mapped from 0xc000000000000000,=20
> while vmalloc'ed area starts from 0xd000000000000000 (for radix, this is
> different, but still beyond a 32-bit offset).
>=20
>> That would mean that all kernel calls into modules are far calls
>> and the other way around form .ko into kernel?
>> Performance is probably suffering because every call needs to be built
>> with full 64-bit offset. No ?
>=20
> Possibly, and I think Michael can give a better perspective, but I think
> this is due to our ABI. For inter-module calls, we need to setup the TOC
> pointer (or the address of the function being called with ABIv2), which=20
> would require us to load a full address regardless.
Thinking more about this, as an optimization, for bpf-to-bpf calls, we=20
could detect a near call and just emit a relative branch since we don't=20
care about TOC with BPF. But, this will depend on whether the different=20
BPF functions are close enough (within 32MB) of one another.
We can attempt that once the generic changes are finalized on.
Thanks,
Naveen
=
^ permalink raw reply
* Re: [PATCH] crypto: talitos: fix Kernel Oops on hashing an empty file
From: Herbert Xu @ 2018-02-09 15:49 UTC (permalink / raw)
To: Christophe Leroy
Cc: David S. Miller, linux-crypto, linux-kernel, linuxppc-dev
In-Reply-To: <20180126160959.BEA466EFCA@localhost.localdomain>
On Fri, Jan 26, 2018 at 05:09:59PM +0100, Christophe Leroy wrote:
> Performing the hash of an empty file leads to a kernel Oops
>
> [ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c
> [ 44.512819] Faulting instruction address: 0xc02d2be8
> [ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 44.529171] BE PREEMPT CMPC885
> [ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
> [ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000
> [ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea)
> [ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000
> [ 44.560855] DAR: 0000000c DSISR: c0000000
> [ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
> [ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
> [ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
> [ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
> [ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
> [ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
> [ 44.608868] Call Trace:
> [ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
> [ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
> [ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
> [ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
> [ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
> [ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
> [ 44.645530] Instruction dump:
> [ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
> [ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
>
> This patch fixes that Oops by checking if src is NULL.
>
> Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: powerpc-linux-gnu-ld: cannot open linker script file arch/powerpc/boot/zImage.coff.lds: No such file or directory
From: Mathieu Malaterre @ 2018-02-09 16:23 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <CA+7wUsybiroxTP8tuvANuAKYKQjNQ8ayNtQDL=1jBV3uZJe-ow@mail.gmail.com>
On Fri, Feb 9, 2018 at 4:55 PM, Mathieu Malaterre <malat@debian.org> wrote:
> Segher,
>
> On Fri, Feb 9, 2018 at 3:48 PM, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>> Hi!
>>
>> On Fri, Feb 09, 2018 at 12:52:03PM +0100, Mathieu Malaterre wrote:
>>> Is anyone using O= output directory option ?
>>
>> Yes, always.
>
> Great !
>
>>> It seems that git/master is failing:
>>>
>>> $ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
>>> $ make O=ppc6xx ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
>>
>> Works fine for me (exact same arch and defconfig). Two differences:
>> 1) I also set CROSS_COMPILE during the config step;
>> 2) I don't build zImage, just the default (but manual "make zImage"
>> afterwards works fine).
>
> Could you run command (2) a second time on your system.
>
>>> WRAP arch/powerpc/boot/zImage.coff
>>> powerpc-linux-gnu-ld: cannot open linker script file
>>> arch/powerpc/boot/zImage.coff.lds: No such file or directory
>>> ../arch/powerpc/boot/Makefile:375: recipe for target
>>> 'arch/powerpc/boot/zImage.coff' failed
>>> make[2]: *** [arch/powerpc/boot/zImage.coff] Error 1
>>
>> Add V=1?
>
> Full steps:
>
> $ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
> $ make O=ppc6xx ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
> -> ok so far
> $ make O=ppc6xx -j4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
> make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
> CHK include/config/kernel.release
> GEN ./Makefile
> CHK include/generated/uapi/linux/version.h
> Using .. as source for kernel
> .. is not clean, please run 'make mrproper'
> in the '..' directory.
> /home/mathieu/tmp/linux/Makefile:1074: recipe for target 'prepare3' failed
> make[1]: *** [prepare3] Error 1
> make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
> Makefile:146: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
>
> Then even after a mrproper I enter in an odd state:
>
> $ make O=ppc6xx -j4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- mrproper
> make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
> rm -f .tmp_symbols.txt
> CLEAN scripts/basic
> CLEAN scripts/kconfig
> CLEAN include/config include/generated arch/powerpc/include/generated
> CLEAN .config
> make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
> mathieu@vostrodell:~/tmp/linux$ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
> make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
> HOSTCC scripts/basic/fixdep
> GEN ./Makefile
> HOSTCC scripts/kconfig/conf.o
> YACC scripts/kconfig/zconf.tab.c
> LEX scripts/kconfig/zconf.lex.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> #
> # configuration written to .config
> #
> make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
> $ make O=ppc6xx -j4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- V=1
> make -C /home/mathieu/tmp/linux/ppc6xx KBUILD_SRC=/home/mathieu/tmp/linux \
> -f /home/mathieu/tmp/linux/Makefile
> make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
> set -e; : ' CHK include/config/kernel.release'; mkdir -p
> include/config/; echo "4.15.0$(/bin/bash ../scripts/setlocalversion
> ..)" < include/config/auto.conf > include/config/kernel.release.tmp;
> if [ -r include/config/kernel.release ] && cmp -s
> include/config/kernel.release include/config/kernel.release.tmp; then
> rm -f include/config/kernel.release.tmp; else : ' UPD
> include/config/kernel.release'; mv -f
> include/config/kernel.release.tmp include/config/kernel.release; fi
> ln -fsn .. source
> make -f ../scripts/Makefile.asm-generic \
> src=uapi/asm obj=arch/powerpc/include/generated/uapi/asm
> /bin/bash ../scripts/mkmakefile \
> .. . 4 15
> GEN ./Makefile
> set -e; : ' CHK include/generated/uapi/linux/version.h'; mkdir -p
> include/generated/uapi/linux/; (echo \#define LINUX_VERSION_CODE
> 265984; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8)
> + (c))';) < ../Makefile > include/generated/uapi/linux/version.h.tmp;
> if [ -r include/generated/uapi/linux/version.h ] && cmp -s
> include/generated/uapi/linux/version.h
> include/generated/uapi/linux/version.h.tmp; then rm -f
> include/generated/uapi/linux/version.h.tmp; else : ' UPD
> include/generated/uapi/linux/version.h'; mv -f
> include/generated/uapi/linux/version.h.tmp
> include/generated/uapi/linux/version.h; fi
> make -f ../scripts/Makefile.build obj=scripts/basic
> rm -f include/linux/version.h
> awk '!x[$0]++' init/modules.builtin usr/modules.builtin
> arch/powerpc/kernel/modules.builtin arch/powerpc/mm/modules.builtin
> arch/powerpc/lib/modules.builtin arch/powerpc/sysdev/modules.builtin
> arch/powerpc/platforms/modules.builtin
> arch/powerpc/math-emu/modules.builtin
> arch/powerpc/crypto/modules.builtin arch/powerpc/net/modules.builtin
> arch/powerpc/xmon/modules.builtin arch/powerpc/perf/modules.builtin
> kernel/modules.builtin certs/modules.builtin mm/modules.builtin
> fs/modules.builtin ipc/modules.builtin security/modules.builtin
> crypto/modules.builtin block/modules.builtin drivers/modules.builtin
> sound/modules.builtin firmware/modules.builtin
> arch/powerpc/oprofile/modules.builtin net/modules.builtin
> lib/modules.builtin virt/modules.builtin > ./modules.builtin
> (cat /dev/null; ) > scripts/basic/modules.order
> rm -f .tmp_quiet_recordmcount
> make -f ../scripts/Makefile.asm-generic \
> src=asm obj=arch/powerpc/include/generated/asm
> if [ -f ../.config -o -d ../include/config ]; then \
> echo >&2 " .. is not clean, please run 'make mrproper'"; \
> echo >&2 " in the '..' directory.";\
> /bin/false; \
> fi;
> .. is not clean, please run 'make mrproper'
> in the '..' directory.
> /home/mathieu/tmp/linux/Makefile:1074: recipe for target 'prepare3' failed
> make[1]: *** [prepare3] Error 1
> make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
> Makefile:146: recipe for target 'sub-make' failed
> make: *** [sub-make] Error 2
>
>
> Current commit is f1517df8701c9f12dae9ce7f43a5d300a6917619 on my side,
> no local change.
After yet another 'make mrproper' I can no longer reproduce the build failure.
Sorry for wasting your time :(
-M
^ permalink raw reply
* Re: powerpc-linux-gnu-ld: cannot open linker script file arch/powerpc/boot/zImage.coff.lds: No such file or directory
From: Mathieu Malaterre @ 2018-02-09 15:55 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20180209144829.GP21977@gate.crashing.org>
Segher,
On Fri, Feb 9, 2018 at 3:48 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> Hi!
>
> On Fri, Feb 09, 2018 at 12:52:03PM +0100, Mathieu Malaterre wrote:
>> Is anyone using O= output directory option ?
>
> Yes, always.
Great !
>> It seems that git/master is failing:
>>
>> $ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
>> $ make O=ppc6xx ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
>
> Works fine for me (exact same arch and defconfig). Two differences:
> 1) I also set CROSS_COMPILE during the config step;
> 2) I don't build zImage, just the default (but manual "make zImage"
> afterwards works fine).
Could you run command (2) a second time on your system.
>> WRAP arch/powerpc/boot/zImage.coff
>> powerpc-linux-gnu-ld: cannot open linker script file
>> arch/powerpc/boot/zImage.coff.lds: No such file or directory
>> ../arch/powerpc/boot/Makefile:375: recipe for target
>> 'arch/powerpc/boot/zImage.coff' failed
>> make[2]: *** [arch/powerpc/boot/zImage.coff] Error 1
>
> Add V=1?
Full steps:
$ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
$ make O=ppc6xx ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
-> ok so far
$ make O=ppc6xx -j4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
CHK include/config/kernel.release
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
Using .. as source for kernel
.. is not clean, please run 'make mrproper'
in the '..' directory.
/home/mathieu/tmp/linux/Makefile:1074: recipe for target 'prepare3' failed
make[1]: *** [prepare3] Error 1
make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
Makefile:146: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
Then even after a mrproper I enter in an odd state:
$ make O=ppc6xx -j4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- mrproper
make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
rm -f .tmp_symbols.txt
CLEAN scripts/basic
CLEAN scripts/kconfig
CLEAN include/config include/generated arch/powerpc/include/generated
CLEAN .config
make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
mathieu@vostrodell:~/tmp/linux$ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
HOSTCC scripts/basic/fixdep
GEN ./Makefile
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#
make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
$ make O=ppc6xx -j4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- V=1
make -C /home/mathieu/tmp/linux/ppc6xx KBUILD_SRC=/home/mathieu/tmp/linux \
-f /home/mathieu/tmp/linux/Makefile
make[1]: Entering directory '/home/mathieu/tmp/linux/ppc6xx'
set -e; : ' CHK include/config/kernel.release'; mkdir -p
include/config/; echo "4.15.0$(/bin/bash ../scripts/setlocalversion
..)" < include/config/auto.conf > include/config/kernel.release.tmp;
if [ -r include/config/kernel.release ] && cmp -s
include/config/kernel.release include/config/kernel.release.tmp; then
rm -f include/config/kernel.release.tmp; else : ' UPD
include/config/kernel.release'; mv -f
include/config/kernel.release.tmp include/config/kernel.release; fi
ln -fsn .. source
make -f ../scripts/Makefile.asm-generic \
src=uapi/asm obj=arch/powerpc/include/generated/uapi/asm
/bin/bash ../scripts/mkmakefile \
.. . 4 15
GEN ./Makefile
set -e; : ' CHK include/generated/uapi/linux/version.h'; mkdir -p
include/generated/uapi/linux/; (echo \#define LINUX_VERSION_CODE
265984; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8)
+ (c))';) < ../Makefile > include/generated/uapi/linux/version.h.tmp;
if [ -r include/generated/uapi/linux/version.h ] && cmp -s
include/generated/uapi/linux/version.h
include/generated/uapi/linux/version.h.tmp; then rm -f
include/generated/uapi/linux/version.h.tmp; else : ' UPD
include/generated/uapi/linux/version.h'; mv -f
include/generated/uapi/linux/version.h.tmp
include/generated/uapi/linux/version.h; fi
make -f ../scripts/Makefile.build obj=scripts/basic
rm -f include/linux/version.h
awk '!x[$0]++' init/modules.builtin usr/modules.builtin
arch/powerpc/kernel/modules.builtin arch/powerpc/mm/modules.builtin
arch/powerpc/lib/modules.builtin arch/powerpc/sysdev/modules.builtin
arch/powerpc/platforms/modules.builtin
arch/powerpc/math-emu/modules.builtin
arch/powerpc/crypto/modules.builtin arch/powerpc/net/modules.builtin
arch/powerpc/xmon/modules.builtin arch/powerpc/perf/modules.builtin
kernel/modules.builtin certs/modules.builtin mm/modules.builtin
fs/modules.builtin ipc/modules.builtin security/modules.builtin
crypto/modules.builtin block/modules.builtin drivers/modules.builtin
sound/modules.builtin firmware/modules.builtin
arch/powerpc/oprofile/modules.builtin net/modules.builtin
lib/modules.builtin virt/modules.builtin > ./modules.builtin
(cat /dev/null; ) > scripts/basic/modules.order
rm -f .tmp_quiet_recordmcount
make -f ../scripts/Makefile.asm-generic \
src=asm obj=arch/powerpc/include/generated/asm
if [ -f ../.config -o -d ../include/config ]; then \
echo >&2 " .. is not clean, please run 'make mrproper'"; \
echo >&2 " in the '..' directory.";\
/bin/false; \
fi;
.. is not clean, please run 'make mrproper'
in the '..' directory.
/home/mathieu/tmp/linux/Makefile:1074: recipe for target 'prepare3' failed
make[1]: *** [prepare3] Error 1
make[1]: Leaving directory '/home/mathieu/tmp/linux/ppc6xx'
Makefile:146: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
Current commit is f1517df8701c9f12dae9ce7f43a5d300a6917619 on my side,
no local change.
^ permalink raw reply
* Re: [PATCH v3 2/4] gpio: Add GPIO driver for Nintendo Wii
From: Jonathan Neuschäfer @ 2018-02-09 15:48 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-kernel, Joel Stanley, linuxppc-dev, linux-gpio, devicetree,
Albert Herranz, Segher Boessenkool, Linus Walleij
In-Reply-To: <20180209120732.17863-3-j.neuschaefer@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
On Fri, Feb 09, 2018 at 01:07:29PM +0100, Jonathan Neuschäfer wrote:
> The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> that supports a configurable number of pins (up to 32), interrupts, and
> some special mechanisms to share the controller between the system's
> security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> not supported.
>
> This patch adds a basic driver for this GPIO controller. Interrupt
> support will come in a later patch.
>
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissimilar.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> Cc: Albert Herranz <albert_herranz@yahoo.es>
> Cc: Segher Boessenkool <segher@kernel.crashing.org>
> <---
Ooops, I just noticed that I broke the separator here. This should be a
normal --- line, obviously.
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mm: Fix crashes with PUD level hugetlb config
From: Aneesh Kumar K.V @ 2018-02-09 15:31 UTC (permalink / raw)
To: Ram Pai; +Cc: benh, paulus, mpe, linuxppc-dev
In-Reply-To: <20180208192930.GB5559@ram.oc3035372033.ibm.com>
On 02/09/2018 12:59 AM, Ram Pai wrote:
> On Thu, Feb 08, 2018 at 08:46:27PM +0530, Aneesh Kumar K.V wrote:
>> "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
>>
>>> To support memory keys, we moved the hash pte slot information to the second
>>> half of the page table. This was ok with PTE entries at level 4 and level 3.
>>> We already allocate larger page table pages at those level to accomodate extra
>>> details. For level 4 we already have the extra space which was used to track
>>> 4k hash page table entry details and at pmd level the extra space was allocated
>>> to track the THP details.
>>>
>>> With hugetlbfs PTE, we used this extra space at the PMD level to store the
>>> slot details. But we also support hugetlbfs PTE at PUD leve and PUD level page
>>> didn't allocate extra space. This resulted in memory corruption.
>>>
>>> Fix this by allocating extra space at PUD level when HUGETLB is enabled. We
>>> may need further changes to allocate larger space at PMD level when we enable
>>> HUGETLB. That will be done in next patch.
>>>
>>> Fixes:bf9a95f9a6481bc6e(" powerpc: Free up four 64K PTE bits in 64K backed HPTE pages")
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Another fix, I still get random memory corruption with hugetlb test with
>> 16G hugepage config.
>
> this fix may not be needed. It random corruption may be artifact of the typo you
> had in your first patch?
Why? the tables at level 2 and leve3 are of different size and we should
use the right offset to store the slot details. Even with the change you
mentioned in the previous mail, I still have kernel crashes with
hugetlbfs test running in parallel to a kernel build.
-aneesh
^ permalink raw reply
* Re: [PATCH v3 2/4] gpio: Add GPIO driver for Nintendo Wii
From: Andy Shevchenko @ 2018-02-09 15:30 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: Linux Kernel Mailing List, Joel Stanley,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT,
open list:GPIO SUBSYSTEM, devicetree, Albert Herranz,
Segher Boessenkool, Linus Walleij
In-Reply-To: <20180209120732.17863-3-j.neuschaefer@gmx.net>
On Fri, Feb 9, 2018 at 2:07 PM, Jonathan Neusch=C3=A4fer
<j.neuschaefer@gmx.net> wrote:
> The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> that supports a configurable number of pins (up to 32), interrupts, and
> some special mechanisms to share the controller between the system's
> security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> not supported.
>
> This patch adds a basic driver for this GPIO controller. Interrupt
> support will come in a later patch.
>
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissimilar.
>
Fine to me, though one comment below.
In any case,
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Jonathan Neusch=C3=A4fer <j.neuschaefer@gmx.net>
> Cc: Albert Herranz <albert_herranz@yahoo.es>
> Cc: Segher Boessenkool <segher@kernel.crashing.org>
> <---
>
> v3:
> - Do some style cleanups, as suggest by Andy Shevchenko
>
> v2:
> - Change hlwd_gpio_driver.driver.name to "gpio-hlwd" to match the
> filename (was "hlwd_gpio")
> - Remove unnecessary include of linux/of_gpio.h, as suggested by Linus
> Walleij.
> - Add struct device pointer to context struct to make it possible to use
> dev_info(hlwd->dev, "..."), as suggested by Linus Walleij
> - Use the GPIO_GENERIC library to reduce code size, as suggested by
> Linus Walleij
> - Use iowrite32be instead of __raw_writel for big-endian MMIO access, as
> suggested by Linus Walleij
> - Remove commit message paragraph suggesting to diff against the
> original driver, because it's so different now
> ---
> drivers/gpio/Kconfig | 9 ++++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-hlwd.c | 115 +++++++++++++++++++++++++++++++++++++++++=
++++++
> 3 files changed, 125 insertions(+)
> create mode 100644 drivers/gpio/gpio-hlwd.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index d6a8e851ad13..47606dfe06cc 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -229,6 +229,15 @@ config GPIO_GRGPIO
> Select this to support Aeroflex Gaisler GRGPIO cores from the G=
RLIB
> VHDL IP core library.
>
> +config GPIO_HLWD
> + tristate "Nintendo Wii (Hollywood) GPIO"
> + depends on OF_GPIO
You may get rid of it if...
> + select GPIO_GENERIC
> + help
> + Select this to support the GPIO controller of the Nintendo Wii.
> +
> + If unsure, say N.
> +
> config GPIO_ICH
> tristate "Intel ICH GPIO"
> depends on PCI && X86
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 4bc24febb889..492f62d0eb59 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_GPIO_FTGPIO010) +=3D gpio-ftgpio010.o
> obj-$(CONFIG_GPIO_GE_FPGA) +=3D gpio-ge.o
> obj-$(CONFIG_GPIO_GPIO_MM) +=3D gpio-gpio-mm.o
> obj-$(CONFIG_GPIO_GRGPIO) +=3D gpio-grgpio.o
> +obj-$(CONFIG_GPIO_HLWD) +=3D gpio-hlwd.o
> obj-$(CONFIG_HTC_EGPIO) +=3D gpio-htc-egpio.o
> obj-$(CONFIG_GPIO_ICH) +=3D gpio-ich.o
> obj-$(CONFIG_GPIO_INGENIC) +=3D gpio-ingenic.o
> diff --git a/drivers/gpio/gpio-hlwd.c b/drivers/gpio/gpio-hlwd.c
> new file mode 100644
> index 000000000000..a63136a68ba3
> --- /dev/null
> +++ b/drivers/gpio/gpio-hlwd.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +// Copyright (C) 2008-2009 The GameCube Linux Team
> +// Copyright (C) 2008,2009 Albert Herranz
> +// Copyright (C) 2017-2018 Jonathan Neusch=C3=A4fer
> +//
> +// Nintendo Wii (Hollywood) GPIO driver
> +
> +#include <linux/gpio/driver.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
...(and using platform device header I suppose)...
> +#include <linux/slab.h>
> +
> +/*
> + * Register names and offsets courtesy of WiiBrew:
> + * https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
> + *
> + * Note that for most registers, there are two versions:
> + * - HW_GPIOB_* Is always accessible by the Broadway PowerPC core, but d=
oes
> + * always give access to all GPIO lines
> + * - HW_GPIO_* Is only accessible by the Broadway PowerPC code if the me=
mory
> + * firewall (AHBPROT) in the Hollywood chipset has been configured to =
allow
> + * such access.
> + *
> + * The ownership of each GPIO line can be configured in the HW_GPIO_OWNE=
R
> + * register: A one bit configures the line for access via the HW_GPIOB_*
> + * registers, a zero bit indicates access via HW_GPIO_*. This driver use=
s
> + * HW_GPIOB_*.
> + */
> +#define HW_GPIOB_OUT 0x00
> +#define HW_GPIOB_DIR 0x04
> +#define HW_GPIOB_IN 0x08
> +#define HW_GPIOB_INTLVL 0x0c
> +#define HW_GPIOB_INTFLAG 0x10
> +#define HW_GPIOB_INTMASK 0x14
> +#define HW_GPIOB_INMIR 0x18
> +#define HW_GPIO_ENABLE 0x1c
> +#define HW_GPIO_OUT 0x20
> +#define HW_GPIO_DIR 0x24
> +#define HW_GPIO_IN 0x28
> +#define HW_GPIO_INTLVL 0x2c
> +#define HW_GPIO_INTFLAG 0x30
> +#define HW_GPIO_INTMASK 0x34
> +#define HW_GPIO_INMIR 0x38
> +#define HW_GPIO_OWNER 0x3c
> +
> +struct hlwd_gpio {
> + struct gpio_chip gpioc;
> + void __iomem *regs;
> +};
> +
> +static int hlwd_gpio_probe(struct platform_device *pdev)
> +{
> + struct hlwd_gpio *hlwd;
> + struct resource *regs_resource;
> + u32 ngpios;
> + int res;
> +
> + hlwd =3D devm_kzalloc(&pdev->dev, sizeof(*hlwd), GFP_KERNEL);
> + if (!hlwd)
> + return -ENOMEM;
> +
> + regs_resource =3D platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + hlwd->regs =3D devm_ioremap_resource(&pdev->dev, regs_resource);
> + if (IS_ERR(hlwd->regs))
> + return PTR_ERR(hlwd->regs);
> +
> + /*
> + * Claim all GPIOs using the OWNER register. This will not work o=
n
> + * systems where the AHBPROT memory firewall hasn't been configur=
ed to
> + * permit PPC access to HW_GPIO_*.
> + *
> + * Note that this has to happen before bgpio_init reads the
> + * HW_GPIOB_OUT and HW_GPIOB_DIR, because otherwise it reads the =
wrong
> + * values.
> + */
> + iowrite32be(0xffffffff, hlwd->regs + HW_GPIO_OWNER);
> +
> + res =3D bgpio_init(&hlwd->gpioc, &pdev->dev, 4,
> + hlwd->regs + HW_GPIOB_IN, hlwd->regs + HW_GPIOB_O=
UT,
> + NULL, hlwd->regs + HW_GPIOB_DIR, NULL,
> + BGPIOF_BIG_ENDIAN_BYTE_ORDER);
> + if (res < 0) {
> + dev_warn(&pdev->dev, "bgpio_init failed: %d\n", res);
> + return res;
> + }
> +
> + res =3D of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios=
);
...if you switch to unified device property API.
> + if (res)
> + ngpios =3D 32;
> + hlwd->gpioc.ngpio =3D ngpios;
> +
> + return devm_gpiochip_add_data(&pdev->dev, &hlwd->gpioc, hlwd);
> +}
> +
> +static const struct of_device_id hlwd_gpio_match[] =3D {
> + { .compatible =3D "nintendo,hollywood-gpio", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, hlwd_gpio_match);
> +
> +static struct platform_driver hlwd_gpio_driver =3D {
> + .driver =3D {
> + .name =3D "gpio-hlwd",
> + .of_match_table =3D hlwd_gpio_match,
> + },
> + .probe =3D hlwd_gpio_probe,
> +};
> +module_platform_driver(hlwd_gpio_driver);
> +
> +MODULE_AUTHOR("Jonathan Neusch=C3=A4fer <j.neuschaefer@gmx.net>");
> +MODULE_DESCRIPTION("Nintendo Wii GPIO driver");
> +MODULE_LICENSE("GPL");
> --
> 2.15.1
>
--=20
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mm: Fix crashes with PUD level hugetlb config
From: Aneesh Kumar K.V @ 2018-02-09 15:30 UTC (permalink / raw)
To: Ram Pai; +Cc: benh, paulus, mpe, linuxppc-dev
In-Reply-To: <20180208192201.GA5559@ram.oc3035372033.ibm.com>
On 02/09/2018 12:52 AM, Ram Pai wrote:
> On Thu, Feb 08, 2018 at 04:04:41PM +0530, Aneesh Kumar K.V wrote:
>> To support memory keys, we moved the hash pte slot information to the second
>> half of the page table. This was ok with PTE entries at level 4 and level 3.
>> We already allocate larger page table pages at those level to accomodate extra
>> details. For level 4 we already have the extra space which was used to track
>> 4k hash page table entry details and at pmd level the extra space was allocated
>> to track the THP details.
>>
>> With hugetlbfs PTE, we used this extra space at the PMD level to store the
>> slot details. But we also support hugetlbfs PTE at PUD leve and PUD level page
>> didn't allocate extra space. This resulted in memory corruption.
>>
>> Fix this by allocating extra space at PUD level when HUGETLB is enabled. We
>> may need further changes to allocate larger space at PMD level when we enable
>> HUGETLB. That will be done in next patch.
>>
>> Fixes:bf9a95f9a6481bc6e(" powerpc: Free up four 64K PTE bits in 64K backed HPTE pages")
>
> hmm.. did not know that hugetlbs operated at the PUD level. Thanks for
> catching this.
>
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> ---
>> NOTE: In the long run we may want to look at my patch series to remove slot
> ...snip...
>> }
>>
>> static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
>> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
>> index 51017726d495..3c14663d457d 100644
>> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
>> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
>> @@ -232,11 +232,13 @@ extern unsigned long __pmd_index_size;
>> extern unsigned long __pud_index_size;
>> extern unsigned long __pgd_index_size;
>> extern unsigned long __pmd_cache_index;
>> +extern unsigned long __pud_cache_index;
>> #define PTE_INDEX_SIZE __pte_index_size
>> #define PMD_INDEX_SIZE __pmd_index_size
>> #define PUD_INDEX_SIZE __pud_index_size
>> #define PGD_INDEX_SIZE __pgd_index_size
>> #define PMD_CACHE_INDEX __pmd_cache_index
>> +#define PUD_CACHE_INDEX __pmd_cache_index
>
> This is a typo. Should be 'pud' not a 'pmd'.
>
> #define PUD_CACHE_INDEX __pud_cache_index
Thanks fixed that.
-aneesh
^ permalink raw reply
* Re: [PATCH v3 2/4] gpio: Add GPIO driver for Nintendo Wii
From: Segher Boessenkool @ 2018-02-09 15:11 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-kernel, Joel Stanley, linuxppc-dev, linux-gpio, devicetree,
Albert Herranz, Linus Walleij
In-Reply-To: <20180209120732.17863-3-j.neuschaefer@gmx.net>
On Fri, Feb 09, 2018 at 01:07:29PM +0100, Jonathan Neuschäfer wrote:
> The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> that supports a configurable number of pins (up to 32), interrupts, and
> some special mechanisms to share the controller between the system's
> security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> not supported.
>
> This patch adds a basic driver for this GPIO controller. Interrupt
> support will come in a later patch.
>
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissimilar.
>
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> Cc: Albert Herranz <albert_herranz@yahoo.es>
> Cc: Segher Boessenkool <segher@kernel.crashing.org>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Looks just fine to me :-)
Segher
^ permalink raw reply
* Re: [PATCH] cxl: Enable NORST bit in PSL_DEBUG register for PSL9
From: Frederic Barrat @ 2018-02-09 14:56 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev
Cc: Andrew Donnellan, Christophe Lombard, Philippe Bergheaud,
Alastair D'Silva
In-Reply-To: <20180209040916.14250-1-vaibhav@linux.vnet.ibm.com>
Le 09/02/2018 à 05:09, Vaibhav Jain a écrit :
> We enable the NORST bit by default for debug afu images to prevent
> reset of AFU trace-data on a PCI link drop. For production AFU images
> this bit is always ignored and PSL gets reconfigured anyways thereby
> resetting the trace data. So setting this bit for non-debug images
> doesn't have any impact.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> ---
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
btw, we should start removing dd1 code, it's not like anybody is going
to try that now.
Fred
> drivers/misc/cxl/pci.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> index 758842f65a1b..c983f23cc2ed 100644
> --- a/drivers/misc/cxl/pci.c
> +++ b/drivers/misc/cxl/pci.c
> @@ -503,8 +503,12 @@ static int init_implementation_adapter_regs_psl9(struct cxl *adapter,
> if (cxl_is_power9_dd1()) {
> /* Disabling deadlock counter CAR */
> cxl_p1_write(adapter, CXL_PSL9_GP_CT, 0x0020000000000001ULL);
> - } else
> - cxl_p1_write(adapter, CXL_PSL9_DEBUG, 0x4000000000000000ULL);
> + /* Enable NORST */
> + cxl_p1_write(adapter, CXL_PSL9_DEBUG, 0x8000000000000000ULL);
> + } else {
> + /* Enable NORST and DD2 features */
> + cxl_p1_write(adapter, CXL_PSL9_DEBUG, 0xC000000000000000ULL);
> + }
>
> return 0;
> }
>
^ permalink raw reply
* Re: powerpc-linux-gnu-ld: cannot open linker script file arch/powerpc/boot/zImage.coff.lds: No such file or directory
From: Segher Boessenkool @ 2018-02-09 14:48 UTC (permalink / raw)
To: Mathieu Malaterre; +Cc: linuxppc-dev
In-Reply-To: <CA+7wUswUir9cHEyvdT8vc+tvSxrcsoY8da+CpqG6kpc4oMj9Wg@mail.gmail.com>
Hi!
On Fri, Feb 09, 2018 at 12:52:03PM +0100, Mathieu Malaterre wrote:
> Is anyone using O= output directory option ?
Yes, always.
> It seems that git/master is failing:
>
> $ make O=ppc6xx ARCH=powerpc ppc6xx_defconfig
> $ make O=ppc6xx ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
Works fine for me (exact same arch and defconfig). Two differences:
1) I also set CROSS_COMPILE during the config step;
2) I don't build zImage, just the default (but manual "make zImage"
afterwards works fine).
> WRAP arch/powerpc/boot/zImage.coff
> powerpc-linux-gnu-ld: cannot open linker script file
> arch/powerpc/boot/zImage.coff.lds: No such file or directory
> ../arch/powerpc/boot/Makefile:375: recipe for target
> 'arch/powerpc/boot/zImage.coff' failed
> make[2]: *** [arch/powerpc/boot/zImage.coff] Error 1
Add V=1?
Segher
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/pci: Fix broken INTx configuration via OF
From: Rob Herring @ 2018-02-09 14:39 UTC (permalink / raw)
To: Michael Ellerman
Cc: Alexey Kardashevskiy, linuxppc-dev, Benjamin Herrenschmidt,
Bjorn Helgaas, linux-pci
In-Reply-To: <87vaf6wvwc.fsf@concordia.ellerman.id.au>
On Thu, Feb 8, 2018 at 11:54 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
>
>> Commit 59f47eff03a0 ("powerpc/pci: Use of_irq_parse_and_map_pci() helper")
>> replaced of_irq_parse_pci() + irq_create_of_mapping() with
>> of_irq_parse_and_map_pci() but this change lost virq returned by
>> irq_create_of_mapping() so virq remained zero causing INTx
>> misconfiguration.
>>
>> This fixes pci_read_irq_line() not to loose a virq returned by
>> of_irq_parse_and_map_pci().
>>
>> Fixes: 59f47eff03a0 "powerpc/pci: Use of_irq_parse_and_map_pci() helper"
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * changed the condition from <=0 to !=0 as by design
>> of_irq_parse_and_map_pci() can only return 0 for an error and virq>0.
>
> It returns int, so you should store the result in an int, and check the
> result for <= 0.
>
> Otherwise if it starts returning a negative error value this code will
> break.
That won't happen until we're confident all callers expect NO_IRQ is
only 0 and don't treat negative as NO_IRQ. I expect that to be never,
but maybe of_irq_parse_and_map_pci calls can be audited more easily
than of_irq_parse_and_map. We ended up with of_irq_get() because we
need to return error codes.
Rob
^ permalink raw reply
* Re: [PATCH 2/3] cxl: Introduce module parameter 'enable_psltrace'
From: christophe lombard @ 2018-02-09 13:14 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, Frederic Barrat
Cc: Philippe Bergheaud, Alastair D'Silva, Andrew Donnellan,
Christophe Lombard
In-Reply-To: <20180209042535.16845-3-vaibhav@linux.vnet.ibm.com>
Le 09/02/2018 à 05:25, Vaibhav Jain a écrit :
> We introduce a new module parameter named 'enable_psltrace' which asks cxl
> to start(by default) psl-traces on an adapter as soon as its probe is
> finished. In case this default behavior is not needed then this
> module parameter can be set to '0'.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> ---
> drivers/misc/cxl/cxl.h | 2 ++
> drivers/misc/cxl/main.c | 4 ++++
> drivers/misc/cxl/pci.c | 3 +++
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
> index 81da307b60c0..1af66451cbb4 100644
> --- a/drivers/misc/cxl/cxl.h
> +++ b/drivers/misc/cxl/cxl.h
> @@ -28,6 +28,7 @@
> #include <uapi/misc/cxl.h>
>
> extern uint cxl_verbose;
> +extern bool cxl_enable_psltrace;
>
> #define CXL_TIMEOUT 5
>
> @@ -678,6 +679,7 @@ struct cxl_service_layer_ops {
> void (*psl_irq_dump_registers)(struct cxl_context *ctx);
> void (*err_irq_dump_registers)(struct cxl *adapter);
> void (*stop_psltrace)(struct cxl *adapter);
> + void (*start_psltrace)(struct cxl *adapter);
> void (*write_timebase_ctrl)(struct cxl *adapter);
> u64 (*timebase_read)(struct cxl *adapter);
> int capi_mode;
> diff --git a/drivers/misc/cxl/main.c b/drivers/misc/cxl/main.c
> index c1ba0d42cbc8..593f2cdba3d8 100644
> --- a/drivers/misc/cxl/main.c
> +++ b/drivers/misc/cxl/main.c
> @@ -34,6 +34,10 @@ uint cxl_verbose;
> module_param_named(verbose, cxl_verbose, uint, 0600);
> MODULE_PARM_DESC(verbose, "Enable verbose dmesg output");
>
> +bool cxl_enable_psltrace = true;
> +module_param_named(enable_psltrace, cxl_enable_psltrace, bool, 0600);
> +MODULE_PARM_DESC(enable_psltrace, "Set PSL traces on probe. default: on");
> +
I am not too agree to add a new parameter. This can cause doubts.
PSL team has confirmed that enabling traces has no impact.
Do you see any reason to disable the traces ?
> const struct cxl_backend_ops *cxl_ops;
>
> int cxl_afu_slbia(struct cxl_afu *afu)
> diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> index 926b13973b73..9e8b8525534c 100644
> --- a/drivers/misc/cxl/pci.c
> +++ b/drivers/misc/cxl/pci.c
> @@ -1726,6 +1726,9 @@ static int cxl_configure_adapter(struct cxl *adapter, struct pci_dev *dev)
> if ((rc = cxl_native_register_psl_err_irq(adapter)))
> goto err;
>
> + if (cxl_enable_psltrace && adapter->native->sl_ops->start_psltrace)
> + adapter->native->sl_ops->start_psltrace(adapter);
> +
> return 0;
>
> err:
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox