netdev - Re: [RFC PATCH 0/4] cpsw: support for control module register

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] [day] [month] [year] [list]

Message-ID: <20130918184931.GA9994@atomide.com>
Date:	Wed, 18 Sep 2013 11:49:32 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Daniel Mack <zonque@...il.com>
Cc:	Mugunthan V N <mugunthanvnm@...com>, netdev@...r.kernel.org,
	davem@...emloft.net, bcousson@...libre.com,
	devicetree-discuss@...ts.ozlabs.org, linux-omap@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] cpsw: support for control module register

* Daniel Mack <zonque@...il.com> [130909 02:06]:
> On 08.09.2013 13:23, Mugunthan V N wrote:
> > This patch series adds the support for configuring GMII_SEL register
> > of control module to select the phy mode type and also to configure
> > the clock source for RMII phy mode whether to use internal clock or
> > the external clock from the phy itself.
> > 
> > Till now CPSW works as this configuration is done in U-Boot and carried
> > over to the kernel. But during suspend/resume Control module tends to
> > lose its configured value for GMII_SEL register in AM33xx PG1.0, so
> > if CPSW is used in RMII or RGMII mode, on resume cpsw is not working
> > as GMII_SEL register lost its configuration values.
> > 
> > The initial version of the patch is done by Daniel Mack but as per
> > Tony's comment he wants it as a seperate driver as it is done in USB
> > control module. I have created a seperate driver for the same and as
> > the merge window is open now and no feature request is accepted I am
> > submitting it as RFC for reviews.
> 
> Thanks for doing this. It's a somehow expensive approach of writing a
> single 32bit register, but I agree it's cleaner to not have this code in
> the cpsw driver directly.

The main reason for doing that is because this register is in a
separate omap SCM (System Control Module) and may need to be
eventually a child of a SCM core driver. This is to avoid invalid
PM dependencies between separate hardware modules as they can
be clocked separately.

Most of the SCM registers can be already handled by using
pinctrl-single driver, but it's not intended for using for
transceivers etc that are not strictly pinctrl related.

Regards,

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