linux-kernel - Re: [PATCH] reset: Add driver for dispmix reset

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: <1561619128.4216.3.camel@pengutronix.de>
Date:   Thu, 27 Jun 2019 09:05:28 +0200
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Fancy Fang <chen.fang@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>
Cc:     "festevam@...il.com" <festevam@...il.com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH] reset: Add driver for dispmix reset

On Wed, 2019-06-26 at 06:46 +0000, Fancy Fang wrote:
[...]
> > The same goes for the clock soft enable bits on i.MX8MM. If those 
> > bits actually control clock gates, they should not be described as 
> > reset controls in the device tree.
>
> [FF] Make sense. The functions provided by the "dispmix reset" is more
> likely to be a combination of a clock gating module and a reset
> control than a standard reset controller. The reason why I choose
> reset framework to implement this device is that: First, this module
> is named as "dispmix reset" in the dispmix's design spec, so it gives
> me the first impression that it should be acted as a reset controller.
> And I'll check this with the IC designer.

Thank you.

> Second, the "dispmix reset" is separated from the CCM LPCG module
> which is used as the only clock controller device for the whole
> platform. So the CCM clock driver seems cannot cover this device.
> Last, the "dispmix reset" is shared by all the submodules in the
> dispmix, so I abstract this device to be a reset controller driver to
> simplify the 'reset' logic for all the submodules drivers.

Agreed on both points.

> If using clock framework to cover this device, another driver needs to
> be implemented. I'll take a close look at it to see if this can
> happen.

Yes, if my assumptions are correct, it would be good if this could be
rewritten as a combined clock and reset driver. There are quite a few
examples for this in drivers/clk already.

[...]
> > Is there any reason not to just use straight readl/writel besides 
> > the automatic clock handling?
>
> [FF] Use regmap is for simplifying the register modifications since
> the register has no SET or CLR shadow, so when set or clear one bit,
> the register needs to be read-and-modify. And besides, the register
> access requires disp-apb clock open, and regmap can handle this
> properly.

Ok, this makes sense to me.

regards
Philipp