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]

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

On Tue, Mar 18, 2008 at 1:33 PM, Pierre Ossman <drzeus@...eus.cx> wrote:
> 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...

Yes, but it's damage is already done.

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

Not sure to which part of the above paragraph you refer here. The
timeout is defined by spec.

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

Good point but IMHO the timeout can got to minutes so it's converging
to infinite in this case.



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

Won't this prevent us from compiling the drivers into kernel?
Second how this possible especially with standard driver as they are
loaded. I know you can enforce module loading but how can you enforce
probing order form user space?

Thanks
Tomas

>  Rgds
>  Pierre
>
>
--
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/