linux-kernel - Re: SDIO: IO-Ready Bit

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: <20080318123325.0843b854@mjolnir.drzeus.cx>
Date:	Tue, 18 Mar 2008 12:33:25 +0100
From:	Pierre Ossman <drzeus@...eus.cx>
To:	"Tomas Winkler" <tomasw@...il.com>
Cc:	lkml <linux-kernel@...r.kernel.org>, benzizbit@...il.com
Subject: Re: SDIO: IO-Ready Bit

On Tue, 18 Mar 2008 13:00:34 +0200
"Tomas Winkler" <tomasw@...il.com> wrote:

> I'm working on SDIO multi function device.  One of the subdevices  a
> system device (SYS) who's  purpose among the others is to initialize
> the whole combo, mainly it's loads the firmware of the devices and
> kick the sub devices. Each of the sub devices has it's own driver.
> This dictates the order of the driver initialization and SYS device
> has to compete it's work before other subdeivces drivers can access
> the hardware. From hardware perspective device is ready when IO-Ready
> bit in SDIO is set.

What a delightfully unfriendly design...

> The first problem is that currently there is hard code timeout  in
> sdio_enable_func instead of using TPLFE_ENABLE_TIMEOUT_VAL
> /*
> 	 * FIXME: This should timeout based on information in the CIS,
> 	 * but we don't have card to parse that yet.
> 	 */
> 	timeout = jiffies + HZ
> 
> This can be probably easily fixed. The significant issue is that this
> is done in busy wait loop and that probe functions are called in
> serially.

The SDIO spec doesn't really allow such a card to exist. So it's not surprising that things break. Does any stack support this odd-ball card?

> 
> Since we cannot ensure that enumeration of SYS devices will be first
> the other sub devices will fail in their probe functions while calling
> sido_enable_func
> 
> One option is to move the sdio_enable_func to be called from a work
> queue kicked from probe. This still requires non-busy wait timeout on
> IO-Ready bit and we cannot fail probe func
> if something goes wrong.
> Second option would be somehow split the sdio probe function across
> the enabled timeout.

I think it's a bit more complex than that. There are likely locks all over the place, both in the relevant driver and the driver model core, that makes this very difficult. Not to mention the fact that the correct timeout will be finite, and you never know how long it will take you to load the firmware.

A better approach is to simply have the drivers for your subfunctions synchronize things. Make sure noone calls sdio_enable_func() until the firmware has been loaded. This could even be done from user space in case you want to use a standard driver.

Rgds
Pierre


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