Adds device tree binding documentation for clocks in the
MT7621 SOC.
Signed-off-by: Sergio Paracuellos
---
.../bindings/clock/mediatek,mt7621-clk.yaml | 66 +++
1 file changed, 66 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/mediatek,mt7621-clk.yam
The documentation for this SOC only talks about two
registers regarding to the clocks:
* SYSC_REG_CPLL_CLKCFG0 - provides some information about
boostrapped refclock. PLL and dividers used for CPU and some
sort of BUS.
* SYSC_REG_CPLL_CLKCFG1 - a banch of gates to enable/disable
clocks for all or s
Vendor listed for mediatek in kernel vendor file 'vendor-prefixes.yaml'
contains 'mediatek' as a valid vendor string. Some nodes in the device
tree are using an invalid vendor string vfor 'mtk' instead. Fix all of
them in dts file. Update also ralink mt7621 related code to properly
match new string
Hi Finn,
On 2021/2/9 13:06, Finn Thain wrote:
On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote:
-Original Message-
From: Finn Thain [mailto:fth...@telegraphics.com.au]
Sent: Monday, February 8, 2021 8:57 PM
To: tanxiaofei
Cc: j...@linux.ibm.com; martin.peter...@oracle.com;
linux-s.
Fix the following sparse warning:
drivers/soc/mediatek/mtk-mutex.c:464:24: warning: symbol 'mtk_mutex_driver' was
not declared. Should it be static?
Signed-off-by: Zou Wei
---
drivers/soc/mediatek/mtk-mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/media
On Wed, Feb 17, 2021 at 12:13:37PM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 17, 2021 at 01:31:36PM +0200, Eli Cohen wrote:
> > Allow to control vdpa device creation and destruction using the vdpa
> > management tool.
> >
> > Examples:
> > 1. List the management devices
> > $ vdpa mgmtdev sho
On 16-02-21, 15:10, Jonathan Marek wrote:
> There is not "nothing to do" when the opp is the same. The frequency can
> be different from opp->rate.
>
> Fixes: 81c4d8a3c414 ("opp: Keep track of currently programmed OPP")
> Signed-off-by: Jonathan Marek
> ---
> drivers/opp/core.c | 7 +--
> dr
On Wed, Feb 17, 2021 at 11:21:22PM +0100, Michael Walle wrote:
> Am 2021-02-17 22:50, schrieb Marc Zyngier:
> > On Wed, 17 Feb 2021 20:10:50 +,
> > Michael Walle wrote:
> > >
> > > Am 2021-02-17 21:02, schrieb Marc Zyngier:
> > > > On 2021-02-17 19:57, Michael Walle wrote:
> > > >> Hi Greg,
>
On Wed, Feb 17, 2021 at 04:20:14PM -0500, Michael S. Tsirkin wrote:
> On Wed, Feb 17, 2021 at 11:42:48AM -0800, Si-Wei Liu wrote:
> >
> >
> > On 2/16/2021 8:20 AM, Eli Cohen wrote:
> > > When we suspend the VM, the VDPA interface will be reset. When the VM is
> > > resumed again, clear_virtqueues
On Thu, Feb 18, 2021 at 11:58:40AM +0530, Atul Gopinathan wrote:
> Resolve the following sparse warning:
> drivers/staging//comedi/comedi_fops.c:2983:41: warning: incorrect type in
> argument 1 (different address spaces)
> drivers/staging//comedi/comedi_fops.c:2983:41:expected void [noderef]
Fix the following coccicheck warnings:
./drivers/net/wireless/intel/iwlegacy/4965-mac.c:2596:54-56: WARNING !A
|| A && B is equivalent to !A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 3 +--
1 file changed, 1 insertion(+), 2
On Thu, Feb 11, 2021 at 6:13 AM Rob Herring wrote:
>
> On Sun, Feb 07, 2021 at 06:23:51PM +0800, Shengjiu Wang wrote:
> > fsl_rpmsg cpu dai driver is driver for rpmsg audio, which is mainly used
> > for getting the user's configuration from device tree and configure the
> > clocks which is used by
On 17-02-21, 11:57, Ionela Voinescu wrote:
> See a very useful comment someone added recently :) :
>
> """
> + /*
> + * We don't need to handle CPUFREQ_REMOVE_POLICY event as the AMU
> + * counters don't have any dependency on cpufreq driver once we have
> + * initialized AMU su
On Thu, Feb 11, 2021 at 6:18 AM Rob Herring wrote:
>
> On Sun, Feb 07, 2021 at 06:23:55PM +0800, Shengjiu Wang wrote:
> > Imx-rpmsg is a new added machine driver for supporting audio on Cortex-M
> > core. The Cortex-M core will control the audio interface, DMA and audio
> > codec, setup the pipeli
Adding myself as maintainer for mt7621 clock driver.
Signed-off-by: Sergio Paracuellos
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 809a68af5efd..be5ada6b4309 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11288,6 +11288,12 @@ L: l
On Fri, Feb 12, 2021 at 01:08:39PM +, Joao Martins wrote:
> Hey,
>
> This series improves page unpinning, with an eye on improving MR
> deregistration for big swaths of memory (which is bound by the page
> unpining), particularly:
Can you also take a look at the (bdev and iomap) direct I/O co
On Wed, Feb 17, 2021 at 01:14:42PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 16.02.21 um 16:57 schrieb Sakari Ailus:
> > Hi all,
> >
> > On merging --- it would seem everyone is happy with merging this
> > through the drm-misc tree. The last patch should wait until all
> > users are
-20210218 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin
On 01/30/21 at 03:10pm, Chen Zhou wrote:
> We make the functions reserve_crashkernel[_low]() as generic for
> x86 and arm64. Since reserve_crashkernel[_low]() implementations
> are quite similar on other architectures as well, we can have more
> users of this later.
>
> So have CONFIG_ARCH_WANT_RE
On Wed, Feb 17, 2021 at 09:50:38PM +, Marc Zyngier wrote:
> On Wed, 17 Feb 2021 20:10:50 +,
> Michael Walle wrote:
> >
> > Am 2021-02-17 21:02, schrieb Marc Zyngier:
> > > On 2021-02-17 19:57, Michael Walle wrote:
> > >> Hi Greg,
> > >>
> > >>> There's no need to keep around a dentry poi
On Wed, Feb 17, 2021 at 05:50:35PM -0700, Andreas Dilger wrote:
> On Feb 17, 2021, at 1:08 AM, Amir Goldstein wrote:
> >
> > You are missing my point.
> > Never mind which server. The server does not *need* to rely on
> > vfs_copy_file_range() to copy files from XFS to ext4.
> > The server is ver
> -Original Message-
> From: Mike Ximing Chen
> Sent: Wednesday, February 10, 2021 12:54 PM
> To: net...@vger.kernel.org
> Cc: da...@davemloft.net; k...@kernel.org; a...@arndb.de;
> gre...@linuxfoundation.org; Williams, Dan J ;
> pierre-
> louis.boss...@linux.intel.com; Gage Eads
> Su
Fix the following coccicheck warning:
./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8142:16-21: WARNING:
conversion to bool not needed here
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+), 2 dele
The sys2_pll_50m should be one of the clock sels of PCIE_AUX clock,
Change the sys2_pll_500m to sys2_pll_50m.
Signed-off-by: Richard Zhu
---
drivers/clk/imx/clk-imx8mq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.
On 02/18/21 at 03:31pm, Baoquan He wrote:
> On 01/30/21 at 03:10pm, Chen Zhou wrote:
> > We make the functions reserve_crashkernel[_low]() as generic for
> > x86 and arm64. Since reserve_crashkernel[_low]() implementations
> > are quite similar on other architectures as well, we can have more
> > u
Allow to control vdpa device creation and destruction using the vdpa
management tool.
Examples:
1. List the management devices
$ vdpa mgmtdev show
pci/:3b:00.1:
supported_classes net
2. Create vdpa instance
$ vdpa dev add mgmtdev pci/:3b:00.1 name vdpa0
3. Show vdpa devices
$ vdpa dev
Looks good:
Reviewed-by: Christoph Hellwig
This whole idea of cross-device copie has always been a horrible idea,
and I've been arguing against it since the patches were posted.
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of sync.
We can avoid this function alltogether since qemu will clear them if
required, e.g. whe
On Wed, Feb 17, 2021 at 05:26:54PM +, Luis Henriques wrote:
> A regression has been reported by Nicolas Boichat, found while using the
> copy_file_range syscall to copy a tracefs file. Before commit
> 5dae222a5ff0 ("vfs: allow copy_file_range to copy across devices") the
> kernel would return
On Wed, Feb 17, 2021 at 11:48:21AM -0800, Scott Branden wrote:
> Hi Greg,
>
> On 2021-02-17 1:40 a.m., Greg Kroah-Hartman wrote:
> > On Tue, Jan 26, 2021 at 07:51:18PM +0100, Greg Kroah-Hartman wrote:
> >> On Tue, Jan 26, 2021 at 10:30:16AM -0800, Scott Branden wrote:
> >>> Hi Greg,
> >>>
> >>>
>
Hi Mike
On 2/16/21 9:00 AM, Mike Leach wrote:
Hi Anshuman,
There have been plenty of detailed comments so I will restrict mine to
a few general issues:-
1) Currently there appears to be no sysfs support (I cannot see the
MODE_SYSFS constants running alongside the MODE_PERF ones present in
the
On Thu, Feb 18, 2021 at 07:34:31AM +, Chen, Mike Ximing wrote:
>
>
> > -Original Message-
> > From: Mike Ximing Chen
> > Sent: Wednesday, February 10, 2021 12:54 PM
> > To: net...@vger.kernel.org
> > Cc: da...@davemloft.net; k...@kernel.org; a...@arndb.de;
> > gre...@linuxfoundation.
Hello Suren,
>> Thanks. I added a few words to clarify this.>
> Any link where I can see the final version?
Sure:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man2/process_madvise.2
Also rendered below.
Thanks,
Michael
NAME
process_madvise - give advice about use of
Hi Andrey,
On Thu, Feb 18, 2021 at 01:11:32AM +0300, Andrey Konovalov wrote:
> Print a warning if V4L2_CID_LINK_FREQ control is not implemented.
>
> Signed-off-by: Andrey Konovalov
> ---
> drivers/media/v4l2-core/v4l2-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/me
Hi Dmitry,
On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti wrote:
Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit :
On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti wrote:
Hi Dmitry,
Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit :
On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov wrote:
On Fri, Jan 29,
On Wed, Feb 10, 2021 at 11:39 PM Mark Brown wrote:
>
> On Wed, Feb 10, 2021 at 02:35:29PM +0800, Shengjiu Wang wrote:
> > On Wed, Feb 10, 2021 at 6:30 AM Mark Brown wrote:
>
> > > Like I say I'd actually recommend moving this control to DAPM.
>
> > I may understand your point, you suggest to use
On Wed, Feb 17, 2021 at 08:16:29AM +0100, Christoph Hellwig wrote:
> On Wed, Feb 17, 2021 at 11:07:14AM +0800, Ming Lei wrote:
> > Do you think it is correct for ioctl(BLKRRPART) to always drop/re-add
> > partition device node?
>
> Yes, that is what it is designed to do. The only reason to call t
Hi,
On Fri, Feb 12, 2021 at 02:57:25PM +0100, Tobias Schramm wrote:
> Previously the variable rate audio pll output was fixed to a divider of
> four. This is unfortunately incompatible with generating commonly used
> I2S core clock rates like 24.576MHz from the 24MHz parent clock.
> This commit ad
>
> + /* for pre_req */
> + hpb->pre_req_min_tr_len = HPB_MULTI_CHUNK_LOW;
This actually needs to be bMAX_DATA_SIZE_FOR_HPB_SINGLE_CMD.
Also wasn't able to find any reference to fHPBen?
Thanks,
Avri
Hi
Am 17.02.21 um 13:32 schrieb Gerd Hoffmann:
Add helper functions to create and move the cursor.
Create the cursor_bo in prepare_fb callback, in the
atomic_commit callback we only send the update command
to the host.
I'm still trying to wrap my head around the qxl cursor code.
Getting vmap
于 2021年2月18日 GMT+08:00 下午3:58:35, Maxime Ripard 写到:
>Hi,
>
>On Fri, Feb 12, 2021 at 02:57:25PM +0100, Tobias Schramm wrote:
>> Previously the variable rate audio pll output was fixed to a divider
>of
>> four. This is unfortunately incompatible with generating commonly
>used
>> I2S core clock ra
Hi Andrey,
On Thu, Feb 18, 2021 at 01:11:33AM +0300, Andrey Konovalov wrote:
> There are places in the camss driver where camss_get_pixel_clock() is
> called to get the pixel rate (using V4L2_CID_PIXEL_RATE control) and to
> calculate the link frequency from it. There is a case when this would
> n
On Thu, Feb 18, 2021 at 4:06 PM Icenowy Zheng wrote:
>
>
>
> 于 2021年2月18日 GMT+08:00 下午3:58:35, Maxime Ripard 写到:
> >Hi,
> >
> >On Fri, Feb 12, 2021 at 02:57:25PM +0100, Tobias Schramm wrote:
> >> Previously the variable rate audio pll output was fixed to a divider
> >of
> >> four. This is unfortu
On Tue, Feb 09, 2021 at 02:16:46PM -0800, Nadav Amit wrote:
> +/*
> + * Flags to be used as scf_flags argument of smp_call_function_many_cond().
> + */
> +#define SCF_WAIT (1U << 0) /* Wait until function execution
> completed */
> +#define SCF_RUN_LOCAL(1U << 1) /* Run als
Sorry for previous mail. Please just ignore that.
> > + /* for pre_req */
> > + hpb->pre_req_min_tr_len = HPB_MULTI_CHUNK_LOW;
> This actually needs to be bMAX_DATA_SIZE_FOR_HPB_SINGLE_CMD.
OK,
> Also wasn't able to find any reference to fHPBen?
OK, I will
Thanks,
Daejun
Given that the last patch killed the last previously existing
user of on_each_cpu_cond_mask there are now the only users.
> if (info->freed_tables) {
> - smp_call_function_many(cpumask, flush_tlb_func,
> -(void *)info, 1);
> + on_each_cpu_c
On Tue, Feb 09, 2021 at 02:16:48PM -0800, Nadav Amit wrote:
> + /*
> + * Although we could have used on_each_cpu_cond_mask(),
> + * open-coding it has performance advantages, as it eliminates
> + * the need for indirect calls or retpolines. In addi
The logic for finding records to fit into a buffer is the same for
kmsg_dump_get_buffer() and syslog_print_all(). Introduce a helper
function find_first_fitting_seq() to handle this logic.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 87 --
1 fi
Hi Andrey,
On Thu, Feb 18, 2021 at 01:11:34AM +0300, Andrey Konovalov wrote:
> From: Vladimir Lypak
>
> Because of u32 type being used to store pixel clock rate, expression used
> to calculate pipeline clocks (pixel_clock * bpp) produces wrong value due
> to integer overflow. This patch changes d
Hello,
Here is v2 of a series to remove @logbuf_lock, exposing the
ringbuffer locklessly to both readers and writers. v1 is here [0].
Since @logbuf_lock was protecting much more than just the
ringbuffer, this series clarifies and cleans up the various
protections using comments, lockless accessor
The global variables @syslog_seq, @syslog_partial, @syslog_time
and write access to @clear_seq are protected by @logbuf_lock.
Once @logbuf_lock is removed, these variables will need their
own synchronization method. Introduce @syslog_lock for this
purpose.
@syslog_lock is a raw_spin_lock for now.
On Wed 17-02-21 13:32:05, Minchan Kim wrote:
> On Wed, Feb 17, 2021 at 09:16:12PM +, Matthew Wilcox wrote:
> > On Wed, Feb 17, 2021 at 12:46:19PM -0800, Minchan Kim wrote:
> > > > I suspect you do not want to add atomic_read inside hot paths, right? Is
> > > > this really something that we have
Instead of using "LOG_LINE_MAX + PREFIX_MAX" for temporary buffer
sizes, introduce CONSOLE_LOG_MAX. This represents the maximum size
that is allowed to be printed to the console for a single record.
Rather than setting CONSOLE_LOG_MAX to "LOG_LINE_MAX + PREFIX_MAX"
(1024), increase it to 4096. Wit
The kmsg_dumper can be called from any context and CPU, possibly
from multiple CPUs simultaneously. Since a static buffer is used
to retrieve the kernel logs, this buffer must be protected against
simultaneous dumping.
Cc: Richard Weinberger
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
-
kmsg_dump_get_buffer() requires nearly the same logic as
syslog_print_all(), but uses different variable names and
does not make use of the ringbuffer loop macros. Modify
kmsg_dump_get_buffer() so that the implementation is as similar
to syslog_print_all() as possible.
A follow-up commit will move
kmsg_dump_rewind_nolock() locklessly reads @clear_seq. However,
this is not done atomically. Since @clear_seq is 64-bit, this
cannot be an atomic operation for all platforms. Therefore, use
a seqcount_latch to allow readers to always read a consistent
value.
Signed-off-by: John Ogness
Reviewed-by
kmsg_dump_rewind() and kmsg_dump_get_line() are lockless, so there is
no need for _nolock() variants. Remove these functions and switch all
callers of the _nolock() variants.
The functions without _nolock() were chosen because they are already
exported to kernel modules.
Signed-off-by: John Ognes
Since the ringbuffer is lockless, there is no need for it to be
protected by @logbuf_lock. Remove @logbuf_lock.
This means that printk_nmi_direct and printk_safe_flush_on_panic()
no longer need to acquire any lock to run.
@console_seq, @exclusive_console_stop_seq, @console_dropped are
protected b
struct kmsg_dumper still contains some fields that were used to
iterate the old ringbuffer. They are no longer used. Remove them
and update the struct documentation.
Signed-off-by: John Ogness
---
include/linux/kmsg_dump.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/
Rather than store the iterator information into the registered
kmsg_dump structure, create a separate iterator structure. The
kmsg_dump_iter structure can reside on the stack of the caller,
thus allowing lockless use of the kmsg_dump functions.
This is in preparation for removal of @logbuf_lock.
The second loop of syslog_print_all() subtracts lengths that were
added in the first loop. With commit b031a684bfd0 ("printk: remove
logbuf_lock writer-protection of ringbuffer") it is possible that
records are (over)written during syslog_print_all(). This allows the
possibility of the second loop
@user->seq is indirectly protected by @logbuf_lock. Once @logbuf_lock
is removed, @user->seq will be no longer safe from an atomicity point
of view.
In preparation for the removal of @logbuf_lock, change it to
atomic64_t to provide this safety.
Signed-off-by: John Ogness
---
kernel/printk/print
Upon registering a console, safe buffers are activated when setting
up the sequence number to replay the log. However, these are already
protected by @console_sem and @syslog_lock. Remove the unnecessary
safe buffer usage.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 10 +++---
1
On Tue, Feb 16, 2021 at 3:46 PM Gwendal Grignou wrote:
>
> Reviewed-by: Gwendal Grignou
Looks fine to me as well.
Reviewed-by: Matt Ranostay
>
> On Mon, Feb 15, 2021 at 4:11 AM Jonathan Cameron wrote:
> >
> > On Mon, 15 Feb 2021 12:40:22 +0200
> > Alexandru Ardelean wrote:
> >
> > > All dri
On Wed, 17 Feb 2021, Benjamin Tissoires wrote:
> [sending those patches on behalf of Roderick]
>
> There is a current thread on LED LKML which basically means that
> we have to revert the LED class exposure until things are settled.
>
> I am sending here the full series that will end up in linux
Richard Guy Briggs wrote:
> On 2021-02-11 23:09, Florian Westphal wrote:
> > So, if just a summary is needed a single audit_log_nfcfg()
> > after 'step 3' and outside of the list_for_each_entry_safe() is all
> > that is needed.
>
> Ok, so it should not matter if it is before or after that
> list_
kmsg_dump() is open coding the kmsg_dump_rewind(). Call
kmsg_dump_rewind() instead.
Signed-off-by: John Ogness
---
kernel/printk/printk.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 744b806d5457..23d525e885e7 1006
On Thu 18-02-21 11:20:51, Muchun Song wrote:
> On Thu, Feb 18, 2021 at 9:00 AM Mike Kravetz wrote:
> >
> > On 2/17/21 12:13 AM, Michal Hocko wrote:
> > > On Tue 16-02-21 11:44:34, Mike Kravetz wrote:
> > > [...]
> > >> If we are not going to do the allocations under the lock, then we will
> > >>
On 01/30/21 at 03:10pm, Chen Zhou wrote:
> To make the functions reserve_crashkernel() as generic,
> replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX.
>
> Signed-off-by: Chen Zhou
> Tested-by: John Donnelly
> ---
> arch/x86/kernel/setup.c | 7 ---
> 1 file changed, 4 insertions
> On Feb 18, 2021, at 12:16 AM, Christoph Hellwig wrote:
>
> On Tue, Feb 09, 2021 at 02:16:48PM -0800, Nadav Amit wrote:
>> +/*
>> + * Although we could have used on_each_cpu_cond_mask(),
>> + * open-coding it has performance advantages, as it eliminates
>> +
On Thu, Feb 18, 2021 at 08:10:28AM +0100, Greg KH wrote:
> On Thu, Feb 18, 2021 at 11:58:40AM +0530, Atul Gopinathan wrote:
> > Resolve the following sparse warning:
> > drivers/staging//comedi/comedi_fops.c:2983:41: warning: incorrect type in
> > argument 1 (different address spaces)
> > drivers/
On 18.02.21 09:17, Michal Hocko wrote:
On Wed 17-02-21 13:32:05, Minchan Kim wrote:
On Wed, Feb 17, 2021 at 09:16:12PM +, Matthew Wilcox wrote:
On Wed, Feb 17, 2021 at 12:46:19PM -0800, Minchan Kim wrote:
I suspect you do not want to add atomic_read inside hot paths, right? Is
this really
On Wed 17-02-21 12:41:34, Tim Chen wrote:
> During soft limit memory reclaim, we will temporarily remove the target
> mem cgroup from the cgroup soft limit tree. We then perform memory
> reclaim, update the memory usage excess count and re-insert the mem
> cgroup back into the mem cgroup soft limi
Am 2021-02-18 08:31, schrieb Greg KH:
On Wed, Feb 17, 2021 at 09:50:38PM +, Marc Zyngier wrote:
On Wed, 17 Feb 2021 20:10:50 +,
Michael Walle wrote:
>
> Am 2021-02-17 21:02, schrieb Marc Zyngier:
> > On 2021-02-17 19:57, Michael Walle wrote:
> >> Hi Greg,
> >>
> >>> There's no need to k
On Thu, Feb 18, 2021 at 08:24:23AM +, Nadav Amit wrote:
> In general, thanks for the feedback (I will reply after I follow your
> feedback). I do have a general question - I thought it was decided that
> clarity should be preferred over following the 80-column limit. Please let
> me know if I m
On Fri, 12 Feb 2021, Lyude Paul wrote:
> I think it wouldn't be a bad idea to just address this with a followup series
> instead and use the old DRM_DEBUG_* macros in the mean time.
aux->dev is there, could also use dev_dbg et al. in the mean time. They
handle NULL dev gracefully too if the drive
Am 2021-02-18 09:40, schrieb Greg KH:
On Wed, Feb 17, 2021 at 08:57:17PM +0100, Michael Walle wrote:
Hi Greg,
> There's no need to keep around a dentry pointer to a simple file that
> debugfs itself can look up when we need to remove it from the system.
> So simplify the code by deleting the va
On Thu, Feb 18, 2021 at 02:03:07PM +0900, Masami Hiramatsu wrote:
> On Wed, 17 Feb 2021 10:17:38 -0800
> "Paul E. McKenney" wrote:
>
> > > > 1. Spawn ksoftirqd earlier.
> > > >
> > > > 2. Suppress attempts to awaken ksoftirqd before it exists,
> > > > forcing all ksoftirq execu
On 17-02-21, 10:32, Thara Gopinath wrote:
> First of all, I am still unable to find this setting in the sysfs space.
The driver needs to call cpufreq_enable_boost_support() for that.
> Irrespective the ideal behavior here will be to change the cpufreq cooling
> dev max state when this happens.
H
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f40ddce88593482919761f74910f42f4b84c004b
commit: 72cdab808714b1ec24b0c7bdebed163ce791f01f ath9k: Do not select
MAC80211_LEDS by default
date: 6 months ago
config: parisc-randconfig-r002-20210218 (attached
Hi Maxime,
It's not really clear to me how that would help.
The closest frequency we can provide for 24.576MHz would be 24580645 Hz,
with N = 127, M = 31 and P = 4, so it would work with what we have
already?
As far as I'm aware the multiplier N ranges from 0 to 128 (offset of 1
from 0 to 1
In the i.MX8MP PCIe design, the PCIe PHY REF clock comes from external
OSC or internal system PLL. It is configured in the IOMUX_GPR14 register
directly, and can't be contolled by CCM at all.
Remove the PCIE PHY clock from clock driver to clean up codes.
There is only one PCIe in i.MX8MP, remove th
[PATCH v2] clk: imx8mp: Remove the none exist pcie clocks
Resolve the following sparse warning:
drivers/staging//comedi/comedi_fops.c:2983:41: warning: incorrect type in
argument 1 (different address spaces)
drivers/staging//comedi/comedi_fops.c:2983:41:expected void [noderef]
*uptr
drivers/staging//comedi/comedi_fops.c:2983:41:got unsigned in
Hi Maxime,
It's not really clear to me how that would help.
The closest frequency we can provide for 24.576MHz would be 24580645 Hz,
with N = 127, M = 31 and P = 4, so it would work with what we have
already?
As far as I'm aware the multiplier N ranges from 0 to 128 (offset of 1
That shoul
On Thu, Feb 18, 2021 at 08:47:15AM +, Marc Zyngier wrote:
> On 2021-02-18 08:38, Greg KH wrote:
> > On Thu, Feb 18, 2021 at 09:27:09AM +0100, Michael Walle wrote:
> > > Am 2021-02-18 08:31, schrieb Greg KH:
> > > > On Wed, Feb 17, 2021 at 09:50:38PM +, Marc Zyngier wrote:
> > > > > On Wed,
Fix the following warning generated by sparse:
drivers/staging//comedi/comedi_fops.c:2956:23: warning: incorrect type in
assignment (different address spaces)
drivers/staging//comedi/comedi_fops.c:2956:23:expected unsigned int
*chanlist
drivers/staging//comedi/comedi_fops.c:2956:23:got v
On Thu, Feb 18, 2021 at 09:27:09AM +0100, Michael Walle wrote:
> Am 2021-02-18 08:31, schrieb Greg KH:
> > On Wed, Feb 17, 2021 at 09:50:38PM +, Marc Zyngier wrote:
> > > On Wed, 17 Feb 2021 20:10:50 +,
> > > Michael Walle wrote:
> > > >
> > > > Am 2021-02-17 21:02, schrieb Marc Zyngier:
>
On Thu, Feb 18, 2021 at 09:27:09AM +0100, Michael Walle wrote:
> Am 2021-02-18 08:31, schrieb Greg KH:
> > On Wed, Feb 17, 2021 at 09:50:38PM +, Marc Zyngier wrote:
> > > On Wed, 17 Feb 2021 20:10:50 +,
> > > Michael Walle wrote:
> > > >
> > > > Am 2021-02-17 21:02, schrieb Marc Zyngier:
>
On 01/30/21 at 03:10pm, Chen Zhou wrote:
> We make the functions reserve_crashkernel[_low]() as generic for
> x86 and arm64. Since reserve_crashkernel[_low]() implementations
> are quite similar on other architectures as well, we can have more
> users of this later.
>
> So have CONFIG_ARCH_WANT_RE
On Thu, Feb 18, 2021 at 03:20:14PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./drivers/net/wireless/intel/iwlegacy/4965-mac.c:2596:54-56: WARNING !A
> || A && B is equivalent to !A || B.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/
On Wed, Feb 17, 2021 at 08:57:17PM +0100, Michael Walle wrote:
> Hi Greg,
>
> > There's no need to keep around a dentry pointer to a simple file that
> > debugfs itself can look up when we need to remove it from the system.
> > So simplify the code by deleting the variable and cleaning up the logi
On 2021-02-18 08:38, Greg KH wrote:
On Thu, Feb 18, 2021 at 09:27:09AM +0100, Michael Walle wrote:
Am 2021-02-18 08:31, schrieb Greg KH:
> On Wed, Feb 17, 2021 at 09:50:38PM +, Marc Zyngier wrote:
> > On Wed, 17 Feb 2021 20:10:50 +,
> > Michael Walle wrote:
> > >
> > > Am 2021-02-17 21:
On 17.02.21 21:56, Andrey Konovalov wrote:
During boot, all non-reserved memblock memory is exposed to the buddy
allocator. Poisoning all that memory with KASAN lengthens boot time,
especially on systems with large amount of RAM. This patch makes
page_alloc to not call kasan_free_pages() on all n
Eliminate the following coccicheck warning:
./tools/testing/selftests/timers/set-timer-lat.c:83:2-3: Unneeded
semicolon
./tools/testing/selftests/timers/nsleep-lat.c:75:2-3: Unneeded semicolon
./tools/testing/selftests/timers/nanosleep.c:75:2-3: Unneeded semicolon
./tools/testing/selftests/timers/i
On Tue, Feb 16, 2021 at 12:18:13PM -0800, Xie He wrote:
> When sending packets, we will first hand over the (L3) packets to the
> LAPB module. The LAPB module will then hand over the corresponding LAPB
> (L2) frames back to us for us to transmit.
>
> The LAPB module can also emit LAPB (L2) frames a
On Wed 17-02-21 08:36:03, Minchan Kim wrote:
> alloc_contig_range is usually used on cma area or movable zone.
> It's critical if the page migration fails on those areas so
> dump more debugging message like memory_hotplug unless user
> specifiy __GFP_NOWARN.
I agree with David that this has a pot
On Thu, 18 Feb 2021 08:54:00 +,
Greg KH wrote:
[...]
> > > Wow, wait, you are removing a debugfs file _before_ debugfs is even
> > > initialized? Didn't expect that, ok, let me go try this again...
> >
> > Yeah, that's a poor man's rename (file being deleted and re-created).
>
> True, but
On 18.02.21 09:56, Michal Hocko wrote:
On Wed 17-02-21 08:36:03, Minchan Kim wrote:
alloc_contig_range is usually used on cma area or movable zone.
It's critical if the page migration fails on those areas so
dump more debugging message like memory_hotplug unless user
specifiy __GFP_NOWARN.
I a
Am 2021-02-18 09:52, schrieb Greg KH:
On Thu, Feb 18, 2021 at 09:27:09AM +0100, Michael Walle wrote:
Am 2021-02-18 08:31, schrieb Greg KH:
> On Wed, Feb 17, 2021 at 09:50:38PM +, Marc Zyngier wrote:
> > On Wed, 17 Feb 2021 20:10:50 +,
> > Michael Walle wrote:
> > >
> > > Am 2021-02-17 2
1 - 100 of 955 matches
Mail list logo
