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@xxxxxx> 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@xxxxxx> wrote:
>> > patches are welcome
>>
>> The were not last times:
>> http://mid.gmane.org/1288656853-4625-1-git-send-email-felipe.contreras@xxxxxxxxx
>
> 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@xxxxxxxxx
>
> "No such article"

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

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/