Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp315969pxm; Wed, 2 Mar 2022 16:11:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJwfmVD/eBR+XmDTJ4UJ17CwpMhlsDqL1C6ZEsTYIxrMzzIik/BmwFc0rkDRsAqSiJTFgHbj X-Received: by 2002:a05:6a00:2301:b0:4e1:5842:48d7 with SMTP id h1-20020a056a00230100b004e1584248d7mr35682399pfh.14.1646266307706; Wed, 02 Mar 2022 16:11:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646266307; cv=none; d=google.com; s=arc-20160816; b=F+P0nSpVKRLBjVnoRu7t3n0po93+UbVM3BpRoqEItb4NeLPQrLE+LcK3iZTEhf+xcM TBVEni7uo6klMDMxn3GeHoINnSSl//Ha+tomFqtpANukt3MKr7P0NsqemIqP0skBjWC9 /m8R07I5YAZUnXKMuG6muIz7grg5TNCFz0IKPxZGIDesC7lXuR1YzOuZFp3x92Y0uiSO 4g1+csKP5W+NKo8Vo1uJJ7l/05ADln2S1nWSZb2kEmYryN/GCjyZFZ9J3FtOcy8JfhVP oJ8rSvYz0VkCNGFXpCplirlqFzkiZ/qoP5Aas7L7VuDBvM0boOHIWo5nDe2Hx76iZFKp +PMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=PITAejhp5addOJEECsyAFsn+IidGaNKUeolD2o1Iu5Q=; b=cR1PN94iWnkH0ahI/g/dfukXaxBZJrYxmAJPqMY7SRHW04c4x1soGIvabT9D4IrDfB AYs2Iku9Zoim5UgfYhlePYyV24ylLIuOxCkio8PU86PdOvLN5ARRQ3zWRb9Bh6IABLE2 MP5MZ3MGuR0fAvbnFgkxipixQIsicKaoTXr5OX9UKbWP/FMUHPdfKUOXX6yvPid8gwhj OMkUt8sSTFE7cfmqoesLhAEqZUiBAYFUlnk3kqnVV42UE7MQT8dWqeox1DRHAXfBg6U2 5YUs8JZiywU2xHl7NFiQeKJhoezPOXEDeHYQTmIFqjsW4FMQbkCtR+AhY1ukpbBRO9mS adMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="PoBC/43Y"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id x23-20020a056a00189700b004c268022b2bsi531954pfh.19.2022.03.02.16.11.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 16:11:47 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="PoBC/43Y"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2CA831C57D7; Wed, 2 Mar 2022 15:27:09 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242993AbiCBUia (ORCPT + 99 others); Wed, 2 Mar 2022 15:38:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238537AbiCBUi2 (ORCPT ); Wed, 2 Mar 2022 15:38:28 -0500 Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 903E6DEE1 for ; Wed, 2 Mar 2022 12:37:42 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id d62so3254216iog.13 for ; Wed, 02 Mar 2022 12:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PITAejhp5addOJEECsyAFsn+IidGaNKUeolD2o1Iu5Q=; b=PoBC/43YZvGUMmCXr2U3UCSYQxPgqcU2t4h5MEKI6iwqEMFsHCmUklvmf2xpDvKuKr +6Y5Vuw70YmFaOt+w6k3rZEffAV0jBSRp9LaMm98pBQ8bLBWFpjFGRvjX9pY1ltp0ZGv QIqxQhwoiXJF6iB0zQNfXl1y10DWNmej/4M4E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=PITAejhp5addOJEECsyAFsn+IidGaNKUeolD2o1Iu5Q=; b=A4fFGvs5KRJjKL6S8JIBb4r2FSi86KuI/NzThAZJ7k4jGThX9k+OOmh84evT9Z9RL8 504YppQaFWRjwvEmafS5UUF9riGlqVl9tH+X0ugN7S3D0ooMknWASkvULdIXMlFoemB4 GGeTtps3zanlg3Z5/Hnl+gaxqJBXrnJLslzKDtcOGwHBigDQkTKBDsWsWAPbffkw95I3 PNHTjLCv9oMXfXgbx2dv2TR7xk70xUza6lSThFORuOvbcrD9E9p5e/sa/CgnkGBaYszR Z+TvmfOQKI5J7K5nqueT8LGdlcnqRpTUW3MekQR/Zmjyx5gaRQ0FuJ0atQIhkfabYtuD NaGg== X-Gm-Message-State: AOAM532m2AdYwGrjJZw//TNb67+OdoJ9G8n0YsB17IV4SY3OkHqL3A4U ucF1xA1hYlkIHCYGHY/RWHH2d2+P0JVw6A== X-Received: by 2002:a02:ccac:0:b0:314:2074:fec4 with SMTP id t12-20020a02ccac000000b003142074fec4mr26963338jap.41.1646253462175; Wed, 02 Mar 2022 12:37:42 -0800 (PST) Received: from google.com (h24-56-189-219.arvdco.broadband.dynamic.tds.net. [24.56.189.219]) by smtp.gmail.com with ESMTPSA id s13-20020a056e0218cd00b002c5f74a97d6sm51472ilu.39.2022.03.02.12.37.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 12:37:41 -0800 (PST) Date: Wed, 2 Mar 2022 13:37:40 -0700 From: Raul E Rangel To: Thomas Gleixner Cc: "Anand K. Mistry" , x86@kernel.org, Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , Linux Kernel Mailing List Subject: Re: [PATCH v2] x86: Add a prompt for HPET_EMULATE_RTC Message-ID: References: <20210429155950.v2.1.I2392cf11fb353d10459958100b69d93346fa167c@changeid> <87bl9se07w.ffs@nanos.tec.linutronix.de> <87zgxbhr17.ffs@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgxbhr17.ffs@nanos.tec.linutronix.de> X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 04, 2021 at 09:55:16AM +0200, Thomas Gleixner wrote: > On Tue, May 04 2021 at 11:21, Anand K. Mistry wrote: > > On Mon, 3 May 2021 at 17:38, Thomas Gleixner wrote: > >> On Thu, Apr 29 2021 at 16:00, Anand K. Mistry wrote: > >> > >> > This does two things: > >> > 1. Makes the option visible in menuconfig, allowing the user to easily > >> > disable this option > >> > 2. Allows olddefconfig to respect the option if it is set in the old > >> > .config file > >> > >> Well, it's pretty clear WHAT it does, but there is absolutely no > >> reasoning WHY this knob is needed in the first place. > > > > Without this option, 'make oldolddefconfig' ignores the option in the > > old .confg file and just sets it to the calculated default for the > > platform. An easy way to test this is to do 'make defconfig' on > > x86-64, set CONFIG_HPET_EMULATE_RTC=n in the generated .config, and > > run 'make olddefconfig'. Without this patch, olddefconfig will ignore > > the set option and overwrite it with CONFIG_HPET_EMULATE_RTC=y. > > Rightfully so because it's a functional correctness issue. When HPET is > enabled in legacy mode it takes over the RTC interrupt line, which makes > RTC alarms disfunctional and therefore we have to emulate it. > > So, no. > > > So, part of the why is that this enables the use of olddefconfig with > > the CONFIG_HPET_EMULATE_RTC option. The other part of why is that my > > team uses 'make olddefconfig' by providing a base config and then > > using olddefconfig to fill in the unset values with defaults to make a > > complete config file for a kernel build. I'd like to disable RTC > > emulation on a particular platform, but I can't use a config option to > > do it without this patch because 'make olddefconfig' will just ignore > > the option. > > You can like to disable it, but that does not make it more correct. See > above. If your platform does not have RTC_DRV_CMOS then you have to > disable that which will also clear CONFIG_HPET_EMULATE_RTC. So on recent AMD Chromebooks we have disabled the RTC emulation by setting rtc-cmos.use_acpi_alarm=1. * https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/3472221 * https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/2355073 It looks like recent Intel platforms have also disabled the RTC emulation. * https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/kernel/v5.15/drivers/rtc/rtc-cmos.c;l=1202 One thing I've been wondering is why is the legacy mode enabled unconditionally by the kernel? * https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/kernel/v5.15/arch/x86/kernel/hpet.c;l=1096 If it's not enabled, can we leave it disabled? I know some firmware doesn't correctly populate the INT_ROUTE_CAP to describe which IRQs are available, but if it is populated can we use it and avoid the RTC HPET emulation layer? I'm not sure what the story is on MSIs or if that's a supported use case. I have been leaving the INT_ROUTE_CAP register unset on the AMD Chromebooks since it's getting ignored by the kernel. Thanks, Raul > > Thanks, > > tglx