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
Attachment:
signature.asc
Description: Digital signature
