From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <51784DF9.7010302@linaro.org> Date: Wed, 24 Apr 2013 14:26:17 -0700 From: John Stultz MIME-Version: 1.0 To: Kay Sievers CC: lkml , stable , Feng Tang , Jason Gunthorpe , Thomas Gleixner Subject: Re: [PATCH] time: Revert ALWAYS_USE_PERSISTENT_CLOCK compile time optimizaitons References: <1366828376-18124-1-git-send-email-john.stultz@linaro.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: On 04/24/2013 12:44 PM, Kay Sievers wrote: > On Wed, Apr 24, 2013 at 8:32 PM, John Stultz wrote: >> Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, >> which enables some minor compile time optimization to avoid >> uncessary code in mostly the suspend/resume path could cause >> problems for userland. >> >> In particular, the dependency for RTC_HCTOSYS on >> !ALWAYS_USE_PERSISTENT_CLOCK, which avoids setting the time >> twice and simplifies suspend/resume, has the side effect >> of causing the /sys/class/rtc/rtcN/hctosys flag to always be >> zero, and this flag is commonly used by udev to setup the >> /dev/rtc symlink to /dev/rtcN, which can cause pain for >> older applications. > An alternative to reverting this could be to set that flag > unconditionally on the rtc that matches the persistent clock the > kernel uses internally? > > I mean regardless of the pretty weird config option > CONFIG_RTC_HCTOSYS_DEVICE, which internally just does a strcmp() with > the given device name when the flag is queried. :) > > Can't we just have the same interface and your original optimization > on x86, even without CONFIG_RTC_HCTOSYS_DEVICE enabled at all? This might be possible, but I'd rather it be part of the unification work w/ the persistent_clock and the RTC code, rather then a quick hack. thanks -john