cdc_ncm disagrees with usbnet about how much framing overhead should
be counted in the tx_bytes statistics, and tries 'fix' this by
decrementing tx_bytes on the transmit path.  But statistics must never
be decremented except due to roll-over; this will thoroughly confuse
user-space.  Also, tx_bytes is only incremented by usbnet in the
completion path.

Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a
tx_bytes delta along with the tx_packets count.

Fixes: beeecd42 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics")
Signed-off-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: NBjørn Mork <bjorn@mork.no>

Currently the usbnet core does not update the tx_packets statistic for
drivers with FLAG_MULTI_PACKET and there is no hook in the TX
completion path where they could do this.

cdc_ncm and dependent drivers are bumping tx_packets stat on the
transmit path while asix and sr9800 aren't updating it at all.

Add a packet count in struct skb_data so these drivers can fill it
in, initialise it to 1 for other drivers, and add the packet count
to the tx_packets statistic on completion.
Signed-off-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
Tested-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fixes below warning by dynamically allocating memory

All warnings:

   drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c: In function
   'cctrl_tbl_show':
   >> drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c:689:1: warning: the
   >> frame
   >> size of 1028 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ucc_geth was indicating link up after a port is administratively enabled even
when nothing is plugged in.  This causes user-space tools to see a spurious link
up the first time after boot.
Signed-off-by: NCliff Clark <cliff_clark@selinc.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We occasionally see in procedure mlx4_GEN_EQE that the driver tries
to grab an uninitialized mutex.

This can occur in only one of two ways:
1. We are trying to generate an async event on an uninitialized slave.
2. We are trying to generate an async event on an illegal slave number
   ( < 0 or > persist->num_vfs) or an inactive slave.

To deal with #1: move the mutex initialization from specific slave init
sequence in procedure mlx_master_do_cmd to mlx4_multi_func_init() (so that
the mutex is always initialized for all slaves).

To deal with #2: check in procedure mlx4_GEN_EQE that the slave number
provided is in the proper range and that the slave is active.
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Netdevice registration should be performed a the end of the driver
initialization flow. If we don't do that, after calling register_netdevice,
device callbacks may be issued by higher layers of the stack before
final configuration of the device is done.

For example (VXLAN configuration race), mlx4_SET_PORT_VXLAN was issued
after the register_netdev command. System network scripts may configure
the interface (UP) right after the registration, which also attach
unicast VXLAN steering rule, before mlx4_SET_PORT_VXLAN was called,
causing the firmware to fail the rule attachment.

Fixes: 837052d0 ("net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling")
Signed-off-by: NIdo Shamay <idos@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Master change notifications may occur other than when joining or
leaving a bridge, for example when being added to or removed from
a bond or Open vSwitch.

Previously in those cases rocker_port_bridge_leave() was called
which results in a null-pointer dereference as rocker_port->bridge_dev
is NULL because there is no bridge device.

This patch makes provision for doing nothing in such cases.

Fixes: 6c707945 ("rocker: implement L2 bridge offloading")
Acked-by: NJiri Pirko <jiri@resnulli.us>
Acked-by: NScott Feldman <sfeldma@gmail.com>
Signed-off-by: NSimon Horman <simon.horman@netronome.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Statistics' state-machine in bnx2x driver must be synced with various driver
flows, but its current locking scheme manages to be wasteful [using 2 locks +
additional local variable] and prone to race-conditions at the same time,
as the state-machine and 'action' are being accessed under different locks.

In addition, current 'safe exec' isn't in fact safe, since the only guarantee
it gives is that DMA transactions are over, but ramrods might still be running.

This patch cleans up said logic, leaving us with a single lock for the entire
flow and removing the possible races.

Changes from v2:
	- Switched into mutex locking from semaphore locking.
	- Release locks on error flows.

Changes from v1:
	Failure to acquire lock fails flow instead of printing a warning and
	allowing access to the critical section.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NAriel Elior <Ariel.Elior@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Return EPROBE_DEFER if Regulator returns EPROBE_DEFER

If the Flexcan driver is built into kernel and a regulator is used to
enable the CAN transceiver, the Flexcan driver may not use the regulator.

When initializing the Flexcan device with a regulator defined in the device
tree, but not initialized, the regulator subsystem returns EPROBE_DEFER, hence
the Flexcan init fails.

The solution for this is to return EPROBE_DEFER if regulator is not initialized
and wait until the regulator is initialized.
Signed-off-by: NAndreas Werner <kernel@andy89.org>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Making sure that the bus-off state gets passed to can_change_state().
Signed-off-by: NAndri Yngvason <andri.yngvason@marel.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The PCAN USB (pro) FD adapters with firmware versions > 2.x support the
switching between ISO (default) and non-ISO conform bitstreams on the CAN bus.
The setting for the 2.x firmware adapters can be modified with the 'ip' tool
from the iproute2 package (option: fd-non-iso [on|off]).
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

The PUCAN_CMD_RX_FRAME_(ENABLE|DISABLE) command has extended its purpose
and was therefore renamed to PUCAN_CMD_SET_(EN|DIS)_OPTION.
Signed-off-by: NStephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

smatch detected the following issue:
drivers/net/can/usb/gs_usb.c:904 gs_usb_probe() error:
   potential null dereference 'dev'.  (kzalloc returns null)

Add a check for null return from kzalloc and return -ENOMEM
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

USB endpoint's wMaxPacketSize field is an le16 entity. Use
appropriate le16_to_cpu macros to maintain endian independence.
Reported-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NAhmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Current driver code arbitrarily assumes a max outstanding tx
value of 16 parallel transmissions. Meanwhile, the device
firmware provides its actual maximum inside its reply to the
CMD_GET_SOFTWARE_INFO message.

Under heavy tx traffic, if the interleaved transmissions count
increases above the limit reported by firmware, the firmware
breaks up badly, reports a massive list of internal errors, and
the candump traces hardly matches the actual frames sent and
received.

On the other hand, in certain models, the firmware can support
up to 48 tx URBs instead of just 16, increasing the driver
throughput by two-fold and reducing the possibility of -ENOBUFs.

Thus dynamically set the driver's max tx URBs value according
to firmware replies.
Signed-off-by: NAhmed S. Darwish <ahmed.darwish@valeo.com>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Transmission of an AP beacon does not call the TX interrupt service routine,
which usually does the cleanup. Instead, cleanup is handled in a tasklet
completion routine. Unfortunately, this routine has a serious bug in that it does
not release the DMA mapping before it frees the skb, thus one IOMMU mapping is
leaked for each beacon. The test system failed with no free IOMMU mapping slots
approximately one hour after hostapd was used to start an AP.

This issue was reported and tested at https://github.com/lwfinger/rtlwifi_new/issues/30.
Reported-and-tested-by: NKevin Mullican <kevin@mullican.com>
Cc: Kevin Mullican <kevin@mullican.com>
Signed-off-by: NShao Fu <shaofu@realtek.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>  [3.18+]
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

When the device is powered up, some (older) firmware versions fail to work
properly if we send commands before the boot is complete (everything is OK
when the device is hot-plugged). The firmware indicates its ready status by
putting the link up.
Newer firmwares delay the first command so they don't suffer from this problem.
They also report the link being always up.

Wait for firmware to become ready (link up) before sending any commands and/or
data.

This also allows lowering CMD_TIMEOUT value to a reasonable time.

Tested with 4.1.0.9 (old) and 4.1.0.30 (new) firmware versions.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The BCM43362 firmware falsely reports it is capable of providing
MBSS. As a result AP mode no longer works for this device. Therefor
disable MBSS in the driver for this chipset.

Cc: stable@vger.kernel.org # 3.19.y
Reported-by: NJorg Krause <jkrause@posteo.de>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

If ->run() fails, it can either free the data structures it
allocated, or leave that task to ->free() which will be called
on failures.

However:
  md.c calls ->free() even if ->private_data is NULL, which
     causes problems in some personalities.
  raid0.c frees the data, but doesn't clear ->private_data,
     which will become a problem when we fix md.c

So better fix both these issues at once.
Reported-by: NRichard W.M. Jones <rjones@redhat.com>
Fixes: 5aa61f42
URL: https://bugzilla.kernel.org/show_bug.cgi?id=94381Signed-off-by: NNeilBrown <neilb@suse.de>

When an EEH error occurs, the device/slot is disconnected. This condition
is more reliably detected (i.e., returns all ones) with an MMIO read rather
than a config read -- especially on power platforms.

Hence, this patch fixes EEH error detection by replacing config reads with
MMIO reads for reading the error registers. The error registers in
Skyhawk-R/BE2/BE3 are accessible both via the config space and the
PCICFG (BAR0) memory space.
Reported-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: NSuresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Issuing this cmd for more than 8 EQs does not have the intended effect
even on BEx and Skyhawk-R.

This patch fixes this by issuing this cmd for upto 8 EQs at a time.
Signed-off-by: NSuresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, a PF does not restrict its VF interface from enabling vlan
promiscuous mode. This breaks vlan isolation when a vlan
(transparent tagging) is configured on a VF.

This patch fixes this problem by disabling the vlan promisc capability
for VFs.
Reported-by: NYoann Juet <veilletechno-irts@univ-nantes.fr>
Signed-off-by: NVasundhara Volam <vasundhara.volam@emulex.com>
Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On a MIPS Malta board, tons of fifo underflow errors have been observed
when using u-boot as bootloader instead of YAMON. The reason for that
is that YAMON used to set the pcnet device to SRAM mode but u-boot does
not. As a result, the default Tx threshold (64 bytes) is now too small to
keep the fifo relatively used and it can result to Tx fifo underflow errors.
As a result of which, it's best to setup the SRAM on supported controllers
so we can always use the NOUFLO bit.

Cc: <netdev@vger.kernel.org>
Cc: <stable@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Cc: Don Fry <pcnet32@frontier.com>
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit b4b55cda (Refine the way to release PCI IRQ resources)
introduced a regression in the PCI IRQ resource management by causing
the IRQ resource of a device, established when pci_enabled_device()
is called on a fully disabled device, to be released when the driver
is unbound from the device, regardless of the enable_cnt.

This leads to the situation that an ill-behaved driver can now make a
device unusable to subsequent drivers by an imbalance in their use of
pci_enable/disable_device().  That is a serious problem for secondary
drivers like vfio-pci, which are innocent of the transgressions of
the previous driver.

Since the solution of this problem is not immediate and requires
further discussion, revert commit b4b55cda and the issue it was
supposed to address (a bug related to xen-pciback) will be taken
care of in a different way going forward.
Reported-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

A check that rejects a CDB with FUA bit set if no write cache is
emulated was added by the following commit:

  fde9f50f target: Add sanity checks for DPO/FUA bit usage

The condition is as follows:

  if (!dev->dev_attrib.emulate_fua_write ||
      !dev->dev_attrib.emulate_write_cache)

However, this check is wrong if the backend device supports WCE but
"emulate_write_cache" is disabled.

This patch uses se_dev_check_wce() (previously named
spc_check_dev_wce) to invoke transport->get_write_cache() if the
device has a write cache or check the "emulate_write_cache" attribute
otherwise.
Reported-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NChristophe Vu-Brugier <cvubrugier@fastmail.fm>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a NULL pointer dereference triggered by a late
target_configure_device() -> alloc_workqueue() failure that results
in target_free_device() being called with DF_CONFIGURED already set,
which subsequently OOPses in destroy_workqueue() code.

Currently this only happens at modprobe target_core_mod time when
core_dev_setup_virtual_lun0() -> target_configure_device() fails,
and the explicit target_free_device() gets called.

To address this bug originally introduced by commit 0fd97ccf, go
ahead and move DF_CONFIGURED to end of target_configure_device()
code to handle this special failure case.
Reported-by: NClaudio Fleiner <cmf@daterainc.com>
Cc: Claudio Fleiner <cmf@daterainc.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org> # v3.7+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a NULL pointer dereference OOPs with pSCSI backends
within target_core_stat.c code.  The bug is caused by a configfs attr
read if no pscsi_dev_virt->pdv_sd has been configured.
Reported-by: NOlaf Hering <olaf@aepfle.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch adds a missing set of conditional check braces in
ft_invl_hw_context() originally introduced by commit dcd998cc
when handling DDP failures in ft_recv_write_data() code.

 commit dcd998cc
 Author: Kiran Patil <kiran.patil@intel.com>
 Date:   Wed Aug 3 09:20:01 2011 +0000

    tcm_fc: Handle DDP/SW fc_frame_payload_get failures in ft_recv_write_data
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Kiran Patil <kiran.patil@intel.com>
Cc: <stable@vger.kernel.org> # 3.1+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a se_cmd->cmd_kref leak buf when se_sess->sess_tearing_down
is true within target_get_sess_cmd() submission path code.

This se_cmd reference leak can occur during active session shutdown when
ack_kref=1 is passed by target_submit_cmd_[map_sgls,tmr]() callers.
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: <stable@vger.kernel.org> # 3.6+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch changes loopback, usb-gadget, vhost-scsi and xen-scsiback
fabric code to invoke transport_register_session() instead of the
unprotected flavour, to ensure se_tpg->session_lock is taken when
adding new session list nodes to se_tpg->tpg_sess_list.

Note that since these four fabric drivers already hold their own
internal TPG mutexes when accessing se_tpg->tpg_sess_list, and
consist of a single se_session created through configfs attribute
access, no list corruption can currently occur.

So for correctness sake, go ahead and use the se_tpg->session_lock
protected version for these four fabric drivers.
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes the incorrect use of __transport_register_session()
in tcm_qla2xxx_check_initiator_node_acl() code, that does not perform
explicit se_tpg->session_lock when accessing se_tpg->tpg_sess_list
to add new se_sess nodes.

Given that tcm_qla2xxx_check_initiator_node_acl() is not called with
qla_hw->hardware_lock held for all accesses of ->tpg_sess_list, the
code should be using transport_register_session() instead.
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Cc: Quinn Tran <quinn.tran@qlogic.com>
Cc: <stable@vger.kernel.org> # 3.5+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This patch fixes a iser specific logout bug where early complete()
of conn->conn_logout_comp in iscsit_close_connection() was causing
isert_wait4logout() to complete too soon, triggering a use after
free NULL pointer dereference of iscsi_conn memory.

The complete() was originally added for traditional iscsi-target
when a ISCSI_LOGOUT_OP failed in iscsi_target_rx_opcode(), but given
iser-target does not wait in logout failure, this special case needs
to be avoided.
Reported-by: NSagi Grimberg <sagig@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Slava Shwartsman <valyushash@gmail.com>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This reverts commit 72859d91.

The original patch was wrong, iscsit_close_connection() still needs
to release iscsi_conn during both normal + exception IN_LOGOUT status
with ib_isert enabled.

The original OOPs is due to completing conn_logout_comp early within
iscsit_close_connection(), causing isert_wait4logout() to complete
instead of waiting for iscsit_logout_post_handler_*() to be called.
Reported-by: NSagi Grimberg <sagig@mellanox.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: Slava Shwartsman <valyushash@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Now that incoming FUA=1 bit check is enforced for backends with FUA or
WCE disabled, go ahead and disallow the changing of related backend
attributes when active fabric exports exist.

This is required to avoid potential failures with existing initiator
LUN registrations that have been previously created with FUA=1.
Reported-by: NChristoph Hellwig <hch@lst.de>
Cc: Doug Gilbert <dgilbert@interlog.com>
Cc: James Bottomley <JBottomley@Parallels.com>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

This reverts commit 2fa645cb.

The assumption that at least 1 preferred console will be registered
when the stdout-path property is set is invalid, which can result
in _no_ consoles.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NRob Herring <robh@kernel.org>

The firmware frequently manages to trigger this, and there's
no known driver workaround, so stop warning.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Commit 106937e8 ("of: fix handling of '/' in options for
of_find_node_by_path()") caused a regression in OF handling of
stdout-path. While it fixes some cases which have '/' after the ':', it
breaks cases where there is more than one '/' *before* the ':'.

For example, it breaks this boot string

  stdout-path = "/rdb/serial@f040ab00:115200";

So rather than doing sequentialized checks (first for '/', then for ':';
or vice versa), to get the correct behavior we need to check for the
first occurrence of either one of them.

It so happens that the handy strcspn() helper can do just that.

Fixes: 106937e8 ("of: fix handling of '/' in options for of_find_node_by_path()")
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: stable@vger.kernel.org # 3.19
Acked-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>

There were regressions seen with commit 106937e8 ("of: fix handling
of '/' in options for of_find_node_by_path()"), where we couldn't handle
extra '/' before the ':'. Let's test for this now.

Confirmed that this test fails without the previous patch and passes
when patched. All other tests pass.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>

The error code paths that require cleanup use a goto to jump to the
cleanup code and return an error code. However, the error code variable
res, which is initialized to -EINVAL when declared, is then overwritten
with the return value of of_parse_phandle_with_args(), and reused as the
return code from of_irq_parse_one(). This leads to an undetermined error
being returned instead of the expected -EINVAL value. Fix it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: NRob Herring <robh@kernel.org>

Add new 3165 PCI IDs for new 1x1 cards.
Signed-off-by: NOren Givon <oren.givon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>