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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 26 Jun 2017 21:13:19 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     linux-kernel@...r.kernel.org, nouveau@...ts.freedesktop.org,
        dri-devel@...ts.freedesktop.org,
        virtualization@...ts.linux-foundation.org,
        amd-gfx@...ts.freedesktop.org,
        Daniel Vetter <daniel.vetter@...el.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Russell King <linux@...linux.org.uk>,
        Ben Skeggs <bskeggs@...hat.com>,
        Dave Airlie <airlied@...hat.com>,
        intel-gfx@...ts.freedesktop.org,
        Vincent Abriou <vincent.abriou@...com>,
        Philippe Cornu <philippe.cornu@...com>,
        Yannick Fertre <yannick.fertre@...com>,
        Alex Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>,
        Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [PATCH v2 00/14] improve the fb_setcmap helper

On 2017-06-26 11:35, Daniel Vetter wrote:
> On Thu, Jun 22, 2017 at 08:06:23AM +0200, Peter Rosin wrote:
>> Hi!
>>
>> While trying to get CLUT support for the atmel_hlcdc driver, and
>> specifically for the emulated fbdev interface, I received some
>> push-back that my feeble in-driver attempts should be solved
>> by the core. This is my attempt to do it right.
>>
>> I have obviously not tested all of this with more than a compile,
>> but patches 1 and 3 are enough to make the atmel-hlcdc driver
>> do what I need (when patched to support CLUT modes). The rest is
>> just lots of removals and cleanup made possible by the improved
>> core.
>>
>> Please test, I would not be surprised if I have fouled up some
>> bit-manipulation somewhere in this mostly mechanical change...
>>
>> Changes since v1:
>>
>> - Rebased to next-20170621
>> - Split 1/11 into a preparatory patch, a cleanup patch and then
>>   the meat in 3/14.
>> - Handle pseudo-palette for FB_VISUAL_TRUECOLOR.
>> - Removed the empty .gamma_get/.gamma_set fb helpers from the
>>   armada driver that I had somehow managed to ignore but which
>>   0day found real quick.
>> - Be less judgemental on drivers only providing .gamma_get and
>>   .gamma_set, but no .load_lut. That's actually a valid thing
>>   to do if you only need pseudo-palette for FB_VISUAL_TRUECOLOR.
>> - Add a comment about colliding bitfields in the nouveau driver.
>> - Remove gamma_set/gamma_get declarations from the radeon driver
>>   (the definitions were removed in v1).
> 
> Ok some nits/questions on the first three, but in principle looks all ok I
> think. The driver patches also look good (but I didn't yet carefully
> review all the conversion). What we might want to do is entirely remove
> driver's reliance on ->gamma_store (mostly amounts to in-lining the
> load_lut functions) and only update ->gamma_store after gamma_set returned
> successfully. But that's a bit more work.
> 
> Save/restoring it instead might be simpler to fix that bug, but since it's
> pre-existing also ok as follow-up.

I'm traveling and cannot make progress this week. The merge window is
also real close so this series will therefore probably miss it unless
something unexpected happens...

I'll get back to this for the next cycle, just a heads up.

Cheers,
peda

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ