On 06.11.20 18:32, Pavel Procopiuc wrote:
Op 05.11.2020 om 21:23 schreef David Hildenbrand:
So just to make sure I understand you correctly, you'd like to see if the
problem with ath11k driver on my hardware persists when I boot pristine
5.10-rc2 kernel (without reverting commit
7fef431be9c9a
On Fri, Nov 6, 2020 at 12:49 AM Wang Qing wrote:
>
> Fix smatch warning.
>
> Signed-off-by: Wang Qing
> ---
> kernel/trace/bpf_trace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 4517c8b..2cb9c45
> --- a/ker
U00DE,
In order to complete your account registration, you must type the following
command on IRC:
/msg NickServ VERIFY REGISTER U00DE nkbcesqxwrsj
Thank you for registering your account on the freenode IRC network!
--
This e-mail was sent due to a command from
U00DE[5fd80...@static.197.15.216
On Wed, Oct 28, 2020 at 10:09:38PM +, Suzuki K Poulose wrote:
> In preparation to detect the support for system instruction
> support, move the detection of the device access to the target
> CPU.
>
> Signed-off-by: Suzuki K Poulose
> ---
> .../coresight/coresight-etm4x-core.c | 45 +
Hi,
Fix a few typos:
On 11/6/20 12:32 PM, Minchan Kim wrote:
> ---
> Documentation/admin-guide/sysctl/vm.rst | 14 ++
> include/linux/mm.h | 2 ++
> include/linux/oom.h | 1 +
> kernel/sysctl.c | 9 +
> mm/oo
Hi Artem,
On Wed, 2020-11-04 at 14:21 +0200, Artem Bityutskiy wrote:
> From: Artem Bityutskiy
>
> The documentation refers to a non-existent 'struct synth_trace_state'
> structure. The correct name is 'struct synth_event_trace_state'.
>
> In other words, this patch is a mechanical substitution:
On Fri, Nov 06, 2020 at 07:33:33PM +0800, Alex Shi wrote:
> The page->mem_cgroup member is replaced by memcg_data, and add a helper
> page_memcg() for it. Need to update comments to avoid confusing.
Hi Alex,
thank you for bringing it in!
I definitely missed those.
>
> Signed-off-by: Alex Shi
>
On Fri, Nov 06, 2020 at 12:29:23PM -0800, Shakeel Butt wrote:
> A VCPU of a VM can allocate couple of pages which can be mmap'ed by the
> user space application. At the moment this memory is not charged to the
> memcg of the VMM. On a large machine running large number of VMs or
> small number of V
on x86_64:
ld: sound/soc/sof/sof-pci-dev.o: in function `sof_pci_probe':
sof-pci-dev.c:(.text+0x5c): undefined reference to `snd_intel_dsp_driver_probe'
Full randconfig file is attached.
Nice catch, thanks Randy! Looks like we put the select
SND_INTEL_DSP_CONFIG in the wrong place, it's n
All,
I am getting ready to send the next v9 series based on tip/master
branch. Could you please give the below tree a try and report any results in
your testing?
git tree:
https://git.kernel.org/pub/scm/linux/kernel/git/jfern/linux.git (branch
coresched)
git log:
https://git.kernel.org/pub/scm/li
On Mon, Nov 02, 2020 at 01:21:39PM +0800, Rong Chen wrote:
> we compared the tmpfs.ops_per_sec: (363 / 103.02) between this commit and
> parent commit.
Thanks! I see about a 50% hit on my system, and this patch restores the
performance. Can you verify this works for you?
diff --git a/mm/madvise
On 11/5/20 11:55 PM, Christoph Hellwig wrote:
On Thu, Nov 05, 2020 at 04:51:42PM -0800, Ralph Campbell wrote:
+extern void prep_transhuge_device_private_page(struct page *page);
No need for the extern.
Right, I was just copying the style.
Would you like to see a preparatory patch that remo
On Fri, 2020-11-06 at 00:59 +0530, Sunil Kovvuri wrote:
> > > > > Output:
> > > > > # ./devlink health
> > > > > pci/0002:01:00.0:
> > > > >reporter npa
> > > > > state healthy error 0 recover 0
> > > > >reporter nix
> > > > > state healthy error 0 recover 0
> > > > > # ./devli
On Thu, 2020-11-05 at 21:26 +0530, Anmol Karn wrote:
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurance of the `neigh`
> is in rose_loopback_timer() as `rose_loopback_neigh`, and it is
> initialized
> in rose_add_loopback_neigh()
On Fri, Nov 06, 2020 at 03:40:08PM -0500, Alan Stern wrote:
> On Fri, Nov 06, 2020 at 11:59:12AM -0800, Paul E. McKenney wrote:
> > On Fri, Nov 06, 2020 at 02:23:51PM -0500, Alan Stern wrote:
> > > On Fri, Nov 06, 2020 at 10:04:46AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Nov 06, 2020 at 11:
On 11/6/20 12:01 AM, Christoph Hellwig wrote:
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+extern struct page *alloc_transhugepage(struct vm_area_struct *vma,
+ unsigned long addr);
No need for the extern. And also here: do we actually need the stub,
or can the
On Fri, Nov 06, 2020 at 09:12:45PM +0100, Krzysztof Kozlowski wrote:
> On Thu, Nov 05, 2020 at 08:55:08PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > The Power Management Unit (PMU) is a separate device which has little
> > > > > common with clock controller. Moving it to one level up (from
On Wed, Oct 28, 2020 at 10:09:39PM +, Suzuki K Poulose wrote:
> We are about to rely on TRCDEVARCH for detecting the ETM
> and its architecture version, falling back to TRCIDR1 if
> the former is not implemented (in older broken implementations).
>
> Also, we use the architecture version infor
On 11/03, Chao Yu wrote:
> On 2020/11/3 10:02, Chao Yu wrote:
> > On 2020/11/3 0:31, Jaegeuk Kim wrote:
> > > On 11/02, Chao Yu wrote:
> > > > This patch supports to store chksum value with compressed
> > > > data, and verify the integrality of compressed data while
> > > > reading the data.
> > >
The pull request you sent on Thu, 5 Nov 2020 21:13:08 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/
> tags/arc-5.10-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4257087e8feb2e6f918eb0773eb1c1a697dd2a39
Thank you!
--
Deet-doot-dot, I a
The pull request you sent on Fri, 6 Nov 2020 18:25:52 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
> tags/tpmdd-next-v5.10-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/28ced768a4262bc81c61c8244e0e57048afc18d1
Thank you!
--
Dee
On Fri, Nov 06, 2020 at 11:43:59AM -0600, Dr. Greg wrote:
> The 900 pound primate in the room, that no one is acknowledging, is
> that this technology was designed to not allow the operating system to
> have any control over what it is doing. In the mindset of kernel
> developers, the operating sy
The pull request you sent on Thu, 5 Nov 2020 13:51:57 -0700:
> git://github.com/awilliam/linux-vfio.git tags/vfio-v5.10-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1669ecf9c884c639c4a83859e33a24d892aec790
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.
The pull request you sent on Fri, 6 Nov 2020 20:43:11 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bf3e76289cd28b87f679cd53e26d67fd708d718a
Thank you!
--
Deet-doot-dot, I am a bot.
http
The pull request you sent on Thu, 5 Nov 2020 11:25:08 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-5.10-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/41f16530241405819ae5644b6544965ab124bbda
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Fri, 6 Nov 2020 17:23:08 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.10-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/02a2aa3500a993c9f0812b8564d36d63b8d49ce4
Thank you!
--
Deet-doot-
The pull request you sent on Fri, 6 Nov 2020 13:20:35 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/30f3f68e27d14a237acc339975e18670e58927ca
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Fri, 6 Nov 2020 14:21:13 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-06-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc7b66ef076644dd646eb9f11563684edc479649
Thank you!
--
Deet-doot-dot, I am a bot.
https://
The pull request you sent on Fri, 06 Nov 2020 09:20:50 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> tags/sound-5.10-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bb72bbe8f6c70e67c85d773e5c9b04c7fe36a0ab
Thank you!
--
Deet-doot-dot,
The pull request you sent on Thu, 5 Nov 2020 21:12:02 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.10-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ee51814888278677cb4384814bbe3c95f6270b50
Thank you!
--
Deet-doot-dot, I am a b
The pull request you sent on Fri, 06 Nov 2020 17:37:59 +:
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
> tags/spi-fix-v5.10-rc2-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44d80621857f916f1370782cdd20c9359ccc5eea
Thank you!
--
Deet-doo
On Thu, Nov 5, 2020 at 3:06 PM KP Singh wrote:
>
> From: KP Singh
>
> The current logic checks if the name of the BTF type passed in
> attach_btf_id starts with "bpf_lsm_", this is not sufficient as it also
> allows attachment to non-LSM hooks like the very function that performs
> this check, i.
On 21/10/20 16:03, Aubrey Li wrote:
> From: Aubrey Li
>
> Added idle cpumask to track idle cpus in sched domain. When a CPU
> enters idle, its corresponding bit in the idle cpumask will be set,
> and when the CPU exits idle, its bit will be cleared.
>
> When a task wakes up to select an idle cpu
Hello:
This patch was applied to bpf/bpf.git (refs/heads/master):
On Thu, 5 Nov 2020 23:06:51 + you wrote:
> From: KP Singh
>
> The current logic checks if the name of the BTF type passed in
> attach_btf_id starts with "bpf_lsm_", this is not sufficient as it also
> allows attachment to no
we have supplied the inline function: of_cft() in cgroup.h.
So replace the direct use 'of->kn->priv' with inline func
of_cft(), which is more readable.
Signed-off-by: Hui Su
---
kernel/cgroup/cgroup.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/cgroup/cgro
On 04/11/20 11:52, Li, Aubrey wrote:
> On 2020/11/4 3:27, Valentin Schneider wrote:
>>> +static DEFINE_PER_CPU(bool, cpu_idle_state);
>>
>> I would've expected this to be far less compact than a cpumask, but that's
>> not the story readelf is telling me. Objdump tells me this is recouping
>> some
On 11/6/20 1:13 PM, Matthew Wilcox wrote:
> On Fri, Nov 06, 2020 at 11:43:59AM -0600, Dr. Greg wrote:
>> The 900 pound primate in the room, that no one is acknowledging, is
>> that this technology was designed to not allow the operating system to
>> have any control over what it is doing. In the m
On 11/6/20 12:03 AM, Christoph Hellwig wrote:
I hate the extra pin count magic here. IMHO we really need to finish
off the series to get rid of the extra references on the ZONE_DEVICE
pages first.
First, thanks for the review comments.
I don't like the extra refcount either, that is why I t
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 63c1b4db662a0967dd7839a2fbaa5300e553901d
Gitweb:
https://git.kernel.org/tip/63c1b4db662a0967dd7839a2fbaa5300e553901d
Author:Mike Galbraith
AuthorDate:Wed, 04 Nov 2020 16:12:44 +01:00
Com
We are trying to reach you as regards the estate of Late George Brumley, you
were made one of the beneficiaries of his estate. Do get back to me at your
earliest convenience. The Trustees
From: Kan Liang
Sometimes the PMU internal buffers have to be flushed for per-CPU events
during a context switch, e.g., large PEBS. Otherwise, the perf tool may
report samples in locations that do not belong to the process where the
samples are processed in, because PEBS does not tag samples with
From: Kan Liang
Some calls to sched_task() in a context switch can be avoided. For
example, large PEBS only requires flushing the buffer in context switch
out. The current code still invokes the sched_task() for large PEBS in
context switch in.
The current code doesn't know and check the states
From: Kan Liang
To supply a PID/TID for large PEBS, it requires flushing the PEBS buffer
in a context switch.
Set PERF_ATTACH_SCHED_CB for the event with large PEBS.
Fixes: 9c964efa4330 ("perf/x86/intel: Drain the PEBS buffer during context
switches")
Signed-off-by: Kan Liang
---
arch/x86/ev
On Thu, Nov 5, 2020 at 11:12 PM wrote:
>
> From: Kaixu Xia
>
> Fix following warning from coccinelle:
>
> ./tools/lib/bpf/libbpf.c:1478:43-48: WARNING: conversion to bool not needed
> here
>
> Signed-off-by: Kaixu Xia
> ---
> tools/lib/bpf/libbpf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 d
On Fri, Nov 6, 2020 at 12:03 PM Zi Yan wrote:
>
> On 3 Nov 2020, at 8:03, Yang Shi wrote:
>
> > When unmap_and_move{_huge_page}() returns !-EAGAIN and !MIGRATEPAGE_SUCCESS,
> > the page would be put back to LRU or proper list if it is non-LRU movable
> > page. But, the callers always call putback
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
v1 => v2:
- Added tags
- Satisfied Miquel's review comments
Lee Jones (23):
mtd: mtdpart: Fix misdocumented function parameter 'mtd'
mtd: d
Fixes the following W=1 kernel build warning(s):
drivers/mtd/ubi/gluebi.c:446: warning: Function parameter or member 'ns_ptr'
not described in 'gluebi_notify'
drivers/mtd/ubi/gluebi.c:446: warning: Excess function parameter 'ptr'
description in 'gluebi_notify'
Cc: Richard Weinberger
Cc: Miqu
Fixes the following W=1 kernel build warning(s):
drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or
member 'np' not described in 'hisi_spi_nor_register'
drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter or
member 'host' not described in 'hi
This patch also places the descriptions in the correct order.
Fixes the following W=1 kernel build warning(s):
drivers/mtd/devices/docg3.c:819: warning: bad line:
drivers/mtd/devices/docg3.c:1799: warning: Excess function parameter 'base'
description in 'doc_probe_device'
Cc: Robert Jarzmik
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/onenand/onenand_base.c:140: warning: Function parameter or
member 'mtd' not described in 'onenand_ooblayout_32_64_ecc'
drivers/mtd/nand/onenand/onenand_base.c:140: warning: Function parameter or
member 'section' not described in
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/cafe_nand.c:372: warning: Function parameter or member
'page' not described in 'cafe_nand_read_page'
drivers/mtd/nand/raw/cafe_nand.c:372: warning: Excess function parameter 'mtd'
description in 'cafe_nand_read_page'
Cc: Mi
Fixes the following W=1 kernel build warning(s):
drivers/mtd/ubi/build.c:61: warning: Function parameter or member 'ubi_num'
not described in 'mtd_dev_param'
Cc: Richard Weinberger
Cc: Miquel Raynal
Cc: Vignesh Raghavendra
Cc: linux-...@lists.infradead.org
Signed-off-by: Lee Jones
---
driv
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/spi/toshiba.c:36: warning: Function parameter or member
'write_cache_variants' not described in 'SPINAND_OP_VARIANTS'
drivers/mtd/nand/spi/toshiba.c:36: warning: Function parameter or member '0'
not described in 'SPINAND_OP_VARI
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/onenand/onenand_base.c:140: warning: Function parameter or
member 'mtd' not described in 'onenand_ooblayout_32_64_ecc'
drivers/mtd/nand/onenand/onenand_base.c:140: warning: Function parameter or
member 'section' not described in
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/omap2.c:191: warning: Function parameter or member 'info'
not described in 'omap_prefetch_enable'
drivers/mtd/nand/raw/omap2.c:221: warning: Function parameter or member 'cs'
not described in 'omap_prefetch_reset'
drivers/m
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/brcmnand/brcmnand.c:1854: warning: Function parameter or
member 'host' not described in 'brcmnand_edu_trans'
drivers/mtd/nand/raw/brcmnand/brcmnand.c:1854: warning: Function parameter or
member 'addr' not described in 'brcmn
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/sunxi_nand.c:250: warning: Function parameter or member
'caps' not described in 'sunxi_nfc'
Cc: Miquel Raynal
Cc: Richard Weinberger
Cc: Vignesh Raghavendra
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Philipp Zabel
Cc: Boris
Fixes the following W=1 kernel build warning(s):
drivers/mtd/ubi/wl.c:584: warning: Function parameter or member 'nested' not
described in 'schedule_erase'
drivers/mtd/ubi/wl.c:1075: warning: Excess function parameter 'shutdown'
description in '__erase_worker'
Cc: Richard Weinberger
Cc: Miqu
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/arasan-nand-controller.c:133: warning: Function parameter
or member 'buf' not described in 'anfc_op'
Cc: Naga Sureshkumar Relli
Cc: Miquel Raynal
Cc: Richard Weinberger
Cc: Vignesh Raghavendra
Cc: Choudary Kalluri
Cc: li
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/omap_elm.c:102: warning: Function parameter or member
'ecc_steps' not described in 'elm_config'
drivers/mtd/nand/raw/omap_elm.c:102: warning: Function parameter or member
'ecc_step_size' not described in 'elm_config'
driver
Fixes the following W=1 kernel build warning(s):
drivers/mtd/mtdpart.c:300: warning: Function parameter or member 'mtd' not
described in '__mtd_del_partition'
drivers/mtd/mtdpart.c:300: warning: Excess function parameter 'priv'
description in '__mtd_del_partition'
Cc: Miquel Raynal
Cc: Richa
Fixes the following W=1 kernel build warning(s):
drivers/mtd/ubi/eba.c:1304: warning: Function parameter or member 'vidb' not
described in 'ubi_eba_copy_leb'
drivers/mtd/ubi/eba.c:1304: warning: Excess function parameter 'vid_hdr'
description in 'ubi_eba_copy_leb'
drivers/mtd/ubi/eba.c:1483:
Correct 'controller' typo while we're at it.
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/s3c2410.c:172: warning: Function parameter or member
'controller' not described in 's3c2410_nand_info'
drivers/mtd/nand/raw/s3c2410.c:172: warning: Function parameter or member
'
Fixes the following W=1 kernel build warning(s):
drivers/mtd/devices/powernv_flash.c:129: warning: Cannot understand * @mtd:
the device
drivers/mtd/devices/powernv_flash.c:145: warning: Cannot understand * @mtd:
the device
drivers/mtd/devices/powernv_flash.c:161: warning: Cannot understand
'dummy' is never checked (as per the nomenclature) and the use of
'emtpymatch' is currently #if 0'ed out. We could also #if 0 the
declaration, but #ifery is pretty ugly, so I like to keep it to a
minimum.
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/raw/diskonchip.c: In fun
Fixes the following W=1 kernel build warning(s):
drivers/mtd/mtdcore.c:1592: warning: Function parameter or member 'section'
not described in 'mtd_ooblayout_find_eccregion'
drivers/mtd/mtdcore.c:1592: warning: Excess function parameter 'sectionp'
description in 'mtd_ooblayout_find_eccregion'
Fixes the following W=1 kernel build warning(s):
drivers/mtd/devices/phram.c:19: warning: Function parameter or member 'fmt'
not described in 'pr_fmt'
Cc: Miquel Raynal
Cc: Richard Weinberger
Cc: Vignesh Raghavendra
Cc: "Jochen Schäuble"
Cc: linux-...@lists.infradead.org
Signed-off-by: Lee
Fixes the following W=1 kernel build warning(s):
drivers/mtd/ubi/kapi.c:464: warning: Function parameter or member 'sgl' not
described in 'ubi_leb_read_sg'
drivers/mtd/ubi/kapi.c:464: warning: Excess function parameter 'buf'
description in 'ubi_leb_read_sg'
Cc: Richard Weinberger
Cc: Miquel
Fixes the following W=1 kernel build warning(s):
drivers/mtd/nand/onenand/onenand_bbt.c:33: warning: Function parameter or
member 'buf' not described in 'check_short_pattern'
drivers/mtd/nand/onenand/onenand_bbt.c:33: warning: Function parameter or
member 'len' not described in 'check_short_pa
On Fri, Nov 06, 2020 at 12:20:13PM +, Mark Brown wrote:
> On Fri, Nov 06, 2020 at 11:54:23AM +, Mark Brown wrote:
> > On Mon, 2 Nov 2020 09:52:26 +0800, Shengjiu Wang wrote:
> > > AUD2HTX (Audio Subsystem TO HDMI TX Subsystem) is a new
> > > IP module found on i.MX8MP.
> >
> > Applied to
>
On 11/06, Chao Yu wrote:
> On 2020/11/6 8:05, Eric Biggers wrote:
> > This patch is marked 2/2, but it seems you sent it out on its own. Patch
> > series
> > are supposed to be resend in full; otherwise people can see just one patch
> > and
> > have no context.
>
> That's a historical problem,
On Wed, Oct 28, 2020 at 10:09:40PM +, Suzuki K Poulose wrote:
> We have been using TRCIDR1 for detecting the ETM version. This
> is in preparation for the future IP support.
>
> Signed-off-by: Suzuki K Poulose
> ---
> .../coresight/coresight-etm4x-core.c | 46 +--
>
Hello RT-list!
I'm pleased to announce the 4.14.204-rt98 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.14-rt
Head SHA1: a732a33d9a454d33d99df2eb900c33039b23d5e2
Or to build 4.14.204-rt98 direc
From: "Steven Rostedt (VMware)"
Currently, the only way to get access to the registers of a function via a
ftrace callback is to set the "FL_SAVE_REGS" bit in the ftrace_ops. But as this
saves all regs as if a breakpoint were to trigger (for use with kprobes), it
is expensive.
The regs are alrea
From: "Steven Rostedt (VMware)"
In preparation to have arguments of a function passed to callbacks attached
to functions as default, change the default callback prototype to receive a
struct ftrace_regs as the forth parameter instead of a pt_regs.
For callbacks that set the FL_SAVE_REGS flag in
This is something I wanted to implement a long time ago, but held off until
there was a good reason to do so. Now it appears that having access to the
arguments of the function by default is very useful. As a bonus, because
arguments must be saved regardless before calling a callback, because the
From: "Steven Rostedt (VMware)"
When CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS is available, the ftrace call
will be able to set the ip of the calling function. This will improve the
performance of live kernel patching where it does not need all the regs to
be stored just to change the instruction poi
On Fri, Nov 6, 2020 at 7:03 PM Nathan Chancellor
wrote:
> On Fri, Nov 06, 2020 at 03:46:36PM +0100, Arnd Bergmann wrote:
> >
> > If it is intentional that we now silently build this code with clang
> > without it working as intended, that should be mentioned in the
> > changelog.
>
> Maybe patch 2
checkpatch doesn't report warnings for many common mistakes
in emails. Some of which are trailing commas and incorrect
use of email comments.
At the same time several false positives are reported due to
incorrect handling of mail comments. The most common of which
is due to the pattern:
# X.X
I
On 13:32-20201106, Peter Ujfalusi wrote:
[...]
> >
> >>
> >>> default power management functionality etc
> >>
> >> Right, so how does that helps with devices present in the SoC, but no
> >> node at all? First thing which comes to mind is AA
On Fri, Nov 6, 2020 at 6:32 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> This is the third version of my seires, now spanning four patches
> instead of two, with a new approach for handling struct ifreq
> compatibility after I realized that my earlier approach introduces
> additional probl
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_drv.c:2: warning: Cannot understand * file
radeon_drv.c
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gareth Hughes
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesk
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_range_manager.c:46: warning: cannot understand
function prototype: 'struct ttm_range_manager '
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Le
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
There are 5000 warnings to work through. It will take a couple more
sets. Although, ("drm/amd/display/dc/basics/fixpt31_32: Move
variables to wher
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/atombios_crtc.c:1796: warning: Excess function
parameter 'encoder' description in 'radeon_get_shared_nondp_ppll'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.or
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Function parameter or member
'dev' not described in 'radeon_info_ioctl'
drivers/gpu/drm/radeon/radeon_kms.c:226: warning: Excess function parameter
'rdev' description in 'radeon_info_ioctl'
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mga/mga_dma.c:29: warning: Cannot understand * file mga_dma.c
drivers/gpu/drm/mga/mga_dma.c:455: warning: Function parameter or member 'dev'
not described in 'mga_do_agp_dma_bootstrap'
drivers/gpu/drm/mga/mga_dma.c:455: warning:
Also rid some unused ones.
This patch solves 2000 warnings!
Fixes the following W=1 kernel build warning(s):
In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from drivers/gpu/drm/amd/amdgpu/../d
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/v3d/v3d_drv.c:73:32: warning: ‘v3d_v3d_pm_ops’ defined but not
used [-Wunused-const-variable=]
Cc: Eric Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Zabel
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
On Fri, 2020-11-06 at 13:32 -0800, Andrii Nakryiko wrote:
> On Thu, Nov 5, 2020 at 11:12 PM wrote:
> > Fix following warning from coccinelle:
> > ./tools/lib/bpf/libbpf.c:1478:43-48: WARNING: conversion to bool not needed
> > here
[]
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.
Place it on the heap instead.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c: In function ‘amdgpu_info_ioctl’:
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:979:1: warning: the frame size of 1128
bytes is larger than 1024 bytes [-Wframe-larger-than=]
Cc: Al
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:594: warning: Function parameter or
member 'reg_addr' not described in 'amdgpu_device_indirect_rreg'
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:624: warning: Function parameter or
member 'reg_addr' not
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_kms.c:756:5: warning: no previous prototype for
‘radeon_get_vblank_counter_kms’ [-Wmissing-prototypes]
756 | u32 radeon_get_vblank_counter_kms(struct drm_crtc *crtc)
| ^
drivers/gpu/drm/
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_gem.c:593: warning: Function parameter or member
'file' not described in 'omap_gem_dumb_create'
drivers/gpu/drm/omapdrm/omap_gem.c:593: warning: Excess function parameter
'drm_file' description in 'omap_gem_dumb_crea
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_kms.c:61:6: warning: no previous prototype for
‘radeon_driver_unload_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:104:5: warning: no previous prototype for
‘radeon_driver_load_kms’ [-Wmissing-prot
There is too much data being stored on the stack.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c: In function
‘sideband_msg_req_encode_decode’:
drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c:168:1: warning: the frame
size of 1072 bytes
Fixes the following W=1 kernel build warning(s):
62 | void radeon_driver_unload_kms(struct drm_device *dev)
| ^~~~
drivers/gpu/drm/radeon/radeon_kms.c:105:5: warning: no previous prototype for
‘radeon_driver_load_kms’ [-Wmissing-prototypes]
105 | int radeon_driver_load_kms
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:313: warning: Function parameter or
member 'dmm' not described in 'dmm_txn_init'
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:313: warning: Function parameter or
member 'tcm' not described in 'dmm_txn_init'
Unfortunately, a suitable one didn't already exist.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:637:6: warning: no previous prototype
for ‘radeon_device_is_virtual’ [-Wmissing-prototypes]
637 | bool radeon_device_is_virtual(void)
| ^
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/r128/ati_pcigart.c:2: warning: Cannot understand * file
ati_pcigart.c
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gareth Hughes
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/r128/ati_pcigart.c |
801 - 900 of 1117 matches
Mail list logo
