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;
Date:   Sat, 12 Nov 2022 11:58:51 -0800
From:   Ashok Raj <ashok.raj@intel.com>
To:     Borislav Petkov <bp@alien8.de>
CC:     Thiago Macieira <thiago.macieira@intel.com>,
        Jithu Joseph <jithu.joseph@intel.com>, <hdegoede@redhat.com>,
        <markgross@kernel.org>, <tglx@linutronix.de>, <mingo@redhat.com>,
        <dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>,
        <gregkh@linuxfoundation.org>, <tony.luck@intel.com>,
        <linux-kernel@vger.kernel.org>,
        <platform-driver-x86@vger.kernel.org>, <patches@lists.linux.dev>,
        <ravi.v.shankar@intel.com>, <athenas.jimenez.gonzalez@intel.com>,
        <sohil.mehta@intel.com>, Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH v2 12/14] platform/x86/intel/ifs: Add current_batch sysfs
 entry
Message-ID: <Y2/6+wavSF53WgZN@a4bf019067fa.jf.intel.com>
References: <20221021203413.1220137-1-jithu.joseph@intel.com>
 <20221107225323.2733518-13-jithu.joseph@intel.com>
 <Y2/JNAmSoYlLKq3A@zn.tnic>
 <208647816.nNe6ejF2h0@tjmaciei-mobl5>
 <Y2/x/vdtE0ciuOhE@zn.tnic>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Y2/x/vdtE0ciuOhE@zn.tnic>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Xp1p8VKRJ5Cwojo3xC6tUXlGyEgt1aY7Jzi8hjC2o3GVck7u2+oFh+Jr8kpj?=
 =?us-ascii?Q?PLBXDtwIolu5D0ptFVJTD9gJv+0Z4LT25DqdErpxofrIH48OcCIlSYxzdUOu?=
 =?us-ascii?Q?Akjr6Vs/y9Sd+o/PERq9Oj96O0JMlhGQ/lOX0NuP7lnXk0WIrT/16a27ITp8?=
 =?us-ascii?Q?sMwqxwUHpdDLAM/3ZeKCP2nihQ01TSeaIgZvWJV2qT15oqpfP9oRZFhXaQMs?=
 =?us-ascii?Q?667IRukBN3Xcf08advZPFiiLy3kyMnyZ5k2w+ZzEJCx8agFiTH4Cy/r8zepe?=
 =?us-ascii?Q?Gbty7H6GKG8Q55tsPyM3Nurl9n+Yl5KNJJDwCagnTqyszSX0g3pQK3pZvog3?=
 =?us-ascii?Q?PdV1WnumAJpvHfPpmN9bAbLKlfQQ5Kcqr1yCVowTWDFpVpCIXHgv27gz5Uy5?=
 =?us-ascii?Q?r/G4KsPbkDwgM3+7tHw6Aot95D0wIFHEa2FgOiutMbt0++6+GCOeyc3EdiVt?=
 =?us-ascii?Q?zPdkI4dPBAn8sWVT9oNPSQUtdK2ZJ0TcUc2Af5xO+xdxXdXSv3G/BSfVbtH+?=
 =?us-ascii?Q?T0C5W93o/X0SAcqQOyJG3zPEeVjvIsbbJnbVqYlmPcbxE6sceBApKmq0MmZa?=
 =?us-ascii?Q?kCG1YA65QrlSHOUd5q5yZZ9s0cLZnh5gl/hdJGlxtDZBvRzjYCh/HbUynhGR?=
 =?us-ascii?Q?Ukq1nqy4vKw4qbgZpH4TFcGFn6xeuY5PvD9ynn69n0VAOqQij/gsJIfYPGzq?=
 =?us-ascii?Q?57/4HAIaS1HOD9FoY08X6l2GAsnfeWhlFipSqvnZk86ffquDSx1gGY1sCfwQ?=
 =?us-ascii?Q?XQxjSZtLhTiaZOthn2ve907NnPgAo9IWpG4Oc7yusyp1cKqVlfDjnRyMcAF7?=
 =?us-ascii?Q?IUmVbUsVz8NY6JNU4qYUz8MRHpuheV58jECflCb2QMUKaguO2GA7I77d1u0W?=
 =?us-ascii?Q?ewbZKLMeWpVAx2ALLrl97AZGe5fk24+bDVzLAGPv6q7v8nMtCtbKgHM5N8nB?=
 =?us-ascii?Q?2XS+M7scv0HJtNtzEXL/aFiJrRnyygKB01AiSl0m6TR4c600T6rInyCpPItj?=
 =?us-ascii?Q?yyVUvB/JPDpXOfL5/VEWgG3JSXoUIq7zyQ07Mxb8OQOljxC1Hn6QSQbUUEKA?=
 =?us-ascii?Q?eF1vmYSLOsGBn7vZ+C8w15p9pA1zsltDDedHTGeNosuL+eVE3LyfOQxKK/aW?=
 =?us-ascii?Q?12IurBKlc6Q48o7p17JqC1/snbed7Kv56Ebgw+ymgca5YLiA2iLWqS00fHqE?=
 =?us-ascii?Q?LP/Zk8cRUnuozb7U0O7MBFDamMe1HK/RNe/Sf22Y51gYPjpBVKxupZMQVoIC?=
 =?us-ascii?Q?oy7E8oQf+lcV6d+c4GFjv9ApYUoG/n+nER/aUa3cXsSWmd0VFzIMzDhoJzPF?=
 =?us-ascii?Q?6PCwwmCDz6FbY/kjmOJCVU+N0/plI3JBpDA05smj2QLewBsXgtbHu5MBYz5d?=
 =?us-ascii?Q?UpNno/x79Lx6TfpMWeM1Pj8SnDioo75uFL9nzUofTgKn/wN0e/yOT5/xfzmk?=
 =?us-ascii?Q?3HUVXa0gfJYy7HBx2Kq03AZhvyWLq7Cy6r8kwGxTcYqvOdwn5jKzSkkQQBxL?=
 =?us-ascii?Q?+AwJmiy70tBZSGjGfueKORp8GBl1F85I9fCa9pog1QqPklMlg/h5B3+KKvsd?=
 =?us-ascii?Q?VsskhlK5UNx+hBGkrr83ltl2X/uSEzTDVTb1UGrQ?=
X-MS-Exchange-CrossTenant-Network-Message-Id: ad5e94d6-dc14-4db6-dba4-08dac4e8550a
X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6201.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2022 19:58:57.7712
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /lUIlOZv2ZY7aBqn1bsD9KmAq0fFzY9yMKjejsmVNaz9C63ZTNEGZS8U0YbnjWcndJPzLEtwWrvxx57DaBQuWw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5782
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Nov 12, 2022 at 08:20:30PM +0100, Borislav Petkov wrote:
> On Sat, Nov 12, 2022 at 10:21:35AM -0800, Thiago Macieira wrote:
> > Not exactly. That's what this file is there for. It allows the algorithm to 
> > read the current batch file, add 1, then echo back. If the load succeeds, the 
> > the batch exists; if not, then the algorithm should simply go back to 0.
> 
> This sounds to me like there's a special order in which those batches
> should be executed?

There is no special sequence required. Idea is that user would like to run all
tests, so simply going through them works. User has no idea what the test
content is for each file, unless there is a case where they like to repeat
a specific batch on one core, they can simply skip and do one specific
batch, they don't need to go through in sequence.

> 
> I thought they're simply collections of test sequences which can be run
> in any order...
> 
> > First, there's the question of the ability to see into /lib/firmware. I'm not a 
> > kernel dev but I'm told that request_firmware() only operates on the root 
> > container's filesystem view. We're expecting that the application may get 
> > deployed as a container (with full privileges so it can write to /sys, sure), 
> > so it won't be able to see the host system's /lib to know what files are 
> > available. It could "guess" at the file names, based on the current processor's 
> > family/model/stepping and a natural number, but that's sub-optimal.
> 
> It is not about seeing - you simply give it the filename -
> request_firmware* does the "seeing". Either the file's there or it
> isn't.

Link to Tony's last post before changing the file formats to accomodate
Greg's feedback.

https://lore.kernel.org/lkml/SJ1PR11MB6083263E8EEBF106B6B61B24FC969@SJ1PR11MB6083.namprd11.prod.outlook.com/

Cheers,
Ashok