P2P support in brcmfmac
Hi John,
In 3.9 we introduced P2P support in brcmfmac which was functional using current wpa_supplicant P2P support, but we did not yet support the P2P_DEVICE user-space API.
Last week I enabled that in brcmfmac testing it with wpa_supplicant patches for P2P_DEVICE support from David Spinadel. So I do have a couple of brcmfmac patches to make that work and would like to submit those for 3.9 although it is not strictly a bug fix. Would you consider taking these?
Regards,
Arend
Quoted 9 lines · Arend van Spriel
In 3.9 we introduced P2P support in brcmfmac which was functional using current
wpa_supplicantP2P support, but we did not yet support theP2P_DEVICEuser-space API.Last week I enabled that in brcmfmac testing it with
wpa_supplicantpatches forP2P_DEVICEsupport from David Spinadel. So I do have a couple of brcmfmac patches to make that work and would like to submit those for 3.9 although it is not strictly a bug fix. Would you consider taking these?
That doesn't sound to me like something that would be worthy of such an exception.
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 6 lines · John W. Linville
Quoted 4 lines · Arend van Spriel
In 3.9 we introduced P2P support in brcmfmac which was functional using current
wpa_supplicantP2P support, but we did not yet support theP2P_DEVICEuser-space API.
Quoted 8 lines
Quoted 5 lines
Last week I enabled that in brcmfmac testing it with
wpa_supplicantpatches forP2P_DEVICEsupport from David Spinadel. So I do have a couple of brcmfmac patches to make that work and would like to submit those for 3.9 although it is not strictly a bug fix. Would you consider taking these?That doesn't sound to me like something that would be worthy of such an exception.
Maybe just make a small patch to disable the other API, so we don't end up having to support both?
johannes
Quoted 13 lines · Johannes Berg
Quoted 12 lines · John W. Linville
Quoted 9 lines · Arend van Spriel
In 3.9 we introduced P2P support in brcmfmac which was functional using current
wpa_supplicantP2P support, but we did not yet support theP2P_DEVICEuser-space API.Last week I enabled that in brcmfmac testing it with
wpa_supplicantpatches forP2P_DEVICEsupport from David Spinadel. So I do have a couple of brcmfmac patches to make that work and would like to submit those for 3.9 although it is not strictly a bug fix. Would you consider taking these?
Quoted 5 lines
Quoted 2 lines
That doesn't sound to me like something that would be worthy of such an exception.
Maybe just make a small patch to disable the other API, so we don't end up having to support both?
Maybe I misunderstood. So brcmfmac currently supports a P2P API that is not otherwise available and which we don't want to support in the future?
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 17 lines · John W. Linville
Quoted 16 lines · Johannes Berg
Quoted 14 lines · John W. Linville
Quoted 9 lines · Arend van Spriel
In 3.9 we introduced P2P support in brcmfmac which was functional using current
wpa_supplicantP2P support, but we did not yet support theP2P_DEVICEuser-space API.Last week I enabled that in brcmfmac testing it with
wpa_supplicantpatches forP2P_DEVICEsupport from David Spinadel. So I do have a couple of brcmfmac patches to make that work and would like to submit those for 3.9 although it is not strictly a bug fix. Would you consider taking these?That doesn't sound to me like something that would be worthy of such an exception.
Quoted 6 lines
Quoted 2 lines
Maybe just make a small patch to disable the other API, so we don't end up having to support both?
Maybe I misunderstood. So brcmfmac currently supports a P2P API that is not otherwise available and which we don't want to support in the future?
As I understand it, brcmfmac currently supports having a P2P device *netdev*, which is of (wireless) type STATION (presumably), which isn't something we want to support (well, I don't anyway, it's difficult to discover for applications).
The "correct" way (the way I decided to implement this P2P device concept in the upstreamtree ) is to have a P2P device *wireless dev* which has no netdev associated -- this makes more sense since no data frames are ever transmitted or received on a P2P device.
As I understand Arend, he was suggesting to put patches into 3.9 that would move brcmfmac from the interim API with a netdev he had used for testing to the final API that is actually implemented in 3.9 but before the wpa_supplicant patches had no way to get used. Now those patches are there in wpa_supplicant though (or well, on their way in)
johannes
Quoted 35 lines · Johannes Berg
Quoted 17 lines · John W. Linville
Quoted 16 lines · Johannes Berg
Quoted 14 lines · John W. Linville
Quoted 9 lines · Arend van Spriel
In 3.9 we introduced P2P support in brcmfmac which was functional using current
wpa_supplicantP2P support, but we did not yet support theP2P_DEVICEuser-space API.Last week I enabled that in brcmfmac testing it with
wpa_supplicantpatches forP2P_DEVICEsupport from David Spinadel. So I do have a couple of brcmfmac patches to make that work and would like to submit those for 3.9 although it is not strictly a bug fix. Would you consider taking these?That doesn't sound to me like something that would be worthy of such an exception.
Quoted 6 lines
Quoted 2 lines
Maybe just make a small patch to disable the other API, so we don't end up having to support both?
Maybe I misunderstood. So brcmfmac currently supports a P2P API that is not otherwise available and which we don't want to support in the future?
As I understand it, brcmfmac currently supports having a P2P device *netdev*, which is of (wireless) type STATION (presumably), which isn't something we want to support (well, I don't anyway, it's difficult to discover for applications).
The "correct" way (the way I decided to implement this P2P device concept in the upstreamtree ) is to have a P2P device *wireless dev* which has no netdev associated -- this makes more sense since no data frames are ever transmitted or received on a P2P device.
Quoted 5 lines
As I understand Arend, he was suggesting to put patches into 3.9 that would move brcmfmac from the interim API with a netdev he had used for testing to the final API that is actually implemented in 3.9 but before the
wpa_supplicantpatches had no way to get used. Now those patches are there inwpa_supplicantthough (or well, on their way in)
I see...in that case, a patch that disables the interim API seems appropriate.
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 21 lines · Johannes Berg
Quoted 20 lines · John W. Linville
Quoted 18 lines · Johannes Berg
Quoted 6 lines · John W. Linville
Quoted 4 lines · Arend van Spriel
In 3.9 we introduced P2P support in brcmfmac which was functional using current
wpa_supplicantP2P support, but we did not yet support theP2P_DEVICEuser-space API.Quoted 8 lines
Quoted 5 lines
Last week I enabled that in brcmfmac testing it with
wpa_supplicantpatches forP2P_DEVICEsupport from David Spinadel. So I do have a couple of brcmfmac patches to make that work and would like to submit those for 3.9 although it is not strictly a bug fix. Would you consider taking these?That doesn't sound to me like something that would be worthy of such an exception.
Maybe just make a small patch to disable the other API, so we don't end up having to support both?
Quoted 8 lines
Quoted 3 lines
Maybe I misunderstood. So brcmfmac currently supports a P2P API that is not otherwise available and which we don't want to support in the future?
As I understand it, brcmfmac currently supports having a P2P device *netdev*, which is of (wireless) type STATION (presumably), which isn't something we want to support (well, I don't anyway, it's difficult to discover for applications).
It is a bit more subtle. After the merge window since 3.9-rc1 brcmfmac supports to have a P2P device *wireless dev* WITH a netdev associated as the old wpa_supplicant needed a network interface. However, this interface is only created when the driver is loaded with a module parameter p2pon set to 1.
So brcmfmac announces P2P_DEVICE support in wiphy information. This will cause wpa_supplicant (with P2P device patches) to create a *wireless_dev* interface of P2P_DEVICE type.
Quoted 4 lines
The "correct" way (the way I decided to implement this P2P device concept in the upstreamtree ) is to have a P2P device *wireless dev* which has no netdev associated -- this makes more sense since no data frames are ever transmitted or received on a P2P device.
True and I made additional patches on top of 3.9-rc1 that add support for creating the "correct" P2P device *wireless_dev* through user-space.
Quoted 5 lines
As I understand Arend, he was suggesting to put patches into 3.9 that would move brcmfmac from the interim API with a netdev he had used for testing to the final API that is actually implemented in 3.9 but before the
wpa_supplicantpatches had no way to get used. Now those patches are there inwpa_supplicantthough (or well, on their way in)
The interim patches went in 3.9-rc1 so they end up in 3.9 without nl80211 user-space support. I am now suggesting to add that nl80211 user-space support for 3.9 as well. As you indicated you do not consider this as an exception to the bugfix rule, I will have to look what happens when the new wpa_supplicant (with P2P device patches) tries to use the 3.9-rc1 brcmfmac.
Regards,
Arend
Quoted 8 lines · Arend van Spriel
Quoted 4 lines
As I understand it, brcmfmac currently supports having a P2P device *netdev*, which is of (wireless) type STATION (presumably), which isn't something we want to support (well, I don't anyway, it's difficult to discover for applications).
It is a bit more subtle. After the merge window since 3.9-rc1 brcmfmac supports to have a P2P device *wireless dev* WITH a netdev associated as the old
wpa_supplicantneeded a network interface.
Oh, funky, I had no idea.
Quoted 3 lines
However, this
interface is only created when the driver is loaded with a module parameter p2pon set to 1.
You could just remove the module parameter then?
Quoted 3 lines
So brcmfmac announces
P2P_DEVICEsupport in wiphy information. This will causewpa_supplicant(with P2P device patches) to create a *wireless_dev* interface ofP2P_DEVICEtype.
Right, but this wouldn't work because you don't support the interface creation, so it would really just be an attempt to create it?
Quoted 6 lines
The interim patches went in 3.9-rc1 so they end up in 3.9 without nl80211 user-space support. I am now suggesting to add that nl80211 user-space support for 3.9 as well. As you indicated you do not consider this as an exception to the bugfix rule, I will have to look what happens when the new
wpa_supplicant(with P2P device patches) tries to use the 3.9-rc1 brcmfmac.
Or you could just remove the module parameter *and* advertisting the P2P_DEVICE interface type, that would be a very small patch to "fix" the API by disabling it for that kernel version. OTOH, I'm not sure if that's a concern for you. For me, it wouldn't be a concern because we mostly use compat-wireless anyway, but your situation might be different.
johannes
Quoted 11 lines · Johannes Berg
Quoted 8 lines · Arend van Spriel
Quoted 4 lines
As I understand it, brcmfmac currently supports having a P2P device *netdev*, which is of (wireless) type STATION (presumably), which isn't something we want to support (well, I don't anyway, it's difficult to discover for applications).
It is a bit more subtle. After the merge window since 3.9-rc1 brcmfmac supports to have a P2P device *wireless dev* WITH a netdev associated as the old
wpa_supplicantneeded a network interface.
Quoted 8 lines
Oh, funky, I had no idea.
Quoted 3 lines
However, this
interface is only created when the driver is loaded with a module parameter p2pon set to 1.You could just remove the module parameter then?
It kind of depends what mix of kernel and wpa_supplicant an OEM or distro would select. There may be use-cases where they would need p2pon parameter to have P2P functionality.
Quoted 7 lines
Quoted 3 lines
So brcmfmac announces
P2P_DEVICEsupport in wiphy information. This will causewpa_supplicant(with P2P device patches) to create a *wireless_dev* interface ofP2P_DEVICEtype.Right, but this wouldn't work because you don't support the interface creation, so it would really just be an attempt to create it?
Sure. Just thought it would be better to avoid the attempt.
Quoted 7 lines
Quoted 6 lines
The interim patches went in 3.9-rc1 so they end up in 3.9 without nl80211 user-space support. I am now suggesting to add that nl80211 user-space support for 3.9 as well. As you indicated you do not consider this as an exception to the bugfix rule, I will have to look what happens when the new
wpa_supplicant(with P2P device patches) tries to use the 3.9-rc1 brcmfmac.
Quoted 6 lines
Or you could just remove the module parameter *and* advertisting the
P2P_DEVICEinterface type, that would be a very small patch to "fix" the API by disabling it for that kernel version. OTOH, I'm not sure if that's a concern for you. For me, it wouldn't be a concern because we mostly use compat-wireless anyway, but your situation might be different.
That is indeed what I guessed the patch should look like, which would make P2P unavailable for 3.9 regardless the wpa_supplicant version used. But indeed there is always compat-drivers aka. compat-wireless so I am not that concerned.
Gr. AvS
Quoted 9 lines · Arend van Spriel
Quoted 6 lines · Johannes Berg
Or you could just remove the module parameter *and* advertisting the
P2P_DEVICEinterface type, that would be a very small patch to "fix" the API by disabling it for that kernel version. OTOH, I'm not sure if that's a concern for you. For me, it wouldn't be a concern because we mostly use compat-wireless anyway, but your situation might be different.
Quoted 4 lines
That is indeed what I guessed the patch should look like, which would make P2P unavailable for 3.9 regardless the
wpa_supplicantversion used. But indeed there is always compat-drivers aka. compat-wireless so I am not that concerned.
I think this is the patch we need in order to avoid messy confusion later...
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.