staging/wlan-ng: reflects NL80211 API change

In today linux-next I got a compile error in wlan-ng:

CC [M] drivers/staging/wlan-ng/p80211netdev.o
In file included from drivers/staging/wlan-ng/p80211netdev.c:91:
drivers/staging/wlan-ng/cfg80211.c:602: warning: ‘enum tx_power_setting’ declared inside parameter list drivers/staging/wlan-ng/cfg80211.c:602: warning: its scope is only this definition or declaration, which is probably not what you want drivers/staging/wlan-ng/cfg80211.c:602: error: parameter 2 (‘type’) has incomplete type drivers/staging/wlan-ng/cfg80211.c: In function ‘prism2_set_tx_power’:
drivers/staging/wlan-ng/cfg80211.c:609: error: ‘TX_POWER_AUTOMATIC’ undeclared (first use in this function) drivers/staging/wlan-ng/cfg80211.c:609: error: (Each undeclared identifier is reported only once drivers/staging/wlan-ng/cfg80211.c:609: error: for each function it appears in.)
make[1]: *** [drivers/staging/wlan-ng/p80211netdev.o] Error 1
make: *** [_module_drivers/staging/wlan-ng] Error 2

The problem is that the 802.11 netlink interface changed and the driver was not updated

Current patch solves the issue

Best regards,

---
 drivers/staging/wlan-ng/cfg80211.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

index b0792f7..9803b28 100644
@@ -599,14 +599,14 @@ int prism2_leave_ibss(struct wiphy *wiphy, struct net_device *dev) {
 
 
 int prism2_set_tx_power(struct wiphy *wiphy,
-			enum tx_power_setting type, int dbm) {
+			enum nl80211_tx_power_setting type, int dbm) {
 	struct prism2_wiphy_private *priv = wiphy_priv(wiphy);
 	wlandevice_t *wlandev = priv->wlandev;
 	u32 data;
 	int result;
 	int err = 0;
 
-	if (type = TX_POWER_AUTOMATIC)
+	if (type = NL80211_TX_POWER_AUTOMATIC)
 		data = 30;
 	else
 		data = dbm;

1.7.0.4

This needs to go through the wireless tree, care to send it there? It just caused a build error in my tree if I was to take it :(

thanks,

greg k-h

Greg,

I look at wireless-next-2.6 and wireless-testing, none of them have the same wlan-ng driver version that linux-next has.

I have seen this situation many times:

1- Someone change and API in a subsystem tree (wirless, pcmcia, block, etc). 2- linux-next tree pull these API changes.
3- The other trees doesn't have the last (or at least the same) driver version that linux-next has.
4- Due the API change the drivers doesn't compile anymore. Both trees compile cleanly separate but when they got merged, problems arises.

Because it is an API change, I'm told to send patches through subsystem trees. But I can't do that because that trees doesn't have the same driver version as linux-next has.

Please tell me how do I have to proceed in these situations. Or tell me if there is a special integration tree for staging (besides linux-next) that I can use to generate my patches against.

Thanks a lot for your help and best regards,

-----------------------------------------
Javier Martínez Canillas
+595 981 88 66 58

Hm, you're right, it's a mess :)

I'll just keep this patch in my "to-apply" queue and watch for the api change to hit Linus's tree and then queue it up to him when needed.

Sound good?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Yes thats good for me. Thank you very much.

Best regards,

-----------------------------------------
Javier Martínez Canillas
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html