carl9170: not able to add P2P_GO - add_interface fail with -EBUSY

carl9170: not able to add P2P_GO - add_interface fail with -EBUSY

[Janusz Dziedzic]

Hello,

With latest compat, wpa_supplicant seems p2p_concurent is set for
car9170 driver based on information from driver.
So, next after p2p_group_add new virtual interface is created for that
- p2p-wlan0-0.

Next, carl9170_op_add_interface() return -EBUSY because there is
already main_vif (NL80211_IFTYPE_STATION) created by default on
startup.
Because of that p2p_group_add() always fail with such chipset and
p2p_concurent=1.

STEPS:
- run wpa_supplicant
- run wpa_cli
- p2p_group_add
FAIL

Is that chipset limitation we could add only new STA interface when
main_vif is also STA?
Where could I find HW documentation for carl9170?



I suspect lower change is not acceptable because of HW limitation?

        main_vif = carl9170_get_main_vif(ar);

        if (main_vif) {
                switch (main_vif->type) {
                case NL80211_IFTYPE_STATION:
-                       if (vif->type == NL80211_IFTYPE_STATION)
+                       if ((vif->type == NL80211_IFTYPE_STATION) ||
+                           (vif->type == NL80211_IFTYPE_AP))
                                break;



BR
Janusz

Re: carl9170: not able to add P2P_GO - add_interface fail with -EBUSY

[Christian Lamparter]

On Friday 06 April 2012 12:39:57 Janusz Dziedzic wrote:
> With latest compat, wpa_supplicant seems p2p_concurent is set for
> car9170 driver based on information from driver.
> So, next after p2p_group_add new virtual interface is created for that
> - p2p-wlan0-0.
> 
> Next, carl9170_op_add_interface() return -EBUSY because there is
> already main_vif (NL80211_IFTYPE_STATION) created by default on
> startup.
> Because of that p2p_group_add() always fail with such chipset and
> p2p_concurent=1.
> 
> STEPS:
> - run wpa_supplicant
> - run wpa_cli
> - p2p_group_add
> FAIL
> 
> Is that chipset limitation we could add only new STA interface when
> main_vif is also STA?
<http://wireless.kernel.org/en/users/Drivers/carl9170#Multiple_Interfaces>
no, it's not. But you'll have to go through several hoops to extend
the driver to switch the "main" interface while the device is up and
running.

good luck!

> Where could I find HW documentation for carl9170?
HW documentation for carl9170? There's no such thing.
But Qualcomm has some docs about the AR9170.
 
> I suspect lower change is not acceptable because of HW limitation?
> 
>         main_vif = carl9170_get_main_vif(ar);
> 
>         if (main_vif) {
>                 switch (main_vif->type) {
>                 case NL80211_IFTYPE_STATION:
> -                       if (vif->type == NL80211_IFTYPE_STATION)
> +                       if ((vif->type == NL80211_IFTYPE_STATION) ||
> +                           (vif->type == NL80211_IFTYPE_AP))
>                                 break;
No, it's just the driver can't guarantee that such a configuration
will be what you think it is.

Regards,
	Chr

Re: carl9170: not able to add P2P_GO - add_interface fail with -EBUSY

[Johannes Berg]

On Fri, 2012-04-06 at 13:22 +0200, Christian Lamparter wrote:

> > Is that chipset limitation we could add only new STA interface when
> > main_vif is also STA?
> <http://wireless.kernel.org/en/users/Drivers/carl9170#Multiple_Interfaces>
> no, it's not. But you'll have to go through several hoops to extend
> the driver to switch the "main" interface while the device is up and
> running.

So the driver has a concept of the order in which interfaces are added?
That's something I never considered when writing the interface type
combinations support.

johannes

Re: carl9170: not able to add P2P_GO - add_interface fail with -EBUSY

[Christian Lamparter]

On Friday 06 April 2012 17:11:29 Johannes Berg wrote:
> On Fri, 2012-04-06 at 13:22 +0200, Christian Lamparter wrote:
> 
> > > Is that chipset limitation we could add only new STA interface when
> > > main_vif is also STA?
> > <http://wireless.kernel.org/en/users/Drivers/carl9170#Multiple_Interfaces>
> > no, it's not. But you'll have to go through several hoops to extend
> > the driver to switch the "main" interface while the device is up and
> > running.
> 
> So the driver has a concept of the order in which interfaces are added?
> That's something I never considered when writing the interface type
> combinations support.
Actually, it's more of a master/slave situation. 

The MAC only has one security engine "mode" which can be either AP/IBSS/WDS.
[So, this setting will be shared with all virtual interfaces]
Next, the MAC only has one TSF counter, [beacon/tbtt timer, etc...] which
is also shared between the virtual interfaces [note: the TSF sync depends
on the mode as well, you see if the main interface is a station/ibss then
the TSF is automatically updated [by the hardware in fact] and there is
nothing a slave interface [e.g.: AP] can do!]. And then there is of
course the shared ERP, basic rates, slot time, multicast, QOS/WME, ... stuff.

Regards,
	Christian

Re: carl9170: not able to add P2P_GO - add_interface fail with -EBUSY

[Adrian Chadd]

Hi,

Conceptually it'd be feasible to reset the hardware to a new state
that supports whatever the new vif features are.

That however includes all the gotcha! issues that occur when doing a
reset whilst live traffic is occuring..


Adrian