On Mon, Nov 14, 2022 at 08:15:58AM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> On Sun, Nov 13, 2022 at 12:48:40PM +0100, Borislav Petkov wrote:
> > Replying to both with one mail because it still feels like there's a
> > misunderstanding.
> >
> > On Sun, Nov 13, 2022 at 08:37:32AM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> > > No, please do not force the driver to resolve a filename path in the
> > > kernel.
> >
> > No, I don't mean to do any filename path resolving - all I suggest is to
> > echo into sysfs the full filename instead of the number. I.e., this:
> >
> > for i in $(ls /lib/firmware/intel/ifs_0/*.scan);
> > do
> > echo $i /sys/devices/virtual/misc/intel_ifs_0/current_batch
Bug ... $i is a full path here. I think Boris meant:
echo ${i##*/} > /sys/devices/virtual/misc/intel_ifs_0/current_batch
> > done
>
> Sorry, yes, that is fine, I was objecting to the previous "write any
> path/file to the sysfs entry and the kernel will parse it" that was
> happening in the original series. A filename, without a path, that
> always loads from the existing in-kernel firmware path locations is
> fine.
Just to set the record straight, the previous patch did *not* allow any
path/file. It seems that you misread that original patch.
Whole thing is here:
https://lore.kernel.org/all/20220708151938.986530-1-jithu.joseph@xxxxxxxxx/
But the important bits are in the commit comment:
Change the semantics of the "reload" file. Writing "1" keeps the legacy
behavior to reload from the default "ff-mm-ss.scan" file, but now interpret
other strings as a filename to be loaded from the /lib/firmware/intel/ifs
directory.
and the code:
+ if (strchr(file_name, '/'))
+ goto done;
Is there some other function/macro that we should have used to check
that user input was a filename and not a pathname that would have made
this clearer?
I do agree that overloading semantics of the "reload" was icky. Changing
the name of the sysfs file and dropping the "1" means reload default has
made this a better interface.
-Tony
