Dan Williams writes:
> On Sat, Nov 16, 2019 at 4:15 AM Aneesh Kumar K.V
> wrote:
>>
>>
>> Considering the direct-map map size is not going to be user selectable,
>> do you agree that we can skip the above step 0 configuration you
>> suggested.
>>
>> The changes proposed in the patch seri
Commit f01642e4912b ("perf metricgroup: Support multiple
events for metricgroup") introduced support for multiple events
in a metric group. But with the current upstream, metric events
names are not printed properly
In power9 platform:
command:# ./perf stat --metric-only -M translation -C 0 -I 100
Christophe Leroy writes:
> A few changes to retrieve DAR and DSISR from struct regs
> instead of retrieving them directly, as they may have
> changed due to a TLB miss.
>
> Also modifies hash_page() and friends to work with virtual
> data addresses instead of physical ones.
>
> Signed-off-by: Chri
Christophe Leroy writes:
> When not using large TLBs, the IMMR region is still
> mapped as a whole block in the FIXMAP area.
>
> Do not remove pages mapped in the FIXMAP region when
> initialising paging.
>
> Properly report that the IMMR region is block-mapped even
> when not using large TLBs.
>
In preparation for allowing to build QE support for architectures
other than PPC, replace the ppc-specific io accessors by the qe_io*
macros. Done via
$ spatch --sp-file io.cocci --in-place drivers/soc/fsl/qe/
where io.cocci is
@@
expression addr, val;
@@
- out_be32(addr, val)
+ qe_iowrite32be(v
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 417df7e19281..2a0e6e642776 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -378,8 +378,
There have been several attempts in the past few years to allow
building the QUICC engine drivers for platforms other than PPC32. This
is yet another attempt.
v4 can be found here:
https://lore.kernel.org/lkml/20191108130123.6839-1-li...@rasmusvillemoes.dk/
Changes in v5:
- add patch (33/48) to
The QUICC engine drivers use the powerpc-specific out_be32() etc. In
order to allow those drivers to build for other architectures, those
must be replaced by iowrite32be(). However, on powerpc, out_be32() is
a simple inline function while iowrite32be() is out-of-line. So in
order not to introduce a
Make it clear that these operate on big-endian registers (i.e. use the
iowrite*be primitives) before we introduce more uses of them and allow
the QE drivers to be built for platforms other than ppc32.
Signed-off-by: Rasmus Villemoes
---
drivers/net/wan/fsl_ucc_hdlc.c | 4 ++--
drivers/soc/fsl/q
The actual io accessors (e.g. in_be32) implicitly add a volatile
qualifier to their address argument. Remove volatile from the struct
definition and the qe_ic_(read/write) helpers, in preparation for
switching from the ppc-specific io accessors to generic ones.
Signed-off-by: Rasmus Villemoes
---
In preparation for allowing QE to be built for architectures other
than ppc, use the generic readx_poll_timeout_atomic() helper from
iopoll.h rather than the ppc-only spin_event_timeout().
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 13 +++--
1 file changed, 7 insertion
Commit e5c5c8d23fef (soc/fsl/qe: only apply QE_General4 workaround on
affected SoCs) introduced use of pvr_version_is(), saying
The QE_General4 workaround is only valid for the MPC832x and MPC836x
SoCs. The other SoCs that embed a QUICC engine are not affected by this
hardware bug and
These includes are not actually needed, and asm/rheap.h and
sysdev/fsl_soc.h are PPC-specific, hence prevent compiling QE for
other architectures.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c| 5 -
drivers/soc/fsl/qe/qe_io.c | 2 --
2 files changed, 7 deletions(-)
diff --
high_active is only assigned to but never used. Remove it.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index 8c874372416b..4b03060d8079 100644
---
There's no point in registering with sysfs when that doesn't actually
allow any interaction with the device or driver (no uevents, no sysfs
files that provide information or allow configuration, no nothing).
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 31
The *_ipic and *_mpic handlers are almost identical - the only
difference is that the latter end with an unconditional
chip->irq_eoi() call. Since IPIC does not have ->irq_eoi, we can
reduce some code duplication by calling irq_eoi conditionally.
This is similar to what is already done in mpc8xxx_
Having to call qe_ic_init() from platform-specific code makes it
awkward to allow building the QE drivers for ARM. It's also a needless
duplication of code, and slightly error-prone: Instead of the caller
needing to know the details of whether the QUICC Engine High and QUICC
Engine Low are actually
This is now exactly the same as mpc83xx_ipic_init_IRQ, so just use
that directly.
Signed-off-by: Rasmus Villemoes
---
arch/powerpc/platforms/83xx/km83xx.c | 2 +-
arch/powerpc/platforms/83xx/misc.c| 7 ---
arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
arch/powerpc/platforms/
Since commit 302c059f2e7b (QE: use subsys_initcall to init qe),
mpc85xx_qe_init() has done nothing apart from possibly emitting a
pr_err(). As part of reducing the amount of QE-related code in
arch/powerpc/ (and eventually support QE on other architectures),
remove this low-hanging fruit.
Signed-o
These functions are only ever called through a function pointer, and
therefore it makes no sense for them to be "static inline" - gcc has
no choice but to emit a copy in each translation unit that takes the
address of one of these. Since they are now only referenced from
qe_ic.c, just make them loc
The qe_ic_cascade_{low,high}_mpic functions are now used as handlers
both when the interrupt parent is mpic as well as ipic, so remove the
_mpic suffix.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/driv
This driver is currently PPC-only, and on powerpc, NO_IRQ is 0, so
this doesn't change functionality. However, not every architecture
defines NO_IRQ, and some define it as -1, so the detection of a failed
irq_of_parse_and_map() (which returns 0 on failure) would be wrong on
those. So to prepare for
There are no current callers of these functions, and they use the
ppc-specific virq_to_hw(). So removing them gets us one step closer to
building QE support for ARM.
If the functionality is ever actually needed, the code can be dug out
of git and then adapted to work on all architectures, but for
These are only called from within qe_ic.c, so make them static.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 4 ++--
include/soc/fsl/qe/qe_ic.h | 10 --
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe
qe_ic_init() takes a flags parameter, but all callers (including the
sole remaining one) have always passed 0. So remove that parameter and
simplify the body accordingly. We still explicitly initialize the
Interrupt Configuration Register (CICR) to its reset value of
all-zeroes, just in case the bo
Christophe Leroy writes:
> arch/powerpc/kernel/ contains 8 files dedicated to kexec.
>
> Move them into a dedicated subdirectory.
>
> Signed-off-by: Christophe Leroy
>
> ---
> v2: moved crash.c as well as it's part of kexec suite.
> v3: renamed files to remove 'kexec' keyword from names.
> v4: re
The public qe_ic.h header is no longer included by anything but
qe_ic.c. Merge both headers into qe_ic.c, and drop the unused
constants.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 52 +++-
drivers/soc/fsl/qe/qe_ic.h | 99 -
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_io.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
index f6b10f38b2f4..99aeb01586bd 100644
--- a/drivers/soc/fsl/qe/qe_io.c
+++ b/drivers/soc/fsl/qe/qe_io
We need to apply be32_to_cpu to make this work correctly on
little-endian hosts.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_io.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
index 99aeb0
Instead of manually doing of_get_property/of_find_property and reading
the value by assigning to a u32* or u64* and dereferencing, use the
of_property_read_* functions.
This make the code more readable, and more importantly, is required
for this to work correctly on little-endian platforms.
Signe
This is necessary for this to work on little-endian hosts.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_io.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
index 61dd8eb8c0fe..11ea08e97db7 100644
---
asm/cpm.h under arch/powerpc is now just a wrapper for including
soc/fsl/cpm.h. In order to make the qe.h header usable on other
architectures, use the latter path directly.
Signed-off-by: Rasmus Villemoes
---
include/soc/fsl/qe/qe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
Some drivers, e.g. ucc_uart, need definitions from cpm.h. In order to
allow building those drivers for non-ppc based SOCs, move the header
to include/soc/fsl. For now, leave a trivial wrapper at the old
location so drivers can be updated one by one.
Signed-off-by: Rasmus Villemoes
---
arch/power
This driver uses #defines from soc/fsl/cpm.h, so instead of relying on
some other header pulling that in, do that explicitly. This is
preparation for allowing this driver to build on ARM.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 1 +
1 file changed, 1 insertion(+)
dif
Some ARM-based SOCs (e.g. LS1021A) also have a QUICC engine. As
preparation for allowing this driver to build on ARM, replace the
ppc-specific in_be16() etc. by the qe_io* helpers. Done via
coccinelle.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 210 +-
The Soft UART hack is only needed for some PPC-based SOCs. To allow
building this driver for non-PPC, guard soft_uart_init() and its
helpers by CONFIG_PPC32, and use a no-op soft_uart_init() otherwise.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 17 -
1 fi
The "soft uart" mechanism is a workaround for a silicon bug which (as
far as I know) only affects some PPC-based SOCs.
The code that determines which microcode blob to request relies on
some powerpc-specific bits (e.g. the mfspr(SPRN_SVR) and hence also
the asm/reg.h header). This makes it a littl
For this to work correctly on little-endian hosts, don't access the
device-tree properties directly in native endianness, but use the
of_property_read_u32() helper.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 36 +++
1 file changed, 15 inse
According to Timur Tabi
This bug in older U-Boots is definitely PowerPC-specific
So before allowing this driver to be built for platforms other than
PPC32, make sure that we don't accept malformed device trees on those
other platforms.
Suggested-by: Timur Tabi
Signed-off-by: Rasmus Villemoe
The buf member of struct qe_bd is a __be32, so to make this work on
little-endian hosts, use be32_to_cpu when reading it.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/ucc_uart.c b/dr
There are a number of problems with cpm_muram_alloc() and its
callers. Most callers assign the return value to some variable and
then use IS_ERR_VALUE to check for allocation failure. However, when
that variable is not sizeof(long), this leads to warnings - and it is
indeed broken to do e.g.
u32
Nobody uses the return value from cpm_muram_free, and functions that
free resources usually return void. One could imagine a use for a "how
much have I allocated" a la ksize(), but knowing how much one had
access to after the fact is useless.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/q
This allows one to simplify callers since they can store a negative
value as a sentinel to indicate "this was never allocated" (or store
the -ENOMEM from an allocation failure) and then call cpm_muram_free()
unconditionally.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_common.c | 3
If the kmalloc() fails, we try to undo the gen_pool allocation we've
just done. Unfortunately, start has already been modified to subtract
the GENPOOL_OFFSET bias, so we're freeing something that very likely
doesn't exist in the gen_pool, meaning we hit the
kernel BUG at lib/genalloc.c:399!
Inte
Now that qe_muram_alloc() returns s32, adapt qe_sdma_init() and avoid
another few IS_ERR_VALUE() uses.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index ec5
cpm_muram_alloc_common() tries to support a kind of lazy
initialization - if the muram_pool has not been created yet, it calls
cpm_muram_init(). Now, cpm_muram_alloc_common() is always called under
spin_lock_irqsave(&cpm_muram_lock, flags);
and cpm_muram_init() does gen_pool_create() (whi
When trying to build this for a 64-bit platform, one gets warnings
from using IS_ERR_VALUE on something which is not sizeof(long).
Instead, change the various *_offset fields to store a signed integer,
and simply check for a negative return from qe_muram_alloc(). Since
qe_muram_free() now accepts
The sdma member of struct qe_immap is not at offset zero, so even if
qe_immr wasn't initialized yet (i.e. NULL), &qe_immr->sdma would not
be NULL.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/s
When building this on a 64-bit platform gcc rightly warns that the
error checking is broken (-ENOMEM stored in an u32 does not compare
greater than (unsigned long)-MAX_ERRNO). Instead, change the
ucc_fast_[tr]x_virtual_fifo_base_offset members to s32 and use an
ordinary check-for-negative. Also, th
When building this on a 64-bit platform gcc rightly warns that the
error checking is broken (-ENOMEM stored in an u32 does not compare
greater than (unsigned long)-MAX_ERRNO). Instead, now that
qe_muram_alloc() returns s32, use that type to store the return value
and use standard kernel style "ret
When releasing the allocated muram resource, we rely on reading back
the offsets from the riptr/tiptr registers. But those registers are
__be16 (and we indeed write them using iowrite16be), so we can't just
read them back with a normal C dereference.
This is not currently a real problem, since for
Qiang Zhao points out that these offsets get written to 16-bit
registers, and there are some QE platforms with more than 64K
muram. So it is possible that qe_muram_alloc() gives us an allocation
that can't actually be used by the hardware, so detect and reject
that.
Reported-by: Qiang Zhao
Signed
Currently, QUICC_ENGINE depends on PPC32, so this in itself does not
change anything. In order to allow removing the PPC32 dependency from
QUICC_ENGINE and avoid allmodconfig build failures, add this explicit
dependency.
Also, the QE Ethernet has never been integrated on any non-PowerPC SoC
and mo
There are also PPC64, ARM and ARM64 based SOCs with a QUICC Engine,
and the core QE code as well as net/wan/fsl_ucc_hdlc and
tty/serial/ucc_uart has now been modified to not rely on ppcisms.
So extend the architectures that can select QUICC_ENGINE, and add the
rather modest requirements of OF && H
On Mon, Nov 18, 2019 at 01:02:00PM +1100, Daniel Axtens wrote:
> Hi Roman,
>
> > We're running a lot of KVM virtual machines on POWER8 hosts and
> > sometimes new VMs can't be started because there are no contiguous
> > regions for HPT because of CMA region fragmentation.
> >
> > The issue is cove
On Thu 14-11-19 21:53:33, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via put_user_page().
> The effect is similar to FOLL_GET, and may b
On Thu 14-11-19 21:53:18, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there are subtle diffe
On Thu 14-11-19 21:53:23, John Hubbard wrote:
> And get rid of the mmap_sem calls, as part of that. Note
> that get_user_pages_fast() will, if necessary, fall back to
> __gup_longterm_unlocked(), which takes the mmap_sem as needed.
>
> Reviewed-by: Jason Gunthorpe
> Reviewed-by: Ira Weiny
> Sign
On Thu 14-11-19 21:53:26, John Hubbard wrote:
> /*
> - * NOTE on FOLL_LONGTERM:
> + * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
> + * other. Here is what they mean, and how to use them:
> *
> * FOLL_LONGTERM indicates that the page will be held for an indefinite
On Thu 14-11-19 21:53:29, John Hubbard wrote:
> Convert process_vm_access to use the new pin_user_pages_remote()
> call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
> code that requires tracking of pinned pages.
>
> Also, release the pages via put_user_page*().
>
> Also, rename "pag
On Thu 14-11-19 21:53:22, John Hubbard wrote:
> 1. Avoid naming conflicts: rename local static function from
> "pin_user_pages()" to "pin_goldfish_pages()".
>
> An upcoming patch will introduce a global pin_user_pages()
> function.
>
> Reviewed-by: Jérôme Glisse
> Reviewed-by: Ira Weiny
> Signe
On Thu 14-11-19 21:53:31, John Hubbard wrote:
> Convert fs/io_uring to use the new pin_user_pages() call, which sets
> FOLL_PIN. Setting FOLL_PIN is now required for code that requires
> tracking of pinned pages, and therefore for any code that calls
> put_user_page().
>
> In partial anticipation
On Thu 14-11-19 21:53:27, John Hubbard wrote:
> 1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
>
> 2. As required by pin_user_pages(), release these pages via
> put_user_page(). In this case, do so via put_user_pages_dirty_lock().
>
> That has the side effect of calling
On Fri, 15 Nov 2019 16:06:34 -0500
Qian Cai wrote:
> > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
>
> # git reset --hard b83b43ffc6e4b514ca034a0fbdee01322e2f7022
>
> Yes, that one is bad.
Can you see if this patch fixes the issue for you?
Thanks!
-- Steve
diff --git
On Mon, 18 Nov 2019 09:51:04 -0500
Steven Rostedt wrote:
> > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> >
> > # git reset --hard b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> >
> > Yes, that one is bad.
>
> Can you see if this patch fixes the issue for you?
Don't
On Mon, 18 Nov 2019 09:58:42 -0500
Steven Rostedt wrote:
> On Mon, 18 Nov 2019 09:51:04 -0500
> Steven Rostedt wrote:
>
> > > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> > >
> > > # git reset --hard b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> > >
> > > Yes, that
Hi Thomas
On 10/30/19 15:38, Qais Yousef wrote:
> Using cpu_up/down directly to bring cpus online/offline loses synchronization
> with sysfs and could suffer from a race similar to what is described in
> commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization
> during LPM").
>
On Mon, 2019-11-18 at 10:16 -0500, Steven Rostedt wrote:
> On Mon, 18 Nov 2019 09:58:42 -0500
> Steven Rostedt wrote:
>
> > On Mon, 18 Nov 2019 09:51:04 -0500
> > Steven Rostedt wrote:
> >
> > > > > Test this commit please: b83b43ffc6e4b514ca034a0fbdee01322e2f7022
> > > > >
> > > >
> >
Le 18/11/2019 à 03:36, Alistair Popple a écrit :
On Monday, 18 November 2019 12:24:24 PM AEDT Oliver O'Halloran wrote:
On Mon, Nov 18, 2019 at 12:06 PM Alistair Popple
wrote:
On Wednesday, 13 November 2019 4:38:21 AM AEDT Frederic Barrat wrote:
However, one question is whether this patc
https://bugzilla.kernel.org/show_bug.cgi?id=205327
--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Michael Ellerman from comment #3)
> Do you want to send a patch?
I already sent the patch to linuxppc-dev@lists.ozlabs.org
(https://patchwork.ozlabs.org/patch/1195212/) but don'
On Mon, 18 Nov 2019, Qais Yousef wrote:
> I had to make an educated guess that you're probably the 'maintainer' of cpu
> hotplug - but there's no explicit entry that says that. Please let me know if
> I need to bring the attention of others too.
:)
> The series do have few rough edges to address
On Thu, 2019-11-14 at 14:41 +0100, Frederic Barrat wrote:
> Hi Alastair,
>
> The patch is huge and could/should probably be split in smaller
> pieces
> to ease the review. However, having sinned on that same topic in the
> past, I made a first pass anyway. I haven't covered everything but
> trie
On 15/11/19 3:35 am, Dan Williams wrote:
Have you discussed with the directory owner if it's ok to split the
driver over several files?
My thought is to establish drivers/opencapi/ and move this and the
existing drivers/misc/ocxl/ bits there.
Is there any other justification for this we can t
On Mon, Nov 18, 2019 at 3:48 PM Andrew Donnellan wrote:
>
> On 15/11/19 3:35 am, Dan Williams wrote:
> >> Have you discussed with the directory owner if it's ok to split the
> >> driver over several files?
> >
> > My thought is to establish drivers/opencapi/ and move this and the
> > existing driv
On 11/18/19 3:58 AM, Jan Kara wrote:
> On Thu 14-11-19 21:53:33, John Hubbard wrote:
>> Add tracking of pages that were pinned via FOLL_PIN.
>>
>> As mentioned in the FOLL_PIN documentation, callers who effectively set
>> FOLL_PIN are required to ultimately free such pages via put_user_page().
>> T
Qais Yousef writes:
> The core device API performs extra housekeeping bits that are missing
> from directly calling cpu_up/down.
>
> See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and
> serialization during LPM") for an example description of what might go
> wrong.
>
> This also pre
Erhard Furtner writes:
> In attach_node_and_children memory is allocated for full_name via
> kasprintf. If the condition of the 1st if is not met the function
> returns early without freeing the memory. Add a kfree() to fix that.
It would be good to mention that this was detected with kmemleak.
On 10/9/19 1:45 am, Frederic Barrat wrote:
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 6104418c9ad5..00a79f3c989f 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -48,13 +48,14 @@ int pnv_pci_get_sl
https://bugzilla.kernel.org/show_bug.cgi?id=205327
--- Comment #6 from Michael Ellerman (mich...@ellerman.id.au) ---
I replied with directions on what to do.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 10/9/19 1:45 am, Frederic Barrat wrote:
When changing the slot state, if opal hits an error and tells as such
in the asynchronous reply, the warning "Wrong msg" is logged, which is
rather confusing. Instead we can reuse the better message which is
already used when we couldn't submit the async
On Tue, 2019-11-19 at 10:47 +1100, Andrew Donnellan wrote:
> On 15/11/19 3:35 am, Dan Williams wrote:
> > > Have you discussed with the directory owner if it's ok to split
> > > the
> > > driver over several files?
> >
> > My thought is to establish drivers/opencapi/ and move this and the
> > exis
On 19/11/19 1:48 pm, Alastair D'Silva wrote:
On Tue, 2019-11-19 at 10:47 +1100, Andrew Donnellan wrote:
On 15/11/19 3:35 am, Dan Williams wrote:
Have you discussed with the directory owner if it's ok to split
the
driver over several files?
My thought is to establish drivers/opencapi/ and move
On Mon, Nov 18, 2019 at 7:29 PM Andrew Donnellan wrote:
>
> On 19/11/19 1:48 pm, Alastair D'Silva wrote:
> > On Tue, 2019-11-19 at 10:47 +1100, Andrew Donnellan wrote:
> >> On 15/11/19 3:35 am, Dan Williams wrote:
> Have you discussed with the directory owner if it's ok to split
> the
>
Hi all,
This series includes a set of fixes for LLVM/Clang when building
a few defconfigs (powernv, ppc44x, and pseries are the ones that our
CI configuration tests [1]). The first patch fixes pseries_defconfig,
which has never worked in mainline. The second and third patches fixes
issues with all
tLinux/linux/issues/240
Reviewed-by: Daniel Axtens
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Improve commit message
v2 -> v3:
* Rebase and merge into a single series.
v3 -> v4:
* Rebase on v5.4-rc3.
* Update links to point to llvmorg-9.0.0 instead of llvmorg-9.0.0-rc2.
v4 -&
eady
had a v2):
* Use -ffreestanding instead of outright disabling the warning because
it is legitimate.
v3 -> v4:
* Rebase on v5.4-rc3
* Add Nick's reviewed-by and Compiler Explorer link.
v4 -> v5:
* Rebase on next-20191118
arch/powerpc/kernel/Makefile | 4 ++--
arch/
v3 -> v4:
* Rebase on v5.4-rc3.
* Add Nick's reviewed-by tag.
* Update the LLVM commit reference to the latest applied version (r374662)
as it was originally committed as r370454, reverted in r370788, and
reapplied as r374662.
v4 -> v5:
* Rebase on next-20191118 to avoi
On 10/9/19 1:45 am, Frederic Barrat wrote:
On powernv, when removing a device through hotplug, the following
warning is logged:
Invalid refcount <.> on <...>
It may be incorrect, the refcount may be set to a higher value than 1
and be valid. of_detach_node() can drop more than one referen
On 11/18/19 2:16 AM, Jan Kara wrote:
> On Thu 14-11-19 21:53:26, John Hubbard wrote:
>> /*
>> - * NOTE on FOLL_LONGTERM:
>> + * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each
>> + * other. Here is what they mean, and how to use them:
>> *
>> * FOLL_LONGTERM indicates
On 10/9/19 1:45 am, Frederic Barrat wrote:
Add the opencapi PHBs to the list of PHBs being scanned to look for
slots.
Signed-off-by: Frederic Barrat
---
drivers/pci/hotplug/pnv_php.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/hotplug/pnv_php.c b/drive
> On 16-Nov-2019, at 12:25 AM, Aneesh Kumar K.V
> wrote:
>
> On 11/15/19 11:36 AM, Sachin Sant wrote:
>> Following Oops is seen on latest (commit 3b4852888d) powerpc merge branch
>> code while running ndctl (test_namespace) tests
>> 85c5b0984e was good.
>
>
>
> Are the namespace size creat
From: Rob Herring
[ Upstream commit 53dd9dce6979bc54d64a3a09a2fb20187a025be7 ]
The next update of libfdt has a new dependency on INT_MAX. Update the
instances of libfdt_env.h in the kernel to either include the necessary
header with the definition or define it locally.
Cc: Russell King
Cc: Ben
From: Rob Herring
[ Upstream commit 53dd9dce6979bc54d64a3a09a2fb20187a025be7 ]
The next update of libfdt has a new dependency on INT_MAX. Update the
instances of libfdt_env.h in the kernel to either include the necessary
header with the definition or define it locally.
Cc: Russell King
Cc: Ben
Chen Wandun writes:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> arch/powerpc/platforms/pseries/ras.c: In function ras_epow_interrupt:
> arch/powerpc/platforms/pseries/ras.c:319:6: warning: variable status set but
> not used [-Wunused-but-set-variable]
Thanks for the patch.
But it almos
On 10/9/19 1:45 am, Frederic Barrat wrote:
Protect the PHB's list of PE. Probably not needed as long as it was
populated during PHB creation, but it feels right and will become
required once we can add/remove opencapi devices on hotplug.
Signed-off-by: Frederic Barrat
Reviewed-by: Andrew Donn
Michael Ellerman writes:
> Christophe Leroy writes:
>> A few changes to retrieve DAR and DSISR from struct regs
>> instead of retrieving them directly, as they may have
>> changed due to a TLB miss.
>>
>> Also modifies hash_page() and friends to work with virtual
>> data addresses instead of phy
Christophe Leroy writes:
> A few changes to retrieve DAR and DSISR from struct regs
> instead of retrieving them directly, as they may have
> changed due to a TLB miss.
>
> Also modifies hash_page() and friends to work with virtual
> data addresses instead of physical ones.
>
> Signed-off-by: Chri
On 11/18/19 1:46 AM, Jan Kara wrote:
> On Thu 14-11-19 21:53:18, John Hubbard wrote:
>> There are four locations in gup.c that have a fair amount of code
>> duplication. This means that changing one requires making the same
>> changes in four places, not to mention reading the same code four
>> tim
On 10/9/19 1:45 am, Frederic Barrat wrote:
With hotplug, an opencapi device can now go away. It needs to be
released, mostly to clean up its PE state. We were previously not
defining any device callback. We can reuse the standard PCI release
callback, it does a bit too much for an opencapi device
Hi Prabhakar,
On Tue, Nov 19, 2019 at 12:02:46PM +0530, Prabhakar Kushwaha wrote:
> Hi Akashi,
>
> On Fri, Nov 15, 2019 at 7:29 AM AKASHI Takahiro
> wrote:
> >
> > Bhupesh,
> >
> > On Fri, Nov 15, 2019 at 01:24:17AM +0530, Bhupesh Sharma wrote:
> > > Hi Akashi,
> > >
> > > On Wed, Nov 13, 2019 a
1 - 100 of 108 matches
Mail list logo
