linux-kernel - Re: [PATCH] HISI LPC: Don't fail probe for unrecognised child devices

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]

Message-ID: <20190104222521.6r7lmz7so22xu2nj@localhost>
Date:   Fri, 4 Jan 2019 14:25:21 -0800
From:   Olof Johansson <olof@...om.net>
To:     John Garry <john.garry@...wei.com>
Cc:     xuwei5@...wei.com, arm@...nel.org, linuxarm@...wei.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] HISI LPC: Don't fail probe for unrecognised child devices

On Thu, Jan 03, 2019 at 07:57:02PM +0800, John Garry wrote:
> Currently for ACPI-based FW we fail the probe for an unrecognised child
> HID.
> 
> However, there is FW in the field with LPC child devices having fake HIDs,
> namely "IPI0002", which was an IPMI device invented to support the
> initial out-of-tree LPC host driver, different from the final mainline
> version.
> 
> To provide compatibility support for these dodgy FWs, just discard the
> unrecognised HIDs instead of failing the probe altogether.
> 
> Tested-by: Zengruan Ye <yezengruan@...wei.com>
> Signed-off-by: John Garry <john.garry@...wei.com>
> 
> diff --git a/drivers/bus/hisi_lpc.c b/drivers/bus/hisi_lpc.c
> index d5f8545..19d7b6f 100644
> --- a/drivers/bus/hisi_lpc.c
> +++ b/drivers/bus/hisi_lpc.c
> @@ -522,10 +522,9 @@ static int hisi_lpc_acpi_probe(struct device *hostdev)
>  
>  		if (!found) {
>  			dev_warn(hostdev,
> -				 "could not find cell for child device (%s)\n",
> +				 "could not find cell for child device (%s), discarding\n",
>  				 hid);
> -			ret = -ENODEV;
> -			goto fail;
> +			continue;
>  		}

This driver is the equivalent of a board file. Wasn't ACPI supposed to
spare us from these platform device tables? It even has hardcoded clock
information in it. :(

Also, we were told that there'll be expectations for users to update
their ACPI tables if they're incompatible our out of date. Can that be done
here as well?


-Olof