Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752146AbaANVNb (ORCPT ); Tue, 14 Jan 2014 16:13:31 -0500 Received: from mail-wi0-f177.google.com ([209.85.212.177]:55352 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751485AbaANVNZ (ORCPT ); Tue, 14 Jan 2014 16:13:25 -0500 MIME-Version: 1.0 In-Reply-To: <52D5A60C.7080800@ti.com> References: <1389625399-24087-1-git-send-email-taras.kondratiuk@linaro.org> <52D404DE.2020806@ti.com> <52D55CE5.1060902@ti.com> <52D5A60C.7080800@ti.com> Date: Tue, 14 Jan 2014 15:13:24 -0600 X-Google-Sender-Auth: VdzfayaoCc9197iMG2WJ2LLiJLg Message-ID: Subject: Re: [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian From: Nishanth Menon To: Santosh Shilimkar Cc: Linaro Kernel , Russell King , Patch Tracking , Tony Lindgren , Taras Kondratiuk , Victor Kamensky , open list , Tero Kristo , Linaro Networking , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" 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 3:03 PM, Santosh Shilimkar wrote: > >> ok.. some sort of Linaro thing about which I have no background about >> - but dont really care in this context. >> > Nothing related Linaro. Its just that platforms are supporting ARM BE > mode and Linaro folks had working patches for Panda. So I suggested > to get them on the lists. I tend to think -> is this with OFF mode and CPUidle completely working? All context save and restore works with this? on HS and GP devices with BE mode builds? works on SDP4430,60 variations, considered reuse with AM43xx which could use parts of that logic? I mean to indicate that terms like "works on panda" tends always to be relative. It is nice to see it as a proof of concept, but I'd hate to see some dead code lying around in kernel and folks blindly following suit and introducing macros for new assembly for a feature that in practice just one group of folks care about and creates additional burden for rest of folks trying to keep that functionality going as we jump from one "device tree" style churn to another "framework"? Not to mean that good features should be kept away.. but personally, I could not find convincing arguments in this case.. 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/