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: <20190118194802.GZ5544@atomide.com>
Date:   Fri, 18 Jan 2019 11:48:02 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     Discussions about the Letux Kernel <letux-kernel@...nphoenux.org>,
        paul@...an.com, sboyd@...nel.org, mturquette@...libre.com,
        linux-kernel@...r.kernel.org, t-kristo@...com,
        bcousson@...libre.com, linux-omap@...r.kernel.org,
        linux-clk@...r.kernel.org, Keerthy <j-keerthy@...com>
Subject: Re: [Letux-kernel] [PATCH v3 3/3] arm: omap_hwmod disable ick
 autoidling when a hwmod requires that

* Andreas Kemnade <andreas@...nade.info> [190118 19:42]:
> On Fri, 18 Jan 2019 20:38:47 +0100
> Andreas Kemnade <andreas@...nade.info> wrote:
> 
> > Hi,
> > 
> > On Fri, 18 Jan 2019 10:36:30 -0800
> > Tony Lindgren <tony@...mide.com> wrote:
> > 
> > [...]
> > > til the next workaround.
> > >   
> > > > That flags also causes the iclk being enabled/disabled
> > > > manually.    
> > > 
> > > Yes but SWSUP_IDLE for the interface clock to me currently
> > > just means:
> > > 
> > > "manually enable and disable ocp interface clock"
> > >   
> > well, if we want to manually disable it and not automatically,
> > we have to disable autoidle or it will be automatically disabled.
> > 
> > Disabling it manually when it is already auto-disabled (by autoidle) is
> > just practically a no-op towards the clock.
> > 
> > > and with your changes it becomes:
> > > 
> > > "manually enable and disable ocp interface clock and block
> > >  autoidle while in use".
> > > 
> > > So aren't we now changing the way things behave in general
> > > for SWSUP_IDLE?
> > >   
> > Yes, we are, so proper testing is needed. But If I read those comments
> > it was always intended this way but not fully implemented because it
> > appeared to be more work like needing a usecounter (which my patchset
> > also adds) for that autoidle flag.
> > 
> and there are quite few hwmods marked by this flag. 
> And then there are those clocks marked by this flags (on am33xx) which
> do not have that autoidle feature at all, so the risk is not too high.

Keerthy, can you please test this series on top of the
related clock patches with your am335x PM test cases?

Regards,

Tony


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ