On 04/01/16 at 02:25pm, Russell King - ARM Linux wrote:
[snip]
> Well, if we want to remove it, we then need to sort out a method of
> specifying a limit on the address - where platforms physical memory
> bridges the 4GB CPU-accessible limit, the crashkernel region must be
> allocated below that
Hi Yuri,
On Wed, Apr 6, 2016 at 12:08 AM, Yury Norov wrote:
> This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem.
> It works with updated glibc [1] (though very draft), and tested with LTP.
>
> It was tested on QEMU and ThunderX machines. No major difference found.
> Th
On 2016/4/6 8:00, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:46:44PM +0800, Yongji Xie wrote:
This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can ensure that a given pci device can only
shoot the MSIs assigned for it.
Signed-off-by: Yongji Xie
---
driv
On 2016/4/6 8:11, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:46:43PM +0800, Yongji Xie wrote:
I'm trying to find a proper way to indicate
the capability of interrupt remapping on PPC64
because we need this to determine whether it is
safe to mmap MSI-X table in VFIO driver.
There is a existing
On 2016/4/6 8:48, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:43:29PM +0800, Yongji Xie wrote:
The resource_alignment will releases memory
resources allocated by firmware so that kernel
can reassign new resources later on. But this
will cause the problem that no resources can be
allocated by ke
On 2016/4/6 8:55, Gavin Shan wrote:
On Tue, Apr 05, 2016 at 09:43:30PM +0800, Yongji Xie wrote:
Now we use the IORESOURCE_STARTALIGN to identify
bridge resources in __assign_resources_sorted().
That's quite fragile. We can't make sure that
the PCI devices' resources will not use
IORESOURCE_START
On Tue, Apr 05, 2016 at 09:43:31PM +0800, Yongji Xie wrote:
>When using resource_alignment kernel parameter,
>the current implement reassigns the alignment by
>changing resources' size which can potentially
>break some drivers. For example, the driver uses
>the size to locate some register whose le
On Tue, 5 Apr 2016, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 05, 2016 at 11:43:36AM -0400, Chris Patterson wrote:
> > On Tue, Apr 5, 2016 at 9:49 AM, Konrad Rzeszutek Wilk
> > wrote:
> > > On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote:
> > >> Add earlycon=xenboot option to Docu
On Tue, Apr 05, 2016 at 09:43:30PM +0800, Yongji Xie wrote:
>Now we use the IORESOURCE_STARTALIGN to identify
>bridge resources in __assign_resources_sorted().
>That's quite fragile. We can't make sure that
>the PCI devices' resources will not use
>IORESOURCE_STARTALIGN any more.
>
>In this patch,
On Tue, Apr 05, 2016 at 09:43:29PM +0800, Yongji Xie wrote:
>The resource_alignment will releases memory
>resources allocated by firmware so that kernel
>can reassign new resources later on. But this
>will cause the problem that no resources can be
>allocated by kernel if PCI_PROBE_ONLY was set,
>e
On Tue, Apr 05, 2016 at 09:46:43PM +0800, Yongji Xie wrote:
>I'm trying to find a proper way to indicate
>the capability of interrupt remapping on PPC64
>because we need this to determine whether it is
>safe to mmap MSI-X table in VFIO driver.
>
>There is a existing flag for this in the IOMMU
>spac
On Tue, Apr 05, 2016 at 09:46:44PM +0800, Yongji Xie wrote:
>This patch enables mmapping MSI-X tables if
>hardware supports interrupt remapping which
>can ensure that a given pci device can only
>shoot the MSIs assigned for it.
>
>Signed-off-by: Yongji Xie
>---
> drivers/vfio/pci/vfio_pci.c
On 4/5/2016 8:48 PM, Laxman Dewangan wrote:
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Milo Kim
Acked-by: Milo Kim
---
drivers/mfd/lp3943.c |
There are about 20 failing tests of 782 in lite scenario.
float_bessel
float_exp_log
float_iperb
float_power
float_trigo
pipeio_1
pipeio_3
pipeio_5
pipeio_8
abort01
clone02
kill11
mmap16
open12
pause01
rename1
From: Andrew Pinski
Add a separate syscall-table for ILP32, which dispatches either to native
LP64 system call implementation or to compat-syscalls, as appropriate.
Signed-off-by: Andrew Pinski
Signed-off-by: Yury Norov
---
arch/arm64/include/asm/unistd.h | 11 ++-
arch/arm64/kernel/Makef
From: Philipp Tomsich
ILP32 VDSO exports next symbols:
__kernel_rt_sigreturn;
__kernel_gettimeofday;
__kernel_clock_gettime;
__kernel_clock_getres;
What shared object to use, kernel selects depending on result of
is_ilp32_compat_task() in arch/arm64/kernel/vdso.c, so it substitutes
correct p
After that, it will be possible to reuse it in ilp32.
Signed-off-by: Yury Norov
---
arch/arm64/include/asm/signal_common.h | 33
arch/arm64/kernel/signal.c | 91 +-
2 files changed, 90 insertions(+), 34 deletions(-)
create mode 100644 arc
Here new aarch32 ptrace syscall handler is introsuced to avoid run-time
detection of the task type.
Signed-off-by: Yury Norov
---
arch/arm64/include/asm/unistd32.h | 2 +-
arch/arm64/kernel/ptrace.c| 50 ++-
arch/arm64/kernel/sys32.c | 1 +
i
They may be accessed from low-level code, so isolating is a measure to
avoid circular dependencies in header files.
The exact reason for circular dependency is WARN_ON() macro added by Al
Viro in patch "set_restore_sigmask() is never called without SIGPENDING
(and never should be)" [edd63a27]
Sig
to handle ILP32 binaries
Signed-off-by: Yury Norov
---
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/binfmt_ilp32.c | 91
2 files changed, 92 insertions(+)
create mode 100644 arch/arm64/kernel/binfmt_ilp32.c
diff --git a/arch/arm64/kernel/M
From: Andrew Pinski
This patch adds the config option for ILP32.
Signed-off-by: Andrew Pinski
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
Signed-off-by: Yury Norov
Reviewed-by: David Daney
---
arch/arm64/Kconfig | 10 +-
1 file changed, 9 insertions(+), 1 delet
Signed-off-by: Yury Norov
---
arch/arm64/include/asm/signal32_common.h | 25 +++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/signal32.c | 85 ---
arch/arm64/kernel/signal32_common.c | 115 +++
4 files c
From: Andrew Pinski
Define __BITS_PER_LONG depending on the ABI used (i.e. check whether
__ILP32__ or __LP64__ is defined). This is necessary for glibc to
determine the appropriate type definitions for the system call interface.
Signed-off-by: Andrew Pinski
Signed-off-by: Philipp Tomsich
Sign
As we support more than one compat formats, it looks more reasonable
to not use fs/compat_binfmt.c. Custom binfmt_elf32.c allows to move aarch32
specific definitions there and make code more maintainable and readable.
Signed-off-by: Yury Norov
---
arch/arm64/Kconfig | 1 -
arch/ar
From: Andrew Pinski
Signed-off-by: Andrew Pinski
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
Signed-off-by: Yury Norov
Reviewed-by: David Daney
---
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/hwcap.h | 4 ++--
arch/arm64/include/asm/process
Based on patch of Andrew Pinski.
This patch introduces is_a32_compat_task and is_a32_thread so it is
easier to say this is a a32 specific thread or a generic compat thread/task.
Corresponding functions are located in to avoid mess in
headers.
Some files include both and ,
and this is wrong beca
From: Andrew Pinski
The kernel needs to be compiled as a LP64 binary for ARM64, even when
using a compiler that defaults to code-generation for the ILP32 ABI.
Consequently, we need to explicitly pass '-mabi=lp64' (supported on
gcc-4.9 and newer).
Signed-off-by: Andrew Pinski
Signed-off-by: Phil
ILP32 tasks are needed to be distinguished from lp64 and aarch32.
This patch adds helper functions is_ilp32_compat_{task,thread} and
thread flag TIF_32BIT_AARCH64 to address it. This is a preparation
for following patches in ilp32 patchset.
For consistency, SET_PERSONALITY are changed here accordi
From: Andrew Pinski
In this patchset ILP32 ABI support is added. Additionally to AARCH32,
which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible.
>From now, AARCH32_EL0 (former COMPAT) config option means the support of
AARCH32 userspace, ARM64_ILP32 - support of ILP32 ABI (see n
The only difference is that non-compat version forces O_LARGEFILE,
and it should be the default behaviour for all architectures, as
we don't support 32-bit off_t. The only exception is tile32, that
continues with compat version of syscalls.
Signed-off-by: Yury Norov
Acked-by: Arnd Bergmann
Acked
From: Bamvor Jian Zhang
With the patches of ILP32, COMPAT is not equivalent to AARCH32 in EL0.
This patch fix this by updating the dependency from COMPAT to
AARCH32_EL0 for ARMV8_DEPRECATED and ARM64_ERRATUM_845719.
Signed-off-by: Bamvor Jian Zhang
Signed-off-by: Yury Norov
---
arch/arm64/Kco
Signed-off-by: Yury Norov
Acked-by: Heiko Carstens
---
Documentation/adding-syscalls.txt | 32
1 file changed, 32 insertions(+)
diff --git a/Documentation/adding-syscalls.txt
b/Documentation/adding-syscalls.txt
index cc2d4ac..d02a6bd 100644
--- a/Documentation/
Based on Andrew Pinski's patch-series.
Signed-off-by: Yury Norov
---
Documentation/arm64/ilp32.txt | 13 +
1 file changed, 13 insertions(+)
create mode 100644 Documentation/arm64/ilp32.txt
diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt
new file mode 1006
Signed-off-by: Yury Norov
Acked-by: Heiko Carstens
---
arch/Kconfig | 4
arch/s390/Kconfig | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 81869a5..92fcbd4 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -589,6 +589,10 @@ config HAVE_STACK_VALIDA
This patch moves required calls to generic files to let other arches use
it if needed. Here also, additional code is introduced, as s390 uses asm
syscall tables, while in general case, wrappers may be used in C code.
__SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
m
As generic unistd syscall table is written in C, syscall
prototypes declaration is needed. It's added to compat header.
Signed-off-by: Yury Norov
Acked-by: Heiko Carstens
---
include/linux/compat.h| 225 +
include/uapi/asm-generic/unistd.h | 227 +
All new 32-bit architectures should have 64-bit off_t type, but existing
architectures has 32-bit ones.
To handle it, new config option is added to arch/Kconfig that defaults
ARCH_32BIT_OFF_T to be disabled for non-64 bit architectures. All existing
32-bit architectures enable it explicitly here.
Some syscalls are declared conditionally, so corresponding wrappers
are conditional accordingly.
Signed-off-by: Yury Norov
Acked-by: Heiko Carstens
---
arch/s390/kernel/Makefile | 2 +-
arch/s390/kernel/compat_linux.c | 4 +
arch/s390/kernel/compat_wrapper.c | 129
From: Andrew Pinski
ILP32 uses AARCH32 compat structures and syscall handlers for signals.
But ILP32 struct rt_sigframe and ucontext differs from both LP64 and
AARCH32. So some specific mechanism is needed to take care of it.
Signed-off-by: Andrew Pinski
Signed-off-by: Yury Norov
---
arch/ar
This version is rebased on kernel v4.6-rc2, and has fixes in signal subsystem.
It works with updated glibc [1] (though very draft), and tested with LTP.
It was tested on QEMU and ThunderX machines. No major difference found.
This is RFC because ILP32 is not tested in big-endian mode.
v3: https:/
On Tue, Apr 5, 2016 at 12:42 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Apr 05, 2016 at 11:43:36AM -0400, Chris Patterson wrote:
>> On Tue, Apr 5, 2016 at 9:49 AM, Konrad Rzeszutek Wilk
>> wrote:
>> > On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote:
>> >> Add earlycon=xenboot opti
On Tue, Apr 05, 2016 at 01:37:49PM -0500, Dinh Nguyen wrote:
> My only suggestion was to change the 3 helper functions(ecc_set_bits,
> ecc_clear_bits, and ecc_test_bits) should be static inline.
That doesn't take care of the iounmap error path Thor is talking about,
AFAICT.
So, I've pushed out wh
On Thu, 31 Mar 2016, ttha...@opensource.altera.com wrote:
> From: Thor Thayer
>
> Add the device tree entries needed to support the Altera On-Chip
> RAM EDAC on the Arria10 chip.
>
> Signed-off-by: Thor Thayer
> ---
> v2: No change
> ---
> arch/arm/boot/dts/socfpga_arria10.dtsi |5 +
>
On Tue, 5 Apr 2016, Borislav Petkov wrote:
> On Tue, Apr 05, 2016 at 12:25:33AM -0500, Thor Thayer wrote:
> > I realize that I'm not calling iounmap(ecc_block_base) and I'll fix that in
> > the next revision with a goto.
>
> I'm assuming nothing else changes. Because I've applied 1-4 already.
>
Here is a respin of the task-isolation patch set. The previous one
came out just before the merge window for 4.6 opened, so I suspect
folks may have been busy merging, since it got few comments.
Frederic, how are you feeling about taking this all via your tree?
And what is your take on the new PR
When this flag is set by the initial prctl(), the semantics of task
isolation change to be "one-shot", i.e. as soon as the kernel is
re-entered for any reason, task isolation is turned off.
During application development, use of this flag is best coupled with
STRICT mode, since otherwise any bug (
This option, similar to NO_HZ_FULL_ALL, simplifies configuring
a system to boot by default with all cores except the boot core
running in task isolation mode.
Signed-off-by: Chris Metcalf
---
init/Kconfig | 10 ++
kernel/isolation.c | 6 ++
2 files changed, 16 insertions(+)
d
The new "task_isolation_debug" flag simplifies debugging
of TASK_ISOLATION kernels when processes are running in
PR_TASK_ISOLATION_ENABLE mode. Such processes should get no
interrupts from the kernel, and if they do, we notify either the
process (if STRICT mode is set and the interrupt is not an N
The existing nohz_full mode is designed as a "soft" isolation mode
that makes tradeoffs to minimize userspace interruptions while
still attempting to avoid overheads in the kernel entry/exit path,
to provide 100% kernel semantics, etc.
However, some applications require a "hard" commitment from th
With task_isolation mode, the task is in principle guaranteed not to
be interrupted by the kernel, but only if it behaves. In particular,
if it enters the kernel via system call, page fault, or any of a
number of other synchronous traps, it may be unexpectedly exposed
to long latencies. Add a sim
On Tue, Apr 05, 2016 at 05:55:26AM -0700, Parav Pandit wrote:
> Just because we add one more rdma resource, we need to ask someone to
> upgrade kernel?
Yes. Just like when you need any other core kernel resource.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body
On Tue, 5 Apr 2016 17:18:17 +0530
Laxman Dewangan wrote:
> Use devm_mfd_add_devices() for mfd devices registration and get
> rid of .remove callback to remove mfd devices. This is done
> by managed device framework.
>
> Signed-off-by: Laxman Dewangan
> CC: Boris Brezillon
Acked-by: Boris Brez
On Tue, Apr 5, 2016 at 9:49 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Apr 04, 2016 at 10:48:11PM -0400, Chris Patterson wrote:
>> Add earlycon=xenboot option to Documentation/kernel-parameters.txt.
>>
>
> But it is not true.
>
> I tried this on x86: "earlycon=xenboot console=tty0"
>
I can invest
On Tue, Apr 05, 2016 at 05:55:26AM -0700, Parav Pandit wrote:
> Hi Christoph,
>
> On Tue, Apr 5, 2016 at 5:42 AM, Christoph Hellwig wrote:
> > On Tue, Apr 05, 2016 at 05:39:21AM -0700, Parav Pandit wrote:
> >> I am not really trying to address OFED issues here. I am sure you
> >> understand that
Hello, Parav.
On Tue, Apr 05, 2016 at 07:25:11AM -0700, Parav Pandit wrote:
> > As it is a fairly isolated domain, to certain extent, it could be okay
> > to let it go. At the same time, I know that these enterprise things
> > tend to go completely wayward and am worried about individual drivers
On Tue, Apr 5, 2016 at 7:01 AM, Tejun Heo wrote:
> Hello, Parav.
>
> On Mon, Apr 04, 2016 at 07:22:38PM -0700, Parav Pandit wrote:
>> > Is it actually customary to have rdma core module updated more
>> > frequently separate from the kernel? Out-of-tree modules being
>> > updated separately happen
On Tue, Apr 5, 2016 at 7:07 AM, Tejun Heo wrote:
> Just one more thing.
>
> On Tue, Apr 05, 2016 at 10:01:07AM -0400, Tejun Heo wrote:
> ...
>> > pool_info in spin lock context, made me allocate memory to get all
>> > values upfront through allocation.
>> > Now that the lock is going away, I can d
Just one more thing.
On Tue, Apr 05, 2016 at 10:01:07AM -0400, Tejun Heo wrote:
...
> > pool_info in spin lock context, made me allocate memory to get all
> > values upfront through allocation.
> > Now that the lock is going away, I can do what you have described above.
So, this might be okay dep
Hello, Parav.
On Mon, Apr 04, 2016 at 07:22:38PM -0700, Parav Pandit wrote:
> > Is it actually customary to have rdma core module updated more
> > frequently separate from the kernel? Out-of-tree modules being
> > updated separately happens quite a bit but this is an in-kernel
> > module, which u
Now we use the IORESOURCE_STARTALIGN to identify
bridge resources in __assign_resources_sorted().
That's quite fragile. We can't make sure that
the PCI devices' resources will not use
IORESOURCE_STARTALIGN any more.
In this patch, we try to use a more robust way
to identify bridge resources.
Sign
I'm trying to find a proper way to indicate
the capability of interrupt remapping on PPC64
because we need this to determine whether it is
safe to mmap MSI-X table in VFIO driver.
There is a existing flag for this in the IOMMU
space:
enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOM
This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can ensure that a given pci device can only
shoot the MSIs assigned for it.
Signed-off-by: Yongji Xie
---
drivers/vfio/pci/vfio_pci.c |9 +++--
drivers/vfio/pci/vfio_pci_private.h |1 +
dr
When vfio passthrough a PCI device of which MMIO
BARs are smaller than PAGE_SIZE, guest will not
handle the mmio accesses to the BARs which leads
to mmio emulations in host.
This is because vfio will not allow to passthrough
one BAR's mmio page which may be shared with other
BARs. Otherwise, there
When using resource_alignment kernel parameter,
the current implement reassigns the alignment by
changing resources' size which can potentially
break some drivers. For example, the driver uses
the size to locate some register whose length is
related to the size.
This adds a new option "noresize" f
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs because
these BARs' mmio page may be shared with other
BARs.
But we should allow to mmap these sub-page MMIO
BARs if we can make sure these BARs' mmio page
will not be shared with other BARs.
To acheive that, w
The resource_alignment will releases memory
resources allocated by firmware so that kernel
can reassign new resources later on. But this
will cause the problem that no resources can be
allocated by kernel if PCI_PROBE_ONLY was set,
e.g. on pSeries platform because PCI_PROBE_ONLY
force kernel to use
Current vfio-pci implementation disallows to mmap
sub-page(size < PAGE_SIZE) MMIO BARs and MSI-X table. This is because
sub-page BARs' mmio page may be shared with other BARs and MSI-X table
should not be accessed directly from the guest for security reasons.
But it will easily cause some performa
On Tue, Apr 05, 2016 at 05:18:32PM +0530, Laxman Dewangan wrote:
> Use devm_mfd_add_devices() for mfd devices registration and get
> rid of .remove callback to remove mfd devices. This is done
> by managed device framework.
>
> Signed-off-by: Laxman Dewangan
> CC: Mark Brown
> CC: patc...@openso
On Tue, Apr 5, 2016 at 1:48 PM, Laxman Dewangan wrote:
> Use devm_mfd_add_devices() for mfd devices registration and get
> rid of .remove callback to remove mfd devices. This is done
> by managed device framework.
>
> Signed-off-by: Laxman Dewangan
> CC: Linus Walleij
Acked-by: Linus Walleij
On Tue, Apr 05, 2016 at 05:18:21PM +0530, Laxman Dewangan wrote:
> Use devm_mfd_add_devices() for mfd devices registration and get
> rid of .remove callback to remove mfd devices. This is done
> by managed device framework.
>
> Signed-off-by: Laxman Dewangan
> CC: Andreas Werner
> ---
Thanks fo
Hi Christoph,
On Tue, Apr 5, 2016 at 5:42 AM, Christoph Hellwig wrote:
> On Tue, Apr 05, 2016 at 05:39:21AM -0700, Parav Pandit wrote:
>> I am not really trying to address OFED issues here. I am sure you
>> understand that if ib_core.ko kernel module is in-kernel module than,
>> for all the fixes
Hello Laxman,
On 04/05/2016 07:48 AM, Laxman Dewangan wrote:
> Use devm_mfd_add_devices() for mfd devices registration and get
> rid of .remove callback to remove mfd devices. This is done
> by managed device framework.
>
> Signed-off-by: Laxman Dewangan
> CC: Ingi Kim
> CC: Javier Martinez Can
Hello Laxman,
On 04/05/2016 07:48 AM, Laxman Dewangan wrote:
> Use devm_mfd_add_devices() for mfd devices registration and get
> rid of .remove callback to remove mfd devices. This is done
> by managed device framework.
>
> Signed-off-by: Laxman Dewangan
> CC: John Crispin
> CC: Javier Martinez
On Tue, Apr 05, 2016 at 05:39:21AM -0700, Parav Pandit wrote:
> I am not really trying to address OFED issues here. I am sure you
> understand that if ib_core.ko kernel module is in-kernel module than,
> for all the fixes/enhancements that goes to it would require people to
> upgrade to newer kerne
Hi Christoph,
On Tue, Apr 5, 2016 at 2:06 AM, Christoph Hellwig wrote:
> On Mon, Apr 04, 2016 at 09:25:04PM -0400, Tejun Heo wrote:
>> Is it actually customary to have rdma core module updated more
>> frequently separate from the kernel? Out-of-tree modules being
>> updated separately happens qu
This series add devm_ version of the APIs mfd_add_devices() and
mfd_release_devices() and get rid of call for mfd_release_devices()
some places and also remove the need of .remove callbacks as this
is not needed.
Laxman Dewangan (20):
mfd: Add devm_ apis for mfd_add_devices and mfd_release_devic
Add device managed APIs devm_mfd_add_devices() and
devm_mfd_remove_devices() for the APIs mfd_add_devices()
and mfd_remove_devices().
This helps in reducing code in error path and sometimes
removal of .remove callback for driver unbind.
Signed-off-by: Laxman Dewangan
---
drivers/mfd/mfd-core.c
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Matt Porter
---
drivers/mfd/bcm590xx.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Wenyou Yang
CC: Krzysztof Kozlowski
---
drivers/mfd/act8945a.c | 13 +++--
1 file changed, 3 inser
Add devm wrappers for the mfd_add_devices() and mfd_remove_devices()
in the list of managed interfaces.
Signed-off-by: Laxman Dewangan
---
Documentation/driver-model/devres.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-m
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Boris Brezillon
---
drivers/mfd/atmel-hlcdc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Guennadi Liakhovetski
---
drivers/mfd/as3711.c | 11 +--
1 file changed, 1 insertion(+), 10 deletio
Use devm_mfd_add_devices() for mfd devices registration and remove
the call of mfd_remove_devices() from .remove callback to remove
mfd devices. This is done by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Beniamino Galvani
---
drivers/mfd/rn5t618.c | 3 +--
1 file changed, 1 in
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Milo Kim
---
drivers/mfd/lp3943.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
di
Use devm_mfd_add_devices() for mfd devices registration and remove
the call of mfd_remove_devices() from .remove callback to remove
mfd devices. This is done by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Chris Zhong
---
drivers/mfd/rk808.c | 3 +--
1 file changed, 1 insertion(
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Andreas Werner
---
drivers/mfd/menf21bmc.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
d
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: John Crispin
CC: Javier Martinez Canillas
---
drivers/mfd/mt6397-core.c | 12 ++--
1 file changed,
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Ingi Kim
CC: Javier Martinez Canillas
---
drivers/mfd/rt5033.c | 10 +-
1 file changed, 1 insertio
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Guodong Xu
---
drivers/mfd/hi6421-pmic-core.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Gyungoh Yoo
---
drivers/mfd/sky81452.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
di
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Florian Fainelli
---
drivers/mfd/rdc321x-southbridge.c | 8 +---
1 file changed, 1 insertion(+), 7 dele
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Todd Fischer
---
drivers/mfd/tps6507x.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Linus Walleij
---
drivers/mfd/stw481x.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Mark Brown
CC: patc...@opensource.wolfsonmicro.com
---
drivers/mfd/wm8400-core.c | 25 +++--
Use devm_mfd_add_devices() for mfd devices registration and remove
the call of mfd_remove_devices() from .remove callback to remove
mfd devices. This is done by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Tony Lindgren
---
drivers/mfd/tps65910.c | 3 +--
1 file changed, 1 inser
Use devm_mfd_add_devices() for mfd devices registration and get
rid of .remove callback to remove mfd devices. This is done
by managed device framework.
Signed-off-by: Laxman Dewangan
CC: Tony Lindgren
---
drivers/mfd/tps65217.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
On Tue, Apr 05, 2016 at 12:56:26PM +0300, Jarkko Sakkinen wrote:
> On Thu, Mar 31, 2016 at 08:58:47AM -0400, Stefan Berger wrote:
> > On 03/31/2016 04:24 AM, Jarkko Sakkinen wrote:
> > >On Tue, Mar 29, 2016 at 02:19:13PM -0400, Stefan Berger wrote:
> > >>Add the retrieval of TPM 1.2 durations and t
On Thu, Mar 31, 2016 at 08:58:47AM -0400, Stefan Berger wrote:
> On 03/31/2016 04:24 AM, Jarkko Sakkinen wrote:
> >On Tue, Mar 29, 2016 at 02:19:13PM -0400, Stefan Berger wrote:
> >>Add the retrieval of TPM 1.2 durations and timeouts. Since this requires
> >>the startup of the TPM, do this for TPM
On Mon, Apr 04, 2016 at 09:25:04PM -0400, Tejun Heo wrote:
> Is it actually customary to have rdma core module updated more
> frequently separate from the kernel? Out-of-tree modules being
> updated separately happens quite a bit but this is an in-kernel
> module, which usually is tightly coupled
On 2016-04-03 13:09, Jonathan Cameron wrote:
> On 03/04/16 09:52, Peter Rosin wrote:
>> From: Peter Rosin
>>
>> Signed-off-by: Peter Rosin
> Very nice, one typo that I could see.
Thanks!
*snip*
>> + and the actual transfer (e.g. if the child mux is auto-closing
>> + and the parent mux
1 - 100 of 101 matches
Mail list logo
