The uses of "rcu_assign_pointer()" are NULLing out the pointers.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
On Mon, Aug 18, 2014 at 03:48:00PM +0200, Ulrich Windl wrote:
> >>> Don Zickus schrieb am 18.08.2014 um 14:44 in
> >>> Nachricht
> <20140818124404.gl49...@redhat.com>:
> > On Mon, Aug 18, 2014 at 08:12:44AM +0200, Ulrich Windl wrote:
> >> >>> Don Zickus schrieb am 14.08.2014 um 19:46 in
> >>
Bjorn,
On 07/23/2014 12:43 PM, Bjorn Helgaas wrote:
On Wed, Jul 23, 2014 at 9:27 AM, Murali Karicheri wrote:
Bjorn,
On 07/22/2014 06:57 PM, Bjorn Helgaas wrote:
On Mon, Jul 21, 2014 at 12:58:40PM -0400, Murali Karicheri wrote:
Murali Karicheri (5):
PCI: designware: add
Add the missing 'compatible' property to device tree root node of
- mt6589-aquaris5.dts
and document the new values.
Signed-off-by: Matthias Brugger
---
Documentation/devicetree/bindings/arm/mediatek.txt |6 ++
arch/arm/boot/dts/mt6589-aquaris5.dts |1 +
2 files
Enable Mediatek platform support for multi_v7_defconfig.
Signed-off-by: Matthias Brugger
---
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 5fb95fb..4c08101 100644
---
We enable GTP6 which ungates the arch timer clock. Apart we write the
frequency with which the timer is running in the CNTFREQ register.
In the future this should be done in the bootloader.
Signed-off-by: Matthias Brugger
---
arch/arm/mach-mediatek/mediatek.c | 26 ++
Enable low-level debug for Mediatek mt6589 SoC on UART0.
Signed-off-by: Matthias Brugger
---
arch/arm/Kconfig.debug | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index b11ad54..cfdd1c0 100644
--- a/arch/arm/Kconfig.debug
+++
This patch adds the device tree node for the arm architecture timer.
Signed-off-by: Matthias Brugger
---
arch/arm/boot/dts/mt6589.dtsi | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mt6589.dtsi b/arch/arm/boot/dts/mt6589.dtsi
index
This patch changes the compatible string of the GIC to the
new "arm,cortex-a7-gic" which does reflect the actual hardware.
Signed-off-by: Matthias Brugger
---
arch/arm/boot/dts/mt6589.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt6589.dtsi
This changes the unit address of the gic node to it's first register area.
Signed-off-by: Matthias Brugger
---
arch/arm/boot/dts/mt6589.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt6589.dtsi b/arch/arm/boot/dts/mt6589.dtsi
index
On Mon, Aug 18, 2014 at 04:38:40PM +0800, Shengjiu Wang wrote:
> Building kernel with SND_SOC_IMX_AUDMUX=n leads to the following error:
Applied, thanks.
signature.asc
Description: Digital signature
The uses of "rcu_assign_pointer()" are NULLing out the pointers.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
On Mon, Aug 18, 2014 at 04:38:39PM +0800, Shengjiu Wang wrote:
> When build fsl-asoc-card as module, there is following error:
Applied, thanks.
signature.asc
Description: Digital signature
Hello,
On 15 August 2014 10:41, Peter Zijlstra wrote:
> On Fri, Aug 15, 2014 at 10:37:32AM -0400, Ashwin Chaugule wrote:
>> On 15 August 2014 10:07, Peter Zijlstra wrote:
>> > On Fri, Aug 15, 2014 at 09:08:50AM -0400, Ashwin Chaugule wrote:
>> >> If the OS only looks at Highest, Lowest,
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
On Mon, Aug 18, 2014 at 08:45:08AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 29, 2014 at 04:52:54PM +0200, Frans Klaver wrote:
> > Hi,
> >
> > Here's a couple of patches that should improve the behavior of the omap
> > serial
> > driver at high data rates and baud rates.
> >
> > I was
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
Il 18/08/2014 16:31, Nadav Amit ha scritto:
> The cause for the blue-screen appears to be seabios, which leaves only 0x20
> slots for “smp_mtrr”s.
> Apparently, the increase in the variable range MTRR count caused it to
> exhaust the available slots.
> As a result, some MSRs are not initialised
On 08/17/2014 07:50 PM, Rob Herring wrote:
On 07/30/2014 01:22 PM, ttha...@opensource.altera.com wrote:
From: Thor Thayer
Add the Altera SDRAM controller bindings and device tree changes to the Altera
SoC project.
Signed-off-by: Thor Thayer
---
v2: Changes to SoC SDRAM EDAC code.
v3:
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
On Mon, Aug 18, 2014 at 02:51:15PM +0800, Sean Cross wrote:
> That gives it almost the exact same kernel config as the SGTL5000.
> Is this the sort of thing you can apply on your end, or would you like
> me to resubmit a v12 with just this file? I'm afraid I don't have a PPC
> toolchain to test
The architectures where this peripheral exists (ARM and SH) have expensive
implementations of writel(), reliant on spin locks and explicit L2 cache
management. These architectures provide a cheaper writel_relaxed() which
is much better suited to peripherals that do not perform DMA. The
situation
The use_interrupts is used only in dagp_request_irq() for checking
a value from user config file. It doesn't need in board_t struct.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |4 +---
drivers/staging/dgap/dgap.h |1 -
2 files changed, 1 insertions(+), 4 deletions(-)
The cause for the blue-screen appears to be seabios, which leaves only 0x20
slots for “smp_mtrr”s.
Apparently, the increase in the variable range MTRR count caused it to exhaust
the available slots.
As a result, some MSRs are not initialised by the BIOS (specifically, 3.5-4GB
are not marked as
On Mon, Aug 18, 2014 at 10:34:08AM +0800, Axel Lin wrote:
> Drop const qualifier for ops of struct regulator_desc.
> Allow regulator drivers to update ops before registering regulator.
Applied, thanks.
signature.asc
Description: Digital signature
The brd(board_t) is initialized with zero, so "intr_used"
is not needed to set zero when request_irq() is failed.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c
This patch makes it possible to use the imx uart with KGDB's FIQ/NMI
mode.
Main changes are:
.poll_init() will, if KGDB+FIQ are enabled, perform deeper hardware
initialization to ensure the serial port is always active (required
otherwise FIQ is not triggered by UART activity). This has an
From: Dirk Behme
Looking at the get_poll_char() function of the 8250.c serial driver,
we learn:
* poll_get_char() doesn't have to save/disable/restore the interrupt
registers. No interrupt handling is needed in this function at all.
Remove it.
* Don't block in case there is no data
On Sun, Aug 17, 2014 at 11:20:44PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Sun, Aug 17, 2014 at 4:02 PM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Sun, Aug 17, 2014 at 11:52:17AM +0800, Chen-Yu Tsai wrote:
> >> Add nodes for the 3 i2c controllers found on A23 SoCs to the sun8i DTSI.
> >>
> >>
On Mon, Aug 18, 2014 at 08:00:09PM +0900, Inha Song wrote:
> This patch update DT binding to support INn_MODE init_data. Each
> input signal path can be configurated either as a Analogue or
> Digital using the INn_MODE registers.
>
> Signed-off-by: Inha Song
> ---
>
On Tue, Aug 12, 2014 at 05:26:00PM +0100, Liviu Dudau wrote:
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index e0ecdcf..dc34039 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -121,7 +121,8 @@ static inline u64 __raw_readq(const
On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
>
Add a .poll_init() function that enables UART RX and registers the
UART's irq with KGDB. By providing this information to KGDB the serial
driver offers "permission" for KGDB to route the UART interrupt signal
from the drivers own handler to KGDBs FIQ handler (which will eventually
use the UART's
Speculatively register a FIQ resource with KGDB. KGDB will only
accept it if the kgdb/fiq feature is enabled (both with compile time and
runtime switches) and the interrupt controller supports FIQ.
By providing this information to KGDB the serial driver offers
"permission" for KGDB to route the
On Tue, Aug 12, 2014 at 05:25:13PM +0100, Liviu Dudau wrote:
> This is my updated attempt at adding support for generic PCI host
> bridge controllers that make use of device tree information to
> configure themselves. This version incorporates Catalin's proposal
> for managing domain numbers that
On Sun, Aug 17, 2014 at 12:47:57PM -0400, Oleg Drokin wrote:
> The patches are CCed to linux-kernel by most everybody anyway, so do we
> really need to
> spell this out explicitly with an 'L:' line or in some other way?
driver-devel and linux-kernel are CC'd already. CC'ing linux-kernel is
On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100,
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org]
> On Behalf Of Rickard Strandqvist
> Sent: Sunday, August 17, 2014 5:40 PM
> To: Steve Wise; Roland Dreier
> Cc: Rickard Strandqvist; Sean Hefty; Hal Rosenstock;
>
The use of "rcu_assign_pointer()" is NULLing out the pointer.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
On Mon, Aug 18, 2014 at 08:00:03PM +0900, Inha Song wrote:
> Some boards need to set the INn_MODE[1:0] register to change
> the input signal patch. This wlf,inmode property is optional.
> If present, values must be specified less than or equal to
> the number of input singals. If values less than
Hi Peter,
On 08/12/2014 06:14 PM, Peter Griffin wrote:
> This patch removes the superflous .owner field for drivers which
> use the module_platform_driver API, as this is overriden in
> platform_driver_register anyway.
>
> Signed-off-by: Peter Griffin
> ---
> drivers/mmc/host/jz4740_mmc.c
On Mon, 18 Aug 2014, Du, ChangbinX wrote:
> > On Fri, 15 Aug 2014, Du, ChangbinX wrote:
> > > If my analysis is correct, could you share your ideas for this issue?
> >
> > Hasn't this already been fixed? See commit d6236f6d1d88 (xhci: Fix runtime
> > suspended xhci from blocking system
On Mon, Aug 18, 2014 at 12:20:20PM +0100, Alban Crequy wrote:
> /proc//cgroup contains one cgroup path on each line. If cgroup names are
> allowed to contain "\n", applications cannot parse /proc//cgroup safely.
>
> Signed-off-by: Alban Crequy
Applied to cgroup/for-3.17-fixes w/ stable cc'd.
On Sun, Aug 17, 2014 at 10:11:30AM -0700, Tim Kryger wrote:
> On Fri, Aug 15, 2014 at 3:29 PM, Mark Brown wrote:
> > Nobody has written suitable code, and please bear in mind that even if
> > the code is written there will probably be cases where it's too
> > expensive for whatever reason so
This patch is motivated by the comment it removes from gic_init_fiq,
namely that the spin locks in eoi_irq preclude certain platforms from
supporting FIQ.
Currently there is only one upstream platform (tegra) that actually
hooks gic_arch_extn.irq_eoi and it does not require these spin locks.
An ARM system based on GICv1 that runs by default in secure mode and
uses both group 0 and group 1 interrupts (in order to exploit FIQ)
will suffer a problem where the IRQ handler occasionally spuriously
acknowledges a group 0 (FIQ) interrupt.
This can be prevented by ensuring the IRQ handler
This patch introduces callbacks to route interrupts to or away
from the FIQ signal and registers these callbacks with the FIQ
infrastructure (if the device can supports it).
Both these aspects combine and allow a driver to deploy a FIQ handler
without any machine specific knowledge; it can be
To support IPI FIQ we alter gic_cpu_init() to honour SMP_IPI_FIQ_MASK and
register a fairly high priority notifier to acknowledge and clear the IPI
when it is triggered.
For the IPI FIQ to be useful we must also make it safe to call
gic_raise_softirq() from the FIQ handler by altering the locking
All GIC hardware except GICv1-without-TrustZone support provides a means
to group exceptions into group 0 (which can optionally be signally using
use FIQ) and group 1. The kernel currently provides no means to exploit
this. This patch alters the initialization of the GIC to place all
interrupts
This patch introduces callbacks to route interrupts to or away
from the FIQ signal. It also causes these callbacks to be registered
with the FIQ infrastructure.
This patch enable FIQ support for mach-versatile whilst mach-ep93xx,
mach-netx, mach-s3c64xx and plat-samsung are unmodified (and can
On 08/18/2014 12:44 AM, Mike Galbraith wrote:
On Sat, 2014-08-16 at 19:50 +0200, Oleg Nesterov wrote:
On 08/16, Rik van Riel wrote:
+ do {
+ seq = nextseq;
+ read_seqbegin_or_lock(>stats_lock, );
+ times->utime = sig->utime;
+
On Mon, Aug 18, 2014 at 09:09:14PM +0800, Guodong Xu wrote:
> This adds driver to support HiSilicon Hi6421 PMIC. Hi6421 includes multi-
> functions, such as regulators, codec, ADCs, Coulomb counter, etc.
> This driver includes core APIs _only_.
Please don't resend already applied patches, if
Il 14/08/2014 09:01, Xiao Guangrong ha scritto:
> - update_memslots(slots, new, kvm->memslots->generation);
> + /* ensure generation number is always increased. */
> + slots->generation = old_memslots->generation;
> + update_memslots(slots, new);
>
On Fri, Aug 15, 2014 at 07:42:34PM +0200, Sebastian Andrzej Siewior wrote:
> diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
> index b161eee..02e82dc 100644
> --- a/include/linux/serial_8250.h
> +++ b/include/linux/serial_8250.h
> @@ -85,6 +85,7 @@ struct uart_8250_port {
>
>>> Don Zickus schrieb am 18.08.2014 um 14:44 in Nachricht
<20140818124404.gl49...@redhat.com>:
> On Mon, Aug 18, 2014 at 08:12:44AM +0200, Ulrich Windl wrote:
>> >>> Don Zickus schrieb am 14.08.2014 um 19:46 in
>> >>> Nachricht
>> <20140814174658.gv49...@redhat.com>:
>> > On Wed, Aug 13, 2014
Hi,
On Fri, Aug 15, 2014 at 07:42:33PM +0200, Sebastian Andrzej Siewior wrote:
> diff --git a/drivers/tty/serial/8250/8250_core.c
> b/drivers/tty/serial/8250/8250_core.c
> index cc90c19..ab003b6 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@
Hi,
On Tue, Jul 29, 2014 at 04:52:54PM +0200, Frans Klaver wrote:
> Hi,
>
> Here's a couple of patches that should improve the behavior of the omap serial
> driver at high data rates and baud rates.
>
> I was actually surprised to see that proper dma support isn't there yet, but
> there you go.
Currently enable_fiq/disable_fiq use a simple offset to convert an IRQ
virq into a FIQ virq. This is too inflexible for multi-platform kernels
and makes runtime error checking impossible.
We solve this by introducing a flexible mapping that allows interrupt
controllers that support FIQ to
On 15/08/2014 17:05, Jason Cooper :
> On Fri, Aug 15, 2014 at 04:41:50PM +0200, Boris BREZILLON wrote:
>> On Fri, 15 Aug 2014 10:22:25 -0400 Jason Cooper wrote:
>>> On Thu, Aug 14, 2014 at 05:45:56PM +0200, Nicolas Ferre wrote:
Arnd, Olof, Kevin,
Boris moved both of our AIC drivers
Modern ARM interrupt controllers require an ACK as interrupts are taken
and an EOI on completion. The FIQ code currently does not provide any
API to perform this.
This patch provides this API, implemented by adding two callbacks to the
fiq_chip structure.
Signed-off-by: Daniel Thompson
Cross CPU signalling based on FIQ is especially useful for kgdb since
it makes stopping all the CPUs during breakpointing more robust (some
of the other architectures already roundup the CPUs using NMIs).
The approach taken provides infrastructure that can be called (or not) by
the driver's FIQ
The FIQ debugger may be used to debug situations when the kernel stuck
in uninterruptable sections, e.g. the kernel infinitely loops or
deadlocked in an interrupt or with interrupts disabled.
Credit:
This patch is a near complete re-write of a patch originally
provided by Anton
This patch introduces a new default FIQ handler that is structured in a
similar way to the existing ARM exception handler and result in the FIQ
being handled by C code running on the SVC stack (despite this code run
in the FIQ handler is subject to severe limitations with respect to
locking making
This patchset makes it possible to use kgdb's NMI infrastructure on ARM
platforms.
The patches are seperated into three distinct groups:
1. arm specific changes; these provide multi-platform support for FIQ
(including raising an IPI using FIQ to ensure effective SMP support)
and extend ARM
Networking under kvm works best if we allocate a per-vCPU RX and TX
queue in a virtual NIC. This requires a per-vCPU queue on the host side.
It is now safe to increase the maximum number of queues.
Preceding patches:
net: allow large number of rx queues
tuntap: Reduce the size of
netif_alloc_rx_queues() uses kcalloc() to allocate memory
for "struct netdev_queue *_rx" array.
If we are doing large rx queue allocation kcalloc() might
fail, so this patch does a fallback to vzalloc().
Similar implementation is done for tx queue allocation in
netif_alloc_netdev_queues().
We
This patch publishes maximum number of tun/tap queues allocated as a
read_only module parameter which a user space application like libvirt
can make use of to limit maximum number of queues. Value of read_only
module parameter can be writable only at module load time. If no value is set
at
This patch switches to flex array to implement the flow caches, it brings
several advantages:
- Reduce the size of the tun_struct structure, which allows us to increase the
upper limit of queues in future.
- Avoid higher order memory allocation. It will be useful when switching to
pure
Networking under KVM works best if we allocate a per-vCPU rx and tx
queue in a virtual NIC. This requires a per-vCPU queue on the host side.
Modern physical NICs have multiqueue support for large number of queues.
To scale vNIC to run multiple queues parallel to maximum number of vCPU's
we need to
Hi,
Le lundi 18 août 2014 à 00:40 +0200, Rickard Strandqvist a écrit :
> Added a guaranteed null-terminate after call to strncpy.
>
Good catch. Do you have an automated way to catch such mistake ?
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/infiniband/hw/cxgb3/cxio_hal.c |1 +
>
At Mon, 18 Aug 2014 14:22:17 +0200,
Oleg Nesterov wrote:
>
> On 08/18, Takashi Iwai wrote:
> >
> > #define module_long_probe_init(initfn) \
> > static int _long_probe_##initfn(void *arg) \
> > {
Hi Pavel,
Am Montag, den 18.08.2014, 15:16 +0200 schrieb Pavel Machek:
> Hi!
>
> I'm getting
>
> socfpga-reset ffd05000.rstmgr: /soc/rstmgr@ffd05000 missing
> #reset-cells property
> socfpga-reset: probe of ffd05000.rstmgr failed with error -22
>
> messages in 3.16... which is no wonder, since
On Mon, 2014-08-18 at 15:09 +0530, Arun Chandran wrote:
> Hi,
>
> I have a piece of code as shown below.
>
> ###
> diff --git a/arch/arm64/include/asm/proc-fns.h
> b/arch/arm64/include/asm/proc-fns.h
> index 9a8fd84..86be4f9 100644
> --- a/arch/arm64/include/asm/proc-fns.h
>
Hello Nick,
On 08/15/2014 06:08 PM, Nick Dyer wrote:
>>
>> Any comments on this? I would really appreciate if you can expand on how
>> this DT property is supposed to be used so I can re-spin the atmel support
>> patch for Peach boards.
>
> The below patch improves the documentation for the
Replace ext_csd "enhanced_area_en" attribute by "partition_setting_completed".
It was used whether or not enhanced user area is defined and without checks of
EXT_CSD_PARTITION_SETTING_COMPLETED bit.
Signed-off-by: Grégory Soutadé
---
drivers/mmc/core/mmc.c |8 +++-
Hello, Xishi, Tang.
On Mon, Aug 18, 2014 at 11:18:00AM +0800, Xishi Qiu wrote:
> If all the nodes are marked hotpluggable flag, alloc node data will fail.
> Because __next_mem_range_rev() will skip the hotpluggable memory regions.
> numa_register_memblks()
> setup_node_data()
>
Checks EXT_CSD_PARTITION_SETTING_COMPLETED bit before
computing enhanced user area offset and size, and adding
mmc general purpose partitions.
The two needs EXT_CSD_PARTITION_SETTING_COMPLETED bit be set
to be valid (as described in JEDEC standard).
Signed-off-by: Grégory Soutadé
---
함명주 writes:
>> --- Original Message ---
>> Sender : Hernandez, Carlos
>> Date : 2014-08-12 22:49 (GMT+09:00)
>> Title : RE: [PATCH 1/2] PM / devfreq: Export helper functions for drivers
>>
>> Acked-By: Carlos Hernandez
>>
>> -Original Message-
>> From:
Hi!
I'm getting
socfpga-reset ffd05000.rstmgr: /soc/rstmgr@ffd05000 missing
#reset-cells property
socfpga-reset: probe of ffd05000.rstmgr failed with error -22
messages in 3.16... which is no wonder, since no socfpga-related dts
contains that property. Is there part of the patch that is missing
Add Hi6421 MFD dts node and regulator nodes into hi3620-hi4511
board config dts file.
Signed-off-by: Guodong Xu
---
arch/arm/boot/dts/hi3620-hi4511.dts | 233
1 file changed, 233 insertions(+)
diff --git a/arch/arm/boot/dts/hi3620-hi4511.dts
This adds driver to support HiSilicon Hi6421 PMIC. Hi6421 includes multi-
functions, such as regulators, codec, ADCs, Coulomb counter, etc.
This driver includes core APIs _only_.
Drivers for individul components, like voltage regulators, are
implemented in corresponding driver directories and
Add driver support for HiSilicon Hi6421 voltage regulators.
Two rules for regulator enabling are defined in hi6421 spec:
1) Between disable and enable of each regulator (LDOs or BUCKs), there must
be a protection gap. Use @off_on_delay of regulator core to implement this.
2) No two regulators
Some regulator require a minimum delay between its disable and next enable.
This is to avoid damages when out-of-range frequent disable/enable of a
single regulator can bring to the regulator chip.
Add @off_on_delay to struct regulator_desc. Device drivers' can use this field
to set this guard
On 18 August 2014 14:36, Geert Uytterhoeven wrote:
> Hi Ian,
>
> On Fri, Aug 15, 2014 at 2:49 PM, Ian Molton
> wrote:
>> On Thu, 14 Aug 2014 17:23:53 +0200
>> Geert Uytterhoeven wrote:
>>
>>> On R-Car Gen 2, the SDHI registers cannot be accessed while the SDHI
>>> module clock is disabled.
struct regulator_ops *ops is a member in struct regulator_desc, which gets
its value from individual regulator driver upon regulator_register() and
is used by regulator core APIs. It's not allowed for regulator core to
modify any of these callbacks in *ops. Add 'const' qualifier to enforce that.
A common delay function can be helpful when implementing new features. Factor
it out to maximize code reusability.
Signed-off-by: Guodong Xu
---
drivers/regulator/core.c | 74 ++--
1 file changed, 40 insertions(+), 34 deletions(-)
diff --git
This patchset adds an MFD core driver and a regulator driver for Hi6421 PMIC
SoC.
Hi6421 is a PMIC SoC designed and manufactured by HiSilicon Ltd. It includes
multi-functions, such as regulators, codec, ADCs, Coulomb counter, etc.
Hi6421 can be used in various Hi3620 SoC based boards. Registers
Commit d647c199510c ("regmap: add DT endianness binding support.")
added support to parse the device endianness from the device tree
but unfortunately the added logic doesn't have the same semantics
than the old code. This leads to a NULL dereference pointer error
when these properties are not
I'm sending a patch to fix the build error on mc13892-regulator.c
-Guodong
On 08/18/2014 10:34 AM, Axel Lin wrote:
> Drop const qualifier for ops of struct regulator_desc.
> Allow regulator drivers to update ops before registering regulator.
>
> Fix below build error:
> CC [M]
Hey,
Op 18-08-14 om 14:57 schreef Dan Carpenter:
> On Thu, Aug 14, 2014 at 11:53:38AM +0200, Maarten Lankhorst wrote:
>> According to the documentation sync_fence_create takes ownership of the
>> point,
>> not a reference on the point.
>>
> What are the user visible effects of this bug? I
On Thu, Aug 14, 2014 at 11:53:38AM +0200, Maarten Lankhorst wrote:
> According to the documentation sync_fence_create takes ownership of the point,
> not a reference on the point.
>
What are the user visible effects of this bug? I assume this is a real
bug but judging solely based on your patch
On Mon, Aug 18, 2014 at 10:29:26AM +0100, Hanjun Guo wrote:
> On 2014-8-15 18:01, Catalin Marinas wrote:
> > Hanjun,
>
> Hi Catalin,
>
> >
> > On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 18:27, Catalin Marinas wrote:
> >>> On Thu, Aug 14, 2014 at 04:21:25AM
Il 18/08/2014 14:27, Wanpeng Li ha scritto:
> > Section 11.11.2.3 of the SDM mentions "All other bits in the
> > IA32_MTRR_PHYSBASEn
> > and IA32_MTRR_PHYSMASKn registers are reserved; the processor generates a
> > general-protection exception(#GP) if software attempts to write to them".
> >
On 8/18/14, 4:29, "Mika Westerberg"
wrote:
>On Sun, Aug 17, 2014 at 01:54:16PM +0100, Grant Likely wrote:
>> On Sun, 17 Aug 2014 09:04:14 +0300, Mika Westerberg
>> wrote:
>> > From: Aaron Lu
>> >
>> > With the unified device properties interface in place, add device
>>tree support.
>> > By
On Mon, Aug 18, 2014 at 08:12:44AM +0200, Ulrich Windl wrote:
> >>> Don Zickus schrieb am 14.08.2014 um 19:46 in
> >>> Nachricht
> <20140814174658.gv49...@redhat.com>:
> > On Wed, Aug 13, 2014 at 05:22:17PM +0200, Ulrich Windl wrote:
> >> Hello!
> >>
> >> Running the current SLES11 SP3 kernel
The uses of "rcu_assign_pointer()" are NULLing out the pointers.
According to RCU_INIT_POINTER()'s block comment:
"1. This use of RCU_INIT_POINTER() is NULLing out the pointer"
it is better to use it instead of rcu_assign_pointer() because it has a
smaller overhead.
The following Coccinelle
On 15 August 2014 15:02, Peter Griffin wrote:
> .set_uhs_signaling field is currently initialised twice once to the
> arch specific callback pxav3_set_uhs_signaling, and also to the generic
> sdhci_set_uhs_signaling callback.
>
> This means that uhs is currently broken for this platform
On 12 August 2014 18:14, Peter Griffin wrote:
> This series cleans up a few platform drivers in how they are declaring there
> dev_pm_ops structs, and gets rid of a few now redundant #else conditions.
>
> Also it removes the .owner field of drivers which use module_platform_driver
> api to
Hello,
On Mon, Aug 18, 2014 at 5:33 AM, Arjun Sreedharan wrote:
> @number first, @size second argument
>
> Signed-off-by: Arjun Sreedharan
Acked-by: Eduardo Valentin
> ---
> tools/thermal/tmon/sysfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
301 - 400 of 1499 matches
Mail list logo
