Hello,
On Tue, Nov 24, 2020 at 03:18:32PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> compared to v1 sent starting with
> Message-Id:20201119132311.2604232-1-u.kleine-koe...@pengutronix.de:
>
> - Prepare siox_shutdown() to be called even for unbound devices in
>patch 1.
> - remove stray
Hello,
On Tue, Nov 24, 2020 at 03:18:34PM +0100, Uwe Kleine-König wrote:
> The driver core ignores the return value of the remove callback, so
> don't give siox drivers the chance to provide a value.
>
> All siox drivers only allocate devm-managed resources in
> .probe, so there is no .remove
Hello Uwe,
you already know, but FTR, there is a typo in the subject.
s/remote/remove/
On Tue, Nov 24, 2020 at 03:18:33PM +0100, Uwe Kleine-König wrote:
> The eventual goal is to get rid of the callbacks in struct
> device_driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
>
On Tue, Nov 24, 2020 at 03:50:01PM +0530, Vidya Sagar wrote:
> Hi Bjorn,
> Please let me know if this patch needs any further modifications
I'm fine with it, but of course Lorenzo will take care of it.
> On 11/12/2020 10:32 PM, Vidya Sagar wrote:
> > External email: Use caution opening links or
date: 6 months ago
config: arm-randconfig-r012-20201124 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
Hello,
On Tue, Nov 24, 2020 at 01:32:05PM +, Mel Gorman wrote:
> I would hope that is not the case because they are not meant to overlap.
> However, if the beginning of the pageblock was not the start of a zone
> then the pages would be valid but the pfn would still be outside the
> zone
> On Nov 24, 2020, at 12:47, Jann Horn wrote:
>
> On Tue, Nov 24, 2020 at 9:43 PM Bae, Chang Seok
> wrote:
>>> On Nov 24, 2020, at 10:41, Jann Horn wrote:
>>> On Tue, Nov 24, 2020 at 7:22 PM Bae, Chang Seok
>>> wrote:
> On Nov 20, 2020, at 15:04, Jann Horn wrote:
> On Thu, Nov 19,
A bus lock is acquired though either split locked access to
writeback (WB) memory or any locked access to non-WB memory. This is
typically >1000 cycles slower than an atomic operation within a cache
line. It also disrupts performance on other cores.
Some CPUs have ability to notify the kernel by
#DB for bus lock is enabled by bus lock detection bit 2 in DEBUGCTL MSR
while #AC for split lock is enabled by split lock detection bit 29 in
TEST_CTRL MSR.
Delivery of #DB for bus lock in userspace clears DR6[11]. To avoid
confusion in identifying #DB, #DB handler sets the bit to 1 before
Since #DB for bus lock detect changes the split_lock_detect parameter,
update the documentation for the changes.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
Acked-by: Randy Dunlap
---
Change Log:
v4:
- Fix a ratelimit wording issue in the doc (Randy).
- Patch 4 is acked by Randy (Randy).
To enforce user application throttling or mitigations, extend the
existing split lock detect kernel parameter:
split_lock_detect=ratelimit:N
It limits bus lock rate to N per second for non-root users.
Signed-off-by: Fenghua Yu
Reviewed-by: Tony Luck
---
arch/x86/kernel/cpu/intel.c |
A bus lock [1] is acquired through either split locked access to
writeback (WB) memory or any locked access to non-WB memory. This is
typically >1000 cycles slower than an atomic operation within
a cache line. It also disrupts performance on other cores.
Although split lock can be detected by #AC
[+cc Rafael, linux-pm for runtime PM question below]
On Tue, Nov 24, 2020 at 02:02:02PM +0800, ricky...@realtek.com wrote:
> From: Ricky Wu
>
> rtsx_pci_sdmmc: add to support autosuspend when the rtd3_en is set
>
> rtsx_pcr: add callback functions about runtime PM
> add delay_work(rtd3_work)
Quoting Oliver Sang (2020-11-19 07:20:18)
> On Fri, Nov 13, 2020 at 04:27:13PM +0200, Joonas Lahtinen wrote:
> > Hi,
> >
> > Could you add intel-...@lists.freedesktop.org into reports going
> > forward.
> >
> > Quoting kernel test robot (2020-11-11 17:58:11)
> > >
> > > Greeting,
> > >
> > >
On Tue, Nov 24, 2020 at 9:43 PM Bae, Chang Seok
wrote:
> > On Nov 24, 2020, at 10:41, Jann Horn wrote:
> > On Tue, Nov 24, 2020 at 7:22 PM Bae, Chang Seok
> > wrote:
> >>> On Nov 20, 2020, at 15:04, Jann Horn wrote:
> >>> On Thu, Nov 19, 2020 at 8:40 PM Chang S. Bae
> >>> wrote:
>
>
On Tue, Nov 24, 2020 at 12:41 PM William Mcvicker
wrote:
>
> On Tue, Nov 24, 2020 at 09:24:26PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 24, 2020 at 10:31:39AM -0800, William Mcvicker wrote:
> > > On Tue, Nov 24, 2020 at 07:12:40PM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Nov 24,
On Mon, Nov 23, 2020 at 2:43 PM Paul Moore wrote:
>
> On Mon, Nov 23, 2020 at 2:21 PM Lokesh Gidra wrote:
> > On Sun, Nov 22, 2020 at 3:14 PM Paul Moore wrote:
> > > On Wed, Nov 18, 2020 at 5:39 PM Lokesh Gidra
> > > wrote:
> > > > I have created a cuttlefish build and have tested with the
Hello Marco,
On Fri, Sep 11, 2020 at 04:47:00PM +0200, Marco Felsch wrote:
> Hi,
>
> Patch 1-2: write path fixes
> The sst write path is completely broken since v5.7-rc1 and in rare cases
> since the support of the sst_write() function (49aac4aec53c).
>
> Patch 3: cleanup
>
> I've tested my
> On Nov 24, 2020, at 10:41, Jann Horn wrote:
>
> On Tue, Nov 24, 2020 at 7:22 PM Bae, Chang Seok
> wrote:
>>> On Nov 20, 2020, at 15:04, Jann Horn wrote:
>>> On Thu, Nov 19, 2020 at 8:40 PM Chang S. Bae
>>> wrote:
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
Hi Guilherme,
On 11/24/20 10:45 AM, Guilherme G. Piccoli wrote:
Hi Kuppuswamy Sathyanarayanan (and all involved here), thanks for the
patch! I'd like to ask what is the status of this patchset - I just
"parachuted" in the issue, and by tracking the linux-pci ML, I found
this V7 (and all
On Tue, Nov 24, 2020 at 09:24:26PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 24, 2020 at 10:31:39AM -0800, William Mcvicker wrote:
> > On Tue, Nov 24, 2020 at 07:12:40PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Nov 24, 2020 at 10:05:16AM -0800, William Mcvicker wrote:
> > > > On Tue,
Hi!
Dne ponedeljek, 23. november 2020 ob 15:39:50 CET je Ezequiel Garcia
napisal(a):
> Cedrus supports H.264 profiles from Baseline to High,
> except for the Extended profile
>
> Expose the V4L2_CID_MPEG_VIDEO_H264_PROFILE so that
> userspace can query the driver for the supported
> profiles
Hi!
Dne ponedeljek, 23. november 2020 ob 15:39:47 CET je Ezequiel Garcia
napisal(a):
> Seems we are converging, as this iteration is really small.
>
> Just like v3, this iteration (plus a patch for VP8 VP8_FRAME_HEADER
initialization,
> which I'll send shortly) passes v4l2-compliance with no
Hi,
On Tue, Nov 24, 2020 at 12:10:31PM -0800, Prashant Malani wrote:
> Both partner and cable have identity VDOs. These are listed separately
> in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
> into a common location to avoid the duplication.
>
> Signed-off-by: Prashant
On Tue, Nov 24, 2020 at 12:16 PM Matthew Wilcox wrote:
>
> So my s/if/while/ suggestion is wrong and we need to do something to
> prevent spurious wakeups. Unless we bury the spurious wakeup logic
> inside wait_on_page_writeback() ...
We can certainly make the "if()" in that loop be a
On Tue, 24 Nov 2020 19:43:08 +
Mark Rutland wrote:
> AFAICT, the issue is that arch_cpu_idle() can be dynamically traced with
> ftrace, and hence the tracing code can unexpectedly run without RCU
> watching. Since that's dynamic tracing, we can avoid it by marking
> arch_cpu_idle() and
The command "make coccicheck C=1 CHECK=scripts/coccicheck" results in the
error:
./scripts/coccicheck: line 65: -1: shift count out of range
This happens because every time the C variable is specified,
the shell arguments need to be "shifted" in order to take only
the last argument, which
On Tue, Nov 24, 2020 at 11:41:57AM +0530, Naresh Kamboju wrote:
> On Mon, 23 Nov 2020 at 18:14, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 5.9.11 release.
> > There are 252 patches in this series, all will be posted as a response
> > to this one. If
On Mon, Nov 23, 2020 at 05:31:09PM -0700, Shuah Khan wrote:
> On 11/23/20 5:19 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.9.11 release.
> > There are 252 patches in this series, all will be posted as a response
> > to this one. If anyone has any
On Mon, Nov 23, 2020 at 02:36:50PM -0800, Guenter Roeck wrote:
> On Mon, Nov 23, 2020 at 01:19:10PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.9.11 release.
> > There are 252 patches in this series, all will be posted as a response
> > to this one.
On Tue, Nov 24, 2020 at 08:53:47PM +0100, Pavel Machek wrote:
> Hi!
>
> > This is the start of the stable review cycle for the 4.19.160 release.
> > There are 91 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
>
On Tue, Nov 24, 2020 at 10:31:39AM -0800, William Mcvicker wrote:
> On Tue, Nov 24, 2020 at 07:12:40PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 24, 2020 at 10:05:16AM -0800, William Mcvicker wrote:
> > > On Tue, Nov 24, 2020 at 10:31:18AM +0100, Jessica Yu wrote:
> > > > +++ William
On Tue, Nov 24, 2020 at 11:21:13AM -0800, Ira Weiny wrote:
> On Tue, Nov 24, 2020 at 02:19:41PM +, Matthew Wilcox wrote:
> > On Mon, Nov 23, 2020 at 10:07:39PM -0800, ira.we...@intel.com wrote:
> > > +static inline void memzero_page(struct page *page, size_t offset, size_t
> > > len)
> > > +{
On Tue, 24 Nov 2020, Vipin Sharma wrote:
> > > Looping Janosch and Christian back into the thread.
> > >
> > >
> > >
> > > I interpret this suggestion as
The pull request you sent on Tue, 24 Nov 2020 19:04:55 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.10-5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/80145ac2f739558e66bd8789df3414bc0e111c58
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Tue, 24 Nov 2020 00:52:20 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/
> tags/arc-5.10-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b1489422041ba58f224270480d8241be24f0f8dd
Thank you!
--
Deet-doot-dot, I
On Tue, Nov 24, 2020 at 11:00:42AM -0800, Linus Torvalds wrote:
> On Tue, Nov 24, 2020 at 10:33 AM Matthew Wilcox wrote:
> >
> > We could fix this by turning that 'if' into a 'while' in
> > write_cache_pages().
>
> That might be the simplest patch indeed.
>
> At the same time, I do worry about
On Tue, Nov 24, 2020 at 8:58 PM Linus Torvalds
wrote:
>
> On Tue, Nov 24, 2020 at 11:55 AM Eric W. Biederman
> wrote:
> >
> > If cell happens to be dead we can remove a fair amount of generic kernel
> > code that only exists to support cell.
>
> Even if some people might still use cell (which
A PD-capable device can return up to 3 Product Type VDOs as part of its
DiscoverIdentity Response (USB PD Spec, Rev 3.0, Version 2.0, Section
6.4.4.3.1). Add sysfs attributes to expose these to userspace.
Cc: Benson Leung
Cc: Heikki Krogerus
Signed-off-by: Prashant Malani
Reviewed-by: Heikki
Hi Heikki,
On Tue, Nov 24, 2020 at 5:23 AM Heikki Krogerus
wrote:
>
> On Fri, Oct 23, 2020 at 02:43:26PM -0700, Prashant Malani wrote:
> > Both partner and cable have identity VDOs. These are listed separately
> > in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
> > into a
Hi Wei,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tip/x86/core]
[also build test WARNING on asm-generic/master iommu/next tip/timers/core
pci/next linus/master v5.10-rc5]
[cannot apply to next-20201124]
[If your patch is applied to the wrong git tree, kindly
Both partner and cable have identity VDOs. These are listed separately
in the Documentation/ABI/testing/sysfs-class-typec. Factor these out
into a common location to avoid the duplication.
Signed-off-by: Prashant Malani
Acked-by: Heikki Krogerus
---
Changes in v4:
- Rebased on top of the
On Mon, 23 Nov 2020 20:10:04 + David Howells wrote:
> Here are some patches that do some reorganisation of the security class
> handling in rxrpc to allow implementation of the RxGK security class that
> will allow AF_RXRPC to use GSSAPI-negotiated tokens and better crypto. The
> RxGK
This parameter is needed to pass it to irq_domain_alloc_descs().
This seems to have been missed by
o06ee6d571f0e ("genirq: Add affinity hint to irq allocation")
This is needed to implement proper support for multiqueue with pseries.
All irq_create_mapping() callers have been updated with the
On 11/24/20 2:25 PM, Lad Prabhakar wrote:
> Replace C++ style comment with C style.
Thanks, I've overlooked this, and the header files should use C style
comment,
not C++.
> While at it also replace the tab with a space between struct and
> struct name.
No connection between these 2
With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
this is broken on pseries.
The affinity is correctly computed in msi_desc but this is not applied
to the system IRQs.
It appears the affinity is correctly
With virtio, in multiqueue case, each queue IRQ is normally
bound to a different CPU using the affinity mask.
This works fine on x86_64 but totally ignored on pseries.
This is not obvious at first look because irqbalance is doing
some balancing to improve that.
It appears that the "managed"
Hi Lukas,
just some general comments, not a full review.
Am Dienstag, den 24.11.2020, 18:27 +0100 schrieb Lukas F. Hartmann:
> This is the device tree for the MNT Reform 2.0 open hardware laptop
> which is based on NXP i.MX8MQ. It is designed around the Boundary Devices
> Nitrogen8M SoM.
Since
On Tue, 2020-11-24 at 10:16 +, Christoph Hellwig wrote:
> On Mon, Nov 23, 2020 at 12:01:35AM +, Edgecombe, Rick P wrote:
> > Another option could be putting the new metadata in vm_struct and
> > just
> > return that, like get_vm_area(). Then we don't need to invent a new
> > struct. But
Use scs_alloc() to allocate also IRQ and SDEI shadow stacks instead of
using statically allocated stacks.
Signed-off-by: Sami Tolvanen
---
arch/arm64/kernel/Makefile | 1 -
arch/arm64/kernel/entry.S | 6 ++--
arch/arm64/kernel/irq.c| 19 ++
arch/arm64/kernel/scs.c| 16
As discussed a few months ago [1][2], virtually mapped shadow call stacks
are better for safety and robustness. This series dusts off the VMAP
option from the original SCS patch series and switches the kernel to use
virtually mapped shadow stacks unconditionally when SCS is enabled.
[1]
The kernel currently uses kmem_cache to allocate shadow call stacks,
which means an overflows may not be immediately detected and can
potentially result in another task's shadow stack to be overwritten.
This change switches SCS to use virtually mapped shadow stacks for
tasks, which increases
On Tue, 2020-11-24 at 10:19 +, h...@infradead.org wrote:
> But I thought that using those pgprot flags was still sort
> overloading
> > the meaning of pgprot. My understanding was that it is supposed to
> > hold
> > the actual bits set in the PTE. For example large pages or TLB
> > hints
> >
On Tue, Nov 24, 2020 at 11:55 AM Eric W. Biederman
wrote:
>
> If cell happens to be dead we can remove a fair amount of generic kernel
> code that only exists to support cell.
Even if some people might still use cell (which sounds unlikely), I
think we can remove the spu core dumping code.
When perf inject reads a perf.data file from an older version of perf,
it writes event attributes into the output with the original size field,
but lays them out as if they had the size currently used. Readers see
a corrupt file. Update the size field to match the layout.
Signed-off-by: Al Grant
On 11/24/2020 7:53 PM, Vitaly Mayatskih wrote:
> [CAUTION: External Email]
>
> On Wed, Nov 18, 2020 at 7:20 AM Vinod Koul wrote:
>
>> this should be single line
>
> Vinod, do you see any obvious functional defects still present in the
> driver, or can it be finally merged for us to start
On Tue, Nov 24, 2020 at 06:24:09PM +, Quentin Perret wrote:
> Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
> Modpost currently reports that as a warning, but clearly this is not a
> pattern we should allow, and all in-tree occurences should have been
> fixed by now. So,
On Fri, Nov 20, 2020 at 12:49:17PM +0100, Uladzislau Rezki (Sony) wrote:
> Make the kvfree_rcu_arg_2() to be open-coded, so readability
> and review look better from the first glance. Moreover, that
> makes it clear that both kvfree_rcu_arg_1/2() use one single
> interface.
>
> Signed-off-by:
On Tue, Nov 24, 2020 at 04:26:33PM +, Wei Liu wrote:
> On Wed, Nov 18, 2020 at 03:36:47PM +0100, Andrea Parri (Microsoft) wrote:
> > When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could
> > invoke put_device(), that will eventually release the device and free
> > the channel
Hi!
> This is the start of the stable review cycle for the 4.19.160 release.
> There are 91 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 25 Nov 2020 12:17:50
VSID is only for create_hpte(). When _PAGE_HASHPTE is
already set, add_hash_page() bails out without calling
create_hpte() and doesn't need the value of VSID.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/book3s32/hash_low.S | 12 ++--
1 file changed, 6 insertions(+), 6
On Mon 2020-11-23 13:21:46, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.246 release.
> There are 38 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
PTE_FLAGS_OFFSET is defined in asm/page_32.h and used only
in hash_low.S
And PTE_FLAGS_OFFSET nullity depends on CONFIG_PTE_64BIT
Instead of tests like #if (PTE_FLAGS_OFFSET != 0), use
CONFIG_PTE_64BIT related code.
Also move the definition of PTE_FLAGS_OFFSET into hash_low.S
directly, that
primary_pteg_full and htab_hash_searches are not used.
Remove them.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/book3s32/hash_low.S | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/powerpc/mm/book3s32/hash_low.S
b/arch/powerpc/mm/book3s32/hash_low.S
index
On Tue 24 Nov 13:18 CST 2020, Alex Elder wrote:
> On 11/22/20 11:23 PM, Bjorn Andersson wrote:
> > The Android and Windows firmware does not accept the use of 3 as a mask
> > to cover the IPA streams. But with 0x721 being related to WiFi and 0x723
> > being unsed the mapping can be reduced to
The table for Unicode upcase conversion requires an order-5 allocation,
which may fail on a highly-fragmented system:
pool-udisksd: page allocation failure: order:5,
mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
nodemask=(null),cpuset=/,mems_allowed=0
CPU: 4 PID: 3756880 Comm: pool-udisksd
The allocation flags of anonymous transparent huge pages can be controlled
through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can
help the system from getting bogged down in the page reclaim and compaction
code when many THPs are getting allocated simultaneously.
However, the
On Wed, Nov 18, 2020 at 08:50:45PM -0800, Song Liu wrote:
SNIP
> + $(Q)$(BPFTOOL) gen skeleton $< > $@
> +
> +$(TMP_OUTPUT)/%.bpf.o: %.bpf.c $(TMP_OUTPUT)/vmlinux.h $(BPFOBJ) |
> $(TMP_OUTPUT)
> + $(call msg,BPF,$@)
> + $(Q)$(CLANG) -g -O2 -target bpf $(INCLUDES)
On Tue, Nov 24, 2020 at 07:16:29PM +, Sean Christopherson wrote:
> On Fri, Nov 13, 2020, David Rientjes wrote:
>
> >
> >
> > On Mon, 2 Nov 2020, Sean Christopherson wrote:
Matthew Wilcox pointed out that the i915 driver opportunistically
allocates tmpfs memory, but will happily reclaim some of its
pool if no memory is available.
Make sure the gfp mask used to opportunistically allocate a THP
is always at least as restrictive as the original gfp mask.
Currently if thp enabled=[madvise], mounting a tmpfs filesystem
with huge=always and mmapping files from that tmpfs does not
result in khugepaged collapsing those mappings, despite the
mount flag indicating that it should.
Fix that by breaking up the blocks of tests in hugepage_vma_check
a little
The allocation flags of anonymous transparent huge pages can be controlled
through the files in /sys/kernel/mm/transparent_hugepage/defrag, which can
help the system from getting bogged down in the page reclaim and compaction
code when many THPs are getting allocated simultaneously.
However, the
On Wed, Nov 18, 2020 at 08:50:46PM -0800, Song Liu wrote:
SNIP
> +static int bpf_program_profiler__install_pe(struct evsel *evsel, int cpu,
> + int fd)
> +{
> + struct bpf_prog_profiler_bpf *skel = evsel->bpf_counter.skel;
> +
> + return
On Wed, Nov 18, 2020 at 08:50:45PM -0800, Song Liu wrote:
SNIP
> +
> +$(TMP_OUTPUT):
> + $(call msg,MKDIR,$@)
> + $(Q)mkdir -p $(TMP_OUTPUT)
> +
> +$(TMP_OUTPUT)/vmlinux.h: $(VMLINUX_BTF_PATH) | $(TMP_OUTPUT) $(BPFTOOL)
> + $(call msg,GEN,$@)
> + $(Q)if [ ! -e
On 10/3/20 6:32 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> This is considered bad for the following reasons:
> (1) We only support the block protection with BPn bits for write
> protection. Not all SST parts
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c:278: warning: Function parameter or
member 'vmhub' not described in 'gmc_v10_0_flush_gpu_tlb'
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c:278: warning: Function parameter or
member 'flush_type' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/msm_gem_shrinker.c:108: warning: Function parameter or
member 'dev' not described in 'msm_gem_shrinker_init'
drivers/gpu/drm/msm/msm_gem_shrinker.c:108: warning: Excess function parameter
'dev_priv' description in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/cz_ih.c:191: warning: Function parameter or member
'ih' not described in 'cz_ih_get_wptr'
drivers/gpu/drm/amd/amdgpu/cz_ih.c:223: warning: Function parameter or member
'ih' not described in 'cz_ih_decode_iv'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/iceland_ih.c:191: warning: Function parameter or
member 'ih' not described in 'iceland_ih_get_wptr'
drivers/gpu/drm/amd/amdgpu/iceland_ih.c:223: warning: Function parameter or
member 'ih' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:2576:5: warning: no previous prototype
for ‘parse_ta_bin_descriptor’ [-Wmissing-prototypes]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Hi,
These patches fix two problems related to wakeup signaling configuration for
bridges.
The first one is that wakeup signaling may be disabled prematurely for a
bridge (patch [1/2]) and the second one is that device wakeup power
configuration may need to be changed when enabling wakeup
From: Rafael J. Wysocki
The idea behind acpi_pm_set_bridge_wakeup() was to allow bridges to
be reference counted for wakeup enabling, because they may be enabled
to signal wakeup on behalf of their subordinate devices and that
may happen for multiple times in a row, whereas for the other devices
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c:255: warning: Function parameter or
member 'async' not described in 'dce_v11_0_page_flip'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc:
From: Rafael J. Wysocki
When wakeup signaling is enabled for a bridge for the second (or every
next) time in a row, its existing device wakeup power configuration
may not match the new conditions. For example, some devices below
it may have been put into low-power states and that changes the
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:2998:6: warning: no previous prototype
for ‘gfx_v9_0_rlc_stop’ [-Wmissing-prototypes]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc:
'struct tu_algo_data' is huge ~400 Bytes.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/msm/dp/dp_ctrl.c: In function ‘_dp_ctrl_calc_tu.constprop’:
drivers/gpu/drm/msm/dp/dp_ctrl.c:938:1: warning: the frame size of 1184 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/vega10_ih.c:377: warning: Function parameter or
member 'ih' not described in 'vega10_ih_get_wptr'
drivers/gpu/drm/amd/amdgpu/vega10_ih.c:440: warning: Function parameter or
member 'ih' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:3698: warning: Excess function parameter
'adev' description in 'DEFAULT_SH_MEM_BASES'
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/amd/amdgpu/gfx_v10_0.c: In function ‘gfx_v10_rlcg_wreg’:
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:1416:18: warning: variable ‘grbm_idx’
set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:1415:18:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c:254: warning: Function parameter or
member 'job' not described in 'sdma_v2_4_ring_emit_ib'
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c:254: warning: Function parameter or
member 'flags' not described in
Hello RT-list!
I'm pleased to announce the 4.14.209-rt101 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: a19d538aef10c100fd2d85b5a96708792154d44f
Or to build 4.14.209-rt101
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:428: warning: Function parameter or
member 'job' not described in 'sdma_v3_0_ring_emit_ib'
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:428: warning: Function parameter or
member 'flags' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:1651: warning: Function parameter or
member 'ib' not described in 'sdma_v3_0_emit_copy_buffer'
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:1651: warning: Excess function
parameter 'ring' description in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c:403: warning: Function parameter or
member 'job' not described in 'sdma_v5_0_ring_emit_ib'
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c:403: warning: Function parameter or
member 'flags' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c:848: warning: Function parameter or
member 'job' not described in 'sdma_v4_0_ring_emit_ib'
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c:848: warning: Function parameter or
member 'flags' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:367: warning: Function parameter or
member 'job' not described in 'sdma_v5_2_ring_emit_ib'
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c:367: warning: Function parameter or
member 'flags' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:97: warning: Function parameter or
member 'size' not described in 'amdgpu_vce_sw_init'
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c:441: warning: Function parameter or
member 'bo' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c:219: warning: Function parameter or
member 'bo' not described in 'uvd_v7_0_enc_get_create_msg'
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c:219: warning: Excess function parameter
'adev' description in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c:211: warning: Function parameter or
member 'bo' not described in 'uvd_v6_0_enc_get_create_msg'
drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c:211: warning: Excess function parameter
'adev' description in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:5008:6: warning: no previous prototype
for ‘gfx_v10_0_rlc_stop’ [-Wmissing-prototypes]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc:
401 - 500 of 1495 matches
Mail list logo
