On Fri, 30 May 2014 14:50:06 -0700, Andi Kleen wrote:
> [v2: Review feedback addressed and some minor improvements]
> [v3: More review feedback addressed and handle test failures better.
> Ported to latest tip/core.]
> [v4: Addressed Namhyung's feedback]
> [v5: Rebase to latest tree. Minor
On Thu, Jun 05, 2014 at 05:48:37PM +0200, Antoine Ténart wrote:
> This series adds the support for the Marvell Berlin USB controllers,
> the USB PHYs and also adds a reset controller.
>
> The reset controller is used by the USB PHY driver and shares the
> existing chip controller node with the
Hi, Richard
Any comment about this patch?
thanks
On Tue, Jun 03, 2014 at 01:30:44PM +0800, Real Name wrote:
> From: Honggang Li
>
> The patch based on linux-next-2014-06-02.
>
> The old init_maps function does two things:
> 1) allocates and initializes one struct page array for bootmem
> 2)
On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote:
> Am 05.06.2014 06:15, schrieb Honggang Li:
> > arch/x86/um/checksum_32.S had been copy & paste from x86. When build
> > x86 uml, csum_partial_copy_generic_i386 mess up the exception table.
> > In fact, exception table dose not
When configuring event perf checked a wrong condition that user
specified both of freq (-F) and period (-c) or the event has no
default value. This worked because most of events don't have default
value and only tracepoint events have default of 1 (and it's not
desirable to change it for those
On 06/09/14 at 10:11am, Dave Young wrote:
> On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> > On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > > Previous patch provided the interface definition and this patch prvides
> > > >
'copy_prev_load' was recently added by commit: 18b46ab (cpufreq: governor: Be
friendly towards latency-sensitive bursty workloads).
It actually is a bit redundant as we also have 'prev_load' which can store any
integer value and can be used instead of 'copy_prev_load' by setting it to zero
when
On Wed, 4 Jun 2014 09:59:30 -0700, Andi Kleen wrote:
> I saw samples.
>
> Oh well we can just drop it. The only difference is that the
> event list cannot set a period then.
I tested with a downloaded event, and it does have samples. But the
frequency could not be changed even with your patch.
Hi Suman,
On Sun, Jun 8, 2014 at 12:51 PM, Suman Tripathi wrote:
> Hi Ming,
>
> I have attached the patches but it is not accepted by Tejun yet, So I will
> post another version.
OK, thanks.
Since Tejun didn't think it is a workable approach, I am not going test
the attachment, but I will
On Sat, Jun 7, 2014 at 12:39 AM, Greg KH wrote:
> On Fri, Jun 06, 2014 at 07:44:08PM +0900, Magnus Damm wrote:
>> staging: Emma Mobile USB driver and KZM9D board code V3
>>
>> [PATCH v3 01/05] staging: emxx_udc: Add Emma Mobile USB Gadget driver
>> [PATCH v3 02/05] staging: emxx_udc: I/O memory
On 8 June 2014 02:11, Srivatsa S. Bhat wrote:
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> + if (unlikely(wall_time > (2 * sampling_rate)) &&
> + j_cdbs->copy_prev_load) {
> +
Hi experts.
I think all the macros with CONFIG_ prefix are supposed to be
defined in Kconfig.
But I've been long wondering why there exists one exception:
CONFIG_SHELL.
Is there any historical, or special reason?
Is it good to rename it to KBUILD_SHELL or something else?
Best Regards
Masahiro
Hi Andi,
On Fri, 30 May 2014 14:50:08 -0700, Andi Kleen wrote:
> @@ -756,22 +816,31 @@ void print_pmu_events(const char *event_glob, bool
> name_only)
> (!is_cpu && strglobmatch(alias->name,
> event_glob
>
On Fri, Jun 6, 2014 at 8:20 PM, Matias Bjørling wrote:
> This converts the current NVMe driver to utilize the blk-mq layer.
Looks it can't be applied cleanly against 3.15-rc8 + Jens's for-linux
branch, when I fix the conflict manually, below failure is triggered:
[ 487.696057] nvme
Using an else following a break or return can unnecessarily
indent code blocks.
ie:
for (i = 0; i < 100; i++) {
int foo = bar();
if (foo < 1)
break;
else
usleep(1);
}
is generally
Sigh, adventures in "unable to mount root filesystem" currently underway.
Tested on a different computer without patches (half size, since it's
an older machine):
Writing 16 MiB:
16777216 bytes (17 MB) copied, 0.289169 s, 58.0 MB/s
16777216 bytes (17 MB) copied, 0.289378 s, 58.0 MB/s
Writing
On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote:
> Some PHY controllers may need to calibrate certain
> PHY settings after initialization of the controller and
> sometimes even after initializing the PHY-consumer too.
> Add support for the same in order to let consumers do so in need.
# RESEND and please ignore previous mail #
On 2014/06/08 20:58, Alexandre Courbot wrote:
> Interesting approach to a long-standing problem. I had my own
> embarrassing attempt at it (power sequences), and more recently Olof
> (CC'd) sent something related for the MMC bus
>
Linus Torvalds:
> So I ended up doing an rc8 because I was a bit worried about some
> last-minute dcache fixes, but it turns out that nobody seemed to even
> notice those. We did have other issues during the week, though, so it
:::
I am afraid there is a problem in dcache. Please read
On Mon, 2014-06-09 at 10:08 +0800, Lai Jiangshan wrote:
> Hi, rt-people
>
> I don't think it is the correct direction.
Yup, it's a band-aid, ergo RFC.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
> Summarizing that, time to feed in 32 MiB of zeros (from user-space):
>
> 0 concurrent reads: 0.356898 0.357693
> 1 concurrent read: 0.505941 0.509075(+42%)
> 2 concurrent reads: 0.662240 0.657055(+84%)
Er, wait a minute... I'm not sure which kernel (patched or unpatched)
I
On Fri, Jun 06, 2014 at 01:02:59PM +0200, Lothar Waßmann wrote:
>
> Signed-off-by: Lothar Waßmann
> ---
> arch/arm/boot/dts/imx6qdl.dtsi |2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
Shawn
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
>
On Sun, 2014-06-08 at 23:51 +0100, Ben Hutchings wrote:
> snprintf() returns the number of bytes that could have been written
> (excluding the null), not the actual number of bytes written. Given a
> long enough subsystem or device name, these functions will advance
> beyond the end of the
On Thu, Jun 5, 2014 at 12:22 PM, Santosh Shilimkar
wrote:
> Recently we introduced the generic device tree infrastructure for couple of
> DMA
> bus parameter, dma-ranges and dma-coherent. Update the documentation so that
> its useful for future users.
>
> The "dma-ranges" property is intended to
> Which writer are you worried about, specifically? A userspace write
> to /dev/random from rgnd?
Actually, the part I'm actually worried about is latency in
add_interrupt_randomness.
But I may have not understood how the locking works. There's a per-CPU
fast pool which isn't locked at all,
On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > Previous patch provided the interface definition and this patch prvides
> > > implementation of new syscall.
> > >
> > > Previously segment
On Thu, Jun 05, 2014 at 11:22:00AM -0400, Santosh Shilimkar wrote:
> Recently we introduced the generic device tree infrastructure for couple of
> DMA
> bus parameter, dma-ranges and dma-coherent. Update the documentation so that
> its useful for future users.
>
> The "dma-ranges" property is
Hi, rt-people
I don't think it is the correct direction.
Softirq (including local_bh_disable()) in RT kernel should be preemptible.
Fixing these problems via converting spinlock_t to raw_spinlock_t will
result that all spinlock_t used in RCU-callbacks are converted which
means almost the
On 06/06/14 at 04:04pm, Vivek Goyal wrote:
> On Fri, Jun 06, 2014 at 03:37:48PM +0800, Dave Young wrote:
> > On 06/05/14 at 11:01am, Vivek Goyal wrote:
> > > On Thu, Jun 05, 2014 at 04:31:34PM +0800, Dave Young wrote:
> > >
> > > [..]
> > > > > + ret = kexec_file_load(kernel_fd,
On 2014-06-06 16:37, Rickard Strandqvist wrote:
Address of local variable assigned to a function parameter
This was partly found using a static code analysis program called cppcheck.
I'd be surprised if this was a real bug, but I agree on principle, we
should not leak stack data. The code is
Hi Linus,
On Sun, Jun 8, 2014 at 10:56 AM, Linus Torvalds
wrote:
> On Wed, Jun 4, 2014 at 11:23 PM, Herbert Xu
> wrote:
>>
>> Here is the crypto update for 3.16:
>
> There's something odd going on with bfin_crc.h.
>
> You moved it in commit 52e6e543f2d8 ("crypto: bfin_crc - access crc
>
On Fri, Jun 06, 2014 at 11:21:27AM -0400, Steven Rostedt wrote:
> Date: Fri, 6 Jun 2014 11:21:27 -0400
> From: Steven Rostedt
> To: "Chen, Gong"
> Cc: "Luck, Tony" , Borislav Petkov ,
> "m.che...@samsung.com" ,
> "linux-a...@vger.kernel.org" , LKML
>
> Subject: Re: [PATCH 5/7 v6] trace, RAS:
From: Fan Wu
What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
calling pinctrl_select_state
2.Remove the HW disable operation in in pinmux_disable_setting function.
3.Remove the disable ops in struct pinmux_ops
4.Remove all the disable ops
On Sun, Jun 08, 2014 at 08:05:24PM -0400, George Spelvin wrote:
>
> The problem I started trying to solve is readers (entropy extractors)
> monopolizing the pool lock and stalling writers (entropy mixers), which
> are supposed to be fast and low overhead.
Which writer are you worried about,
On Sun, Jun 8, 2014 at 3:14 PM, Luiz Capitulino wrote:
> In short, I believe this is just dead code for the upstream kernel but this
> causes a bug for 2.6.32 based kernels.
>
> The setup_node_data() function is used to initialize NODE_DATA() for a node.
> It gets a node id and a memory range.
Seeing from the code, it is OK.
Reviewed-by: Tang Chen
Thanks.
On 06/07/2014 02:21 PM, Fabian Frederick wrote:
memblock_set_bottom_up is only called by
__init cmdline_parse_movable_node and __init numa_init.
Cc: Andrew Morton
Cc: Tang Chen
Signed-off-by: Fabian Frederick
---
This is
On Sat, Jun 7, 2014 at 4:18 PM, Dave Airlie wrote:
> cc'ing list
>
> On 8 June 2014 04:08, Howard Chu wrote:
>> On Asus NP56D, if you use vgaswitcheroo to turn off the discrete GPU, the
>> kernel starts spewing these messages endlessly, until /var/log partition
>> fills up:
>>
>> Jun 7 17:40:27
Daniel Borkmann wrote:
> On 06/08/2014 07:34 PM, Hannes Frederic Sowa wrote:
>> Please check this as it makes the code more complicated and I doubt it is
>> worth it.
>
> Agreed.
Just to clarify, the goal is to be able to replace "prandom_u32() %
range" all over the kernel with
I have a few assorted cleanups in-work, but I was thinking about the
following and it's led to some thinking about the (non-)usefulness
of the out[] buffer from _mix_pool_bytes.
The problem I started trying to solve is readers (entropy extractors)
monopolizing the pool lock and stalling writers
snprintf() returns the number of bytes that could have been written
(excluding the null), not the actual number of bytes written. Given a
long enough subsystem or device name, these functions will advance
beyond the end of the on-stack buffer in dev_vprintk_exit(), resulting
in an information
On Fri, 6 Jun 2014, Gu Zheng wrote:
> >> When running with the kernel(3.15-rc7+), the follow bug occurs:
> >> [ 9969.258987] BUG: sleeping function called from invalid context at
> >> kernel/locking/mutex.c:586
> >> [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name:
> >>
On Sun, 8 Jun 2014, Luiz Capitulino wrote:
> diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> index 4064aca..01b493e 100644
> --- a/arch/x86/include/asm/numa.h
> +++ b/arch/x86/include/asm/numa.h
> @@ -9,7 +9,6 @@
> #ifdef CONFIG_NUMA
>
> #define NR_NODE_MEMBLKS
Hi nice to meet you . I'm Ms Laura Roland from Switzerland, is a pleasure to
contact you today,please write me back . thanks from Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Tejun, Vivek,
I came across this crash when attempting to run the 'hello world'
example from the Getting Started section on the docker.io homepage.
Repro kernels:
(upstream linus) 3.15.0
(RHEL7 RC-2) 3.10.0-121.el7.x86_64
To reproduce, boot with slub_debug=FZPU and run the example.
%
In short, I believe this is just dead code for the upstream kernel but this
causes a bug for 2.6.32 based kernels.
The setup_node_data() function is used to initialize NODE_DATA() for a node.
It gets a node id and a memory range. The start address for the memory range
is rounded up to ZONE_ALIGN
Hi
I think someone missed the count sizeof type in memcpy.
I'm no expert on this code.
But I wonder if also the the next for loop wrong?
It will fill with 0XFF00 but it is
not a complete 0X you're looking for?
So something like:
memset([sigOffset], 0xFF, MAX_RW_SIZE
Array 'SigBuff' is filled incompletely.
Someone forget to multiply for the sizeof type.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/staging/bcm/nvm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On Sat, Jun 7, 2014 at 11:24 AM, Linus Torvalds
wrote:
>
> Comments? Mel, this code is mostly attributed to you, I'd like to hear
> what you think in particular.
In the meantime, I've removed the "nr_unqueued_dirty == nr_taken"
check for congestion_wait(), since I can't see how it can possibly
With a tree that is close to 3.15 final I'm regularly seeing the
following on my EeePC 900 when starting ioquake3:
[drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits
(expected 32768, found 0)
[ cut here ]
WARNING: CPU: 0 PID: 1594 at
From: "John W. Linville"
Date: Fri, 6 Jun 2014 12:05:58 -0400
> Please accept this batch of fixes intended for the 3.16 stream.
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
All devices supported by ina2xx are bidirectional and reports the
measured shunt voltage and power values as a signed 16 bit, but the
current driver implementation caches all registers as u16, leading to an
incorrect sign extension when reporting to the userspace in
ina2xx_get_value().
This patch
(Please do not top-post.)
On Sunday 08 June 2014 22:47:31 Rickard Strandqvist wrote:
> I found this error in some of the files. And after discussion with
> Larry Finger and Peter Wu, it was decided that all files with this if
> statement should change.
>
> But of course I should update the
This function is supposed to return true if the new load imbalance
is worse than the old one. It didn't. I can only hope brown paper
bags are in style.
Now things converge much better on both the 4 node and 8 node systems.
I am not sure why this did not seem to impact specjbb performance on
the
On Sun, Jun 8, 2014 at 9:30 PM, Guenter Roeck wrote:
> On Sun, Jun 08, 2014 at 01:16:00PM -0700, Guenter Roeck wrote:
>> On Sat, Jun 07, 2014 at 09:47:01PM +0100, Fabio Baltieri wrote:
>> > All devices supported by the ina2xx driver are bidirectional and reports
>> > the measured value as a
Thank you for your comments!
> Have you checked assembler output if this helps anything at all? Constant
> propagation in the compiler should be able to figure that out all by
> itself. The only places I use __builtin_constant_p today are where I
> also make use of inline assembler.
Yes, I did.
Hi
Quite right!
I found this error in some of the files. And after discussion with
Larry Finger and Peter Wu, it was decided that all files with this if
statement should change.
But of course I should update the comment to something more suitable.
Kind regards
Rickard Strandqvist
2014-06-08
On Sun, 8 Jun 2014, Rickard Strandqvist wrote:
> I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false
>
The test you're changing is '(X & ~0xfc) == 0x3' which is not always
false, so is (bt_msr & MSR_AP) == MSR_AP or (bt_msr & ~MSR_AP) == MSR_AP
correct? Either way,
On Sun, 8 Jun 2014, Rickard Strandqvist wrote:
> I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false
>
Where is the 0xfc that your converting?
> After pointing this out, Larry Finger informed what would be the correct one.
> '(X & 0x3) == 0x3'
>
This is already what
On Sun, Jun 08, 2014 at 01:16:00PM -0700, Guenter Roeck wrote:
> On Sat, Jun 07, 2014 at 09:47:01PM +0100, Fabio Baltieri wrote:
> > All devices supported by the ina2xx driver are bidirectional and reports
> > the measured value as a signed 16 bit, but the current driver
> > implementation caches
On Sun, Jun 8, 2014, at 5:40, George Spelvin wrote:
> > Seems fine by me, since it's random anyway archs might not care
> > about the *_le32, though this might yield additional work in some
> > cases I presume.
>
> If you think that's okay, sure. I kept it consistent to get byte-for-byte
>
On Sat, Jun 07, 2014 at 09:47:01PM +0100, Fabio Baltieri wrote:
> All devices supported by the ina2xx driver are bidirectional and reports
> the measured value as a signed 16 bit, but the current driver
> implementation caches the number as an u16, leading to an incorrect sign
> extension when
On 06/08/2014 07:34 PM, Hannes Frederic Sowa wrote:
...
Please check this as it makes the code more complicated and I doubt it is worth
it.
Agreed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 06/08/2014 02:42 PM, George Spelvin wrote:
Note, when you talk about efficiency here, this is called once every
40+ secs ... ;)
Agreed, in this case the code size saving (avoid a function call) is the
main benefit. And I prefer to avoid inefficiency on general priinciples,
if it's not
From: Sathish Kumar Balasubramaniam
This patch fixes a bug in the list of peripheral functions for the IPSR5 pin
mux configuration of the PFC (Pin Function Controller) of the Renesas R-Car H2
SoC (R8A7790). There should be exactly 8 values listed for the IP5_23_21
peripheral function which is
> On Jun 8, 2014, at 10:18, Sam Ravnborg wrote:
>
> I would say that tools/include/tools/* should be considered the baseline
> for programs running on the host.
> So therefore unconditionally adding -I$(srctree)/tools/include should then
> be OK.
>
>Sam
I think we should do this, but I
So I ended up doing an rc8 because I was a bit worried about some
last-minute dcache fixes, but it turns out that nobody seemed to even
notice those. We did have other issues during the week, though, so it
was just as well. The futex fixes and cleanups may stand out, but as
usual there's various
This patch adds pins for two IR controllers on A20
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
This patch enables two IR devices in dts:
- One IR device physically found on Cubieboard 2
- One IR device physically found on Cubietruck
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 6 ++
This patch adds records for two IR controllers on A20
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
This patch adds driver for sunxi IR controller.
It is based on Alexsey Shestacov's work based on the original driver
supplied by Allwinner.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile| 1 +
This patch introduces Consumer IR(CIR) support for sunxi boards.
This is based on Alexsey Shestacov's work based on the original driver
supplied by Allwinner.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
Changes since version 1:
- Fix timer memory leaks
- Fix
This patch adds documentation for Device-Tree bindings for sunxi IR
controller.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
.../devicetree/bindings/media/sunxi-ir.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
On Sun, Jun 8, 2014 at 9:53 PM, H. Peter Anvin wrote:
>
> This would point either to an iommu problem, or a problem in the driver
> where addresses somehow get truncated to 32 bits. Since this is a
> graphics driver it is extremely complex, and subtle problems could be
> buried somewhere inside
It looks like this patch is adding blank lines not parenthesis like the
subject says.
regards,
dan carpenter
On Sun, Jun 08, 2014 at 11:12:57PM +0900, Choi Gi-yong wrote:
> Signed-off-by: Choi Gi-yong
> ---
> drivers/staging/speakup/speakup_acntpc.c | 5 -
> 1 file changed, 4
On 06/06/2014 05:06 PM, Nikolay Amiantov wrote:
>
> I've played a bit with this theory in mind and found a very
> interesting thing -- when I reserve all memory upper than 4G with
> "memmap" kernel option ("memmap=99G$0x1"), everything works!
> Also, I've written a small utility that
On 06/08/2014 02:45 AM, Ingo Molnar wrote:
>
> * Sitsofe Wheeler wrote:
>
>> Hi,
>>
>> The latest kernel (c593e8978722f7f4a12932733cfeed6c0c74fbaa) refuses to
>> boot on my EeePC - after grub is finished the screen just remains black
>> and the only thing that does something is pressing the
Attention User;
Your email Quota is almost exceeded. Starting from June 8th, we are migrating
to new email interface. So we are currently doing a maintenance on our server.
Please, click the link below to Enter and update your account and avoid losing
your inbox.
On Sun, Jun 8, 2014 at 4:40 AM, Pavel Machek wrote:
>
> When you proposed to put wait queues into task_struct, you were
> probably looking for less coding and more analysis?
I'm ok with coding, I find your particular patch horrible.
You add a dynamic allocator that will work *horribly* badly if
On Sat, Jun 7, 2014, at 1:28, George Spelvin wrote:
> diff --git a/include/linux/random.h b/include/linux/random.h
> index 57fbbffd..e1f3ec9a 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -47,11 +47,23 @@ void prandom_bytes_state(struct rnd_state *state, void
> *buf,
On Sun, Jun 8, 2014 at 8:19 AM, Bjorn Helgaas wrote:
> [+cc linux-pci, linux-pm]
>
>
> I don't know what ACPI methods you're calling, but (as I'm sure you
> know) it's not guaranteed to be safe to call random methods because
> they can make arbitrary changes to the system.
Yes, I've tested this
On Fri, Jun 06, 2014 at 02:07:11PM -0700, H. Peter Anvin wrote:
> On 06/06/2014 02:00 PM, Andrew Morton wrote:
> > On Wed, 4 Jun 2014 15:35:42 -0700 "H. Peter Anvin"
> > wrote:
> >
> >> Vdso cleanups and improvements largely from Andy Lutomirski.
> >
> > arch/x86/vdso/vdso2c.h: In function
Hi Chris
So uint max was a better default value.
Yeah, good it came into use. The main thing that the code got a proper review :)
Kind regards
Rickard Strandqvist
2014-06-08 3:41 GMT+02:00 Chris Metcalf :
> On 5/31/2014 7:00 PM, Rickard Strandqvist wrote:
>>
>> There is a risk that the
A single escaped constant char is not a complex macro.
Signed-off-by: Joe Perches
---
On Sun, 2014-06-08 at 23:12 +0900, Choi Gi-yong wrote:
> diff --git a/drivers/staging/speakup/speakup_acntpc.c
> b/drivers/staging/speakup/speakup_acntpc.c
[]
> @@ -35,7 +35,7 @@
[]
> -#define PROCSPEECH '\r'
On 06/08/2014 05:43 AM, Peter Wu wrote:
On Sunday 08 June 2014 12:36:11 Rickard Strandqvist wrote:
Then we use MSR_MASK instead, new patch then. But I will wait a day?
Or what is long enough to be sure that nobody else have any
objections? How is this usually resolved?
Well, Larry is the
CONFIG_REGULATOR_AB8500_DEBUG is always not defined.
ab8500_regulator_debug_init() is not called at all now,
ab8500_regulator_debug_exit() simply return 0, thus remove them.
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c | 13 -
include/linux/regulator/ab8500.h | 14
Now this is a DT-only driver because non-devicetree probe path is removed,
so merge ab8500_regulator_of_probe() into ab8500_regulator_probe().
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff
Signed-off-by: Choi Gi-yong
---
drivers/staging/speakup/speakup_acntpc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/speakup/speakup_acntpc.c
b/drivers/staging/speakup/speakup_acntpc.c
index 31f952b..f70b698 100644
---
Signed-off-by: navin patidar
---
V2:
Restore sequence of source code compilation, sequence was changed by v1
of this patch.
drivers/staging/rtl8188eu/core/rtw_br_ext.c| 61
drivers/staging/rtl8188eu/include/recv_osdep.h |1 -
2 files changed, 62 deletions(-)
On 06/06, Paul E. McKenney wrote:
>
> On Tue, Jun 03, 2014 at 10:01:25PM +0200, Oleg Nesterov wrote:
> >
> > I'll try to recheck rt_mutex_unlock() tomorrow. _Perhaps_ rcu_read_unlock()
> > should be shifted from lock_task_sighand() to unlock_task_sighand() to
> > ensure that rt_mutex_unlock() does
On Sun, Jun 8, 2014 at 10:09 AM, Houcheng Lin wrote:
> The Problem
> ---
> The reset signal on a hardware board is send either:
> - during machine initialization
> - during bus master's initialization
>
> In some hardware design, devices on bus need a non-standard and extra reset
> Note, when you talk about efficiency here, this is called once every
> 40+ secs ... ;)
Agreed, in this case the code size saving (avoid a function call) is the
main benefit. And I prefer to avoid inefficiency on general priinciples,
if it's not serving some other goal.
--
To unsubscribe from
> Seems fine by me, since it's random anyway archs might not care
> about the *_le32, though this might yield additional work in some
> cases I presume.
If you think that's okay, sure. I kept it consistent to get byte-for-byte
identical results.
If variations in that are allowed, that can also
On 06/08/2014 01:30 PM, George Spelvin wrote:
Fine by me this cleanup, although not strictly needed.
Agreed. The timer slack is set to HZ (1 second) anyway.
It just dawned on me that a simpler and more efficient way to do this
(which I'll do in v2 of this) would be:
Note, when you talk
>> #ifdef CONFIG_RANDOM32_SELFTEST
>> static void __init prandom_state_selftest(void);
>> +#else
>> +#define prandom_state_selftest() (void)0
> Fine by me. I think you can remove this '(void)0' here, though.
That's the standard way to write a no-op statement in C.
I seem to recall there's a
On 06/07/2014 10:25 AM, George Spelvin wrote:
The functions exist for a reason; the manual byte-at-a-time code
is unnecessarily slow (and bloated).
Signed-off-by: George Spelvin
Seems fine by me, since it's random anyway archs might not care
about the *_le32, though this might yield
Thank you for your time and attention on all these comments.
> Fine by me although we simply resembled initialization code from
> GSL here. I think that your subject line is a bit misleading though.
Yes, I had a hard time coming up with a good summary. I'm removing
*static* calls but not
On 06/07/2014 10:22 AM, George Spelvin wrote:
The preferred Linux style for optional features is to define
no-op stub functions rather than wrap each call site in #ifdef.
Signed-off-by: George Spelvin
---
lib/random32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Thu, Jun 5, 2014 at 3:22 AM, abdoulaye berthe wrote:
> This avoids handling gpiochip remove error in device
> remove handler.
>
> Signed-off-by: abdoulaye berthe
> ---
> drivers/gpio/gpiolib.c | 24 +++-
> include/linux/gpio/driver.h | 2 +-
> 2 files changed, 8
On 06/07/2014 10:20 AM, George Spelvin wrote:
Unrolling code in single-use code paths is just silly. There are two
instances:
1) prandom_warmup() calls 10 times.
2) prandom_state_selftest() can avoid one call and simplify the
loop logic by repeating an assignment to a local variable
On 06/07/2014 10:19 AM, George Spelvin wrote:
So it can be thrown away along with the code that uses it.
Signed-off-by: George Spelvin
Fine by me.
Acked-by: Daniel Borkmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
1 - 100 of 264 matches
Mail list logo
