linux-kernel - Re: [PATCH v3 0/6] Introducing Exynos ChipId driver

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]

Date:	Sun, 11 May 2014 18:51:26 -0700
From:	Olof Johansson <olof@...om.net>
To:	Pankaj Dubey <pankaj.dubey@...sung.com>
Cc:	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH v3 0/6] Introducing Exynos ChipId driver

Hi,

On Sun, May 11, 2014 at 6:52 PM, Pankaj Dubey <pankaj.dubey@...sung.com> wrote:
> On 05/11/2014 04:12 PM, Olof Johansson wrote:
>>
>> Hi,
>>
>> On Sat, May 10, 2014 at 12:18 AM,  <y@...sung.com> wrote:
>>>
>>> From: Pankaj Dubey <pankaj.dubey@...sung.com>
>>>
>>> This patch series attempts to get rid of soc_is_exynosXXXX macros
>>> and eventually with the help of this series we can probably get
>>> rid of CONFIG_SOC_EXYNOSXXXX in near future.
>>> Each Exynos SoC has ChipID block which can give information about
>>> SoC's product Id and revision number. Currently we have single
>>> DT binding information for this as "samsung,exynos4210-chipid".
>>> But Exynos4 and Exynos5 SoC series have one small difference in
>>> chip Id, with resepect to product id bit-masks. So it means we
>>> should have separate compatible string for these different series
>>> of SoCs. So I have added second compatible string for handling
>>> this difference.
>>> This patch series is based on Kukjin Kim's for-next (3.14_rc1 tag)
>>> and prepared on top of following patch series and it's dependent
>>> patch series.
>>>
>>> [1]: Map SYSRAM through generic SRAM bindings by Sachin Kamat.
>>>          http://www.spinics.net/lists/arm-kernel/msg327677.html
>>> [2]: Exynos PMU cleanup and refactoring.
>>>          https://lkml.org/lkml/2014/4/30/44
>>> [3]: Introduce drivers/soc and add QCOM GSBI driver.
>>>          https://lkml.org/lkml/2014/4/24/520
>>>
>>> Revision 2 and it's discussion can be found here
>>>   - https://lkml.org/lkml/2014/5/6/100
>>
>> As I just realized when I commented on the last patch in the patchset
>> (the cpufreq section): I think you can, and should, use
>> of_machine_is_compatible() for most of these cases, instead of using a
>> new API through a chipid driver. Since all boards based on an SoC
>> should have that in the string of compatibles, it's a shared and easy
>> way to handle this without adding custom drivers per manufacturer.
>
> I am sorry, I could not see your comments in my last patch-set.
>
> Anyway, thanks for review. During first version of this patch, I had
> discussion with Arnd [1], and it looks like he do not like idea of using
> "of_machine_is_compatible".
>
> [1]: https://lkml.org/lkml/2014/5/5/126
>       and
> https://lkml.org/lkml/2014/5/5/335

Ok, I've commented on that thread now.

> So my proposal was till we get generic solution for all files
> under mach-exynos let's use chip-id driver provided APIs.

of_machine_is_compatible() is a quite sensible existing generic
interface to do this. We don't need to add a driver for it.

> Also chip-id driver is not only for providing this API but also
> to provide SoC specific information as a sysfs entry to userspace.
> So even though we do not want to use chipid driver API's
> for identifying SoCs we can keep this driver.

For this you might want a chipid driver, yes. I'm mostly objecting to
the addition of the new is_soc_.*() API, not the introduction of the
driver for that purpose.

> So let us discuss again and decide which will be best way
> (at the same time less overhead) solution for removing usage
> of soc_is_exynosXYZ and related CONFIG macros from exynos.

> @Arnd and Tomasz, I would appreciate if you spent some time
> to review this series as I have addressed many of your
> review comments.


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