[RFC PATCH 0/3] hw_random: support for delayed init randomness requests

2014-07-13 Thread Amit Shah
Hello, This series introduces a way to allow devices to contribute to initial system randomness after a certain delay. Specifically, the virtio-rng device can contribute initial randomness only after a successful probe(). A delayed workqueue item is queued in the system queue to fetch this

[RFC PATCH 1/3] hw_random: allow RNG devices to give early randomness after a delay

2014-07-13 Thread Amit Shah
Some RNG devices may not be ready to give early randomness at probe() time, and hence lose out on the opportunity to contribute to system randomness at boot- or device hotplug- time. This commit schedules a delayed work item for such devices, and fetches early randomness after a delay. Currently

[RFC PATCH 3/3] Revert "virtio: rng: ensure reads happen after successful probe"

2014-07-13 Thread Amit Shah
This reverts commit ceb5d72a2e27e95bc9570ce259c45b35f0e23462. This commit was added for -stable so systems with virtio-rng don't freeze at boot-time. With the addition of the previous commits that delay the request for initial randomness after probe() is successful, this is no longer needed.

[RFC PATCH 2/3] virtio: rng: only accept delayed early randomness requests

2014-07-13 Thread Amit Shah
hw_random core can ask for initial randomness after a slight delay after probe() finishes, and we can contribute to system randomness at that point. Tell the hw_random core by setting the HWRNG_DELAY_READ_AT_INIT flag. CC: Kees Cook CC: Jason Cooper CC: Herbert Xu Signed-off-by: Amit Shah

Re: [RFC 0/7] hrtimer: drop active hrtimer checks after adding it

2014-07-13 Thread Viresh Kumar
Hi Thomas, On 10 July 2014 07:04, Frederic Weisbecker wrote: > On Wed, Jul 09, 2014 at 11:30:41PM +0200, Thomas Gleixner wrote: >> On Wed, 9 Jul 2014, Viresh Kumar wrote: >> >> So your patch series drops active hrtimer checks after adding it, >> according to your subject line. >> >> Quite useeul

[PATCH V6] regulator: DA9211 : new regulator driver

2014-07-13 Thread James Ban
This is the driver for the Dialog DA9211 Multi-phase 12A DC-DC Buck Converter regulator. It communicates via an I2C bus to the device. Signed-off-by: James Ban --- This patch is relative to linux-next repository tag next-20140710. Changes in V6: - Removed an unnecessary log. Changes in V5: -

Re: [PATCHv8 2/2] mailbox: Introduce framework for mailbox

2014-07-13 Thread Jassi Brar
On 12 July 2014 03:39, Markus Mayer wrote: > On 11 July 2014 02:35, Jassi Brar wrote: >> Introduce common framework for client/protocol drivers and >> controller drivers of Inter-Processor-Communication (IPC). >> >> Client driver developers should have a look at >>

[PATCH] cpufreq: Fix latency for cpufreq_info

2014-07-13 Thread Nicholas Krause
This fixes the latency for the cpufreq policy to 1 million nanoseconds that calls the function pxa_cpu_init for the member of the structure called cpuinfo.transition_latency. Signed-off-by: Nicholas Krause --- drivers/cpufreq/pxa2xx-cpufreq.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCHv8 2/2] mailbox: Introduce framework for mailbox

2014-07-13 Thread Jassi Brar
On 11 July 2014 22:56, Arnd Bergmann wrote: > On Friday 11 July 2014, Jassi Brar wrote: >> + >> + This document aims to help developers write client and controller >> +drivers for the API. But before we start, let us note that the >> +client (especially) and controller drivers are likely going to

Re: [PATCH] ASoC: omap-dmic: Use devm_clk_get

2014-07-13 Thread Peter Ujfalusi
On 07/11/2014 07:14 AM, Himangi Saraogi wrote: > This patch introduces the use of managed interfaces like devm_clk_get > and does away with the clk_puts in the probe and remove functions. A > label is also done away with. Acked-by: Peter Ujfalusi > > Signed-off-by: Himangi Saraogi > --- >

Re: pull request: wireless-next 2014-07-11

2014-07-13 Thread David Miller
From: "John W. Linville" Date: Fri, 11 Jul 2014 16:06:50 -0400 > Please pull this batch of updates intended for the 3.17 stream... > > This is primarily a Bluetooth pull. Gustavo says: > > "A lot of patches to 3.17. The bulk of changes here are for LE support. > The 6loWPAN over Bluetooth now

[PATCH 1/1] driver/tty: Fix a warning in check_tty_count

2014-07-13 Thread Li, Zhen-Hua
When there are to many open/close on a tty device in the same time, there may be a warning like: Warning: dev (ttyS0) tty->count(4) != #fd's(3) in tty_release_dev That's because tty->count and files in tty->tty_files are not synchronized in time. So I add a lock to avoid this. Signed-off-by:

<    1   2   3   4   5   6