From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934777AbbLQN5g (ORCPT ); Thu, 17 Dec 2015 08:57:36 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:54948 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756074AbbLQN5e (ORCPT ); Thu, 17 Dec 2015 08:57:34 -0500 From: Arnd Bergmann To: Catalin Marinas Cc: bamvor.zhangjian@huawei.com, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, schwab@suse.de, joseph@codesourcery.com, Nathan_Lynch@mentor.com, agraf@suse.de, linux-kernel@vger.kernel.org, klimov.linux@gmail.com, Andrew Pinski , broonie@kernel.org, Yury Norov , Andrew Pinski , ddaney.cavm@gmail.com, jan.dakinevich@gmail.com, philipp.tomsich@theobroma-systems.com, linux-arm-kernel@lists.infradead.org, christoph.muellner@theobroma-systems.com Subject: Re: [PATCH v6 09/20] arm64:ilp32: share HWCAP between LP64 and ILP32 Date: Thu, 17 Dec 2015 14:56:24 +0100 Message-ID: <9201094.hyFNZIqCTY@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151217105445.GA25232@e104818-lin.cambridge.arm.com> References: <1450215766-14765-1-git-send-email-ynorov@caviumnetworks.com> <15616150.rsIFodoBKz@wuerfel> <20151217105445.GA25232@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:zAuylHl16EpJcS4mZB26X2in8VY8LTj9ce5Um4ksFwW8KOn1hZq 9yCPrgiBI8I4bUkPRLGq6H3pFJZqiCNvVsn6rsw7wl55emFtrdjsiPIJfIx6NNMeiaCw1P0 pjV9OFTDqhd2//Y7MY91XfjqfqH053H+IJ38JGAzf+h+ScbWvGKXXFiUHfzfKZoiqy0NOc1 sgJpc6K+1yvEwowVecBWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:6foc4GfxCXs=:Nmb7zjZO1ZnZlFBWTNDQXM ZeyND+fn/xgDU9yl4Adbc6JG5P9HKfh0uOQTgncTJNpG6+Mk9GeXPyCWtwRMI7oJIAQ9csmct 3Z6yuOKp8YpGBaXfo125L+6bBghjMeNIah16HbJBR5SwZ65bmUhJt04NpBj6yP63psjMLZXcg YiyVeHB74rU03kiBPZ+Hqvl3HFG8gd9F9HBcu4CmBKl41kqVTu4D3AVXZD0Ogc4Pg3LnVas1j VNJBTZFDYy/Sb+kfloHVFyeUwssqhKDdFkE7ojT5JZbq1gpEhh8rxsGjc+OB3qMV86GOvYwHb 2yrisK73ae7WsPAZLQeDErjnL5HZ3FVOlzyIYs2kYMo91Z07ufxCbzdVm/mpFZyuEerwy6YwD e0I+vQKrODhbLbWnrS1QBssK9QhU/HLK646sGBGD6++YBof8fOT4n3QsFNCIdQglr64aR3Min jo2lSNUlIQR/2zAizW8McDzZCYx/dZhUcYHOcFRbWMAygkDOazt5PB2YjTPWw1lKCRXEGXazd NUFx/1F97Ola+o0H3KRnZg2GqcwxD3MId4F7Z2B8wTFbf/8vKFFLyfdcGMsjrt+qBVr74albx 6Cu1QTnjhzJhDMsvtPqMmSQGA0DrYICgf47ZApsVKVbMRYqh4to1+cLyD2nd7dvKT83v+B6T9 vtiNrZclyhBj0e4zpfngRzEQHiHW5aAo+pnc3dZDKd3JDJ/TJEezv98HqXn5qG6d0TAuwrbd+ Ki0FOv8ZgNs04Kzy Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 17 December 2015 10:54:47 Catalin Marinas wrote: > > > IIUC, we may have a problem with this. elf_hwcap is 64-bit long while > > > elf_info[n] is 32-bit (Elf32_Addr), so we truncate AT_HWCAP if we ever > > > go beyond bit 31. The above may need to look something like: > > > > > > #define COMPAT_ELF_HWCAP \ > > > (is_a32_compat_task() \ > > > ? compat_elf_hwcap \ > > > : (u32)elf_hwcap) > > > > > > #define COMPAT_ELF_HWCAP2 \ > > > (is_a32_compat_task() \ > > > ? compat_elf_hwcap2 \ > > > : (u32)(elf_hwcap >> 32)) > > > > Yes, interesting find. > > BTW, we need to make sure this series (primarily the ABI) is big-endian > safe. I know it is not targeted at this initially but given that the > reason for doing it is legacy networking code, I wouldn't be surprised > if someone asks for BE at some point in the future. Yes, I'm sure that will be needed. Arnd