From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932378AbcF3N75 (ORCPT ); Thu, 30 Jun 2016 09:59:57 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:39078 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932294AbcF3N7w (ORCPT ); Thu, 30 Jun 2016 09:59:52 -0400 Subject: Re: [PATCH] usb: host: Allow EHCI_OMAP to be built-in when USB_GADGET is 'm' To: Felipe Balbi References: <1467276056-19357-1-git-send-email-rogerq@ti.com> <8760srgf00.fsf@linux.intel.com> CC: , , , , , , From: Roger Quadros Message-ID: <577525BF.3060509@ti.com> Date: Thu, 30 Jun 2016 16:59:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <8760srgf00.fsf@linux.intel.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Felipe, On 30/06/16 13:14, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> NOP_USB_XCEIV is used not only by gadget drivers but by >> host drivers as well e.g. EHCI_OMAP. >> >> commit 5a8d651a2bde ("usb: gadget: move gadget API functions to udc-core") >> made it so that NOP_USB_XCEIV can't be built-in if USB_GADGET is 'm'. >> But this prevents EHCI_OMAP to be built-in if USB_GADGET is 'm'. >> >> Fix this undesired behaviour by moving usb_gadget_vbus_connect/disconnect() >> to usb/gadget.h so that NOP_USB_XCEIV has no build dependency >> on USB_GADGET. >> >> Retain the original Kconfig behaviour i.e. NOP_USB_XCEIV is selected >> by drivers that need it. > > no, this is the wrong way to fix this. NOP _has_ a dependency on the > Gadget API if it calls Gadget API functions. Dependencies are proper. > > Maybe the reason for the problem is that we ended up adding far too much > code to phy-generic.c itself. Maybe it shouldn't know about clks and > interrupts. The original idea of that driver was to simply satisfy a > requirement to have a valid transceiver by some platforms. Maybe we > should fix that instead. Moving functions around to workaround a problem > is not the way to go, sorry. > OK but something that was working all these years is broken by your patch. Do you mind fixing it please? Or at least let me know how you want to get it fixed. cheers, -roger