linux-kernel - Re: [PATCH 08/11] drm: nouveau: remove dead code and pointless local lut storage

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 for Android: free password hash cracker in your pocket

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

Message-ID: <abeaa572-c129-f942-1aa4-ec028da846be@axentia.se>
Date:   Wed, 21 Jun 2017 12:35:02 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     linux-kernel@...r.kernel.org
Cc:     Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>,
        David Airlie <airlied@...ux.ie>,
        Dave Airlie <airlied@...hat.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Daniel Vetter <daniel.vetter@...el.com>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Sean Paul <seanpaul@...omium.org>,
        Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
        Ben Skeggs <bskeggs@...hat.com>,
        Yannick Fertre <yannick.fertre@...com>,
        Philippe Cornu <philippe.cornu@...com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Vincent Abriou <vincent.abriou@...com>,
        amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        virtualization@...ts.linux-foundation.org,
        intel-gfx@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
        Boris Brezillon <boris.brezillon@...e-electrons.com>
Subject: Re: [PATCH 08/11] drm: nouveau: remove dead code and pointless local
 lut storage

On 2017-06-20 21:25, Peter Rosin wrote:
> The redundant fb helpers .load_lut, .gamma_set and .gamma_get are
> no longer used. Remove the dead code and hook up the crtc .gamma_set
> to use the crtc gamma_store directly instead of duplicating that
> info locally.

[...]

> -	for (i = 0; i < 256; i++) {
> -		u16 r = nv_crtc->lut.r[i] >> 2;
> -		u16 g = nv_crtc->lut.g[i] >> 2;
> -		u16 b = nv_crtc->lut.b[i] >> 2;
> +	r = crtc->gamma_store;
> +	g = r + crtc->gamma_size;
> +	b = g + crtc->gamma_size;
>  
> +	for (i = 0; i < 256; i++) {
>  		if (disp->disp->oclass < GF110_DISP) {
> -			writew(r + 0x0000, lut + (i * 0x08) + 0);
> -			writew(g + 0x0000, lut + (i * 0x08) + 2);
> -			writew(b + 0x0000, lut + (i * 0x08) + 4);
> +			writew((*r++ >> 2) + 0x0000, lut + (i * 0x08) + 0);
> +			writew((*g++ >> 2) + 0x0000, lut + (i * 0x08) + 2);
> +			writew((*b++ >> 2) + 0x0000, lut + (i * 0x08) + 4);
>  		} else {
> -			writew(r + 0x6000, lut + (i * 0x20) + 0);
> -			writew(g + 0x6000, lut + (i * 0x20) + 2);
> -			writew(b + 0x6000, lut + (i * 0x20) + 4);
> +			writew((*r++ >> 2) + 0x6000, lut + (i * 0x20) + 0);
> +			writew((*g++ >> 2) + 0x6000, lut + (i * 0x20) + 2);
> +			writew((*b++ >> 2) + 0x6000, lut + (i * 0x20) + 4);
>  		}
>  	}
>  }

I forgot to mention this, but the above is very strange for
disp->disp->oclass >= GF110_DISP because 0x6000 interferes with
the 14 bits that appear to be the lut depth in the registers.

I suspect some other bit-shift should be used for that case?

Someone should probably consult a datasheet...

Cheers,
peda