From: Rob Clark
Similar to the previous patch, clear shadow on suspend to avoid timeouts
waiting for ringbuffer space.
Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as
privileged")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +++-
1
From: Rob Clark
Clear the shadow rptr on suspend. Otherwise, when we resume, we can
have a stale value until CP_WHERE_AM_I executes. If we suspend near
the ringbuffer wraparound point, this can lead to a chicken/egg
situation where we are waiting for ringbuffer space to write the
CP_WHERE_AM_I
On Thu, Oct 29, 2020 at 11:14:32AM +0100, Christoph Hellwig wrote:
> Merge __follow_pte_pmd, follow_pte_pmd and follow_pte into a single
> follow_pte function and just pass two additional NULL arguments for
> the two previous follow_pte callers.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by:
On Tue, Nov 10, 2020 at 5:02 AM Denis Kirjanov wrote:
>
> On 11/10/20, xiakaixu1...@gmail.com wrote:
> > From: Kaixu Xia
> >
> > The unsigned variable datasec_id is assigned a return value from the call
> > to check_pseudo_btf_id(), which may return negative error code.
> >
> > Fixes coccicheck
On Fri, Oct 23, 2020 at 1:02 PM Chen Yu wrote:
>
> Currently there are 4 driver flags to control system suspend/resume
> behavior: DPM_FLAG_NO_DIRECT_COMPLETE, DPM_FLAG_SMART_PREPARE,
> DPM_FLAG_SMART_SUSPEND and DPM_FLAG_MAY_SKIP_RESUME. Print these flags
> during suspend resume so as to get a
> -Original Message-
> From: David Gow
>
> On Mon, Nov 9, 2020 at 2:49 PM Arpitha Raghunandan <98.a...@gmail.com> wrote:
> >
> > On 07/11/20 3:36 pm, Marco Elver wrote:
> > > On Sat, 7 Nov 2020 at 05:58, David Gow wrote:
> > >> On Sat, Nov 7, 2020 at 3:22 AM Arpitha Raghunandan
NUMA topologies where the shortest path between some two nodes requires
three or more hops (i.e. diameter > 2) end up being misrepresented in the
scheduler topology structures.
This is currently detected when booting a kernel with CONFIG_SCHED_DEBUG=y
+ sched_debug on the cmdline, although this
On Tue, 2020-11-10 at 10:49 +0100, Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 09:39:34AM +0100, Giovanni Gherdovich wrote:
>
> > +#ifdef CONFIG_ACPI
> > +void init_freq_invariance_cppc(void)
> > +{
> > + init_freq_invariance(false, true);
> > +
> > + if
This patch fixes/removes some obsolete comments in the code related
to the kernel memory accounting:
- kmem_cache->memcg_params.memcg_caches has been removed
by commit 9855609bde03 ("mm: memcg/slab: use a single set of
kmem_caches for all accounted allocations")
- memcg->kmemcg_id is not used
On Tue, Nov 10, 2020 at 10:44:00AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Similar to the previous patch, clear shadow on suspend to avoid timeouts
> waiting for ringbuffer space.
>
> Fixes: 8907afb476ac ("drm/msm: Allow a5xx to mark the RPTR shadow as
> privileged")
> Signed-off-by: Rob
On Tue, Nov 10, 2020 at 10:43:59AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Clear the shadow rptr on suspend. Otherwise, when we resume, we can
> have a stale value until CP_WHERE_AM_I executes. If we suspend near
> the ringbuffer wraparound point, this can lead to a chicken/egg
>
On Fri, Oct 16, 2020 at 03:51:25PM -0700, Kees Cook wrote:
> On Fri, Oct 16, 2020 at 12:53:13PM +0200, Peter Zijlstra wrote:
> > That's like saying: "I'm too lazy to track what I've looked at already".
> > You're basically proposing to graffiti "Kees was here -- 16/10/2020" all
> > over the
Document and adjust the compatibles for i.MX7S based boards.
The Toradex boards use multiple compatibles.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
---
Changes since v1:
1. Rebase,
2. Add Rob's review.
---
Documentation/devicetree/bindings/arm/fsl.yaml | 12 +---
1
There are four flavors of TechNexion PICO-IMX6 boards. They have their
own DTSes, even though in Dwarf, Nymph and Pi are exactly the same.
They also have their own bindings so adjust the compatibles to match the
bindings.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. None
---
Tsuchiya Yuto wrote:
> When a PCIe function level reset (FLR) is performed but without fw reset for
> some reasons (e.g., on Microsoft Surface devices, fw reset requires other
> quirks), it fails to reset wifi properly. You can trigger the issue on such
> devices via debugfs entry for reset:
>
On Tue, Nov 10, 2020 at 10:46:15AM -0800, Roman Gushchin wrote:
> This patch fixes/removes some obsolete comments in the code related
> to the kernel memory accounting:
> - kmem_cache->memcg_params.memcg_caches has been removed
> by commit 9855609bde03 ("mm: memcg/slab: use a single set of
>
On Mon, Nov 9, 2020 at 7:29 PM Alexander Lobakin wrote:
>
> From: Alexander Lobakin
> Date: Tue, 10 Nov 2020 00:17:18 +
>
> > While testing UDP GSO fraglists forwarding through driver that uses
> > Fast GRO (via napi_gro_frags()), I was observing lots of out-of-order
> > iperf packets:
> >
>
Tsuchiya Yuto wrote:
> If a reset is performed, but even the reset fails for some reasons (e.g.,
> on Surface devices, the fw reset requires another quirks),
> cancel_work_sync() hangs in mwifiex_cleanup_pcie().
>
> # firmware went into a bad state
> [...]
> [ 1608.281690]
On Tue, Nov 10, 2020 at 5:35 AM Linus Walleij wrote:
> On Fri, Nov 6, 2020 at 5:27 AM John Stultz wrote:
>
> > Allow the qcom_scm driver to be loadable as a permenent module.
> >
...
> I applied this patch to the pinctrl tree as well, I suppose
> that was the intention. If someone gets upset I
On Thu, Sep 03, 2020 at 09:53:25PM +0200, Krzysztof Kozlowski wrote:
> Cover the dt-bindings of mailbox drivers by mailbox maintainers entry.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. New patch
Jassi,
Any comments on this patch?
Best regards,
Krzysztof
Em Tue, Nov 10, 2020 at 07:23:34PM +0100, Jiri Olsa escreveu:
> On Tue, Nov 10, 2020 at 11:10:46AM +0100, Jiri Olsa wrote:
> > On Tue, Nov 10, 2020 at 09:28:51AM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 09, 2020 at 10:53:54PM +0100, Jiri Olsa wrote:
> > > > There's new misc bit for mmap2 to
Hello,
syzbot found the following issue on:
HEAD commit:521b619a Merge tag 'linux-kselftest-kunit-fixes-5.10-rc3' ..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=173b8fb650
kernel config: https://syzkaller.appspot.com/x/.config?x=61033507391c77ff
On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>> If I could get post-5.5 kernels to boot at all with the AMD IOMMU
>> enabled, I'd have a go at throwing that together now...
>
> It can share the dmar domain code. Let me frob something.
On Fri, Nov 06, 2020 at 03:48:16PM +0800, Alex Shi wrote:
> From 84e69f892119d99612e9668e3fe47a3922bafff1 Mon Sep 17 00:00:00 2001
> From: Alex Shi
> Date: Tue, 18 Aug 2020 16:44:21 +0800
> Subject: [PATCH v21 17/19] mm/lru: replace pgdat lru_lock with lruvec lock
>
> This patch moves per node
Wang Qing wrote:
> workarould -> workaround
>
> Signed-off-by: Wang Qing
Patch applied to wireless-drivers-next.git, thanks.
dd90fc4630d2 rtlwifi: fix spelling typo of workaround
--
On Tue, 10 Nov 2020, Muchun Song wrote:
> If we reparent the slab objects to the root memcg, when we free
> the slab object, we need to update the per-memcg vmstats to keep
> it correct for the root memcg. Now this at least affects the vmstat
> of NR_KERNEL_STACK_KB for !CONFIG_VMAP_STACK when
Hi Ezequiel,
url:
https://github.com/0day-ci/linux/commits/Ezequiel-Garcia/MPEG-2-stateless-API-cleanup/20201106-045304
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-m021-20201110 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue
On Tue, Nov 10, 2020 at 10:16 AM Matthew Wilcox wrote:
>
> On Tue, Nov 10, 2020 at 10:12:48AM -0800, Yang Shi wrote:
> > @@ -2142,6 +2151,10 @@ int migrate_misplaced_transhuge_page(struct
> > mm_struct *mm,
> > int page_lru = page_is_file_lru(page);
> > unsigned long start = address
On 2020-10-17 04:29, Doug Anderson wrote:
Hi,
On Thu, Oct 15, 2020 at 10:53 AM Sibi Sankar
wrote:
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC
since the gold cores only support frequencies upto 2.1 GHz.
Signed-off-by: Sibi Sankar
---
On Tue, Nov 10, 2020 at 9:46 AM Josh Poimboeuf wrote:
>
> On Mon, Nov 09, 2020 at 08:29:24PM -0600, Josh Poimboeuf wrote:
> > On Mon, Nov 09, 2020 at 03:11:41PM -0800, Sami Tolvanen wrote:
> > > CONFIG_XEN
> > >
> > > __switch_to_asm()+0x0: undefined stack state
> > >
One fixup following my patch commit be117ca32261 ("pinctrl:
qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then
a selected config") being queued in LinusW's tree, as a new
config entry was added for the msm9853 that also needs the
change.
Applies to LinusW's pinctrl devel tree.
Cc:
On Tue, Oct 27, 2020 at 04:59:12AM +, Al Viro wrote:
> I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd like
> it to go through the sparc tree anyway).
Done - sorry for disappearing ;-/
On Tue, Nov 10, 2020 at 10:46 AM Roman Gushchin wrote:
>
> This patch fixes/removes some obsolete comments in the code related
> to the kernel memory accounting:
> - kmem_cache->memcg_params.memcg_caches has been removed
> by commit 9855609bde03 ("mm: memcg/slab: use a single set of
>
On Fri, Nov 06, 2020 at 03:50:22PM +0800, Alex Shi wrote:
> From 6c142eb582e7d0dbf473572ad092eca07ab75221 Mon Sep 17 00:00:00 2001
> From: Alexander Duyck
> Date: Tue, 26 May 2020 17:31:15 +0800
> Subject: [PATCH v21 18/19] mm/lru: introduce the relock_page_lruvec function
>
> Use this new
From: Chris Co
When invoking kexec() on a Linux guest running on a Hyper-V host, the
kernel panics.
RIP: 0010:cpuhp_issue_call+0x137/0x140
Call Trace:
__cpuhp_remove_state_cpuslocked+0x99/0x100
__cpuhp_remove_state+0x1c/0x30
hv_kexec_handler+0x23/0x30 [hv_vmbus]
On Thu, Nov 05, 2020 at 04:55:37PM +0800, Alex Shi wrote:
> From: Hugh Dickins
>
> It is necessary for page_idle_get_page() to recheck PageLRU() after
> get_page_unless_zero(), but holding lru_lock around that serves no
> useful purpose, and adds to lru_lock contention: delete it.
>
> See
Alexander reported a syzkaller / KASAN finding on s390, see below for
complete output.
In do_huge_pmd_anonymous_page(), the pre-allocated pagetable will be freed
in some cases. In the case of userfaultfd_missing(), this will happen after
calling handle_userfault(), which might have released the
Currently checkpatch warns us if there is no 'Signed-off-by' line
for the patch.
E.g., running checkpatch on commit 9ac060a708e0 ("leaking_addresses:
Completely remove --version flag") reports this error:
ERROR: Missing Signed-off-by: line(s)
Provide a fix by adding a Signed-off-by line
On 10/11/2020 18:38, Paul E. McKenney wrote:
> On Tue, Nov 10, 2020 at 03:34:05PM +, Colin Ian King wrote:
>> On 10/11/2020 15:24, Paul E. McKenney wrote:
>>> On Mon, Nov 09, 2020 at 11:57:15PM -0500, Paul Gortmaker wrote:
On 2020-11-09 8:07 p.m., Qian Cai wrote:
> On Mon,
On Fri, Nov 06, 2020 at 09:20:04AM +0800, Alex Shi wrote:
> From 2fd278b1ca6c3e260ad249808b62f671d8db5a7b Mon Sep 17 00:00:00 2001
> From: Alex Shi
> Date: Thu, 5 Nov 2020 11:38:24 +0800
> Subject: [PATCH v21 06/19] mm/rmap: stop store reordering issue on
> page->mapping
>
> Hugh Dickins and
I was reading rt.c and was looking at the code pertaining to allowing a
non-migratable task to preempt a migratable task of the same priority.
It appears to me that one of the comments describing when this will
happen is wrong.
It appears that preemption will only happen when the task is *not*
Signed-off-by: Sidney Cammeresi
---
kernel/sched/rt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 49ec096..6197c9e 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1560,7 +1560,7 @@ static void
On Mon, 9 Nov 2020 09:58:54 +0530, Anshuman Khandual wrote:
> This series brings three different changes to the only memory event notifier
> on
> arm64 platform. These changes improve it's robustness while also enhancing
> debug
> capabilities during potential memory offlining error conditions.
On Tue, Nov 10, 2020 at 07:11:28AM -0800, Shakeel Butt wrote:
> On Mon, Nov 9, 2020 at 5:28 PM Roman Gushchin wrote:
> >
> > On Fri, Oct 23, 2020 at 12:30:53PM -0400, Johannes Weiner wrote:
> > > On Wed, Oct 21, 2020 at 12:33:22PM -0700, Roman Gushchin wrote:
> > > > On Tue, Oct 20, 2020 at
On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote:
> As a hardening measure, we currently randomize the placement of
> physical memory inside the linear region when KASLR is in effect.
> Since the random offset at which to place the available physical
> memory inside the linear region is
On Mon, Oct 26, 2020 at 05:49:21PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The way that bpmp_populate_debugfs_inband() uses strncpy()
> and strncat() makes no sense since the size argument for
> the first is insufficient to contain the trailing '/'
> and the second passes the
On Mon, 9 Nov 2020 17:08:36 +0530, Anshuman Khandual wrote:
> Mapping between IPI type index and its string is direct without requiring
> an additional offset. Hence the existing macro S(x, s) is now redundant
> and can just be dropped. This also makes the code clean and simple.
Applied to arm64
On Tue, 3 Nov 2020 10:22:29 +, Mark Rutland wrote:
> Depending on configuration options and specific code paths, we either
> use the empty_zero_page or the configuration-dependent reserved_ttbr0
> as a reserved value for TTBR{0,1}_EL1.
>
> To simplify this code, let's always allocate and use
On Tue, 10 Nov 2020 17:25:24 +0800 Yicong Yang wrote:
> The attr->set() receive a value of u64, but simple_strtoll() is used
> for doing the conversion. It will lead to the error cast if user inputs
> a negative value.
>
> Use kstrtoull() instead of simple_strtoll() to convert a string got
>
On Mon, Nov 9, 2020 at 6:25 PM Lukasz Luba wrote:
>
> The constraint name has limit of size 30, which sometimes might be hit.
> When this happens the new line might be lost. Prevent this and set the
> new line when the name string is too long."
>
> Signed-off-by: Lukasz Luba
> ---
>
On Tue, Nov 10, 2020 at 06:50:04PM +0100, Peter Hilber wrote:
> Hi Cristian,
>
> sorry, I mistakenly used the wrong sender ("Mailing Lists") for the
> original comment mail. Please see below for my reply.
>
> On 10.11.20 18:21, Cristian Marussi wrote:
> > On Tue, Nov 10, 2020 at 05:00:05PM
On 10 November 2020 18:56:17 GMT, Thomas Gleixner wrote:
>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>>> If I could get post-5.5 kernels to boot at all with the AMD IOMMU
>>> enabled, I'd have a go at throwing that together
On Tue, Oct 27, 2020 at 8:24 AM Victor Ding wrote:
>
> This patch series adds support for AMD Fam17h RAPL counters. As per
> AMD PPR, Fam17h and Fam19h support RAPL counters to monitor power
> usage. The RAPL counter operates as with Intel RAPL. Therefore, it is
> beneficial to re-use existing
On 11/9/2020 8:23 PM, Rayagonda Kokatanur wrote:
> Hi Ray,
>
> Could you please check Dhananjay comments and update your thoughts.
>
> On Fri, Nov 6, 2020 at 11:11 PM Dhananjay Phadke
> wrote:
>>
>> On Thu, 5 Nov 2020 15:13:04 +0530, Rayagonda Kokatanur wrote:
So the suggestion was to
Thanks for continuing to work this Muchun!
On 11/8/20 6:10 AM, Muchun Song wrote:
...
> For tail pages, the value of compound_head is the same. So we can reuse
> first page of tail page structs. We map the virtual addresses of the
> remaining 6 pages of tail page structs to the first tail page
For your urgent attention please
Dearest, how are you? i hope this message finds you in good health and spirit.
My name is Mrs. Celine Marchand. Your email address was revealed to me after
much prayer and supplication by the almighty God. Therefore, my contact with
you is divine with utmost
Occasionally when logging out of the ttyS0 aka serial console I see that
irq 4: Affinity broken due to vector space exhaustion.
is output to the console.
At boot the default smp_affinity is
/proc/irq/4/smp_affinity:00ff,,00ff
The irqbalance service runs and can change
On 10 Nov 2020, at 13:39, Christoph Hellwig wrote:
On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
You do consistently ask for a shim layer, but you haven???t explained
what
we gain by diverging from the documented and tested API of the
upstream zstd
project. It???s an important
On Mon, Nov 9, 2020 at 11:36 PM Ard Biesheuvel wrote:
>
> BE32 != BE8
Oh? Sorry, what does BE8 stand for? arch/arm/mm/Kconfig says:
CONFIG_CPU_ENDIAN_BE8
Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
vs:
CPU_ENDIAN_BE32
Support for the BE-32 (big-endian) mode on
On Tue, 10 Nov 2020, Pablo Neira Ayuso wrote:
> Hi Casey,
>
> On Wed, Nov 04, 2020 at 04:49:17PM -0800, Casey Schaufler wrote:
> > Change netlink netfilter interfaces to use lsmcontext
> > pointers, and remove scaffolding.
> >
> > Reviewed-by: Kees Cook
> > Reviewed-by: John Johansen
> >
On 11/10/2020 12:00 PM, John Stultz wrote:
One fixup following my patch commit be117ca32261 ("pinctrl:
qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then
a selected config") being queued in LinusW's tree, as a new
config entry was added for the msm9853 that also needs the
change.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/trinity_dpm.c:146:18: warning: ‘trinity_sysls_default’
defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/radeon/trinity_dpm.c:131:18: warning:
‘trinity_mgcg_shls_disable’ defined but not used
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r600.c:1615:5: warning: no previous prototype for
‘r600_gpu_check_soft_reset’ [-Wmissing-prototypes]
1615 | u32 r600_gpu_check_soft_reset(struct radeon_device *rdev)
| ^
Cc: Alex Deucher
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/rv770_dpm.c:47:18: warning: no previous prototype for
‘rv770_get_ps’ [-Wmissing-prototypes]
47 | struct rv7xx_ps *rv770_get_ps(struct radeon_ps *rps)
| ^~~~
drivers/gpu/drm/radeon/rv770_dpm.c:54:26: warning: no
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen.c: In function ‘evergreen_gpu_init’:
drivers/gpu/drm/radeon/evergreen.c:1419: warning: Function parameter or member
'async' not described in 'evergreen_page_flip'
Cc: Alex Deucher
Cc: "Christian König"
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/si.c: In function ‘si_gpu_init’:
drivers/gpu/drm/radeon/si.c:3090:6: warning: variable ‘mc_shared_chmap’ set
but not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r600.c:3480:5: warning: no previous prototype for
‘r600_ih_ring_alloc’ [-Wmissing-prototypes]
3480 | int r600_ih_ring_alloc(struct radeon_device *rdev)
| ^~
drivers/gpu/drm/radeon/r600.c:3516:6: warning:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen_hdmi.c:37:6: warning: no previous prototype
for ‘dce4_audio_enable’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/evergreen_hdmi.c:67:6: warning: no previous prototype
for ‘evergreen_hdmi_update_acr’
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni.c: In function ‘cayman_gpu_init’:
drivers/gpu/drm/radeon/ni.c:2679: warning: Function parameter or member 'ring'
not described in 'cayman_vm_flush'
drivers/gpu/drm/radeon/ni.c:2679: warning: Function parameter or
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.
Exciting times (using Arm as the benchmark):
Before these sets:
5031 drivers/gpu/
3923 drivers/gpu/drm/amd/
258 drivers/gpu/drm/radeon/
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_irq_kms.c:53:13: warning: no previous prototype
for ‘radeon_driver_irq_handler_kms’ [-Wmissing-prototypes]
53 | irqreturn_t radeon_driver_irq_handler_kms(int irq, void *arg)
| ^
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni.c: In function ‘cayman_gpu_init’:
drivers/gpu/drm/radeon/ni.c:880:6: warning: variable ‘mc_shared_chmap’ set but
not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_sync.c:92: warning: Function parameter or member
'rdev' not described in 'radeon_sync_resv'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_dp_mst.c: In function ‘radeon_mst_encoder_dpms’:
drivers/gpu/drm/radeon/radeon_dp_mst.c:366:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen.c: In function ‘evergreen_gpu_init’:
drivers/gpu/drm/radeon/evergreen.c:3135:6: warning: variable ‘mc_shared_chmap’
set but not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_mn.c:51: warning: Function parameter or member
'cur_seq' not described in 'radeon_mn_invalidate'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni.c:1378:6: warning: no previous prototype for
‘cayman_cp_int_cntl_setup’ [-Wmissing-prototypes]
1378 | void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
| ^~~~
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen_cs.c:1026: warning: Function parameter or
member 'p' not described in 'evergreen_cs_packet_parse_vline'
drivers/gpu/drm/radeon/evergreen_cs.c:1026: warning: Excess function parameter
'parser' description in
On 11/9/20 5:52 AM, Oscar Salvador wrote:
> On Sun, Nov 08, 2020 at 10:10:55PM +0800, Muchun Song wrote:
>> The purpose of introducing HUGETLB_PAGE_FREE_VMEMMAP is to configure
>> whether to enable the feature of freeing unused vmemmap associated
>> with HugeTLB pages. Now only support x86.
>>
>>
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni_dpm.c:727:23: warning: no previous prototype for
‘ni_get_pi’ [-Wmissing-prototypes]
727 | struct ni_power_info *ni_get_pi(struct radeon_device *rdev)
| ^
drivers/gpu/drm/radeon/ni_dpm.c:734:15: warning: no
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r600_cs.c:793: warning: Function parameter or member
'p' not described in 'r600_cs_packet_parse_vline'
drivers/gpu/drm/radeon/r600_cs.c:793: warning: Excess function parameter
'parser' description in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/sumo_dpm.c:81:25: warning: no previous prototype for
‘sumo_get_pi’ [-Wmissing-prototypes]
81 | struct sumo_power_info *sumo_get_pi(struct radeon_device *rdev)
| ^~~
Cc: Alex Deucher
Cc: "Christian König"
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r100.c:163: warning: Function parameter or member
'async' not described in 'r100_page_flip'
drivers/gpu/drm/radeon/r100.c:848: warning: Function parameter or member
'rdev' not described in 'r100_ring_hdp_flush'
On Wed, Nov 4, 2020 at 11:58 AM Lukasz Luba wrote:
>
> Hi Rafael,
>
> On 11/3/20 9:05 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > The Energy Model supports power values expressed in an abstract scale.
> > This has an impact on Intelligent Power Allocation (IPA) and should be
> > documented
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_prime.c:34:18: warning: no previous prototype
for ‘radeon_gem_prime_get_sg_table’ [-Wmissing-prototypes]
34 | struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj)
|
On Tue, Nov 10, 2020 at 06:40:45PM +0200, Vladimir Oltean wrote:
> I am fairly confident that this is how your hardware works, because
> that's also how peer delay wants to be timestamped, it seems.
So I was confident and also wrong, it appears. My KSZ9477 datasheet
says:
In the host-to-switch
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/atombios_i2c.c:100:5: warning: no previous prototype
for ‘radeon_atom_hw_i2c_xfer’ [-Wmissing-prototypes]
100 | int radeon_atom_hw_i2c_xfer(struct i2c_adapter *i2c_adap,
| ^~~
commit 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and
init_on_free=1 boot options") resulted with init_on_alloc=1 in all pages
leaving the buddy via alloc_pages() and friends to be
initialized/cleared/zeroed on allocation.
However, the same logic is currently not applied to
On 11/9/20 2:29 AM, Greg Kroah-Hartman wrote:
> On Sat, Nov 07, 2020 at 03:10:06PM +0100, Greg Kroah-Hartman wrote:
>> On Fri, Nov 06, 2020 at 08:27:44PM +, Vineet Gupta wrote:
>>> Hi Stable Team,
>>>
>>> On 10/19/20 7:19 PM, Vineet Gupta wrote:
This reverts commit
On Tue, Nov 10, 2020 at 11:29 AM Jeffrey Hugo wrote:
>
> On 11/10/2020 12:00 PM, John Stultz wrote:
> > One fixup following my patch commit be117ca32261 ("pinctrl:
> > qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then
> > a selected config") being queued in LinusW's tree, as a new
>
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_ttm.c:931:5: warning: no previous prototype for
‘radeon_mmap’ [-Wmissing-prototypes]
931 | int radeon_mmap(struct file *filp, struct vm_area_struct *vma)
| ^~~
Cc: Alex Deucher
Cc: "Christian König"
Cc:
And the piece of code that has never been executed.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ci_dpm.c: In function ‘ci_set_dpm_event_sources’:
drivers/gpu/drm/radeon/ci_dpm.c:1369:28: warning: variable ‘dpm_event_src’ set
but not used [-Wunused-but-set-variable]
The PLL status polling loops in the set_rate callbacks of some PLLs
have no timeout detection and may become endless loops when something
goes wrong with the PLL.
For some PLLs there is already the ktime API based timeout detection,
but it will not work in all conditions when .set_rate gets
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_ib.c:61: warning: Function parameter or member
'vm' not described in 'radeon_ib_get'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc:
On Fri, Nov 06, 2020 at 04:25:48PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 05:47:21PM +, Robin Murphy wrote:
> > On 2020-11-05 16:43, Thierry Reding wrote:
> > > On Thu, Sep 24, 2020 at 01:27:25PM +0200, Thierry Reding wrote:
> > > > On Tue, Sep 15, 2020 at 02:36:48PM +0200,
On 11/10/2020 12:32 PM, John Stultz wrote:
On Tue, Nov 10, 2020 at 11:29 AM Jeffrey Hugo wrote:
On 11/10/2020 12:00 PM, John Stultz wrote:
One fixup following my patch commit be117ca32261 ("pinctrl:
qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then
a selected config") being
On Mon, Nov 9, 2020 at 1:45 PM Ard Biesheuvel wrote:
>
> On Mon, 9 Nov 2020 at 22:09, Nick Desaulniers wrote:
> >
> > I didn't see anything in linux-next today, or
> > https://www.armlinux.org.uk/developer/patches/ Incoming or Applied.
> >
> > Did it just get merged into the for-next branch, or
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/cik_sdma.c:949: warning: Function parameter or member
'ring' not described in 'cik_dma_vm_flush'
drivers/gpu/drm/radeon/cik_sdma.c:949: warning: Function parameter or member
'vm_id' not described in 'cik_dma_vm_flush'
> On Nov 10, 2020, at 7:25 AM, David Sterba wrote:
>
> On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
>> On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
>>> You just keep resedning this crap, don't you? Haven't you been told
>>> multiple times to provide a proper kernel API by
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_vm.c:131: warning: Function parameter or member
'rdev' not described in 'radeon_vm_get_bos'
drivers/gpu/drm/radeon/radeon_vm.c:643: warning: Excess function parameter
'start' description in
801 - 900 of 1567 matches
Mail list logo
