From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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 9F44EC433FE
	for <linux-kernel@archiver.kernel.org>; Sun, 13 Nov 2022 07:37:43 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S235176AbiKMHhm (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Sun, 13 Nov 2022 02:37:42 -0500
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33744 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S229753AbiKMHhj (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 13 Nov 2022 02:37:39 -0500
Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D5A613DC5;
        Sat, 12 Nov 2022 23:37:37 -0800 (PST)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
        (No client certificate requested)
        by ams.source.kernel.org (Postfix) with ESMTPS id 5439CB80B28;
        Sun, 13 Nov 2022 07:37:36 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3613BC433D6;
        Sun, 13 Nov 2022 07:37:34 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
        s=korg; t=1668325054;
        bh=K5f5WERRWkb6eqwCLLHTvYjdz0b2Y79tLB/FkGJ2uno=;
        h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
        b=hth5qIr6K/BXeGN+nzXp2dlIgHD/8Y+bVXeBqE7WvHKkC232mjN6XRBTxXk0dMgCb
         LWw7sCYrzy/vWO/vEKzVlfAUUN5YQKTnTbCiCrdEJVgoMQtVJcDcorSPy347BcAqYS
         Etib0blRgZ74dFduuHbC7by8fPcRhkfooIq0LAgE=
Date:   Sun, 13 Nov 2022 08:37:32 +0100
From:   "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To:     "Luck, Tony" <tony.luck@intel.com>
Cc:     Borislav Petkov <bp@alien8.de>,
        "Joseph, Jithu" <jithu.joseph@intel.com>,
        "hdegoede@redhat.com" <hdegoede@redhat.com>,
        "markgross@kernel.org" <markgross@kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>, "hpa@zytor.com" <hpa@zytor.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>,
        "patches@lists.linux.dev" <patches@lists.linux.dev>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "Macieira, Thiago" <thiago.macieira@intel.com>,
        "Jimenez Gonzalez, Athenas" <athenas.jimenez.gonzalez@intel.com>,
        "Mehta, Sohil" <sohil.mehta@intel.com>
Subject: Re: [PATCH v2 12/14] platform/x86/intel/ifs: Add current_batch sysfs
 entry
Message-ID: <Y3CevK2zhAmiUyG9@kroah.com>
References: <20221021203413.1220137-1-jithu.joseph@intel.com>
 <20221107225323.2733518-1-jithu.joseph@intel.com>
 <20221107225323.2733518-13-jithu.joseph@intel.com>
 <Y2/JNAmSoYlLKq3A@zn.tnic>
 <CC3629D6-B205-4150-80E5-FC7A7A76DD25@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CC3629D6-B205-4150-80E5-FC7A7A76DD25@intel.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Nov 12, 2022 at 06:33:58PM +0000, Luck, Tony wrote:
> 
> > Dunno - sounds silly to me. Means one needs to go and look up which
> > files are there and echo those batch numbers into sysfs and so on.
> > 
> > What I would do is make it real trivial for the user so that latter can
> > simply do:
> > 
> > for f in $(ls /lib/firmware/intel/ifs_0/*.scan);
> > do
> >    echo $f > /sys/devices/virtual/misc/intel_ifs_0/test_file
> > done
> > 
> > and simply supply the full filename.
> 
> We tried the full file name in an earlier version. GregKH was unimpressed. But that was when we were trying to overload the meaning of the “reload” file.
> 
> Is it different now?

No, please do not force the driver to resolve a filename path in the
kernel.