linux-kernel - Re: [Question] reset controlling

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]

Date:	Mon, 18 Apr 2016 17:13:57 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:	linux-clk@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Olof Johansson <olof@...om.net>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Stephen Boyd <sboyd@...eaurora.org>, devicetree@...r.kernel.org
Subject: Re: [Question] reset controlling

On Sunday 17 April 2016 17:16:58 Masahiro Yamada wrote:
> 2016-04-17 4:23 GMT+09:00 Arnd Bergmann <arnd@...db.de>:
> >> Reset signals are sometimes cascaded.
> >> For example, the UART blocks on my SoCs have a reset for the whole of
> >> UART blocks
> >> besides per-channel reset signals.
> >>
> >>                      |---(UART ch0 reset)---> UART0
> >>                      |
> >> ----(UART reset)-----|---(UART ch1 reset)---> UART1
> >>                      |
> >>                      |---(UART ch2 reset)---> UART2
> >>
> >> I found this works well with clk-gate drivers.
> >> Even reset_control_reset() can be implemented
> >> with clk_disable() followed by clk_enable().
> >>
> >
> > Interesting. My feeling from your description is that this is something
> > that should be added to the reset controller subsystem. It has probably
> > not been a serious issue for anyone else, but it's also likely that you
> > are not the only one that would benefit from having support for nested
> > resets in the API.
> 
> I want reset sub-system to support (1) nesting,  (2) enable_count.
> 
> To get these two features supported, the reset frame-work
> would be similar implementation to the clock subsystem.
> (In other words, we would duplicate effort
> between clock and reset.)
> 
> Moreover, it is very common to control resets and clocks
> from one hardware block.
> 
> So, I am looking for some idea that perhaps can unify the clock
> and reset subsystems.

If you find parts of the code that could be shared, we can probably
split those out into a file in lib/*.c and have that used by both
subsystems and potentially others as well.

> I found some SoCs implement reset drivers in drivers/clk.
> 
> 
> masahiro@...ver:~/workspace/linux/drivers/clk$ git grep
> reset_controller_register
> mediatek/reset.c:       ret = reset_controller_register(&data->rcdev);
> mmp/reset.c:    reset_controller_register(&unit->rcdev);
> qcom/common.c:  ret = reset_controller_register(&reset->rcdev);
> rockchip/softrst.c:     ret = reset_controller_register(&softrst->rcdev);
> sirf/clk-atlas7.c:      reset_controller_register(&atlas7_rst_ctlr);
> sunxi/clk-a10-ve.c:     err = reset_controller_register(&reset_data->rcdev);
> sunxi/clk-sun9i-mmc.c:  ret = reset_controller_register(&data->rcdev);
> sunxi/clk-usb.c:        reset_controller_register(&reset_data->rcdev);
> tegra/clk.c:    reset_controller_register(&rst_ctlr);

I think these are all the ones that have a shared hardware block doing
both clocks and resets. My guess is that most other hardware does it
differently.

> I asked about this in the following thread.
> https://lkml.org/lkml/2015/11/10/724

Your hardware seems to be in a third category, which is not uncommon
either: you have clocks, resets and additional registers all in a
single block without a structure around them.

You can handle this with purely syscon based abstraction, or you
can have a driver for the combined device that registers itself
to multiple subsystems in addition to being a syscon.

	Arnd