linux-kernel - 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-next>] [day] [month] [year] [list]

Date:	Tue, 18 Mar 2008 13:00:34 +0200
From:	"Tomas Winkler" <tomasw@...il.com>
To:	drzeus@...eus.cx
Cc:	lkml <linux-kernel@...r.kernel.org>, benzizbit@...il.com
Subject: SDIO: IO-Ready Bit

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

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.

Thanks
Tomas
--
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/