linux-kernel - Re: [PATCH v2 1/1] platform/x86: asus-wmi: add support variant of TUF RGB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 20 Mar 2024 13:36:58 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: "Luke D. Jones" <luke@...nes.dev>
cc: Hans de Goede <hdegoede@...hat.com>, corentin.chary@...il.com, 
    platform-driver-x86@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/1] platform/x86: asus-wmi: add support variant of
 TUF RGB

On Wed, 20 Mar 2024, Luke D. Jones wrote:

> Adds support for a second TUF RGB wmi call that some versions of the TUF
> laptop come with. Also adjusts existing support to select whichever is
> available.
> 
> Signed-off-by: Luke D. Jones <luke@...nes.dev>
> ---
>  drivers/platform/x86/asus-wmi.c            | 13 +++++++++++--
>  include/linux/platform_data/x86/asus-wmi.h |  1 +
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index b9a2fb8007c0..0d8a2b82cc06 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c

> @@ -4544,6 +4545,14 @@ static int asus_wmi_add(struct platform_device *pdev)
>  		asus->gpu_mux_dev = ASUS_WMI_DEVID_GPU_MUX_VIVO;
>  	}
>  
> +	if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_TUF_RGB_MODE)) {

The patch itself is fine,

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>

However,

There's a major problem in the way you're submitting these. This patch is 
built on top of the GPU_MUX_VIVO patch as can be seen from the context
above. Yet, you're sending these independently instead of series. I 
suspect there are other similar problems among these patches that there's 
hidden dependency order in which these should be applied. This will cause 
problems if maintainer applies the patches in wrong order (they may even 
misapply with fuzz).

Only if the patches are truly independent, that is, focus on solving 
entirely differently thing (functional independency) and do not have any 
linewise conflicts (code locality independecy) either, it's fine to send 
patches as independent ones without making a series out of them. But 
clearly it's not the case here.

-- 
 i.