linux-kernel - Re: [PATCH 1/9] ARM: dts: exynos: Add macros for GPIO configuration

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] [day] [month] [year] [list]

Message-ID: <5709554.y3Mq6my3Uz@wuerfel>
Date:   Wed, 31 Aug 2016 15:33:47 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Krzysztof Kozlowski <k.kozlowski@...sung.com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Kukjin Kim <kgene@...nel.org>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        devicetree@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Javier Martinez Canillas <javier@....samsung.com>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH 1/9] ARM: dts: exynos: Add macros for GPIO configuration

On Wednesday, August 31, 2016 3:07:00 PM CEST Krzysztof Kozlowski wrote:
> 
> Ok, sounds reasonable. I want to convert also older platforms S3C (drive
> strengths and pull up/down differ) and arm64 SoC: Exynos7. For the
> latter the problem is there is no common place for sharing DTS, except
> the headers. However this does not really belong to headers. I guess
> some level of duplication might be still exist.

We have stuff in the headers that belongs way less there, so I wouldn't
mind, but having a separate set of definitions for arm64 also isn't
a problem at all.
 
> > I think overall, a better solution would have been to define the
> > constants globally (shared with non-exynos) to start with,
> > and have the driver translate generic numbers into vendor
> > specific ones. Obviously it's too late for that now.
> 
> We could extend driver by adding new bindings accepting generic numbers
> (and still backward compatible) but this looks like an overkill.

Agreed, that would only make things more confusing, not less.

	Arnd