On Thu, Mar 28, 2019 at 06:28:26AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 28, 2019 at 01:36:12AM +, Zhang, Jun wrote:
> > Hello, Paul
> >
> > Yes, I only use original V3.18.136 to test. Because system run very slowly,
> > I give up.
> >
> > Device: NUC (made in 2017)
> > OS:
On Thu, Mar 28, 2019 at 02:03:17PM +0100, Borislav Petkov wrote:
> On Tue, Mar 19, 2019 at 09:43:25PM +0300, Andy Shevchenko wrote:
> > If by BIOS or by other means the serial port is configured
> > user might want to skip reconfiguration in the boot code.
>
> That needs more explanation: how can
On Thu, Mar 28, 2019 at 03:11:40PM +0200, Andy Shevchenko wrote:
> Any idea how it can be done?
Like this?
static u8 serial_inb(unsigned long addr, int offset)
{
if (early_serial_do_mmio) {
asm volatile("movb %1,%0" : "=q" (v) : "m" (*(volatile u8
__force *)addr));
Hi,
On 28-03-19 11:34, Chen, Hu wrote:
I run Android on x86 PC (it's a NUC). Everytime I press the power button
to wake the system, it suspends right away. After some debug, I find
that Android wants to see KEY_POWER at resume. Otherwise, its
opportunistic suspend will kick in shortly.
Hi Anup,
The code still does not use ASID in TLB flush routines. Without this
added the code does not boot on systems with true ASID support.
We also need to consider the case of CONTEXTID overflow on 32-bit
systems. 32-bit CONTEXTID may overflow in a month time.
Please all see my inline
smatch complaint:
arch/mips/sgi-ip27/ip27-irq.c:123 shutdown_bridge_irq()
warn: variable dereferenced before check 'hd' (see line 121)
Fix it by removing local variable and use hd->pin directly.
Fixes: 69a07a41d908 ("MIPS: SGI-IP27: rework HUB interrupts")
Reported-by: Dan Carpenter
Fix a typo in the compatible string
Signed-off-by: Angus Ainslie (Purism)
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index
On imx8mq B0 chip, AHB/SDMA clock ratio 2:1 can't be supported,
since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
to 500Mhz, so use 1:1 instead.
To limit this change to the imx8mq for now this patch also adds an
im8mq-sdma compatible string.
Signed-off-by: Angus Ainslie
The imx8mq 1:1 check breaks some earlier imx chips so limit the
ratio check to the imx8mq.
Angus Ainslie (Purism) (4):
arm64: dts: imx8mq: Fix the fsl,imx8mq-sdma compatible string
dmaengine: imx-sdma: Add clock ratio 1:1 check
dt-bindings: Document the new imx8mq-sdma compatible string
Set ahb clock on sdma1 to get rid of "Timeout waiting for CH0"
on the imx8mq.
Signed-off-by: Angus Ainslie (Purism)
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
The imx8mq needs to be specified to check the clk ratio.
Signed-off-by: Angus Ainslie (Purism)
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
On Thu, Mar 28, 2019 at 03:15:57PM +0200, Andy Shevchenko wrote:
> kstrtox() simple can't cover _all_ simple_strtox() cases.
I see only one case here. Are you saying kstrtoull() cannot work
here?
> I don't feel like uglifying code to satisfy a tool producing a silly
warning.
Uglifying how?
--
On Thu, Mar 28, 2019 at 03:21:53PM +0200, Andy Shevchenko wrote:
> If the connection to the target is done via serial interface and
> firmware and / or bootloader already did necessary configuration.
Again: how is the user supposed to know that? When a user sees "nocfg"'s
documentation, how is
czw., 28 mar 2019 o 14:11 Mukesh Ojha napisał(a):
>
>
> On 3/28/2019 4:30 PM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Calling read() for a single byte read will return 2 currently. Use
> > simple_read_from_buffer() which correctly handles all sizes.
> >
> > Fixes:
Physical memory hotadd has to allocate a memmap (struct page array) for
the newly added memory section. Currently, alloc_pages_node() is used
for those allocations.
This has some disadvantages:
a) an existing memory is consumed for that purpose
(~2MB per 128MB memory section on x86_64)
b)
From: Michal Hocko
check_pages_isolated_cb currently accounts the whole pfn range as being
offlined if test_pages_isolated suceeds on the range. This is based on
the assumption that all pages in the range are freed which is currently
the case in most cases but it won't be with later changes, as
From: Michal Hocko
arch_add_memory, __add_pages take a want_memblock which controls whether
the newly added memory should get the sysfs memblock user API (e.g.
ZONE_DEVICE users do not want/need this interface). Some callers even
want to control where do we allocate the memmap from by
From: Michal Hocko
The sufix "kmalloc" is misleading.
Rename it to alloc_section_memmap/free_section_memmap which
better reflects the funcionality.
Signed-off-by: Michal Hocko
Signed-off-by: Oscar Salvador
---
mm/sparse.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
Hi,
since last two RFCs were almost unnoticed (thanks David for the feedback),
I decided to re-work some parts to make it more simple and give it a more
testing, and drop the RFC, to see if it gets more attention.
I also added David's feedback, so now all users of add_memory/__add_memory/
On Thu, Mar 28, 2019 at 1:27 AM Junge, Terry wrote:
>
> Hi Nicolas,
>
> V4 looks good to me.
Looks good to me too.
Terry, can I consider this as a formal Rev-by you?
Cheers,
Benjamin
>
> Thanks,
> Terry
>
> >-Original Message-
> >Subject: [PATCH v4] HID: core: move Usage Page
On Thu, Mar 28, 2019 at 02:39:07PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:15:57PM +0200, Andy Shevchenko wrote:
> > kstrtox() simple can't cover _all_ simple_strtox() cases.
>
> I see only one case here. Are you saying kstrtoull() cannot work
> here?
Can, but with code
On 3/28/2019 1:24 PM, Yue Haibing wrote:
From: YueHaibing
KASAN report this:
BUG: KASAN: global-out-of-bounds in qedi_dbg_err+0xda/0x330 [qedi]
Read of size 31 at addr c12b0ae0 by task syz-executor.0/2429
CPU: 0 PID: 2429 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware
On Thu, Mar 28, 2019 at 02:28:55PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:11:40PM +0200, Andy Shevchenko wrote:
> > Any idea how it can be done?
>
> Like this?
>
> static u8 serial_inb(unsigned long addr, int offset)
It's not a generic serial_in()...
> {
> if
On 3/25/19 1:47 PM, David Rientjes wrote:
> This ensures that the address and length provided to DBG_DECRYPT and
> DBG_ENCRYPT do not cause an overflow.
>
> At the same time, pass the actual number of pages pinned in memory to
> sev_unpin_memory() as a cleanup.
>
> Reported-by: Cfir Cohen
>
On Thu, Mar 28, 2019 at 02:42:13PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:21:53PM +0200, Andy Shevchenko wrote:
> > If the connection to the target is done via serial interface and
> > firmware and / or bootloader already did necessary configuration.
>
> Again: how is the user
On Thu, Mar 28, 2019 at 03:50:15PM +0200, Andy Shevchenko wrote:
> Can, but with code uglifying to workaround kstrtox() restrictions.
> simple_strtox() _just works_ as expected.
simple_strtox() also has its problems.
> Requires buffer copying, finding digits there, making a proper termination.
On Thu, Mar 28, 2019 at 03:52:26PM +0200, Andy Shevchenko wrote:
> It's not a generic serial_in()...
Why?
> What about mmio32 as next step?
Next step where? Is it part of your patches?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, Mar 27, 2019 at 03:29:47PM -0700, Greg Thelen wrote:
> On Fri, Mar 22, 2019 at 11:15 AM Roman Gushchin wrote:
> > On Thu, Mar 07, 2019 at 08:56:32AM -0800, Greg Thelen wrote:
> > > + int cpu;
> > > +
> > > + for_each_online_cpu(cpu)
> > > + x +=
Hi Paolo and Radim,
On 2/1/19 10:47 AM, Singh, Brijesh wrote:
> svm.c is pretty huge, before we add more SEV specific commands (e.g SEV-ES,
> SEV-Migration etc) lets move the SEV command handling into a separate file.
> There is no logical changes in this series.
>
Any thoughts on this series
On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>
> Hi Anup,
>
> The code still does not use ASID in TLB flush routines. Without this
> added the code does not boot on systems with true ASID support.
Can you elaborate why flush by ASID is need and flush_tlb_all() will
not work?
>
> We also need
On Wed 2019-03-27 16:20:37, Sakari Ailus wrote:
> Hi Petr,
>
> On Wed, Mar 27, 2019 at 01:26:25PM +0100, Petr Mladek wrote:
> > On Tue 2019-03-26 14:41:01, Sakari Ailus wrote:
> > > Add two convenience functions for accessing node's parents:
> > >
> > > fwnode_count_parents() returns the number
Em Wed, Mar 27, 2019 at 03:53:30PM -0400, Liang, Kan escreveu:
> On 3/18/2019 4:53 AM, Jiri Olsa wrote:
> > On Fri, Mar 15, 2019 at 11:00:14AM -0700, kan.li...@linux.intel.com wrote:
> > > From: Kan Liang
> > > Signed-off-by: Kan Liang
> > > Cc: Thomas Richter
> > > Cc: sta...@vger.kernel.org
>
On Thu, Mar 28, 2019 at 04:00:39PM +0200, Andy Shevchenko wrote:
> If it's _non-standard_ serial interface (by meaning of I/O accessors and port
> addresses), user may consider to use this options in case the interface to
> communicate with kernel is serial one and its configuration is done by
On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>
> Hi Anup,
>
> The code still does not use ASID in TLB flush routines. Without this
> added the code does not boot on systems with true ASID support.
>
> We also need to consider the case of CONTEXTID overflow on 32-bit
> systems. 32-bit CONTEXTID
On Wed, Mar 27, 2019 at 11:52 PM Greg KH wrote:
>
> On Wed, Mar 27, 2019 at 12:01:50PM -0700, Patrick Venture wrote:
> > On Wed, Mar 27, 2019 at 11:54 AM Greg KH wrote:
> > >
> > > On Wed, Mar 27, 2019 at 11:44:36AM -0700, Patrick Venture wrote:
> > > > On Wed, Mar 27, 2019 at 11:28 AM Greg KH
Hello,
arch/x86/include/asm/bitops.h defines clear_bit(nr, addr) for
non-constant |nr| values as follows:
void clear_bit(long nr, volatile unsigned long *addr) {
asm volatile("lock; btr %1,%0"
: "+m"(*(volatile long *)addr)
: "Ir" (nr));
}
On 3/28/19 6:19 AM, raymond pang wrote:
> When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for
> a stack virtual address. Stack DMA buffers must be avoided.
Thanks, applied.
--
Jens Axboe
The "result" variable isn't initialized on this error path.
Fixes: 55e331cf7ebe ("drivers: add support for the TI VLYNQ bus")
Signed-off-by: Dan Carpenter
---
drivers/vlynq/vlynq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vlynq/vlynq.c
On Thu, Mar 28, 2019 at 03:05:08PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:52:26PM +0200, Andy Shevchenko wrote:
> > It's not a generic serial_in()...
>
> Why?
By name and by what it's handling (only byte accesses to I/O or MMIO).
> > What about mmio32 as next step?
>
> Next
On Thu, Mar 07, 2019 at 08:56:32AM -0800, Greg Thelen wrote:
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3880,6 +3880,7 @@ struct wb_domain *mem_cgroup_wb_domain(struct
> bdi_writeback *wb)
> * @pheadroom: out parameter for number of allocatable pages according to
> memcg
> *
On Thursday, March 03/28/19, 2019 at 18:10:37 +0530, Jason Gunthorpe wrote:
> On Wed, Mar 27, 2019 at 07:08:54PM +0530, Potnuri Bharat Teja wrote:
> > On Saturday, March 03/23/19, 2019 at 08:07:46 +0530, Kangjie Lu wrote:
> > >
> > >
> > > > On Mar 8, 2019, at 11:19 PM, Kangjie Lu wrote:
> > >
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 to 0x8000 0600 .
For this vmemmap has to be disabled.
Cc: Daniel Axtens
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Kconfig.debug| 3 +-
On Thu, Mar 28, 2019 at 03:03:29PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:50:15PM +0200, Andy Shevchenko wrote:
> > Can, but with code uglifying to workaround kstrtox() restrictions.
> > simple_strtox() _just works_ as expected.
>
> simple_strtox() also has its problems.
Yes!
On Thu, Mar 28, 2019 at 07:50:23PM +0530, Potnuri Bharat Teja wrote:
> On Thursday, March 03/28/19, 2019 at 18:10:37 +0530, Jason Gunthorpe wrote:
> > On Wed, Mar 27, 2019 at 07:08:54PM +0530, Potnuri Bharat Teja wrote:
> > > On Saturday, March 03/23/19, 2019 at 08:07:46 +0530, Kangjie Lu wrote:
>
On 03/27, Joel Fernandes wrote:
>
> Also, based on Kees comment, I think it appears to me that get_pid and
> put_pid can race in this way in the original code right?
>
> get_pid put_pid
>
> atomic_dec_and_test returns 1
> atomic_inc
>
On Thu, Mar 28, 2019 at 03:13:07PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 04:00:39PM +0200, Andy Shevchenko wrote:
> > If it's _non-standard_ serial interface (by meaning of I/O accessors and
> > port
> > addresses), user may consider to use this options in case the interface to
On Tue 2019-03-26 15:24:50, Andy Shevchenko wrote:
> On Tue, Mar 26, 2019 at 02:11:35PM +0100, Rasmus Villemoes wrote:
> > On 26/03/2019 13.41, Sakari Ailus wrote:
> > > Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> > > support printing full path of the node,
On 28/03/2019 14:09, Anup Patel wrote:
> On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>>
>> Hi Anup,
>>
>> The code still does not use ASID in TLB flush routines. Without this
>> added the code does not boot on systems with true ASID support.
>
> Can you elaborate why flush by ASID is need
On 3/28/2019 7:47 PM, Dan Carpenter wrote:
The "result" variable isn't initialized on this error path.
Fixes: 55e331cf7ebe ("drivers: add support for the TI VLYNQ bus")
Signed-off-by: Dan Carpenter
Reviewed-by: Mukesh Ojha
-Mukesh
---
drivers/vlynq/vlynq.c | 3 ++-
1 file changed, 2
On 28/03/2019 14:13, Anup Patel wrote:
> On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>>
>> Hi Anup,
>>
>> The code still does not use ASID in TLB flush routines. Without this
>> added the code does not boot on systems with true ASID support.
>>
>> We also need to consider the case of
On Thu, Mar 28, 2019 at 04:20:01PM +0200, Andy Shevchenko wrote:
> By name and by what it's handling (only byte accesses to I/O or MMIO).
Your series does only byte accesses so you can use byte variant.
> My point is, that doing branch(es) on each I/O call is not good as simple
> calling the
On Thu, Mar 28, 2019 at 04:23:02PM +0200, Andy Shevchenko wrote:
> If it's strong opinion, I consider this rather as NAK.
> Thank you for review.
Your call.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed 2019-03-27 16:10:48, Sakari Ailus wrote:
> Hi Petr,
>
> On Tue, Mar 26, 2019 at 04:13:07PM +0100, Petr Mladek wrote:
> > On Fri 2019-03-22 17:29:30, Sakari Ailus wrote:
> > > Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> > > support printing full path of the
On 3/28/2019 7:46 PM, Bo YU wrote:
When compiling with check flag: make -C tools/bpf/bpftool/
gcc will warning:
jit_disasm.c:119:29: warning: assignment discards ‘const’ qualifier
from pointer target type [-Wdiscarded-qualifiers]
info.disassembler_options = disassembler_options;
So
On Thu, Mar 28, 2019 at 03:57:44AM +0100, Jann Horn wrote:
> On Thu, Mar 28, 2019 at 3:34 AM Joel Fernandes wrote:
> > On Thu, Mar 28, 2019 at 01:59:45AM +0100, Jann Horn wrote:
> > > On Thu, Mar 28, 2019 at 1:06 AM Kees Cook wrote:
> > > > On Wed, Mar 27, 2019 at 7:53 AM Joel Fernandes (Google)
We forgot to set "err" on this error path.
Fixes: 9e543e22e204 ("irqchip: Add driver for Loongson-1 interrupt controller")
Signed-off-by: Dan Carpenter
---
drivers/irqchip/irq-ls1x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-ls1x.c b/drivers/irqchip/irq-ls1x.c
On Thu, Mar 28, 2019 at 03:26:19PM +0100, Oleg Nesterov wrote:
> On 03/27, Joel Fernandes wrote:
> >
> > Also, based on Kees comment, I think it appears to me that get_pid and
> > put_pid can race in this way in the original code right?
> >
> > get_pid put_pid
> >
> >
On 3/28/2019 7:07 PM, Thomas Bogendoerfer wrote:
smatch complaint:
arch/mips/sgi-ip27/ip27-irq.c:123 shutdown_bridge_irq()
warn: variable dereferenced before check 'hd' (see line 121)
Fix it by removing local variable and use hd->pin directly.
Fixes: 69a07a41d908 ("MIPS: SGI-IP27:
On Wed, Mar 27, 2019 at 11:43:20PM +, David Howells wrote:
> +static void binderfs_free_fc(struct fs_context *fc)
> +{
> + struct binderfs_info *info = fc->s_fs_info;
> +
> + if (info) {
> + struct ipc_namespace *ipc_ns = fc->s_fs_info;
> + put_ipc_ns(ipc_ns);
On Thu, Mar 28, 2019 at 03:35:35PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 04:23:02PM +0200, Andy Shevchenko wrote:
> > If it's strong opinion, I consider this rather as NAK.
> > Thank you for review.
>
> Your call.
Yes, as I said I won't uglify code to pursue kstrtox() whim.
On Thu, Mar 28, 2019 at 03:34:47PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 04:20:01PM +0200, Andy Shevchenko wrote:
> > By name and by what it's handling (only byte accesses to I/O or MMIO).
>
> Your series does only byte accesses so you can use byte variant.
>
> > My point is,
On Thu, Mar 28, 2019 at 12:13 PM Sakari Ailus
wrote:
>
> Hi Rafael,
>
> On Thu, Mar 28, 2019 at 10:38:01AM +0100, Rafael J. Wysocki wrote:
> > On Wed, Mar 27, 2019 at 3:20 PM Sakari Ailus
> > wrote:
> > >
> > > Hi Petr,
> > >
> > > On Wed, Mar 27, 2019 at 01:26:25PM +0100, Petr Mladek wrote:
> >
On Thu, 2019-03-28 at 06:38 -0700, Angus Ainslie (Purism) wrote:
> Fix a typo in the compatible string
>
> Signed-off-by: Angus Ainslie (Purism)
Reviwed-by: Daniel Baluta
On Wed, Mar 27, 2019 at 11:21:58AM -0700, Matthew Wilcox wrote:
> On Wed, Mar 27, 2019 at 05:29:57PM +, Catalin Marinas wrote:
> > On Wed, Mar 27, 2019 at 09:44:32AM +0100, Michal Hocko wrote:
> > > As long as there is an implicit __GFP_NOFAIL then kmemleak is simply
> > > broken no matter
On 3/28/2019 6:43 PM, Geert Uytterhoeven wrote:
gpiochip_free_hogs() was always called from gpiochip_remove(), not
of_gpiochip_remove(). It is now also called from the failure patch in
gpiochip_add_data_with_key().
Fixes: f625d4601759f1cf ("gpio: add GPIO hogging mechanism")
Signed-off-by:
On Wed, Mar 27, 2019 at 02:02:27PM -0400, Qian Cai wrote:
> On 3/27/19 1:29 PM, Catalin Marinas wrote:
> > From dc4194539f8191bb754901cea74c86e7960886f8 Mon Sep 17 00:00:00 2001
> > From: Catalin Marinas
> > Date: Wed, 27 Mar 2019 17:20:57 +
> > Subject: [PATCH] mm: kmemleak: Add an emergency
On Wed, Mar 13, 2019 at 04:42:15PM +0800, ryder@kernel.org wrote:
> From: Ryder Lee
>
> This adds basic support for MT7629 reference board.
>
> Signed-off-by: Ryder Lee
> ---
> Changes since v1:
> -Fix unit-address warnings.
> -Put all the mmio peripherals under a simple-bus node.
> -Drop
Greetings,
We are consultancy firm situated in Bahrain currently looking to finance new or
existing projects in any industry.
Currently we are sourcing for investment opportunities for our review and
consideration and we provide financial and strategic advisory services to
growing companies
On Wed, Mar 27, 2019 at 05:38:46PM -0400, Joel Fernandes wrote:
> On Wed, Mar 27, 2019 at 11:44:37AM -0700, Paul E. McKenney wrote:
> > On Wed, Mar 27, 2019 at 01:45:45PM -0400, Joel Fernandes wrote:
> > > On Wed, Mar 27, 2019 at 08:53:51AM -0700, Paul E. McKenney wrote:
> > > > On Wed, Mar 27,
On 28.03.19 14:43, Oscar Salvador wrote:
> Hi,
>
> since last two RFCs were almost unnoticed (thanks David for the feedback),
> I decided to re-work some parts to make it more simple and give it a more
> testing, and drop the RFC, to see if it gets more attention.
> I also added David's feedback,
On Wed, Mar 13, 2019 at 11:00:07AM +0200, Georgi Djakov wrote:
> In addition to frequency and voltage, some devices may have bandwidth
> requirements for their interconnect throughput - for example a CPU
> or GPU may also need to increase or decrease their bandwidth to DDR
> memory based on the
On Sat, Mar 16, 2019 at 12:32:49AM +0530, Sibi Sankar wrote:
>
>
> On 3/13/19 2:30 PM, Georgi Djakov wrote:
> > Here is a proposal to extend the OPP bindings with bandwidth based on
> > a previous discussion [1].
> >
> > Every functional block on a SoC can contribute to the system power
> >
The next patch will introduce another approach to compute the next
interrupt based on the array suffixes derived algorithm. This one
will replace the variance computation code.
The patch review will be too complex if we change the code little by
little, it is much simpler to remove the variance
The previous approach based on the variance was discarding values from
the timings when they were considered as anomalies as stated by the
normal law statistical model.
However in the interrupt life, there can be multiple anomalies due to
the nature of the device generating the interrupts, and
On Thu, Mar 28, 2019 at 3:41 PM Angus Ainslie (Purism) wrote:
>
> The imx8mq needs to be specified to check the clk ratio.
>
> Signed-off-by: Angus Ainslie (Purism)
> ---
> Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
Since we're just talking about RCU stuff now, adding Paul McKenney to
the thread.
On Thu, Mar 28, 2019 at 3:37 PM Joel Fernandes wrote:
> On Thu, Mar 28, 2019 at 03:57:44AM +0100, Jann Horn wrote:
> > On Thu, Mar 28, 2019 at 3:34 AM Joel Fernandes
> > wrote:
> > > On Thu, Mar 28, 2019 at
On Wed, 13 Mar 2019 15:10:30 +0100, Neil Armstrong wrote:
> The Amlogic G12A has a slighly different Power Control, but uses the
> same address space and sysctrl registers.
>
> Signed-off-by: Neil Armstrong
> ---
> .../devicetree/bindings/power/amlogic,meson-gx-pwrc.txt | 4 +++-
> 1 file
On Wed, 13 Mar 2019 15:20:40 +0100, Christina Quast wrote:
> In the iMX7d datasheet, the PAD_CTL_DSE_X* values are different from
> the documentation.
>
> Changes since v2:
> * Changed patch title to 'dt-bindings: pinctrl: imx7d:'
>
> Signed-off-by: Christina Quast
> ---
>
Hi,
First, thanks for taking a look at this.
On 3/28/19 5:04 AM, Rafael J. Wysocki wrote:
On Tue, Mar 26, 2019 at 11:40 PM Jeremy Linton wrote:
ACPI 6.3 adds a flag to indicate that child nodes are all
identical cores. This is useful to authoritatively determine
if a set of (possibly
Most architectures current have a debugfs file for dumping the kernel
page tables. Currently each architecture has to implement custom
functions for walking the page tables because the generic
walk_page_range() function is unable to walk the page tables used by the
kernel.
This series extends the
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_large() functions/macros.
For arm64, we already have p?d_sect() macros which
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_large() functions/macros.
For mips, we only support large pages on 64 bit.
For 64
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_large() functions/macros.
For riscv a page is large when it has a read, write or
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_large() functions/macros.
For s390, pud_large() and pmd_large() are already
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_large() functions/macros.
For x86 we already have static inline functions, so
Exposing the pud/pgd levels of the page tables to walk_page_range() means
we may come across the exotic large mappings that come with large areas
of contiguous memory (such as the kernel's linear map).
For architectures that don't provide p?d_large() macros, provide generic
does nothing defaults.
For the /sys/kernel/debug/page_tables/ files, rather than outputing a
mostly empty line when a block of memory isn't present just skip the
line. This keeps the output shorter and will help with a future change
switching to using the generic page walk code as we no longer care about
the 'level'
Now walk_page_range() can walk kernel page tables, we can switch the
arm64 ptdump code over to using it, simplifying the code.
Signed-off-by: Steven Price
---
arch/arm64/mm/dump.c | 117 ++-
1 file changed, 59 insertions(+), 58 deletions(-)
diff --git
pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were
no users. We're about to add users so reintroduce them, along with
p4d_entry() as we now have 5 levels of tables.
Note that commit a00cc7d9dd93d66a ("mm, x86:
It is useful to be able to skip parts of the page table tree even when
walking without VMAs. Add test_p?d callbacks similar to test_walk but
which are called just before a table at that level is walked. If the
callback returns non-zero then the entire table is skipped.
Signed-off-by: Steven Price
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct.
This means that ptdump_walk_pgd_level_core() is now always passed a
valid pgd, so drop the support for pgd==NULL.
Signed-off-by: Steven Price
---
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level() need to pass an mm_struct rather
than the raw pgd_t pointer. Luckily since commit 7e904a91bf60
("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct
for EFI on x86.
Signed-off-by:
mm/dump_pagetables.c passes both struct seq_file and struct pg_state
down the chain of walk_*_level() functions to be passed to note_page().
Instead place the struct seq_file in struct pg_state and access it from
struct pg_state (which is private to this file) in note_page().
Signed-off-by:
Make use of the new functionality in walk_page_range to remove the
arch page walking code and use the generic code to walk the page tables.
The effective permissions are passed down the chain using new fields
in struct pg_state.
The KASAN optimisation is implemented by including test_p?d
An mm_struct is needed to enable x86 to use of the generic
walk_page_range() function.
In the case of walking the user page tables (when
CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a
fake_mm structure because there isn't an mm_struct with a pointer
to the pgd of the user
Since 48684a65b4e3: "mm: pagewalk: fix misbehavior of walk_page_range
for vma(VM_PFNMAP)", page_table_walk() will report any kernel area as
a hole, because it lacks a vma.
This means each arch has re-implemented page table walking when needed,
for example in the per-arch ptdump walker.
Remove
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_large() functions/macros.
For sparc 64 bit, pmd_large() and pud_large() are already
On 3/28/19 8:43 AM, Pierre Morel wrote:
On 26/03/2019 19:57, Tony Krowiak wrote:
On 3/22/19 10:43 AM, Pierre Morel wrote:
We prepare the interception of the PQAP/AQIC instruction for
the case the AQIC facility is enabled in the guest.
...snip...
+/*
+ * handle_pqap: Handling pqap
On Thu, 2019-03-28 at 14:59 +, Catalin Marinas wrote: 2
> +/* minimum memory pool sizes */
> +#define MIN_OBJECT_POOL (NR_CPUS * 4)
> +#define MIN_SCAN_AREA_POOL (NR_CPUS * 1)
I am thinking about making those are tunable, so people could have a big pool
depends on
From: Saravana Kannan
Many CPU architectures have caches that can scale independent of the
CPUs. Frequency scaling of the caches is necessary to make sure the cache
is not a performance bottleneck that leads to poor performance and
power. The same idea applies for RAM/DDR.
To achieve this, this
201 - 300 of 681 matches
Mail list logo
