The vhost_set_vring_num_addr() could be called in the middle of
invalidate_range_start() and invalidate_range_end(). If we don't reset
invalidate_count after the un-registering of MMU notifier, the
invalidate_cont will run out of sync (e.g never reach zero). This will
in fact disable the fast acces
We don't free map during vhost_map_unprefetch(). This means it could
be leaked. Fixing by free the map.
Reported-by: Michael S. Tsirkin
Fixes: 7f466032dc9e ("vhost: access vq metadata through kernel virtual address")
Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 4 +---
1 file changed,
There's no need for RCU synchronization in vhost_uninit_vq_maps()
since we've already serialized with readers (memory accessors). This
also avoid the possible userspace DOS through ioctl() because of the
possible high latency caused by synchronize_rcu().
Reported-by: Michael S. Tsirkin
Fixes: 7f4
On Fri, 09 Aug 2019 04:54:58 +0200,
Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the sound tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> sound/hda/hdac_bus.c: In function 'snd_hdac_aligned_read':
> sound/hda/hdac_bus.c:228:6: error: implicit declaration
Dear Friend,
I came across your e-mail contact prior a private search whilst in
need of your partnership for investment assistance in your country. I
am opportune to use this medium to exhibit my legal intentions towards
investing to your country under your management. I am fully convinced
that yo
On 2019/8/9 5:00, Jeremy Linton wrote:
> Hi,
>
> First thanks for posting this!
>
> I ran this on our DAWN platform and it does what it says. Its a pretty
> reasonable start, but I get -1's in the command row rather than "dd" (or
> similar) and this also results in [unknown] for the shared obje
On Thu, Aug 08, 2019 at 12:07:28PM -0700, Linus Torvalds wrote:
> End result: a DRAM buffer can work, but is not "reliable".
> Particularly if you turn power on and off, data retention of DRAM is
> iffy. But it's possible, at least in theory.
>
> So I have a patch that implements a "stupid ring b
On 2019/8/9 12:00, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/lightnvm/pblk-read.c: In function 'pblk_submit_read_gc':
> drivers/lightnvm/pblk-read.c:421:18: warning: unused variable 'geo'
On Tue, Jul 30, 2019 at 11:15:03AM -0700, Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> expression
Hi Shawn/Leo,
Removing the "big-endian" property has caused problems in our UEFI firmware.
In UEFI, we use the device tree to detect and use the qspi controller and
flashes attached to it.
We don't maintain a list of platforms like linux driver.
Can you please revert the endianness change from l
On Thu, Aug 08, 2019 at 03:57:30PM +0300, Adrian Hunter wrote:
> On 8/08/19 3:42 PM, Ludovic Desroches wrote:
> > On Thu, Aug 08, 2019 at 10:35:43AM +0200, Eugen Hristev - M18282 wrote:
> >> From: Eugen Hristev
> >>
> >> Add mmc capabilities for SDMMC0 for this board.
> >> With this enabled, eMMC
Hello everyone,
Friendly reminder that the TAB elections are coming soon:
The Linux Foundation Technical Advisory Board (TAB) serves as the
interface between the kernel development community and the Linux
Foundation. The TAB advises the Foundation on kernel-related matters,
helps member companies
On 2019.08.08 19:16 Viresh Kumar wrote:
> On 08-08-19, 09:25, Doug Smythies wrote:
>> On 2019.08.07 00:06 Viresh Kumar wrote:
>> Tested by: Doug Smythies
>> Thermald seems to now be working O.K. for all the governors.
>
> Thanks for testing Doug.
>
>> I do note that if one sets
>> /sys/devices/sy
[Again, please do not top post - it makes a mess of any longer
discussion]
On Thu 08-08-19 15:15:12, Edward Chron wrote:
> In our experience far more (99.9%+) OOM events are not kernel issues,
> they're user task memory issues.
> Properly maintained Linux kernel only rarely have issues.
> So usefu
On Thu 08-08-19 16:39:28, Andrew Morton wrote:
> On Thu, 8 Aug 2019 20:53:13 +0200 Michal Hocko wrote:
>
> > > https://lkml.org/lkml/2019/6/1/165
> > >
> > > Ironic to find that commit message in a stable backport.
> > >
> > > I'm happy to drop the Fixes tag.
> >
> > No, please do not drop the
The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset")
deferred detaching of unused buffer to virtio device unplug time.
This causes unplug/replug of single port in virtio device with an
error "Error allocating inbufs\n". As we don't free the unused buffers
attached with the port. Re-
This patch series fixes the issue with unplug/replug of a port in virtio
console driver which fails with an error "Error allocating inbufs\n".
Patch 1 makes use of 'virtqueue_detach_unused_buf' function to detach
the unused buffers during port hotunplug time.
Patch 2 updates the next avail index fo
This patch decrements 'next_avail_idx' count when detaching a buffer
from vq for packed ring code. Split ring code already does this in
virtqueue_detach_unused_buf_split function. This updates the
'next_avail_idx' to the previous correct index after an unused buffer
is detatched from the vq.
Signe
On 08-08-19, 23:35, Doug Smythies wrote:
> O.K. While I understand the explanations, I still struggle with
> this scenario:
>
> doug@s15:~/temp$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
> 50<<< Note: 50% = 1.9 GHz in my system)
> doug@s15:~/temp$ grep .
> /sys/devices/system/cpu
On 30/07/2019 20:15, Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> expression ret;
> struct platfo
Hi,
On 26/07/19 16:54, Peter Zijlstra wrote:
[...]
> +void dl_server_init(struct sched_dl_entity *dl_se, struct rq *rq,
> + dl_server_has_tasks_f has_tasks,
> + dl_server_pick_f pick)
> +{
> + dl_se->dl_server = 1;
> + dl_se->rq = rq;
> + dl_se->server
On Mon, 5 Aug 2019, Christoph Hellwig wrote:
> On Fri, Aug 02, 2019 at 11:07:53AM +0200, Thomas Gleixner wrote:
> > Last time I did, there was resistance :)
>
> Do you have a pointer? Note that in the buffer head case maybe
> a hash lock based on the page address is even better, as we only
> ever
On Wed, 7 Aug 2019, Jon Derrick wrote:
Cc+: Ming, Christoph.
Left context for reference.
> The current irq spreading algorithm spreads vectors amongst cpus evenly
> per node. If a node has more cpus than another node, the extra vectors
> being spread may not be reported back to the caller.
>
>
In function of_get_child_regulator(), the loop for_each_child_of_node()
contains two mid-loop return statements. Ordinarily the loop gets the
node child at the beginning of every iteration and automatically puts
child after the main body has been executed. However in the case of a
mid-loop return c
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.
Entropy is derived from the banner and timer, which will change every
build and boot. This not so much saf
Larry Finger writes:
> On 8/7/19 8:51 PM, Valdis Klētnieks wrote:
>> Fix spurious warning message when building with W=1:
>>
>>CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o
>> drivers/net/wireless/realtek/rtlwifi/usb.c:243: warning: Cannot understand
>> * on line 243 - I thought it was
On 8/08/19 12:09 AM, Shirley Her (SC) wrote:
> Fix data read/write error in HS200 mode due to chip DLL lock phase shift
Please change the patch subject and commit message to match what the patch
actually does.
>
> Signed-off-by:Shirley Her
> ---
> change in V5:
> 1. split 2 patches into 3 patc
On 8/08/19 12:09 AM, Shirley Her (SC) wrote:
> Fix data read/write error in HS200 mode due to chip DLL lock phase shift
Please change the patch subject and commit message to match what the patch
actually does.
>
> Signed-off-by:Shirley Her
> ---
> change in V5:
> 1. split 2 patches into 3 patc
Each iteration of for_each_available_child_of_node() puts the previous
node, but in the case of a return from the middle of the loop, there is
no put, thus causing a memory leak. Hence create a new label,
err_node_put, that puts the previous node (child) before returning the
required value. Also in
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
arch/powerpc/mm/book3s64/mmu_context.
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
arch/s390/include/asm/gmap.h | 4 +++
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
arch/s390/mm/extmem.c | 11 ++
On 08.08.19 09:18, Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
> So convert atomic_t ref counters to refcount_t.
>
> Signed-off-by: Chu
Hi Nikolaus,
please try the patch below:
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 561c4812545b..2c8abf07e617 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -232,6 +232,8 @@ void omap_fbdev_init
On Thu, Aug 08, 2019 at 09:02:47AM +0200, Thomas Gleixner wrote:
> > > mm/slub.c: bit_spin_lock(PG_locked, &page->flags);
> >
> > One caller ouf of a gazillion that spins on the page lock instead of
> > sleepign on it like everyone else. That should not have passed your
> > smell test to s
Each iteration of for_each_available_child_of_node() puts the previous
node, but in the case of a return from the middle of the loop, there is
no put, thus causing a memory leak. Hence create a new label,
err_node_put, that puts the previous node (child) before returning the
required value. Also in
On Wed, Aug 07, 2019 at 07:43:01AM -0500, Bjorn Helgaas wrote:
> On Wed, Aug 07, 2019 at 07:59:58AM +0200, Christoph Hellwig wrote:
> > no-mmu sounds stange, as we use that for linux ports without paging
> > hardware. I think an "io" got lost somewhere..
>
> I had already changed the subject to
>
On Wed, Aug 07, 2019 at 09:58:06AM -0600, Logan Gunthorpe wrote:
> We only calculate it at the same time as we calculate the distance. This
> is necessary because, to calculate the type, we have to walk the tree
> and check the ACS bits. If we separated it, we'd have to walk the tree
> twice in a v
On Sat, 06 Jul 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Linus Walleij
> Cc: Lee Jones
> Cc: linux-arm-ker...
On Sat, 06 Jul 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Lee Jones
> Signed-off-by: Greg Kroah-Hartman
> ---
On Sat, 06 Jul 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Linus Walleij
> Cc: Lee Jones
> Cc: linux-arm-ker...
Each iteration of for_each_available_child_of_node() puts the previous
node, but in the case of a goto from the middle of the loop, there is no
put, thus causing a memory leak. Hence add an of_node_put() before each
mid-loop goto.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
Ch
On 8/08/19 12:10 AM, Shirley Her (SC) wrote:
> Fix data read/write error in HS200 mode due to chip DLL lock phase shift
>
> Signed-off-by:Shirley Her
> ---
> change in V5:
> 1. split 2 patches into 3 patches
> 2. make dll_adjust_count start from 0
> 3. fix ret overwritten issue
> 4. use break
In function sysc_check_children, there is an if-statement checking
whether the value returned by function sysc_check_one_child is non-zero.
However, sysc_check_one_child always returns 0, and hence this check is
not needed. Hence remove this if-block.
Signed-off-by: Nishka Dasgupta
---
drivers/b
śr., 7 sie 2019 o 21:28 Sekhar Nori napisał(a):
>
> On 05/08/19 1:59 PM, Bartosz Golaszewski wrote:
> > pon., 22 lip 2019 o 15:17 Bartosz Golaszewski napisał(a):
> >>
> >> From: Bartosz Golaszewski
> >>
> >> Sekhar,
> >>
> >> the following patches switch DaVinci to using the new clocksource driv
On Tue, Aug 06, 2019 at 11:00:19AM +0200, Arnd Bergmann wrote:
> > I was playing with sed yesterday, but the resulted code might be unreadable.
> >
> > Sed scripts tend to be somewhat unreadable.
> > I just wondered which language is appropriate for this?
> > Maybe perl, or what else? I am not good
On Wed 07-08-19 17:05:33, Mike Kravetz wrote:
> Li Wang discovered that LTP/move_page12 V2 sometimes triggers SIGBUS
> in the kernel-v5.2.3 testing. This is caused by a race between hugetlb
> page migration and page fault.
>
> If a hugetlb page can not be allocated to satisfy a page fault, the ta
On Tue, Jul 30, 2019 at 8:23 PM Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> expression ret;
> st
On Thu 08-08-19 09:46:07, Michal Hocko wrote:
> On Wed 07-08-19 17:05:33, Mike Kravetz wrote:
> > Li Wang discovered that LTP/move_page12 V2 sometimes triggers SIGBUS
> > in the kernel-v5.2.3 testing. This is caused by a race between hugetlb
> > page migration and page fault.
> >
> > If a hugetlb
On Wed, Aug 07, 2019 at 08:40:58AM -0700, Paul Walmsley wrote:
> On Wed, 7 Aug 2019, Christoph Hellwig wrote:
>
> > On Wed, Aug 07, 2019 at 05:22:15PM +0200, Greg KH wrote:
> > > > Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 cache controller
> > > > driver for SiFive SoCs")
> > > > Sign
On Thu, 8 Aug 2019 15:18:26 +0800
Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
> So convert atomic_t ref counters to refcount_t.
>
>
The ia64 implementation pte_alloc_one(), pte_alloc_one_kernel(),
pte_free_kernel() and pte_free() is identical to the generic except of lack
of __GFP_ACCOUNT for the user PTEs allocation.
Switch ia64 to use generic version of these functions.
Signed-off-by: Mike Rapoport
---
arch/ia64/include/a
On 8/8/19 8:52 AM, Juri Lelli wrote:
> Hi Dietmar,
>
> On 07/08/19 18:31, Dietmar Eggemann wrote:
>> On 7/26/19 4:54 PM, Peter Zijlstra wrote:
>>>
>>>
>>> Signed-off-by: Peter Zijlstra (Intel)
>>
>> [...]
>>
>>> @@ -889,6 +891,8 @@ static void update_curr(struct cfs_rq *c
>>> trace_sc
The sh implementation pte_alloc_one(), pte_alloc_one_kernel(),
pte_free_kernel() and pte_free() is identical to the generic except of lack
of __GFP_ACCOUNT for the user PTEs allocation.
Switch sh to use generic version of these functions.
Signed-off-by: Mike Rapoport
---
arch/sh/include/asm/pga
Hi,
I while ago Nicholas proposed to remove quicklist page table caches [1].
I've rebased his patch on the curren upstream and switched ia64 and sh to
use generic versions of PTE allocation.
[1] https://lore.kernel.org/linux-mm/20190711030339.20892-1-npig...@gmail.com
Mike Rapoport (2):
ia64:
From: Nicholas Piggin
Remove page table allocator "quicklists". These have been around for a
long time, but have not got much traction in the last decade and are
only used on ia64 and sh architectures.
The numbers in the initial commit look interesting but probably don't
apply anymore. If anybod
On Thu, 8 Aug 2019, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 09:02:47AM +0200, Thomas Gleixner wrote:
> > > > mm/slub.c: bit_spin_lock(PG_locked, &page->flags);
> > >
> > > One caller ouf of a gazillion that spins on the page lock instead of
> > > sleepign on it like everyone else
Hi Stephen,
On Tue, Jul 30, 2019 at 8:21 PM Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> express
On Wed, Aug 07, 2019 at 06:31:59PM +0200, Dietmar Eggemann wrote:
> On 7/26/19 4:54 PM, Peter Zijlstra wrote:
> >
> >
> > Signed-off-by: Peter Zijlstra (Intel)
>
> [...]
>
> > @@ -889,6 +891,8 @@ static void update_curr(struct cfs_rq *c
> > trace_sched_stat_runtime(curtask, delta_e
Hi Stephen,
On Tue, Jul 30, 2019 at 10:58 PM Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> expres
The following two reasons cause FP registers are sometimes not
initialized before starting the user program.
1. Currently, the FP context is initialized in flush_thread() function
and we expect these initial values to be restored to FP register when
doing FP context switch. However, the FP co
Make the __fstate_clean() function can correctly set the
state of sstatus.FS in pt_regs to SR_FS_CLEAN.
Tested on both QEMU and HiFive Unleashed using BBL + Linux.
Signed-off-by: Vincent Chen
---
arch/riscv/include/asm/switch_to.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
The following two reasons cause FP registers are sometimes not
initialized before starting the user program.
1. Currently, the FP context is initialized in flush_thread() function
and we expect these initial values to be restored to FP register when
doing FP context switch. However, the FP
Enable deprecated/obsolete ARMv8 instructions emulation. This allows
to run ARMv6 binaries (e.g. Raspberry Pi) on ARMv8 machines.
Signed-off-by: Stefan Agner
---
arch/arm64/configs/defconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs
Reference counters are preferred to use refcount_t instead of
atomic_t.
This is because the implementation of refcount_t can prevent
overflows and detect possible use-after-free.
So convert atomic_t ref counters to refcount_t.
Signed-off-by: Chuhong Yuan
---
crypto/cryptd.c | 44
Hi Stephen,
On Tue, Jul 30, 2019 at 8:21 PM Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> express
On Wed, 2019-08-07 at 12:51 +0200, Uwe Kleine-König wrote:
> On Wed, Aug 07, 2019 at 08:26:23AM +, Philippe Schenker wrote:
> > Add the phy-node and mdio bus to the fec-node, represented as is on
> > hardware.
> > This commit includes micrel,led-mode that is set to the default
> > value, prepar
The static xpc_arch_operations structure xpc_arch_ops_uv is only copied
into the structure xpc_arch_ops, after which it is never modified; nor
is it used in any other way. Hence it can be declared as a constant to
prevent unintended modifications of its fields.
Issue found with Coccinelle.
Signed-
Hi Stephen,
On Tue, Jul 30, 2019 at 8:21 PM Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> express
On Thu, Aug 8, 2019 at 9:50 AM Christoph Hellwig wrote:
> On Wed, Aug 07, 2019 at 08:40:58AM -0700, Paul Walmsley wrote:
> > On Wed, 7 Aug 2019, Christoph Hellwig wrote:
> > > On Wed, Aug 07, 2019 at 05:22:15PM +0200, Greg KH wrote:
> > > > > Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 c
On Tue, Aug 06, 2019 at 02:16:10PM -0700, Reinette Chatre wrote:
> > I'd leave it to tglx to say how we should mirror cache inclusivity in
> > cpuinfo_x86: whether a synthetic X86_FEATURE bit or cache the respective
> > CPUID words which state whether L2/L3 is inclusive...
>
> Thank you very much.
Hi Stephen,
On Tue, Jul 30, 2019 at 8:19 PM Stephen Boyd wrote:
> We don't need dev_err() messages when platform_get_irq() fails now that
> platform_get_irq() prints an error message itself when something goes
> wrong. Let's remove these prints with a simple semantic patch.
>
> //
> @@
> express
On 8/8/19 9:56 AM, Peter Zijlstra wrote:
> On Wed, Aug 07, 2019 at 06:31:59PM +0200, Dietmar Eggemann wrote:
>> On 7/26/19 4:54 PM, Peter Zijlstra wrote:
>>>
>>>
>>> Signed-off-by: Peter Zijlstra (Intel)
>>
>> [...]
>>
>>> @@ -889,6 +891,8 @@ static void update_curr(struct cfs_rq *c
>>>
On Thu, Aug 08, 2019 at 10:08:41AM +0200, Borislav Petkov wrote:
> Ok, tglx and I talked it over a bit on IRC: so your 1/10 patch is pretty
> close - just leave out the generic struct cacheinfo bits and put the
> cache inclusivity property in a static variable there.
... and by "there" I mean arch
On 8/8/19 2:10 AM, Kalle Valo wrote:
Larry Finger writes:
On 8/7/19 8:51 PM, Valdis Klētnieks wrote:
Fix spurious warning message when building with W=1:
CC [M] drivers/net/wireless/realtek/rtlwifi/usb.o
drivers/net/wireless/realtek/rtlwifi/usb.c:243: warning: Cannot understand *
on l
Hi all,
Changes since 20190807:
I reverted a commit from the kbuild-current tree by request.
The dma-mapping-fixes tree gained a build failure for which I reverted
the merge of that tree.
The bpf-next tree gained a conflict against Linus' tree.
The crypto tree still had its build failure for w
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
diff --git a/arch/powerpc/kernel/kaslr_booke.c
b/arch/powerpc/kernel/kaslr_booke.c
index c6b326424b54..436f9a03f385 100644
--- a/arch/powerpc/kernel/kaslr_booke.c
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -361,6 +361,18 @@ static
On Fri, Jun 07, 2019 at 05:44:06PM +0200, Paul Cercueil wrote:
> Right now none of the Ingenic-based boards probe this driver from
> devicetree. This driver defined three compatible strings for the exact
> same behaviour. Before these strings are used, we can remove two of
> them.
>
> Signed-off-b
On Mon, Jul 08, 2019 at 08:04:25PM -0600, Rob Herring wrote:
> On Fri, Jun 07, 2019 at 05:44:05PM +0200, Paul Cercueil wrote:
> > Right now none of the Ingenic-based boards probe this driver from
> > devicetree. This driver defined three compatible strings for the exact
> > same behaviour. Before t
On Wed, 7 Aug 2019 16:33:11 +
Parav Pandit wrote:
> > -Original Message-
> > From: Cornelia Huck
> > Sent: Wednesday, August 7, 2019 2:58 PM
> > To: Parav Pandit
> > Cc: k...@vger.kernel.org; wankh...@nvidia.com; linux-
> > ker...@vger.kernel.org; alex.william...@redhat.com; c...@nv
From: Eugen Hristev
Add mmc capabilities for SDMMC0 for this board.
With this enabled, eMMC connected card is detected as:
mmc0: new DDR MMC card at address 0001
Signed-off-by: Eugen Hristev
---
arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/ar
From: Eugen Hristev
HS200 is not implemented in the driver, but the controller claims it
through caps.
Remove it via quirk.
Without this quirk, the mmc core will try to enable hs200, which will fail,
and the eMMC initialization will fail.
Signed-off-by: Eugen Hristev
---
drivers/mmc/host/sdhci
From: Rafael J. Wysocki
One of the modifications made by commit d916b1be94b6 ("nvme-pci: use
host managed power state for suspend") was adding a pci_save_state()
call to nvme_suspend() in order to prevent the PCI bus-level PM from
being applied to the suspended NVMe devices, but if ASPM is not
en
On 2019/8/7 21:03, Michael Ellerman wrote:
Jason Yan writes:
When kaslr is enabled, the kernel offset is different for every boot.
This brings some difficult to debug the kernel. Dump out the kernel
offset when panic so that we can easily debug the kernel.
Some of this is taken from the ar
This patch adds the evaluation variant of the model A of the PineH64.
The model A has the same size of the pine64 and has a PCIE slot.
The only devicetree difference with current pineH64, is the PHY
regulator.
Signed-off-by: Corentin Labbe
---
arch/arm64/boot/dts/allwinner/Makefile| 1
On Wed, Aug 07, 2019 at 12:23:29PM -0700, Reinette Chatre wrote:
> I do not fully understand this proposal. All those goto labels take care
> of the the different failures that can be encountered during the
> initialization of the pseudo-lock region. Each initialization failure is
> associated with
Hi,
These two patches fix a minor issue related to system suspend in the intel-hid
and intel-vbtn drivers and update the suspend/resume handling in intel-hid to
reduce special-casing in it somewhat.
Please refer to the changelogs for details.
Thanks,
Rafael
On Thu, Aug 08, 2019 at 08:02:10AM +0200, Michal Hocko wrote:
>On Thu 08-08-19 11:26:38, Wei Yang wrote:
>> On Wed, Aug 07, 2019 at 09:51:01AM +0200, Michal Hocko wrote:
>> >On Wed 07-08-19 08:31:09, Wei Yang wrote:
>> >> On Tue, Aug 06, 2019 at 11:29:52AM +0200, Vlastimil Babka wrote:
>> >> >On 8/
From: Rafael J. Wysocki
Both intel-hid and intel-vbtn set a wakeup_mode flag causing them
to behave in a special way during system suspend and while suspended
in their "prepare" PM callbacks and clear it in their "resume" PM
callbacks. That may cause the wakeup_mode flag to remain set after
a sy
From: Rafael J. Wysocki
Notice that intel_button_array_enable() never disables the power
button which is the only one needed to wake up the system from
suspend-to-idle, so it can be safely called during suspend-to-idle
as well as during "regular" system suspend, and rearrange the
code in the driv
On 08/08/19 10:11, Dietmar Eggemann wrote:
> On 8/8/19 9:56 AM, Peter Zijlstra wrote:
> > On Wed, Aug 07, 2019 at 06:31:59PM +0200, Dietmar Eggemann wrote:
> >> On 7/26/19 4:54 PM, Peter Zijlstra wrote:
> >>>
> >>>
> >>> Signed-off-by: Peter Zijlstra (Intel)
> >>
> >> [...]
> >>
> >>> @@ -889,6 +8
Le 07/08/2019 à 03:24, Chris Packham a écrit :
On Wed, 2019-08-07 at 11:13 +1000, Michael Ellerman wrote:
Chris Packham writes:
On Tue, 2019-08-06 at 21:32 +1000, Michael Ellerman wrote:
The difference between a working and non working defconfig is
CONFIG_PREEMPT specifically CONFIG_PREEMP
> - ndev->last_ps = 0;
> ret = nvme_get_power_state(ctrl, &ndev->last_ps);
> - if (ret < 0)
> + if (ret < 0 || ndev->last_ps == U32_MAX)
Is the intent of the magic U32_MAX check to see if the
nvme_get_power_state failed at the nvme level? In that case just
checking for any non-z
The patch adds ftm_alarm0 DT node
- add new rcpm node
- add ftm_alarm0 node
- aliases ftm_alarm0 as rtc1
Signed-off-by: Biwen Li
---
Change in v3:
- add little-endian property of rcpm for ls1088a,ls208xa
Change in v2:
- None
arch/arm64/boot/dts/freescale
The patch add ftm_alarm0 DT node
- add rcpm node
- add ftm_alarm0 node
- aliases ftm_alarm0 as rtc1
Signed-off-by: Biwen Li
---
Change in v3:
- None
Change in v2:
- delete reg-name property
- correct fsl,rcpm-wakeup property
arch/arm/boot/dts/ls1
The patch adds ftm_alarm0 DT node for LS1028ARDB board
FlexTimer1 module is used to wakeup the system
Signed-off-by: Biwen Li
---
Change in v3:
- add little-endian property of rcpm
Change in v2:
- None
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 18 ++
1 fi
On 8/8/19 5:26 AM, Wei Yang wrote:
>
> @@ -2270,12 +2270,9 @@ find_vma_prev(struct mm_struct *mm, unsigned long addr,
> if (vma) {
> *pprev = vma->vm_prev;
> } else {
> - struct rb_node *rb_node = mm->mm_rb.rb_node;
> - *pprev = NULL;
> -
On 08/08/19 01:15, Paul Walmsley wrote:
> On Wed, 7 Aug 2019, Paolo Bonzini wrote:
>
>> On 07/08/19 14:27, Anup Patel wrote:
>>> This series adds initial KVM RISC-V support. Currently, we are able to boot
>>> RISC-V 64bit Linux Guests with multiple VCPUs.
>>
>> Looks good to me! Still need an Ack
On 8/8/19 10:46 AM, Juri Lelli wrote:
> On 08/08/19 10:11, Dietmar Eggemann wrote:
>> On 8/8/19 9:56 AM, Peter Zijlstra wrote:
>>> On Wed, Aug 07, 2019 at 06:31:59PM +0200, Dietmar Eggemann wrote:
On 7/26/19 4:54 PM, Peter Zijlstra wrote:
>
>
> Signed-off-by: Peter Zijlstra (Intel)
From: Neo Hou
This patch adds the Spreadtrum PWM support, which provides maximum 4
channels.
Signed-off-by: Neo Hou
Co-developed-by: Baolin Wang
Signed-off-by: Baolin Wang
---
drivers/pwm/Kconfig| 10 ++
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-sprd.c | 311 +++
401 - 500 of 1073 matches
Mail list logo
