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

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

[Felipe Contreras]

Should probably have CC'ed linux-omap.

On Mon, Dec 5, 2011 at 7:23 PM, Felipe Contreras
<felipe.contreras@nokia.com> wrote:
> From: Felipe Contreras <felipe.contreras@gmail.com>
>
> This reverts commit 10299e2e4e3ed3b16503d4e04edd48b33083f4e2.
>
> This seems to break USB networking stuff.
>
> Cc: Kalle Jokiniemi <kalle.jokiniemi@nokia.com>
> Cc: Heikki Krogerus <heikki.krogerus@nokia.com>
> Cc: Anton Vorontsov <cbouatmailru@gmail.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   27 +------------------------
>  1 files changed, 2 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index ba1aa07..9f8e4d2 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -23,7 +23,6 @@
>  #include <linux/gpio.h>
>  #include <linux/gpio_keys.h>
>  #include <linux/mmc/host.h>
> -#include <linux/power/isp1704_charger.h>
>
>  #include <plat/mcspi.h>
>  #include <plat/board.h>
> @@ -56,8 +55,6 @@
>  #define RX51_FMTX_IRQ                  53
>  #define RX51_LP5523_CHIP_EN_GPIO       41
>
> -#define RX51_USB_TRANSCEIVER_RST_GPIO  67
> -
>  /* list all spi devices here */
>  enum {
>        RX51_SPI_WL1251,
> @@ -174,30 +171,10 @@ static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
>        },
>  };
>
> -static void rx51_charger_set_power(bool on)
> -{
> -       gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
> -}
> -
> -static struct isp1704_charger_data rx51_charger_data = {
> -       .set_power      = rx51_charger_set_power,
> -};
> -
>  static struct platform_device rx51_charger_device = {
> -       .name   = "isp1704_charger",
> -       .dev    = {
> -               .platform_data = &rx51_charger_data,
> -       },
> +       .name = "isp1704_charger",
>  };
>
> -static void __init rx51_charger_init(void)
> -{
> -       WARN_ON(gpio_request_one(RX51_USB_TRANSCEIVER_RST_GPIO,
> -               GPIOF_OUT_INIT_LOW, "isp1704_reset"));
> -
> -       platform_device_register(&rx51_charger_device);
> -}
> -
>  #if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
>
>  #define RX51_GPIO_CAMERA_LENS_COVER    110
> @@ -1102,6 +1079,6 @@ void __init rx51_peripherals_init(void)
>        if (partition)
>                omap2_hsmmc_init(mmc);
>
> -       rx51_charger_init();
> +       platform_device_register(&rx51_charger_device);
>  }

-- 
Felipe Contreras

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

[Jarkko Nikula]

On 12/05/2011 07:31 PM, Felipe Contreras wrote:
> Should probably have CC'ed linux-omap.
>
> On Mon, Dec 5, 2011 at 7:23 PM, Felipe Contreras
> <felipe.contreras@nokia.com>  wrote:
>> From: Felipe Contreras<felipe.contreras@gmail.com>
>>
>> This reverts commit 10299e2e4e3ed3b16503d4e04edd48b33083f4e2.
>>
>> This seems to break USB networking stuff.
>>
I don't think revert is needed since CONFIG_CHARGER_ISP1704=y should 
make it working. Although I don't know do we really need to drive the 
ISP1704 into reset in board-rx51-peripherals.c? Would it be better to 
leave gpio state as it was set by the bootloader and let the driver to 
do reset sequence if needed?

http://marc.info/?l=linux-omap&m=130795363204884&w=2

-- 
Jarkko

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

[Felipe Contreras]

On Wed, Dec 7, 2011 at 1:46 PM, Jarkko Nikula <jarkko.nikula@bitmer.com> wrote:
> On 12/05/2011 07:31 PM, Felipe Contreras wrote:
>>
>> Should probably have CC'ed linux-omap.
>>
>> On Mon, Dec 5, 2011 at 7:23 PM, Felipe Contreras
>> <felipe.contreras@nokia.com>  wrote:
>>>
>>> From: Felipe Contreras<felipe.contreras@gmail.com>
>>>
>>> This reverts commit 10299e2e4e3ed3b16503d4e04edd48b33083f4e2.
>>>
>>> This seems to break USB networking stuff.
>>>
> I don't think revert is needed since CONFIG_CHARGER_ISP1704=y should make it
> working. Although I don't know do we really need to drive the ISP1704 into
> reset in board-rx51-peripherals.c? Would it be better to leave gpio state as
> it was set by the bootloader and let the driver to do reset sequence if
> needed?
>
> http://marc.info/?l=linux-omap&m=130795363204884&w=2

Nope, that's actually worst:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab001
Internal error: : 1028 [#1]
Modules linked in:
CPU: 0    Tainted: G        W     (3.2.0-rc4-n900+ #5)
PC is at musb_ulpi_write+0x18/0x70
LR is at isp1704_charger_probe+0x7c/0x354
pc : [<c0186188>]    lr : [<c022e720>]    psr: a0000013
sp : ce81df08  ip : ce843f80  fp : 00000000
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : c0345984  r6 : c032d988  r5 : c032d9c4  r4 : fa0ab076
r3 : fa0ab000  r2 : 000000aa  r1 : 00000016  r0 : 00000000
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000015
Process swapper (pid: 1, stack limit = 0xce81c2e8)
Stack: (0xce81df08 to 0xce81e000)
df00:                   cea76840 c022e720 c032d990 c032d9c4 c0345984 c0345984
df20: 00000000 c0168d48 c0168d30 c0167ba4 00000000 c032d990 c032d9c4 c0345984
df40: 00000000 c0167cc0 c0345984 00000000 c0167c60 c016741c ce806ef8 ce85fa70
df60: c0345984 cea768c0 c0343e10 c0166d88 c02a1768 c02a1768 00000074 c0345984
df80: c030ef3c c000e874 00000000 00000000 00000000 c01682c4 c031b15c c030ef3c
dfa0: c000e874 00000000 00000000 c0008560 0000005f 0000000d c031ae90 00003539
dfc0: 00000000 c031b15c c031ae90 c000e874 00000013 00000000 00000000 00000000
dfe0: 00000000 c02f9208 00000000 00000000 c02f9198 c000e874 00000000 00000000
[<c0186188>] (musb_ulpi_write+0x18/0x70) from [<c022e720>]
(isp1704_charger_probe+0x7c/0x354)
[<c022e720>] (isp1704_charger_probe+0x7c/0x354) from [<c0168d48>]
(platform_drv_probe+0x18/0x1c)
[<c0168d48>] (platform_drv_probe+0x18/0x1c) from [<c0167ba4>]
(driver_probe_device+0xc8/0x184)
[<c0167ba4>] (driver_probe_device+0xc8/0x184) from [<c0167cc0>]
(__driver_attach+0x60/0x84)
[<c0167cc0>] (__driver_attach+0x60/0x84) from [<c016741c>]
(bus_for_each_dev+0x44/0x74)
[<c016741c>] (bus_for_each_dev+0x44/0x74) from [<c0166d88>]
(bus_add_driver+0x9c/0x20c)
[<c0166d88>] (bus_add_driver+0x9c/0x20c) from [<c01682c4>]
(driver_register+0xa4/0x130)
[<c01682c4>] (driver_register+0xa4/0x130) from [<c0008560>]
(do_one_initcall+0x94/0x164)
[<c0008560>] (do_one_initcall+0x94/0x164) from [<c02f9208>]
(kernel_init+0x70/0x118)
[<c02f9208>] (kernel_init+0x70/0x118) from [<c000e874>]
(kernel_thread_exit+0x0/0x8)
Code: e6ef2072 e6ef1071 e2834076 e3a00000 (e5d3c001)
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:161 omap3_l3_app_irq+0xe8/0x12c()
In-band Error seen by MPU  at address 0
Modules linked in:
[<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c002f97c>]
(warn_slowpath_common+0x4c/0x64)
[<c002f97c>] (warn_slowpath_common+0x4c/0x64) from [<c002fa14>]
(warn_slowpath_fmt+0x2c/0x3c)
[<c002fa14>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0021d84>]
(omap3_l3_app_irq+0xe8/0x12c)
[<c0021d84>] (omap3_l3_app_irq+0xe8/0x12c) from [<c005a338>]
(handle_irq_event_percpu+0x28/0x174)
[<c005a338>] (handle_irq_event_percpu+0x28/0x174) from [<c005a4ac>]
(handle_irq_event+0x28/0x38)
[<c005a4ac>] (handle_irq_event+0x28/0x38) from [<c005c8c8>]
(handle_level_irq+0xb8/0xe0)
[<c005c8c8>] (handle_level_irq+0xb8/0xe0) from [<c0059fe8>]
(generic_handle_irq+0x28/0x30)
[<c0059fe8>] (generic_handle_irq+0x28/0x30) from [<c000e80c>]
(handle_IRQ+0x60/0x84)
[<c000e80c>] (handle_IRQ+0x60/0x84) from [<c000d4f4>] (__irq_svc+0x34/0x80)
[<c000d4f4>] (__irq_svc+0x34/0x80) from [<c002f8b0>] (oops_exit+0x0/0x18)
[<c002f8b0>] (oops_exit+0x0/0x18) from [<0000000b>] (0xb)
---[ end trace 1b75b31a2719ed1e ]---
---[ end trace 1b75b31a2719ed1f ]---
Kernel panic - not syncing: Attempted to kill init!
[<c0012aa4>] (unwind_backtrace+0x0/0xec) from [<c022ee84>] (panic+0x54/0x184)
[<c022ee84>] (panic+0x54/0x184) from [<c00327a4>] (do_exit+0x98/0x5bc)
[<c00327a4>] (do_exit+0x98/0x5bc) from [<c0011010>] (die+0x27c/0x2b8)
[<c0011010>] (die+0x27c/0x2b8) from [<c0008444>] (do_DataAbort+0x80/0x94)
[<c0008444>] (do_DataAbort+0x80/0x94) from [<c000d498>] (__dabt_svc+0x38/0x60)
Exception stack(0xce81dec0 to 0xce81df08)
dec0: 00000000 00000016 000000aa fa0ab000 fa0ab076 c032d9c4 c032d988 c0345984
dee0: 00000000 00000000 00000000 00000000 ce843f80 ce81df08 c022e720 c0186188
df00: a0000013 ffffffff
[<c000d498>] (__dabt_svc+0x38/0x60) from [<c0186188>]
(musb_ulpi_write+0x18/0x70)
[<c0186188>] (musb_ulpi_write+0x18/0x70) from [<c022e720>]
(isp1704_charger_probe+0x7c/0x354)
[<c022e720>] (isp1704_charger_probe+0x7c/0x354) from [<c0168d48>]
(platform_drv_probe+0x18/0x1c)
[<c0168d48>] (platform_drv_probe+0x18/0x1c) from [<c0167ba4>]
(driver_probe_device+0xc8/0x184)
[<c0167ba4>] (driver_probe_device+0xc8/0x184) from [<c0167cc0>]
(__driver_attach+0x60/0x84)
[<c0167cc0>] (__driver_attach+0x60/0x84) from [<c016741c>]
(bus_for_each_dev+0x44/0x74)
[<c016741c>] (bus_for_each_dev+0x44/0x74) from [<c0166d88>]
(bus_add_driver+0x9c/0x20c)
[<c0166d88>] (bus_add_driver+0x9c/0x20c) from [<c01682c4>]
(driver_register+0xa4/0x130)
[<c01682c4>] (driver_register+0xa4/0x130) from [<c0008560>]
(do_one_initcall+0x94/0x164)
[<c0008560>] (do_one_initcall+0x94/0x164) from [<c02f9208>]
(kernel_init+0x70/0x118)
[<c02f9208>] (kernel_init+0x70/0x118) from [<c000e874>]
(kernel_thread_exit+0x0/0x8)

-- 
Felipe Contreras

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

[Jarkko Nikula]

On 12/07/2011 08:42 PM, Felipe Contreras wrote:
> On Wed, Dec 7, 2011 at 1:46 PM, Jarkko Nikula <jarkko.nikula@bitmer.com> wrote:
>> On 12/05/2011 07:31 PM, Felipe Contreras wrote:
>>> Should probably have CC'ed linux-omap.
>>>
>>> On Mon, Dec 5, 2011 at 7:23 PM, Felipe Contreras
>>> <felipe.contreras@nokia.com>  wrote:
>>>> From: Felipe Contreras<felipe.contreras@gmail.com>
>>>>
>>>> This reverts commit 10299e2e4e3ed3b16503d4e04edd48b33083f4e2.
>>>>
>>>> This seems to break USB networking stuff.
>>>>
>> I don't think revert is needed since CONFIG_CHARGER_ISP1704=y should make it
>> working. Although I don't know do we really need to drive the ISP1704 into
>> reset in board-rx51-peripherals.c? Would it be better to leave gpio state as
>> it was set by the bootloader and let the driver to do reset sequence if
>> needed?
>>
>> http://marc.info/?l=linux-omap&m=130795363204884&w=2
> Nope, that's actually worst:
>
> Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab001
> Internal error: : 1028 [#1]
> Modules linked in:
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.

-- 
Jarkko

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

[Felipe Contreras]

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*

-- 
Felipe Contreras

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

[Felipe Balbi]

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

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

-- 
balbi

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

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

[Felipe Contreras]

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
http://mid.gmane.org/1287482608-11320-1-git-send-email-felipe.contreras@gmail.com

But I'll try again... Once I'm done with this endless bisect =/

Cheers.

-- 
Felipe Contreras

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

[Felipe Balbi]

[-- 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 --]

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

[Felipe Contreras]

On Wed, Dec 14, 2011 at 9:30 AM, Felipe Balbi <balbi@ti.com> wrote:
> 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:
>> > 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.

Yes, the situation is much better, but these patches still apply on
usb core, or at least the same concept. Anyway, I have the new trivial
patches, I'll send them soon.

> [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:

Read the patch carefully, it doesn't add any new dependencies, it just
shuffles them around, I already explained that. And the rest of the
stuff adds *defaults*, not dependencies, so you can still build in
x86.

> 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.

Some of these changes have already been ack'ed, I just need to split
them. The rest, I guess I have to push it upstairs to Linus so he can
say if it does make sense to make builds more difficult for the users,
and keep the size of the current defconfigs from decreasing.

>> http://mid.gmane.org/1287482608-11320-1-git-send-email-felipe.contreras@gmail.com
>
> "No such article"

It's there. Here's the direct link:
http://article.gmane.org/gmane.linux.kernel/1050608

-- 
Felipe Contreras