On Thu, Oct 12, 2023 at 02:35:15PM +0200, Christian König wrote:
> Additional to that from the software side Felix summarized it in the HMM
> peer2peer discussion thread recently quite well.
Do you have a pointer to that discussion?
In nv17_tv_get_hd_modes(), 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(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference.
Signed-off-by: Ma Ke
---
Reviewed-by: Lyude Paul
On Wed, 2023-10-11 at 13:41 +0200, Karol Herbst wrote:
> Just special case DP DSM connectors until we properly figure out how to
> deal with this.
>
> This resolves user regressions on GPUs with such connectors without
> reverting the original fix.
>
> Cc: Lyude Paul
>
On 10/7/23 05:23, Ma Ke wrote:
In nv17_tv_get_ld_modes(), 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.
Signed-off-by: Ma Ke
Reviewed-by: Danilo Krummrich
---
On 10/8/23 16:02, Randy Dunlap wrote:
kernel-doc emits a warning:
include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
@NOUVEAU_GETPARAM_EXEC_PUSH_MAX
on line 49 - I thought it was a doc line
We don't have a way to document a macro value via kernel-doc, so
change the "/**"
On Thu, Oct 12, 2023 at 02:35:15PM +0200, Christian König wrote:
> Am 12.10.23 um 12:33 schrieb Dave Airlie:
> > On Wed, 11 Oct 2023 at 17:07, Christian König
> > wrote:
> > > Am 10.10.23 um 22:23 schrieb Dave Airlie:
> > > > > I think we're then optimizing for different scenarios. Our compute
>
Am 12.10.23 um 12:33 schrieb Dave Airlie:
On Wed, 11 Oct 2023 at 17:07, Christian König wrote:
Am 10.10.23 um 22:23 schrieb Dave Airlie:
I think we're then optimizing for different scenarios. Our compute
driver will use mostly external objects only, and if shared, I don't
forsee them bound to
On Wed, 11 Oct 2023 at 17:07, Christian König wrote:
>
> Am 10.10.23 um 22:23 schrieb Dave Airlie:
> >> I think we're then optimizing for different scenarios. Our compute
> >> driver will use mostly external objects only, and if shared, I don't
> >> forsee them bound to many VMs. What saves us
