linux-kernel - Re: [PATCH V2] drm/mgag200: Fix big-endian support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20251208.133950.469837482614896193.rene@exactco.de>
Date: Mon, 08 Dec 2025 13:39:50 +0100 (CET)
From: René Rebe <rene@...ctco.de>
To: tzimmermann@...e.de
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 airlied@...hat.com
Subject: Re: [PATCH V2] drm/mgag200: Fix big-endian support

Moin Thomas,

On Mon, 8 Dec 2025 09:29:53 +0100, Thomas Zimmermann <tzimmermann@...e.de> wrote:

> Hi,
> 
> thanks for the update.

of course!

> Am 05.12.25 um 18:24 schrieb René Rebe:
> > Unlike the original, deleted Matrox mga driver, the new mgag200 driver
> > has the XRGB frame-buffer byte swapped on big-endian "RISC"
> > systems. Fix by enabling byte swapping "PowerPC" OPMODE for any
> > __BIG_ENDIAN config.
> >
> > Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
> > Signed-off-by: René Rebe <rene@...ctco.de>
> > Cc: stable@...nel.org
> > ---
> > V2: move to atomic_update
> > Tested on IBM 43p Model 150 (7043-150) running T2/Linux.
> > ---
> >   drivers/gpu/drm/mgag200/mgag200_mode.c | 14 ++++++++++++++
> >   1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> > b/drivers/gpu/drm/mgag200/mgag200_mode.c
> > index 951d715dea30..d40434ec68ab 100644
> > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> > @@ -496,6 +496,20 @@ void
> > mgag200_primary_plane_helper_atomic_update(struct drm_plane *plane,
> >   	struct drm_atomic_helper_damage_iter iter;
> >   	struct drm_rect damage;
> >   +#ifdef __BIG_ENDIAN
> > +	/* Big-endian byte-swapping */
> > +	switch (fb->format->format) {
> > +	case DRM_FORMAT_RGB565:
> > +		WREG32(MGAREG_OPMODE, 0x10100);
> > +		break;
> > +	case DRM_FORMAT_XRGB8888:
> > +		WREG32(MGAREG_OPMODE, 0x20200);
> > +		break;
> > +	default:
> > +		break;
> 
> No need for a default branch IIRC.

Hm, it was a preventitive measure to avoid compiler warnings, but I'll
check if we don't get one for unhandled format cases, ...

> > +	}
> 
> This is the right place to set up the write mode.
> 
> But looking at the G200 docs, I found that the reset value for OPMODE
> has bit 18 set to 1. These writes clear the value. If that
> intentional?

Well the same doc says: "Reserved <1:0> <7:4> <15:10> <31:18>
Reserved. When writing to this register, the bits in these fields must
be set to ‘0’.  Reading will return ‘0’s"

So I would guess the reset value is a typo. But I'll adjust the code
nontheless.

> For better style and compatibility, I suggest to first read the value
> and keep the reserved bit as-is.
> 
> u32 opmode
> 
> opmode = RREG32(MGAREG_OPMODE)
> opmode &= ~GENMASK(17, 16)
> opmode &= ~GENMASK(9, 8)
> opmode &= ~GENMASK(3, 2)

I'll merge that in one line of GENMASK, hope that's acceptable.

> switch (format) {
>         opmode |= ...;
> }
> 
> WREG32(OPMODE, opmode);
> 
> You can put that in a helper near set_startadd [1]
> 
> void mgag200_set_datasiz(struct mga_device *mdev, u32 format)
> {
> #if __BIG_ENDIAN
> ...
> #endif
> }
> 
> Then call that from atomic_update and it should be fine.

I'll make it a function that if that is what is preferred.

     René

> [1]
> https://elixir.bootlin.com/linux/v6.18/source/drivers/gpu/drm/mgag200/mgag200_mode.c#L117

-- 
René Rebe, ExactCODE GmbH, Berlin, Germany
https://exactco.de • https://t2linux.com • https://patreon.com/renerebe