hi, On Wed, Dec 14, 2011 at 01:02:09AM +0200, Felipe Contreras wrote: > On Wed, Dec 14, 2011 at 12:53 AM, Felipe Balbi wrote: > > On Tue, Dec 13, 2011 at 11:19:52PM +0200, Felipe Contreras wrote: > >> On Mon, Dec 12, 2011 at 9:09 AM, Jarkko Nikula wrote: > >> > Indeed yes. I checked that in 3.0 it still works but not in 3.1 so some > >> > non isp1704_charger change has broke it as there hasn't been changes on it. > >> > >> Actually it's broken in 3.0 as well, try this configuration: > >> > >>       # CONFIG_USB_MUSB_HOST is not set > >>       # CONFIG_USB_MUSB_PERIPHERAL is not set > >>       CONFIG_USB_MUSB_OTG=y > >>       CONFIG_USB_GADGET_MUSB_HDRC=y > >>       CONFIG_USB_MUSB_HDRC_HCD=y > >> > >>       CONFIG_USB_GADGET_SELECTED=y > >>       # CONFIG_USB_GADGET_FUSB300 is not set > >>       # CONFIG_USB_GADGET_OMAP is not set > >>       # CONFIG_USB_GADGET_R8A66597 is not set > >>       # CONFIG_USB_GADGET_PXA_U2O is not set > >>       # CONFIG_USB_GADGET_M66592 is not set > >>       # CONFIG_USB_GADGET_DUMMY_HCD is not set > >> > >> I will try to find where the issues started to happen, but it's a bit > >> difficult because all this USB Kconfig stuff is completely messed up. > >> > >> *Sigh* > > > > patches are welcome > > The were not last times: > http://mid.gmane.org/1288656853-4625-1-git-send-email-felipe.contreras@gmail.com At least [1] will not apply anymore. Most of that stuff has been cleaned up after I introduced the UDC class/core driver. There are still lots of things to fix up, but it won't happen overnight. Specially if people are more willing to complain than to patch. [2] Makes no sense whatsoever. I have been fighting a lot against these ARCH dependencies. It's generally used to hide some moronic constructs relying on or headers. Most of the time, it's just to be able to access e.g. machine_is_*, cpu_is_* or omap_ctrl_read* and the like. Also, the first step for having a single ARM zImage is to get rid of those ARCH dependencies; we need to be able to compile modules on all ARCHes (even x86 for that matter) because: a) it makes maintainer's lives easier (make allmodconfig/allyesconfig really help when applying patches) b) it helps using linux-next for compile tests better (similar as above) c) it makes it simpler to have a single zImage (from that particular driver's point of view, you can delete arch/arm/plat-omap/include/plat/*.h and nothing will change). So, if those are the only patches you can provide, please refrain from doing so as it will only take time reviewing. Instead, help really cleaning up the problems, make sure drivers compile on other ARCHes, make sure you don't include or on drivers, make sure you help reviewing patches which are coming in. > http://mid.gmane.org/1287482608-11320-1-git-send-email-felipe.contreras@gmail.com "No such article" > But I'll try again... Once I'm done with this endless bisect =/ please do, but follow the above. [1] http://article.gmane.org/gmane.linux.kernel/1056944 [2] http://article.gmane.org/gmane.linux.ports.arm.omap/45713 -- balbi