Ard Biesheuvel [Tue, 31 May 2022 08:53:42 +0000 (09:53 +0100)]
ARM: 9209/1: Spectre-BHB: avoid pr_info() every time a CPU comes out of idle
Jon reports that the Spectre-BHB init code is filling up the kernel log
with spurious notifications about which mitigation has been enabled,
every time any CPU comes out of a low power state.
Given that Spectre-BHB mitigations are system wide, only a single
mitigation can be enabled, and we already print an error if two types of
CPUs coexist in a single system that require different Spectre-BHB
mitigations.
This means that the pr_info() that describes the selected mitigation
does not need to be emitted for each CPU anyway, and so we can simply
emit it only once.
In order to clarify the above in the log message, update it to describe
that the selected mitigation will be enabled on all CPUs, including ones
that are unaffected. If another CPU comes up later that is affected and
requires a different mitigation, we report an error as before.
Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround") Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Alan Previn [Tue, 7 Jun 2022 00:23:14 +0000 (17:23 -0700)]
drm/i915/guc: Asynchronous flush of GuC log regions
Both error-capture and relay-logging mechanism use the GuC
log infrastructure. That means the KMD must send a log flush
complete notification back to GuC after reading the data out.
This call is currently being sent synchronously.
However, synchronous H2Gs cause problems when the system is
backed up. There is no need for this to be synchronous. The
KMD wasn't even looking at the return status from it. So make
it asynchronous and then there is no issue about time outs.
ARM: dts: qcom: apq8064: disable DSI and DSI PHY by default
Disable DSI and DSI PHY devices by default. The only actual user,
Nexus 7, already contains `status = "okay"` property in the respective
devices nodes.
Follow the usual scheme and use name 'iface' rather than 'iface_clk' for
the interface clock. The DSI PHY driver can cope with both of them, so
there is no breakage.
Enable the Qualcomm Bandwidth Monitor to allow scaling interconnects
depending on bandwidth usage between CPU and memory. This is used
already on Qualcomm SDM845 SoC.
Bandwidth monitoring (BWMON) sits between various subsytems like CPU,
GPU, Last Level caches and memory subsystem. The BWMON can be
configured to monitor the data throuhput between memory and other
subsytems. The throughput is measured within specified sampling window
and is used to vote for corresponding interconnect bandwidth.
Current implementation brings support for BWMON v4, used for example on
SDM845 to measure bandwidth between CPU (gladiator_noc) and Last Level
Cache (memnoc). Usage of this BWMON allows to remove fixed bandwidth
votes from cpufreq (CPU nodes) thus achieve high memory throughput even
with lower CPU frequencies.
Add bindings for the Qualcomm Bandwidth Monitor device providing
performance data on interconnects. The bindings describe only BWMON CPU
(version 4), e.g. the instance which appeared for the first on Qualcomm
MSM8998 SoC and is also used on SDM845. This BWMON device sits between
CPU and Last Level Cache Controller.
Marijn Suijten [Sun, 8 May 2022 10:03:35 +0000 (12:03 +0200)]
arm64: dts: qcom: sm6125: Add DLL/DDR configuration on SDHCI 1/2
These config values have been extracted from CodeLinaro's most recent
trinket/sm6125 tag:
https://git.codelinaro.org/clo/la/kernel/msm-4.14/-/blob/LA.UM.9.11.r1-05600-NICOBAR.QSSI12.0/arch/arm64/boot/dts/qcom/trinket.dtsi
Marijn Suijten [Sun, 8 May 2022 10:03:33 +0000 (12:03 +0200)]
arm64: dts: qcom: sm6125: Move sdc2 pinctrl from seine-pdx201 to sm6125
Both the sdc2-on and sdc2-off pinctrl nodes are used by the
sdhci@4784000 node in sm6125.dtsi. Surprisingly sdc2-off is defined in
sm6125, yet its sdc2-on counterpart is only defined in board-specific DT
for the Sony Seine PDX201 board/device resulting in an "undefined label
&sdc2_state_on" error if sm6125.dtsi were included elsewhere.
This sm6125 base dtsi should not rely on externally defined labels; the
properties referencing it should then also be written externally.
Since the sdc2-on pin configuration is board-independent just like
sdc2-off, move it from seine-pdx201.dts into sm6125.dtsi.
The SDCard-detect pin (gpio98) is however board-specific, and remains as
an overwrite in seine-pdx201.dts for both the on and off state.
As a drive-by cleanup, reorder bias- and drive-strength properties.
Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125") Fixes: 82e1783890b7 ("arm64: dts: qcom: sm6125: Add support for Sony Xperia 10II") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220508100336.127176-1-marijn.suijten@somainline.org
Al Viro [Sat, 11 Jun 2022 20:44:21 +0000 (16:44 -0400)]
iov_iter_get_pages{,_alloc}(): cap the maxsize with MAX_RW_COUNT
All callers can and should handle iov_iter_get_pages() returning
fewer pages than requested. All in-kernel ones do. And it makes
the arithmetical overflow analysis much simpler...
Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Al Viro [Tue, 7 Jun 2022 03:44:33 +0000 (23:44 -0400)]
iov_iter_bvec_advance(): don't bother with bvec_iter
do what we do for iovec/kvec; that ends up generating better code,
AFAICS.
Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Shunsuke Mie [Wed, 22 Jun 2022 04:09:24 +0000 (13:09 +0900)]
PCI: endpoint: Don't stop controller when unbinding endpoint function
Unbinding an endpoint function from the endpoint controller shouldn't stop
the controller. This is especially a problem for multi-function endpoints
where other endpoints may still be active.
Don't stop the controller when unbinding one of its endpoints. Normally
the controller is stopped via configfs.
Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to test PCI") Link: https://lore.kernel.org/r/20220622040924.113279-1-mie@igel.co.jp Signed-off-by: Shunsuke Mie <mie@igel.co.jp> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Bjorn Andersson [Thu, 5 May 2022 02:27:06 +0000 (19:27 -0700)]
arm64: dts: qcom: db820c: Add user LEDs
The db820c has 4 "user LEDs", all connected to the PMI8994. The first
three are connected to the three current sinks provided by the TRILED
and the fourth is connected to MPP2.
By utilizing the DTEST bus the MPP is fed the control signal from the
fourth LPG block, providing a consistent interface to the user.
Bjorn Andersson [Thu, 5 May 2022 02:27:04 +0000 (19:27 -0700)]
arm64: dts: qcom: sdm845: Enable user LEDs on DB845c
The DB845c has 4 "user LEDs", the last one is already supported as it's
just wired to a gpio. Now that the LPG binding is in place we can wire
up the other 3 LEDs as well.
Jonathan Marek [Wed, 6 Jul 2022 15:43:36 +0000 (17:43 +0200)]
clk: qcom: add support for SM8350 DISPCC
Add support to the SM8350 display clock controller by extending the SM8250
display clock controller, which is almost identical but has some minor
differences.
Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Robert Foss <robert.foss@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220706154337.2026269-5-robert.foss@linaro.org
clk: qcom: clk-alpha-pll: add Lucid EVO PLL configuration interfaces
Add controls for Lucid EVO PLL configuration and export control functions
to clock controller drivers, the PLL is used by Qualcomm SM8450 camera
and display clock controllers.
After merging lucid and trion pll functions in commit 0b01489475c6
("clk: qcom: clk-alpha-pll: same regs and ops for trion and lucid")
the function clk_trion_pll_configure() is left with an old description
header, which results in a W=2 compile time warning, fix it.
Randy Dunlap [Wed, 6 Jul 2022 18:42:24 +0000 (11:42 -0700)]
drm: xlnx: add <linux/io.h> for readl/writel
Add a header file to prevent build errors:
../drivers/gpu/drm/xlnx/zynqmp_dp.c: In function ‘zynqmp_dp_write’:
../drivers/gpu/drm/xlnx/zynqmp_dp.c:335:9: error: implicit declaration of function ‘writel’ [-Werror=implicit-function-declaration]
335 | writel(val, dp->iomem + offset);
../drivers/gpu/drm/xlnx/zynqmp_dp.c: In function ‘zynqmp_dp_read’:
../drivers/gpu/drm/xlnx/zynqmp_dp.c:340:16: error: implicit declaration of function ‘readl’ [-Werror=implicit-function-declaration]
340 | return readl(dp->iomem + offset);
Fixes: a204f9743b68 ("drm: Remove linux/i2c.h from drm_crtc.h") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Hyun Kwon <hyun.kwon@xilinx.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Michal Simek <michal.simek@xilinx.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220706184224.29116-1-rdunlap@infradead.org
Mark Brown [Wed, 6 Jul 2022 19:37:03 +0000 (20:37 +0100)]
spi: AMD SPI controller driver bug fix and cleanups
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:
This patch series addresses an issue in the spi-amd driver and, while
there, performs some additional cleanups, like simplifying the error
handling in the probe function and removing an unused struct member.
For improving code readability, it also adds some kernel-doc comments.
Ville Syrjälä [Thu, 30 Jun 2022 15:06:00 +0000 (18:06 +0300)]
drm/i915: Nuke PCH_JSP
JSP is based on ICP and we don't really need to differentiate
between the two. So let's just delcare JSP to be ICP.
The only slight change here is for Wa_14011294188 which we
used to apply for JSP but now we'll only apply to MCC. This
should be fine since the issue being dealt with was introduced
in TGP and inherited into MCC. JSP being derived from ICP
should not need this workaround.
Al Viro [Mon, 4 Jul 2022 02:07:32 +0000 (22:07 -0400)]
step_into(): lose inode argument
make handle_mounts() always fetch it. This is just the first step -
the callers of step_into() will stop trying to calculate the sucker,
etc.
The passed value should be equal to dentry->d_inode in all cases;
in RCU mode - fetched after we'd sampled ->d_seq. Might as well
fetch it here. We do need to validate ->d_seq, which duplicates
the check currently done in lookup_fast(); that duplication will
go away shortly.
After that change handle_mounts() always ignores the initial value of
*inode and always sets it on success.
Al Viro [Mon, 4 Jul 2022 22:12:39 +0000 (18:12 -0400)]
namei: stash the sampled ->d_seq into nameidata
New field: nd->next_seq. Set to 0 outside of RCU mode, holds the sampled
value for the next dentry to be considered. Used instead of an arseload
of local variables, arguments, etc.
step_into() has lost seq argument; nd->next_seq is used, so dentry passed
to it must be the one ->next_seq is about.
There are two requirements for RCU pathwalk:
1) it should not give a hard failure (other than -ECHILD) unless
non-RCU pathwalk might fail that way given suitable timings.
2) it should not succeed unless non-RCU pathwalk might succeed
with the same end location given suitable timings.
The use of seq numbers is the way we achieve that. Invariant we want
to maintain is:
if RCU pathwalk can reach the state with given nd->path, nd->inode
and nd->seq after having traversed some part of pathname, it must be possible
for non-RCU pathwalk to reach the same nd->path and nd->inode after having
traversed the same part of pathname, and observe the nd->path.dentry->d_seq
equal to what RCU pathwalk has in nd->seq
For transition from parent to child, we sample child's ->d_seq
and verify that parent's ->d_seq remains unchanged. Anything that
disrupts parent-child relationship would've bumped ->d_seq on both.
For transitions from child to parent we sample parent's ->d_seq
and verify that child's ->d_seq has not changed. Same reasoning as
for the previous case applies.
For transition from mountpoint to root of mounted we sample
the ->d_seq of root and verify that nobody has touched mount_lock since
the beginning of pathwalk. That guarantees that mount we'd found had
been there all along, with these mountpoint and root of the mounted.
It would be possible for a non-RCU pathwalk to reach the previous state,
find the same mount and observe its root at the moment we'd sampled
->d_seq of that
For transitions from root of mounted to mountpoint we sample
->d_seq of mountpoint and verify that mount_lock had not been touched
since the beginning of pathwalk. The same reasoning as in the
previous case applies.
Keith Busch [Wed, 6 Jul 2022 17:05:05 +0000 (10:05 -0700)]
nvme: use struct group for generic command dwords
This will allow the trace event to know the full size of the data
intended to be copied and silence read overflow checks.
Reported-by: John Garry <john.garry@huawei.com> Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
Merge tag 'for-linus' of https://github.com/openrisc/linux
Pull OpenRISC fixes from Stafford Horne:
"Fixups for OpenRISC found during recent testing:
- An OpenRISC irqchip fix to stop acking level interrupts which was
causing issues on SMP platforms
- A comment typo fix in our unwinder code"
* tag 'for-linus' of https://github.com/openrisc/linux:
openrisc: unwinder: Fix grammar issue in comment
irqchip: or1k-pic: Undefine mask_ack for level triggered hardware
Merge tag 'sound-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This became largish as it includes the pending ASoC fixes.
Almost all changes are device-specific small fixes, while many of them
are coverage for mixer issues that were detected by selftest. In
addition, usual suspects for HD/USB-audio are there"
* tag 'sound-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (43 commits)
ALSA: cs46xx: Fix missing snd_card_free() call at probe error
ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)
ALSA: usb-audio: Add quirk for Fiero SC-01
ALSA: hda/realtek: Add quirk for Clevo L140PU
ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices
ASoC: madera: Fix event generation for rate controls
ASoC: madera: Fix event generation for OUT1 demux
ASoC: cs47l15: Fix event generation for low power mux control
ASoC: cs35l41: Add ASP TX3/4 source to register patch
ASoC: dapm: Initialise kcontrol data for mux/demux controls
ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error
ASoC: cs35l41: Correct some control names
ASoC: wm5110: Fix DRE control
ASoC: wm_adsp: Fix event for preloader
MAINTAINERS: update ASoC Qualcomm maintainer email-id
ASoC: rockchip: i2s: switch BCLK to GPIO
ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states
ASoC: SOF: pm: add definitions for S4 and S5 states
ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2
ASoC: SOF: Intel: hda: Fix compressed stream position tracking
...
Al Viro [Wed, 6 Jul 2022 16:40:31 +0000 (12:40 -0400)]
namei: move clearing LOOKUP_RCU towards rcu_read_unlock()
try_to_unlazy()/try_to_unlazy_next() drop LOOKUP_RCU in the
very beginning and do rcu_read_unlock() only at the very end.
However, nothing done in between even looks at the flag in
question; might as well clear it at the same time we unlock.
Note that try_to_unlazy_next() used to call legitimize_mnt(),
which might drop/regain rcu_read_lock() in some cases. This
is no longer true, so we really have rcu_read_lock() held
all along until the end.
dmaengine: altera-msgdma: Fixed some inconsistent function name descriptions
Inconsistent function names describing msgdma_chan_remove() and
msgdma_dma_remove are modified to msgdma_dev_remove() and msgdma_remove().
Remove some warnings found by running scripts/kernel-doc, which is caused
by using 'make W=1'.
drivers/dma/altera-msgdma.c:927: warning: expecting prototype for msgdma_dma_remove(). Prototype was for msgdma_remove() instead.
drivers/dma/altera-msgdma.c:758: warning: expecting prototype for msgdma_chan_remove(). Prototype was for msgdma_dev_remove() instead.
The conditional block for variants with a second clock should have set
minItems, not maxItems, which was already 2. Since clock-names requires
two items, this typo should not have caused any problems.
Fixes: edd14218bd66 ("dt-bindings: dmaengine: Convert Allwinner A31 and A64 DMA to a schema") Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220702031903.21703-1-samuel@sholland.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
Compatibles can come in two formats. Either "vendor,ip-soc" or
"vendor,soc-ip". Add a DT schema documenting preferred policy and
enforcing it for all new compatibles, except few existing patterns. The
schema also disallows wild-cards used in SoC compatibles.
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:03 +0000 (11:11 +0300)]
drm/msm/mdp5: move iommu_domain_alloc() call close to its usage
Move iommu_domain_alloc() in front of adress space/IOMMU initialization.
This allows us to drop final bits of struct mdp5_cfg_platform which
remained from the pre-DT days.
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489695/ Link: https://lore.kernel.org/r/20220616081106.350262-3-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
Dmitry Baryshkov [Thu, 16 Jun 2022 08:11:02 +0000 (11:11 +0300)]
drm/msm/dpu: check both DPU and MDSS devices for the IOMMU
Follow the lead of MDP5 driver and check both DPU and MDSS devices for
the IOMMU specifiers.
Historically DPU devices had IOMMU specified in the MDSS device tree
node, but as some of MDP5 devices are being converted to the supported
by the DPU driver, the driver should adapt and check both devices.
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/489696/ Link: https://lore.kernel.org/r/20220616081106.350262-2-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Wed, 15 Jun 2022 16:35:28 +0000 (09:35 -0700)]
drm/msm: Fix %d vs %u
In debugging fence rollover, I noticed that GPU state capture and
devcore dumps were showing me negative fence numbers. Let's fix that
and some related signed vs unsigned confusion.
drm/msm/dpu: move struct dpu_hw_blk definition to dpu_hw_utils.h
There is little point in having a separate header just for a single
opaque struct definition. Drop it now and move the struct to the
dpu_hw_util.h header.
drm/msm/dpu: merge base_off with blk_off in struct dpu_hw_blk_reg_map
There is little point in keeping a separate MDP address and block offset
in this struct. Merge them to form a new blk_addr field used for all
register access.
Rob Clark [Sun, 29 May 2022 18:04:23 +0000 (11:04 -0700)]
drm/msm/adreno: Allow larger address space size
The restriction to 4G was strictly to work around 64b math bug in some
versions of SQE firmware. This appears to be fixed in a650+ SQE fw, so
allow a larger address space size on these devices.
Also, add a modparam override for debugging and igt.
v2: Send the right version of the patch (ie. the one that actually
compiles)
Konrad Dybcio [Sat, 28 May 2022 16:03:51 +0000 (18:03 +0200)]
drm/msm/adreno: Fix up formatting
Leading spaces are not something checkpatch likes, and it says so when
they are present. Use tabs consistently to indent function body and
unwrap a 83-char-long line, as 100 is cool nowadays.
Konrad Dybcio [Sat, 28 May 2022 16:03:50 +0000 (18:03 +0200)]
drm/msm/a6xx: Add speedbin support for A619 GPU
There are various SKUs of A619, ranging from 565 MHz to 850 MHz, depending
on the bin. Add support for distinguishing them, so that proper frequency
ranges can be applied, depending on the HW.
Douglas Anderson [Fri, 10 Jun 2022 19:47:31 +0000 (12:47 -0700)]
drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy
From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately the current a6xx_gpu_busy() grabs a
reference to the GMU's "struct device".
The fact that we were grabbing the wrong reference was easily seen to
cause crashes that happen if we change the GPU's pm_runtime usage to
not use autosuspend. It's also believed to cause some long tail GPU
crashes even with autosuspend.
We could look at changing it so that we do pm_runtime_get_if_in_use()
on the GPU's "struct device", but then we run into a different
problem. pm_runtime_get_if_in_use() will return 0 for the GPU's
"struct device" the whole time when we're in the "autosuspend
delay". That is, when we drop the last reference to the GPU but we're
waiting a period before actually suspending then we'll think the GPU
is off. One reason that's bad is that if the GPU didn't actually turn
off then the cycle counter doesn't lose state and that throws off all
of our calculations.
Let's change the code to keep track of the suspend state of
devfreq. msm_devfreq_suspend() is always called before we actually
suspend the GPU and msm_devfreq_resume() after we resume it. This
means we can use the suspended state to know if we're powered or not.
NOTE: one might wonder when exactly our status function is called when
devfreq is supposed to be disabled. The stack crawl I captured was:
msm_devfreq_get_dev_status
devfreq_simple_ondemand_func
devfreq_update_target
qos_notifier_call
qos_max_notifier_call
blocking_notifier_call_chain
pm_qos_update_target
freq_qos_apply
apply_constraint
__dev_pm_qos_update_request
dev_pm_qos_update_request
msm_devfreq_idle_work
Fixes: eadf79286a4b ("drm/msm: Check for powered down HW in the devfreq callbacks") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rob Clark <robdclark@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/489124/ Link: https://lore.kernel.org/r/20220610124639.v4.1.Ie846c5352bc307ee4248d7cab998ab3016b85d06@changeid Signed-off-by: Rob Clark <robdclark@chromium.org>
James Clark [Wed, 11 May 2022 14:46:00 +0000 (15:46 +0100)]
Documentation: coresight: Link config options to existing documentation
In order to document the newly added branch_broadcast option, create a
table that links all of the config option formats to any existing docs.
That way when the branch broadcast docs are expanded they are accessible
from both places.
James Clark [Wed, 11 May 2022 14:45:59 +0000 (15:45 +0100)]
Documentation: coresight: Turn numbered subsections into real subsections
This is to allow them to be referenced in a later commit. There was
also a mistake where sysFS was introduced as section 2, but numbered
as section 1. And vice versa for 'Using perf framework'. This can't
happen with unnumbered sections.
James Clark [Wed, 11 May 2022 14:45:58 +0000 (15:45 +0100)]
coresight: Add config flag to enable branch broadcast
When enabled, all taken branch addresses are output, even if the branch
was because of a direct branch instruction. This enables reconstruction
of the program flow without having access to the memory image of the
code being executed.
Use bit 8 for the config option which would be the correct bit for
programming ETMv3. Although branch broadcast can't be enabled on ETMv3
because it's not in the define ETM3X_SUPPORTED_OPTIONS, using the
correct bit might help prevent future collisions or allow it to be
enabled if needed.
Hsin-Yi Wang [Thu, 30 Jun 2022 17:33:29 +0000 (01:33 +0800)]
video: of_display_timing.h: include errno.h
If CONFIG_OF is not enabled, default of_get_display_timing() returns an
errno, so include the header.
Fixes: 422b67e0b31a ("videomode: provide dummy inline functions for !CONFIG_OF") Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Helge Deller <deller@gmx.de>
Dpintf is the displayport interface hardware unit. This unit is similar
to dpi and can reuse most of the code.
This patch adds support for mt8195-dpintf to this dpi driver. Main
differences are:
- 4 pixels for one iteration for dp_intf while dpi is 1 pixel for one
iteration.
- Input of dp_intf is two pixels per iteration.
- Some register contents differ slightly between the two components.
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20220705102530.1344-6-rex-bc.chen@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Coverity detected that usdt_rel_ip is unconditionally overwritten
anyways, so there is no need to unnecessarily initialize it with unused
value. Clean this up.
When compiling with -O2, GCC detects few problems with selftests/bpf, so
fix all of them. Two are real issues (uninitialized err and nums
out-of-bounds access), but two other uninitialized variables warnings
are due to GCC not being able to prove that variables are indeed
initialized under conditions under which they are used.
When compiling selftests/bpf in optimized mode (-O2), GCC erroneously
complains about uninitialized token variable:
In file included from network_helpers.c:22:
network_helpers.c: In function ‘open_netns’:
test_progs.h:355:22: error: ‘token’ may be used uninitialized [-Werror=maybe-uninitialized]
355 | int ___err = libbpf_get_error(___res); \
| ^~~~~~~~~~~~~~~~~~~~~~~~
network_helpers.c:440:14: note: in expansion of macro ‘ASSERT_OK_PTR’
440 | if (!ASSERT_OK_PTR(token, "malloc token"))
| ^~~~~~~~~~~~~
In file included from /data/users/andriin/linux/tools/testing/selftests/bpf/tools/include/bpf/libbpf.h:21,
from bpf_util.h:9,
from network_helpers.c:20:
/data/users/andriin/linux/tools/testing/selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here
113 | LIBBPF_API long libbpf_get_error(const void *ptr);
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:522: /data/users/andriin/linux/tools/testing/selftests/bpf/network_helpers.o] Error 1
This is completely bogus becuase libbpf_get_error() doesn't dereference
pointer, but the only easy way to silence this is to allocate initialized
memory with calloc().
Johan Almbladh [Tue, 5 Jul 2022 08:23:45 +0000 (10:23 +0200)]
xdp: Fix spurious packet loss in generic XDP TX path
The byte queue limits (BQL) mechanism is intended to move queuing from
the driver to the network stack in order to reduce latency caused by
excessive queuing in hardware. However, when transmitting or redirecting
a packet using generic XDP, the qdisc layer is bypassed and there are no
additional queues. Since netif_xmit_stopped() also takes BQL limits into
account, but without having any alternative queuing, packets are
silently dropped.
This patch modifies the drop condition to only consider cases when the
driver itself cannot accept any more packets. This is analogous to the
condition in __dev_direct_xmit(). Dropped packets are also counted on
the device.
Bypassing the qdisc layer in the generic XDP TX path means that XDP
packets are able to starve other packets going through a qdisc, and
DDOS attacks will be more effective. In-driver-XDP use dedicated TX
queues, so they do not have this starvation issue.
projects / people / ms / linux.git / log
