<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v6.6.6</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.6.6</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.6.6'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-12-11T09:40:17Z</updated>
<entry>
<title>Linux 6.6.6</title>
<updated>2023-12-11T09:40:17Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-12-11T09:40:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0c38b88c33239b236930264a5467dca6334792f3'/>
<id>urn:sha1:0c38b88c33239b236930264a5467dca6334792f3</id>
<content type='text'>
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "wifi: cfg80211: fix CQM for non-range use"</title>
<updated>2023-12-11T09:40:17Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-12-11T09:16:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9099d0682462e8664c8cbbe8989de65e50f62b17'/>
<id>urn:sha1:9099d0682462e8664c8cbbe8989de65e50f62b17</id>
<content type='text'>
This reverts commit 4a7e92551618f3737b305f62451353ee05662f57 which is
commit 7e7efdda6adb385fbdfd6f819d76bc68c923c394 upstream.

It needed to have commit 076fc8775daf ("wifi: cfg80211: remove wdev
mutex") applied to properly work, otherwise regressions happen.

Link: https://lore.kernel.org/r/e374bb16-5b13-44cc-b11a-2f4eefb1ecf5@manjaro.org
Link: https://lore.kernel.org/r/87sf4belmm.fsf@turtle.gmx.de
Link: https://lore.kernel.org/r/20231210213930.61378-1-leo@leolam.fr
Reported-by: Léo Lam &lt;leo@leolam.fr&gt;
Reported-by: Sven Joachim &lt;svenjoac@gmx.de&gt;
Reported-by: Philip Müller &lt;philm@manjaro.org&gt;
Cc: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Linux 6.6.5</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-12-08T07:52:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3318612b308bd4fa8647f9f80becd8ff1e2ef208'/>
<id>urn:sha1:3318612b308bd4fa8647f9f80becd8ff1e2ef208</id>
<content type='text'>
Link: https://lore.kernel.org/r/20231205031535.163661217@linuxfoundation.org
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Takeshi Ogasawara &lt;takeshi.ogasawara@futuring-girl.com&gt;
Tested-by: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Tested-by: Harshit Mogalapalli &lt;harshit.m.mogalapalli@oracle.com&gt;
Tested-by: Ronald Warsow &lt;rwarsow@gmx.de&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: SeongJae Park &lt;sj@kernel.org&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Ricardo B. Marliere &lt;ricardo@marliere.net&gt;
Tested-by: Justin M. Forbes &lt;jforbes@fedoraproject.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>vfio: Drop vfio_file_iommu_group() stub to fudge around a KVM wart</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Sean Christopherson</name>
<email>seanjc@google.com</email>
</author>
<published>2023-11-30T00:10:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fcda4d22f5df70fac308d7654bcbeb6fea2d2a47'/>
<id>urn:sha1:fcda4d22f5df70fac308d7654bcbeb6fea2d2a47</id>
<content type='text'>
[ Upstream commit 4ea95c04fa6b9043a1a301240996aeebe3cb28ec ]

Drop the vfio_file_iommu_group() stub and instead unconditionally declare
the function to fudge around a KVM wart where KVM tries to do symbol_get()
on vfio_file_iommu_group() (and other VFIO symbols) even if CONFIG_VFIO=n.

Ensuring the symbol is always declared fixes a PPC build error when
modules are also disabled, in which case symbol_get() simply points at the
address of the symbol (with some attributes shenanigans).  Because KVM
does symbol_get() instead of directly depending on VFIO, the lack of a
fully defined symbol is not problematic (ugly, but "fine").

   arch/powerpc/kvm/../../../virt/kvm/vfio.c:89:7:
   error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
           fn = symbol_get(vfio_file_iommu_group);
                ^
   include/linux/module.h:805:60: note: expanded from macro 'symbol_get'
   #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak,visibility("hidden"))); &amp;(x); })
                                                              ^
   include/linux/vfio.h:294:35: note: previous definition is here
   static inline struct iommu_group *vfio_file_iommu_group(struct file *file)
                                     ^
   arch/powerpc/kvm/../../../virt/kvm/vfio.c:89:7:
   error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
           fn = symbol_get(vfio_file_iommu_group);
                ^
   include/linux/module.h:805:65: note: expanded from macro 'symbol_get'
   #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak,visibility("hidden"))); &amp;(x); })
                                                                   ^
   include/linux/vfio.h:294:35: note: previous definition is here
   static inline struct iommu_group *vfio_file_iommu_group(struct file *file)
                                     ^
   2 errors generated.

Although KVM is firmly in the wrong (there is zero reason for KVM to build
virt/kvm/vfio.c when VFIO is disabled), fudge around the error in VFIO as
the stub is unnecessary and doesn't serve its intended purpose (KVM is the
only external user of vfio_file_iommu_group()), and there is an in-flight
series to clean up the entire KVM&lt;-&gt;VFIO interaction, i.e. fixing this in
KVM would result in more churn in the long run, and the stub needs to go
away regardless.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202308251949.5IiaV0sz-lkp@intel.com
Closes: https://lore.kernel.org/oe-kbuild-all/202309030741.82aLACDG-lkp@intel.com
Closes: https://lore.kernel.org/oe-kbuild-all/202309110914.QLH0LU6L-lkp@intel.com
Link: https://lore.kernel.org/all/0-v1-08396538817d+13c5-vfio_kvm_kconfig_jgg@nvidia.com
Link: https://lore.kernel.org/all/20230916003118.2540661-1-seanjc@google.com
Cc: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Cc: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Tested-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Fixes: c1cce6d079b8 ("vfio: Compile vfio_group infrastructure optionally")
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Link: https://lore.kernel.org/r/20231130001000.543240-1-seanjc@google.com
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/xen: fix percpu vcpu_info allocation</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2023-11-24T07:48:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=602aa0efcf0dba24ef7bd78be9262285b33b4614'/>
<id>urn:sha1:602aa0efcf0dba24ef7bd78be9262285b33b4614</id>
<content type='text'>
[ Upstream commit db2832309a82b9acc4b8cc33a1831d36507ec13e ]

Today the percpu struct vcpu_info is allocated via DEFINE_PER_CPU(),
meaning that it could cross a page boundary. In this case registering
it with the hypervisor will fail, resulting in a panic().

This can easily be fixed by using DEFINE_PER_CPU_ALIGNED() instead,
as struct vcpu_info is guaranteed to have a size of 64 bytes, matching
the cache line size of x86 64-bit processors (Xen doesn't support
32-bit processors).

Fixes: 5ead97c84fa7 ("xen: Core Xen implementation")
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.con&gt;
Link: https://lore.kernel.org/r/20231124074852.25161-1-jgross@suse.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vfio/pds: Fix possible sleep while in atomic context</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Brett Creeley</name>
<email>brett.creeley@amd.com</email>
</author>
<published>2023-11-22T19:25:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=72654bc1d404e05ab7e7c26cfbc966f5cd63288b'/>
<id>urn:sha1:72654bc1d404e05ab7e7c26cfbc966f5cd63288b</id>
<content type='text'>
[ Upstream commit ae2667cd8a479bb5abd6e24c12fcc9ef5bc06d75 ]

The driver could possibly sleep while in atomic context resulting
in the following call trace while CONFIG_DEBUG_ATOMIC_SLEEP=y is
set:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2817, name: bash
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x36/0x50
 __might_resched+0x123/0x170
 mutex_lock+0x1e/0x50
 pds_vfio_put_lm_file+0x1e/0xa0 [pds_vfio_pci]
 pds_vfio_put_save_file+0x19/0x30 [pds_vfio_pci]
 pds_vfio_state_mutex_unlock+0x2e/0x80 [pds_vfio_pci]
 pci_reset_function+0x4b/0x70
 reset_store+0x5b/0xa0
 kernfs_fop_write_iter+0x137/0x1d0
 vfs_write+0x2de/0x410
 ksys_write+0x5d/0xd0
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

This can happen if pds_vfio_put_restore_file() and/or
pds_vfio_put_save_file() grab the mutex_lock(&amp;lm_file-&gt;lock)
while the spin_lock(&amp;pds_vfio-&gt;reset_lock) is held, which can
happen during while calling pds_vfio_state_mutex_unlock().

Fix this by changing the reset_lock to reset_mutex so there are no such
conerns. Also, make sure to destroy the reset_mutex in the driver specific
VFIO device release function.

This also fixes a spinlock bad magic BUG that was caused
by not calling spinlock_init() on the reset_lock. Since, the lock is
being changed to a mutex, make sure to call mutex_init() on it.

Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Closes: https://lore.kernel.org/kvm/1f9bc27b-3de9-4891-9687-ba2820c1b390@moroto.mountain/
Fixes: bb500dbe2ac6 ("vfio/pds: Add VFIO live migration support")
Signed-off-by: Brett Creeley &lt;brett.creeley@amd.com&gt;
Reviewed-by: Shannon Nelson &lt;shannon.nelson@amd.com&gt;
Link: https://lore.kernel.org/r/20231122192532.25791-3-brett.creeley@amd.com
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vfio/pds: Fix mutex lock-&gt;magic != lock warning</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Brett Creeley</name>
<email>brett.creeley@amd.com</email>
</author>
<published>2023-11-22T19:25:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e9e45c19624eb8eb0d91cee487f7c8c5bf7a471a'/>
<id>urn:sha1:e9e45c19624eb8eb0d91cee487f7c8c5bf7a471a</id>
<content type='text'>
[ Upstream commit 91aeb563bd4332e2988f8c0f64f125c4ecb5bcb3 ]

The following BUG was found when running on a kernel with
CONFIG_DEBUG_MUTEXES=y set:

DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
RIP: 0010:mutex_trylock+0x10d/0x120
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x85/0x140
 ? mutex_trylock+0x10d/0x120
 ? report_bug+0xfc/0x1e0
 ? handle_bug+0x3f/0x70
 ? exc_invalid_op+0x17/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? mutex_trylock+0x10d/0x120
 ? mutex_trylock+0x10d/0x120
 pds_vfio_reset+0x3a/0x60 [pds_vfio_pci]
 pci_reset_function+0x4b/0x70
 reset_store+0x5b/0xa0
 kernfs_fop_write_iter+0x137/0x1d0
 vfs_write+0x2de/0x410
 ksys_write+0x5d/0xd0
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

As shown, lock-&gt;magic != lock. This is because
mutex_init(&amp;pds_vfio-&gt;state_mutex) is called in the VFIO open path. So,
if a reset is initiated before the VFIO device is opened the mutex will
have never been initialized. Fix this by calling
mutex_init(&amp;pds_vfio-&gt;state_mutex) in the VFIO init path.

Also, don't destroy the mutex on close because the device may
be re-opened, which would cause mutex to be uninitialized. Fix this by
implementing a driver specific vfio_device_ops.release callback that
destroys the mutex before calling vfio_pci_core_release_dev().

Fixes: bb500dbe2ac6 ("vfio/pds: Add VFIO live migration support")
Signed-off-by: Brett Creeley &lt;brett.creeley@amd.com&gt;
Reviewed-by: Shannon Nelson &lt;shannon.nelson@amd.com&gt;
Link: https://lore.kernel.org/r/20231122192532.25791-2-brett.creeley@amd.com
Signed-off-by: Alex Williamson &lt;alex.williamson@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix MPCC 1DLUT programming</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Ilya Bakoulin</name>
<email>ilya.bakoulin@amd.com</email>
</author>
<published>2023-11-07T20:07:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=117917b0be2e9bc893859a70cfff17e48020ada8'/>
<id>urn:sha1:117917b0be2e9bc893859a70cfff17e48020ada8</id>
<content type='text'>
[ Upstream commit 6f395cebdd8927fbffdc3a55a14fcacf93634359 ]

[Why]
Wrong function is used to translate LUT values to HW format, leading to
visible artifacting in some cases.

[How]
Use the correct cm3_helper function.

Cc: stable@vger.kernel.org # 6.1+
Reviewed-by: Krunoslav Kovac &lt;krunoslav.kovac@amd.com&gt;
Acked-by: Hamza Mahfooz &lt;hamza.mahfooz@amd.com&gt;
Signed-off-by: Ilya Bakoulin &lt;ilya.bakoulin@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Simplify brightness initialization</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Camille Cho</name>
<email>camille.cho@amd.com</email>
</author>
<published>2023-11-03T04:08:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d05614ebad8c2eff20f40ca1f55e36a76d4b0dd8'/>
<id>urn:sha1:d05614ebad8c2eff20f40ca1f55e36a76d4b0dd8</id>
<content type='text'>
[ Upstream commit d9e865826c202b262f9ee3f17a03cc4ac5d44ced ]

[Why]
Remove the brightness cache in DC. It uses a single value to represent
the brightness for both SDR and HDR mode. This leads to flash in HDR
on/off. It also unconditionally programs brightness as in HDR mode. This
may introduce garbage on SDR mode in miniLED panel.

[How]
Simplify the initialization flow by removing the DC cache and taking
what panel has as default. Expand the mechanism for PWM to DPCD Aux to
restore cached brightness value generally.

Cc: stable@vger.kernel.org # 6.1+
Reviewed-by: Krunoslav Kovac &lt;krunoslav.kovac@amd.com&gt;
Acked-by: Hamza Mahfooz &lt;hamza.mahfooz@amd.com&gt;
Signed-off-by: Camille Cho &lt;camille.cho@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Reduce default backlight min from 5 nits to 1 nits</title>
<updated>2023-12-08T07:52:25Z</updated>
<author>
<name>Swapnil Patel</name>
<email>swapnil.patel@amd.com</email>
</author>
<published>2023-10-04T19:58:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=86cd446a7727f92db999b55c66e9a59cf7a0545a'/>
<id>urn:sha1:86cd446a7727f92db999b55c66e9a59cf7a0545a</id>
<content type='text'>
[ Upstream commit 5edb7cdff85af8f8c5fda5b88310535ab823f663 ]

[Why &amp; How]
Currently set_default_brightness_aux function uses 5 nits as lower limit
to check for valid default_backlight setting. However some newer panels
can support even lower default settings

Reviewed-by: Agustin Gutierrez &lt;agustin.gutierrez@amd.com&gt;
Acked-by: Roman Li &lt;roman.li@amd.com&gt;
Signed-off-by: Swapnil Patel &lt;swapnil.patel@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Stable-dep-of: d9e865826c20 ("drm/amd/display: Simplify brightness initialization")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
