Patch "fs/aio: Make io_cancel() generate completions again" is based on the
assumption that calling kiocb->ki_cancel() does not complete R/W requests.
This is incorrect: the two drivers that call kiocb_set_cancel_fn() callers
set a cancellation function that calls usb_ep_dequeue(). According to its
documentation, usb_ep_dequeue() calls the completion routine with status
-ECONNRESET. Hence this revert.
Cc: Benjamin LaHaise <ben@communityfibre.ca>
Cc: Eric Biggers <ebiggers@google.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Avi Kivity <avi@scylladb.com>
Cc: Sandeep Dhavale <dhavale@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: stable@vger.kernel.org
Reported-by: syzbot+b91eb2ed18f599dd3c31@syzkaller.appspotmail.com
Fixes: 54cbc058d8 ("fs/aio: Make io_cancel() generate completions again")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240304182945.3646109-1-bvanassche@acm.org
Acked-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
I will lose access to my @.*intel.com e-mail addresses soon so let me
adjust the maintainers entry and update the mailmap too.
While at it consolidate a few other of my old emails to point to the
main one.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20240228142240.2539358-1-tvrtko.ursulin@linux.intel.com
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGhZs6bAKwk/OTgTpSD+KveBX+j4FAmXizwMACgkQSD+KveBX
+j5uTAf/aI+qZtPXaCykJ86E0IfyPbFHNIK0OSEGuYGXXMABa6s/nBO87qkCVjZc
Lpnr7gj3plGwrHQTY30Ii3h6UpLpSY+LMhGKfGjtQAHiY4PIMIrTIcqp2+H4Zzxm
eK8DT/YUNPs/NT4GAKuwLkwxh9W1dj4fPac2kSth1UqKJnn9Y+GyCfwu4oVL+jhX
wT3P0F04ettHJN71xznmTOMWOBlWExchbdOi07tSvFmUMyDzRAmhFinE/1SrDxnl
l3nB5Qrhe5J1wLJH18gSju5k87sgsjevRqWDwZY+TFf3PEs/HUUqFMP1nmQf4LVF
pW3STDnPI/UyB4GzLn+Z5oDHaARRHw==
=6rTh
-----END PGP SIGNATURE-----
Merge tag 'mlx5-fixes-2024-03-01' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5 fixes 2024-03-01
This series provides bug fixes to mlx5 driver.
Please pull and let me know if there is any problem.
* tag 'mlx5-fixes-2024-03-01' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
net/mlx5e: Switch to using _bh variant of of spinlock API in port timestamping NAPI poll context
net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map
net/mlx5e: Fix MACsec state loss upon state update in offload path
net/mlx5e: Change the warning when ignore_flow_level is not supported
net/mlx5: Check capability for fw_reset
net/mlx5: Fix fw reporter diagnose output
net/mlx5: E-switch, Change flow rule destination checking
Revert "net/mlx5e: Check the number of elements before walk TC rhashtable"
Revert "net/mlx5: Block entering switchdev mode with ns inconsistency"
====================
Link: https://lore.kernel.org/r/20240302070318.62997-1-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2024-03-01 (ixgbe, i40e, ice)
This series contains updates to ixgbe, i40e, and ice drivers.
Maciej corrects disable flow for ixgbe, i40e, and ice drivers which could
cause non-functional interface with AF_XDP.
Michal restores host configuration when changing MSI-X count for VFs on
ice driver.
* '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
ice: reconfig host after changing MSI-X on VF
ice: reorder disabling IRQ and NAPI in ice_qp_dis
i40e: disable NAPI right after disabling irqs when handling xsk_pool
ixgbe: {dis, en}able irqs in ixgbe_txrx_ring_{dis, en}able
====================
Link: https://lore.kernel.org/r/20240301192549.2993798-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Based on the static analyzis of the code it looks like when an entry
from the MAC table was removed, the entry was still used after being
freed. More precise the vid of the mac_entry was used after calling
devm_kfree on the mac_entry.
The fix consists in first using the vid of the mac_entry to delete the
entry from the HW and after that to free it.
Fixes: b37a1bae74 ("net: sparx5: add mactable support")
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240301080608.3053468-1-horatiu.vultur@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kishon updated his email in commit e6aa4edd2f ("MAINTAINERS: Update
Kishon's email address in PCI endpoint subsystem").
However, as he is no longer at TI, his TI email now bounces.
Add the same email as he has in MAINTAINERS to a mailmap, so that
get_maintainer.pl will not output an email that bounces.
(This is neeed as get_maintainer.pl will use "git author" to CC
people who have significantly modified the same file as you.)
Link: https://lkml.kernel.org/r/20240229134318.1201935-1-cassel@kernel.org
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Cc: Kishon Vijay Abraham I <kishon@kernel.org>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
We continue to see false positives from -Warray-bounds even in GCC 10,
which is getting reported in a few places[1] still:
security/security.c:811:2: warning: `memcpy' offset 32 is out of the bounds [0, 0] [-Warray-bounds]
Lower the GCC version check from 11 to 10.
Link: https://lkml.kernel.org/r/20240223170824.work.768-kees@kernel.org
Reported-by: Lu Yao <yaolu@kylinos.cn>
Closes: https://lore.kernel.org/lkml/20240117014541.8887-1-yaolu@kylinos.cn/
Link: https://lore.kernel.org/linux-next/65d84438.620a0220.7d171.81a7@mx.google.com [1]
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Paul Moore <paul@paul-moore.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Marc Aurèle La France <tsi@tuyoix.net>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
When debugging issues with a workload using SysV shmem, Michal Hocko has
come up with a reproducer that shows how a series of mprotect() operations
can result in an elevated shm_nattch and thus leak of the resource.
The problem is caused by wrong assumptions in vma_merge() commit
714965ca82 ("mm/mmap: start distinguishing if vma can be removed in
mergeability test"). The shmem vmas have a vma_ops->close callback that
decrements shm_nattch, and we remove the vma without calling it.
vma_merge() has thus historically avoided merging vma's with
vma_ops->close and commit 714965ca82 was supposed to keep it that way.
It relaxed the checks for vma_ops->close in can_vma_merge_after() assuming
that it is never called on a vma that would be a candidate for removal.
However, the vma_merge() code does also use the result of this check in
the decision to remove a different vma in the merge case 7.
A robust solution would be to refactor vma_merge() code in a way that the
vma_ops->close check is only done for vma's that are actually going to be
removed, and not as part of the preliminary checks. That would both solve
the existing bug, and also allow additional merges that the checks
currently prevent unnecessarily in some cases.
However to fix the existing bug first with a minimized risk, and for
easier stable backports, this patch only adds a vma_ops->close check to
the buggy case 7 specifically. All other cases of vma removal are covered
by the can_vma_merge_before() check that includes the test for
vma_ops->close.
The reproducer code, adapted from Michal Hocko's code:
int main(int argc, char *argv[]) {
int segment_id;
size_t segment_size = 20 * PAGE_SIZE;
char * sh_mem;
struct shmid_ds shmid_ds;
key_t key = 0x1234;
segment_id = shmget(key, segment_size,
IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR);
sh_mem = (char *)shmat(segment_id, NULL, 0);
mprotect(sh_mem + 2*PAGE_SIZE, PAGE_SIZE, PROT_NONE);
mprotect(sh_mem + PAGE_SIZE, PAGE_SIZE, PROT_WRITE);
mprotect(sh_mem + 2*PAGE_SIZE, PAGE_SIZE, PROT_WRITE);
shmdt(sh_mem);
shmctl(segment_id, IPC_STAT, &shmid_ds);
printf("nattch after shmdt(): %lu (expected: 0)\n", shmid_ds.shm_nattch);
if (shmctl(segment_id, IPC_RMID, 0))
printf("IPCRM failed %d\n", errno);
return (shmid_ds.shm_nattch) ? 1 : 0;
}
Link: https://lkml.kernel.org/r/20240222215930.14637-2-vbabka@suse.cz
Fixes: 714965ca82 ("mm/mmap: start distinguishing if vma can be removed in mergeability test")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
After ptep_clear_flush(), if we find that src_folio is pinned we will fail
UFFDIO_MOVE and put src_folio back to src_pte entry, but the change to
src_folio->{mapping,index} is not restored in this process. This is not
what we expected, so fix it.
This can cause the rmap for that page to be invalid, possibly resulting
in memory corruption. At least swapout+migration would no longer work,
because we might fail to locate the mappings of that folio.
Link: https://lkml.kernel.org/r/20240222080815.46291-1-zhengqi.arch@bytedance.com
Fixes: adef440691 ("userfaultfd: UFFDIO_MOVE uABI")
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Sven reports an infinite loop in __alloc_pages_slowpath() for costly order
__GFP_RETRY_MAYFAIL allocations that are also GFP_NOIO. Such combination
can happen in a suspend/resume context where a GFP_KERNEL allocation can
have __GFP_IO masked out via gfp_allowed_mask.
Quoting Sven:
1. try to do a "costly" allocation (order > PAGE_ALLOC_COSTLY_ORDER)
with __GFP_RETRY_MAYFAIL set.
2. page alloc's __alloc_pages_slowpath tries to get a page from the
freelist. This fails because there is nothing free of that costly
order.
3. page alloc tries to reclaim by calling __alloc_pages_direct_reclaim,
which bails out because a zone is ready to be compacted; it pretends
to have made a single page of progress.
4. page alloc tries to compact, but this always bails out early because
__GFP_IO is not set (it's not passed by the snd allocator, and even
if it were, we are suspending so the __GFP_IO flag would be cleared
anyway).
5. page alloc believes reclaim progress was made (because of the
pretense in item 3) and so it checks whether it should retry
compaction. The compaction retry logic thinks it should try again,
because:
a) reclaim is needed because of the early bail-out in item 4
b) a zonelist is suitable for compaction
6. goto 2. indefinite stall.
(end quote)
The immediate root cause is confusing the COMPACT_SKIPPED returned from
__alloc_pages_direct_compact() (step 4) due to lack of __GFP_IO to be
indicating a lack of order-0 pages, and in step 5 evaluating that in
should_compact_retry() as a reason to retry, before incrementing and
limiting the number of retries. There are however other places that
wrongly assume that compaction can happen while we lack __GFP_IO.
To fix this, introduce gfp_compaction_allowed() to abstract the __GFP_IO
evaluation and switch the open-coded test in try_to_compact_pages() to use
it.
Also use the new helper in:
- compaction_ready(), which will make reclaim not bail out in step 3, so
there's at least one attempt to actually reclaim, even if chances are
small for a costly order
- in_reclaim_compaction() which will make should_continue_reclaim()
return false and we don't over-reclaim unnecessarily
- in __alloc_pages_slowpath() to set a local variable can_compact,
which is then used to avoid retrying reclaim/compaction for costly
allocations (step 5) if we can't compact and also to skip the early
compaction attempt that we do in some cases
Link: https://lkml.kernel.org/r/20240221114357.13655-2-vbabka@suse.cz
Fixes: 3250845d05 ("Revert "mm, oom: prevent premature OOM killer invocation for high order request"")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Sven van Ashbrook <svenva@chromium.org>
Closes: https://lore.kernel.org/all/CAG-rBihs_xMKb3wrMO1%2B-%2Bp4fowP9oy1pa_OTkfxBzPUVOZF%2Bg@mail.gmail.com/
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Curtis Malainey <cujomalainey@chromium.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
ASoC machine driver can use snd_soc_{of_}get_dlc() (A) to get DAI name
for dlc (snd_soc_dai_link_component). In this function call
dlc->dai_name is parsed via snd_soc_dai_name_get() (B).
(A) int snd_soc_get_dlc(...)
{
...
(B) dlc->dai_name = snd_soc_dai_name_get(dai);
...
}
(B) has a priority to return dai->name as dlc->dai_name. In most cases
card can probe successfully. However it has an issue that ASoC tries to
rebind card. Here is a simplified flow for example:
| a) Card probes successfully at first
| b) One of the component bound to this card is removed for some
| reason the component->dev is released
| c) That component is re-registered
v d) ASoC calls snd_soc_try_rebind_card()
a) points dlc->dai_name to dai->name. b) releases all resource of the
old DAI. c) creates new DAI structure. In result d) can not use
dlc->dai_name to add new created DAI.
So it's reasonable that prefer to return dai->driver->name in
snd_soc_dai_name_get() because dai->driver is a pre-defined global
variable. Also update snd_soc_is_matching_dai() for alignment.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Link: https://msgid.link/r/20240304072128.2845432-1-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a KUnit test for the cs-amp-lib library. This has test cases
for cs_amp_get_efi_calibration_data() and cs_amp_write_cal_coeffs().
A KUNIT_STATIC_STUB_REDIRECT() has been added to
cs_amp_get_efi_variable() and cs_amp_write_cal_coeff() so that the
KUnit test can redirect these to test harness functions.
Much of the testing involves invoking the same function with different
parameters, i.e. the number of amps and the amp index within the array.
This uses parameterization rather than looping. The idea is to avoid
looping over configurations within one test case as that has a higher
chance of having a bug that doesn't actually test all the expected cases.
Having the test run exactly one configuration, and then tear-down, is less
prone to accidentally skipped configurations.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://msgid.link/r/20240304143705.26362-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
cocci warnings: (new ones prefixed by >>)
>> drivers/firmware/microchip/mpfs-auto-update.c:387:72-78:
ERROR: application of sizeof to pointer
drivers/firmware/microchip/mpfs-auto-update.c:170:72-78:
ERROR: application of sizeof to pointer
response_msg is a pointer to u32, so the size of element it points to is
supposed to be a multiple of sizeof(u32), rather than sizeof(u32 *).
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202403040516.CYxoWTXw-lkp@intel.com/
Signed-off-by: Dawei Li <dawei.li@shingroup.cn>
Fixes: ec5b0f1193 ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
The HP Pavilion Aero Laptop 13-be2xxx(8BD6) requires a quirk entry for its internal microphone to function.
Signed-off-by: Al Raj Hassain <alrajhassain@gmail.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://msgid.link/r/20240304103924.13673-1-alrajhassain@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Timing select registers for SRC and CMD are by default
referring to the corresponding SSI word select.
The calculation rule from HW spec skips SSI8, which has
no clock connection.
>From section 43.2.18 CMD Output Timing Select Register (CMDOUT_TIMSEL),
of R-Car Series, 3rd Generation Hardware User’s Manual Rev.2.20:
CMD0_OUT_DIVCLK_ Output Timing
SEL [4:0] Signal Select
B'0 0110: ssi_ws0
B'0 0111: ssi_ws1
B'0 1000: ssi_ws2
B'0 1001: ssi_ws3
B'0 1010: ssi_ws4
B'0 1011: ssi_ws5
B'0 1100: ssi_ws6
B'0 1101: ssi_ws7
<GAP>
B'0 1110: ssi_ws9
B'0 1111: Setting prohibited
Fix the erroneous prohibited setting of timsel value 1111 (0xf) for SSI9
by using timsel value 1110 (0xe) instead. This is possible because SSI8
is not connected as shown by <GAP> in the table above.
[21.695055] rcar_sound ec500000.sound: b adg[0]-CMDOUT_TIMSEL (32):00000f00/00000f1f
Correct the timsel assignment.
Fixes: 629509c5bc ("ASoC: rsnd: add Gen2 SRC and DMAEngine support")
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Andreas Pape <Andreas.Pape4@bosch.com>
Signed-off-by: Yeswanth Rayapati <yeswanth.rayapati@in.bosch.com>
Tested-by: Yeswanth Rayapati <yeswanth.rayapati@in.bosch.com>
[erosca: massage commit description]
Signed-off-by: Eugeniu Rosca <eugeniu.rosca@bosch.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://msgid.link/r/20240301085003.3057-1-erosca@de.adit-jv.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The current measured frame rate is 59.95Hz, which does not meet the
requirements of touch-stylus and stylus cannot work normally. After
adjustment, the actual measurement is 60.001Hz. Now this panel looks
like it's only used by me on the MTK platform, so let's change this
set of parameters.
[ dianders: Added "(again") to subject and fixed the "Fixes" line ]
Fixes: cea7008190 ("drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBP")
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240301061128.3145982-1-yangcong5@huaqin.corp-partner.google.com
The linear ranges aren't really matching what they should be. Indeed,
the range is inclusive of the min value, so it makes sense the previous
range does NOT include the max step value representing the min value of
the range in question.
Since 3.4V is represented by the decimal value 232, the previous range
max step value should be 231 and not 232.
No expected change in behavior since 3.4V was mapped with step 232 from
the first range but is now mapped with step 232 from the second range.
While at it, remove the incorrect comment from the second range.
Fixes: f991a220a4 ("regulator: rk808: add rk806 support")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-2-3904ab70d250@theobroma-systems.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The linear ranges aren't really matching what they should be. Indeed,
the range is inclusive of the min value, so it makes sense the previous
range does NOT include the max step value representing the min value of
the range in question.
Since 1.5V is represented by the decimal value 160, the previous range
max step value should be 159 and not 160. Similarly, 3.4V is represented
by the decimal value 236, so the previous range max value should be 235
and not 237.
The only change in behavior this makes is that this actually modeled
the ranges to map step with decimal value 237 with 3.65V instead of
3.4V (the max supported by the HW).
Fixes: f991a220a4 ("regulator: rk808: add rk806 support")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-1-3904ab70d250@theobroma-systems.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This contains two fixes to make the MGBE Ethernet devices found on
Tegra234 work properly.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmXY2ekACgkQ3SOs138+
s6GI7xAAmXPB8boojnCr+WQmh6L1akDS8qHicDS7frL/ySf7quZ0mxM8lYwn2DEh
fGl62amo3s8Qqm+IRcMw/H4gA51U7XSOglxpxpY3KpgghysQgxuSJ7NbYZYLaUyn
dnr3dLvesEbChJGgcOHTBKo75oa2gd0tWST69csNMZbp1FKUHq4DeF77j3NBLeYb
9UIZ1rXSo9VqKNBKrlPwaNdTWVoC4xOmIVkGLvJNlIuNN1+IfhZyxRNuHWoWp6Co
vWDqrAoIIYWfzNWeizm7unvWepRZfLx6fKBlLghifpQ7aRvcJeOKcSXDe8wW7Qz4
sWCtCHnNjuCnGD6UVyUY8MaYx3P3og1/vt8ywLa8MJblYQ6ki/RAsIyXdxJea3ZD
A1r6UEypDtj14WKHhIFvluMSxBlPDHFYU8cyBGXcE4EqKYZwXSpU6TMiyrVz86Iw
PEoBIj9wvRxaf5LdEYccuGZj+z8awC0syS0uDHVN1oa2KZASgKJrhyrQQHzI0t7F
n6tiBh7xaDIHhyCCmLZiqwHf9zBEjiA1a4sZBFcQGTuXwoaePGb9DO8vwSkRNQa2
2GjWaPbfvOFhznOE+6bn6gEa9ymkQLATPnaM7ENiLfnsIFeF1zpG/MSoR+eK/Img
sq4r8+dHwkZpC8iVQv6ix1X9fk8XizKeNiG4iuABPmdX/+bf+Os=
=b7sU
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXl2c0ACgkQYKtH/8kJ
UidOrw//WAoCu3ExvDZRQYD8JpiIuQ7kv35ABz83TeM8xcLCvxJMxEs9+h8BthRA
vrRpLh2clYD42xixQisD2ac4fxHvHgzssbuvlbj+lzE+TTKy3j5MAv/7OiR94GCy
yu2VSBd3ST45lN9XPnxN+R2fwP1rdn2ByfKrODUB0gCgbG6cCNVh+Ba3mbABwbN2
RaJ6eEH15bqZ/BKtuCpIPkf0M4AzSLRY4cjLKm6cOPGe2J515vUn9/1gqUDlXZyB
4lsiGwlpDJTey6szHxqzPFPMb+nLQJK7GM5tVq3s24DoJ2XFD6mhJSrpa5PYAVdB
5DF68fBNar+Oas9TYE3KOIVy6M1wat1ga5zaQIMwXmQHeHnyv32Gt4iEVGF6AUBC
v69Mj/VJ8NMGUTLd5S9tQ6ZQcl1TUC0SMHaavyVfbWxcIJ94u1sz5vheU0JGBcMW
DHsvVCZerv2q7IjhZ+DT0xyW6jCsWwqvmi0pj+3X+MiWt5k3tiK41HOCriX/IAwk
dYhwwMH+FbZTjoROG7UVc9I2SRGg6XP1FQ7/CCYidPoDcajii9UvaiVgXxQtzyEe
F3UahafQ5xMO0YLrDjgTp9Y/JscRbW0tI9LEQDx6QH3YAVmGR302jnWtNVA8SRoL
Mgs4lGKa45GuyvPbp7ToW/WjI2F0xtV33PmH0oU8vTbJqyyzJ5U=
=Ad8s
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-6.8-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
arm64: tegra: Device tree fixes for v6.8
This contains two fixes to make the MGBE Ethernet devices found on
Tegra234 work properly.
* tag 'tegra-for-6.8-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Fix Tegra234 MGBE power-domains
arm64: tegra: Set the correct PHY mode for MGBE
Link: https://lore.kernel.org/r/20240226144536.1525704-1-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Update MAINTAINERS to use a public mailing list for NXP i.MX
development.
- Re-enable CONFIG_BACKLIGHT_CLASS_DEVICE in imx_v6_v7_defconfig to fix
a backlight regression.
- Remove DSI port endpoints from i.MX7 SoC DTSI to fix a display
regression.
- Fix LDB clocks property for i.MX8MP device tree.
- Fix TC9595 reset GPIO on DH i.MX8M Plus DHCOM SoM.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmXbTckUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM78BQf9GRuY8jwenOGOoUFksUJrZzl6a/nl
glYzNyq4t4i91xDE9rU+GtoQe+DjWgKYftiR2pgHNv/uCKIPO+6D4yfLG/eyQet9
Z1kknUg6kUndiOaWaZ3FiiY3JUoUWHjaXw2REY8ksyVpRQ2fVtSOI2IeFtqIqFuQ
X1Fx7slntIcbGpbc3iGzZVTi7+ucShYjaVUWUd588iayQsXyHLqz/RxYRVlaErYF
BElc5Nm+Auw+8Mr+jz2Q71dn+qOI806V+IvqrTGX8PauCk9WsF/TsYcm6MzrhgKh
4N+NNpqLY11Ty9i+K6OS6qE77jVZ9xxe2UUk0qfa8xWujIGFlLpl3e8q8A==
=0xer
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXl2ZwACgkQYKtH/8kJ
UietfhAAgm1N4FQRIeWC38uzbR/MN4O29zXEOPNdAYnUdwB8r5gizrViFzsss8al
EnHDkYzm3k1dnWyRw/gF1BWXLF2lUim2d9ohjYUD3i/HjmLFN4W8vyz0eKUtZrDb
WAM7Bz9J5QKM+jsi93nXbWznoNArUKjIltwveka0VAS1Mn1HEgcY27as5rPzH3qV
iWykR6eOMbpCaVQAS1dAt6woa8kvyJGvxnHNtpE/Ac+KeZXjCjHulY7/RK7ZpeHM
JtufwjzmBltJ3a6G1vergUsH4FIGMJNMBCEKq9cWrSz1gxov1FxOTiokzCp7pQd/
p8q5xU7NNe0kLosXTxIW2j8rYarQVHy0EaiqwzNi3rwvLBucTc9bbB/B4eEiG6Nm
HB75/FMu54Xbt/Nt7ov+mgpD62ZjMpypyxsRoiffse170RyyiIqoQvWtSSQML/ef
E0jnv7P+4/Dh9/NxM1I5+RXlfz8b3v8bA5AxINwpiEXYPnNwRX5gxFFF/qQwLVD5
P3botb12Ly0gnJBCc84d+G4/BYlrzG/ktNIPlih6XaDXdnzjQkDpRnHAWWKYAeBp
WwiIu5mL+CHlplYlwgep2tBkZeoSJCVUih32YxKeJRYFCmJcufaGvOIO3FcpostE
1zCnF58PDk6J4XApjx+2oihRoIwmJ1gQ/9FswzNBMT76H49csIg=
=3Eab
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 6.8, round 2:
- Update MAINTAINERS to use a public mailing list for NXP i.MX
development.
- Re-enable CONFIG_BACKLIGHT_CLASS_DEVICE in imx_v6_v7_defconfig to fix
a backlight regression.
- Remove DSI port endpoints from i.MX7 SoC DTSI to fix a display
regression.
- Fix LDB clocks property for i.MX8MP device tree.
- Fix TC9595 reset GPIO on DH i.MX8M Plus DHCOM SoM.
* tag 'imx-fixes-6.8-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: dts: imx8mp: Fix LDB clocks property
arm64: dts: imx8mp: Fix TC9595 reset GPIO on DH i.MX8M Plus DHCOM SoM
MAINTAINERS: Use a proper mailinglist for NXP i.MX development
ARM: dts: imx7: remove DSI port endpoints
ARM: imx_v6_v7_defconfig: Restore CONFIG_BACKLIGHT_CLASS_DEVICE
Link: https://lore.kernel.org/r/ZdtPJzdenRybI+Bq@dragon
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This marks an additional GPIO as protected on SM8650 devices, to avoid
a system reset caused by a security violation with some firmware
versions.
It also adds the missing interconnect-names, which resolves a regression
where one of the I2C busses on SM6115 devices would no longer probe in
Linux.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmXaqtsVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FztYP/0zH8fB4JBYTxsPwO7/ZYuwPgWuF
HjfNIfmNyPq87u2GV3BXtTGIXNBZIJeC6gW9HJWYj67OaCJHWebZqwXbSFTveDr8
G60OwT4vO5SoEFgDv+y1Q5xlWZ1eurzplu/shH1J+aGzj3RSoBsZ/8wcmEszVQ8x
FO0pkPyrQY8I2kEfyYyAM1Q1rQe4STESP1ijEcZBFKdRRxQIyR/nxdz8V22wbmrf
kImpzCGX+IJj0Lu3klvsKwZVBLfksOiijRXDzangpoEW/Lnwjk2AWWYGNm/J3vCx
cfplkWVLGydPmNsoMlCghGA3Qq17lmD8nlXJLOVk14wa/urf4J6gZ03lu8vS9k/A
bAetQCqrPHq7FsGspxR/uZXjF2/9Zk2w+J7ASuhpu3cbssCJT7upBP7kexc2mjPv
ASgPpxtFhIdRoqNhQ/6dB/LTxIc0qv7OXKuXtqz0TpSiOtF2vGBpCjInAsmfNfWH
sSgJ8FtX6Iov4q7QWEt5zn4bdM4kRjaOipe98qGzSXW+BLVQm8ALx/G4WKemTS6i
+hIt5MJExhrvrNsbknCwvEAzBwmxO456N6vwMbgXJBdED/JtVDbCcgVjiq65ityZ
PY8gakw9u5oIvBTYWrRdVm9SJe/LBWxhIYNuWpSEuJh8tW6k4DH5oghxisKC7xt7
QzAjQhR9Aa7OUn6V
=XtCr
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmXl2W4ACgkQYKtH/8kJ
UidKTg//eshErspYoVmC9lMU+8vdrDD0rYdGX21OM7aHBMhp1iy5bbprQ7/BEfST
i7s83FzgpcTxes8FltEQW6u/uev/WrLCfQ77MF2aI/RC8awkMmKRSVjOjMedl/3C
aCrtIQJI8bMY4x9fLJPnSVG523wf5ekVWXiH6j4lY7zWGbecS0B4eL2vYC/RWXVT
WiF2g6/IUjxkYXk8mAxEbUA5SL1m92zjwUc39jRJQrVmVTb/zoVJr5rEIdXZ/El+
9/CK56Vg75ajGWQNwt2APyQR65NxH1nIgktYwiz9HcBK47fifnM8lpD0709HvT7c
8V8hZ0Tn7q2NbfCM3eCn2IoRgSFYPPtHFw3B/TakTW3ZxQUYYkdRyixNiulaAOkJ
sjcDuxYhQ2CsnAfhgblXd06Oqd/GlMTUFOyGxsydnWY73san2L3eWchczzAHSVoH
/IiiW0Q0QGiL0RjUDGvppxfBC7kzOWgfABp2jWPkwHU1yaVfNsLrUgh+EsDevS3m
C+d9/kYVVjgu1hTQGgTXPVMPVeDt1Weyuv6sYIlf6KnNchMXOFJfYzTXgYwxBtaU
CsAC23HSBV3EkuuRte3cbGrvyLTJsMOBEQ98zNHCa0Y9yVkdY5zWqDpi6qizX1KJ
si2Py/LwK68a+WdljcP05K/vMuqxNN7oV5w8DSSxC0O881Y6AAE=
=30J9
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM64 DeviceTree fixes for 6.8
This marks an additional GPIO as protected on SM8650 devices, to avoid
a system reset caused by a security violation with some firmware
versions.
It also adds the missing interconnect-names, which resolves a regression
where one of the I2C busses on SM6115 devices would no longer probe in
Linux.
* tag 'qcom-arm64-fixes-for-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: sm6115: Fix missing interconnect-names
arm64: dts: qcom: sm8650-mtp: add gpio74 as reserved gpio
arm64: dts: qcom: sm8650-qrd: add gpio74 as reserved gpio
Link: https://lore.kernel.org/r/20240225025205.479589-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Matthieu Baerts says:
====================
selftests: mptcp: fixes for diag.sh
Here are two patches fixing issues in MPTCP diag.sh kselftest:
- Patch 1 makes sure the exit code is '1' in case of error, and not the
test ID, not to return an exit code that would be wrongly interpreted
by the ksefltests framework, e.g. '4' means 'skip'.
- Patch 2 avoids waiting for unnecessary conditions, which can cause
timeouts in some very slow environments.
====================
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
When creating a lot of listener sockets, it is enough to wait only for
the last one, like we are doing before in diag.sh for other subtests.
If we do a check for each listener sockets, each time listing all
available sockets, it can take a very long time in very slow
environments, at the point we can reach some timeout.
When using the debug kconfig, the waiting time switches from more than
8 sec to 0.1 sec on my side. In slow/busy environments, and with a poll
timeout set to 30 ms, the waiting time could go up to ~100 sec because
the listener socket would timeout and stop, while the script would still
be checking one by one if all sockets are ready. The result is that
after having waited for everything to be ready, all sockets have been
stopped due to a timeout, and it is too late for the script to check how
many there were.
While at it, also removed ss options we don't need: we only need the
filtering options, to count how many listener sockets have been created.
We don't need to ask ss to display internal TCP information, and the
memory if the output is dropped by the 'wc -l' command anyway.
Fixes: b4b51d36bb ("selftests: mptcp: explicitly trigger the listener diag code-path")
Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://lore.kernel.org/r/20240301063754.2ecefecf@kernel.org
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The test counter 'test_cnt' should not be returned in diag.sh, e.g. what
if only the 4th test fail? Will do 'exit 4' which is 'exit ${KSFT_SKIP}',
the whole test will be marked as skipped instead of 'failed'!
So we should do ret=${KSFT_FAIL} instead.
Fixes: df62f2ec3d ("selftests/mptcp: add diag interface tests")
Cc: stable@vger.kernel.org
Fixes: 42fb6cddec ("selftests: mptcp: more stable diag tests")
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
If drm_kms_helper_poll=n the output poll work will only get scheduled
from drm_helper_probe_single_connector_modes() to handle a delayed
hotplug event. Since polling is disabled the work in this case should
just call drm_kms_helper_hotplug_event() w/o detecting the state of
connectors and rescheduling the work.
After commit d33a54e399 after a delayed hotplug event above the
connectors did get re-detected in the poll work and the work got
re-scheduled periodically (since poll_running is also false if
drm_kms_helper_poll=n), in effect ignoring the drm_kms_helper_poll=n
kernel param.
Fix the above by calling only drm_kms_helper_hotplug_event() for a
delayed hotplug event if drm_kms_helper_hotplug_event=n, as was done
before d33a54e399.
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: d33a54e399 ("drm/probe_helper: sort out poll_running vs poll_enabled")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240301152243.1670573-1-imre.deak@intel.com
If message fills up we need to stop writing. 'break' will
only get us out of the iteration over pools of a single
netdev, we need to also stop walking netdevs.
This results in either infinite dump, or missing pools,
depending on whether message full happens on the last
netdev (infinite dump) or non-last (missing pools).
Fixes: 950ab53b77 ("net: page_pool: implement GET in the netlink API")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I'm updating __assign_str() and will be removing the second parameter. To
make sure that it does not break anything, I make sure that it matches the
__string() field, as that is where the string is actually going to be
saved in. To make sure there's nothing that breaks, I added a WARN_ON() to
make sure that what was used in __string() is the same that is used in
__assign_str().
In doing this change, an error was triggered as __assign_str() now expects
the string passed in to be a char * value. I instead had the following
warning:
include/trace/events/qdisc.h: In function ‘trace_event_raw_event_qdisc_reset’:
include/trace/events/qdisc.h:91:35: error: passing argument 1 of 'strcmp' from incompatible pointer type [-Werror=incompatible-pointer-types]
91 | __assign_str(dev, qdisc_dev(q));
That's because the qdisc_enqueue() and qdisc_reset() pass in qdisc_dev(q)
to __assign_str() and to __string(). But that function returns a pointer
to struct net_device and not a string.
It appears that these events are just saving the pointer as a string and
then reading it as a string as well.
Use qdisc_dev(q)->name to save the device instead.
Fixes: a34dac0b90 ("net_sched: add tracepoints for qdisc_reset() and qdisc_destroy()")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There was one overlooked place to be replaced with
snd_ctl_find_id_mixer() for code simplification.
No functional change, only code refactoring.
Link: https://lore.kernel.org/r/20240304082158.8583-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HDMI codecs which are present and functional from audio perspective lack
i915 support on drm side what results in -ENODEV during the probing
sequence. There is no reason to perform recovery procedure e.g.: reset
the HDAudio controller if this is the case.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240226124432.1203798-4-cezary.rojewski@intel.com
If i915 does not support given platform but the hardware i.e.: HDAudio
codec is still there, the codec-probing procedure will succeed for such
device but the follow up initialization will always end up with -ENODEV.
While bus could filter out address '2' which Intel's HDMI/DP codecs
always enumerate on, more robust approach is to check for i915 presence
before registering display codecs.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240226124432.1203798-3-cezary.rojewski@intel.com
Commit 78f613ba1e ("drm/i915: finish removal of CNL") and its friends
removed support for i915 for all CNL-based platforms. HDAudio library,
however, still treats such platforms as valid candidates for i915
binding. Update query mechanism to reflect changes made in drm tree.
At the same time, i915 support for LKF-based platforms has not been
provided so remove them from valid binding candidates.
Link: https://lore.kernel.org/all/20210728215946.1573015-1-lucas.demarchi@intel.com/
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20240226124432.1203798-2-cezary.rojewski@intel.com
When building feature controls from a unit without a name, we try to
derive a name first from the feature unit's input, then fall back to the
output terminal.
If a feature unit connects directly to a "USB Streaming" input terminal
rather than a mixer or other virtual type, the control receives the
somewhat meaningless name "PCM", even if the output had a descriptive
type such as "Headset" or "Speaker".
Here is an example of such AudioControl descriptor from a USB headset
which ends up named "PCM Playback" and is therefore not recognized as
headphones by userspace:
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 4
wTerminalType 0x0101 USB Streaming
bAssocTerminal 5
bNrChannels 2
wChannelConfig 0x0003
Left Front (L)
Right Front (R)
iChannelNames 0
iTerminal 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 5
wTerminalType 0x0402 Headset
bAssocTerminal 4
bSourceID 6
iTerminal 0
AudioControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 6
bSourceID 4
bControlSize 2
bmaControls(0) 0x0002
Volume Control
bmaControls(1) 0x0000
bmaControls(2) 0x0000
iFeature 0
Other headsets and DACs I tried that used their output terminal for
naming only did so due to their input being an unnamed sidetone mixer.
Instead of always starting with the input terminal, check the type of it
first. If it seems uninteresting, invert the order and use the output
terminal first for naming.
This makes userspace recognize headsets with simple controls as
headphones, and leads to more consistent naming of playback devices
based on their outputs irrespective of sidetone mixers.
Signed-off-by: Kenny Levinsen <kl@kl.wtf>
Link: https://lore.kernel.org/r/20240301231107.42679-1-kl@kl.wtf
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Whilst this laptop contains _DSD inside the BIOS, there is an error in
this configuration. Override the _DSD in the BIOS with the correct
configuration for this laptop.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20240301160154.158398-4-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When not configured for wakeup lis3lv02d_i2c_suspend() will call
lis3lv02d_poweroff() even if the device has already been turned off
by the runtime-suspend handler and if configured for wakeup and
the device is runtime-suspended at this point then it is not turned
back on to serve as a wakeup source.
Before commit b1b9f7a494 ("misc: lis3lv02d_i2c: Add missing setting
of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable
the regulators which as a side effect made calling poweroff() twice ok.
Now that poweroff() correctly disables the regulators, doing this twice
triggers a WARN() in the regulator core:
unbalanced disables for regulator-dummy
WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable
...
Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if
already runtime-suspended and add a poweron() call when necessary to
make wakeup work.
lis3lv02d_i2c_resume() has similar issues, with an added weirness that
it always powers on the device if it is runtime suspended, after which
the first runtime-resume will call poweron() again, causing the enabled
count for the regulator to increase by 1 every suspend/resume. These
unbalanced regulator_enable() calls cause the regulator to never
be turned off and trigger the following WARN() on driver unbind:
WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put
Fix this by making lis3lv02d_i2c_resume() mirror the new suspend().
Fixes: b1b9f7a494 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://lore.kernel.org/regressions/5fc6da74-af0a-4aac-b4d5-a000b39a63a5@molgen.mpg.de/
Cc: stable@vger.kernel.org
Cc: regressions@lists.linux.dev
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 15 7590
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20240220190035.53402-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 09896da073 ("arm64: dts: qcom: msm8996: Hook up MPM") has
hooked up the MPM irq chip on the MSM8996 platform. However this causes
my Dragonboard 820c crash during bootup (usually when probing IOMMUs).
Revert the offending commit for now. Quick debug shows that making
tlmm's wakeup-parent point to the MPM is enough to trigger the crash.
Fixes: 09896da073 ("arm64: dts: qcom: msm8996: Hook up MPM")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20240221-msm8996-revert-mpm-v1-1-cdca9e30c9b4@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add additional HyperX device identifiers to xpad_device and xpad_table.
Suggested-by: Chris Toledanes<chris.toledanes@hp.com>
Reviewed-by: Carl Ng <carl.ng@hp.com>
Signed-off-by: Max Nguyen <maxwell.nguyen@hp.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/44ad5ffa-76d8-4046-94ee-2ef171930ed2@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Driver fixes for:
- dw-edma fixes to improve driver and remote HDMA setup
- fsl-edma fixes for SoC hange, irq init and byte calculations
and sparse fixes
- idxd: safe user copy of completion record fix
- ptdma: consistent DMA mask fix
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+vs47OPLdNbVcHzyfBQHDyUjg0cFAmXkqM4ACgkQfBQHDyUj
g0flMg//bgnkYdt/Y4nDbJxPobQHSOLl86GbD9mIddeocwdsA/QQ4uz/WzN+rngY
0M7/7Zfq+RMq6lfesLMJ5DXycYBGIMQYZ1ItpIL4Xw3sSo2i6qFn18dSqbesRpkB
bsfdrbqCEHWwghkBszoTGXGx24XRdQzTUmMziL9jqdIvXXf5HCKeGSZnC5L6ssxs
JfdCee7ZSPK6gOVlBlN8zjzG8ZI2bwH+B1okyZwWljorPInr8UQ3ysR3neEUab6O
JMzVmp46LhTQmHEZxzBbfR18rbVhr0xRRs78UwJPhPrgp9PFOkxdLl9lGDh8Fa2x
jApi9cl5rSrW2bEv5fe8k5EM64G9G5arJU9F6+Goqm39ftDTktKBPhwmIR/NqOZF
AHmW2c+0trDMOg099oWd+ozgbMkdbrdjf6BA9vSLKsXLTFHDZEA1fEKifJP5NCSQ
ZQJVpQn0wiBOQSJxpr4mbk/n5JeKzt/uyQSF8Qo8Kp9OWXiNrjWzJ0bZnVafkTlU
E91WGiGjYQmh28DV432IM07IXVKLtIMa/BXuWMhOZY+/HUJK/AaRStxEB5kkLJDm
EExDe23Rviu0lXDW4cH+R14d4L/9EJY87Ynm2p85rOj/rnwW9gWyu3BwD3aBXa2e
yKlng355WCBISMl8wXpeMQe1/yaxf48YLdrmdLD95bT0w5Dc0gc=
=mX0o
-----END PGP SIGNATURE-----
Merge tag 'dmaengine-fix2-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine
Pull dmaengine fixes from Vinod Koul:
- dw-edma fixes to improve driver and remote HDMA setup
- fsl-edma fixes for SoC hange, irq init and byte calculations and
sparse fixes
- idxd: safe user copy of completion record fix
- ptdma: consistent DMA mask fix
* tag 'dmaengine-fix2-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine:
dmaengine: ptdma: use consistent DMA masks
dmaengine: fsl-qdma: add __iomem and struct in union to fix sparse warning
dmaengine: idxd: Ensure safe user copy of completion record
dmaengine: fsl-edma: correct max_segment_size setting
dmaengine: idxd: Remove shadow Event Log head stored in idxd
dmaengine: fsl-edma: correct calculation of 'nbytes' in multi-fifo scenario
dmaengine: fsl-qdma: init irq after reg initialization
dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read
dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup
dmaengine: dw-edma: HDMA: Add sync read before starting the DMA transfer in remote setup
dmaengine: dw-edma: Add HDMA remote interrupt configuration
dmaengine: dw-edma: HDMA_V0_REMOTEL_STOP_INT_EN typo fix
dmaengine: dw-edma: Fix wrong interrupt bit set for HDMA
dmaengine: dw-edma: Fix the ch_count hdma callback
