Eric Lee / smarc-fsl-linux-kernel

12 Nov, 2011

1 commit

02 Jun, 2011

1 commit

13 May, 2011

1 commit

27 Jul, 2010

1 commit

12 Apr, 2010

1 commit

30 Mar, 2010

1 commit

  • 5a0e3ad6a   include cleanup: Update gfp.h and slab.h includes to prepare for breaking implic… ... Browse Code »

    …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

11 Mar, 2010

1 commit

17 Sep, 2009

1 commit

20 Aug, 2009

1 commit

  • bfc32e6a9   mac80211: Decouple fail_avg stats used by mesh from rate control algorithm. ... Browse Code »

    Mesh uses the tx failure average to compute the (m)path metric. This used to
    be done inside the rate control module. This patch breaks the dependency
    between the mesh stack and the rate control algorithm. Mesh will now work
    independently of the chosen rate control algorithm.

    The mesh stack keeps a moving average of the average transmission losses for
    each mesh peer station. If the fail average exceeds a certain threshold, the
    peer link is marked as broken.

    Signed-off-by: Javier Cardona
    Signed-off-by: John W. Linville

    Javier Cardona
     

14 Aug, 2009

2 commits

25 Jul, 2009

2 commits

  • 4c6d4f5c3   mac80211: add helper for management / no-ack frame rate decision ... Browse Code »

    All current rate control algorithms agree to send management and no-ack
    frames at the lowest rate. They also agree to do this when sta
    and the private rate control data is NULL. We add a hlper to mac80211
    for this and simplify the rate control algorithm code.

    Developers wishing to make enhancements to rate control algorithms
    are for broadcast/multicast can opt to not use this in their
    gate_rate() mac80211 callback.

    Cc: Zhu Yi
    Acked-by: Reinette Chatre
    Cc: ipw3945-devel@lists.sourceforge.net
    Cc: Gabor Juhos
    Acked-by: Felix Fietkau
    Cc: Derek Smithies
    Cc: Chittajit Mitra
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • e89864365   mac80211: make minstrel/pid RC use ieee80211_is_data(fc) ... Browse Code »

    Cc: Felix Fietkau
    Cc: Derek Smithies
    Cc: Chittajit Mitra
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     

08 Jul, 2009

1 commit

11 Jun, 2009

1 commit

  • 5ee58d7e6   mac80211: fix minstrel single-rate memory corruption ... Browse Code »

    The minstrel rate controller periodically looks up rate indexes in
    a sampling table. When accessing a specific row and column, minstrel
    correctly does a bounds check which, on the surface, appears to handle
    the case where mi->n_rates < 2. However, mi->sample_idx is actually
    defined as an unsigned, so the right hand side is taken to be a huge
    positive number when negative, and the check will always fail.

    Consequently, the RC will overrun the array and cause random memory
    corruption when communicating with a peer that has only a single rate.
    The max value of mi->sample_idx is around 25 so casting to int should
    have no ill effects.

    Without the change, uptime is a few minutes under load with an AP
    that has a single hard-coded rate, and both the AP and STA could
    potentially crash. With the change, both lasted 12 hours with a
    steady load.

    Thanks to Ognjen Maric for providing the single-rate clue so I could
    reproduce this.

    This fixes http://bugzilla.kernel.org/show_bug.cgi?id=12490 on the
    regression list (also http://bugzilla.kernel.org/show_bug.cgi?id=13000).

    Cc: stable@kernel.org
    Reported-by: Sergey S. Kostyliov
    Reported-by: Ognjen Maric
    Signed-off-by: Bob Copeland
    Signed-off-by: John W. Linville

    Bob Copeland
     

19 May, 2009

1 commit

12 May, 2009

1 commit

  • 621ad7c96   mac80211: avoid NULL ptr deref when finding max_rates in PID and minstrel ... Browse Code »

    "There is another problem with this piece of code. The sband will be NULL
    after second iteration on single band device and cause null pointer
    dereference. Everything is working with dual band card. Sorry, but i
    don't know how to explain this clearly in English. I have looked on the
    second patch for pid algorithm and found similar bug."

    Reported-by: Karol Szuster
    Signed-off-by: John W. Linville

    John W. Linville
     

09 May, 2009

1 commit

07 May, 2009

1 commit

05 May, 2009

1 commit

  • 8e5321752   mac80211: minstrel, fix memory corruption ... Browse Code »

    minstrel doesn't count max rate count in fact, since it doesn't use
    a loop variable `i' and hence allocs space only for bitrates found in
    the first band.

    Fix it by involving the `i' as an index so that it traverses all the
    bands now and finds the real max bitrate count.

    Signed-off-by: Jiri Slaby
    Cc: Felix Fietkau
    Signed-off-by: John W. Linville

    Jiri Slaby
     

13 Jan, 2009

1 commit

  • d57854bb1   minstrel: fix warning if lowest supported rate index is not 0 ... Browse Code »

    This patch fixes the following WARNING (caused by rix_to_ndx): "
    >WARNING: at net/mac80211/rc80211_minstrel.c:69 minstrel_rate_init+0xd2/0x33a [mac80211]()
    >[...]
    >Call Trace:
    > warn_on_slowpath+0x51/0x75
    > _format_mac_addr+0x4c/0x88
    > minstrel_rate_init+0xd2/0x33a [mac80211]
    > print_mac+0x16/0x1b
    > schedule_hrtimeout_range+0xdc/0x107
    > ieee80211_add_station+0x158/0x1bd [mac80211]
    > nl80211_new_station+0x1b3/0x20b [cfg80211]

    The reason is that I'm experimenting with "g" only mode on a 802.11 b/g card.

    Therefore rate_lowest_index returns 4 (= 6Mbit, instead of usual 0 = 1Mbit).
    Since mi->r array is initialized with zeros in minstrel_alloc_sta,
    rix_to_ndx has a hard time to find the 6Mbit entry and will trigged the WARNING.

    Signed-off-by: Christian Lamparter
    Acked-by: Felix Fietkau
    Signed-off-by: John W. Linville

    Christian Lamparter
     

11 Nov, 2008

1 commit

01 Nov, 2008

3 commits

  • 50fb2e457   mac80211: remove rate_control_clear ... Browse Code »

    "Clearing" the rate control algorithm is pointless, none of
    the algorithms actually uses this operation and it's not even
    invoked properly for all channel switching. Also, there's no
    need to since rate control algorithms work per station.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • f4a8cd94f   minstrel: improve performance for non-MRR drivers ... Browse Code »

    This patch enhances minstrel's performance for non-MRR setups,
    by preventing it from sampling slower rates with >95% success
    probability and by putting at least 1 non-sample frame between
    several sample frames.

    Signed-off-by: Felix Fietkau
    Signed-off-by: John W. Linville

    Felix Fietkau
     
  • e6a9854b0   mac80211/drivers: rewrite the rate control API ... Browse Code »

    So after the previous changes we were still unhappy with how
    convoluted the API is and decided to make things simpler for
    everybody. This completely changes the rate control API, now
    taking into account 802.11n with MCS rates and more control,
    most drivers don't support that though.

    Signed-off-by: Felix Fietkau
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

07 Oct, 2008

1 commit