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]
Date:	Wed, 26 Aug 2015 10:09:56 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Maxime Coquelin <maxime.coquelin@...com>
Cc:	Michael Turquette <mturquette@...libre.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
	sboyd@...eaurora.org, s.hauer@...gutronix.de, geert@...ux-m68k.org
Subject: Re: [PATCH RFC RFT 0/3] clk: detect per-user enable imbalances and
 implement hand-off

On Wed, 26 Aug 2015, Maxime Coquelin wrote:

> Hi Lee,
> 
> On 08/26/2015 08:54 AM, Lee Jones wrote:
> >On Tue, 25 Aug 2015, Michael Turquette wrote:
> >
> >
> >>Maybe I am the one missing something? My goal was to allow the consumer
> >>driver to gate the critical clock. So we need clk_disable_unused to
> >>actually disable the clock for that to work.
> >>
> >>I think you are suggesting that clk_disable_unused should *not* disable
> >>the clock if it is critical. Can you confirm that?
> >My take is that a critical clock should only be disabled when a
> >knowledgeable driver wants to gate it for a specific purpose [probably
> >using clk_disable()].  Once the aforementioned driver no longer has a
> >use for the clock [whether that happens with clk_unprepare_disable()
> >or clk_put() ...] the clock should be ungated and be provided with
> >critical status once more.
> >
> How do you differentiate between a knowledgeable and
> non-knowledgeable driver?
> Let's take the example of the clock used by the i2c on STi SoCs.
> This clock is used by i2c, and is also critical to the system, but
> only i2c takes it.
> 
> At first transfer, the i2c will enable the clock and then disables it.
> 
> What we would expect here is that the clk_disable does not gate the
> clock, even if only user since the hand-off flag has been set.
> Else, system will freeze.

The I2C driver in this instance is not a knowledgeable driver and
should not be taking a reference to a critical clock.

In the example you provide, the real issue is that the I2C driver uses
one of the critical clock's siblings.  Without this framework, if it
gives up the reference to its own clock and there are no users of any
sibling clocks, the parent is gated.  This has the unfortunate effect
of gating the entire family, critical clock included.

These sorts of issues are precisely what we're trying to fix here.

For clarification, a knowledgeable driver is one that requests an
actual (not a sibling of) critical clock.  It's knowledgeable in the
fact that it knows what gating the clock will do to the system, but it
"knows best" that this is actually fine.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ