Hi Qian,
Qian Cai wrote:
OK, reverted the commit,
c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
RELOCATABLE”)
or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this
thread,
https://lore.kernel.org/lkml/15ac5b0e-a221-4b8c-9039-fa96b8ef7...@lca.pw/
>> > > On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote:
>> > > > +#define UIO_INFO_VER "devicetree,pseudo"
>> > >
>> > > What does this mean? Changing a number into a non-obvious string (Why
>> > > "pseudo"? Why does the UIO user care that the config came from the
>> > > device
>> > > tree
A driver for freescale 85xx platforms to access the Cache-Sram form
user level. This is extremely helpful for some user-space applications
that require high performance memory accesses.
Cc: Greg Kroah-Hartman
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlab
This series add a new uio driver for freescale 85xx platforms to
access the Cache-Sram form user level. This is extremely helpful
for the user-space applications that require high performance memory
accesses.
It fixes the compile errors and warning of the hardware level drivers
and implements the
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile error when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of
function ‘ioremap_
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram
This series is based on top of my previously posted series which reworks
how devices are added to their IOMMU groups. The two series are largely
orthogonal to each other, but they both touch pnv_pci_ioda_dma_dev_setup()
so there's a minor merge conflict if they aren't applied together. I can
fix th
For each PHB we maintain a reverse-map that can be used to find the
PE that a BDFN is currently mapped to. Add a helper for doing this
lookup so we can check if a PE has been configured without looking
at pdn->pe_number.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-iod
For normal PHBs IODA PEs are handled on a per-bus basis so all the devices
on that bus will share a PE. Which PE specificly is determined by the location
of the MMIO BARs for the devices on the bus so we can't actually configure the
bus PEs until after MMIO resources are allocated. As a result PEs
Doing it once during boot rather than doing it on the fly and drop the janky
populated logic.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/platforms/powernv/pci-ioda.c | 26 +-
arch/powerpc/platforms/powernv/pci.h | 1 -
2 files changed, 9 insertions(+), 18 del
pnv_pci_ioda_configure_bus() should now only ever be called when a device is
added to the bus so add a WARN_ON() to the empty bus check. Similarly,
pnv_pci_ioda_setup_bus_PE() should only ever be called for an unconfigured PE,
so add a WARN_ON() for that case too.
Signed-off-by: Oliver O'Halloran
On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
We try to keep the defconfig untouched after decoupling CONFIG_VHOST
out of CO
On Thu, Apr 16, 2020 at 11:58:29PM -0500, Scott Wood wrote:
> On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote:
> > > > On Thu, 2020-04-16 at 08:35 -0700, Wang Wenhu wrote:
> > > > > +#define UIO_INFO_VER "devicetree,pseudo"
> > > >
> > > > What does this mean? Changing a number into a non-obvious st
>A driver for freescale 85xx platforms to access the Cache-Sram form>user
>level. This is extremely helpful for some user-space applications
>that require high performance memory accesses.
>
>Cc: Greg Kroah-Hartman
>Cc: Christophe Leroy
>Cc: Scott Wood
>Cc: Michael Ellerman
>Cc: linuxppc-dev@l
On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote:
> And the fact they were exported leaves possibility that there is a
> driver somewhere relying on these symbols or distro kernel won't build
> because the symbol disappeared from exports (I do not know what KABI
> guarantees or
On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
> > > On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
> > > > On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote:
>
* Segher Boessenkool:
> On Thu, Apr 16, 2020 at 08:34:42PM -0400, Rich Felker wrote:
>> On Thu, Apr 16, 2020 at 06:02:35PM -0500, Segher Boessenkool wrote:
>> > On Thu, Apr 16, 2020 at 08:12:19PM +0200, Florian Weimer wrote:
>> > > > I think my choice would be just making the inline syscall be a s
On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
On 2020/4/17 上午6:55, Michael S. Tsirkin wrote:
On Wed, Apr 15, 2020 at 10:43:
On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
> > > On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
> > > > On Fri, Apr 17, 2020 at 11:12:14AM +0800, Jason Wang wrote:
>
On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
On 2020/4/17 下午2:33, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 11:12:
Power9 processor supports Virtual Accelerator Switchboard (VAS) which
allows kernel and userspace to send compression requests to Nest
Accelerator (NX) directly. The NX unit comprises of 2 842 compression
engines and 1 GZIP engine. Linux kernel already has 842 compression
support on kernel. This
On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
> > > On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
> > > > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
>
On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
> > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
> > > On 2020/4/17 下午4:29, Michael S. Tsirkin wrote:
> > > > On Fri, Apr 17, 2020 at 03:36:52PM +0800, Jason Wang wrote:
>
Initialize send and receive window attributes for GZIP high and
normal priority types.
Signed-off-by: Haren Myneni
---
arch/powerpc/platforms/powernv/vas-window.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/vas-window.c
Define the VAS_TX_WIN_OPEN ioctl interface for NX GZIP access
from user space. This interface is used to open GZIP send window and
mmap region which can be used by userspace to send requests to NX
directly with copy/paste instructions.
Signed-off-by: Haren Myneni
---
Documentation/userspace-ap
On power9, userspace can send GZIP compression requests directly to NX
once kernel establishes NX channel / window with VAS. This patch provides
user space API which allows user space to establish channel using open
VAS_TX_WIN_OPEN ioctl, mmap and close operations.
Each window corresponds to fil
coproc entry is initialized during NX probe on power9, but not on P8.
nx842_delete_coprocs() is used for both and frees receive window if it
is allocated. Getting crash for rmmod on P8 since coproc->vas.rxwin
is not initialized.
This patch replaces kmalloc with kzalloc in nx842_powernv_probe()
Rename nx-842-powernv.c to nx-common-powernv.c to add code for setup
and enable new GZIP compression type. The actual functionality is not
changed in this patch.
Signed-off-by: Haren Myneni
Acked-by: Herbert Xu
---
drivers/crypto/nx/Makefile|2 +-
drivers/crypto/nx/nx-842-powe
Make setup and enable code generic to support new GZIP compression type.
Changed nx842 reference to nx and moved some code to new functions.
Functionality is not changed except sparse warning fix - setting NULL
instead of 0 for per_cpu send window in nx_delete_coprocs().
Signed-off-by: Haren Myn
Changes to probe GZIP device-tree nodes, open RX windows and setup
GZIP compression type. No plans to provide GZIP usage in kernel right
now, but this patch enables GZIP for user space usage.
Signed-off-by: Haren Myneni
Acked-by: Herbert Xu
---
drivers/crypto/nx/nx-common-powernv.c | 46 +
When window is opened, pid reference is taken for user space
windows. Not needed for kernel windows. So remove 'pid' in
vas_tx_win_attr struct.
Signed-off-by: Haren Myneni
Acked-by: Herbert Xu
---
arch/powerpc/include/asm/vas.h| 1 -
drivers/crypto/nx/nx-common-powernv.c | 1 -
2 file
Power9 introduced Virtual Accelerator Switchboard (VAS) which allows
userspace to communicate with Nest Accelerator (NX) directly. But
kernel has to establish channel to NX for userspace. This document
describes user space API that application can use to establish
communication channel.
Signed-o
On Fri, 2020-04-17 at 09:42 +0200, Greg KH wrote:
> On Thu, Apr 16, 2020 at 11:58:29PM -0500, Scott Wood wrote:
> > On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote:
> > > Sounds it is. And does the modification below fit well?
> > > ---
> > > -static const struct of_device_id uio_mpc85xx_l2ctlr_of_mat
Returning from an interrupt or syscall to a signal handler currently begins
execution directly at the handler's entry point, with LR set to the address
of the sigreturn trampoline. When the signal handler function returns, it
runs the trampoline. It looks like this:
# interrupt at user address
Hi Michael,
On Fri, Apr 17, 2020 at 10:57 AM Michael S. Tsirkin wrote:
> On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote:
> > On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
> > > On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
> > > > On 2020/4/17 下午4:29, Michael S. Tsirkin
On 2020/4/17 下午5:25, Geert Uytterhoeven wrote:
Hi Michael,
On Fri, Apr 17, 2020 at 10:57 AM Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 04:51:19PM +0800, Jason Wang wrote:
On 2020/4/17 下午4:46, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 04:39:49PM +0800, Jason Wang wrote:
On 2
On 2020/4/17 下午5:01, Michael S. Tsirkin wrote:
There could be some misunderstanding here. I thought it's somehow similar: a
CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is
not set.
Thanks
BTW do entries with no prompt actually appear in defconfig?
Yes. I can see
On Fri, Apr 17, 2020 at 05:33:56PM +0800, Jason Wang wrote:
>
> On 2020/4/17 下午5:01, Michael S. Tsirkin wrote:
> > > There could be some misunderstanding here. I thought it's somehow
> > > similar: a
> > > CONFIG_VHOST_MENU=y will be left in the defconfigs even if CONFIG_VHOST is
> > > not set.
>
On 2020/4/17 下午5:38, Michael S. Tsirkin wrote:
On Fri, Apr 17, 2020 at 05:33:56PM +0800, Jason Wang wrote:
On 2020/4/17 下午5:01, Michael S. Tsirkin wrote:
There could be some misunderstanding here. I thought it's somehow similar: a
CONFIG_VHOST_MENU=y will be left in the defconfigs even if CON
Le 18/04/2019 à 08:51, Michael Ellerman a écrit :
Kernel Userspace Access Prevention utilises a feature of the Radix MMU
which disallows read and write access to userspace addresses. By
utilising this, the kernel is prevented from accessing user data from
outside of trusted paths that perform
Excerpts from Christophe Leroy's message of April 17, 2020 8:10 pm:
>
>
> Le 18/04/2019 à 08:51, Michael Ellerman a écrit :
>> Kernel Userspace Access Prevention utilises a feature of the Radix MMU
>> which disallows read and write access to userspace addresses. By
>> utilising this, the kernel i
Steven Rostedt writes:
> On Thu, 16 Apr 2020 21:19:10 -0400
> Qian Cai wrote:
>
>> OK, reverted the commit,
>>
>> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
>> RELOCATABLE”)
>>
>> or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this
>> thread,
"Naveen N. Rao" writes:
> Hi Qian,
>
> Qian Cai wrote:
>> OK, reverted the commit,
>>
>> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
>> RELOCATABLE”)
>>
>> or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this
>> thread,
>>
>> https://lore.kerne
> On Apr 16, 2020, at 10:46 PM, Russell Currey wrote:
>
> On Thu, 2020-04-16 at 22:40 -0400, Qian Cai wrote:
>>> On Apr 16, 2020, at 10:27 PM, Russell Currey
>>> wrote:
>>>
>>> Reverting the patch with the given config will have the same effect
>>> as
>>> STRICT_KERNEL_RWX=n. Not discountin
CONFIG_PPC_KUAP_DEBUG is not selectable because it depends on PPC_32
which doesn't exists.
Fixing it leads to a deadlock due to a vital register getting
clobbered in _switch().
Change dependency to PPC32 and use r0 instead of r4 in _switch()
Fixes: e2fb9f544431 ("powerpc/32: Prepare for Kernel U
If a task generates a KUAP fault, even from an acceptable
user access sequence, it is not a simple EFAULT.
Instead of emiting a warning, print a critical message and
kill the task with SIGSEGV.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/32/kup.h | 7 +--
arch
> On Apr 17, 2020, at 3:01 AM, Naveen N. Rao wrote:
>
> Hi Qian,
>
> Qian Cai wrote:
>> OK, reverted the commit,
>> c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
>> RELOCATABLE”)
>> or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this
>> thread
Le 17/04/2020 à 12:39, Nicholas Piggin a écrit :
Excerpts from Christophe Leroy's message of April 17, 2020 8:10 pm:
Le 18/04/2019 à 08:51, Michael Ellerman a écrit :
Kernel Userspace Access Prevention utilises a feature of the Radix MMU
which disallows read and write access to userspace a
> On Apr 2, 2020, at 7:24 AM, Michael Ellerman wrote:
>
> Qian Cai writes:
>> From: Peter Zijlstra
>>
>> In the CPU-offline process, it calls mmdrop() after idle entry and the
>> subsequent call to cpuhp_report_idle_dead(). Once execution passes the
>> call to rcu_report_dead(), RCU is igno
On Wed, Apr 15, 2020 at 10:20:11AM +0200, Arnd Bergmann wrote:
> > I'd rather keep it out of this series and to
> > an interested party. Then again x32 doesn't seem to have a whole lot
> > of interested parties..
>
> Fine with me. It's on my mental list of things that we want to kill off
> eve
>On Fri, 2020-04-17 at 09:42 +0200, Greg KH wrote:>> On Thu, Apr 16, 2020 at
>11:58:29PM -0500, Scott Wood wrote:
>> > On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote:
>> > > Sounds it is. And does the modification below fit well?
>> > > ---
>> > > -static const struct of_device_id uio_mpc85xx_l2ctlr
On Wed, Apr 8, 2020 at 10:24 PM Russell King - ARM Linux admin
wrote:
> On Wed, Apr 08, 2020 at 08:58:16PM +0200, Arnd Bergmann wrote:
> > - int i;
> > - struct qbman_eq_desc ed[32];
> > + struct qbman_eq_desc *ed = kcalloc(sizeof(struct qbman_eq_desc), 32,
> > GFP_KERNEL);
>
> I thin
Qian Cai wrote:
On Apr 17, 2020, at 3:01 AM, Naveen N. Rao wrote:
Hi Qian,
Qian Cai wrote:
OK, reverted the commit,
c55d7b5e6426 (“powerpc: Remove STRICT_KERNEL_RWX incompatibility with
RELOCATABLE”)
or set STRICT_KERNEL_RWX=n fixed the crash below and also mentioned in this
thread,
http
https://bugzilla.kernel.org/show_bug.cgi?id=206203
--- Comment #11 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 288565
--> https://bugzilla.kernel.org/attachment.cgi?id=288565&action=edit
kmemleak output (kernel 5.7-rc1, PowerMac G5 11,2)
Applied Frank's patch set on top of 5.7-
https://bugzilla.kernel.org/show_bug.cgi?id=206203
--- Comment #12 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 288567
--> https://bugzilla.kernel.org/attachment.cgi?id=288567&action=edit
dmesg (kernel 5.7-rc1, PowerMac G5 11,2)
--
You are receiving this mail because:
You are w
unsafe_put_user() is designed to take benefit of 'asm goto'.
Instead of using the standard __put_user() approach and branch
based on the returned error, use 'asm goto' and make the
exception code branch directly to the error label. There is
no code anymore in the fixup section.
This change signif
At the time being, unsafe_copy_to_user() is based on
raw_copy_to_user() which calls __copy_tofrom_user().
__copy_tofrom_user() is a big optimised function to copy big amount
of data. It aligns destinations to cache line in order to use
dcbz instruction.
Today unsafe_copy_to_user() is called only
On 4/17/20 6:53 PM, Michal Suchánek wrote:
> Hello,
Hi, thanks for reproducing on latest upstream!
> instrumenting the kernel with the following patch
>
> ---
> mm/slub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index d6787bbe0248..d40995d5f8ff 100644
>
Implements a new uio driver for freescale 85xx platforms to access
the Cache-Sram form user level. It is extremely helpful for the user
space applications that require high performance memory accesses.
Cc: Greg Kroah-Hartman
Cc: Christophe Leroy
Cc: Scott Wood
Cc: Michael Ellerman
Cc: linuxppc
On 4/17/20 10:21 AM, Wang Wenhu wrote:
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81cfc2b..f6e6ec0089c0 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -105,6 +105,14 @@ config UIO_NETX
> To compile this driver as a module, choose M here; the m
Christoph Hellwig writes:
> On Wed, Apr 15, 2020 at 10:20:11AM +0200, Arnd Bergmann wrote:
>> > I'd rather keep it out of this series and to
>> > an interested party. Then again x32 doesn't seem to have a whole lot
>> > of interested parties..
>>
>> Fine with me. It's on my mental list of thing
Now that architectures provide arch_hugetlb_valid_size(), parsing
of "hugepagesz=" can be done in architecture independent code.
Create a single routine to handle hugepagesz= parsing and remove
all arch specific routines. We can also remove the interface
hugetlb_bad_size() as this is no longer use
The routine hugetlb_add_hstate prints a warning if the hstate already
exists. This was originally done as part of kernel command line
parsing. If 'hugepagesz=' was specified more than once, the warning
pr_warn("hugepagesz= specified twice, ignoring\n");
would be printed.
Some architectur
The architecture independent routine hugetlb_default_setup sets up
the default huge pages size. It has no way to verify if the passed
value is valid, so it accepts it and attempts to validate at a later
time. This requires undocumented cooperation between the arch specific
and arch independent co
With all hugetlb page processing done in a single file clean up code.
- Make code match desired semantics
- Update documentation with semantics
- Make all warnings and errors messages start with 'HugeTLB:'.
- Consistently name command line parsing routines.
- Check for hugepages_supported() befor
v3 -
Used weak attribute method of defining arch_hugetlb_valid_size.
This eliminates changes to arch specific hugetlb.h files (Peter)
Updated documentation (Peter, Randy)
Fixed handling of implicitly specified gigantic page preallocation
in existing code and removed documentation
On Fri, Apr 17, 2020 at 8:13 PM Eric W. Biederman wrote:
>
> Christoph Hellwig writes:
>
> > On Wed, Apr 15, 2020 at 10:20:11AM +0200, Arnd Bergmann wrote:
> >> > I'd rather keep it out of this series and to
> >> > an interested party. Then again x32 doesn't seem to have a whole lot
> >> > of in
Christoph Hellwig writes:
> Instead of an architecture specific calling convention in common code
> just pass a flags argument with architecture specific values.
This bothers me because it makes all architectures pay for the sins of
x32. Further it starts burying the details of the what is happ
To remove the use of set_fs in the coredump code there needs to be a
way to convert a kernel siginfo to a userspace compat siginfo.
Call that function copy_siginfo_to_compat and factor it out of
copy_siginfo_to_user32.
The existence of x32 complicates this code. On x32 SIGCHLD uses 64bit
times
The code in binfmt_elf.c is differnt from the rest of the code that
processes siginfo, as it sends siginfo from a kernel buffer to a file
rather than from kernel memory to userspace buffers. To remove it's
use of set_fs the code needs some different siginfo helpers.
Add the helper copy_siginfo_
Christoph Hellwig writes:
> Hi all,
>
> this series gets rid of playing with the address limit in the exec and
> coredump code. Most of this was fairly trivial, the biggest changes are
> those to the spufs coredump code.
>
> Changes since v1:
> - properly spell NUL
> - properly handle the comp
On Fri, 2020-04-17 at 22:16 +0800, 王文虎 wrote:
> > On Fri, 2020-04-17 at 09:42 +0200, Greg KH wrote:>> On Thu, Apr 16, 2020
> > at 11:58:29PM -0500, Scott Wood wrote:
> > > > On Fri, 2020-04-17 at 10:31 +0800, 王文虎 wrote:
> > > > > Sounds it is. And does the modification below fit well?
> > > > > ---
On Fri, 2020-04-17 at 10:21 -0700, Wang Wenhu wrote:
> Implements a new uio driver for freescale 85xx platforms to access
> the Cache-Sram form user level. It is extremely helpful for the user
> space applications that require high performance memory accesses.
>
> Cc: Greg Kroah-Hartman
> Cc: Chr
On Fri, Apr 17, 2020 at 07:17:47PM +1000, Nicholas Piggin wrote:
> I don't know much about dwarf, gdb still seems to recognize the signal
> frame and unwind properly if I break inside a signal handler.
Yes, the dwarf unwind info still looks good. The commented out dwarf
near the end of sigtramp.S
On 4/16/20 9:07 PM, Oliver O'Halloran wrote:
> The vio and ibmebus buses are used for pseries specific paravirtualised
> devices and currently they're initialised by the generic initcall types.
> This is mostly fine, but it can result in some nuisance errors in dmesg
> when booting on PowerNV on so
76 matches
Mail list logo
