On 31 May 2016 at 15:14, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2016-05-31 at 15:10 +0200, Rafał Miłecki wrote: > >> > Unfortunately, I get compiler warnings about width_* being possibly >> > used uninitialized. Can you address that please? >> It's nice your compiled got this mistake, my didn't. There were >> actually meant to be static. I'll fix that. > > I actually think the compiler is wrong, and there's no reason for them > to be static, is there? > > The first iteration of the loop should always initialize since -1 is > used for initialization? > > In any case, I'd prefer to avoid static, if necessary pass some kind of > context structure in to the function? I don't know if we can assume getting all three attributes: NL80211_BAND_ATTR_HT_CAPA NL80211_BAND_ATTR_VHT_CAPA NL80211_BAND_ATTR_FREQS at the same single handler call. I guess not. That's why I believe we need all width_* to be static, so they keep value across separated handler calls. >> > > +TOPLEVEL(channels, NULL, NL80211_CMD_GET_WIPHY, 0, CIB_PHY, >> > > handle_channels, "Show available channels."); >> > Maybe that should be allowed for a CIB_DEV too? >> Since this is PHY specific, I was thinking it should be CIB_PHY. I >> didn't see reason to allow querying devices. Similarly we don't >> support "iw dev wlan0 reg get". >> >> Anyway, I can change that if you think it's better for some reason. > > I was just thinking that supporting it with wlan0 would in certain > cases make it easier for the user (not having to look up the phy > number) > >> Any hint how to make command usable with both: phy and dev? > > Just add: > > TOPLEVEL(channels, NULL, NL80211_CMD_GET_WIPHY, 0, CIB_NETDEV, ...); But this will disallow using "iw phy phy0 channels". I'd prefer to have this one working in the first place and having "iw dev wlan0 channels" as an alternative. Is there a way to achieve that easily? -- Rafał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
