On Thu, 25 Mar 2021, Jann Horn wrote:
> Hi!
>
> Tavis noticed that on ARM kernels with CONFIG_BINFMT_ELF_FDPIC, it
> looks like the FDPIC_FUNCPTRS personality flag is not reset on
> execve(). This would mean that if a process first executes an ELF
> FDPIC binary (which forces the personality to
On Thu, 11 Mar 2021, Miguel Ojeda wrote:
> On Thu, Mar 11, 2021 at 10:47 AM Masahiro Yamada wrote:
> >
> > +# When you raise the minimum version, please update
> > +# Documentation/process/changes.rst as well.
> > +min_gcc_version=4.9.0
> > +min_llvm_version=10.0.1
> > +min_icc_version=16.0.3 #
On Wed, 10 Mar 2021, Nick Desaulniers wrote:
> On Wed, Mar 10, 2021 at 1:08 PM Arnd Bergmann wrote:
> >
> > On Wed, Mar 10, 2021 at 9:50 PM Masahiro Yamada
> > wrote:
> > > On Mon, Mar 1, 2021 at 10:11 AM Nicholas Piggin wrote:
> > > > Excerpts from Arnd Bergmann's message of February 27,
On Wed, 10 Mar 2021, Sedat Dilek wrote:
> The best results on size-reduction of vmlinux I got with Clang-CFI on x86-64.
>
> Clang-LTO and Clang-CFI:
> I was able to build with CONFIG_TRIM_UNUSED_KSYMS=y which needs to add
> a whitelist file or add a whitelist to scripts/gen_autoksyms.sh.
> And
On Mon, 1 Mar 2021, Nicholas Piggin wrote:
> Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm:
> > Unlike what Nick expected in his submission, I now think the annotations
> > will be needed for LTO just like they are for --gc-sections.
>
> Yeah I wasn't sure exactly what LTO
On Tue, 9 Mar 2021, Rasmus Villemoes wrote:
> On 09/03/2021 20.54, Nicolas Pitre wrote:
> > On Wed, 10 Mar 2021, Masahiro Yamada wrote:
> >
>
> >>> I'm not sure I do understand every detail here, especially since it is
> >>> so far away from
On Wed, 10 Mar 2021, Masahiro Yamada wrote:
> On Wed, Mar 10, 2021 at 2:36 AM Nicolas Pitre wrote:
> >
> > On Wed, 10 Mar 2021, Masahiro Yamada wrote:
> >
> > > Commit a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some
> > > guarding&q
lied
to mainline after all those years, the recursive approach brings
nothing. Maybe that could be revisited if true LTO ever makes it into
mainline, and the desire to reduce the binary size is still relevant
enough to justify it.
Acked-by: Nicolas Pitre
Nicolas
On Tue, 9 Mar 2021, Masahiro Yamada wrote:
> On Fri, Feb 26, 2021 at 4:24 AM Nicolas Pitre wrote:
> >
> > If CONFIG_TRIM_UNUSED_KSYMS is enabled then build time willincrease.
> > That comes with the feature.
>
> This patch set intends to change this.
> TRIM_U
On Thu, 4 Mar 2021, Masahiro Yamada wrote:
> The kernel build uses various tools, many of which are provided by the
> same software suite, for example, LLVM and Binutils.
>
> When we raise the minimal version of Clang/LLVM, we need to update
> clang_min_version in scripts/cc-version.sh and also
On Fri, 26 Feb 2021, Masahiro Yamada wrote:
> On Fri, Feb 26, 2021 at 2:20 AM Nicolas Pitre wrote:
> >
> > On Fri, 26 Feb 2021, Masahiro Yamada wrote:
> >
> > >
> > > Now CONFIG_TRIM_UNUSED_KSYMS is revived, but Linus is still unhappy
> > > abo
On Fri, 26 Feb 2021, Masahiro Yamada wrote:
>
> Now CONFIG_TRIM_UNUSED_KSYMS is revived, but Linus is still unhappy
> about the build speed.
>
> I re-implemented this feature, and the build time cost is now
> almost unnoticeable level.
>
> I hope this makes Linus happy.
:-)
I'm surprised to
ompat: remove KERNEL_DS usage in
> sys_oabi_epoll_ctl()")
> Signed-off-by: Randy Dunlap
> Reported-by: kernel test robot # from an lkp .config file
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Nicolas Pitre
> Cc: Alexander Viro
> Cc: patc...@a
ugh it won't build.
>
> By adding a dependency on HAS_IOMEM, the driver will not be enabled on
> architectures which don't support it.
>
> Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver")
> Signed-off-by: David Gow
Acked-by: Nicolas Pitre
>
ugh it won't build.
>
> By adding a dependency on HAS_IOMEM, the driver will not be enabled on
> architectures which don't support it.
>
> Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver")
> Signed-off-by: David Gow
Acked-by: Nicolas Pitre
>
() and
pm_clk_op_unlock() may or may not lock/unlock psd->lock depending on
some runtime condition. To work around that we tell it the lock is
always untaken for the purpose of static analisys.
Thanks to Naresh Kamboju for reporting issues with the initial patch.
Signed-off-by: Nicolas Pitre
Tested-by: Nar
On Mon, 25 Jan 2021, Rafael J. Wysocki wrote:
> On Sun, Jan 24, 2021 at 12:07 AM Nicolas Pitre wrote:
> > A note on sparse:
> > According to https://lwn.net/Articles/109066/ there are things
> > that sparse can't cope with. In particular, pm_clk_op_lock() and
> > pm
() and
pm_clk_op_unlock() may or may not lock/unlock psd->lock depending on
some runtime condition. To work around that we tell sparse the lock
is always untaken for the purpose of static analisys.
Thanks to Naresh Kamboju for reporting issues with the initial patch.
Signed-off-by: Nicolas Pitre
Tes
On Fri, 22 Jan 2021, Nicolas Pitre wrote:
> On Fri, 22 Jan 2021, Rafael J. Wysocki wrote:
>
> > On Fri, Jan 22, 2021 at 4:48 PM Naresh Kamboju
> > wrote:
> > >
> > > On Fri, 22 Jan 2021 at 20:39, Rafael J. Wysocki wrote:
> > > >
> >
t; > > >
> > > > On Thu, Jan 21, 2021 at 6:23 PM Nicolas Pitre
> > > > wrote:
> > > > >
> > > > > The clock API splits its interface into sleepable ant atomic contexts:
> > > > >
> > > > > - clk_prepare/clk
On Fri, 22 Jan 2021, Rafael J. Wysocki wrote:
> > > +/**
> > > + * pm_clk_list_unlock - counterpart to pm_clk_list_lock().
> > > + * @psd: the same pm_subsys_data instance previously passed to
> > > + * pm_clk_list_lock().
> > > + */
> > > +static void pm_clk_list_unlock(struct
pm_runtime_resume()
may be invoked in atomic context.
For clocks that do implement the enable and disable methods then
everything just works as before.
Signed-off-by: Nicolas Pitre
---
On Thu, 21 Jan 2021, Rafael J. Wysocki wrote:
> So I'm going to drop this patch from linux-next until the is
On Thu, 21 Jan 2021, Rafael J. Wysocki wrote:
> On Thu, Jan 21, 2021 at 1:11 PM Naresh Kamboju
> wrote:
> >
> > ref:
> > https://builds.tuxbuild.com/1nN0vkpNP4qhvIuIJN12j7tTpQs/
>
> So I'm going to drop this patch from linux-next until the issue is
> resolved, thanks!
No problem - I'm on it.
On Tue, 19 Jan 2021, Geert Uytterhoeven wrote:
> Hi Kevin, Nicolas,
>
> On Tue, Jan 19, 2021 at 7:45 PM Kevin Hilman wrote:
> > [ + Geert.. renesas SoCs are the primary user of PM clk ]
>
> Thanks!
>
> > Nicolas Pitre writes:
> > > The clock API splits
Ping.
On Mon, 4 Jan 2021, Nicolas Pitre wrote:
> The clock API splits its interface into sleepable ant atomic contexts:
>
> - clk_prepare/clk_unprepare for stuff that might sleep
>
> - clk_enable_clk_disable for anything that may be done in atomic context
>
> The cod
pm_runtime_resume()
may be invoked in atomic context.
For clocks that do implement the enable and disable methods then
everything just works as before.
Signed-off-by: Nicolas Pitre
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index ced6863a16..a62fb0f9b1 100644
-attributes]
> static const struct __maybe_unused of_device_id i3c_hci_of_match[] = {
> ^
> include/linux/compiler_attributes.h:267:56: note: expanded
>
> Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused variable
> warning")
> Si
out this variable, period.
>
> Fixes: 95393f3e07ab ("i3c/master/mipi-i3c-hci: quiet maybe-unused variable
> warning")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1221
> Signed-off-by: Nathan Chancellor
Acked-by: Nicolas Pitre
> ---
> drivers/i3c/mast
On Mon, 30 Nov 2020, Parshuram Thombare wrote:
> add i3c_secondary_master_register which is used
> to register secondary masters.
I'm not sure about the logic here. Why would the secondary master
initialize the bus? If you make a distinction between primary and
secondary, then the primary
On Mon, 30 Nov 2020, Parshuram Thombare wrote:
> Removed last argument 'secondary' and restructured i3c_master_register
> to move code that can be common to i3c_secondary_master_register
> to separate function i3c_master_init.
>
> Signed-off-by: Parshuram Thombare
[...]
> +static int
),
> i.e. not at a multiple of 128 MiB.
>
> Suggested-by: Nicolas Pitre
> Suggested-by: Ard Biesheuvel
> Signed-off-by: Geert Uytterhoeven
I'm not that intimate with dt contents so:
Acked-by: Nicolas Pitre
And it would be a good idea to repeat the GOT fixup caviat comment
befo
d-off-by: Geert Uytterhoeven
Reviewed-by: Nicolas Pitre
> ---
> v10:
> - New.
> ---
> arch/arm/boot/compressed/head.S | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
>
On Thu, 3 Dec 2020, Geert Uytterhoeven wrote:
> DTB stores all values as 32-bit big-endian integers.
> Add a macro to convert such values to native CPU endianness, to reduce
> duplication.
>
> Signed-off-by: Geert Uytterhoeven
I agree with Ard's suggestions. In any case:
Revie
can't
really comment on rv asm styling and page setup).
Acked-by: Nicolas Pitre
If you have a chance to test cramfs' user space XIP support that would
be nice. So far it was tested only on ARM. See
Documentation/filesystems/cramfs.rst for instructions.
> ---
> arch/
On Wed, 2 Dec 2020, Vitaly Wool wrote:
> On Wed, Dec 2, 2020 at 7:06 PM Nicolas Pitre wrote:
> >
> > On Wed, 2 Dec 2020, Vitaly Wool wrote:
> >
> > > Introduce XIP (eXecute In Place) support for RISC-V platforms.
> > > It allows code to be exec
On Wed, 2 Dec 2020, Vitaly Wool wrote:
> Introduce XIP (eXecute In Place) support for RISC-V platforms.
> It allows code to be executed directly from non-volatile storage
> directly addressable by the CPU, such as QSPI NOR flash which can
> be found on many RISC-V platforms. This makes way for
On Mon, 30 Nov 2020, Nick Desaulniers wrote:
> On Mon, Nov 30, 2020 at 11:05 AM Nicolas Pitre wrote:
>
> > + __rem = __n >> 32;
> > *n = __res;
> > return __rem;
>
> The above 3 statement could be:
>
> ```
> *n = __res;
&
d produces the same code with this patch applied.
Signed-off-by: Nicolas Pitre
Reviewed-by: Ard Biesheuvel
Tested-by: Ard Biesheuvel
---
This is related to the thread titled "[RESEND,PATCH] ARM: fix
__div64_32() error when compiling with clang". My limited compile test
with clang appe
On Mon, 30 Nov 2020, Ard Biesheuvel wrote:
> On Mon, 30 Nov 2020 at 16:51, Nicolas Pitre wrote:
>
> > Here's my version of the fix which should be correct. Warning: this
> > is completely untested, but should in theory produce the same code on
> > modern gcc.
>
On Mon, 30 Nov 2020, Ard Biesheuvel wrote:
> (+ Nico)
>
> On Mon, 30 Nov 2020 at 11:11, Ard Biesheuvel wrote:
> >
> > On Mon, 23 Nov 2020 at 08:39, Antony Yu wrote:
> > >
> > > __do_div64 clobbers the input register r0 in little endian system.
> > > According to the inline assembly document,
On Thu, 26 Nov 2020, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in the Kconfig help text. Fix it.
>
> Signed-off-by: Colin Ian King
Acked-by: Nicolas Pitre
> ---
> fs/cramfs/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion
ialized garbage
> starting address from being used.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: 9ad9a52cce28 ("i3c/master: introduce the mipi-i3c-hci driver")
> Signed-off-by: Colin Ian King
Acked-by: Nicolas Pitre
> ---
> drivers/i
On Mon, 23 Nov 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> Remove open coded kmap/memcpy/kunmap and use mempcy_from_page() instead.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
> ---
> fs/cramfs/inode.c | 3 +--
> 1 file
On Fri, 9 Oct 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Ac
On Sun, 27 Sep 2020, Rong Chen wrote:
> Hi Nicolas,
>
> Thanks for the feedback, the error still remains with gcc 10.2.0:
I've created the simplest test case that can be. You won't believe it.
Test case:
$ cat test.c
unsigned int test(unsigned int x, unsigned long long y)
{
y /=
This looks like a buggy compiler to me.
On Sun, 30 Aug 2020, kernel test robot wrote:
> Hi Nicolas,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: e77aee1326f7691763aa968eee2f57db37840b9d
> commit:
On Tue, 4 Aug 2020, Conor Culhane wrote:
> Miquel is passing 0 as the delay_us argument.
Good point.
> Is this still a concern?
Not in that case.
Nicolas
On Thu, 9 Jul 2020, Miquel Raynal wrote:
> Add support for Silvaco I3C dual-role IP. The master role is supported
> in SDR mode only. I2C transfers have not been tested but are shared
> because they are so close to the I3C transfers in terms of registers
> configuration.
>
> Signed-off-by:
t's not usable and it never had been; as the matter of fact,
> that's the reason sys/procfs.h had been introduced back in 1996.
Huh! That's convenient alright.
Acked-by: Nicolas Pitre
Nicolas
> ^1da177e4c3f41 drivers/char/vt.c Linus Torvalds 2005-04-16 1183
> unsigned long old_origin, new_origin, new_scr_end, rlth, rrem, err = 0;
> 9e0ba741aabdf1 drivers/char/vt.c qiaochong 2010-08-09 1184
> unsigned long end;
> d8ae7242718738 drivers/tty/vt
On Fri, 12 Jun 2020, afzal mohammed wrote:
> Performance wise, results are not encouraging, 'dd' on tmpfs results,
>
> ARM Cortex-A8, BeagleBone White (256MiB RAM):
> w/o series - ~29.5 MB/s
> w/ series - ~20.5 MB/s
> w/ series & highmem disabled - ~21.2 MB/s
>
> On Cortex-A15(2GiB RAM) in
On Fri, 5 Jun 2020, Philippe Mathieu-Daudé wrote:
> Unfortunately refreshable braille displays have that "hardware
> limitations". 80 cells displays are very expensive.
> Visual impairments is rarely a "choice".
> Relaxing the 80-char limit make it harder for blind developers
> to contribute.
case
as well.
Signed-off-by: Nicolas Pitre
Reported-by: syzbot+0bfda3ade1ee9288a...@syzkaller.appspotmail.com
Fixes: 9a98e7a80f95 ("vt: don't use kmalloc() for the unicode screen buffer")
Cc:
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index e5ffed795e..48a8199f78 100644
---
On Sat, 2 May 2020, Jiri Slaby wrote:
> > Call Trace:
> > virt_to_head_page include/linux/mm.h:833 [inline]
> > virt_to_cache mm/slab.h:474 [inline]
> > kfree+0x60/0x220 mm/slab.c:3749
> > vc_do_resize+0x738/0x1ce0 drivers/tty/vt/vt.c:1233
> Of course, s/kfree/vfree/ there. NIcolas, could you
;
> > Testing done so far:
> >
> > - Creating a simple core dump on X86-64 still works.
> > - The created coredump on X86-64 opens in GDB, and both the stack and the
> >exectutable look vaguely plausible.
> > - 32-bit ARM compiles with FDPIC support, both with MM
On Wed, 29 Apr 2020, Linus Torvalds wrote:
> While we're at it, is there anybody who knows binfmt_flat?
I'd say Greg Ungerer.
> It might be Nicolas too.
I only contributed the necessary changes to make it work on targets with
a MMU. Once fdpic started to worked I used that instead.
FWIW I
On Fri, 18 Oct 2019, Sudeep Holla wrote:
> On Fri, Oct 18, 2019 at 11:25:17AM +0530, Viresh Kumar wrote:
> > On 17-10-19, 13:35, Sudeep Holla wrote:
> > > Fix the following checkpatch checks/warnings:
> > >
> > > CHECK: Unnecessary parentheses around the code
> > > CHECK: Alignment should match
On Thu, 17 Oct 2019, Sudeep Holla wrote:
> Hi,
>
> Since vexpress-spc is the sole user of arm_big_little cpufreq driver,
> there's no point in keeping it separate anymore. I wanted to post these
> patches for ages but kept postponing for no reason.
For these patches:
Acked-by
On Sat, 21 Sep 2019, Xiaoming Ni wrote:
> @ Nicolas Pitre
> Can I make a v2 patch based on your advice ?
> Or you will submit a patch for "GFP_WONTFAIL" yourself ?
Here's a patch implementing what I had in mind. This is compile tested
only.
- >8
Subject: [PATCH]
On Thu, 19 Sep 2019, Greg KH wrote:
> On Thu, Sep 19, 2019 at 05:18:15PM +0800, Xiaoming Ni wrote:
> > Using kzalloc() to allocate memory in function con_init(), but not
> > checking the return value, there is a risk of null pointer references
> > oops.
> >
> > Signed-off-by: Xiaoming Ni
>
>
On Tue, 10 Sep 2019, Masahiro Yamada wrote:
> On Tue, Sep 10, 2019 at 1:06 AM Nicolas Pitre wrote:
> >
> > On Mon, 9 Sep 2019, Masahiro Yamada wrote:
> >
> > > Hi Nicolas,
> > >
> > > On Mon, Sep 9, 2019 at 10:48 PM Nicolas Pitre wrote:
> >
On Mon, 9 Sep 2019, Masahiro Yamada wrote:
> Hi Nicolas,
>
> On Mon, Sep 9, 2019 at 10:48 PM Nicolas Pitre wrote:
> >
> > On Mon, 9 Sep 2019, Masahiro Yamada wrote:
> >
> > > This line was touched by commit f235541699bc ("export.h: allow for
&g
On Mon, 9 Sep 2019, Masahiro Yamada wrote:
> This line was touched by commit f235541699bc ("export.h: allow for
> per-symbol configurable EXPORT_SYMBOL()"), but the commit log did
> not explain why.
>
> CONFIG_TRIM_UNUSED_KSYMS works for me without defined(__KERNEL__).
I'm pretty sure it was
Ping.
On Tue, 20 Aug 2019, Nicolas Pitre wrote:
> Let's rework that code to avoid large immediate values and convert some
> 64-bit variables to 32-bit ones when possible. This allows gcc to
> produce smaller and better code. This even produces optimal code on
> RISC-V.
>
Let's rework that code to avoid large immediate values and convert some
64-bit variables to 32-bit ones when possible. This allows gcc to
produce smaller and better code. This even produces optimal code on
RISC-V.
Signed-off-by: Nicolas Pitre
diff --git a/include/asm-generic/div64.h b/include
which
> could be included for builds using compilers that don't handle this
> condition safely resulting in undefined behavior.
>
> Signed-off-by: Puranjay Mohan
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Shuah Khan
Acked-by: N
On Wed, 12 Jun 2019, Gen Zhang wrote:
> On Wed, Jun 12, 2019 at 03:38:38PM +0200, Greg KH wrote:
> > On Wed, Jun 12, 2019 at 09:15:06PM +0800, Gen Zhang wrote:
> > > In function con_init(), the pointer variable vc_cons[currcons].d, vc and
> > > vc->vc_screenbuf is allocated by kzalloc().
On Sun, 9 Jun 2019, Gen Zhang wrote:
> On Sat, Jun 08, 2019 at 08:15:46PM -0400, Nicolas Pitre wrote:
> > On Sat, 8 Jun 2019, Greg KH wrote:
> >
> > > And please provide "real" names for the
> > > labels, "fail1" and &qu
.
> > >
> > > Further, since the allcoation is in a loop, we should free all the
> > > allocated memory in a loop.
> > >
> > > Signed-off-by: Gen Zhang
> > > Reviewed-by: Nicolas Pitre
> > > ---
> > > diff --git a/drivers
On Mon, 27 May 2019, Jann Horn wrote:
> On Sat, May 25, 2019 at 11:43 PM Andrew Morton
> wrote:
> > On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
> > > load_flat_shared_library() is broken: It only calls load_flat_file() if
> > > prepare_binprm() returns zero, but prepare_binprm() returns
> allocated memory in a loop.
>
> Signed-off-by: Gen Zhang
Reviewed-by: Nicolas Pitre
>
> ---
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index fdd12f8..d50f68f 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3350,10 +3350,14 @@ st
On Tue, 21 May 2019, Gen Zhang wrote:
> On Tue, May 21, 2019 at 12:30:38AM -0400, Nicolas Pitre wrote:
> > Now imagine that MIN_NR_CONSOLES is defined to 10 instead of 1.
> >
> > What happens with allocated memory if the err_vc condition is met on the
> > 5th loop?
&
On Tue, 21 May 2019, Gen Zhang wrote:
> On Mon, May 20, 2019 at 11:26:20PM -0400, Nicolas Pitre wrote:
> > On Tue, 21 May 2019, Gen Zhang wrote:
> >
> > > On Mon, May 20, 2019 at 10:55:40PM -0400, Nicolas Pitre wrote:
> > > > On Tue, 21 May 2019, Gen Zhang w
On Tue, 21 May 2019, Gen Zhang wrote:
> On Mon, May 20, 2019 at 10:55:40PM -0400, Nicolas Pitre wrote:
> > On Tue, 21 May 2019, Gen Zhang wrote:
> >
> > > In function con_init(), the pointer variable vc_cons[currcons].d, vc and
> > > vc->vc_screenbuf is
On Tue, 21 May 2019, Gen Zhang wrote:
> In function con_init(), the pointer variable vc_cons[currcons].d, vc and
> vc->vc_screenbuf is allocated a memory space via kzalloc(). And they are
> used in the following codes.
> However, when there is a memory allocation error, kzalloc() can fail.
> Thus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 2 Apr 2019, Linus Torvalds wrote:
> On Tue, Apr 2, 2019 at 7:18 AM Nicolas Pitre wrote:
> >
> > The @linaro version won't be valid much longer.
>
> Generally I like seeing these come in from the old address just to veri
The @linaro version won't be valid much longer.
Signed-off-by: Nicolas Pitre
diff --git a/.mailmap b/.mailmap
index b2cde8668d..ae2bcad06f 100644
--- a/.mailmap
+++ b/.mailmap
@@ -156,6 +156,8 @@ Morten Welinder
Morten Welinder
Mythri P K
Nguyen Anh Quynh
+Nicolas Pitre
+Nicolas Pitre
See Documentation/filesystems/mount_api.txt for more information.
>
> Signed-off-by: David Howells
> cc: Nicolas Pitre
> cc: linux-...@lists.infradead.org
> cc: linux-bl...@vger.kernel.org
Tested-by: Nicolas Pitre
Acked-by: Nicolas Pitre
>
:69:6: error: invalid operand for
> instruction
>mrc 15, 0, r3, cr0, cr0, 5
>^
> arch/arm/mach-mvebu/pmsu_ll.S:19:6: error: invalid operand for instruction
>mrc 15, 0, r0, cr0, cr0, 5 @ get the CPU ID
>^
>
> Signed-off-by: Stefan Agner
Acked-by: Nic
redefinition
> mvebu_boot_wa_start:
> ^
>
> Drop the label.
>
> Signed-off-by: Stefan Agner
Acked-by: Nicolas Pitre
> ---
> arch/arm/mach-mvebu/pmsu_ll.S | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-mvebu/pmsu_ll.S b/arch/arm/mach-mvebu/pmsu_l
On Tue, 26 Feb 2019, Yifeng Li wrote:
> In vt.c, "blank_state" will be initialized to "blank_normal_wait" in
> con_init() if AND ONLY IF ("blankinterval" > 0). If "blankinterval" is 0,
> "blank_state" will be "blank_off" (== 0), and a call to do_blank_screen()
> will always abort. Even if a
s change fixes HYP/SVC mode mismatch on Samsung Exynos5422-based Odroid
> XU3/XU4/HC1 boards.
>
> Fixes: 3721924c8154 ("ARM: 8081/1: MCPM: provide infrastructure to allow for
> MCPM loopback")
> Signed-off-by: Marek Szyprowski
Acked-by: Nicolas Pitre
> ---
> arch
Let's
fix that by moving all the scrollback handling to flush_scrollback()
where it logically belongs, and invoking it before the actual screen
clearing in csi_J(), making the code simpler in the end.
Reported-by: Matthew Whitehead
Signed-off-by: Nicolas Pitre
Tested-by: Matthew Whitehead
Fixes: 4b
added .syntax unified in the commit log of each
patch where this is added along with a link to the gcc PR. Then you may
add Acked-by: Nicolas Pitre to the whole series.
Nicolas
On Thu, 7 Feb 2019, Stefan Agner wrote:
> Use unified assembler syntax (UAL) in headers. Divided syntax is
> considered depricated. This will also allow to build the kernel
> using LLVM's integrated assembler.
>
> Signed-off-by: Stefan Agner
> ---
> arch/arm/include/asm/assembler.h | 8
On Thu, 7 Feb 2019, Stefan Agner wrote:
> Use unified assembler syntax (UAL) in macros. Divided syntax is
> considered depricated. This will also allow to build the kernel
> using LLVM's integrated assembler.
>
> Signed-off-by: Stefan Agner
> ---
> arch/arm/lib/copy_from_user.S | 2 +-
>
they
shouldn't (onli /dev/vcsa without a number should), and also fixes
/dev/vcsu that should return scrollback content when scrollback is
active but currently doesn't.
An unnecessary call to vga_set_mem_top() is also removed.
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org # v4.19+
---
I
On Mon, 14 Jan 2019, Christoph Hellwig wrote:
> Instead of setting up a kernel pointer to track the current PIO address,
> track the offset in the current page, and do an atomic kmap for the page
> while doing the actual PIO operations.
>
> Signed-off-by: Christoph Hellwig
Just a small
On Fri, 11 Jan 2019, Greg Kroah-Hartman wrote:
> On Fri, Jan 11, 2019 at 01:33:09PM -0500, Nicolas Pitre wrote:
> > I use Linux with the help of a braille display and the brltty daemon. It
> > turns out that the latest mainline kernel I can work with comes from
> > commit
On Fri, 11 Jan 2019, Vito Caputo wrote:
> On Fri, Jan 11, 2019 at 01:33:09PM -0500, Nicolas Pitre wrote:
> > I use Linux with the help of a braille display and the brltty daemon. It
> > turns out that the latest mainline kernel I can work with comes from
> > commit 231f
I use Linux with the help of a braille display and the brltty daemon. It
turns out that the latest mainline kernel I can work with comes from
commit 231f8fd0cc. Anything past that and I lose the ability to read the
console barely a few seconds after the system has booted as brltty is
thrown a
On Thu, 10 Jan 2019, Nicolas Pitre wrote:
> The vt code is just a frigging mess of integer variables and pointer
> variables referring to the same thing. It is therefore littered with
> casts all over the place. And of course I missed one in this patch.
>
> Here's a revised
On Thu, 10 Jan 2019, Nicolas Pitre wrote:
> When CONFIG_VGACON_SOFT_SCROLLBACK is selected, the VGA display memory
> index and vc_visible_origin don't change when scrollback is activated.
> The actual screen content is saved away and the scrollbackdata is copied
> over it. However
they
shouldn't (onli /dev/vcsa without a number should), and also fixes
/dev/vcsu that should return scrollback content when scrollback is
active but currently doesn't.
An unnecessary call to vga_set_mem_top() is also removed.
Signed-off-by: Nicolas Pitre
Cc: sta...@vger.kernel.org # v4.19+
---
I
to signal the first event as such even if
it might be spurious. The screen could be modified, and modified back
to its initial state before we get to read it, so users must be prepared
for that anyway.
Signed-off-by: Nicolas Pitre
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_scre
On Tue, 8 Jan 2019, Nicolas Pitre wrote:
> When VT_DISALLOCATE is used on a vt, user space waiting with poll() on
> the corresponding /dev/vcs device is not awakened. This is now fixed by
> returning POLLHUP|POLLERR to user space.
>
> Also, in the normal screen update case, we do
response in a non-error situation,
saving some confusion on the user space side. The only known user app
making use of poll() on /dev/vcs* is BRLTTY which is known to cope with
that change already, so the risk of breakage is pretty much nonexistent.
Signed-off-by: Nicolas Pitre
---
drivers/tty/vt
of breakage is pretty much nonexistent.
Signed-off-by: Nicolas Pitre
---
drivers/tty/vt/vc_screen.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index 1bbe2a30cd..1d887113ff 100644
--- a/drivers/tty/vt
-implemented /dev/vcsua* devices should be considered.
Signed-off-by: Nicolas Pitre
---
drivers/tty/vt/vc_screen.c | 5 +++--
drivers/tty/vt/vt.c| 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index 2384ea85ff
Hello Greg,
Here's a few patches fixing various issues. The first 2 are most
certainly stable material. I don't know if the other issues are serious enough
to be stable worthy though.
Please feel free to tag them as such if so.
Nicolas
1 - 100 of 2892 matches
Mail list logo
