linux-kernel - Re: [PATCH 0/3] arm64,hi6220: Enable 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-next>] [day] [month] [year] [list]

Date:	Thu, 5 Feb 2015 22:18:17 -0800
From:	Olof Johansson <olof@...om.net>
To:	Brent Wang <wangbintian@...il.com>
Cc:	Tyler Baker <tyler.baker@...aro.org>,
	Bintian Wang <bintian.wang@...wei.com>,
	linux-arm-kernel <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>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Kevin Hilman <khilman@...aro.org>,
	Mike Turquette <mturquette@...aro.org>,
	Rob Herring <rob.herring@...aro.org>,
	Zhangfei Gao <zhangfei.gao@...aro.org>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Xu Wei <xuwei5@...ilicon.com>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Haifeng Yan <yanhaifeng@...il.com>,
	Stephen Boyd <sboyd@...eaurora.org>, xuejiancheng@...wei.com,
	sledge.yanwei@...wei.com,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Guodong Xu <guodong.xu@...aro.org>, dan.zhao@...ilicon.com,
	"huxinwei@...wei.com" <huxinwei@...wei.com>,
	xuyiping@...ilicon.com, victor.lixin@...ilicon.com,
	btw@...l.itp.ac.cn, puck.chen@...ilicon.com,
	wangbinghui@...ilicon.com, zhenwei.wang@...ilicon.com,
	"Liguozhu (Kenneth)" <liguozhu@...ilicon.com>,
	XinWei Kong <kong.kongxinwei@...ilicon.com>,
	heyunlei@...wei.com, w.f@...wei.com, z.liuxinliang@...wei.com
Subject: Re: [PATCH 0/3] arm64,hi6220: Enable Hisilicon Hi6220 SoC

On Thu, Feb 5, 2015 at 8:21 PM, Brent Wang <wangbintian@...il.com> wrote:
> Hello Olof and Tyler,
>
> 2015-02-06 7:52 GMT+08:00 Tyler Baker <tyler.baker@...aro.org>:
>>
>> On 5 February 2015 at 11:02, Olof Johansson <olof@...om.net> wrote:
>> > On Thu, Feb 5, 2015 at 10:46 AM, Tyler Baker <tyler.baker@...aro.org>
>> > wrote:
>> >> Hi Bintian,
>> >>
>> >> On 5 February 2015 at 01:24, Bintian Wang <bintian.wang@...wei.com>
>> >> wrote:
>> >>> Hello,
>> >>>
>> >>> Hi6220 is one mobile solution of Hisilicon, this patchset contains
>> >>> initial support for Hi6220 SoC and HiKey development board, which
>> >>> is based on ARM Cortex A53 architecture. Initial support is minimal
>> >>> and includes just the arch configuration, clock driver, device tree
>> >>> configuration.
>> >>>
>> >>> Many peripheral drivers will be submitted later.
>> >>>
>> >>> Any comments will be appreciated!
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Bintian Wang (3):
>> >>>   arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
>> >>>   clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
>> >>>   arm64: dts: Add dts files for Hisilicon Hi6220 SoC
>> >>
>> >> Thanks for posting these! I've applied this series on top of
>> >> next-20150204, however there was some fuzz that needed to be cleaned
>> >> up on 3/3 [1]. I've confirmed the platform is booting to a basic user
>> >> space without issue.
>> >
>> > From ramdisk only, right?
>>
>> Correct, ramdisk only.
>>
>> > Given the timing of the posting of this
>> > patch set, I'm not going to merge it for 3.20. Hopefully for 3.21
>> > there will be some more peripheral support as well -- at least some
>> > sort of storage device.
>>
>> Seem fair to me. I also hope to see more patches posted shortly.
>
> Yes, the mmc and sd drivers will be submitted soon, should they be included
> in this patchset?  I have thought submitting this patch first for review, if
> there
> is no problem for this patchset and then submit other drivers, you know,
> other
> drivers will depend on this patchset.


The drivers should ideally not depend on the SoC patchset -- the
driver can go in independently. The DTS updates to specify the
hardware should go in through arm-soc even if the driver itself (and
the binding document update) should go in through the driver subsystem
instead.


So, you can choose if you want to post everything as a long series,
and cc different maintainers on the various parts of the series -- or
you can post each driver or subsystem as a patchset on its own and let
that get merged through respective maintainer. The latter is most
common these days.


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