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]
Message-ID: <1ba2fa240803180400y1d7a2740t2c21b8b73a755016@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ