Usually you have to take the bus lock.  Why not here too?

I saw this when working on something else.  Not even compile tested.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Cc: Greg Dietsche <Gregory.Dietsche@cuw.edu>
Cc: "Uwe Kleine-Konig" <u.kleine-koenig@pengutronix.de>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Accesses to the mdio busses must be done with the mdio_lock to ensure
proper operation.  Conveniently we have the helper function
mdiobus_read() to do that for us.  Lets use it in get_phy_id() instead
of accessing the bus without the lock held.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Conflicts:
	drivers/net/wireless/iwlwifi/iwl-pci.c
	drivers/net/wireless/wl12xx/main.c

Signed-off-by: NGurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Change details:
 - Add a callback in the BNA, which is called before sending FW command to stop
   RxQs. After this callback is called, driver should not post anymore Rx
   buffers to the RxQ. This addresses a small window where driver posts Rx
   buffers while FW is stopping/has stopped the RxQ.
 - Registering callback function, rx_stall_cbfn, during bna_rx_create.
   Invoking callback function, rx_stall_cbfn, before sending rx_cfg_clr
   command to FW
 - Bnad_cb_rx_stall implementation - set a flag in the Rxq to mark buffer
   posting disabled state. While posting buffers check for the above flag.
Signed-off-by: NGurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Change details:
 - Fix to release soft reset in PLL init for HW
 - Added stats attributes and new bfi msg class
 - Removed some unused code and typo fixes
Signed-off-by: NGurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch enables new HW Brocade 1860. Add BFA_CM_NIC capability mask to
bfa_ioc_attr, Sub-System Device ID Info and support for Brocade 1860 device
ID to bfa_ioc.c and bnad.c.
Signed-off-by: NGurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add new device ID 0x22 and new asic generation BFI_ASIC_GEN_CT2 for 1860.
Implement FW download from user space for new Brocade HW.
Signed-off-by: NGurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add capability map and generic model name scheme for manufacturing block.
Add card types for new HW.

Remove bfa_mfg_is_card_type_valid and ibfa_mfg_adapter_prop_init_flash_ct
macros.
Signed-off-by: NGurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add logic to set ASIC specfic interface in IOC, HW interface initialization
APIs, mode based initialization and MSI-X resource allocation for 1860 with
no asic block. Add new h/w specific register definitions and setup registers
used by IOC logic.

Use normal kernel declaration style, c99 initializers and const for mailbox
structures. Remove unneeded parentheses.
Signed-off-by: NGurunatha Karaje <gkaraje@brocade.com>
Signed-off-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In order to make USB-to-Ethernet-adapters (depending on usbnet) support
timestamping, the "skb_defer_rx_timestamp" and "skb_tx_timestamp" function
calls are added.
Signed-off-by: NMichael Riesch <michael@riesch.at>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add poll controller function for fec nic.
Signed-off-by: NXiao Jiang <jgq516@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Don't use hardcoded irq num and replace it with
FEC_IRQ_NUM macro.
Signed-off-by: NXiao Jiang <jgq516@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Noticed that the legacy Interrupt handler didn't have the same
ECC warning as did the MSI.  So this patch adds it.

Signed-off-by: Don Skidmore <donald.c.skidmore>
Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

The X540 thermal sensor interrupt isn't a General Purpose Interrupt
so doesn't need to be enabled in ixgbe_setup_gpie().  Likewise X540 doesn't
use the SDP0 for thermal sensor so it doesn't need to be enabled for any
device other than 82599.
Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com>
Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Add code to enable thermal sensors for the x540 hardware, as well as a
thermal interrupt check which will exit with a critical message of a
thermal overheat is detected. Intent of code allows other mac types to
be added with different configuration in the future.

Fixed in this version is the addition of setting the temp_sensor
capable flag which was previously only set for a specific mac.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Revise high and low threshold marks wrt flow control to account
for the X540 devices and latency introduced by the loopback
switch.

Without this it was in theory possible to drop frames on a
supposedly lossless link with X540 or SR-IOV enabled.

Previously we used a magic number in a define to calculate the
threshold values. This made it difficult to sort out exactly
which latencies were or were not being accounted for. Here
I was overly explicit and tried to used #define names that would
be recognizable after reading the IEEE 802.1Qbb specification.
Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Disable LLI for FCoE since regular interrupt
and their moderation rate works slightly better
for FCoE also.
Signed-off-by: NVasu Dev <vasu.dev@intel.com>
Tested-by: NRoss Brattain <ross.b.brattain@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch is meant to help cleanup the interrupt throttle rate logic by
storing the interrupt throttle rate as a value in microseconds instead of
interrupts per second.  The advantage to this approach is that the value
can now be stored in an 16 bit field and doesn't require as much math to
flip the value back and forth since the hardware already used microseconds
when setting the rate.
Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Changes to clean up the vlan rx path broke trunk vlan.  Trunk vlans in
a VF driver are those set using:

"ip link set <pfdev> vf <n> <vlanid>"
Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
CC: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Doing an 'ifconfig ethN down' followed by an 'ifconfig ethN up' on a qemu-kvm
guest system configured with two e1000 NICs can result in an 'unable to handle
kernel paging request at 0000000100000000' or 'bad page map in process ...' or
something similar.

These result from a 4096-byte page being corrupted with the following two-word
pattern (16-bytes) repeated throughout the entire page:

  0x0000000000000000
  0x0000000100000000

There can be other bits set as well. What is a constant is that the 2nd word
has the 32nd bit set. So one could see:

        :
  0x0000000000000000
  0x0000000100000000
  0x0000000000000000
  0x0000000172adc067    <<< bad pte
  0x800000006ec60067
  0x0000000700000040
  0x0000000000000000
  0x0000000100000000
        :

Which came from from a process' page table I dumped out when the marked line
was seen as bad by print_bad_pte().

The repeating pattern represents the e1000's two-word receive descriptor:

struct e1000_rx_desc {
        __le64 buffer_addr;   /* Address of the descriptor's data buffer */
        __le16 length;        /* Length of data DMAed into data buffer */
        __le16 csum;          /* Packet checksum */
        u8 status;            /* Descriptor status */
        u8 errors;            /* Descriptor Errors */
        __le16 special;
};

And the 32nd bit of the 2nd word maps to the 'u8 status' member, and
corresponds to E1000_RXD_STAT_DD which indicates the descriptor is done.

The corruption appears to result from the following...

 . An 'ifconfig ethN down' gets us into e1000_close(), which through a number
   of subfunctions results in:
     1. E1000_RCTL_EN being cleared in RCTL register.  [e1000_down()]
     2. dma_free_coherent() being called.  [e1000_free_rx_resources()]

 . An 'ifconfig ethN up' gets us into e1000_open(), which through a number of
   subfunctions results in:
     1. dma_alloc_coherent() being called.  [e1000_setup_rx_resources()]
     2. E1000_RCTL_EN being set in RCTL register.  [e1000_setup_rctl()]
     3. E1000_RCTL_EN being cleared in RCTL register.  [e1000_configure_rx()]
     4. RDLEN, RDBAH and RDBAL registers being set to reflect the dma page
        allocated in step 1.  [e1000_configure_rx()]
     5. E1000_RCTL_EN being set in RCTL register.  [e1000_configure_rx()]

During the 'ifconfig ethN up' there is a window opened, starting in step 2
where the receives are enabled up until they are disabled in step 3, in which
the address of the receive descriptor dma page known by the NIC is still the
previous one which was freed during the 'ifconfig ethN down'. If this memory
has been reallocated for some other use and the NIC feels so inclined, it will
write to that former dma page with predictably unpleasant results.

I realize that in the guest, we're dealing with an e1000 NIC that is software
emulated by qemu-kvm. The problem doesn't appear to occur on bare-metal. Andy
suspects that this is because in the emulator link-up is essentially instant
and traffic can start flowing immediately. Whereas on bare-metal, link-up
usually seems to take at least a few milliseconds. And this might be enough
to prevent traffic from flowing into the device inside the window where
E1000_RCTL_EN is set.

So perhaps a modification needs to be made to the qemu-kvm e1000 NIC emulator
to delay the link-up. But in defense of the emulator, it seems like a bad idea
to enable dma operations before the address of the memory to be involved has
been made known.

The following patch no longer enables receives in e1000_setup_rctl() but leaves
them however they were. It only enables receives in e1000_configure_rx(), and
only after the dma address has been made known to the hardware.

There are two places where e1000_setup_rctl() gets called. The one in
e1000_configure() is followed immediately by a call to e1000_configure_rx(), so
there's really no change functionally (except for the removal of the problem
window. The other is in __e1000_shutdown() and is not followed by a call to
e1000_configure_rx(), so there is a change functionally. But consider...

 . An 'ifconfig ethN down' (just as described above).

 . A 'suspend' of the system, which (I'm assuming) will find its way into
   e1000_suspend() which calls __e1000_shutdown() resulting in:
     1. E1000_RCTL_EN being set in RCTL register.  [e1000_setup_rctl()]

And again we've re-opened the problem window for some unknown amount of time.
Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
Signed-off-by: NDean Nelson <dnelson@redhat.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch adds support for SJW user settings to not set the synchronization
jump width (SJW) to 1 in any case when using the in-kernel bittiming
calculation.

The ip-tool from iproute2 already supports to pass the user defined SJW
value. The given SJW value is sanitized with the controller specific sjw_max
and the calculated tseg2 value. As the SJW can have values up to 4 providing
this value will lead to the maximum possible SJW automatically. A higher SJW
allows higher controller oscillator tolerances.
Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch also changes writel/readl to iowrite32/ioread32.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds the driver for the SJA1000 based PCMCIA card 'CPC-Card' from
EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
Acked-by: NMarkus Plessing <plessing@ems-wuensche.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add an event to monitor comm value changes of tasks.  Such an event
becomes vital, if someone desires to control threads of a process in
different manner.

A natural characteristic of threads is its comm value, and helpfully
application developers have an opportunity to change it in runtime.
Reporting about such events via proc connector allows to fine-grain
monitoring and control potentials, for instance a process control daemon
listening to proc connector and following comm value policies can place
specific threads to assigned cgroup partitions.

It might be possible to achieve a pale partial one-shot likeness without
this update, if an application changes comm value of a thread generator
task beforehand, then a new thread is cloned, and after that proc
connector listener gets the fork event and reads new thread's comm value
from procfs stat file, but this change visibly simplifies and extends the
matter.
Signed-off-by: NVladimir Zapolskiy <vzapolskiy@gmail.com>
Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The upper protocol numbers of PPPOE are different, and should be treated
specially.
Signed-off-by: NChangli Gao <xiaosuo@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since commit 7361c36c (af_unix: Allow credentials to work across
user and pid namespaces) af_unix performance dropped a lot.

This is because we now take a reference on pid and cred in each write(),
and release them in read(), usually done from another process,
eventually from another cpu. This triggers false sharing.

# Events: 154K cycles
#
# Overhead  Command       Shared Object        Symbol
# ........  .......  ..................  .........................
#
    10.40%  hackbench  [kernel.kallsyms]   [k] put_pid
     8.60%  hackbench  [kernel.kallsyms]   [k] unix_stream_recvmsg
     7.87%  hackbench  [kernel.kallsyms]   [k] unix_stream_sendmsg
     6.11%  hackbench  [kernel.kallsyms]   [k] do_raw_spin_lock
     4.95%  hackbench  [kernel.kallsyms]   [k] unix_scm_to_skb
     4.87%  hackbench  [kernel.kallsyms]   [k] pid_nr_ns
     4.34%  hackbench  [kernel.kallsyms]   [k] cred_to_ucred
     2.39%  hackbench  [kernel.kallsyms]   [k] unix_destruct_scm
     2.24%  hackbench  [kernel.kallsyms]   [k] sub_preempt_count
     1.75%  hackbench  [kernel.kallsyms]   [k] fget_light
     1.51%  hackbench  [kernel.kallsyms]   [k]
__mutex_lock_interruptible_slowpath
     1.42%  hackbench  [kernel.kallsyms]   [k] sock_alloc_send_pskb

This patch includes SCM_CREDENTIALS information in a af_unix message/skb
only if requested by the sender, [man 7 unix for details how to include
ancillary data using sendmsg() system call]

Note: This might break buggy applications that expected SCM_CREDENTIAL
from an unaware write() system call, and receiver not using SO_PASSCRED
socket option.

If SOCK_PASSCRED is set on source or destination socket, we still
include credentials for mere write() syscalls.

Performance boost in hackbench : more than 50% gain on a 16 thread
machine (2 quad-core cpus, 2 threads per core)

hackbench 20 thread 2000

4.228 sec instead of 9.102 sec
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NTim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Conflicts:
	drivers/net/wireless/iwlwifi/iwl-scan.c
	net/wireless/nl80211.c

Correct flag usage - use it as a bit index instead of a bit value.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

wrqu->encoding.length comes from the network administrator.  It's
size u16.  We want to limit "tocopy" to the smallest value of either
"len_keys", "wrqu->encoding.length" or 100.  But because .length
gets cast from u16 to u8 we might use a random, smaller value than
the was desired.  It's probably not very serious, but we may as well
fix it.

Btw, this is from code auditing and not from testing.  I don't know
if this affects anyone in real life.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

save and configure tx param per sdata, rather than
per hardware.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

tx params are currently configured per hw, although they
should be configured per interface.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Whenever the scan request or tx_mgmt is requesting not to
use CCK rate for managemet frames through
NL80211_ATTR_TX_NO_CCK_RATE attribute, then mac80211 should
select appropriate least non-CCK rate. This could help to
send P2P probes and P2P action frames at non 11b rates
without diabling 11b rates globally.

Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add a new nl80211 attribute to specify whether to send the management
frames in CCK rate or not. As of now the wpa_supplicant is disabling
CCK rate at P2P init itself. So this patch helps to send P2P probe
request/probe response/action frames being sent at non CCK rate in 2GHz
without disabling 11b rates.

This attribute is used with NL80211_CMD_TRIGGER_SCAN and
NL80211_CMD_FRAME commands to disable CCK rate for management frame
transmission.

Cc: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We returned a freed variable on some error paths when the intent was
to return a NULL.  Part of the reason this was missed was that the
code was confusing because it had too many gotos so I removed them
and simplified the flow a bit.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NLauro Ramos Venancio <lauro.venancio@openbossa.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we cancel a scan, the completion runs
only from the workqueue. This can cause the
remain-on-channel scan to fail when another
one was just canceled, because we're still
aborting it.

To fix this, run the completion inline with
the lock still held before returning from
iwl_scan_cancel_timeout().

Also, to avoid the scan complete work from
completing a new scan prematurely, add a
new STATUS_SCAN_COMPLETE bit.
Reported-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Tested-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

To make the next patch easier to read, move
the function up, it'll be needed earlier in
this file in the next patch.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>