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@xxxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxx>
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.
