netdev - Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.

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:	Wed, 23 Sep 2009 10:48:14 -0700
From:	Inaky Perez-Gonzalez <inaky@...ux.intel.com>
To:	Tomas Winkler <tomasw@...il.com>
Cc:	Johannes Berg <johannes@...solutions.net>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"linville@...driver.com" <linville@...driver.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"Zhu, Yi" <yi.zhu@...el.com>,
	"Kao, Cindy H" <cindy.h.kao@...el.com>,
	"Cohen, Guy" <guy.cohen@...el.com>,
	"Rindjunsky, Ron" <ron.rindjunsky@...el.com>
Subject: Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top
 driver.

On Wed, 2009-09-23 at 01:23 -0600, Tomas Winkler wrote:
> On Wed, Sep 23, 2009 at 9:57 AM, Johannes Berg
> <johannes@...solutions.net> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html