On 9/23/20 2:33 AM, Qian Cai wrote:
> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
>> When a passthrough IO adapter is removed from a pseries machine using
>> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
>> guest OS to clear all page table entries related to
Build kernel with `C=2`:
arch/powerpc/perf/isa207-common.c:24:18: warning: symbol
'isa207_pmu_format_attr' was not declared. Should it be static?
arch/powerpc/perf/power9-pmu.c:101:5: warning: symbol 'p9_dd21_bl_ev'
was not declared. Should it be static?
arch/powerpc/perf/power9-pmu.c:115:5: warnin
When a passthrough IO adapter is removed from a pseries machine using
hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
guest OS to clear all page table entries related to the adapter. If
some are still present, the RTAS call which isolates the PCI slot
returns error 9001 "vali
Le 23/09/2020 à 09:18, Vincent Nicolas a écrit :
From: Christophe Leroy
Sent: Tuesday, 22 September 2020 14:38
To: Vincent Nicolas ; joc...@scram.de
Cc: linuxppc-dev@lists.ozlabs.org ;
linux-...@vger.kernel.org
Subject: Re: [PATCH] i2c: cpm: Fix i2c_ram structure
Le 22/09/2020 à
On 22/09/2020 12:01, Arnd Bergmann wrote:
> On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov wrote:
>> On 22/09/2020 10:23, Arnd Bergmann wrote:
>>> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov
>>> wrote:
On 22/09/2020 03:58, Andy Lutomirski wrote:
> On Mon, Sep 21, 2020 at 5:24 PM Pave
On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
> > On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
> >>
> >> If a task is migrated to a different CPU then the mapping address will
> >> change which will explode in colo
On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
> Alternatively this could of course be solved with per CPU page tables
> which will come around some day anyway I fear.
Previously (with PTI) we looked at making the entire kernel map per-CPU,
and that takes a 2K copy on switch_mm()
From: Christophe Leroy
Sent: Tuesday, 22 September 2020 14:38
To: Vincent Nicolas ; joc...@scram.de
Cc: linuxppc-dev@lists.ozlabs.org ;
linux-...@vger.kernel.org
Subject: Re: [PATCH] i2c: cpm: Fix i2c_ram structure
Le 22/09/2020 à 11:04, nico.vi...@gmail.com a écrit :
> From: Nicolas V
On Wed, Sep 23 2020 at 12:19, peterz wrote:
> On Mon, Sep 21, 2020 at 09:27:57PM +0200, Thomas Gleixner wrote:
>> Alternatively this could of course be solved with per CPU page tables
>> which will come around some day anyway I fear.
>
> Previously (with PTI) we looked at making the entire kernel m
>
> From: Christophe Leroy
> Sent: Wednesday, 23 September 2020 10:01
> To: Vincent Nicolas; joc...@scram.de
> Cc: linuxppc-dev@lists.ozlabs.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] i2c: cpm: Fix i2c_ram structure
>
>
>
> Le 23/09/2020 à 09:1
Le 23/09/2020 à 14:55, Vincent Nicolas a écrit :
From: Christophe Leroy
Sent: Wednesday, 23 September 2020 10:01
To: Vincent Nicolas; joc...@scram.de
Cc: linuxppc-dev@lists.ozlabs.org; linux-...@vger.kernel.org
Subject: Re: [PATCH] i2c: cpm: Fix i2c
On Wed, Sep 23, 2020 at 11:01:34AM +0300, Pavel Begunkov wrote:
> > I'm not following why that would be considered a valid option,
> > as that clearly breaks existing users that update from a 32-bit
> > kernel to a 64-bit one.
>
> Do you mean users who move 32-bit binaries (without recompiling) t
On Wed, Sep 23 2020 at 10:40, peterz wrote:
> Right, so I'm concerned. migrate_disable() wrecks pretty much all
> Real-Time scheduler theory we have, and PREEMPRT_RT bringing it in is
> somewhat ironic.
It's even more ironic that the approach of PREEMPT_RT has been
'pragmatic ignorance of theory'
From: Nicolas VINCENT
the i2c_ram structure is missing the sdmatmp field mentionned in
datasheet for MPC8272 at paragraph 36.5. With this field missing, the
hardware would write past the allocated memory done through
cpm_muram_alloc for the i2c_ram structure and land in memory allocated
for the b
On Tue, Sep 22, 2020 at 12:26:18PM +1000, Alexey Kardashevskiy wrote:
> > Well, the original intent of dma_get_required_mask is to return the
> > mask that the driver then uses to figure out what to set, so what aacraid
> > does fits that use case.
>
> What was the original intent exactly? The dr
Acked-by: Jochen Friedrich
Am 23.09.2020 um 16:08 schrieb nico.vi...@gmail.com:
From: Nicolas VINCENT
the i2c_ram structure is missing the sdmatmp field mentionned in
datasheet for MPC8272 at paragraph 36.5. With this field missing, the
hardware would write past the allocated memory done thro
On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
> +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> + unsigned long nr_segs, unsigned long fast_segs,
Hmm... For fast_segs unsigned long had always been ridiculous
(4G struct iovec on caller stack fram
On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote:
> COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd,
> - const struct compat_iovec __user *,vec,
> + const struct iovec __user *, vec,
Um... Will it even compile?
> #ifdef __ARCH_WANT_COMPAT_SYS_PREADV64
On Wed, Sep 23, 2020 at 03:25:49PM +0100, Al Viro wrote:
> On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote:
> > COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd,
> > - const struct compat_iovec __user *,vec,
> > + const struct iovec __user *, vec,
>
> Um...
On Mon, Sep 21 2020 at 21:27, Thomas Gleixner wrote:
> On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote:
>> On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote:
>> Maybe we really *could* call this new kmap functionality something
>> like "kmap_percpu()" (or maybe "local" is good enough), and
From: Al Viro
> Sent: 23 September 2020 15:17
>
> On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
>
> > +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> > + unsigned long nr_segs, unsigned long fast_segs,
>
> Hmm... For fast_segs unsigned long had a
On Wed, Sep 23, 2020 at 03:16:54PM +0100, Al Viro wrote:
> On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
>
> > +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> > + unsigned long nr_segs, unsigned long fast_segs,
>
> Hmm... For fast_segs unsigned lo
On Wed, Sep 23, 2020 at 02:38:24PM +, David Laight wrote:
> From: Al Viro
> > Sent: 23 September 2020 15:17
> >
> > On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
> >
> > > +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> > > + unsigned long nr_seg
On Wed, Sep 23, 2020 at 04:32:51PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 23, 2020 at 03:25:49PM +0100, Al Viro wrote:
> > On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote:
> > > COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd,
> > > - const struct compat_iovec __u
On Wed, 23 Sep 2020 10:40:32 +0200
pet...@infradead.org wrote:
> However, with migrate_disable() we can have each task preempted in a
> migrate_disable() region, worse we can stack them all on the _same_ CPU
> (super ridiculous odds, sure). And then we end up only able to run one
> task, with the
On Wed, Sep 23, 2020 at 04:08:40PM +0200, nico.vi...@gmail.com wrote:
> From: Nicolas VINCENT
>
> the i2c_ram structure is missing the sdmatmp field mentionned in
> datasheet for MPC8272 at paragraph 36.5. With this field missing, the
> hardware would write past the allocated memory done through
On Wed, Sep 23, 2020 at 03:59:01PM +0100, Al Viro wrote:
> > That's a very good question. But it does not just compile but actually
> > works. Probably because all the syscall wrappers mean that we don't
> > actually generate the normal names. I just tried this:
> >
> > --- a/include/linux/sys
On Wed, Sep 23, 2020 at 05:38:31PM +0100, Al Viro wrote:
> On Wed, Sep 23, 2020 at 03:59:01PM +0100, Al Viro wrote:
>
> > > That's a very good question. But it does not just compile but actually
> > > works. Probably because all the syscall wrappers mean that we don't
> > > actually generate the
On Wed, Sep 23, 2020 at 12:39 PM Al Viro wrote:
>
> On Wed, Sep 23, 2020 at 03:59:01PM +0100, Al Viro wrote:
>
> > > That's a very good question. But it does not just compile but actually
> > > works. Probably because all the syscall wrappers mean that we don't
> > > actually generate the normal
On Wed, Sep 23, 2020 at 06:05:27PM +0100, Al Viro wrote:
> On Wed, Sep 23, 2020 at 05:38:31PM +0100, Al Viro wrote:
> > On Wed, Sep 23, 2020 at 03:59:01PM +0100, Al Viro wrote:
> >
> > > > That's a very good question. But it does not just compile but actually
> > > > works. Probably because all
Le 23/09/2020 à 18:08, Wolfram Sang a écrit :
On Wed, Sep 23, 2020 at 04:08:40PM +0200, nico.vi...@gmail.com wrote:
From: Nicolas VINCENT
the i2c_ram structure is missing the sdmatmp field mentionned in
datasheet for MPC8272 at paragraph 36.5. With this field missing, the
hardware would wri
On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote:
>
> I wonder if we should do something like
>
> SYSCALL_DECLARE3(readv, unsigned long, fd, const struct iovec __user *, vec,
> unsigned long, vlen);
> in syscalls.h instead, and not under that ifdef.
>
> Let it expand to declaration o
On Wed, Sep 23, 2020 at 08:45:51PM +0200, Arnd Bergmann wrote:
> On Wed, Sep 23, 2020 at 6:38 PM Al Viro wrote:
> >
> > I wonder if we should do something like
> >
> > SYSCALL_DECLARE3(readv, unsigned long, fd, const struct iovec __user *, vec,
> > unsigned long, vlen);
> > in sys
On Wed, Sep 23, 2020 at 9:48 PM Al Viro wrote:
> FWIW, after playing with that for a while... Do we really want the
> compat_sys_...() declarations to live in linux/compat.h? Most of
> the users of that file don't want those; why not move them to
> linux/syscalls.h?
Sure, let's do that. The tre
[Cc'ing Nayna Jain, linuxppc-dev@lists.ozlabs.org]
Hi Lakshmi,
On Tue, 2020-09-08 at 16:08 -0700, Lakshmi Ramasubramanian wrote:
> On kexec file load Integrity Measurement Architecture(IMA) subsystem
> may verify the IMA signature of the kernel and initramfs, and measure
> it. The command line pa
s/MSIX/MSI-X/ (subject and below)
On Sat, Mar 14, 2020 at 11:30:31AM +0800, Xiaowei Bao wrote:
> Each PF of EP device should have it's own MSI or MSIX capabitily
> struct, so create a dw_pcie_ep_func struct and remove the msi_cap
> and msix_cap to this struct from dw_pcie_ep, and manage the PFs
>
On 04.09.2020 02:28, Chris Packham wrote:
> The SPIE register contains counts for the TX FIFO so any time the irq
> handler was invoked we would attempt to process the RX/TX fifos. Use the
> SPIM value to mask the events so that we only process interrupts that
> were expected.
>
> This was a laten
On Wed, Sep 23 2020 at 11:52, Steven Rostedt wrote:
> On Wed, 23 Sep 2020 10:40:32 +0200
> pet...@infradead.org wrote:
>
>> However, with migrate_disable() we can have each task preempted in a
>> migrate_disable() region, worse we can stack them all on the _same_ CPU
>> (super ridiculous odds, sure
On 24/09/20 8:27 am, Heiner Kallweit wrote:
> On 04.09.2020 02:28, Chris Packham wrote:
>> The SPIE register contains counts for the TX FIFO so any time the irq
>> handler was invoked we would attempt to process the RX/TX fifos. Use the
>> SPIM value to mask the events so that we only process inte
On Wed, 23 Sep 2020 22:55:54 +0200
Thomas Gleixner wrote:
> > Perhaps make migrate_disable() an anonymous local_lock()?
> >
> > This should lower the SHC in theory, if you can't have stacked migrate
> > disables on the same CPU.
>
> I'm pretty sure this ends up in locking hell pretty fast and
From: Arnd Bergmann
> Sent: 23 September 2020 19:46
...
> Regardless of that, another advantage of having the SYSCALL_DECLAREx()
> would be the ability to include that header file from elsewhere with a
> different
> macro definition to create a machine-readable version of the interface when
> comb
In commit 61f879d97ce4 ("powerpc/pseries: Detect secure and trusted
boot state of the system.") we taught the kernel how to understand the
secure-boot parameters used by a pseries guest.
However, CONFIG_PPC_SECURE_BOOT still requires PowerNV. I didn't
catch this because pseries_le_defconfig includ
Hi Srikar,
> The patch avoids allocating cpufreq_policy on stack hence fixing frame
> size overflow in 'powernv_cpufreq_reboot_notifier'
>
> ./drivers/cpufreq/powernv-cpufreq.c: In function
> _powernv_cpufreq_reboot_notifier_:
> ./drivers/cpufreq/powernv-cpufreq.c:906:1: error: the frame size of
> On 22-Sep-2020, at 4:16 PM, Paul A. Clarke wrote:
>
> Just one nit in a comment below...
> (and this is not worthy of tags like "reviewed-by" ;-)
>
> On Mon, Sep 21, 2020 at 03:10:04AM -0400, Athira Rajeev wrote:
>> PMU counter support functions enforces event constraints for group of
>> ev
> On 23-Sep-2020, at 12:44 PM, Wang Wensheng wrote:
>
> Build kernel with `C=2`:
> arch/powerpc/perf/isa207-common.c:24:18: warning: symbol
> 'isa207_pmu_format_attr' was not declared. Should it be static?
> arch/powerpc/perf/power9-pmu.c:101:5: warning: symbol 'p9_dd21_bl_ev'
> was not declar
Switch the 85xx defconfigs from the soon to be removed legacy ide
driver to libata.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 6 +++---
arch/powerpc/configs/85xx/tqm8540_defconfig | 6 +++---
arch/powerpc/configs/85xx/tqm8541_defconfig | 6 +++
On 23/09/2020 17:06, Cédric Le Goater wrote:
> On 9/23/20 2:33 AM, Qian Cai wrote:
>> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
>>> When a passthrough IO adapter is removed from a pseries machine using
>>> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
>>
* Daniel Axtens [2020-09-24 12:35:05]:
> Hi Srikar,
>
>
> This looks a lot like commit d95fe371ecd2 ("cpufreq: powernv: Fix
> frame-size-overflow in powernv_cpufreq_work_fn").
>
Yes, very very similar.
> As with that patch, I have checked for matching puts/gets and that all
> uses of '&' ch
This patch adds a brief MODULE_DESCRIPTION to rpadlpar_io kernel modules
(descriptions taken from Kconfig file)
Signed-off-by: Mamatha Inamdar
---
drivers/pci/hotplug/rpadlpar_core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/hotplug/rpadlpar_core.c
b/drivers/pci/hotplug
On many powerpc platforms the discovery and initalisation of
pci_controllers (PHBs) happens inside of setup_arch(). This is very early
in boot (pre-initcalls) and means that we're initialising the PHB long
before many basic kernel services (slab allocator, debugfs, a real ioremap)
are available.
O
Make powernv and pseries use ppc_mc.discover_phbs. These two platforms need
to be done together because they both depends on pci_dn's being created
from the DT. The pci_dn contains a pointer to the relevant pci_controller
so they need to be created after the pci_controller structures are
available,
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/maple/setup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index f7e66a2005b4..4e9ad5bf3efb 100644
--- a/arch/powerpc/platforms/maple/
Signed-off-by: Oliver O'Halloran
---
only compile tested
---
arch/powerpc/platforms/512x/mpc5121_ads.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c
b/arch/powerpc/platforms/512x/mpc5121_ads.c
index 6303fbfc4e4f..9d030
Signed-off-by: Oliver O'Halloran
---
compile tested with mpc5200_defconfig
---
arch/powerpc/platforms/52xx/efika.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c
b/arch/powerpc/platforms/52xx/efika.c
index 4514a6f7458a..3b7d70d71692 1006
Signed-off-by: Oliver O'Halloran
---
compile tested with 52xx/lite5200b_defconfig
---
arch/powerpc/platforms/52xx/lite5200.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/lite5200.c
b/arch/powerpc/platforms/52xx/lite5200.c
index 3181aac08225..0
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/52xx/media5200.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/media5200.c
b/arch/powerpc/platforms/52xx/media5200.c
index 07c5bc4ed0b5..efb8bdecbcc7 100644
--- a/arch/powerpc/platform
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/52xx/mpc5200_simple.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c
b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index 2d01e9b2e779..b9f5675b0a1d 100644
--- a/arch/p
Signed-off-by: Oliver O'Halloran
---
compile tested with pq2fads_defconfig
---
arch/powerpc/platforms/82xx/mpc8272_ads.c | 2 +-
arch/powerpc/platforms/82xx/pq2fads.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c
b/arch/powe
Signed-off-by: Oliver O'Halloran
---
compile tested with mpc83xx_defconfig
---
arch/powerpc/platforms/83xx/asp834x.c | 1 +
arch/powerpc/platforms/83xx/km83xx.c | 1 +
arch/powerpc/platforms/83xx/misc.c| 2 --
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 1 +
arch/powerpc/platform
Signed-off-by: Oliver O'Halloran
---
compile tested with amigaone_defconfig
---
arch/powerpc/platforms/amigaone/setup.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/amigaone/setup.c
b/arch/powerpc/platforms/amigaone/setup.c
index f5d0bf999
60 matches
Mail list logo
