On Sun, 2020-04-19 at 20:05 -0700, Wang Wenhu wrote:
> +static void sram_uapi_res_insert(struct sram_uapi *uapi,
> + struct sram_resource *res)
> +{
> + struct sram_resource *cur, *tmp;
> + struct list_head *head = &uapi->res_list;
> +
> + list_for_each_entr
On Tue, Apr 21, 2020 at 8:56 AM Christophe Leroy
wrote:
> Le 20/04/2020 à 21:57, Arnd Bergmann a écrit :
>
> Yes that was one of the objective, be able to add that as a second step.
> First objective was adding the missing clocks and increasing
> maintainability.
>
> I can add a patch for that now
Hi Oliver,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on scottwood/next v5.7-rc2 next-20200420]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base'
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 some OSes, e.g.
[2.984439] synth uevent: /devices/
The driver has to be manually loaded if it is built as a module. It
is neither exporting MODULE_DEVICE_TABLE nor MODULE_ALIAS. Moreover,
no platform-device is created (and thus no uevent is sent) for the
clockgen nodes it depends on.
Convert the module to a platform driver with its own alias. More
Add a platform device for qoirq-cpufreq driver for the compatible
clockgen blocks.
Reviewed-by: Yuantian Tang
Acked-by: Viresh Kumar
Signed-off-by: Mian Yousaf Kaukab
---
v2:
+Rafael, Stephen, linux-clk
Add Reviewed-by and Acked-by tags
drivers/clk/clk-qoriq.c | 30 +
Hi
[adding some drivers/char/random folks + LKML to CC]
Vlastimil Babka writes:
> 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 i
On Tue, Apr 21, 2020 at 11:31:14AM +0800, Baoquan He wrote:
> On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The early_pfn_to_nid() and it's helper __early_pfn_to_nid() are spread
> > around include/linux/mm.h, include/linux/mmzone.h and mm/page_alloc.c.
> >
> > Dro
Use dev_dbg instead of dev_err in irq handler, the dev_err
is expensive, we don't need the message to be printed everytime,
which is almost a debug option.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_esai.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/
On Tue, Apr 21, 2020 at 10:24:35AM +0800, Baoquan He wrote:
> On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The early_pfn_to_nid() and it's helper __early_pfn_to_nid() are spread
> > around include/linux/mm.h, include/linux/mmzone.h and mm/page_alloc.c.
> >
> > Dro
On Tue, Apr 21, 2020 at 12:23:16PM +0800, Baoquan He wrote:
> On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The CONFIG_HAVE_MEMBLOCK_NODE_MAP is used to differentiate initialization
> > of nodes and zones structures between the systems that have region to node
> > m
Hi, Greg, Arnd,
Thank you for your comments first, and then really very very very sorry
for driving Greg to sigh and I hope there would be chance to share Moutai
(rather than whisky, we drink it much, a kind of Baijiu), after the virus.
Back to the comments, I'd like to do a bit of documentation
On Tue, Apr 21, 2020 at 03:49:19AM +0100, Al Viro wrote:
> The only source I'd been able to find speeks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in q
On 04/21/20 at 11:49am, Mike Rapoport wrote:
> On Tue, Apr 21, 2020 at 10:24:35AM +0800, Baoquan He wrote:
> > On 04/12/20 at 10:48pm, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > The early_pfn_to_nid() and it's helper __early_pfn_to_nid() are spread
> > > around include/linux/mm.h,
On Tue, Apr 21, 2020 at 05:09:47PM +0800, 王文虎 wrote:
> Hi, Greg, Arnd,
>
> Thank you for your comments first, and then really very very very sorry
> for driving Greg to sigh and I hope there would be chance to share Moutai
> (rather than whisky, we drink it much, a kind of Baijiu), after the virus
On Wed, Apr 15, 2020 at 06:49:14PM +0530, Aishwarya R wrote:
> >> Use of_property_read_u32 to read the "reg" and "i2c-address" property
> >> instead of using of_get_property to check the return values.
> >>
> >> Signed-off-by: Aishwarya R
>
> > This is quite a fragile driver. Have you tested it o
On 04/21/20 at 12:09pm, Mike Rapoport wrote:
> > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > > index fc0aad0bc1f5..e67dc501576a 100644
> > > --- a/mm/memory_hotplug.c
> > > +++ b/mm/memory_hotplug.c
> > > @@ -1372,11 +1372,7 @@ check_pages_isolated_cb(unsigned long start_pfn,
> >
On Tue, Apr 21, 2020 at 04:41:23PM +0800, Shengjiu Wang wrote:
> Use dev_dbg instead of dev_err in irq handler, the dev_err
> is expensive, we don't need the message to be printed everytime,
> which is almost a debug option.
> if (esr & ESAI_ESR_RFF_MASK)
> - dev_warn(&pdev->dev,
* Szabolcs Nagy:
> * Nicholas Piggin [2020-04-20 12:08:36 +1000]:
>> Excerpts from Rich Felker's message of April 20, 2020 11:29 am:
>> > Also, allowing patching of executable pages is generally frowned upon
>> > these days because W^X is a desirable hardening property.
>>
>> Right, it would wan
>On Tue, Apr 21, 2020 at 05:09:47PM +0800, 王文虎 wrote:
>> Hi, Greg, Arnd,
>>
>> Thank you for your comments first, and then really very very very sorry
>> for driving Greg to sigh and I hope there would be chance to share Moutai
>> (rather than whisky, we drink it much, a kind of Baijiu), after the
Hi
On Tue, Apr 21, 2020 at 5:53 PM Mark Brown wrote:
>
> On Tue, Apr 21, 2020 at 04:41:23PM +0800, Shengjiu Wang wrote:
> > Use dev_dbg instead of dev_err in irq handler, the dev_err
> > is expensive, we don't need the message to be printed everytime,
> > which is almost a debug option.
>
> >
Le 18/04/2020 à 16:40, Sasha Levin a écrit :
From: Frederic Barrat
[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
This shouldn't be backported to stable.
Fred
The pci_dn structure used to store a pointer to the struct pci_dev, so
taking a reference on the device was re
Le 18/04/2020 à 16:40, Sasha Levin a écrit :
From: Frederic Barrat
[ Upstream commit 658ab186dd22060408d94f5c5a6d02d809baba44 ]
This doesn't need to be backported to stable.
Fred
On powernv, when removing a device through hotplug, the following
warning is logged:
Invalid refc
Le 18/04/2020 à 16:40, Sasha Levin a écrit :
From: Frederic Barrat
[ Upstream commit 49ce94b8677c7d7a15c4d7cbbb9ff1cd8387827b ]
This shouldn't be backported to stable.
Fred
The PCI hotplug framework is used to update the devices when a new
image is written to the FPGA.
Reviewed-by:
Le 18/04/2020 à 16:42, Sasha Levin a écrit :
From: Frederic Barrat
[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
Like for kernel 5.4, the patches 41, 42, 43 of this series are not
desirable for stable.
Fred
The pci_dn structure used to store a pointer to the struct p
Le 18/04/2020 à 16:09, Sasha Levin a écrit :
From: Frederic Barrat
[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
Like for other stable kernels, patches 71, 72, 73 of this series are not
desirable for stable.
Fred
The pci_dn structure used to store a pointer to the st
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index 39eec9031487..a62795079d9c 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -19,6 +19,7 @@ config CXL
select CXL_BASE
select CXL_AFU_DRIVER_OPS
select CXL_LIB
+ select SI
On 4/21/20 1:19 PM, Frederic Barrat wrote:
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index 39eec9031487..a62795079d9c 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -19,6 +19,7 @@ config CXL
select CXL_BASE
select CXL_AFU_DRIVER_OP
Michal Suchánek writes:
> On Mon, Apr 20, 2020 at 08:50:30AM +0200, Michal Suchánek wrote:
>> On Mon, Apr 20, 2020 at 04:15:39PM +1000, Michael Ellerman wrote:
>> > Michal Suchánek writes:
> ...
>> >
>> >
>> > And I've just hit it with your config on a machine here, but the crash
>> > is differ
On Tue, Apr 21, 2020 at 10:21:52PM +1000, Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, Apr 20, 2020 at 08:50:30AM +0200, Michal Suchánek wrote:
> >> On Mon, Apr 20, 2020 at 04:15:39PM +1000, Michael Ellerman wrote:
> >> > Michal Suchánek writes:
> > ...
> >> >
> >> >
> >> > And
Segher Boessenkool writes:
> Hi!
>
> On Fri, Apr 03, 2020 at 03:10:54PM +1100, Alistair Popple wrote:
>> +#define PCR_ARCH_300 0x10/* Architecture 3.00 */
>
> It's called 3.0, not 3.00?
It should actually be 3.0B shouldn't it?
cheers
>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>> pass the efi, it won't get the SRAT table correctly, if I remember
>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>> ACPI only, this won't happen on bare metal though. Need check carefully.
>>
"Gautham R. Shenoy" writes:
> This is the fifth version of the patches to track and expose idle PURR
> and SPURR ticks. These patches are required by tools such as lparstat
> to compute system utilization for capacity planning purposes.
>
> The previous versions can be found here:
> v4: https://lk
Hi Laurent,
Laurent Dufour writes:
> The newly introduced ibm,secure-memory nodes supersede the
> ibm,uv-firmware's property secure-memory-ranges.
Is either documented in a device tree binding document anywhere?
cheers
> Firmware will no more expose the secure-memory-ranges property so first
>
On Tue, Apr 21, 2020 at 11:37 PM Michael Ellerman wrote:
>
> Hi Laurent,
>
> Laurent Dufour writes:
> > The newly introduced ibm,secure-memory nodes supersede the
> > ibm,uv-firmware's property secure-memory-ranges.
>
> Is either documented in a device tree binding document anywhere?
>
> cheers
>
libfs.c has many functions that are useful to implement dentry and inode
operations, but not many at the filesystem level. As a result, code to
create files and inodes has a lot of duplication, to the point that
tracefs has copied several hundred lines from debugfs.
The main two libfs.c functions
aa_mk_null_file is using simple_pin_fs/simple_release_fs with local
variables as arguments, for what would amount to a simple
vfs_kern_mount/mntput pair if everything was inlined. Just use
the normal filesystem API since the reference counting is not needed
here (it is a local variable and always
Simplify passing the count and mount to simple_pin_fs and
simple_release_fs by wrapping them in the simple_fs struct,
in preparation for adding more high level operations to
fs/libfs.c
There is no functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
---
drivers/gpu/drm/drm_drv.
On Fri, Apr 17, 2020 at 09:26:56AM -0400, Qian Cai wrote:
> > Acked-by: Michael Ellerman (powerpc)
>
> Peter, can you take a look at this patch when you have a chance?
Sorry, -ETOOMUCHEMAIL, got it now, thanks!
On 21.04.20 15:29, David Hildenbrand wrote:
>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>>> pass the efi, it won't get the SRAT table correctly, if I remember
>>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>>> ACPI only, this won't happen
It is a common special case for new_inode to initialize the
time to the current time and the inode to get_next_ino().
Introduce a core function that does it.
Signed-off-by: Emanuele Giuseppe Esposito
---
fs/libfs.c | 20
include/linux/fs.h | 1 +
2 files changed, 21
libfs.c has many functions that are useful to implement dentry and inode
operations, but not many at the filesystem level. Start adding file
creation wrappers, the simplest returns an anonymous inode.
There is no functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
---
drivers/
A bunch of code is duplicated between debugfs and tracefs, unify it to the
libfs library.
The code is very similar, except that dentry and inode creation are unified
into a single function (unlike start_creating in debugfs and tracefs, which
only takes care of dentries). This adds an output param
The only difference, compared to the pre-existing code, is that symlink
creation now triggers fsnotify_create. This was a bug in the debugfs
code, since for example vfs_symlink does call fsnotify_create.
Signed-off-by: Emanuele Giuseppe Esposito
---
fs/debugfs/inode.c | 144 +---
There is no semantic change intended; the code in the libfs.c
functions in fact was derived from debugfs and tracefs code.
Signed-off-by: Emanuele Giuseppe Esposito
---
fs/tracefs/inode.c | 86 --
1 file changed, 7 insertions(+), 79 deletions(-)
diff
On Fri, 17 Apr 2020 11:50:45 -0700
Mike Kravetz wrote:
> 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
David Hildenbrand writes:
>>> ACPI SRAT is embeded into efi, need read out the rsdp pointer. If we don't
>>> pass the efi, it won't get the SRAT table correctly, if I remember
>>> correctly. Yeah, I remeber kvm guest can get memory hotplugged with
>>> ACPI only, this won't happen on bare metal th
On Thu, 2020-04-16 at 05:58:40 UTC, Haren Myneni wrote:
>
> This function allocates IRQ on a specific chip. VAS needs per chip
> IRQ allocation and will have IRQ handler per VAS instance.
>
> Signed-off-by: Haren Myneni
> Reviewed-by: Cédric Le Goater
Series applied to powerpc next, thanks.
On Fri, 2020-04-17 at 09:00:29 UTC, Haren Myneni wrote:
>
> Initialize send and receive window attributes for GZIP high and
> normal priority types.
>
> Signed-off-by: Haren Myneni
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a8c0c69b5e95e8f155480d5203a7bafb8024fd93
On Mon, 2020-04-20 at 20:55:34 UTC, Raphael Moreira Zinsly wrote:
> Add files to access the powerpc NX-GZIP engine in user space.
>
> Signed-off-by: Bulent Abali
> Signed-off-by: Raphael Moreira Zinsly
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d53979b589609d87036
>> b) "kexec -s -l" seems to work fine. For now, the kernel does not seem
>> to get placed on virtio-mem memory (pure luck due to the left-to-right
>> search). Memory added by virtio-mem is not getting added to the e820
>> map. Once the virtio-mem driver comes back up in the kexec kernel, the
>>
On Tue, Apr 21, 2020 at 12:28:25PM +, David Laight wrote:
> From: Nicholas Piggin
> > Sent: 20 April 2020 02:10
> ...
> > >> Yes, but does it really matter to optimize this specific usage case
> > >> for size? glibc, for instance, tries to leverage the syscall mechanism
> > >> by adding some co
On 21/04/2020 11:39, Rich Felker wrote:
> On Tue, Apr 21, 2020 at 12:28:25PM +, David Laight wrote:
>> From: Nicholas Piggin
>>> Sent: 20 April 2020 02:10
>> ...
> Yes, but does it really matter to optimize this specific usage case
> for size? glibc, for instance, tries to leverage t
From: Adhemerval Zanella
> Sent: 21 April 2020 16:01
>
> On 21/04/2020 11:39, Rich Felker wrote:
> > On Tue, Apr 21, 2020 at 12:28:25PM +, David Laight wrote:
> >> From: Nicholas Piggin
> >>> Sent: 20 April 2020 02:10
> >> ...
> > Yes, but does it really matter to optimize this specific us
Replace the coredump ->read method with a ->dump method that must call
dump_emit itself. That way we avoid a buffer allocation an messing with
set_fs() to call into code that is intended to deal with user buffers.
For the ->get case we can now use a small on-stack buffer and avoid
memory allocatio
From: "Eric W. Biederman"
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 x3
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 v2:
- don't cleanup the compat siginfo calling conventions, use the patch
variant from Eric w
From: "Eric W. Biederman"
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.
Ad
There is no logic in elf_core_dump itself, or in the various arch helpers
called from it which use uaccess routines on kernel pointers except for
the file writes thate are nicely encapsulated by using __kernel_write in
dump_emit.
Signed-off-by: Christoph Hellwig
---
fs/binfmt_elf.c | 40
There is no logic in elf_fdpic_core_dump itself, or in the various arch
helpers called from it which use uaccess routines on kernel pointers
except for the file writes thate are nicely encapsulated by using
__kernel_write in dump_emit.
Signed-off-by: Christoph Hellwig
---
fs/binfmt_elf_fdpic.c |
copy_strings_kernel is always used with a single argument,
adjust the calling convention to that.
Signed-off-by: Christoph Hellwig
---
fs/binfmt_em86.c| 6 +++---
fs/binfmt_misc.c| 4 ++--
fs/binfmt_script.c | 6 +++---
fs/exec.c | 13 ++---
include/
Currently copy_string_kernel is just a wrapper around copy_strings that
simplifies the calling conventions and uses set_fs to allow passing a
kernel pointer. But due to the fact the we only need to handle a single
kernel argument pointer, the logic can be sigificantly simplified while
getting rid
Hi!
On Tue, Apr 21, 2020 at 01:04:05AM +, Joel Stanley wrote:
> On Mon, 20 Apr 2020 at 18:38, Christophe Leroy
> wrote:
> > _ALIGN_DOWN() is specific to powerpc
> > ALIGN_DOWN() is generic and does the same
> >
> > Replace _ALIGN_DOWN() by ALIGN_DOWN()
>
> This one is a bit less obvious. It
From: Nicholas Piggin
> Sent: 20 April 2020 02:10
...
> >> Yes, but does it really matter to optimize this specific usage case
> >> for size? glibc, for instance, tries to leverage the syscall mechanism
> >> by adding some complex pre-processor asm directives. It optimizes
> >> the syscall code si
This patch series convert the remaining files under Documentation/filesystems
to the ReST file format (except for dax.txt and patch-lookup.txt).
It is based on linux-next (next-2020021).
PS.: I opted to add mainly ML from the output of get_maintainers.pl to the c/c
list of patch 00/34, because
This file is at groff output format. Manually convert it to
ReST format, trying to preserve a similar output after parsed.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/filesystems/spufs/index.rst | 1 +
.../spufs/{spufs.txt => spufs.rst}| 59 +--
MAINTA
This series addresses the crash reported by Qian Cai on ppc64le with
-mprofile-kernel here:
https://lore.kernel.org/r/15ac5b0e-a221-4b8c-9039-fa96b8ef7...@lca.pw
While fixing patch_instruction() should address the crash, we should
still change the default stub we setup for _mcount() for cases wh
module_trampoline_target() is only used by ftrace. Move the prototype
within the appropriate #ifdef in the header. Also, move the function
body to the end of module_64.c so as to consolidate all ftrace code in
one place.
No functional changes.
Signed-off-by: Naveen N. Rao
---
arch/powerpc/inclu
For -mprofile-kernel, we need special handling when generating stubs for
ftrace calls such as _mcount(). To faciliate this, we check if a
R_PPC64_REL24 relocation is for a symbol named "_mcount()" along with
also checking the instruction sequence. The latter is not really
required since "_mcount()"
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x0
Le 21/04/2020 à 15:43, Oliver O'Halloran a écrit :
On Tue, Apr 21, 2020 at 11:37 PM Michael Ellerman wrote:
Hi Laurent,
Laurent Dufour writes:
The newly introduced ibm,secure-memory nodes supersede the
ibm,uv-firmware's property secure-memory-ranges.
Is either documented in a device tree
Hi,
On Tue, Apr 21, 2020 at 11:58:31AM +1000, Oliver O'Halloran wrote:
> On Tue, Apr 21, 2020 at 11:53 AM Alistair Popple
> wrote:
> >
> > On Tuesday, 21 April 2020 11:30:52 AM AEST Alistair Popple wrote:
> > > On Saturday, 4 April 2020 2:32:08 AM AEST Segher Boessenkool wrote:
> > > > Hi!
> > >
On Tue, 14 Apr 2020 14:56:00 +0800, Shengjiu Wang wrote:
> Add new module driver for new ASRC in i.MX8MN, several commits
> are added for new property fsl,asrc-format
>
> Shengjiu Wang (7):
> ASoC: fsl_asrc: rename asrc_priv to asrc
> ASoC: dt-bindings: fsl_asrc: Add new property fsl,asrc-form
On Thu, 16 Apr 2020 20:25:30 +0800, Shengjiu Wang wrote:
> Add new module driver for new ASRC in i.MX8MN, several commits
> are added for new property fsl,asrc-format
>
> Shengjiu Wang (7):
> ASoC: fsl_asrc: rename asrc_priv to asrc
> ASoC: dt-bindings: fsl_asrc: Add new property fsl,asrc-form
On Mon, Apr 20, 2020 at 7:49 PM Al Viro wrote:
>
> The only source I'd been able to find speaks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in questi
On Tue, Apr 21, 2020 at 05:41:58PM +0200, Christoph Hellwig wrote:
> static ssize_t spufs_proxydma_info_read(struct file *file, char __user *buf,
> size_t len, loff_t *pos)
> {
> struct spu_context *ctx = file->private_data;
> + struct spu_proxydma_info
On Tue, Apr 21, 2020 at 07:49:41PM +0100, Al Viro wrote:
> > spin_lock(&ctx->csa.register_lock);
> > - ret = __spufs_proxydma_info_read(ctx, buf, len, pos);
> > + __spufs_proxydma_info_read(ctx, &info);
> > + ret = simple_read_from_buffer(buf, len, pos, &info, sizeof(info));
>
> IDGI...
On Tue, Apr 21, 2020 at 09:01:48PM +0200, Christoph Hellwig wrote:
> On Tue, Apr 21, 2020 at 07:49:41PM +0100, Al Viro wrote:
> > > spin_lock(&ctx->csa.register_lock);
> > > - ret = __spufs_proxydma_info_read(ctx, buf, len, pos);
> > > + __spufs_proxydma_info_read(ctx, &info);
> > > + ret = simpl
On Tue, Apr 21, 2020 at 08:19:09PM +0100, Al Viro wrote:
> On Tue, Apr 21, 2020 at 09:01:48PM +0200, Christoph Hellwig wrote:
> > On Tue, Apr 21, 2020 at 07:49:41PM +0100, Al Viro wrote:
> > > > spin_lock(&ctx->csa.register_lock);
> > > > - ret = __spufs_proxydma_info_read(ctx, buf, l
Sam Bobroff writes:
> If a device is hot unplgged during EEH recovery, it's possible for the
> RTAS call to ibm,configure-pe in pseries_eeh_configure() to return
> parameter error (-3), however negative return values are not checked
> for and this leads to an infinite loop.
>
> Fix this by correct
This series renames pmd_mknotpresent() as pmd_mkinvalid(). Before that it
drops an existing pmd_mknotpresent() definition from powerpc platform which
was never required as it defines it's pmdp_invalidate() through subscribing
__HAVE_ARCH_PMDP_INVALIDATE. This does not create any functional change.
Platform needs to define pmd_mknotpresent() for generic pmdp_invalidate()
only when __HAVE_ARCH_PMDP_INVALIDATE is not subscribed. Otherwise platform
specific pmd_mknotpresent() is not required. Hence just drop it.
Cc: Benjamin Herrenschmidt
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: linuxppc-
On Tue, Apr 21, 2020 at 06:33:36PM -0500, Nathan Lynch wrote:
> Sam Bobroff writes:
> > If a device is hot unplgged during EEH recovery, it's possible for the
> > RTAS call to ibm,configure-pe in pseries_eeh_configure() to return
> > parameter error (-3), however negative return values are not che
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from :32:
./usr/include/asm/vas-api.h:15:2: error: unknown type name '__u32'
15 | __u32 version;
| ^
./usr/include/asm/vas-api.h:16:2: error: unknown type name
Excerpts from Rich Felker's message of April 21, 2020 3:27 am:
> On Mon, Apr 20, 2020 at 02:31:58PM +1000, Nicholas Piggin wrote:
>> Excerpts from Rich Felker's message of April 20, 2020 2:09 pm:
>> > On Mon, Apr 20, 2020 at 12:32:21PM +1000, Nicholas Piggin wrote:
>> >> Excerpts from Rich Felker's
Excerpts from Nicholas Piggin's message of April 22, 2020 4:18 pm:
> If we go further and try to preserve r3 as well by putting the return
> value in r9 or r0, we go backwards about 300 bytes. It's good for the
> lock loops and complex functions, but hurts a lot of simpler functions
> that have
Stephen, Sorry missed it. Thanks for fixing it.
Acked-by: Haren Myneni
On 4/21/20 10:41 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from :32:
> ./usr/include/asm/vas-api.h:15:
Hi all,
After merging the akpm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/powernv/vas-fault.c: In function 'update_csb':
arch/powerpc/platforms/powernv/vas-fault.c:130:2: error: implicit declaration
of function 'use_mm' [-Werror=implicit-fun
On 21/04/2020 16:35, Oliver O'Halloran wrote:
> On Tue, Apr 21, 2020 at 3:11 PM Alexey Kardashevskiy wrote:
>>
>> One example of a problem device is AMD GPU with 64bit video PCI function
>> and 32bit audio, no?
>>
>> What PEs will they get assigned to now? Where will audio's MMIO go? It
>> cann
Let me try to summarise what we have.
- vdso style call is ruled out as unnecessary with possible security
concerns. Caller can internally use indirect branch to select variant
if it wants to use that mechanism to select.
- LR clobber seems to handled okay by gcc. It can increase size of sm
90 matches
Mail list logo
