linux-kernel - Re: [PATCH 1/2] async: async device driver probing

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, 13 Aug 2014 10:20:33 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	falcon@...zu.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] async: async device driver probing

Hi Greg,

On Sat, Feb 08, 2014 at 10:27:29AM -0800, Greg KH wrote:
> On Sat, Feb 08, 2014 at 07:05:38PM +0800, falcon@...zu.com wrote:
> > From: Wu Zhangjin <wuzhangjin@...il.com>
> > 
> > [*Note*: NOT applicable, only for comments.]
> > 
> > To async the slow driver probing function of some devices, the device probing
> > support is modified to support async scheduling.
> > 
> > In order to async your driver probing function, please mask the async_probe
> > flag to 1, and to make sure one asynced probing is executed before an specified
> > point, please call async_synchronize_full() in that point..
> > 
> > Usage:
> > 
> > 	static struct i2c_driver test_driver = {
> > 		.driver = {
> > 			.name   = TEST_DEV_NAME,
> > 			.owner  = THIS_MODULE,
> > 	+               .async_probe = 1,
> > 		},
> 
> Why is this needed, we have defered probing and the container stuff, so
> what problem is this solving?

Deferred probing only helps if resources are not ready yet, but
sometimes we have a slow(ish) device which initialization stalls probing
the rest of the system. For example a touchpad can take up to a second
to calibrate itself after reset. One could try scheduling reset
asynchronously, or try to offload it to open(), but that is not always
best:

1. Manual async: what to do when reset fails? Ideally we do not want to
leave driver half-way bound with device not operable, but much rather
signal the rest of the system that binding of the device failed and
release all resources.

2. Offload to open: the same issue as with manually doing async reset,
plus sometimes we do not know all parameters that we should create input
device with until after we reset physical device and queried it for
capabilities.

Marking a driver to tell device core to execute probe asynchronously [at
boot time] seems like a very appealing feature from driver author POV.

What is the container stuff you mention?

Thanks.

-- 
Dmitry
--
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/