Re: [PATCH 0/3] arm64,hi6220: Enable Hisilicon Hi6220 SoC

From: Olof Johansson
Date: Fri Feb 06 2015 - 01:18:24 EST


On Thu, Feb 5, 2015 at 8:21 PM, Brent Wang <wangbintian@xxxxxxxxx> wrote:
> Hello Olof and Tyler,
>
> 2015-02-06 7:52 GMT+08:00 Tyler Baker <tyler.baker@xxxxxxxxxx>:
>>
>> On 5 February 2015 at 11:02, Olof Johansson <olof@xxxxxxxxx> wrote:
>> > On Thu, Feb 5, 2015 at 10:46 AM, Tyler Baker <tyler.baker@xxxxxxxxxx>
>> > wrote:
>> >> Hi Bintian,
>> >>
>> >> On 5 February 2015 at 01:24, Bintian Wang <bintian.wang@xxxxxxxxxx>
>> >> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/