linux-kernel - Re: [PATCH] staging: tidspbridge: remove file handling functions for loader

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]

Message-ID: <AANLkTikcuqWbV1xGhirL65YKRjVW=2JcdYw272a0AJSN@mail.gmail.com>
Date:	Wed, 8 Dec 2010 17:02:20 -0600
From:	"Ramirez Luna, Omar" <omar.ramirez@...com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-omap <linux-omap@...r.kernel.org>,
	Ohad Ben-Cohen <ohad@...ery.com>, Nishanth Menon <nm@...com>,
	Felipe Contreras <felipe.contreras@...il.com>,
	Fernando Guzman Lugo <fernando.lugo@...com>,
	Armando Uribe De Leon <x0095078@...com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Ernesto Ramos Falcon <ernesto@...com>,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	Rene Sapiens <rene.sapiens@...com>
Subject: Re: [PATCH] staging: tidspbridge: remove file handling functions for loader

Hi,

On Wed, Dec 8, 2010 at 4:26 PM, Greg KH <greg@...ah.com> wrote:
> On Tue, Dec 07, 2010 at 12:09:06AM -0600, Omar Ramirez Luna wrote:
>> Instead use request_firmware and friends to get a valid firmware
>> image.
>>
>> Right now the image is supplied dynamically through udev and the
>> following rule:
>>
>> KERNEL=="omap-dsp", SUBSYSTEM=="firmware", ACTION=="add",     \
>>       RUN+="/bin/sh -c 'echo 1 > /sys/$DEVPATH/loading;       \
>>               cat $FIRMWARE > /sys/$DEVPATH/data;             \
>>               echo 0 > /sys/$DEVPATH/loading'"
>
> Why do you need a custom firmware rule?

It was meant as an example, when I compiled my minimal file system it
didn't supply the firmware.sh script nor created /lib/firmware... I
thought that not everybody would have the firmware.sh, so I just
provided a sample rule.

>  Why doesn't the default  firmware loading rule that comes with udev work properly for you?
> What are you needing different here that works properly for all other drivers?

firmware.sh under /lib/udev/ and dsp binaries installed under
/lib/firmware/, my rule is the brute version of firmware.sh so nothing
different in the script.

Probably the only change would be to supply the firmware name only, as
of now the insmod parameter requires the entire path, e.g.:

insmod bridgedriver.ko base_img=/lib/dsp/baseimage.dof

if using firmware.sh and placing firmware files under /lib/firmware/, then

insmod bridgedriver.ko base_img=baseimage.dof

Should be enough.

Regards,

Omar
--
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/