Re: [PATCH 2/2] Revert "ARM: RX-51: Enable isp1704 power on/off"

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3227 bytes --]

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 <balbi@ti.com> 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 <jarkko.nikula@bitmer.com> 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 <plat/*> or <mach/*> 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 <plat/*> or <mach/*> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]