[PATCH v2 2/2] net: flexcan: add transceiver switch gpios support

[Dong Aisheng]

On Thu, Jun 28, 2012 at 08:32:22PM +0800, Lothar Waßmann wrote:
> Hi,
> 
> Dong Aisheng writes:
> > On Thu, Jun 28, 2012 at 08:05:14PM +0800, Marc Kleine-Budde wrote:
> > > On 06/28/2012 01:46 PM, Shawn Guo wrote:
> > > > On Thu, Jun 28, 2012 at 07:33:28PM +0800, Dong Aisheng wrote:
> > > >>> +		phy_stby_gpio = of_get_named_gpio_flags(pdev->dev.of_node,
> > > >>> +							"phy-standby-gpios",
> > > >>> +							0, &flags);
> > > >>> +		if (gpio_is_valid(phy_stby_gpio)) {
> > > >>> +			if (flags == OF_GPIO_ACTIVE_LOW)
> > > >>> +				phy_stby_high = false;
> > > >>> +			err = devm_gpio_request_one(&pdev->dev, phy_stby_gpio,
> > > >>> +						    GPIOF_DIR_OUT,
> > > >>> +						    "phy-standby");
> > > >>> +			if (err) {
> > > >>> +				dev_err(&pdev->dev,
> > > >>> +					"failed to request gpio %d: %d\n",
> > > >>> +					phy_stby_gpio, err);
> > > >>> +				goto failed_gpio;
> > > >> I checked mx28 evk, it seems the phy only has a STB gpio and shared by both CAN0&CAN1.
> > > >> I wonder the CAN1 probe may fail here.
> > > >>
> > > > It can be managed by dts.  Here is what I have in imx28-evk.dts, where
> > > > only can0 has phy-enable-gpios property.
> > > > 
> > > > 
> > > > 	can0: can at 80032000 {
> > > > 		pinctrl-names = "default";
> > > > 		pinctrl-0 = <&can0_pins_a>;
> > > > 		phy-enable-gpios = <&gpio2 13 0>;
> > > > 		status = "okay";
> > > > 	};
> > > > 
> > > > 	can1: can at 80034000 {
> > > > 		pinctrl-names = "default";
> > > > 		pinctrl-0 = <&can1_pins_a>;
> > > > 		status = "okay";
> > > > 	};
> > > 
> > > Will this work if can0 is down and can1 is up?
> > > 
> > > Can we abstract the transceiver power as a regulator? Or a clock? :P
> > > 
> > Hmm, it may not be a power.
> > For mx28evk, it's a STBY pin.
> > So it may hard to abstract it as a regulator or clock.
> > 
> I have created a 'gpio-switch' driver in my private tree that can be
> used for exactly this purpose. It takes care of the pin polarity and
> initial state of the pins and can handle shared pins like in this
> case. The client driver does not even need to care whether an actual
> GPIO exists for the current platform.
> 
> I could prepare a patch and post it here.
> 
Would be glad to see your patches.
It may be useful, not only for this case,
we also meet some other issues, i'm not sure but may have similar requirement
like SDIO WiFi reset, usb phy reset and etc.

Regards
Dong Aisheng