summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mac80211: remove doubled semicolonJohannes Berg2015-01-161-1/+1
| | | | Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: change bandwidth reporting to explicit fieldJohannes Berg2015-01-158-50/+125
| | | | | | | | | | | | | | | | | | For some reason, we made the bandwidth separate flags, which is rather confusing - a single rate cannot have different bandwidths at the same time. Change this to no longer be flags but use a separate field for the bandwidth ('bw') instead. While at it, add support for 5 and 10 MHz rates - these are reported as regular legacy rates with their real bitrate, but tagged as 5/10 now to make it easier to distinguish them. In the nl80211 API, the flags are preserved, but the code now can also clearly only set a single one of the flags. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove 80+80 MHz rate reportingJohannes Berg2015-01-154-11/+6
| | | | | | | | | | | These rates are treated the same as 160 MHz in the spec, so it makes no sense to distinguish them. As no driver uses them yet, this is also not a problem, just remove them. In the userspace API the field remains reserved to preserve API and ABI. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove 80+80 MHz rate reportingJohannes Berg2015-01-154-13/+2
| | | | | | | | | These rates are treated the same as 160 MHz in the spec, so it makes no sense to distinguish them. As no driver uses them yet, this is also not a problem, just remove them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: docs: remove station_info_flagsJohannes Berg2015-01-141-1/+0
| | | | | | | I removed the enum earlier, but forgot to remove it from the documentation - do that now. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* nl80211: send netdetect configuration info in NL80211_CMD_GET_WOWLANLuciano Coelho2015-01-142-1/+55
| | | | | | | | | | | | Send the netdetect configuration information in the response to NL8021_CMD_GET_WOWLAN commands. This includes the scan interval, SSIDs to match and frequencies to scan. Additionally, add the NL80211_WOWLAN_TRIG_NET_DETECT with NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: avoid reg-hints in self-managed only systemsArik Nemtsov2015-01-141-0/+25
| | | | | | | | | | | | | | | When a system contains only self-managed regulatory devices all hints from the regulatory core are ignored. Stop hint processing early in this case. These systems usually don't have CRDA deployed, which results in endless (irrelevent) logs of the form: cfg80211: Calling CRDA to update world regulatory domain Make sure there's at least one self-managed device before discarding a hint, in order to prevent initial hints from disappearing on CRDA managed systems. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: introduce sync regdom set API for self-managedArik Nemtsov2015-01-142-2/+43
| | | | | | | | | | | A self-managed device will sometimes need to set its regdomain synchronously. Notably it should be set before usermode has a chance to query it. Expose a new API to accomplish this which requires the RTNL. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: don't defer scans in case of radar detectionEliad Peller2015-01-141-1/+1
| | | | | | | | | Radar detection can last indefinite time. There is no point in deferring a scan request in this case - simply return -EBUSY. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: consider only relevant vifs for radar_required calculationEliad Peller2015-01-141-2/+30
| | | | | | | | | | | | ctx->conf.radar_enabled should reflect whether radar detection is enabled for the channel context. When calculating it, make it consider only the vifs that have this context assigned (instead of all the vifs). Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove local->radar_detect_enabledEliad Peller2015-01-144-7/+5
| | | | | | | | | | | | | | | | | | | local->radar_detect_enabled should tell whether radar_detect is enabled on any interface belonging to local. However, it's not getting updated correctly in many cases (actually, when testing with hwsim it's never been set, even when the dfs master is beaconing). Instead of handling all the corner cases (e.g. channel switch), simply check whether radar detection is enabled only when needed, instead of caching the result. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add TDLS supported channels correctlyArik Nemtsov2015-01-141-5/+21
| | | | | | | | | | | | | | | The function adding the supported channels IE during a TDLS connection had several issues: 1. If the entire subband is usable, the function exitted the loop without adding it 2. The function only checked chandef_usable, ignoring flags like RADAR which would prevent TDLS off-channel communcation. 3. HT20 was explicitly required in the chandef, while not a requirement for TDLS off-channel. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: let flush() drop packets when possibleEmmanuel Grumbach2015-01-1410-22/+27
| | | | | | | | | | | | | | | | When roaming / suspending, it makes no sense to wait until the transmit queues of the device are empty. In extreme condition they can be starved (VO saturating the air), but even in regular cases, it is pointless to delay the roaming because the low level driver is trying to send packets to an AP which is far away. We'd rather drop these packets and let TCP retransmit if needed. This will allow to speed up the roaming. For suspend, the explanation is even more trivial. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* rfkill: document rfkill module parametersAndrew Clausen2015-01-092-0/+15
| | | | | | | | | Document the rfkill module parameters default_state and master_switch_mode. Signed-off-by: Andrew Clausen <andrew.p.clausen@gmail.com> [rewrite commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix handling TIM IE when stations disconnectJohannes Berg2015-01-091-3/+13
| | | | | | | | | | | | | | | | | | | | | When a station disconnects with frames still pending, we clear the TIM bit, but too late - it's only cleared when the station is already removed from the driver, and thus the driver can get confused (and hwsim will loudly complain.) Fix this by clearing the TIM bit earlier, when the station has been unlinked but not removed from the driver yet. To do this, refactor the TIM recalculation to in that case ignore traffic and simply assume no pending traffic - this is correct for the disconnected station even though the frames haven't been freed yet at that point. This patch isn't needed for current drivers though as they don't check the station argument to the set_tim() operation and thus don't really run into the possible confusion. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211_hwsim: fix PS debugfs file lockingJohannes Berg2015-01-091-11/+11
| | | | | | | | The functions called within the iterators must be called with tasklets disabled, so use atomic iteration like the rest of the code and disable tasklets around the whole operation. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: provide per-TID RX/TX MSDU countersJohannes Berg2015-01-085-2/+68
| | | | | | | | | Implement the new counters cfg80211 can now advertise to userspace. The TX code is in the sequence number handler, which is a bit odd, but that place already knows the TID and frame type, so it was easiest and least impact there. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* nl80211: support per-TID station statisticsJohannes Berg2015-01-083-0/+93
| | | | | | | | | | | | | | | | | The base for the current statistics is pretty mixed up, support exporting RX/TX statistics for MSDUs per TID. This (currently) covers received MSDUs, transmitted MSDUs and retries/failures thereof. Doing it per TID for MSDUs makes more sense than say only per AC because it's symmetric - we could export per-AC statistics for all frames (which AC we used for transmission can be determined also for management frames) but per TID is better and usually data frames are really the ones we care about. Also, on RX we can't determine the AC - but we do know the TID for any QoS MPDU we received. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* nl80211: clarify packet statistics descriptionsJohannes Berg2015-01-082-15/+21
| | | | | | | | The current statistics we keep aren't very clear, some are on MPDUs and some on MSDUs/MMPDUs. Clarify the descriptions based on the counters mac80211 keeps. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: add nl80211 beacon-only statisticsJohannes Berg2015-01-083-0/+13
| | | | | | | | | | Add these two values: * BEACON_RX: number of beacons received from this peer * BEACON_SIGNAL_AVG: signal strength average for beacons only These can then be used for Android Lollipop's statistics request. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove enum station_info_flagsJohannes Berg2015-01-0818-254/+142
| | | | | | | | | | | | | | This is really just duplicating the list of information that's already available in the nl80211 attribute, so remove the list. Two small changes are needed: * remove STATION_INFO_ASSOC_REQ_IES complete, but the length (assoc_req_ies_len) can be used instead * add NL80211_STA_INFO_RX_DROP_MISC which exists internally but not in nl80211 yet This gets rid of the duplicate maintenance of the two lists. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow drivers to provide most station statisticsJohannes Berg2015-01-085-87/+110
| | | | | | | | | | | | | | | | | | | In many cases, drivers can filter things like beacons that will skew statistics reported by mac80211. To get correct statistics in these cases, call drivers to obtain statistics and let them override all values, filling values from mac80211 if the driver didn't provide them. Not all of them make sense for the driver to fill, so some are still always done by mac80211. Note that this doesn't currently allow a driver to say "I know this value is wrong, don't report it at all", or to sum it up with a mac80211 value (as could be useful for "dropped misc"), that can be added if it turns out to be needed. This also gets rid of the get_rssi() method as is can now be implemented using sta_statistics(). Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: send statistics with delete station eventJohannes Berg2015-01-081-1/+3
| | | | | | | | | Use the new cfg80211_del_sta_sinfo() function to send the statistics about the deleted station with the delete event. This lets userspace see how much traffic etc. the deleted station used. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: allow including station info in delete eventJohannes Berg2015-01-082-23/+31
| | | | | | | | | | | | | When a station is removed, its statistics may be interesting to userspace, for example for further aggregation of statistics of all stations that ever connected to an AP. Introduce a new cfg80211_del_sta_sinfo() function (and make the cfg80211_del_sta() a static inline calling it) to allow passing a struct station_info along with this, and send the data in the nl80211 event message. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: add scan time to survey dataJohannes Berg2015-01-084-2/+16
| | | | | | | Add the time spent scanning to the survey data so it can be reported by drivers that collect such information. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: allow survey data to return global dataJohannes Berg2015-01-083-17/+33
| | | | | | | | | Not all devices are able to report survey data (particularly time spent for various operations) per channel. As all these statistics already exist in survey data, allow such devices to report them (if userspace requested it) Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove "channel" from survey namesJohannes Berg2015-01-0816-127/+135
| | | | | | | | | All of the survey data is (currently) per channel anyway, so having the word "channel" in the name does nothing. In the next patch I'll introduce global data to the survey, where the word "channel" is actually confusing. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Re-fix accounting of the tailroom-needed counterIdo Yariv2015-01-074-9/+16
| | | | | | | | | | | | | | | | | | | | | When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags only require headroom space. Therefore, the tailroom-needed counter can safely be decremented for most drivers. The older incarnation of this patch (ca34e3b5) assumed that the above holds true for all drivers. As reported by Christopher Chavez and researched by Christian Lamparter and Larry Finger, this isn't a valid assumption for p54 and cw1200. Drivers that still require tailroom for ICV/MIC even when HW encryption is enabled can use IEEE80211_KEY_FLAG_RESERVE_TAILROOM to indicate it. Signed-off-by: Ido Yariv <idox.yariv@intel.com> Cc: Christopher Chavez <chrischavez@gmx.us> Cc: Christian Lamparter <chunkeey@googlemail.com> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Solomon Peachy <pizza@shaftnet.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge branch 'mac80211' into mac80211-nextJohannes Berg2015-01-0728-220/+348
|\ | | | | | | | | | | | | Merge mac80211.git to get some changes that would otherwise cause conflicts with new changes coming here. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * Revert "mac80211: Fix accounting of the tailroom-needed counter"Johannes Berg2015-01-052-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit ca34e3b5c808385b175650605faa29e71e91991b. It turns out that the p54 and cw2100 drivers assume that there's tailroom even when they don't say they really need it. However, there's currently no way for them to explicitly say they do need it, so for now revert this. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=90331. Cc: stable@vger.kernel.org Fixes: ca34e3b5c808 ("mac80211: Fix accounting of the tailroom-needed counter") Reported-by: Christopher Chavez <chrischavez@gmx.us> Bisected-by: Larry Finger <Larry.Finger@lwfinger.net> Debugged-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: free management frame keys when removing stationJohannes Berg2014-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | When writing the code to allow per-station GTKs, I neglected to take into account the management frame keys (index 4 and 5) when freeing the station and only added code to free the first four data frame keys. Fix this by iterating the array of keys over the right length. Cc: stable@vger.kernel.org Fixes: e31b82136d1a ("cfg80211/mac80211: allow per-station GTKs") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: correctly check ad-hoc channelsArik Nemtsov2014-12-121-1/+7
| | | | | | | | | | | | | | | | | | Ad-hoc requires beaconing for regulatory purposes. Validate that the channel is valid for beaconing, and not only enabled. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: don't WARN about two consecutive Country IE hintEmmanuel Grumbach2014-12-121-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can happen and there is no point in added more detection code lower in the stack. Catching these in one single point (cfg80211) is enough. Stop WARNING about this case. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=89001 Cc: stable@vger.kernel.org Fixes: 2f1c6c572d7b ("cfg80211: process non country IE conflicting first") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: update the channel context after channel switchEmmanuel Grumbach2014-12-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the channel switch has been made, a vif is now using the channel context which was reserved. When that happens, we need to update the channel context since its parameters may change. I hit a case in which I switched to a 40Mhz channel but the reserved channel context was still on 20Mhz. The rate control would try to send 40Mhz packets on a 20Mhz channel context and that made iwlwifi's firmware unhappy. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * nl80211: check matches array length before acessing itLuciano Coelho2014-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the userspace passes a malformed sched scan request (or a net detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH attribute without any nested matchsets, a NULL pointer dereference will occur. Fix this by checking that we do have matchsets in our array before trying to access it. BUG: unable to handle kernel NULL pointer dereference at 0000000000000024 IP: [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] PGD 865c067 PUD 865b067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat] CPU: 2 PID: 2442 Comm: iw Tainted: G O 3.17.2 #31 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000 RIP: 0010:[<ffffffffa002fd69>] [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] RSP: 0018:ffff880008d838d0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0 RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019 R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00 R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388 FS: 00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0 Stack: ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0 0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948 ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000 Call Trace: [<ffffffff814689c9>] ? nla_parse+0xb9/0x120 [<ffffffffa00306de>] nl80211_set_wowlan+0x75e/0x960 [cfg80211] [<ffffffff810bf3d5>] ? mark_held_locks+0x75/0xa0 [<ffffffff8161a77b>] genl_family_rcv_msg+0x18b/0x360 [<ffffffff810bf66d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8161a9d4>] genl_rcv_msg+0x84/0xc0 [<ffffffff8161a950>] ? genl_family_rcv_msg+0x360/0x360 [<ffffffff81618e79>] netlink_rcv_skb+0xa9/0xd0 [<ffffffff81619458>] genl_rcv+0x28/0x40 [<ffffffff816184a5>] netlink_unicast+0x105/0x180 [<ffffffff8161886f>] netlink_sendmsg+0x34f/0x7a0 [<ffffffff8105a097>] ? kvm_clock_read+0x27/0x40 [<ffffffff815c644d>] sock_sendmsg+0x8d/0xc0 [<ffffffff811a75c9>] ? might_fault+0xb9/0xc0 [<ffffffff811a756e>] ? might_fault+0x5e/0xc0 [<ffffffff815d5d26>] ? verify_iovec+0x56/0xe0 [<ffffffff815c73e0>] ___sys_sendmsg+0x3d0/0x3e0 [<ffffffff810a7be8>] ? sched_clock_cpu+0x98/0xd0 [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580 [<ffffffff810bb39f>] ? up_read+0x1f/0x40 [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580 [<ffffffff812146ed>] ? __fget_light+0x13d/0x160 [<ffffffff815c7b02>] __sys_sendmsg+0x42/0x80 [<ffffffff815c7b52>] SyS_sendmsg+0x12/0x20 [<ffffffff81751f69>] system_call_fastpath+0x16/0x1b Fixes: ea73cbce4e1f ("nl80211: fix scheduled scan RSSI matchset attribute confusion") Cc: stable@vger.kernel.org [3.15+] Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: avoid mem leak on driver hint setArik Nemtsov2014-12-121-1/+4
| | | | | | | | | | | | | | | | | | | | | | In the already-set and intersect case of a driver-hint, the previous wiphy regdomain was not freed before being reset with a copy of the cfg80211 regdomain. Cc: stable@vger.kernel.org Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Acked-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * cfg80211: Fix 160 MHz channels with 80+80 and 160 MHz driversJouni Malinen2014-12-121-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The VHT supported channel width field is a two bit integer, not a bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and ended up rejecting 160 MHz channel width if the driver indicated support for both 160 and 80+80 MHz channels. Cc: stable@vger.kernel.org (3.16+) Fixes: 3d9d1d6656a73 ("nl80211/cfg80211: support VHT channel configuration") (however, no real drivers had 160 MHz support it until 3.16) Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: fix multicast LED blinking and counterAndreas Müller2014-12-121-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount" stopped being incremented after the use-after-free fix. Furthermore, the RX-LED will be triggered by every multicast frame (which wouldn't happen before) which wouldn't allow the LED to rest at all. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the patch. Cc: stable@vger.kernel.org Fixes: b8fff407a180 ("mac80211: fix use-after-free in defragmentation") Signed-off-by: Andreas Müller <goo@stapelspeicher.org> [rewrite commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * mac80211: avoid using uninitialized stack dataJes Sorensen2014-12-121-0/+1
| | | | | | | | | | | | | | | | | | | | Avoid a case where we would access uninitialized stack data if the AP advertises HT support without 40MHz channel support. Cc: stable@vger.kernel.org Fixes: f3000e1b43f1 ("mac80211: fix broken use of VHT/20Mhz with some APs") Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * r8169:update rtl8168g pcie ephy parameterChun-Hao Lin2014-12-111-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add ephy parameter to rtl8168g. Also change the common function of rtl8168g from "rtl_hw_start_8168g_1" to "rtl_hw_start_8168g". And function "rtl_hw_start_8168g_1" is used for setting rtl8168g hardware parameters. Following is the explanation of what hardware parameter change for. rtl8168g may erroneous judge the PCIe signal quality and show the error bit on PCI configuration space when in PCIe low power mode. The following ephy parameters are for above issue. { 0x00, 0x0000, 0x0008 } { 0x0c, 0x37d0, 0x0820 } { 0x1e, 0x0000, 0x0001 } rtl8168g may return to PCIe L0 from PCIe L0s low power mode too slow. The following ephy parameter is for above issue. { 0x19, 0x8000, 0x0000 } Signed-off-by: Chunhao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: dsa: bcm_sf2: force link for all fixed PHY devicesFlorian Fainelli2014-12-111-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For ports of the switch that we define as "fixed PHYs" such as MoCA, we would have our Port 7 special handling that would allow us to assert the link status indication. For other ports, such as e.g: RGMII_1 connected to a cable modem, we would rely on whatever the bootloader has left configured, which is a bad assumption to make, we really need to force the link status indication here. Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge branch 'dma_mb'David S. Miller2014-12-1118-179/+258
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Alexander Duyck says: ==================== arch: Add lightweight memory barriers for coherent memory access These patches introduce two new primitives for synchronizing cache coherent memory writes and reads. These two new primitives are: dma_rmb() dma_wmb() The first patch cleans up some unnecessary overhead related to the definition of read_barrier_depends, smp_read_barrier_depends, and comments related to the barrier. The second patch adds the primitives for the applicable architectures and asm-generic. The third patch adds the barriers to r8169 which turns out to be a good example of where the new barriers might be useful as they have full rmb()/wmb() barriers ordering accesses to the descriptors and the DescOwn bit. The fourth patch adds support for coherent_rmb() to the Intel fm10k, igb, and ixgbe drivers. Testing with the ixgbe driver has shown a processing time reduction of at least 7ns per 64B frame on a Core i7-4930K. This patch series is essentially the v7 for: v4-7: Add lightweight memory barriers for coherent memory access v3: Add lightweight memory barriers fast_rmb() and fast_wmb() v2: Introduce load_acquire() and store_release() v1: Introduce read_acquire() The key changes in this patch series versus the earlier patches are: v7 resubmit: - Added Acked-by: Ben Herrenschmidt from v5 to dma_rmb/wmb patch - No code changes from previous set, still applies cleanly and builds. v7: - Dropped test/debug patch that was accidentally slipped in v6: - Replaced "memory based device I/O" with "consistent memory" in docs - Added reference to DMA-API.txt to explain consistent memory v5: - Renamed barriers dma_rmb and dma_wmb - Undid smp_wmb changes in x86 and PowerPC - Defined smp_rmb as __lwsync for SMP case on PowerPC v4: - Renamed barriers coherent_rmb and coherent_wmb - Added smp_lwsync for use in smp_load_acquire/smp_store_release v3: - Moved away from acquire()/store() and instead focused on barriers - Added cleanup of read_barrier_depends - Added change in r8169 to fix cur_tx/DescOwn ordering - Simplified changes to just replacing/moving barriers in r8169 - Added update to documentation with code example v2: - Renamed read_acquire() to be consistent with smp_load_acquire() - Changed barrier used to be consistent with smp_load_acquire() - Updated PowerPC code to use __lwsync based on IBM article - Added store_release() as this is a viable use case for drivers - Added r8169 patch which is able to fully use primitives - Added fm10k/igb/ixgbe patch which is able to test performance ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| | * fm10k/igb/ixgbe: Use dma_rmb on Rx descriptor readsAlexander Duyck2014-12-113-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change makes it so that dma_rmb is used when reading the Rx descriptor. The advantage of dma_rmb is that it allows for a much lower cost barrier on x86, powerpc, arm, and arm64 architectures than a traditional memory barrier when dealing with reads that only have to synchronize to coherent memory. In addition I have updated the code so that it just checks to see if any bits have been set instead of just the DD bit since the DD bit will always be set as a part of a descriptor write-back so we just need to check for a non-zero value being present at that memory location rather than just checking for any specific bit. This allows the code itself to appear much cleaner and allows the compiler more room to optimize. Cc: Matthew Vick <matthew.vick@intel.com> Cc: Don Skidmore <donald.c.skidmore@intel.com> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| | * r8169: Use dma_rmb() and dma_wmb() for DescOwn checksAlexander Duyck2014-12-111-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The r8169 use a pair of wmb() calls when setting up the descriptor rings. The first is to synchronize the descriptor data with the descriptor status, and the second is to synchronize the descriptor status with the use of the MMIO doorbell to notify the device that descriptors are ready. This can come at a heavy price on some systems, and is not really necessary on systems such as x86 as a simple barrier() would suffice to order store/store accesses. As such we can replace the first memory barrier with dma_wmb() to reduce the cost for these accesses. In addition the r8169 uses a rmb() to prevent compiler optimization in the cleanup paths, however by moving the barrier down a few lines and replacing it with a dma_rmb() we should be able to use it to guarantee descriptor accesses do not occur until the device has updated the DescOwn bit from its end. One last change I made is to move the update of cur_tx in the xmit path to after the wmb. This way we can guarantee the device and all CPUs should see the DescOwn update before they see the cur_tx value update. Cc: Realtek linux nic maintainers <nic_swsd@realtek.com> Cc: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| | * arch: Add lightweight memory barriers dma_rmb() and dma_wmb()Alexander Duyck2014-12-1112-26/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a number of situations where the mandatory barriers rmb() and wmb() are used to order memory/memory operations in the device drivers and those barriers are much heavier than they actually need to be. For example in the case of PowerPC wmb() calls the heavy-weight sync instruction when for coherent memory operations all that is really needed is an lsync or eieio instruction. This commit adds a coherent only version of the mandatory memory barriers rmb() and wmb(). In most cases this should result in the barrier being the same as the SMP barriers for the SMP case, however in some cases we use a barrier that is somewhere in between rmb() and smp_rmb(). For example on ARM the rmb barriers break down as follows: Barrier Call Explanation --------- -------- ---------------------------------- rmb() dsb() Data synchronization barrier - system dma_rmb() dmb(osh) data memory barrier - outer sharable smp_rmb() dmb(ish) data memory barrier - inner sharable These new barriers are not as safe as the standard rmb() and wmb(). Specifically they do not guarantee ordering between coherent and incoherent memories. The primary use case for these would be to enforce ordering of reads and writes when accessing coherent memory that is shared between the CPU and a device. It may also be noted that there is no dma_mb(). Most architectures don't provide a good mechanism for performing a coherent only full barrier without resorting to the same mechanism used in mb(). As such there isn't much to be gained in trying to define such a function. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: Michael Ellerman <michael@ellerman.id.au> Cc: Michael Neuling <mikey@neuling.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: David Miller <davem@davemloft.net> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| | * arch: Cleanup read_barrier_depends() and commentsAlexander Duyck2014-12-1110-135/+129
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is meant to cleanup the handling of read_barrier_depends and smp_read_barrier_depends. In multiple spots in the kernel headers read_barrier_depends is defined as "do {} while (0)", however we then go into the SMP vs non-SMP sections and have the SMP version reference read_barrier_depends, and the non-SMP define it as yet another empty do/while. With this commit I went through and cleaned out the duplicate definitions and reduced the number of definitions down to 2 per header. In addition I moved the 50 line comments for the macro from the x86 and mips headers that defined it as an empty do/while to those that were actually defining the macro, alpha and blackfin. Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * Merge branch 'dsa'David S. Miller2014-12-111-3/+13
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Florian Fainelli says: ==================== net: dsa: two small bug fixes Here are two small fixes for the DSA slave interface creation code: - first patch fixes a null pointer de-reference with an invalid PHY device pointer while calling phy_connect_direct() - second path propagates the dsa_slave_phy_setup() error code down to its caller: dsa_slave_create ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| | * net: dsa: propagate error code from dsa_slave_phy_setupFlorian Fainelli2014-12-111-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case we cannot attach to our slave netdevice PHY, error out and propagate that error up to the caller: dsa_slave_create(). Fixes: 0d8bcdd383b8 ("net: dsa: allow for more complex PHY setups") Signed-off-by: Andrey Volkov <andrey.volkov@nexvision.fr> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| | * net: dsa: handle non-existing PHYs on switch internal busFlorian Fainelli2014-12-111-0/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case there is no PHY at the designated address on the internal switch, we would basically de-reference a null pointer here: dsa_slave_phy_setup(...) { p->phy = ds->slave_mii_bus->phy_map[p->port]; phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link, ^------ This can be triggered when the platform configuration (platform_data or Device Tree) indicates there should be a PHY device at this address, but the HW is non-responsive, such that we cannot attach a PHY device at this specific location. Fix this by checking the return value prior to calling phy_connect_direct(). CC: Andrew Lunn <andrew@lunn.ch> Fixes: b31f65fb4383 ("net: dsa: slave: Fix autoneg for phys on switch MDIO bus") Reported-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Andrey Volkov <andrey.volkov@nexvision.fr> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | mac80211: skip disabled channels in VHT checkArik Nemtsov2015-01-061-4/+6
| | | | | | | | | | | | | | | | | | The patch "40a11ca mac80211: check if channels allow 80 MHz for VHT probe requests" considered disabled channels as VHT enabled, and mistakenly sent out probe-requests with the VHT IE. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
OpenPOWER on IntegriCloud