On Sat, Aug 17, 2024 at 10:30:41PM +0200, Kevin Holm wrote:
>
>
> On 17.08.24 10:42, Greg KH wrote:
> > On Tue, Jul 30, 2024 at 08:53:39PM +0200, Kevin Holm wrote:
> > > From: Wayne Lin
> > >
> > > [ Upstream commit fa57924c76d995e87c
On Tue, Jul 30, 2024 at 08:53:39PM +0200, Kevin Holm wrote:
> From: Wayne Lin
>
> [ Upstream commit fa57924c76d995e87ca3533ec60d1d5e55769a27 ]
>
> [Why]
> dm_dp_mst_is_port_support_mode() is a bit not following the original design
> rule and cause
> light up issue with multiple 4k monitors afte
On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
> On Thu, Aug 15, 2024 at 1:11 AM Greg KH wrote:
> >
> > On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> > > On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling
> > > wrote:
> > &
On Wed, Aug 28, 2024 at 10:15:56AM -0500, Vamsi Krishna Brahmajosyula wrote:
> From: Jesse Zhang
>
> [ Upstream commit 88a9a467c548d0b3c7761b4fd54a68e70f9c0944 ]
>
> Initialize the size before calling amdgpu_vce_cs_reloc, such as case
> 0x0301.
> V2: To really improve the handling we would
On Tue, Sep 03, 2024 at 04:58:09AM +, sikkamukul wrote:
> From: Bob Zhou
>
> [ Upstream commit 50151b7f1c79a09117837eb95b76c2de76841dab ]
>
> Check return value and conduct null pointer handling to avoid null pointer
> dereference.
>
> Signed-off-by: Bob Zhou
> Reviewed-by: Tim Huang
> S
On Tue, Aug 27, 2024 at 10:18:27AM -0400, Alex Deucher wrote:
> On Sat, Aug 24, 2024 at 1:23 AM Greg KH wrote:
> >
> > On Fri, Aug 23, 2024 at 05:23:46PM -0400, Alex Deucher wrote:
> > > On Thu, Aug 15, 2024 at 1:11 AM Greg KH
> > > wrote:
> > > &g
On Fri, Sep 06, 2024 at 11:02:32AM -0400, Alex Deucher wrote:
> On Fri, Sep 6, 2024 at 4:50 AM Mukul Sikka wrote:
> >
> > On Fri, Sep 6, 2024 at 12:05 AM Alex Deucher wrote:
> > >
> > > On Tue, Sep 3, 2024 at 5:53 AM sikkamukul
> > > wrote:
> > > >
> > > > From: Bob Zhou
> > > >
> > > > [ Upst
On Wed, Jun 12, 2024 at 12:10:37PM +1200, Matthew Ruffell wrote:
> Hi Greg KH, Sasha,
>
> Please pick up this patch for 5.15 stable tree. I have built a test kernel and
> can confirm that it fixes affected users.
>
> Downstream bug:
> https://bugs.launchpad.net/ubuntu/+sour
On Thu, Jun 20, 2024 at 10:11:27AM -0600, Alex Hung wrote:
> From: Dillon Varone
>
> [WHY & HOW]
> Currently the force only works for a single display, make it so it can
> be forced per stream.
>
> Reviewed-by: Alvin Lee
> Cc: Mario Limonciello
> Cc: Alex Deucher
> Cc: sta...@vger.kernel.org
On Tue, Jul 30, 2024 at 05:56:42AM +, Lin, Wayne wrote:
> [Public]
>
> Hi,
> Thanks for the report.
>
> Patch fa57924c76d995 ("drm/amd/display: Refactor function
> dm_dp_mst_is_port_support_mode()")
> is kind of correcting problems causing by commit:
> 4df96ba6676034 ("drm/amd/display: Add t
On Mon, Jul 29, 2024 at 10:31:38AM +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 16.07.24 19:33, Alex Deucher wrote:
> > This reverts commit bc87d666c05a13e6d4ae1ddce41fc43d2567b9a2 and the
> > register changes from commit 6d4279cb99ac4f51d10409501d29969f687ac8dc.
> >
> > Close
On Tue, Jul 30, 2024 at 08:53:39PM +0200, Kevin Holm wrote:
> From: Wayne Lin
>
> [ Upstream commit fa57924c76d995e87ca3533ec60d1d5e55769a27 ]
>
> [Why]
> dm_dp_mst_is_port_support_mode() is a bit not following the original design
> rule and cause
> light up issue with multiple 4k monitors afte
Hi all,
As some of you have noticed, there's a TON of failure messages being
sent out for AMD gpu driver commits that are tagged for stable
backports. In short, you all are doing something really wrong with how
you are tagging these.
Please fix it up to NOT have duplicates in multiple branches t
On Wed, Aug 14, 2024 at 04:39:29PM -0400, Felix Kuehling wrote:
> On 2024-08-12 11:00, Greg KH wrote:
> > Hi all,
> >
> > As some of you have noticed, there's a TON of failure messages being
> > sent out for AMD gpu driver commits that are tagged for stable
>
On Wed, Aug 14, 2024 at 05:30:08PM -0400, Alex Deucher wrote:
> On Wed, Aug 14, 2024 at 4:55 PM Felix Kuehling wrote:
> >
> > On 2024-08-12 11:00, Greg KH wrote:
> > > Hi all,
> > >
> > > As some of you have noticed, there's a TON of failure m
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: https://gitee.com/src-openeuler/kernel/is
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
>
> Referenc
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
> exec
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
> b
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:
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 all
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 17.05.2
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: sta..
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
> fle
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 systems
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, 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 test
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 t
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 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 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 &mode->head to list_add_tail(), and
> there is
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 me
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 se
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: ha
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 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 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 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 r
> > 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 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
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 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 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 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() instea
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 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: h
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()
> > &g
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 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 DEFIN
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 N
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 a
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 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
> https://cgit.freedesktop.org/~agrodzov/linux/commit/?h=amd-staging-drm-n
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
> > > stu
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, 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, 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 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 pag
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 fe
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 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 pr
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 pr
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 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 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 th
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
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 drm-t
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 (immature
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 wit
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:
>
> https://www.spinics.
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 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 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 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 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 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 in
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 list_for_each_e
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 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 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 Torval
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, 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 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 D
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 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:
>
> htt
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 segfaul
ng: dyndbg: use ESCAPE_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,
>
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:
> > > &
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 Messag
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 w
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 k
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 post-in
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 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 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 'props2'
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 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 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 'props2'
1 - 100 of 134 matches
Mail list logo
