linux-kernel - Re: [PATCH v4 01/11] mfd: add pruss mfd driver.

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: <CF1FC9DE1796407FB4D636189646927F@subhasishg>
Date:	Thu, 28 Apr 2011 12:47:21 +0530
From:	"Subhasish Ghosh" <subhasish@...tralsolutions.com>
To:	"Arnd Bergmann" <arnd@...db.de>
Cc:	<linux-arm-kernel@...ts.infradead.org>,
	<davinci-linux-open-source@...ux.davincidsp.com>,
	<sachi@...tralsolutions.com>,
	"Samuel Ortiz" <sameo@...ux.intel.com>, <nsekhar@...com>,
	"open list" <linux-kernel@...r.kernel.org>, <m-watkins@...com>
Subject: Re: [PATCH v4 01/11] mfd: add pruss mfd driver.

Hi,

>> SG -- It depends upon how the firmware is implemented. If another
>>             firmware is downloaded on it, it will emulate another device.
>>             Also, if a firmware emulated on it supports switching between
>> devices,
>>             that too is possible. Its just a microcontroller, we can do
>> whatever we feel like
>>             with it. Both the PRUs have separate instruction/data ram, so
>> both can be used
>>             to implement two different devices.
>
> I see. So the problem that I see with the current code is that you
> force the system to provide a set of devices from the MFD, which
> then get passed to the individual drivers (uart and can) that load
> the firmware they need. Please correct me if I am reading your code
> wrong.
>
> What I suggest you do instead is to have the request_firmware
> call in the low-level MFD driver, so the user can provide the
> firmware that he/she wants to use, and then the MFD driver will
> create the devices that match the firmware loaded into the device.
>
> You can easily do that by adding a small header to the firmware
> format and interpret that header by the MFD driver. When the name
> of the subdevice is part of that header, the MFD driver does not
> need to understand the difference, it can simply pass that on
> when creating its child devices.

I don't understand why loading the firmware should be done at the MFD 
driver.
The user already specifies the device he/she wants to start on the PRU via 
modprobe.
A driver can be inserted, which can download a printer firmware on one PRU 
and a
scanner firmware on the other. This way both cores can be used for separate 
purposes.
I mean, say in a real MFD controller, that will also have two separate cores 
running on it,
just that, the firmware on it would not be downloaded runtime but fused in 
some non volatile memory. 

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