linux-kernel - Re: staging/dream: add gpio and pmem support

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]

Message-ID: <20091028155116.GA1434@kroah.com>
Date:	Wed, 28 Oct 2009 08:51:16 -0700
From:	Greg KH <greg@...ah.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Arve Hj?nnev?g <arve@...roid.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Brian Swetland <swetland@...gle.com>
Subject: Re: staging/dream: add gpio and pmem support

On Wed, Oct 28, 2009 at 12:25:22AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > What is so wrong with wakelocks? They are just nops in this case.
> > 
> > Are they really?  Then why is the whole large file needed?
> 
> It is probably not, I went to "submit vendor code, then clean it up"
> mode. CONFIG_HAS_WAKELOCK should be disabled, so it basically stubs
> itself out.
> 
> > > 2) you submit it
> > 
> > Wait, it has to BUILD!  This code has never been able to be built.  Only
> > after I disabled it from the CONFIG_ANDROID have I noticed this, which
> > is my fault.  But it needs to get fixed, and taking a bunch of code in
> > addition to the mess we have now, seems like the wrong way to do it.
> 
> It seems to be the only reasonable way. gpio is used from all the
> other stuff, and removing it is not really an option.
> 
> > > Now, I see that wakelocks are show-stopper for merging into kernel
> > > proper, but what is the problem for staging? We merged drivers with
> > > OS_MEMORY_ALLOCATE(); wakelocks are just nops in this case.
> > > 
> > > Could we please clean this driver in-tree? (Wakelocks are already nops
> > > due to #ifdef magic, cleaning them incrementally is easy.)
> > 
> > With this patch, will it build properly?
> 
> Its certainly way closer to building... it builds for me, with
> something like below; platform devices really are initialized from
> board-* files and get passed parameters.

Ick.  This isn't ok, we can't take patches for staging stuff in files
outside of drivers/staging/

So for now, I've deleted the drivers/staging/dream/ directory from my
tree, which will get pushed for 2.6.33.  Please clean the code up and
get it into buildable shape and I will be glad to add the drivers back
into the staging directory at that time.

thanks,

greg k-h
--
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/