Hello,
On Wed, Aug 07, 2013 at 03:37:46PM +0200, Michal Hocko wrote:
> > It isn't different from listening from epoll, for example.
>
> epoll limits the number of watchers, no?
Not that I know of. It'll be limited by max open fds but I don't
think there are other limits. Why would there be?
>
On Wed 07-08-13 09:22:10, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 07, 2013 at 01:28:25PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of threshold events registered
> > per memcg. This might lead to an user triggered memory depletion if a
> > regular user is allowed to
There is no need to have a nlmsghdr pointer to another temporary buffer.
Instead use a full struct nlmsghdr.
Signed-off-by: Olaf Hering
---
tools/hv/hv_kvp_daemon.c | 15 +--
tools/hv/hv_vss_daemon.c | 15 +--
2 files changed, 10 insertions(+), 20 deletions(-)
diff --git
The return type of ffs() is 'int' on all architectures except cris and
hexagon. This unifies the return type to 'int'.
The problem I'm seeing is that the following line generates a warning
on cris and hexagon because of the mismatch between format '%u' and
return type of ffs().
printk("b
The return type of ffs() is 'int' on all architectures except cris and
hexagon. This unifies the return type to 'int'.
The problem I'm seeing is that the following line generates a warning
on cris and hexagon because of the mismatch between format '%u' and
return type of ffs().
printk("b
On 8/5/13 3:17 AM, Namhyung Kim wrote:
I don't think this is a problem, its in line with Ingo's suggestion of a
new perf ioctl to ask the kernel to generate PERF_RECORD_MMAP events for
existing threads.
Hmm.. could you please give me a link of the thread?
I believe this is the thread being re
On Mon 05-08-13 12:43:58, Andy Lutomirski wrote:
> My application fallocates and mmaps (shared, writable) a lot (several
> GB) of data at startup. Those mappings are mlocked, and they live on
> ext4. The first write to any given page is slow because
> ext4_da_get_block_prep can block. This means
On Wed 07-08-13 09:08:36, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of oom_control events
> > registered per memcg. This might lead to an user triggered memory
> > depletion if a regular user is
Hello, Michal.
On Wed, Aug 07, 2013 at 03:26:13PM +0200, Michal Hocko wrote:
> I would rather see it not changed unless it really is a big win in the
> cgroup core. So far I do not see anything like that (just look at
> __cgroup_from_dentry which needs to be exported to allow for the move).
The e
On Aug 7, 2013, at 7:09 PM, Tony Lindgren wrote:
> * Chen Baozi [130805 08:33]:
>> ping?
>>
>> On Aug 1, 2013, at 7:27 PM, Chen Baozi wrote:
>>
>>> The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
>>> rather than INCREMENTER_NUMERATOR_OFFSET.
>
> Maybe describe what
On Wed, 7 Aug 2013, Peter Wu wrote:
> > does the patch below fix the problem you are seeing?
> That one is already in 3.11-rc4 as far as I can see. Also, that code can
> probably simplified by moving the mutex_unlock after the out label, removing
> the need to duplicate the mutex_unlock.
>
> Re
On Wednesday 07 August 2013 03:01:26 Jiri Kosina wrote:
> On Tue, 6 Aug 2013, Peter Wu wrote:
> > While debugging upowerd (with Logitech Unifying receiver via hidraw),
> > I came across this list corruption warning.
>
> Peter,
>
> does the patch below fix the problem you are seeing?
That one is a
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> It doesn't exist on the Snowball development board.
>
> Signed-off-by: Lee Jones
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> TPS61052 is a; boost converter, LED driver, LED flash driver and
> simple GPIO pin chip. It has no use here however, as it is not
> found on the Snowball development board.
>
> Signed-off-by: Lee Jones
Patch applied.
Yours,
Linus Walleij
--
T
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> It doesn't exist on the Snowball development board.
>
> Signed-off-by: Lee Jones
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
On Fri, Jul 19, 2013 at 4:13 PM, Lee Jones wrote:
> It doesn't exist on this development board.
>
> Signed-off-by: Lee Jones
Patch applied to my ux500-dt branch.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote:
> On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote:
>> well, let's divide things up into two categories:
>>
>> 1) the arrangement and format of pixels.. ie. what userspace would
>> need to know if it mmap's a buffer. This includes pixel format,
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Wednesday, August 07, 2013 9:07 AM
> To: KY Srinivasan; gre...@linuxfoundation.org
> Cc: linux-kernel@vger.kernel.org; Olaf Hering
> Subject: [PATCH] Tools: hv: correct payload size in netlink_send
>
> netlink_send
On Wed 07-08-13 08:43:21, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> > How is it specific to memcg? The fact only memcg uses the interface
> > doesn't imply it is memcg specific.
>
> I don't follow. It's only for memcg. That is *by defi
Add a test for the newly added PERF_COUNT_SW_DUMMY event.
The test checks that tracking events continue when an
event is disabled but a dummy software event is not
disabled.
Signed-off-by: Adrian Hunter
---
tools/perf/Makefile | 1 +
tools/perf/tests/builtin-test.c | 4 ++
tool
Add support for the new dummy software event
PERF_COUNT_SW_DUMMY.
Signed-off-by: Adrian Hunter
---
tools/perf/util/parse-events.c | 4
tools/perf/util/parse-events.l | 1 +
tools/perf/util/python.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/tools/perf/util/parse-events.c b/
When an event is disabled the "tracking" events
selected by the 'mmap', 'comm' and 'task' bits of
struct perf_event_attr, are also disabled. However,
the information those events provide is necessary to
resolve symbols for when the main event is re-enabled.
The "tracking" events can be kept enabl
Hi
This is an alternative to the 'keep tracking' flag patch
which is here:
http://marc.info/?l=linux-kernel&m=137242545521246&w=2
perf tools is updated and a test added to demonstrate the
new event.
Adrian Hunter (3):
perf: add a dummy software event to keep tracking
perf t
Hello,
On Wed, Aug 07, 2013 at 01:28:25PM +0200, Michal Hocko wrote:
> There is no limit for the maximum number of threshold events registered
> per memcg. This might lead to an user triggered memory depletion if a
> regular user is allowed to register on memory.[memsw.]usage_in_bytes
> eventfd in
Greetings
You are a beneficiary to my late clients Will and Testament, late James
Jampbell made his inheritance in your favour. i need your attention on this
issue.
Barr Colin Lee.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
On 08/07/2013 09:09 PM, Takuya Yoshikawa wrote:
> On Tue, 30 Jul 2013 21:02:08 +0800
> Xiao Guangrong wrote:
>
>> @@ -2342,6 +2358,13 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>> */
>> kvm_flush_remote_tlbs(kvm);
>>
>> +if (kvm->arch.rcu_free_shadow_page) {
>> +
On Wed, Aug 07, 2013 at 09:08:36AM -0400, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> > There is no limit for the maximum number of oom_control events
> > registered per memcg. This might lead to an user triggered memory
> > depletion if a
On Tue, 30 Jul 2013 21:02:08 +0800
Xiao Guangrong wrote:
> @@ -2342,6 +2358,13 @@ static void kvm_mmu_commit_zap_page(struct kvm *kvm,
>*/
> kvm_flush_remote_tlbs(kvm);
>
> + if (kvm->arch.rcu_free_shadow_page) {
> + sp = list_first_entry(invalid_list, struct kvm_m
On Tue, 06 Aug, at 08:45:08PM, Roy Franz wrote:
> The x86/AMD64 EFI stubs must us a call wrapper to convert between
> the Linux and EFI ABIs, so void pointers are sufficient. For ARM,
> the ABIs are compatible, so we can directly invoke the function
> pointers. The functions that are used by the
On Tue, 06 Aug, at 08:45:06PM, Roy Franz wrote:
> Rename variables to be not initrd specific, as now the function
> loads arbitrary files.
>
> Signed-off-by: Roy Franz
> ---
> drivers/firmware/efi/efi-stub-helper.c | 92
>
> 1 file changed, 46 insertions(+), 4
**_usb_get_phy_**() APIs should generate equivalent
error codes in case of failure in getting phy. There's no
need of returning NULL pointer, like in devm_usb_get_phy()
or devm_usb_get_phy_dev(), since it's nowhere handled.
Earlier series of patches starting:
9ee1c7f usb: host: ohci-exynos: fix PH
On Tue, 06 Aug, at 08:44:59PM, Roy Franz wrote:
> Signed-off-by: Roy Franz
> ---
> arch/x86/boot/compressed/eboot.c | 38 +++--
> drivers/firmware/efi/efi-stub-helper.c | 96
> +---
> 2 files changed, 72 insertions(+), 62 deletions(-)
For future ref
On Tue, 06 Aug, at 08:45:00PM, Roy Franz wrote:
> Rename them to be more similar, as low_free() could be used to free
> memory allocated by both high_alloc() and low_alloc().
> high_alloc() -> efi_high_alloc()
> low_alloc() -> efi_low_alloc()
> low_free() -> efi_free()
>
> Signed-off-by: Roy Fr
Hello, Michal.
On Wed, Aug 07, 2013 at 01:28:26PM +0200, Michal Hocko wrote:
> There is no limit for the maximum number of oom_control events
> registered per memcg. This might lead to an user triggered memory
> depletion if a regular user is allowed to register events.
>
> Let's be more strict a
netlink_send is supposed to send just the cn_msg+hv_kvp_msg via netlink.
Currently it sets an incorrect iovec size, as reported by valgrind.
In the case of registering with the kernel the allocated buffer is large
enough to hold nlmsghdr+cn_msg+hv_kvp_msg, no overrun happens. In the
case of respon
On Tue, Aug 06, 2013 at 02:08:15PM +0100, Mark Rutland wrote:
> On Tue, Aug 06, 2013 at 12:59:21PM +0100, Will Deacon wrote:
> > But we already check `event->pmu != leader_pmu' in validate_event, so we
> > shouldn't get anywhere nearer calling get_event_idx in the case you
> > describe. It sounds m
On Tue, Aug 06, 2013 at 11:34:35PM +0200, Mathias Krause wrote:
> Commit a5463cd3 "ARM: make vectors page inaccessible from userspace"
> introduced a typo making arch_vma_name() always return "[vectors]".
> Fix up that regression (of the hush-hush security fix).
And if you search the list archives
On Wed, Aug 07, 2013 at 06:24:56PM +0800, Lai Jiangshan wrote:
> Although all articles declare that rcu read site is deadlock-immunity.
> It is not true for rcu-preempt, it will be deadlock if rcu read site
> overlaps with scheduler lock.
The real rule is that if the scheduler does its outermost r
Hi,
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
@@ -0,0 +1,19 @@
+Zevio GPIO controller
+
+Required properties:
+- compatible = "lsi,zevio-gpio"
+- reg =
+- #gpio-cells = <2>
+- gpio-controller;
+
+Optional:
+- #ngpios = <32>: Number of GPIOs. Defaults to 32 if abs
This driver supports the GPIO controller found in LSI ZEVIO SoCs.
It has been successfully tested on a TI nspire CX calculator.
---
.../devicetree/bindings/gpio/gpio-zevio.txt| 18 ++
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile
My Latitude E6510 has the following graphics HW:
01:00.0 VGA compatible controller: nVidia Corporation GT218 [NVS 3100M] (rev
a2) (prog-if 00 [VGA controller])
Subsystem: Dell Latitude E6510
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at e200 (32-bit, non-
This patch splits the sam9x5 peripheral definitions into:
- a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
- several optional peripheral definitions which will be included by specific
sam9x5 SoCs (at91sam9x5_'periph name'.dtsi)
This provides a better representation of the real hardware (dro
Hello, Michal.
On Wed, Aug 07, 2013 at 02:18:36PM +0200, Michal Hocko wrote:
> How is it specific to memcg? The fact only memcg uses the interface
> doesn't imply it is memcg specific.
I don't follow. It's only for memcg. That is *by definition* memcg
specific. It's the verbatim meaning of the
Dear,
Our company manufactures a range of injectable and oral steroids products that
are used successfully in over 10 countries.
We are considering expanding our products to new markets and we would
appreciate you assistance.
In particular, we would like to look for product agents. We will quote
On Tue 06-08-13 12:15:09, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Aug 06, 2013 at 05:58:04PM +0200, Michal Hocko wrote:
> > I am objecting to moving the generic part of that code into memcg. The
> > memcg part and the additional complexity (all the parsing and conditions
> > for signalling)
> -Original Message-
> From: grund...@google.com [mailto:grund...@google.com] On Behalf Of Grant
> Grundler
> Sent: Wednesday, August 07, 2013 1:07 AM
> To: Marek Szyprowski
>
> Hi Marek,
>
> On Tue, Aug 6, 2013 at 6:17 AM, Marek Szyprowski
> wrote:
> ...
> > IMHO it is much better to h
On Tue, Aug 6, 2013 at 6:43 PM, Oleg Nesterov wrote:
> Felipe, thanks a lot. Yes fab840f is wrong, this "bug" is already
> used as a feature.
>
> Grazvydas, I cc'ed you because I do not really understand
> set_thread_context(). It does a couple of extra PTRACE_POKEUSER's
> with the "Linux 2.6.33+
On Mon, Aug 05, 2013 at 01:15:40PM +0100, Matt Fleming wrote:
> > +static __init int match_config_table(efi_guid_t *guid,
> > +unsigned long table,
> > +efi_config_table_type_t *table_types)
> > +{
> > + u8 str[38];
>
> Shouldn't th
v2: added myself as a maintainer
Sorry for previous bad-wrapped email.
ideapad_slidebar is a new driver which enables slidebars on some
Lenovo IdeaPad laptops (the slidebars work with SlideNav/Desktop
Navigator under Windows)
Fixes this: https://bugzilla.kernel.org/show_bug.cgi?id=16004
Registe
On 07/08/13 11:54, Namhyung Kim wrote:
> On Wed, 07 Aug 2013 11:19:32 +0300, Adrian Hunter wrote:
>> On 07/08/13 11:09, Namhyung Kim wrote:
>>> On Mon, 5 Aug 2013 19:26:25 +0300, Adrian Hunter wrote:
The size of data retrieved from a sample event must be
validated to ensure it does not g
vmlinux maps now map to the dso and the symbol values
are now file offsets. For comparison with kallsyms
the virtual memory address is needed which is obtained
by unmapping the symbol value.
The "vmlinux symtab matches kallsyms" is adjusted
accordingly.
Signed-off-by: Adrian Hunter
---
tools/p
Hi Huajun,
Sorry for the long delay.
I've been too busy to catch up this new big feature.
Anyway, do you guys still design or focus on this issue?
Nowadays, I can afford to dive into this issue.
So, if you have done any progress so far, can you share it with me?
Otherwise, I'd like to start to de
The new "object code reading" test shows that it is not possible
to read object code from vmlinux. That is because the mappings
do not map to the dso. This patch fixes that.
A side-effect of changing the kernel map is that the "reloc"
offset must be taken into account. As a result of that
separ
kallsyms maps now may map to kcore and the symbol values
now may be file offsets. For comparison with vmlinux
the virtual memory address is needed which is obtained
by unmapping the symbol value.
The "vmlinux symtab matches kallsyms" is adjusted
accordingly.
Signed-off-by: Adrian Hunter
---
to
Currently the symbol name is displayed at the top
when displaying symbol annotation. Add to this
the dso long name.
Signed-off-by: Adrian Hunter
---
tools/perf/ui/browsers/annotate.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/tools/perf/ui/browsers/ann
When kcore is used for annotation, symbols do not
have correct sizes because they come from kallsyms.
That sometimes results in an extra nop being seen
after the end of a function. Remove it.
Signed-off-by: Adrian Hunter
---
tools/perf/util/annotate.c | 31 +++
1 fil
Annotation with /proc/kcore is possible so the logic
is adjusted to allow it. The main difference is that
/proc/kcore had no symbols so the parsing logic needed
a tweak to read jump offsets.
The other difference is that objdump cannot always
read from kcore. That seems to be a bug with objdump.
We want the trig_sts bits to be cleared in all cases where we consider
the jack detection interrupt to have been handled. Specifically, if a
duplicate detection event was suppressed these bits were not cleared
causing the CODEC to not enter a low power state. This patch clears the
bits on the dupli
When removing duplicate symbols, prefer to remove
syscall aliases starting with SyS or compat_SyS.
A side-effect of that is that it results in slightly
improved results for the "vmlinux symtab matches kallsyms"
test.
Signed-off-by: Adrian Hunter
---
tools/perf/util/symbol.c | 17 ++-
On 7 August 2013 17:00, Sudeep KarkadaNagesha
wrote:
> Any particular reason we need this check in all drivers after your
> commit: 5a1c0228 "cpufreq: Avoid calling cpufreq driver's target()
> routine if target_freq == policy->cur"
>
> I think it can removed from all drivers, am I missing somethin
kcore has no symbols, so the call target name does not display.
Fix by looking up the symbol name if it is on the same map.
Signed-off-by: Adrian Hunter
---
tools/perf/util/annotate.c | 16
1 file changed, 16 insertions(+)
diff --git a/tools/perf/util/annotate.c b/tools/perf/ut
Make the "object code reading" test attempt to read from
kcore.
The test uses objdump which struggles with kcore. i.e.
doesn't always work, sometimes takes a long time.
The test has been made to work around those issues.
Signed-off-by: Adrian Hunter
---
tools/perf/tests/code-reading.c | 100 +++
In the absence of vmlinux, perf tools uses kallsyms
for symbols. If the user has access, now also map to
/proc/kcore.
The dso data_type is now set to either
DSO_BINARY_TYPE__KCORE or DSO_BINARY_TYPE__GUEST_KCORE
as approprite.
This patch breaks the "vmlinux symtab matches kallsyms"
test. That i
The new "object code reading" test shows that it is not possible
to read object code from kernel modules. That is because the mappings
do not map to the dsos. This patch fixes that.
This involves identifying and flagging relocatable (ELF type ET_REL) files
(e.g. kernel modules) for symbol adjust
In order to use kernel maps to read object code, those
maps must be adjusted to map to the dso file offset.
Because lazy-initialization is used, that is not done
until symbols are loaded. However the maps are first
used by thread__find_addr_map() before symbols are loaded.
So this patch changes th
Using the information in mmap events, perf tools can read object
code associated with sampled addresses. A test is added that
compares bytes read by perf with the same bytes read using
objdump.
Signed-off-by: Adrian Hunter
---
tools/perf/Makefile | 1 +
tools/perf/tests/builtin-te
Hi
Here are some patches that add support for reading object code from vmlinux,
kernel modules and /proc/kcore.
Changes in V4:
perf tools: make it possible to read object code from kernel modules
Fix symbol adjustment for kernel modules
Remove kallsyms' sym
On Wed, Aug 07 2013, Rusty Russell wrote:
> Christoph Jaeger writes:
>> In param_get_byte(), to which the macro STANDARD_PARAM_DEF(byte, ...)
>> expands,
>> "%c" is used to print an unsigned char. So it gets printed as a character
>> what
>> is not intended here. Use "%hhu" instead.
>>
>> Signed
On 07/08/13 12:22, Viresh Kumar wrote:
> On 7 August 2013 16:46, Amit Daniel Kachhap wrote:
>> This patch fixes the issue of un-necessary setting the clock controller
>> when the new target frequency is same as the current one. This case usually
>> occurs with governors like ondemand which passes
There is no limit for the maximum number of threshold events registered
per memcg. This might lead to an user triggered memory depletion if a
regular user is allowed to register on memory.[memsw.]usage_in_bytes
eventfd interface.
Let's be more strict and cap the number of events that might be
regi
There is no limit for the maximum number of oom_control events
registered per memcg. This might lead to an user triggered memory
depletion if a regular user is allowed to register events.
Let's be more strict and cap the number of events that might be
registered. MAX_OOM_NOTIFY_EVENTS value is mor
On Wed, Aug 7, 2013 at 1:06 PM, Lars Poeschel wrote:
> From: Lars Poeschel
>
> Following commit ff5c9059 and therefore other omap platforms using
> the gpio-omap driver correct the #interrupt-cells property on am33xx
> too. The omap gpio binding documentaion also states that
> the #interrupt-cell
There is no limit for the maximum number of vmpressure events registered
per memcg. This might lead to an user triggered memory depletion if a
regular user is allowed to register events.
Let's be more strict and cap the number of events that might be
registered. MAX_VMPRESSURE_EVENTS value is more
v2: added myself as a maintainer
ideapad_slidebar is a new driver which enables slidebars on some
Lenovo IdeaPad laptops (the slidebars work with SlideNav/Desktop
Navigator under Windows)
Fixes this: https://bugzilla.kernel.org/show_bug.cgi?id=16004
Registers 'IdeaPad Slidebar' input device and
On 7 August 2013 16:46, Amit Daniel Kachhap wrote:
> This patch fixes the issue of un-necessary setting the clock controller
> when the new target frequency is same as the current one. This case usually
> occurs with governors like ondemand which passes the target frequency as the
> percentage of
This patch fixes the issue of un-necessary setting the clock controller
when the new target frequency is same as the current one. This case usually
occurs with governors like ondemand which passes the target frequency as the
percentage of average frequency. This check is present in most of the cpuf
In the following patches, we need to call get_ramdisk_{image|size}()
to get initrd file's address and size. So make these two functions
global.
v1 -> v2:
As tj suggested, make these two function static inline in
arch/x86/include/asm/setup.h.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
--
From: Lars Poeschel
Following commit ff5c9059 and therefore other omap platforms using
the gpio-omap driver correct the #interrupt-cells property on am33xx
too. The omap gpio binding documentaion also states that
the #interrupt-cells property should be 2.
Signed-off-by: Lars Poeschel
---
arch/
> -Original Message-
> From: Stanislaw Gruszka [mailto:sgrus...@redhat.com]
> Sent: Tuesday, August 06, 2013 09:55
> To: Winkler, Tomas
> Cc: linux-kernel@vger.kernel.org
> Subject: [3.10 regression] mei endless recursion
>
> Hi
>
> We have a bug report when system fail to boot on 3.10
Linux kernel cannot migrate pages used by the kernel. As a result, hotpluggable
memory used by the kernel won't be able to be hot-removed. To solve this
problem, the basic idea is to prevent memblock from allocating hotpluggable
memory for the kernel at early time, and arrange all hotpluggable memo
Since we split acpi_table_init() into two steps, and want to do
the two steps separately, we need to do check_multiple_madt() after
acpi_table_init_override().
But we also have to keep acpi_table_init() as before because it
is also used in ia64, we have to do check_multiple_madt() directly
in acpi
As the previous patches split the acpi_gbl_root_table_list initialization
procedure into two steps: install and override, this patch does the "install"
steps earlier, right after memblock is ready.
In this way, we are able to find SRAT in firmware earlier. And then, we can
prevent memblock from al
The macro INVALID_TABLE() is defined like this:
#define INVALID_TABLE(x, path, name)\
{ pr_err("ACPI OVERRIDE: " x " [%s%s]\n", path, name); continue; }
And it is used like this:
for (...) {
...
if (...)
The previous patch introduces two new functions:
acpi_tb_root_table_install() and acpi_tb_root_table_override(),
which work just the same as acpi_tb_parse_root_table() if they are
called in sequence.
In order to split acpi_initialize_tables(), call thes two functions
in acpi_initialize_tables(
Linux cannot migrate pages used by the kernel due to the direct mapping
(va = pa + PAGE_OFFSET), any memory used by the kernel cannot be hot-removed.
So when using memory hotplug, we have to prevent the kernel from using
hotpluggable memory.
The ACPI table SRAT (System Resource Affinity Table) con
Hello Richard,
On 07/08/2013 12:38, Richard Genoud wrote:
2013/8/7 Boris BREZILLON :
This patch splits the sam9x5 peripheral definitions into:
- a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
- several optional peripheral definitions which will be included by specific
sam9x5 SoCs (at91s
* Chen Baozi [130805 08:33]:
> ping?
>
> On Aug 1, 2013, at 7:27 PM, Chen Baozi wrote:
>
> > The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
> > rather than INCREMENTER_NUMERATOR_OFFSET.
Maybe describe what exactly happens without this fix?
Also we should get few ack
On Wed, Aug 07, 2013 at 10:36:08AM +, Matthew Garrett wrote:
> Not really. The ACPI driver is able to do this because the events and
> the backlight are associated with the same device.
Well, it doesn't work at least in my case.
I need to echo stuff into /sys/class/backlight/intel_backlight :
In the next commit this function will be used in the uio subsystem
Signed-off-by: Uwe Kleine-König
---
Hello,
Greg suggested to take this patch together with the next one via his uio
tree with the appropriate acks.
Best regards
Uwe
mm/memory.c | 1 +
1 file changed, 1 insertion(+)
diff --git
This makes it possible to let gdb access mappings of the process that is
being debugged.
uio_mmap_logical was moved and uio_vm_ops renamed to group related code
and differentiate to new stuff.
Signed-off-by: Uwe Kleine-König
---
drivers/uio/uio.c | 26 +-
1 file changed,
vma_count is used write-only and so fails to be useful. So remove it.
Signed-off-by: Uwe Kleine-König
---
drivers/uio/uio.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index c4279b2..8abe78c 100644
--- a/drivers/uio/uio.c
+++ b/drive
In acpi_initrd_override(), it checks several things to ensure the
table it found is valid. In later patches, we need to do these check
somewhere else. So this patch introduces a common function
acpi_verify_initrd() to do all these checks, and reuse it in different
places. The function will be used
2013/8/7 boris brezillon :
> Hello Richard,
>
>
> On 07/08/2013 12:38, Richard Genoud wrote:
>>
>> 2013/8/7 Boris BREZILLON :
>>>
>>> This patch splits the sam9x5 peripheral definitions into:
>>> - a common base for all sam9x5 SoCs (at91sam9x5.dtsi)
>>> - several optional peripheral definitions whi
In ACPI, SRAT(System Resource Affinity Table) contains NUMA info.
The memory affinities in SRAT record every memory range in the
system, and also, flags specifying if the memory range is
hotpluggable.
(Please refer to ACPI spec 5.0 5.2.16)
memblock starts to work at very early time, and SRAT has n
The previous patch introduces two new functions:
acpi_initialize_tables_firmware() and acpi_initialize_tables_override(),
which work just the same as acpi_initialize_tables() if they are called
in sequence.
In order to split acpi_table_init() on acpi side, call these two functions
in acpi_tabl
The comments of find_cpio_data() says:
* @offset: When a matching file is found, this is the offset to the
* beginning of the cpio. ..
But according to the code,
dptr = PTR_ALIGN(p + ch[C_NAMESIZE], 4);
nptr = PTR_ALIGN(dptr + ch[C_FILESIZE], 4);
*offset = (long)npt
This patch splits acpi_boot_table_init() into two steps,
so that we can do each step separately in later patches.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanfei
---
arch/x86/kernel/acpi/boot.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/acpi
This patch splits acpi_tb_parse_root_table() into two steps, and
introduces two new functions:
acpi_tb_root_table_install() and acpi_tb_root_table_override().
They are just the same as acpi_tb_parse_root_table() if they are
called in sequence.
Signed-off-by: Tang Chen
Reviewed-by: Zhang Yanf
This patch splits acpi_table_init() into two steps.
Since acpi_table_init() is used not just in x86, also used in ia64,
we introduce two new functions:
acpi_table_init_firmware() and acpi_table_init_override(),
which work just the same as acpi_table_init() if they are called
in sequence. This
There is no flag in memblock to describe what type the memory is.
Sometimes, we may use memblock to reserve some memory for special usage.
And we want to know what kind of memory it is. So we need a way to
differentiate memory for different usage.
In hotplug environment, we want to reserve hotplug
601 - 700 of 848 matches
Mail list logo
