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: <3428574.kpvz0qlT1a@diego>
Date:	Thu, 10 Apr 2014 11:34:47 +0200
From:	Heiko Stübner <heiko.stuebner@...com>
To:	Gregory CLEMENT <gregory.clement@...e-electrons.com>
Cc:	Matthias Brugger <matthias.bgg@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Rutland <mark.rutland@....com>,
	Andrew Lunn <andrew@...n.ch>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Russell King <linux@....linux.org.uk>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Florian Vaussard <florian.vaussard@...l.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Jason Cooper <jason@...edaemon.net>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Rob Herring <robh+dt@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Silvio F <silvio.fricke@...il.com>,
	Kumar Gala <galak@...eaurora.org>,
	Olof Johansson <olof@...om.net>,
	Jonathan Cameron <jic23@...nel.org>
Subject: Re: [PATCH 3/4] arm: add basic support for Mediatek MT6589 boards

Hi Gregory,

Am Donnerstag, 10. April 2014, 08:46:03 schrieb Gregory CLEMENT:
> On 10/04/2014 08:29, Matthias Brugger wrote:
> > 2014-04-09 22:26 GMT+02:00 Gregory CLEMENT <gregory.clement@...e-
electrons.com>:
> >> Hi Matthias,
> >> 
> >> On 09/04/2014 19:45, Matthias Brugger wrote:
> >>> diff --git a/arch/arm/boot/dts/mtk6589.dtsi
> >>> b/arch/arm/boot/dts/mtk6589.dtsi new file mode 100644
> >>> index 0000000..6dbb74f
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/mtk6589.dtsi
> >>> @@ -0,0 +1,105 @@
> >>> +/*
> >>> + * Copyright (c) 2014 MundoReader S.L.
> >>> + * Author: Matthias Brugger <matthias.bgg@...il.com>
> >>> + *
> >>> + * This program is free software; you can redistribute it and/or modify
> >>> + * it under the terms of the GNU General Public License as published by
> >>> + * the Free Software Foundation; either version 2 of the License, or
> >>> + * (at your option) any later version.
> >>> + *
> >>> + * This program is distributed in the hope that it will be useful,
> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >>> + * GNU General Public License for more details.
> >>> + */
> >>> +
> >>> +#include <dt-bindings/interrupt-controller/irq.h>
> >>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> >>> +#include "skeleton.dtsi"
> >>> +
> >>> +/ {
> >>> +     compatible = "mediatek,mt6589";
> >>> +     interrupt-parent = <&gic>;
> >>> +
> >>> +     cpus {
> >>> +             #address-cells = <1>;
> >>> +             #size-cells = <0>;
> >>> +
> >>> +             cpu@0 {
> >>> +                     device_type = "cpu";
> >>> +                     compatible = "arm,cortex-a7";
> >>> +                     next-level-cache = <&L2>;
> >>> +                     reg = <0x0>;
> >>> +             };
> >>> +             cpu@1 {
> >>> +                     device_type = "cpu";
> >>> +                     compatible = "arm,cortex-a7";
> >>> +                     next-level-cache = <&L2>;
> >>> +                     reg = <0x1>;
> >>> +             };
> >>> +             cpu@2 {
> >>> +                     device_type = "cpu";
> >>> +                     compatible = "arm,cortex-a7";
> >>> +                     next-level-cache = <&L2>;
> >>> +                     reg = <0x2>;
> >>> +             };
> >>> +             cpu@3 {
> >>> +                     device_type = "cpu";
> >>> +                     compatible = "arm,cortex-a7";
> >>> +                     next-level-cache = <&L2>;
> >>> +                     reg = <0x3>;
> >>> +             };
> >>> +
> >>> +     };
> >>> +
> >>> +     clocks {
> >>> +             #address-cells = <1>;
> >>> +             #size-cells = <1>;
> >>> +             ranges;
> >>> +
> >>> +             system_clk: system_clk {
> >>> +                     compatible = "fixed-clock";
> >>> +                     clock-frequency = <13000000>;
> >>> +                     #clock-cells = <0>;
> >>> +                     clock-output-names = "system_clk";
> >>> +             };
> >> 
> >> Is it really a fixed clock without any parent, or do you
> >> declare it as a fixed clock because you don't have any clock
> >> common framework support yet?
> > 
> > I don't have any common clock framework support yet.
> 
> So maybe you should provide one (even a very simple one).
> 
> Pretending a clock is a fixed clock and ignoring its parents
> will be problematic when you will add the common clock framework
> support because the device tree is supposed to be stable and you won't
> be able to change it then.

personally I think the danger of introducing unsuitable bindings/precedents 
for a clock controller before it is fully understood is higher.

I'd just rename the clock above to something like dummy130m like sunxi also 
does for example, to reflect its unfinished state and when the clock controller 
is present later on change the supplying clock of the timer.

Or maybe I'm overlooking something here :-)


Heiko
--
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