NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

Hi, This seems non-exploitable due to mmap_min_addr, so I guess it should be treated just as a regular bug Tested with 4.5-rc4 and with 4.4 under Opteron 6272 and FX-8320 [167193.153283] BUG: unable to handle kernel NULL pointer dereference at 00f0 [167193.153372] IP: []

NULL-ptr deref in kvm_arch_vcpu_ioctl under AMD CPUs

Hi, This seems non-exploitable due to mmap_min_addr, so I guess it should be treated just as a regular bug Tested with 4.5-rc4 and with 4.4 under Opteron 6272 and FX-8320 [167193.153283] BUG: unable to handle kernel NULL pointer dereference at 00f0 [167193.153372] IP: []

Re: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA + gfp=0

On Fri, Feb 19, 2016 at 09:12:04AM +0100, Rabin Vincent wrote: > Given a device which uses arm_coherent_dma_ops and on which > dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA > API with gfp=0 results in a memory leak and memory corruption. > > p = dma_alloc_coherent(dev,

Re: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA + gfp=0

On Fri, Feb 19, 2016 at 09:12:04AM +0100, Rabin Vincent wrote: > Given a device which uses arm_coherent_dma_ops and on which > dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA > API with gfp=0 results in a memory leak and memory corruption. > > p = dma_alloc_coherent(dev,

Re: [PATCH 5/8] arm64: kprobes instruction simulation support

Hi David, On 18/02/16 23:48, David Long wrote: > From: Sandeepa Prabhu > > Kprobes needs simulation of instructions that cannot be stepped > from different memory location, e.g.: those instructions > that uses PC-relative addressing. In simulation, the behaviour >

Re: [PATCH 5/8] arm64: kprobes instruction simulation support

Hi David, On 18/02/16 23:48, David Long wrote: > From: Sandeepa Prabhu > > Kprobes needs simulation of instructions that cannot be stepped > from different memory location, e.g.: those instructions > that uses PC-relative addressing. In simulation, the behaviour > of the instruction is

Re: [PATCH v5 3/3] irqchip: add nps Internal and external irqchips

Hey Noam, Could you please re-send and attach a changelog: On Thu, Feb 11, 2016 at 08:40:59PM +0200, Noam Camus wrote: > From: Noam Camus > > Adding EZchip NPS400 support. > NPS internal interrupts are internally handled at > Multi Thread Manager (MTM) that is signaled for

Re: [PATCH v5 3/3] irqchip: add nps Internal and external irqchips

Hey Noam, Could you please re-send and attach a changelog: On Thu, Feb 11, 2016 at 08:40:59PM +0200, Noam Camus wrote: > From: Noam Camus > > Adding EZchip NPS400 support. > NPS internal interrupts are internally handled at > Multi Thread Manager (MTM) that is signaled for deactivating > an

Re: Device probing proceeds even when the default pinctrl state is invalid

Hi Romain, On Fri, Feb 19, 2016 at 02:30:49PM +0100, romain izard wrote: > 2016-02-18 21:07 GMT+01:00 Linus Walleij : > > On Thu, Feb 18, 2016 at 11:37 AM, Romain Izard > > wrote: > > > >> The current code for device probing tries to map the

Re: Device probing proceeds even when the default pinctrl state is invalid

Hi Romain, On Fri, Feb 19, 2016 at 02:30:49PM +0100, romain izard wrote: > 2016-02-18 21:07 GMT+01:00 Linus Walleij : > > On Thu, Feb 18, 2016 at 11:37 AM, Romain Izard > > wrote: > > > >> The current code for device probing tries to map the default pinctrl > >> state (in pinctrl_bind_pins), but

Re: [PATCH 06/54] perf tools: Add API to config maps in bpf object

Sorry for the top post, but the message below didn't made it thru due to local problems as I recently switched notebooks, my postfix setup barfed this one :-\ This is what I have in my tmp.perf/bpf_map:

Re: [PATCH 06/54] perf tools: Add API to config maps in bpf object

Sorry for the top post, but the message below didn't made it thru due to local problems as I recently switched notebooks, my postfix setup barfed this one :-\ This is what I have in my tmp.perf/bpf_map:

Re: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA + gfp=0

On Fri, Feb 19 2016, Rabin Vincent wrote: > Given a device which uses arm_coherent_dma_ops and on which > dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA > API with gfp=0 results in a memory leak and memory corruption. > > p = dma_alloc_coherent(dev, sz, , 0); > if (p) >

Re: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA + gfp=0

On Fri, Feb 19 2016, Rabin Vincent wrote: > Given a device which uses arm_coherent_dma_ops and on which > dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA > API with gfp=0 results in a memory leak and memory corruption. > > p = dma_alloc_coherent(dev, sz, , 0); > if (p) >

[RFC v2 1/7] sections.h: add sections header to collect all section info

Linux makes extensive use of custom ELF header sections, documentation for these are well scatterred. Unify this documentation in a central place. Signed-off-by: Luis R. Rodriguez --- Documentation/DocBook/Makefile | 3 +- Documentation/DocBook/sections.tmpl | 99

[RFC v2 1/7] sections.h: add sections header to collect all section info

Linux makes extensive use of custom ELF header sections, documentation for these are well scatterred. Unify this documentation in a central place. Signed-off-by: Luis R. Rodriguez --- Documentation/DocBook/Makefile | 3 +- Documentation/DocBook/sections.tmpl | 99

[RFC v2 2/7] tables.h: add linker table support

A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications, per architecture. This adds a general linker

[RFC v2 4/7] asm/sections: add a generic push_section_tbl()

With a generic linker tables solution in place we need a general asm solution for declaring entries with asm. The first easy target is to cover the C asm declarations, guard the header file for now and define a first generic entry push_section_tbl() to be used later for custom linker table

[RFC v2 2/7] tables.h: add linker table support

A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications, per architecture. This adds a general linker

[RFC v2 4/7] asm/sections: add a generic push_section_tbl()

With a generic linker tables solution in place we need a general asm solution for declaring entries with asm. The first easy target is to cover the C asm declarations, guard the header file for now and define a first generic entry push_section_tbl() to be used later for custom linker table

[RFC v2 6/7] dynamic_debug: port to use linker tables

This removes the custom vmlinux.lds.h hacks and uses the generalized solution for .data (SECTION_DATA) entries. This is much more potential for further fine tuning here though in the future. For instance, linker tables enable an extra postfix for order level annotations, this could easily be used

[RFC v2 6/7] dynamic_debug: port to use linker tables

This removes the custom vmlinux.lds.h hacks and uses the generalized solution for .data (SECTION_DATA) entries. This is much more potential for further fine tuning here though in the future. For instance, linker tables enable an extra postfix for order level annotations, this could easily be used

[RFC v2 5/7] jump_label: port __jump_table to linker tables

Move the __jump_table from the a custom section solution to a generic solution, this avoiding extra vmlinux.lds.h customizations. This also demos the use of the .data (SECTION_DATA) linker tables and of push_section_tbl(). Signed-off-by: Luis R. Rodriguez ---

[RFC v2 5/7] jump_label: port __jump_table to linker tables

Move the __jump_table from the a custom section solution to a generic solution, this avoiding extra vmlinux.lds.h customizations. This also demos the use of the .data (SECTION_DATA) linker tables and of push_section_tbl(). Signed-off-by: Luis R. Rodriguez --- arch/arm/include/asm/jump_label.h

Re: [PATCH 1/2] mm: cma: split out in_cma check to separate function

On Fri, Feb 19 2016, Rabin Vincent wrote: > Split out the logic in cma_release() which checks if the page is in the > contiguous area to a new function which can be called separately. ARM > will use this. > > Signed-off-by: Rabin Vincent > --- > include/linux/cma.h | 12

[RFC v2 7/7] kprobes: port to linker table

kprobe makes use of two custom sections: type name beginend init.data _kprobe_blacklist __start_kprobe_blacklist__stop_kprobe_blacklist text .kprobes.text __kprobes_text_start__kprobes_text_end Port these to the linker table generic

Re: [PATCH 1/2] mm: cma: split out in_cma check to separate function

On Fri, Feb 19 2016, Rabin Vincent wrote: > Split out the logic in cma_release() which checks if the page is in the > contiguous area to a new function which can be called separately. ARM > will use this. > > Signed-off-by: Rabin Vincent > --- > include/linux/cma.h | 12 > mm/cma.c

[RFC v2 7/7] kprobes: port to linker table

kprobe makes use of two custom sections: type name beginend init.data _kprobe_blacklist __start_kprobe_blacklist__stop_kprobe_blacklist text .kprobes.text __kprobes_text_start__kprobes_text_end Port these to the linker table generic

Re: [PATCH v2] fusion-mptbase: handle failed allocation for workqueue

On 18.2.2016 17:55, Ewan Milne wrote: > On Thu, 2016-02-18 at 11:40 -0500, Ewan Milne wrote: >> It also appears to me upon further inspection that the existing code has >> other problems. In particular, once mpt_mapresources() has returned >> with a nonzero error code, it looks like iounmap()

Re: [PATCH v2] fusion-mptbase: handle failed allocation for workqueue

On 18.2.2016 17:55, Ewan Milne wrote: > On Thu, 2016-02-18 at 11:40 -0500, Ewan Milne wrote: >> It also appears to me upon further inspection that the existing code has >> other problems. In particular, once mpt_mapresources() has returned >> with a nonzero error code, it looks like iounmap()

[RFC v2 0/7] linux: add linker tables

This is my v2 of the original linker table work [0], now with six proof of concepts ports of existing code using custom section with custom linker script modifications: * DEFINE_LINKTABLE_TEXT(char, kprobes); * DEFINE_LINKTABLE_DATA(struct jump_entry, __jump_table); *

[RFC v2 0/7] linux: add linker tables

This is my v2 of the original linker table work [0], now with six proof of concepts ports of existing code using custom section with custom linker script modifications: * DEFINE_LINKTABLE_TEXT(char, kprobes); * DEFINE_LINKTABLE_DATA(struct jump_entry, __jump_table); *

[RFC v2 3/7] firmware: port built-in section to linker table

This ports built-in firmware to use linker tables, this replaces the custom section solution with a generic solution. This also demos the use of the .rodata (SECTION_RO) linker tables. Tested with 0 built-in firmware, 1 and 2 built-in firmwares successfully. Signed-off-by: Luis R. Rodriguez

[RFC v2 3/7] firmware: port built-in section to linker table

This ports built-in firmware to use linker tables, this replaces the custom section solution with a generic solution. This also demos the use of the .rodata (SECTION_RO) linker tables. Tested with 0 built-in firmware, 1 and 2 built-in firmwares successfully. Signed-off-by: Luis R. Rodriguez

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

Hi all, On Wed, 10 Feb 2016 11:58:12 + Juri Lelli wrote: [...] > > > } else if (!dl_policy(policy) && task_has_dl_policy(p)) { > > > __dl_clear(dl_b, p->dl.dl_bw); > > > + __dl_sub_ac(task_rq(p), p->dl.dl_bw); > > > > Instead of adding __dl_add_ac()

Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth

Hi all, On Wed, 10 Feb 2016 11:58:12 + Juri Lelli wrote: [...] > > > } else if (!dl_policy(policy) && task_has_dl_policy(p)) { > > > __dl_clear(dl_b, p->dl.dl_bw); > > > + __dl_sub_ac(task_rq(p), p->dl.dl_bw); > > > > Instead of adding __dl_add_ac() and __dl_sub_ac)

Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

On 19/02/16 13:08, Luis R. Rodriguez wrote: > Although hardware_subarch has been in place since the x86 boot > protocol 2.07 it hasn't been used much. Enumerate current possible > values to avoid misuses and help with semantics later at boot > time should this be used further. > > Cc: Andy

Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

On 19/02/16 13:08, Luis R. Rodriguez wrote: > Although hardware_subarch has been in place since the x86 boot > protocol 2.07 it hasn't been used much. Enumerate current possible > values to avoid misuses and help with semantics later at boot > time should this be used further. > > Cc: Andy

[PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

This commits adds a new irqchip driver that handles the ODMI controller found on Marvell 7K/8K processors. The ODMI controller provide MSI interrupt functionality to on-board peripherals, much like the GIC-v2m. Signed-off-by: Thomas Petazzoni --- Changes v2

[PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on Marvell 7K/8K

This commits adds a new irqchip driver that handles the ODMI controller found on Marvell 7K/8K processors. The ODMI controller provide MSI interrupt functionality to on-board peripherals, much like the GIC-v2m. Signed-off-by: Thomas Petazzoni --- Changes v2 -> v2: - Express NODMIS_SHIFT,

Re: [Xen-devel] [PATCH 0/9] x86/init: replace paravirt_enabled() were possible

On 19/02/16 13:08, Luis R. Rodriguez wrote: > I originally set out to rename paravirt_enabled() to paravirt_legacy() > but we instead decided to remove paravirt_enabled() completely. Although > I have some linker table work which will help make this cleaner, instead > of waiting for that to go in,

Re: [Xen-devel] [PATCH 0/9] x86/init: replace paravirt_enabled() were possible

On 19/02/16 13:08, Luis R. Rodriguez wrote: > I originally set out to rename paravirt_enabled() to paravirt_legacy() > but we instead decided to remove paravirt_enabled() completely. Although > I have some linker table work which will help make this cleaner, instead > of waiting for that to go in,

Re: Device probing proceeds even when the default pinctrl state is invalid

2016-02-18 21:07 GMT+01:00 Linus Walleij : > On Thu, Feb 18, 2016 at 11:37 AM, Romain Izard > wrote: > >> The current code for device probing tries to map the default pinctrl >> state (in pinctrl_bind_pins), but is returning 0 or -EDEFER. If

Re: Device probing proceeds even when the default pinctrl state is invalid

2016-02-18 21:07 GMT+01:00 Linus Walleij : > On Thu, Feb 18, 2016 at 11:37 AM, Romain Izard > wrote: > >> The current code for device probing tries to map the default pinctrl >> state (in pinctrl_bind_pins), but is returning 0 or -EDEFER. If there >> is an other error, it is not reported. This

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On 19/02/16 13:08, Luis R. Rodriguez wrote: > The current check is a super long winded way of asking if this > is on lguest. The flags is used for legacy features, this is > likely inspired by the ACPI IA-PC boot architecture flags, where > as for RTC it annotates No CMOS real-time clock present.

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On 19/02/16 13:08, Luis R. Rodriguez wrote: > The current check is a super long winded way of asking if this > is on lguest. The flags is used for legacy features, this is > likely inspired by the ACPI IA-PC boot architecture flags, where > as for RTC it annotates No CMOS real-time clock present.

[GIT PULL] irqchip changes for v4.5

Thomas, Hopefully the last fix for this cycle. :-) Please pull. thx, Jason. The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://git.infradead.org/users/jcooper/linux.git

[GIT PULL] irqchip changes for v4.5

Thomas, Hopefully the last fix for this cycle. :-) Please pull. thx, Jason. The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://git.infradead.org/users/jcooper/linux.git

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On 19/02/16 14:08, Luis R. Rodriguez wrote: > The current check is a super long winded way of asking if this > is on lguest. The flags is used for legacy features, this is What about Xen pv-domU? I wouldn't expect those to have PV_SUPPORTED_RTC set. Juergen > likely inspired by the ACPI IA-PC

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On 19/02/16 14:08, Luis R. Rodriguez wrote: > The current check is a super long winded way of asking if this > is on lguest. The flags is used for legacy features, this is What about Xen pv-domU? I wouldn't expect those to have PV_SUPPORTED_RTC set. Juergen > likely inspired by the ACPI IA-PC

Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

On 19/02/16 14:08, Luis R. Rodriguez wrote: > Although hardware_subarch has been in place since the x86 boot > protocol 2.07 it hasn't been used much. Enumerate current possible > values to avoid misuses and help with semantics later at boot > time should this be used further. > > Cc: Andy

Re: [Xen-devel] [PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

On 19/02/16 14:08, Luis R. Rodriguez wrote: > Although hardware_subarch has been in place since the x86 boot > protocol 2.07 it hasn't been used much. Enumerate current possible > values to avoid misuses and help with semantics later at boot > time should this be used further. > > Cc: Andy

Re: [PATCH] ARM: dts: at91: sama5d2 Xplained: Correct the macb irq pinctrl node

On Thu, Feb 18, 2016 at 11:21:06AM +0100, Romain Izard wrote: > All pinctrl nodes for the Atmel pinctrl controller need to have their > bias configuration explicitly defined. Otherwise, the pinctrl mapping > is not valid. > > It works for now as the pinctrl driver proceeds even with invalid >

Re: [PATCH] ARM: dts: at91: sama5d2 Xplained: Correct the macb irq pinctrl node

On Thu, Feb 18, 2016 at 11:21:06AM +0100, Romain Izard wrote: > All pinctrl nodes for the Atmel pinctrl controller need to have their > bias configuration explicitly defined. Otherwise, the pinctrl mapping > is not valid. > > It works for now as the pinctrl driver proceeds even with invalid >

[PATCH 3/9] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten.c

[PATCH 3/9] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index

[PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. Cc: Andy Shevchenko Signed-off-by:

[PATCH 1/9] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. Cc: Andy Shevchenko Signed-off-by: Luis R. Rodriguez ---

[PATCH 4/9] x86/init: make ebda depend on PC subarch

This lets us remove its use of paravirt_enabled(). The other subarchs are not needed here given that on 32-bit there is a switch already that negates access to this code on X86_SUBARCH_INTEL_MID, and X86_SUBARCH_CE4100. Both lguest and Xen had paravirt_enabled so that excludes them.

[PATCH 4/9] x86/init: make ebda depend on PC subarch

This lets us remove its use of paravirt_enabled(). The other subarchs are not needed here given that on 32-bit there is a switch already that negates access to this code on X86_SUBARCH_INTEL_MID, and X86_SUBARCH_CE4100. Both lguest and Xen had paravirt_enabled so that excludes them.

[PATCH 6/9] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled() and both Xen and lguest never set this. This check is not needed. Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/tboot.c | 6 -- 1 file changed, 6 deletions(-) diff --git

[PATCH 6/9] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled() and both Xen and lguest never set this. This check is not needed. Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/tboot.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/x86/kernel/tboot.c

[PATCH 7/9] x86/cpu/intel: replace paravirt_enabled() for f00f work around

Use the harware subarch instead now that they are set. If we want to test removing this work around on Xen we can do so separatley as another independent change, for now we just want to remove paravirt_enabled(). Signed-off-by: Luis R. Rodriguez ---

[PATCH 7/9] x86/cpu/intel: replace paravirt_enabled() for f00f work around

Use the harware subarch instead now that they are set. If we want to test removing this work around on Xen we can do so separatley as another independent change, for now we just want to remove paravirt_enabled(). Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/cpu/intel.c | 4 +++- 1 file

[PATCH 9/9] pnpbios: replace paravirt_enabled() check with subarch checks

Since we are removing paravirt_enabled() replace it with a logical equivalent. Signed-off-by: Luis R. Rodriguez --- drivers/pnp/pnpbios/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c index

Re: [PATCH] scripts/coccinelle: modernize

On 2016-02-18 00:47, Nishanth Menon wrote: > On 02/17/2016 05:16 PM, Julia Lawall wrote: >> & is no longer allowed in column 0, since Coccinelle 1.0.4. >> >> Signed-off-by: Julia Lawall [...] > Verified with: > spatch --version > spatch byte-code version

[PATCH 9/9] pnpbios: replace paravirt_enabled() check with subarch checks

Since we are removing paravirt_enabled() replace it with a logical equivalent. Signed-off-by: Luis R. Rodriguez --- drivers/pnp/pnpbios/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c index

Re: [PATCH] scripts/coccinelle: modernize

On 2016-02-18 00:47, Nishanth Menon wrote: > On 02/17/2016 05:16 PM, Julia Lawall wrote: >> & is no longer allowed in column 0, since Coccinelle 1.0.4. >> >> Signed-off-by: Julia Lawall [...] > Verified with: > spatch --version > spatch byte-code version 1.0.4-00118-gc7cf750d1c44 compiled with

[PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

The current check is a super long winded way of asking if this is on lguest. The flags is used for legacy features, this is likely inspired by the ACPI IA-PC boot architecture flags, where as for RTC it annotates No CMOS real-time clock present. I don't expect we will be implementing more legacy

[PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

The current check is a super long winded way of asking if this is on lguest. The flags is used for legacy features, this is likely inspired by the ACPI IA-PC boot architecture flags, where as for RTC it annotates No CMOS real-time clock present. I don't expect we will be implementing more legacy

[PULL] GICv3 changes for 4.5-rc5

Hi Thomas, Please find below a pull request for three GICv3 fixes that I've collected over the past week. Hopefully, this will be the last batch for 4.5. Thanks, M. The following changes since commit 1a1ebd5fb1e203ee8cc73508cc7a38ac4b804596: irqchip/gic-v3: Make sure read from

[PULL] GICv3 changes for 4.5-rc5

Hi Thomas, Please find below a pull request for three GICv3 fixes that I've collected over the past week. Hopefully, this will be the last batch for 4.5. Thanks, M. The following changes since commit 1a1ebd5fb1e203ee8cc73508cc7a38ac4b804596: irqchip/gic-v3: Make sure read from

[PATCH 2/9] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644

[PATCH 5/9] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true) do never set the apm_bios_info, the paravirt_enabled() check is simply not needed. Signed-off-by: Luis

[PATCH 2/9] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644 ---

[PATCH 5/9] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true) do never set the apm_bios_info, the paravirt_enabled() check is simply not needed. Signed-off-by: Luis

[PATCH 0/9] x86/init: replace paravirt_enabled() were possible

I originally set out to rename paravirt_enabled() to paravirt_legacy() but we instead decided to remove paravirt_enabled() completely. Although I have some linker table work which will help make this cleaner, instead of waiting for that to go in, just remove the known cases that should be safe for

[PATCH 0/9] x86/init: replace paravirt_enabled() were possible

I originally set out to rename paravirt_enabled() to paravirt_legacy() but we instead decided to remove paravirt_enabled() completely. Although I have some linker table work which will help make this cleaner, instead of waiting for that to go in, just remove the known cases that should be safe for

Re: [PATCH] ehea: Drop owner assignment from platform_driver

On Fri, Feb 19, 2016 at 5:05 PM, Thadeu Lima de Souza Cascardo wrote: > NACK. > > ehea does not use platform_driver_register, it uses > ibmebus_register_driver, which does not set owner. > > Cascardo. Thanks for the feedback. I'll make sure to check for this in the future.

Re: [PATCH] ehea: Drop owner assignment from platform_driver

On Fri, Feb 19, 2016 at 5:05 PM, Thadeu Lima de Souza Cascardo wrote: > NACK. > > ehea does not use platform_driver_register, it uses > ibmebus_register_driver, which does not set owner. > > Cascardo. Thanks for the feedback. I'll make sure to check for this in the future. Amitoj

[PATCH 2/4] drm: Add DT bindings documentation for ARC PGU display controller

This add DT bindings documentation for ARC PGU display controller. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala

[PATCH 2/4] drm: Add DT bindings documentation for ARC PGU display controller

This add DT bindings documentation for ARC PGU display controller. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: devicet...@vger.kernel.org Cc: linux-snps-...@lists.infradead.org ---

[PATCH 4/4] MAINTAINERS: Add maintainer for ARC PGU display controller

This updates MAINTEINERS file with information about maintainer of ARC PGU display controller driver. Signed-off-by: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS

[PATCH 4/4] MAINTAINERS: Add maintainer for ARC PGU display controller

This updates MAINTEINERS file with information about maintainer of ARC PGU display controller driver. Signed-off-by: Alexey Brodkin Cc: linux-snps-...@lists.infradead.org --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 28cd72b..26ac58c

[PATCH 3/4] arc: axs10x - add support of ARC PGU

Synopsys DesignWare ARC SDP boards sport ARC SDP display controller attached to ADV7511 HDMI encoder. That change adds desctiption of both ARC PGU and ADV7511 in ARC SDP'd base-board Device Tree. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Pawel

[PATCH 3/4] arc: axs10x - add support of ARC PGU

Synopsys DesignWare ARC SDP boards sport ARC SDP display controller attached to ADV7511 HDMI encoder. That change adds desctiption of both ARC PGU and ADV7511 in ARC SDP'd base-board Device Tree. Signed-off-by: Alexey Brodkin Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell

[PATCH 0/4] drm: Add support of ARC PGU display controller

This series add support of ARC PGU display controller. ARC PGU is a quite simple byte streamer that gets data from the framebuffer and pushes it to hte connected encoder (DP or HDMI). It was tested on ARC SDP boards (axs101 in particular). Alexey Brodkin (4): drm: Add support of ARC PGU

[PATCH 0/4] drm: Add support of ARC PGU display controller

This series add support of ARC PGU display controller. ARC PGU is a quite simple byte streamer that gets data from the framebuffer and pushes it to hte connected encoder (DP or HDMI). It was tested on ARC SDP boards (axs101 in particular). Alexey Brodkin (4): drm: Add support of ARC PGU

[PATCH 1/4] drm: Add support of ARC PGU display controller

{ + struct arcpgu_drm_private *arcpgu = drm->dev_private; + + if (arcpgu->fbdev) { + drm_fbdev_cma_fini(arcpgu->fbdev); + arcpgu->fbdev = NULL; + } + drm_kms_helper_poll_fini(drm); + drm_vblank_cleanup(drm); + drm_mode_config_clea

[PATCH 1/4] drm: Add support of ARC PGU display controller

>dev_private; + + if (arcpgu->fbdev) { + drm_fbdev_cma_fini(arcpgu->fbdev); + arcpgu->fbdev = NULL; + } + drm_kms_helper_poll_fini(drm); + drm_vblank_cleanup(drm); + drm_mode_config_cleanup(drm); + + return 0; +} +

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote: > On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > > > Hi Bamvor, everybody, > > > > I have new glibc that follows new ABI: > > https://github.com/norov/glibc/tree/new-api > > Ah, very good! > > > It's very draft and

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote: > On Friday 19 February 2016 01:35:06 Yury Norov wrote: > > > > Hi Bamvor, everybody, > > > > I have new glibc that follows new ABI: > > https://github.com/norov/glibc/tree/new-api > > Ah, very good! > > > It's very draft and

[PATCH 2/3] lightnvm: fold get bb tbl when using dual/quad plane mode

When the media manager runs in dual or quad plane mode, lightnvm abstracts away plane specific commands. This poses a problem for get bad block table, as it reports bad blocks per plane, making the table either two or four times bigger than expected. Fold the bad block list before returning.

[PATCH 2/3] lightnvm: fold get bb tbl when using dual/quad plane mode

When the media manager runs in dual or quad plane mode, lightnvm abstracts away plane specific commands. This poses a problem for get bad block table, as it reports bad blocks per plane, making the table either two or four times bigger than expected. Fold the bad block list before returning.

[PATCH 1/3] lightnvm: fix up nonsensical configure overrun checking

From: Alan Instead of checking a constant 0 actually check the space available. Even better remember to allow for the header and also check the right amount of space is needed. Signed-off-by: Alan Cox Signed-off-by: Matias Bjørling

[PATCH 3/3] lightnvm: generalize rrpc ppa calculations

From: Javier González In rrpc, some calculations assume a certain configuration (e.g., 1 LUN, 1 sector per page). The reason behind this was that LightNVM used a simple configuration with QEMU to test core features in the beginning. This patch relaxes these assumptions and

[PATCH 0/3] LightNVM patches for next 4.5-rc

Hi Jens, Here is a couple of patches for the next 4.5-rc. A patch from Alan that fixes up logic in nvm_configure_get. Another patch from Javier that fixes a bug with multiple luns in RRPC, and at last a patch from me that fixes the get bad block interface when multiple planes are available on

[PATCH 1/3] lightnvm: fix up nonsensical configure overrun checking

From: Alan Instead of checking a constant 0 actually check the space available. Even better remember to allow for the header and also check the right amount of space is needed. Signed-off-by: Alan Cox Signed-off-by: Matias Bjørling --- drivers/lightnvm/core.c | 11 +-- 1 file

[PATCH 3/3] lightnvm: generalize rrpc ppa calculations

From: Javier González In rrpc, some calculations assume a certain configuration (e.g., 1 LUN, 1 sector per page). The reason behind this was that LightNVM used a simple configuration with QEMU to test core features in the beginning. This patch relaxes these assumptions and generalizes

[PATCH 0/3] LightNVM patches for next 4.5-rc

Hi Jens, Here is a couple of patches for the next 4.5-rc. A patch from Alan that fixes up logic in nvm_configure_get. Another patch from Javier that fixes a bug with multiple luns in RRPC, and at last a patch from me that fixes the get bad block interface when multiple planes are available on

<    5   6   7   8   9   10   11   12   13   14   >