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: <20170703231553.1be2f4b3@bbrezillon>
Date:   Mon, 3 Jul 2017 23:15:53 +0200
From:   Boris Brezillon <boris.brezillon@...e-electrons.com>
To:     Peter Rosin <peda@...ntia.se>,
        Daniel Vetter <daniel.vetter@...ll.ch>
Cc:     linux-kernel@...r.kernel.org, David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org,
        Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>
Subject: Re: [PATCH] drm: atmel-hlcdc: use a default gamma ramp if none is
 specified

Le Mon, 3 Jul 2017 22:59:36 +0200,
Peter Rosin <peda@...ntia.se> a écrit :

> On 2017-07-03 14:02, Boris Brezillon wrote:
> > On Mon, 3 Jul 2017 13:53:28 +0200
> > Peter Rosin <peda@...ntia.se> wrote:
> >   
> >> On 2017-07-03 13:31, Boris Brezillon wrote:  
> >>> On Mon,  3 Jul 2017 11:42:10 +0200
> >>> Peter Rosin <peda@...ntia.se> wrote:
> >>>     
> >>>> At init and if the gamma_lut property is ever removed, the clut
> >>>> registers must be programmed with a default gamma ramp instead of
> >>>> being left in some unknown state.
> >>>>
> >>>> Fixes: 364a7bf574eb ("drm: atmel-hlcdc: add support for 8-bit color lookup table mode")
> >>>> Signed-off-by: Peter Rosin <peda@...ntia.se>
> >>>> ---
> >>>>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 17 ++++++++++++++++-
> >>>>  1 file changed, 16 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >>>> index b5bd9b0..0ccd93c 100644
> >>>> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >>>> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >>>> @@ -429,6 +429,14 @@ static void atmel_hlcdc_plane_update_format(struct atmel_hlcdc_plane *plane,
> >>>>  				    ATMEL_HLCDC_LAYER_FORMAT_CFG, cfg);
> >>>>  }
> >>>>  
> >>>> +static void atmel_hlcdc_default_gamma_ramp(struct atmel_hlcdc_layer *layer)
> >>>> +{
> >>>> +	int idx;
> >>>> +
> >>>> +	for (idx = 0; idx < ATMEL_HLCDC_CLUT_SIZE; idx++)
> >>>> +		atmel_hlcdc_layer_write_clut(layer, idx, idx * 0x10101);
> >>>> +}
> >>>> +
> >>>>  static void atmel_hlcdc_plane_update_clut(struct atmel_hlcdc_plane *plane)
> >>>>  {
> >>>>  	struct drm_crtc *crtc = plane->base.crtc;
> >>>> @@ -438,9 +446,14 @@ static void atmel_hlcdc_plane_update_clut(struct atmel_hlcdc_plane *plane)
> >>>>  	if (!crtc || !crtc->state)
> >>>>  		return;
> >>>>  
> >>>> -	if (!crtc->state->color_mgmt_changed || !crtc->state->gamma_lut)
> >>>> +	if (!crtc->state->color_mgmt_changed)
> >>>>  		return;
> >>>>  
> >>>> +	if (!crtc->state->gamma_lut) {
> >>>> +		atmel_hlcdc_default_gamma_ramp(&plane->layer);    
> >>>
> >>> Hm, I'd prefer to have state->gamma_lut properly initialized in
> >>> atmel_hlcdc_crtc_reset(), this way you don't have to do that in the
> >>> update path.    
> >>
> >> The gamma_lut property can be removed, so you have to handle it here anyway. No?  
> > 
> > Hm, what do you mean by removed? AFAICT, a property, once attached to
> > a DRM object, exists until the DRM object is destroyed. The data
> > attached to this property (here, the gamma_lut array) can be NULL, but
> > once you have allocated the data container, it will be duplicated (and
> > possibly updated) every time an atomic operation is triggered.  
> 
> By remove I meant someone somehow triggering a call like this:
> 
> 	drm_atomic_crtc_set_property(crtc, ...->gamma_lut_property, 0);
> 
> By the looks of it, that is not happening? But I'm not sure of that, and
> even if it's not happening today, that may change...

Hm, that means someone would deliberately set an empty CLUT and still
request to display something C8 formated? If you want my opinion, we
should return -EINVAL if this happens. Using a default CLUT table to
support C8 early in the boot is one thing, allowing one to explicitly
discard the CLUT and expecting C8 to work properly sounds like a bad to
me.

> 
> > By initializing this field in crtc->reset(), you enforce the
> > default/reset state, which IIUC, is what you want here.  
> 
> Agreed, if it is not possible to remove/clear out the gamma_lut property,
> then the only thing needed is to initialize the hw clut registers to the
> linear ramp somewhere early.

Well, I don't know if we should prevent one from discarding the CLUT,
but we should definitely prevent one from using C8 format when
->gamma_lut is NULL.

> 
> But is it indeed a fact that there is no way to clear out the gamma_lut prop?

You clearly showed it was possible, so I'd say no. Daniel, any opinion
on this specific problem?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ