public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Kay Sievers <kay@vrfy.org>
Cc: Alexander Holler <holler@ahsoftware.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Feng Tang <feng.tang@intel.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Subject: Re: CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT_CLOCK changes?
Date: Wed, 24 Apr 2013 09:42:19 -0700	[thread overview]
Message-ID: <51780B6B.1040205@linaro.org> (raw)
In-Reply-To: <CAPXgP10OJGHwZZHCtUMZfnSzj2cKJmg6NGg2pPKiuHWPKuuo-Q@mail.gmail.com>

On 04/24/2013 09:32 AM, Kay Sievers wrote:
> On Wed, Apr 24, 2013 at 6:07 PM, John Stultz <john.stultz@linaro.org> wrote:
>
>> So summarizing the above, because as much as I'm aware, its always been
>> redundant and unnecessary on x86.  Thus being able at build time to mark it
>> as unnecessary was attractive, since it reduced the code paths running at
>> suspend/resume.
>>
>> That said, Kay's concerns about userland implications (basically the
>> userland side effects of SYSTOHC being enabled) give me pause, so I may
>> revert the HAS_PERSISTENT_CLOCK on x86 change.
> Thanks a lot for all the missing details!
>
> No, I think that all makes too much sense to revert it. Let's just
> find a way to solve it properly. I don't think it is of any pressing
> importance to keep the old behaviour, if we can still provide the
> functionality today.

So some compile time optimizations for code that likely needs to be 
reworked anyway aren't worth the risk of breaking userland to me. Let me 
pull these out (on the kernel side, the same code paths will run, we 
just avoid some extra checks) so the hctosys flag doesn't change in 
distro configs that expect it.

thanks
-john


  reply	other threads:[~2013-04-24 16:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-24  1:34 CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT_CLOCK changes? Kay Sievers
2013-04-24  2:43 ` John Stultz
2013-04-24  3:05   ` Kay Sievers
2013-04-24  3:19     ` John Stultz
2013-04-24  3:33       ` Kay Sievers
2013-04-24  3:51         ` Kay Sievers
2013-04-24 16:33           ` John Stultz
2013-04-24 16:30         ` John Stultz
2013-04-24 16:51           ` Kay Sievers
2013-04-24  5:12       ` Alexander Holler
2013-04-24 16:07         ` John Stultz
2013-04-24 16:32           ` Kay Sievers
2013-04-24 16:42             ` John Stultz [this message]
2013-04-25  7:11           ` Alexander Holler
2013-04-25 16:01             ` Kay Sievers
2013-04-25 16:13             ` John Stultz
2013-04-25 18:33               ` Jason Gunthorpe
2013-04-25 19:45                 ` Kay Sievers
2013-04-25 19:54                   ` John Stultz
2013-04-25 20:35                     ` Jason Gunthorpe
2013-04-25 20:03                 ` John Stultz
2013-04-25 21:02                   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51780B6B.1040205@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=feng.tang@intel.com \
    --cc=holler@ahsoftware.de \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox