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] [day] [month] [year] [list]
Date:	Mon, 22 Sep 2014 19:13:27 +0200
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Max Schwarz <max.schwarz@...ine.de>,
	Chris Zhong <zyw@...k-chips.com>,
	linux-rockchip@...ts.infradead.org,
	Heiko Stuebner <heiko@...ech.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c-rk3x: move setup to the earlier subsys initcall

Hi,

> In general you are correct.  You can get by with lots of probe
> deferrals.  I don't personally know of any case where things are
> broken with the current code, but it's really nice to avoid the
> deferrals if possible.

Yes, we all want proper dependencies and ordering, yet deferred probing
is the best we have.

> Given that this is a core SoC i2c bus and is used for _a lot_ of
> external connectivity (including for connecting to the primary
> regulator on most boards), bumping up the priority in the init order
> makes a lot of sense to me.
> 
> This also matches the i2c busses of most other major SoCs.  A selected
> few examples:
> 
> i2c-gpio.c:subsys_initcall(i2c_gpio_init);
> i2c-omap.c:subsys_initcall(omap_i2c_init_driver);
> i2c-s3c2410.c:subsys_initcall(i2c_adap_s3c_init);
> i2c-tegra.c:subsys_initcall(tegra_i2c_init_driver);

They were "lucky" to be around before deferred probing and using
subsys_initcall was always considered a hack. I am not accepting new
users of this hack unless there is really no other solution.

So, NACK, since it doesn't solve a problem.

Regards,

   Wolfram


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ