lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 14 Dec 2011 21:31:01 +0200
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	balbi@...com
Cc:	Jarkko Nikula <jarkko.nikula@...mer.com>,
	Felipe Contreras <felipe.contreras@...ia.com>,
	linux-main <linux-kernel@...r.kernel.org>,
	Kalle Jokiniemi <kalle.jokiniemi@...ia.com>,
	Heikki Krogerus <heikki.krogerus@...ia.com>,
	Anton Vorontsov <cbouatmailru@...il.com>,
	Tony Lindgren <tony@...mide.com>, linux-omap@...r.kernel.org
Subject: Re: [PATCH 2/2] Revert "ARM: RX-51: Enable isp1704 power on/off"

On Wed, Dec 14, 2011 at 9:30 AM, Felipe Balbi <balbi@...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@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ