Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp4556034rwb; Sun, 13 Nov 2022 08:17:55 -0800 (PST) X-Google-Smtp-Source: AA0mqf5tmCKD8sNwzV+7H9F6dxyyldktHx+Sc8DhCmwrxMbDVUYJ61IftpPltn6uL+xqvDC8mLJg X-Received: by 2002:a17:90a:d808:b0:213:9c67:1b09 with SMTP id a8-20020a17090ad80800b002139c671b09mr10177331pjv.221.1668356275499; Sun, 13 Nov 2022 08:17:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668356275; cv=none; d=google.com; s=arc-20160816; b=WhwwDu3En7eR8RgHkNZ8azDxR8qmDx2fhQOvx0UPg5E9dsBR4YVNLakGdcW8ejcNf1 q2pMZpue+B7bvYOYg38dYDHKZpB3f/wB5g1OW/tZ+3DFtOKEncoOuJeRA8QheyqLaxqN eIbkKwLNKNjZEY3eznb2AmdGzbCY41VXd3/RFPO8q+CsH6HGlqoF0Yakp2XCJF0i2G8b IkyGMnJ2aRlOc433/kPDP4dYPnei64NvxrJNXB9MUjOzEWEjKhXHcCa9Ujf4Vy20VWJM 8e0o+Pn6W80y55PXS3vcjm1jitKZ0jpA0xhTEUap/tKEhZ5UIoHqA4OGAaIw2EA8HpQa KRYw== 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=vCiMS/elp3sdK9l9eDxJDQCzDCE3T5vFzE6vazFsbBM=; b=HPD/VYwxLwobxdIZt/fQ7xuA/v4HUp6jNdKj6P56FCSAIiNyt5000QaU864k+w6HP1 8uBkrdnbyyQe7eyS2qsaO88I/irWCfBN5emCLh0mQGneaAxpzkWbkwNUBWWbfaqltk38 NsHnBSA0U3/VjpQC7v9i/xbPbhRIdBGEUBD5iw9pjNkzxTdtZql4b/Ai0hxMnhQ74Vva jP1jX3PkvueV4sCS074kgTvPeGWmfm1toTD23nTwG1gjFq4NFwqIUWnNaCz7BJtAnvGx dhBNQArxzqIlWthds3PCLs7+AhsGQIAO4mpTLre3GRw4Ko0ckXbyfxK78QUE4FbqXRWW HJWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=DSbieSiN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x5-20020a1709028ec500b0017f871eb680si6692992plo.269.2022.11.13.08.17.43; Sun, 13 Nov 2022 08:17:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=DSbieSiN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235320AbiKMP7B (ORCPT + 90 others); Sun, 13 Nov 2022 10:59:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233792AbiKMP67 (ORCPT ); Sun, 13 Nov 2022 10:58:59 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95973E0D0; Sun, 13 Nov 2022 07:58:58 -0800 (PST) Received: from zn.tnic (p200300ea9733e71a329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e71a:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id CC4291EC0518; Sun, 13 Nov 2022 16:58:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1668355136; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=vCiMS/elp3sdK9l9eDxJDQCzDCE3T5vFzE6vazFsbBM=; b=DSbieSiNqZOW6fR/TDrRpN1E5WfowfQQZlgvbudSRIArMVsmYyMeFGn1k3YT14pjzXdDxM 2el/q+/MHG5vflunPWJzoDbPO6GCMucVTCM+qp1wAn7Oi3AkQcVjJtHTnkD+4pAJuAt+WQ HJsR4PR1WNY80AcGMd7VbzXUUB5ieTM= Date: Sun, 13 Nov 2022 16:58:52 +0100 From: Borislav Petkov To: Ashok Raj Cc: "gregkh@linuxfoundation.org" , Thiago Macieira , "Luck, Tony" , "Joseph, Jithu" , "hdegoede@redhat.com" , "markgross@kernel.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "dave.hansen@linux.intel.com" , "x86@kernel.org" , "hpa@zytor.com" , "linux-kernel@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" , "patches@lists.linux.dev" , "Shankar, Ravi V" , "Jimenez Gonzalez, Athenas" , "Mehta, Sohil" Subject: Re: [PATCH v2 12/14] platform/x86/intel/ifs: Add current_batch sysfs entry Message-ID: References: <20221021203413.1220137-1-jithu.joseph@intel.com> <20221107225323.2733518-1-jithu.joseph@intel.com> <20221107225323.2733518-13-jithu.joseph@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 Sun, Nov 13, 2022 at 07:15:03AM -0800, Ashok Raj wrote: > Do you expect the /lib/firmware/intel/ifs_0/ to contain *ONLY* files for > this platform? For microcode we have everything in the public release > included here. Same as microcode, as I said further down in my mail: "And, ofcourse it would check the format of that string against family, model, stepping and sequence number (btw this way you drop your limitation of 256 for the sequence number which you don't really need either)." > In the above proposal, you can *ONLY* put files for this platform > unlike simply copying everything released and let the kernel pick the > right one since it does the ff-mm-ss-*.scan lookup. Only the batch > number is supplied from user space. No, see above. You check the filename against the current f/m/s. Just like microcode. > Even in the current implementation, user doesn't need to know f/m/s. > That's something the driver selects automatically, just like what > microcode does for reload. Basically what I'm saying all this time. > Isn't it simple now? No need to check if user supplied the right f/m/s > since its not a user input, kernel composes that automatically. Let's see * try echoing a magic number into some sysfs file vs * simply try *all* files in a directory Latter is even simpler because you don't have to explain anything about sequence numbers - the user doesn't need to know. > The tool we have is not for a simple test run. That can easily be done with > a shell script. The tool does a bit more like handling retries if the test > was not scheduled. The fundamental pass/fail simply output is what the > kernel provides. Because a simple script can't handle retries based on the values read from that sysfs file? Yeah, right. > I don't think the current proposed interface expects a f/m/s. The entire > IFS design was sort of mimicking the microcode interface. Ashok, you prove for the nth time that you don't really read my emails. Sorry, try again. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette