linux-kernel - Re: [PATCH 2/2] reset: Add basic single-register reset driver

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: <CAHp75VeLmwUwkpJ7C7bzKOq5YzFXabHseqCwM+Wf09s2-=amRA@mail.gmail.com>
Date:   Mon, 29 May 2017 18:41:13 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Joel Stanley <joel@....id.au>
Cc:     Philipp Zabel <p.zabel@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Andrew Jeffery <andrew@...id.au>
Subject: Re: [PATCH 2/2] reset: Add basic single-register reset driver

On Mon, May 29, 2017 at 1:24 PM, Joel Stanley <joel@....id.au> wrote:
> On Sun, May 28, 2017 at 12:41 AM, Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
>> On Fri, May 26, 2017 at 6:32 AM, Joel Stanley <joel@....id.au> wrote:
>>> This driver is a basic single-register reset controller driver that
>>> supports clearing a single bit in a register.
>>>
>>
>> While this makes sense, I'm wondering if there can be generic
>> interface for this from which we can derive this one and GPIO-based
>> one.
>
> Do we have a GPIO based one already? I couldn't find it.

No, we haven't.

> Having a think, it would be a very similar looking driver, but with
> little shared code. The context struct would contain a gpio pointer
> instead of regmap, probe would request a GPIO instead of a regmap and
> the assert/deassert/status callbacks would be gpiod_ calls.
>
> Given this is four of the four functions in this driver, do you think would be
> better off with two small drivers?

Fair enough.
Sounds like independent drivers for now is a good approach, though
it's up to maintainer.

-- 
With Best Regards,
Andy Shevchenko