| Age | Commit message (Collapse) | Author |
|---|
|
Add ethtool support to retrieve and set the transmit and receive ring
sizes. This allows runtime tuning of these parameters, which can
result in better throughput with gigabit parts.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Rather than keep subtracting four off the packet length throughout the
receive path, do it at the point we read the packet length from the
descriptor.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Avoid checking for the enhanced buffer descriptor flag and the receive
checksumming/vlan flags - we now only set these feature flags if we
already know that we have enhanced buffer descriptors.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
descriptors
Only set the vlan tag and ip checksumming options if we have enhanced
buffer descriptors - enhanced descriptors are required for these
features.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The receive checksum flag is only changed upon ethtool configuration,
so move it into the flags member. In any case, this is checked
alongside the BUFDESC_EX flag.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add a new flags field to contain the mostly static driver configuration,
the first of which is the bufdesc_ex flag.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Both fec_restart() and fec_stop() both perform a reset of the FEC. This
reset can result in an in-process MDIO transfer being terminated, which
can lead to the MDIO read/write functions timing out. Add some locking
to prevent this occuring.
We can't use a spinlock for this as the MDIO accessor functions use
wait_for_completion_timeout(), which sleeps.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
There is a commonality to fec_enet_mdio_read() and fec_enet_mdio_write()
which can be factored out. Factor that commonality out, since we need
to add some locking to prevent resets interfering with MDIO accesses.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
When SG is enabled, we must ensure that there are up to 1+MAX_SKB_FRAGS
free entries in the ring. When SG is disabled, this can be reduced to
one, and we can allow smaller rings. Adjust this setting according to
the state of SG.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Extend the previous commit to the receive descriptor ring as well. This
gets rid of the two nextdesc/prevdesc functions, since we now just need
to get the descriptor for an index instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Maintaining the transmit ring position via pointers is inefficient,
especially when it involves complex pointer manipulation, and overlap
with the receive descriptor logic.
Re-implement this using indexes, and a single function which returns
the descriptor (appropriate to the descriptor type). As an additional
benefit, using a union allows cleaner access to the descriptor.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Using a union gives clearer C code than the existing solution, and
allows the removal of some odd code from the receive path whose
purpose was to merely store the enhanced buffer descriptor.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Just as we need a barrier in the transmit path, we also need a barrier
in the receive path to ensure that we don't modify a handed over
descriptor.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Ensure that the writes to the descriptor data is visible to the hardware
before the descriptor is handed over to the hardware.
Having discussed this with Will Deacon, we need a wmb() between writing
the descriptor data and handing the descriptor over to the hardware.
The corresponding rmb() is in the ethernet hardware.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The FEC maintains two pointers into the transmit ring:
next - this is the insertion point in the ring, and points at a free
entry which can be written to.
dirty - this is the last dirty entry which we successfully cleaned, and
is always incremented prior to cleaning an entry.
The calculation used for the number of free packets is slightly buggy,
which is:
entries = dirty - next - 1
if (entries < 0)
entries += size;
Let's take some examples:
At ring initialisation, dirty is set to size-1, and next is set to 0.
This gives:
entries = size-1 - 0 - 1 = size - 2 => size - 2
But hang on, we have no packets in the empty ring, so why "size - 2" ?
Let's also check if we back the pointers up by one position - so
dirty=size-2, next=size-1.
entries = size-2 - size-1 - 1 = -2 - -1 - 1 = -2 => size - 2
Okay, so that's the same. Now, what about the "ring full" criteria.
We can never completely fill the transmit ring, because a completely
full ring is indistinguishable from a completely empty ring. We
reserve one entry to permit us to keep a distinction.
Hence, our "full" case is when both pointers are equal, so dirty=size-1,
next=size-1.
entries = size-1 - size-1 - 1 = -1 => size - 1
This is where things break down - in this case, the function is not
returning the number of free entries in the ring, because it should
be zero!
Fix this by changing the calculation to something which reflects the
actual ring behaviour:
entries = dirty - next;
if (entries < 0)
entries += size;
Plugging the above three cases into this gives:
entries = size-1 - 0 = size - 1 => size - 1
entries = size-2 - size-1 = -1 => size - 1
entries = size-1 - size-1 = 0 => 0
Here, we have more correct behaviour (remembering that we have reserved
one entry as described above).
The perverse thing is that every test at this function's called site
almost took account of the off-by-one error. Let's fix this to have
saner semantics - returning the number of permissible free entries in
the ring which can then be compared using expected tests against our
required numbers of packets.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
It is wasteful to keep checking whether we're stopped, and the number
of free packets to see whether we should restart the queue for each
entry in the ring which we process. Move this to the end of the
processing so we check once per ring clean.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Clean up the various callsites to this function; most callsites
are using a temporary variable and immediately following it with
a test. There is no need of a temporary variable for this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Move the calculation of the transmit DMA ring address to fec_enet_init()
so the CPU and DMA ring address calculations are localised.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Increasing the receive ring size allows more packets to be received
before we run out of ring entries to store the packets. With 16
ring entries, this corresponds with a maximum of 16 * 1534 bytes,
or just 24KiB. At gigabit speeds, this would take around 200us to
fill. Increasing this to 512 entries gives us more scope when we
have busy workloads, as it increases the ring to 767K, and around
6.3ms.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add support for byte queue limits, which allows the network schedulers
to control packet latency and packet queues more accurately. Further
information on this feature can be found at
https://lwn.net/Articles/469652/
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
UDP performance is extremely poor. iperf reports UDP receive speeds in
the range of 50Mbps with a high packet loss. The interface typically
reports a few thousand overrun errors per iperf run. This is far from
satisfactory.
Adjust the receive FIFO thresholds to reduce the number of errors.
Firstly, we decrease RAFL (receive almost full threshold) to the minimum
value of 4, which gives us the maximum available space in the FIFO prior
to indicating a FIFO overrun condition.
Secondly, we adjust the RSEM value to send a XOFF pause frame early
enough that an in-progress transmission can complete without overflowing
the FIFO.
Document these registers and the changes being made in the driver.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The FEC hardware in iMX6 is capable of separate control of each flow
control path: the receiver can be programmed via the receive control
register to detect flow control frames, and the transmitter can be
programmed via the receive FIFO thresholds to enable generation of
pause frames.
This means we can implement the full range of flow control: both
symmetric and asymmetric flow control. We support ethtool configuring
all options: forced manual mode, where each path can be controlled
individually, and autonegotiation mode.
In autonegotiation mode, the tx/rx enable bits can be used to influence
the outcome, though they don't precisely define which paths will be
enabled. One combination we don't support is "symmetric only" since we
can always configure each path independently, a case which Linux seems
to often get wrong.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Verify that the checksum offset is inside the packet header before
we zero the entry. This ensures that we don't perform an out of
bounds write.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
On transmit timeout or close, dirty transmit descriptors were not being
correctly cleaned: the only time that DMA mappings are cleaned is when
scanning the TX ring after a transmit interrupt. Fix this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The FEC receive error handling suffers from several problems:
1. When a FIFO overrun error occurs, the descriptor is closed and
reception stops. The remainder of the packet is discarded by the
MAC.
The documentation states that other status bits are invalid, and they
will be zero. However, practical experience on iMX6 shows this is
not the case - the CR (crc error) bit will also be set.
This leads to each FIFO overrun event incrementing both the fifo
error count and the crc error count, which makes the error statistics
less useful. Fix this by ignoring all other status bits of the FIFO
overrun is set, and add a comment to that effect.
2. A late collision invalidates all but the overrun condition; the
remaining error conditions must be ignored.
3. Despite accounting for errors, it continues to receive the errored
packets and pass them into the network stack as if they were
correctly received.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is a set of two small fixes, both to code which went in during
the merge window: cxgb4i has a scheduling in atomic bug in its new
ipv6 code and uas fails to work properly with the new scsi-mq code"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
[SCSI] uas: disable use of blk-mq I/O path
[SCSI] cxgb4i: avoid holding mutex in interrupt context
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/josh/linux
Pull kconfig fixes for tiny setups from Josh Triplett:
"Two Kconfig bugfixes for 3.17 related to tinification. These fixes
make the Kconfig "General Setup" menu much more usable"
* tag 'tiny/kconfig-for-3.17' of https://git.kernel.org/pub/scm/linux/kernel/git/josh/linux:
init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu
init/Kconfig: Hide printk log config if CONFIG_PRINTK=n
|
|
commit 03b8c7b623c80af264c4c8d6111e5c6289933666 ("futex: Allow
architectures to skip futex_atomic_cmpxchg_inatomic() test") added the
HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in
the middle of the options for the EXPERT menu. However,
HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops
placing items in the EXPERT menu, and displays the remaining several
EXPERT items (starting with EPOLL) directly in the General Setup menu.
Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make
HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the
subsequent items display as part of the EXPERT menu again; the EMBEDDED
menu now appears as the next top-level item in the General Setup menu,
which makes General Setup much shorter and more usable.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Cc: stable <stable@vger.kernel.org>
|
|
The buffers sized by CONFIG_LOG_BUF_SHIFT and
CONFIG_LOG_CPU_MAX_BUF_SHIFT do not exist if CONFIG_PRINTK=n, so don't
ask about their size at all.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Cc: stable <stable@vger.kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"Two i2c driver bugfixes"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: qup: Fix order of runtime pm initialization
i2c: rk3x: fix 0 length write transfers
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull trace ring buffer iterator fix from Steven Rostedt:
"While testing some new changes for 3.18, I kept hitting a bug every so
often in the ring buffer. At first I thought it had to do with some
of the changes I was working on, but then testing something else I
realized that the bug was in 3.17 itself. I ran several bisects as
the bug was not very reproducible, and finally came up with the commit
that I could reproduce easily within a few minutes, and without the
change I could run the tests over an hour without issue. The change
fit the bug and I figured out a fix. That bad commit was:
Commit 651e22f2701b "ring-buffer: Always reset iterator to reader page"
This commit fixed a bug, but in the process created another one. It
used the wrong value as the cached value that is used to see if things
changed while an iterator was in use. This made it look like a change
always happened, and could cause the iterator to go into an infinite
loop"
* tag 'trace-fixes-v3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ring-buffer: Fix infinite spin in reading buffer
|
|
Pull cifs/smb3 fixes from Steve French:
"Fix for CIFS/SMB3 oops on reconnect during readpages (3.17 regression)
and for incorrectly closing file handle in symlink error cases"
* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
CIFS: Fix readpages retrying on reconnects
Fix problem recognizing symlinks
|
|
Pull raid5 discard fix from Neil Brown:
"One fix for raid5 discard issue"
* tag 'md/3.17-final-fix' of git://neil.brown.name/md:
md/raid5: disable 'DISCARD' by default due to safety concerns.
|
|
Pull drm fixes from Dave Airlie:
"Nothing too major or scary.
One i915 regression fix, nouveau has a tmds regression fix, along with
a regression fix for the runtime pm code for optimus laptops not
restoring the display hw correctly"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau: make sure display hardware is reinitialised on runtime resume
drm/nouveau: punt fbcon resume out to a workqueue
drm/nouveau: fix regression on original nv50 board
drm/nv50/disp: fix dpms regression on certain boards
drm/i915: Flush the PTEs after updating them before suspend
|
|
The uas driver uses the block layer tag for USB3 stream IDs. With
blk-mq we can get larger tag numbers that the queue depth, which breaks
this assumption. A fix is under way for 3.18, but sits on top of
large changes so can't easily be backported. Set the disable_blk_mq
path so that a uas device can't easily crash the system when using
blk-mq for SCSI.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These are three regression fixes (cpufreq core, pcc-cpufreq, i915 /
ACPI) and one trivial fix for a callback return value mismatch in the
cpufreq integrator driver.
Specifics:
- A recent cpufreq core fix went too far and introduced a regression
in the system suspend code path. Fix from Viresh Kumar.
- An ACPI-related commit in the i915 driver that fixed backlight
problems for some Thinkpads inadvertently broke a Dell machine (in
3.16). Fix from Aaron Lu.
- The pcc-cpufreq driver was broken during the 3.15 cycle by a commit
that put wait_event() under a spinlock by mistake. Fix that
(Rafael J Wysocki).
- The return value type of integrator_cpufreq_remove() is void, but
should be int. Fix from Arnd Bergmann"
* tag 'pm+acpi-3.17-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: update 'cpufreq_suspended' after stopping governors
ACPI / i915: Update the condition to ignore firmware backlight change request
cpufreq: integrator: fix integrator_cpufreq_remove return type
cpufreq: pcc-cpufreq: Fix wait_event() under spinlock
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
final regression fix for 3.17.
* tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Flush the PTEs after updating them before suspend
|
|
The runtime pm calls need to be done before populating the children via the
i2c_add_adapter call. If this is not done, a child can run into issues trying
to do i2c read/writes due to the pm_runtime_sync failing.
Signed-off-by: Andy Gross <agross@codeaurora.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
|
|
i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Tested-by: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org
|
|
* pm-cpufreq:
cpufreq: update 'cpufreq_suspended' after stopping governors
cpufreq: integrator: fix integrator_cpufreq_remove return type
cpufreq: pcc-cpufreq: Fix wait_event() under spinlock
* acpi-video:
ACPI / i915: Update the condition to ignore firmware backlight change request
|
|
Merge fixes from Andrew Morton:
"5 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm: page_alloc: fix zone allocation fairness on UP
perf: fix perf bug in fork()
MAINTAINERS: change git URL for mpc5xxx tree
mm: memcontrol: do not iterate uninitialized memcgs
ocfs2/dlm: should put mle when goto kill in dlm_assert_master_handler
|
|
The zone allocation batches can easily underflow due to higher-order
allocations or spills to remote nodes. On SMP that's fine, because
underflows are expected from concurrency and dealt with by returning 0.
But on UP, zone_page_state will just return a wrapped unsigned long,
which will get past the <= 0 check and then consider the zone eligible
until its watermarks are hit.
Commit 3a025760fc15 ("mm: page_alloc: spill to remote nodes before
waking kswapd") already made the counter-resetting use
atomic_long_read() to accomodate underflows from remote spills, but it
didn't go all the way with it.
Make it clear that these batches are expected to go negative regardless
of concurrency, and use atomic_long_read() everywhere.
Fixes: 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by
calling perf_event_free_task() when failing sched_fork() we will not yet
have done the memset() on ->perf_event_ctxp[] and will therefore try and
'free' the inherited contexts, which are still in use by the parent
process. This is bad..
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Sylvain 'ythier' Hitier <sylvain.hitier@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The repository for mpc5xxx has been moved, update git URL to new
location.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The cgroup iterators yield css objects that have not yet gone through
css_online(), but they are not complete memcgs at this point and so the
memcg iterators should not return them. Commit d8ad30559715 ("mm/memcg:
iteration skip memcgs not yet fully initialized") set out to implement
exactly this, but it uses CSS_ONLINE, a cgroup-internal flag that does
not meet the ordering requirements for memcg, and so the iterator may
skip over initialized groups, or return partially initialized memcgs.
The cgroup core can not reasonably provide a clear answer on whether the
object around the css has been fully initialized, as that depends on
controller-specific locking and lifetime rules. Thus, introduce a
memcg-specific flag that is set after the memcg has been initialized in
css_online(), and read before mem_cgroup_iter() callers access the memcg
members.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Hugh Dickins <hughd@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org> [3.12+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
In dlm_assert_master_handler, the mle is get in dlm_find_mle, should be
put when goto kill, otherwise, this mle will never be released.
Signed-off-by: Alex Chen <alex.chen@huawei.com>
Reviewed-by: Joseph Qi <joseph.qi@huawei.com>
Reviewed-by: joyce.xue <xuejiufei@huawei.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fix from Mauro Carvalho Chehab:
"One last time regression fix at em28xx. The removal of .reset_resume
broke suspend/resume on this driver for some devices.
There are more fixes to be done for em28xx suspend/resume to be better
handled, but I'm opting to let them to stay for a while at the media
devel tree, in order to get more tests. So, for now, let's just
revert this patch"
* tag 'media/v3.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
Revert "[media] media: em28xx - remove reset_resume interface"
|
