linux-kernel - Re: [PATCH] staging: nokia_h4: nokia_core.c: use usleep

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:	Fri, 30 May 2014 08:59:59 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Pavel Machek <pavel@....cz>
Cc:	Marcel Holtmann <marcel@...tmann.org>,
	Miguel Oliveira <cmroliv@...il.com>, gulsah.1004@...il.com,
	Pali Rohár <pali.rohar@...il.com>,
	peter.p.waskiewicz.jr@...el.com, kristina.martsenko@...il.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: nokia_h4: nokia_core.c: use usleep_range()
 instead of msleep()

On Fri, May 30, 2014 at 02:30:23PM +0200, Pavel Machek wrote:
> Hi!
> 
> > >> Creating this patch for the Eudyptula Challenge.
> > >> Replaced msleep() for a delay < 20ms with a usleep_range() between 10000us and 15000us.
> > >> Also inserted a blank line after adeclaration.
> > > 
> > > So you are changing timings without testing. Plus, burning CPU power
> > > instead of sleeping.
> > > 
> > > Seems you'll need another patch for the challenge :-).
> > 
> > I actually wonder if anybody is seriously working on this driver. My concern with the staging drivers has always been that we are quick with merging them when the work on getting them into upstream shape is actually hard. However reality is once they are in staging nobody is doing the work to clean them up and fix the issues.
> >
> 
> There is active work on merging n900 changes.

Really?  Where?

> And no, it does not progress as quickly as I'd like, but we'll get
> there. It is also requirement for n900 FM radio receiving...
> 
> > Greg, instead of wasting our time with this, can we just remove this driver from staging.
> 
> Please don't.

As there has not been any real work on it since it has been merged, I
don't see why I shouldn't remove it.  If you do get some work done on
it, you can always revert the removal and continue on.  But the
existance of code in staging that is not progressing forward at all is
something that I don't like at all, and will be doing a large sweep of
soon to remove.

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/