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]

Message-Id: <201405301815.10811@pali>
Date:	Fri, 30 May 2014 18:15:09 +0200
From:	Pali Rohár <pali.rohar@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Pavel Machek <pavel@....cz>, Marcel Holtmann <marcel@...tmann.org>,
	Miguel Oliveira <cmroliv@...il.com>, gulsah.1004@...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()

Hi Greg,

On Friday 30 May 2014 17:59:59 Greg KH wrote:
> 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?
> 

You can look at elinux wiki where is table how process is going:
http://elinux.org/N900

Also look at planed future list and its progress:
http://elinux.org/N900/Changelog

You can see that drivers are including step by step.

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

Just look how much time took to include my patch for radio-
bcm2048 (fm radio part of this chip) which fixing wrong overflow 
check. I sent it at the end of December and... yes it is still 
not included in linus tree. Now it is somethere in media tree and 
probably will be pulled in next merge window.

This means that it takes about half of year to include patches 
for these drivers.

So why now you want to very quickly remove this driver from 
staging but you did not wanted to take my above patch?

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)