netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Timur Tabi <timur@codeaurora.org>
Cc: Andrew Lunn <andrew@lunn.ch>, Rob Herring <robh@kernel.org>,
	Gilad Avidov <gavidov@codeaurora.org>,
	netdev <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Sagar Dharia <sdharia@codeaurora.org>,
	shankerd@codeaurora.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	vikrams@codeaurora.org,
	Christopher Covington <cov@codeaurora.org>
Subject: Re: [PATCH V3] net: emac: emac gigabit ethernet controller driver
Date: Fri, 8 Apr 2016 16:25:42 -0700	[thread overview]
Message-ID: <20160408232542.GL391@tuxbot> (raw)
In-Reply-To: <57083834.2060102@codeaurora.org>

On Fri 08 Apr 16:01 PDT 2016, Timur Tabi wrote:

> Bjorn Andersson wrote:
> 
> >It sounds like you're trying to say that the pins used can be are
> >muxed as GPIO or MDIO, in the TLMM.
> 
> I'm not 100% sure, but I think that's correct.  If you don't want to have
> normal networking, you could connect those external pins to some GPIO device
> (like an LED or whatever), and then configure the pin muxing for GPIO
> purposes.  But if that's true, it's only true on the FSM9900. On the
> QDF2432, those lines are not connected to the TLMM.  They are instead
> hard-wired to the Emac.
> 

Then through proper use of the pinctrl framework you should configure
the FSM9900 to mux these pins appropriately and the two solutions are
equivalent.

> >In the downstream kernel this is often seen with the drivers calling
> >gpio_request() to "reserve" said pins, but all you should do is
> >described the desired configuration and muxing in the pinctrl node,
> >reference that from your driver and simply ignore the fact that those
> >pins could have been used as GPIO pins.
> 
> That makes sense, but I think the driver already does that.
> 
> https://patchwork.ozlabs.org/patch/561667/
> 
> Function emac_probe_resources() has a call to of_get_named_gpio().  And then
> emac_mac_up() calls gpio_request().  As far as I can tell, that's it.
> 
> I'm guessing that the of_get_named_gpio() call needs to be changed somehow,
> but I'm not sure how.
> 

Thanks for the link.

In short those call to the gpio framework should just be removed. They
should only be there if you're using the gpiolib to control the state of
those pins, and you're not as far as I can see.


The general outline of what you should have in your dts instead is:

soc {
	tlmm {
		compatible = "qcom,pinctrl-xyz";

		mdio_pins_a: mdio {
			state {
				pins = "gpio0", "gpio1";
				function = "mdio";
			};
		};
	};

	emac {
		compatible = "qcom,somthing-emac";

		pinctrl-names = "default";
		pinctrl-0 = <&mdio_pins_a>;
	};
};

Regards,
Bjorn

  reply	other threads:[~2016-04-08 23:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30  1:48 [PATCH V3] net: emac: emac gigabit ethernet controller driver Gilad Avidov
2015-12-30  2:31 ` kbuild test robot
     [not found] ` <1451440135-25771-1-git-send-email-gavidov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-12-30  4:26   ` kbuild test robot
2015-12-31 23:10 ` Rob Herring
2016-01-29 18:22   ` Timur Tabi
     [not found]     ` <56ABADEA.40801-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-01-29 20:10       ` Rob Herring
2016-01-29 20:38         ` Timur Tabi
2016-01-30 21:58           ` Rob Herring
2016-04-07 19:28         ` Timur Tabi
     [not found]           ` <5706B4EF.2050600-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-04-07 20:10             ` Andrew Lunn
     [not found]               ` <20160407201009.GA16136-g2DYL2Zd6BY@public.gmane.org>
2016-04-07 21:43                 ` Timur Tabi
2016-04-08  0:53                   ` Andrew Lunn
2016-04-08 19:06                     ` Timur Tabi
2016-04-08 21:07                       ` Vikram Sethi
     [not found]                         ` <57081D96.902-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-04-08 21:45                           ` Timur Tabi
     [not found]                       ` <5708013F.90207-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-04-08 22:43                         ` Bjorn Andersson
2016-04-08 23:01                           ` Timur Tabi
2016-04-08 23:25                             ` Bjorn Andersson [this message]
2016-01-06  0:21 ` Timur Tabi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160408232542.GL391@tuxbot \
    --to=bjorn.andersson@linaro.org \
    --cc=andrew@lunn.ch \
    --cc=cov@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gavidov@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sdharia@codeaurora.org \
    --cc=shankerd@codeaurora.org \
    --cc=timur@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).