[rt2x00-users] rt2x00 patches from OpenWrt.org

Felix Fietkau nbd at nbd.name
Thu Nov 29 01:56:33 AEDT 2012


On 26.11.2012, at 16:32, Stanislaw Gruszka <sgruszka at redhat.com> wrote:

> Hi
> 
> On Sun, Nov 25, 2012 at 01:33:20PM +0200, Daniel Golle wrote:
>> We got a few patches for rt2x00 lurking around here which are needed for SoC
>> support:
>> 
>> https://dev.openwrt.org/browser/trunk/package/mac80211/patches/
>> 
>> 600-rt2x00-disable-pci-code-if-CONFIG_PCI-not-defined.patch
>> 601-rt2x00-set_pci_mwi.patch
>> 602-rt2x00-introduce-rt2x00_platform_h.patch
>> 603-rt2x00-introduce-rt2x00eeprom.patch
>> 604-rt2x00-add-CONFIG_RT2X00_LIB_EEPROM-option.patch
>> 605-rt2x00-pci-eeprom.patch
>> 606-rt2x00_no_realign.patch
>> 607-rt2x00-allow_disabling_bands_through_platform_data.patch
>> 608-add_platform_data_mac_addr.patch
>> 
>> 
>> Should I import them to wireless-testing and post them as a series on
>> rt2x00-users?
> 
> That would be great IMHO.
> 
>> I'm asking as the detection of 20MHz instead of 40MHz clock rate on Rt3352
>> (and Rt5350 in future) requires rt2x00_platform.h, see
>> 623-rt2x00-rf_vals-rt3352-xtal20.patch
>> 
>> Besides MediaTek/RaLink SoCs, rt2x00_platform.h will also be also used by
>> lantiq and bcm63xx boards which got MediaTek/RaLink WiFi modules, so importing
>> it at this point makes sense also without arch/mips/ralink being ready to go
>> upstream, see
>> https://dev.openwrt.org/browser/trunk/target/linux/brcm63xx/patches-3.6/446-BCM63XX-add-a-fixup-for-rt2x00-devices.patch
>> and
>> https://dev.openwrt.org/browser/trunk/target/linux/lantiq/files-3.3/arch/mips/lantiq/xway/dev-wifi-rt2x00.c
> 
> I think, I prefer module options instead of platform_data. Those can be
> specified by /etc/modprobe.d/file (or /etc/modprobe.conf) or by kernel
> command line parameters in bootloader, for example:
> 
> rt2x00lib.disable_5ghz=1 rt2800pci.eeprom_file=1
> 
> But, module options are limited to one device, so if there is or will be
> possible to have two or more rt2x00 devices on one system with different
> options, platform data should be used.
I strongly disagree. Using module parameters for this sounds like an ugly hack to me, and having multiple devices running the same driver is not uncommon either. 
These options are defined for specific devices via platform code and will most likely be changed to device tree in the future. They are not meant to be configured by the user or the boot loader.

- Felix



More information about the users mailing list