On Wed, 2009-09-23 at 01:23 -0600, Tomas Winkler wrote: > On Wed, Sep 23, 2009 at 9:57 AM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Wed, 2009-09-23 at 02:38 +0300, Tomas Winkler wrote: > > > >> +config IWMC3200TOP > >> + tristate "Intel Wireless MultiCom Top Driver" > >> + depends on MMC && EXPERIMENTAL > >> + select FW_LOADER > >> + ---help--- > >> + Intel Wireless MultiCom 3200 Top driver is responsible for > >> + for firmware load and enabled coms enumeration > > > > This seems like the wrong approach to me. > > > > To me, it seems like you have a device that contains an internal bus and > > allows bus enumeration. Typically, we would surface that bus in the > > driver/device model and allow sub-drivers to bind to that by way of > > exposing the internal bus, like e.g. drivers/ssb/. > > From HW perspective your assumption is not exactly correct. All the > devices are visible on the SDIO bus but they are not operational > (probe won't succeed) until TOP download the firmware and kicks the > devices. From SW perspective to create another bus layer is an option. > I'm not sure if it's not more complicated one. It is definitely more complicated; we thought about it and it wasn't worth. The current solution works and it is simple enough. To extend Tomas' explanation: 1 device powers up 2 enabling any sdio function that is not the top one fails; drivers return -ENODEV 3 top function is enabled, firmware loaded, it initializes the rest of the functions. Top driver kicks a SDIO bus rescan on a workqueue 4 other sdio functions can be enabled and probe succesfully (uploading firmware, yadah yadah). A subbus would add a lot of complexity to all this, having to replicate most of the device probing, suspend/resume, pre/post reset (that's is being added to SDIO). Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
