On Tue, Feb 13, 2018 at 8:12 PM, Brendan Higgins
<brendanhigg...@google.com> wrote:
> On Tue, Feb 13, 2018 at 1:29 AM, Avi Fishman <avifishma...@gmail.com> wrote:
>> On Tue, Feb 13, 2018 at 10:30 AM, Arnd Bergmann <a...@arndb.de> wrote:
>>> On Tue, Feb 6, 2018 at 12:57 AM, Brendan Higgins
>>> <brendanhigg...@google.com> wrote:
>>>> Add a common device tree for all Nuvoton NPCM750 BMCs and a board
>>>> specific device tree for the NPCM750 (Poleg) evaluation board.
>>>> Signed-off-by: Brendan Higgins <brendanhigg...@google.com>
>>>> Reviewed-by: Tomer Maimon <tmaimo...@gmail.com>
>>>> Reviewed-by: Avi Fishman <avifishma...@gmail.com>
>>>> Reviewed-by: Joel Stanley <j...@jms.id.au>
>>>> Reviewed-by: Rob Herring <r...@kernel.org>
>>>> Tested-by: Tomer Maimon <tmaimo...@gmail.com>
>>>> Tested-by: Avi Fishman <avifishma...@gmail.com>
>>> ...
>>>> +               enable-method = "nuvoton,npcm7xx-smp";
>>> I see this has already been reviewed quite a bit, but I'm curious
>>> about the 'npcm7xx'
>>> part here. Shouldn't that be a real chip name rather than a wildcard?
>> There is a family of npcm7xx, some with SMP and some without.
>> For those who has it, it is common for all to use the same
>> "nuvoton,npcm7xx-smp".
> I think Arnd is right. In this case it should be "nuvoton,npcm750-smp". We can
> use CPU_METHOD_OF_DECLARE to alias to as many compatible properties as needed.
> Although everything in the 7xx family currently is either single core or has 
> the
> same SMP behavior, you could paint yourself into a corner if you were to make
> one SMP device in the 7xx family which behaves differently from all other
> devices and then need to come up with new compatible string names just for 
> that.

Right, this is the reason for the very simple 'no wildcards in DT
identifiers' rule.
There simply isn't a reason to make an exception here.


Reply via email to