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:	Tue, 3 Aug 2010 18:29:46 -0500
From:	"Ramirez Luna, Omar" <omar.ramirez@...com>
To:	"Chemparathy, Cyril" <cyril@...com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
CC:	"Nori, Sekhar" <nsekhar@...com>,
	"Govindarajan, Sriramakrishnan" <srk@...com>,
	"Chemparathy, Cyril" <cyril@...com>
Subject: RE: [PATCH 1/8] netdev: separate out davinci mdio controller code

Hi,

>From: linux-omap-owner@...r.kernel.org [mailto:linux-omap-owner@...r.kernel.org] On Behalf Of Cyril
>Chemparathy
>
>Davinci's MDIO controller is present on other TI devices, without an
>accompanying EMAC.  For example, on tnetv107x, the same MDIO module is used in
>conjunction with a 3-port switch hardware.
>
>By separating the MDIO controller code into its own platform driver, this
>patch allows common logic to be reused on such platforms.
>
>Signed-off-by: Cyril Chemparathy <cyril@...com>
>---
> drivers/net/Kconfig          |   10 +
> drivers/net/Makefile         |    1 +
> drivers/net/davinci_mdio.c   |  386 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/davinci_emac.h |    4 +
> 4 files changed, 401 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/davinci_mdio.c
>
[...]
>diff --git a/drivers/net/davinci_mdio.c b/drivers/net/davinci_mdio.c
>new file mode 100644
>index 0000000..d34a53a
>--- /dev/null
>+++ b/drivers/net/davinci_mdio.c
[...]
>+
>+/* wait until hardware is ready for another user access */
>+static inline u32 wait_for_user_access(struct davinci_mdio_data *data)
>+{
>+	struct davinci_mdio_regs __iomem *regs = data->regs;
>+	u32 reg;
>+
>+	while ((reg = __raw_readl(&regs->user[0].access)) & USERACCESS_GO)
>+		;

potential infinite loop? I saw another place in your series using time_after, might fit in here too.

>+
>+	return reg;
>+}
>+
>+/* wait until hardware state machine is idle */
>+static inline void wait_for_idle(struct davinci_mdio_data *data)
>+{
>+	struct davinci_mdio_regs __iomem *regs = data->regs;
>+
>+	while ((__raw_readl(&regs->control) & CONTROL_IDLE) == 0)
>+		;

Ditto

>+}
>+
[...]

Regards,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ