From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96073C433FE for ; Tue, 19 Apr 2022 22:28:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358175AbiDSWbY (ORCPT ); Tue, 19 Apr 2022 18:31:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357935AbiDSWbV (ORCPT ); Tue, 19 Apr 2022 18:31:21 -0400 Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18C9E24953 for ; Tue, 19 Apr 2022 15:28:38 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id x1so141825pfj.2 for ; Tue, 19 Apr 2022 15:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kb4y1ct+D39bV4tAeLvKJMLtfqsTHYQZH4lenFOa/s=; b=CwsvcqUQiVh25FI4ZNK8H+0YPMBP3eJ+P3BPK5+aJX86n2oBAuo37ctouTLoufKp3t AR0duUflr347GoKa1+yY2PIvjEI7hepl8ldvHjU82VoBYV1IveuNNeT2qS+Bxa7Oe1Qk 8P1ZsVi1PH1Fo9rBcHc5aVoRhxrRRSjFXZEPV+B3g9mY4z3qe6c8QOAm+cakFYC8IFLs OG96Ex2auEffqpTVwkIpTzSM/T7wuEzcktzOJRoL1s2lksufdzd2y9Li1HQkwA1c2jt2 Ouj1krBuEpKLayRIU49KBi8slX2S3bxXI8AUmsjnbfr87yy/DX4QmrOeVmV/wJMbUjnb O94w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+kb4y1ct+D39bV4tAeLvKJMLtfqsTHYQZH4lenFOa/s=; b=HYx9aAay0cfjQhByppQdU6WCYtV2yxkyNewkenJTdy+M1D8UkiwCZVZ9zjRl1Pvt3u 9sKhzTqOvv3/jNP/EB4BfufX9tXSUfoZziJC756hnjONLKgfw6JRUCSc8op8g1cSymHT 25+02yd4MbQqunaB6w4TpiZ7QhxWu0MJoUqmVjoVO3yIY2OT6yO88GLhKjbQm7QD3XsK 5gy1GvBUW1+Kpjn2bOsAAS33buxiyv2Hw3wII5Dtdt+zX8P07T9DTb/YSdE5QqW3SJkW 1uzXXj/tkJBUJPd951dZx8aCHHG3SMw/KIE4om7g/V0EdyBBArg/vjbvNmm1B/2f8Ep6 GWpQ== X-Gm-Message-State: AOAM532wSv/aGkwGER7lIr1KmL6UzXWD3NGBJxkK4w56DZLQqFFbErqc X3oG0FwamXaVh7V/z4c5OdER6RzEjibfZ0pnk9ko9w== X-Google-Smtp-Source: ABdhPJy4KNZkUqNaqV9vPC98/sJFh5SHFjYoQr6PyXvPfsPEpn0S6UwD0reKh4DY9t5+K8leyfzLFiBcIRHF+HKJrHs= X-Received: by 2002:a63:1117:0:b0:399:2df0:7fb9 with SMTP id g23-20020a631117000000b003992df07fb9mr17107704pgl.40.1650407317523; Tue, 19 Apr 2022 15:28:37 -0700 (PDT) MIME-Version: 1.0 References: <20220407191347.9681-1-jithu.joseph@intel.com> <20220419163859.2228874-1-tony.luck@intel.com> <20220419163859.2228874-4-tony.luck@intel.com> In-Reply-To: From: Dan Williams Date: Tue, 19 Apr 2022 15:28:26 -0700 Message-ID: Subject: Re: [PATCH v3 03/11] platform/x86/intel/ifs: Create device for Intel IFS (In Field Scan) To: Greg KH Cc: Tony Luck , Hans de Goede , markgross@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , "H. Peter Anvin" , Jonathan Corbet , Andy Shevchenko , "Joseph, Jithu" , "Raj, Ashok" , Steven Rostedt , Linux Kernel Mailing List , Linux Doc Mailing List , platform-driver-x86@vger.kernel.org, patches@lists.linux.dev, Ravi V Shankar Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 19, 2022 at 11:09 AM Dan Williams wrote: > > On Tue, Apr 19, 2022 at 9:48 AM Greg KH wrote: > > > > On Tue, Apr 19, 2022 at 09:38:51AM -0700, Tony Luck wrote: > > > The initial implementation of IFS is model specific. Enumeration is > > > via a combination of family-model-stepping and a check for a bit in the > > > CORE_CAPABILITIES MSR. > > > > > > Linux has handled this lack of enumeration before with a code stub to > > > create a device. See arch/x86/kernel/pmem.c. Use the same approach > > > here. > > > > Ick, why? Why not just create a simple virtual device and use that? Do > > you really want to bind a driver to this? Or do you already "know" the > > only driver that you have will bind to this? > > With the realization that there may be multiple instances of an > IFS-like capability going forward, and that ideally those capabilities > would move away from a CPU capability bit to an ACPI description, then > it seemed to me that a simulated platform_device for this is a > reasonable fit. I.e. when / if an ACPI _HID is assigned for this > capability the same platform_driver can be reused for those instances. Turns out the ACPI enumeration for this may not materialize, so this can indeed move to a simple / driver-less device.