Search Linux Wireless

Re: [RFC 0/3] of: add common bindings to (de)activate IEEE 802.11 bands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 2, 2016 at 5:50 PM, Martin Blumenstingl
<martin.blumenstingl@xxxxxxxxxxxxxx> wrote:
> There are at least two drivers (ath9k and mt76) out there, where
> devicetree authors need to override the enabled bands.
>
> For ath9k there is only one use-case: disabling a band which has been
> incorrectly enabled by the vendor in the EEPROM (enabling a band is not
> possible because the calibration data would be missing in the EEPROM).
> The mt76 driver (currently pending for review) however allows enabling
> and disabling the 2.4GHz and 5GHz band, see [0].
>
> Based on the discussion of (earlier versions of) my ath9k devicetree
> patch it was suggested [1] that we use enable- and disable- properties.
> The current patch implements:
> - bands can be enabled or disabled with the corresponding property
> - if both (disable and enable) properties are given and a driver asks
>   whether the band is enabled then the logic will return false (= not
>   enabled, preferring the disabled flag)
> - if both (disable and enable) properties are given and a driver asks
>   whether the band is disabled then the logic will return true (again,
>   preferring the disabled flag over the enabled flag)
>
> We can still change the logic to do what the mt76 driver does (I am
> fine with both solutions):
> - property not available: driver decides which bands to enable
> - property set to 0: disable the band
> - property set to 1: enable the band

I prefer this way. Really, I'd prefer just a boolean disable property.
I'm not sure why you need the enable. We usually have these tri-state
properties when you want not present to mean use the bootloader or
default setting. Try to make not present the most common case.

> The new code has been integrated into ath9k to demonstrate how to use
> it (with the benefit that the disable_2ghz and disable_5ghz settings
> from the ath9k_platform_data can now also be configured via .dts).
>
> open questions/decisions needed:
> - where to place this new code? I put it into drivers/of/of_ieee80211
>   because that's where most other functions live.
>   However, I found that this makes backporting the code harder (using
>   wireless-backports from the driver-backports project [2])

We are generally moving subsystem specific code like this out of
drivers/of/, so please do that here. Maybe someone will get motivated
to move the other networking code out too.

> - we need a decision whether we want to go with two flags for each
>   band (enable-ieee80211-band and disable-ieee80211-band) or if we
>   prefer the solution from the mt76 driver (which means that the
>   property for a band is absent for auto-detection, or
>   ieee80211-band-enabled = <0/1> is specified. we could also move
>   the 0 and 1 to a header file of course to make it easer to read,
>   such as IEEE80211_BAND_ENABLED and IEEE80211_BAND_DISABLED)

Please don't add defines for this. 0/1 meaning false/true is clear enough IMO.

Rob



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux