netdev - Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib

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: <20080421175627.GD4134@ld0162-tx32.am.freescale.net>
Date:	Mon, 21 Apr 2008 12:56:27 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Laurent Pinchart <laurentp@...-semaphore.com>
Cc:	linuxppc-dev@...abs.org, avorontsov@...mvista.com,
	netdev@...r.kernel.org
Subject: Re: [RFC fs_enet: Convert MII bitbang driver to use GPIO lib

On Fri, Apr 18, 2008 at 01:34:29PM +0200, Laurent Pinchart wrote:
> Scott Wood was concerned in 
> http://patchwork.ozlabs.org/linuxppc/patch?id=17490 that the gpio lib might 
> be an unnecessary burden for memory-constraint platforms. Should we keep two 
> mdio bitbang drivers, one with direct access to the ports and one using gpio 
> lib ? The later solves the concurrent access issues present in the current 
> fs_enet mdio bitbang driber.

The memory-constrained platform I had in mind was 8xx, which doesn't use
bitbanged MDIO.  It might nice to keep the gpiolib bit separate to avoid
situations such as ep8248e where mdiobb would be the only thing requiring
a gpiolib binding, though -- but it shouldn't be two separate bitbang
drivers, just the existing bitbang driver plus some glue code that binds
it to gpiolib.

-Scott
--
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