The first line of the top file comment should begin on the line following
the block comment opening, thereby following the convention used elsewhere
in the driver set.
Signed-off-by: David Binder <david.binder@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Reviewed-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The first line of the top file comment should begin on the line following
the block comment opening, thereby following the convention used elsewhere
in the driver set.
Signed-off-by: David Binder <david.binder@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Reviewed-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Due to include order, the visorbus_private.h file was missing a required
include header visorbus.h. If visorchipset.c or visorbus_main.c ever were
to change the order of the includes for visobus.h and visorbus_private.h,
the code would fail to compile.
Reviewed-by: Sameer Wadgaonkar <sameer.wadgaonkar@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Reviewed-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The functions viosrbus_device_pause_response() and
viosrbus_device_resume_response() are functionally similar.
Merging these functions into a single function called
visorbus_device_changestate_response().
Signed-off-by: Sameer Wadgaonkar <sameer.wadgaonkar@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Reviewed-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The functions visorbus_create_response(), visorbus_destroy_response(),
viosrbus_device_create_response(), viosrbus_device_destroy_response()
are all functionally similar. Merging these four functions into a
single function called visorbus_response().
Signed-off-by: Sameer Wadgaonkar <sameer.wadgaonkar@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Reviewed-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace use of standard Linux dma_data_direction with a Unisys-
specific uis_dma_data_direction and provide a function to convert
from the latter to the former. This is necessary because Unisys
s-Par depends on the exact format of this field in multiple OSs
and languages, and so using the standard version creates an
unnecessary dependency between the kernel and s-Par.
Signed-off-by: Steven Matthews <steven.matthews@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Reviewed-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moved blocked comment on to own line at beginning of struct to follow
standard. Since this is an internal structure, the block comment isn't
actually a kernel-doc so we only start the block with one asterisk.
Signed-off-by: Mark Foresta <Mark.Foresta@Unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Reviewed-by: David Binder <david.binder@unisys.com>
Reviewed-by: Tim Sell <timothy.sell@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Pirko says:
====================
net: sched: couple of chain fixes
Jiri Pirko (2):
net: sched: fix use after free when tcf_chain_destroy is called
multiple times
net: sched: don't do tcf_chain_flush from tcf_chain_destroy
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
tcf_chain_flush needs to be called with RTNL. However, on
free_tcf->
tcf_action_goto_chain_fini->
tcf_chain_put->
tcf_chain_destroy->
tcf_chain_flush
callpath, it is called without RTNL.
This issue was notified by following warning:
[ 155.599052] WARNING: suspicious RCU usage
[ 155.603165] 4.13.0-rc5jiri+ #54 Not tainted
[ 155.607456] -----------------------------
[ 155.611561] net/sched/cls_api.c:195 suspicious rcu_dereference_protected() usage!
Since on this callpath, the chain is guaranteed to be already empty
by check in tcf_chain_put, move the tcf_chain_flush call out and call it
only where it is needed - into tcf_block_put.
Fixes: db50514f9a ("net: sched: add termination action to allow goto chain")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The goto_chain termination action takes a reference of a chain. In that
case, there is an issue when block_put is called tcf_chain_destroy
directly. The follo-up call of tcf_chain_put by goto_chain action free
works with memory that is already freed. This was caught by kasan:
[ 220.337908] BUG: KASAN: use-after-free in tcf_chain_put+0x1b/0x50
[ 220.344103] Read of size 4 at addr ffff88036d1f2cec by task systemd-journal/261
[ 220.353047] CPU: 0 PID: 261 Comm: systemd-journal Not tainted 4.13.0-rc5jiri+ #54
[ 220.360661] Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox x86 mezzanine board, BIOS 4.6.5 08/02/2016
[ 220.371784] Call Trace:
[ 220.374290] <IRQ>
[ 220.376355] dump_stack+0xd5/0x150
[ 220.391485] print_address_description+0x86/0x410
[ 220.396308] kasan_report+0x181/0x4c0
[ 220.415211] tcf_chain_put+0x1b/0x50
[ 220.418949] free_tcf+0x95/0xc0
So allow tcf_chain_destroy to be called multiple times, free only in
case the reference count drops to 0.
Fixes: 5bc1701881 ("net: sched: introduce multichain support for filters")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
High order GFP_KERNEL allocations can stress the host badly.
Use modern kvmalloc_array()/kvfree() instead of custom
allocations.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
zorro_device_id are not supposed to change at runtime. All functions
working with zorro_device_id provided by <linux/zorro.h> work with
const zorro_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Antoine Tenart says:
====================
net: mvpp2: MAC/GoP configuration
This is based on net-next (e2a7c34fb2).
I removed the GoP interrupt and PHY optional parts in this v2 to ease
the review process as the MAC/GoP initialization seemed to start less
discussions :)
This series now only aims at making the PPv2 driver less depending on
the firmware/bootloader initialization. Some patches cleanup some parts
as well, and add new interface descriptions in the dt.
The current implementation of the PPv2 driver relies on the
firmware/bootloader initialization to configure some parts, as the Group
of Ports (GoP) and the MACs (GMAC and/or XLG MAC --for 10G--). The
drawback is the kernel must be configured to match exactly what the
bootloader configures which is not convenient and is an issue when using
boards having an Ethernet port and an SFP port wired to the same GoP
port, as no dynamic configuration can be done.
This series adds the GoP and GMAC/XLG MAC initializations so that the
PPV2 does not have to rely on a previous initialization. One part is
still missing from this series, and that would be the 'comphy' which
provides shared serdes PHYs and which must be configured as well for a
full kernel initialization to work. This comphy support will be part of
a following up series. (This series was also tested with this 'comphy'
support, as it's nearly ready).
@Dave: patches 9 and 10 should go through the mvebu tree. Thanks!
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
