From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 31 Jul 2014 16:49:26 -0600 Subject: [U-Boot] [PATCH] ARM: tegra: add Colibri T30 board support In-Reply-To: References: <1406828177-23047-1-git-send-email-stefan@agner.ch> Message-ID: <53DAC7F6.3080308@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/31/2014 03:55 PM, Simon Glass wrote: > On 31 July 2014 19:00, Stefan Agner wrote: >> Am 2014-07-31 19:41, schrieb Simon Glass: >>> On 31 July 2014 18:36, Stefan Agner wrote: >>>> >>>> This adds board support for the Toradex Colibri T30 module. >>>> +/* >>>> + * Enable AX88772B USB to LAN controller >>>> + */ >>>> +void pin_mux_usb(void) >>>> +{ >>>> + /* Enable LAN_VBUS */ >>>> + gpio_request(GPIO_PDD2, NULL); >>>> + gpio_direction_output(GPIO_PDD2, 1); >>>> + >>>> + /* Reset ASIX using LAN_RESET */ >>>> + gpio_request(GPIO_PDD0, NULL); >>>> + gpio_direction_output(GPIO_PDD0, 0); >>>> + >>>> + udelay(5); >>>> + >>>> + gpio_set_value(GPIO_PDD0, 1); >>> >>> >>> You are using device tree for sdhci - shouldn't we use it for USB also? >>> >> >> The Colibri T30 has a ASIX USB to Ethernet chip on its board. We >> reset/power the ASIX here. It is a very board specific reset/powering, >> hence I put it in here. >> >> In my initial patches I had it in the nvidia,phy-reset-gpio and >> nvidia,vbus-gpio properties. Technically, it would work to have this >> GPIOs in the device tree as USB properties, but I think this would be >> logically wrong... > > For VBUS I think it would be correct to put it in the USB. For the > reset, I'm not sure - it looks like a separate pin so putting it in > the device tree for USB would be wrong I think. > > What does the kernel do for these? The kernel doesn't yet have a good answer to things like this, i.e. data that's not directly driven by the requirements of a controller or protocol, but rather the custom/out-of-band aspects of the device that's connected to the controller. So, a GPIO for VBUS is something very closely tied to the USB specification, and basically any USB controller needs to represent and handle it in the same way. However, a GPIO to reset/enable a USB device is something completely outside the scope of the USB specification, and is very device specific, and there's currently no good answer re: how to handle it. There have been various attempts to solve it such as a generic "power sequences" DT binding, various proposals for a "slot" or "connector" or "target device" binding, or even explicitly defining the attached device in DT (even though it can be probed) and having the driver for that handle all the HW-specific details. However these threads have unfortunately all languished.