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: <CACPK8Xe-_hTey7hTJjG2-EcDsTN0qOw3bWBcrZZohEK3QOJuvg@mail.gmail.com>
Date:   Wed, 14 Oct 2020 05:28:00 +0000
From:   Joel Stanley <joel@....id.au>
To:     Stephen Boyd <sboyd@...nel.org>
Cc:     Andrew Jeffery <andrew@...id.au>,
        Michael Turquette <mturquette@...libre.com>,
        Ryan Chen <ryan_chen@...eedtech.com>,
        BMC-SW <bmc-sw@...eedtech.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-aspeed <linux-aspeed@...ts.ozlabs.org>,
        linux-clk@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical

On Wed, 14 Oct 2020 at 02:50, Stephen Boyd <sboyd@...nel.org> wrote:
>
> Quoting Ryan Chen (2020-09-28 00:01:08)
> > In ASPEED SoC LCLK is LPC clock for all SuperIO device, UART1/UART2 are
> > default for Host SuperIO UART device, eSPI clk for Host eSPI bus access
> > eSPI slave channel, those clks can't be disable should keep default,
> > otherwise will affect Host side access SuperIO and SPI slave device.
> >
> > Signed-off-by: Ryan Chen <ryan_chen@...eedtech.com>
> > ---
>
> Is there resolution on this thread?

Not yet.

We have a system where the BMC (management controller) controls some
clocks, but the peripherals that it's clocking are outside the BMC's
control. In this case, the host processor us using some UARTs and what
not independent of any code running on the BMC.

Ryan wants to have them marked as critical so the BMC never powers them down.

However, there are systems that don't use this part of the soc, so for
those implementations they are not critical and Linux on the BMC can
turn them off.

Do you have any thoughts? Has anyone solved a similar problem already?

Cheers,

Joel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ