Al,
>> I don't have anything queued for 5.8 for hpsa so there shouldn't be any
>> conflicts if it goes through vfs.git. But I'm perfectly happy to take
>> the changes through SCSI if that's your preference.
>
> Up to you; if you need a pull request, just say so.
OK, I queued these up for 5.8.
On Wed, Jun 03, 2020 at 04:53:11PM -0400, Martin K. Petersen wrote:
>
> Hi Al!
>
> > OK... Acked-by/Tested-by added, branch re-pushed (commits are otherwise
> > identical). Which tree would you prefer that to go through - vfs.git,
> > scsi.git, something else?
>
> I don't have anything queued
Hi Al!
> OK... Acked-by/Tested-by added, branch re-pushed (commits are otherwise
> identical). Which tree would you prefer that to go through - vfs.git,
> scsi.git, something else?
I don't have anything queued for 5.8 for hpsa so there shouldn't be any
conflicts if it goes through vfs.git. Bu
On Wed, Jun 03, 2020 at 06:37:11PM +, don.br...@microchip.com wrote:
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org
> [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Al Viro
> Sent: Friday, May 29, 2020 6:39 PM
> To: Linus Torvalds
> Cc: linux-kernel@vger.kernel.
-Original Message-
From: linux-scsi-ow...@vger.kernel.org
[mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Al Viro
Sent: Friday, May 29, 2020 6:39 PM
To: Linus Torvalds
Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; Don Brace
; linux-s...@vger.kernel.org
Subject:
> hpsa compat ioctl done (hopefully) saner. I really want
> to kill compat_alloc_user_space() off - it's always trouble and
> for a driver-private ioctls it's absolutely pointless.
>
> Note that this is only compile-tested - I don't have the
> hardware to test it on *or* userland to
On Fri, May 29, 2020 at 4:54 PM Linus Torvalds
wrote:
>
> My only complaint was that kvm thing that I think should have gone even
> further.
Oh... And the cc list looks a bit odd.
You cc'd fsdevel, but none of the patches were really to any
filesystem code (ok, the pselect and binfmt thing is i
On Fri, May 29, 2020 at 4:26 PM Al Viro wrote:
>
> The stuff that doesn't fit anywhere else. Hopefully
> saner marshalling for weird 7-argument syscalls (pselect6()),
That looked fine to me, btw. Looks like an improvement even outside
the "avoid __get_user()" and double STAC/CLAC issue.
> low-h
On Fri, May 29, 2020 at 08:06:14AM +0300, Jani Nikula wrote:
> On Fri, 29 May 2020, Al Viro wrote:
> > Low-hanging fruit in i915 uaccess-related stuff.
> > There's some subtler stuff remaining after that; these
> > are the simple ones.
>
> Please Cc: intel-...@lists.freedesktop.org for i915 c
On Fri, May 29, 2020 at 11:48:51AM +0100, Ian Abbott wrote:
> > Al Viro (10):
> >comedi: move compat ioctl handling to native fops
> >comedi: get rid of indirection via translated_ioctl()
> >comedi: get rid of compat_alloc_user_space() mess in COMEDI_CHANINFO
> > compat
>
On 29/05/2020 01:34, Al Viro wrote:
The way comedi compat ioctls are done is wrong.
Instead of having ->compat_ioctl() copying the 32bit
stuff in, then passing the kernel copies to helpers shared
with native ->ioctl() and doing copyout with conversion if
needed, it's playing silly buggers
On Fri, 29 May 2020, Al Viro wrote:
> Low-hanging fruit in i915 uaccess-related stuff.
> There's some subtler stuff remaining after that; these
> are the simple ones.
Please Cc: intel-...@lists.freedesktop.org for i915 changes.
Also added Chris who I believe will be able to best review the
From: Al Viro
> Sent: 10 May 2020 00:41
>
> One of the uaccess-related branches; this one is just the
> cases when access_ok() calls are trivially pointless - the address
> in question gets fed only to primitives that do access_ok() checks
> themselves.
There is also the check in rw_copy_ch
On Sat, May 09, 2020 at 05:34:58PM -0700, Linus Torvalds wrote:
> On Sat, May 9, 2020 at 4:41 PM Al Viro wrote:
> >
> > Individual patches in followups; if nobody screams - into #for-next
> > it goes...
>
> Looks fine to me, although I only read your commit logs, I didn't
> verify that wh
On Sat, May 9, 2020 at 4:41 PM Al Viro wrote:
>
> Individual patches in followups; if nobody screams - into #for-next
> it goes...
Looks fine to me, although I only read your commit logs, I didn't
verify that what you stated was actually true (ie the whole "only used
for xyz" parts).
But
+ Rob, devicetree@, Mark
On Wed, 5 Jun 2019, Kevin Hilman wrote:
> Paul Walmsley writes:
>
> > Palmer has asked me to collect patches for the v5.2-rc releases and v5.3
> > merge window, so I'll be doing so. This is just a heads-up so no one is
> > surprised to see 'patch queued' responses fr
Paul Walmsley writes:
> Palmer has asked me to collect patches for the v5.2-rc releases and v5.3
> merge window, so I'll be doing so. This is just a heads-up so no one is
> surprised to see 'patch queued' responses from me.
Speaking of v5.2-rc, any chance your DT series will make it for v5.2?
On Wed, Feb 13, 2019 at 02:05:13PM +, Vabhav Sharma wrote:
> ++ Kernel Mailing list
>
> From: Vabhav Sharma
> Sent: Wednesday, February 13, 2019 7:30 PM
> To: Greg Kroah-Hartman ; Stephen Boyd
> ; Viresh Kumar
> Subject: PATCHES MERGE MISSING FROM PATCHSET
> Importance: High
>
> Hello Maint
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
> The problem is that users have to wait tens of minutes to see perf
> top results on the screen in KNL. Before that, there is nothing but
> a black screen.
I'm actually curious why so I started digging last night.
First, I made perf top
On 10/29/2018 6:42 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
- struct annotation_options *annotation_options
__maybe_unused)
+ struct annotation_options *annotation_options __maybe_unused,
+
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
> - struct annotation_options *annotation_options
> __maybe_unused)
> + struct annotation_options *annotation_options __maybe_unused,
> + atomic_t *nr_rb_read __maybe_unused)
> {
There is no problem with the message, the problem is the thread where
the message is being displayed, just signal the display thread to
display the warning, not doing that in the event processing thread.
How about this patch (just did some simple test)? It moves the warning
to display thr
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 14:20:15 -0400
> You didn't see any warning before the patch. I think it is just
> because perf top hides the problem.
Quite honestly, the last time I played around with this:
1) The new ring buffer mode didn't exist
2) perf started up much more quickl
Em Mon, Oct 29, 2018 at 02:20:15PM -0400, Liang, Kan escreveu:
>
>
> On 10/29/2018 1:48 PM, David Miller wrote:
> > From: "Liang, Kan"
> > Date: Mon, 29 Oct 2018 13:42:56 -0400
> >
> > >
> > >
> > > On 10/29/2018 1:40 PM, David Miller wrote:
> > > > From: "Liang, Kan"
> > > > Date: Mon, 29 O
On 10/29/2018 1:48 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 13:42:56 -0400
On 10/29/2018 1:40 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
I just realized that the problem in KNL will be back if we switch
back to non-overwri
Em Mon, Oct 29, 2018 at 10:43:21AM -0700, David Miller escreveu:
> From: "Liang, Kan"
> Date: Mon, 29 Oct 2018 11:11:25 -0400
>
> > The processing time for each perf_top__mmap_read_idx() should not that
> > long. We may check it after each perf_top__mmap_read_idx(). Also
> > change the ui_warning
Em Mon, Oct 29, 2018 at 10:40:08AM -0700, David Miller escreveu:
> From: "Liang, Kan"
> Date: Mon, 29 Oct 2018 10:33:06 -0400
>
> > I just realized that the problem in KNL will be back if we switch
> > back to non-overwrite mode.
>
>> What is KNL?
I guess its Knights Landing.
https://en.wikipe
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 13:42:56 -0400
>
>
> On 10/29/2018 1:40 PM, David Miller wrote:
>> From: "Liang, Kan"
>> Date: Mon, 29 Oct 2018 10:33:06 -0400
>>
>>> I just realized that the problem in KNL will be back if we switch
>>> back to non-overwrite mode.
>> What is KNL?
>>
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 11:11:25 -0400
> The processing time for each perf_top__mmap_read_idx() should not that
> long. We may check it after each perf_top__mmap_read_idx(). Also
> change the ui_warning to one-time warning. The patch as below can do
> that (not test).
You canno
On 10/29/2018 1:40 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
I just realized that the problem in KNL will be back if we switch
back to non-overwrite mode.
What is KNL?
Intel Xeon Phi Processor, Knights Landing.
Thanks,
Kan
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
> I just realized that the problem in KNL will be back if we switch
> back to non-overwrite mode.
What is KNL?
On 10/29/2018 10:35 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Oct 29, 2018 at 10:33:06AM -0400, Liang, Kan escreveu:
On 10/29/2018 9:03 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Oct 29, 2018 at 10:33:06AM -0400, Liang, Kan escreveu:
> On 10/29/2018 9:03 AM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
> > > On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Oct 26, 2018 at 03:16:29PM -0400, L
On 10/29/2018 9:03 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
On Fri, Sep 14, 2018 at 5:10 PM Al Viro wrote:
>
> On Fri, Sep 14, 2018 at 10:21:53AM +0200, Arnd Bergmann wrote:
>
> > This does sound very appealing, but there is a small downside:
> > The difference between ".compat_ioctl = NULL" and
> > ".compat_ioctl=native_ioctl" is now very subtle, and I wo
On Fri, Sep 14, 2018 at 10:21:53AM +0200, Arnd Bergmann wrote:
> This does sound very appealing, but there is a small downside:
> The difference between ".compat_ioctl = NULL" and
> ".compat_ioctl=native_ioctl" is now very subtle, and I wouldn't
> necessarily expect casual readers to understand th
On Fri, Sep 14, 2018 at 4:27 AM Al Viro wrote:
> On Thu, Sep 13, 2018 at 10:56:48PM +0200, Arnd Bergmann wrote:
> commit de36af5ca465156863b5fb7548e3660ea7d3bbcf
> Author: Al Viro
> Date: Thu Sep 13 22:12:15 2018 -0400
>
> change semantics of ldisc ->compat_ioctl()
>
> First of all, ma
On Thu, Sep 13, 2018 at 10:56:48PM +0200, Arnd Bergmann wrote:
> Yes, I saw that too, but couldn't figure out exactly what ipwireless
> does. I suppose it is some serial port driver that comes with a
> hardcoded ppp implementation instead of a switchable ldisc?
NFI...
> > > * SIOCGIFNAME, SIOCGI
On Thu, Sep 13, 2018 at 10:31 PM Al Viro wrote:
>
> On Thu, Sep 13, 2018 at 01:19:42PM +0200, Arnd Bergmann wrote:
> > On Thu, Sep 13, 2018 at 4:31 AM Al Viro wrote:
> > * TIOCSERGWILD/TIOCSERSWILD are obsolete and never do
> >anything useful, but the return code is inconsistent: ENOTTY
> >
On Thu, Sep 13, 2018 at 01:19:42PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 13, 2018 at 4:31 AM Al Viro wrote:
> >
> > See vfs.git#work.tty-ioctl. Completely untested, should seriously
> > clean the things up wrt compat. Remaining problems (aside of the bugs
> > introduced in it, of cou
On Thu, Sep 13, 2018 at 03:31:19AM +0100, Al Viro wrote:
> See vfs.git#work.tty-ioctl. Completely untested, should seriously
> clean the things up wrt compat. Remaining problems (aside of the bugs
> introduced in it, of course):
> * TIOCSERGSTRUCT must die; it's present only in amiser
On Thu, Sep 13, 2018 at 4:31 AM Al Viro wrote:
>
> See vfs.git#work.tty-ioctl. Completely untested, should seriously
> clean the things up wrt compat. Remaining problems (aside of the bugs
> introduced in it, of course):
> * TIOCSERGSTRUCT must die; it's present only in amiserial
On Sun, Jul 29, 2018 at 11:03:17PM +0100, Al Viro wrote:
> A bunch of filesystems switched to discard_new_inode() (btrfs, ufs, udf, ext2,
> jfs)
> new primitive: discard_new_inode()
> btrfs: switch to discard_new_inode()
> ufs: switch to discard_new_inode()
> udf: switch to
On Sun, Jul 29, 2018 at 3:03 PM Al Viro wrote:
>
> Assorted icache-related fixes for the next window; some of that is -stable
> fodder.
I don't see anything alarming in the patches, but "some of it is
-stable fodder" looks wrong.
The only one that is marked for stable is 03/16, and that seems to
On Tue, 20 Feb 2018 18:45:39 PST (-0800), alan...@andestech.com wrote:
On Tue, Feb 13, 2018 at 01:13:15PM +0800, Alan Quey-Liang Kao(高魁良) wrote:
This patch set includes the building blocks of dynamic ftrace features
for RISC-V machines.
Changes in v4:
- Organize code structure according to cha
On Thu, Feb 22, 2018 at 12:05:11AM +0800, Palmer Dabbelt wrote:
> On Mon, 12 Feb 2018 21:13:15 PST (-0800), alan...@andestech.com wrote:
> > This patch set includes the building blocks of dynamic ftrace features
> > for RISC-V machines.
> >
> > Changes in v4:
> > - Organize code structure accordin
On Mon, 12 Feb 2018 21:13:15 PST (-0800), alan...@andestech.com wrote:
This patch set includes the building blocks of dynamic ftrace features
for RISC-V machines.
Changes in v4:
- Organize code structure according to changes in v3
- Rebase onto the riscv-linux-4.15 branch at github's
riscv/
On Fri, 02 Feb 2018 01:45:28 PST (-0800), Christoph Hellwig wrote:
Looks fine:
Reviewed-by: Christoph Hellwig
Thanks, I'm still working through my FOSDEM-related email backlog. I'll target
this for the next RC, as it seems like a small enough fix. It should be in the
next linux-next.
On Wed, Feb 07, 2018 at 04:37:10PM -0800, Palmer Dabbelt wrote:
> On Thu, 18 Jan 2018 07:45:39 PST (-0800), noner...@gmail.com wrote:
> > This patch set includes the building blocks of dynamic ftrace features
> > for RISC-V machines.
> >
> > Changes in v3:
> > - Replace the nops at the tracer cal
On Wed, Feb 07, 2018 at 04:37:10PM -0800, Palmer Dabbelt wrote:
> On Thu, 18 Jan 2018 07:45:39 PST (-0800), noner...@gmail.com wrote:
> > This patch set includes the building blocks of dynamic ftrace features
> > for RISC-V machines.
> >
> > Changes in v3:
> > - Replace the nops at the tracer cal
On Thu, 18 Jan 2018 07:45:39 PST (-0800), noner...@gmail.com wrote:
This patch set includes the building blocks of dynamic ftrace features
for RISC-V machines.
Changes in v3:
- Replace the nops at the tracer call sites into a "call ftrace_stub"
instruction for better understanding (1/6 and 2
Looks fine:
Reviewed-by: Christoph Hellwig
On Fri, 26 Jan 2018 15:13:19 PST (-0800), Linus Torvalds wrote:
On Fri, Jan 26, 2018 at 2:39 PM, Palmer Dabbelt wrote:
I can understand if it's too late to get this into 4.15, but given that
it's not a code change I was hoping it'd still be OK.
No problem. Something like this is a no-brainer
On Thu, 25 Jan 2018 00:31:53 PST (-0800), sho...@gmail.com wrote:
On Wed, Jan 24, 2018 at 07:07:56PM -0800, Palmer Dabbelt wrote:
The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch
code looked at the Kconfig entry for our first-level irqchip driver and
called into it directl
On Thu, 18 Jan 2018 07:45:13 PST (-0800), Christoph Hellwig wrote:
I think this should not be asm-generic and lib, but kernel/irq/handle.c
and include/linux/irq.h, under the CONFIG_MULTI_IRQ_HANDLER symbol
already used by arm.
Also for completeness of the series please convert arm, arm64 and
ope
On Sun, Jan 14, 2018 at 11:24:53PM -0800, Stefan O'Rear wrote:
> On Sun, Jan 14, 2018 at 10:47 PM, Alan Kao wrote:
> > + /*
> > +* For the dynamic ftrace to work, here we should reserve at least
> > +* 8 bytes for a functional auipc-jalr pair. Pseudo inst nop may be
> > +
On Sun, Jan 14, 2018 at 10:47 PM, Alan Kao wrote:
> + /*
> +* For the dynamic ftrace to work, here we should reserve at least
> +* 8 bytes for a functional auipc-jalr pair. Pseudo inst nop may be
> +* interpreted as different length in different models, so we manually
On Wed, Jan 10, 2018 at 08:43:54AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 10, 2018 at 03:38:09PM +0800, Alan Kao wrote:
> > -LDFLAGS_vmlinux :=
> > +ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
> > + LDFLAGS_vmlinux := --no-relax
> > +else
> > + LDFLAGS_vmlinux :=
> > +endif
>
> Why not:
>
> LDFL
On Wed, Jan 10, 2018 at 03:38:09PM +0800, Alan Kao wrote:
> -LDFLAGS_vmlinux :=
> +ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
> + LDFLAGS_vmlinux := --no-relax
> +else
> + LDFLAGS_vmlinux :=
> +endif
Why not:
LDFLAGS_vmlinux :=
ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
LDFLAGS_vmlinux += --no-relax
endif
On Tue, 09 Jan 2018 00:11:45 PST (-0800), h...@lst.de wrote:
On Mon, Jan 08, 2018 at 05:27:56PM -0800, Palmer Dabbelt wrote:
During the glibc upstreaming it was suggested that CLONE_BACKWARDS was a
deprecated ABI decision. I think we just copied it from ARM, but I
don't see any reason to favor
On Mon, Jan 08, 2018 at 05:27:56PM -0800, Palmer Dabbelt wrote:
> During the glibc upstreaming it was suggested that CLONE_BACKWARDS was a
> deprecated ABI decision. I think we just copied it from ARM, but I
> don't see any reason to favor one over the other.
>
> While we haven't released yet so
On Thu, 21 Dec 2017 12:43:20 PST (-0800), Arnd Bergmann wrote:
On Thu, Dec 21, 2017 at 9:32 PM, Palmer Dabbelt wrote:
On Wed, 20 Dec 2017 01:14:31 PST (-0800), zong...@gmail.com wrote:
I've added Arnd and Olof, in case they have a bit more perspective here. If
I'm reading this correctly, th
On Thu, Dec 21, 2017 at 9:32 PM, Palmer Dabbelt wrote:
> On Wed, 20 Dec 2017 01:14:31 PST (-0800), zong...@gmail.com wrote:
> I've added Arnd and Olof, in case they have a bit more perspective here. If
> I'm reading this correctly, there isn't an arm or arm64 option to do this.
> There is an opt
On Wed, 20 Dec 2017 01:14:31 PST (-0800), zong...@gmail.com wrote:
Build the dtb into the kernel image.
If the DTB is given via bootloader, the external DTB is adopted first.
Signed-off-by: Zong Li
---
arch/riscv/Kconfig | 4
arch/riscv/Makefile | 9 +
arch/ri
On Mon, 18 Dec 2017 01:52:48 PST (-0800), noner...@gmail.com wrote:
This patch contains basic ftrace support for RV64I platform.
Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
(HAVE_FUNCTION_GRAPH_FP_TEST) are imp
On Mon, 18 Dec 2017 23:44:38 PST (-0800), zong...@gmail.com wrote:
When the interrupt sourece id > 31, the register address is not 4 byte
alignment. Arithmetic on void pointer has no size extension, it just
add the result of 'hwirq/32' directly.
Signed-off-by: Zong Li
---
drivers/irqchip/irq-r
On Mon, Dec 11, 2017 at 10:15:58AM -0800, Palmer Dabbelt wrote:
> On Wed, 06 Dec 2017 18:31:10 PST (-0800), noner...@gmail.com wrote:
Hi Palmer,
I forgot to explain this section in the previous reply:
> > +ENTRY(_mcount)
> > + la t4, ftrace_stub
> > +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>
On Wed, 06 Dec 2017 18:31:10 PST (-0800), noner...@gmail.com wrote:
This patch contains basic ftrace support for RV64I platform.
Specifically, function tracer (HAVE_FUNCTION_TRACER), function graph
tracer (HAVE_FUNCTION_GRAPH_TRACER), and a frame pointer test
(HAVE_FUNCTION_GRAPH_FP_TEST) are imp
On Thu, Dec 07, 2017 at 12:59:35PM -0800, Palmer Dabbelt wrote:
> On Sat, 02 Dec 2017 19:20:02 PST (-0800), parri.and...@gmail.com wrote:
> >On Fri, Dec 01, 2017 at 01:39:12PM -0800, Palmer Dabbelt wrote:
> >> RISC-V: Remove smb_mb__{before,after}_spinlock()
> >
> >I wonder whether you really
On Sat, 02 Dec 2017 19:20:02 PST (-0800), parri.and...@gmail.com wrote:
On Fri, Dec 01, 2017 at 01:39:12PM -0800, Palmer Dabbelt wrote:
RISC-V: Remove smb_mb__{before,after}_spinlock()
I wonder whether you really meant to remove smp_mb__after_spinlock():
on the one hand, this primitive d
On Thu, Nov 30, 2017 at 10:38:32AM -0800, Palmer Dabbelt wrote:
> index da09fb986459..dd5a9dd7a102 100644
> --- a/include/asm-generic/audit_dir_write.h
> +++ b/include/asm-generic/audit_dir_write.h
> @@ -27,7 +27,9 @@ __NR_mknod,
> __NR_mkdirat,
> __NR_mknodat,
> __NR_unlinkat,
> +#ifdef __NR_renam
On Thu, 30 Nov 2017 12:32:04 PST (-0800), Olof Johansson wrote:
Hi,
On Mon, Nov 20, 2017 at 10:57 AM, Palmer Dabbelt wrote:
From: Andrew Waterman
The RISC-V ISA allows for instruction caches that are not coherent WRT
stores, even on a single hart. As a result, we need to explicitly flush
th
Hi,
On Mon, Nov 20, 2017 at 10:57 AM, Palmer Dabbelt wrote:
> From: Andrew Waterman
>
> The RISC-V ISA allows for instruction caches that are not coherent WRT
> stores, even on a single hart. As a result, we need to explicitly flush
> the instruction cache whenever marking a dirty page as execu
On Thu, Nov 30, 2017 at 10:38 AM, Palmer Dabbelt wrote:
> On Thu, 30 Nov 2017 10:30:32 PST (-0800), Christoph Hellwig wrote:
>>
>> On Wed, Nov 29, 2017 at 05:55:19PM -0800, Olof Johansson wrote:
>>>
>>> In file included from ../lib/audit.c:8:0:
>>> ../include/asm-generic/audit_dir_write.h:30:1: er
On Thu, 30 Nov 2017 03:31:53 PST (-0800), pombreda...@nexb.com wrote:
On Thu, Nov 30, 2017 at 9:53 AM, Alan Kao wrote:
[]
diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h
new file mode 100644
index ..38beadb07ad5
--- /dev/null
+++ b/arch/riscv/include/a
On Thu, 30 Nov 2017 10:30:32 PST (-0800), Christoph Hellwig wrote:
On Wed, Nov 29, 2017 at 05:55:19PM -0800, Olof Johansson wrote:
In file included from ../lib/audit.c:8:0:
../include/asm-generic/audit_dir_write.h:30:1: error: '__NR_renameat'
undeclared here (not in a function); did you mean '_
On Wed, 29 Nov 2017 17:55:11 PST (-0800), Olof Johansson wrote:
Here's a short series of patches that produces a working
allmodconfig. Would be nice to see them go in so we can add build
coverage.
I was just about to send a pull request when these came in last night, so it's
good timing :). T
On Wed, 29 Nov 2017 17:55:17 PST (-0800), Olof Johansson wrote:
Fixes the following on allmodconfig build:
profile.c:(.text+0x3e4): undefined reference to `setup_profiling_timer'
Signed-off-by: Olof Johansson
---
arch/riscv/kernel/smp.c | 8
1 file changed, 8 insertions(+)
diff --gi
On Wed, Nov 22, 2017 at 9:38 AM, Palmer Dabbelt wrote:
> On Tue, 21 Nov 2017 08:57:07 PST (-0800), david.lai...@aculab.com wrote:
>>
>> From: Palmer Dabbelt
>>>
>>> Sent: 20 November 2017 18:58
>>>
>>> The RISC-V ISA allows for instruction caches that are not coherent WRT
>>> stores, even on a sin
On Tue, 21 Nov 2017 08:57:07 PST (-0800), david.lai...@aculab.com wrote:
From: Palmer Dabbelt
Sent: 20 November 2017 18:58
The RISC-V ISA allows for instruction caches that are not coherent WRT
stores, even on a single hart. As a result, we need to explicitly flush
the instruction cache whenev
On Tue, 21 Nov 2017 03:04:52 PST (-0800), mark.rutl...@arm.com wrote:
Hi Palmer,
On Mon, Nov 20, 2017 at 11:50:22AM -0800, Palmer Dabbelt wrote:
RISC-V doesn't currently specify a mechanism for enabling or disabling
CPUs. Instead, we assume that all CPUs are enabled on boot, and if
someone wan
On Tue, 21 Nov 2017 12:08:32 PST (-0800), j.neuschae...@gmx.net wrote:
On Tue, Nov 21, 2017 at 09:37:02AM -0800, Palmer Dabbelt wrote:
[...]
This isn't really a big deal to me, as I'm only interested in RISC-V
systems, but there's been some pushback on the concept of an SBI so it
seemed like a s
On Tue, Nov 21, 2017 at 09:37:02AM -0800, Palmer Dabbelt wrote:
[...]
> This isn't really a big deal to me, as I'm only interested in RISC-V
> systems, but there's been some pushback on the concept of an SBI so it
> seemed like a simple way to allow people to build non-SBI (and there for not
> real
On Mon, 20 Nov 2017 17:08:44 PST (-0800), j.neuschae...@gmx.net wrote:
On Mon, Nov 20, 2017 at 01:28:01PM -0800, Palmer Dabbelt wrote:
> > @@ -0,0 +1,20 @@
> > +RISC-V Supervisor Binary Interface (SBI)
> > +
> > +The RISC-V privileged ISA specification mandates the presence of a
supervisor
> >
On Mon, 20 Nov 2017 13:47:09 PST (-0800), r...@kernel.org wrote:
On Mon, Nov 20, 2017 at 11:50:22AM -0800, Palmer Dabbelt wrote:
RISC-V doesn't currently specify a mechanism for enabling or disabling
CPUs. Instead, we assume that all CPUs are enabled on boot, and if
someone wants to save power
On Mon, 20 Nov 2017 13:45:20 PST (-0800), r...@kernel.org wrote:
On Mon, Nov 20, 2017 at 11:50:00AM -0800, Palmer Dabbelt wrote:
The RISC-V privileged ISA mandates the presence of an SBI, but there's
no reason not to put it in the device tree. This would allow us to
possibly remove the SBI late
Hi Palmer,
On Mon, Nov 20, 2017 at 01:28:01PM -0800, Palmer Dabbelt wrote:
> On Mon, 20 Nov 2017 12:28:56 PST (-0800), j.neuschae...@gmx.net wrote:
> > On Mon, Nov 20, 2017 at 11:50:00AM -0800, Palmer Dabbelt wrote:
> > > +RISC-V Supervisor Binary Interface (SBI)
> > > +
> > > +The RISC-V privileg
On Mon, Nov 20, 2017 at 01:28:01PM -0800, Palmer Dabbelt wrote:
[...]
> > > +++ b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt
> >
> > Nit: Other bindings use either a comma (as in the compatible string,
> > "riscv,sbi.txt") or a dash (vendor-product.txt, "riscv-sbi.txt") in the
> > fi
On Mon, 20 Nov 2017 12:28:56 PST (-0800), j.neuschae...@gmx.net wrote:
On Mon, Nov 20, 2017 at 11:50:00AM -0800, Palmer Dabbelt wrote:
The RISC-V privileged ISA mandates the presence of an SBI, but there's
no reason not to put it in the device tree. This would allow us to
possibly remove the SB
On Sun, 19 Nov 2017 23:35:28 PST (-0800), j.neuschae...@gmx.net wrote:
Hi Palmer,
On Thu, Oct 05, 2017 at 11:16:33AM +0100, Mark Rutland wrote:
[...]
I would *strongly* recommend that from day one, you determine the SMP
bringup mechanism via an enable-method property, and document the
contract
Hi Palmer,
On Thu, Oct 05, 2017 at 11:16:33AM +0100, Mark Rutland wrote:
[...]
> I would *strongly* recommend that from day one, you determine the SMP
> bringup mechanism via an enable-method property, and document the
> contract with FW/bootloader somewhere in the kernel tree.
Somewhat, but not
> From: Will Deacon [mailto:will.dea...@arm.com]
> Hi Daniel,
>
> On Thu, Nov 16, 2017 at 06:40:46AM +, Daniel Lustig wrote:
> > > > In that case, maybe we should just start out having a fence on
> > > > both sides for
> > >
> > > Actually, given your architecture is RCsc rather than RCpc, so
Hi Daniel,
On Thu, Nov 16, 2017 at 06:40:46AM +, Daniel Lustig wrote:
> > > In that case, maybe we should just start out having a fence on both
> > > sides for
> >
> > Actually, given your architecture is RCsc rather than RCpc, so I think maybe
> > you could follow the way that ARM uses(i.e.
> > In that case, maybe we should just start out having a fence on both
> > sides for
>
> Actually, given your architecture is RCsc rather than RCpc, so I think maybe
> you could follow the way that ARM uses(i.e. relaxed load + release store + a
> full barrier). You can see the commit log of 8e86f
On Wed, 15 Nov 2017 15:59:44 PST (-0800), Daniel Lustig wrote:
On Wed, 15 Nov 2017 10:06:01 PST (-0800), will.dea...@arm.com wrote:
On Tue, Nov 14, 2017 at 12:30:59PM -0800, Palmer Dabbelt wrote:
> On Tue, 24 Oct 2017 07:10:33 PDT (-0700), will.dea...@arm.com wrote:
>>On Tue, Sep 26, 2017 at 06:
> > Bergmann ; Olof Johansson ; linux-
> > ker...@vger.kernel.org; patc...@groups.riscv.org; pet...@infradead.org
> > Subject: Re: [patches] Re: [PATCH v9 05/12] RISC-V: Atomic and Locking Code
> >
> > On Wed, Nov 15, 2017 at 11:59:44PM +, Daniel Lustig wrote
groups.riscv.org; pet...@infradead.org
> Subject: Re: [patches] Re: [PATCH v9 05/12] RISC-V: Atomic and Locking Code
>
> On Wed, Nov 15, 2017 at 11:59:44PM +, Daniel Lustig wrote:
> > > On Wed, 15 Nov 2017 10:06:01 PST (-0800), will.dea...@arm.com wrote:
> > >> On Tue, Nov
On Wed, Nov 15, 2017 at 11:59:44PM +, Daniel Lustig wrote:
> > On Wed, 15 Nov 2017 10:06:01 PST (-0800), will.dea...@arm.com wrote:
> >> On Tue, Nov 14, 2017 at 12:30:59PM -0800, Palmer Dabbelt wrote:
> >> > On Tue, 24 Oct 2017 07:10:33 PDT (-0700), will.dea...@arm.com wrote:
> >> >>On Tue, Sep
> On Wed, 15 Nov 2017 10:06:01 PST (-0800), will.dea...@arm.com wrote:
>> On Tue, Nov 14, 2017 at 12:30:59PM -0800, Palmer Dabbelt wrote:
>> > On Tue, 24 Oct 2017 07:10:33 PDT (-0700), will.dea...@arm.com wrote:
>> >>On Tue, Sep 26, 2017 at 06:56:31PM -0700, Palmer Dabbelt wrote:
> >
> > Hi Palmer,
On Wed, 15 Nov 2017 10:06:01 PST (-0800), will.dea...@arm.com wrote:
Hi Palmer,
On Tue, Nov 14, 2017 at 12:30:59PM -0800, Palmer Dabbelt wrote:
On Tue, 24 Oct 2017 07:10:33 PDT (-0700), will.dea...@arm.com wrote:
>On Tue, Sep 26, 2017 at 06:56:31PM -0700, Palmer Dabbelt wrote:
>>+ATOMIC_OPS(add
1 - 100 of 360 matches
Mail list logo
