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:   Fri, 30 Nov 2018 07:37:14 +0000
From:   Anson Huang <anson.huang@....com>
To:     Stephen Boyd <sboyd@...nel.org>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Fabio Estevam <fabio.estevam@....com>
CC:     dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH] clk: imx6sl: ensure MMDC CH0 handshake is bypassed

Hi, Stephen

Best Regards!
Anson Huang

> -----Original Message-----
> From: Stephen Boyd [mailto:sboyd@...nel.org]
> Sent: 2018年11月30日 15:25
> To: kernel@...gutronix.de; linux-arm-kernel@...ts.infradead.org;
> linux-clk@...r.kernel.org; linux-kernel@...r.kernel.org;
> mturquette@...libre.com; s.hauer@...gutronix.de; shawnguo@...nel.org;
> Anson Huang <anson.huang@....com>; Fabio Estevam
> <fabio.estevam@....com>
> Cc: dl-linux-imx <linux-imx@....com>
> Subject: Re: [PATCH] clk: imx6sl: ensure MMDC CH0 handshake is bypassed
> 
> Quoting Anson Huang (2018-11-29 23:23:47)
> > Same as other i.MX6 SoCs, ensure unused MMDC channel's handshake is
> > bypassed, this is to make sure no request signal will be generated
> > when periphe_clk_sel is changed or SRC warm reset is triggered.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@....com>
> 
> Does this need a fixes tag?

Normally this bit is 1b'1 by reset, but during our development, it used to be
overwritten in u-boot and lead to some clock operation fail in Linux kernel, that is why we ensure it
in clock driver early phase. IMO, it should be OK to not add a fix tag, since it is just
to make sure the setting is correct and NOT depends on the hardware reset value which
could be changed in u-boot.

Anson.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ