[Public]
Reviewed-by: Srinivasan Shanmugam
-Original Message-
From: amd-gfx On Behalf Of
shijie...@208suo.com
Sent: Friday, July 14, 2023 1:36 PM
To: Deucher, Alexander ; Pan, Xinhui
; airl...@gmail.com; dan...@ffwll.ch
Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.or
On 7/12/23 08:12, Alex Deucher wrote:
On Wed, Jul 12, 2023 at 8:04 AM Ricardo Cañuelo
wrote:
UBSAN complains about out-of-bounds array indexes on all 1-element
arrays defined on this driver:
UBSAN: array-index-out-of-bounds in
/home/rcn/work/repos/kernelci/kernelci-core/linux_kernel_mainl
On Thu, Jul 13, 2023 at 1:13 PM Randy Dunlap wrote:
>
>
>
> On 7/13/23 09:36, Jim Cromie wrote:
> > Add some basic info on classmap usage and api
> >
> > Signed-off-by: Jim Cromie
> > ---
> > .../admin-guide/dynamic-debug-howto.rst | 64 ++-
> > 1 file changed, 63 insertion
On Thu, Jul 13, 2023 at 1:04 PM Randy Dunlap wrote:
>
> Hi Jim,
>
> On 7/13/23 09:36, Jim Cromie wrote:
> > Signed-off-by: Jim Cromie
> > ---
> > lib/Kconfig.debug | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index d4f
On 7/13/23 21:58, Harry Wentland wrote:
> After driver init we shouldn't create new properties. Doing so
> will lead to a warning storm from __drm_mode_object_add.
>
> We don't really need to create the property for MST connectors.
> Re-using the mst_root connector's property is fine.
>
> v2: Add
Even if there's nothing currently parsing amdgpu's coredump files, if
we eventually have such tools they will be glad to find a version field
to properly read the file.
Create a version number to be displayed on top of coredump file, to be
incremented when the file format or content get changed.
Giving that we use codedump just for device resets, move it's functions
and structs to a more semantic file, the amdgpu_reset.{c, h}.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 9 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 80 --
driv
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
driver
During a GPU reset, a normal memory reclaim could block to reclaim
memory. Giving that coredump is a best effort mechanism, it shouldn't
disturb the reset path. Change its memory allocation flag to a
nonblocking one.
Signed-off-by: André Almeida
Reviewed-by: Christian König
---
drivers/gpu/drm/
Create a module parameter to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu
Hi,
The goal of this patchset is to improve debugging device resets on amdgpu.
The first patch creates a new module parameter to disable soft recoveries,
ensuring every recovery go through the full device reset, making easier to
generate resets from userspace tools like [0] and [1]. This is impor
Am 2023-07-14 um 10:26 schrieb Vlastimil Babka:
On 7/12/23 18:24, Felix Kuehling wrote:
Allocations in the heap and stack tend to be small, with several
allocations sharing the same page. Sharing the same page for different
allocations with different access patterns leads to thrashing when we
mi
On 7/12/23 18:24, Felix Kuehling wrote:
> Allocations in the heap and stack tend to be small, with several
> allocations sharing the same page. Sharing the same page for different
> allocations with different access patterns leads to thrashing when we
> migrate data back and forth on GPU and CPU
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Candice Li
Sent: Friday, July 14, 2023 1:41 AM
To: amd-gfx@lists.freedesktop.org
Cc: Li, Candice ; Zhang, Hawking
Subject: [PATCH] drm/amdgpu: Allow the initramfs generator to include
psp_13_0_6_t
On Fri, 14 Jul 2023 14:34:04 +0900
wrote:
> >> > So I'm confused about why it's mentioned. Was it backported?
> >>
> >> Taketo Kabe, could you please help to clean this confusion up? Did you
> >> mean 5.19 in https://bugzilla.kernel.org/show_bug.cgi?id=217669#c5 ? And
> >> BTW: did you really
On 2023-07-14 05:44, sguttula wrote:
This patch will enable secure decode playback on VCN4
Signed-off-by: sguttula
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
in
Hi Paulo,
> I didn't review all struct changes but I reckon that you got the train
> of thought to be followed by now. Please count on me for reviewing those
> changes :-)
Thanks for reviewing the patch. It turned out that making these changes
properly isn't so trivial as I thought and I'll need
Hi
Am 13.07.23 um 17:14 schrieb Tvrtko Ursulin:
On 13/07/2023 16:09, Thomas Zimmermann wrote:
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this
Hi Thomas,
On Fri, Jul 14, 2023 at 9:53 AM Thomas Zimmermann wrote:
> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> useful when fbdev had special handling for driver modules. With
> commit 376b3ff54c9a
On Wed, Jul 12, 2023 at 10:12:08AM -0400, Alex Deucher wrote:
> On Wed, Jul 12, 2023 at 8:04 AM Ricardo Cañuelo
> wrote:
> >
> > UBSAN complains about out-of-bounds array indexes on all 1-element
> > arrays defined on this driver:
> >
> > UBSAN: array-index-out-of-bounds in
> > /home/rcn/work/rep
Fix five occurrences of the checkpatch.pl error:
ERROR: "foo* bar" should be "foo *bar"
ERROR: that open brace { should be on the previous line
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/radeon_audio.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/driver
On 2023/7/14 15:49, Thomas Zimmermann wrote:
Most fbdev drivers depend on framebuffer_alloc() to initialize the
allocated memory to 0. Document this guarantee.
v3:
* slightly reword the sentence (Miguel)
Suggested-by: Miguel Ojeda
Signed-off-by: Thomas Zimmermann
Reviewed-by: Miguel
On Fri, Jul 14, 2023 at 12:24:05PM +0200, Thomas Zimmermann wrote:
> >
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag FBINFO_DEFAUL
Em 14/07/2023 04:57, Christian König escreveu:
Am 13.07.23 um 23:32 schrieb André Almeida:
Log the IB addresses used by the hung job along with the stuck ring
name. Note that due to nested IBs, the one that caused the reset itself
may be in not listed address.
Signed-off-by: André Almeida
-
Em 14/07/2023 04:52, Christian König escreveu:
Am 13.07.23 um 23:32 schrieb André Almeida:
If a kernel thread caused the reset, the information available to be
logged will be limited, so return early in the dump function.
Why? The register values and vram lost state should still be valid.
~0 as no xcp partition is used in several places, so improve its
definition by a macro for code consistency.
Suggested-by: Christian König
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_xcp.c | 4 ++--
drivers/
[Public]
> -Original Message-
> From: Mikhail Gavrilov
> Sent: Saturday, July 8, 2023 6:27 AM
> To: Chen, Guchun
> Cc: amd-gfx list ; Koenig, Christian
> ; Deucher, Alexander
> ; Linux List Kernel Mailing ker...@vger.kernel.org>
> Subject: Re: [regression][6.5] KASAN: slab-out-of-bounds
Other PDs/PTs allocation should just use the same xcp_id as that
stored in root PD.
Suggested-by: Christian König
Signed-off-by: Guchun Chen
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/
Recent code set xcp_id stored from file private data when opening
device to amdgpu bo for accounting memory usage etc, but not all
VMs are attached to this fpriv structure like the vm cases in
amdgpu_mes_self_test, otherwise, KASAN will complain below out
of bound access. And more importantly, VM c
Hi
Am 14.07.23 um 12:29 schrieb Dan Carpenter:
On Fri, Jul 14, 2023 at 12:24:05PM +0200, Thomas Zimmermann wrote:
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
fbde
This patch will enable VCN FW workaround using
DRM KEY INJECT WORKAROUND method,
which is helping in fixing the secure playback.
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message as per veera's feedback
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 9 +
drivers/gpu/drm/
Hi
Am 14.07.23 um 12:04 schrieb Geert Uytterhoeven:
Hi Thomas,
On Fri, Jul 14, 2023 at 9:53 AM Thomas Zimmermann wrote:
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handl
[AMD Official Use Only - General]
Suresh,
Please modify the commit message to a more meaningful one.
1. add a commit title
2. write about the changes than the effect of the change.
Something like Enabling FW workaround in using shared memory for VCN 4
3. Can you please check if this change is appl
This patch will fix the secure playback corruption due
to HW bug on VCN4.
Signed-off-by: sguttula
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 9 +
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 4
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
This patch will enable secure decode playback on VCN4
Signed-off-by: sguttula
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index e8c02ae10163..d199f87febd1 100644
--- a
Update the list of devices that require the cwsr trap handling
workaround for debugging use cases.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdkfd/kfd_debug.c| 5 ++---
drivers/gpu/drm/amd/amdkfd/kfd_debug.h| 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_dev
MES can concurrently schedule queues on the device that require
exclusive device access if marked exclusively_scheduled without the
requirement of GWS. Similar to the F32 HWS, MES will manage
quality of service for these queues.
Use this for cooperative groups since cooperative groups are device
o
Am 13.07.23 um 23:32 schrieb André Almeida:
Log the IB addresses used by the hung job along with the stuck ring
name. Note that due to nested IBs, the one that caused the reset itself
may be in not listed address.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h|
Am 13.07.23 um 23:32 schrieb André Almeida:
If a kernel thread caused the reset, the information available to be
logged will be limited, so return early in the dump function.
Why? The register values and vram lost state should still be valid.
Christian.
Signed-off-by: André Almeida
---
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix co
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by a static declaration. So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by a static declaration. So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix c
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
Most fbdev drivers depend on framebuffer_alloc() to initialize the
allocated memory to 0. Document this guarantee.
v3:
* slightly reword the sentence (Miguel)
Suggested-by: Miguel Ojeda
Signed-off-by: Thomas Zimmermann
Reviewed-by: Miguel Ojeda
Cc: Helge Deller
---
drivers/video/fbde
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix co
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* f
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_.
v3:
* include board name in commit mess
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No
functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Helge Deller
---
include/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d5c13f34b0
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* f
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* f
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix co
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit messa
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by devm_kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* f
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handling for driver modules. With
commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
and have no further effect.
P
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix co
Am 13.07.23 um 23:32 schrieb André Almeida:
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Signed-off-by: André Almeida
---
v2: Replace GFP_
Am 14.07.23 um 07:35 schrieb shijie...@208suo.com:
Fix one occurrence of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
It's nice to see all those little typos fixed, but I'm not sure how
feasible it is to send patches for each type individually.
Maybe just merge them together
On Fri, 14 Jul 2023 09:50:17 +0700
Bagas Sanjaya wrote:
> Hi,
>
> I notice a regression report on Bugzilla [1]. Quoting from it:
>
>
> See Bugzilla for the full thread and attached patches that fixes
> this regression.
>
> Later, when bisecting, the reporter got better kernel trace:
>
> > [
Fix four occurrences of the checkpatch.pl error:
ERROR: open brace '{' following enum go on the same line
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/ni_dpm.h | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni_dpm.h
b/drivers/gpu/dr
Fix the checkpatch error as open brace '{' following struct should
go on the same line.
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/include/yellow_carp_offset.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/yellow_carp_offset.h
b/drive
Add missing spaces and remove spaces to clear checkpatch errors.
ERROR: space prohibited before that ',' (ctx:WxV)
ERROR: space required after that ',' (ctx:VxV)
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/include/atom-bits.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
Thanks you all for getting attention to the report:
regressi...@leemhuis.info sed in
<55a3bbb1-5b3c-f454-b529-8ee9944cc...@leemhuis.info>
>> On 14.07.23 05:12, Steven Rostedt wrote:
>> > On Fri, 14 Jul 2023 09:50:17 +0700
>> > Bagas Sanjaya wrote:
>> >
>> >> I notice a regression report on Bu
Fix two occurrences of the checkpatch.pl error:
ERROR: space prohibited before that ',' (ctx:WxV)
ERROR: space required after that ',' (ctx:WxV)
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/atom-bits.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rade
Fix the checkpatch error as open brace '{' following struct should
go on the same line.
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/include/discovery.h | 33 +
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/discovery.h
b/
Fix four occurrences of the checkpatch.pl error:
ERROR: trailing whitespace
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/include/amd_shared.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_share
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Origin report: https://gitlab.freedesktop.org/drm/amd/-/issues/2615
>
> Compile with CONFIG_DRM_RADEON=m on 32bit,
> kernel panics on radeon.ko load.
>
> On slow machine, there is 70 second window between
> login: prompt on ra
Thanks you all for getting attention to the report:
regressi...@leemhuis.info sed in
<55a3bbb1-5b3c-f454-b529-8ee9944cc...@leemhuis.info>
>> On 14.07.23 05:12, Steven Rostedt wrote:
>> > On Fri, 14 Jul 2023 09:50:17 +0700
>> > Bagas Sanjaya wrote:
>> >
>> >> I notice a regression report on Bu
Fix one occurrence of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/uvd_v1_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c
b/drivers/gpu/drm/radeon/uvd_v1_0.c
index 58557
Fix four occurrences of the checkpatch.pl error:
ERROR: open brace '{' following function definitions go on the next line
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rade
Fix two occurrences of the checkpatch.pl error:
ERROR: spaces required around that '+=' (ctx:VxV)
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/r100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r100.c
b/drivers/gpu/drm/radeon/r100.c
index af
Fix the checkpatch error as open brace '{' following struct should
go on the same line.
Signed-off-by: Ran Sun
---
drivers/gpu/drm/amd/include/atomfirmwareid.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/include/atomfirmwareid.h
b/drivers/gpu/d
On 14.07.23 05:12, Steven Rostedt wrote:
> On Fri, 14 Jul 2023 09:50:17 +0700
> Bagas Sanjaya wrote:
>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>
>>
>> See Bugzilla for the full thread and attached patches that fixes
>> this regression.
>>
>> Later, when bisecting, the r
Fix eight occurrences of the checkpatch.pl error:
ERROR: that open brace { should be on the previous line
ERROR: space prohibited before that close parenthesis ')'
ERROR: spaces required around that '?' (ctx:VxW)
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/sumo_dpm.c | 18
Fix seventeen occurrences of the checkpatch.pl error:
ERROR: open brace '{' following struct go on the same line
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/smu7_discrete.h | 51 +-
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/rad
77 matches
Mail list logo
