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]

Date:	Sun, 15 May 2011 11:33:23 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Subhasish Ghosh <subhasish@...tralsolutions.com>,
	"Nori, Sekhar" <nsekhar@...com>,
	linux-arm-kernel@...ts.infradead.org,
	davinci-linux-open-source@...ux.davincidsp.com,
	sachi@...tralsolutions.com, Samuel Ortiz <sameo@...ux.intel.com>,
	open list <linux-kernel@...r.kernel.org>,
	"Watkins, Melissa" <m-watkins@...com>
Subject: Re: [PATCH v4 01/11] mfd: add pruss mfd driver.

On Sunday 15 May 2011, Mark Brown wrote:
> > My whole point has been that you register them from the main pruss driver
> > based on run-time data instead of compile-time pre-configured stuff in the
> > board file.
> 
> I'm not so sure - if the usage is fixed as a result of the pins on the
> device being wired a CAN bus then it seems reasonable to tell the system
> about that so it'll stop the user trying to run SPI or something against
> it at runtime.

I'm mostly worried about the case where the pins are not hardwired for
some specific function -- Subhasish was mentioning that these may be
implemented using a pluggable extension board and I want to make sure
that you are not required to recompile the kernel when changing the
extension board.

However, you made a good point that in many cases it will be hardwired
so it may be valuable to preconfigure this in a way that does not require
scripts to set up variables in sysfs when you already know what is there.

Note that my suggestion to put the device name into the firmware file
covers this case, because you can then simply ship a firmware blob that
matches the hardware configuration. Thinking about the future device
tree setup, you can even put the firmware blob itself into a property
in the device tree file.

	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/