linux-kernel - Re: [RFC PATCH 2/3] mxc: move serial driver init()/exit() to platform

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Feb 2009 23:09:00 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Paulius Zaleckas <paulius.zaleckas@...tonika.lt>, greg@...ah.com,
	s.hauer@...gutronix.de, linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/3] mxc: move serial driver init()/exit() to
 platform_device

On Tue, 24 Feb 2009, Russell King - ARM Linux wrote:

> I really don't like this approach to controlling multiplex pins, which
> is to setup the SoC pin configuration when the driver is being bound and
> to remove it when the driver is unbound.

What do you think about the reasoning given by Sascha here: 
http://marc.info/?l=linux-arm-kernel&m=123453175927569&w=2 which is power 
saving?

> 
> Let's take the issue of a serial driver.
> 
> The outputs of a serial port have defined inactive levels - for TXD, RTS
> and DTR, that's logic one.  If a driver is not loaded and you have a
> peripheral connected to this port, you probably don't want them to see
> a break level on TXD, or active RTS or DTR signal.
> 
> However, by hooking the SoC pin configuration into the binding and
> unbinding of the driver, the state of the pins are indeterminent until
> the driver is initialised.
> 
> I can think of other cases in hardware I've dealt with which required
> careful handling of SSP signals to ensure that a flip-flop in a FPGA is
> correctly set to ensure that left/right channels aren't swapped.
> 
> Basically, my point is that for 99.9% of the time, SoC pin configuration
> is determined by the platform board layout, and the right place to set
> this configuration up is in the board support file, just like we do on
> PXA platforms.
> 
> For the 0.1% of cases where a board needs to manipulate the SoC pin
> configuration depending on which drivers are loaded, doing so at driver
> probe time _may_ make sense, but it feels all together cumbersome,
> especially as unloading drivers has historically had question marks
> over it.
> 
> Surely, for this 0.1% of cases, the right solution would be to have an
> interface which allows a platform device to be unregistered, the SoC pin
> mux settings changed by platform code, and the new device registered?
> 
> Finally, note that the approach of putting init/exit into struct
> platform_device doesn't cater for all cases - we're still going to need
> to have init/exit pointers in platform data for some platform devices,
> such as MMC drivers, which have to pass parameters to those hooks.

Thanks
Guennadi
---
Guennadi Liakhovetski
--
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/