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
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
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
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:
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
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
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,
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
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
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
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
* 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:
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
> ---
>
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
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:
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
@@
* 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
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
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
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
>
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
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
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
* 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);
>
>
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
>
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
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
> ---
>
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
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
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
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
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
* 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
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
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
* 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 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]:
> > > > > ---
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
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 -
* 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
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
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
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
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
>
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
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
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
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.
* 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:
* 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
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
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
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:
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
* 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,
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
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
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
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
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
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.
>
>
On 2015/2/20 11:59, Masami Hiramatsu wrote:
> Hi,
>
> Sorry for replying late.
>
> (2015/02/13 14:39), Wang Nan wrote:
>> I fell very sorry for people who reviewed my v2 patch series yesterday
>> at https://lkml.org/lkml/2015/2/12/234 because I didn't provide enough
>> information in commit log.
Hi Thomas, Ingo,
this pull request provides the following fixes for 4.0-rc1:
- Fix the Kconfig to prevent the asm9260 timer to be compiled with
allyesconfig with sparc/sparc64 (Daniel Lezcano)
- Reorder the mtk driver init sequence in order to prevent a potential
race when the clock is
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
On Mon, Feb 23, 2015 at 10:12:23AM +, Peter Griffin wrote:
> I think all the writel IO accessors in this driver can be replaced
> with the *_relaxed variant. This will avoid the overhead of taking a
> spinlock in the l2 outer cache part of writel.
You're really operating on old information.
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
> (2015/02/24 15:04), Eugene Shatokhin wrote:
24.02.2015 06:47, Masami Hiramatsu пишет:
No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).
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
On Tue, Feb 24, 2015 at 04:42:10PM -0800, Vikas Shivappa wrote:
> >>+
> >>+ pr_info("cbmlength:%u,Closs: %u\n", cbm_len, maxid);
> >
> >This text message needs to be much more user-friendly if it is going out
> >to the console unconditionally.
> >
>
> bit mask lengh: number of CLOSids: ? . it
On Wed, Feb 25, 2015 at 11:51:57AM +0100, Arnd Bergmann wrote:
> 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,
> > >
On Tue, Feb 24, 2015 at 04:54:17PM -0500, Chris Metcalf wrote:
> On 2/14/2015 6:22 AM, Catalin Marinas wrote:
> >1. user populates sival_int compat_sigevent and invokes
> >compat_sys_mq_notify()
> >2. kernel get_compat_sigevent() copies compat_sigevent into the native
> >sigevent. compat
On 02/24/2015 04:25 PM, Arnd Bergmann wrote:
> On Tuesday 24 February 2015 12:28:41 Ezequiel Garcia wrote:
>>
>> Gah, no, you are right. I got confused.
>>
>> So it would be OK to avoid remove pt_regs from the uapi headers?
>> How does this affect the signal handling nios2 implementation?
>>
>
This patch fix spelling typos in Documentations/input.
Signed-off-by: Masanari Iida
---
Documentation/input/alps.txt| 4 ++--
Documentation/input/event-codes.txt | 2 +-
Documentation/input/gpio-tilt.txt | 2 +-
Documentation/input/iforce-protocol.txt | 2 +-
Davidlohr Bueso wrote:
> The mm->exe_file is currently serialized with mmap_sem (shared) in order
> to both safely (1) read the file and (2) compute the realpath by calling
> tomoyo_realpath_from_path, making it an absolute overkill. Good users will,
> on the other hand, make use of the more
As preparation work for the introduction of an eFuse subsystem,
this commit moves Tegra's fuse header and fixes the includes
where needed.
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Alexandre Courbot
Signed-off-by: Ezequiel Garcia
---
arch/arm/mach-tegra/cpuidle.c | 3 +--
The soc/tegra/fuse.h header makes use of kernel-specific types (u32, u8) and
therefore it needs a linux/types.h include.
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Alexandre Courbot
Signed-off-by: Ezequiel Garcia
---
include/soc/tegra/fuse.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
Now that the efuse subsystem has been introduced, move the Tegra efuse driver
from drivers/soc/tegra/fuse/ to drivers/efuse/tegra. For now, there's no
generic efuse API. However, by having the drivers in a unified location it is
expected that such API will arise easier once support for more
This patchset introduces a new driver subsystem, meant to support eFuse
(alias OTP, one-time-programmable) devices.
The motivation behind this work is to have a common place for drivers
that are currently more or less scattered: the tegra efuses are in
drivers/soc/ and the sunxi efuses in
On 2015/2/25 19:11, Wang Nan wrote:
> On 2015/2/20 11:59, Masami Hiramatsu wrote:
>> Hi,
>>
>> Sorry for replying late.
>>
>> (2015/02/13 14:39), Wang Nan wrote:
>>> I fell very sorry for people who reviewed my v2 patch series yesterday
>>> at https://lkml.org/lkml/2015/2/12/234 because I didn't
This commit introduces a new eFuse subsystem stub to hold all the eFuse-like
device drivers. This will be used to host the currently supported Tegra
eFuse driver, and will allow to add support for other platforms as well.
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Maxime Ripard
Cc: Arnd
On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
> So the process steps basically look like this:
> 1.) cat capsule_ticket===> acquire a number and lock mutex then
> expose
> firmware_class user helper
>
After the introduction of the efuse subsystem, platforms are now required
to select the efuse support explicitly.
Cc: Stephen Warren
Cc: Thierry Reding
Cc: Alexandre Courbot
Signed-off-by: Ezequiel Garcia
---
arch/arm/mach-tegra/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
The Sunxi SoC eFuse support is currently located under drivers/eeprom,
although the driver is not an eeprom. This commit just moves the driver
to drivers/efuse. There's no functionality change.
Cc: Maxime Ripard
Signed-off-by: Ezequiel Garcia
---
drivers/efuse/Kconfig | 12
901 - 1000 of 1756 matches
Mail list logo
