summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-03-19resources: Set type in __request_region()Bjorn Helgaas
We don't set the type (I/O, memory, etc.) of resources added by __request_region(), which leads to confusing messages like this: address space collision: [io 0x1000-0x107f] conflicts with ACPI CPU throttle [??? 0x00001010-0x00001015 flags 0x80000000] Set the type of a new resource added by __request_region() (used by request_region() and request_mem_region()) to the type of its parent. This makes the resource tree internally consistent and fixes messages like the above, where the ACPI CPU throttle resource really is an I/O port region, but request_region() didn't fill in the type, so %pR didn't know how to print it. Sample dmesg showing the issue at the link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611 Reported-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-19PCI: Don't check resource_size() in pci_bus_alloc_resource()Bjorn Helgaas
Paul reported that after f75b99d5a77d ("PCI: Enforce bus address limits in resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not set), intel-gtt complained "can't ioremap flush page - no chipset flushing". In addition, other PCI resource allocations, e.g., for bridge windows, failed. This happens because we incorrectly skip bus resources of [mem 0x00000000-0xffffffff] because we think they are of size zero. When resource_size_t is 32 bits wide, resource_size() on [mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1) overflows. Therefore, we can't use "resource_size() == 0" to decide that allocation from this resource will fail. allocate_resource() should fail anyway if it can't satisfy the address constraints, so we should just depend on that. A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid, but we do fall back to it as a default when we don't have information about host bridge apertures. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611 Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation Reported-and-tested-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-19s390/PCI: Use generic pci_enable_resources()Bjorn Helgaas
The generic pci_enable_resources() does essentially the same thing as the code in the s390 version of pcibios_enable_device(). There are differences, but I don't think any of them are a problem. The generic code: - Checks everything up to PCI_NUM_RESOURCES, not PCI_BAR_COUNT (6), so we'll now check the ROM resource, IOV resources, and bridge windows. - Checks for res->flags & IORESOURCE_UNSET. The s390 code never sets IORESOURCE_UNSET, so this isn't a problem. - Checks res->parent. The s390 pcibios_add_device() calls pci_claim_resource() on all BARs (except ROM, IOV, and bridge windows) so this isn't a problem either. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
2014-03-19tile PCI RC: Use default pcibios_enable_device()Bjorn Helgaas
We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Note: pci_enable_resources() checks that r->parent is non-NULL, which basically checks that pci_claim_resource() or request_resource() has been called for each BAR. I don't see where that happens for tile, but this patch doesn't change that behavior, so if it worked before, it should still work. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Chris Metcalf <cmetcalf@tilera.com>
2014-03-19sparc/PCI: Use default pcibios_enable_device() (Leon only)Bjorn Helgaas
We don't need anything arch-specific in pcibios_enable_device() so drop the arch implementation and use the default generic one. Note that sparc has two pcibios_enable_device() implementations other than the one removed here. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Daniel Hellstrom <daniel@gaisler.com
2014-03-19sh/PCI: Use default pcibios_enable_device()Bjorn Helgaas
We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Paul Mundt <lethal@linux-sh.org> CC: linux-sh@vger.kernel.org
2014-03-19microblaze/PCI: Use default pcibios_enable_device()Bjorn Helgaas
We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Michal Simek <monstr@monstr.eu> CC: microblaze-uclinux@itee.uq.edu.au
2014-03-19alpha/PCI: Use default pcibios_enable_device()Bjorn Helgaas
We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: linux-alpha@vger.kernel.org
2014-03-19PCI: Add "weak" generic pcibios_enable_device() implementationBjorn Helgaas
Many architectures implement pcibios_enable_device() the same way, so provide a default implementation in the core. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-19PCI: Don't enable decoding if BAR hasn't been assigned an addressBjorn Helgaas
Don't enable memory or I/O decoding if we haven't assigned or claimed the BAR's resource. If we enable decoding for a BAR that hasn't been assigned an address, we'll likely cause bus conflicts. This declines to enable decoding for resources with IORESOURCE_UNSET. Note that drivers can use pci_enable_device_io() or pci_enable_device_mem() if they only care about specific types of BARs. In that case, we don't bother checking whether the corresponding resources are assigned or claimed. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-19Staging: unisys: Remove RETINT macroKen Cox
The RETINT macro included a goto statement which is not allowed in the kernel. Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: unisys: Remove FAIL macroKen Cox
The FAIL macro ultimately includes a goto statement which is not allowed in the kernel. Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: unisys: Remove RETVOID macroKen Cox
The RETVOID macro contained a goto statement which is not allowed in the kernel. Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: unisys: Remove RETPTR macroKen Cox
The RETPTR macro contained a goto statement which is not allowed in the kernel. Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: unisys: Remove RETBOOL macroKen Cox
The RETBOOL macro contained a goto statement which is not allowed in the kernel. Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: unisys: Remove FAIL_WPOSTCODE_1 macroKen Cox
Part of a series to get rid of goto statements embedded in macros. I'm breaking this up into a series of smaller patches for easier review. The later patches in the series will actually remove the goto statements. Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Bluetooth: Fix Pair Device response parameters for pairing failureJohan Hedberg
It is possible that pairing fails after we've already received remote identity information. One example of such a situation is when re-encryption using the LTK fails. In this case the hci_conn object has already been updated with the identity address but user space does not yet know about it (since we didn't notify it of the new IRK yet). To ensure user space doesn't get a Pair Device command response with an unknown address always use the same address in the response as was used for the original command. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-19Staging: unisys: Cleanup macros to get rid of goto statementsKen Cox
Remove the following macros: TRY CHKFD CHKDD CHKFDX CHKDDX ADDPROCLINE TRY_WPOSTCODE_1 TRY_WPOSTCODE_2 FAIL_WPOSTCODE_2 FAIL_WPOSTCODE_3 Part of a series to get rid of goto statements embedded in macros. I'm breaking this up into a series of smaller patches for easier review. The later patches in the series will actually remove the goto statements. Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: unisys: include: Remove unused macros from timskmod.hKen Cox
The following macros were never referenced and have been removed: DEVFROMID DEVFROMFILE DEVFROMINODE DEVFROMIDX TRY_WPOSTCODE_3 Signed-off-by: Ken Cox <jkc@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Bluetooth: Fix SMP user passkey notification mgmt eventJohan Hedberg
When performing SMP pairing with MITM protection one side needs to enter the passkey while the other side displays to the user what needs to be entered. Nowhere in the SMP specification does it say that the displaying side needs to any kind of confirmation of the passkey, even though a code comment in smp.c implies this. This patch removes the misleading comment and converts the code to use the passkey notification mgmt event instead of the passkey confirmation mgmt event. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-19Bluetooth: Increase SMP re-encryption delay to 500msJohan Hedberg
In some cases the current 250ms delay is not enough for the remote to receive the keys, as can be witnessed by the following log: > ACL Data RX: Handle 64 flags 0x02 dlen 21 [hci1] 231.414217 SMP: Signing Information (0x0a) len 16 Signature key: 555bb66b7ab3abc9d5c287c97fe6eb29 < ACL Data TX: Handle 64 flags 0x00 dlen 21 [hci1] 231.414414 SMP: Encryption Information (0x06) len 16 Long term key: 2a7cdc233c9a4b1f3ed31dd9843fea29 < ACL Data TX: Handle 64 flags 0x00 dlen 15 [hci1] 231.414466 SMP: Master Identification (0x07) len 10 EDIV: 0xeccc Rand: 0x322e0ef50bd9308a < ACL Data TX: Handle 64 flags 0x00 dlen 21 [hci1] 231.414505 SMP: Signing Information (0x0a) len 16 Signature key: bbda1b2076e2325aa66fbcdd5388f745 > HCI Event: Number of Completed Packets (0x13) plen 5 [hci1] 231.483130 Num handles: 1 Handle: 64 Count: 2 < HCI Command: LE Start Encryption (0x08|0x0019) plen 28 [hci1] 231.664211 Handle: 64 Random number: 0x5052ad2b75fed54b Encrypted diversifier: 0xb7c2 Long term key: a336ede66711b49a84bde9b41426692e > HCI Event: Command Status (0x0f) plen 4 [hci1] 231.666937 LE Start Encryption (0x08|0x0019) ncmd 1 Status: Success (0x00) > HCI Event: Number of Completed Packets (0x13) plen 5 [hci1] 231.712646 Num handles: 1 Handle: 64 Count: 1 > HCI Event: Disconnect Complete (0x05) plen 4 [hci1] 232.562587 Status: Success (0x00) Handle: 64 Reason: Remote User Terminated Connection (0x13) As can be seen, the last key (Signing Information) is sent at 231.414505 but the completed packets event for it comes only at 231.712646, i.e. roughly 298ms later. To have a better margin of error this patch increases the delay to 500ms. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-19Bluetooth: Simplify logic when checking SMP_FLAG_TK_VALIDJohan Hedberg
This is a trivial coding style simplification by instead of having an extra early return to instead revert the if condition and do the single needed queue_work() call there. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-03-19staging: dgap: fix the rest of the checkpatch warnings in dgap.cMark Hounschell
This patch fixes all the simple_strtol and simple_strtoul warnings as reported by checkpatch. After this patch, checkpatch will report zero errors or warnings on dgap.c. Signed-off-by: Mark Hounschell <markh@compro.net> Tested-by: Mark Hounschell <markh@compro.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: bcm: Remove unnecessary parenthesesTugce Sirin
This patch fixes checkpatch.pl warning Unnecessary parentheses in bcm driver. Signed-off-by: Tugce Sirin <ztugcesirin@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging: wlags49_h2: Delete unnecessary bracesJelena Bjelja
Fix the following checkpatch.pl warnings in wl_netdev.c: WARNING: braces {} are not necessary for single statement blocks Signed-off-by: Jelena Bjelja <jelena.bjelja.ing@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging: wlags49_h2: Do not use assignment in if conditionJelena Bjelja
Fix the following checkpatch.pl issue in wl_netdev.c: ERROR: do not use assignment in if condition Signed-off-by: Jelena Bjelja <jelena.bjelja.ing@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging: wlags49_h2: Enclose macro in a do-while loopJelena Bjelja
Fix the following checkpatch.pl issues in wl_netdev.c: ERROR: Macros with multiple statements should be enclosed in a do - while loop Signed-off-by: Jelena Bjelja <jelena.bjelja.ing@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging/media/davinci_vpfe/vpfe_video.h Unnecessary space after function ↵Aybuke Ozdemir
pointer name Fix checkpatch.pl issues with Unnecessary space after function pointer name in vpfe_video.h Signed-off-by: Aybuke Ozdemir <aybuke.147@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging/media/davinci_vpfe/vpfe_video.h Fix missing space after return typeAybuke Ozdemir
Fix checkpatch.pl issues with missing space after return type in /vpfe_video.h Signed-off-by: Aybuke Ozdemir <aybuke.147@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging: nokia_h4p: Fix quoted string split across linesGulsah Kose
Fix checkpatch.pl issues with quoted string split across lines in nokia_fw-csr.c Signed-off-by: Gulsah Kose <gulsah.1004@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19i40e: support VF link state ndoMitch Williams
This netdev op allows the PF driver to control the virtual link state of the VF devices. This can be used to deny naughty VF drivers access to the wire, or to allow VFs (regardless of temperament) to communicate with each other over the device's internal switch even though external link is down. Add the actual ndo function, and modify vc_notify_link_state to check the link status of each VF before sending a message in the case when physical link changes state. Change-ID: Ib5a6924da78c540789f21d26b5e8086d71c29384 Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com> Tested-by: Sibai Li <sibai.li@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-03-19staging/lustre/libcfs: remove cfs_pausePeng Tao
Cc: Andreas Dilger <andreas.dilger@intel.com> Cc: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: Peng Tao <bergwolf@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging/lustre/libcfs: remove schedule_timeout_and_set_statePeng Tao
Cc: Andreas Dilger <andreas.dilger@intel.com> Cc: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: Peng Tao <bergwolf@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging/lustre/libcfs: remove waitq_timedwaitPeng Tao
Cc: Andreas Dilger <andreas.dilger@intel.com> Cc: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: Peng Tao <bergwolf@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging/lustre/libcfs: remove waitq_waitPeng Tao
Cc: Andreas Dilger <andreas.dilger@intel.com> Cc: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: Peng Tao <bergwolf@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging/lustre/libcfs: remove init_waitqueue_entry_currentPeng Tao
Cc: Andreas Dilger <andreas.dilger@intel.com> Cc: Oleg Drokin <oleg.drokin@intel.com> Signed-off-by: Peng Tao <bergwolf@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging: ft1000: Fix line over 80 characters.Gulsah Kose
Fix checkpatch.pl issues with line over 80 characters in ft1000.h Signed-off-by: Gulsah Kose <gulsah.1004@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging: as102: as10x_handle.h .Fix Unnecessary space after function pointer ↵Aybuke Ozdemir
name This patch removes the following checkpatch.pl warning in as10x_handle.h Warning : Unnecessary space after function pointer name Signed-off-by: Aybuke Ozdemir <aybuke.147@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: wlan-ng: Fix smatch warning potential null referenceTugce Sirin
This patch fixes potential null dereference 'wlandev' in wlan-ng driver. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Tugce Sirin <ztugcesirin@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19staging: adc: mxs-lradc.c Fix line over 80 characters.Aybuke Ozdemir
Fix checkpatch.pl issues with line over 80 characters in mxs-lradc.c Signed-off-by: Aybuke Ozdemir <aybuke.147@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19Staging: lustre: Fix space required before the open parenthesisTugce Sirin
This patch fixes space required before the open parenthesis in lustre driver. Signed-off-by: Tugce Sirin <ztugcesirin@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-03-19libata: remove unused ata_sas_port_async_resume() stubDan Williams
Commit bc6e7c4b0d1a "libata, libsas: kill pm_result and related cleanup" renamed ata_sas_port_async_resume() to ata_sas_port_resume(), but missed a CONFIG_PM=n stub conversion. Randy fixed that up in commit a5a6569959fc "libata.h: add stub for ata_sas_port_resume", but missed the deletion of the now unused ata_sas_port_async_resume() routine. Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2014-03-19cfg80211: remove macro ASSERT_RDEV_LOCK(rdev)Zhao, Gang
Macro ASSERT_RDEV_LOCK(rdev) is equal to ASSERT_RTNL(), so replace it with ASSERT_RTNL() and remove it. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-19cfg80211: remove unnecessary checkZhao, Gang
RCU pointer bss->pub.beacon_ies is checked before in previous statement: if (rcu_access_pointer(bss->pub.beacon_ies)) continue; There is no need to check it twice(and in the wrong way :) ). Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-19mac80211: set beamforming bit in radiotapEmmanuel Grumbach
Add a bit in rx_status.vht_flags to let the low level driver notify mac80211 about a beamformed packet. Propagate this to the radiotap header. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-19cfg80211/mac80211: ignore signal if the frame was heard on wrong channelEmmanuel Grumbach
On 2.4Ghz band, the channels overlap since the delta between different channels is 5Mhz while the width of the receiver is 20Mhz (at least). This means that we can hear beacons or probe responses from adjacent channels. These frames will have a significant lower RSSI which will feed all kinds of logic with inaccurate data. An obvious example is the roaming algorithm that will think our AP is getting weak and will try to move to another AP. In order to avoid this, update the signal only if the frame has been heard on the same channel as the one advertised by the AP in its DS / HT IEs. We refrain from updating the values only if the AP is already in the BSS list so that we will still have a valid (but inaccurate) value if the AP was heard on an adjacent channel only. To achieve this, stop taking the channel from DS / HT IEs in mac80211. The DS / HT IEs is taken into account to discard the frame if it was received on a disabled channel. This can happen due to the same phenomenon: the frame is sent on channel 12, but heard on channel 11 while channel 12 can be disabled on certain devices. Since this check is done in cfg80211, stop even checking this in mac80211. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [remove unused rx_freq variable] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-19cfg80211: make __cfg80211_join_ibss() staticZhao, Gang
Function __cfg80211_join_ibss() is only used in net/wireless/ibss.c, so make it static. Signed-off-by: Zhao, Gang <gamerh2o@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-19mac80211: add status_driver_data array to ieee80211_tx_infoEliad Peller
Drivers might want to have private data in addition to all other ieee80211_tx_info.status fields. The current ieee80211_tx_info.rate_driver_data overlaps with some of the non-rate data (e.g. ampdu_ack_len), so it might not be good enough. Since we already know how much free bytes remained, simply use this size to define (void *) array. While on it, change ack_signal type from int to the more explicit s32 type. Signed-off-by: Eliad Peller <eliadx.peller@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-19mac80211: release sched_scan_sdata when stopping sched scanAlexander Bondar
Assuming sched_scan_stop operation is synchronous the driver may not necessary call ieee80211_sched_scan_stopped_work. Since this work is the only place where sched_scan_sdata is released we can possibly run into situation when it is never released. Fix this by releasing it just after calling drv_sched_scan_stop. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-19mac80211: fix WPA with VLAN on AP side with ps-sta againMichael Braun
commit de74a1d9032f4d37ea453ad2a647e1aff4cd2591 "mac80211: fix WPA with VLAN on AP side with ps-sta" fixed an issue where queued multicast packets would be sent out encrypted with the key of an other bss. commit "7cbf9d017dbb5e3276de7d527925d42d4c11e732" "mac80211: fix oops on mesh PS broadcast forwarding" essentially reverted it, because vif.type cannot be AP_VLAN due to the check to vif.type in ieee80211_get_buffered_bc before. As the later commit intended to fix the MESH case, fix it by checking for IFTYPE_AP instead of IFTYPE_AP_VLAN. Cc: stable@vger.kernel.org Fixes: 7cbf9d017dbb ("mac80211: fix oops on mesh PS broadcast forwarding") Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>