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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ