linux-kernel - Re: [PATCH 1/2] reset: add reset-simple to unify socfpga, stm32, and sunxi

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: <1488975630.2467.20.camel@pengutronix.de>
Date:   Wed, 08 Mar 2017 13:20:30 +0100
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Alexandre Torgue <alexandre.torgue@...com>
Cc:     Andre Przywara <andre.przywara@....com>,
        linux-kernel@...r.kernel.org,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Chen-Yu Tsai <wens@...e.org>
Subject: Re: [PATCH 1/2] reset: add reset-simple to unify socfpga, stm32,
 and sunxi

On Wed, 2017-03-08 at 12:05 +0100, Alexandre Torgue wrote:
> Hi Philipp,
> 
> On 03/08/2017 11:19 AM, Andre Przywara wrote:
> > Hi,
> >
> > On 08/03/17 09:54, Philipp Zabel wrote:
> >> Reset operations for simple reset controllers with reset lines that can
> >> be controlled by toggling bits in (mostly) contiguous register ranges
> >> using read-modify-write cycles under a spinlock. So far this covers the
> >> socfpga, stm32, and sunxi drivers.
> >
> > Wow, that looks nice, thanks for that.
> >
> > But can't we go one step further and unify those driver into one file then?
> > And either have different probe functions to cover the different DT
> > requirements or to just have one unified probe checking for the super
> > set of all properties?
> 
> I agree with Andre. It looks nice and it should be a good thing to have 
> a common probe inside reset-simple.c
> Maybe only "nresets" and "inverted"  DT properties are needed.

Adding DT properties is not an option, as the driver would have to work
with the existing bindings. We could merge them into one file, with a
single probe function that configures different parameters depending on
the of_device_id returned by of_match_device.

regards
Philipp