<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v6.6.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-11-20T10:59:39+00:00</updated>
<entry>
<title>Revert "mmc: core: Capture correct oemid-bits for eMMC cards"</title>
<updated>2023-11-20T10:59:39+00:00</updated>
<author>
<name>Dominique Martinet</name>
<email>dominique.martinet@atmark-techno.com</email>
</author>
<published>2023-11-03T00:42:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd389b213f9df9d85c4af990259d96f16b4a0797'/>
<id>urn:sha1:cd389b213f9df9d85c4af990259d96f16b4a0797</id>
<content type='text'>
commit 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 upstream.

This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff.

The commit above made quirks with an OEMID fail to be applied, as they
were checking card-&gt;cid.oemid for the full 16 bits defined in MMC_FIXUP
macros but the field would only contain the bottom 8 bits.

eMMC v5.1A might have bogus values in OEMID's higher bits so another fix
will be made, but it has been decided to revert this until that is ready.

Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards")
Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org
Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com
Signed-off-by: Dominique Martinet &lt;dominique.martinet@atmark-techno.com&gt;
Cc: stable@vger.kernel.org
Cc: Alex Fetters &lt;Alex.Fetters@garmin.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "PCI/ASPM: Disable only ASPM_STATE_L1 when driver, disables L1"</title>
<updated>2023-11-20T10:59:39+00:00</updated>
<author>
<name>Heiner Kallweit</name>
<email>hkallweit1@gmail.com</email>
</author>
<published>2023-10-11T07:36:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=84d24fe40db03eb3bc0d92c0b6e17fa972f9d2b7'/>
<id>urn:sha1:84d24fe40db03eb3bc0d92c0b6e17fa972f9d2b7</id>
<content type='text'>
commit 3cb4f534bac010258b2688395c2f13459a932be9 upstream.

This reverts commit fb097dcd5a28c0a2325632405c76a66777a6bed9.

After fb097dcd5a28 ("PCI/ASPM: Disable only ASPM_STATE_L1 when driver
disables L1"), disabling L1 via pci_disable_link_state(PCIE_LINK_STATE_L1),
then enabling one substate, e.g., L1.1, via sysfs actually enables *all*
the substates.

For example, r8169 disables L1 because of hardware issues on a number of
systems, which implicitly disables the L1.1 and L1.2 substates.

On some systems, L1 and L1.1 work fine, but L1.2 causes missed rx packets.
Enabling L1.1 via the sysfs "aspm_l1_1" attribute unexpectedly enables L1.2
as well as L1.1.

After fb097dcd5a28, pci_disable_link_state(PCIE_LINK_STATE_L1) adds only
ASPM_L1 (but not any of the L1.x substates) to the "aspm_disable" mask:

  --- Before fb097dcd5a28
  +++ After fb097dcd5a28

  # r8169 disables L1:
    pci_disable_link_state(PCIE_LINK_STATE_L1)
  -   disable |= ASPM_L1 | ASPM_L1_1 | ASPM_L1_2 | ...  # disable L1, L1.x
  +   disable |= ASPM_L1                                # disable L1 only

  # write "1" to sysfs "aspm_l1_1" attribute:
    l1_1_aspm
      aspm_attr_store_common(state = ASPM_L1_1)
        disable &amp;= ~ASPM_L1_1              # enable L1.1
        if (state &amp; (ASPM_L1_1 | ...))     # if enabling any substate
          disable &amp;= ~ASPM_L1              # enable L1

  # final state:
  - disable = ASPM_L1_2 | ...              # L1, L1.1 enabled; L1.2 disabled
  + disable = 0                            # L1, L1.1, L1.2 all enabled

Enabling an L1.x substate removes the substate and L1 from the
"aspm_disable" mask.  After fb097dcd5a28, the substates were not added to
the mask when disabling L1, so enabling one substate implicitly enables all
of them.

Revert fb097dcd5a28 so enabling one substate doesn't enable the others.

Link: https://lore.kernel.org/r/c75931ac-7208-4200-9ca1-821629cf5e28@gmail.com
Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
[bhelgaas: work through example in commit log]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fbdev: fsl-diu-fb: mark wr_reg_wa() static</title>
<updated>2023-11-20T10:59:38+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2023-11-08T12:58:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=172056918ad888caac780d494f62fedcfe5a668b'/>
<id>urn:sha1:172056918ad888caac780d494f62fedcfe5a668b</id>
<content type='text'>
[ Upstream commit a5035c81847430dfa3482807b07325f29e9e8c09 ]

wr_reg_wa() is not an appropriate name for a global function, and doesn't need
to be global anyway, so mark it static and avoid the warning:

drivers/video/fbdev/fsl-diu-fb.c:493:6: error: no previous prototype for 'wr_reg_wa' [-Werror=missing-prototypes]

Fixes: 0d9dab39fbbe ("powerpc/5121: fsl-diu-fb: fix issue with re-enabling DIU area descriptor")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fbdev: imsttfb: fix a resource leak in probe</title>
<updated>2023-11-20T10:59:38+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2023-10-27T12:05:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b346a531159d08c564a312a9eaeea691704f3c00'/>
<id>urn:sha1:b346a531159d08c564a312a9eaeea691704f3c00</id>
<content type='text'>
[ Upstream commit aba6ab57a910ad4b940c2024d15f2cdbf5b7f76b ]

I've re-written the error handling but the bug is that if init_imstt()
fails we need to call iounmap(par-&gt;cmap_regs).

Fixes: c75f5a550610 ("fbdev: imsttfb: Fix use after free bug in imsttfb_probe")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fbdev: imsttfb: fix double free in probe()</title>
<updated>2023-11-20T10:59:38+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2023-10-27T12:04:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85fd4eb8f6f85c82a0788cd3daa88cef2568c050'/>
<id>urn:sha1:85fd4eb8f6f85c82a0788cd3daa88cef2568c050</id>
<content type='text'>
[ Upstream commit e08c30efda21ef4c0ec084a3a9581c220b442ba9 ]

The init_imstt() function calls framebuffer_release() on error and then
the probe() function calls it again.  It should only be done in probe.

Fixes: 518ecb6a209f ("fbdev: imsttfb: Fix error path of imsttfb_probe()")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64/arm: arm_pmuv3: perf: Don't truncate 64-bit registers</title>
<updated>2023-11-20T10:59:38+00:00</updated>
<author>
<name>Ilkka Koskinen</name>
<email>ilkka@os.amperecomputing.com</email>
</author>
<published>2023-11-02T18:30:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=afadf1fad63bfd2880c4c148816af701a76b5596'/>
<id>urn:sha1:afadf1fad63bfd2880c4c148816af701a76b5596</id>
<content type='text'>
[ Upstream commit 403edfa436286b21f5ffe6856ae5b36396e8966c ]

The driver used to truncate several 64-bit registers such as PMCEID[n]
registers used to describe whether architectural and microarchitectural
events in range 0x4000-0x401f exist. Due to discarding the bits, the
driver made the events invisible, even if they existed.

Moreover, PMCCFILTR and PMCR registers have additional bits in the upper
32 bits. This patch makes them available although they aren't currently
used. Finally, functions handling PMXEVCNTR and PMXEVTYPER registers are
removed as they not being used at all.

Fixes: df29ddf4f04b ("arm64: perf: Abstract system register accesses away")
Reported-by: Carl Worth &lt;carl@os.amperecomputing.com&gt;
Signed-off-by: Ilkka Koskinen &lt;ilkka@os.amperecomputing.com&gt;
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Closes: https://lore.kernel.org/..
Reviewed-by: Anshuman Khandual &lt;anshuman.khandual@arm.com&gt;
Link: https://lore.kernel.org/r/20231102183012.1251410-1-ilkka@os.amperecomputing.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>spi: spi-zynq-qspi: add spi-mem to driver kconfig dependencies</title>
<updated>2023-11-20T10:59:38+00:00</updated>
<author>
<name>Amit Kumar Mahapatra</name>
<email>amit.kumar-mahapatra@amd.com</email>
</author>
<published>2023-11-03T18:43:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6abd5a8b2d5cf85007f81334288d91069a9dcdf'/>
<id>urn:sha1:a6abd5a8b2d5cf85007f81334288d91069a9dcdf</id>
<content type='text'>
[ Upstream commit c2ded280a4b1b7bd93e53670528504be08d24967 ]

Zynq QSPI driver has been converted to use spi-mem framework so
add spi-mem to driver kconfig dependencies.

Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller")
Signed-off-by: Amit Kumar Mahapatra &lt;amit.kumar-mahapatra@amd.com&gt;
Signed-off-by: Radhey Shyam Pandey &lt;radhey.shyam.pandey@amd.com&gt;
Link: https://lore.kernel.org/r/1699037031-702858-1-git-send-email-radhey.shyam.pandey@amd.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE</title>
<updated>2023-11-20T10:59:37+00:00</updated>
<author>
<name>Erik Kurzinger</name>
<email>ekurzinger@nvidia.com</email>
</author>
<published>2023-08-16T16:26:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2341c64551d17bb3b841e42362251f996c7329db'/>
<id>urn:sha1:2341c64551d17bb3b841e42362251f996c7329db</id>
<content type='text'>
[ Upstream commit 101c9f637efa1655f55876644d4439e552267527 ]

If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been
submitted for the given timeline point the call will fail immediately
with EINVAL. This does not match the intended behavior where the call
should wait until the fence has been submitted (or the timeout expires).

The following small example program illustrates the issue. It should
wait for 5 seconds and then print ETIME, but instead it terminates right
away after printing EINVAL.

  #include &lt;stdio.h&gt;
  #include &lt;fcntl.h&gt;
  #include &lt;time.h&gt;
  #include &lt;errno.h&gt;
  #include &lt;xf86drm.h&gt;
  int main(void)
  {
      int fd = open("/dev/dri/card0", O_RDWR);
      uint32_t syncobj;
      drmSyncobjCreate(fd, 0, &amp;syncobj);
      struct timespec ts;
      clock_gettime(CLOCK_MONOTONIC, &amp;ts);
      uint64_t point = 1;
      if (drmSyncobjTimelineWait(fd, &amp;syncobj, &amp;point, 1,
                                 ts.tv_sec * 1000000000 + ts.tv_nsec + 5000000000, // 5s
                                 DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE, NULL)) {
          printf("drmSyncobjTimelineWait failed %d\n", errno);
      }
  }

Fixes: 01d6c3578379 ("drm/syncobj: add support for timeline point wait v8")
Signed-off-by: Erik Kurzinger &lt;ekurzinger@nvidia.com&gt;
Reviewed by: Simon Ser &lt;contact@emersion.fd&gt;
Signed-off-by: Simon Ser &lt;contact@emersion.fr&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1fac96f1-2f3f-f9f9-4eb0-340f27a8f6c0@nvidia.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/vc4: tests: Fix UAF in the mock helpers</title>
<updated>2023-11-20T10:59:37+00:00</updated>
<author>
<name>Maxime Ripard</name>
<email>mripard@kernel.org</email>
</author>
<published>2023-10-24T10:56:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e733f3e9dc7c5b4210a0cc5bfb3347f6ca9fa747'/>
<id>urn:sha1:e733f3e9dc7c5b4210a0cc5bfb3347f6ca9fa747</id>
<content type='text'>
[ Upstream commit cdcd6aef9db5797995d4153ea19fdf56d189f0e4 ]

The VC4 mock helpers allocate the CRTC, encoders and connectors using a
call to kunit_kzalloc(), but the DRM device they are attache to survives
for longer than the test itself which leads to use-after-frees reported
by KASAN.

Switch to drmm_kzalloc to tie the lifetime of these objects to the main
DRM device.

Fixes: f759f5b53f1c ("drm/vc4: tests: Introduce a mocking infrastructure")
Reported-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Closes: https://lore.kernel.org/all/CA+G9fYvJA2HGqzR9LGgq63v0SKaUejHAE6f7+z9cwWN-ourJ_g@mail.gmail.com/
Tested-by: Anders Roxell &lt;anders.roxell@linaro.org&gt;
Reviewed-by: Maíra Canal &lt;mcanal@igalia.com&gt;
Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20231024105640.352752-1-mripard@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drivers: perf: Do not broadcast to other cpus when starting a counter</title>
<updated>2023-11-20T10:59:37+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2023-10-26T08:40:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85be1a73fd298ed3fd060dfce97caef5f9928c57'/>
<id>urn:sha1:85be1a73fd298ed3fd060dfce97caef5f9928c57</id>
<content type='text'>
[ Upstream commit 61e3d993c8bd3e80f8f1363ed5e04f88ab531b72 ]

This command:

$ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000

gives rise to this kernel warning:

[  444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436
[  444.364515] Modules linked in:
[  444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty #73
[  444.364771] Hardware name: riscv-virtio,qemu (DT)
[  444.364868] epc : smp_call_function_many_cond+0x42c/0x436
[  444.364917]  ra : on_each_cpu_cond_mask+0x20/0x32
[  444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800
[  444.364966]  gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0
[  444.364982]  t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0
[  444.364998]  s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000
[  444.365013]  a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100
[  444.365029]  a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000
[  444.365044]  s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98
[  444.365060]  s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000
[  444.365075]  s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001
[  444.365090]  s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6
[  444.365104]  t5 : 0000000400000000 t6 : ff60000002e010d0
[  444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
[  444.365226] [&lt;ffffffff8009f9e0&gt;] smp_call_function_many_cond+0x42c/0x436
[  444.365295] [&lt;ffffffff8009fa5a&gt;] on_each_cpu_cond_mask+0x20/0x32
[  444.365311] [&lt;ffffffff806e90dc&gt;] pmu_sbi_ctr_start+0x7a/0xaa
[  444.365327] [&lt;ffffffff806e880c&gt;] riscv_pmu_start+0x48/0x66
[  444.365339] [&lt;ffffffff8012111a&gt;] perf_adjust_freq_unthr_context+0x196/0x1ac
[  444.365356] [&lt;ffffffff801237aa&gt;] perf_event_task_tick+0x78/0x8c
[  444.365368] [&lt;ffffffff8003faf4&gt;] scheduler_tick+0xe6/0x25e
[  444.365383] [&lt;ffffffff8008a042&gt;] update_process_times+0x80/0x96
[  444.365398] [&lt;ffffffff800991ec&gt;] tick_sched_handle+0x26/0x52
[  444.365410] [&lt;ffffffff800993e4&gt;] tick_sched_timer+0x50/0x98
[  444.365422] [&lt;ffffffff8008a6aa&gt;] __hrtimer_run_queues+0x126/0x18a
[  444.365433] [&lt;ffffffff8008b350&gt;] hrtimer_interrupt+0xce/0x1da
[  444.365444] [&lt;ffffffff806cdc60&gt;] riscv_timer_interrupt+0x30/0x3a
[  444.365457] [&lt;ffffffff8006afa6&gt;] handle_percpu_devid_irq+0x80/0x114
[  444.365470] [&lt;ffffffff80065b82&gt;] generic_handle_domain_irq+0x1c/0x2a
[  444.365483] [&lt;ffffffff8045faec&gt;] riscv_intc_irq+0x2e/0x46
[  444.365497] [&lt;ffffffff808a9c62&gt;] handle_riscv_irq+0x4a/0x74
[  444.365521] [&lt;ffffffff808aa760&gt;] do_irq+0x7c/0x7e
[  444.365796] ---[ end trace 0000000000000000 ]---

That's because the fix in commit 3fec323339a4 ("drivers: perf: Fix panic
in riscv SBI mmap support") was wrong since there is no need to broadcast
to other cpus when starting a counter, that's only needed in mmap when
the counters could have already been started on other cpus, so simply
remove this broadcast.

Fixes: 3fec323339a4 ("drivers: perf: Fix panic in riscv SBI mmap support")
Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Tested-by: Clément Léger &lt;cleger@rivosinc.com&gt;
Tested-by: Yu Chien Peter Lin &lt;peterlin@andestech.com&gt;
Tested-by: Lad Prabhakar &lt;prabhakar.mahadev-lad.rj@bp.renesas.com&gt; #On
Link: https://lore.kernel.org/r/20231026084010.11888-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
