On Thu, May 02, 2024 at 05:31:00PM -0400, Steven Rostedt wrote:
> On Wed, 1 May 2024 20:31:06 -0700
> "Paul E. McKenney" wrote:
>
> > On Thu, May 02, 2024 at 11:05:01AM +0900, Masami Hiramatsu wrote:
> > > On Wed, 1 May 2024 16:12:37 -0700
> > > "
1 +
> arch/sh/math-emu/math.c | 2 +
> arch/sh/mm/nommu.c | 2 +
> arch/sh/mm/pgtable.c| 4 +-
> arch/sh/mm/tlbex_32.c | 1 +
> 23 files changed, 68 insertions(+), 189 deletions(-)
> create mode
Hi Geert,
On Thu, 2024-05-02 at 09:03 +0200, Geert Uytterhoeven wrote:
> On Wed, May 1, 2024 at 3:58 PM John Paul Adrian Glaubitz
> wrote:
> > On Wed, 2024-05-01 at 11:12 +0200, John Paul Adrian Glaubitz wrote:
> > > On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrot
On Thu, May 02, 2024 at 11:05:01AM +0900, Masami Hiramatsu wrote:
> On Wed, 1 May 2024 16:12:37 -0700
> "Paul E. McKenney" wrote:
>
> > Note that the immediate pressure for this patch should be relieved by the
> > NAPI patch series [1], but this sort of p
registration. Therefore, make the registration-side RCU Tasks
grace period be asynchronous via call_rcu_tasks().
[1] https://lore.kernel.org/all/cover.1710877680.git@cloudflare.com/
Reported-by: Jakub Kicinski
Reported-by: Alexei Starovoitov
Reported-by: Chris Mason
Signed-off-by: Paul E
Hi Geert,
On Wed, 2024-05-01 at 11:12 +0200, John Paul Adrian Glaubitz wrote:
> Hi Geert,
>
> On Fri, 2024-03-01 at 22:02 +0100, Geert Uytterhoeven wrote:
> > dma_extend(), get_dma_info_by_name(), register_chan_caps(), and
> > request_dma_bycap() are unused. Remove them,
_32.c | 1 +
> arch/sh/math-emu/math.c | 2 +
> arch/sh/mm/nommu.c | 2 +
> arch/sh/mm/pgtable.c| 4 +-
> arch/sh/mm/tlbex_32.c | 1 +
> 23 files changed, 68 insertions(+), 189 deletions(-)
>
igned long flags);
>
> extern int register_dmac(struct dma_info *info);
> extern void unregister_dmac(struct dma_info *info);
> -extern struct dma_info *get_dma_info_by_name(const char *dmac_name);
> -
> -extern int dma_extend(unsigned int chan, unsigned long op, void *param);
> -extern int register_chan_caps(const char *dmac, struct dma_chan_caps
> *capslist);
>
> /* arch/sh/drivers/dma/dma-sysfs.c */
> extern int dma_create_sysfs_files(struct dma_channel *, struct dma_info *);
I assume we could re-add these again in case we need them, but it would be good
if Yoshinori could comment on whether we should keep these functions or not.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
atomic_set(>busy, 1);
> - return channel->chan;
> - }
> -
> - return -ENOSYS;
> -}
> -
> int request_dma(unsigned int chan, const char *dev_id)
> {
> struct dma_channel *channel = { 0 };
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
etprobe (which rely on rethook) runtime throughput
> by 2.3%, according to BPF benchmarks ([0]).
>
> [0]
> https://lore.kernel.org/bpf/caef4bzauq2wkmjzdc9s0rbwa01bybgwhn6andxqshyia47p...@mail.gmail.com/
>
> Signed-off-by: Andrii Nakryiko
Acked-by: Paul E. McKenney
> ---
&g
On Tue, Apr 09, 2024 at 11:32:48PM +0900, Masami Hiramatsu wrote:
> Hi Paul,
>
> Thanks, both looks good to me.
>
> Acked-by: Masami Hiramatsu (Google)
>
> Let me update bootconfig/fixes.
Thank you very much! As soon as I see them in -next from you, I wil
...
Fixes: 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to
/proc/bootconfig")
Signed-off-by: Zhenhua Huang
Signed-off-by: Paul E. McKenney
Cc:
Cc:
Acked-by: Masami Hiramatsu (Google)
---
fs/proc/bootconfig.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions
le. This will cause automation
to fall back to the /proc/cmdline file, which will be identical to the
comment in this no-embedded-kernel-parameters case.
Signed-off-by: Masami Hiramatsu
Signed-off-by: Paul E. McKenney
---
fs/proc/bootconfig.c | 2 +-
include/linux/bootconfig.h | 1 +
init/main.
.
Thanx, Paul
b/fs/proc/bootconfig.c | 12 ++--
b/include/linux/bootconfig.h |1 +
b/init/main.c|5 +
fs/proc/bootconfig.c |2 +-
4
On Tue, Apr 09, 2024 at 09:25:40AM +0900, Masami Hiramatsu wrote:
> On Mon, 8 Apr 2024 12:18:19 -0700
> "Paul E. McKenney" wrote:
>
> > On Sat, Apr 06, 2024 at 11:11:08AM +0900, Masami Hiramatsu wrote:
> > > On Thu, 4 Apr 2024 21:25:41 -0700
> > > "
On Sat, Apr 06, 2024 at 11:11:08AM +0900, Masami Hiramatsu wrote:
> On Thu, 4 Apr 2024 21:25:41 -0700
> "Paul E. McKenney" wrote:
>
> > On Fri, Apr 05, 2024 at 11:57:45AM +0900, Masami Hiramatsu wrote:
> > > On Fri, 5 Apr 2024 10:23:24 +0900
>
On Fri, Apr 05, 2024 at 11:57:45AM +0900, Masami Hiramatsu wrote:
> On Fri, 5 Apr 2024 10:23:24 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Thu, 4 Apr 2024 10:43:14 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Thu, Apr 04, 20
On Thu, Apr 04, 2024 at 08:55:22AM +0900, Masami Hiramatsu wrote:
> On Wed, 3 Apr 2024 12:16:28 -0700
> "Paul E. McKenney" wrote:
>
> > commit 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to
> > /proc/bootconfig") adds bootloade
On Wed, Apr 03, 2024 at 03:29:12PM -0400, Steven Rostedt wrote:
> On Wed, 3 Apr 2024 11:53:14 -0700
> "Paul E. McKenney" wrote:
>
> > @@ -5366,6 +5366,13 @@ static void remove_direct_functions_hash(struct
> > ftrace_hash *hash, unsigned long
> >
ot;fs/proc: Add boot loader arguments as comment to
/proc/bootconfig")
Signed-off-by: Zhenhua Huang
Signed-off-by: Paul E. McKenney
Cc: Masami Hiramatsu
Cc:
Cc:
diff --git a/fs/proc/bootconfig.c b/fs/proc/bootconfig.c
index 902b326e1e560..e5635a6b127b0 100644
--- a/fs/proc/bootco
, significantly slowing
trace registration. Therefore, make the registration-side RCU Tasks
grace period be asynchronous via call_rcu_tasks().
Reported-by: Jakub Kicinski
Reported-by: Alexei Starovoitov
Reported-by: Chris Mason
Signed-off-by: Paul E. McKenney
Cc: Steven Rostedt
Cc: Masami
On Fri, Mar 01, 2024 at 03:30:01PM -0500, Steven Rostedt wrote:
> On Fri, 1 Mar 2024 12:25:10 -0800
> "Paul E. McKenney" wrote:
>
> > > That would work for me. If there are no objections, I will make this
> > > change.
> >
> > But I di
On Wed, Feb 28, 2024 at 01:16:04PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:
> > On Wed, 28 Feb 2024 11:38:29 -0800
> > "Paul E. McKenney" wrote:
> >
> > > The advent of CONFIG_PREEMPT_AUTO, AKA la
On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:
> On Wed, 28 Feb 2024 11:38:29 -0800
> "Paul E. McKenney" wrote:
>
> > The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> > even kernels built with CONFIG_PREEMPT_NONE or CONFIG_
synchronize_rcu_tasks()
based on CONFIG_TASKS_RCU instead of CONFIG_PREEMPTION.
Only build tested.
Signed-off-by: Paul E. McKenney
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Mark Rutland
Cc: Mathieu Desnoyers
Cc: Ankur Arora
Cc: Thomas Gleixner
Cc:
diff --git a/kernel/trace/ftrace.c b/kernel
; someone to search for exactly where the bug happened.
>
> Reported-by: Borislav Petkov
> Signed-off-by: Steven Rostedt (Google)
Reviewed-by: Paul E. McKenney
> ---
> include/linux/tracepoint.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff
On 7 Jan 2024, at 19:22, Paul Heidekrüger wrote:
> On 12.12.2023 10:32, Marco Elver wrote:
>> On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger
>> wrote:
>>>
>>> On 12.12.2023 00:37, Andrey Konovalov wrote:
>>>> On Tue, Dec 12, 2023 at 12:35 AM Pa
On Mon, Jan 29, 2024 at 08:58:10AM +0800, Yang Jihong wrote:
> Hello,
>
> On 2024/1/28 3:22, Paul E. McKenney wrote:
> > On Tue, Jan 09, 2024 at 07:28:29PM +0800, Yang Jihong wrote:
> > > Hello,
> > >
> > > PING.
> > >
> > > I had
On Sat, Jan 27, 2024 at 06:09:05PM +0800, Chen Zhongjin wrote:
> On 2024/1/20 23:30, Paul E. McKenney wrote:
(Apologies for the delay, despite my attempts to make it otherwise,
your email still got dumped into my spam folder.)
> Hi Paul,
> This patch works for my reproduce test case.
while executing in
a trampoline.
But could you please try out the patch shown at the end of this email?
Thanx, Paul
> Thanks,
> Yang
>
> On 2024/1/2 11:40, Chen Zhongjin wrote:
> > There is a deadlock scenario in
On Fri, Jan 19, 2024 at 06:37:26AM -0800, Paul E. McKenney wrote:
> On Thu, Jan 18, 2024 at 02:18:42AM +, Chen Zhongjin wrote:
> > There is a deadlock scenario in kprobe_optimizer():
> >
> > pid A pid B pid C
exit_tasks_rcu_start() adds the
current task to this list and does ...
OK, this is getting a bit involved. If you would like to follow along,
please feel free to look here:
https://docs.google.com/document/d/1MEHHs5qbbZBzhN8dGP17pt-d87WptFJ2ZQcqS221d9I/edit?usp=sharing
Thanx, Paul
> /* Step 3: Optimize kprobes after quiesence period */
> do_optimize_kprobes();
> --
> 2.25.1
>
On Thu, Jan 18, 2024 at 06:44:54AM -0800, Paul E. McKenney wrote:
> On Wed, Jan 17, 2024 at 09:26:46PM -0500, Steven Rostedt wrote:
> > On Thu, 18 Jan 2024 02:18:42 +
> > Chen Zhongjin wrote:
> >
> > > There is a deadlock scenario in kprobe
> --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -104,7 +104,7 @@ config STATIC_CALL_SELFTEST
> > config OPTPROBES
> > def_bool y
> > depends on KPROBES && HAVE_OPTPROBES
> > - select TASKS_RCU if PREEMPTION
> > + selec
plementation, just let me know.
(The memory-ordering trick is to use "smp_mb(); smp_load_acquire();" to
sample the counter and "smp_store_release(); smp_mb();" to update it.)
Thanx, Paul
> > Signed-off-by: Chen Zhongjin
>
> Thanks. Should we backport this fix into earlier kernels? If so, are
> we able to identify a suitable Fixes: target?
On 12.12.2023 10:32, Marco Elver wrote:
> On Tue, 12 Dec 2023 at 10:19, Paul Heidekrüger
> wrote:
> >
> > On 12.12.2023 00:37, Andrey Konovalov wrote:
> > > On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
> > > wrote:
> > > >
> > >
Good catch, and what I get for testing with only a single bootconfig
parameter. :-/
Reviewed-by: Paul E. McKenney
Tested-by: Paul E. McKenney
> ---
> fs/proc/bootconfig.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/proc/bootconfig.c b/
ld pass some usable information about the object in
> question to allow SELinux to find a security context for it. Like an
> inode associated with the device, for example.
I agree with Stephen and I still remain skeptical that these hooks are
needed. Until I see a compelling case as to why the existing LSM
hooks are not sufficient I can't ACK these hooks.
--
paul-moore.com
On 12.12.2023 00:37, Andrey Konovalov wrote:
> On Tue, Dec 12, 2023 at 12:35 AM Paul Heidekrüger
> wrote:
> >
> > Using CONFIG_FTRACE=y instead of CONFIG_TRACEPOINTS=y produces the same
> > error
> > for me.
> >
> > So
> >
> >
On 11.12.2023 23:56, Marco Elver wrote:
> On Mon, 11 Dec 2023 at 23:48, Paul Heidekrüger
> wrote:
> >
> > On 11.12.2023 21:51, Andrey Konovalov wrote:
> > > On Mon, Dec 11, 2023 at 7:59 PM Paul Heidekrüger
> > > wrote:
> > > >
> > >
On 11.12.2023 21:51, Andrey Konovalov wrote:
> On Mon, Dec 11, 2023 at 7:59 PM Paul Heidekrüger
> wrote:
> >
> > > Hi Paul,
> > >
> > > I've been successfully running KASAN tests with CONFIG_TRACEPOINTS
> > > enabled on arm64 since this patch landed
Hi Andrey!
On 11.12.2023 18:50, Andrey Konovalov wrote:
> On Mon, Dec 11, 2023 at 5:37 PM Paul Heidekrüger
> wrote:
> >
> > Hi all!
> >
> > On 05.05.2023 09:58, Steven Rostedt wrote:
> > > On Mon, 1 May 2023 15:02:37 -0700
> > > Peter Collingbou
EST=y
CONFIG_TRACEPOINTS, which CONFIG_KASAN_TEST relies on since the patch this
thread is based on, isn't defined for arm64, AFAICT.
If I comment out the dependency on CONFIG_TRACEPOINTS, the tests appear to run,
but KUnit isn't picking up the KASan output.
If I revert the patch, the above .kunitconfig appears to work fine on arm64 and
the tests pass.
The above .kunitconfig works as intended on X86, no changes necessary.
Am I missing something?
Many thanks,
Paul
---
>
>
> Applied to kbuild.
>
> I did not get any report from the 0day bot so far,
> but I hope it will get a little more compile tests
> before getting into linux-next.
Haven't touched that kind of header shuffle for over 10 years?
But yeah, it is near impossible to
uot;,
> + { "devcreate", "devdestroy", "devopen", "net", "block", NULL} },
I think we can just call the permissions "create", "open", and "destroy"
since the "dev" prefix is somewhat implied by this being a dedicated
VDUSE object class.
I don't see where you are using the "net" and "block" permissions above,
is this a leftover from a prior draft of this patch or are you planning
to do something with these permissions?
> { NULL }
>};
>
> --
> 2.41.0
--
paul-moore.com
nsigned long)(o), \
> + (unsigned long)(n), \
> + sizeof(*(ptr))); \
> +})
> +
> #endif /* __ASM_SH_CMPXCHG_H */
Reviewed-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian
arch_cmpxchg_local() is
> > defined as raw "cmpxchg" without lock prefix.
> >
> > #define __cmpxchg_local(ptr, old, new, size)\
> > __raw_cmpxchg((ptr), (old), (new), (size), "")
> >
>
> Yes, you're right; s
(unsigned long)_n_, sizeof(*(ptr))); \
>})
>
> +#include
> +
> #endif /* __ASM_SH_CMPXCHG_H */
Reviewed-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
> functions).
>
> As found with Coccinelle[1], add __counted_by for struct sidtab_str_cache.
>
> [1]
> https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
>
> Cc: Paul Moore
> C
On Aug 17, 2023 Paul Moore wrote:
>
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
> (for
On Fri, 2 Jun 2023, Ira Weiny wrote:
> Paul Cassella wrote:
> > On Sat, 3 Dec 2022, Ira Weiny wrote:
> > > On Sat, Dec 03, 2022 at 09:58:58AM +, Yongqiang Liu wrote:
> > > > We should always call dax_region_put() whenever devm_create_dev_dax()
> > > &
; > - return PTR_ERR(dev_dax);
> >
> > /* child dev_dax instances now own the lifetime of the dax_region */
This comment should probably be updated now. :)
--
Paul Cassella
> > dax_region_put(dax_region);
> > - return 0;
> > +
> > + return IS_ERR(dev_dax) ? PTR_ERR(dev_dax) : 0;
> > }
> >
> > static int dax_hmem_remove(struct platform_device *pdev)
> > --
> > 2.25.1
> >
> >
>
Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it. Therefore, remove the "select SRCU"
Kconfig statements.
Signed-off-by: Paul E. McKenney
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc:
Acked-by: Dan Williams
Reviewe
On Thu, Jan 05, 2023 at 08:48:28AM -0800, Dan Williams wrote:
> Paul E. McKenney wrote:
> > Now that the SRCU Kconfig option is unconditionally selected, there is
> > no longer any point in selecting it. Therefore, remove the "select SRCU"
> > Kconfig statements.
Now that the SRCU Kconfig option is unconditionally selected, there is
no longer any point in selecting it. Therefore, remove the "select SRCU"
Kconfig statements.
Signed-off-by: Paul E. McKenney
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc:
---
drivers/dax/Kconfig | 1
On Tue, Apr 20, 2021 at 02:56:30PM +0800, kernel test robot wrote:
> Hi Paul,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 7af08140979a6e7e12b78c93b862
On 4/19/21 2:33 PM, Len Brown via Libc-alpha wrote:
the AI guys are super excited about matrix multiplication,
but I have a hard time imagining why grep(1) would find a use for it.
I don't. Matrix multiplication is used in modern string-searching
algorithms that could be useful in running
in drm_dp_mst_atomic_check_mstb_bw_limit()
Signed-off-by: Lyude Paul
Cc: Robert Foss
Reviewed-by: Robert Foss
---
drivers/gpu/drm/drm_dp_mst_topology.c | 368 +-
1 file changed, 187 insertions(+), 181 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm
_dp_dump_access
Signed-off-by: Lyude Paul
Cc: Robert Foss
Reviewed-by: Robert Foss
---
drivers/gpu/drm/drm_dp_helper.c | 121
1 file changed, 59 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
ind
we should do the same for ours.
Signed-off-by: Lyude Paul
---
include/drm/drm_print.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a3c58c941bdc..9b66be54dd16 100644
--- a/include/drm/drm_pri
, expr);
)
And correcting the indentation of the resulting code by hand.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 45 +++
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
b/drivers
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff
the drm_device to these functions instead of using drm_dp_aux.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 4 +++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3
ure to point
this out in the documentation for struct drm_dp_aux.
v3:
* Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out
Signed-off-by: Lyude Paul
Acked-by: Thierry Reding
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 7 ---
.../gpu/drm/amd/disp
bridges. So, let's fix this documentation to clarify when the right
time to use drm_dp_aux_init() or drm_dp_aux_register() is.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 57 +
1 file changed, 37 insertions(+), 20 deletions(-)
diff --git
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 25 -
1 file changed, 20 insertions(+), 5 deletions
() and hook it up in all DRM drivers
across the kernel to take care of cleaning up the i2c adapter once it's no
longer needed.
This should also fix the regressions noted in the Tegra driver.
Signed-off-by: Lyude Paul
Fixes: 39c17ae60ea9 ("drm/tegra: Don't register DP AUX channels before
conne
connector creation doesn't attempt to do any real error handling.
So, let's fix this and also cleanup amdgpu_dm_initialize_dp_connector()
while we're at it. This way we can handle the error codes from
drm_dp_aux_init().
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29
Since we're about to make it so that drm_dp_aux_init() can fail (and thus -
should have it's return value checked) - we should require that callers of
drm_dp_aux_register() also check it's return value since drm_dp_aux_init()
can be called from there.
Signed-off-by: Lyude Paul
---
include/drm
On Mon, Apr 19, 2021 at 01:35:56PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 16, 2021 at 11:47 AM Paul E. McKenney wrote:
> >
> > On Thu, Apr 15, 2021 at 11:04:37PM -0700, Nick Desaulniers wrote:
> > > On Thu, Apr 15, 2021 at 9:27 PM Boqun Feng wrote:
> > &g
On Mon, Apr 19, 2021 at 02:23:45AM +0200, Frederic Weisbecker wrote:
> On Sat, Apr 17, 2021 at 09:46:16PM -0700, Paul E. McKenney wrote:
> > On Sat, Apr 17, 2021 at 03:16:49PM +0200, Frederic Weisbecker wrote:
> > > On Wed, Apr 14, 2021 at 08:55:38AM -0700, Paul E. McKenney wro
-by: Paul Cercueil
Cheers,
-Paul
---
Notes:
v6:
New patch.
drivers/pinctrl/pinctrl-ingenic.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-ingenic.c
b/drivers/pinctrl/pinctrl-ingenic.c
index 8ed62a4..b57433d 100644
--- a/drivers/pinctrl
. ]
[ paulmck: Don't reset injectfail per Neeraj Upadhyay feedback. ]
[ paulmck: Apply Thomas Gleixner feedback. ]
Signed-off-by: Paul E. McKenney
---
.../admin-guide/kernel-parameters.txt | 6 +++
kernel/time/clocksource.c | 53 ---
2 files changed, 52
will be checked at most once.
Suggested-by: Thomas Gleixner # For verify_n_cpus=1.
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
Signed-off-by: Paul E. McKenney
---
.../admin-guide/kernel-parameters.txt | 10
from the current 62.5 milliseconds
down to 200 microseconds.
Suggested-by: Thomas Gleixner
Cc: John Stultz
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
[ paulmck: Apply Rik van Riel feedback. ]
Reported-by: Chris Mason
Signed-off-by: Paul E. McKenney
Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Cc: Jonathan Corbet
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Andi Kleen
Reported-by: Chris Mason
[ paulmck: Apply Randy Dunlap feedback. ]
Signed-off-by: Paul E. McKenney
---
Documentation/admin-guide/kernel-parameters.txt | 16
kernel
Andi Kleen
Reported-by: Chris Mason
[ paulmck: Add "static" to clocksource_verify_one_cpu() per kernel test robot
feedback. ]
[ paulmck: Apply Thomas Gleixner feedback. ]
Signed-off-by: Paul E. McKenney
---
arch/x86/kernel/tsc.c | 3 +-
include/linux/clocksource.h | 2 +-
kerne
feedback. ]
Reported-by: Chris Mason
Signed-off-by: Paul E. McKenney
---
.../admin-guide/kernel-parameters.txt | 16 +
kernel/time/clocksource.c | 23 +++
2 files changed, 39 insertions(+)
diff --git a/Documentation/admin-guide/kernel
.
Changes since v2:
o Rebased to v5.11-rc6.
o Updated Cc: list.
Changes since v1:
o Applied feedback from Rik van Riel.
o Rebased to v5.11-rc3.
o Stripped "RFC" from the subject lines.
physically in the socket. From dmesg:
smpboot: Allowing 6 CPUs, 2 hotplug CPUs
setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:6 nr_node_ids:1
rcu: RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=6.
smp: Brought up 1 node, 4 CPUs
And from userspace, see:
paul@trash:/sys/devices/syste
recently as a year ago for as yet unseen new flags.
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Peter Xu
Fixes: 3662daf02350 ("sched/isolation: Allow "isolcpus=" to skip unknown
sub-parameters")
Signed-off-by: Paul Gortmaker
diff
Zijlstra
Cc: Frederic Weisbecker
Fixes: 3662daf02350 ("sched/isolation: Allow "isolcpus=" to skip unknown
sub-parameters")
Signed-off-by: Paul Gortmaker
diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
index 5a6ea03f9882..9652dba7e938 100644
--- a/kernel/sched
her
the `BriefDescription` ends with a period or not, and whether
there is an extra space at the end.
Regardless, LGTM.
Tested-by: Paul A. Clarke
Reviewed-by: Paul A. Clarke
PC
On Sat, Apr 17, 2021 at 04:51:36PM -0700, Paul E. McKenney wrote:
> On Sat, Apr 17, 2021 at 02:47:18PM +0200, Thomas Gleixner wrote:
[ . . . ]
> > > + delta = (s64)((csnow_mid - csnow_begin) & cs->mask);
> > > + if (delta < 0)
> > > +
On Sat, Apr 17, 2021 at 03:16:49PM +0200, Frederic Weisbecker wrote:
> On Wed, Apr 14, 2021 at 08:55:38AM -0700, Paul E. McKenney wrote:
> > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > > index 75ed367d5b60..24db97cbf76b 100644
> > > --- a/kernel/rcu/rcu.
On Sat, Apr 17, 2021 at 02:47:18PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 21:36, Paul E. McKenney wrote:
>
> Bah, hit send too quick.
>
> > + cpumask_clear(_ahead);
> > + cpumask_clear(_behind);
> > + preempt_disable();
>
> Daft.
Wou
On Sat, Apr 17, 2021 at 02:28:22PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 21:36, Paul E. McKenney wrote:
> > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
> > index 1fc0962c89c0..97eeaf164296 100644
> > --- a/arch/x86/kernel/kvmclock
On Sun, Apr 18, 2021 at 01:15:26AM +0200, Thomas Gleixner wrote:
> On Sat, Apr 17 2021 at 15:54, Paul E. McKenney wrote:
> > On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote:
> >> I so wish we could just delete all of this horror instead of making it
On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote:
> On Tue, Apr 13 2021 at 21:35, Paul E. McKenney wrote:
> > #define WATCHDOG_INTERVAL (HZ >> 1)
> > #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4)
> > +#define WATCHDOG_MAX_SKEW (NSEC_PER_SEC >&
l set)
{
unsigned int idx = pin % PINS_PER_GPIO_CHIP;
unsigned int offt = pin / PINS_PER_GPIO_CHIP;
@@ -2668,7 +3131,7 @@ static inline void
jz4730_config_pin_function(struct ingenic_pinctrl *jzpc,
}
static inline bool ingenic_get_pin_config(struct ingenic_pinctrl
*jzpc,
-
Hi Zhou,
Le sam. 17 avril 2021 à 0:14, 周琰杰 (Zhou Yanjie)
a écrit :
Add support for probing the pinctrl-ingenic driver on the
JZ4775 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
Cheers,
-Paul
---
Notes:
v3:
New
Hi Zhou,
Le sam. 17 avril 2021 à 0:14, 周琰杰 (Zhou Yanjie)
a écrit :
Add support for probing the pinctrl-ingenic driver on the
JZ4755 SoC from Ingenic.
Signed-off-by: 周琰杰 (Zhou Yanjie)
Reviewed-by: Andy Shevchenko
Reviewed-by: Paul Cercueil
Cheers,
-Paul
---
Notes:
v3:
New
1 - 100 of 49960 matches
Mail list logo
