| Age | Commit message (Collapse) | Author |
|---|
|
Updates newly added stats from fc_get_host_stats,
added new function fc_exch_update_stats to
update exches related stats from fc_exch.c
by going thru internal ema_list elements.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Acked-by : Robert Love <robert.w.love@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
Adds stats to track FCP pkt and frame alloc
failure.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Acked-by : Robert Love <robert.w.love@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
The libfc is used by fcoe but fcoe agnostic,
and therefore should not have any fcoe references.
So renaming fcoe_dev_stats from libfc as its for fc_stats.
After that libfc is fcoe string free except some strings for
Open-FCoE.org.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Acked-by : Robert Love <robert.w.love@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Acked-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
The libfc provides more flexibility and with that
we can monitor some more FC specific stats for
FC exches or FCP error cases, this patch add
such new FC stats.
The patch adds *only* FC specific new stats to
existing fc_host attribute container.
Added stats names are self explanatory as
existing FC stats already has, however anyway
still added commentary along their definition
to describe them.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Acked-by : Robert Love <robert.w.love@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. Replace a field access from orphan by NULL in two
places.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier c;
expression E;
iterator name list_for_each_entry;
statement S;
@@
list_for_each_entry(c,...) { ... when != break;
when forall
when strict
}
...
(
c = E
|
*c
)
// </smpl>
Artem: fortunately, this did not cause any issues because we iterate the orphan
list using the elements count, so we never dereferenced the corrupted pointer.
This is why I do not send this patch to -stable. But otherwise - well spotted!
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
|
|
In the log reply code we assume that 'c->lhead_offs' is known and may be
non-zero, which is not the case because we do not store it in the master
node and have to find out by scanning on every mount. Knowing this fact
allows us to simplify the log scanning loop a bit and remove a couple
of unneeded local variables.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
|
|
This patch adds another debugfs knob which switches UBIFS to R/O mode.
I needed it while trying to reproduce the 'first log node is not CS node'
bug. Without this debugfs knob you have to perform a power cut to repruduce
the bug. The knob is named 'ro_error' and all it does is it sets the
'ro_error' UBIFS flag which makes UBIFS disallow any further writes - even
write-back will fail with -EROFS. Useful for debugging.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
|
|
Fix the following compilation warning:
fs/ubifs/dir.c: In function 'ubifs_rename':
fs/ubifs/dir.c:972:15: warning: 'saved_nlink' may be used uninitialized
in this function
Use the 'uninitialized_var()' macro to get rid of this false-positive.
Artem: massaged the patch a bit.
Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
|
|
While this code is still being shuffled around the KBUILD_MODNAME value
isn't particularly useful, switch to something a bit more useful.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
UBIFS has a feature called "empty space fix-up" which is a quirk to work-around
limitations of dumb flasher programs. Namely, of those flashers that are unable
to skip NAND pages full of 0xFFs while flashing, resulting in empty space at
the end of half-filled eraseblocks to be unusable for UBIFS. This feature is
relatively new (introduced in v3.0).
The fix-up routine (fixup_free_space()) is executed only once at the very first
mount if the superblock has the 'space_fixup' flag set (can be done with -F
option of mkfs.ubifs). It basically reads all the UBIFS data and metadata and
writes it back to the same LEB. The routine assumes the image is pristine and
does not have anything in the journal.
There was a bug in 'fixup_free_space()' where it fixed up the log incorrectly.
All but one LEB of the log of a pristine file-system are empty. And one
contains just a commit start node. And 'fixup_free_space()' just unmapped this
LEB, which resulted in wiping the commit start node. As a result, some users
were unable to mount the file-system next time with the following symptom:
UBIFS error (pid 1): replay_log_leb: first log node at LEB 3:0 is not CS node
UBIFS error (pid 1): replay_log_leb: log error detected while replaying the log at LEB 3:0
The root-cause of this bug was that 'fixup_free_space()' wrongly assumed
that the beginning of empty space in the log head (c->lhead_offs) was known
on mount. However, it is not the case - it was always 0. UBIFS does not store
in it the master node and finds out by scanning the log on every mount.
The fix is simple - just pass commit start node size instead of 0 to
'fixup_leb()'.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
Cc: stable@vger.kernel.org [v3.0+]
Reported-by: Iwo Mergler <Iwo.Mergler@netcommwireless.com>
Tested-by: Iwo Mergler <Iwo.Mergler@netcommwireless.com>
Reported-by: James Nute <newten82@gmail.com>
|
|
Use a more current logging style.
Add pr_fmt to prefix dmaengine: to messages.
Convert printk(KERN_ERR to pr_err(.
Convert embedded function name use to "%s: ", __func__
Align arguments.
Original-patch-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Using the "private" field from struct dma_chan is deprecated. The sh
dmaengine driver now also supports the preferred DMA channel allocation
and configuration method, using a standard filter function and a channel
configuration operation. This patch updates sh_mmcif to use this new
method.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Chris Ball <cjb@laptop.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
This patch extends the sh dmaengine driver to support the preferred channel
selection and configuration method, instead of using the "private" field
from struct dma_chan. We add a standard filter function to be used by
slave drivers instead of implementing their own ones, and add support for
the DMA_SLAVE_CONFIG control operation, which must accompany the new
channel selection method. We still support the legacy .private channel
allocation method to cater for a smooth driver migration.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
[applied a trvial checkpath fix]
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Initially struct shdma_slave has been introduced with the only member - an
unsigned slave ID - to describe common properties of DMA slaves in an
extensible way. However, experience shows, that a slave ID is indeed the
only parameter, needed to identify DMA slaves. This is also, what is used
by the core dmaengine API in struct dma_slave_config. We switch to using
the slave_id directly, instead of passing a pointer to struct shdma_slave
to improve compatibility with the core. We also make the slave_id signed
for easier error checking.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Using struct dma_chan::private is deprecated. To update the shdma driver to
stop using it we first have to eliminate internal runtime uses of it. After
that we will also be able to stop using it for channel configuration.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
The SIU ALSA driver is not using the DMA device pointer for DMA channel
filtering any more, it can be now removed.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
DMA channels are filtered based on slave IDs, no need to additionally filter
on DMA device.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
dmae_find_slave() needs only the slave_id field from the slave object, no
need to pass the pointer to the object, pass the slave_id directly.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
|
|
Turn on the pin widget's PIN_OUT bit from playback prepare. The pin is
enabled in open, but is disabled in hdmi_init_pin which is called during
system resume. This causes a system suspend/resume during playback to
mute HDMI/DP. Enabling the pin in prepare instead of open allows calling
snd_pcm_prepare after a system resume to restore audio.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Merge Linus tree into drm to fixup conflicts in radeon code for further
testing before upstream merge.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/radeon/radeon_gart.c
|
|
Userspace uses long in quite a few places more than the kernel. Which
gives me neat proof that I'm the only guy on this side of the galaxy
who ever tried to run glxgears on a 64bit machine with sis graphics on
linux.
Note that the longs in drm_sis_mem_t aren't aligned properly, so this
won't even work with 32bit userspace on 64bit kernel as-is. Hence the
patch can't break that, either.
Nope, I'm not nuts enough to write the 32bit ioctl compat layer for
this and test it with some wine app. Even though hunting the ebay
dungeons for a sis card actually supported by the mesa drivers casts
some doubts on this ...
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
With the last patch to ditch DMA_QUEUE support, we should be able
to call the dma cleanup uncoditionally, even when the master has
disappeared.
Do so because it just makes more sense.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Absolutely unused. All the values are only ever initialized and
then used at most in some debug printout functions.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Only one driver (i810) even sets that flag. Now the actual locking
code uncoditionally promotes lock->context to an unsigned int.
Closer inspection of the userspace reveals that the drm lock context
is defined as an unsigned int (at least on linux). I suspect we just
have a strange case of signedness confusion going on.
Tested on my i815, doesn't seem to break anything.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
All leftover users either haven't set DRIVER_HAVE_DMA, in which
case this will never be called, or use the drm_core implementation.
Call that directly in the only callsite.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The reclaim_buffers function of the savage driver actually wants to run
with the hw_lock held - at least there are printks in the call-chain
to that effect. But the drm core only calls reclaim_buffers as used
by savage _after_ forcefully dropping the hwlock (in case it's still
hold by the closing fd).
So do the same idlelock dance as for the other dma drivers and hope
that papers over any issues.
v2: Don't let the idlelock linger around.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
i810 was the last user of this code, with that gone, kill it.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This reverts commit 6e877b576ddf7cde5db2e9a6dcb56fef0ea77e64,
reinstating the original commit:
commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Oct 25 23:51:24 2011 +0200
drm/i810: cleanup reclaim_buffers
My dear old i815 always hits the deadlocked on reclaim_buffers
warning. Switch over to the idlelock duct-tape on hope that
works better. I've fired up my i815 and now closing glxgears doesn't
take 5 seconds anymore. \o/
The original problem with that was that I've moved it ahead in the
series so that it could be included despite some patches not being
ready quite yet. The little problem is that this patch required some
of the previous rework to work correctly.
Now that everything is in the right order again, this actually works
on my i810 and does speed up closing gl apps as the original commit
claimed. Without hanging the machine, as the revert says.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The only two users are now folded into the drivers preclose functions,
so this is unused.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Like for via.
v2: Actually drop the idlelock again if taken.
v3: Fixup.
v4: Fixup the "has master" vs. "is master" confusion the refactor
introduced.
v5: Drop the idlelock in the early return path.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
A few things
- kill reclaim_buffers, it's never ever called because via does not set
DRIVER_HAVE_DMA
- inline the idlelock dance into the buffer reclaim logic and make it
a simple preclose cleanup function
- directly call the the dma_quiescent function and kill the needless
if check.
v2: Actually drop the idlelock when we take it. Reported by James
Simmons.
v3: Rebased onto latest drm-next.
v4: Fixup the refactor.
v5: More fixup the refactor - I've accidentally changed the check for
any master to checking whether the closing fd is the master.
v6: Don't forget to drop the idlelock in the early return path, too.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This ports over the dpms code from udlfb, and should mean
a better chance of turning on some udl devices.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This check the root ports supported link speeds and enables
GEN2 mode if the 5.0 GT link speed is available.
The first 3.0 cards are SI so they will probably need more investigation.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This should work for PCIE3.0 as well.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
We need these for detecting the max link speed for drm drivers.
Acked-by: Bjorn Helgaas <bhelgass@google.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Print various CP register that have valuable informations regarding
GPU lockup.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
we are referencing the pointer after doing alloc_apertures,
as alloc_apertures kzallocs, the kzalloc may fail and we get a NULL.
so we need to check for NULL before we dereference this pointer
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This could previously fail if either of the enabled displays was using a
horizontal resolution that is a multiple of 128, and only the leftmost column
of the cursor was (supposed to be) visible at the right edge of that display.
The solution is to move the cursor one pixel to the left in that case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33183
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The passed mode must not be modified by the operation, make it const.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
It's unused. At it confused me quite a bit until I've discovered that.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Go through the interface vtable instead, because not everyone might be
using the crtc helper code.
Cc: dri-devel@lists.freedesktop.org
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Ok, this requires quite a dance to actually hit:
1) We plug in a 2nd screen, enable it in both X and (by vt-switching)
in the fbcon.
2) We disable that screen again in with xrandr.
3) We vt-switch again, so that fbcon displays on the 2nd screen, but X
on the first screen. This obviously needs a driver that doesn't switch
off unused functions when regaining the VT.
3) When X controls the vt, we unplug that screen.
Now drm_fb_helper_hotplug_event we noticed that that some crtcs are
bound, but because we still have the fbcon on the 2nd screeen we also
have bound set. Which means the fbcon wrongly assumes it's in control
of everything an happily disables the output on the 2nd screen, but
enables its fb on the first screen.
Work around this issue by counting how many crtcs are bound and how
many are bound to fbcon and assuming that when fbcon isn't bound to
all of them, it better not touch the output configuration.
Conceptually this is the same as only restoring the fbcon output
configuration on the driver's ->lastclose, when we're sure that no one
else is using kms. So this should be consistent with existing kms
drivers.
Chris has created a separate patch for the intel ddx, but I think we
should fix this issue here regardless - the fbcon messing with the
output config while it's not fully in control simply isn't a too
polite behaviour.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772
Tested-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Instead of only setting the FCOE segmentation offload and CRC offload flags
if we enable FCoE, we could just set them always since there are no
modifications needed to the hardware or adapter FCoE structure in order to
use these features.
The advantage to this is that if FCoE enablement fails, for example because
SR-IOV was enabled on 82599, we will still have use of the FCoE
segmentation offload and Tx/Rx CRC offloads which should still help to
improve the FCoE performance.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
drm-next
This contains all the radeon documentation rebased on top of the ib fixes.
* 'next' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: fix SS setup for DCPLL
drm/radeon: fix up pll selection on DCE5/6
drm/radeon: start to document evergreen.c
drm/radeon: start to document the functions r100.c
drm/radeon: document VM functions in radeon_gart.c (v3)
drm/radeon: document non-VM functions in radeon_gart.c (v2)
drm/radeon: document radeon_ring.c (v4)
drm/radeon: document radeon_fence.c (v2)
drm/radeon: document radeon_asic.c
drm/radeon: document radeon_irq_kms.c
drm/radeon: document radeon_kms.c
drm/radeon: document radeon_device.c (v2)
drm/radeon: add rptr save support for r1xx-r5xx
drm/radeon: update rptr saving logic for memory buffers
drm/radeon: remove radeon_ring_index()
drm/radeon: update ib_execute for SI (v2)
drm/radeon: fix const IB handling v2
drm/radeon: let sa manager block for fences to wait for v2
drm/radeon: return an error if there is nothing to wait for
|
|
The current logic is enabling anti-spoof on all pools and then clearing
anti-spoof on just the first PF pool. The correct approach is to only set
anti-spoof on the VF pools and to leave all of the PF pools unchecked.
This allows for items such as FCoE to use adjacent pools within the PF for
transmit and receive queues without the traffic being blocked by this
security feature.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This change corrects an issue in which an FCoE enabled adapter was always
setting the FCoE SAN MAC MPSAR register to 0x1. This results in the first
VF being assigned the SAN MAC address in the case of SR-IOV and as such is
incorrect. To resolve this I am adding a new function that will update the
SAN MAC pool address after reset.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This patch changes the behavior of the FCoE configuration so that it is
much closer to how the main body of the ixgbe driver works for ring
allocation.
The first piece is the ixgbe_fcoe_ddp_enable/disable calls. These allocate
the percpu values and if successful set the fcoe_ddp_xid value indicating
that we can support DDP.
The next piece is the ixgbe_setup/free_ddp_resources calls. These are
called on open/close and will allocate and free the DMA pools.
Finally ixgbe_configure_fcoe is now just register configuration. It can go
through and enable the registers for the FCoE redirection offload, and FIP
configuration without any interference from the DDP pool allocation.
The net result of all this is two fold. First it adds a certain amount of
exception handling. So for example if ixgbe_setup_fcoe_resources fails we
will actually generate an error in open and refuse to bring up the
interface.
Secondly it provides a much more graceful failure case than the previous
model which would skip setting up the registers for FCoE on failure to
allocate DDP resources leaving no Rx functionality enabled instead of just
disabling DDP.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This change merges the 2 statistics values for noddp and noddp_ext_buff
and the dma_pool into a single structure that can be allocated per CPU.
The advantages to this are several fold. First we only need to do one
alloc_percpu call now instead of 3, so that means less overhead for
handling memory allocation failures. Secondly in the case of
ixgbe_fcoe_ddp_setup we only need to call get_cpu once which makes things a
bit cleaner since we can drop a put_cpu() from the exception path.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This change makes it so we always use the FCoE redirection table. We just
set all 8 entries to the same value in the case of only having one queue
for FCoE.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
