Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751655AbaANR4U (ORCPT ); Tue, 14 Jan 2014 12:56:20 -0500 Received: from mail-wi0-f179.google.com ([209.85.212.179]:50588 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751537AbaANR4S (ORCPT ); Tue, 14 Jan 2014 12:56:18 -0500 MIME-Version: 1.0 In-Reply-To: References: <1389625399-24087-1-git-send-email-taras.kondratiuk@linaro.org> <52D404DE.2020806@ti.com> <52D55CE5.1060902@ti.com> Date: Tue, 14 Jan 2014 11:56:17 -0600 X-Google-Sender-Auth: jOgtJBVcuKPHdn5JqPRctt3Lnrs Message-ID: Subject: Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian From: Nishanth Menon To: Victor Kamensky Cc: Taras Kondratiuk , Tero Kristo , Patch Tracking , Linaro Networking , Linaro Kernel , Tony Lindgren , Russell King , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , open list Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky wrote: > > When BE kernel is built Makefile does take of compiling code in BE > mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set. Agreed, and I assume you cannot instead switch to LE mode when entering assembly assuming LE? The reason I ask this is - most of our development is NOT in BE mode. we will continue to manipulate and add assembly - AM335x, DRA7/OMAP5 etc.. and obviously not every code change will indulge in ensuring right markers will be in place. by ensuring readl_relaxed handles the variations, you have ensured that I dont need to care about drivers other than to ensure they use _relaxed variants. in the case of assembly, this does not seem long term manageable. > >> is the idea of BE build meant to deal with having a single BE kernel >> build work for all platforms (including LE ones)? > > Sort of. The idea here to run BE image on OMAP4 chip, with > kernel that would deals with LE periphery correctly, but ARM > core run in BE with special kernel that compiled for BE case (i.e > CONFIG_CPU_BIG_ENDIAN is set). I still dont get the usecase - other than "hey, we do this coz we can do it!".. I mean, yep, it sounds great and all.. but 4 years down the line, is this still going to work? is this going to be interesting careabout? or we are just maintaining additional code for a passing fancy or proof-of-concept? Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/