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 970BDC4332F for ; Mon, 14 Nov 2022 19:04:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236732AbiKNTEH (ORCPT ); Mon, 14 Nov 2022 14:04:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231757AbiKNTED (ORCPT ); Mon, 14 Nov 2022 14:04:03 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAC29615E; Mon, 14 Nov 2022 11:04:01 -0800 (PST) Received: from zn.tnic (p200300ea9733e773329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e773: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 BC03B1EC0304; Mon, 14 Nov 2022 20:03:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1668452639; 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=TvJ+UE/GU6N+bzHIS1Z6JgJ7axC3eCCZB2aZePqwuuI=; b=RSiC2bcdmaneRJBumhyokJqDZ5FMfLhBifoRh+KV4gXUWcR9RO/dCmkaDZbroPB1uzbspL BX826okxjtSp99mkPwxnC/NSkWqw95qyDYUfOlMNFuAGr5npe9PM3kSoCPlPRLkVmq9Ss6 OVKXrhj62SlXtiRATftf8Ai1zJytkKc= Date: Mon, 14 Nov 2022 20:03:55 +0100 From: Borislav Petkov To: Dave Hansen Cc: Ashok Raj , "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> <45aa0f69-2523-3cba-8f41-b1351f16b78f@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <45aa0f69-2523-3cba-8f41-b1351f16b78f@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 14, 2022 at 10:13:44AM -0800, Dave Hansen wrote: > So, what's the point of the sscanf() to check the *filename* other than > saving some potentially expensive request_firmware() calls? The point is to do a first sanity check. The other tests are of course mandatory. Which brings me to another bastardly idea: Let's say you have sequence numbers 0-6. Now someone comes along and changes them all to x-y, where both x and y are > 6. Or removes the sequence numbers completely. Now you go and echo your sequence number into current_batch and nothing happens. But the sequences *are* there - just not named in a magic way. Now *my* idea would work because you don't care what the filenames are. But you don't want that and you want do some silly sequence numbers which the user has to go and connect with what's in the directory. If this were microcode and arch/x86/, I would've never accepted it. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette