syzbot has found a reproducer for the following issue on:
HEAD commit:1b929c02afd3 Linux 6.2-rc1
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=145c6a6848
kernel config: https://syzkaller.appspot.com/x/.config?x=2651619a26b4d687
dashboard link:
Fix all kernel-doc warnings in dc/core/dc.c:
dc.c:385: warning: missing initial short description on line:
* dc_stream_adjust_vmin_vmax:
dc.c:392: warning: contents before sections
dc.c:399: warning: No description found for return value of
'dc_stream_adjust_vmin_vmax'
dc.c:434: warning:
On 2022-12-27 22:16:58, Bjorn Andersson wrote:
> On Mon, Dec 12, 2022 at 10:33:13AM +0100, Konrad Dybcio wrote:
> > [..]
> > + power-domains = < SM8150_MMCX>;
> > + /* TODO: Maybe rpmhpd_opp_min_svs could work as well? */
>
> The power-domain being not disabled
On Fri, Dec 23, 2022 at 09:42:58AM -0800, Rob Clark wrote:
> On Thu, Dec 22, 2022 at 2:29 PM Matthew Brost wrote:
> >
> > In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
> > mapping between a drm_gpu_scheduler and drm_sched_entity. At first this
> > seems a bit odd but let us
Hi Maíra,
Am 28.12.22 um 20:49 schrieb Maíra Canal:
Hi Stefan,
I was able to reproduce this error on drm-misc-next. I bisected,
and I got into commit 6bed2ea3cb38. I noticed that the crtc->mutex is
being locked twice, and this might be causing the problem. I wrote a
patch to try to fix this
On 02/11/2022 20:06, Dmitry Baryshkov wrote:
From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
Hi Stefan,
I was able to reproduce this error on drm-misc-next. I bisected,
and I got into commit 6bed2ea3cb38. I noticed that the crtc->mutex is
being locked twice, and this might be causing the problem. I wrote a
patch to try to fix this issue, and after applying the patch, I wasn't
able to
On Wed, Dec 21, 2022 at 10:43:59PM +0530, Akhil P Oommen wrote:
> From: Ulf Hansson
>
> Some genpd providers doesn't ensure that it has turned off at hardware.
> This is fine until the consumer really requires during some special
> scenarios that the power domain collapse at hardware before it
On Wed, 7 Dec 2022 03:27:58 +0200, Dmitry Baryshkov wrote:
> Add device tree nodes for MDSS, DPU and DSI devices on Qualcomm SM8450
> platform. Enable these devices and add the HDMI bridge configuration on
> SM8450 HDK.
>
> Changes since v3:
> - Renamed mdss node to display-subsystem@ (Krzysztof)
On Wed, Dec 28, 2022 at 8:27 AM Rob Clark wrote:
>
> On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko
> wrote:
> >
> > On 11/17/22 18:09, Christian König wrote:
> > > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko:
> > >> [SNIP]
> > >>> drm_sched_entity_flush() should be called from the flush
If GFX11 microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.
Move the request for GFX11 microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario
If GFX10 microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.
Move the request for GFX10 microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario
If VCN microcode is not available during early init, the microcode
framebuffer will have already been released and the screen will
freeze.
Move the request for VCN microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario Limonciello
---
If GFX9 microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.
Move the request for GFX9 microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario
If PSP microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Move the request for PSP microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario
If SDMA microcode is not available during early init, the microcode
framebuffer will have already been released and the screen will
freeze.
Move the request from SDMA microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario Limonciello
If MES microcode is required but not available during early init, the
microcode framebuffer will have already been released and the screen will
freeze.
Move the request for MES microcode into the IP discovery phase
so that if it's not available, IP discovery will fail.
Signed-off-by: Mario
The special case for the one dGPU has been moved into
`amdgpu_ucode_ip_version_decode`, so simplify this code.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git
Remove the special casing from SMU v11 code. No intended functional
changes.
Signed-off-by: Mario Limonciello
---
.../gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c| 35 ++-
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c
This will allow other parts of the driver that currently special
case firmware file names to before IP version style naming to just
have a single call to `amdgpu_ucode_ip_version_decode`.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 208 ++
Removing the firmware framebuffer from the driver means that even
if the driver doesn't support the IP blocks in a GPU it will no
longer be functional after the driver fails to initialize.
This change will ensure that unsupported IP blocks at least cause
the driver to work with the EFI
One of the first thing that KMS drivers do during initialization is
destroy the system firmware framebuffer by means of
`drm_aperture_remove_conflicting_pci_framebuffers`
This means that if for any reason the GPU failed to probe the user
will be stuck with at best a screen frozen at the last
From: Randy Dunlap
[ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ]
The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
../drivers/video/fbdev/uvesafb.c: In
From: Randy Dunlap
[ Upstream commit 71c53e19226b0166ba387d3c590d0509f541a0a1 ]
The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
In file included from
On Thu, Nov 17, 2022 at 7:12 AM Dmitry Osipenko
wrote:
>
> On 11/17/22 18:09, Christian König wrote:
> > Am 17.11.22 um 15:41 schrieb Dmitry Osipenko:
> >> [SNIP]
> >>> drm_sched_entity_flush() should be called from the flush callback from
> >>> the file_operations structure of panfrost. See
From: Randy Dunlap
[ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ]
The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
../drivers/video/fbdev/uvesafb.c: In
From: Randy Dunlap
[ Upstream commit 71c53e19226b0166ba387d3c590d0509f541a0a1 ]
The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
In file included from
From: Randy Dunlap
[ Upstream commit 35b4f4d4a725cf8f8c10649163cd12aed509b953 ]
The uvesafb fbdev driver uses memory management information that is not
available on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
../drivers/video/fbdev/uvesafb.c: In
From: Randy Dunlap
[ Upstream commit 71c53e19226b0166ba387d3c590d0509f541a0a1 ]
The geode fbdev driver uses struct cpuinfo fields that are not present
on ARCH=um, so don't allow this driver to be built on UML.
Prevents these build errors:
In file included from
From: Thomas Zimmermann
[ Upstream commit dbbf933d365da1a76a540211bee3d57bde520194 ]
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
From: Thomas Zimmermann
[ Upstream commit dbbf933d365da1a76a540211bee3d57bde520194 ]
In drm_atomic_helper_check_crtc_state(), do not add a new plane state
to the global state if it does not exist already. Adding a new plane
state will result in overhead for the plane during the atomic-commit
Hello,
Commit 2541626cfb79 breaks GM20B probe with
the following kernel log:
[2.153892] [ cut here ]
[2.153897] WARNING: CPU: 1 PID: 36 at
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273
gf100_vmm_valid+0x2c4/0x390
[2.153916] Modules linked in:
[
On 12/27, Maíra Canal wrote:
> As v3d_submit_tfu_ioctl() performs the same steps as drm_gem_object_lookup(),
> replace the open-code implementation in v3d with its DRM core equivalent.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/v3d/v3d_gem.c | 7 +--
> 1 file changed, 1
On Wed, Dec 28, 2022 at 03:48:05PM +0200, Mikko Perttunen wrote:
> On 12/28/22 15:34, Deepak R Varma wrote:
> > On Wed, Dec 28, 2022 at 03:17:59PM +0200, Mikko Perttunen wrote:
> > > On 12/28/22 15:08, Deepak R Varma wrote:
> > >
> > > Hi,
> > >
> > > it gets rid of visual hints on code paths
On Fri, Dec 23, 2022 at 03:42:33PM +0100, Ard Biesheuvel wrote:
> (cc Andy)
I believe there are two reasons I'm Cc'ed now:
- the Cc was forgotten. because I remember reviewing some parts
of this contribution
- this conflicts (to some extent) with my patch that speeds up
the scrolling
For the
On 12/28/22 15:34, Deepak R Varma wrote:
On Wed, Dec 28, 2022 at 03:17:59PM +0200, Mikko Perttunen wrote:
On 12/28/22 15:08, Deepak R Varma wrote:
On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:
On 12/27/22 19:14, Deepak R Varma wrote:
kfree() & vfree() internally perform
On Wed, Dec 28, 2022 at 03:17:59PM +0200, Mikko Perttunen wrote:
> On 12/28/22 15:08, Deepak R Varma wrote:
> > On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:
> > > On 12/27/22 19:14, Deepak R Varma wrote:
> > > > kfree() & vfree() internally perform NULL check on the pointer
On 12/28/22 15:08, Deepak R Varma wrote:
On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:
On 12/27/22 19:14, Deepak R Varma wrote:
kfree() & vfree() internally perform NULL check on the pointer handed
to it and take no action if it indeed is NULL. Hence there is no need
for a
Add in missing qcom,dsi-phy-regulator-ldo-mode to the 28nm DSI PHY.
When converting from .txt to .yaml we missed this one.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
This is the one remaining patch I had from a previous series for
mdss-dsi-ctrl and the dsi-phy. The mdss-dsi-ctrl set became a bigger so I
split out the 28nm phy fixes.
I'm resubmitting with Dmitry's RB as a standalone.
Old:
On Wed, Dec 28, 2022 at 02:28:54PM +0200, Mikko Perttunen wrote:
> On 12/27/22 19:14, Deepak R Varma wrote:
> > kfree() & vfree() internally perform NULL check on the pointer handed
> > to it and take no action if it indeed is NULL. Hence there is no need
> > for a pre-check of the memory pointer
On 12/27/22 19:14, Deepak R Varma wrote:
kfree() & vfree() internally perform NULL check on the pointer handed
to it and take no action if it indeed is NULL. Hence there is no need
for a pre-check of the memory pointer before handing it to
kfree()/vfree().
Issue reported by ifnullfree.cocci
Hi Javier,
Could you please also cc maintainers on the actual macro addition since
it's hard to review without seeing what the code gets changed to
(especially when there's multiple revisions). I assume
https://lore.kernel.org/dri-devel/20221228014757.3170486-2-javi...@redhat.com/
is the
Hi,
Am 21.12.22 um 20:46 schrieb Stefan Wahren:
Hi,
if i enable PROVE_LOCKING on the Raspberry Pi 3 B+
(arm/multi_v7_defconfig) using v6.1 (didn't test older versions) i'm
getting the following warning:
[ 204.043396] WARNING: CPU: 2 PID: 42 at
drivers/gpu/drm/drm_modeset_lock.c:276
On Tue, Dec 27, 2022 at 11:36:13PM +0530, Deepak R Varma wrote:
> On Tue, Dec 27, 2022 at 12:13:56PM -0500, Rodrigo Vivi wrote:
> > On Tue, Dec 27, 2022 at 01:30:53PM +0530, Deepak R Varma wrote:
> > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > function adds the
drm_print.h says DRM_DEBUG_KMS is deprecated in favor of
drm_dbg_kms().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 112 ++---
drivers/gpu/drm/drm_color_mgmt.c | 4 +-
drivers/gpu/drm/drm_connector.c| 21 ++---
drm_print.h says DRM_DEBUG is deprecated in favor of drm_dbg_core().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_agpsupport.c | 4 +-
drivers/gpu/drm/drm_bufs.c| 114 +++---
drivers/gpu/drm/drm_context.c | 14 ++--
drivers/gpu/drm/drm_dma.c
drm_print.h says DRM_INFO is deprecated in favor of drm_notice().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_displayid.c | 2 +-
drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c
radeon_get_connector_for_encoder() assigns radeon_encoder->enc_priv to
mst_enc which is dereferenced later without being checked for NULL
beforehand. It is possible for radeon_encoder->enc_priv and therefore
mst_enc, to be NULL due to potential lack of memory.
This patch adds a sanity NULL-check
This patchset aims to remove usages of deprecated DRM_* macros from the
files residing in drivers/gpu/drm root.
In process, I found out that NULL as first argument of drm_dbg_* wasn't
working, but it was listed as the alternative in deprecation comment,
so I fixed that before removing usages of
drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().
Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
include/drm/drm_print.h
Comments say macros DRM_DEBUG_* are deprecated in favor of
drm_dbg_*(NULL, ...), but they have broken support for it,
as the macro will result in `(NULL) ? (NULL)->dev : NULL`.
Thus, fix them by separating logic to get dev ptr in a new
function, which will return the dev ptr if arg is not NULL.
drm_print.h says DRM_DEBUG_PRIME is deprecated in favor of
drm_dbg_prime().
Signed-off-by: Siddh Raman Pant
Reviewed-by: Simon Ser
---
drivers/gpu/drm/drm_gem_dma_helper.c | 4 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Due to my rookie mistake this patch isn't necessary anymore in
upstream version. The issue was already resolved in a different
manner.
Apologies for inconvenience.
drm_print.h says DRM_DEBUG_ATOMIC is deprecated in favor of
drm_dbg_atomic().
Signed-off-by: Siddh Raman Pant
Reviewed-by: Simon Ser
---
drivers/gpu/drm/drm_blend.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c
drm_print.h says DRM_DEBUG_LEASE is deprecated in favor of
drm_dbg_lease().
Signed-off-by: Siddh Raman Pant
Reviewed-by: Simon Ser
---
drivers/gpu/drm/drm_lease.c | 64 -
1 file changed, 34 insertions(+), 30 deletions(-)
diff --git
drm_print.h says DRM_INFO is deprecated in favor of drm_info().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_client_modeset.c | 2 +-
drivers/gpu/drm/drm_connector.c | 7 ---
drivers/gpu/drm/drm_drv.c| 2 +-
drivers/gpu/drm/drm_pci.c| 2 +-
4 files
drm_print.h says DRM_ERROR is deprecated in favor of drm_err().
Signed-off-by: Siddh Raman Pant
---
drivers/gpu/drm/drm_bridge.c | 8
drivers/gpu/drm/drm_bufs.c | 8
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
drivers/gpu/drm/drm_context.c| 4
On Thu, 22 Dec 2022 21:10:34 +0530, Siddh Raman Pant wrote:
> Changes in v2:
> - Removed conversions to pr_*() in DRM_INFO, DRM_NOTE, and DRM_ERROR changes.
> - Due to above, DRM_NOTE usage cannot be removed and the patch is dropped.
> - DRY: NULL support is now achieved by way of a separate
On Fri, 23 Dec 2022 15:35:58 +0300
Dmitry Osipenko wrote:
> 28.11.2022 18:23, Luca Ceresoli пишет:
...
> > +static const struct tegra_vip_ops tegra20_vip_ops = {
> > + .vip_start_streaming = tegra20_vip_start_streaming,
> > +};
> > +
> > +const struct tegra_vip_soc tegra20_vip_soc = {
> > +
On Thu, 8 Dec 2022 at 00:42, Abhinav Kumar wrote:
>
>
>
> On 12/5/2022 8:37 AM, Robert Foss wrote:
> > Add compatibility for SM8350 display subsystem, including
> > required entries in DPU hw catalog.
> >
> > Signed-off-by: Robert Foss
> > ---
> > .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
On 12/27/2022 11:54 PM, Bjorn Andersson wrote:
> On Mon, Dec 12, 2022 at 04:39:09PM +0100, Ulf Hansson wrote:
>> On Fri, 9 Dec 2022 at 18:36, Ulf Hansson wrote:
>>> On Thu, 8 Dec 2022 at 22:06, Bjorn Andersson wrote:
On Thu, Dec 08, 2022 at 02:40:55PM +0100, Ulf Hansson wrote:
> On Wed,
On Tue, 27 Dec 2022, Alexey Lukyachuk wrote:
> On Tue, 27 Dec 2022 11:39:25 -0500
> Rodrigo Vivi wrote:
>
>> On Sun, Dec 25, 2022 at 09:55:08PM +0300, Alexey Lukyanchuk wrote:
>> > dell wyse 3040 doesn't peform poweroff properly, but instead remains in
>> > turned power on state.
>>
>> okay,
On Mon, 5 Dec 2022 at 17:47, Krzysztof Kozlowski
wrote:
>
> On 05/12/2022 17:37, Robert Foss wrote:
> > The sm8350-hdk ships with the LT9611 UXC DSI/HDMI bridge chip.
> >
> > In order to toggle the board to enable the HDMI output,
> > switch #7 & #8 on the rightmost multi-switch package have
> >
On 12/28/22 02:44, yang.yan...@zte.com.cn wrote:
From: Xu Panda
The implementation of strscpy() is more robust and safer.
That's now the recommended way to copy NUL-terminated strings.
Signed-off-by: Xu Panda
Signed-off-by: Yang Yang
---
drivers/video/fbdev/aty/atyfb_base.c | 3 +--
1
65 matches
Mail list logo
