As part of the gp_seq clean up, the Startleaf condition doesn't occur
anymore. Remove it from the comment in the trace event file.
Signed-off-by: Joel Fernandes (Google)
---
include/trace/events/rcu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/trace/events/rcu.h b/include/trace/e
On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google)
wrote:
>
> As part of the gp_seq clean up, the Startleaf condition doesn't occur
> anymore. Remove it from the comment in the trace event file.
Sorry, I meant here Startedleaf. Let me know if you want me to resend the patch.
thanks,
- Joe
Add support for configuring the machine constraints
valid_modes_mask element based on a list of allowed modes
specified via a device tree property.
Signed-off-by: David Collins
---
drivers/regulator/of_regulator.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-
There is currently no accepted way to configure constraints->valid_modes_mask
for regulators defined in device tree. This patch series defines a new
common regulator device tree property, regulator-allowed-modes, which can be
used to specify the set of modes that the regulator is allowed to use.
I
Add a common device tree property for regulator nodes to support
the specification of allowed operating modes.
Signed-off-by: David Collins
---
Documentation/devicetree/bindings/regulator/regulator.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/reg
On 05/11/2018 05:33 PM, Joel Fernandes (Google) wrote:
> rcu_seq_snap may be tricky for someone looking at it for the first time.
> Lets document how it works with an example to make it easier.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
> kernel/rcu/rcu.h | 23 ++-
> 1
rcu_seq_snap may be tricky for someone looking at it for the first time.
Lets document how it works with an example to make it easier.
Signed-off-by: Joel Fernandes (Google)
---
v2 changes: Corrections as suggested by Randy.
kernel/rcu/rcu.h | 24 +++-
1 file changed, 23 ins
Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs. These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine th
This patch series adds a driver and device tree binding documentation for
PMIC regulator control via Resource Power Manager-hardened (RPMh) on some
Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block
which contains several accelerators which are used to manage various
hardwar
Add the QCOM RPMh regulator driver to manage PMIC regulators
which are controlled via RPMh on some Qualcomm Technologies, Inc.
SoCs. RPMh is a hardware block which contains several
accelerators which are used to manage various hardware resources
that are shared between the processors of the SoC.
On Sat, May 12, 2018 at 12:57 AM, Bjorn Helgaas wrote:
> Andrew wrote:
>> A friend of mine has a brand new LG laptop that has intermittent NVMe
>> failures. They mostly happen during a suspend/resume cycle
>> (apparently during suspend, not resume). Unlike the earlier
>> Dell/Samsung issue, the
On 05/11/2018 07:20 PM, Joel Fernandes (Google) wrote:
> rcu_seq_snap may be tricky for someone looking at it for the first time.
> Lets document how it works with an example to make it easier.
>
> Signed-off-by: Joel Fernandes (Google)
> ---
> v2 changes: Corrections as suggested by Randy.
>
>
On Fri, May 11, 2018 at 06:29:57PM -0700, Joel Fernandes wrote:
> On Fri, May 11, 2018 at 6:29 PM, Joel Fernandes (Google)
> wrote:
> >
> > As part of the gp_seq clean up, the Startleaf condition doesn't occur
> > anymore. Remove it from the comment in the trace event file.
>
> Sorry, I meant her
Hi,
I bet this has come up before, but my search foo didn't find anything.
When (cross) building nios2 allmodconfig, I am seeing this build error:
ERROR: "empty_zero_page" [net/ceph/libceph.ko] undefined!
ERROR: "empty_zero_page" [fs/exofs/exofs.ko] undefined!
ERROR: "empty_zero_page" [fs/crypto
-- Forwarded message --
From: Kyungtae Kim
Date: Fri, May 11, 2018 at 11:38 AM
Subject: KASAN: use-after-free Write in write_mem
To: a...@arndb.de, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org
Cc: Byoungyoung Lee , DaeLyong Jeong
We report the crash:
"KASAN: use-afte
Hi Kalle,
On Fri, 11 May 2018 15:20:23 +0300 Kalle Valo wrote:
>
> Btw Stephen for mac80211 reports it would be a good idea to also cc
> linux-wireless list, in case Johannes is not around etc.
Thanks for the suggestion. Done.
--
Cheers,
Stephen Rothwell
pgpWmdiByugpz.pgp
Description: OpenP
Hi all,
Just cc'ing the wireless list at Kalle's suggestion.
On Wed, 9 May 2018 14:56:24 +1000 Stephen Rothwell
wrote:
>
> Hi Johannes,
>
> After merging the mac80211-next tree, today's linux-next build (arm_multi
> v7_defconfig) produced this warning:
>
> drivers/net/wireless/marvell/mwifiex
Hi David,
On Fri, 11 May 2018 10:47:01 +0200 David Sterba wrote:
>
> Please add
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git next-fixes
Added from Monday (as btrfs-fixes).
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not
Hi Al,
As requested I have added the vfs-fixes tree
(git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git#fixes) to
linux-next from Monday.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
linux-nex
On Sat, May 12, 2018 at 09:42:21AM +0900, Masami Hiramatsu wrote:
> Hi Greg,
>
> Could you pick this series to stable?
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Hi all,
As an outcome of some discussion, I have added a pending-fixes branch
to linux-next. This branch contains Linus' tree merged with branches
containing only fixes pending for the current release. The branch is a
strict subset of linux-next each day (as so rebases like linux-next
does).
It
Hi all,
On Wed, 9 May 2018 20:47:27 +1000 Stephen Rothwell
wrote:
>
> On Wed, 9 May 2018 18:03:46 +0900 Mark Brown wrote:
> >
> > On Wed, May 09, 2018 at 10:47:57AM +0200, Daniel Vetter wrote:
> > > On Wed, May 9, 2018 at 10:44 AM, Mark Brown wrote:
> > >
> >
> > > > I think this is
The series aims to switch vfs timestamps to use
struct timespec64. Currently vfs uses struct timespec,
which is not y2038 safe.
The series involves the following:
1. Add vfs helper functions for supporting struct timepec64 timestamps.
2. Cast prints of vfs timestamps to avoid warnings after the sw
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
This will lead to type mismatch for memcpys.
Use regular assignments instead.
Signed-off-by: Deepa Dinamani
Cc: trond.mykleb...@primarydata.com
---
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
Convert these print formats to use long long types to
avoid warnings and errors on conversion.
Signed-off-by: Deepa Dinamani
Cc: z...@redhat.com
Cc:
As vfs moves to using struct timespec64 to represent times,
update the argument to timespec_truncate() to use
struct timespec64. Also change the name of the function.
The rest of the implementation logic is the same.
Move this to fs/inode.c instead of kernel/time/time.c as all the
users of this ap
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
Convert these print formats to use long long types to
avoid warnings and errors on conversion.
Signed-off-by: Deepa Dinamani
CC: andreas.dil...@inte
Subsequent patches in the series convert inode timestamps
to use struct timespec64 instead of struct timespec as
part of solving the y2038 problem.
commit fd3cfad374d4 ("udf: Convert udf_disk_stamp_to_time() to use mktime64()")
eliminated the NULL return condition from udf_disk_stamp_to_time().
ud
struct timespec is not y2038 safe. Transition vfs to use
y2038 safe struct timespec64 instead.
The change was made with the help of the following cocinelle
script. This catches about 80% of the changes.
All the header file and logic changes are included in the
first 5 rules. The rest are trivial s
On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote:
> On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote:
> > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote:
> > > Hello folks,
> > >
> > > I think I wrote the title in a misleading way.
> > >
> > > Please
On Fri, 2018-05-11 at 17:03 +0200, Matthias Brugger wrote:
>
> On 04/11/2018 10:53 AM, sean.w...@mediatek.com wrote:
> > From: Sean Wang
> >
> > Below two wrong nodes in existing DTS files would cause a fail boot since
> > in fact the address 0 is not the correct place the memory device locates
Hi Paul,
On Fri, 11 May 2018 23:29:12 +0200
Paul Cercueil wrote:
> By specifying the properties "mtd-oob-ecc" and "mtd-oob-free", it is
> now possible to specify from devicetree where the ECC data is located
> inside the OOB region.
Why would we want to do that? I mean, ECC/free regions are ECC
On Sun, Apr 22, 2018 at 08:03:39PM -0700, Paul E. McKenney wrote:
> The rcu_start_this_gp() function had a simple form of funnel locking that
> used only the leaves and root of the rcu_node tree, which is fine for
> systems with only a few hundred CPUs, but sub-optimal for systems having
> thousand
Use new return type vm_fault_t for fault handler
in struct vm_operations_struct. For now, this is
just documenting that the function returns a
VM_FAULT value rather than an errno. Once all
instances are converted, vm_fault_t will become
a distinct type.
commit 1c8f422059ae ("mm: change return typ
On Sat, 2018-05-12 at 11:47 +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler
> in struct vm_operations_struct. For now, this is
> just documenting that the function returns a
> VM_FAULT value rather than an errno. Once all
> instances are converted, vm_fault_t will
On Sat, May 12, 2018 at 11:50 AM, Joe Perches wrote:
> On Sat, 2018-05-12 at 11:47 +0530, Souptick Joarder wrote:
>> Use new return type vm_fault_t for fault handler
>> in struct vm_operations_struct. For now, this is
>> just documenting that the function returns a
>> VM_FAULT value rather than an
On Sat, May 12, 2018 at 11:55 AM, Souptick Joarder wrote:
> On Sat, May 12, 2018 at 11:50 AM, Joe Perches wrote:
>> On Sat, 2018-05-12 at 11:47 +0530, Souptick Joarder wrote:
>>> Use new return type vm_fault_t for fault handler
>>> in struct vm_operations_struct. For now, this is
>>> just documen
On Fri, May 11, 2018 at 10:08:24PM -0700, Paul E. McKenney wrote:
> On Fri, May 11, 2018 at 03:41:38PM -0700, Joel Fernandes wrote:
> > On Fri, May 11, 2018 at 09:17:46AM -0700, Paul E. McKenney wrote:
> > > On Fri, May 11, 2018 at 09:57:54PM +0900, Byungchul Park wrote:
> > > > Hello folks,
> > >
According to error handling path before and after this one, we should go
to 'out_md_fid' here, instead of 'out_md', if 'obd_connect()' fails.
Signed-off-by: Christophe JAILLET
---
The last goto 'out_lock_cn_cb' looks spurious but is correct.
In case of error, 'd_make_root()' performs a 'iput()',
Use new return type vm_fault_t for fault handler
in struct vm_operations_struct. For now, this is
just documenting that the function returns a
VM_FAULT value rather than an errno. Once all
instances are converted, vm_fault_t will become
a distinct type.
commit 1c8f422059ae ("mm: change return typ
Commit-ID: 789ba28013ce23dbf5e9f5f014f4233b35523bf3
Gitweb: https://git.kernel.org/tip/789ba28013ce23dbf5e9f5f014f4233b35523bf3
Author: Mel Gorman
AuthorDate: Wed, 9 May 2018 17:31:15 +0100
Committer: Ingo Molnar
CommitDate: Sat, 12 May 2018 08:37:56 +0200
Revert "sched/numa: Delay ret
On Fri, May 11, 2018 at 9:59 PM, Deepa Dinamani wrote:
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index 5fcb845b9fec..fb681d302bb3 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -392,7 +392,7 @@ int pstore_mkfile(struct dentry *root, struct
> pstore_record *record)
>
This prepares pstore for converting the VFS layer to timespec64.
Cc: Deepa Dinamani
Signed-off-by: Kees Cook
---
fs/pstore/inode.c | 3 ++-
fs/pstore/platform.c | 2 +-
include/linux/pstore.h | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/pstore/inode.c b/fs/ps
On 05/10/2018, 02:49 PM, Josh Poimboeuf wrote:
> On Thu, May 10, 2018 at 02:33:03PM +0200, Jiri Slaby wrote:
>> On 04/19/2018, 03:42 PM, Josh Poimboeuf wrote:
>>> On Mon, Apr 16, 2018 at 05:16:53PM -0500, Josh Poimboeuf wrote:
On Wed, Dec 20, 2017 at 08:07:17PM +0100, Jiri Slaby wrote:
> O
> Am 10.05.2018 um 18:42 schrieb Mauro Carvalho Chehab
> :
>
> Em Thu, 10 May 2018 09:38:46 -0600
> Jonathan Corbet escreveu:
>
>> On Thu, 10 May 2018 11:21:13 -0300
>> Mauro Carvalho Chehab wrote:
>>
>>> The problem with a hint-based mechanism is that it will generate
>>> false hints. If ad
On Fri, May 11, 2018 at 9:59 AM, Abdul Haleem
wrote:
> Greeting's
>
> Today's next kernel on powerpc machine has boot warnings with commit
>
> a794d8d : crypto: ccree - enable support for hardware keys
Adding the crypto list and maintainer as it came in via the crypto tree.
>
> Warning disappear
On Thu, 2018-05-10 at 12:28 +0200, Mike Galbraith wrote:
> On Thu, 2018-05-10 at 11:10 +0200, Mike Galbraith wrote:
> > Greetings,
> >
> > When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The
> > below is from master.today.
> >
> > [12594.640959] nouveau :01:00.0: swiotlb buffe
On May 11, 2018 1:03:04 AM GMT+03:00, Randy Dunlap
wrote:
>On 05/10/2018 01:48 PM, Andrew Morton wrote:
>> On Thu, 10 May 2018 09:37:51 -0700 Randy Dunlap
> wrote:
>>
>>> On 05/10/2018 12:28 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20180509:
>>>
>>> on i386:
>>>
>>
Hi,
Currently, there is no read barrier between reading the index
(kfifo.in) and fetching the real data from the fifo.
I am afraid that will cause the vfifo is observed as not empty
however the data is not actually ready for read. Right?
Thanks!
Hi Lee,
On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote:
> A number of drivers have been using the wrong OF helper when doing child-node
> lookups during probe. This meant that they were doing tree-wide searches
> rather
> than matching on child nodes and that the parent node could e
On 09/05/18 17:11, Roger Pau Monné wrote:
> On Wed, May 09, 2018 at 12:30:16PM +0100, Roger Pau Monné wrote:
>> On Wed, May 09, 2018 at 11:56:40AM +0100, Andrew Cooper wrote:
>>> On 09/05/18 11:21, Roger Pau Monne wrote:
>>> I'm not sure that setting the default MTRR type is going to be a
>>> cleve
On 09/05/18 12:21, Roger Pau Monne wrote:
> There's no need to store the xenstore page or event channel in
> xen_start_info if they are locally initialized.
>
> This also fixes PVH local xenstore initialization due to the lack of
> xen_start_info in that case.
>
> Signed-off-by: Boris Ostrovsky
On 2018-05-10 10:10, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
>> If the bridge supplier is unbound, this will bring the bridge consumer
>> down along with the bridge. Thus, there will no longer linger any
>> dangling pointers from the bridge consumer (the drm_device) to some
>
On 05/08/2018 04:47 PM, Marc Zyngier wrote:
On 26/04/18 17:18, Ludovic Barre wrote:
From: radek
- In stm32_exti_alloc function, discards irq_domain_set_info
with handle_simple_irq. This overwrite the setting defined while init
of generic chips. Exti controller manages edge irq type.
-
On 2018/5/11 13:20, DaeRyong Jeong wrote:
We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr
Note that this bug is previously reported by syzkaller.
https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91
Nonetheless, this bug has not fixed yet, and we hope
On Sat, May 5, 2018 at 2:10 PM, kbuild test robot wrote:
>drivers/android/binder.o: In function `binder_thread_write':
>>> binder.c:(.text+0x6a16): undefined reference to `__get_user_bad'
Looks like m68k doesn't support 64-bit get_user(). I could just have
binder depend on !CONFIG_M68K, but t
On Tue, May 08, 2018 at 07:26:06PM +0300, Dmitry Osipenko wrote:
> CDEV1 and CDEV2 clocks are a bit special case, their parent clock is
> created by the pinctrl driver. It should be possible for clk user to
> request these clocks before pinctrl driver got probed and hence user will
> get an orphane
Hello Linus,
Here is the MTD fixes PR for 4.17-rc5.
Regards,
Boris
The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
are available in the git repository at:
git://git.infradead.org/linux-mtd.git tags/mtd/fixes-for-4.1
Hi all,
this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.
The dma-noncoherent
Switch to the generic noncoherent direct mapping implementation for
the nommu dma map implementation.
Signed-off-by: Christoph Hellwig
---
arch/arc/Kconfig| 1 +
arch/arm/Kconfig| 4 +
arch/arm/mm/dma-mapping-nommu.c | 139 +---
3 f
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/arc/Kconfig | 4 +
arch/arc/include/asm/Kbuild| 1 +
arch/arc/include/asm/dma-mapping.h | 21 -
arch/arc/mm/dma.c | 141 +++--
Add a new dma_map_ops implementation that uses dma-direct for the
address mapping of streaming mappings, and which requires arch-specific
implemenations of coherent allocate/free.
Architectures have to provide flushing helpers to ownership trasnfers
to the device and/or CPU, and can provide option
ARCH_DMA_ADDR_T_64BIT is always true for 64-bit architectures now, so we
can skip the clause requiring it. 'n' is the default default, so no need
to explicitly state it.
Signed-off-by: Christoph Hellwig
---
lib/Kconfig | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/li
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/c6x/Kconfig | 3 +
arch/c6x/include/asm/Kbuild| 1 +
arch/c6x/include/asm/dma-mapping.h | 28 --
arch/c6x/include/asm/setup.h | 2 +
arch/c6x/kern
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/nios2/Kconfig | 3 +
arch/nios2/include/asm/Kbuild| 1 +
arch/nios2/include/asm/dma-mapping.h | 20
arch/nios2/mm/dma-mapping.c | 139 +++---
Switch to the generic noncoherent direct mapping implementation.
This makes sure the cache_sync routines is called in the unmap_sg
case, to match the unmap_single and sync_{single,sg}_to_cpu cases.
Note that this now always uses page_address, as previously done
in the non-sg cache sync routines.
Switch to the generic noncoherent direct mapping implementation.
This removes the previous sync_single_for_cpu implementation, which looks
bogus given that no syncing is happening in the similar but more
important unmap_single case.
This adds the previously missing sync_sg_for_device implementati
Both unused.
Signed-off-by: Christoph Hellwig
---
arch/microblaze/include/asm/pgtable.h | 3 --
arch/microblaze/mm/consistent.c | 45 ---
2 files changed, 48 deletions(-)
diff --git a/arch/microblaze/include/asm/pgtable.h
b/arch/microblaze/include/asm/pgtable.h
i
And use it in the maple bus code to avoid a dma API dependency.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/cacheflush.h | 7 +++
arch/sh/mm/consistent.c | 5 +
drivers/sh/maple/maple.c | 7 ---
3 files changed, 12 insertions(+), 7 deletions(-)
diff --g
This is a slight change in behavior as we avoid the detour through the
virtual mapping for the coherent allocator, but if this CPU really is
coherent that should be the right thing to do.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 1 +
arch/sh/include/asm/dma-mappin
Remove the indirection through the dma_ops variable, and just return
nommu_dma_ops directly from get_arch_dma_ops.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/dma-mapping.h | 5 ++---
arch/sh/kernel/dma-nommu.c| 8 +---
arch/sh/mm/consistent.c | 3 ---
arch/
Half of the file just contains platform device memory setup code which
is required for all builds, and half contains helpers for dma coherent
allocation, which is only needed if CONFIG_DMA_NONCOHERENT is enabled.
Signed-off-by: Christoph Hellwig
---
arch/sh/kernel/Makefile | 2 +-
arch/sh
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/xtensa/Kconfig | 3 +
arch/xtensa/include/asm/Kbuild| 1 +
arch/xtensa/include/asm/dma-mapping.h | 26 --
arch/xtensa/kernel/pci-dma.c | 130 +++-
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 3 +-
arch/sh/include/asm/Kbuild| 1 +
arch/sh/include/asm/dma-mapping.h | 26 ---
arch/sh/kernel/Makefile | 2 +-
arch/sh/kernel
Switch to the generic noncoherent direct mapping implementation.
Parisc previously had two different non-coherent dma ops implementation
that just different in the way coherent allocations were handled or not
handled. The different behavior is not selected at runtime in the
arch_dma_alloc and arc
Due to a snafu "paes" testmgr tests were not ordered
lexicographically, which led to boot time warnings.
Reorder the tests as needed.
Fixes: a794d8d ("crypto: ccree - enable support for hardware keys")
Reported-by: Abdul Haleem
Signed-off-by: Gilad Ben-Yossef
---
crypto/testmgr.c | 44 +
Switch to the generic noncoherent direct mapping implementation.
This removes the previous sync_single_for_device implementation, which
looks bogus given that no syncing is happening in the similar but more
important map_single case.
Signed-off-by: Christoph Hellwig
---
arch/sparc/Kconfig
Switch to the generic noncoherent direct mapping implementation.
Fix sync_single_for_device to do the same cache coherency operations as
the more tested map_single path, as both should transfer ownership to
the device.
Remove the sync_single_for_cpu implementation as no cache coherency
operations
On Mon, May 07, 2018 at 08:29:42PM +0800, Icenowy Zheng wrote:
> From: Ondrej Jirman
>
> Add SY8106A regulator to r_i2c bus and enable the r_i2c bus on
> Orange Pi PC, then set the power supply of the ARM cores to this
> regulator, in order to enable DVFS.
>
> Signed-off-by: Ondrej Jirman
> [Ic
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/m68k/Kconfig | 2 +
arch/m68k/include/asm/Kbuild| 1 +
arch/m68k/include/asm/dma-mapping.h | 12 -
arch/m68k/kernel/dma.c | 68 -
My guts thinks you are right. Feel free to send a patch...
Am Freitag, den 11.05.2018, 15:25 +0800 schrieb Xiao Guangrong:
> Hi,
>
> Currently, there is no read barrier between reading the index
> (kfifo.in) and fetching the real data from the fifo.
>
> I am afraid that will cause the vfifo is o
Switch to the generic noncoherent direct mapping implementation.
This removes the direction-based optimizations in
sync_{single,sg}_for_{cpu,device} which were marked untestested and
do not match the usually very well tested {un,}map_{single,sg}
implementations.
Signed-off-by: Christoph Hellwig
On Thu, May 10, 2018 at 09:48:31AM -0700, Tony Lindgren wrote:
> * Johan Hovold [180509 09:46]:
> > Add support for controller runtime power management to serdev core. This
> > is needed to allow slave drivers to manage the runtime PM state of the
> > underlying serial controller when its driver,
On Fri, May 11, 2018 at 09:57:52AM +0200, Martijn Coenen wrote:
> On Sat, May 5, 2018 at 2:10 PM, kbuild test robot wrote:
> >drivers/android/binder.o: In function `binder_thread_write':
> >>> binder.c:(.text+0x6a16): undefined reference to `__get_user_bad'
>
> Looks like m68k doesn't support
The assign_vector_locked() calls allocate_vector to get a real vector for
an IRQ. If the current target CPU is online and in the new requested
affinity mask, allocate_vector() will return 0 and nothing should be done.
But, the assign_vector_locked() always call the apic_update_irq_cfg(). it's
poin
Use dedicated Odroid audio subsystem DT bindings instead of the simple-card.
This adds support for audio on the HDMI interface.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 ++---
arch/arm/boot/dts/exynos4412-odroidu3.dts |
On 09/05/18 22:52, Suzuki K Poulose wrote:
On 05/04/2018 11:06 AM, Julien Thierry wrote:
Hi,
In order to prepare the v3 of this patchset, I'd like people's opinion
on what this patch does. More below.
On 17/01/18 11:54, Julien Thierry wrote:
From: Daniel Thompson
Currently alternatives
On Fri, 11 May 2018, Johan Hovold wrote:
> Hi Lee,
>
> On Mon, Nov 20, 2017 at 11:45:43AM +0100, Johan Hovold wrote:
> > A number of drivers have been using the wrong OF helper when doing
> > child-node
> > lookups during probe. This meant that they were doing tree-wide searches
> > rather
> >
Tue, May 08, 2018 at 05:33:01PM CEST, starni...@g.ncu.edu.tw wrote:
>A Low-Power Wide-Area Network (LPWAN) is a type of wireless
>telecommunication wide area network designed to allow long range
>communications at a low bit rate among things (connected objects), such
>as sensors operated on a batte
On Fri, May 11, 2018 at 10:08 AM, Greg KH wrote:
> I think using !CONFIG_M68K is a good start. We can blacklist any other
> arch that doesn't support this, and that list should be small as I doubt
> any new ones will be added without this support.
Thanks, I will send a v2.
>
> thanks,
>
> greg
From: Changbin Du
Hi all,
I know some kernel developers was searching for a method to dissable GCC
optimizations, probably they want to apply GCC '-O0' option. But since Linux
kernel replys on GCC optimization to remove some dead code, so '-O0' just
breaks the build. They do need this because the
From: Changbin Du
This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
this option will prevent the compiler from optimizing the kernel by
auto-inlining functions not marked with the inline keyword.
With this option, only functions explicitly marked with "inline" will
be inlined.
From: Changbin Du
This will apply GCC '-Og' optimization level which is supported
since GCC 4.8. This optimization level offers a reasonable level
of optimization while maintaining fast compilation and a good
debugging experience. It is similar to '-O1' while perferring
to keep debug ability over
Some data structure members were either misspelled or missing.
Fixes: aeb068c572 ("i2c: i2c-stm32f7: add driver")
Fixes: 380b8a85e7 ("i2c: i2c-stm32f7: Add initial SMBus protocols support")
Signed-off-by: Pierre-Yves MORDRET
---
Version history:
v1:
* Initial
---
---
drivers/i2c/bus
From: Changbin Du
With '-Og' optimization level, GCC would not optimize a count for a loop
as a constant value. But BUILD_BUG_ON() only accept compile-time constant
values. Let's use __fix_to_virt() to avoid the error.
arch/arm/mm/mmu.o: In function `fix_to_virt':
/home/changbin/work/linux/./inc
From: Changbin Du
The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.
Signed-off-by: Changbin Du
Acked-by: Steven Rostedt (VMware)
---
arch/x86/include/asm/pgtable_64.h | 2 ++
arch/x86/k
Add I2C/SMBUS Driver entry for STM32 family from ST Microelectronics.
Signed-off-by: Pierre-Yves MORDRET
---
Version history:
v1:
* Initial
---
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 79bb02f..a0e597d 100644
--- a/MAI
On Thu, May 10, 2018 at 09:27:50PM -0500, Samuel Holland wrote:
> The Allwinner A64 SoC is known [1] to have an unstable architectural
> timer, which manifests itself most obviously in the time jumping forward
> a multiple of 95 years [2][3]. This coincides with 2^56 cycles at a
> timer frequency o
Hi Bjorn,
>
> [+cc Tejun, Wolfram]
>
> On Wed, May 09, 2018 at 04:20:11PM +0800, Yao Chen wrote:
> > Add support for MSI.
> > ...
>
> > @@ -448,6 +467,26 @@ static int kirin_pcie_host_init(struct pcie_port
> > *pp) static int __init kirin_add_pcie_port(struct dw_pcie *pci,
> >
The DesignWare GPIO IP can be configured for either 1 interrupt or 1
per GPIO in port A, but the driver currently only supports 1 interrupt.
See the DesignWare DW_apb_gpio Databook description of the
'GPIO_INTR_IO' parameter.
This change allows the driver to work with up to 32 interrupts, it will
501 - 600 of 683 matches
Mail list logo
