linux-kernel - Re: [PATCH v3 5/6] drm: atmel-hlcdc: prefer a lower pixel-clock than requested

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]

Message-ID: <20200106190234.GA15881@ravnborg.org>
Date:   Mon, 6 Jan 2020 20:02:34 +0100
From:   Sam Ravnborg <sam@...nborg.org>
To:     Claudiu.Beznea@...rochip.com
Cc:     alexandre.belloni@...tlin.com, airlied@...ux.ie,
        Nicolas.Ferre@...rochip.com, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, boris.brezillon@...tlin.com,
        lee.jones@...aro.org, peda@...ntia.se,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 5/6] drm: atmel-hlcdc: prefer a lower pixel-clock than
 requested

Hi Claudiu.
On Mon, Jan 06, 2020 at 09:25:40AM +0000, Claudiu.Beznea@...rochip.com wrote:
> 
> 
> On 04.01.2020 19:12, Sam Ravnborg wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > 
> > Hi Claudiu
> > 
> > On Thu, Jan 02, 2020 at 10:08:48AM +0100, Sam Ravnborg wrote:
> >> On Wed, Dec 18, 2019 at 02:28:28PM +0200, Claudiu Beznea wrote:
> >>> From: Peter Rosin <peda@...ntia.se>
> >>>
> >>> The intention was to only select a higher pixel-clock rate than the
> >>> requested, if a slight overclocking would result in a rate significantly
> >>> closer to the requested rate than if the conservative lower pixel-clock
> >>> rate is selected. The fixed patch has the logic the other way around and
> >>> actually prefers the higher frequency. Fix that.
> >>>
> >>> Fixes: f6f7ad323461 ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
> >> The id is wrong here - the right one is: 9946a3a9dbedaaacef8b7e94f6ac144f1daaf1de
> >> The wrong id above was used before - so I think it is a copy'n'paste
> >> thing.
> >>
> >> Hint: try "dim fixes 9946a3a9dbedaaacef8b7e94f6ac144f1daaf1de"
> >>
> >> If I get a quick response from Lee I can fix it up while applying.
> >>
> >>       Sam
> >>
> >>> Reported-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
> >>> Tested-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
> >>> Signed-off-by: Peter Rosin <peda@...ntia.se>
> > 
> > One other detail.
> > The patch has passed through your hands, so you have to add your s-o-b
> > to document this.
> > The chain of s-o-b shall document the path the patch has taken towards
> > the kernel.
> > 
> > In this case:
> > Peter => Claudiu => Sam => Applied.
> > 
> > Please resend or reply where you say OK that I add your s-o-b.
> 
> Sure! Please add my Signed-off-by: Claudiu Beznea <claudiu.beznea@...rochip.com>

Thanks - all four DRM patches pushed to drm-misc-next.
I used "dim fixes" so we could Cc relevant stable versions.

	Sam