[Patch v3] supplicant: add dbus getter method for nl80211 iftype

[Avinash Patil]

Hi,

Just to bring this discussion to logical end:

Patches for ability to convert virtual interface type from any of the
supported types to any other supported types for mwifiex driver have
been submitted  upstream and have been accepted.

http://www.spinics.net/lists/linux-wireless/msg131912.html

Jouni/Johannes,

Thanks a lot for your valuable comments. As Johannes suggested I have
decoupled netdev interface combination from FW interface types.

Regards,
Avinash

On Mon, Dec 22, 2014 at 4:29 PM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> On Mon, 2014-12-22 at 12:42 +0200, Jouni Malinen wrote:
>
>> > So when wiphy capabilities indicate support for AP interface, it does not
>> > mean we should expect very first interface to be of AP type.
>> > Driver can have multiple virtual interfaces and one of them would support
>> > AP operation. So having right to know interface type is something that is
>> > not expected??
>>
>> That's a kernel side question (i.e., not really a topic for the hostap
>> mailing list, but linux-wireless). I agree that vendors can have
>> different designs in how what kind of combinations are supported.
>> However, you will need to make sure cfg80211 can advertise the
>> capabilities properly for your driver. It sounds like that is not the
>> case here now [...]
>
> This is indeed the case. The question is, however, less around the
> actual combination capabilities and more around how those are
> interpreted with existing interfaces. I'm arguing that the current
> advertisement of capabilities and combinations makes no representations
> about which interfaces can change types at what time and assumes that
> any interface belonging to a given hardware can always change to any
> other type as long as the combinations are respected.
>
> I would *very strongly* recommend that the driver be fixed to remove
> this limitation, it clearly must be possible to fix this in the driver,
> at least by decoupling the "netdev" and "internal device/firmware
> virtual device" concepts.
>
> If this is not possible then the current interface combinations
> advertisement that cfg80211 exposes cannot be used, and a new API must
> be added that takes such restrictions into account. I'd hate to see
> this, but if I've seen reasonable effort of (failing at) fixing the
> driver I might be willing to accept such an API change into
> cfg80211/nl80211.
>
> johannes
>