lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 29 Oct 2015 15:53:29 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Emil Velikov <emil.l.velikov@...il.com>
Cc:	Vincent ABRIOU <vincent.abriou@...com>,
	Benjamin Gaignard <benjamin.gaignard@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH] drm/sti: Remove select of CONFIG_FW_LOADER_USER_HELPER_FALLBACK

On Thu, 29 Oct 2015 15:37:51 +0100,
Emil Velikov wrote:
> 
> On 29 October 2015 at 14:21, Vincent ABRIOU <vincent.abriou@...com> wrote:
> > Hi Takashi,
> >
> > Removing FW_LOADER_USER_HELPER_FALLBACK leads to a failure in our HQVDP
> > firmware execution.
> > Indeed, our firmware is not built-in. It is a proprietary firmware
> > uploaded into the file system that's why we need the
> > USER_HELPER_FALLBACK to be able to load it once file system is available.
> >
> Hmm most other DRM drivers also require firmware. Whist some allow the
> firmware to be picked in initrd it's not a strict requirement.
> So I'm wondering how come there hasn't been (m)any reports,
> considering that neither one sets USER_HELPER_FALLBACK.
> 
> Perhaps they also need it, or something in the sti module is done
> differently ? Just some food for thought.

It's the option each user decides to set or not, depending on the
deployed system.  Most of PCs don't need them, and actually enabling
this option causes troubles for them.  On other embedded systems, this
might be still needed.  So, it's the system setup issue, and not the
thing a driver needs to care.

Imagine that your driver has "select EXT3_FS" because your system
requires it; without that option, it won't boot, OMG!
Is it the right thing?  Obviously no.  The same logic is applied to
this case, too.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ