Troy Kisky says:
====================
net: fec: cleanup/fixes
V2 is a rebase on top of johannes endian-safe patch and
is only the 1st eight patches.
The testing for this series was done on a nitrogen6x.
The base commit was
commit b45efa30a6
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Testing showed no change in performance.
Testing used imx_v6_v7_defconfig + CONFIG_MICREL_PHY.
The processor was running at 996Mhz.
The following commands were used to get the transfer rates.
On an x86 ubunto system,
iperf -s -i.5 -u
On a nitrogen6x board, running via SD Card.
I first stopped some background processes
stop cron
stop upstart-file-bridge
stop upstart-socket-bridge
stop upstart-udev-bridge
stop rsyslog
stop dbus
killall dhclient
echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
taskset 0x2 iperf -c 192.168.0.201 -u -t60 -b500M -r
There is a branch available on github with this series, and the rest of
my fec patches, for those who would like to test it.
https://github.com:boundarydevices/linux-imx6.git branch net-next_master
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Unmap initial buffer on error.
Don't free skb until it has been unmapped.
Move cbd_bufaddr assignment closer to the mapping function.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If you don't own it, you shouldn't write to it.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Only the interrupt routine processes this condition.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is no need for complex macros every time we need to activate
a queue. Also, no need to call skb_get_queue_mapping when we already
know which queue it is using.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When first initialized, cur_tx points to the 1st
entry in the queue, and dirty_tx points to the last.
At this point, fec_enet_get_free_txdesc_num will
return tx_ring_size -2. If tx_ring_size -2 entries
are now queued, then fec_enet_get_free_txdesc_num
should return 0, but it returns tx_ring_size instead.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On an overrun, the other flags are not
valid, so don't check them.
Also, don't pass bad frames up the stack.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Setting the FTRL register will stop the fec from
trying to use multiple receive buffers.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Convert this driver to use clkdev_create() instead of
clk_register_clkdevs(). The latter API is only used by this driver,
although this driver only allocates one clk to add anyway.
Furthermore, this driver allocates the clk_lookup structure with
devm, but clkdev_drop() will free that structure when passed,
leading to a double free when this driver is removed. Clean it
all up and pave the way for the removal of clk_register_clkdevs().
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
STM32F429 allows to remap FMC SDRAM Bank 1 from 0xc0000000 to 0x0,
by writing 0x4 to SYSCFG_MEMRMP register.
As mentionned in the reference manual (see chapter 9.3.1), the performance
gain is really interresting:
"In remap mode at address 0x0000 0000, the CPU can access the external
memory via ICode bus instead of System bus which boosts up the
performance."
These are the dhrystone results with and without the remap enabled:
Default (SDRAM in 0xc0000000):
---------------------------------
Microseconds for one run through Dhrystone: 31.8
Dhrystones per Second: 31416.9
Remap (SDRAM in 0x0000000):
-----------------------------
Microseconds for one run through Dhrystone: 20.6
Dhrystones per Second: 48520.1
This patch first change the SDRAM start address to 0x0 for STM32429i-EVAL
board, and also set the dma-range property as the other masters than the M4
CPU still see SDRAM in 0xc0000000.
Note that the Discovery board cannot benefit from this feature, since the
SDRAM is connected to Bank 2.
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
This patch selects USART1 pin configuration on PA9/PA10 pins
for both Eval and Disco boards.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
The STM32F429 MCU has 11 GPIO banks, with 16 pins per bank.
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
After the drm_device_is_unplugged() was removed, the 'dev' variable is now
unused, and we get a warning for that:
drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_mmap':
drivers/gpu/drm/msm/msm_fbdev.c:65:21: error: unused variable 'dev' [-Werror=unused-variable]
This removes the variable as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e9f8250f2f ("drm/msm: remove the drm_device_is_unplugged check")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455181810-3910161-1-git-send-email-arnd@arndb.de
Intel BXT/APL use a card detect GPIO however the host controller
will not enable bus power unless it's card detect also reflects
the presence of a card. Unfortunately those 2 things race which
can result in commands not starting, after which the controller
does nothing and there is a 10 second wait for the driver's
10-second timer to timeout.
That is fixed by having the driver look also at the present state
register to determine if the card is present. Consequently, provide
a 'get_cd' mmc host operation for BXT/APL that does that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Intel BXT/APL use a card detect GPIO however the host controller
will not enable bus power unless it's card detect also reflects
the presence of a card. Unfortunately those 2 things race which
can result in commands not starting, after which the controller
does nothing and there is a 10 second wait for the driver's
10-second timer to timeout.
That is fixed by having the driver look also at the present state
register to determine if the card is present. Consequently, provide
a 'get_cd' mmc host operation for BXT/APL that does that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Drivers may need to provide their own get_cd() mmc host op, but
currently the internals of the current op (sdhci_get_cd()) are
provided by sdhci_do_get_cd() which is also called from
sdhci_request().
To allow override of the get_cd functionality, change sdhci_request()
to call ->get_cd() instead of sdhci_do_get_cd().
Note, in the future the call to ->get_cd() will likely be removed
from sdhci_request() since most drivers don't need actually it.
However this change is being done now to facilitate a subsequent
bug fix.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
In the past, fixes for specific hardware devices were implemented
in sdhci using quirks. That approach is no longer accepted because
the growing number of quirks was starting to make the code difficult
to understand and maintain.
One alternative to quirks, is to allow drivers to override the default
mmc host operations. This patch makes it easy to do that, and it is
needed for a subsequent bug fix, for which separate patches are
provided.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Add support for booting secondary CPUs on MT7623.
Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This adds basic chip support for Mediatek MT7623.
Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This adds a DT binding documentation for the MT7623 SoC from Mediatek.
Signed-off-by: John Crispin <blogic@openwrt.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
The fake agp driver for the intel graphics gart is only needed for ums
support. And we ditched that a long time ago:
commit 03dae59c72
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jul 23 16:27:25 2014 +0200
drm/i915: Ditch UMS config option
With this there's no longer the problem that 2 drivers (fake agp
driver and the drm/i915 driver) fight over the same piece, which fixes
apparent dma leaks detected by CONFIG_DMA_API_DEBUG.
Note that the leak isn't real since intel-gtt refcounts and will tear
down eventually. But the debug code assumes that when the i915 driver
unbinds from the pci device everything should be gone. Which isn't the
case if we have intel-agp enabled - userspace might need it. But by
ditching this intel-gtt setup and teardown is completely tied to the
livetime of the "real" driver.
While at it untangle the init ordering a bit - the fake agp wouldn't
be initialized correctly if i915.ko loads first. Which isn't a problem
since when i915 loads in kms mode you won't need the fake agp support
needed by the ums driver ...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93793
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453901881-26425-3-git-send-email-daniel.vetter@ffwll.ch
Depending on the configuration either the 32 or 64 bit version of
elf_check_arch() is defined. parse_crash_elf{32|64}_headers() does
some basic verification of the ELF header via
vmcore_elf{32|64}_check_arch() which happen to map to elf_check_arch().
Since the implementation 32 and 64 bit version of elf_check_arch()
differ, we use the wrong type:
In file included from include/linux/elf.h:4:0,
from fs/proc/vmcore.c:13:
fs/proc/vmcore.c: In function 'parse_crash_elf64_headers':
>> arch/mips/include/asm/elf.h:228:23: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
struct elfhdr *__h = (hdr); \
^
include/linux/crash_dump.h:41:37: note: in expansion of macro 'elf_check_arch'
#define vmcore_elf64_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
^
fs/proc/vmcore.c:1015:4: note: in expansion of macro 'vmcore_elf64_check_arch'
!vmcore_elf64_check_arch(&ehdr) ||
^
Therefore, we rather define vmcore_elf{32|64}_check_arch() as a
basic machine check and use it also in binfm_elf?32.c as well.
Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Suggested-by: Maciej W. Rozycki <macro@imgtec.com>
Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12529/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The ARM GICv3 specification mentions the need for dsb after a read
from the ICC_IAR1_EL1 register:
4.1.1 Physical CPU Interface:
The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1
on the state of a returned INTID are not guaranteed
to be visible until after the execution of a DSB.
Not having this could result in missed interrupts, so let's add the
required barrier.
[Marc: fixed commit message]
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
EOImode1 is only used for the root controller and hence only the root
controller uses the eoimode1 functions for handling interrupts. However,
if the root controller supports EOImode1, then the EOImodeNS bit will be
set for all GICs, enabling EOImode1. This is not what we want and this
causes interrupts on non-root GICs to only be dropped in priority but
never deactivated. Therefore, only set the EOImodeNS bit for the root
controller.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Setting the affinity of an IRQ, it only applicable for the root
interrupt controller and so only populate this operator for the root
controller.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
replacing printk(s) with appropriate pr_info and pr_err
in order to fix checkpatch.pl warnings
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Wall time obtained from do_gettimeofday gives 32 bit timeval which can only
represent time until January 2038. This patch moves to ktime_t, a 64-bit time.
Also, wall time is susceptible to sudden jumps due to user setting the time or
due to NTP. Boot time is constantly increasing time better suited for
subtracting two timestamps.
Signed-off-by: Abhilash Jindal <klock.android@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Accessing more than one byte from a symbol declared simply 'char' is undefined
behavior, as reported by UBSAN:
UBSAN: Undefined behaviour in drivers/base/power/trace.c:178:18
load of address ffffffff8203fc78 with insufficient space
for an object of type 'char'
Avoid this by declaring the symbols as arrays.
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Calling component_add() may result in the completion of a set of
devices, which will try to bring up a master. In bringing the master
up, we populate its match array with the current set of children.
If binding any of the devices fails, component_add() itself will fail,
free the struct component entry, and return to the caller. The
now-freed entry is never removed from the master's match array, and
will later be used in a futile attempt to bind to freed memory.
Bring component_add's behaviour on failure to bring up a master into
line with component_del by removing the (to-be-freed) component from
the master's match array.
The specific case which broke was:
- rockchip_drm_drv adds a component master
- dwhdmi_rockchip adds a child component in probe (master incomplete)
- rockchip_drm_vop adds two children in probe, which completes the
set
- inside component_add, we try to bring up the master, having
populated the master's match array, and fail with EPROBE_DEFER from
dwhdmi_rockchip; we delete the putative component
- rockchip_drm_vop's probe fails and returns EPROBE_DEFER
- we later re-probe rockchip_drm_vop and add the component; the
master is complete, so we attempt to bring it up again
- walking the match array, we find the previous child, whose master
pointer doesn't match (as it has been freed in the meantime)
- rockchip_drm_vop probe fails, and will never be attempted again
Fixes: ffc30b74fd
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
No need to require the bond down while changing these settings, the change
will be reflected immediately and the 3ad mode will sort itself out.
For faster convergence set port->ntt to true in order to generate new
LACPDUs immediately.
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In certain 802.11 wireless deployments, there will be NA proxies
that use knowledge of the network to correctly answer requests.
To prevent unsolicitd advertisements on the shared medium from
being a problem, on such deployments wireless needs to drop them.
Enable this by providing an option called "drop_unsolicited_na".
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In order to solve a problem with 802.11, the so-called hole-196 attack,
add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
enabled, causes the stack to drop IPv6 unicast packets encapsulated in
link-layer multi- or broadcast frames. Such frames can (as an attack)
be created by any member of the same wireless network and transmitted
as valid encrypted frames since the symmetric key for broadcast frames
is shared between all stations.
Reviewed-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In certain 802.11 wireless deployments, there will be ARP proxies
that use knowledge of the network to correctly answer requests.
To prevent gratuitous ARP frames on the shared medium from being
a problem, on such deployments wireless needs to drop them.
Enable this by providing an option called "drop_gratuitous_arp".
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In order to solve a problem with 802.11, the so-called hole-196 attack,
add an option (sysctl) called "drop_unicast_in_l2_multicast" which, if
enabled, causes the stack to drop IPv4 unicast packets encapsulated in
link-layer multi- or broadcast frames. Such frames can (as an attack)
be created by any member of the same wireless network and transmitted
as valid encrypted frames since the symmetric key for broadcast frames
is shared between all stations.
Additionally, enabling this option provides compliance with a SHOULD
clause of RFC 1122.
Reviewed-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Siva Reddy Kallam <siva.kallam@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Acked-by: Prashant Sreedharan <prashant@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the checkpatch.pl error to bpf_dbg.c:
ERROR: do not initialise statics to 0
Signed-off-by: Wei Tang <tangwei@cmss.chinamobile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add support for filtering link dumps by master device and kind, similar
to the filtering implemented for neighbor dumps.
Each net_device that exists adds between 1196 bytes (eth) and 1556 bytes
(bridge) to the link dump. As the number of interfaces increases so does
the amount of data pushed to user space for a link list. If the user
only wants to see a list of specific devices (e.g., interfaces enslaved
to a specific bridge or a list of VRFs) most of that data is thrown away.
Passing the filters to the kernel to have only relevant data returned
makes the dump more efficient.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to TV.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-7-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to CRT.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-6-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to SDVO.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-5-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort MST.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-4-git-send-email-mika.kahola@intel.com
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to HDMI.
V2:
- removed computation for max dot clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
- check for stereo mode added
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-3-git-send-email-mika.kahola@intel.com
