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>
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
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
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
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This patch is based on an earlier patch by Eric Paris, he describes
the problem below:
"If an inode is accessed before policy load it will get placed on a
list of inodes to be initialized after policy load. After policy
load we call inode_doinit() which calls inode_doinit_with_dentry()
on all inodes accessed before policy load. In the case of inodes
in procfs that means we'll end up at the bottom where it does:
/* Default to the fs superblock SID. */
isec->sid = sbsec->sid;
if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
if (opt_dentry) {
isec->sclass = inode_mode_to_security_class(...)
rc = selinux_proc_get_sid(opt_dentry,
isec->sclass,
&sid);
if (rc)
goto out_unlock;
isec->sid = sid;
}
}
Since opt_dentry is null, we'll never call selinux_proc_get_sid()
and will leave the inode labeled with the label on the superblock.
I believe a fix would be to mimic the behavior of xattrs. Look
for an alias of the inode. If it can't be found, just leave the
inode uninitialized (and pick it up later) if it can be found, we
should be able to call selinux_proc_get_sid() ..."
On a system exhibiting this problem, you will notice a lot of files in
/proc with the generic "proc_t" type (at least the ones that were
accessed early in the boot), for example:
# ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax
However, with this patch in place we see the expected result:
# ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Acked-by: Eric Paris <eparis@redhat.com>
It turns out that doing the SELinux MAC checks for mmap() before the
DAC checks was causing users and the SELinux policy folks headaches
as users were seeing a lot of SELinux AVC denials for the
memprotect:mmap_zero permission that would have also been denied by
the normal DAC capability checks (CAP_SYS_RAWIO).
Example:
# cat mmap_test.c
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <sys/mman.h>
int main(int argc, char *argv[])
{
int rc;
void *mem;
mem = mmap(0x0, 4096,
PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
if (mem == MAP_FAILED)
return errno;
printf("mem = %p\n", mem);
munmap(mem, 4096);
return 0;
}
# gcc -g -O0 -o mmap_test mmap_test.c
# ./mmap_test
mem = (nil)
# ausearch -m AVC | grep mmap_zero
type=AVC msg=audit(...): avc: denied { mmap_zero }
for pid=1025 comm="mmap_test"
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tclass=memprotect
This patch corrects things so that when the above example is run by a
user without CAP_SYS_RAWIO the SELinux AVC is no longer generated as
the DAC capability check fails before the SELinux permission check.
Signed-off-by: Paul Moore <pmoore@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Correctly tag the SELinux mailing list as moderated for non-subscribers
and do some shuffling of the SELinux maintainers to try and make things
more clear when the scripts/get_maintainer.pl script is used.
# ./scripts/get_maintainer.pl -f security/selinux
Paul Moore <paul@paul-moore.com> (supporter:SELINUX SECURITY...)
Stephen Smalley <sds@tycho.nsa.gov> (supporter:SELINUX SECURITY...)
Eric Paris <eparis@parisplace.org> (supporter:SELINUX SECURITY...)
James Morris <james.l.morris@oracle.com> (supporter:SECURITY SUBSYSTEM)
selinux@tycho.nsa.gov (moderated list:SELINUX SECURITY...)
linux-security-module@vger.kernel.org (open list:SECURITY SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@parisplace.org>
Cc: James Morris <james.l.morris@oracle.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
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>
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>
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>
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>
Commit bc6e7c4b0d "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
a5a6569959 "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>
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>
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>
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>
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>
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>
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>
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>
commit de74a1d903
"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 "7cbf9d017d"
"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: 7cbf9d017d ("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>
