From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753699AbbIZTeU (ORCPT ); Sat, 26 Sep 2015 15:34:20 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:65466 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753323AbbIZTeP (ORCPT ); Sat, 26 Sep 2015 15:34:15 -0400 From: Arnd Bergmann To: linaro-kernel@lists.linaro.org Cc: Viresh Kumar , "Rafael J. Wysocki" , "open list:NETWORKING DRIVERS (WIRELESS)" , "moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM..." , "open list:TARGET SUBSYSTEM" , "linux-doc@vger.kernel.org" , Greg Kroah-Hartman , "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" , "Rafael J. Wysocki" , QCA ath9k Development , Linux Kernel Mailing List , Intel Linux Wireless , Linux ACPI , "open list:AMD IOMMU (AMD-VI)" , "open list:BLUETOOTH DRIVERS" , "netdev@vger.kernel.org" , Johannes Berg , Linux Memory Management List , "linux-arm-kernel@lists.infradead.org" , "open list:EDAC-CORE" Subject: Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Date: Sat, 26 Sep 2015 21:33:56 +0200 Message-ID: <1540878.9slRi6Q7xb@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:xNQGTxaLsf4vf0PB4X7PvcNFXaLYzoS6i7vzz6Npmgk8HTYM9DJ VjxoIX9SbLWGbuohRnjej1gj4Vl0g8W5VsB6XD2p/DsS6TYKkoVLsKupYWk5vwDB9xy1L6R lzNiKVGFu4UT/SSziNDHDSS2tVxZkqitNvb9+YVhxoS552hEWYjG56SzPr/4n26RHiZJrTo 6NSjD9a8Z/TXBR/lhHADw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FVAbrH/VKTg=:bx8Gr7LE/G8KkIiEo2jCnL r/KO63iNKPs7mIgFisI74F6FDqt97f92haX4EmNdMOHD2JVFSyKR/UdIStg4cgzrk1OXrHFqt WDi+Vr19RCbfLjJP1zkoqKdWOdc+iL/gry4sKTS63MYrtDvJq1+4RPFaetJ8JR9nbYmn3Yf3v ktAGywHP16i+aqT1chcDO96OSm7KAdnqKu+eYthNoWp4Y5aelkOouhD5B85E6x+sevozSLHka DwxNVgRt1AIBZhutNT3FiGsJtS7te1v5g36c0DLsW85Y197i5hK3h275EShMBOrOa/3V2QijB begDu4ubbL6N3tX6P5K9i2wWCV9OtlMeWAS4HfKpLuUlGUCTpHD09hJmVhwSPlY5EteRU/MMc KvIHF0amgyNtHQkUiqccAOZpjKvPU/GcQf/gB3CxzisbH/vlRVaaDbxc/aKFG/HW5gGm811Jp 7q1iuxzWvBJiGwEr0HqOa+ee4apyyrYwoiJ1qxR/k+tc6iWIsNRO9ZAhOsHwhayrAZAeEURNa EL94UXZXlWhFHAl73DHwk8NeCuBR7gprLhyFKgz6QduGVtJSJaRrNFdjqz7ZgKn8LTx1hWwP6 SoOLd3IMZXfd2BzRDhheDdGdiT+Uw+PM7ptooH6TqvHii0CPB4WhktgqI7rLPjHMGfdMD69KH iKp+uVUWd+fnu2aC6wxLeIHObXtO0OzVhgcIl/fvmdE/twr52qhdyIdyM142tHE8O4puYJhaH ltFcVtscJtsz2O8G Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote: > On 25 September 2015 at 15:19, Rafael J. Wysocki wrote: > > So if you allow something like debugfs to update your structure, how > > do you make sure there is the proper locking? > > Not really sure at all.. Isn't there some debugfs locking that will > jump in, to avoid updation of fields to the same device? No, if you need any locking to access variable, you cannot use the simple debugfs helpers but have to provide your own functions. > >> Anyway, that problem isn't here for sure as its between two > >> unsigned-longs. So, should I just move it to bool and resend ? > > > > I guess it might be more convenient to fold this into the other patch, > > because we seem to be splitting hairs here. > > I can and that's what I did. But then Arnd asked me to separate it > out. I can fold it back if that's what you want. It still makes sense to keep it separate I think, the patch is clearly different from the other parts. Arnd