Re: [PATCH v2 1/3] drm: Add panel backlight quirks
On 6/23/24 01:51, Thomas Weißschuh wrote:
Panels using a PWM-controlled backlight source without an do not have a
standard way to communicate their valid PWM ranges.
On x86 the ranges are read from ACPI through driver-specific tables.
The built-in ranges are not necessarily correct, or may grow stale if an
older device can be retrofitted with newer panels.
Add a quirk infrastructure with which the valid backlight ranges can be
maintained as part of the kernel.
Signed-off-by: Thomas Weißschuh
---
...
+EXPORT_SYMBOL(drm_get_panel_backlight_quirk);
+
+MODULE_LICENSE("GPL");
Missing a MODULE_DESCRIPTION()
This will result in a make W=1 warning
Re: 6.5.5: UBSAN: radeon_atombios.c: index 1 is out of range for type 'UCHAR [1]'
On 10/1/23 17:12, Justin Piszcz wrote: [Sun Oct 1 15:59:04 2023] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/radeon/radeon_atombios.c:2620:43 [Sun Oct 1 15:59:04 2023] index 1 is out of range for type 'UCHAR [1]' [Sun Oct 1 15:59:04 2023] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G T 6.5.5 #13 55df8de52754ef95effc50a55e9206abdea304ac [Sun Oct 1 15:59:04 2023] Hardware name: Supermicro X9SRL-F/X9SRL-F, BIOS 3.3 11/13/2018 [Sun Oct 1 15:59:04 2023] Call Trace: [Sun Oct 1 15:59:04 2023] [Sun Oct 1 15:59:04 2023] dump_stack_lvl+0x36/0x50 [Sun Oct 1 15:59:04 2023] __ubsan_handle_out_of_bounds+0xc7/0x110 [Sun Oct 1 15:59:04 2023] radeon_atombios_get_power_modes+0x87a/0x8f0 [Sun Oct 1 15:59:04 2023] radeon_pm_init+0x13a/0x7e0 [Sun Oct 1 15:59:04 2023] evergreen_init+0x13d/0x3d0 [Sun Oct 1 15:59:04 2023] radeon_device_init+0x60a/0xbf0 [Sun Oct 1 15:59:04 2023] radeon_driver_load_kms+0xb1/0x250 [Sun Oct 1 15:59:04 2023] drm_dev_register+0xfc/0x250 [Sun Oct 1 15:59:04 2023] radeon_pci_probe+0xd0/0x150 [Sun Oct 1 15:59:04 2023] pci_device_probe+0x97/0x130 [Sun Oct 1 15:59:04 2023] really_probe+0xbe/0x2f0 [Sun Oct 1 15:59:04 2023] ? __pfx___driver_attach+0x10/0x10 [Sun Oct 1 15:59:04 2023] __driver_probe_device+0x6e/0x120 [Sun Oct 1 15:59:04 2023] driver_probe_device+0x1a/0x90 [Sun Oct 1 15:59:04 2023] __driver_attach+0xd4/0x170 [Sun Oct 1 15:59:04 2023] bus_for_each_dev+0x87/0xe0 [Sun Oct 1 15:59:04 2023] bus_add_driver+0xf3/0x1f0 [Sun Oct 1 15:59:04 2023] driver_register+0x58/0x120 [Sun Oct 1 15:59:04 2023] ? __pfx_radeon_module_init+0x10/0x10 [Sun Oct 1 15:59:04 2023] do_one_initcall+0x93/0x4a0 [Sun Oct 1 15:59:04 2023] kernel_init_freeable+0x301/0x580 [Sun Oct 1 15:59:04 2023] ? __pfx_kernel_init+0x10/0x10 [Sun Oct 1 15:59:04 2023] kernel_init+0x15/0x1b0 [Sun Oct 1 15:59:04 2023] ret_from_fork+0x2f/0x50 [Sun Oct 1 15:59:04 2023] ? __pfx_kernel_init+0x10/0x10 [Sun Oct 1 15:59:04 2023] ret_from_fork_asm+0x1b/0x30 [Sun Oct 1 15:59:04 2023] [Sun Oct 1 15:59:04 2023] [Sun Oct 1 15:59:04 2023] [drm] radeon: dpm initialized [Sun Oct 1 15:59:04 2023] [drm] GART: num cpu pages 262144, num gpu pages 262144 [Sun Oct 1 15:59:04 2023] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [Sun Oct 1 15:59:04 2023] [drm] PCIE GART of 1024M enabled (table at 0x0014C000). [Sun Oct 1 15:59:04 2023] radeon :03:00.0: WB enabled [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 0 use gpu addr 0x4c00 [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 3 use gpu addr 0x4c0c [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 5 use gpu addr 0x0005c418 [Sun Oct 1 15:59:04 2023] radeon :03:00.0: radeon: MSI limited to 32-bit [Sun Oct 1 15:59:04 2023] radeon :03:00.0: radeon: using MSI. [Sun Oct 1 15:59:04 2023] [drm] radeon: irq initialized. Please also open an issue on freedesktop tracker [1]. Thanks. [1]: https://gitlab.freedesktop.org/drm/amd/-/issues Issue opened: https://gitlab.freedesktop.org/drm/amd/-/issues/2894 Regards, Justin +Kees since I've worked with him on several of these flexible array issues. I just happened to look at kernel logs today for my ath1*k driver maintenance and see the subject issue is present on my device, running 6.9.0-rc1. The freedesktop issue tracker says the issue is closed, but any fix has not landed in the upstream kernel. Is there a -next patch somewhere? [ 12.105270] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/radeon/radeon_atombios.c:2718:34 [ 12.105272] index 48 is out of range for type 'UCHAR [1]' [ If there isn't really an upstream fix, I can probably supply one. /jeff
Re: 6.5.5: UBSAN: radeon_atombios.c: index 1 is out of range for type 'UCHAR [1]'
On 4/8/2024 9:23 PM, Alex Deucher wrote: > On Mon, Apr 8, 2024 at 9:45 PM Kees Cook wrote: >> >> >> >> On April 8, 2024 5:45:29 PM PDT, Jeff Johnson >> wrote: >>> On 10/1/23 17:12, Justin Piszcz wrote: >>>>>> >>>>>> [Sun Oct 1 15:59:04 2023] UBSAN: array-index-out-of-bounds in >>>>>> drivers/gpu/drm/radeon/radeon_atombios.c:2620:43 >>>>>> [Sun Oct 1 15:59:04 2023] index 1 is out of range for type 'UCHAR [1]' >>>>>> [Sun Oct 1 15:59:04 2023] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G >>>>>> T 6.5.5 #13 55df8de52754ef95effc50a55e9206abdea304ac >>>>>> [Sun Oct 1 15:59:04 2023] Hardware name: Supermicro X9SRL-F/X9SRL-F, >>>>>> BIOS 3.3 11/13/2018 >>>>>> [Sun Oct 1 15:59:04 2023] Call Trace: >>>>>> [Sun Oct 1 15:59:04 2023] >>>>>> [Sun Oct 1 15:59:04 2023] dump_stack_lvl+0x36/0x50 >>>>>> [Sun Oct 1 15:59:04 2023] __ubsan_handle_out_of_bounds+0xc7/0x110 >>>>>> [Sun Oct 1 15:59:04 2023] radeon_atombios_get_power_modes+0x87a/0x8f0 >>>>>> [Sun Oct 1 15:59:04 2023] radeon_pm_init+0x13a/0x7e0 >>>>>> [Sun Oct 1 15:59:04 2023] evergreen_init+0x13d/0x3d0 >>>>>> [Sun Oct 1 15:59:04 2023] radeon_device_init+0x60a/0xbf0 >>>>>> [Sun Oct 1 15:59:04 2023] radeon_driver_load_kms+0xb1/0x250 >>>>>> [Sun Oct 1 15:59:04 2023] drm_dev_register+0xfc/0x250 >>>>>> [Sun Oct 1 15:59:04 2023] radeon_pci_probe+0xd0/0x150 >>>>>> [Sun Oct 1 15:59:04 2023] pci_device_probe+0x97/0x130 >>>>>> [Sun Oct 1 15:59:04 2023] really_probe+0xbe/0x2f0 >>>>>> [Sun Oct 1 15:59:04 2023] ? __pfx___driver_attach+0x10/0x10 >>>>>> [Sun Oct 1 15:59:04 2023] __driver_probe_device+0x6e/0x120 >>>>>> [Sun Oct 1 15:59:04 2023] driver_probe_device+0x1a/0x90 >>>>>> [Sun Oct 1 15:59:04 2023] __driver_attach+0xd4/0x170 >>>>>> [Sun Oct 1 15:59:04 2023] bus_for_each_dev+0x87/0xe0 >>>>>> [Sun Oct 1 15:59:04 2023] bus_add_driver+0xf3/0x1f0 >>>>>> [Sun Oct 1 15:59:04 2023] driver_register+0x58/0x120 >>>>>> [Sun Oct 1 15:59:04 2023] ? __pfx_radeon_module_init+0x10/0x10 >>>>>> [Sun Oct 1 15:59:04 2023] do_one_initcall+0x93/0x4a0 >>>>>> [Sun Oct 1 15:59:04 2023] kernel_init_freeable+0x301/0x580 >>>>>> [Sun Oct 1 15:59:04 2023] ? __pfx_kernel_init+0x10/0x10 >>>>>> [Sun Oct 1 15:59:04 2023] kernel_init+0x15/0x1b0 >>>>>> [Sun Oct 1 15:59:04 2023] ret_from_fork+0x2f/0x50 >>>>>> [Sun Oct 1 15:59:04 2023] ? __pfx_kernel_init+0x10/0x10 >>>>>> [Sun Oct 1 15:59:04 2023] ret_from_fork_asm+0x1b/0x30 >>>>>> [Sun Oct 1 15:59:04 2023] >>>>>> [Sun Oct 1 15:59:04 2023] >>>>>> >>>>>> [Sun Oct 1 15:59:04 2023] [drm] radeon: dpm initialized >>>>>> [Sun Oct 1 15:59:04 2023] [drm] GART: num cpu pages 262144, num gpu >>>>>> pages 262144 >>>>>> [Sun Oct 1 15:59:04 2023] [drm] enabling PCIE gen 2 link speeds, >>>>>> disable with radeon.pcie_gen2=0 >>>>>> [Sun Oct 1 15:59:04 2023] [drm] PCIE GART of 1024M enabled (table at >>>>>> 0x0014C000). >>>>>> [Sun Oct 1 15:59:04 2023] radeon :03:00.0: WB enabled >>>>>> [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 0 >>>>>> use gpu addr 0x4c00 >>>>>> [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 3 >>>>>> use gpu addr 0x4c0c >>>>>> [Sun Oct 1 15:59:04 2023] radeon :03:00.0: fence driver on ring 5 >>>>>> use gpu addr 0x0005c418 >>>>>> [Sun Oct 1 15:59:04 2023] radeon :03:00.0: radeon: MSI limited to >>>>>> 32-bit >>>>>> [Sun Oct 1 15:59:04 2023] radeon :03:00.0: radeon: using MSI. >>>>>> [Sun Oct 1 15:59:04 2023] [drm] radeon: irq initialized. >>>>>> >>>>> >>>>> Please also open an issue on freedesktop tracker [1]. >>>>> >>>>> Thanks. >>>>> >>>>> [1]: ht
Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()
On 2/23/2024 9:56 AM, Steven Rostedt wrote: > From: "Steven Rostedt (Google)" > > [ >This is a treewide change. I will likely re-create this patch again in >the second week of the merge window of v6.9 and submit it then. Hoping >to keep the conflicts that it will cause to a minimum. > ] > > With the rework of how the __string() handles dynamic strings where it > saves off the source string in field in the helper structure[1], the > assignment of that value to the trace event field is stored in the helper > value and does not need to be passed in again. Just curious if this could be done piecemeal by first changing the macros to be variadic macros which allows you to ignore the extra argument. The callers could then be modified in their separate trees. And then once all the callers have be merged, the macros could be changed to no longer be variadic.
Re: [PATCH V8 3/9] cfg80211: expose nl80211_chan_width_to_mhz for wide sharing
On 8/10/2023 12:37 AM, Evan Quan wrote:
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7c7d03aa9d06..f50508e295db 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
cfg80211_chandef_compatible(const struct cfg80211_chan_def *chandef1,
const struct cfg80211_chan_def *chandef2);
+/**
+ * nl80211_chan_width_to_mhz - get the channel width in Mhz
+ * @chan_width: the channel width from &enum nl80211_chan_width
+ * Return: channel width in Mhz if the chan_width from &enum nl80211_chan_width
+ * is valid. -1 otherwise.
SI nit: s/Mhz/MHz/ in both places
+ */
+int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width);
+
/**
* cfg80211_chandef_valid - check if a channel definition is valid
* @chandef: the channel definition to check
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 0b7e81db383d..227db04eac42 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -141,7 +141,7 @@ static bool cfg80211_edmg_chandef_valid(const struct
cfg80211_chan_def *chandef)
return true;
}
-static int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
+int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
{
int mhz;
@@ -190,6 +190,7 @@ static int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
}
return mhz;
}
+EXPORT_SYMBOL(nl80211_chan_width_to_mhz);
static int cfg80211_chandef_get_width(const struct cfg80211_chan_def *c)
{
Re: [V11 3/8] wifi: mac80211: Add support for WBRF features
On 8/30/2023 11:20 PM, Evan Quan wrote:
To support the WBRF mechanism, Wifi adapters utilized in the system must
Since this is the first mention of WBRF in the core wireless code IMO
you should indicate what this is an acronym for and briefly describe it
(or add a lore link).
I'm wondering if WBRF is just a special case of frequency avoidance, and
that more generic naming/terminology should be used in core wireless.
For example, I know there are vendor-specific solutions which allow
Wi-Fi to avoid using channels which may conflict with cellular or
BlueTooth, and those may benefit from a more generic
register the frequencies in use(or unregister those frequencies no longer
used) via the dedicated calls. So that, other drivers responding to the
frequencies can take proper actions to mitigate possible interference.
Co-developed-by: Mario Limonciello
Signed-off-by: Mario Limonciello
Co-developed-by: Evan Quan
Signed-off-by: Evan Quan
--
v1->v2:
- place the new added member(`wbrf_supported`) in
ieee80211_local(Johannes)
- handle chandefs change scenario properly(Johannes)
- some minor fixes around code sharing and possible invalid input
checks(Johannes)
v2->v3:
- drop unnecessary input checks and intermediate APIs(Mario)
- Separate some mac80211 common code(Mario, Johannes)
v3->v4:
- some minor fixes around return values(Johannes)
v9->v10:
- get ranges_in->num_of_ranges set and passed in(Johannes)
---
include/linux/ieee80211.h | 1 +
net/mac80211/Makefile | 2 +
net/mac80211/chan.c| 9
net/mac80211/ieee80211_i.h | 9
net/mac80211/main.c| 2 +
net/mac80211/wbrf.c| 105 +
6 files changed, 128 insertions(+)
create mode 100644 net/mac80211/wbrf.c
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 4b998090898e..f995d06da87f 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -4335,6 +4335,7 @@ static inline int ieee80211_get_tdls_action(struct
sk_buff *skb, u32 hdr_size)
/* convert frequencies */
#define MHZ_TO_KHZ(freq) ((freq) * 1000)
#define KHZ_TO_MHZ(freq) ((freq) / 1000)
+#define KHZ_TO_HZ(freq) ((freq) * 1000)
#define PR_KHZ(f) KHZ_TO_MHZ(f), f % 1000
#define KHZ_F "%d.%03d"
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index b8de44da1fb8..d46c36f55fd3 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -65,4 +65,6 @@ rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS) += \
mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-y)
+mac80211-y += wbrf.o
+
ccflags-y += -DDEBUG
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 68952752b599..458469c224ae 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -506,11 +506,16 @@ static void _ieee80211_change_chanctx(struct
ieee80211_local *local,
WARN_ON(!cfg80211_chandef_compatible(&ctx->conf.def, chandef));
+ ieee80211_remove_wbrf(local, &ctx->conf.def);
+
ctx->conf.def = *chandef;
/* check if min chanctx also changed */
changed = IEEE80211_CHANCTX_CHANGE_WIDTH |
_ieee80211_recalc_chanctx_min_def(local, ctx, rsvd_for);
+
+ ieee80211_add_wbrf(local, &ctx->conf.def);
+
drv_change_chanctx(local, ctx, changed);
if (!local->use_chanctx) {
@@ -668,6 +673,8 @@ static int ieee80211_add_chanctx(struct ieee80211_local
*local,
lockdep_assert_held(&local->mtx);
lockdep_assert_held(&local->chanctx_mtx);
+ ieee80211_add_wbrf(local, &ctx->conf.def);
+
if (!local->use_chanctx)
local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
@@ -748,6 +755,8 @@ static void ieee80211_del_chanctx(struct ieee80211_local *local,
}
ieee80211_recalc_idle(local);
+
+ ieee80211_remove_wbrf(local, &ctx->conf.def);
}
static void ieee80211_free_chanctx(struct ieee80211_local *local,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 91633a0b723e..719f2c892132 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1600,6 +1600,8 @@ struct ieee80211_local {
/* extended capabilities provided by mac80211 */
u8 ext_capa[8];
+
+ bool wbrf_supported;
};
static inline struct ieee80211_sub_if_data *
@@ -2638,4 +2640,11 @@ ieee80211_eht_cap_ie_to_sta_eht_cap(struct
ieee80211_sub_if_data *sdata,
const struct ieee80211_eht_cap_elem
*eht_cap_ie_elem,
u8 eht_cap_len,
struct link_sta_info *link_sta);
+
+void ieee80211_check_wbrf_support(struct ieee80211_local *local);
+void ieee80211_add_wbrf(struct ieee80211_local *local,
+ struct cfg80211_chan_def *chandef);
+void ieee80211_remove_wbrf(struct ieee80211_local *local,
+ struct cfg80211_chan_def *chandef);
+
#endif /* IEEE80211_I_H
Re: [PATCH v5 03/44] drm/vkms: Add kunit tests for VKMS LUT handling
On 8/19/24 13:56, Harry Wentland wrote:
> Debugging LUT math is much easier when we can unit test
> it. Add kunit functionality to VKMS and add tests for
> - get_lut_index
> - lerp_u16
>
> v5:
> - Bring back static for lerp_u16 and get_lut_index (Arthur)
>
> v4:
> - Test the critical points of the lerp function (Pekka)
>
> v3:
> - Use include way of testing static functions (Arthur)
note version information is usually after the "---" so that it not part
of the final git history
>
> Signed-off-by: Harry Wentland
> Cc: Arthur Grillo
> ---
> drivers/gpu/drm/vkms/Kconfig | 5 +
> drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
> drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 163 ++
> drivers/gpu/drm/vkms/vkms_composer.c | 4 +
> 4 files changed, 176 insertions(+)
> create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
> create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>
> diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
> index b9ecdebecb0b..c1f8b343ff0e 100644
> --- a/drivers/gpu/drm/vkms/Kconfig
> +++ b/drivers/gpu/drm/vkms/Kconfig
> @@ -13,3 +13,8 @@ config DRM_VKMS
> a VKMS.
>
> If M is selected the module will be called vkms.
> +
> +config DRM_VKMS_KUNIT_TESTS
> + tristate "Tests for VKMS" if !KUNIT_ALL_TESTS
> + depends on DRM_VKMS && KUNIT
> + default KUNIT_ALL_TESTS
> diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig
> b/drivers/gpu/drm/vkms/tests/.kunitconfig
> new file mode 100644
> index ..70e378228cbd
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
> @@ -0,0 +1,4 @@
> +CONFIG_KUNIT=y
> +CONFIG_DRM=y
> +CONFIG_DRM_VKMS=y
> +CONFIG_DRM_VKMS_KUNIT_TESTS=y
> diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> new file mode 100644
> index ..fc73e48aa57c
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
...
> +kunit_test_suite(vkms_color_test_suite);
> +
> +MODULE_LICENSE("GPL");
> \ No newline at end of file
Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the
description is missing"), a module without a MODULE_DESCRIPTION() will
result in a warning when built with make W=1. Recently, multiple
developers have been eradicating these warnings treewide, and very few
are left, so please don't introduce a new one :)
Please add the missing MODULE_DESCRIPTION()
/jeff
Re: [PATCH v5 20/44] drm/tests: Add a few tests around drm_fixed.h
On 8/19/24 13:56, Harry Wentland wrote:
> While working on the CTM implementation of VKMS I had to ascertain
> myself of a few assumptions. One of those is whether drm_fixed.h
> treats its numbers using signed-magnitude or twos-complement. It is
> twos-complement.
>
> In order to make someone else's day easier I am adding the
> drm_test_int2fixp test that validates the above assumption.
>
> I am also adding a test for the new sm2fixp function that converts
> from a signed-magnitude fixed point to the twos-complement fixed
> point.
>
> Signed-off-by: Harry Wentland
> ---
> drivers/gpu/drm/tests/Makefile| 3 +-
> drivers/gpu/drm/tests/drm_fixp_test.c | 69 +++
> 2 files changed, 71 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/tests/drm_fixp_test.c
>
> diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
> index 56dab563abd7..bd69df0eee33 100644
> --- a/drivers/gpu/drm/tests/Makefile
> +++ b/drivers/gpu/drm/tests/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
> drm_modes_test.o \
> drm_plane_helper_test.o \
> drm_probe_helper_test.o \
> - drm_rect_test.o
> + drm_rect_test.o \
> + drm_fixp_test.o
>
> CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
> diff --git a/drivers/gpu/drm/tests/drm_fixp_test.c
> b/drivers/gpu/drm/tests/drm_fixp_test.c
> new file mode 100644
> index ..f420f173ff66
> --- /dev/null
> +++ b/drivers/gpu/drm/tests/drm_fixp_test.c
> @@ -0,0 +1,69 @@
...
> +MODULE_AUTHOR("AMD");
> +MODULE_LICENSE("GPL and additional rights");
> \ No newline at end of file
Please add the missing MODULE_DESCRIPTION()
