"id" is type is a uid_t (32 bits) but on 64 bit systems strict_strtoul()
modifies 64 bits of data. We should use kstrtouint() instead.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
The latest generation of ipr hardware performs best when command blocks
are aligned to a boundary equal to the size of the command block. Ensure
512 byte alignment, since this is the largest size command block we
can send.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Increase the total number of max concurrent outstanding commands
for the most recent family of adapters in order to improve overall
adapter performance.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The ipr driver added some memory barriers in order to ensure
a PowerPC sync instruction was executed prior to sending a
command to the adapter to ensure the command block was
coherent with respect to the PCI bus's view of memory.
However, some time ago, the powerpc architecture writel
macros were changed to include the sync since most drivers
don't properly handle this. So remove these memory barriers
since they are not needed and result in executing twice
as many sync instructions, which has a significant performance
penalty.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The latest ipr hardware no longer requires the driver to issue any MMIOs
to clear the interrupt so remove this to optimize performance.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
For the latest ipr SAS adapters, target id's are a completely
logical construct that are managed in the ipr driver. This fixes
an issue that can arise if a device is deleted via sysfs. If
a new device is then physically added, it will use the previous
device's target id. If the host is then rescanned, the device
that had been deleted, since it is using the same target id as
the new device is using, will never be found, resulting in
a missing device. Fix this by only freeing the target id
only if the resource is actually gone.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
commit 737f360d5b (linux-next)
"regulator: Remove support for supplies specified by struct device"
deletes the field from the struct, but this platform was still trying
to set those fields. Delete the assignments.
arch/arm/mach-pxa/magician.c:581: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/magician.c:581: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/magician.c:585: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/magician.c:585: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/hx4700.c:683: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/hx4700.c:683: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/hx4700.c:687: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/hx4700.c:687: warning: initialization from incompatible pointer type
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
commit 44c10138fd (PCI: Change all
drivers to use pci_device->revision) converted all drivers to use
pci_dev->revision. Convert these three drivers which got missed.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Fixes spurious warnings.
Tested-by: Dave Jones <davej@redhat.com>
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't use "cpu" any more after 2baab4e904 "sched: Fix
select_fallback_rq() vs cpu_active/cpu_online".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Paul Menage <paul@paulmenage.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120328104608.GD29022@elgon.mountain
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The rtnl_lock is primarily used to serialize networking
driver changes as well as to ensure that a networking driver
is not removed when making changes to it. fcoe also uses
the rtnl_lock to protect the fcoe hostlist.
fcoe_create holds the rtnl_lock over the entirity of the
routine including a the call to fcoe_ctlr_link_up.
This causes the below deadlock because fcoe_ctlr_link_up
acquires the fcoe_ctlr ctlr_mutex and this deadlocks with
a libfcoe thread that acquires the fcoe_ctlr ctlr_mutex and
then the rtnl_lock (to update a MAC address).
This patch drops the rtnl_lock before calling
fcoe_ctlr_link_up and therefore the deadlock is prevented.
https://bugzilla.kernel.org/show_bug.cgi?id=42918
the existing dependency chain (in reverse order) is:
-> #1 (&fip->ctlr_mutex){+.+...}:
[<c1091f70>] lock_acquire+0x80/0x1b0
[<c147655d>] mutex_lock_nested+0x6d/0x340
[<f8970c32>] fcoe_ctlr_link_up+0x22/0x180 [libfcoe]
[<f894620e>] fcoe_create+0x47e/0x6e0 [fcoe]
[<f8973dd3>] fcoe_transport_create+0x143/0x250 [libfcoe]
[<c10527e0>] param_attr_store+0x30/0x60
[<c1052696>] module_attr_store+0x26/0x40
[<c11a201e>] sysfs_write_file+0xae/0x100
[<c11449df>] vfs_write+0x8f/0x160
[<c1144cbd>] sys_write+0x3d/0x70
[<c147a0c4>] syscall_call+0x7/0xb
-> #0 (rtnl_mutex){+.+.+.}:
[<c109164b>] __lock_acquire+0x140b/0x1720
[<c1091f70>] lock_acquire+0x80/0x1b0
[<c147655d>] mutex_lock_nested+0x6d/0x340
[<c13a10c4>] rtnl_lock+0x14/0x20
[<f89445ac>] fcoe_update_src_mac+0x2c/0xb0 [fcoe]
[<f8971712>] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe]
[<c104fb69>] process_one_work+0x179/0x5d0
[<c10502f1>] worker_thread+0x121/0x2d0
[<c10550ed>] kthread+0x7d/0x90
[<c1481a82>] kernel_thread_helper+0x6/0x10
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&fip->ctlr_mutex);
lock(rtnl_mutex);
lock(&fip->ctlr_mutex);
lock(rtnl_mutex);
*** DEADLOCK ***
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Made changes to set the rport maxfrsize param to use a value that is
equal to or less than the Buffer-to-Buffer Receive Data_Field size
specified in the Common Service Parameters.
Increased the diag memtest timeout for the Brocade-1860 adapters.
Made changes to enable valid port speed configuration check for all adapters.
Made changes to increase the max hw segments in a request, in order to
support larger data transfers from user space.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Fixed the LPS (Logical Port Services) state machine to send a
FDISC/FLOGI to the FW from the request queue wait state, when
there is space available again on the request queue.
Made changes to free the vport on LOGO/cleanup complete instead
of free'ing it from vport_delete_handler in the module unload scenario.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Programming of the service parameters Tx credits etc., is now done in firmware.
Remove the logic of sending the service parameters to firmware from driver.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Made changes to the Fabric Assigned Address(FAA) feature implementation.
Introduced the IOCFC state machine, which now handles the FAA logic,
IOC and BFA sub-modules enablement.
Removed un-wanted FAA enable/disable routines; FAA is enabled by default.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Made changes to resume the flash controller if it is halted before going
ahead with flash controller pause/resume logic.
Made changes to avoid clearing off the interrupts during the initial
pll initialization.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Made changes to ensure only the function that comes first will execute
the IOC hw semaphore unlock logic.
Used IOC init sem register to serialize execution of the unlock logic.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Made changes to the driver ISR to process any pending completions even if
the RME bit is not set in the interrupt status register.
Signed-off-by: Krishna Gudipati <kgudipat@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
This fix ensures that the IOP_LOGINFO_CODE_TASK_TERMINATED
messages do not clutter the sas_log_info messages.
Bugzilla 42142 - mpt2sas: Number specified in wrong base
https://bugzilla.kernel.org/show_bug.cgi?id=42142
Signed-off-by: Sathisha Nanjappa <sathisha.nanjappa@hp.com>
Acked-by: "Nandigama, Nagalakshmi" <Nagalakshmi.Nandigama@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
While investigating another bug, I found that the code on the incoming path
in __netif_receive_skb will only set skb->skb_iif if it is already 0. When
dev_forward_skb() is used in the case of interfaces like veth, skb_iif may
already have been set. Making dev_forward_skb() cause the packet to look
like a newly received packet would seem to the the correct behaviour here,
as otherwise the wrong incoming interface can be reported for such a packet.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
When using multicast over a local bridge feeding a number of LXC guests
using veth, the LXC guests are unable to get a response from other guests
when pinging 224.0.0.1. Multicast packets did not appear to be getting
delivered to the network namespaces of the guest hosts, and further
inspection showed that the incoming route was pointing to the loopback
device of the host, not the guest. This lead to the wrong network namespace
being picked up by sockets (like ICMP). Fix this by using the correct
network namespace when creating the inbound route entry.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
While it is desirable to rate limit certain messages, it is not
desirable to rate limit the incrementing of counters associated
with those messages.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Starting fcoe fails at fcoe_transport_create when attempting to allocate a
pool of 4K exchanges on a 64-bit single-CPU environment because the call to
__alloc_percpu() is greater than the max of 32K. This patch reduces the
number of exchanges to fit within the maximum allowed space.
[ Whitespace problems fixed by Robert Love to satisfy chechpatch.pl ]
Signed-off-by: Steven Clark <sclark@crossbeam.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
There is potentially lots of contention for the rx_list_lock. On a cpu that is
receiving lots of fcoe traffic, the softirq context has to add and release the
lock for every frame it receives, as does the receiving per-cpu thread. We can
reduce this contention somewhat by altering the per-cpu threads loop such that
when traffic is detected on the fcoe_rx_list, we splice it to a temporary list.
In this way, we can process multiple skbs while only having to acquire and
release the fcoe_rx_list lock once.
[ Braces around single statement while loop removed by Robert Love
to satisfy checkpath.pl. ]
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
TLBs are available only for MMU systems.
Error log:
arch/microblaze/kernel/setup.c: In function 'debugfs_tlb':
arch/microblaze/kernel/setup.c:217: error: 'tlb_skip' undeclared (first use in this function)
arch/microblaze/kernel/setup.c:217: error: (Each undeclared identifier is reported only once
arch/microblaze/kernel/setup.c:217: error: for each function it appears in.)
make[1]: *** [arch/microblaze/kernel/setup.o] Error 1
Signed-off-by: Michal Simek <monstr@monstr.eu>
commit e7a51997da ([SCSI] fcoe: flush per-cpu
thread work when destroying interface) added a skb flush to the fcoe_rx_list,
which ensures that we push any pending frames on the list through the per-cpu
receive thread. Because of this, its redundant to lock and scan the list
first, dropping any arriving frames.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
As with the fcoe sw transport, the bnx2fc packet handler function runs only in
softirq context. Theres no need to disable bottom halves here
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The fcoe sw recive packet function (fcoe_rcv) only ever executes in softirq
context. Given that, and the fact that no use of the fcoe_rx_list is made in
irq context, its not necessecary to disable bottom halves while actually
receiving the frame. Convert spin_*_bh calls in that function to their
lock-only equivalents
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Some switch implementations (eg., HP virtual connect FlexFabric) send two MAC
descriptors in FIP FLOGI response, with first MAC descriptor (granted_mac) used
as FPMA, and the second one (fcoe_mac) used as destination address for
sending/receiving FCoE packets. fip_mac continues to be used for FIP traffic.
This patch introduces fcoe_mac in fcoe_fcf structure. For regular switches,
both fcoe_mac and fip_mac will be the same. For the switches that send
additional MAC descriptor, fcoe_mac is updated.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Currently fc_host mfs is not getting updated in
case its changed during FLOGI and that leaves fc_host
to show its initial old value in sysfs, so instead
have fc_host mfs updated along with updating lport mfs
during FLOGI.
Also in case of bad mfs during flogi, error out
instead of continuing with flogi.
[ Changes made by Robert Love: condition to '>=' and
added printing of lport->mfs in DBG statement. FLOGI
resp processing failed without being able to compare
FCoE MFS 2112 against an incoming MFS of 2112 ]
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
When handling CVL with no Vx port descriptors, lports for NPIV ports are reset
before issuing the ctlr_reset. This causes FDISCs to be issued before
successful FLOGI. Fix it by resetting the controller before resetting the
lports.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
commit 859b7b649a introduced the ability to call
fcoe_recv_frame in softirq context. While this is beneficial to performance,
its not safe to do, as it breaks the serialization of access to the lport
structure (i.e. when an fcoe interface is being torn down, theres no way to
serialize the teardown effort with the completion of receieve operations
occuring in softirq context. As a result, lport (and other) data structures can
be read and modified in parallel leading to corruption. Most notable is the
vport list, which is protected by a mutex, that will cause a panic if a softirq
receive while said mutex is locked. Additionaly, the ema_list, discussed here:
http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html
Can be corrupted if a list traversal occurs in softirq context at the same time
as a list delete in process context. And generally the lport state variables
will not be stable, and may lead to unpredictable results.
The most direct fix is to remove the bits from the above commit that allowed
fcoe_recv_frame to be called in softirq context. We just force all frames to be
handled by the per-cpu rx threads. This will allow the fcoe_if_destroy's use of
fcoe_percpu_clean to function properly, ensuring that no frames are being
received while the lport is being torn down.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Santosh Nayak <santoshprasadnayak@gmail.com>
Acked-by: Jack Wang <jack_wang@usish.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Xen dom0 needs to paravirtualize IO operations to the IO APIC,
so add a io_apic_ops for it to intercept. Do this as ops
structure because there's at least some chance that another
paravirtualized environment may want to intercept these.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: jwboyer@redhat.com
Cc: yinghai@kernel.org
Link: http://lkml.kernel.org/r/1332385090-18056-2-git-send-email-konrad.wilk@oracle.com
[ Made all the affected code easier on the eyes ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Polling for card hotplug events is a better option than using SDHI native
hotplug interrupt, because the latter option forces the controller to stay
permanently powered up and enabled.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Now that userspace is making use of kernel-provided sanitized headers for
working out supported interfaces, we need to be a bit more diligent with
matching the syscall definitions with their actual wiring/support state.
In theory it shouldn't hurt anything since sys_ni_syscall will ultimately
do the right thing, but there's also not much need to lie about legacy
x86 syscalls that we've never supported.
This tightens things up a bit for uClibc at least.
Suggested-by: Carmelo Amoroso <carmelo.amoroso@st.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Update the driver version number to better match version of out of tree
driver that has similar functionality.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This was pointed out to me by Xiaojun Zhang on Source Forge.
CC: Xiaojun Zhang <zhangxiaojun@sourceforge.net>
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Dan Carpenter noticed that ixgbevf initial default was different than
the rest. But the problem is broader than that, only one Intel driver (ixgb)
was doing it almost right.
The convention for default debug level should be consistent among
Intel drivers and follow established convention.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Old Microblaze toolchain supported "b" contstrains for
all register but it always points to general purpose reg.
New Microblaze toolchain is more strict in this
and general purpose register should be used there "r".
Signed-off-by: Michal Simek <monstr@monstr.eu>
If in big-endian mode, switch the PCI bus, too.
Tested on both litte-endian and big-endian sh7785lcr.
Signed-off-by: Thomas Schwinge <thomas@codesourcery.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
When DMA is enabled, sh-sci transfer begins with
uart_start()
sci_start_tx()
if (cookie_tx < 0) schedule_work()
Then, starts DMA when wq scheduled, -- (A)
process_one_work()
work_fn_rx()
cookie_tx = desc->submit_tx()
And finishes when DMA transfer ends, -- (B)
sci_dma_tx_complete()
async_tx_ack()
cookie_tx = -EINVAL
(possible another schedule_work())
This A to B sequence is not reentrant, since controlling variables
(for example, cookie_tx above) are not queues nor lists. So, they
must be invoked as A B A B..., otherwise results in kernel crash.
To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0
(represents "not used") to call schedule_work().
But cookie_tx will not be set (to a cookie, also means "used") until
in the middle of work queue scheduled function work_fn_tx().
This gap between the test and set allows the breakage of the sequence
under the very frequently call of uart_start().
Another gap between async_tx_ack() and another schedule_work() results
in the same issue, too.
This patch introduces a new condition "cookie_tx == 0" just to mark
it is "busy" and assign it within spin-locked region to fill the gaps.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
CHCR of SH7763, SH7764, SH7780 and SH7785 is constitution same as SH7757.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
