Not even getting a reply after one invested quite a bit of time with
preparing and writing a report can be quite devastating. But when it
comes to Linux, this can easily happen for good or bad reasons. Hence,
use this opportunity to explain why this might happen. Hopefully some
people will then be
Describe what users have to do if they can't reproduce a problem with
mainline they want to see fixed in stable and longterm kernels. This is
separated from the main flow, as integrating it there would make it a
lot harder to follow.
Note users will only enter this section in two cases: (1) the
Make it obvious that bugzilla.kernel.org most of the time is the wrong
place to file a report, as it's not working well. Instead, tell users
how to read the MAINTAINERS file to find the proper place for their
report. Also mention ./scripts/get_maintainer.pl. Sadly this is only
available for users
The reader now users the mainline kernel and is getting closer to
reporting the issue, so it's a good point to let people recheck and
optimize their notes how to reproduce the issue. It's also a good moment
to make them search again for existing reports, as they might have
learned something in the
On Fri, Nov 06, 2020 at 12:53:34PM +, Ionela Voinescu wrote:
> +static inline
> +int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
> +{
> + if (!cpu_has_amu_feat(cpu))
> + return -EOPNOTSUPP;
> +
> + smp_call_function_single(cpu, func, val, 1);
> +
> +
Explicitly lay out the remaining options if the user can't reproduce the
issue with a mainline kernel. Especially send those that are interested
in seeing it fixed in stable and longterm kernels to a section dedicated
to it (added in a later patch), as the process would get hard to follow
if all
Describe what users will have to do if they deal with a regression.
Point out that bisection is really important.
While at it explicitly mention the .config files for the newer kernel
needs to be similar to the old kernel, as that's an important detail
quite a few people seem to miss sometimes.
Tell users to disable solutions like DKMS to make sure the kernel they
install later remains vanilla. The old text did not do that, but such
solutions were not that widespread back when it was written.
Signed-off-by: Thorsten Leemhuis
---
Documentation/admin-guide/reporting-bugs.rst | 22
Help users to avoid a few pitfalls, as they might be the real reason why
the kernel is acting up somehow.
Signed-off-by: Thorsten Leemhuis
---
Documentation/admin-guide/reporting-bugs.rst | 35
1 file changed, 35 insertions(+)
diff --git
On 12 Nov 2020, at 12:58, Ralph Campbell wrote:
> On 11/11/20 12:40 PM, Zi Yan wrote:
>> From: Zi Yan
>>
>> It reads thp_nr_pages and splits to provided new_nr. It prepares for
>> upcoming changes to support split huge page to any lower order.
>>
>> Signed-off-by: Zi Yan
>
> Looks OK to me.
>
On 11/4/20 10:50 PM, Bjorn Andersson wrote:
> The core part of this series is the update to the sysmon driver to ensure that
> notifications sent to the remote processor are consistent and always present
> valid state transitions.
>
> In testing this I finally took the time to fix up the issue
On Thu, Nov 12, 2020 at 6:49 PM Nathan Chancellor
wrote:
>
> Hi Matteo,
>
> On Thu, Nov 12, 2020 at 12:26:45PM +0100, Matteo Croce wrote:
> > On Thu, Nov 12, 2020 at 4:50 AM Nathan Chancellor
> > wrote:
> > >
> > > Clang warns:
> > >
> > > kernel/reboot.c:707:17: warning: implicit conversion
On Tue, Nov 10, 2020 at 05:47:14PM -0800, Nick Desaulniers wrote:
> The "fallthrough" pseudo-keyword was added as a portable way to denote
> intentional fallthrough. Clang will still warn on cases where there is a
> fallthrough to an immediate break. Add explicit breaks for those cases.
>
>
This part is quite similar to the old text and just a placeholder for
now. It and the referenced document afaics need to be revisited, as they
seem outdated to me. But I'm not really familiar with the current state
of things in that area and thus didn't feel qualified to write down
anything better
More explicitly than the old text point out the Linux kernel developers
don't care about vendor kernels. That is obvious to Linux kernel
developers, but something a lot of users fail to gasp, as quite a few (a
lot?) reports on bugzilla.kernel.org show; most of them get silently
ignored, which is
gt; > 368 seconds.
> > [12065.073524][ T1310] Tainted: G L5.10.0-rc3-next-
> > 20201112 #2
> > [12065.081076][ T1310] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > disables this message.
> > [12065.089648][ T1310]
On Tue, Nov 10, 2020 at 06:51:20PM -0800, 'Nick Desaulniers' via Clang Built
Linux wrote:
> Since
> commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
> the minimum supported version of GCC is gcc-4.9. It's now safe to remove
> this code.
>
> Link:
MSI support for platform devices.
Signed-off-by: Vikas Gupta
---
drivers/vfio/platform/vfio_platform_common.c | 84 ++-
drivers/vfio/platform/vfio_platform_irq.c | 238 +-
drivers/vfio/platform/vfio_platform_private.h | 23 ++
3 files changed, 331 insertions(+), 14
This series rewrites the "how to report bugs to the Linux kernel
maintainers" document to make it more straight forward and its essence
easier to grasp. At the same time make the text provide a lot more details
about the process in form of a reference section, so users that want or
need to know
Explicitly outline that some issues are more important than others and
thus need to be handled differently in some steps that are about to
follow. This makes things explicit and easy to find if you need to look
up what issues actually qualify as "regression" or a "severe problem".
The alternative
Provide an introduction to the reference section that will provide more
details how to report an issue. Mention a few general things here. Those
are not strictly needed, but likely wise to write down somewhere.
Signed-off-by: Thorsten Leemhuis
---
v2:
- mention
sparse is unhappy with us casting the __iomem address space pointer to
a type with no address space attribute specified:
"sparse warnings: (new ones prefixed by >>)"
>> drivers/mtd/maps/physmap-bt1-rom.c:78:18: sparse: sparse: cast removes
>> address space '__iomem' of expression
Indeed we
Get straight to the point in a few paragraphs instead of forcing users
to read quite a bit of text, like the old approach did.
All normally needed fits into the first three paragraphs. The fourth is
dedicated to issues only happening in stable and longterm kernels, as
things otherwise get hard to
Tell users to write some rough notes how to reproduce the issue. They
will need those notes soon once they have to reproduce the issue with a
fresh kernel later in the process. At the same time the notes can serve
as basis for the report later.
While at it point out that each report should focus
Now that the document described all preparatory steps tell users to
install a really fresh kernel. The text tries pretty hard motivating
them to install a mainline kernel, as that is best for reporting issues.
Mention the latest stable kernel as an acceptable alternative, but
discourage this
Add a small reminder that users are best of preparing for emergencies.
Doesn't cost us much and might prevent data-loss for a few people, as
disabling DKMS, installing mainline and other tasks this guide suggest
can break the system if you're unlucky.
Signed-off-by: Thorsten Leemhuis
---
Add a more detailed section on how to report issues to the Linux kernel
developers that nevertheless still is shorter, more straight-forward and
thus easier to gasp than the old text. It should provide enough details
for most users, even if it still leaves a lot of things unexplained.
Some of them
On Tue, Nov 10, 2020 at 06:41:40PM -0800, 'Nick Desaulniers' via Clang Built
Linux wrote:
> This reverts commit 43aeaa29573924df76f44eda2bbd94ca36e407b5.
>
> Since
> commit 0bddd227f3dc ("Documentation: update for gcc 4.9 requirement")
> the minimum supported version of GCC is gcc-4.9. It's now
On 11/12/20 7:07 AM, Rachit Agarwal wrote:
> From: Rachit Agarwal >
>
> Hi All,
>
> I/O batching is beneficial for optimizing IOPS and throughput for
> various applications. For instance, several kernel block drivers would
> benefit from batching, including mmc [1] and tcp-based storage drivers
Tell users early in the process to check the taint flag, as that will
prevent them from investing time into a report that might be worthless.
That way users for example will notice that the issue they face is in
fact caused by an add-on kernel module or and Oops that happened
earlier.
This
In the case of msi, vendor specific msi module may require
region access to handle msi cleanup so we need to cleanup region
after irq cleanup only.
Signed-off-by: Vikas Gupta
---
drivers/vfio/platform/vfio_platform_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Handle stable and longterm kernels in a subsection, as dealing with them
directly in the main part of the step-by-step guide turned out to make
it messy and hard to follow: it looked a bit like code with a large
amount of if-then-else section to handle special cases, which made the
typical flow
On Thu, 12 Nov 2020 10:25:13 -0500 Sven Van Asbroeck wrote:
> From: Sven Van Asbroeck
>
> When no devicetree is present, the driver will use an
> uninitialized variable.
>
> Fix by initializing this variable.
>
> Fixes: 902a66e08cea ("lan743x: correctly handle chips with internal PHY")
>
On Thu, Nov 12, 2020 at 06:59:36PM +0100, Matteo Croce wrote:
> On Thu, Nov 12, 2020 at 6:49 PM Nathan Chancellor
> wrote:
> >
> > Hi Matteo,
> >
> > On Thu, Nov 12, 2020 at 12:26:45PM +0100, Matteo Croce wrote:
> > > On Thu, Nov 12, 2020 at 4:50 AM Nathan Chancellor
> > > wrote:
> > > >
> > > >
On Thu, 12 Nov 2020 16:26:03 +0100 Simon Horman wrote:
> On Thu, Nov 12, 2020 at 10:58:52PM +0800, YueHaibing wrote:
> > nfp_cpp_from_nfp6000_pcie() returns ERR_PTR() and never returns
> > NULL. The NULL test should be removed, also return correct err.
> >
> > Fixes: 63461a028f76 ("nfp: add the
On Thu, Nov 12, 2020 at 09:54AM -0800, Paul E. McKenney wrote:
> On Thu, Nov 12, 2020 at 05:14:39PM +0100, Marco Elver wrote:
> > On Thu, Nov 12, 2020 at 01:49PM +0100, Marco Elver wrote:
> > > On Thu, 12 Nov 2020 at 01:11, Paul E. McKenney wrote:
> > [...]
> > > > > This assert didn't fire yet,
On Thu, Nov 12, 2020 at 12:05:25PM +0200, Grygorii Strashko wrote:
> But, as Richard mentioned [1], ptp_clock_register() may return NULL even if
> PTP_1588_CLOCK=y
> (which I can't confirm neither deny - from the fast look at
> ptp_clock_register()
> code it seems should not return NULL)
This
Then why does line 278 right below it check for NULL?
On Thu, Nov 12, 2020 at 5:56 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Nov 12, 2020 at 05:13:30PM +, John Boero wrote:
> > Yes the patch is backwards sorry. Testing alt proposal from
> > st...@rowland.harvard.edu. It may be a buggy
On Thu, Nov 12 2020 at 08:26, Bjorn Helgaas wrote:
> On Thu, Nov 12, 2020 at 02:50:42PM +0100, Thomas Gleixner wrote:
>> So I had a closer look and the reason why it only matters for the
>> chained handler case is that
>>
>>__irq_set_handler(..., is_chained = true, ...)
>>
>> starts up the
On Thu, Nov 12, 2020 at 09:25:12AM +0100, Arnd Bergmann wrote:
> This is not really getting any better. If Richard is worried about
> Kconfig getting changed here, I would suggest handling the
> case of PTP being disabled by returning an error early on in the
> function, like
>
> struct am65_cpts
On 11/12/20 9:20 AM, Jason Gunthorpe wrote:
I think it should be like this, Bart?
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 6017d525084a0c..80f9673956ced2 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++
Frequency invariant accounting calculations need the ratio
freq_curr/freq_max, but freq_max is unknown as it depends on dynamic power
allocation between cores: AMD EPYC CPUs implement "Core Performance Boost".
Three candidates are considered to estimate this value:
- maximum non-boost frequency
-
The value freq_max/freq_base is a fundamental component of frequency
invariance calculations. It may come from a variety of sources such as MSRs
or ACPI data, tracking it down when troubleshooting a system could be
non-trivial. It is worth saving it in the kernel logs.
# dmesg | grep 'Estimated
v3 at https://lore.kernel.org/lkml/20201110200519.18180-1-ggherdov...@suse.cz/
Changes wrt v3:
- Correct the #ifdef guard for cppc_get_perf_caps() from CONFIG_ACPI to
CONFIG_ACPI_CPPC_LIB (reported by "kernel test robot ")
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From: Nathan Fontenot
This is the first pass in creating the ability to calculate the
frequency invariance on AMD systems. This approach uses the CPPC
highest performance and nominal performance values that range from
0 - 255 instead of a high and base frquency. This is because we do
not have
Hi Linux maintainers,
The linux-x25 mail list doesn't seem to be working. We sent a lot of
emails to linux-x25 but Martin Schiller as a subscriber hasn't
received a single email from the mail list.
Looking at the mail list archive at:
https://www.spinics.net/lists/linux-x25/
I see the last
On a Webcam from Quanta, we see the following error.
usb 3-5: New USB device found, idVendor=0408, idProduct=30d2, bcdDevice= 0.03
usb 3-5: New USB device strings: Mfr=3, Product=1, SerialNumber=2
usb 3-5: Product: USB2.0 HD UVC WebCam
usb 3-5: Manufacturer: Quanta
usb 3-5: SerialNumber: 0x0001
On Thu, Nov 12, 2020 at 10:25:48AM -0800, Bart Van Assche wrote:
> On 11/12/20 9:20 AM, Jason Gunthorpe wrote:
> > I think it should be like this, Bart?
> >
> > diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
> > b/drivers/infiniband/ulp/srpt/ib_srpt.c
> > index 6017d525084a0c..80f9673956ced2
On Tue, 2020-11-10 at 21:05 +0100, Giovanni Gherdovich wrote:
> v2 at https://lore.kernel.org/lkml/20201110183054.15883-1-ggherdov...@suse.cz/
>
> Changes wrt v2:
>
> - "code golf" on the function function init_freq_invariance_cppc().
> Make better use of the "secondary" argument to
Follow the device tree standards that states to set the
status="reserved" if an device is operational, but used by a non-linux
firmware in the system.
Signed-off-by: Nishanth Menon
Reviewed-by: Tony Lindgren
Acked-by: Vignesh Raghavendra
---
Changes since V2:
- No change beyond picking up
The default state of a device tree node is "okay". There is no specific
use of explicitly adding status = "okay" in the SoC dtsi.
Fixes: 8ebcaaae8017 ("arm64: dts: ti: k3-j721e-main: Add crypto accelerator
node")
Fixes: b366b2409c97 ("arm64: dts: ti: k3-am6: Add crypto accelarator node")
On Thu, 2020-11-12 at 17:26 +, Valentin Schneider wrote:
> On 12/11/20 16:38, Qian Cai wrote:
> > Some syscall fuzzing from an unprivileged user starts to trigger this below
> > since this commit first appeared in the linux-next today. Does it ring any
> > bells?
X86 in a KVM guest as well.
The device tree standard states that when the status property is
not present under a node, the okay value is assumed. There are many
reasons for doing the same, the number of strings in the device
tree, default power management functionality, etc. are a few of the
reasons.
In general, after a few
Changes since v2[3]:
- Rebase on top of ti-k3-dts-next (no functional changes)
- picked up reviewed-by and acks from folks.
Since we have all the required acks and reviews, I will apply this
series tomorrow morning since this can cause churn for other folks.
Changes since v1[1]:
- Picked up
The device tree standard states that when the status property is
not present under a node, the okay value is assumed. There are many
reasons for doing the same, the number of strings in the device
tree, default power management functionality, etc. are a few of the
reasons.
In general, after a few
The default state of a device tree node is "okay". There is no specific
use of explicitly adding status = "okay" in the board dts.
Fixes: 7e7e7dd51d06 ("arm64: dts: ti: k3-am654-base-board: enable USB1")
Signed-off-by: Nishanth Menon
Reviewed-by: Tony Lindgren
Acked-by: Roger Quadros
Cc: Roger
On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>
> Hi Herbert, Bruce,
>
> Here's my first cut at a generic Kerberos crypto library in the kernel so
> that I can share code between rxrpc and sunrpc (and cifs?).
>
> I derived some of the parts from the sunrpc gss library and added
> On Nov 12, 2020, at 1:37 PM, J. Bruce Fields wrote:
>
> On Thu, Nov 12, 2020 at 12:57:45PM +, David Howells wrote:
>>
>> Hi Herbert, Bruce,
>>
>> Here's my first cut at a generic Kerberos crypto library in the kernel so
>> that I can share code between rxrpc and sunrpc (and cifs?).
>>
Hi Vikas,
On 11/12/20 6:58 PM, Vikas Gupta wrote:
> This RFC adds support for MSI for platform devices.
> a) MSI(s) is/are added in addition to the normal interrupts.
> b) The vendor specific MSI configuration can be done using
>callbacks which is implemented as msi module.
> c) Adds a msi
Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
script and options") added '-z norelro' to the arm64 Makefile when
CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
defaults to '-z relro' but the kernel does not use program headers or
adhere to the section
From: Liam Mark
Collect the time for each allocation recorded in page owner so that
allocation "surges" can be measured.
Record the pid for each allocation recorded in page owner so that
the source of allocation "surges" can be better identified.
Signed-off-by: Liam Mark
Signed-off-by: Georgi
Hello Bjorn
On Wed, Nov 11, 2020 at 10:08:44AM -0600, Bjorn Andersson wrote:
> On Wed 11 Nov 03:15 CST 2020, Serge Semin wrote:
>
> > In accordance with the DWC USB3 bindings the corresponding node
> > name is suppose to comply with the Generic USB HCD DT schema, which
> > requires the USB nodes
On Thu, Nov 12, 2020 at 9:20 AM KP Singh wrote:
>
> From: KP Singh
>
> Update the set of sleepable hooks with the ones that do not trigger
> a warning with might_fault() when exercised with the correct kernel
> config options enabled, i.e.
>
> DEBUG_ATOMIC_SLEEP=y
> LOCKDEP=y
>
On Thu, Nov 12, 2020 at 9:20 AM KP Singh wrote:
>
> From: KP Singh
>
> Sleepable hooks are never called from an NMI/interrupt context, so it is
> safe to use the bpf_d_path helper in LSM programs attaching to these
> hooks.
>
> The helper is not restricted to sleepable programs and merely uses
Hi Nick,
Regarding llvm-nm, this extra thumb +1 is noticed after porting
https://lore.kernel.org/linux-arm-kernel/20201013033947.2257501-1-natechancel...@gmail.com/
to the Android Common Kernel android-4.19-stable. I'm not sure why using ld.lld
causes this difference, but this proposed patch
On Thu, Nov 12, 2020 at 06:15:08PM +, John Boero wrote:
> Then why does line 278 right below it check for NULL?
I am sorry, but there is no context here at all. There's a reason you
don't top-post for technical discussions :)
thanks,
greg k-h
From: Sven Van Asbroeck
When running this chip on arm imx6, we intermittently observe
the following kernel warning in the log, especially when the
system is under high load:
[ 50.119484] [ cut here ]
[ 50.124377] WARNING: CPU: 0 PID: 303 at kernel/softirq.c:169
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:487: warning: Function parameter or
member 'dev' not described in 'amdgpu_info_ioctl'
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:487: warning: Excess function
parameter 'adev' description in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or
member 'ddp_comp' not described in 'mtk_disp_ovl'
drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or
member 'crtc' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vc4/vc4_debugfs.c:25: warning: Function parameter or member
'minor' not described in 'vc4_debugfs_init'
drivers/gpu/drm/vc4/vc4_debugfs.c:62: warning: Function parameter or member
'dev' not described in 'vc4_debugfs_add_file'
The alternative is to move them into the source file that uses then,
but they are large and intrusive, so that strategy is being avoided.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vc4/vc4_hdmi_regs.h:282:39: warning: ‘vc5_hdmi_hdmi1_fields’
defined but not used
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/exynos/exynos_drm_fimd.c:733: warning: Function parameter or
member 'ctx' not described in 'fimd_shadow_protect_win'
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: David Airlie
Cc: Daniel Vetter
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/armada/armada_overlay.c:329:1: warning: no previous prototype
for ‘armada_overlay_duplicate_state’ [-Wmissing-prototypes]
Cc: Russell King
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by:
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.
NB: Hopefully the other sets turn up in -next soon, so they can
be rebased and any stragglers re-submitted.
Lee Jones (30):
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c: In function
‘amdgpu_atombios_encoder_init_backlight’:
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c:174:5: warning: variable
‘backlight_level’ set but not used [-Wunused-but-set-variable]
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:283:6: warning: no previous
prototype for ‘atmel_hlcdc_plane_setup_scaler’ [-Wmissing-prototypes]
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:44: warning: cannot understand
function prototype:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/exynos/exynos_drm_gsc.c:129: warning: Function parameter or
member 'num_limits' not described in 'gsc_driverdata'
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: David Airlie
Cc: Daniel Vetter
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or
member 'ddp_comp' not described in 'mtk_disp_color'
drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or
member 'crtc' not described in
Must start with "struct "
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/rockchip/rockchip_lvds.c:49: warning: cannot understand
function prototype: 'struct rockchip_lvds_soc_data '
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Mark Yao
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c:283:6: warning: no previous
prototype for ‘atmel_hlcdc_plane_setup_scaler’ [-Wmissing-prototypes]
Cc: Sam Ravnborg
Cc: Boris Brezillon
Cc: David Airlie
Cc: Daniel Vetter
Cc: Nicolas Ferre
Cc:
The comment about them (also removed) says:
/* fb_rsrc and aper_rsrc aren't really used currently, but still exist
* in case we decide we need information on the BAR for BSD in the
* future.
*/
Well that was written 12 years ago in 2008. We are now in the future
and they are still
The precedent has already been set by other macros in the same file.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ set but not
used [-Wunused-but-set-variable]
55 | struct drm_crtc *crtc;
| ^~~~
Cc: Maarten Lankhorst
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/v3d/v3d_gem.c:292: warning: Function parameter or member
'bo_handles' not described in 'v3d_lookup_bos'
drivers/gpu/drm/v3d/v3d_gem.c:292: warning: Function parameter or member
'bo_count' not described in 'v3d_lookup_bos'
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/v3d/v3d_sched.c:75: warning: Function parameter or member
'sched_job' not described in 'v3d_job_dependency'
drivers/gpu/drm/v3d/v3d_sched.c:75: warning: Function parameter or member
's_entity' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/via/via_dma.c: In function ‘via_cmdbuf_jump’:
drivers/gpu/drm/via/via_dma.c:596:11: warning: variable ‘agp_base’ set but not
used [-Wunused-but-set-variable]
Cc: David Airlie
Cc: Daniel Vetter
Cc:
On Thu, 12 Nov 2020, santosh.shilim...@oracle.com wrote:
> On 11/12/20 5:21 AM, Lee Jones wrote:
> > On Thu, 12 Nov 2020, Tero Kristo wrote:
> >
> > > On 12/11/2020 12:31, Lee Jones wrote:
> > > > Cc:ing a few people I know.
> > > >
> > > > On Tue, 03 Nov 2020, Lee Jones wrote:
> > > >
> > > >
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/exynos/exynos7_drm_decon.c:354: warning: Function parameter or
member 'ctx' not described in 'decon_shadow_protect_win'
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: David Airlie
Cc: Daniel Vetter
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:464: warning: Function parameter or
member 'bo' not described in 'amdgpu_move_blit'
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:464: warning: Function parameter or
member 'evict' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/sti/sti_hdmi.h:36:40: warning: ‘colorspace_mode_names’ defined
but not used [-Wunused-const-variable=]
36 | static const struct drm_prop_enum_list colorspace_mode_names[] = {
| ^
Cc: Benjamin Gaignard
Cc:
... and demote non-conformant kernel-doc header.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning: Function parameter
or member 'subdev' not described in 'nvkm_firmware_get'
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:71: warning:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vc4/vc4_v3d.c:131: warning: Function parameter or member 'vc4'
not described in 'vc4_v3d_pm_get'
drivers/gpu/drm/vc4/vc4_v3d.c:231: warning: Function parameter or member 'vc4'
not described in 'bin_bo_alloc'
Cc: Eric Anholt
The following changes since commit bf3e76289cd28b87f679cd53e26d67fd708d718a:
Merge branch 'mtd/fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux (2020-11-06 13:08:25
-0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:357: warning: Function
parameter or member 'dsi' not described in 'ns2bc'
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:357: warning: Function
parameter or member 'ns' not described in 'ns2bc'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:685: warning: Function parameter or
member 'backoff' not described in 'amdgpu_cs_parser_fini'
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1655: warning: Function parameter or
member 'map' not described in
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_set_audio_infoframe’:
drivers/gpu/drm/vc4/vc4_hdmi.c:334:6: warning: variable ‘ret’ set but not used
[-Wunused-but-set-variable]
Cc: Eric Anholt
Cc: Maxime Ripard
Cc: David Airlie
Cc:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/rockchip/rockchip_rgb.c:71:22: warning: no previous prototype
for ‘rockchip_rgb_init’ [-Wmissing-prototypes]
drivers/gpu/drm/rockchip/rockchip_rgb.c:159:6: warning: no previous prototype
for ‘rockchip_rgb_fini’
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:63: warning: Excess function
parameter 'adev' description in 'amdgpu_ring_alloc'
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:122: warning: Excess function
parameter 'adev' description in
And fix-up a misnamed member description.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:33: warning: cannot understand
function prototype: 'struct atmel_hlcdc_crtc_state '
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c:52: warning: cannot
It seems only to repeat the function name.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:450: warning: Function parameter
or member 'amdgpu_connector' not described in 'amdgpu_display_ddc_probe'
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:450:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:139: warning: Function parameter or
member 'flags' not described in 'amdgpu_fence_emit'
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:197: warning: Function parameter or
member 'timeout' not described in
801 - 900 of 1451 matches
Mail list logo
