linux-kernel - Re: [PATCH v2 4/6] clk: hi6220: Clock driver support 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: <3183355.UnoLoN8dF8@wuerfel>
Date:	Mon, 13 Apr 2015 17:34:57 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Bintian <bintian.wang@...wei.com>, mark.rutland@....com,
	dan.zhao@...ilicon.com, btw@...l.itp.ac.cn,
	catalin.marinas@....com, wangbinghui@...ilicon.com,
	will.deacon@....com, huxinwei@...wei.com,
	haojian.zhuang@...aro.org, yanhaifeng@...il.com,
	rob.herring@...aro.org, mturquette@...aro.org,
	victor.lixin@...ilicon.com, xuwei5@...ilicon.com,
	jh80.chung@...sung.com, sledge.yanwei@...wei.com,
	kong.kongxinwei@...ilicon.com, heyunlei@...wei.com,
	puck.chen@...ilicon.com, zhangfei.gao@...aro.org,
	z.liuxinliang@...wei.com, devicetree@...r.kernel.org,
	khilman@...aro.org, pawel.moll@....com,
	ijc+devicetree@...lion.org.uk, tyler.baker@...aro.org,
	olof@...om.net, robh+dt@...nel.org, linux@....linux.org.uk,
	zhenwei.wang@...ilicon.com, w.f@...wei.com, guodong.xu@...aro.org,
	tomeu.vizoso@...labora.com, sboyd@...eaurora.org,
	linux-kernel@...r.kernel.org, galak@...eaurora.org,
	xuejiancheng@...wei.com, jorge.ramirez-ortiz@...aro.org,
	xuyiping@...ilicon.com, liguozhu@...ilicon.com
Subject: Re: [PATCH v2 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC

On Monday 13 April 2015 21:57:46 Bintian wrote:
> Hello Arnd,
> 
> Thanks for your code review.
> 
> On 2015/4/13 21:30, Arnd Bergmann wrote:
> > On Monday 13 April 2015 17:17:38 Bintian Wang wrote:
> >> +#define HI6220_CFG_CSI2PHY     8
> >> +#define HI6220_ISP_SCLK_GATE   9
> >> +#define HI6220_ISP_SCLK_GATE1  10
> >> +#define HI6220_ADE_CORE_GATE   11
> >> +#define HI6220_CODEC_VPU_GATE  12
> >> +#define HI6220_MED_SYSPLL      13
> >> +
> >> +/* mux clocks */
> >> +#define HI6220_1440_1200       20
> >> +#define HI6220_1000_1200       21
> >> +#define HI6220_1000_1440       22
> >> +
> >> +/* divider clocks */
> >> +#define HI6220_CODEC_JPEG      30
> >> +#define HI6220_ISP_SCLK_SRC    31
> >> +#define HI6220_ISP_SCLK1       32
> >>
> >
> > The numbers seem rather arbitrary, and you have both holes as well as duplicate
> > numbers here. I would suggest you do one of two things instead:

> I just worry about some special clocks may be added later so keep some
> holes for them;
>
> The duplicate numbers means clocks belong to different system control
> domains.

I don't understand. How would there be additional clocks added later?
Wouldn't that be a new chip?

If you have separate system control domains, doesn't that mean that you
also have separate DT bindings?

> > a) have a separate header file per clock driver and make all the
> >     numbers unique and consecutive within that header
> >
> > b) use the same numbers as the hardware registers so you can put the
> >     numbers directly into the dts and don't need a header to create
> >     an artificial ABI between the clock driver and the boot loader.
> This header file will be used by device tree (I like using the clock
> name instead "magic number" in dts :) )

That's not how it works though: The dts file is the place to define
the hardware numbers, we do that for all sorts of numbers: interrupts,
gpios, register ranges etc are all defined in dts to avoid putting
magic numbers in external header files.

There are some cases where it gets too ugly for clock controllers
that are highly irregular, but yours doesn't seem to be that kind.

E.g. all the fixed rate clocks should just be separate device nodes,
which lets you remove the binding for that node.

> so how about keep them in one header file and let dts just include
> one header file (not four files), but remove the holes?

The header files constantly cause problems with merge dependencies,
and we have some other companies that keep releasing new chips
that each time require a new header file. If hisilicon plans to make
more chips like this one, please consider coming up with more
generic bindings to avoid this.

	Arnd
--
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/