The size of struct snd_compr_avail is 0x1c in 32bit kernel,
while it is 0x20 in 64bit kernel 0x4 bytes added because of
alignment. It is OK when 32bit kernel met 32bit user space.
There exist stack corruption if 64bit kernel met 32bit user
space, because the size of struct snd_compr_avail is 0x1c
> > This is todays fresh git with 3.15.0-rc6-00190-g1ee1cea on V210, THP
> > enabled & always on. Got this and a segfault on apt-spawned xz.
>
> Thanks a lot for the report.
>
> I've been bogged down with other things but I will come back to
> this stuff soon.
Just to document a strangeness tha
On Mon, 2014-06-09 at 05:17 +0200, Mike Galbraith wrote:
> 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.
Making aio play by the rules is safe. Another option is to bend the
rules
From: Yang Wei
While loading g_mass_storage module, the following warning
is triggered.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[<800179cc>] (unwind_backtrace+0x0/0x104) fro
This patch add documentation for S2MPU02 PMIC device. S2MPU02 has a little
difference from S2MPS11/S2MPS14 PMIC and has LDO[1-28]/Buck[1-7].
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Randy
Add support for Samsung S2MPU02 PMIC device to the MFD sec-core driver.
The S2MPU02 device includes PMIC/RTC/Clock devices.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 19 +
drivers/mfd/sec-irq.c| 88 +++
This patch add Samsung S2MPU02 PMIC device driver in exiting S2MPS11 PMIC
driver because S2MPU02 has a little different between S2MPU02 and S2MPS1x.
The S2MPU02 PMIC has LDO[1-28] and BUCK[1-7] regulators.
This patchset had a dependency on regulator.git (Mark Brown) because following
patchset[1-4]
This patch add S2MPU02 regulator device to existing S2MPS11 device driver
because of little difference between S2MPS1x and S2MPU02. The S2MPU02
regulator device includes LDO[1-28] and BUCK[1-7].
Signed-off-by: Chanwoo Choi
[Add missing linear_min_sel of S2MPU02 LDO regulators by Jonghwa Lee]
Sign
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. You will get a big update to
Atmel touchscreen driver, devm suppo
commit 7b5a3522 (loop: Limit the number of requests in the bio list) limit
the request number in loop queue to not over 128. Make the number tunable
from sysfs can improve performance.
The following test is done on a machine with 512M memory. The backend of
/dev/loop1 is a nfs file.
[root@bijx mn
Hi Alan,
Sorry for my late response, as I was 000, Additionally, I am very
grateful for your review.
On 06/06/2014 02:08 AM, Alan Stern wrote:
On Wed, 4 Jun 2014 wei.y...@windriver.com wrote:
From: Yang Wei
While loading g_mass_storage module, the following warning is triggered.
WARNING:
On Mon, Jun 9, 2014 at 6:35 AM, Ming Lei wrote:
> 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, belo
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 descript
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 clo
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) co
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 wor
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 eve
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
> > > > implementati
'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 we
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 look
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 an
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 :00:07.0
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 bette
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 whi
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
> (http://www.spinics.net/
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
htt
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 maj
> 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 d
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
> inde
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-stac
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, whi
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 l
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 int
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 spinlock
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, info.initrd_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
> registe
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 users
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, speci
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. The
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 untested.
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 "prandom_u32_max(r
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 (e
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 leak
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:
> >> pytho
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 http://vg
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 a
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(&Buff[sigOffset], 0xFF, MAX_RW_S
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(-)
diff
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 be
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 drivers/gpu
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 inf
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 commen
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 4
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 signed
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 2
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, y
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 t
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
> identi
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 repo
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 in
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 servi
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 didn
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 ot
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
inde
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 ++
arch/arm/boot/dts/sun7i-a20-cu
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 b/arch/arm/boot/dts/sun7i-a20.dt
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 +
drivers
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 rac
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 Documentati
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 i
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 insertions(+),
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 fills
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 powe
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.
http://convert2web.com/staff
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, in
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 be
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 'go6
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 variabl
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 maint
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 --gi
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
--- a/drivers/staging/speakup/speakup
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(-)
1 - 100 of 142 matches
Mail list logo