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: <201104271605.09537.arnd@arndb.de>
Date:	Wed, 27 Apr 2011 16:05:09 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Subhasish Ghosh" <subhasish@...tralsolutions.com>
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.

On Wednesday 27 April 2011, Subhasish Ghosh wrote:
> >
> > If I read your code correctly, you hardwire the usage of the two
> > PRUs in the da850 board code, which makes it impossible to use
> > them in different ways even if the hardware supports it. If this is
> > indeed the case, using an MFD device might not be the best option
> > and we should try to come up with a way to dynamically repurpose
> > the PRU with some user interface.
> 
> 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.

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