From: xuejiancheng@huawei.com (xuejiancheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc
Date: Thu, 10 Dec 2015 14:13:46 +0800 [thread overview]
Message-ID: <5669181A.7030105@huawei.com> (raw)
In-Reply-To: <4297924.YW2IR8MmHA@wuerfel>
On 2015/12/9 23:32, Arnd Bergmann wrote:
> On Tuesday 08 December 2015 11:03:20 xuejiancheng wrote:
>>>>
>>>> I think we should come up with a way to handle this in general for
>>>> ARCH_HISI. It's not problem to have a couple of sub-options, but I'd
>>>> rather not have one for each SoC because I'm sure that hisilicon has
>>>> made dozens or possibly hundreds of ARM based SoCs that belong into
>>>> a couple of families.
>>>
>>> Agree with you.
>>>
>>>>
>>>> The individual selection of IP blocks is not that important, because
>>>> those tend to just be generic device drivers that we can enable on
>>>> any platform using the defconfig files.
>>>>
>>>> You said that ARCH_HI3519 and HIP04 have an identical system controller,
>>>> but it's different for Hi36xx, correct?
>>>
>>> No. The system controller of HI3519 is also different from HIP04. Maybe I gave you
>>> wrong descriptions. Sorry about that.
>>>
>>>>
>>>> So maybe we can generalize the HIP04 option to include all chips with
>>>> that system controller as they appear to share a common ancestry regardless
>>>> of the target market?
>>>>
>>>
>>> I agree that we generalize some options regardless of the product line and target market.
>>>
>>>> The Hi35xx family includes some rather older chips as well based on ARM9
>>>> etc, correct? Are they closely related to the new one as well, or do they
>>>> just share the name?
>>>
>>> Yes. It's correct. They may share some IP blocks. But they may be very different
>>> from the new one for the arch code. I also don't think it's a good idea to make
>>> them share the same name.
>>
>> I will use ARCH_HISI instead of ARCH_HI3519.
>>
>>
>
> Do you mean you want to remove the other options as well?
>
> We should do this consistently at least within the Kconfig file.
I think it is ideal if we can do that. But I won't change it in HI3519 soc patch.
I will just use ARCH_HISI for HI3519 this time.
>
> Arnd
>
> .
>
next prev parent reply other threads:[~2015-12-10 6:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 2:42 [PATCH v2 3/9] ARM: hisi: enable Hi3519 soc Jiancheng Xue
2015-12-03 9:40 ` Arnd Bergmann
2015-12-04 4:07 ` xuejiancheng
2015-12-04 21:54 ` Arnd Bergmann
2015-12-07 6:58 ` xuejiancheng
2015-12-07 9:46 ` Arnd Bergmann
2015-12-08 1:55 ` xuejiancheng
2015-12-08 3:03 ` xuejiancheng
2015-12-09 15:32 ` Arnd Bergmann
2015-12-10 6:13 ` xuejiancheng [this message]
2015-12-10 8:25 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5669181A.7030105@huawei.com \
--to=xuejiancheng@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).