sa1100 provides its own variant of the clk API rather than using the
generic COMMON_CLK API. This generally works, but it causes some link
errors with drivers using the clk_set_rate, clk_get_parent, clk_set_parent
or clk_round_rate functions when a platform lacks those interfaces.
This adds trivial stub implementations for each of them, based on
the behavior of the COMMON_CLK implementation:
- set_rate() and set_parent() report success without doing anything
- round_rate() returns the clk rate
- get_parent() returns NULL.
This adds the minimal bloat and should do the right thing for
the simple clock hardware in this SoC.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
davinci still has its own clk implementation, but lacks
a clk_get_parent() helper, which can lead to link errors
in randconfig builds.
This adds the usual implementation.
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In commit 3169663ac5 "ARM: sa11x0/pxa: convert OS timer registers
to IOMEM", the definition of the OSCR macro was changed to be an
__iomem pointer, but the same register is also used by the XIP
code. This patch does the corresponding change here as well.
On PXA, the IRQ register definitions were removed even earlier, in
commit 5d284e353e ("ARM: pxa: avoid accessing interrupt registers
directly"). This patch unfortunately brings some of that back. An
earlier version of my patch moved the code into an external function,
which could not work for CONFIG_XIP_KERNEL+CONFIG_MTD_XIP, so this
restores something close to the original code.
Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/241716.html
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A change to the platform data definitions caused a warning in the board code:
arch/arm/mach-davinci/board-da850-evm.c:1221:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
arch/arm/mach-davinci/board-da850-evm.c:1231:13: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
This is a bit unfortunate, since we generally like structure definitions to
be const, but as this is legacy code, the easiest way out is still to
remove the 'const' annotation here.
Fixes: 4a5f8ae50b ("[media] davinci: vpif_capture: get subdevs from DT when available")
Fixes: 231ce279e6 ("ARM: davinci: fix const warnings")
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The ZTE SoC drivers are only useful when building for a ZTE ZX platform.
Fixes: 4c2c2e3971 ("soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Baoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Due to a bugfix in wireless tree and the commit mentioned below a merge
was needed which went haywire. So the submitted change resulted in the
function brcmf_sdiod_sgtable_alloc() being called twice during the probe
thus leaking the memory of the first call.
Cc: stable@vger.kernel.org # 4.6.x
Fixes: 4d79289598 ("brcmfmac: switch to new platform data")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The commit to rework the headroom check in start_xmit() now calls
pxskb_expand_head() unconditionally if the header is CoW. Unfortunately,
it does so with the delta between the extant headroom and the header
length, which may be negative if there is already sufficient headroom.
pskb_expand_head() does allow for size being 0, in which case it just
copies, so clamp the header delta to zero.
Opening Chrome (and all my tabs) on a PCIE device was enough to reliably
hit this.
Fixes: 270a6c1f65 ("brcmfmac: rework headroom check in .start_xmit()")
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Arend Van Spriel <arend.vanspriel@broadcom.com>
Cc: James Hughes <james.hughes@raspberrypi.org>
Cc: Hante Meuleman <hante.meuleman@broadcom.com>
Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Cc: Franky Lin <franky.lin@broadcom.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Drop the unused endpoints. They should only be used when there is an
actual remote-endpoint connected.
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Drop the unused endpoints. They should only be used when there is
an actual remote-endpoint connected.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Broadcom BCM53573 SoCs actually have 32 GPIOs, and not 16.
Fixes: 3f37ec79dd ("bcma: support BCM53573 series of wireless SoCs")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The current code kfree's entry and then dereferences it by accessing
entry->bssid. Avoid the dereference-after-free by moving the kfree
after the access to entry->bssid.
Detected by CoverityScan, CID#1448600 ("Read from pointer after free")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
- Fix wrong irq type for gpio expeander on Armada 388 GP
- Use __pa_symbol instead of virt_to_phys in the mv98dx3236 platform
SMP code
-----BEGIN PGP SIGNATURE-----
iIEEABECAEEWIQQYqXDMF3cvSLY+g9cLBhiOFHI71QUCWW3X4iMcZ3JlZ29yeS5j
bGVtZW50QGZyZWUtZWxlY3Ryb25zLmNvbQAKCRALBhiOFHI71e78AJ4+wNdgOn6C
8PVxz97Ngx2L0O44AgCfXWXbhHye3y4p2wfLfFTBT1prMZ4=
=gydP
-----END PGP SIGNATURE-----
Merge tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu into fixes
Pull "mvebu fixes for 4.13 (part 1)" from Gregory CLEMENT:
- Fix wrong irq type for gpio expeander on Armada 388 GP
- Use __pa_symbol instead of virt_to_phys in the mv98dx3236 platform
SMP code
* tag 'mvebu-fixes-4.13-1' of git://git.infradead.org/linux-mvebu:
ARM: dts: armada-38x: Fix irq type for pca955
ARM: mvebu: use __pa_symbol in the mv98dx3236 platform SMP code
Add necessary parent clocks for audss (Audio SubSystem, MAUDIO) clock
controller block.
This allows driver to keep EPLL enabled before accessing any MAUDIO
registers thus fixing silent hang. This silent hang appeared with
commit 6edfa11cb3 ("clk: samsung: Add enable/disable operation for
PLL36XX clocks"), e.g. on Odroid U3 usually with last (but unrelated)
messages:
[ 2.382741] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[ 2.405686] usb 1-3: new high-speed USB device number 3 using exynos-ehci
[ 2.419843] max77686-rtc max77686-rtc: setting system clock to 2017-06-21 17:04:13 UTC (1498064653)
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Correct order of sound clock frequencies for ULCB boards
used by r8a7795 and r8a7796 SoCs.
These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZaHmuAAoJENfPZGlqN0++XmQP/i7HumkEn4LPeyEQ/ePTwOHs
zz6CNekfmW0aJe4lceRmZ/xMkIuzrwma+EsQj3xj35cl1iK3MvjkguVYAFeYVhJb
w0X0qJp/0Opz0RNlKo4Pufj0yWy1ZyAQ9ci3UZELTik1sJI/7LG9eyjrXfaxRywo
OrYq3l41t9Y3/5e9MThUP4oxLO5B8YaJDtGGVYOoVk7cIs0PM9ffG8GVz0IPbrmF
wFEbVr/EohjpQL0SJ5GO2+NJhUbJFRuLOBWZOTyBQiZ3GByloRXzDR6gU/XSczHB
vElss4KZiWp2k7xRaBgaHK88u8wSOKdDkXrl6pto+aw1gAlFtOgWArKNQtkrp0vd
+VHk7Emhdnsw9SWTz0N+Oq7fyA2QIWo1sBr16AkmgB/JStlOXklJWjKgtyK0+mLj
FZAhOz5qO9ctr0WO87gbVvTz9xcs81g/K0D9rFTlmEIF8GEuDZxrX43LlIDl7I9r
nbfBj/HFtXqQXLIzS2OR9ah2F5DFWMym2/+mYuSkOt883PrbyjBq2xNdDD+QYcnO
+p6xCHAY/xiT953NBs/2z0kAXp6bWMjEOO7Lsv3SnPUss7Nng6RU2wbJepZd05Lo
ZH0k1L7IJtq2UVduHFYkEwKzTGCycW4mmposVNHZm42FOw19nR6Xd3khU57fMAni
ZH59p+Q/lFxcddwDZ0T1
=bjUb
-----END PGP SIGNATURE-----
Merge tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
Pull "Second Round of Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:
Correct order of sound clock frequencies for ULCB boards
used by r8a7795 and r8a7796 SoCs.
These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.
* tag 'renesas-fixes2-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
arm64: dts: renesas: ulcb: sound clock-frequency needs descending order
- Fix disable_irq related shared IRQ warnings for omap3 PRM
- Fix omap4 legacy code regression that accidentally removed code that
we still need for PRM interrupts
- Fix dm8168-evm NAND pins and MMC write protect pin direction
- Fix dra71-evm mdio impedance values
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEkgNvrZJU/QSQYIcQG9Q+yVyrpXMFAlld8MERHHRvbnlAYXRv
bWlkZS5jb20ACgkQG9Q+yVyrpXPnxRAAkGl1Q0HYGFl6+0YCLzk4jAD8Tx3T8kS6
Y+zaXkUowyQj548Sx55hSbCfxIyJETF2VBFWbMVMeNaDE1Gge+2rj6NdELAP1olu
cOIuRlJt4R6xBXRhJKMu4yA2DqslOD6C2rNM6B0qmNFoO+O4/9uhYZEAD03/RFRJ
8EXvr5lGjCfljEC/EgN7kfyPCOjU4aknbREZOUknQ/CMYm53G6FrNzppNNe0CVmj
59/Pp6lgYVPrBNXMpcD1LXu8fkOcp6vQ70h+WFLrdaf1GOZSj7SDHD50Lk2tNnN6
UWJ3aRE3cGnaNBwcnnrMkwMyIWBU6mEWSAOl/bQgf/jFiyFcgqDk+/i9POqGqzou
p3Jyn9of8Cg3SoIbImOsPODMgtesDmxy36nYcR+EH6x/mGDnwFzhxR74RB/X2ltq
RoeT8RbJxckz+h80Zjp6IbJQoJ6CcNqtPDiaf/GqsloSEYcUh51CBrP0teT51nFU
VZk9PRRsasIc7mpgyDg8jODZCtzvK0KTyTU3l6b6Oct7o8b/BOMAunKTAvujsT5Q
gqFCIJZ/iNTZ5GN8I6qEOTD4um5NFDl//tiQlVbU4/t/k2eUzlHErl0sc+ycv+N5
pRmz843Zs7U3lSithCF4/840BG7dQ0cTbx9binYtSCUOI9wKKORWz6ieKOf7mZi2
TR/Sqx+i0dI=
=ibLi
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Pull "Few fixes for omaps for issues found recently" from Tony Lindgren:
- Fix disable_irq related shared IRQ warnings for omap3 PRM
- Fix omap4 legacy code regression that accidentally removed code that
we still need for PRM interrupts
- Fix dm8168-evm NAND pins and MMC write protect pin direction
- Fix dra71-evm mdio impedance values
* tag 'omap-for-v4.13/fixes-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: dra71-evm: mdio: Fix impedance values
ARM: dts: dm816x: Correct the state of the write protect pin
ARM: dts: dm816x: Correct NAND support nodes
ARM: OMAP4: Fix legacy code clean-up regression
ARM: OMAP2+: Fix omap3 prm shared irq
Correct order of sound clock frequencies for Salvator boards
used by r8a7795 and r8a7796 SoCs.
These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZVhaCAAoJENfPZGlqN0++/zkP/1aHxFA560O3cb4SebIeJKQd
TQFd7YocK1lsqD6DP1ZLQI7ytPfpyAKPctKLRe2NSwr+kf5N8rbYUfZ88pBXe7ez
y9mbFBYcKHvDLrGHtW5hebBGB6HAh2Ll9DMW6Hqdsv8qG1/EqlLwBkA10/VSjaYk
Xfp4XnbyXsWCxbllU04We0uel945rg6tQy6VBszW5QEwMEX4zhaOsmi6z8nCv11E
k8Q6xl2/+FWc/zfivJSzBn59XjQSo+E54yRkmaYcteTY2+8Y787QMvVKkbUAvnHi
DrVplSPdbQPeZInqDiw97fvUNDTIzYatskMF3Lv6HFZ+u8YHTrW6yq2CShWtecUx
7BP8GgwfkLHt8J5PADMpNejzfE5lz+7EPm8+2jhGeoHd0BNjojaFvbyL01pJntwp
nJrSKlLmRB1CDEiubVPUUrY+EWcx7wxK0V8eliWTAn/o1ijJTErbRF91Z/U9BACF
PQUToBZ8MJKbjbrFXmelswkTwORV7au0KwY6Jzm2Vue7TiCZU4BXwyxZ1hmH3dI1
GLOWo5mtlXWcUnHLrPv44x6povNQDCtPGowTyKkqo2vXIAlAkMaG4V5D2tV9ykr7
d0UDWA44fF7QYcgW8hEd1eY0ILnYuX7Zanh0xvb5OBjqLEwsf+FvLel6/eMzg4Pj
tNB+iosh5YumUfCIue0D
=t800
-----END PGP SIGNATURE-----
Merge tag 'renesas-fixes-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
Pull "Renesas ARM Based SoC Fixes for v4.13" from Simon Horman:
Correct order of sound clock frequencies for Salvator boards
used by r8a7795 and r8a7796 SoCs.
These sounds clock frequencies are used as the ADG clock (output clocks
for audio module) initial setting and sound codec's initial system clock
which needs the maximum clock frequency. Thus, descending order is
required.
* tag 'renesas-fixes-for-v4.13' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
arm64: renesas: salvator-common: sound clock-frequency needs descending order
mwifiex records information about various channels as it receives scan
information. It does this by appending to a buffer that was sized
to the max number of supported channels on any band, but there are
numerous problems:
(a) scans can return info from more than one band (e.g., both 2.4 and 5
GHz), so the determined "max" is not large enough
(b) some firmware appears to return multiple results for a given
channel, so the max *really* isn't large enough
(c) there is no bounds checking when stashing these stats, so problems
(a) and (b) can easily lead to buffer overflows
Let's patch this by setting a slightly-more-correct max (that accounts
for a combination of both 2.4G and 5G bands) and adding a bounds check
when writing to our statistics buffer.
Due to problem (b), we still might not properly report all known survey
information (e.g., with "iw <dev> survey dump"), since duplicate results
(or otherwise "larger than expected" results) will cause some
truncation. But that's a problem for a future bugfix.
(And because of this known deficiency, only log the excess at the WARN
level, since that isn't visible by default in this driver and would
otherwise be a bit too noisy.)
Fixes: bf35443314 ("mwifiex: channel statistics support for mwifiex")
Cc: <stable@vger.kernel.org>
Cc: Avinash Patil <patila@marvell.com>
Cc: Xinming Hu <huxm@marvell.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Ganapathi Bhat <gbhat@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.
Even worse, a write to any of the cursor register apart from CURBASE
will cancel an already pending cursor update. So if we have armed a
CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
would cancel that armed update. Thus we're left with a cursor that
doesn't appear to move, or even change shape.
Fix the problem by always performing the CURBASE write after a
CURPOS write. Bspec is somewhat unclear which platforms actually
require this CURBASE write and which don't. So to keep it simple
and to make sure we really fix the problem across all supported
devices, let's just perform the CURBASE write unconditionally.
Cc: Paul Menzel <pmenzel@molgen.mpg.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790
Fixes: 75343a44c9 ("drm/i915: Drop useless posting reads from cursor commit")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170714155227.6089-1-ville.syrjala@linux.intel.com
(cherry picked from commit 8753d2bc5e)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
Fixes: 2889caa923 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170714151242.517-2-imre.deak@intel.com
(cherry picked from commit edd9003f7f)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Manish Chopra says:
====================
qed/qede: Enhancements
This patch series adds these below features support in qed/qede
1) Ntuple filter configuration [via ethtool -n/N]
2) EEE (energy efficient ethernet) support [ethtool --set-eee/show-eee]
3) Coalescing configuration support for VFs [via ethtool -c/C]
Please consider applying this to "net-next"
V1->V2:
* Fixes below Kbuild test robot warning.
drivers/net//ethernet/qlogic/qed/qed_l2.c:
In function 'qed_get_queue_coalesce':
drivers/net//ethernet/qlogic/qed/qed_l2.c:2137:8: error:
implicit declaration of function 'qed_vf_pf_get_coalesce'
[-Werror=implicit-function-declaration]
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Maximum coalesce per Rx/Tx queue is extended from
255 to 511.
Signed-off-by: Rahul Verma <rahul.verma@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Retrieve the actual coalesce value from hardware for every Rx/Tx
queue, instead of Rx/Tx coalesce value cached during set coalesce.
Signed-off-by: Rahul Verma <Rahul.Verma@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch add the ethtool support to set RX/Tx coalesce
value to the VF associated Rx/Tx queues.
Signed-off-by: Rahul Verma <Rahul.Verma@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The patch adds ethtool callback implementations for querying/configuring
the Energy Efficient Ethernet (EEE) parameters.
Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The patch adds required driver support for reading/configuring the
Energy Efficient Ethernet (EEE) parameters.
Signed-off-by: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support for adding and deleting rx flow
classification rules. Using this user can classify RX flow
constituting of TCP/UDP 4-tuples [src_ip/dst_ip and src_port/dst_port]
to be steered on a given RX queue
Signed-off-by: Manish Chopra <manish.chopra@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds support for ethtool getter APIs to query
RX flow classification rules.
Signed-off-by: Manish Chopra <manish.chopra@cavium.com>
Signed-off-by: Yuval Mintz <yuval.mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit b1f5bfc27a ("sctp: don't dereference ptr before leaving
_sctp_walk_{params, errors}()") tried to fix the issue that it
may overstep the chunk end for _sctp_walk_{params, errors} with
'chunk_end > offset(length) + sizeof(length)'.
But it introduced a side effect: When processing INIT, it verifies
the chunks with 'param.v == chunk_end' after iterating all params
by sctp_walk_params(). With the check 'chunk_end > offset(length)
+ sizeof(length)', it would return when the last param is not yet
accessed. Because the last param usually is fwdtsn supported param
whose size is 4 and 'chunk_end == offset(length) + sizeof(length)'
This is a badly issue even causing sctp couldn't process 4-shakes.
Client would always get abort when connecting to server, due to
the failure of INIT chunk verification on server.
The patch is to use 'chunk_end <= offset(length) + sizeof(length)'
instead of 'chunk_end < offset(length) + sizeof(length)' for both
_sctp_walk_params and _sctp_walk_errors.
Fixes: b1f5bfc27a ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In dccp_feat_init, when ccid_get_builtin_ccids failsto alloc
memory for rx.val, it should free tx.val before returning an
error.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The patch "dccp: fix a memleak that dccp_ipv6 doesn't put reqsk
properly" fixed reqsk refcnt leak for dccp_ipv6. The same issue
exists on dccp_ipv4.
This patch is to fix it for dccp_ipv4.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In dccp_v6_conn_request, after reqsk gets alloced and hashed into
ehash table, reqsk's refcnt is set 3. one is for req->rsk_timer,
one is for hlist, and the other one is for current using.
The problem is when dccp_v6_conn_request returns and finishes using
reqsk, it doesn't put reqsk. This will cause reqsk refcnt leaks and
reqsk obj never gets freed.
Jianlin found this issue when running dccp_memleak.c in a loop, the
system memory would run out.
dccp_memleak.c:
int s1 = socket(PF_INET6, 6, IPPROTO_IP);
bind(s1, &sa1, 0x20);
listen(s1, 0x9);
int s2 = socket(PF_INET6, 6, IPPROTO_IP);
connect(s2, &sa1, 0x20);
close(s1);
close(s2);
This patch is to put the reqsk before dccp_v6_conn_request returns,
just as what tcp_conn_request does.
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fixes: dad6f37c26 ("powerpc: subpage_protect: Increase the array size to take care of 64TB")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Tested-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
"qd.id" comes directly from the copy_from_user() on the line before so
we should verify that it's within bounds.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
FCOE offloading failed with:
[qed_sp_fcoe_func_start:150(sp-0-3b:00.02)]Cannot satisfy CQ amount. CQs
requested 8, CQs available 6. Aborting function start
[qed_fcoe_start:821()]Failed to start fcoe
[__qedf_probe:3041]:6: Cannot start FCoE function.
The reason is a newly introduced check in the qed main part. This change
also provides the information about how many CQs are available, so we
simply limit the number of requested CQs..
Fixes: 3c5da94278 ("qed: Share additional information with qedf")
Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: Chad Dupuis <chad.dupuis@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The CPU hotplug related code of this driver can be simplified by:
1) Consolidating the callbacks into a single state. The CPU thread can be
torn down on the CPU which goes offline. There is no point in delaying
that to the CPU dead state
2) Let the core code invoke the online/offline callbacks and remove the
extra for_each_online_cpu() loops.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Chad Dupuis <chad.dupuis@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The CPU hotplug related code of this driver can be simplified by:
1) Consolidating the callbacks into a single state. The CPU thread can be
torn down on the CPU which goes offline. There is no point in delaying
that to the CPU dead state
2) Let the core code invoke the online/offline callbacks and remove the
extra for_each_online_cpu() loops.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The BNX2I module init/exit code installs/removes the hotplug callbacks with
the cpu hotplug lock held. This worked with the old CPU locking
implementation which allowed recursive locking, but with the new percpu
rwsem based mechanism this is not longer allowed.
Use the _cpuslocked() variants to fix this.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Chad Dupuis <chad.dupuis@cavium.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The BNX2FC module init/exit code installs/removes the hotplug callbacks with
the cpu hotplug lock held. This worked with the old CPU locking
implementation which allowed recursive locking, but with the new percpu
rwsem based mechanism this is not longer allowed.
Use the _cpuslocked() variants to fix this.
Reported-by: kernel test robot <fengguang.wu@intel.com>
Acked-by: Chad Dupuis <chad.dupuis@cavium.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
bnx2fc_process_new_cqes() has protection against CPU hotplug, which relies
on the per cpu thread pointer. This protection is racy because it happens
only partially with the per cpu fp_work_lock held.
If the CPU is unplugged after the lock is dropped, the wakeup code can
dereference a NULL pointer or access freed and potentially reused memory.
Restructure the code so the thread check and wakeup happens with the
fp_work_lock held.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Chad Dupuis <chad.dupuis@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The rework of the exynos DRM clock handling introduced
warnings for configurations that have CONFIG_PM disabled:
drivers/gpu/drm/exynos/exynos_hdmi.c:736:13: error: 'hdmi_clk_disable_gates' defined but not used [-Werror=unused-function]
static void hdmi_clk_disable_gates(struct hdmi_context *hdata)
^~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/exynos/exynos_hdmi.c:717:12: error: 'hdmi_clk_enable_gates' defined but not used [-Werror=unused-function]
static int hdmi_clk_enable_gates(struct hdmi_context *hdata)
The problem is that the PM functions themselves are inside of
an #ifdef, but some functions they call are not.
This patch removes the #ifdef and instead marks the PM functions
as __maybe_unused, which is a more reliable way to get it right.
Link: https://patchwork.kernel.org/patch/8436281/
Fixes: 9be7e98984 ("drm/exynos/hdmi: clock code re-factoring")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
If the s5p-cec driver is a module and the drm exynos driver is built-in, then
the CEC core will be a module also, causing the CEC notifier to fail (will be
compiled as empty functions).
To prevent this select CEC_CORE if CEC_NOTIFIER is set to ensure the CEC core
is also built into the kernel.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The "Fixes" patch was incorrectly merged, as a result PHY is prematurely
powered off and for example Odroid-U3 cannot disable TV power domain
when HDMI cable is unplugged.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 625e63e2 ("drm/exynos/hdmi: fix pipeline disable order")
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch moves drm_bridge_add call into probe.
It doesn't need to call drm_bridge_add call every time
bind callback is called.
Changelog v2
- moved drm_bridge_remove call into remove callback.
- corrected description.
Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Remove the error handling of bridge_node because the bridge_node is
optional.
For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is optional.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
It doesn't need to try to find a bridge if bridge node doesn't exist.
Reviewed-by: Shuah Khan <shuahkh@osg.samsung.com>
Tested-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
12294 1192 0 13486 34ae drivers/gpu/drm/exynos/exynos_hdmi.o
File size after constify hdmi_match_types.
text data bss dec hex filename
13318 176 0 13494 34b6 drivers/gpu/drm/exynos/exynos_hdmi.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
num_ioctls is already assigned when declaring the exynos_drm_driver
structure. No need to duplicate it here.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The buffer passed to bpf_obj_get_info_by_fd() should be initialized
to zeros. Kernel will enforce that to guarantee we can safely extend
info structures in the future.
Making the bpf_obj_get_info_by_fd() call in libbpf perform the zeroing
is problematic, however, since some members of the info structures
may need to be initialized by the callers (for instance pointers
to buffers to which kernel is to dump translated and jited images).
Remove the zeroing and fix up the in-tree callers before any kernel
has been released with this code.
As Daniel points out this seems to be the intended operation anyway,
since commit 95b9afd398 ("bpf: Test for bpf ID") is itself setting
the buffer pointers before calling bpf_obj_get_info_by_fd().
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
