Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp180707pxu; Wed, 25 Nov 2020 16:56:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJya8OVHrNKbnc3+B1bM+uAHAXOxIknsgYS0dFDhiTDUEYbxABP7XaA7omNv/bfyyVy1OeXj X-Received: by 2002:a17:906:5945:: with SMTP id g5mr475245ejr.553.1606352204628; Wed, 25 Nov 2020 16:56:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606352204; cv=none; d=google.com; s=arc-20160816; b=i2QtddUi+0pJnHRch4Ncof01mfYzSnszf+2uat6eGffgIaCeVw+BNiVkFEK2hOonLU TBNOQScfwF5ZtyjqcexgkTFC4xFW1jN9Mdjimatmytme0lZjDckMD6VFmRw885lQszLq iuQwiguiCdCxx532xdVgA04jWGOTz6YIns5KVpiLMu76J86Aktw5IImFl4XrCqP18fdf tM1NXE5MfCkppl2wKLhdORJFYheDi2uR3eTwzWS2p/TYydoIceUCQ4oal8UmpWDvMotw y/Bd5QpWDVzoj1iD3jTNwDmnHDhGf1+0M+6KVGL9Wg4hZTHOLQKUDikg56krk8i84fYF Ctew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=mzr6UOnsfyNXZdV6NA8bv0lhwjnBdh+CcA7c2WqTOSg=; b=k7yRQg2um1MvI3ofSNL5LsW6Gluw3AWofJ/kArFYix6AE3mw02T3PRp4SncMvXloUG 6IkVdxdCKYw3DxT0ho7ZipfHrxLnSTEpxI9NTCemd2GFLE4tec+xej/MABxF34I13jgV Wa8Cd0BMwRyUrHudp6MaDhEyLv1Bw2MEuQ7BVI9pmoGuohHqJXcv97kU5q+MVnVJJxyS W9+CPzDmLGAqA7SqyvIEutF23hbco/4qetwwdD7p0O+Rr9LyvdxkDyzxhl7h4OugJ1Ka ZEVg1W2uqK9l4Rx2pYwpws/yzWCL/rpmYF20DN9elJP4O8LeN+s/9dKVsAwF2qYn9isD OteA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=g6jiyEdX; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=2R0YMZIJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p13si2188627edm.325.2020.11.25.16.56.22; Wed, 25 Nov 2020 16:56:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=g6jiyEdX; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=2R0YMZIJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728934AbgKZAul (ORCPT + 99 others); Wed, 25 Nov 2020 19:50:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725836AbgKZAul (ORCPT ); Wed, 25 Nov 2020 19:50:41 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 558CFC0613D4; Wed, 25 Nov 2020 16:50:41 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1606351840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mzr6UOnsfyNXZdV6NA8bv0lhwjnBdh+CcA7c2WqTOSg=; b=g6jiyEdXD5WNu/5SEzbD5xJdSl95lHvmYh7cn55huXcxwNNhbg0KKz2xKI46Pkn1PUQK6n Q80HByiMpuO7YMh3cE+gqSj0gM+uCFUrhCaoZuiwCm5zAp9Sr6tlOqtHanCGGX0QBbtvew tJ2isQFsddTi+JanWS0hrNlR1Hvj4TTen0+Ccst4KHh15MjbUPdH9riShDA3zxq8wzIEmk 25Yw9XD3tVKdPSZrrCiq5/RTIJwZTsC2Z5U50CHcXGJN5YMNpTh/LcAj8u5rgQGGezXwEl QksCZZwQnVgDxyolcZJoe2nirJcQKx/PlA/uY9b89CFEks+seUdaloiu/Jq7lw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1606351840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mzr6UOnsfyNXZdV6NA8bv0lhwjnBdh+CcA7c2WqTOSg=; b=2R0YMZIJ5dKXYcHHC4jYWwBdWun70vMGbQ/XNTxbGMP9hssPQssKyN5ppzXpI0DzJC29d7 g1HaUlFMVh6D5jBQ== To: Bjorn Helgaas Cc: Ingo Molnar , Borislav Petkov , x86@kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Helgaas , Feng Tang , Kai-Heng Feng Subject: Re: [PATCH] x86/PCI: Convert force_disable_hpet() to standard quirk In-Reply-To: <20201125191327.GA653914@bjorn-Precision-5520> References: <20201125191327.GA653914@bjorn-Precision-5520> Date: Thu, 26 Nov 2020 01:50:39 +0100 Message-ID: <87lfepj600.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 25 2020 at 13:13, Bjorn Helgaas wrote: > On Wed, Nov 25, 2020 at 01:46:23PM +0100, Thomas Gleixner wrote: >> Now the more interesting question is why this needs to be a PCI quirk in >> the first place. Can't we just disable the HPET based on family/model >> quirks? > > You mean like a CPUID check or something? I'm all in favor of doing > something that doesn't depend on PCI. The reason why these are PCI quirks is that the HPET is not part of the CPU core. It's usually part of 00:00:0 (aka. host bridge) and the legacy mess which resides there. OTOH that thing is integrated into the actual chip nowadays and these quirks are platform quirks, so the CPUID and the PCI vendor/device codes should be the same for a particular model. But what do I know. This whole platform/cpuid mess is inpenetrable even for people who have access to the Intel internal documentation... But, the point is that HPET does not provide any value on contemporary CPUs assumed that Intel finally decided that TSC and the TSC deadline timer are crucial system components along with the ability to get the correct frequency of these beasts from firmware/cpuid. So if parts of a particular chip generation, which we can determine by CPUID (family, model) has issues with HPET, then there is no value in preserving HPET for the N out of M submodels which are not affected even if we can differentiate them by the host bridge device id. But as I said above, what do I know. The Intel wizards which might have better insight into this should speak up and come forth with objections. Otherwise I just go and disable HPET support for the CPU models which are covered by these PCI quirks today. Ideally we can just disable it for anything more modern as well, but of course that requires that future devices have proper frequency enumeration and Intel prevents the OEMs to screw that up with their "value add" BIOS/SMM machinery. Hope dies last... Thanks, tglx