linux-kernel - Re: [PATCH 3/5] reset: Add Realtek RTD1295 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1502897593.7596.9.camel@pengutronix.de>
Date:   Wed, 16 Aug 2017 17:33:13 +0200
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Andreas Färber <afaerber@...e.de>,
        linux-arm-kernel@...ts.infradead.org
Cc:     linux-kernel@...r.kernel.org, Roc He <hepeng@...oo.tv>,
        蒋丽琴 <jiang.liqin@...iatech.com>
Subject: Re: [PATCH 3/5] reset: Add Realtek RTD1295 driver

On Wed, 2017-08-16 at 14:09 +0200, Andreas Färber wrote:
> Hi Philipp,
> 
> Am 16.08.2017 um 11:44 schrieb Philipp Zabel:
> > On Wed, 2017-08-16 at 02:38 +0200, Andreas Färber wrote:
> > > Add a per-register reset controller driver. This deals with the
> > > fact
> > > that not all registers are adjoined.
> > 
> > the way you handle the non-contiguous reset registers, this looks
> > like
> > a candidate to join the recently discussed reset-simple driver [1].
> > Could you check if that would fit?
> 
> Thanks, I appreciate the idea, and it looks like you already have the
> active-low logic in place.
> 
> Are you okay with keeping the first three as separate nodes, or would
> you rather want one node to cover the first three registers, plus two
> separate ones for the non-contiguous cases?

I am fine with keeping them separate, if you think this best describes
the hardware.

> Or is the simple driver supposed to cover gaps, too? Then we could go
> with just two nodes. (I found it weird to have reset and then reset4,
> so I went with separate ones as seen downstream.)

I had declared gaps as out of scope of the simple reset controller
driver, but if the implementation could be kept reasonably simple, we
could think about supporting something like this, too:

		reset: reset-controller@...00000 {
			compatible = "realtek,rtd1295-reset";
			reg = <0x98000000 0xc>, <0x98000050 0x4>;
			#reset-cells = <1>;
		};

regards
Philipp