On 2019/09/06 19:35, David Hildenbrand wrote:
> On 06.09.19 12:02, Toshiki Fukasawa wrote:
>> Thank you for your feedback.
>>
>> On 2019/09/06 17:45, David Hildenbrand wrote:
>>> On 06.09.19 10:09, Toshiki Fukasawa wrote:
A kernel panic is observed during reading
On 08/09/2019 15.06, Vinod Koul wrote:
> On 06-09-19, 17:18, Peter Ujfalusi wrote:
>> On systems where multiple DMA controllers available, none Slave (for example
>
> On systems with multiple DMA controllers, non Slave...
Sure.
>> memcpy operation) users can not be described in DT as there
Hi,
On 27/08/19 9:28 AM, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan
>
> on Intel's Lightning Mountain(LGM) SoCs QSPI controller do not use
> Direct Memory Access(DMA) and Direct Access Controller(DAC).
>
> This patch introduces to properly disable the DMA and DAC
>
Hi Dave,
On 9/9/19 1:32 PM, Dave Chinner wrote:
On Mon, Sep 09, 2019 at 09:58:49AM +0800, kernel test robot wrote:
Greeting,
FYI, we noticed a -71.2% improvement of fsmark.app_overhead due to commit:
A negative improvement? That's somewhat ambiguous...
Sorry for causing the
Currently a device does not belong to any of the numa nodes
(dev->numa_node is NUMA_NO_NODE) when the node id is neither
specified by fw nor by virtual device layer and the device has
no parent device.
According to discussion in [1]:
Even if a device's numa node is not specified, the device
Hi,
Mostly some cosmetic comments below, other than that seems fine to me.
On 30/07/2019 12:34, Peter Ujfalusi wrote:
From: Grygorii Strashko
The Ring Accelerator (RINGACC or RA) provides hardware acceleration to
enable straightforward passing of work between a producer and a consumer.
There
If we are already under list_lock, don't call kmalloc(). Otherwise we
will run into deadlock because kmalloc() also tries to grab the same
lock.
Instead, allocate pages directly. Given currently page->objects has
15 bits, we only need 1 page. We may waste some memory but we only do
so when slub
On Sun, Sep 08, 2019 at 08:19:21PM -0400, Valdis Klētnieks wrote:
> In that case, rather than removing it, shouldn't we be *adding*
> code to properly set it instead?
Right, setting the UtcOffset fields to 0 is the first step marking
them as invalid for now. This is also why access_time_ms did
On Mon, Sep 09, 2019 at 02:06:54PM +0800, Rong Chen wrote:
> Hi Dave,
>
> On 9/9/19 1:32 PM, Dave Chinner wrote:
> > On Mon, Sep 09, 2019 at 09:58:49AM +0800, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed a -71.2% improvement of fsmark.app_overhead due to commit:
> > A
Peter Zijlstra wrote:
>
> Paulmck actually has an example of that somewhere; ISTR that particular
> case actually got fixed by GCC, but I'd really _love_ for some compiler
> people (both GCC and LLVM) to state that their respective compilers will
> not do load/store tearing for machine word sized
On 09/07/2019 12:33 AM, Gerald Schaefer wrote:
> On Fri, 6 Sep 2019 11:58:59 +0530
> Anshuman Khandual wrote:
>
>> On 09/05/2019 10:36 PM, Gerald Schaefer wrote:
>>> On Thu, 5 Sep 2019 14:48:14 +0530
>>> Anshuman Khandual wrote:
>>>
> [...]
>> +
>> +#if
On 08/09/2019 15.10, Vinod Koul wrote:
> On 08-09-19, 10:47, Peter Ujfalusi wrote:
>>
>>
>> On 06/09/2019 17.18, Peter Ujfalusi wrote:
>>> On systems where multiple DMA controllers available, none Slave (for example
>>> memcpy operation) users can not be described in DT as there is no device
Hi Sujeev, all,
Is the code somewhere in a repository for review?>
> Hi Greg Kroah-Hartman\Arnd Bergmann and community
>
> Thank you for all the feedback, I believe I have addressed all the comments
> from previous
> patches. Also, I am excluding mhi network driver in this series. I still have
Hi Pierre
We are working on a backport 3.14 branch for Chrome projects based on BDW
platform. In the branch 4-channel capture is supported on some platforms but
not all. So we need to add a constraint in the machine driver for machines
don't support this feature.
I checked the for-next branch
On Sun, Sep 8, 2019 at 6:19 PM Linus Torvalds
wrote:
>
> On Sat, Sep 7, 2019 at 11:08 PM syzbot
> wrote:
> >
> > The bug was bisected to:
> >
> > commit e41d58185f1444368873d4d7422f7664a68be61d
> > Author: Dmitry Vyukov
> > Date: Wed Jul 12 21:34:35 2017 +
> >
> > fault-inject:
On 9/6/2019 7:20 PM, Andrew Murray wrote:
On Fri, Sep 06, 2019 at 06:58:11PM +0800, Dilip Kota wrote:
Hi Andrew Murray,
Thanks for the review. Please find my response inline.
On 9/5/2019 6:45 PM, Andrew Murray wrote:
On Wed, Sep 04, 2019 at 06:10:31PM +0800, Dilip Kota wrote:
Add support
On 08/09/2019 17.12, Vinod Koul wrote:
> On 30-07-19, 12:34, Peter Ujfalusi wrote:
>> The metadata is best described as side band data or parameters traveling
>> alongside the data DMAd by the DMA engine. It is data
>> which is understood by the peripheral and the peripheral driver only, the
>>
On 9/6/2019 5:19 PM, Andy Shevchenko wrote:
On Thu, Sep 05, 2019 at 10:31:29PM +0200, Martin Blumenstingl wrote:
On Wed, Sep 4, 2019 at 12:11 PM Dilip Kota wrote:
+ phy-names:
+const: pciephy
the most popular choice in Documentation/devicetree/bindings/pci/ is "pcie-phy"
if Rob is
This patch is to remove following hardware events
from JSON file which are not supported on POWER8.
pm_l3_p0_grp_pump
pm_l3_p0_lco_data
pm_l3_p0_lco_no_data
pm_l3_p0_lco_rty
Fixes: c3b4d5c4afb0 ("perf vendor events: Remove P8 HW events which are not
supported")
Note: Unfortunately power8 event
Hi Andreas,
I'm so sorry for the delay. I was working on another project now, and I wasn't
entirely devoted to this. I looked at it at the weekend and the modified code
is working. I have only tested OpenWRT in build - r10204-38b22b1, kernel
4.14.125. I do not expect complications on other
On 2019/9/6 下午9:46, Michael S. Tsirkin wrote:
On Thu, Sep 05, 2019 at 08:27:35PM +0800, Jason Wang wrote:
It was reported that metadata acceleration introduces several issues,
so this patch reverts commit ff466032dc9e5a61217f22ea34b2df932786bbfc,
73f628ec9e6bcc45b77c53fe6d0c0ec55eaf82af and
On 2019/9/6 下午9:15, David Miller wrote:
From: Jason Wang
Date: Fri, 6 Sep 2019 18:02:35 +0800
On 2019/9/5 下午9:59, Jason Gunthorpe wrote:
I think you should apply the revert this cycle and rebase the other
patch for next..
Jason
Yes, the plan is to revert in this release cycle.
Then you
On 2019/9/8 下午7:05, Michael S. Tsirkin wrote:
iovec addresses coming from vhost are assumed to be
pre-validated, but in fact can be speculated to a value
out of range.
Userspace address are later validated with array_index_nospec so we can
be sure kernel info does not leak through these
Hi Vladimir,
> I won't attend the LPC, however I would appreciate if you book some
A pity. I would have liked to have you in the room. Let's see if we can
get enough input from you via mail here.
> time to review my original / alternative implementation of the TI
> DS90Ux9xx I2C bridge device
On Mon, Sep 09, 2019 at 05:21:55PM +1000, Herbert Xu wrote:
> On Fri, Sep 06, 2019 at 11:18:19AM +, Horia Geanta wrote:
> > On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> > > In order to access IP block's registers we need to enable appropriate
> > > clocks first, otherwise we are risking
On 2019/9/9 下午12:45, Michael S. Tsirkin wrote:
Since idx can be speculated, I guess we need array_index_nospec here?
So we have
ACQUIRE(mmu_lock)
get idx
RELEASE(mmu_lock)
ACQUIRE(mmu_lock)
read array[idx]
RELEASE(mmu_lock)
Then I think idx can't be speculated consider we've passed
Hi,
On 09/09/19 11:39 AM, Tero Kristo wrote:
[...]
>> diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
>> new file mode 100644
>> index ..401dfc963319
>> --- /dev/null
>> +++ b/drivers/soc/ti/k3-ringacc.c
>> @@ -0,0 +1,1191 @@
>> +// SPDX-License-Identifier:
Hi Vignesh,
Thank you so much for the review comments and your time.
On 9/9/2019 2:05 PM, Vignesh Raghavendra wrote:
Hi,
On 27/08/19 9:28 AM, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
on Intel's Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Memory
On 25/07/19 6:42 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add all DaVinci boards to multi_v5_defconfig.
>
> Signed-off-by: Bartosz Golaszewski
Acked-by: Sekhar Nori
Thanks,
Sekhar
On 25/07/19 6:42 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add modifications necessary to make davinci part of the ARM v5
> multiplatform build.
>
> Move the arch-specific configuration out of arch/arm/Kconfig and
> into mach-davinci/Kconfig. Remove the sub-menu for DaVinci
In function acpi_idle_do_entry(), we do an io port access to guarantee
hardware behavior. But it could trigger unnecessary vmexit for
virtualization environemnt.
>From the comments of this part of code, we could use busy wait instead
of io port access to guarantee hardware behavior and avoid
Hello Sakari,
Thanks for your reply.
> On 6 Sep 2019, at 09:54, Sakari Ailus wrote:
>
> Hi Jan,
>
> Thanks for the patchset.
>
> On Thu, Sep 05, 2019 at 11:56:00AM +0100, Jan Kotas wrote:
>> /*
>> * Driver for Cadence MIPI-CSI2 RX Controller v1.3
>> *
>> - * Copyright (C) 2017 Cadence
Update global clock controller SDCC2/4 clocks to use the floor rcg ops,
so as to use the rounded down clock rates for these clocks.
Signed-off-by: Taniya Das
---
drivers/clk/qcom/gcc-ipq8074.c | 2 +-
drivers/clk/qcom/gcc-msm8998.c | 4 ++--
drivers/clk/qcom/gcc-qcs404.c | 2 +-
On 09.09.19 07:48, Toshiki Fukasawa wrote:
> On 2019/09/06 19:35, David Hildenbrand wrote:
>> On 06.09.19 12:02, Toshiki Fukasawa wrote:
>>> Thank you for your feedback.
>>>
>>> On 2019/09/06 17:45, David Hildenbrand wrote:
On 06.09.19 10:09, Toshiki Fukasawa wrote:
> A kernel panic is
Hi Stephen, Vinod,
On 9/7/2019 2:08 AM, Stephen Boyd wrote:
Quoting Vinod Koul (2019-09-05 21:56:59)
Update the gcc qcs404 clock driver to use floor ops for sdcc clocks. As
disuccsed in [1] it is good idea to use floor ops for sdcc clocks as we
dont want the clock rates to do round up.
[1]:
On Mon, Sep 09, 2019 at 07:41:21AM +, Jan Kotas wrote:
>
>
> Hello Sakari,
>
> Thanks for your reply.
> > On 6 Sep 2019, at 09:54, Sakari Ailus wrote:
> >
> > Hi Jan,
> >
> > Thanks for the patchset.
> >
> > On Thu, Sep 05, 2019 at 11:56:00AM +0100, Jan Kotas wrote:
> >> /*
> >> *
On 28.08.19 09:42, Yi Wang wrote:
> We get two warnings when build kernel W=1:
> mm/shuffle.c:36:12: warning: no previous prototype for ‘shuffle_show’
> [-Wmissing-prototypes]
> mm/sparse.c:220:6: warning: no previous prototype for
> ‘subsection_mask_set’ [-Wmissing-prototypes]
>
> Make the
On 07.09.19 23:47, Souptick Joarder wrote:
> __online_page_set_limits() is a dummy function and an extra call
> to this function can be avoided.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/xen/balloon.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/xen/balloon.c
On 08/09/19 7:01 PM, Bartosz Golaszewski wrote:
> sob., 7 wrz 2019 o 10:21 Arnd Bergmann napisał(a):
>>
>> On Wed, Aug 28, 2019 at 9:55 AM Bartosz Golaszewski
>> wrote:
>>> śr., 28 sie 2019 o 09:44 Sekhar Nori napisał(a):
>>>
>>> Actually I tested this without the clocksource conversion and it
On Wed, Sep 04, 2019 at 11:01:17AM +0800, zhong jiang wrote:
> Use kzfree instead of memset() + kfree().
>
> Signed-off-by: zhong jiang
> ---
> drivers/crypto/marvell/hash.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
On 2019/9/9 15:30, Jaegeuk Kim wrote:
> On 09/09, Chao Yu wrote:
>> On 2019/9/9 9:25, Jaegeuk Kim wrote:
>>> If committing atomic pages is failed when doing f2fs_do_sync_file(), we can
>>> get commited pages but atomic_file being still set like:
>>>
>>> - inmem:0, atomic IO:4 (Max. 10),
On 07.09.19 23:47, Souptick Joarder wrote:
> __online_page_set_limits() is a dummy function and an extra call
> to this function can be avoided.
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/hv/hv_balloon.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/hv/hv_balloon.c
On 07.09.19 23:47, Souptick Joarder wrote:
> As both the callers of this dummy __online_page_set_limits()
> is removed, this can be removed permanently.
>
> Signed-off-by: Souptick Joarder
> ---
> include/linux/memory_hotplug.h | 1 -
> mm/memory_hotplug.c| 5 -
> 2 files
The current version of the IOCTL have a small problem which prevents us
from extending the API by making use of reserved fields. In these new
IOCTLs, we are now making sure that flags and rsv fields are zero which
will allow us to extend the API in the future.
Reviewed-by: Richard Cochran
Some controllers allow for a one-shot output pulse, in contrast to
periodic output. Now that we have extensible versions of our IOCTLs, we
can finally make use of the 'flags' field to pass a bit telling driver
that if we want one-shot pulse output.
Signed-off-by: Felipe Balbi
---
Changes since
On 09.09.19 09:46, David Hildenbrand wrote:
> On 09.09.19 07:48, Toshiki Fukasawa wrote:
>> On 2019/09/06 19:35, David Hildenbrand wrote:
>>> On 06.09.19 12:02, Toshiki Fukasawa wrote:
Thank you for your feedback.
On 2019/09/06 17:45, David Hildenbrand wrote:
> On 06.09.19
On Sun 08-09-19 03:17:01, Souptick Joarder wrote:
> __online_page_set_limits() is a dummy function and an extra call
> to this can be avoided.
>
> As both of the callers are now removed, __online_page_set_limits()
> can be removed permanently.
>
> Souptick Joarder (3):
> hv_ballon: Avoid
> On 9 Sep 2019, at 09:51, Sakari Ailus wrote:
>
>
> On Mon, Sep 09, 2019 at 07:41:21AM +, Jan Kotas wrote:
>>
>>
>> Hello Sakari,
>>
>> Thanks for your reply.
>>> On 6 Sep 2019, at 09:54, Sakari Ailus wrote:
>>>
>>> Hi Jan,
>>>
>>> Thanks for the patchset.
>>>
>>> On Thu, Sep 05,
On Fri, Sep 06, 2019 at 04:29:50PM -0500, Steve Wahl wrote:
> Our hardware (UV aka Superdome Flex) has address ranges marked
> reserved by the BIOS. These ranges can cause the system to halt if
> accessed.
>
> During kernel initialization, the processor was speculating into
> reserved memory
On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Change the logic used to generate randomness in the suffle path so that we
> can avoid cache line bouncing. The previous logic was sharing the offset
> and entropy word between all CPUs. As such this can result in cache line
>
This definition is not used anywhere, let's remove it.
Suggested-by: Andy Shevchenko
Signed-off-by: Dmitry Torokhov
---
include/linux/property.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/property.h b/include/linux/property.h
index 9b3d4ca3a73a..44c1704f7163 100644
---
Instead of explicitly setting values of integer types when copying property
entries lets just copy entire value union when processing non-array values.
When handling array values assign the pointer there using the newly introduced
"raw" pointer union member. This allows us to remove
Because property_copy_string_array() stores the newly allocated pointer in the
destination property, we have an awkward code in property_entry_copy_data()
where we fetch the new pointer from dst.
Let's change property_copy_string_array() to return pointer and rely on the
common path in
Let's switch to using PROPERTY_ENTRY_U8_ARRAY_LEN() to initialize
property entries instead of poking into the structure directly.
Signed-off-by: Dmitry Torokhov
---
drivers/firmware/efi/apple-properties.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
We do not need a special flag to know if we are dealing with an array, as we can
get that data from ration between element length and the data size, however we
do need a flag to know whether the data is stored directly inside property_entry
or separately.
Signed-off-by: Dmitry Torokhov
---
There is no need to treat string arrays and single strings separately, we can go
exclusively by the element length in relation to data type size.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git
These series implement "references" properties for software nodes as true
properties, instead of managing them completely separately.
The first 10 patches are generic cleanups and consolidation and unification
of the existing code; patch #11 implements PROPERTY_EMTRY_REF() and friends;
patch #12
Sometimes we want to initialize property entry array from a regular
pointer, when we can't determine length automatically via ARRAY_SIZE.
Let's introduce PROPERTY_ENTRY_ARRAY_XXX_LEN macros that take explicit
"len" argument.
Signed-off-by: Dmitry Torokhov
---
include/linux/property.h | 19
It is possible to store references to software nodes in the same fashion as
other static properties, so that users do not need to define separate
structures:
static const struct software_node gpio_bank_b_node = {
.name = "B",
};
static const struct property_entry simone_key_enter_props[]
There is absolutely no reason to have them as we can handle it all nicely in
property_entry_read_int_array().
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c | 85 +++
1 file changed, 14 insertions(+), 71 deletions(-)
diff --git
We do not need to handle each data type separately, we can simply return either
the raw pointer or pointer to values union.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c | 29 ++---
1 file changed, 6 insertions(+), 23 deletions(-)
diff --git
Now that static device properties allow defining reference properties
together with all other types of properties, instead of managing them
separately, let's adjust the driver.
Signed-off-by: Dmitry Torokhov
---
drivers/platform/x86/intel_cht_int33fe.c | 81
1 file
We can unify string properties initializer macros with integer
initializers.
Signed-off-by: Dmitry Torokhov
---
include/linux/property.h | 70 +---
1 file changed, 30 insertions(+), 40 deletions(-)
diff --git a/include/linux/property.h
Now that all users of references have moved to reference properties,
we can remove separate handling of references.
Signed-off-by: Dmitry Torokhov
---
drivers/base/swnode.c| 44 +++-
include/linux/property.h | 14 -
2 files changed, 16
> strongly encouraged to restrict their checkpatch cleanups to the
> staging tree, since when such cleanup patches are considered welcome
> very much depends on the kernel subsystem and the maintainers
> involved.)
Should I still send the ones I tried to submit in this thread again
as separate
The mailbox length is 0x1000 hence the max_register value is 0xFFC.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Move the head/tail adding logic out of the shuffle code and into the
> __free_one_page function since ultimately that is where it is really
> needed anyway. By doing this we should be able to reduce the overhead
> and can
Quoting Jorge Ramirez-Ortiz (2019-09-06 16:23:46)
> The max register is 0x23004 as per the manual (the current
> max_register that this commit is fixing is actually out of bounds).
>
> Signed-off-by: Jorge Ramirez-Ortiz
> ---
Fixes tag?
> drivers/clk/qcom/turingcc-qcs404.c | 2 +-
> 1 file
On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck
>
> In order to support page reporting it will be necessary to store and
> retrieve the migratetype of a page. To enable that I am moving the set and
> get operations for pcppage_migratetype into the mm/internal.h header so
> that
From: Walter Wu
This patch is KASAN report adds the alloc/free stacks for page allocator
in order to help programmer to see memory corruption caused by page.
By default, KASAN doesn't record alloc and free stack for page allocator.
It is difficult to fix up page use-after-free or dobule-free
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f74c2bb98776e2de508f4d607cd519873065118e
commit: a035d552a93bb9ef6048733bb9f2a0dc857ff869 Makefile: Globally enable
fall-through warning
date: 6 weeks ago
config: arm-allyesconfig (attached as
On Mon, Sep 09, 2019 at 02:51:03PM +0800, Dilip Kota wrote:
>
> On 9/6/2019 7:20 PM, Andrew Murray wrote:
> > On Fri, Sep 06, 2019 at 06:58:11PM +0800, Dilip Kota wrote:
> > > Hi Andrew Murray,
> > >
> > > Thanks for the review. Please find my response inline.
> > >
> > > On 9/5/2019 6:45 PM,
+++ Matthias Maennich [06/09/19 11:32 +0100]:
As of Linux 5.3-rc7, there are 31207 [1] exported symbols in the kernel.
That is a growth of roughly 1000 symbols since 4.17 (30206 [2]). There
seems to be some consensus amongst kernel devs that the export surface
is too large, and hard to reason
On Sun 08-09-19 13:45:13, David Rientjes wrote:
> If the reverts to 5.3 are not
> applied, then I'm not at all confident that forward progress on this issue
> will be made:
David, could you stop this finally? I think there is a good consensus
that the current (even after reverts) behavior is
From: Joerg Vehlow
During the skb_queue_splice_init the tasklet could have been preempted
and __skb_queue_tail called, which led to an inconsistent queue.
Signed-off-by: Joerg Vehlow
---
net/xfrm/xfrm_input.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
if ovl_encode_real_fh() fails, no memory was allocated
and the error in the error-valued pointer should be returned.
Fixes: 9b6faee0747 ("ovl: check ERR_PTR() return value from ovl_encode_fh()")
Signed-off-by: Ding Xiang
---
fs/overlayfs/export.c | 2 +-
1 file changed, 1 insertion(+), 1
Introduce interrupts retrigger support for Amazon's Annapurna Labs Fabric
Interrupt Controller.
Signed-off-by: Talel Shenhar
---
drivers/irqchip/irq-al-fic.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/irqchip/irq-al-fic.c b/drivers/irqchip/irq-al-fic.c
index
There are total of 151 non-secure gpio (0-150) and four
pins of pinmux (91, 92, 93 and 94) are not mapped to any
gpio pin, hence update same in DT.
Fixes: 8aa428cc1e2e ("arm64: dts: Add pinctrl DT nodes for Stingray SOC")
Signed-off-by: Rayagonda Kokatanur
---
On Thu 05-09-19 01:44:12, sunqiuyang wrote:
> >
> >
> > From: Michal Hocko [mho...@kernel.org]
> > Sent: Wednesday, September 04, 2019 20:52
> > To: sunqiuyang
> > Cc: linux-kernel@vger.kernel.org; linux...@kvack.org
> > Subject: Re: [PATCH 1/1]
On Sun, 2019-09-08 at 22:27 +0100, Catalin Marinas wrote:
> On Fri, Sep 06, 2019 at 02:06:14PM +0200, Nicolas Saenz Julienne wrote:
> > @@ -430,7 +454,7 @@ void __init arm64_memblock_init(void)
> >
> > high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> >
> > -
On 9/9/19 4:49 AM, 禹舟键 wrote:
>> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
>> index 025151dcb651..8e51fbb88549 100644
>> --- a/tools/perf/builtin-sched.c
>> +++ b/tools/perf/builtin-sched.c
>> @@ -3374,6 +3374,7 @@ int cmd_sched(int argc, const char **argv)
>>
On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Move the static definition for things such as HUGETLB_PAGE_ORDER out of
> asm/pgtable.h and place it in page-defs.h. By doing this the includes
> become much easier to deal with as currently arm64 is the only architecture
>
On Sat, 2019-09-07 at 20:54 +0800, kbuild test robot wrote:
> [External]
>
> Hi Alexandru,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
Hmm, this error should be expectable I guess: I applied this on net-next/master.
Alex
> [cannot apply to
KASAN will record last stack of page in order to help programmer
to see memory corruption caused by page.
What is difference between page_owner and our patch?
page_owner records alloc stack of page, but our patch is to record
last stack(it may be alloc or free stack of page).
Signed-off-by:
The max register is 0x23004 as per the manual (the current
max_register that this commit is fixing is actually out of bounds).
Fixes: 892df0191b29 ("clk: qcom: Add QCS404 TuringCC")
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: add Fixes tag
drivers/clk/qcom/turingcc-qcs404.c | 2 +-
1 file
On 07.09.19 19:26, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Currently the page poisoning setting wasn't being enabled unless free page
> hinting was enabled. However we will need the page poisoning tracking logic
> as well for unused page reporting. As such pull it out and make it a
>
layerscape otg function should be supported HNP SRP and ADP protocol
accroing to rm doc, but dwc3 code not realize it and use id pin to
detect who is host or device(0 is host 1 is device) this patch is to
enable OTG mode on ls1028ardb ls1088ardb and ls1046ardb in dts
Signed-off-by: Yinbo Zhu
---
On Mon, Sep 09, 2019 at 11:24:19AM +0530, Naresh Kamboju wrote:
> On Sun, 8 Sep 2019 at 18:19, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 5.2.14 release.
> > There are 94 patches in this series, all will be posted as a response
> > to this one. If
On Sat, Sep 07, 2019 at 10:25:12AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck
>
> Change the logic used to generate randomness in the suffle path so that we
Typo.
> can avoid cache line bouncing. The previous logic was sharing the offset
> and entropy word between all CPUs. As such
The mailbox length is 0x1000 hence the max_register value is 0xFFC.
Fixes: c6a8b171ca8e ("mailbox: qcom: Convert APCS IPC driver to use
regmap")
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: added Fixes tag
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +-
1 file changed, 1 insertion(+), 1
The purpose of crb_fixup_cmd_size() function is to work around broken
BIOSes and get the trustable size between the ACPI region and register.
When the TPM has a command buffer and response buffer independently,
the crb_map_io() function calls crb_fixup_cmd_size() twice to calculate
each buffer
On 07/09/2019 00:44, Aleksa Sarai wrote:
> On 2019-09-06, Andy Lutomirski wrote:
>>> On Sep 6, 2019, at 12:07 PM, Steve Grubb wrote:
>>>
On Friday, September 6, 2019 2:57:00 PM EDT Florian Weimer wrote:
* Steve Grubb:
> Now with LD_AUDIT
> $
This patch series enhances the support for the AMD's fTPM.
The AMD system assigned a command buffer and response buffer
independently in ACPI NVS region. ACPI NVS region allowed nothing to
assign a resource in it.
For supporting AMD's fTPM, I made a patch to enhance the code of command
and
I got an AMD system which had a Ryzen Threadripper 1950X and MSI
mainboard, and I had a problem with AMD's fTPM. My machine showed an error
message below, and the fTPM didn't work because of it.
[ 5.732084] tpm_crb MSFT0101:00: can't request region for resource
[mem
Document Amazon's Annapurna Labs POS SoC binding.
Signed-off-by: Talel Shenhar
---
.../devicetree/bindings/soc/amazon/amazon,al-pos.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/amazon/amazon,al-pos.txt
diff --git
The Amazon's Annapurna Labs SoCs includes Point Of Serialization error
logging unit that reports an error in case of write error (e.g. attempt to
write to a read only register).
This patch series introduces the support for this unit.
Talel Shenhar (3):
dt-bindings: soc: al-pos: Amazon's
Amazon's Annapurna Labs SoCs uses al-pos driver, enable it.
Signed-off-by: Talel Shenhar
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 4778c77..bd86b15 100644
---
The Amazon's Annapurna Labs SoCs includes Point Of Serialization error
logging unit that reports an error in case write error (e.g. attempt to
write to a read only register).
This patch introduces the support for this unit.
Signed-off-by: Talel Shenhar
---
MAINTAINERS | 6 +++
On 06/09/2019 20:41, Andy Lutomirski wrote:
>
>
>> On Sep 6, 2019, at 11:38 AM, Jeff Layton wrote:
>>
>>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
On 06/09/2019 18:48, Jeff Layton wrote:
> On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote:
>> On 06/09/2019
On Fri, Sep 06, 2019 at 08:51:59PM +0200, Arnd Bergmann wrote:
> The intel_pin_to_gpio() function is only called by the
> PM support functions and causes a warning when those are disabled:
>
> drivers/pinctrl/intel/pinctrl-intel.c:841:12: error: unused function
> 'intel_pin_to_gpio'
1 - 100 of 731 matches
Mail list logo
