linux-kernel - Re: [PATCH v2 01/12] device: property: delay device-driver matches

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:	Thu, 02 Jul 2015 01:29:59 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:	linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	linux-acpi@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-fbdev@...r.kernel.org, linux-gpio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-pwm@...r.kernel.org,
	alsa-devel@...a-project.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v2 01/12] device: property: delay device-driver matches

On Wednesday, July 01, 2015 11:40:56 AM Tomeu Vizoso wrote:
> Delay matches of platform devices until late_initcall, when we are sure
> that all built-in drivers have been registered already. This is needed
> to prevent deferred probes because of some dependencies' drivers not
> having registered yet.
> 
> This reduces the total amount of work that the kernel does during boot
> because it won't try to match devices to drivers when built-in drivers
> are still registering but also reduces some parallelism, so total boot
> time might slightly increase or decrease depending on the platform and
> kernel configuration.
> 
> This change will make make possible to prevent any deferred probes once
> devices are probed in dependency order.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
> ---
> 
> Changes in v2:
> - Instead of delaying all probes until late_initcall, only delay matches
>   of platform devices that have a firmware node attached.
> 
>  drivers/base/property.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 8528eb9..8ead1ba 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -16,8 +16,11 @@
>  #include <linux/of.h>
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
> +#include <linux/platform_device.h>
>  #include <linux/property.h>
>  
> +static bool fwnode_match_enable = false;
> +
>  /**
>   * device_add_property_set - Add a collection of properties to a device object.
>   * @dev: Device to add properties to.
> @@ -604,6 +607,15 @@ EXPORT_SYMBOL_GPL(fwnode_is_compatible);
>  bool fwnode_driver_match_device(struct device *dev,
>  				const struct device_driver *drv)
>  {
> +	/*
> +	 * Delay matches of platform devices until late_initcall, when we are
> +	 * sure that all built-in drivers have been registered already. This
> +	 * is needed to prevent deferred probes because of some drivers
> +	 * not having registered yet.
> +	 */
> +	if(dev->bus == &platform_bus_type && !fwnode_match_enable)
> +		return false;

I'm not particularly enthusiastic about referring to specific bus types in
generic code like that.

What about having a special version of fwnode_driver_match_device() specifically
for the platform bus type that will do the check?

> +
>  	if (is_of_node(dev->fwnode))
>  		return of_driver_match_device(dev, drv);
>  	else if (is_acpi_node(dev->fwnode))
> @@ -612,3 +624,20 @@ bool fwnode_driver_match_device(struct device *dev,
>  	return false;
>  }
>  EXPORT_SYMBOL_GPL(fwnode_driver_match_device);
> +
> +static int __device_attach(struct device *dev, void *data)
> +{
> +	device_initial_probe(dev);
> +
> +	return 0;
> +}
> +
> +static int fwnode_match_initcall(void)
> +{
> +	fwnode_match_enable = true;
> +
> +	bus_for_each_dev(&platform_bus_type, NULL, NULL, __device_attach);
> +
> +	return 0;
> +}
> +late_initcall(fwnode_match_initcall);
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/