On Thu, May 23, 2024 at 05:59:39PM +0200, Armin Wolf wrote:
> Am 23.05.24 um 15:13 schrieb Barry Kauler:
>
> > On Wed, May 22, 2024 at 12:58 AM Armin Wolf wrote:
> > > Am 20.05.24 um 18:22 schrieb Alex Deucher:
> > >
> > > > On Sat, May 18, 2024 at 8:17 PM Armin Wolf wrote:
> > > > > Am
Ok, I'm getting tired of seeing these for the USB portion of the tree,
so I went to look for:
On Fri, May 03, 2024 at 04:44:42AM +0800, kernel test robot wrote:
> |-- arc-randconfig-002-20240503
> | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used
This warning (same for
On Fri, May 03, 2024 at 11:30:50AM +0530, Krishna Kurapati PSSNV wrote:
>
>
> On 5/3/2024 10:42 AM, Greg KH wrote:
> > Ok, I'm getting tired of seeing these for the USB portion of the tree,
> > so I went to look for:
> >
> > On Fri, May 03, 2024 at 04:44:42
On Thu, Apr 18, 2024 at 03:19:46AM +, wangzhu wrote:
> Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
> in linux-5.10, there is a patch in the linux-6.7 branch to fix it, its commit
> is 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB
>
On Thu, Apr 18, 2024 at 01:51:33AM +, wangzhu wrote:
> Hi Greg, thanks for your reply. Since there is no patch to fix CVE-2023-52624
> in linux-5.10, there is a patch in the linux-6.7 branch, its commit is
> 2ef98c6d753a744e333b7e34b9cf687040fba57d ("drm/amd/display: Wake DMCUB before
>
On Tue, Apr 16, 2024 at 03:52:40AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit 2ef98c6d753a744e333b7e34b9cf687040fba57d
> category: bugfix
> bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9BV4C
> CVE: CVE-2023-52624
>
>
On Tue, Apr 16, 2024 at 02:43:47AM +, Zhu Wang wrote:
> From: Nicholas Kazlauskas
>
> stable inclusion
> from stable-v6.7.3
> commit2ef98c6d753a7 ("drm/amd/display: Wake DMCUB before executing
> GPINT commands")
> category: bugfix
> bugzilla:
On Thu, Jan 04, 2024 at 08:54:19AM -0500, Hamza Mahfooz wrote:
> On 1/3/24 14:17, Joshua Ashton wrote:
> > Thanks! Is it possible for us to get this backported too?
>
> Sure thing.
>
> Cc: sta...@vger.kernel.org
This is not the correct way to submit patches for inclusion in the
stable kernel
On Wed, Jan 03, 2024 at 09:44:18AM -0500, Hamza Mahfooz wrote:
> On 12/29/23 11:25, Melissa Wen wrote:
> > IGT `amdgpu/amd_color/crtc-lut-accuracy` fails right at the beginning of
> > the test execution, during atomic check, because DC rejects the
> > bandwidth state for a fb sizing 64x64. The
On Thu, Nov 09, 2023 at 10:43:50AM +0200, José Pekkarinen wrote:
> On 2023-11-08 09:29, Greg KH wrote:
> > On Wed, Nov 08, 2023 at 08:54:35AM +0200, José Pekkarinen wrote:
> > > The following case seems to be safe to be replaced with a flexible
> > > array
> > &
On Wed, Nov 08, 2023 at 08:40:48AM +0100, Heiner Kallweit wrote:
> On 08.11.2023 08:05, Greg KH wrote:
> > On Wed, Nov 08, 2023 at 11:34:00AM +0800, Li Ma wrote:
> >> From: Heiner Kallweit
> >>
> >> This effectively reverts 4b5f82f6aaef. On a number of sys
On Wed, Nov 08, 2023 at 08:54:35AM +0200, José Pekkarinen wrote:
> The following case seems to be safe to be replaced with a flexible array
> to clean up the added coccinelle warning. This patch will just do it.
>
> drivers/gpu/drm/amd/pm/powerplay/smumgr/smu8_smumgr.h:76:38-63: WARNING use
>
On Wed, Nov 08, 2023 at 11:34:00AM +0800, Li Ma wrote:
> From: Heiner Kallweit
>
> This effectively reverts 4b5f82f6aaef. On a number of systems ASPM L1
> causes tx timeouts with RTL8168h, see referenced bug report.
>
> Fixes: 4b5f82f6aaef ("r8169: enable ASPM L1/L1.1 from RTL8168h")
> Cc:
On Mon, Oct 09, 2023 at 02:46:40PM +0200, Christian König wrote:
> Am 07.10.23 um 11:50 schrieb Greg KH:
> > On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
> > > This is also causing log spam on 5.15. It was included in 5.15.1
On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
> This is also causing log spam on 5.15. It was included in 5.15.128 as
> commit 4921792e04f2125b5eadef9dbe9417a8354c7eff. I encountered this and
> found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching
> the
On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
> This is also causing log spam on 5.15. It was included in 5.15.128 as
> commit 4921792e04f2125b5eadef9dbe9417a8354c7eff. I encountered this and
> found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching
> the
On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
> Am 31.08.23 um 12:56 schrieb Greg KH:
> > On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
> > > Am 30.08.23 um 20:53 schrieb Chia-I Wu:
> > > > On Sun, Jul 23, 2023 at 6:24 PM Sash
On Wed, Aug 30, 2023 at 11:53:29AM -0700, Chia-I Wu wrote:
> On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin wrote:
> >
> > From: Lang Yu
> >
> > [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
> >
> > When using cpu to update page tables, vm update fences are unused.
> > Install stub
On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
> Am 30.08.23 um 20:53 schrieb Chia-I Wu:
> > On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin wrote:
> > > From: Lang Yu
> > >
> > > [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
> > >
> > > When using cpu to update
On Wed, Aug 23, 2023 at 10:53:43AM +0300, Kalle Valo wrote:
> Greg KH writes:
>
> > On Mon, Aug 21, 2023 at 10:13:45PM -0500, Limonciello, Mario wrote:
> >> So I wonder if the right answer is to put it in drivers/net/wireless
> >> initially and if we come up
On Mon, Aug 21, 2023 at 10:13:45PM -0500, Limonciello, Mario wrote:
> So I wonder if the right answer is to put it in drivers/net/wireless
> initially and if we come up with a need later for non wifi producers we can
> discuss moving it at that time.
Please do so.
thanks,
greg k-h
On Fri, Aug 18, 2023 at 05:49:14PM -0500, Limonciello, Mario wrote:
>
>
> On 8/18/2023 4:24 PM, Greg KH wrote:
> > On Fri, Aug 18, 2023 at 11:26:11AM +0800, Evan Quan wrote:
> > > drivers/base/Makefile | 1 +
> > > drivers/base/wbrf.
On Fri, Aug 18, 2023 at 11:26:11AM +0800, Evan Quan wrote:
> drivers/base/Makefile | 1 +
> drivers/base/wbrf.c | 280 ++
Why is a wifi-specific thing going into drivers/base/?
confused,
greg k-h
On Tue, Apr 25, 2023 at 05:48:27PM -0700, Chia-I Wu wrote:
> Signed-off-by: Chia-I Wu
> Cc: sta...@vger.kernel.org
I know I can not take patches without any changelog text at all, maybe
the DRM developers are more lax, but it's not a good idea at all.
thanks,
greg k-h
On Tue, Apr 25, 2023 at 11:17:14PM -0700, Chia-I Wu wrote:
> mgr->ctx_handles should be protected by mgr->lock.
>
> v2: improve commit message
>
> Signed-off-by: Chia-I Wu
> Cc: sta...@vger.kernel.org
What commit id does this fix? How far back in stable kernels should
this go?
thanks,
greg
On Tue, Apr 18, 2023 at 07:15:22PM -0300, Guilherme G. Piccoli wrote:
> commit 542a56e8eb4467ae654eefab31ff194569db39cd upstream.
>
> The VCN firmware loading path enables the indirect SRAM mode if it's
> advertised as supported. We might have some cases of FW issues that
> prevents this mode to
On Fri, Jan 27, 2023 at 03:02:41PM +, Limonciello, Mario wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Linux kernel regression tracking (Thorsten Leemhuis)
> >
> > Sent: Friday, January 27, 2023 03:15
> > To: Greg K
On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote:
> On 1/20/2023 11:46, Guenter Roeck wrote:
> > On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:
> > > This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
> > >
> > > [Why]
> > > Changes cause regression on
On Sat, Jan 21, 2023 at 10:12:16AM +0800, Tim Huang wrote:
> The psp suspend & resume should be skipped to avoid destroy
> the TMR and reload FWs again for IMU enabled APU ASICs.
>
> Signed-off-by: Tim Huang
> Acked-by: Alex Deucher
> Reviewed-by: Mario Limonciello
> ---
>
On Sat, Jan 21, 2023 at 10:49:55AM +0800, Tim Huang wrote:
> PMFW will handle that properly for gpu reset case. Driver involvement
> may cause some unexpected issues.
>
> Signed-off-by: Tim Huang
> ---
> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 14 ++
> 1 file changed, 14
On Thu, Jan 12, 2023 at 04:26:45PM +0100, Daniel Vetter wrote:
> On Thu, 12 Jan 2023 at 13:47, Greg KH wrote:
> > On Wed, Jan 04, 2023 at 07:56:33PM +0200, Dragos-Marian Panait wrote:
> > > From: Jiasheng Jiang
> > >
> > > [ Upstream commit abfa
On Wed, Jan 04, 2023 at 07:56:33PM +0200, Dragos-Marian Panait wrote:
> From: Jiasheng Jiang
>
> [ Upstream commit abfaf0eee97925905e742aa3b0b72e04a918fa9e ]
>
> As the possible failure of the allocation, kmemdup() may return NULL
> pointer.
> Therefore, it should be better to check the
On Wed, Jan 04, 2023 at 08:05:57PM +0200, Dragos-Marian Panait wrote:
>
> On 04.01.2023 16:48, Greg KH wrote:
> > On Wed, Jan 04, 2023 at 09:35:03AM -0500, Alex Deucher wrote:
> > > On Wed, Jan 4, 2023 at 8:23 AM Christian König
> > > wrote:
> > >
On Wed, Jan 04, 2023 at 09:35:03AM -0500, Alex Deucher wrote:
> On Wed, Jan 4, 2023 at 8:23 AM Christian König
> wrote:
> >
> > Am 04.01.23 um 13:41 schrieb Greg KH:
> > > On Tue, Jan 03, 2023 at 08:43:08PM +0200, Dragos-Marian Panait wrote:
> > >> From: J
On Tue, Jan 03, 2023 at 08:43:08PM +0200, Dragos-Marian Panait wrote:
> From: Jiasheng Jiang
>
> [ Upstream commit abfaf0eee97925905e742aa3b0b72e04a918fa9e ]
>
> As the possible failure of the allocation, kmemdup() may return NULL
> pointer.
> Therefore, it should be better to check the
On Tue, Jan 03, 2023 at 08:43:07PM +0200, Dragos-Marian Panait wrote:
> The following commit is needed to fix CVE-2022-3108:
That's a funny cve, given that you can not ever trigger it in a system,
right? Why was a CVE allocated for that?
{sigh}
On Fri, Nov 11, 2022 at 03:17:08PM -0700, Jim Cromie wrote:
> hi Jason, Greg, DRM-folk,
>
> drm.debug-on-dyndbg has a regression due to a chicken-&-egg problem;
> drm.debug is applied to enable dyndbg callsites before the dependent
> modules' callsites are available to be enabled.
>
> My "fixes"
On Fri, Nov 11, 2022 at 03:17:09PM -0700, Jim Cromie wrote:
> drm.debug-on-dyndbg has a regression, due to a chicken-egg
> initialization problem:
>
> 1- modprobe i915
>i915 needs drm.ko, which is loaded 1st
>
> 2- "modprobe drm drm.debug=0x1ff" (virtual/implied)
>drm.debug is set
On Tue, Oct 25, 2022 at 03:15:49PM +0800, Yang Yingliang wrote:
> Inject fault while loading module, kset_register() may fail.
> If it fails, the kset.kobj.name allocated by kobject_set_name()
> which must be called before a call to kset_register() may be
> leaked, since refcount of kobj was set
On Mon, Oct 24, 2022 at 10:39:44PM +0800, Yang Yingliang wrote:
>
> On 2022/10/24 21:52, Greg KH wrote:
> > On Mon, Oct 24, 2022 at 08:19:10PM +0800, Yang Yingliang wrote:
> > > Inject fault while loading module, kset_register() may fail.
> > > If it fails, the name
On Mon, Oct 24, 2022 at 08:19:10PM +0800, Yang Yingliang wrote:
> Inject fault while loading module, kset_register() may fail.
> If it fails, the name allocated by kobject_set_name() which
> is called before kset_register() is leaked, because refcount
> of kobject is hold in kset_init().
>
> As a
On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
>
> On 2022/10/21 13:37, Greg KH wrote:
> > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> > > On 2022-10-20 22:20, Yang Yingliang wrote:
> > > > The previous discussion link:
>
On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote:
>
> On 2022/10/21 13:34, Luben Tuikov wrote:
> > On 2022-10-20 22:20, Yang Yingliang wrote:
> > > kset_register() is currently used in some places without calling
> > > kset_put() in error path, because the callers think it should be
On Fri, Oct 21, 2022 at 03:55:18AM -0400, Luben Tuikov wrote:
> On 2022-10-21 01:37, Greg KH wrote:
> > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> >> On 2022-10-20 22:20, Yang Yingliang wrote:
> >>> The previous discus
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> On 2022-10-20 22:20, Yang Yingliang wrote:
> > The previous discussion link:
> > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
>
> The very first discussion on this was here:
>
>
On Tue, Oct 18, 2022 at 10:17:24AM +0530, Lijo Lazar wrote:
> MMHUB 2.1.x versions don't have ATCL2. Remove accesses to ATCL2 registers.
>
> Since they are non-existing registers, read access will cause a
> 'Completer Abort' and gets reported when AER is enabled with the below patch.
> Tagging
On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> hi Greg, Dan, Jason, DRM-folk,
>
> heres follow-up to V6:
> rebased on driver-core/driver-core-next for -v6 applied bits (thanks)
> rework drm_debug_enabled{_raw,_instrumented,} per Dan.
>
> It excludes:
> nouveau parts
On Sun, Sep 04, 2022 at 03:40:37PM -0600, Jim Cromie wrote:
> hi Greg, Jason, DRM-folk, Steven,
>
> If Im not too late for linux-next in this cycle, heres V6. Diffs are minor:
>
> - rebased onto e47eb90a0a9a (tag: next-20220901, linux-next/master)
>gets past Kconfig conflict, same for
On Wed, Sep 07, 2022 at 04:54:00PM +0200, Greg KH wrote:
> On Sun, Sep 04, 2022 at 03:40:58PM -0600, Jim Cromie wrote:
> > Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as
> > sysfs-nodes for testing.
>
> Wait, why sysfs?
>
> sysfs isn't for t
On Sun, Sep 04, 2022 at 03:40:58PM -0600, Jim Cromie wrote:
> Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as
> sysfs-nodes for testing.
Wait, why sysfs?
sysfs isn't for testing, why not use debugfs?
>
> For each of the 4 class-map-types:
>
> - declare a class-map of
On Tue, Sep 06, 2022 at 09:18:09PM +0200, Daniel Vetter wrote:
> On Fri, Aug 12, 2022 at 08:03:47AM +0200, Greg KH wrote:
> > On Thu, Aug 11, 2022 at 06:52:40PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 03, 2022 at 04:13:05PM -0400, Jason Baron wrote:
> > > >
&g
On Mon, Aug 15, 2022 at 09:11:18PM +0600, Khalid Masum wrote:
> On 8/15/22 20:15, Dong, Ruijing wrote:
> > [AMD Official Use Only - General]
> >
> > Sorry, which "r" value was overwritten? I didn't see the point of making
> > this change.
> >
> > Thanks
> > Ruijing
> >
> > -Original
On Wed, Aug 10, 2022 at 11:39:39AM -0400, Alex Deucher wrote:
> On Wed, Aug 10, 2022 at 11:38 AM Greg KH wrote:
> >
> > On Wed, Aug 10, 2022 at 11:28:18AM -0400, Alex Deucher wrote:
> > > On Tue, Jul 19, 2022 at 2:57 PM Alex Deucher
> > > wrote:
> > > &
PE_SPACE for cat control
> > > Applying: dyndbg: let query-modname override actual module name
> > > Applying: dyndbg: add test_dynamic_debug module
> > > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries
> > >
> > > Jason,
> > > those abo
On Wed, Aug 10, 2022 at 11:28:18AM -0400, Alex Deucher wrote:
> On Tue, Jul 19, 2022 at 2:57 PM Alex Deucher
> wrote:
> >
> > The new vkms virtual display code is atomic so there is
> > no need to call drm_helper_disable_unused_functions()
> > when it is enabled. Doing so can result in a
On Thu, Jul 07, 2022 at 02:56:34PM +0800, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0 Add linux-next
> specific files for 20220706
>
> Error/Warning reports:
>
>
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I
On Mon, May 30, 2022 at 05:29:02PM +0800, Ryan Lin wrote:
> From: Alex Deucher
>
> To avoid a recently added warning:
> Bogus possible_crtcs: [ENCODER:65:TMDS-65] possible_crtcs=0xf (full crtc
> mask=0x7)
> WARNING: CPU: 3 PID: 439 at drivers/gpu/drm/drm_mode_config.c:617
>
On Tue, May 17, 2022 at 05:57:00PM +0800, Yuanjun Gong wrote:
> From: Gong Yuanjun
>
> In radeon_fp_native_mode(), the return value of drm_mode_duplicate()
> is assigned to mode, which will lead to a NULL pointer dereference
> on failure of drm_mode_duplicate(). Add a check to avoid npd.
>
>
On Tue, May 17, 2022 at 05:57:46PM +0800, Yuanjun Gong wrote:
> From: Gong Yuanjun
>
> gpu_metrics_table is allocated in yellow_carp_init_smc_tables() but
> not freed in yellow_carp_fini_smc_tables().
>
> Signed-off-by: Gong Yuanjun
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
On Mon, May 09, 2022 at 03:49:03PM +0100, Lee Jones wrote:
> On Thu, 14 Apr 2022, Greg KH wrote:
>
> > On Tue, Apr 12, 2022 at 04:20:57PM +0100, Lee Jones wrote:
> > > [ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
> > >
> > > This is a pa
On Sat, Apr 23, 2022 at 12:06:33PM -0400, Demi Marie Obenour wrote:
> Two Qubes OS users reported that their AMD GPU systems did not work on
> 5.17.4, while 5.16.18 worked fine. Details can be found on
> https://github.com/QubesOS/qubes-issues/issues/7462. The initial report
> listed the GPU as
On Tue, Apr 12, 2022 at 04:20:57PM +0100, Lee Jones wrote:
> [ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
>
> This is a partial cherry-pick of the above upstream commit.
>
> It ensures the file descriptor passed in by userspace is a valid one.
>
> Cc: Felix Kuehling
> Cc: Alex
On Tue, Apr 12, 2022 at 04:35:28PM +0100, Lee Jones wrote:
> From: Bas Nieuwenhuizen
>
> [ Upstream commit 021830d24ba55a578f602979274965344c8e6284 ]
>
> Otherwise we interpret the file private data as drm & amdgpu data
> while it might not be, possibly allowing one to get memory corruption.
>
On Tue, Apr 12, 2022 at 08:52:11AM +0200, Paul Menzel wrote:
> > Reviewed-by: George Shen
> > Acked-by: Alex Hung
> > Signed-off-by: Martin Leung
>
> Shouldn’t the Signed-off-by line by the author go first?
No, this is the correct order.
thanks,
greg k-h
On Tue, Mar 01, 2022 at 06:40:04PM +0100, Jakob Koschel wrote:
>
>
> > On 1. Mar 2022, at 18:36, Greg KH wrote:
> >
> > On Tue, Mar 01, 2022 at 12:28:15PM +0100, Jakob Koschel wrote:
> >>
> >>
> >>> On 1. Mar 2022, at 01:41, Linus Tor
On Tue, Mar 01, 2022 at 12:28:15PM +0100, Jakob Koschel wrote:
>
>
> > On 1. Mar 2022, at 01:41, Linus Torvalds
> > wrote:
> >
> > On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel
> > wrote:
> >>
> >> The goal of this is to get compiler warnings right? This would indeed be
> >> great.
> >
>
On Mon, Feb 28, 2022 at 01:06:57PM +0100, Jakob Koschel wrote:
>
>
> > On 28. Feb 2022, at 12:20, Greg KH wrote:
> >
> > On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
> >> If the list does not contain the expected element, the value of
&g
On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
> If the list does not contain the expected element, the value of
> list_for_each_entry() iterator will not point to a valid structure.
> To avoid type confusion in such case, the list iterator
> scope will be limited to
On Tue, Jan 25, 2022 at 12:57:29AM +0800, Zhou Qingyang wrote:
> In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()
> is assigned to mode and is passed to drm_mode_probed_add() directly after
> that. drm_mode_probed_add() passes >head to list_add_tail(), and
> there is a
On Tue, Jan 25, 2022 at 12:55:51AM +0800, Zhou Qingyang wrote:
> In calculate_bandwidth(), the tag free_sclk and free_yclk are reversed,
> which could lead to a memory leak of yclk.
>
> Fix this bug by changing the location of free_sclk and free_yclk.
>
> This bug was found by a static analyzer.
On Thu, Jan 27, 2022 at 02:51:56PM +0800, tangmeng wrote:
> Replace disbale with disable and replace unavaibale with unavailable.
>
> Signed-off-by: tangmeng
> ---
> drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
> drivers/pcmcia/rsrc_nonstatic.c
On Sun, Jul 11, 2021 at 05:05:59PM +0300, Oded Gabbay wrote:
> Hi,
> This is v5 of this patch-set following again a long email thread.
>
> It contains fixes to the implementation according to the review that Jason
> did on v4. Jason, I appreciate your feedback. If you can take another look
> to
On Mon, Jun 21, 2021 at 02:28:48PM +0200, Daniel Vetter wrote:
> On Fri, Jun 18, 2021 at 2:36 PM Oded Gabbay wrote:
> > User process might want to share the device memory with another
> > driver/device, and to allow it to access it over PCIe (P2P).
> >
> > To enable this, we utilize the dma-buf
On Thu, Jan 21, 2021 at 10:20:40AM +0100, Ard Biesheuvel wrote:
> From: Alex Deucher
>
> commit c241ed2f0ea549c18cff62a3708b43846b84dae3 upstream.
>
> >From Ard:
>
> "Simply disabling -mgeneral-regs-only left and right is risky, given that
> the standard AArch64 ABI permits the use of FP/SIMD
On Tue, Jan 19, 2021 at 02:04:48PM -0500, Alex Deucher wrote:
> On Tue, Jan 19, 2021 at 1:26 PM Greg KH wrote:
> >
> > On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
> > >
> > > On 1/19/21 2:34 AM, Greg KH wrote:
> > > > On
On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
>
> On 1/19/21 2:34 AM, Greg KH wrote:
> > On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
> > > static struct pci_driver amdgpu_kms_pci_driver = {
> > >
On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
> static struct pci_driver amdgpu_kms_pci_driver = {
> .name = DRIVER_NAME,
> .id_table = pciidlist,
> @@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
> .shutdown = amdgpu_pci_shutdown,
>
On Wed, Dec 02, 2020 at 01:02:06PM -0500, Andrey Grodzovsky wrote:
>
> On 12/2/20 12:34 PM, Greg KH wrote:
> > On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
> > > On 11/11/20 10:34 AM, Greg KH wrote:
> > > > On Wed, Nov 11, 2020 at 10:13:13
On Wed, Dec 02, 2020 at 10:48:01AM -0500, Andrey Grodzovsky wrote:
>
> On 11/11/20 10:34 AM, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> > > On 11/10/20 12:59 PM, Greg KH wrote:
> > > > On Tue, Nov 10, 2020 at 12:54:21
On Wed, Nov 11, 2020 at 10:45:53AM -0500, Andrey Grodzovsky wrote:
>
> On 11/11/20 10:34 AM, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
> > > On 11/10/20 12:59 PM, Greg KH wrote:
> > > > On Tue, Nov 10, 2020 at 12:54:21
On Wed, Nov 11, 2020 at 10:13:13AM -0500, Andrey Grodzovsky wrote:
>
> On 11/10/20 12:59 PM, Greg KH wrote:
> > On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
> > > Hi, back to this after a long context switch for some higher priority
> > >
On Tue, Nov 10, 2020 at 12:54:21PM -0500, Andrey Grodzovsky wrote:
> Hi, back to this after a long context switch for some higher priority stuff.
>
> So here I was able eventually to drop all this code and this change here
>
On Tue, Nov 03, 2020 at 02:50:40PM +, Deucher, Alexander wrote:
> [AMD Public Use]
>
> > -Original Message-
> > From: Greg KH
> > Sent: Tuesday, November 3, 2020 1:53 AM
> > To: Koenig, Christian
> > Cc: Alex Deucher ; Deepak R Va
On Mon, Nov 02, 2020 at 09:48:25PM +0100, Christian König wrote:
> Am 03.11.20 um 07:53 schrieb Greg KH:
> > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:
> > > Am 02.11.20 um 20:43 schrieb Alex Deucher:
> > > > On Mon, Nov 2, 2020 at 1:42 PM
On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:
> Am 02.11.20 um 20:43 schrieb Alex Deucher:
> > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote:
> > > Initializing global variable to 0 or NULL is not necessary and should
> > > be avoided. Issue reported by checkpatch script
On Mon, Nov 02, 2020 at 02:43:45PM -0500, Alex Deucher wrote:
> On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma wrote:
> >
> > Initializing global variable to 0 or NULL is not necessary and should
> > be avoided. Issue reported by checkpatch script as:
> > ERROR: do not initialise globals to 0 (or
On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote:
> Am 30.10.20 um 08:57 schrieb Deepak R Varma:
> > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> > > > Using
On Fri, Oct 30, 2020 at 01:47:05PM +0530, Sumera Priyadarsini wrote:
> On Fri, 30 Oct, 2020, 1:32 PM Greg KH, wrote:
>
> > On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote:
> > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > > > O
On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote:
> On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote:
> > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
>
On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here:
On Thu, Oct 22, 2020 at 11:36:12AM -0400, Alex Deucher wrote:
> On Wed, Oct 21, 2020 at 7:31 PM Bas Nieuwenhuizen
> wrote:
> >
> > With modifiers I'd like to support non-dedicated buffers for
> > images.
> >
> > Signed-off-by: Bas Nieuwenhuizen
> > Cc: sta...@vger.kernel.org # 5.1.0
>
> I think
On Thu, Oct 22, 2020 at 07:17:56PM +0530, Sumera Priyadarsini wrote:
> Using snprintf() for show() methods holds the risk of buffer overrun
> as snprintf() does not know the PAGE_SIZE maximum of the temporary
> buffer used to output sysfs content.
>
> Modify amdgpu_psp.c to use sysfs_emit()
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> This is a upcoming change to clean up a new warning treewide.
> I am wondering if the change could be one mega patch (see below) or
> normal patch per file about 100 patches or somewhere half way by collecting
>
On Tue, Sep 15, 2020 at 02:46:07PM -0400, Alex Deucher wrote:
> This change breaks tons of systems.
Very vague :(
This commit has also been merged for over a year, why the sudden
problem now?
> This reverts commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713.
You mean "33b3ad3788ab ("drm/radeon:
On Tue, Jun 23, 2020 at 11:04:30PM -0400, Andrey Grodzovsky wrote:
>
> On 6/23/20 2:05 AM, Greg KH wrote:
> > On Tue, Jun 23, 2020 at 12:51:00AM -0400, Andrey Grodzovsky wrote:
> > > On 6/22/20 12:45 PM, Greg KH wrote:
> > > > On Mon, Jun 22, 2020 at 12:07:25
On Tue, Jun 23, 2020 at 12:51:00AM -0400, Andrey Grodzovsky wrote:
>
> On 6/22/20 12:45 PM, Greg KH wrote:
> > On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
> > > On 6/22/20 7:21 AM, Greg KH wrote:
> > > > On Mon, Jun 22, 2020 at 11:5
On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey Grodzovsky wrote:
>
> On 6/22/20 7:21 AM, Greg KH wrote:
> > On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> > > On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > > > Track sysf
rent
> > folder was already removed during pci remove.
Huh? That should not happen, do you have a backtrace of that crash?
> > Signed-off-by: Andrey Grodzovsky
>
> Uh I thought sysfs just gets yanked completely. Please check with Greg KH
> whether hand-rolling all this really
On Thu, Apr 16, 2020 at 07:31:58AM +0200, Christoph Hellwig wrote:
> Some architectures like arm64 and s390 require USER_DS to be set for
> kernel threads to access user address space, which is the whole purpose
> of kthread_use_mm, but other like x86 don't. That has lead to a huge
> mess where
1 - 100 of 112 matches
Mail list logo
