linux-kernel - Re: [PATCH] USB: ehci-omap: Select 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: <20130411182946.GA20264@arwen.pp.htv.fi>
Date:	Thu, 11 Apr 2013 21:29:46 +0300
From:	Felipe Balbi <balbi@...com>
To:	Alexander Holler <holler@...oftware.de>
CC:	Roger Quadros <rogerq@...com>, <balbi@...com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [PATCH] USB: ehci-omap: Select USB_PHY

Hi,

On Thu, Apr 11, 2013 at 07:33:32PM +0200, Alexander Holler wrote:
> >>Sorry, but this just will end up with many users having broken configs
> >>because of disabled stuff they don't know why they have to enable them.
> >>And thus with a never ending stream of questions and thus with a needed
> >>FAQ entry.
> >>
> >
> >Alexander,
> >
> >I agree with you that it can get difficult with users. But it is best for
> >users do not disable anything they are not familiar with.
> >
> >As the USB_PHY option doesn't depend on anything, it is safe to select it
> >from USB_EHCI_HCD_OMAP.
> >
> >However, the PHY drivers themselves must be selected from the board configs.
> 
> Maybe I understood something wrong, but if the OMAP USB driver
> requires CONFIG_USB_PHY (or similiar), it should be selected
> automatically and not just enabled in the board config.

and who said OMAP USB depends on CONFIG_USB_PHY ? Some platforms need to
control a PHY and some don't.

> I just had it to often, that I needed to search around why a driver
> doesn't work (or even compiles), just to find out that I need to
> enable some strange config option which wasn't selected
> automatically. Especially with OMAPs. ;)

so ? Send a patch fixing it, those are really welcome. You see, it's
very difficult to get all of this perfectly right and if people continue
to rant rather than fix, we will get nowhere.

> And this not only occured when disabling options, it often occured by
> just updating the kernel. Suddenly some obscur option was needed too,
> it wasn't selected automatically by make oldconfig, bang. So the
> argument to not remove anything from a board config doesn't help
> much.

blablabla, Kconfig changes are *always* necessary. Specially when we
need to re-design an entire API because the previous one was just a
*SINGLE* global pointer.

Go check out kernel 2.6.39 (maybe even 3.1 and 3.2) and you'll see that
we're much better off today where we can actually have multiple PHY
drivers and multiple UDC drivers enabled (either as modules or
built-in), but the fact is that changing all of this over takes time and
sometimes people make mistakes, but that's alright, since we have the
-rc series to catch those unwanted errors.

Without the help of the rest of the community, though, it'll just get
slower and slower. With the whole single zImage effort going on in the
ARM land, things have gotten much more critical WRT getting rid of
"selects" and turning legacy "drivers" into real drivers, not just a
bunch of exported functions which a single architecture uses.

Add to that all the rework going on in the Gadget Framework, PHY layer
and EHCI drivers (which now has a core re-usable library thanks to Alan
Stern) and you have a lot of work to do.

Next time you consider ranting about something, use that 'frustration'
and turn it into motivation to write patches, then we all win. Also
consider that under drivers/usb/ alone we have 270K LOCs, and that's
quite a lot of code to handle with only a few of us (Greg, Sarah, Alan,
Alex and myself) being the gateway towards mainline.

With all that comes the responsibility of revieweing drivers for
architectures we, most of the times, don't have access to with drivers
that only compile in some ceratin ways.

Cleaning all of that takes time. Look at all the effort it's taking the
Chipidea folks just to get rid of a couple copies of the chipidea
driver. It takes time, it takes sweat and we can all use some help
rather than some random rant.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)