On Fri, Jan 24, 2014 at 11:11:29AM -0800, Jens Axboe wrote:
> It is pretty much the same. I don't like the semantics of the old one,
> where it's 0/1/2 for off/on/different-on, though. Seems like now would
> be a good time to clean it up.
I don't think arbitrarily breaking this fairly widely used
* Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
> > On 01/26/2014 10:49 PM, Richard Weinberger wrote:
> > >>
> > >> No, because that information is available to user space unless we panic.
> > >
> > > Didn't you mean non-root?
> > > I thought one has to set dmesg_restrict anyways if kASLR
On Sun, Jan 26, 2014 at 08:32:09PM -0800, Linus Torvalds wrote:
> On Sun, Jan 26, 2014 at 4:22 PM, Al Viro wrote:
> >
> > Umm... Can't uprobe_notify_resume() modify regs as well?
>
> Probably.
>
> .. and on the other hand, we should actually be able to use 'sysret'
> for signal handling on x86-
* H. Peter Anvin wrote:
> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
> >>
> >> No, because that information is available to user space unless we panic.
> >
> > Didn't you mean non-root?
> > I thought one has to set dmesg_restrict anyways if kASLR is used.
> >
> > And isn't the offset av
Am 27.01.2014 07:52, schrieb H. Peter Anvin:
> Of course, stack traces themselves contain that information, so one
> could argue that oops=panic is required in order for kASLR to provide
> any kind of security against root. (oops=panic is probably a good idea
> in secure environments anyway...)
N
Call netif_carrier_on() after register_device(). Otherwise it won't work since
the device was still in NETREG_UNINITIALIZED state.
Fixes a68f9614614749727286f675d15f1e09d13cb54a
(hyperv: Fix race between probe and open calls)
Cc: Haiyang Zhang
Cc: K. Y. Srinivasan
Reported-by: Di Nie
Tested-by
Hi
Thank you for review.
On Mon, Jan 27, 2014 at 5:16 AM, Dmitry Eremin-Solenikov
wrote:
> On Mon, Jan 27, 2014 at 3:14 AM, Dmitry Torokhov
> wrote:
>> On Mon, Jan 27, 2014 at 02:31:59AM +0400, Dmitry Eremin-Solenikov wrote:
>>> On Mon, Jan 27, 2014 at 1:49 AM, Tomasz Figa wrote:
>>> > On 26.0
On 01/24/2014 06:31 AM, Dave Jones wrote:
On Thu, Jan 23, 2014 at 01:58:24AM -0500, Dave Jones wrote:
> 128 bytes is a pretty small amount of stack though, so I'm just as confused
> as to what the actual bug here is.
>
> After trying the proposed fix, I got another oops in the earl
* H. Peter Anvin wrote:
> I strongly disagree with putting variables in file scope when
> function scope will do, [...]
Yes, you are right that single-use file scope statics 'could' be moved
function local and are syntactically superior because in that case
other functions cannot make use of
Dear Thomas,
could you please comment John's question (see bellow) regarding flags.
On 01/21/2014 11:12 PM, John Stultz wrote:
On 01/13/2014 02:43 AM, Alexey Perevalov wrote:
Hello dear community.
This is reworked patch set of original Anton's Vorontsov
proposal regarding unified deferrable ti
On 01/27/2014 07:55 AM, Bo Shen wrote:
> When SSC works in slave mode, according to the hardware design, the
> clock can get from TK pin, also can get from RK pin. So, add one
> parameter to choose where the clock from.
>
> Signed-off-by: Bo Shen
> ---
> Changes in v2: None
>
> sound/soc/atmel/
2014-01-16 Barry Song <21cn...@gmail.com>:
>
>> From: Linus Walleij [linus.wall...@linaro.org]
>> Sent: Wednesday, January 15, 2014 17:10
>> To: linux-kernel@vger.kernel.org; Barry Song
>> Cc: linux-g...@vger.kernel.org; Linus Walleij
>> Subject: [PATCH] pinctrl: sirf: lock IRQs when starting them
Make it available to choose the clock from TK pin or RK pin. This
is hardware design decided.
Signed-off-by: Bo Shen
---
Changes in v2: None
sound/soc/atmel/atmel_wm8904.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/sound/soc/atmel/atmel_wm8904.c b/sound/soc/atmel/atmel_wm89
When SSC works in slave mode, according to the hardware design, the
clock can get from TK pin, also can get from RK pin. So, add one
parameter to choose where the clock from.
Signed-off-by: Bo Shen
---
Changes in v2: None
sound/soc/atmel/atmel_ssc_dai.c | 16
sound/soc/atmel/at
Add the option to choose clock on which pin input to SSC (as slave).
Default is on TK pin to SSC, add "atmel,clk-from-rk-pin" option to
specify the clock is on RK pin to SSC.
Signed-off-by: Bo Shen
---
Changes in v2:
- using "-" replace "_" in binding document
Documentation/devicetree/binding
When SSC work in slave mode, the clock can come from TK pin and also
can come from RK pin, this is hardware design decided. So, make it
available to choose where the clock from.
Changes in v2:
- using "-" replace "_" in binding document
Bo Shen (3):
ASoC: atmel_ssc_dai: make option to choose
On Mon, Jan 27, 2014 at 12:32:36AM +, Raghu Gandham wrote:
> Hi Dmitry,
>
> >
> > On Sat, Jan 25, 2014 at 11:01:54AM -0800, Raghu Gandham wrote:
> > > The standard IO regions are already reserved by the platform code on
> > > most MIPS devices(malta, cobalt, sni). The Commit
> > > 197a1e96c8
Hi Alexey,
On Mon, Jan 27, 2014 at 10:31:36AM +0400, Alexey Khoroshilov wrote:
> On 21.01.2014 23:59, Dmitry Torokhov wrote:
> > On Sun, Jan 19, 2014 at 03:24:26AM +0400, Alexey Khoroshilov wrote:
> >> There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
> >> anywhere in the drive
Of course, stack traces themselves contain that information, so one
could argue that oops=panic is required in order for kASLR to provide
any kind of security against root. (oops=panic is probably a good idea
in secure environments anyway...)
-hpa
--
To unsubscribe from this list: send t
On 01/26/2014 10:49 PM, Richard Weinberger wrote:
>>
>> No, because that information is available to user space unless we panic.
>
> Didn't you mean non-root?
> I thought one has to set dmesg_restrict anyways if kASLR is used.
>
> And isn't the offset available to perf too?
> Of course only for r
On Mon, Jan 27, 2014 at 6:33 AM, H. Peter Anvin wrote:
> On 01/26/2014 02:16 AM, Richard Weinberger wrote:
>>
>> Currently we print the kernel offset only upon a panic() using the
>> panic notifier list.
>> This way it does not show up if the kernel hits a BUG() in process
>> context or something
From: Geert Uytterhoeven
Date: Sun, 26 Jan 2014 11:44:23 +0100
> drivers/net/ethernet/8390/apne.c: In function ‘apne_probe1’:
> drivers/net/ethernet/8390/apne.c:215: warning: unused variable ‘ei_local’
>
> Introduced by commit c45f812f0280c13f1b7992be5e0de512312a9e8f ("8390 :
> Replace ei_debug
Commit b981513f806d (ACPI / scan: bail out early if failed to parse
APIC ID for CPU) emits an error message if ACPI processor driver fails
to query APIC ID for the CPU.
Originally it's designed to catch BIOS bugs for CPU hot-addition. But
it accidently reveals another type of BIOS bug that:
1) BIO
On 21.01.2014 23:59, Dmitry Torokhov wrote:
> On Sun, Jan 19, 2014 at 03:24:26AM +0400, Alexey Khoroshilov wrote:
>> There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
>> anywhere in the driver.
>>
>> The patch adds usb_get_dev() to failure handling code of gtco_probe()
>> and to
As everyone should know by now, we want to integrate the cpuidle
governor with the scheduler for a more efficient idling of CPUs.
In order to help the transition, this small patch series moves the
existing interaction with cpuidle from architecture code to generic
core code. No functional change s
... so we can get rid of it entirely.
Signed-off-by: Nicolas Pitre
---
include/linux/cpu.h | 1 -
kernel/cpu/idle.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 03e235ad1b..218fab7521 100644
--- a/include/linux/cpu.h
+++ b/include/linux/
ARM and ARM64 are the only two architectures implementing
arch_cpu_idle_prepare() simply to call local_fiq_enable().
We have secondary_start_kernel() already calling local_fiq_enable() and
this is done a second time in arch_cpu_idle_prepare() in that case. And
enabling FIQs has nothing to do with
In order to integrate cpuidle with the scheduler, we must have a better
proximity in the core code with what cpuidle is doing and not delegate
such interaction to arch code.
Architectures implementing arch_cpu_idle() should simply enter
a cheap idle mode in the absence of a proper cpuidle driver.
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre
---
arch/arm/kernel/process.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 725b8c95e0..34a59b7614 100644
--- a/arch/arm/kerne
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre
---
arch/sh/kernel/idle.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
index 2ea4483fd7..be616ee0cf 100644
--- a/arch/sh/kernel/idle.c
+++ b/arch/sh/kerne
ARM and ARM64 are the only two architectures implementing
arch_cpu_idle_prepare() simply to call local_fiq_enable().
We have secondary_start_kernel() already calling local_fiq_enable() and
this is done a second time in arch_cpu_idle_prepare() in that case. And
enabling FIQs has nothing to do with
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre
---
arch/x86/kernel/process.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95ab8..4505e2a950 100644
--- a/arch/x86/kernel/process.c
++
The core idle loop now takes care of it. However a few things need
checking:
- Invocation of cpuidle_idle_call() in pseries_lpar_idle() happened
through arch_cpu_idle() and was therefore always preceded by a call
to ppc64_runlatch_off(). To preserve this property now that
cpuidle_idle_call
Integration of cpuidle with the scheduler requires that the idle loop be
closely integrated with the scheduler proper. Moving cpu/idle.c into the
sched directory will allow for a smoother integration, and eliminate a
subdirectory which contained only one source file.
Signed-off-by: Nicolas Pitre
On Thu, 23 Jan 2014 17:22:48 +0100, Jiri Olsa wrote:
> On Thu, Jan 23, 2014 at 09:13:44AM +0900, Namhyung Kim wrote:
>>
>> $ perf report --no-call-graph --children --stdio
>>
>> # Self Children Command Shared Object Symbol
>> # ... ...
Catalin,
On 01/23/2014 11:53 PM, Catalin Marinas wrote:
On Fri, Jan 17, 2014 at 08:13:18AM +, AKASHI Takahiro wrote:
generic compat sycall audit (lib/compat_audit.c) requires unistd_32.h
for __NR_xyx compat syscall numbers. This is a different file from unistd32.h
on arm64 and so it must be
From: Barry Song
For users of hibernation, people care more about the size of the compressed
image than uncompressed one. as embedded guys will try to improve the speed
of SD, NAND and do the best to shrink memory to make the image as less as
possible.
so printing the speed of compressed image is
On Thu, 23 Jan 2014 15:56:54 +0100, Jiri Olsa wrote:
> On Thu, Jan 23, 2014 at 09:13:45AM +0900, Namhyung Kim wrote:
>> There're some duplicate code when adding hist entries. They are
>> different in that some have branch info or mem info but generally do
>> same thing. So introduce new struct hi
On Thu, 23 Jan 2014 15:44:00 +0100, Jiri Olsa wrote:
> On Thu, Jan 23, 2014 at 09:13:45AM +0900, Namhyung Kim wrote:
>> There're some duplicate code when adding hist entries. They are
>> different in that some have branch info or mem info but generally do
>> same thing. So introduce new struct hi
Hi,
On Thu, 23 Jan 2014 14:38:48 +0100, Jiri Olsa wrote:
> On Thu, Jan 23, 2014 at 08:28:49AM +0900, Namhyung Kim wrote:
>> Currently if a sample was filtered by command line option, it just
>> dropped. But this affects final output in that the percentage can be
>> different since the filtered en
On 01/26/2014 02:16 AM, Richard Weinberger wrote:
>
> Currently we print the kernel offset only upon a panic() using the
> panic notifier list.
> This way it does not show up if the kernel hits a BUG() in process
> context or something less critical.
> Wouldn't make more sense to report the offset
On Thu, 23 Jan 2014 14:21:00 +0100, Jiri Olsa wrote:
> On Thu, Jan 23, 2014 at 08:28:49AM +0900, Namhyung Kim wrote:
>> Currently if a sample was filtered by command line option, it just
>> dropped. But this affects final output in that the percentage can be
>> different since the filtered entries
[Re: [PATCH] mm: bring back /sys/kernel/mm] On 26/01/2014 (Sun 21:02) Hugh
Dickins wrote:
> On Sun, 26 Jan 2014, Paul Gortmaker wrote:
> > [[PATCH] mm: bring back /sys/kernel/mm] On 26/01/2014 (Sun 18:52) Hugh
> > Dickins wrote:
> >
> > > Commit da29bd36224b ("mm/mm_init.c: make creation of the
On Wed, 22 Jan 2014 10:01:48 -0500, Josh Boyer wrote:
> The plugindir_SQ definition contains $(prefix) which is not needed
> as the $(libdir) definition already contains prefix in it. This
> leads to the path including an extra prefix in it, e.g. /usr/usr/lib64.
>
> The -DPLUGIN_DIR defintion incl
On 01/25/2014 02:45 PM, Sebastian Andrzej Siewior wrote:
Dear RT folks!
I'm pleased to announce the v3.12.8-rt11 patch set.
[..]
Thanks a lot, Sebastian, excellent work!
I have upgraded about 40 different QA Farm systems (x86: 32-bit, 64-bit,
single-core, multi-core 2 to 32, single-socket, du
Hi, Vinod,
Let me give some more explanation on the eDMA engine pause and termination
here:
The eDMA engine is a request-driven controller, it manage all channels in one
engine
and schedule them to perform each one's transfer when one's dma request arrive.
When a dma request of a specific chan
Hi Jiri and Josh,
On Wed, 22 Jan 2014 12:36:30 +0100, Jiri Olsa wrote:
> On Tue, Jan 21, 2014 at 03:02:43PM -0500, Josh Boyer wrote:
>> Hi All,
>>
>> I went to build Linux v3.13-737-g7fe67a1 in Fedora this morning and it
>> resulted in RPM complaining that the perf and perf.so binaries had
>> str
[To audit maintainers]
On 01/23/2014 11:18 PM, Catalin Marinas wrote:
On Fri, Jan 17, 2014 at 08:13:14AM +, AKASHI Takahiro wrote:
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -327,6 +327,8 @@ enum {
/* distinguish syscall tables */
#define __AUDIT_ARCH_64BIT 0x8
On Sat, 2014-01-25 at 06:12 +0100, Mike Galbraith wrote:
> On Fri, 2014-01-24 at 20:50 +0100, Sebastian Andrzej Siewior wrote:
> > * Mike Galbraith | 2014-01-18 04:25:14 [+0100]:
> >
> > >> ># timers-do-not-raise-softirq-unconditionally.patch
> > >> ># rtmutex-use-a-trylock-for-waiter-lock-in-tr
On Sun, 26 Jan 2014, Paul Gortmaker wrote:
> [[PATCH] mm: bring back /sys/kernel/mm] On 26/01/2014 (Sun 18:52) Hugh
> Dickins wrote:
>
> > Commit da29bd36224b ("mm/mm_init.c: make creation of the mm_kobj happen
> > earlier than device_initcall") changed to pure_initcall(mm_sysfs_init).
> >
> > T
On 01/26/2014 08:32 PM, Linus Torvalds wrote:
> On Sun, Jan 26, 2014 at 4:22 PM, Al Viro wrote:
>>
>> Umm... Can't uprobe_notify_resume() modify regs as well?
>
> Probably.
>
> .. and on the other hand, we should actually be able to use 'sysret'
> for signal handling on x86-64, because while sy
v2:
Updated description of CONFIG_ACPI_INT3403_THERMAL:
Linus didn't like the config help text. This patch updated the help text to
"
Newer laptops and tablets that use ACPI may have thermal sensors outside the
core CPU/SOC for thermal safety reasons. These temperature sensors are also
exposed fo
Newer laptops and tablets may have thermal sensors outside the core cpu/SOC.
These temperature sensors are exposed to OS via ACPI using INT3403 objects.
This driver registers each INT3403 thermal sensor as a thermal zone device,
and exposes its _TMP, PATx and GTSH method via the standard thermal co
On Sun, Jan 26, 2014 at 4:22 PM, Al Viro wrote:
>
> Umm... Can't uprobe_notify_resume() modify regs as well?
Probably.
.. and on the other hand, we should actually be able to use 'sysret'
for signal handling on x86-64, because while sysret destroys %rcx and
doesn't allow for returning to odd mo
Hi
On Mon, Jan 27, 2014 at 5:33 AM, Mark Brown wrote:
> On Sun, Jan 26, 2014 at 01:36:53PM -0800, Dmitry Torokhov wrote:
>> On Sat, Jan 25, 2014 at 11:35:54PM +0530, Manish Badarkhe wrote:
>
>> > Use "devm_regulator_register" instead of "regulator_register"
>> > which simplifies the code.
>
>> ..
On Sun, 26 Jan 2014, Russell King - ARM Linux wrote:
> On Tue, Jan 21, 2014 at 12:45:05AM +, Alan Cox wrote:
> > Peter handed it on. Try using git log on Documentation/devices.txt. It
> > still gets updates.
> >
> > Perhaps you'd care to stick to reality and fix the tree instead of trying
> >
The kernel can currently only handle a single hugetlb page fault at a time.
This is due to a single mutex that serializes the entire path. This lock
protects from spurious OOM errors under conditions of low of low availability
of free hugepages. This problem is specific to hugepages, because it is
On 01/26/2014 03:51 PM, Mark Brown wrote:
On Sun, Jan 26, 2014 at 02:04:06PM -0800, Guenter Roeck wrote:
I think I have a better idea: Surround the regulator code, or at least
its error handling, in the lm90 driver with
if (IS_ENABLED(CONFIG_OF)) {
}
Would that be ok ? If
sigh, I sent the wrong patch, this one has some bogus leftovers of some
other things. Please ignore, I'm sending v2.
On Sun, 2014-01-26 at 19:52 -0800, Davidlohr Bueso wrote:
> The kernel can currently only handle a single hugetlb page fault at a time.
> This is due to a single mutex that serializ
[[PATCH] mm: bring back /sys/kernel/mm] On 26/01/2014 (Sun 18:52) Hugh Dickins
wrote:
> Commit da29bd36224b ("mm/mm_init.c: make creation of the mm_kobj happen
> earlier than device_initcall") changed to pure_initcall(mm_sysfs_init).
>
> That's too early: mm_sysfs_init() depends on core_initcall
OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
not disable advertisement when PHY supports them. This results in
non-functioning network when the MAC is connected to a gigabit PHY connected
to a gigabit switch.
The fix is to disable gigabit speed advertisement on attach
Signed-off-by: Max Filippov
---
.../devicetree/bindings/net/opencores-ethoc.txt| 25 ++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/opencores-ethoc.txt
diff --git a/Documentation/devicetree/bindings/net/opencores-ethoc.txt
b
Hello David, Grant, Rob, Chris and everybody,
this series improves ethoc behavior in gigabit environment:
- first patch disables gigabit advertisement in the attached PHY making
possible to use gigabit link without any additional setup;
- second patch adds support to set up MII management bus fr
MII management bus clock is derived from the MAC clock by dividing it by
MIIMODER register CLKDIV field value. This value may need to be set up
in case it is undefined or its default value is too high (and
communication with PHY is too slow) or too low (and communication with
PHY is impossible). Th
From: Joonsoo Kim
Currently, to track reserved and allocated regions, we use two different
ways, depending on the mapping. For MAP_SHARED, we use address_mapping's
private_list and, while for MAP_PRIVATE, we use a resv_map.
Now, we are preparing to change a coarse grained lock which protect a
re
This patchset resumes the work to improve the whole hugepage fault
scalability path. Previous efforts can be found here:
https://lkml.org/lkml/2013/7/26/299
https://lkml.org/lkml/2013/12/18/50
The latest attempt to address the big-fat hugetlb instantiation mutex by
removing the need for it altoge
From: Joonsoo Kim
To change a protection method for region tracking to find grained one,
we pass the resv_map, instead of list_head, to region manipulation
functions. This doesn't introduce any functional change, and it is just
for preparing a next step.
Reviewed-by: Aneesh Kumar K.V
Signed-off
From: Joonsoo Kim
Util now, we get a resv_map by two ways according to each mapping type.
This makes code dirty and unreadable. Unify it.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
Signed-off-by: Davidlohr Bueso
---
mm/hugetlb.c | 76 ++--
From: Joonsoo Kim
There is a race condition if we map a same file on different processes.
Region tracking is protected by mmap_sem and hugetlb_instantiation_mutex.
When we do mmap, we don't grab a hugetlb_instantiation_mutex, but only the,
mmap_sem (exclusively). This doesn't prevent other tasks
From: Joonsoo Kim
Currently, we have two variable to represent whether we can use reserved
page or not, chg and avoid_reserve, respectively. With aggregating these,
we can have more clean code. This makes no functional difference.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
Signed
From: Joonsoo Kim
This is a preparation patch to unify the use of vma_resv_map() regardless
of the map type. This patch prepares it by removing resv_map_put(), which
only works for HPAGE_RESV_OWNER's resv_map, not for all resv_maps.
Reviewed-by: Aneesh Kumar K.V
Signed-off-by: Joonsoo Kim
[Upd
The kernel can currently only handle a single hugetlb page fault at a time.
This is due to a single mutex that serializes the entire path. This lock
protects from spurious OOM errors under conditions of low of low availability
of free hugepages. This problem is specific to hugepages, because it is
From: Joonsoo Kim
vma_has_reserves() can be substituted by using return value of
vma_needs_reservation(). If chg returned by vma_needs_reservation()
is 0, it means that vma has reserves. Otherwise, it means that vma don't
have reserves and need a hugepage outside of reserve pool. This definition
(2014/01/26 13:02), David Rientjes wrote:
> On Thu, 16 Jan 2014, HATAYAMA Daisuke wrote:
>
>> Hello,
>>
>> This patch deals with the issue of handling boot_cpu_physical_apicid
>> in boot process I avoided in disable_cpu_apicid patch because I
>> cannot guess how long it needs to take for the revie
Commit da29bd36224b ("mm/mm_init.c: make creation of the mm_kobj happen
earlier than device_initcall") changed to pure_initcall(mm_sysfs_init).
That's too early: mm_sysfs_init() depends on core_initcall(ksysfs_init)
to have made the kernel_kobj directory "kernel" in which to create "mm".
Make it
On Thu, Jan 23, 2014 at 02:22:12PM -0500, Johannes Weiner wrote:
> On Thu, Jan 23, 2014 at 02:20:14PM +0900, Minchan Kim wrote:
> > On Wed, Jan 22, 2014 at 01:42:17PM -0500, Johannes Weiner wrote:
> > > On Mon, Jan 13, 2014 at 04:39:47PM +0900, Minchan Kim wrote:
> > > > On Fri, Jan 10, 2014 at 01:
On 01/27/2014 10:10 AM, H. Peter Anvin wrote:
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
Peter, you mean we should remove these two call and do what they do in
user-space, right?
Unless we think there is a benefit to the kernel to have a on/off switch
for the #BR exception (if disabled, all
Hello Weigie,
On Fri, Jan 24, 2014 at 10:20:36PM +0800, Weijie Yang wrote:
> On Thu, Jan 23, 2014 at 2:30 PM, Cai Liu wrote:
> > Hello Minchan
> >
> > 2014/1/23 Minchan Kim :
> >> Hello Cai,
> >>
> >> On Thu, Jan 23, 2014 at 09:38:41AM +0800, Cai Liu wrote:
> >>> Hello Dan
> >>>
> >>> 2014/1/22 D
On 01/26/2014 05:55 PM, Ren Qiaowei wrote:
>
> Peter, you mean we should remove these two call and do what they do in
> user-space, right?
>
Unless we think there is a benefit to the kernel to have a on/off switch
for the #BR exception (if disabled, all #BR exceptions are signals,
regardless of s
On 01/26/2014 11:14 PM, Ingo Molnar wrote:
* Ren, Qiaowei wrote:
The size of one bound table is 4M bytes for 64bit, and 16K bytes for
32bit. It can not be accessed by user-space, and it will be accessed
automatically by hardware.
So, here's the bound-table allocation AFAICS:
+static bool a
On 01/27/2014 09:53 AM, H. Peter Anvin wrote:
On 01/26/2014 05:34 PM, Ren Qiaowei wrote:
I agree with you and we should suppress all the warnings as possible. If
I use (unsgined long) to cast like the following code, what do you think
about it? sizeof(long) will be 4 for 32-bit.
info->si
On 01/27/2014 09:50 AM, H. Peter Anvin wrote:
On 01/26/2014 12:39 AM, Ingo Molnar wrote:
It will be only once per startup.
In that case it would be more efficient to make this part of the
binary execution environment so that exec() sets it up automatically,
not a separate prctl() syscall.
Josh Boyer wrote:
> adds a udelay(1) call to the ath9k driver. This will cause a
> build error on various ARM configs because the value passed to udelay
> is too large:
>
> ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath9k/ath9k_hw.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make:
On 01/26/2014 05:34 PM, Ren Qiaowei wrote:
>>
> I agree with you and we should suppress all the warnings as possible. If
> I use (unsgined long) to cast like the following code, what do you think
> about it? sizeof(long) will be 4 for 32-bit.
>
> info->si_lower = (void __user *)(unsigned long)
On 01/26/2014 12:39 AM, Ingo Molnar wrote:
>>
>> It will be only once per startup.
>
> In that case it would be more efficient to make this part of the
> binary execution environment so that exec() sets it up automatically,
> not a separate prctl() syscall.
>
This is not necessarily possible,
On 01/27/2014 05:38 AM, David Rientjes wrote:
On Sun, 26 Jan 2014, Ren Qiaowei wrote:
arch/x86/kernel/mpx.c: In function ‘do_mpx_bounds’:
arch/x86/kernel/mpx.c:407:3: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
arch/x86/kernel/mpx.c:409:3: warning: cast to po
From: Rafael J. Wysocki
After recent PCI core changes related to the rescan/remove locking,
the ACPIPHP's disable_slot() function is only called under the
general PCI rescan/remove lock, so it doesn't have to use
dev_in_slot() any more to avoid race conditions. Make it simply
walk the devices on
From: Rafael J. Wysocki
None of the existing users of struct acpi_dock_ops actually needs the
first argument of its member functions, so redefine those functions
to take only two arguments, the event type and data pointer, and
update the users of struct acpi_dock_ops accordingly.
Signed-off-by:
From: Rafael J. Wysocki
A few lines of code can be cut from hotplug_event() by defining
and initializing the slot variable at the top of the function,
so do that.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 19 ++-
1 file changed, 6 insertions(+)
From: Rafael J. Wysocki
Make hotplug_event() use acpi_handle_debug() instead of an open-coded
debug message printing and clean up the messages printed by it.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 13 +++--
1 file changed, 3 insertions(+), 10 deleti
From: Rafael J. Wysocki
After recent PCI core changes related to the rescan/remove locking,
the code sections under crit_sect mutexes from ACPIPHP slot objects
are always executed under the general PCI rescan/remove lock.
For this reason, the crit_sect mutexes are simply redundant, so drop
them.
From: Rafael J. Wysocki
If a struct acpi_device pointer is passed to acpiphp_no_hotplug()
instead of an ACPI handle, the function won't need to call
acpi_bus_get_device(), which may be costly, any more. Then,
trim_stale_devices() can call acpiphp_no_hotplug() passing
the struct acpi_device objec
From: Rafael J. Wysocki
If trim_stale_devices() calls acpi_bus_trim() directly, we can
save a potentially costly acpi_bus_get_device() invocation. After
making that change acpiphp_bus_trim() would only be called from one
place, so move the code from it to that place and drop it.
Signed-off-by:
From: Rafael J. Wysocki
The err label in register_slot() is only jumped to from one place,
so move the code under the label to that place and drop the label.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 12
1 file changed, 4 insertions(+), 8 deletion
Hi Dmitry,
>
> On Sat, Jan 25, 2014 at 11:01:54AM -0800, Raghu Gandham wrote:
> > The standard IO regions are already reserved by the platform code on
> > most MIPS devices(malta, cobalt, sni). The Commit
> > 197a1e96c8be5b6005145af3a4c0e45e2d651444
> > ("Input: i8042-io - fix up region handling
Hi All,
ACPIPHP can be simplified a bit on top of some PCI and ACPI changes merged
recently and the following series of patches implements those simplifications:
[1/11] Fix up two kerneldoc comments in acpiphp_glue.c.
[2/11] Get rid of an unnecessary label in register_slot().
[3/11] Drop acpiphp_
From: Rafael J. Wysocki
Add proper kerneldoc comments describing acpiphp_enumerate_slots()
and acpiphp_remove_slots().
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
Index: linux-pm/drivers/pci/ho
From: Rafael J. Wysocki
acpiphp_bus_add() is only called from one place, so move the code out
of it into that place and drop it. Also make that code use
func_to_acpi_device() to get the struct acpi_device pointer it needs
instead of calling acpi_bus_get_device() which may be costly.
Signed-off-
From: Rafael J. Wysocki
After recent modifications of the ACPI core making it create a struct
acpi_device object for every namespace node representing a device
regardless of the current status of that device the ACPIPHP code
can store a struct acpi_device pointer instead of an ACPI handle
in stru
On Sun, Jan 26, 2014 at 02:28:15PM -0800, Linus Torvalds wrote:
> The x86-64 (and 32-bit, for that matter) system call slowpaths are all
> in C, but the *selection* of which slow-path to take is a mixture of
> complicated assembler ("sysret_check -> sysret_careful ->
> sysret_signal ->sysret_audit
1 - 100 of 270 matches
Mail list logo
