Christophe Leroy's on June 7, 2019 4:56 pm:
>
>
> Le 07/06/2019 à 08:19, Nicholas Piggin a écrit :
>> powerpc/64s does not use ioremap_page_range, so it does not get huge
>> vmap iomap mappings automatically. The radix kernel mapping function
>> already allows larger page mappings that work with
https://bugzilla.kernel.org/show_bug.cgi?id=203839
--- Comment #3 from Christophe Leroy (christophe.le...@c-s.fr) ---
Could you try and revert the following commits ?
38b4564cf042 powerpc/32: don't do syscall stuff in transfer_to_handler
1a4b739bbb4f powerpc/32: implement fast entry for syscalls
Could you try and revert the following commits ?
38b4564cf042 powerpc/32: don't do syscall stuff in transfer_to_handler
1a4b739bbb4f powerpc/32: implement fast entry for syscalls on BOOKE
b86fb88855ea powerpc/32: implement fast entry for syscalls on non BOOKE
Thanks
Christophe
On 06/07/2019 12:
Very similar definitions for notify_page_fault() are being used by multiple
architectures duplicating much of the same code. This attempts to unify all
of them into a generic implementation, rename it as kprobe_page_fault() and
then move it to a common header.
kprobes_built_in() can detect CONFIG_
On Thu, Jun 06, 2019 at 04:01:05PM -0700, Nicolin Chen wrote:
> This reverts commit 8973112aa41b8ad956a5b47f2fe17bc2a5cf2645.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
> 1) Though ETDR and TX0~5 are not volatile b
Hi Anshuman,
On Fri, 7 Jun 2019 16:04:15 +0530 Anshuman Khandual
wrote:
>
> +static nokprobe_inline bool kprobe_page_fault(struct pt_regs *regs,
> + unsigned int trap)
> +{
> + int ret = 0;
> +
> + /*
> + * To be potentially processing a kp
On 6/7/19 1:48 AM, Madhavan Srinivasan wrote:
>
> On 06/06/19 11:06 PM, Claudio Carvalho wrote:
>> When the ultravisor firmware is available, it takes control over the
>> LDBAR register. In this case, thread-imc updates and save/restore
>> operations on the LDBAR register are handled by ultraviso
Nathan Lynch writes:
> During post-migration device tree updates, we can oops in
> pseries_update_drconf_memory if the source device tree has an
> ibm,dynamic-memory-v2 property and the destination has a
> ibm,dynamic_memory (v1) property. The notifier processes an "update"
> for the ibm,dynamic-
powerpc/pseries/svm: Unshare all pages before kexecing a new kernel.
A new kernel deserves a clean slate. Any pages shared with the
hypervisor is unshared before invoking the new kernel. However there are
exceptions. If the new kernel is invoked to dump the current kernel, or
if there is a ex
Michael Ellerman writes:
> Nathan Lynch writes:
>
>> During post-migration device tree updates, we can oops in
>> pseries_update_drconf_memory if the source device tree has an
>> ibm,dynamic-memory-v2 property and the destination has a
>> ibm,dynamic_memory (v1) property. The notifier processes
On 6/7/19 3:34 AM, Anshuman Khandual wrote:
> +static nokprobe_inline bool kprobe_page_fault(struct pt_regs *regs,
> + unsigned int trap)
> +{
> + int ret = 0;
> +
> + /*
> + * To be potentially processing a kprobe fault and to be allowed
> +
Le 07/06/2019 à 12:34, Anshuman Khandual a écrit :
Very similar definitions for notify_page_fault() are being used by multiple
architectures duplicating much of the same code. This attempts to unify all
of them into a generic implementation, rename it as kprobe_page_fault() and
then move it to
On 6/5/19 5:50 PM, Aaro Koskinen wrote:
Hi,
When upgrading from v5.0 -> v5.1 on G4 PowerBook, I noticed WLAN does
not work anymore:
[ 42.004303] b43legacy-phy0: Loading firmware version 0x127, patch level 14
(2005-04-18 02:36:27)
[ 42.184837] b43legacy-phy0 debug: Chip initialized
[ 42.1
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
you throw in a few printks what failed? I.e. did dma_direct_supported
return false? Did the actual allocation fail?
On 6/7/19 12:29 PM, Christoph Hellwig wrote:
I don't think we should work around this in the driver, we need to fix
it in the core. I'm curious why my previous patch didn't work. Can
you throw in a few printks what failed? I.e. did dma_direct_supported
return false? Did the actual allocation
Sphinx doesn't like orphan documents:
Documentation/accelerators/ocxl.rst: WARNING: document isn't included in
any toctree
Documentation/arm/stm32/overview.rst: WARNING: document isn't included in
any toctree
Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't
in
This document is used by multiple architectures:
$ echo $(git grep -l pkey_mprotect arch|cut -d'/' -f 2|sort|uniq)
alpha arm arm64 ia64 m68k microblaze mips parisc powerpc s390 sh sparc
x86 xtensa
So, let's move it to the core book and adjust the links to it
accordingly.
Signed
Before:
> @@ -46,23 +46,6 @@ kmmio_fault(struct pt_regs *regs, unsigned long addr)
> return 0;
> }
>
> -static nokprobe_inline int kprobes_fault(struct pt_regs *regs)
> -{
> - if (!kprobes_built_in())
> - return 0;
> - if (user_mode(regs))
> - return 0;
> -
On Thu, 2019-06-06 at 14:36 -0300, Claudio Carvalho wrote:
> From: Anshuman Khandual
>
> CONFIG_PPC_UV adds support for ultravisor.
>
> Signed-off-by: Anshuman Khandual
> Signed-off-by: Bharata B Rao
> Signed-off-by: Ram Pai
> [Update config help and commit message]
> Signed-off-by: Claudio
Check driver state before halting it during a reset. If the driver is
not running, do nothing. Otherwise, a request to deactivate a down link
can cause an error and the reset will fail.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 ++-
1 file changed, 2 insertions(+),
It was observed that multicast packets were no longer received after
a device reset. The fix is to resend the current multicast list to
the backing device after recovery.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/d
The return values for these memory allocations are unchecked,
which may cause an oops if the driver does not handle them after
a failure. Fix by checking the function's return code.
Signed-off-by: Thomas Falcon
---
drivers/net/ethernet/ibm/ibmvnic.c | 13 +++--
1 file changed, 7 insertio
This series contains three unrelated fixes to issues seen during
device resets. The first patch fixes an error when the driver requests
to deactivate the link of an uninitialized device, resulting in a
failure to reset. Next, a patch to fix multicast transmission
failures seen after a driver rese
Hello Mark,
On Fri, Jun 07, 2019 at 12:12:44PM +0100, Mark Brown wrote:
> On Thu, Jun 06, 2019 at 04:01:05PM -0700, Nicolin Chen wrote:
> > This reverts commit 8973112aa41b8ad956a5b47f2fe17bc2a5cf2645.
>
> Please use subject lines matching the style for the subsystem. This
> makes it easier for
On 06/06/2019 10:04 PM, Nathan Lynch wrote:
> During post-migration device tree updates, we can oops in
> pseries_update_drconf_memory if the source device tree has an
> ibm,dynamic-memory-v2 property and the destination has a
> ibm,dynamic_memory (v1) property. The notifier processes an "update"
>
Commit 8973112aa41b ("ASoC: fsl_esai: ETDR and TX0~5 registers are
non volatile") removed TX data registers from the volatile_reg list
and appended default values for them. However, being data registers
of TX, they should not have been removed from the list because they
should not be cached -- see
Tyrel Datwyler writes:
> On 06/06/2019 10:04 PM, Nathan Lynch wrote:
>> During post-migration device tree updates, we can oops in
>> pseries_update_drconf_memory if the source device tree has an
>> ibm,dynamic-memory-v2 property and the destination has a
>> ibm,dynamic_memory (v1) property. The n
> Please try the attached patch. I'm not really pleased with it and I will
> continue to determine why the fallback to a 30-bit mask fails, but at least
> this
> one works for me.
Your patch only makes sense if the device is indeed capable of
addressing 31-bits.
So either the driver is buggy
28 matches
Mail list logo