netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080124162345.GA27359@localhost.localdomain>
Date:	Thu, 24 Jan 2008 19:23:45 +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 09:55:31AM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
> 
> >Can we not introduce new pio-maps in the device trees? There
> >were debates regarding this, and if I understood everything
> >correctly, pio-maps considered as a bad taste. Better
> >do bunch of par_io_config_pin() in the board file. Better
> >yet fixup the firmware (u-boot) to set up dedicated pins
> >correctly.
> 
> I'm on the fence with respect to pio-maps vs. par_io_config_pin() calls.  
> The problem is that the configuration of these pins is board-specific, but 
> pins are used by devices.  A device driver can't call par_io_config_pin(), 
> because the calls are different depending on which SoC and which UCC you're 
> using.  The platform code can't call par_io_config_pin(), because that 
> configuration depends on which drivers are loaded.

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? I think this particular board and patch isn't that case.

Even if someday there will be the case when drivers are mutually
exclusive, i.e. presence of some driver should trigger pins
reconfiguration, then anyway this should be handled differently.

That is, we should not _register_ two mutually exclusive devices
in the first place, so drivers will not probe them. That's board
setup code authority, and pins configuration still should happen
there.

[ Irrelevant to UCCs and this particular case: lately I've
  encountered one interesting case of Par IO usage. FHCI USB needs
  switching between pin's dedicated functions and GPIO functions.
  So, firstly it is using pins as dedicated, and later (at the bus
  reset) driver turns them to act as GPIOs. This is still handled
  without pio-map though, via gpios = <> property for that driver. ]

> In other words, the pin configurations are dependent on the UCC 
> configurations, and the UCC configurations are stored in the device tree.  
> So it makes sense to put the pin configurations in the device tree, too.

In that particular case UCC configuration is static, for every UCC.
So, we can set up all pins in the firmware/board file.

Please correct me if I'm wrong.

-- 
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html