linux-kernel - Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.

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]

Message-ID: <20080124172327.GA6786@localhost.localdomain>
Date:	Thu, 24 Jan 2008 20:23:27 +0300
From:	Anton Vorontsov <avorontsov@...mvista.com>
To:	Timur Tabi <timur@...escale.com>
Cc:	Poonam_Aggrwal-b10812 <b10812@...escale.com>,
	kumar.gala@...escale.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	rubini@...ion.unipv.it, linuxppc-dev@...abs.org,
	michael.barkowski@...escale.com, rich.cutler@...escale.com,
	ashish.kalra@...escale.com
Subject: Re: [PATCH UCC TDM 1/3 Updated] Platform changes for UCC TDM driver for MPC8323eRDB. Also includes related QE changes and dts entries.

On Thu, Jan 24, 2008 at 10:33:47AM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
> 
> >Are you saying that TDM is sharing same pins with the other QE device,
> >and we can choose to use/not use some device depending on which driver
> >is loaded?
> 
> No.  I'd have to closely examine the DTS, but I don't think that UCC 
> devices share pins at all.  But that isn't my point.
> 
> >In that particular case UCC configuration is static, for every UCC.
> >So, we can set up all pins in the firmware/board file.
> 
> Yes, but deciding what the UCC does might not be static.  At what point do 
> we declare, "UCC5 is for eth0 and eth0 only"?
> 
> The advantage of putting the pin configurations in the device tree is that 
> they now become configurable.  I can envision a scenario where UCC5 could 
> be either an Ethernet or a UART, depending on the setting of some jumpers 
> on the board. That's what the QE was designed for: any UCC can do any task, 
> and you can even have a UCC change its purpose while the system is running. 
> So I don't want the pin configurations hard-coded into the kernel.  Having 
> them in the device tree gives me some flexibility.

If hardware configuration is selected at the bootup time, by jumpers
or switches, it's even easier to do it right. Without pio-map.

> For instance, I have a plan (that I keep postponing) to introduce a new 
> feature in U-Boot where U-Boot can determine the settings of some board 
> jumpers and modify the device tree accordingly. The instructions on how to 
> modify the device tree would be embedded in the tree itself.

Why you need to modify the device tree for that? Let the U-Boot simply
setup pins for the kernel. Regarding kernel overwriting pins
configuration...

> I can't 
> support this feature if the kernel calls par_io_config_pin() regardless of 
> what's in the device tree.

What I've understood from the previous debates, is that ideally kernel
should not touch pins' configuration. Today we're using pio-map solely
to fix up some old firmware misconfiguration. And we can do this in the
board file still. To determine if we need to fixup the firmware or not,
we can use some device tree property instead (firmware version?).

p.s.
I'm neither for pio-map nor against. I just want some consequence
regarding this. Last thread ended with consequence that pio-map is a
bad thing to use...

-- 
Anton Vorontsov
email: cbou@...l.ru
backup email: ya-cbou@...dex.ru
irc://irc.freenode.net/bd2
--
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/