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>] [day] [month] [year] [list]
Message-ID: <20140903194344.2099f2f3@bbrezillon>
Date:	Wed, 3 Sep 2014 19:43:44 +0200
From:	Boris BREZILLON <boris.brezillon@...e-electrons.com>
To:	Mike Turquette <mturquette@...aro.org>
Cc:	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Andrew Victor <linux@...im.org.za>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Gael PORTAY <gael.portay@...il.com>
Subject: Re: [PATCH 0/5] clk: at91: fix USB clk support on at91rm9200/sam9
 SoCs

Hi Mike,

On Wed, 03 Sep 2014 10:20:05 -0700
Mike Turquette <mturquette@...aro.org> wrote:

> Quoting Boris BREZILLON (2014-09-03 01:08:28)
> > Hi Mike,
> > 
> > On Tue, 02 Sep 2014 15:38:46 -0700
> > Mike Turquette <mturquette@...aro.org> wrote:
> > 
> > > Quoting Boris BREZILLON (2014-09-02 00:50:13)
> > > > Hi,
> > > > 
> > > > This patch series fixes several bugs in the PLL driver preventing a proper
> > > > set_rate on the PLL clk.
> > > > It also enables propagation of set_rate request on the USB clk in order to
> > > > configure the PLL rate according to the USB block requirement (48 MHz).
> > > > 
> > > > Note that existing kernels, relying on the PLL configuration made by the
> > > > the bootloader should not be impacted by this bug, but others (those
> > > > directly booting from at91bootstrap or not enabling USB support in the
> > > > bootloader) will be.
> > > > 
> > > > This bug was reported by Gaƫl, who's directly booting the kernel from the
> > > > bootstrap.
> > > 
> > > Applied to clk-next.
> > 
> > Thanks for applying this series to clk-next, but I wonder if we
> > shouldn't try to get this merged in 3.17 (in order to avoid back-porting
> > these fixes to 3.17 stable branch).
> 
> These bug have been in there since 2013, so I guess you'll need to
> backport to any other stable branches as well?
> 
> > 
> > I know I said it shouldn't impact that much users, but IMHO we
> > shouldn't rely on this assumption.
> 
> Well, the bugs have existed since last year I guess, and they are not a
> new regression as such. In fact I think that these problems have existed
> since drivers/clk/at91/clk-pll.c and drivers/clk/at91/clk-usb.c were
> introduced, no?

Well, actually the code is here since the beginning, but it's only used
since 3.17: these fixes are touching at91sam9260/at91rm9200 specific
clks code, and these 2 families have been moved to the CCF in 3.17 (DT
node definitions and CCF Kconfig option selection for these SoCs).
I'm not sure we have to backport the fixes in this case.

> 
> > 
> > Let me know if you're okay to take these patches in clk-fixes, because
> > this patch [1] needs to be applied first (I guess Nicolas will take it
> > through his -fixes branch).
> 
> The dependency is another reason I am not thrilled about taking this
> through -fixes. But additionally, "rework rm9200 USB clock to propagate
> set_rate to the parent clk" is more like a new feature than a fix.

Kind of. But without this feature, USB IPs (both host and
device) won't work if the PLL is not correctly initialized by the
bootloader, so this can be considered as a bug fix.

> 
> I feel that the code here is a bit more than I usually like to take just
> for fixing a new regression, especially when this is neither a
> regression nor is it new.

I understand.

> 
> Let me know if you still disagree.

I'd certainly prefer not having to back port these "fixes" in 3.17 after
3.18 is out, but I can deal with it.

Best Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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