At Fri, 12 Jun 2015 01:23:18 +0300,
Mihai Donțu wrote:
>
> On Thu, 11 Jun 2015 07:01:13 +0200 Takashi Iwai wrote:
> > At Thu, 11 Jun 2015 01:12:36 +0300, Mihai Donțu wrote:
> > > On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote:
> > > > From: Takashi Iwai
> > > > Subject: [PATCH] ALSA: hda -
> - /* Reclaim above the high watermark. */
> - sc->nr_to_reclaim = max(SWAP_CLUSTER_MAX, high_wmark_pages(zone));
> + /* Aim to reclaim above all the zone high watermarks */
> + for (z = 0; z <= end_zone; z++) {
> + zone = pgdat->node_zones + end_zone;
s/end_zone/z/ ?
>
fixed all checkpatch.pl ERROR: do not use C99 // comments
Any C99 comments used to comment out code are simply removed.
Also some of the errors occur inside '#if 0' blocks which I
might as well fix since checkpatch.pl caught them but the blocks
themselves should probably be cleaned up later.
Sign
On Thu, Jun 11, 2015 at 02:45:57PM -0700, Paul E. McKenney wrote:
> Color me slow and stupid. Maybe due to reviewing a patch too early in
> the morning, who knows?
>
> There is nothing above that prevents the compiler and the CPU from
> reordering the assignments to X and Y with the increment of
Hello,
Cc += linux-kernel@vger.kernel.org, forgot that on submission.
On Fri, Jun 12, 2015 at 08:59:59AM +0200, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter
Le 10/06/2015 20:17, Rob Herring a écrit :
On Wed, Jun 10, 2015 at 10:12 AM, leroy christophe
wrote:
Le 06/06/2015 17:32, Rob Herring a écrit :
On Sat, Jun 6, 2015 at 6:20 AM, christophe leroy
wrote:
I've got a MPC8323 RDB evaluation platform from freescale
kernel 4.0 doesn't boot
kernel 3
* Andy Lutomirski wrote:
> > 1)
> >
> > So the first critical question is: if the ACPI/BIOS suspend code corrupts
> > the
> > kernel's DS, how can we get so far as to resume fully, return to
> > user-space,
> > and segfault there so that it can all be reported?
> >
> > So neither the explana
From: Arnaud Ebalard
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 170 +-
3 files changed,
Hello,
This patch series adds a new driver supporting Marvell's CESA IP.
This driver addresses some limitations of the existing one.
>From a performance and CPU load point of view the most important
limitation in the existing driver is the lack of DMA support, thus
preventing us from chaining cryp
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This commi
From: Arnaud Ebalard
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
driver
From: Arnaud Ebalard
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 147
3 file
Gen5 and Gen6 trackpad devices are able to detect and report object proximity
data/events, add this function support in the cyapa driver through the
MTB protocl ABS_MT_DISTANCE event.
TEST=test on Chromebook.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 19 -
drive
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff -
V0 patches mainly have following updates:
1) Add Gen6 trackpad device support;
2) Add report proximity data function support for Gen5 and Gen6 devices;
3) Fully support runtime suspend/resume power management;
4) Add of_match_table mechanism support.
This patch series is mainly amied to add new g
Add CYTP0002 name for Gen6 device for ACPI configuration
TEST=test on Chromebook.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 7e7613f..24302d6 100644
--- a/drivers/inp
Based on the cyapa core, add the gen6 trackpad device's basic functions
supported, so gen6 trackpad device can work with kernel input system.
And also based on the state parse interface, the cyapa driver can
automatically determine the attached is gen3, gen5 or gen6 protocol
trackpad device, then s
Add proximity and interrupt control interfaces in sysfs device node.
The proximity interface is used to disable/enable proximity function in device.
The interrupt interface is used to disbale/enable interrupt from device.
TEST=test on Chromebook.
Signed-off-by: Dudley Du
---
drivers/input/mouse/
Change strings 'gen5' to 'pip' for all macros, varibales and functions when
they are shared to be used in for gen5 and gen6 modules. The change of these
strings is aimed to keep name definition much more clear and readable.
TEST=test on Chromebook.
Signed-off-by: Dudley Du
---
drivers/input/mous
Add of_match_device machanism support for Cypress trackpad device, and
add the sample description document of adding the trackpad device node in DT.
TEST=test on Chromebook.
Signed-off-by: Dudley Du
---
.../devicetree/bindings/input/cypress,cyapa.txt| 44 ++
.../devicetre
Fix the the runtime suspend power management not working issue when system
starts up and before user touches the trackpad device.
TEST=test on Chromebook.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 79 +++-
drivers/input/mouse/cyapa.h
Start using pr_fmt and convert all remaining printk to use
pr_* family of macros.
Signed-off-by: Sudip Mukherjee
---
drivers/i2c/busses/i2c-parport.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-parport.c b/drivers/i2c/busses/
On Thu, Jun 11, 2015 at 03:14:34PM +0200, Sebastian Andrzej Siewior wrote:
> This was spotted by Fernando Lopez-Lezcano
> while he tried to compile a -RT kernel with this driver enabled.
> "make C=2" would also warn about this. This is is based on his patch.
>
> Reported-by: Fernando Lopez-Lezcan
This patch series changes the 32-bit time types (timespec/itimerspec) to
the 64-bit types (timespec64/itimerspec64), since 32-bit time types will
break in the year 2038 on 32bit systems.
This patch series introduces new methods with timespec64/itimerspec64 type,
and removes the old ones with times
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index e4dfee0..087370e 10064
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs.
Add a module parameter to choose whether these SoCs should be attached to
the new or the old driver.
The default policy is to keep attaching those IPs to the old driver if it
is enabled, until we decide the new CESA driver
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is
Add support for DES operations.
Signed-off-by: Boris Brezillon
Signed-off-by: Arnaud Ebalard
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not ret
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for exa
Ez az üzenet a rendszergazda üzenetközpont valamennyi tulajdonosa webmail
számlák. Jelenleg korszerűsítése a adatbázis-központ és figyelembe email.
Töröljük email segítségével webes e-mail fiókot, hogy nagyobb teret az új
számlákat. Ha még nem frissítette előtt ez az utolsó alkalom, hogy
csinálni.
On Dove platforms, the crypto engine requires a clock. Document this
clocks property in the mv_cesa bindings doc.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/crypto
* Linus Torvalds wrote:
> On Thu, Jun 11, 2015 at 1:37 PM, Linus Torvalds
> wrote:
> >
> > Don't use "for_each_process_thread(g, p)". You only care about each mm, and
> > threads all share the same mm, so just do
> >
> > for_each_process(p)
> >
> > instead of iterating over all threads too
From: Arnaud Ebalard
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 157 ++
3 files change
Hi Daniel,
2015-06-10 22:09 GMT+02:00 Daniel Thompson :
> This adds documentation of device tree bindings for the clock related
> portions of the STM32 RCC block.
>
> Signed-off-by: Daniel Thompson
> ---
> .../devicetree/bindings/clock/st,stm32-rcc.txt | 65
> ++
> 1 fil
On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler wrote:
> Am 11.06.2015 um 14:30 schrieb Linus Walleij:
>> Certainly it is possible to create deadlocks in this scenario, but the
>> scope is not to create an ubreakable system.
>
> IAnd what happens if you run into a deadlock? Do you print "you've
The itimerspec is not year 2038 safe on 32bit systems due to the
limitation of the struct timespec members. Introduce itimerspec64
which uses struct timespec64 instead and provide conversion
functions.
Signed-off-by: Baolin Wang
---
include/linux/time64.h | 35 +
On Tue, Jun 02, 2015 at 03:24:03PM -0700, Ben Zhang wrote:
> The get/put callbacks need the kcontrol pointer to get context
> information like snd_soc_codec and drvdata.
>
> Signed-off-by: Ben Zhang
I did have this change in my internal tree as well and is required, thanks
for sending, I need thi
On Thu, Jun 11, 2015 at 04:54:26PM +0100, David Woodhouse wrote:
> It looks like the original kdump patch set has basically now been
> rewritten. Perhaps the best thing to do is for Zhenhua to resubmit an
> updated and clean version rather than preserving that
> churn?
Yeah, you are right. The his
The current_kernel_time() is not year 2038 safe on 32bit systems
due to return timespec value. Introduce current_kernel_time64()
function which returns timespec64 value, also as a helper function
calling by current_kernel_time().
Signed-off-by: Baolin Wang
---
include/linux/timekeeping.h | 10
On Thu, Jun 11, 2015 at 07:36:05PM +0200, Frederic Weisbecker wrote:
> Restart the tick when necessary from the irq exit path. It makes nohz
> full more flexible and allow it to piggyback the tick restart on the
> scheduler IPI in the future instead of sending a dedicated IPI that
> often doubles t
On Wednesday 10 June 2015 20:38:30 Claudio Cappelli wrote:
> From: Claudio Cappelli
>
> Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
>
> Signed-off-by: Claudio Cappelli
> Suggested-by: Lars Melin
>
> ---
>
> drivers/usb/serial/option.c |1 +
> 1 file changed
On Thu, Jun 11, 2015 at 07:36:07PM +0200, Frederic Weisbecker wrote:
> +static void tick_nohz_full_update_dependencies(void)
> +{
> + struct tick_sched *ts = this_cpu_ptr(&tick_cpu_sched);
> +
> + if (!posix_cpu_timers_can_stop_tick(current))
> + ts->tick_needed |= TICK_NEEDED_P
John,
The description is just awful.
On Thu, Jun 11, 2015 at 03:54:56PM -0700, John Stultz wrote:
> Since the leapsecond is applied at tick-time, this
> means there is a small window of time at the start
> of a leap-second where we cross into the next second
> before applying the leap.
First you
On Fri, 2015-06-12 at 09:55 +0800, Koro Chen wrote:
> On Thu, 2015-06-11 at 09:03 +0200, Paul Bolle wrote:
> > (What does negating a bool twice do?)
> >
> Because bool actually can be unsigned char, although actually in this
> driver, the caller always passes "true" or "false" to this function.
b
On Fri, Jun 12, 2015 at 12:03:22PM +0800, Huang Rui wrote:
> > What's the purpose of the "enable" parameter?
> >
>
> Enable mwaitx timer. Should I add comments to explain the usage?
No, you should read your own patch, notice that the only usage site
provides a true, then realize its a redundant
Due to the security_settime() with timespec type is not year 2038
safe on 32bit systems. Introduce the security_settime64()
function with timespec64 type.
Change the settime() callback of security_list_options structure
argument with timespec64 type as a helper function wrapped by
security_settime
On Thu, Jun 11, 2015 at 11:07 PM, Ingo Molnar wrote:
>
> * Srinivas Pandruvada wrote:
>
>> Suspend to RAM process is returning to userspsace with DS set to KERNEL_DS
>> after resume, this cause general protection fault. [...]
>
> But s2ram has no influence on 'returning to user-space'. So unless
On 10/06/2015 at 17:21:57 +0200, Andrea Scian wrote :
> >I would return -EINVAL here because the result might still pass
> >rtc_valid_tm() but be outdated.
>
> At first look I agree with you, but a bit later they say:
>
> /* the clock can give out invalid datetime, but we cannot return
> * -EINV
Thanks Vaishali. I have added your patch to our local kernel git, and
will submit it within a following upstream shipment.
Regards, Ursula Braun
On Wed, 2015-06-10 at 16:22 +0530, Vaishali Thakkar wrote:
> In little endian cases, the macro htons unfolds to __swab16 which
> provides special case f
On Thu, Jun 11, 2015 at 06:49:34PM +0300, Daniel Baluta wrote:
> Because of the ABI confusion proximity value exposed by SX9500
> was inverted.
>
> Signed-off-by: Daniel Baluta
Reviewed-by: Vlad Dogaru
Sorry for causing the confusion, it was the only proximity sensor I had
encountered to date.
Due to the do_sys_settimeofday() with timespec type is not year 2038
safe on 32bit systems, and it should introduce the do_sys_settimeofday64()
function with timespec64 type to make it is ready for 2038 issue.
For removing the old do_sys_settimeofday() function with timespec type
conveniently in f
Add more reviewers
> -Original Message-
> From: Zhang, Dongxing
> Sent: Wednesday, June 10, 2015 3:21 PM
> To: gre...@linuxfoundation.org; pe...@hurleysoftware.com;
> a...@linux.intel.com
> Cc: linux-kernel@vger.kernel.org; Zhang, Dongxing; Wang, Xiaoming
> Subject: [PATCH] tty/vt: Fix the
These are new helper macros that convert between a user timespec/
itimerspec and a kernel timespec64/itimerspec64 structure.
When converting syscall functions, it need to deal with these conversions:
user timespec (32 bit), kernel timespec (32 bit)
user timespec (64 bit), kernel timespec (64 b
The timer_get() callback in struct k_clock is not year 2038 safe on
32bit systems.
To address this implement a new callback timer_get64() which uses
struct itimerspec64 along with a default implementation which is a
wrapper for the existing timer_get() callback. The default callback
is installed a
In order to reuse the very same logic for the year 2038 safe syscalls
which we need to introduce for 32bit systems, factor out the guts of
the 'timer_gettime' syscall.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions
The timer_set() callback in struct k_clock is not year 2038 safe on
32bit systems.
To address this implement a new callback timer_set64() which uses
struct itimerspec64 along with a default implementation which is a
wrapper for the existing timer_set() callback. The default callback
is installed a
In order to reuse the very same logic for the year 2038 safe syscalls
which we need to introduce for 32bit system, factor out the guts of
the 'timer_settime' syscall.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 41 ++---
1 file changed, 26 in
* Andy Lutomirski wrote:
> > --- a/arch/x86/kernel/acpi/wakeup_32.S
> > +++ b/arch/x86/kernel/acpi/wakeup_32.S
> > @@ -81,6 +81,10 @@ ENTRY(do_suspend_lowlevel)
> > jmp ret_point
> > .p2align 4,,7
> > ret_point:
> > + /* In case the BIOS corrupted DS, make the kernel c
In order to reuse the very same logic for the year 2038 safe syscalls
which we need to introduce for 32bit system, factor out the guts of
the 'clock_gettime' syscall.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(
In order to reuse the very same logic for the year 2038 safe syscalls
which we need to introduce for 32bit system, factor out the guts of
the 'clock_getres' syscall.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-
The clock_get() callback in struct k_clock is not year 2038 safe on
32bit systems.
To address this implement a new callback clock_get64() which uses
struct timespec64 along with a default implementation which is a
wrapper for the existing clock_get() callback. The default callback
is installed at
The clock_getres() callback in struct k_clock is not year 2038 safe on
32bit systems.
To address this implement a new callback clock_getres64() which uses
struct timespec64 along with a default implementation which is a
wrapper for the existing clock_getres() callback. The default callback
is inst
The clock_set() callback in struct k_clock is not year 2038 safe on
32bit systems.
To address this implement a new callback clock_set64() which uses
struct timespec64 along with a default implementation which is a
wrapper for the existing clock_set() callback. The default callback
is installed at
* Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang"
>
> This definition is used in APEI code when needing to map pages as
> uncached.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang
> ---
> arch/x86/include/asm/acpi.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --g
In order to reuse the very same logic for the year 2038 safe syscalls
which we need to introduce for 32bit system, factor out the guts of
the 'clock_settime' syscall.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
The timekeeping_clocktai() function is not year 2038 safe on 32bit
systems, change its implementation with using struct timespec64.
Signed-off-by: Baolin Wang
---
include/linux/timekeeping.h |4 ++--
kernel/time/posix-timers.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
d
On 11/06/2015 14:25, Takashi Iwai wrote:
At Thu, 11 Jun 2015 14:04:45 +0200,
Quentin Lambert wrote:
On 11/06/2015 12:02, Takashi Iwai wrote:
At Thu, 11 Jun 2015 10:03:38 +0200,
Quentin Lambert wrote:
The dev_attrs field of struct bus_type is going away, use dev_groups instead.
This convert
This patch adds Memory Bandwidth Monitoring events to the exitsing
intel_cqm pmu in the Linux Kernel.
Intel MBM builds on Cache Monitoring Technology (CMT) infrastructure
to allow monitoring of bandwidth from one level of the cache hierarchy
to the next - in this case focusing on the L3 cache, whi
The clock_getres()/clock_get()/clock_set()/timer_set()/timer_get()
callbacks in struct k_clock are not year 2038 safe on 32bit systems,
and it need convert to safe callbacks which use struct timespec64
or struct itimerspec64.
Signed-off-by: Baolin Wang
---
kernel/time/posix-timers.c | 94 +
The clock_getres()/clock_get()/clock_set()/timer_set()/timer_get()
callbacks in struct k_clock are not year 2038 safe on 32bit systems,
and it need convert to safe callbacks which use struct timespec64
or struct itimerspec64.
Signed-off-by: Baolin Wang
---
drivers/char/mmtimer.c | 36 +
>>> On 12.06.15 at 01:23, wrote:
> There are two usages on MTRRs:
> 1) MTRR entries set by firmware
> 2) MTRR entries set by OS drivers
>
> We can obsolete 2), but we have no control over 1). As UEFI firmwares
> also set this up, this usage will continue to stay. So, we should not
> get rid o
Migrate arm_global_timer driver to the new 'set-state' interface
provided by the clockevents core, the earlier 'set-mode' interface is
marked obsolete now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
Acked-by: Daniel Lezcano
Cc:
Hi Thomas/Daniel,
I have incorporated all the improvements Daniel suggested on V1 and so
here is V2.
The first patch allows set-state callbacks to be optional, otherwise it
leads to unnecessary noop callbacks for drivers which don't want to
implement them. Over that, these noop-callbacks result i
Its mandatory for the drivers to provide set_state_{oneshot|periodic}()
(only if related modes are supported) and set_state_shutdown() callbacks
today, if they are implementing the new set-state interface.
But this leads to unnecessary noop callbacks for drivers which don't
want to implement them.
Migrate bcm_kona driver to the new 'set-state' interface provided by
the clockevents core, the earlier 'set-mode' interface is marked
obsolete now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
Oneshot callback isn't required as it
Migrate cs5535 driver to the new 'set-state' interface provided by
the clockevents core, the earlier 'set-mode' interface is marked
obsolete now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
Acked-by: Daniel Lezcano
Cc: Andres Sa
Migrate em_sti driver to the new 'set-state' interface provided by
the clockevents core, the earlier 'set-mode' interface is marked
obsolete now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
NOTE: This also drops a special check:
Migrate bcm2835 driver to the new 'set-state' interface provided by
the clockevents core, the earlier 'set-mode' interface is marked
obsolete now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
We weren't doing anything in the ->set
The clock_getres()/clock_get()/clock_set()/timer_set()/timer_get()
callbacks in struct k_clock are not year 2038 safe on 32bit systems,
and it need convert to safe callbacks which use struct timespec64
or struct itimerspec64.
Signed-off-by: Baolin Wang
---
kernel/time/alarmtimer.c | 38 +++
On Fri, Jun 12, 2015 at 09:38:48AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 12, 2015 at 12:03:22PM +0800, Huang Rui wrote:
>
> > > What's the purpose of the "enable" parameter?
> > >
> >
> > Enable mwaitx timer. Should I add comments to explain the usage?
>
> No, you should read your own patc
Migrate arm_arch_timer driver to the new 'set-state' interface provided
by the clockevents core, the earlier 'set-mode' interface is marked
obsolete now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
Cc: Marc Zyngier
Signed-off-by
unreferenced object 0x8800bd132fe8 (size 256):
comm "Xorg", pid 1260, jiffies 4294901661 (age 660.504s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 e8 2f 13 bd 00 88 ff ff ./..
01 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
backtrace:
[]
* Linus Torvalds wrote:
> On Jun 12, 2015 00:23, "Ingo Molnar" wrote:
> >
> > We might make it so: but that would mean restricting certain clone_flags
> > variants - not sure that's possible with our current ABI usage?
>
> We already do that. You can't share signal info unless you share the m
The clock_getres()/clock_get()/clock_set()/timer_set()/timer_get()
callbacks in struct k_clock are not year 2038 safe on 32bit systems,
and it need convert to safe callbacks which use struct timespec64
or struct itimerspec64.
The clock_gettime()/clock_settime()/clock_getres()/timer_gettime()/
time
On 06/09/2015 02:01 AM, Lorenzo Pieralisi wrote:
When a PCI bus is scanned, upon PCI bridge detection the kernel
has to read the bridge registers to set-up its resources so that
the PCI resource hierarchy can be validated properly.
Most if not all architectures read PCI bridge registers in the
p
The conversion between struct timespec and jiffies is not year 2038
safe on 32bit systems. Introduce timespec64_to_jiffies() and
jiffies_to_timespec64() functions which use struct timespec64 to
make it ready for 2038 issue.
Signed-off-by: Baolin Wang
---
include/linux/jiffies.h | 21 ++
On 06/12/2015 12:27 AM, Scott Wood wrote:
> Dropping the upper bits of the size harms the ability to detect error
> scenarios where unmappably large -- but not power-of-two -- regions
> are requested to be mapped.
>
> However, this patch doesn't fix that. It just postpones the loss of
> the up
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 028c63b56795206464263fa3bc47094704c2a840:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
On Thu, Jun 04, 2015 at 09:02:49PM +0800, Xishi Qiu wrote:
> Add a new interface in path /proc/sys/vm/mirrorable. When set to 1, it means
> we should allocate mirrored memory for both user and kernel processes.
As Dave and Kamezawa-san commented, documentation is not enough, so please
add a sectio
On Fri, 2015-06-12 at 01:00 +0900, KOBAYASHI Yoshitake wrote:
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 5897d8d..050f0e9 100644
> +config MTD_NAND_BENAND
> + tristate
> + depends on MTD_NAND_BENAND_ENABLE
> + default MTD_NAND
> +
> +config MTD_NAND_BENA
The cputime_to_timespec() and timespec_to_cputime() functions are
not year 2038 safe on 32bit systems due to the struct timepsec will
overflow in 2038 year. Introduce cputime_to_timespec64() and
timespec64_to_cputime() functions which use struct timespec64,
as well as for arch/s390 and arch/powerpc
The clock_getres()/clock_get()/clock_set()/timer_set()/timer_get()
callbacks in struct k_clock are not year 2038 safe on 32bit systems,
and it need convert to safe callbacks which use struct timespec64
or struct itimerspec64.
Signed-off-by: Baolin Wang
---
kernel/time/posix-cpu-timers.c | 84 +
All of the k_clock users have been converted to the y2038 safe methods,
this patch removes the older methods with timepsec/itimerspec type,
as a result the k_clock structure is ready for the year 2038.
Signed-off-by: Baolin Wang
---
include/linux/posix-timers.h |9 -
kernel/time/posix-ti
>-Original Message-
>From: Suravee Suthikulpanit [mailto:suravee.suthikulpa...@amd.com]
>Sent: Wednesday, June 10, 2015 9:39 PM
>To: r...@rjwysocki.net; l...@kernel.org; catalin.mari...@arm.com;
>will.dea...@arm.com; thomas.lenda...@amd.com;
>herb...@gondor.apana.org.au; da...@davemloft.net
* Andrew Morton wrote:
> On Thu, 11 Jun 2015 16:07:10 +0200 Ingo Molnar wrote:
>
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -1592,6 +1592,22 @@ static struct task_struct *copy_process(unsigned
> > long clone_flags,
> > syscall_tracepoint_update(p);
> > write_unlock_irq(&ta
%es is used implicitly by string instructions.
On June 12, 2015 12:50:13 AM PDT, Ingo Molnar wrote:
>
>* Andy Lutomirski wrote:
>
>> > --- a/arch/x86/kernel/acpi/wakeup_32.S
>> > +++ b/arch/x86/kernel/acpi/wakeup_32.S
>> > @@ -81,6 +81,10 @@ ENTRY(do_suspend_lowlevel)
>> > jmp ret_po
* Boris Ostrovsky wrote:
> On 06/11/2015 10:07 AM, Ingo Molnar wrote:
>
> >diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> >index fb0a9dd1d6e4..e0bf90470d70 100644
> >--- a/arch/x86/mm/pgtable.c
> >+++ b/arch/x86/mm/pgtable.c
> >@@ -391,6 +391,63 @@ pgd_t *pgd_alloc(struct mm_struc
Hi Viresh,
On 06/12/2015 10:00 AM, Viresh Kumar wrote:
Migrate arm_global_timer driver to the new 'set-state' interface
provided by the clockevents core, the earlier 'set-mode' interface is
marked obsolete now.
This also enables us to implement callbacks for new states of clockevent
devices, fo
1 - 100 of 759 matches
Mail list logo
