On Sat, Mar 7, 2015 at 5:59 PM, David Rientjes wrote:
>
> Hmm, although the bug is reported for a 3.12 kernel, I assume this is for
> stable 3.10+? If so, it should apply fine with the exception of removing
> e820_reserve_setup_data() from setup_arch() rather than
> memblock_x86_reserve_range_set
Currently kaslr only randomize physical address of kernel loading, then add
the delta to virtual address of kernel text mapping. Because kernel virtual
address can only be from __START_KERNEL_map to
LOAD_PHYSICAL_ADDR+CONFIG_RANDOMIZE_BASE_MAX_OFFSET,
namely [0x8000, 0xc00
Kernel is expected to be randomly reloaded anywhere in the whole
physical memory area, it could be near 64T at most. In this case
there could be about 4*1024*1024 randomization slots. Hence the
old slot array will cost too much memory and also not efficient
to store the slot information one by one
Kaslr extended kernel text mapping region size from 512M to 1G,
namely CONFIG_RANDOMIZE_BASE_MAX_OFFSET. This means kernel text
can be mapped to below region:
[__START_KERNEL_map + LOAD_PHYSICAL_ADDR, __START_KERNEL_map + 1G]
Introduce a function find_random_virt_offset() to get random value
betw
Add two functions mem_min_overlap() and store_slot_info() which will be
used later.
Given a memory region mem_min_overlap will iterate all avoid region to
find the first one which overlap with it.
store_slot_info() calculates the slot info of passed in region and
store it into slot_areas[].
Sign
On Sun, Mar 01, 2015 at 11:41:26PM +0100, Stefan Agner wrote:
...
> Stefan Agner (3):
> irqchip: vf610-mscm-ir: add support for MSCM interrupt router
> irqchip: vf610-mscm: dt-bindings: add MSCM bindings
> ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)
>
> .../arm/freescale
Several auxiliary functions and slots[] are not needed any more since
struct slot_area is used to store the slot info of kaslr now. Hence
remove them in this patch.
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/aslr.c | 24
1 file changed, 24 deletions(-)
diff
On x86_64, in old kaslr implementaion only physical address of kernel
loading is randomized. Then calculate the delta of physical address
where vmlinux was linked to load and where it is finally loaded. If
delta is not equal to 0, namely there's a new physical address where
kernel is actually decom
In kaslr implementation mechanism, mainly process_e820_entry and
slots_fetch_random do the job. process_e820_entry is responsible
for storing the slot information. slots_fetch_random takes care
of fetching slot information. In this patch, for adding support
of kernel physical address randomization
When process 32 bit relocation tables a local variable extended is
defined to calculate the physical address of relocs entry. However
it's type is int which is enough for i386, for x86_64 not enough.
That's why relocation can only be handled when kernel is loaded
below 2G, otherwise a overflow will
On Sat, Mar 07, 2015 at 07:42:47PM +0800, Duson Lin wrote:
> The resume function always return success, so stop event can not be
> triggered when "suspend_stress_test" running. In order to debug more
> easily, we add some error messages in elan_enable_power and
> elan_disable_power funtion.
>
> Si
On Sat, Mar 07, 2015 at 09:21:02PM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Mar 04, 2015 at 02:47:42PM -0800, Dmitry Torokhov wrote:
> > [...]
> > > >Do you want it to go through my or MFD tree?
> > > Other drivers merged in each maintainers git.
>
> Actually only Lee took PATCH 1 so far
On Sat, Mar 07, 2015 at 11:38:55PM +0100, Paul Bolle wrote:
> On Sat, 2015-03-07 at 14:26 -0800, Dmitry Torokhov wrote:
> > On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote:
> > I was talking about them being treated differently from technological
> > standpoint (i.e. the code), not from legal on
Lee,
On Wed, Feb 18, 2015 at 03:13:56PM +, Lee Jones wrote:
> Rebased (again) and resending.
>
> This driver enables IRQs which are controlled using System Configuration
> registers. Without it Performance Monitoring, Core Sight Tracing and some
> L2 Caches will fail to function.
>
> v2 =
Geert,
On Thu, Feb 26, 2015 at 11:43:32AM +0100, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/irqchip/irq-renesas-irqc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied to irqchip/core several days ago (my mailserver was down).
thx,
Jason.
I used usb cdrom emulation to play video dvd for my daughter, but I got below
error:
[dave@darkstar tmp]$ cat /mnt/sr1/VIDEO_TS/VTS_01_5.VOB >/dev/null
cat: /mnt/sr1/VIDEO_TS/VTS_01_5.VOB: Input/output error
[dave@darkstar tmp]$ dmesg|tail -1
[ 3349.371857] sr1: rw=0, want=8028824, limit=4607996
Hi Mathias,
On Fri, Feb 27, 2015 at 12:20:07AM +0100, Mathias Gottschlag wrote:
> These PS/2 commands make some touchpads stop responding, so this commit
> adds some dummy functions to replace the generic implementation. Because
> @@ -60,6 +65,7 @@ struct psmouse {
>
> unsigned int rate;
>
Hi Yong Wu,
Thanks for this series. Please see my comments inline.
On Fri, Mar 6, 2015 at 7:48 PM, wrote:
> From: Yong Wu
>
> This patch adds support for mediatek m4u (MultiMedia Memory Management Unit).
> Currently this only supports m4u gen 2 with 2 levels of page table on mt8173.
[snip]
>
Some code to reproduce this is at https://github.com/craig65535/mcast-exmpl.
The kernel module hooks TCP connects via a jprobe, and multicasts a
generic netlink message on every connect. So after insmod'ing the
module, just connect anywhere to send a multicast.
The client receives multicasts, eve
From: Guenter Roeck
Date: Fri, 6 Mar 2015 22:23:51 -0800
> EEE configuration is similar for the various MV88E6xxx chips.
> Add generic support for it.
>
> Signed-off-by: Guenter Roeck
> Reviewed-by: Florian Fainelli
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-
From: Guenter Roeck
Date: Fri, 6 Mar 2015 22:23:52 -0800
> Enable EEE support for MV88E6352.
>
> Signed-off-by: Guenter Roeck
Applied.
--
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:
Fixed some codeing style issues.
Signed-off-by: hmsjwzb
---
drivers/net/ieee802154/mrf24j40.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index fba2dfd..d35c7a0 100644
--- a/drivers
From: Boris Brezillon
Date: Sat, 7 Mar 2015 07:23:28 +0100
> The rm9200 boards use the dedicated at91_ether driver instead of the
> regular macb driver.
>
> Both the macb and at91_ether drivers can be compiled as separated
> modules.
> Since the at91_ether driver uses code from the macb driver,
Allocating a large number of elements in atomic context could quickly
deplete memory reserves, so just disallow atomic resizing entirely.
Nothing currently uses mempool_resize() with anything other than
GFP_KERNEL, so convert existing callers to drop the gfp_mask.
Signed-off-by: David Rientjes
-
fixed a coding style issue
Signed-off-by: weizhewang
---
sound/soc/codecs/rt5670.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5670.c b/sound/soc/codecs/rt5670.c
index fd10261..11ced93 100644
--- a/sound/soc/codecs/rt5670.c
+++ b/sound/soc/codecs/rt5
On Sat, Mar 07, 2015 at 06:53:46PM -0800, David Rientjes wrote:
> blk_init_rl() allocates a mempool using mempool_create_node() with node
> local memory. This only allocates the mempool and element list locally
> to the requeue queue node.
>
> What we really want to do is allocate the request its
blk_init_rl() allocates a mempool using mempool_create_node() with node
local memory. This only allocates the mempool and element list locally
to the requeue queue node.
What we really want to do is allocate the request itself local to the
queue. To do this, we need our own alloc and free functi
On Sat, 2015-03-07 at 12:56 -0500, Adrian Remonda wrote:
> Signed-off-by: Adrian Remonda
[]
> diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c
[]
> +static void hexDump(const void *src, size_t length, size_t bLine, char
> *prefix)
> +{
Is there something necessary t
Hi,
On Fri, Mar 06, 2015 at 04:03:27PM +0530, Jenny TC wrote:
> At present charger manager support only regulator based charging
> control. But most of the charger drivers are registered with power
> supply subsystem. This patch adds support for power supply based
> charging control along with the
On Sat, 7 Mar 2015, Yinghai Lu wrote:
> Now we are using memblock to do early resource reserver/allocation
> instead of using e820 map directly, and setup_data is reserved in
> memblock early already.
> Also kexec generate setup_data and pass pointer to second kernel,
> so second kernel reserve se
Hi,
On Fri, Mar 06, 2015 at 04:03:26PM +0530, Jenny TC wrote:
> Introduce power_supply charger control interfaces to control
> charging from charging framework like charger-manager. The interfaces
> are similar to the existing power supply get/set interfaces, but
> introduce a different set of pro
On 03/07/2015 06:27 PM, David Rientjes wrote:
> On Sat, 7 Mar 2015, Jens Axboe wrote:
>
> mempool_alloc() does not support __GFP_ZERO since elements may come from
> memory that has already been released by mempool_free().
>
> Remove __GFP_ZERO from mempool_alloc() in drbd_req_new()
On Sat, Mar 07, 2015 at 12:53:14PM -0800, Linus Torvalds wrote:
> On Sat, Mar 7, 2015 at 12:44 PM, Al Viro wrote:
> >
> > Most of the catch consists of ->poll() instances that return -E...; there's
> > also an unpleasant mess in net/9p/trans_fd.c and a braino in sunrpc
> > unexpectedly caught by t
Hi,
On Fri, Mar 06, 2015 at 12:12:50PM +0100, Oliver Neukum wrote:
> On Fri, 2015-03-06 at 16:03 +0530, Jenny TC wrote:
> > +struct psy_temp_mon_table {
> > + int temp_max;
> > + int temp_min;
> > + int charging_current; /* CC */
> > + int charging_voltage; /* CV */
>
> In which units?
F
On Sat, 7 Mar 2015, Jens Axboe wrote:
> >>> mempool_alloc() does not support __GFP_ZERO since elements may come from
> >>> memory that has already been released by mempool_free().
> >>>
> >>> Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly
> >>> initialize it to 0.
> >>
> >>
On 03/07/2015 05:53 PM, David Rientjes wrote:
> On Sat, 7 Mar 2015, Jens Axboe wrote:
>
>>> mempool_alloc() does not support __GFP_ZERO since elements may come from
>>> memory that has already been released by mempool_free().
>>>
>>> Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and pro
Now setup_data is reserved via memblock and e820 and different
handlers have different ways, and it is confusing.
1. SETUP_E820_EXT: is consumed early and will not copy or access again.
have memory wasted.
2. SETUP_EFI: is accessed via ioremap every time at early stage.
have memory
Hi,
On Fri, Mar 06, 2015 at 04:03:24PM +0530, Jenny TC wrote:
> Charging current (CC) and charging voltage (CV) may vary based on
> battery temperature. To support CC and CV for different temperature
> zones, defined a charging object which holds the properties related
> to battery charging.
>
>
So we could avoid ioremap every time later.
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/pci.h | 2 ++
arch/x86/kernel/setup.c| 1 +
arch/x86/pci/common.c | 77 +-
3 files changed, 65 in
Cc: Matt Fleming
Signed-off-by: Yinghai Lu
---
arch/x86/kernel/kdebugfs.c | 142 -
arch/x86/kernel/setup.c| 17 --
2 files changed, 159 deletions(-)
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404b..c8ca86c 1
We will not reserve setup_data in generic code. Every handler need to
reserve and copy setup_data locally.
Current dtd handling already have code for copying, just add reserve code.
Also simplify code a bit by storing real dtb size.
Cc: Rob Herring
Cc: David Vrabel
Signed-off-by: Yinghai Lu
-
So we could let kexec-tools to rebuild SETUP_PCI and pass it to
second kernel if needed.
Now kexec-tools already build SETUP_EFI and SETUP_E820EXT.
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/pci/common.c | 175
Let it reserve setup_data, and keep it's own list.
Also clear the hdr.setup_data, as all handler now handle or
reserve setup_data locally already.
Cc: Bjorn Helgaas
Cc: Matt Fleming
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/pci.h | 2 ++
arch/x86/kernel
The copy will be in __initdata, and it is small.
We can use pointer to access the setup_data instead of using early_memmap
everywhere.
Cc: Matt Fleming
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/efi.h | 2 +-
arch/x86/platform/efi/efi.c| 13 ++
As EFI stub code could put them high when on 32bit or with exactmap=
on 64bit conf.
Check if the range is mapped, otherwise allocate new one and have
the rom data copied. So we could access them directly.
Signed-off-by: Yinghai Lu
---
arch/x86/pci/common.c | 47 +
Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec generate setup_data and pass pointer to second kernel,
so second kernel reserve setup_data by their own.
(Now kexec-tools create SE
On Sun, Mar 08, 2015 at 01:01:14AM +0100, Rafał Miłecki wrote:
> Thanks for your work on this. It looks amazing, nice piece of code :)
Thanks :) And thanks for testing this. I believe I suggested to you that
I'd be releasing this "soon" several months ago. Better late than never,
I guess?
> On 7
On Sat, 7 Mar 2015, Jens Axboe wrote:
> > mempool_alloc() does not support __GFP_ZERO since elements may come from
> > memory that has already been released by mempool_free().
> >
> > Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly
> > initialize it to 0.
>
> You should add
The copy will be in __initdata, and it is small.
We can use pointer to access the setup_data instead of using early_memmap
everywhere.
Cc: Matt Fleming
Cc: linux-...@vger.kernel.org
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/efi.h | 2 +-
arch/x86/platform/efi/efi.c| 13 ++
Now we are using memblock to do early resource reserver/allocation
instead of using e820 map directly, and setup_data is reserved in
memblock early already.
Also kexec generate setup_data and pass pointer to second kernel,
so second kernel reserve setup_data by their own.
(Now kexec-tools create SE
Now setup_data is reserved via memblock and e820 and different
handlers have different ways, and it is confusing.
1. SETUP_E820_EXT: is consumed early and will not copy or access again.
have memory wasted.
2. SETUP_EFI: is accessed via ioremap every time at early stage.
have memory
On Saturday, March 07, 2015 12:29:33 PM Pavel Machek wrote:
> On Sat 2015-03-07 12:06:45, Alexandre Belloni wrote:
> > On 07/03/2015 at 11:39:39 +0100, Pavel Machek wrote :
> > > > The Atmel watchdog can't be stopped once it's started. This is actually
> > > > very useful so we can reset if suspen
On Saturday, March 07, 2015 12:06:45 PM Alexandre Belloni wrote:
> On 07/03/2015 at 11:39:39 +0100, Pavel Machek wrote :
> > > The Atmel watchdog can't be stopped once it's started. This is actually
> > > very useful so we can reset if suspend or resume failed, the only
> > > drawback is that you
Mempools created for kmalloc caches should use
mempool_create_kmalloc_pool().
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Neil Brown
Signed-off-by: David Rientjes
---
drivers/md/dm-log-userspace-base.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drive
On 7 March 2015 at 18:39, Rafał Miłecki wrote:
> It seems that brcmnand_ctlrdy_irq never fires on my device. Just like
> controller was never generating any IRQ.
>
>
> I started comparing your driver with OpenWrt's bcm_nand.c (which
> should be very similar to Broadcom's SDK NAND driver for ARM).
On 03/07/2015 05:24 PM, David Rientjes wrote:
mempool_alloc() does not support __GFP_ZERO since elements may come from
memory that has already been released by mempool_free().
Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly
initialize it to 0.
You should add it to mempool
From: Oleg Drokin
This patch continues to further remove deprecated functions, such as
any_online_cpu, for_each_cpu_mask and also cleaning up
usage of NR_CPUS in a few places
Signed-off-by: Oleg Drokin
---
.../staging/lustre/lustre/libcfs/linux/linux-cpu.c | 32 --
1 file c
From: Oleg Drokin
cpus_weight and for_each_cpu_mask are deprecated, so replace them
with cpumask_weight and for_each_cpu respectively.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
From: Lai Siyao
ll_intent_drop_lock() may sleep in memory allocation, which
should not be called inside spinlock.
Signed-off-by: Lai Siyao
Signed-off-by: Jian Yu
Reviewed-on: http://review.whamcloud.com/10674
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2272
Signed-off-by: Oleg Drokin
From: Oleg Drokin
The first two patches are a follow on for the previous patch series
on not using deprecated cpumask-related code.
And two blocking while atomic/not running fixes.
Please consider.
Lai Siyao (1):
staging/lustre/llite: avoid nonatomic memory alloc under spinlock
Oleg Drokin
From: Oleg Drokin
Move setting of TASK_INTERRUPTIBLE just around schedule call in
libcfs_sock_accept.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/libcfs/linux/linux-tcpip.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lu
Mempools created for slab caches should use
mempool_create_slab_pool().
Cc: Lars Ellenberg
Cc: Jens Axboe
Signed-off-by: David Rientjes
---
drivers/block/drbd/drbd_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/d
mempool_alloc() does not support __GFP_ZERO since elements may come from
memory that has already been released by mempool_free().
Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly
initialize it to 0.
Cc: Lars Ellenberg
Cc: Jens Axboe
Signed-off-by: David Rientjes
---
drive
On 3/6/15 5:09 PM, Steven Rostedt wrote:
On Wed, 4 Mar 2015 15:48:24 -0500
Steven Rostedt wrote:
On Wed, 4 Mar 2015 21:33:16 +0100
Ingo Molnar wrote:
* Alexei Starovoitov wrote:
On Sun, Mar 1, 2015 at 3:27 PM, Alexei Starovoitov wrote:
Peter, Steven,
I think this set addresses everyth
مرحبا عزيزي،
أنا ميريام
راجحة، اتصلت
لك بقلب مثقل
بسبب الصراع
أو العنف في
بلدي سوريا،
حيث كانت هناك
اعتقالات
والجماعية
شعبي البلاد
مما أسفر عن
مقتل بسبب
الهجمات بين
الحكومة و
المعار&#
1590;ة المعروفة
باسم
الائتلاف
الوطني لقوى
الثورة
والمعارضة
السورية.
بسبب العلاقة
الوثيقة بين
Hi Brian,
Thanks for your work on this. It looks amazing, nice piece of code :)
On 7 March 2015 at 02:18, Brian Norris wrote:
> This adds (long in coming) support for the Broadcom BCM7xxx Set-Top Box NAND
> controller. This controller has been used in a variety of Broadcom SoCs.
>
> There are a
Mempools created for slab caches should use
mempool_create_slab_pool().
Signed-off-by: David Rientjes
---
arch/sh/kernel/dwarf.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/sh/kernel/dwarf.c b/arch/sh/kernel/dwarf.c
--- a/arch/sh/kernel/dwarf.c
+++ b/arc
dwarf_reg_pool and dwarf_frame_pool are not properly destroyed when
cleaning up the dwarf unwinder. Destroy them with mempool_destroy().
Also mark dwarf_unwinder_cleanup() as __init.
Signed-off-by: David Rientjes
---
arch/sh/kernel/dwarf.c | 6 +-
1 file changed, 5 insertions(+), 1 deletio
Liebe Begünstigte,
Sie wurden ausgewählt, um (€950.000,00 EURO) als Charity-Spenden / Hilfe der
Qatar Foundation erhalten. Kontaktieren Sie uns über E-Mail für weitere
Informationen;
Mit freundlichen Grüßen,
Ingenieur Saad Al Muhannadi.
Kontakt e-mail: saadalm...@gmail.com
Präsident der Qata
Hi,
On Fri, Feb 27, 2015 at 01:40:44PM +0100, Pali Rohár wrote:
> > However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
> > is not set:
> >
> > alg: hash: Chunking test 1 failed for omap-sha1
> > alg: hash: Chunking test 1 failed for omap-md5
> > alg: hash: Chunking test 1 fa
On Wed, 25 Feb 2015 16:39:59 +0800
, Hanjun Guo
wrote:
> From: Graeme Gregory
>
> Add Kconfigs to build ACPI on ARM64, and make ACPI available on ARM64.
>
> acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
> depend on X86 || IA64, and implement it on ARM64 in the futur
On Wed, 25 Feb 2015 16:39:58 +0800
, Hanjun Guo
wrote:
> From: Al Stone
>
> ACPI reduced hardware mode is disabled by default, but ARM64
> can only run properly in ACPI hardware reduced mode, so select
> ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64.
>
> CC: Catalin Marinas
> CC: Wil
On Wed, 25 Feb 2015 16:39:57 +0800
, Hanjun Guo
wrote:
> Using the information presented by GTDT (Generic Timer Description Table)
> to initialize the arch timer (not memory-mapped).
>
> CC: Daniel Lezcano
> CC: Thomas Gleixner
> Originally-by: Amit Daniel Kachhap
> Tested-by: Suravee Suthiku
On Wed, 25 Feb 2015 16:39:56 +0800
, Hanjun Guo
wrote:
> From: Tomasz Nowicki
>
> ACPI kernel uses MADT table for proper GIC initialization. It needs to
> parse GIC related subtables, collect CPU interface and distributor
> addresses and call driver initialization function (which is hardware
>
On Sat, Mar 07, 2015 at 12:25:29PM -0300, Gustavo Bittencourt wrote:
> On Sat, Mar 7, 2015 at 11:15 AM, Sebastian Andrzej Siewior
> wrote:
> >
> > I'm pleased to announce the v3.18.9-rt4 patch set.
> >
> > Changes since v3.18.9-rt3
> >
>
> Has v3.18.9-rt3 been released? If so, I missed the announ
On Sat, 2015-03-07 at 15:21 +, Lad Prabhakar wrote:
> --- /dev/null
> +++ b/drivers/media/i2c/ov2659.c
> @@ -0,0 +1,1495 @@
> +/*
> + * Omnivision OV2659 CMOS Image Sensor driver
> + *
> + * Copyright (C) 2015 Texas Instruments, Inc.
> + *
> + * Benoit Parrot
> + * Lad, Prabhakar
> + *
> + *
On Wed, 25 Feb 2015 16:39:55 +0800
, Hanjun Guo
wrote:
> Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
> used, and then register device's gsi with the core IRQ subsystem.
>
> acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
> since gsi is unique in the system
On Wed, 25 Feb 2015 16:39:54 +0800
, Hanjun Guo
wrote:
> Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
> from the GICC Structure introduced by ACPI 5.1.
>
> The ARM architecture defines the MPIDR register as the CPU hardware
> identifier. This patch adds the code infra
Thomas,
Here's a small round of changes for the next merge window.
Please pull.
thx,
Jason.
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.infradead.org/users/jcoop
On Wed, 25 Feb 2015 16:39:53 +0800
, Hanjun Guo
wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_m
On Sat, 2015-03-07 at 14:26 -0800, Dmitry Torokhov wrote:
> On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote:
> I was talking about them being treated differently from technological
> standpoint (i.e. the code), not from legal one.
>From a technological standpoint it would be easy to declare "GP
On March 7, 2015 2:12:20 PM PST, Paul Bolle wrote:
>On Sat, 2015-03-07 at 14:02 -0800, Dmitry Torokhov wrote:
>> On March 7, 2015 1:54:41 PM PST, Paul Bolle
>wrote:
>> >By that logic we might as well simplify the logic of
>> >license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why
>chec
On Sat, 2015-03-07 at 13:35 +0200, Alexander Shishkin wrote:
> Documentation/ABI/testing/configfs-stp-policy| 44 ++
git am whined about this file when I tried to apply this patch:
Applying: stm class: Introduce an abstraction for System Trace Module
devices
[...]/.git/rebase-apply/p
On Fri, Feb 06, 2015 at 09:46:52PM +0100, Angelo Dureghello wrote:
Dear all,
i was using the public x86 32bit toolchain from kernel.org:
https://www.kernel.org/pub/tools/crosstool/files/bin/i686/4.6.3/i686-gcc-4.6.3-nolibc_m68k-linux.tar.gz
Unfortunately, for ColdFire arch, there is a bug in
On 7 March 2015 at 02:18, Brian Norris wrote:
> +static int brcmnand_waitfunc(struct mtd_info *mtd, struct nand_chip *this)
> +{
> + struct nand_chip *chip = mtd->priv;
> + struct brcmnand_host *host = chip->priv;
> + struct brcmnand_controller *ctrl = host->ctrl;
> + unsig
On Wed, Feb 25, 2015 at 7:25 PM, David Cohen
wrote:
> In my case [1] I need 2 "virtual devices" (and more in future) to be
> part of an USB OTG port control. I call it virtual because they are too
> simple components connected to no bus and controlled by GPIOs:
> - a fixed regulator controlled by
On Sat, 2015-03-07 at 14:02 -0800, Dmitry Torokhov wrote:
> On March 7, 2015 1:54:41 PM PST, Paul Bolle wrote:
> >By that logic we might as well simplify the logic of
> >license_is_gpl_compatible() and MODULE_LICENSE() quite a bit. Why check
> >for six variants instead of just one and be done with
A patch referenced in:
https://lkml.org/lkml/2014/1/15/253
is in mainline (3.19 kernel). However this patch is not in
longterm (3.10 kernel). There is a bug report related to
this issue in:
https://bugzilla.kernel.org/show_bug.cgi?id=94181
by a user that is running a 3.10.x kernel.
It would
Boris found data from boot stage can not be used kernel stage.
Bootloader allocate buffer according to init_size in hdr, and load the
ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
During running of ZO, ZO move itself to the middle of buffer at
z_extract_offset to make sure that
We need to include that in boot::decompress_kernel stage to set new
ident mapping.
Also add checking for __pa/__va macro definition, as we need to override them
in boot::decompress_kernel stage.
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/page.h | 5 +++
arch/x86/mm/ident_map.c | 74
Commit
f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
started passing KASLR status to kernel proper, but it uses a physical
address as the vaule, leading to parsing bogus KASLR status in kernel
proper.
The setup_data linked list and thus the element which contains
kaslr_
Now ZO sit end of the buffer, we can find out where is ZO text
and data/bss etc.
[input, input+input_size) is copied compressed kernel, not the whole ZO.
[output, output+init_size) is the buffer for VO.
[input+input_size, output+init_size) is [_text, _end) for ZO.
that could be first range in mem
First, aslr will support to put random VO above 4G, so we must set ident
mapping for the range even we come from startup_32 path.
Second, when boot from 64bit bootloader, bootloader set ident mapping,
and boot via ZO (arch/x86/boot/compressed/vmlinux) startup_64.
Those pages for pagetable need to
commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
introduced one run_size for kaslr.
We should use real runtime size (include copy/decompress) aka init_size.
run_size is VO (vmlinux) init size include bss and brk.
init_size is the size needed for decompress and it is bigger t
Boris found data from boot stage can not be used kernel stage.
Bootloader allocate buffer according to init_size in hdr, and load the
ZO (arch/x86/boot/compressed/vmlinux) from start of that buffer.
During running of ZO, ZO move itself to the middle of buffer at
z_extract_offset to make sure that
First 3 patches make ZO (arch/x86/boot/compressed/vmlinux) data region is not
overwritten by VO (vmlinux) after decompress. So could pass data from ZO to VO.
The 4th one is fixing kaslr_enabled accessing. Old code is using address
as value wrongly.
Last 3 patches are the base for kaslr supportin
On March 7, 2015 1:54:41 PM PST, Paul Bolle wrote:
>On Sat, 2015-03-07 at 13:25 -0800, Dmitry Torokhov wrote:
>> I am not sure if anyone cares about exact version of GPL in module
>> information (2 only vs 2+) since it only used to figure out if the
>> module taints kernel or not. In fact there ar
Hi Prabhakar,
On Sat, Mar 07, 2015 at 03:21:40PM +, Lad Prabhakar wrote:
> + pixel-clock-frequency = <7000>;
As commented privately, could you use the link-frequencies property for this
purpose? On parallel bus if often equals the pixel clock, but works
On Sat, 2015-03-07 at 13:25 -0800, Dmitry Torokhov wrote:
> I am not sure if anyone cares about exact version of GPL in module
> information (2 only vs 2+) since it only used to figure out if the
> module taints kernel or not. In fact there are more modules that are v2
> only that claim GPL than th
On Sat, Mar 07, 2015 at 06:48:21PM +, Alexander Gordeev wrote:
> On Sat, Mar 07, 2015 at 09:42:34AM -0800, Paul E. McKenney wrote:
> > On Sat, Mar 07, 2015 at 06:03:36PM +0100, Alexander Gordeev wrote:
> > > Currently a condition when RCU tree is unable to accommodate
> > > the configured numbe
1 - 100 of 373 matches
Mail list logo
