linux-kernel - Re: [PATCH] spi/spi_s3c64xx: Move to subsys

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: <20100908161245.GC3686@angua.secretlab.ca>
Date:	Wed, 8 Sep 2010 10:12:45 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Jassi Brar <jassisinghbrar@...il.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Jassi Brar <jassi.brar@...sung.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	spi-devel-general@...ts.sourceforge.net,
	patches@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spi/spi_s3c64xx: Move to subsys_initcall()

On Wed, Sep 08, 2010 at 06:37:59PM +0900, Jassi Brar wrote:
> On Wed, Sep 8, 2010 at 6:12 PM, Mark Brown
> <broonie@...nsource.wolfsonmicro.com> wrote:
> > On Wed, Sep 08, 2010 at 01:55:39PM +0900, Jassi Brar wrote:
> >> On Tue, Sep 7, 2010 at 7:29 PM, Mark Brown
> >> <broonie@...nsource.wolfsonmicro.com> wrote:
> >> > Allow the use of the S3C64xx SPI controller with things like PMICs by
> >> > moving the init up to subsys_initcall().
> >
> >> Couldn't any user ever need to load it as a module?
> >> If no, we might as well drop the s3c64xx_spi_exit and s3c64xx_spi_remove
> >
> > This doesn't prevent building as a module - when built as a module
> > subsys_initcall() is identical to module_init(), the change will only
> > affect the order in which things are done when the code is built into
> > the kernel otherwise it's a noop.
> I didn't know that, thanks for the info.
> 
> Acked-by: Jassi Brar <jassi.brar@...sung.com>

Applied, thanks.

... but it seems to me that there is a systemic problem in the way the driver model is being used if SPI (and I2C) bus drivers need to be 'special' in this regard.  What are the ordering requirements on things like PMICs?  (My uneducated assumption is that other devices depend on them being enabled before being probed.)  Would it be better to have a mechanism to defer probing on certain devices until other devices are probed?  Then the relationships could be made explicit instead of the rather coarse-grained (and potentially fragile) approach of changing the init order.

g.
--
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/