linux-kernel - Re: [PATCH 3/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC

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: <CAAS=xmhGiiDWm+c-dbX7NTECgLW9iCrtaUFLzwzriqV9Tpktrg@mail.gmail.com>
Date:	Wed, 11 Feb 2015 09:49:26 +0800
From:	Brent Wang <wangbintian@...il.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Bintian Wang <bintian.wang@...wei.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Will Deacon <Will.Deacon@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	"galak@...eaurora.org" <galak@...eaurora.org>,
	"khilman@...aro.org" <khilman@...aro.org>,
	"mturquette@...aro.org" <mturquette@...aro.org>,
	"rob.herring@...aro.org" <rob.herring@...aro.org>,
	"zhangfei.gao@...aro.org" <zhangfei.gao@...aro.org>,
	"haojian.zhuang@...aro.org" <haojian.zhuang@...aro.org>,
	"xuwei5@...ilicon.com" <xuwei5@...ilicon.com>,
	"jh80.chung@...sung.com" <jh80.chung@...sung.com>,
	"olof@...om.net" <olof@...om.net>,
	"yanhaifeng@...il.com" <yanhaifeng@...il.com>,
	"sboyd@...eaurora.org" <sboyd@...eaurora.org>,
	"xuejiancheng@...wei.com" <xuejiancheng@...wei.com>,
	"sledge.yanwei@...wei.com" <sledge.yanwei@...wei.com>,
	"tomeu.vizoso@...labora.com" <tomeu.vizoso@...labora.com>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"guodong.xu@...aro.org" <guodong.xu@...aro.org>,
	"xuyiping@...ilicon.com" <xuyiping@...ilicon.com>,
	"wangbinghui@...ilicon.com" <wangbinghui@...ilicon.com>,
	"zhenwei.wang@...ilicon.com" <zhenwei.wang@...ilicon.com>,
	"victor.lixin@...ilicon.com" <victor.lixin@...ilicon.com>,
	"puck.chen@...ilicon.com" <puck.chen@...ilicon.com>,
	"dan.zhao@...ilicon.com" <dan.zhao@...ilicon.com>,
	"huxinwei@...wei.com" <huxinwei@...wei.com>,
	"z.liuxinliang@...wei.com" <z.liuxinliang@...wei.com>,
	"heyunlei@...wei.com" <heyunlei@...wei.com>,
	"kong.kongxinwei@...ilicon.com" <kong.kongxinwei@...ilicon.com>,
	"btw@...l.itp.ac.cn" <btw@...l.itp.ac.cn>,
	"w.f@...wei.com" <w.f@...wei.com>,
	"liguozhu@...ilicon.com" <liguozhu@...ilicon.com>
Subject: Re: [PATCH 3/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC

Hello Mark,

2015-02-10 23:27 GMT+08:00 Mark Rutland <mark.rutland@....com>:
 [...]
>> >
>> >> >> >> +             pm_ctrl: pm_ctrl {
>> >> >> >> +                     compatible = "hisilicon,pmctrl", "syscon";
>> >> >> >> +                     #address-cells = <1>;
>> >> >> >> +                     #size-cells = <1>;
>> >> >> >> +                     reg = <0x0 0xf7032000 0x0 0x1000>;
>> >> >> >> +                     ranges = <0 0x0 0xf7032000 0x1000>;
>> >> >> >> +
>> >> >> >> +                     clock_power: clock3@0 {
>> >> >> >> +                             compatible = "hisilicon,hi6220-clock-power";
>> >> >> >> +                             reg = <0 0x1000>;
>> >> >> >> +                             #clock-cells = <1>;
>> >> >> >> +                     };
>> >> >> >> +             };
>> >> >> >
>> >> >> > I really doesn't see the point in having a sub-device that covers the
>> >> >> > entirely of the register space of the containing node, and that being
>> >> >> > the case I am extremely concerned that the containers are marked as
>> >> >> > syscon compatible.
>> >> >> The SoC clocks are designed and placed under different system controllers,
>> >> >> so I define corresponding nodes under different controllers for clock operation.
>> >> >
>> >> > What I'm concerned wit hhere is that the pm_ctrl node and the clock3@0
>> >> > sub-node have the _exact_ same register space.
>> >> >
>> >> > Given this should mean that the clock3@0 node owns that register space,
>> >> > having the container node export this as syscon does not make sense. And
>> >> > the split between pm_ctrl and clock3@) doesn't seem to make sense given
>> >> > they cover the same space.
>> >> I understand your worry and will find the max offset of those clocks
>> >> under this controller.
>> >>
>> >> >
>> >> > As I asked before, why is pm_ctrl marked as a syscon, and what's the
>> >> > point of the separate sub-node?
>> >> There is no big difference between pm_ctrl and other controller,  they
>> >> are all designed as
>> >> the base address to control some functions of other modules (certainly
>> >> include some clock gates).
>> >
>> > Are they just different instances of the same IP block, or are there
>> > fundamental differences between them?
>> You can understand it as a different instance of the same IP block,
>> there is no fundamental
>> differences between them.
>
> Ok. If that's the case each should have the same compatible string.
Although they have same function, they control different domain, I
should use different compatible string to distinguish different
domains.

Thanks,

Bintian
>
> Thanks,
> Mark.



-- 
Best Regards,

Bintian
===========================
Don't be nervous, just be happy!
--
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/