On Tue, Feb 24, 2015 at 10:27:05PM +0100, Antonio Ospite wrote:
> On Mon, 23 Feb 2015 15:52:45 +0200
> Mika Westerberg wrote:
>
> > The HID over I2C specification allows to have the interrupt for a HID
> > device to be GPIO instead of directly connected to the IO-APIC.
> >
> > Add support for th
> * v3.19 ignored [io 0x0cf8-0x0cff], but v4.0 includes it. I think
> it's wrong to include it because that's the configuration space
> address/data registers, so it's consumed by the host bridge and not
> produced on the downstream side.
>
> * v3.19 includes [mem 0x7ff0-0xfebf], but v4.0
CC linux-gpio, as this looks like the LED equivalent of bulk gpio?
On Thu, Feb 19, 2015 at 10:14 PM, Felipe Balbi wrote:
> Do we have support for LED controllers which can handle patterns of
> different kinds ? I mean, currently, if we have an LED controller such
> as TPIC2810 [1] which can contr
Commit-ID: 72c6fb4f74b6b3797f5b1abd6944d7a1d2adbf04
Gitweb: http://git.kernel.org/tip/72c6fb4f74b6b3797f5b1abd6944d7a1d2adbf04
Author: Andy Lutomirski
AuthorDate: Tue, 24 Feb 2015 16:01:39 -0800
Committer: Ingo Molnar
CommitDate: Wed, 25 Feb 2015 08:27:50 +0100
x86/ia32-compat: Fix CLO
Commit-ID: 08571f1ae327bfb631cb7171bde5ea605df626c6
Gitweb: http://git.kernel.org/tip/08571f1ae327bfb631cb7171bde5ea605df626c6
Author: Andy Lutomirski
AuthorDate: Tue, 24 Feb 2015 16:01:38 -0800
Committer: Ingo Molnar
CommitDate: Wed, 25 Feb 2015 08:27:49 +0100
x86/ptrace: Remove check
On 25/02/15 06:39, Kenneth Westfield wrote:
From: Kenneth Westfield
Define the LPASS platform driver, the LPASS
CPU DAI driver and the Storm machine driver
configurations, and how to build them.
Signed-off-by: Kenneth Westfield
Acked-by: Banajit Goswami
---
sound/soc/qcom/Kconfig | 23 +
Changes since v8:
- remove MPIDR packing things by introducing phys_cpuid_t;
- update patch acpi: fix acpi_os_ioremap for arm64 to follow
Rafael's suggestion;
- Squash patch (disable ACPI if ACPI less than 5.1) to patch
(Get RSDP and ACPI boot-time table);
- Move sleep_arm.c to a
For a normal 8 cpu sockets system, it will up to 240 cpu threads (Xeon E7
v2 family for now), and we need 240 entries for local apic or local x2apic
in MADT table, so it will be much verbose information printed with a slow
uart console when system booted, this will be even worse with large system
w
From: Graeme Gregory
Now with the base changes to the arm memory mapping it is safe
to convert to using ioremap to map in the tables after
acpi_gbl_permanent_mmap is set.
CC: Rafael J Wysocki
Tested-by: Robert Richter
Acked-by: Robert Richter
Signed-off-by: Al Stone
Signed-off-by: Graeme Gre
Hi,
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, February 18, 2015 2:19 PM
> To: Scot Doyle
> Cc: Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ACPI / EC: Remove non-standard log emphasis
>
> On Sunday, February 15, 2015 07:
From: Mark Salter
The acpi_os_ioremap() function may be used to map normal RAM or IO
regions. The current implementation simply uses ioremap_cache(). This
will work for some architectures, but arm64 ioremap_cache() cannot be
used to map IO regions which don't support caching. So for arm64, use
io
CPU hardware ID (phys_id) is defined as u32 in structure acpi_processor,
but phys_id is used as int in acpi processor driver, so it will lead to
some inconsistence for the drivers.
Furthermore, to cater for ACPI arch ports that implement 64 bits CPU
ids a generic CPU physical id type is required.
From: Mark Salter
Commit 0e63ea48b4d8 (arm64/efi: add missing call to early_ioremap_reset())
added a missing call to early_ioremap_reset(). This triggers a BUG if code
tries using early_ioremap() after the early_ioremap_reset(). This is a
problem for some ACPI code which needs short-lived tempora
From: Al Stone
As we want to get ACPI tables to parse and then use the information
for system initialization, we should get the RSDP (Root System
Description Pointer) first, it then locates Extended Root Description
Table (XSDT) which contains all the 64-bit physical address that
pointer to other
From: Graeme Gregory
There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the firmware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).
FADT table c
When MADT is parsed, print GIC information as debug message:
ACPI: GICC (acpi_id[0x] address[e112f000] MPIDR[0x0] enabled)
ACPI: GICC (acpi_id[0x0001] address[e112f000] MPIDR[0x1] enabled)
...
ACPI: GICC (acpi_id[0x0201] address[e112f000] MPIDR[0x201] enabled)
Those de
From: Al Stone
This implements the following policy to decide whether ACPI should
be used to boot the system:
- acpi=off: ACPI will not be used to boot the system, even if there is
no alternative available (e.g., device tree is empty)
- acpi=force: only ACPI will be used to boot the system; if
From: Graeme Gregory
If the early boot methods of acpi are happy that we have valid ACPI
tables and acpi=force has been passed, then do not unflat devicetree
effectively disabling further hardware probing from DT.
CC: Catalin Marinas
CC: Will Deacon
Tested-by: Suravee Suthikulpanit
Tested-by:
CONFIG_ACPI depends CONFIG_PCI on x86 and ia64, in ARM64 server
world we will have PCIe in most cases, but some of them may not,
make CONFIG_ACPI depend CONFIG_PCI on ARM64 will satisfy both.
With that case, we need some arch dependent PCI functions to
access the config space before the PCI root b
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
abstraction agnostic). In a similar way, FDT initialize GICv1/2.
NOT
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, so use hwirq number directly
for the mapping.
We are going to im
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_map.
ACPI 5.1 only has two explicit methods to boot up SMP, PSCI
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 infrastructure to retrieve the MPIDR
values from the ARM ACPI GICC struc
From: Graeme Gregory
Add documentation for the guidelines of how to use ACPI
on ARM64.
Reviewed-by: Suravee Suthikulpanit
Reviewed-by: Yi Li
Reviewed-by: Mark Langsdorf
Reviewed-by: Ashwin Chaugule
Acked-by: Robert Richter
Signed-off-by: Graeme Gregory
Signed-off-by: Al Stone
Signed-off-b
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: Will Deacon
Reviewed-by: Grant Likely
Tested-by: Suravee Suthikulpanit
Te
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 Suthikulpanit
Tested-by: Yijing Wang
Tested-by: Mark Langsdorf
Tested-by: J
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 future.
CC: Rafael J. Wysocki
CC: Catalin Marinas
CC: Will Deacon
Revi
From: Al Stone
Two more documentation files are also being added:
(1) A verbatim copy of the "Why ACPI on ARM?" blog posting by Grant Likely,
which is also summarized in arm-acpi.txt, and
(2) A section by section review of the ACPI spec (acpi_object_usage.txt)
to note recommendations and
From: Graeme Gregory
ACPI 5.1 does not currently support S states for ARM64 hardware but
ACPI code will call acpi_target_system_state() for device power
management, so introduce acpi_sleep.c to allow other drivers to function
until S states are defined.
Since it is arm64 specific stub holder, so
Current Exynos CPU idle driver supports entering AFTR (Arm Off, Top
Running) mode on Exynos 4210 (coupled), Exynos 4x12 and Exynos 5250.
Enable it in default configuration to reduce energy consumption.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/configs/exynos_defconfig | 2 ++
1 file change
Current Exynos CPU idle driver supports entering AFTR (Arm Off, Top
Running) mode on Exynos 4210 (coupled), Exynos 4x12 and Exynos 5250.
Enable it in default configuration to reduce energy consumption.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file chang
Hi,
On 24/02/15 22:31, NeilBrown wrote:
> On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen
> wrote:
>
>> Hi,
>>
>> On 24/02/15 11:37, NeilBrown wrote:
>>>
>>>
>>> commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
>>> OMAPDSS: rename display-sysfs 'name' entry
>>>
>>> broke the xorg X server o
Add the parent device so that udev can show the full hierarchy. This avoids the
device showing up under /devices/virtual/input instead of the i2c bus it is
actually attached to.
Signed-off-by: Stefan Sauer
---
drivers/input/misc/mma8450.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drive
* Denys Vlasenko wrote:
> PER_CPU_VAR(kernel_stack) was set up in a way where it
> points five stack slots below the top of stack.
>
> Presumably, it was done to avoid one "sub $5*8,%rsp" in
> syscall/sysenter code paths, where iret frame needs to be
> created by hand.
>
> Ironically, none
Hi,
> From: Zheng, Lv
> Sent: Wednesday, February 25, 2015 4:42 PM
>
> Hi,
>
> > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> > Sent: Wednesday, February 18, 2015 2:19 PM
> > To: Scot Doyle
> > Cc: Zheng, Lv; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PAT
Hi Abhilash,
> This patch fixes the wrong control of PD_DET_EN (power down detection
> mode) for Exynos7 because exynos7_tmu_control() always enables the
> power down detection mode regardless 'on' parameter.
>
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Signed-off-by: Chanwoo Choi
> ---
> drive
On Wed, Feb 25, 2015 at 5:25 PM, Geert Uytterhoeven
wrote:
> CC linux-gpio, as this looks like the LED equivalent of bulk gpio?
Indeed. The LED core could implement something similar to
gpiod_set_array() to allow several LEDs to be set in one call. If the
controller supports it, it would then set
On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote:
> From: Hongzhou Yang
>
> The upcoming MTK pinctrl driver have a big pin table for each SoC,
> and we don't want to bloat the kernel binary if we don't need it.
> Add config options so we can build for one SoC only.
>
> Signed-off-by: Hongz
On Tuesday 24 February 2015 17:36:50 Andrew Duggan wrote:
> A touchpad may have firmware based palm detection code enabled which
> suppresses 2D data from being reported when the firmware believes a palm is
> on the touchpad. This functionality is meant to be used in mouse mode without
> a driver.
The calling function invoke_rcu_core will check it.
Signed-off-by: Yao Dongdong
---
kernel/rcu/tree.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 48d640c..e5f9b7e 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -274
* H. Peter Anvin wrote:
> On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
> > On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko
> > wrote:
> >>
> >> In all three 32-bit entry points, %eax is
> >> zero-extended to %rax. It is safe to do 32-bit compare
> >> when checking that syscall# is not too
On Wed, 25 Feb 2015 10:49:58 +0200 Tomi Valkeinen
wrote:
> Hi,
>
> On 24/02/15 22:31, NeilBrown wrote:
> > On Tue, 24 Feb 2015 12:40:32 +0200 Tomi Valkeinen
> > wrote:
> >
> >> Hi,
> >>
> >> On 24/02/15 11:37, NeilBrown wrote:
> >>>
> >>>
> >>> commit 303e4697e762dc92a40405f4e4b8aac02cd0d70b
>
On Tue, Feb 24, 2015 at 06:41:50PM +0200, Ameen Ali wrote:
> avoid out-of-bounds-read by checking count before indexing.
>
> Signed-off-by : Ameen Ali
> ---
> drivers/s390/block/dcssblk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s390/block/dcssblk.c b/dri
On Tue, Feb 24, 2015 at 03:16:37PM -0800, Vikas Shivappa wrote:
> This patch adds a new cgroup subsystem to support the new Cache Allocation
> Technology (CAT) feature found in future Intel Xeon Intel processors. CAT is
> part of Resource Director Technology(RDT) or Platform Shared resource contr
David,
I can try to prepare a patch fixing the null-ptr access.
Thanks for the hint with the search_count, I'll try it.
2015-02-24 2:37 GMT+01:00 David Fries :
> Thorsten,
> Are you planning on submitting a patch?
>
> FYI, I load the one wire module with
> wire search_count=1
> in
> /etc/module
On 02/25/2015 01:20 AM, Ingo Molnar wrote:
I think the fundamental fragility is that we allow the high
32 bits to be nonzero.
So could we just zap the high 32 bits of RAX early in the
entry code, and then from that point on we could both use
32-bit ops and won't have to remember the possibility
On 25/02/15 11:20, NeilBrown wrote:
> Tested-by: NeilBrown
>
> Before the patch:
>
> # ls -l /sys/devices/platform/omapdss/display0
> lrwxrwxrwx 1 root root 0 Feb 8 12:57 /sys/devices/platform/omapdss/display0
> -> ../spi_lcd/spi_master/spi32766/spi32766.0
>
> After the patch:
>
> # ls -l
These devices do not need to return to non-graphic console
for suspend, so disable that option.
This means there is less work to do in the suspend/resume cycle,
making it smoother and cheaper.
Signed-off-by: NeilBrown
--
Hi Tomi,
I wonder if you would consider this patch too. It works for me
On Tue, Feb 24, 2015 at 05:48:17PM +0100, Borislav Petkov wrote:
>
> Thanks for the review, very good points. I had spotted some of them
> myself but had to restrain myself not to do them now for the very
> simple reason: we want this code first cleaned up nicely, in small and
> self-contained pie
* H. Peter Anvin wrote:
> > So could we just zap the high 32 bits of RAX early in
> > the entry code, and then from that point on we could
> > both use 32-bit ops and won't have to remember the
> > possibility either?
>
> We do that, [...]
Ok, indeed, so in ia32_sysenter_target() we have:
* Andy Lutomirski wrote:
> - BUG_ON(((current_stack_pointer() ^ this_cpu_read_stable(kernel_stack))
> + BUG_ON(((current_stack_pointer() ^
> +(this_cpu_read_stable(kernel_stack) - 1))
> & ~(THREAD_SIZE - 1)) != 0);
>
> preempt_count_sub(HARDIR
On Mon 2015-01-26 20:41:53, Scot Doyle wrote:
> The fbcon cursor, when set to blink, is hardcoded to toggle display state
> five times per second. Expose this setting via
> /sys/class/graphics/fbcon/cursor_blink_ms
>
> Values written to the interface set the approximate time interval in
> millisec
On Tue 2015-02-24 09:37:34, Tony Lindgren wrote:
> * Pali Rohár [150224 09:42]:
> > On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
> > > * Pali Rohár [150218 16:03]:
> > > > --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > > > +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> > >
On Mon, Feb 23, 2015 at 09:37:24AM +, Stathis Voukelatos wrote:
> Hi Richard,
>
> On 18/02/15 21:08, Richard Cochran wrote:
> >On Tue, Feb 17, 2015 at 02:03:30PM +, Stathis Voukelatos wrote:
> >>The command string for packet matching is stored in module RAM
> >>and consists of a sequence o
On 24/02/15 18:08, Zubair Lutfullah Kakakhel wrote:
> From: Alex Smith
>
> Add device tree bindings for the DMA controller on JZ4780 SoCs, used by
> the dma-jz4780 driver.
>
> Signed-off-by: Alex Smith
> Signed-off-by: Zubair Lutfullah Kakakhel
>
> ---
> V1 -> V2 None
> ---
> .../devicetre
Hi,
On 02/25/2015 04:52 PM, Alim Akhtar wrote:
> Hi Doug,
>
>
> On Fri, Feb 20, 2015 at 5:19 AM, Doug Anderson wrote:
>> Alim and Addy,
>>
>> On Sun, Feb 15, 2015 at 3:28 PM, Alim Akhtar wrote:
>>> Hi Addy,
>>>
>>> On Sat, Feb 14, 2015 at 11:47 AM, Addy Ke wrote:
As show in mmc_power_up(
On Tue, Feb 24, 2015 at 12:23:48AM +, Laurent Pinchart wrote:
> On Tuesday 24 February 2015 01:20:21 Vincent Stehlé wrote:
> > LPAE iommu page table makes sense only for ARM and ARM64 architectures. Add
> > the corresponding dependency in Kconfig (and enable for COMPILE_TEST, too,
> > as per La
On Tue, Feb 24, 2015 at 10:33:02AM +, Geert Uytterhoeven wrote:
> On Mon, Feb 23, 2015 at 5:52 PM, Laurent Pinchart
> wrote:
> > On Sunday 22 February 2015 17:09:06 Vincent Stehlé wrote:
> >> LPAE iommu page table makes sense only for ARM architecture. Add the
> >> corresponding dependency in
On 02/24/2015 08:39 AM, Arun Chandran wrote:
> This patch converts all __raw_readl and __raw_writel function calls
> to their corresponding readl_relaxed and writel_relaxed variants.
>
> It also tells the driver to set ahb_endian_swp_mgmt_en bit in dma_cfg
> when the cpu is configured in big endia
On 25/02/15 11:37, NeilBrown wrote:
>
> These devices do not need to return to non-graphic console
> for suspend, so disable that option.
> This means there is less work to do in the suspend/resume cycle,
> making it smoother and cheaper.
>
>
> Signed-off-by: NeilBrown
>
> --
> Hi Tomi,
> I w
Hello Doug,
On 02/25/2015 06:43 AM, Doug Anderson wrote:
>
> OK, so looking through things I _think_ I found another difference
> that _might_ matter...
>
Yes it does! when adding the "sd1_bus1" the slot pinctrl I do have
the WiFi module working, thanks a lot for your help!
> Upstream (arch/ar
* Greg KH wrote:
> > >It's:
> > >
> > > d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
> >
> > Yes, This is the original patch. Please note I have taken out the
> > READ_ONCE changes from the original patch to avoid build warnings
> > mentioned below.
> > (Those READ_ONCE
Hi, Tomasz,
Thanks for you comment :)
On Wed, 25 Feb 2015 09:54:02 +0900
Tomasz Figa wrote:
> Hi Inha,
>
> Thanks for the patch. Please see my comments inline.
>
> 2015-02-24 18:22 GMT+09:00 Inha Song :
> > This patch add CLKOUT driver support for Exynos3250 SoC.
>
> Could you please add a l
Am 25.02.2015 um 11:08 schrieb Ingo Molnar:
>
> * Greg KH wrote:
>
It's:
d6abfdb20223 x86/spinlocks/paravirt: Fix memory corruption on unlock
>>>
>>> Yes, This is the original patch. Please note I have taken out the
>>> READ_ONCE changes from the original patch to avoid build war
* David Rientjes wrote:
> The problem is with the structure of your patchset. You
> want three patches. There's one bugfix patch, a
> preparation patch, and a feature patch. The bugfix patch
> should come first so that it can be applied, possibly, to
> stable kernels and doesn't depend on
On Wednesday 25 February 2015 10:50:00 Pavel Machek wrote:
> On Tue 2015-02-24 09:37:34, Tony Lindgren wrote:
> > * Pali Rohár [150224 09:42]:
> > > On Tuesday 24 February 2015 18:25:12 Tony Lindgren wrote:
> > > > * Pali Rohár [150218 16:03]:
> > > > > --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_d
On 24/02/15 21:53, Nicolas Pitre wrote:
On Tue, 24 Feb 2015, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
Avoid secure transactions while probing the CCI PMU. The
existing code makes use of the Peripheral ID2 (PID2) register
to determine the revision of the CCI400, which requires a
secu
Chris, Ulf, gentle ping?
On Thu, Feb 12, 2015 at 1:36 PM, Alexandre Courbot wrote:
> The alloc() and free() hooks required each pwrseq implementation to set
> host->pwrseq themselves. This is error-prone and could be done at a
> higher level if alloc() was changed to return a pointer to a struct
* Boaz Harrosh wrote:
> List of patches:
> [PATCH 1/3] e820: Don't let unknown DIMM type come out BUSY
> The main fix
>
> [PATCH 2/3] resource: Add new flag IORESOURCE_WARN (64bit)
> Warn in request_resource
>
> [PATCH 3A/3] e820: Add the unknown-12 Memory type (DDR3-NvDIMM)
>
Reviewed-by: Dan Carpenter
regards,
dan carpenter
--
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 24/02/15 22:17, Nicolas Pitre wrote:
On Tue, 24 Feb 2015, Suzuki K. Poulose wrote:
From: "Suzuki K. Poulose"
This patch separates the PMU driver code from the low level
CCI driver code, and enables the CCI400-PMU for ARM64.
Introduces config options for both.
- ARM_CCI400_MCPM - co
* Christian Borntraeger wrote:
> > By all means!
> >
> > You'll first need to cherry-pick these commits:
>
> > 927609d622a3 kernel: tighten rules for ACCESS ONCE
> > c5b19946eb76 kernel: Fix sparse warning for ACCESS_ONCE
> > dd36929720f4 kernel: make READ_ONCE() valid on const arguments
>
* Matt Fleming wrote:
> On Sun, 22 Feb, at 07:43:48PM, Yinghai Lu wrote:
> > Index: linux-2.6/arch/x86/boot/header.S
> > ===
> > --- linux-2.6.orig/arch/x86/boot/header.S
> > +++ linux-2.6/arch/x86/boot/header.S
> > @@ -301,7 +301,7
From: Robert Jarzmik
As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function pxa_timer_common_init() to the function
.init.text:sched_clock_register()
From: Matthias Brugger
We have two race conditions in the probe code which could lead to a null
pointer dereference in the interrupt handler.
The interrupt handler accesses the clockevent device, which may not yet be
registered.
First race condition happens when the interrupt handler gets regis
The Kconfig options for the asm9260 timer is wrong as it can be selected by
another platform with allyes config and thus leading to a compilation failure
as some non arch related code is pulled by the compilation.
Fix this by having the platform Kconfig to select the timer as it is done for
the ot
Hi, Doug.
It makes sense. Looks good to me. Thanks!
Acked-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
On 02/21/2015 03:57 AM, Doug Anderson wrote:
> It appears that we can confuse things if we try to turn on the MMC
> clock when the power is off. Adjust is so that we turn the clock on
> (us
Dear, Doug.
Looks good to me. Thanks!
Acked-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
On 02/21/2015 03:57 AM, Doug Anderson wrote:
> We should give dw_mmc a good reset after we apply power. On some
> boards vqmmc may actually be connected to the IP block in the SoC so
> it's good to reset
On Tue, Feb 24, 2015 at 01:39:46PM -0500, Steven Rostedt wrote:
> Index: linux-rt.git/kernel/sched/rt.c
> ===
> --- linux-rt.git.orig/kernel/sched/rt.c 2015-02-24 10:44:08.798785452
> -0500
> +++ linux-rt.git/kernel/sched/rt.c
* Daniel Lezcano wrote:
> From: Robert Jarzmik
>
> As pxa_timer_common_init() is only called in init context, mark it as
> such, and quiesce the compiler warnings :
> WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
> from the function pxa_timer_common_init() to the fun
Hi, Addy.
Acked-by: Jaehoon Chung
Thanks!
Best Regards,
Jaehoon Chung
On 02/20/2015 11:37 AM, Addy Ke wrote:
> To support HS200 and UHS mode, mmc core will call init_card() to
> execute tuning:
> - sdio: init_card can be executed at runtime resume.
> - sd and mmc: init_card can be executed at
On Tue, Feb 24, 2015 at 04:07:07PM -0800, Andy Lutomirski wrote:
> I'd prefer a different partial solution: encourage everyone to clear
> the xstate before making syscalls (using e.g. vzeroall). In fact,
> maybe user code should aggressively clear newly-unused xstate.
We don't trust userspace.
-
Robert,
On 24/02/15 22:05, Robert ABEL wrote:
> GPMC_CONFIG1_i parameters CLKACTIVATIONTIME and WAITMONITORINGTIME
> have reserved values.
> Raise an error if calculated timings try to program reserved values.
>
> GPMC_CONFIG1_i ATTCHEDDEVICEPAGELENGTH and DEVICESIZE were already checked
typo AT
On 02/25/2015 11:35 AM, Ingo Molnar wrote:
* Daniel Lezcano wrote:
From: Robert Jarzmik
As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference
from the function
* Andy Lutomirski wrote:
> > I'm a big fan of simplifying things, but.
> >
> > SIMD registers were growing in x86, and they are going
> > to grow again, this time four-fold in Intel MIC: from
> > sixteen 256-bit registers to thirty two 512-bit
> > registers.
> >
> > That's 2 kbytes of data. J
* Daniel Lezcano wrote:
> On 02/25/2015 11:35 AM, Ingo Molnar wrote:
> >
> >* Daniel Lezcano wrote:
> >
> >>From: Robert Jarzmik
> >>
> >>As pxa_timer_common_init() is only called in init context, mark it as
> >>such, and quiesce the compiler warnings :
> >>WARNING: vmlinux.o(.text.unlikely+0x
* Borislav Petkov wrote:
> On Tue, Feb 24, 2015 at 04:07:07PM -0800, Andy Lutomirski wrote:
>
> > I'd prefer a different partial solution: encourage
> > everyone to clear the xstate before making syscalls
> > (using e.g. vzeroall). In fact, maybe user code should
> > aggressively clear newly
On 02/25/2015 12:24 AM, David Rientjes wrote:
From: Greg Thelen
Commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on local
node") restructured alloc_hugepage_vma() with the intent of only
allocating transparent hugepages locally when there was not an effective
interleave mempolicy.
On Fri, Feb 20, 2015 at 07:56:15PM -0800, Hugh Dickins wrote:
> Commit 07a427884348 ("mm: shmem: avoid atomic operation during
> shmem_getpage_gfp") rightly replaced one instance of SetPageSwapBacked
> by __SetPageSwapBacked, pointing out that the newly allocated page is
> not yet visible to other
On Wednesday 25 February 2015 17:07:22 Yingjoe Chen wrote:
> On Tue, 2015-01-27 at 15:13 +0800, Hongzhou Yang wrote:
> > From: Hongzhou Yang
> >
> > The upcoming MTK pinctrl driver have a big pin table for each SoC,
> > and we don't want to bloat the kernel binary if we don't need it.
> > Add con
Hi Richard,
On 25/02/15 09:50, Richard Cochran wrote:
The Linux kernel already fully supports this kind of application via
the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms. We certainly
don't need another another interface just for someone's warped
hardware design.
I suggest that you fi
On 02/25/2015 11:48 AM, Ingo Molnar wrote:
* Daniel Lezcano wrote:
On 02/25/2015 11:35 AM, Ingo Molnar wrote:
* Daniel Lezcano wrote:
From: Robert Jarzmik
As pxa_timer_common_init() is only called in init context, mark it as
such, and quiesce the compiler warnings :
WARNING: vmlinux.o(
On Wed, Feb 25, 2015 at 3:32 PM, Michal Simek wrote:
> On 02/24/2015 08:39 AM, Arun Chandran wrote:
>> This patch converts all __raw_readl and __raw_writel function calls
>> to their corresponding readl_relaxed and writel_relaxed variants.
>>
>> It also tells the driver to set ahb_endian_swp_mgmt_
* Daniel Lezcano wrote:
> On 02/25/2015 11:48 AM, Ingo Molnar wrote:
> >
> >* Daniel Lezcano wrote:
> >
> >>On 02/25/2015 11:35 AM, Ingo Molnar wrote:
> >>>
> >>>* Daniel Lezcano wrote:
> >>>
> From: Robert Jarzmik
>
> As pxa_timer_common_init() is only called in init context, ma
2015-02-24 21:51 GMT+01:00 Guenter Roeck :
> I think the lm85 conversion actually introduces a bug with such an
> off-by-one mistake. And if it doesn't, there is still a unexplained
> and not easy to understand '-1' in one of the calls to find_closest().
>
> So the question is if the new code reall
On 24/02/15 22:05, Robert ABEL wrote:
> OMAP2+ GPMC driver undefines DEBUG, which makes it unnecessarily
> hard to turn DEBUG on. Remove the offending lines.
>
> Signed-off-by: Robert ABEL
Acked-by: Roger Quadros
cheers,
-roger
> ---
> drivers/memory/omap-gpmc.c | 2 --
> 1 file changed, 2 d
Hi,
On 02/02/15 11:45, James Hogan wrote:
> This patchset adds basic support for the MIPS Common Device Memory Map
> Memory (CDMM) region in the form of a bus in the standard Linux device
> model.
It'd be great to get these patches upstream for v4.1 via the MIPS tree
along with my other two relat
Hi,
On 29/01/15 11:14, James Hogan wrote:
> This patchset adds a TTY, console, and KGDB driver for the MIPS Fast
> Debug Channel (FDC) hardware, for communicating with a debugger via an
> EJTAG probe. 16 TTY ports are created per FDC device, corresponding to
> the 16 FDC channels. Each VPE usually
On Mon, 23 Feb 2015, Peter Griffin wrote:
> On Wed, 18 Feb 2015, Lee Jones wrote:
>
> > ST's Low Power Controller (LPC) controls two devices; watchdog and RTC.
> > Only one of the devices can be used at any one time. This is enforced
> > by the correlating MFD driver. This portion of the driver-
On Wed, Feb 25, 2015 at 02:47:45AM +, Yingjoe Chen wrote:
> The functions __cpu_flush_user_tlb_range and __cpu_flush_kern_tlb_range
> were removed in commit fa48e6f780 'arm64: mm: Optimise tlb flush logic
> where we have >4K granule'. Global variable cpu_tlb was never used in
> arm64.
>
> Remo
1 - 100 of 878 matches
Mail list logo
