| Age | Commit message (Collapse) | Author |
|---|
|
In status_to_posix_error STATUS_IO_REPARSE_TAG_NOT_HANDLED was mapped
to both -EOPNOTSUPP and also to -EIO but the later one (-EIO) is
ignored. Remove the duplicate.
Reviewed-by: Paulo Alcantara (SUSE) <pc@manguebit.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fixes from Mauro Carvalho Chehab:
- driver fixes due to incorrect fwnode_handle_put() call
- bt8xx: bttv_risc_packed(): remove field checks
- vb2: frame_vector.c: replace WARN_ONCE with a comment
- imx219: a couple typo fixes and perform a full mode set
unconditionally
- uvcvideo: Fix OOB read
- some dependency fixes
* tag 'media/v6.6-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
media: imx-mipi-csis: Remove an incorrect fwnode_handle_put() call
media: vb2: frame_vector.c: replace WARN_ONCE with a comment
media: uvcvideo: Fix OOB read
media: bt8xx: bttv_risc_packed(): remove field checks
media: i2c: rdacm21: Remove an incorrect fwnode_handle_put() call
media: i2c: imx219: Perform a full mode set unconditionally
media: i2c: imx219: Fix crop rectangle setting when changing format
media: i2c: imx219: Fix a typo referring to a wrong variable
media: i2c: max9286: Remove an incorrect fwnode_handle_put() call
media: ivsc: Depend on VIDEO_DEV
media: via: Use correct dependency for camera sensor drivers
media: v4l: Use correct dependency for camera sensor drivers
media: pci: ivsc: Select build dependencies
|
|
Add device tree for the Fairphone 5 smartphone which is based on
the QCM6490 SoC.
Supported features are, as of now:
* Bluetooth
* Debug UART
* Display via simplefb
* Flash/torch LED
* Flip cover sensor
* Power & volume buttons
* RTC
* SD card
* USB
* Various plumbing like regulators, i2c, spi, etc
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230919-fp5-initial-v2-7-14bb7cedadf5@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Fairphone 5 is a smartphone based on the QCM6490 SoC.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230919-fp5-initial-v2-6-14bb7cedadf5@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add a node for the led controller found on PM8350C, used for flash and
torch purposes.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20230919-fp5-initial-v2-4-14bb7cedadf5@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Like other Qualcomm PMICs the PM7250B can be used on different addresses
on the SPMI bus. Use similar defines like the PMK8350 to make this
possible but skip the ifndef based on maintainer feedback.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230919-fp5-initial-v2-3-14bb7cedadf5@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
With the standard Qualcomm TrustZone setup, components such as lpasscc,
pdc_reset and watchdog shouldn't be touched by Linux. Mark them with
the status 'reserved' and reenable them in the chrome-common dtsi.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20230919-fp5-initial-v2-1-14bb7cedadf5@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Fix the apps iommu local address space range as per data sheet.
Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC")
Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230917140039.25283-1-quic_gkohli@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"A few more followup fixes to the directory listing.
People have noticed different behaviour compared to other filesystems
after changes in 6.5. This is now unified to more "logical" and
expected behaviour while still within POSIX. And a few more fixes for
stable.
- change behaviour of readdir()/rewinddir() when new directory
entries are created after opendir(), properly tracking the last
entry
- fix race in readdir when multiple threads can set the last entry
index for a directory
Additionally:
- use exclusive lock when direct io might need to drop privs and call
notify_change()
- don't clear uptodate bit on page after an error, this may lead to a
deadlock in subpage mode
- fix waiting pattern when multiple readers block on Merkle tree
data, switch to folios"
* tag 'for-6.6-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: fix race between reading a directory and adding entries to it
btrfs: refresh dir last index during a rewinddir(3) call
btrfs: set last dir index to the current last index when opening dir
btrfs: don't clear uptodate on write errors
btrfs: file_remove_privs needs an exclusive lock in direct io write
btrfs: convert btrfs_read_merkle_tree_page() to use a folio
|
|
Now that SCM has support for indicating that SDI has been enabled by
default, lets set the property so SCM disables it during probing.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20230816164641.3371878-4-robimarko@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Update bits to match downstream irq-bitmask values.
Fixes: 0484d3ce0902 ("arm64: dts: qcom: Add DTS for MSM8976 and MSM8956 SoCs")
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Link: https://lore.kernel.org/r/20230812112534.8610-8-a39.skl@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
MSM8976 downstream dts define reloc region which is used by pil-tz
to load both wcnss and lpass, on mainline however we might not be
able to do it and we need separate regions(also validating dts might get
problematic if we had to put memory-region(rproc node) per device).
Luckily it seems size and entry points in firmware headers appears
to be static across multiple devices including Sony Loire platform
and Xiaomi Redmi Note 3 Pro this should let us fit in first ~17MB
Split lpass region(reloc on downstream) into two separate regions.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Link: https://lore.kernel.org/r/20230812112534.8610-7-a39.skl@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
WLED is used for controlling the backlight on some boards, add the node
for it.
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
Link: https://lore.kernel.org/r/20230913185514.21840-1-danila@jiaxyga.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add an ICE node to sa8775p SoC description and enable it by adding a
phandle to the UFS node.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230913153529.32777-2-bartosz.golaszewski@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of fixes, plus a new device ID for Intel Granite
Rapids systems.
The fix for the i.MX driver is fairly urgent, it's fixing a data
corruption issue when bits per word isn't 8.
There's also one fix which was queued but not sent for v6.4 due to
being minor and arriving at the end of the release"
* tag 'spi-fix-v6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: imx: Take in account bits per word instead of assuming 8-bits
spi: intel-pci: Add support for Granite Rapids SPI serial flash
spi: stm32: add a delay before SPI disable
spi: nxp-fspi: reset the FLSHxCR1 registers
spi: zynqmp-gqspi: fix clock imbalance on probe failure
|
|
Both MSM8916 and MSM8939 have unnecessarily large reservations for the
venus firmware for some reason. According to the ELF headers and
downstream [1] 5 MiB is enough. Let's set the minimum size as default.
With the dynamic reserved memory allocations boards can easily override
this if needed, although in practice there does not seem to be any
device with a different venus firmware size.
[1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blame/LA.BR.1.2.9.1-02310-8x16.0/arch/arm/boot/dts/qcom/msm8939-common.dtsi#L69
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-9-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The modem firmware size is typically highly device-specific.
The current size of the mpss_mem region in msm8916.dtsi (0x2b00000)
only works for some APQ8016 devices without full-featured modem,
such as the DragonBoard 410c.
The full modem firmware is typically about twice as large (~45 MiB
-> ~90 MiB) but also varies by a few MiB from device to device. Since
these devices are quite memory-constrained nowadays it's important to
minimize the unnecessary memory reservations.
Make it clear that each board needs to specify the necessary mpss_mem
size by replacing the DB410c-specific size in msm8916.dtsi with a
simple comment. &mpss_mem is disabled by default so it's fine to leave
some properties up to the boards if they want to enable it.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-8-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Now that we no longer have fixed addresses for the firmware memory
regions, disable them by default and only enable them together with
the actual user in the board DT.
This frees up unnecessary reserved memory for boards that do not use
some of the remoteprocs and allows moving selected device-specific
properties (such as firmware size) to the board-specific DT part in
the next step.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-7-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Follow the example of MSM8916 and reserve the firmware memory regions
dynamically to allow boards to define only the device-specific parts.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-6-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
At a first glance the MBA memory region on MSM8916 looks intentionally
placed at the fixed address 0x8ea00000. This is what the ELF headers of
the firmware specify as base address, and the typical Qualcomm-specific
bits suggest the binary is not relocatable.
However, on a closer look this is pointless: Unlike other firmware
images the hardware expects to have the raw ELF image loaded to the MBA
region, including the ELF header (without parsing it at all). This
means that we actually just load the ELF header (not the code!) at
0x8ea00000. The real LOAD segments follow at arbitrary aligned
addresses depending on the structure of the ELF binary.
In practice it looks like we can use an arbitrary 1 MiB-aligned region
for MBA. The downstream/vendor kernel just allocates this dynamically
at an arbitrary (aligned) address.
Drop the pointless fixed address and use the new dynamic reserved
memory mechanism to allocate a region close to the others. This reduces
gaps in the memory map and provides Linux with more contiguous memory.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-5-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Most of the reserved firmware memory on MSM8916 can be relocated when
respecting the required alignment. To avoid having to precompute the
reserved memory regions in every board DT, describe the actual
requirements (size, alignment, alloc-ranges) using the dynamic reserved
memory allocation.
This approach has several advantages:
1. We can define "templates" for the reserved memory regions in
msm8916.dtsi and keep only device-specific details in the board DT.
This is useful for the "mpss" region size for example, which varies
from device to device. It is no longer necessary to redefine all
firmware regions to shift their addresses.
2. When some of the functionality (e.g. WCNSS, Modem, Venus) is not
enabled or needed for a device, the reserved memory can stay
disabled, freeing up the unused reservation for Linux.
3. Devices with special requirements for one of the firmware regions
are handled automatically. For example, msm8916-longcheer-l8150
has non-relocatable "wcnss" firmware that must be loaded exactly
at address 0x8b600000. When this is defined as a static region,
the other dynamic allocations automatically adjust to a different
place with suitable alignment.
All in all this approach significantly reduces the boilerplate necessary
to define the different firmware regions, and makes it easier to enable
functionality on the different devices.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-4-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
gps_mem is needed by the modem firmware for GPS to work. However, it is
accessed via QMI memshare [1] which is not available upstream yet.
Until it lands upstream reserving this does not provide any advantage.
[1]: https://lore.kernel.org/linux-arm-msm/20210319172321.22248-1-nikitos.tr@gmail.com/
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-3-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
MSM8916/39 do not need signed GPU firmware so it is generally okay to
have it enabled by default. However, currently the GPU does not work
without also enabling MDSS and it's questionable if someone would
really need it without a display in practice.
For consistency let's follow newer SoCs and disable the GPU by default.
Enable it for all existing devices that already have &mdss enabled.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-2-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Venus needs firmware that is usually signed with a device-specific key.
There are also devices that might not need it (especially during
bring-up), so let's follow more recent SoCs and disable it by default.
Enable it explicitly for all current devices except msm8916-mtp. That
one has just UART enabled currently so it cannot really benefit from
Venus.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-1-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"One fix for the tps6287x driver which was incorrectly specifying the
field for voltage range selection leading to incorrect voltages being
set"
* tag 'regulator-fix-v6.6-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: Fix voltage range selection
|
|
Assert that vasprintf() succeeds as the "returned" string is undefined
on failure. Checking the result also eliminates the only warning with
default options in KVM selftests, i.e. is the only thing getting in the
way of compile with -Werror.
lib/test_util.c: In function ‘strdup_printf’:
lib/test_util.c:390:9: error: ignoring return value of ‘vasprintf’
declared with attribute ‘warn_unused_result’ [-Werror=unused-result]
390 | vasprintf(&str, fmt, ap);
| ^~~~~~~~~~~~~~~~~~~~~~~~
Don't bother capturing the return value, allegedly vasprintf() can only
fail due to a memory allocation failure.
Fixes: dfaf20af7649 ("KVM: arm64: selftests: Replace str_with_index with strdup_printf")
Cc: Andrew Jones <ajones@ventanamicro.com>
Cc: Haibo Xu <haibo1.xu@intel.com>
Cc: Anup Patel <anup@brainfault.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Tested-by: Andrew Jones <ajones@ventanamicro.com>
Message-Id: <20230914010636.1391735-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts commit ffb6cf19e06334062744b7e3493f71e500964f8e.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit 50e9ceef1d4f644ee0049e82e360058a64ec284c.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit 0269b585868e59b6a2ecc6ea685d39310e4fc18b.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit e44df2664746aed8b6dd5245eb711a0ce33c5cf5.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
This reverts commit d48c3397291690c3576d6c983b0a86ecbc203cac.
Users reported regressions due to enabling multi-grained timestamps
unconditionally. As no clear consensus on a solution has come up and the
discussion has gone back to the drawing board revert the infrastructure
changes for. If it isn't code that's here to stay, make it go away.
Message-ID: <20230920-keine-eile-c9755b5825db@brauner>
Acked-by: Jan Kara <jack@suse.cz>
Acked-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
|
|
sc7180 has an ADSP remoteproc that exclusively controls the audio
hardware on devices that use Qualcomm firmware.
Add it along with the relevant audio services.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20230907-sc7180-adsp-rproc-v3-4-6515c3fbe0a3@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Some devices use tertiary mi2s to connect external audio codec.
Add it near the other two i2s pinctrl definitions so the devices don't
have to duplicate it.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230907-sc7180-adsp-rproc-v3-3-6515c3fbe0a3@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The PMIC IRQ line is attached to GPIO1_IO03, as indicated by pca9451grp
pinctrl config.
Fixes: c982ecfa7992a ("arm64: dts: freescale: add initial device tree for MBa93xxLA SBC board")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
engine->stats is a union of execlist and guc stat objects. When execlist
specific fields are initialized, the initial state of guc stats is
affected. This results in bad busyness values when using GuC mode. Move
the execlist initialization from common code to execlist specific code.
Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu")
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230912212247.1828681-1-umesh.nerlige.ramappa@intel.com
(cherry picked from commit 4485bd519f5d6d620a29d0547ff3c982bdeeb468)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Move the check for "if (IS_ERR(obj))" in front of the call to
i915_gem_object_set_cache_coherency() which dereferences "obj".
Otherwise it will lead to a crash.
Fixes: 43aa755eae2c ("drm/i915/mtl: Update cache coherency setting for context structure")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/455b2279-2e08-4d00-9784-be56d8ee42e3@moroto.mountain
(cherry picked from commit c92ec50822fb84306d951520d81919328421acbd)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
This reverts commit 76a6dd7bfcbb ("arm64: dts: qcom: sm8450: Add PRNG"),
since the RNG HW on the SM8450 SoC is in fact a True Random Number Generator,
a more appropriate compatible should be instead as reported at [1].
[1] https://lore.kernel.org/all/20230818161720.3644424-1-quic_omprsing@quicinc.com/
Suggested-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230828-topic-sm8550-rng-v3-1-7a0678ca7988@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Drop the redundant reg-names and mclk from the PM8916 analog codec that
were removed from the DT schema. Having the mclk on the analog codec is
incorrect because only the digital codec consumes it directly.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230718-pm8916-mclk-v1-6-4b4a58b4240a@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The EDID returned by drm_bridge_get_edid() needs to be freed.
Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR")
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org # v5.17+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230914131015.2472029-1-jani.nikula@intel.com
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.6
Quite a large collection of fixes, with numbers boosted by multiple
vendors sending multi-patch serieses. Nothing super major, and also one
device quirk.
|
|
Buttress spec requires that the interrupt status is cleared at
the source first (before clearing MTL_BUTTRESS_INTERRUPT_STAT),
that implies that we have to mask out the global interrupt while
handling buttress interrupts.
Fixes: 79cdc56c4a54 ("accel/ivpu: Add initial support for VPU 4")
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230822095238.3722815-1-stanislaw.gruszka@linux.intel.com
|
|
When making CONFIG_DEBUG_KMEMLEAK=y and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y,
modprobe handshake-test and then rmmmod handshake-test, the below memory
leak is detected.
The struct socket_alloc which is allocated by alloc_inode_sb() in
__sock_create() is not freed. And the struct dentry which is allocated
by __d_alloc() in sock_alloc_file() is not freed.
Since fput() will call file->f_op->release() which is sock_close() here and
it will call __sock_release(). and fput() will call dput(dentry) to free
the struct dentry. So replace sock_release() with fput() to fix the
below memory leak. After applying this patch, the following memory leak is
never detected.
unreferenced object 0xffff888109165840 (size 768):
comm "kunit_try_catch", pid 1852, jiffies 4294685807 (age 976.262s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa0209ba2>] 0xffffffffa0209ba2
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810f472008 (size 192):
comm "kunit_try_catch", pid 1852, jiffies 4294685808 (age 976.261s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 08 20 47 0f 81 88 ff ff ......... G.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0209bbb>] 0xffffffffa0209bbb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810958e580 (size 224):
comm "kunit_try_catch", pid 1852, jiffies 4294685808 (age 976.261s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0209bbb>] 0xffffffffa0209bbb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926dc88 (size 192):
comm "kunit_try_catch", pid 1854, jiffies 4294685809 (age 976.271s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 88 dc 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208fdc>] 0xffffffffa0208fdc
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a241380 (size 224):
comm "kunit_try_catch", pid 1854, jiffies 4294685809 (age 976.271s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208fdc>] 0xffffffffa0208fdc
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109165040 (size 768):
comm "kunit_try_catch", pid 1856, jiffies 4294685811 (age 976.269s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa0208860>] 0xffffffffa0208860
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926d568 (size 192):
comm "kunit_try_catch", pid 1856, jiffies 4294685811 (age 976.269s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 68 d5 26 09 81 88 ff ff ........h.&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208879>] 0xffffffffa0208879
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a240580 (size 224):
comm "kunit_try_catch", pid 1856, jiffies 4294685811 (age 976.347s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208879>] 0xffffffffa0208879
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109164c40 (size 768):
comm "kunit_try_catch", pid 1858, jiffies 4294685816 (age 976.342s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa0208541>] 0xffffffffa0208541
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926cd18 (size 192):
comm "kunit_try_catch", pid 1858, jiffies 4294685816 (age 976.342s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 18 cd 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa020855a>] 0xffffffffa020855a
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a240200 (size 224):
comm "kunit_try_catch", pid 1858, jiffies 4294685816 (age 976.342s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa020855a>] 0xffffffffa020855a
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109164840 (size 768):
comm "kunit_try_catch", pid 1860, jiffies 4294685817 (age 976.416s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa02093e2>] 0xffffffffa02093e2
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926cab8 (size 192):
comm "kunit_try_catch", pid 1860, jiffies 4294685817 (age 976.416s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 b8 ca 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02093fb>] 0xffffffffa02093fb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810a240040 (size 224):
comm "kunit_try_catch", pid 1860, jiffies 4294685817 (age 976.416s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02093fb>] 0xffffffffa02093fb
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109166440 (size 768):
comm "kunit_try_catch", pid 1862, jiffies 4294685819 (age 976.489s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa02097c1>] 0xffffffffa02097c1
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810926c398 (size 192):
comm "kunit_try_catch", pid 1862, jiffies 4294685819 (age 976.489s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 98 c3 26 09 81 88 ff ff ..........&.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02097da>] 0xffffffffa02097da
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107e0b8c0 (size 224):
comm "kunit_try_catch", pid 1862, jiffies 4294685819 (age 976.489s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa02097da>] 0xffffffffa02097da
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888109164440 (size 768):
comm "kunit_try_catch", pid 1864, jiffies 4294685821 (age 976.487s)
hex dump (first 32 bytes):
01 00 00 00 01 00 5a 5a 20 00 00 00 00 00 00 00 ......ZZ .......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8397993f>] sock_alloc_inode+0x1f/0x1b0
[<ffffffff81a2cb5b>] alloc_inode+0x5b/0x1a0
[<ffffffff81a32bed>] new_inode_pseudo+0xd/0x70
[<ffffffff8397889c>] sock_alloc+0x3c/0x260
[<ffffffff83979b46>] __sock_create+0x66/0x3d0
[<ffffffffa020824e>] 0xffffffffa020824e
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810f4cf698 (size 192):
comm "kunit_try_catch", pid 1864, jiffies 4294685821 (age 976.501s)
hex dump (first 32 bytes):
00 00 50 40 02 00 00 00 00 00 00 00 00 00 00 00 ..P@............
00 00 00 00 00 00 00 00 98 f6 4c 0f 81 88 ff ff ..........L.....
backtrace:
[<ffffffff81a1ff11>] __d_alloc+0x31/0x8a0
[<ffffffff81a2910e>] d_alloc_pseudo+0xe/0x50
[<ffffffff819d549e>] alloc_file_pseudo+0xce/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208267>] 0xffffffffa0208267
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107e0b000 (size 224):
comm "kunit_try_catch", pid 1864, jiffies 4294685821 (age 976.501s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 03 00 2e 08 01 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff819d4b90>] alloc_empty_file+0x50/0x160
[<ffffffff819d4cf9>] alloc_file+0x59/0x730
[<ffffffff819d5524>] alloc_file_pseudo+0x154/0x210
[<ffffffff83978582>] sock_alloc_file+0x42/0x1b0
[<ffffffffa0208267>] 0xffffffffa0208267
[<ffffffff829cf03a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81236fc6>] kthread+0x2b6/0x380
[<ffffffff81096afd>] ret_from_fork+0x2d/0x70
[<ffffffff81003511>] ret_from_fork_asm+0x11/0x20
Fixes: 88232ec1ec5e ("net/handshake: Add Kunit tests for the handshake consumer API")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
before check 'hwdev'
'hwdev' is checked too late and hwdev will not be NULL, so remove the check
Fixes: 2acf960e3be6 ("net: hinic: Add support for configuration of rx-vlan-filter by ethtool")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202309112354.pikZCmyk-lkp@intel.com/
Signed-off-by: Cai Huoqing <cai.huoqing@linux.dev>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If an error occurs after a successful irq_domain_add_linear() call, it
should be undone by a corresponding irq_domain_remove(), as already done
in the remove function.
Fixes: c6ce2b6bffe5 ("gpio: add TB10x GPIO driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Kyle Zeng reported that there is a race between IPSET_CMD_ADD and IPSET_CMD_SWAP
in netfilter/ip_set, which can lead to the invocation of `__ip_set_put` on a
wrong `set`, triggering the `BUG_ON(set->ref == 0);` check in it.
The race is caused by using the wrong reference counter, i.e. the ref counter instead
of ref_netlink.
Fixes: 24e227896bbf ("netfilter: ipset: Add schedule point in call_ad().")
Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
Closes: https://lore.kernel.org/netfilter-devel/ZPZqetxOmH+w%2Fmyc@westworld/#r
Tested-by: Kyle Zeng <zengyhkyle@gmail.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
When more than 255 elements expired we're supposed to switch to a new gc
container structure.
This never happens: u8 type will wrap before reaching the boundary
and nft_trans_gc_space() always returns true.
This means we recycle the initial gc container structure and
lose track of the elements that came before.
While at it, don't deref 'gc' after we've passed it to call_rcu.
Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
Reported-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
nft -f -<<EOF
add table ip t
add table ip t { flags dormant; }
add chain ip t c { type filter hook input priority 0; }
add table ip t
EOF
Triggers a splat from nf core on next table delete because we lose
track of right hook register state:
WARNING: CPU: 2 PID: 1597 at net/netfilter/core.c:501 __nf_unregister_net_hook
RIP: 0010:__nf_unregister_net_hook+0x41b/0x570
nf_unregister_net_hook+0xb4/0xf0
__nf_tables_unregister_hook+0x160/0x1d0
[..]
The above should have table in *active* state, but in fact no
hooks were registered.
Reject on/off/on games rather than attempting to fix this.
Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
Reported-by: "Lee, Cherie-Anne" <cherie.lee@starlabs.sg>
Cc: Bing-Jhong Billy Jheng <billy@starlabs.sg>
Cc: info@starlabs.sg
Signed-off-by: Florian Westphal <fw@strlen.de>
|
|
There are some attributes added by vxlan_fill_info() which are not
accounted for in vxlan_get_size(). Add them.
I didn't find a way to trigger an actual problem from this miscalculation
since there is usually extra space in netlink size calculations like
if_nlmsg_size(); but maybe I just didn't search long enough.
Fixes: 3511494ce2f3 ("vxlan: Group Policy extension")
Fixes: e1e5314de08b ("vxlan: implement GPE")
Fixes: 0ace2ca89cbd ("vxlan: Use checksum partial with remote checksum offload")
Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device")
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists
before dereferencing it as rdma_set_service_type() argument
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: fd261ce6a30e ("rds: rdma: update rdma transport for tos")
Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Since commit:
9257959a6e5b4fca ("locking/atomic: scripts: restructure fallback ifdeffery")
The ordering fallbacks for atomic*_read_acquire() and
atomic*_set_release() erroneously fall back to the implictly relaxed
atomic*_read() and atomic*_set() variants respectively, without any
additional barriers. This loses the ACQUIRE and RELEASE ordering
semantics, which can result in a wide variety of problems, even on
strongly-ordered architectures where the implementation of
atomic*_read() and/or atomic*_set() allows the compiler to reorder those
relative to other accesses.
In practice this has been observed to break bit spinlocks on arm64,
resulting in dentry cache corruption.
The fallback logic was intended to allow ACQUIRE/RELEASE/RELAXED ops to
be defined in terms of FULL ops, but where an op had RELAXED ordering by
default, this unintentionally permitted the ACQUIRE/RELEASE ops to be
defined in terms of the implicitly RELAXED default.
This patch corrects the logic to avoid falling back to implicitly
RELAXED ops, resulting in the same behaviour as prior to commit
9257959a6e5b4fca.
I've verified the resulting assembly on arm64 by generating outlined
wrappers of the atomics. Prior to this patch the compiler generates
sequences using relaxed load (LDR) and store (STR) instructions, e.g.
| <outlined_atomic64_read_acquire>:
| ldr x0, [x0]
| ret
|
| <outlined_atomic64_set_release>:
| str x1, [x0]
| ret
With this patch applied the compiler generates sequences using the
intended load-acquire (LDAR) and store-release (STLR) instructions, e.g.
| <outlined_atomic64_read_acquire>:
| ldar x0, [x0]
| ret
|
| <outlined_atomic64_set_release>:
| stlr x1, [x0]
| ret
To make sure that there were no other victims of the ifdeffery rewrite,
I generated outlined copies of all of the {atomic,atomic64,atomic_long}
atomic operations before and after commit 9257959a6e5b4fca. A diff of
the generated assembly on arm64 shows that only the read_acquire() and
set_release() operations were changed, and only lost their intended
ordering:
| [mark@lakrids:~/src/linux]% diff -u \
| <(aarch64-linux-gnu-objdump -d before-9257959a6e5b4fca.o)
| <(aarch64-linux-gnu-objdump -d after-9257959a6e5b4fca.o)
| --- /proc/self/fd/11 2023-09-19 16:51:51.114779415 +0100
| +++ /proc/self/fd/16 2023-09-19 16:51:51.114779415 +0100
| @@ -1,5 +1,5 @@
|
| -before-9257959a6e5b4fca.o: file format elf64-littleaarch64
| +after-9257959a6e5b4fca.o: file format elf64-littleaarch64
|
|
| Disassembly of section .text:
| @@ -9,7 +9,7 @@
| 4: d65f03c0 ret
|
| 0000000000000008 <outlined_atomic_read_acquire>:
| - 8: 88dffc00 ldar w0, [x0]
| + 8: b9400000 ldr w0, [x0]
| c: d65f03c0 ret
|
| 0000000000000010 <outlined_atomic_set>:
| @@ -17,7 +17,7 @@
| 14: d65f03c0 ret
|
| 0000000000000018 <outlined_atomic_set_release>:
| - 18: 889ffc01 stlr w1, [x0]
| + 18: b9000001 str w1, [x0]
| 1c: d65f03c0 ret
|
| 0000000000000020 <outlined_atomic_add>:
| @@ -1230,7 +1230,7 @@
| 1070: d65f03c0 ret
|
| 0000000000001074 <outlined_atomic64_read_acquire>:
| - 1074: c8dffc00 ldar x0, [x0]
| + 1074: f9400000 ldr x0, [x0]
| 1078: d65f03c0 ret
|
| 000000000000107c <outlined_atomic64_set>:
| @@ -1238,7 +1238,7 @@
| 1080: d65f03c0 ret
|
| 0000000000001084 <outlined_atomic64_set_release>:
| - 1084: c89ffc01 stlr x1, [x0]
| + 1084: f9000001 str x1, [x0]
| 1088: d65f03c0 ret
|
| 000000000000108c <outlined_atomic64_add>:
| @@ -2427,7 +2427,7 @@
| 207c: d65f03c0 ret
|
| 0000000000002080 <outlined_atomic_long_read_acquire>:
| - 2080: c8dffc00 ldar x0, [x0]
| + 2080: f9400000 ldr x0, [x0]
| 2084: d65f03c0 ret
|
| 0000000000002088 <outlined_atomic_long_set>:
| @@ -2435,7 +2435,7 @@
| 208c: d65f03c0 ret
|
| 0000000000002090 <outlined_atomic_long_set_release>:
| - 2090: c89ffc01 stlr x1, [x0]
| + 2090: f9000001 str x1, [x0]
| 2094: d65f03c0 ret
|
| 0000000000002098 <outlined_atomic_long_add>:
I've build tested this with a variety of configs for alpha, arm, arm64,
csky, i386, m68k, microblaze, mips, nios2, openrisc, powerpc, riscv,
s390, sh, sparc, x86_64, and xtensa, for which I've seen no issues. I
was unable to build test for ia64 and parisc due to existing build
breakage in v6.6-rc2.
Fixes: 9257959a6e5b4fca ("locking/atomic: scripts: restructure fallback ifdeffery")
Reported-by: Ming Lei <ming.lei@redhat.com>
Reported-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Baokun Li <libaokun1@huawei.com>
Link: https://lkml.kernel.org/r/20230919171430.2697727-1-mark.rutland@arm.com
|
