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: <20200102160534.GJ22390@dell>
Date:   Thu, 2 Jan 2020 16:05:34 +0000
From:   Lee Jones <lee.jones@...aro.org>
To:     Sam Ravnborg <sam@...nborg.org>
Cc:     Claudiu Beznea <claudiu.beznea@...rochip.com>,
        boris.brezillon@...tlin.com, airlied@...ux.ie,
        nicolas.ferre@...rochip.com, alexandre.belloni@...tlin.com,
        peda@...ntia.se, dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/6] fixes for atmel-hlcdc

On Thu, 02 Jan 2020, Sam Ravnborg wrote:

> Hi Lee.
> 
> How do de handle the two mfd related patches?
> 
> > I have few fixes for atmel-hlcdc driver in this series as well
> > as two reverts.
> > Revert "drm: atmel-hlcdc: enable sys_clk during initalization." is
> > due to the fix in in patch 2/5.
> > 
> > Thank you,
> > Claudiu Beznea
> > 
> > Changes in v3:
> > - changes dev_err() message in patch 4/6
> > - collect Acked-by tags
> > 
> > Changes in v2:
> > - introduce patch 3/6
> > - use dev_err() inpatch 4/6
> > - introduce patch 5/6 instead of reverting commit f6f7ad323461
> >   ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
> > 
> > Claudiu Beznea (5):
> >   drm: atmel-hlcdc: use double rate for pixel clock only if supported
> >   drm: atmel-hlcdc: enable clock before configuring timing engine
> 
> >   mfd: atmel-hlcdc: add struct device member to struct
> >     atmel_hlcdc_regmap
> >   mfd: atmel-hlcdc: return in case of error
> 
> Would it be OK to apply the to drm-misc-next, or shal they go in via
> your mfd tree?

How are they related to the other patches?  Do they have build-time
dependencies on any of the other patches, or vice versa? 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ