linux-kernel - Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <560565AF.2010701@oracle.com>
Date:	Fri, 25 Sep 2015 08:18:07 -0700
From:	santosh shilimkar <santosh.shilimkar@...cle.com>
To:	Nishanth Menon <nm@...com>, Murali Karicheri <m-karicheri2@...com>,
	Santosh Shilimkar <ssantosh@...nel.org>
Cc:	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific
 compatible flags

On 9/25/2015 7:50 AM, Nishanth Menon wrote:
> On 09/24/2015 10:54 AM, Murali Karicheri wrote:
> [...]
>> ti,omap3 is the family of omap3 devices similar to keystone. ti,omap3450
>> is required if there is an exceptional treatment required for ti,omap3450.
>>
>> In keystone case so far there is no case of exceptional treatment
>> required in the code for a specific SoC. So a generic name, ti,keystone
>> is used. When exceptional treatment is needed in the future, for example
>> k2hk Soc, we should introduce SoC specific string in the following order.
>
> Did you do a grep on the code to see?
> $ git grep ti,omap3 arch/arm/mach-omap2/
>             arch/arm/mach-omap2/board-generic.c:    "ti,omap3430",
> arch/arm/mach-omap2/board-generic.c:    "ti,omap3",
> arch/arm/mach-omap2/board-generic.c:    "ti,omap36xx",
> arch/arm/mach-omap2/board-generic.c:    "ti,omap3-beagle",
>
> This is the same as keystone's device support. even though only 36xx was
> needed, we introduced other SoC specific compatibility match.
>
>> "ti,k2hk-evm", "ti,k2hk", "ti,keystone"
>>
>> So unless there is an exception, there is no need for a SoC specific
>> string in the compatibility string list. So this can be added later if
>> there is need for exceptional treatment. Did I get it wrong?
>>
>
> I see both your views seem to be "if we dont need a compatible" dont add
> it. My view was based on "be accurate in the hardware description"
>
> OK - i will probably agree on the topic. But, how about userspace
> needing to know which SoC they are on, without needing to depend on
> board->soc mapping? How do we help resolve that?
>
Why the user space should care about exact SOC ?
--
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/