linux-kernel - Re: [PATCH] usb: host: Allow EHCI_OMAP to be built-in when USB

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

Message-ID: <577525BF.3060509@ti.com>
Date:	Thu, 30 Jun 2016 16:59:27 +0300
From:	Roger Quadros <rogerq@...com>
To:	Felipe Balbi <balbi@...nel.org>
CC:	<stern@...land.harvard.edu>, <sre@...nel.org>,
	<peter.chen@....com>, <tony@...mide.com>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-omap@...r.kernel.org>
Subject: Re: [PATCH] usb: host: Allow EHCI_OMAP to be built-in when USB_GADGET
 is 'm'

Hi Felipe,

On 30/06/16 13:14, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq@...com> 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