The is_psr_su parameter is a boolean flag indicating whether the Panel
Self Refresh Selective Update (PSR SU) feature is enabled which is a
power-saving feature that allows only the updated regions of the screen
to be refreshed, reducing the amount of data that needs to be sent to
the display.
Fixes the below with gcc W=1:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5257: warning: Function parameter or member 'is_psr_su' not described in 'fill_dc_dirty_rects'
Fixes: 13d6b0812e58 ("drm/amdgpu: make damage clips support configurable")
Cc: stable(a)vger.kernel.org
Cc: Hamza Mahfooz <hamza.mahfooz(a)amd.com>
Cc: Mario Limonciello <mario.limonciello(a)amd.com>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai(a)amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b9ac3d2f8029..1b51f7fb48ea 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5234,6 +5234,10 @@ static inline void fill_dc_dirty_rect(struct drm_plane *plane,
* @new_plane_state: New state of @plane
* @crtc_state: New state of CRTC connected to the @plane
* @flip_addrs: DC flip tracking struct, which also tracts dirty rects
+ * @is_psr_su: Flag indicating whether Panel Self Refresh Selective Update (PSR SU) is enabled.
+ * If PSR SU is enabled and damage clips are available, only the regions of the screen
+ * that have changed will be updated. If PSR SU is not enabled,
+ * or if damage clips are not available, the entire screen will be updated.
* @dirty_regions_changed: dirty regions changed
*
* For PSR SU, DC informs the DMUB uController of dirty rectangle regions
--
2.34.1
Hi Greg,
I believe these patches are likely already on your radar. I just wanted to
inform you that it would be highly appreciated if we could see their inclusion
in the upcoming release.
e0526ec5360a 2024-01-30hv_netvsc: Fix race condition between
netvsc_probe and netvsc_remove [Jakub Kicinski]
We would like to even get:
9cae43da9867 hv_netvsc: Register VF in netvsc_probe if
NET_DEVICE_REGISTER missed
included, but the patch is still in netdev and has not made it into
Linus's tree. If it does come in,
could you please consider including it too.
Thanks,
- Allen
The current logic is probably fine but is a bit convoluted. Plus, we
don't want partial pages to be part of the sequential operation just in
case the core would optimize the page read with a subpage read (which
would break the sequence). This may happen on the first and last page
only, so if the start offset or the end offset is not aligned with a
page boundary, better avoid them to prevent any risk.
Cc: stable(a)vger.kernel.org
Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads")
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
---
drivers/mtd/nand/raw/nand_base.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 139fdf3e58c0..bbdcfbe643f3 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -3460,21 +3460,29 @@ static void rawnand_enable_cont_reads(struct nand_chip *chip, unsigned int page,
u32 readlen, int col)
{
struct mtd_info *mtd = nand_to_mtd(chip);
+ unsigned int end_page, end_col;
+
+ chip->cont_read.ongoing = false;
if (!chip->controller->supported_op.cont_read)
return;
- if ((col && col + readlen < (3 * mtd->writesize)) ||
- (!col && readlen < (2 * mtd->writesize))) {
- chip->cont_read.ongoing = false;
- return;
- }
+ end_page = DIV_ROUND_UP(col + readlen, mtd->writesize);
+ end_col = (col + readlen) % mtd->writesize;
- chip->cont_read.ongoing = true;
- chip->cont_read.first_page = page;
if (col)
- chip->cont_read.first_page++;
- chip->cont_read.last_page = page + ((readlen >> chip->page_shift) & chip->pagemask);
+ page++;
+
+ if (end_col && end_page)
+ end_page--;
+
+ if (page + 1 > end_page)
+ return;
+
+ chip->cont_read.first_page = page;
+ chip->cont_read.last_page = end_page;
+ chip->cont_read.ongoing = true;
+
rawnand_cap_cont_reads(chip);
}
--
2.34.1
On Wed, Feb 21, 2024 at 1:33 PM Jason A. Donenfeld <Jason(a)zx2c4.com> wrote:
>
> There are few uses of CoCo that don't rely on working cryptography and
> hence a working RNG. Unfortunately, the CoCo threat model means that the
> VM host cannot be trusted and may actively work against guests to
> extract secrets or manipulate computation. Since a malicious host can
> modify or observe nearly all inputs to guests, the only remaining source
> of entropy for CoCo guests is RDRAND.
>
> If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole
> is meant to gracefully continue on gathering entropy from other sources,
> but since there aren't other sources on CoCo, this is catastrophic.
> This is mostly a concern at boot time when initially seeding the RNG, as
> after that the consequences of a broken RDRAND are much more
> theoretical.
>
> So, try at boot to seed the RNG using 256 bits of RDRAND output. If this
> fails, panic(). This will also trigger if the system is booted without
> RDRAND, as RDRAND is essential for a safe CoCo boot.
>
> This patch is deliberately written to be "just a CoCo x86 driver
> feature" and not part of the RNG itself. Many device drivers and
> platforms have some desire to contribute something to the RNG, and
> add_device_randomness() is specifically meant for this purpose. Any
> driver can call this with seed data of any quality, or even garbage
> quality, and it can only possibly make the quality of the RNG better or
> have no effect, but can never make it worse. Rather than trying to
> build something into the core of the RNG, this patch interprets the
> particular CoCo issue as just a CoCo issue, and therefore separates this
> all out into driver (well, arch/platform) code.
>
> Cc: Borislav Petkov <bp(a)alien8.de>
> Cc: Daniel P. Berrangé <berrange(a)redhat.com>
> Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
> Cc: Elena Reshetova <elena.reshetova(a)intel.com>
> Cc: H. Peter Anvin <hpa(a)zytor.com>
> Cc: Ingo Molnar <mingo(a)redhat.com>
> Cc: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
> Cc: Theodore Ts'o <tytso(a)mit.edu>
> Cc: Thomas Gleixner <tglx(a)linutronix.de>
> Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com>
Also,
Cc: stable(a)vger.kernel.org
At least, I think that's probably what we want, though I don't know
what version range is relevant for CoCo.
Syzkaller reports a potential circular dependency leading to deadlock
in 5.10 and 5.15 stable releases since the commit
92d4abd66f70 ("Bluetooth: vhci: Fix race when opening vhci device")
that caused this crash was backported to these branches.
The problem has been fixed by the following upstream patch that was
adapted to 5.10 and 5.15. All of the changes made to the patch
in order to adapt it are described at the end of commit message.
This patch has already been backported to the following stable branches:
v6.6 - https://lore.kernel.org/stable/20231230115814.038261305@linuxfoundation.org/
v6.1 - https://lore.kernel.org/stable/20231230115807.749489379@linuxfoundation.org/
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.