[PATCH 7/7] dyndbg: replace classmap list with a vector
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.
So this changes:
struct ddebug_table gets: classes for the start-addy, num_classes for
the length (placed to improve struct packing).
The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.
The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.
Also move #define __outvar up, above an added use in a fn-prototype.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 61 -
1 file changed, 32 insertions(+), 29 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 48ca1387a409..fd5296dbb40f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
extern struct ddebug_class_map __stop___dyndbg_classes[];
struct ddebug_table {
- struct list_head link, maps;
+ struct list_head link;
const char *mod_name;
- unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+ struct ddebug_class_map *classes;
+ unsigned int num_ddebugs, num_classes;
};
struct ddebug_query {
@@ -146,13 +147,15 @@ static void vpr_info_dq(const struct ddebug_query *query,
const char *msg)
query->first_lineno, query->last_lineno, query->class_string);
}
+#define __outvar /* filled by callee */
static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table
const *dt,
- const char
*class_string, int *class_id)
+ const char
*class_string,
+ __outvar int *class_id)
{
struct ddebug_class_map *map;
- int idx;
+ int i, idx;
- list_for_each_entry(map, &dt->maps, link) {
+ for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -163,7 +166,6 @@ static struct ddebug_class_map
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
}
-#define __outvar /* filled by callee */
/*
* Search the tables for _ddebug's which match the given `query' and
* apply the `flags' and `mask' to them. Returns number of matching
@@ -1109,9 +,10 @@ static void *ddebug_proc_next(struct seq_file *m, void
*p, loff_t *pos)
static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug
*dp)
{
- struct ddebug_class_map *map;
+ struct ddebug_class_map *map = iter->table->classes;
+ int i, nc = iter->table->num_classes;
- list_for_each_entry(map, &iter->table->maps, link)
+ for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
@@ -1195,30 +1198,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
};
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct
_ddebug_info *di)
{
struct ddebug_class_map *cm;
- int i, j, ct = 0;
+ int i, nc = 0;
- for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+ /*
+* Find this module's classmaps in a subrange/wholerange of
+* the builtin/modular classmap vector/section. Save the start
+* and length of the subrange at its edges.
+*/
+ for (cm = di->classes, i = 0; i < di->num_classes; i++, cm++) {
if (!strcmp(cm->mod_name, dt->mod_name)) {
-
- v2pr_info("class[%d]: module:%s base:%d len:%d
ty:%d\n", i,
- cm->mod_name, cm->base, cm->length,
cm->map_type);
-
- for (j = 0; j < cm->length; j++)
- v3pr_info(" %d: %d %s\n", j + cm->base, j,
- cm->class_names[j]);
-
- list_add(&cm->link, &dt->maps);
-
[PATCH 6/7] dyndbg: clone DECLARE_DYNDBG_CLASSMAP to REFERENCE_DYNDBG_CLASSMAP
DECLARE_DYNDBG_CLASSMAPs job is to allow modules to declare the debug
classes/categories they want dyndbg to >control. Its args name the
class-names, and the sysfs interface style (usually a class-bitmap).
A separate module_param_cb wires the sysfs node to the classmap.
In DRM, multiple modules declare identical DRM_UT_* classmaps, so that
they are modified across those modules in a coordinated way, by either
explicit class DRM_UT_* queries to >control, or by writes to drm.debug
(/sys/module/drm/parameters/debug).
This coordination-by-identical-declarations is weird, so this patch
splits the macro into DECLARE and REFERENCE (USE?) flavors. This
distinction improves the api; DECLARE is used once to specify the
classmap, and multiple users REFERENCE the single declaration
explicitly.
Currently the latter just reuses the former, and still needs all the
same args, but that can be tuned later; the DECLARE can initialize the
(extern/global) struct classmap, and REFERENCE can, well reference
that struct.
Signed-off-by: Jim Cromie
---
RFC: s/REFERENCE_/USE_/ ??
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
include/linux/dynamic_debug.h | 10 ++
6 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 3c9fecdd6b2f..5c733d96fe4c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -188,7 +188,7 @@ int amdgpu_vcnfw_log;
static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..1f20c1e721a4 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -41,7 +41,7 @@
#include "drm_dp_helper_internal.h"
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 7d86020b5244..4675c95c90b4 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -51,7 +51,7 @@
#include "drm_crtc_helper_internal.h"
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index d1e4d528cb17..14ebbbf53821 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -29,7 +29,7 @@
#include "i915_params.h"
#include "i915_drv.h"
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index fd99ec0f4257..b943bf2a36fe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -71,7 +71,7 @@
#include "nouveau_svm.h"
#include "nouveau_dmem.h"
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+REFERENCE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 41682278d2e8..76430bac7f79 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -111,6 +111,16 @@ struct ddebug_class_map {
#define NUM_TYPE_ARGS(eltype, ...) \
(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
+/*
+ * refer to the classmap instantiated once, by the macro above. This
+ * distinguishes the multiple users of drm.debug from the single
+ * definition, allowing them to specialize. ATM its a pass-thru, but
+ * it should help regularize the admittedly wierd sharing by identical
+ * definitions.
+ */
+#define REFERENCE_DYNDBG_CLASSMAP(_var, _maptype, _base, ...)
[PATCH 5/7] dyndbg: fix readback value on LEVEL_NAMES interfaces
Since sysfs knobs should generally read-back what was just written (unless theres a good reason to do otherwise), this result (using test_dynamic_debug.ko) is suboptimal: echo L3 > p_level_names cat p_level_names 4 Fix this with a -1 offset in LEVEL_NAMES readback. NOTE: Calling this a BUG is debatable, and the above is slightly inaccurate wrt "read-back"; whats written is a LEVEL_NAME (a string). Whats read back is an integer, giving the 'edge' of the 'low-pass-filter' The actual test looks like: RTT: L4 -> p_level_names : 4 :: DOING: levels 4-1 [ 17.509594] dyndbg: "L4" > p_level_names:0x4 [ 17.510115] dyndbg: apply: 0x1f to: 0xf [ 17.510506] dyndbg: query 0: "class L4 +p" mod:* [ 17.510992] dyndbg: split into words: "class" "L4" "+p" [ 17.511521] dyndbg: op='+' [ 17.511811] dyndbg: flags=0x1 [ 17.512127] dyndbg: *flagsp=0x1 *maskp=0x [ 17.512604] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 class=L4 [ 17.513414] dyndbg: applied: func="" file="" module="" format="" lineno=0-0 class=L4 [ 17.514204] dyndbg: processed 1 queries, with 1 matches, 0 errs [ 17.514809] dyndbg: bit_4: 1 matches on class: L4 -> 0x1f [ 17.515355] dyndbg: p_level_names: changed bit-4: "L4" f->1f [ 17.515933] dyndbg: total matches: 1 crap [[ 5 != 4 ]] This -1 adjustment just reports the edge consistently with its input-mapping. Fixes: b9400852c080 (dyndbg: add drm.debug style (drm/parameters/debug) bitmap support) Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 009f2ead09c1..48ca1387a409 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -794,6 +794,8 @@ int param_get_dyndbg_classes(char *buffer, const struct kernel_param *kp) return scnprintf(buffer, PAGE_SIZE, "0x%lx\n", *dcp->bits); case DD_CLASS_TYPE_LEVEL_NAMES: + return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl - 1); + case DD_CLASS_TYPE_LEVEL_NUM: return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl); default: -- 2.38.1
[PATCH 3/7] test-dyndbg: fixup CLASSMAP usage error
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class
unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. Basically, I coded in an error, and
forgot to verify it and remove it.
RFC:
This patch fixes a bad usage of DEFINE_DYNDBG_CLASSMAP(), showing that
it is too error-prone. As noted in test-dynamic-debug.c comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist) used in DEFINE_DYNAMIC_DEBUG_CLASSMAP(), on
__VA_ARGS__ a 2nd time. Then, DRM would pass DRM_UT_* ; all the
categories, in order, and not their stringifications, which created
all the usage complications above.
Signed-off-by: Jim Cromie
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.38.1
[PATCH 2/7] drm_print: fixup improve stale comment
Cited commit uses stale macro name, fix this. And improve the explanation.
When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() does the
mapping of DRM_UT_* onto BITs in drm.debug. While this is still using
the drm_debug_category enum to do the mapping, its doing so somewhat
indirectly, with the ordered set of DRM_UT_* enum-vals. This requires
that the macro args: DRM_UT_* list must be kept in sync.
fixes: f158936b60a7 (drm: POC drm on dyndbg - use in core, 2 helpers, 3
drivers.)
Signed-off-by: Jim Cromie
---
. emphasize ABI non-change despite enum val change - Jani
---
include/drm/drm_print.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..06deb58d5af4 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const
char *prefix)
*
*/
enum drm_debug_category {
- /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
+ /*
+* Keep DECLARE_DYNDBG_CLASSMAP args in sync with changes
+* here, the values define BIT()s in drm.debug, so are ABI.
+*/
/**
* @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
* drm_memory.c, ...
--
2.38.1
[PATCH 4/7] test-dyndbg: show that DEBUG enables prdbgs at compiletime
Dyndbg is required to enable prdbgs at compile-time if DEBUG is defined. Show this works; add the defn to test_dynamic_debug.c, and manually inspect/verify its effect at module load: [ 15.292810] dyndbg: module:test_dynamic_debug attached 4 classes [ 15.293189] dyndbg: 32 debug prints in module test_dynamic_debug [ 15.293715] test_dd: init start [ 15.293716] test_dd: doing categories [ 15.293716] test_dd: LOW msg ... [ 15.293733] test_dd: L6 msg [ 15.293733] test_dd: L7 msg [ 15.293733] test_dd: init done NOTES: As is observable above, define DEBUG enables all prdbgs, including those in mod_init-fn, and more notably, the "class"d ones (callsites with non-default class_ids). This differs from the >control interface, which in order to properly protect a client's class'd prdbgs, requires a "class FOO" in queries to change them. Note that the DEBUG is in the module source file. This yields an occaisional surprise; the following disables all the compile-time enabled plain prdbgs, but leaves the class'd ones enabled. :#> modprobe test_dynamic_debug dyndbg==_ Signed-off-by: Jim Cromie --- lib/test_dynamic_debug.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c index a01f0193a419..9d48689dc0ab 100644 --- a/lib/test_dynamic_debug.c +++ b/lib/test_dynamic_debug.c @@ -8,6 +8,8 @@ #define pr_fmt(fmt) "test_dd: " fmt +#define DEBUG + #include /* run tests by reading or writing sysfs node: do_prints */ -- 2.38.1
[PATCH 0/7] DYNAMIC_DEBUG fixups for rc
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" are unready, so lets just mark it BROKEN for now. Meanwhile, heres some other fixes, a comment tweak, a proof of non-bug, an internal simplification, and a cleanup/improvement to the main macro (API): Split DECLARE_DYNDBG_CLASSMAP in 1/2; REFERENCE_DYNDBG_CLASSMAP now refers to a classmap DECLARE'd just once. I think this gives a path away from the coordination-by-identical-classmaps "feature" that Jani and others thought was "weird" (my term). Jim Cromie (7): drm: mark drm.debug-on-dyndbg as BROKEN for now drm_print: fixup improve stale comment test-dyndbg: fixup CLASSMAP usage error test-dyndbg: show that DEBUG enables prdbgs at compiletime dyndbg: fix readback value on LEVEL_NAMES interfaces dyndbg: clone DECLARE_DYNDBG_CLASSMAP to REFERENCE_DYNDBG_CLASSMAP dyndbg: replace classmap list with a vector drivers/gpu/drm/Kconfig | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/display/drm_dp_helper.c | 2 +- drivers/gpu/drm/drm_crtc_helper.c | 2 +- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- include/drm/drm_print.h | 5 +- include/linux/dynamic_debug.h | 10 lib/dynamic_debug.c | 63 + lib/test_dynamic_debug.c| 4 +- 10 files changed, 57 insertions(+), 36 deletions(-) -- 2.38.1
[PATCH 1/7] drm: mark drm.debug-on-dyndbg as BROKEN for now
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-initialization, from boot-args etc 3- `modprobe i915` finishes W/O drm.debug-on-dyndbg that just works, because all drm_dbg* callsites use drm_debug_enabled() to check __drm_debug & DEM_UT_ before printing. But the whole point of drm.debug-on-dyndbg is to avoid that runtime test, by enabling (at post-modinit) a static-key at each callsite in the just-loaded module. And since drm.ko is loaded before all dependent modules, none are "just-loaded", and no drm.debug callsites are present yet, except those in drm.ko itself. Signed-off-by: Jim Cromie --- drivers/gpu/drm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 34f5a092c99e..0d1e59e6bb7e 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -54,6 +54,7 @@ config DRM_DEBUG_MM config DRM_USE_DYNAMIC_DEBUG bool "use dynamic debug to implement drm.debug" default y + depends on BROKEN # chicken-egg initial enable problem depends on DRM depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE depends on JUMP_LABEL -- 2.38.1
[PATCH] drm/amdgpu: there is no vbios fb on devices with no display hw (v2)
If we enable virtual display functionality on parts with
no display hardware we can end up trying to check for and
reserve the vbios FB area on devices where it doesn't exist.
Check if display hardware is actually present on the hardware
before trying to reserve the memory.
v2: move the check into common code
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 41 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 2 +-
3 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5a4aaf4d9ed1..1f3a4d596d0d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1298,6 +1298,7 @@ void amdgpu_device_pcie_port_wreg(struct amdgpu_device
*adev,
u32 reg, u32 v);
struct dma_fence *amdgpu_device_switch_gang(struct amdgpu_device *adev,
struct dma_fence *gang);
+bool amdgpu_device_has_display_hardware(struct amdgpu_device *adev);
/* atpx handler */
#if defined(CONFIG_VGA_SWITCHEROO)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e039df9fb3dd..148ac2e9f31f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -6045,3 +6045,44 @@ struct dma_fence *amdgpu_device_switch_gang(struct
amdgpu_device *adev,
dma_fence_put(old);
return NULL;
}
+
+bool amdgpu_device_has_display_hardware(struct amdgpu_device *adev)
+{
+ switch (adev->asic_type) {
+#ifdef CONFIG_DRM_AMDGPU_SI
+ case CHIP_HAINAN:
+#endif
+ case CHIP_TOPAZ:
+ /* chips with no display hardware */
+ return false;
+#ifdef CONFIG_DRM_AMDGPU_SI
+ case CHIP_TAHITI:
+ case CHIP_PITCAIRN:
+ case CHIP_VERDE:
+ case CHIP_OLAND:
+#endif
+#ifdef CONFIG_DRM_AMDGPU_CIK
+ case CHIP_BONAIRE:
+ case CHIP_HAWAII:
+ case CHIP_KAVERI:
+ case CHIP_KABINI:
+ case CHIP_MULLINS:
+#endif
+ case CHIP_TONGA:
+ case CHIP_FIJI:
+ case CHIP_POLARIS10:
+ case CHIP_POLARIS11:
+ case CHIP_POLARIS12:
+ case CHIP_VEGAM:
+ case CHIP_CARRIZO:
+ case CHIP_STONEY:
+ /* chips with display hardware */
+ return true;
+ default:
+ /* IP discovery */
+ if (!adev->ip_versions[DCE_HWIP][0] ||
+ (adev->harvest_ip_mask & AMD_HARVEST_IP_DMU_MASK))
+ return false;
+ return true;
+ }
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 9c0d9baab4e2..4365ede42855 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -657,7 +657,7 @@ void amdgpu_gmc_get_vbios_allocations(struct amdgpu_device
*adev)
}
if (amdgpu_sriov_vf(adev) ||
- !amdgpu_device_ip_get_ip_block(adev, AMD_IP_BLOCK_TYPE_DCE)) {
+ !amdgpu_device_has_display_hardware(adev)) {
size = 0;
} else {
size = amdgpu_gmc_get_vbios_fb_size(adev);
--
2.38.1
[pull] amdgpu, amdkfd, radeon drm-next-6.2
Hi Dave, Daniel, More new stuff for 6.2. The following changes since commit a143bc517bf31c4575191efbaac216a11ec016e0: Merge branch '00.06-gr-ampere' of https://gitlab.freedesktop.org/skeggsb/nouveau into drm-next (2022-11-09 11:18:56 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.2-2022-11-11 for you to fetch changes up to 2ebf61f2cfb9a11bc17db30df3e675a4cd7418d3: drm/amdgpu: Fix memory leak in amdgpu_cs_pass1 (2022-11-10 15:30:34 -0500) amd-drm-next-6.2-2022-11-11: amdgpu: - SMU 13.x updates - GPUVM TLB race fix - DCN 3.1.4 updates - DCN 3.2.x updates - PSR fixes - Kerneldoc fix - Vega10 fan fix - GPUVM locking fixes in error pathes - BACO fix for Beige Goby - EEPROM I2C address cleanup - GFXOFF fix - Fix DC memory leak in error pathes - Flexible array updates - Mtype fix for GPUVM PTEs - Move Kconfig into amdgpu directory - SR-IOV updates - Fix possible memory leak in CS IOCTL error path amdkfd: - Fix possible memory overrun - CRIU fixes radeon: - ACPI ref count fix - HDA audio notifier support - Move Kconfig into radeon directory UAPI: - Add new GEM_CREATE flags to help to transition more KFD functionality to the DRM UAPI. These are used internally in the driver to align location based memory coherency requirements from memory allocated in the KFD with how we manage GPUVM PTEs. They are currently blocked in the GEM_CREATE IOCTL as we don't have a user right now. They are just used internally in the kernel driver for now for existing KFD memory allocations. So a change to the UAPI header, but no functional change in the UAPI. Alvin Lee (4): drm/amd/display: Wait for VBLANK during pipe programming drm/amd/display: Use min transition for SubVP into MPO drm/amd/display: Disable phantom OTG after enable for plane disable drm/amd/display: Add margin for max vblank time for SubVP + DRR Andrew Davis (1): drm: Move radeon and amdgpu Kconfig options into their directories Aric Cyr (1): drm/amd/display: 3.2.211 Asher Song (1): Revert "drm/amdgpu: Revert "drm/amdgpu: getting fan speed pwm for vega10 properly"" Aurabindo Pillai (1): drm/amd/display: Zeromem mypipe heap struct before using it Chaitanya Dhere (1): drm/amd/display: Fix FCLK deviation and tool compile issues Christian König (1): drm/amdgpu: workaround for TLB seq race Dillon Varone (1): drm/amd/display: Enforce minimum prefetch time for low memclk on DCN32 Dong Chenchen (1): drm/amdgpu: Fix memory leak in amdgpu_cs_pass1 Felix Kuehling (3): drm/amdkfd: Fix error handling in kfd_criu_restore_events drm/amdkfd: Fix error handling in criu_checkpoint drm/amdgpu: Set MTYPE in PTE based on BO flags Gavin Wan (1): drm/amdgpu: Ignore stop rlc on SRIOV environment. George Shen (1): drm/amd/display: Populate DP2.0 output type for DML pipe Guchun Chen (1): drm/amdgpu: disable BACO on special BEIGE_GOBY card Hamza Mahfooz (1): drm/amd/display: only fill dirty rectangles when PSR is enabled Hanjun Guo (1): drm/radeon: Add the missed acpi_put_table() to fix memory leak Harsh Jain (1): drm/amdgpu: complete gfxoff allow signal during suspend without delay Kenneth Feng (2): drm/amd/pm: enable mode1 reset on smu_v13_0_10 drm/amd/pm: skip disabling all smu features on smu_v13_0_10 in suspend Leo Ma (1): drm/amd/display: Adding HDMI SCDC DEVICE_ID define Liu Jian (1): drm/amd/display: delete the duplicate .set_odm_bypass initialization in dcn314_tg_funcs LongJun Tang (1): drm/amd/display: Have risk for memory exhaustion Luben Tuikov (2): drm/amdgpu: Remove redundant I2C EEPROM address drm/amdgpu: Decouple RAS EEPROM addresses from chips Ma Jun (2): drm/amdkfd: Fix the memory overrun drm/amdkfd: Make kfd_fill_cache_non_crat_info() as static Max Tseng (1): drm/amd/display: Cursor update refactor: PSR-SU support condition Michael Strauss (1): drm/amd/display: Only update link settings after successful MST link train Mike Hsieh (1): drm/amd/display: Set correct EOTF and Gamut flag in VRR info Mustapha Ghaddar (1): drm/amd/display: Fix fallback issues for DP LL 1.4a tests Nawwar Ali (1): drm/amd/display: Update 709 gamma to 2.222 as stated in the standerd Nicholas Kazlauskas (3): drm/amd/display: Update SR watermarks for DCN314 drm/amd/display: Allow tuning DCN314 bounding box drm/amd/display: Fix reg timeout in enc314_enable_fifo Paulo Miguel Almeida (2): drm/amdgpu: Replace 1-element array with flexible-array member drm/amdgpu: Replace one-element array with flex-array member Philip Yang (2): drm/amdgpu: Unlock bo_list_mutex after error handling drm/amdgpu: Drop evic
[linux-next:master] BUILD REGRESSION f8f60f322f0640c8edda2942ca5f84b7a27c417a
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: f8f60f322f0640c8edda2942ca5f84b7a27c417a Add linux-next specific files for 2022 Error/Warning reports: https://lore.kernel.org/linux-mm/202210261404.b6ulzg7h-...@intel.com https://lore.kernel.org/oe-kbuild-all/202210270637.q5y7fikj-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211090634.ryfkk0ws-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211102047.qp7ithm4-...@intel.com https://lore.kernel.org/oe-kbuild-all/20221624.1xztuzhj-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/arm/mach-s3c/devs.c:32:10: fatal error: linux/platform_data/dma-s3c24xx.h: No such file or directory arch/x86/platform/efi/runtime-map.c:138:5: warning: no previous prototype for 'efi_get_runtime_map_size' [-Wmissing-prototypes] arch/x86/platform/efi/runtime-map.c:143:5: warning: no previous prototype for 'efi_get_runtime_map_desc_size' [-Wmissing-prototypes] arch/x86/platform/efi/runtime-map.c:148:5: warning: no previous prototype for 'efi_runtime_map_copy' [-Wmissing-prototypes] csky-linux-ld: local_object.c:(.text+0x84): undefined reference to `ipv6_icmp_error' drivers/block/zram/zram_drv.c:1857:7: warning: variable 'err' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] drivers/block/zram/zram_drv.c:1857:7: warning: variable 'err' is used uninitialized whenever '||' condition is true [-Wsometimes-uninitialized] drivers/firmware/efi/memmap.c:57:52: warning: suggest braces around empty body in an 'if' statement [-Wempty-body] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4887: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5073:24: warning: implicit conversion from 'enum ' to 'enum dc_status' [-Wenum-conversion] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for function 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for function 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for function 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for function 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable 'loc' set but not used [-Wunused-but-set-variable] local_object.c:(.text+0x60): undefined reference to `ipv6_icmp_error' vmlinux.o: warning: objtool: __btrfs_map_block+0x1e22: unreachable instruction Unverified Error/Warning (likely false positive, please contact us if interested): drivers/gpu/drm/nouveau/nvkm/subdev/mc/ga100.c:51:1: sparse: sparse: symbol 'ga100_mc_device' was not declared. Should it be static? lib/zstd/compress/huf_compress.c:460 HUF_getIndex() warn: the 'RANK_POSITION_LOG_BUCKETS_BEGIN' macro might need parens lib/zstd/decompress/zstd_decompress_block.c:1009 ZSTD_execSequence() warn: inconsistent indenting lib/zstd/decompress/zstd_decompress_block.c:894 ZSTD_execSequenceEnd() warn: inconsistent indenting lib/zstd/decompress/zstd_decompress_block.c:942 ZSTD_execSequenceEndSplitLitBuffer() warn: inconsistent indenting lib/zstd/decompress/zstd_decompress_internal.h:206 ZSTD_DCtx_get_bmi2() warn: inconsistent indenting mm/khugepaged.c:2038 collapse_file() warn: iterator used outside loop: 'page' Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-core-dc_link_dp.c:warning:implicit-conversion-from-enum-anonymous-to-enum-dc_status | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-gf100.c:warning:no-previous-prototype-for-gf100_fifo_nonstall_block | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-runl.c:warning:no-previous-prototype-for-nvkm_engn_cgrp_get | |-- drivers-gpu-drm-nouveau-nvkm-engine-gr-tu102.c:warning:no-previous-prototype-for-tu102_gr_load | |-- drivers-gpu-drm-n
Re: [PATCH] drm/amdgpu: disable BACO support on more cards
On Fri, Nov 11, 2022 at 3:57 AM Guchun Chen wrote: > > Otherwise, some unexpected PCIE AER errors will be observed > in runtime suspend/resume cycle. > > Signed-off-by: Guchun Chen Please make sure we try and root cause this. I would hate to have to leave this in place for a long time. Acked-by: Alex Deucher > --- > drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c > b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c > index 6212fd270857..697e98a0a20a 100644 > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c > @@ -379,6 +379,10 @@ static void sienna_cichlid_check_bxco_support(struct > smu_context *smu) > ((adev->pdev->device == 0x73BF) && > (adev->pdev->revision == 0xCF)) || > ((adev->pdev->device == 0x7422) && > + (adev->pdev->revision == 0x00)) || > + ((adev->pdev->device == 0x73A3) && > + (adev->pdev->revision == 0x00)) || > + ((adev->pdev->device == 0x73E3) && > (adev->pdev->revision == 0x00))) > smu_baco->platform_support = false; > > -- > 2.25.1 >
Re: [PATCH] amdgpu_dm_2027: Add pointer check
The commit title should user the drm/amd/display prefix.
It might also be good to be more specific, like:
drm/amd/display: Check dc_resource_state_construct succeeded
On 11/11/22 02:14, Denis Arefev wrote:
> Return value of a function 'dc_create_state' is
> dereferenced at amdgpu_dm.c:2027 without checking for null
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
Does this fix a test case? If so, please describe.
> Signed-off-by: Denis Arefev
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 0f7749e9424d..529483997154 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1960,7 +1960,9 @@ static int dm_resume(void *handle)
> dc_release_state(dm_state->context);
> dm_state->context = dc_create_state(dm->dc);
> /* TODO: Remove dc_state->dccg, use dc->dccg directly. */
> - dc_resource_state_construct(dm->dc, dm_state->context);
> + if (dm_state->context) {
> + dc_resource_state_construct(dm->dc, dm_state->context);
> + }
I don't see how this won't leave the driver state in a
mess. Are you sure this isn't a fatal error?
Harry
>
> /* Before powering on DC we need to re-initialize DMUB. */
> r = dm_dmub_hw_init(adev);
[PATCH] drm/amd/display: remove set but unused variable 'state'
The variable state is not effectively used in the function, so delete it.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource.c:1613:24:
warning: variable ‘state’ set but not used.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3027#c0
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
index f7fea3544c31..df477a53b64a 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c
@@ -1610,7 +1610,6 @@ bool dcn32_acquire_post_bldn_3dlut(
struct dc_transfer_func **shaper)
{
bool ret = false;
- union dc_3dlut_state *state;
ASSERT(*lut == NULL && *shaper == NULL);
*lut = NULL;
@@ -1619,7 +1618,6 @@ bool dcn32_acquire_post_bldn_3dlut(
if (!res_ctx->is_mpc_3dlut_acquired[mpcc_id]) {
*lut = pool->mpc_lut[mpcc_id];
*shaper = pool->mpc_shaper[mpcc_id];
- state = &pool->mpc_lut[mpcc_id]->state;
res_ctx->is_mpc_3dlut_acquired[mpcc_id] = true;
ret = true;
}
--
2.20.1.7.g153144c
Re: [PATCH] drm/amdgpu: Fix memory leak in amdgpu_cs_pass1
Am 10.11.22 um 15:33 schrieb Dong Chenchen:
When p->gang_size equals 0, amdgpu_cs_pass1() will return directly
without freeing chunk_array, which will cause a memory leak issue,
this patch fixes it.
Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6")
Signed-off-by: Dong Chenchen
Good catch, thanks. Patch is Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 1bbd39b3b0fc..0e24d6b80e0b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -287,8 +287,10 @@ static int amdgpu_cs_pass1(struct amdgpu_cs_parser *p,
}
}
- if (!p->gang_size)
- return -EINVAL;
+ if (!p->gang_size) {
+ ret = -EINVAL;
+ goto free_partial_kdata;
+ }
for (i = 0; i < p->gang_size; ++i) {
ret = amdgpu_job_alloc(p->adev, num_ibs[i], &p->jobs[i], vm);
RE: [PATCH] drm/amdgpu: Remove programming GCMC_VM_FB_LOCATION* on gfxhub_v3_0_3 in VF
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Yifan Zha
Sent: Friday, November 11, 2022 15:31
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Zhang, Hawking
Cc: Chen, Horace ; Chang, HaiJun ;
Zha, YiFan(Even)
Subject: [PATCH] drm/amdgpu: Remove programming GCMC_VM_FB_LOCATION* on
gfxhub_v3_0_3 in VF
[Why]
GCMC_VM related registers should be programmed by PSP on host side.
L1 and RLCG will block these regisers on VF.
[How]
Remove programming GCMC_VM_FB_LOCATION_BASE/TOP on gfxhub_v3_0_3 under SRIOV VF.
Signed-off-by: Yifan Zha
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0_3.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0_3.c
b/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0_3.c
index 716ae6f2aefe..080ff11ca305 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0_3.c
@@ -357,18 +357,6 @@ static void gfxhub_v3_0_3_program_invalidation(struct
amdgpu_device *adev)
static int gfxhub_v3_0_3_gart_enable(struct amdgpu_device *adev) {
- if (amdgpu_sriov_vf(adev)) {
- /*
-* GCMC_VM_FB_LOCATION_BASE/TOP is NULL for VF, becuase they are
-* VF copy registers so vbios post doesn't program them, for
-* SRIOV driver need to program them
-*/
- WREG32_SOC15(GC, 0, regGCMC_VM_FB_LOCATION_BASE,
-adev->gmc.vram_start >> 24);
- WREG32_SOC15(GC, 0, regGCMC_VM_FB_LOCATION_TOP,
-adev->gmc.vram_end >> 24);
- }
-
/* GART Enable. */
gfxhub_v3_0_3_init_gart_aperture_regs(adev);
gfxhub_v3_0_3_init_system_aperture_regs(adev);
--
2.25.1
RE: [PATCH] nbio_v7_4: Add pointer check
[AMD Official Use Only - General]
Hey,
The patch does the right thing from coding principal perspective, but it is
really redundant check in RAS context.
The function is a hardware interrupt handler which is only triggered for
specific RAS event. When software receives the interrupt, the pointer of RAS
context must be valid one. Otherwise, even the interrupt won't be enabled at
all...
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Denis Arefev
Sent: Friday, November 11, 2022 15:41
To: Deucher, Alexander
Cc: avid Airlie ; linux-ker...@vger.kernel.org;
dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; Daniel Vetter
; Koenig, Christian
Subject: [PATCH] nbio_v7_4: Add pointer check
Return value of a function 'amdgpu_ras_find_obj' is dereferenced at
nbio_v7_4.c:325 without checking for null
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Arefev
---
drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
index eadc9526d33f..0f2ac99de864 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
@@ -304,6 +304,9 @@ static void
nbio_v7_4_handle_ras_controller_intr_no_bifring(struct amdgpu_device
struct ras_err_data err_data = {0, 0, 0, NULL};
struct amdgpu_ras *ras = amdgpu_ras_get_context(adev);
+ if (!obj)
+ return;
bif_doorbell_intr_cntl = RREG32_SOC15(NBIO, 0, mmBIF_DOORBELL_INT_CNTL);
if (REG_GET_FIELD(bif_doorbell_intr_cntl,
BIF_DOORBELL_INT_CNTL, RAS_CNTLR_INTERRUPT_STATUS)) {
--
2.25.1
[PATCH] drm/amdgpu: disable BACO support on more cards
Otherwise, some unexpected PCIE AER errors will be observed in runtime suspend/resume cycle. Signed-off-by: Guchun Chen --- drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c index 6212fd270857..697e98a0a20a 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c @@ -379,6 +379,10 @@ static void sienna_cichlid_check_bxco_support(struct smu_context *smu) ((adev->pdev->device == 0x73BF) && (adev->pdev->revision == 0xCF)) || ((adev->pdev->device == 0x7422) && + (adev->pdev->revision == 0x00)) || + ((adev->pdev->device == 0x73A3) && + (adev->pdev->revision == 0x00)) || + ((adev->pdev->device == 0x73E3) && (adev->pdev->revision == 0x00))) smu_baco->platform_support = false; -- 2.25.1
[PATCH] amdgpu_dm_2027: Add pointer check
Return value of a function 'dc_create_state' is
dereferenced at amdgpu_dm.c:2027 without checking for null
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Arefev
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0f7749e9424d..529483997154 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1960,7 +1960,9 @@ static int dm_resume(void *handle)
dc_release_state(dm_state->context);
dm_state->context = dc_create_state(dm->dc);
/* TODO: Remove dc_state->dccg, use dc->dccg directly. */
- dc_resource_state_construct(dm->dc, dm_state->context);
+ if (dm_state->context) {
+ dc_resource_state_construct(dm->dc, dm_state->context);
+ }
/* Before powering on DC we need to re-initialize DMUB. */
r = dm_dmub_hw_init(adev);
--
2.25.1
Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
On Thu, Nov 10, 2022 at 11:39:02PM -0600, Gustavo A. R. Silva wrote:
> On Wed, Nov 09, 2022 at 10:20:34PM -0500, Alex Deucher wrote:
> > On Wed, Nov 9, 2022 at 8:31 PM Paulo Miguel Almeida
> > wrote:
> > >
> > > On Wed, Nov 09, 2022 at 06:45:57PM -0600, Gustavo A. R. Silva wrote:
> > > > On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
> > > >
> > > > Adding Alex, Christian and DRM lists to the thread.
> > >
> > > Thanks so much for your reply Gustavo
> > > Yep, that's a good idea.
> > >
> > > >
> > > > > struct _ATOM_INIT_REG_BLOCK {
> > > > > USHORT usRegIndexTblSize;/* 0 2 */
> > > > > USHORT usRegDataBlkSize; /* 2 2 */
> > > > > ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1]; /* 4 3 */
> > > > > ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1]; /* 7 8 */
> > > >
> > > > I didn't find evidence that asRegDataBuf is used anywhere in the
> > > > codebase[1].
> > > > ...
> > > >
> > > > ...
> > > > As I pointed out above, I don't see asRegDataBuf[] being used in the
> > > > codebase (of course it may describe firmware memory layout). Instead,
> > > > there is this jump to a block of data past asRegIndexBuf[]:
> > > >
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1444:
> > > > 1444: ATOM_MEMORY_SETTING_DATA_BLOCK *reg_data =
> > > > 1445: (ATOM_MEMORY_SETTING_DATA_BLOCK *)
> > > > 1446: ((u8 *)reg_block + (2 * sizeof(u16)) +
> > > > 1447: le16_to_cpu(reg_block->usRegIndexTblSize));
> > > >
> > > > So, it seems the one relevant array, from the kernel side, is
> > > > asRegIndexBuf[]. I wonder if we really need asRegDataBuf[] in that
> > > > structure... or if we could try modifying that struct and only have
> > > > asRegIndexBuf[] as last member? and then we can transform it into a
> > > > flex-array member.
> > >
> > > I saw that one too. That would be the way it's currently accessing
> > > asRegDataBuf member as the existing struct would make asRegDataBuf[0]
> > > point
> > > to some index within the asRegIndexBuf member (as you probably got it too)
> > >
> > > you are right... asRegDataBuff isn't used from a static analysis
> > > point of view but removing it make the code a bit cryptic, right?
> > >
> > > That's pickle, ay? :-)
> > >
> > > >
> > > > If for any strong reasong we cannot remove asRegDataBuf[] then I think
> > > > we
> > > > could give it a try and use DECLARE_FLEX_ARRAY() to declare both arrays
> > > > in the structure.
> > > >
> > >
> > > Out of curiosity, why both rather than just asRegIndexBuf?
>
> Because if I understand the code and Alex's reply below correctly, both
> arrays are being used to describe data of variable size, and both arrays
> need to stay. The situation is that it'd be _strange_ to transform just
> one of them into a flex-array member and not the other, and at the same
My apologies, I tried being succinct and I ended up mistakenly leading you
to understand a different thing. I will be more careful next time :-)
What I meant was why would you use DECLARE_FLEX_ARRAY macro for both
members instead of the following ?
typedef struct _ATOM_INIT_REG_BLOCK{
USHORT usRegIndexTblSize;
USHORT usRegDataBlkSize;
DECLARE_FLEX_ARRAY(ATOM_INIT_REG_INDEX_FORMAT, asRegIndexBuf); // Macro
needed
ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[];// Regular
FMA
}ATOM_INIT_REG_BLOCK;
> On the other hand, I fail to see how the current state of the code is
> problematic for things like -fstrict-flex-arrays, right now. asRegDataBuf[]
> is not being used for anything in the kernel, and asRegIndexBuf[] is
> correctly being accessed through it's only valid index zero, after which
> is decays into a pointer[2].
>
> That struct is definitely not great (I don't love it), but we might try
> to explore other cases while we determine how and if we ultimately need
> to modify it.
>
> I'll open an issue for this in the bug tracker, so we keep an eye on it.
> :)
Fair enough. Thanks heaps Gustavo, I will move on to the other fake flex
array occurences and circle back to it once a decision in made. Please
count on me to make the changes :-)
>
> > >
> > > > But first, of course, Alex, Christian, it'd be really great if we can
> > > > have your input and feedback. :)
> >
> > This header describes the layout of memory stored in the ROM on the
> > GPU. It's shared between vbios and driver so some parts aren't
> > necessarily directly used by the driver. As for what to do about it,
> > I'm not sure. This structure stores a set of register offsets
> > (asRegIndexBuf) and data values (asRegDataBuf) for specific operations
> > (e.g., walk this structure and program register X with value Y. For a
> > little background on atombios, it's a set of data and command tables
> > stored in the vbios ROM image. The driver has an interpreter for the
> > command tables (see
[PATCH] nbio_v7_4: Add pointer check
Return value of a function 'amdgpu_ras_find_obj' is dereferenced
at nbio_v7_4.c:325 without checking for null
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Arefev
---
drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
index eadc9526d33f..0f2ac99de864 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c
@@ -304,6 +304,9 @@ static void
nbio_v7_4_handle_ras_controller_intr_no_bifring(struct amdgpu_device
struct ras_err_data err_data = {0, 0, 0, NULL};
struct amdgpu_ras *ras = amdgpu_ras_get_context(adev);
+ if (!obj)
+ return;
bif_doorbell_intr_cntl = RREG32_SOC15(NBIO, 0, mmBIF_DOORBELL_INT_CNTL);
if (REG_GET_FIELD(bif_doorbell_intr_cntl,
BIF_DOORBELL_INT_CNTL, RAS_CNTLR_INTERRUPT_STATUS)) {
--
2.25.1
