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
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
>
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
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
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
* 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
* 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
>
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 -
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/
* 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)
>
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
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
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]:
> > > > > ---
* 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
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
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
* 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
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
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
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 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 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
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 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
> ---
>
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 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 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
>
* 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);
>
>
* 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:
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
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 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
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 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
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 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
* 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
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
@@
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.
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 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
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
> ---
>
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:
* 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
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
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
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
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
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,
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
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: 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: 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.
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
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
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
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
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
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
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: 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
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
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
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
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
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
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
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
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
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
> * 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
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
-Original Message-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Wednesday, February 25, 2015 7:48 PM
On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
So this sounds pretty overengineered for no reason, or maybe I'm missing
the reason.
If I had to give
On Mon, Feb 16, 2015 at 06:38:20PM +, Will Deacon wrote:
Various build/boot bots have reported WARNs being triggered by the ARM
iopgtable LPAE self-tests on i386 machines.
This boils down to two instances of right-shifting a 32-bit unsigned
long (i.e. an iova) by more than the size of
On 24/02/15 22:05, Robert ABEL wrote:
GPMC debug output is aligned to 10 characters for field names.
However, some fields have bigger names, screwing up the alignment.
Consequently, alignment was changed to longest field name (17 chars) for now.
Signed-off-by: Robert ABEL
From the indenting we can see the curly braces were obviously intended.
This is a static checker fix, but my guess is that we don't read enough
bytes, because we don't calculate t_len correctly.
Fixes: f1d82698029b ('memstick: use fully asynchronous request processing')
Signed-off-by: Dan
On 2015-02-06 15:58, David Howells wrote:
Note that the revised sign-file program no longer supports the -s
signature
option as I'm not sure what the best way to deal with this is. Do we generate
a PKCS#7 cert from the signature given, or do we get given a PKCS#7 cert? I
lean towards the
The example is wrong in that the phys property should take a
phandle to the phy port.
Also with the changing over to generic PHY type constants we also
update this as well.
Signed-off-by: Peter Griffin peter.grif...@linaro.org
---
Documentation/devicetree/bindings/ata/ahci-st.txt | 4 ++--
1
Wed, Feb 25, 2015 at 02:36:12PM CET, dan.carpen...@oracle.com wrote:
val is declared as a u64 so static checkers complain that this shift
can wrap. I don't have the hardware but probably it's doesn't have over
It's a QEMU hardware, you can have it easily.
31 ports. Still we may as well silence
On 02/25/2015 01:37 PM, Andrey Wagin wrote:
2015-02-13 0:54 GMT+03:00 Denys Vlasenko dvlas...@redhat.com:
My test vm doesn't boot with this patch. Could you help to investigate
this issue?
Hi Andrey, thanks for testing!
I have attached a kernel config and console log.
Looking at the logs,
ST's Low Power Controller can currently operate in two supported modes;
Watchdog and Real Time Clock. These defines will aid engineers to easily
identify the selected mode.
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
include/dt-bindings/mfd/st-lpc.h | 15 +++
1 file changed,
ST's Low Power Controller (LPC) controls two devices; watchdog and RTC.
Only one of the devices can be used at any one time, which is enforced
by the correlating MFD driver.
This driver set provides everything you need to choose one (and only
one) of the LPC devices to run per I/P block, of
* Joakim Hernberg | 2015-02-19 10:36:01 [+0100]:
On Tue, 17 Feb 2015 09:37:44 +0100
Daniel Wagner w...@monom.org wrote:
I needed the patch below to get it running stable under load on my
shiny box.
FWIW, this patch makes 3.18-rt survive thermal events on my laptop.
Okay. I applied a slightly
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 0f172f8..1a861c9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++
On Tue 24-02-15 14:11:27, Johannes Weiner wrote:
[...]
I'm fine with keeping the allocation looping, but is that message
helpful? It seems completely useless to the user encountering it. Is
it going to help kernel developers when we get a bug report with it?
It is better than a silent
On Wednesday 25 February 2015 08:33:16 Ezequiel Garcia wrote:
/me is more confused now
In arch/nios2/include/asm/ucontext.h
struct ucontext {
unsigned long uc_flags;
struct ucontext *uc_link;
stack_t uc_stack;
struct mcontext
On Wed, Feb 25, 2015 at 03:32:08PM +0100, Cornelia Huck wrote:
On Wed, 25 Feb 2015 15:14:36 +0100
Michael S. Tsirkin m...@redhat.com wrote:
virtio balloon has this code:
wait_event_interruptible(vb-config_change,
(diff = towards_target(vb)) != 0
On Wed, 25 Feb 2015, Gabriele Mazzotta wrote:
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
On 02/25/2015 12:22 PM, Ingo Molnar wrote:
* Boaz Harrosh b...@plexistor.com 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]
On Tue, Feb 24, 2015 at 10:02:55PM -0300, Lucas De Marchi wrote:
On Mon, Feb 23, 2015 at 12:51 PM, Michal Marek mma...@suse.cz wrote:
On 2015-02-23 15:30, Lucas De Marchi wrote:
My questions are:
1) should we put *all* the modules in the builtin index?
You mean all *.o files that do not
2015-02-20 19:33 GMT+01:00 Peter Meerwald pme...@pmeerw.net:
STMicrolectronics's STM32 series is a family of Cortex-M
microcontrollers. It is used in various applications, and
proposes a wide range of peripherals.
the text describing the STM32 could be a bit more specific :)
some more
Hi Ezequiel,
On Wed, Feb 25, 2015 at 08:45:12AM -0300, Ezequiel Garcia wrote:
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
2015-02-20 22:37 GMT+01:00 Paul Bolle pebo...@tiscali.nl:
On Fri, 2015-02-20 at 21:00 +0100, Uwe Kleine-König wrote:
On Fri, Feb 20, 2015 at 07:01:13PM +0100, Maxime Coquelin wrote:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed..cfd9532 100644
--- a/arch/arm/Kconfig
+++
2015-02-20 21:00 GMT+01:00 Uwe Kleine-König u.kleine-koe...@pengutronix.de:
Hello,
On Fri, Feb 20, 2015 at 07:01:13PM +0100, Maxime Coquelin wrote:
STMicrolectronics's STM32 series is a family of Cortex-M
microcontrollers. It is used in various applications, and
proposes a wide range of
801 - 900 of 1756 matches
Mail list logo
