| Age | Commit message (Collapse) | Author |
|---|
|
Florian Fainelli says:
====================
drivers: net: Fix 64-bit statistics seqcount init
This patch series fixes a bunch of drivers to have their 64-bit statistics
seqcount cookie be initialized correctly. Most of these drivers (except b44,
gtp) are probably used on 64-bit only hosts and so the lockdep splat might have
never been seen.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that by using the proper helper function: netdev_alloc_pcpu_stats().
Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that. In commit 6c80f3fc2398 ("netvsc: report per-channel stats in
ethtool statistics") netdev_alloc_pcpu_stats() was removed in favor of
open-coding the 64-bits statistics, except that u64_stats_init() was
missed.
Fixes: 6c80f3fc2398 ("netvsc: report per-channel stats in ethtool statistics")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that by using netdev_alloc_pcpu_stats() instead of an open coded
allocation.
Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that.
Fixes: 4c3523623dc0 ("net: add driver for Netronome NFP4000/NFP6000 NIC VFs")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that.
Fixes: 4197aa7bb818 ("ixgbevf: provide 64 bit statistics")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that.
Fixes: 980e9b118642 ("i40e: Add support for 64 bit netstats")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a
lockdep splat indicating this seqcount is not correctly initialized, fix
that.
Fixes: eeda8585522b ("b44: add 64 bit stats")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If a workload caused a HW GPU hang or it is in the middle of
vGPU reset, the workload queue should be cleaned up to emulate
the hang state of the GPU.
v2:
- use ENGINE_MASK(ring_id) instead of (1 << ring_id). (Zhenyu)
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
Use resetting_eng to identify which engine is resetting
so the rest ones' workload won't be impacted
v2:
- use ENGINE_MASK(ring_id) instead of (1 << ring_id). (Zhenyu)
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
|
The implementation of PCI workarounds may require that the device is reset
from its probe function. This implies that the PCI device lock is already
held, and makes calling pci_reset_function() impossible (since it will
itself try to take that lock).
Add pci_reset_function_locked(), which is the equivalent of
pci_reset_function(), except that it requires the PCI device lock to be
already held by the caller.
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
[bhelgaas: folded in fix for conflict with 52354b9d1f46 ("PCI: Remove
__pci_dev_reset() and pci_dev_reset()")]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # 4.11: 52354b9d1f46: PCI: Remove __pci_dev_reset() and pci_dev_reset()
Cc: stable@vger.kernel.org # 4.11
|
|
Niklas Söderlund says:
====================
ravb: add wake-on-lan support via magic packet
WoL is enabled in the suspend callback by setting MagicPacket detection
and disabling all interrupts expect MagicPacket. In the resume path the
driver needs to reset the hardware to rearm the WoL logic, this prevents
the driver from simply restoring the registers and to take advantage of
that ravb was not suspended to reduce resume time. To reset the
hardware the driver closes the device, sets it in reset mode and reopens
the device just like it would do in a normal suspend/resume scenario
without WoL enabled, but it both closes and opens the device in the
resume callback since the device needs to be reset for WoL to work.
One quirk needed for WoL is that the module clock needs to be prevented
from being switched off by Runtime PM. To keep the clock alive the
suspend callback need to call clk_enable() directly to increase the
usage count of the clock. Then when Runtime PM decreases the clock usage
count it won't reach 0 and be switched off.
Changes since v2
- Only do the clock dance to workaround PSCI sleep when resuming if WoL
is enabled. This was a bug in v2 which resulted in a WARN if resuming
from PSCI sleep with WoL disabled, thanks Sergei for pointing this
out!
- Break out clock dance workaround in separate patch to make it easier
to revert once a fix is upstream for the clock driver as suggested by
Sergei.
Changes since v1
- Fix issue where device would fail to resume from PSCI suspend if WoL
was enabled, reported by Geert. The fault was that the clock driver
thinks the clock is on, but PSCI have disabled it, added workaround
for this in ravb driver which can be removed once the clock driver is
aware of the PSCI behavior.
- Only try to restore from wol wake up if netif is running, since this
is a condition to enable wol in the first place this was a bug in v1.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The renesas-cpg-mssr clock driver are not yet aware of PSCI sleep where
power is cut to the SoC. When resuming from this state with WoL enabled
the enable count of the ravb clock is 1 and the clock driver thinks the
clock is already on when PM core enables the clock and increments the
enable count to 2. This will result in the ravb driver failing to talk
to the hardware since the module clock is off. Work around this by
forcing the enable count to 0 and then back to 2 when resuming with WoL
enabled.
This workaround should be reverted once the renesas-cpg-mssr clock
driver becomes aware of this PSCI sleep behavior.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
WoL is enabled in the suspend callback by setting MagicPacket detection
and disabling all interrupts expect MagicPacket. In the resume path the
driver needs to reset the hardware to rearm the WoL logic, this prevents
the driver from simply restoring the registers and to take advantage of
that ravb was not suspended to reduce resume time. To reset the
hardware the driver closes the device, sets it in reset mode and reopens
the device just like it would do in a normal suspend/resume scenario
without WoL enabled, but it both closes and opens the device in the
resume callback since the device needs to be reset for WoL to work.
One quirk needed for WoL is that the module clock needs to be prevented
from being switched off by Runtime PM. To keep the clock alive the
suspend callback need to call clk_enable() directly to increase the
usage count of the clock. Then when Runtime PM decreases the clock usage
count it won't reach 0 and be switched off.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
Johan Hedberg says:
====================
pull request: bluetooth-next 2017-08-01
Here's our first batch of Bluetooth patches for the 4.14 kernel:
- Several new USB IDs for the btusb driver
- Memory leak fix in btusb driver
- Cleanups & fixes to hci_nokia, hci_serdev and hci_bcm drivers
- Fixed cleanup path in mrf24j40 (802.15.4) driver probe function
- A few other smaller cleanups & fixes to drivers
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t
into dmam_alloc_coherent, which the compiler warns about:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt':
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:54:50: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
The returned DMA address is later passed on to a function that
takes a phys_addr_t, so it's clearly wrong to use the DMA
mapping interface here: the memory may be uncached, or the
address may be completely wrong if there is an IOMMU connected
to the device. What the code actually wants to do is to get
the physical address from the reserved-mem node. It goes through
the dma-mapping interfaces for obscure reasons, and this
apparently only works by chance, relying on specific bugs
in the error handling of the arm64 dma-mapping implementation.
The same problem existed in the "venus" media driver, which was
now fixed by Stanimir Varbanov after long discussions.
In order to make some progress here, I have now ported his
approach over to the adreno driver. The patch is currently
untested, and should get a good review, but it is now much
simpler than the original, and it should be obvious what
goes wrong if I made a mistake in the port.
See also: a6e2d36bf6b7 ("media: venus: don't abuse dma_alloc for non-DMA allocations")
Cc: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Fixes: 7c65817e6d38 ("drm/msm: gpu: Enable zap shader for A5XX")
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-and-Tested-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
When compile-testing for something other than ARCH_QCOM,
we run into a link error:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_hw_init':
a5xx_gpu.c:(.text.a5xx_hw_init+0x600): undefined reference to `qcom_mdt_get_size'
a5xx_gpu.c:(.text.a5xx_hw_init+0x93c): undefined reference to `qcom_mdt_load'
There is already an #ifdef that tries to check for CONFIG_QCOM_MDT_LOADER,
but that symbol is only meaningful when building for ARCH_QCOM.
This adds a compile-time check for ARCH_QCOM, and clarifies the
Kconfig select statement so we don't even try it for other targets.
The check for CONFIG_QCOM_MDT_LOADER can then go away, which also
improves compile-time coverage and makes the code a little nicer
to read.
Fixes: 7c65817e6d38 ("drm/msm: gpu: Enable zap shader for A5XX")
Acked-by: Jordan Crouse <jcrouse@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
msm_gpu's get_timestamp() op (called by the MSM_GET_PARAM ioctl) can
result in register accesses. We need our power domain and clocks to
be active for that. Make sure they are enabled here.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
__user should be used to identify user pointers and not __u64
variables containing pointers.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Fix a typo in msm_ioctl_gem_submit - check args->flags for the
MSM_SUBMIT_NO_IMPLICIT flag instead of args->fence.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
On A5XX GPU hardware clock gating needs to be turned off before
reading certain GPU registers via AHB. Turn off HWCG before calling
adreno_show() to safely dump all the registers without a system hang.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
There are some use cases wherein we need to turn off hardware clock
gating before reading certain registers. Modify the A5XX HWCG function
to allow user to enable or disable clock gating at will.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The 0xf400 and 0xf800 ranges are in the RBBM_SECVID block which may
be protected from CPU access. Skip dumping them since they are minimally
useful for debugging and they aren't worth a system hang.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
In the case that GRO is turned on and the original received packet is
CHECKSUM_PARTIAL, if the outer UDP header is exactly at the last
csum-unnecessary point, which for instance could occur if the packet
comes from another Linux guest on the same Linux host, we have to do
either remcsum_adjust or set up CHECKSUM_PARTIAL again with its
csum_start properly reset considering RCO.
However, since b7fe10e5ebac ("gro: Fix remcsum offload to deal with frags
in GRO") that barrier in such case could be skipped if GRO turned on,
hence we pass over it and the inner L4 validation mistakenly reckons
it as a bad csum.
This patch makes remcsum_offload being reset at the same time of GRO
remcsum cleanup, so as to make it work in such case as before.
Fixes: b7fe10e5ebac ("gro: Fix remcsum offload to deal with frags in GRO")
Signed-off-by: Koichiro Den <den@klaipeden.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In the case that GRO is turned on and the original received packet is
CHECKSUM_PARTIAL, if the outer UDP header is exactly at the last
csum-unnecessary point, which for instance could occur if the packet
comes from another Linux guest on the same Linux host, we have to do
either remcsum_adjust or set up CHECKSUM_PARTIAL again with its
csum_start properly reset considering RCO.
However, since b7fe10e5ebac("gro: Fix remcsum offload to deal with frags
in GRO") that barrier in such case could be skipped if GRO turned on,
hence we pass over it and the inner L4 validation mistakenly reckons
it as a bad csum.
This patch makes remcsum_offload being reset at the same time of GRO
remcsum cleanup, so as to make it work in such case as before.
Fixes: b7fe10e5ebac ("gro: Fix remcsum offload to deal with frags in GRO")
Signed-off-by: Koichiro Den <den@klaipeden.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Skb frags may contain compound pages. Various operations map frags
temporarily using kmap_atomic, but this function works on single
pages, not whole compound pages. The distinction is only relevant
for high mem pages that require temporary mappings.
Introduce a looping mechanism that for compound highmem pages maps
one page at a time, does not change behavior on other pages.
Use the loop in the kmap_atomic callers in net/core/skbuff.c.
Verified by triggering skb_copy_bits with
tcpdump -n -c 100 -i ${DEV} -w /dev/null &
netperf -t TCP_STREAM -H ${HOST}
and by triggering __skb_checksum with
ethtool -K ${DEV} tx off
repeated the tests with looping on a non-highmem platform
(x86_64) by making skb_frag_must_loop always return true.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Sean Wang says:
====================
net-next: mediatek: add support for ethernet on MT7622 SoC
Changes since v2:
- update John's mail
Changes since v1:
- add refinement for ethernet clock management
- take out the code block for ESW, add it until ESW driver is actually introduced
The series adds the driver for ethernet controller found on MT7622 SoC.
There are additions against with previous MT7623 SoC such as shared SGMII
given for the dual GMACs and built-in 5-ports 10/100 embedded switch support
(ESW). Thus more clocks consumers and SGMII hardware setup for the extra
features are all introduced here and as for the support for ESW that would be
planned to add in the separate patch integrating with DSA infrastructure
in the future.
Currently testing successfully is done with those patches for the conditions
such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with RTL8211F PHY via SGMII.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Sean and Nelson work for MediaTek on maintaining the MediaTek ethernet
driver for the existing SoCs and adding support for the following SoCs.
In the past, Sean has been active at making most of the qualifications
, stress test and submitting a lot of patches for the driver while
Nelson was looking into the aspects more on hardware additions and details
such as introducing PDMA with Hardware LRO to the driver. Also update
John's up-to-date mail address in the patch.
Cc: John Crispin <john@phrozen.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
Acked-by: John Crispin <john@phrozen.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch adds the driver for ethernet controller on MT7622 SoC. It has
the similar handling logic as the previously MT7623 does, but there are
additions against with MT7623 SoC, the shared SGMII given for the dual
GMACs and including 5-ports 10/100 embedded switch support (ESW) as the
GMAC1 option, thus more clocks consumers for the extra feature are
introduced here. So for ease portability and maintenance, those
differences all are being kept inside the platform data as other drivers
usually do. Currently testing successfully is done with those patches for
the conditions such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with
RTL8211F PHY via SGMII.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch is the preparation patch in order to adapt into various
hardware through adding platform data which holds specific characteristics
among MediaTek SoCs and introducing the unified clock handler for those
distinct clock requirements depending on different features such as
TRGMII and SGMII getting support on the target SoC. And finally, add
enhancement with given the generic description for Kconfig and remove the
unnecessary machine type dependency in Makefile.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The patch adds the supplements in the dt-binding document for MediaTek
MT7622 SoC with extra SGMII system controller and relevant clock consumers
listed as the requirements for those SoCs equipped with the SGMII circuit.
Also, add the missing binding information for MT7623 SoC here which relies
on the fallback binding of MT2701.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We have upstream bindings (msm8916) that have the "_clk" suffix in the
clock names. The downstream bindings also require it.
We want to drop the "_clk" suffix and at the same time support existing
bindings. Update the MDP5 code with the the msm_clk_get() helper to
support both old and new clock names.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
The mdp5_cmd_encoder_disable is accidentally called in the encoder enable
path. We've not seen any problems since we haven't tested with command
mode panels in a while. Fix the copy-paste error.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
When I converted dell-wmi to the new bus infrastructure, I left the
call to dell_wmi_check_descriptor_buffer() in dell_wmi_init(). This
could cause two problems:
- An error message when loading the driver on a system without
dell-wmi. We'd try to read the event descriptor even if the WMI
GUID wasn't there.
- A possible race if dell-wmi was loaded manually before wmi was
fully initialized.
Fix it by moving the call to the probe function where it belongs.
Fixes: bff589be59c5 ("platform/x86: dell-wmi: Convert to the WMI bus infrastructure")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
|
|
While I was testing the upcoming adv7533 CEC support with my Dragonboard c410
I encountered this NULL pointer dereference:
[ 17.912822] Unable to handle kernel NULL pointer dereference at virtual address 000000e8
[ 17.917191] user pgtable: 4k pages, 48-bit VAs, pgd = ffff800030e9f000
[ 17.925249] [00000000000000e8] *pgd=00000000b0daf003, *pud=0000000000000000
[ 17.931650] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 17.938395] Modules linked in: btqcomsmd btqca arc4 wcn36xx mac80211 bluetooth cfg80211 ecdh_generic r8152 snd_soc_hdmi_codec adv7511 cec
qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm
[ 17.943967] CPU: 0 PID: 1684 Comm: Xorg Tainted: G W 4.13.0-rc1-dragonboard #111
[ 17.962005] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[ 17.970685] task: ffff800031236c00 task.stack: ffff800033fbc000
[ 17.977582] PC is at msm_gem_unmap_vma+0x20/0x80 [msm]
[ 17.983213] LR is at put_iova+0x60/0xb8 [msm]
[ 17.988303] pc : [<ffff000000ac2d58>] lr : [<ffff000000ac07c8>] pstate: 20000145
[ 17.992733] sp : ffff800033fbfb30
[ 18.000193] x29: ffff800033fbfb30 x28: ffff800030b5f000
[ 18.003407] x27: 00000000000000b4 x26: ffff0000009f8cd8
[ 18.008789] x25: 0000000000000004 x24: dead000000000100
[ 18.014085] x23: dead000000000200 x22: ffff800030b5fd40
[ 18.019379] x21: ffff800030b5fc00 x20: 0000000000000000
[ 18.024675] x19: ffff80003082bf00 x18: 0000000000000000
[ 18.029970] x17: 0000ffffb3347e70 x16: ffff000008207638
[ 18.035265] x15: 0000000000000053 x14: 0000000000000000
[ 18.040560] x13: 0000000000000038 x12: 0101010101010101
[ 18.045855] x11: 7f7f7f7f7f7f7f7f x10: 0000000000000040
[ 18.051150] x9 : ffff800030b5f038 x8 : ffff800031657b50
[ 18.056446] x7 : ffff800031657b78 x6 : 0000000000000000
[ 18.061740] x5 : 0000000000000000 x4 : 00000000b5c01000
[ 18.067036] x3 : 0000000000000000 x2 : ffff8000337bf300
[ 18.072330] x1 : ffff80003082bf00 x0 : 0000000000000000
[ 18.077629] Process Xorg (pid: 1684, stack limit = 0xffff800033fbc000)
[ 18.082925] Stack: (0xffff800033fbfb30 to 0xffff800033fc0000)
[ 18.089262] fb20: ffff800033fbfb60 ffff000000ac07c8
[ 18.095081] fb40: ffff80003082bf00 ffff800030b5fc90 ffff800030b5fc00 ffff000000abf4a0
[ 18.102893] fb60: ffff800033fbfba0 ffff000000ac16b0 ffff800030b5fc00 ffff8000338ff870
[ 18.110706] fb80: ffff8000338ff800 ffff800030b5fc00 ffff800030b5fda8 ffff800033fbfd80
[ 18.118518] fba0: ffff800033fbfbe0 ffff0000009d4244 ffff800030b5fc00 ffff800030b5f038
[ 18.126332] fbc0: ffff800033fbfbd0 ffff800030b5fc00 ffff800030b5f038 ffff0000009d4840
[ 18.134144] fbe0: ffff800033fbfbf0 ffff0000009d4858 ffff800033fbfc10 ffff0000009d48e4
[ 18.141955] fc00: ffff800030b5fc00 ffff8000338ffd98 ffff800033fbfc30 ffff0000009d49a4
[ 18.149768] fc20: ffff800030b5fc00 ffff800030b5f000 ffff800033fbfc60 ffff0000009d4a4c
[ 18.157581] fc40: ffff800030b5f050 ffff800030b5f000 0000000000000001 ffff800030b5fc00
[ 18.165394] fc60: ffff800033fbfca0 ffff0000009d4ab0 0000000000000018 ffff800030b5f000
[ 18.173206] fc80: ffff0000009efd28 ffff800033fbfd80 ffff8000338ff800 ffff0000009d56a8
[ 18.181019] fca0: ffff800033fbfcb0 ffff0000009efd54 ffff800033fbfcc0 ffff0000009d56c8
[ 18.188831] fcc0: ffff800033fbfd00 ffff0000009d58e0 ffff0000009fa6e0 00000000c00464b4
[ 18.196643] fce0: 0000000000000004 ffff80003082b400 0000ffffea1f0e00 0000000000000000
[ 18.204456] fd00: ffff800033fbfe00 ffff000008206f0c ffff80000335caf8 ffff80003082b400
[ 18.212269] fd20: 0000ffffea1f0e00 ffff80003082b400 00000000c00464b4 0000ffffea1f0e00
[ 18.220081] fd40: 0000000000000124 000000000000001d ffff0000089d2000 ffff800031236c00
[ 18.227894] fd60: ffff800033fbfd80 0000000000000004 ffff0000009efd28 ffff800033fbfd80
[ 18.235706] fd80: 0000000100000001 0000008000000001 0000001800000020 0000000000000001
[ 18.243518] fda0: 0000000100000000 0000000100000001 0000ffff00000000 0000ffff00000000
[ 18.251331] fdc0: 0000000000000124 0000000000000038 ffff0000089d2000 ffff800031236c00
[ 18.259144] fde0: ffff800033fbfe40 ffff000008214124 ffff800033fbfe30 ffff000008203290
[ 18.266956] fe00: ffff800033fbfe80 ffff0000082076b4 0000000000000000 ffff800030d8a000
[ 18.274768] fe20: ffff80003082b400 0000000000000016 ffff800033fbfe50 ffff0000081f0488
[ 18.282581] fe40: ffff800033fbfe80 ffff000008207678 0000000000000000 ffff80003082b400
[ 18.290393] fe60: ffff800033fbfe70 ffff0000082138b0 ffff800033fbfe80 ffff000008207658
[ 18.298207] fe80: 0000000000000000 ffff000008082f84 0000000000000000 0000800034a16000
[ 18.306017] fea0: ffffffffffffffff 0000ffffb3347e7c 0000000000000000 0000000000000015
[ 18.313832] fec0: 0000000000000016 00000000c00464b4 0000ffffea1f0e00 0000000000000001
[ 18.321643] fee0: 0000000000000020 0000000000000080 0000000000000001 0000000000000000
[ 18.329456] ff00: 000000000000001d 000000012692c5b0 0101010101010101 7f7f7f7f7f7f7f7f
[ 18.337269] ff20: 0101010101010101 0000000000000038 0000000000000000 0000000000000053
[ 18.345082] ff40: 0000ffffb368b2b8 0000ffffb3347e70 0000000000000000 0000ffffb3847000
[ 18.352894] ff60: 0000ffffea1f0e00 00000000c00464b4 0000000000000016 0000ffffea1f0edc
[ 18.360705] ff80: 000000012692ad20 0000000000000003 00000001214282e4 0000000121428388
[ 18.368518] ffa0: 0000000000000000 0000ffffea1f0da0 0000ffffb367185c 0000ffffea1f0da0
[ 18.376332] ffc0: 0000ffffb3347e7c 0000000000000000 0000000000000016 000000000000001d
[ 18.384142] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 18.391953] Call trace:
[ 18.399760] Exception stack(0xffff800033fbf950 to 0xffff800033fbfa80)
[ 18.402023] f940: ffff80003082bf00 0001000000000000
[ 18.408622] f960: ffff800033fbfb30 ffff000000ac2d58 0000000020000145 ffff8000338ffa78
[ 18.416435] f980: 0000000000000000 0000000000000000 ffff800033fbf9e0 ffff0000089afcf0
[ 18.424248] f9a0: ffff80000348f230 ffff8000338ffa78 0000000000000000 0000000000000000
[ 18.432060] f9c0: ffff8000338ffaa8 0000000000000001 ffff800033fbfb80 ffff0000009e8f38
[ 18.439872] f9e0: ffff800033fbfa10 ffff0000089a9ff8 0000000000000027 ffff80003082b918
[ 18.447684] fa00: 0000000000000000 ffff80003082bf00 ffff8000337bf300 0000000000000000
[ 18.455497] fa20: 00000000b5c01000 0000000000000000 0000000000000000 ffff800031657b78
[ 18.463310] fa40: ffff800031657b50 ffff800030b5f038 0000000000000040 7f7f7f7f7f7f7f7f
[ 18.471122] fa60: 0101010101010101 0000000000000038 0000000000000000 0000000000000053
[ 18.479062] [<ffff000000ac2d58>] msm_gem_unmap_vma+0x20/0x80 [msm]
[ 18.486862] [<ffff000000ac07c8>] put_iova+0x60/0xb8 [msm]
[ 18.492938] [<ffff000000ac16b0>] msm_gem_free_object+0x60/0x198 [msm]
[ 18.498432] [<ffff0000009d4244>] drm_gem_object_free+0x1c/0x58 [drm]
[ 18.504854] [<ffff0000009d4858>] drm_gem_object_put_unlocked+0x90/0xa0 [drm]
[ 18.511273] [<ffff0000009d48e4>] drm_gem_object_handle_put_unlocked+0x64/0xd0 [drm]
[ 18.518300] [<ffff0000009d49a4>] drm_gem_object_release_handle+0x54/0x98 [drm]
[ 18.525679] [<ffff0000009d4a4c>] drm_gem_handle_delete+0x64/0xb8 [drm]
[ 18.532968] [<ffff0000009d4ab0>] drm_gem_dumb_destroy+0x10/0x18 [drm]
[ 18.539479] [<ffff0000009efd54>] drm_mode_destroy_dumb_ioctl+0x2c/0x40 [drm]
[ 18.545992] [<ffff0000009d56c8>] drm_ioctl_kernel+0x68/0xe0 [drm]
[ 18.553105] [<ffff0000009d58e0>] drm_ioctl+0x178/0x3b0 [drm]
[ 18.558970] [<ffff000008206f0c>] do_vfs_ioctl+0xa4/0x7d0
[ 18.564694] [<ffff0000082076b4>] SyS_ioctl+0x7c/0x98
[ 18.569992] [<ffff000008082f84>] el0_svc_naked+0x38/0x3c
[ 18.574941] Code: a90153f3 aa0003f4 f90013f5 aa0103f3 (f9407400)
[ 18.580502] ---[ end trace b1ac6888ec40b0be ]---
It turns out that the aspace argument in msm_gem_unmap_vma() is NULL.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
[Note: this case gets hit with !IOMMU config]
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
While I was testing the upcoming adv7533 CEC support with my Dragonboard c410
I encountered this warning several times during boot:
[ 4.408309] WARNING: CPU: 3 PID: 1347 at drivers/gpu/drm/msm/msm_gem.c:312 add_vma+0x78/0x88 [msm]
[ 4.412951] Modules linked in: snd_soc_hdmi_codec adv7511 cec qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm
[ 4.421728] CPU: 3 PID: 1347 Comm: kworker/3:3 Not tainted 4.13.0-rc1-dragonboard #111
[ 4.433090] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[ 4.441081] Workqueue: events deferred_probe_work_func
[ 4.447929] task: ffff800031243600 task.stack: ffff800003394000
[ 4.453023] PC is at add_vma+0x78/0x88 [msm]
[ 4.458823] LR is at _msm_gem_new+0xd4/0x188 [msm]
[ 4.463207] pc : [<ffff000000ac01f8>] lr : [<ffff000000ac06b4>] pstate: 40000145
[ 4.467811] sp : ffff8000033978a0
[ 4.475357] x29: ffff8000033978a0 x28: ffff8000031dea18
[ 4.478572] x27: ffff800003933a00 x26: ffff800003b39800
[ 4.483953] x25: ffff8000338ff800 x24: 0000000000000001
[ 4.489249] x23: 0000000000000000 x22: ffff800003b39800
[ 4.494544] x21: ffff8000338ff800 x20: 0000000000000000
[ 4.499839] x19: ffff800003932600 x18: 0000000000000001
[ 4.505135] x17: 0000ffff8969e9e0 x16: ffff7e00000ce7a0
[ 4.510429] x15: ffffffffffffffff x14: ffff8000833977ef
[ 4.515724] x13: ffff8000033977f3 x12: 0000000000000038
[ 4.521020] x11: 0101010101010101 x10: ffffff7f7fff7f7f
[ 4.526315] x9 : 0000000000000000 x8 : ffff800003932800
[ 4.531633] x7 : 0000000000000000 x6 : 000000000000003f
[ 4.531644] x5 : 0000000000000040 x4 : 0000000000000000
[ 4.531650] x3 : ffff800031243600 x2 : 0000000000000000
[ 4.531655] x1 : 0000000000000000 x0 : 0000000000000000
[ 4.531670] Call trace:
[ 4.531676] Exception stack(0xffff8000033976c0 to 0xffff8000033977f0)
[ 4.531683] 76c0: ffff800003932600 0001000000000000 ffff8000033978a0 ffff000000ac01f8
[ 4.531688] 76e0: 0000000000000140 0000000000000000 ffff800003932550 ffff800003397780
[ 4.531694] 7700: ffff800003397730 ffff000008261ce8 0000000000000000 ffff8000031d2f80
[ 4.531699] 7720: ffff800003397800 ffff0000081d671c 0000000000000140 0000000000000000
[ 4.531705] 7740: ffff000000ac04c0 0000000000004003 ffff800003397908 00000000014080c0
[ 4.531710] 7760: 0000000000000000 ffff800003b39800 0000000000000000 0000000000000000
[ 4.531716] 7780: 0000000000000000 ffff800031243600 0000000000000000 0000000000000040
[ 4.531721] 77a0: 000000000000003f 0000000000000000 ffff800003932800 0000000000000000
[ 4.531726] 77c0: ffffff7f7fff7f7f 0101010101010101 0000000000000038 ffff8000033977f3
[ 4.531730] 77e0: ffff8000833977ef ffffffffffffffff
[ 4.531881] [<ffff000000ac01f8>] add_vma+0x78/0x88 [msm]
[ 4.532011] [<ffff000000ac06b4>] _msm_gem_new+0xd4/0x188 [msm]
[ 4.532134] [<ffff000000ac1900>] msm_gem_new+0x10/0x18 [msm]
[ 4.532260] [<ffff000000acb274>] msm_dsi_host_modeset_init+0x17c/0x268 [msm]
[ 4.532384] [<ffff000000ac9024>] msm_dsi_modeset_init+0x34/0x1b8 [msm]
[ 4.532504] [<ffff000000ab6168>] modeset_init+0x408/0x488 [msm]
[ 4.532623] [<ffff000000ab6c4c>] mdp5_kms_init+0x2b4/0x338 [msm]
[ 4.532745] [<ffff000000abeff8>] msm_drm_bind+0x218/0x4e8 [msm]
[ 4.532755] [<ffff00000855d744>] try_to_bring_up_master+0x1f4/0x318
[ 4.532762] [<ffff00000855d900>] component_add+0x98/0x180
[ 4.532887] [<ffff000000ac8da0>] dsi_dev_probe+0x18/0x28 [msm]
[ 4.532895] [<ffff000008565fe8>] platform_drv_probe+0x58/0xc0
[ 4.532901] [<ffff00000856410c>] driver_probe_device+0x324/0x458
[ 4.532907] [<ffff00000856440c>] __device_attach_driver+0xac/0x170
[ 4.532913] [<ffff000008561ef4>] bus_for_each_drv+0x4c/0x98
[ 4.532918] [<ffff000008563c38>] __device_attach+0xc0/0x160
[ 4.532924] [<ffff000008564530>] device_initial_probe+0x10/0x18
[ 4.532929] [<ffff000008562f84>] bus_probe_device+0x94/0xa0
[ 4.532934] [<ffff0000085635d4>] deferred_probe_work_func+0x8c/0xe8
[ 4.532941] [<ffff0000080d79bc>] process_one_work+0x1d4/0x330
[ 4.532946] [<ffff0000080d7b60>] worker_thread+0x48/0x468
[ 4.532952] [<ffff0000080ddae4>] kthread+0x12c/0x130
[ 4.532958] [<ffff000008082f10>] ret_from_fork+0x10/0x40
[ 4.532962] ---[ end trace b1ac6888ec40b0bb ]---
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop.
Test: receive a packet which the ip length > 20 and the first byte of ip option is 0, produce this issue
Signed-off-by: yujuan.qi <yujuan.qi@mediatek.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Tom Herbert says:
====================
net: Infrastructure changes for [kz]proxy
This patch set contains some general infrastructure enhancements that
will be used by kernel proxy and zero proxy.
The changes are:
- proto_ops: Add locked versions of sendmsg and sendpage
- skb_send_sock: Allow sending and skb on a socket within the
kernel
- Generalize strparser. Allow it to be used in other contexts than
just in the read_sock path. This will be used in the transmit
path of zero proxy.
Some nice future work (which I've been discussing with John Fastabend)
will be to make some of the related functions to allow gifting of skbs
We should be able to do that with skb_send_sock and strp_process. I'd
also like this feature in the read_sock callbeck.
Tested: Ran modified kernel without incident. Tested new functionality
using zero proxy (in development).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Generalize strparser from more than just being used in conjunction
with read_sock. strparser will also be used in the send path with
zero proxy. The primary change is to create strp_process function
that performs the critical processing on skbs. The documentation
is also updated to reflect the new uses.
Signed-off-by: Tom Herbert <tom@quantonium.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add skb_send_sock to send an skbuff on a socket within the kernel.
Arguments include an offset so that an skbuf might be sent in mulitple
calls (e.g. send buffer limit is hit).
Signed-off-by: Tom Herbert <tom@quantonium.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add new proto_ops sendmsg_locked and sendpage_locked that can be
called when the socket lock is already held. Correspondingly, add
kernel_sendmsg_locked and kernel_sendpage_locked as front end
functions.
These functions will be used in zero proxy so that we can take
the socket lock in a ULP sendmsg/sendpage and then directly call the
backend transport proto_ops functions.
Signed-off-by: Tom Herbert <tom@quantonium.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Grygorii Strashko says:
====================
net: ethernet: ti: cpts: fix tx timestamping timeout
With the low Ethernet connection speed cpdma notification about packet
processing can be received before CPTS TX timestamp event, which is set
when packet actually left CPSW while cpdma notification is sent when packet
pushed in CPSW fifo. As result, when connection is slow and CPU is fast
enough TX timestamping is not working properly.
Issue was discovered using timestamping tool on am57x boards with Ethernet link
speed forced to 100M and on am335x-evm with Ethernet link speed forced to 10M.
Patch3 - This series fixes it by introducing TX SKB queue to store PTP SKBs for
which Ethernet Transmit Event hasn't been received yet and then re-check this
queue with new Ethernet Transmit Events by scheduling CPTS overflow
work more often until TX SKB queue is not empty.
Patch 1,2 - As CPTS overflow work is time critical task it important to ensure
that its scheduling is not delayed. Unfortunately, There could be significant
delay in CPTS work schedule under high system load and on -RT which could cause
CPTS misbehavior due to internal counter overflow and there is no way to tune
CPTS overflow work execution policy and priority manually. The kthread_worker
can be used instead of workqueues, as it creates separate named kthread for
each worker and its its execution policy and priority can be configured
using chrt tool. Instead of modifying CPTS driver itself it was proposed to
it was proposed to add PTP auxiliary worker to the PHC subsystem [1], so
other drivers can benefit from this feature also.
[1] https://www.spinics.net/lists/netdev/msg445392.html
changes in v4:
- fixed memleak in ptp_clock_register()
- undocumented change in cpts_find_ts() moved to separate patch (minor fix)
changes in v3:
- patch 1: added proper error handling in ptp_clock_register.
minor comments applied.
changes in v2:
- added PTP auxiliary worker to the PHC subsystem
Links
v3: https://www.spinics.net/lists/netdev/msg446058.html
v2: https://www.spinics.net/lists/netdev/msg445859.html
v1: https://www.spinics.net/lists/netdev/msg445387.html
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Now the call chain
cpts_find_ts()
|- cpts_fifo_read(cpts, CPTS_EV_PUSH)
will stop reading CPTS FIFO if PUSH event is found. But this is not
expected and CPTS FIFI should be completely drained here. This is most
probably copy-paste error and it has no negative impact as CPTS_EV_PUSH
should not be present in FIFO without TS_PUSH request and
cpts_systim_read() and cpts_find_ts() synchronized by spin_lock.
Correct above by calling cpts_fifo_read() with -1 parameter, so it will
read all CPTS event from FIFO.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
With the low speed Ethernet connection CPDMA notification about packet
processing can be received before CPTS TX timestamp event, which is set
when packet actually left CPSW while cpdma notification is sent when packet
pushed in CPSW fifo. As result, when connection is slow and CPU is fast
enough TX timestamping is not working properly.
Fix it, by introducing TX SKB queue to store PTP SKBs for which Ethernet
Transmit Event hasn't been received yet and then re-check this queue
with new Ethernet Transmit Events by scheduling CPTS overflow
work more often (every 1 jiffies) until TX SKB queue is not empty.
Side effect of this change is:
- User space tools require to take into account possible delay in TX
timestamp processing (for example ptp4l works with tx_timestamp_timeout=400
under net traffic and tx_timestamp_timeout=25 in idle).
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There could be significant delay in CPTS work schedule under high system
load and on -RT which could cause CPTS misbehavior due to internal counter
overflow. Usage of own kthread_worker allows to avoid such kind of issues
and makes it possible to tune priority of CPTS kthread_worker thread on -RT
(thread name "cpts").
Hence, the CPTS driver is converted to use PTP auxiliary worker as PHC
subsystem implements such functionality in a generic way now.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Many PTP drivers required to perform some asynchronous or periodic work,
like periodically handling PHC counter overflow or handle delayed timestamp
for RX/TX network packets. In most of the cases, such work is implemented
using workqueues. Unfortunately, Kernel workqueues might introduce
significant delay in work scheduling under high system load and on -RT,
which could cause misbehavior of PTP drivers due to internal counter
overflow, for example, and there is no way to tune its execution policy and
priority manuallly.
Hence, The kthread_worker can be used insted of workqueues, as it create
separte named kthread for each worker and its its execution policy and
priority can be configured using chrt tool.
This prblem was reported for two drivers TI CPSW CPTS and dp83640, so
instead of modifying each of these driver it was proposed to add PTP
auxiliary worker to the PHC subsystem.
The patch adds PTP auxiliary worker in PHC subsystem using kthread_worker
and kthread_delayed_work and introduces two new PHC subsystem APIs:
- long (*do_aux_work)(struct ptp_clock_info *ptp) callback in
ptp_clock_info structure, which driver should assign if it require to
perform asynchronous or periodic work. Driver should return the delay of
the PTP next auxiliary work scheduling time (>=0) or negative value in case
further scheduling is not required.
- int ptp_schedule_worker(struct ptp_clock *ptp, unsigned long delay) which
allows schedule PTP auxiliary work.
The name of kthread_worker thread corresponds PTP PHC device name "ptp%d".
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The verifier is allocated on the stack, but the EXCHANGE_ID RPC call was
changed to be asynchronous by commit 8d89bd70bc939. If we interrrupt
the call to rpc_wait_for_completion_task(), we can therefore end up
transmitting random stack contents in lieu of the verifier.
Fixes: 8d89bd70bc939 ("NFS setup async exchange_id")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
|
|
After the commit mentioned below, we start computing the byte and pixel
clocks (dsi_calc_clk_rate) in the DSI bridge's mode_set() op. The
calculation involves the number of DSI lanes being used by the
downstream bridge/panel.
If the downstream bridge/panel tries to change the number of DSI lanes
(as done in the ADV7533 driver) in its mode_set() op, then our DSI
host driver will not have the correct number of lanes when computing
byte/pixel clocks.
Fix this by delaying the clock rate calculation in the DSI bridge
enable path. In particular, compute the clock rates in
msm_dsi_host_get_phy_clk_req().
This fixes the DSI host error interrupts seen when we try to switch
between modes that require different number of lanes (4 to 3 lanes, or
vice versa) on db410c. The error interrupts occur since the byte/pixel
clock rates aren't according to what the DSI video mode timing engine
expects.
Fixes: b62aa70a98c5 ("drm/msm/dsi: Move PHY operations out of host")
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
Fixes an insta-reboot when screen-blanking kicks in, due to cursor
updates without clocks enabled.
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
We recently added locking to this function but there was a direct return
that was overlooked where we need to unlock.
Fixes: 0e08270a1f01 ("drm/msm: Separate locking of buffer resources from struct_mutex")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
