linux-kernel - Re: [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to work on 32-bits

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 18 Jul 2017 13:39:48 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Laurentiu Tudor <laurentiu.tudor@....com>
Cc:     gregkh <gregkh@...uxfoundation.org>,
        Stuart Yoder <stuyoder@...il.com>,
        "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Alexander Graf <agraf@...e.de>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Ruxandra Ioana Radulescu <ruxandra.radulescu@....com>,
        Bharat Bhushan <bharat.bhushan@....com>,
        Catalin Horghidan <catalin.horghidan@....com>,
        Leo Li <leoyang.li@....com>, Roy Pledge <roy.pledge@....com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 6/7] staging: fsl-mc: rewrite mc command send/receive to
 work on 32-bits

On Tue, Jul 18, 2017 at 1:08 PM, Laurentiu Tudor
<laurentiu.tudor@....com> wrote:
> On 07/17/2017 06:00 PM, Arnd Bergmann wrote:

>> Strictly speaking the __raw_writel() won't guarantee that the
>> data is written as a single word, the compiler might decide to
>> split it up into byte-sized writes if it believes the destination pointer
>> is unaligned and the CPU has no efficient writes.
>>
>> I think this cannot happen on arm or powerpc, as we go through
>> inline assembly for the store, but it's not completely portable.
>
> Should i worry about portability? Slim changes that this driver
> will ever run on anything else other than ARM & ARM64.
> My current goal was just to make it compile on other arches.

I always recommend writing any driver in the most portable way
out of principle, since you never know who looks at it for reference
when writing another driver.

I wouldn't expect the driver itself to be used on other architectures,
but of course you never know what CPU becomes fashionable
10 years from now.

        Arnd