В Tue, 16 Jul 2019 19:35:49 -0700
Sowjanya Komatineni пишет:
> On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:
> >
> > On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:
> >>
> >> On 7/16/19 3:00 PM, Dmitry Osipenko wrote:
> >>> 17.07.2019 0:35, Sowjanya Komatineni пишет:
> On 7/16/19 2:21
On Tue, Jul 16, 2019 at 06:20:23PM -0700, John Hubbard wrote:
> > - unsigned long _zd_pad_1;/* uses mapping */
> > + /*
> > +* The following fields are used to hold the source
> > +* page anonymous mapping informati
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Bor
PVH guest needs PV extentions to work, so "nopv" parameter should be
ignored for PVH but not for HVM guest.
If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore "nopv" parameter directly.
If PVH guest boots up via the normal boot entry same as
On 17-07-19, 11:55, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
>
> Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang
> Cc: "Rafael J. Wy
Hi all,
Please do not add v5.4 material to your linux-next included branches
until after v5.3-rc1 has been released.
Changes since 20190716:
The kbuild tree lost its build failure.
The xfs tree gained a conflict against Linus' tree.
Non-merge commits (relative to Linus' tree):
On 7/16/19 9:22 PM, Christoph Hellwig wrote:
> On Tue, Jul 16, 2019 at 06:20:23PM -0700, John Hubbard wrote:
>>> - unsigned long _zd_pad_1;/* uses mapping */
>>> + /*
>>> +* The following fields are used to hold the source
>>> +
Hi Randy,
On Tue, 16 Jul 2019 20:50:11 -0700 Randy Dunlap wrote:
>
> drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):
>
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig~linux-next
> +++ a/drivers/gpu/drm/amd/amdgpu/Kconfig
> @@ -27,7 +27,12 @@ config DRM_AMDGPU_CIK
> config D
On Tue, Jul 16, 2019 at 09:31:33PM -0700, John Hubbard wrote:
> OK, so just delete all the _zd_pad_* fields? Works for me. It's misleading to
> calling something padding, if it's actually unavailable because it's used
> in the other union, so deleting would be even better than commenting.
>
> In t
On 14.07.19 11:15, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.
This gap is missed in XEN PV int3 exception entry path, then b
> # Conflicts:
> # drivers/nvme/host/core.c
I thought you were going to fix this up :)
But I can do that and this version of the series looks fine to me.
On 16-07-19, 12:53, Niklas Cassel wrote:
> Here I cheated and simply used get_cpu_device(0).
>
> Since I cheated, I used get_cpu_device(0) always,
> so even when CPU1,CPU2,CPU3 is attached, dev_pm_opp_get_opp_count(cpu0) is
> still 0.
>
> I added a print in
> [3.836533] cpr_set_performance: n
On Wed, 2019-07-17 at 06:50 +0200, Christoph Hellwig wrote:
> > # Conflicts:
> > # drivers/nvme/host/core.c
>
> I thought you were going to fix this up :)
Haha yeah I was ...
> But I can do that and this version of the series looks fine to me.
Thanks !
Cheers,
Ben.
On 16.07.19 06:26, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
Signed-off-by: Zhenzhong Duan
Reviewed-by: Juergen Gross
... and complete series applied to
On 14.07.19 11:15, Zhenzhong Duan wrote:
Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.
This gap is missed in XEN PV int3 exception entry path, then b
On Wed 17-07-19 01:50:31, Yang Shi wrote:
> When running ltp's oom test with kmemleak enabled, the below warning was
> triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
> passed in:
>
> WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608
> __alloc_pages_nodemask+0x1c31/0x1d5
On Wed 17-07-19 07:07:11, Michal Hocko wrote:
> On Wed 17-07-19 01:50:31, Yang Shi wrote:
> > When running ltp's oom test with kmemleak enabled, the below warning was
> > triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
> > passed in:
> >
> > WARNING: CPU: 105 PID: 2138 at m
Whoops. Thanks.
On Mon, 15 Jul 2019 at 17:28, Arnd Bergmann wrote:
>
> The usage is now hidden in an #ifdef, so we need to move
> the variable itself in there as well to avoid this warning:
>
> kernel/locking/lockdep_proc.c:203:21: error: unused variable 'class'
> [-Werror,-Wunused-variable]
Hi Boris,
> -Original Message-
> From: Boris Brezillon
> Sent: Tuesday, July 16, 2019 1:15 PM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; bbrezil...@kernel.org; rich...@nod.at;
> dw...@infradead.org; computersforpe...@gmail.com; marek.va...@gmail.com;
> vigne...@ti.com;
On Tue 16-07-19 16:28:21, Qian Cai wrote:
> On Tue, 2019-07-16 at 22:07 +0200, Michal Hocko wrote:
> > On Tue 16-07-19 15:21:17, Qian Cai wrote:
> > [...]
> > > Thanks to this commit, there are allocation with __GFP_DIRECT_RECLAIM that
> > > succeeded would keep trying with __GFP_NOFAIL for kmemlea
В Tue, 16 Jul 2019 22:25:25 -0700
Sowjanya Komatineni пишет:
> On 7/16/19 9:11 PM, Dmitry Osipenko wrote:
> > В Tue, 16 Jul 2019 19:35:49 -0700
> > Sowjanya Komatineni пишет:
> >
> >> On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:
> >>> On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:
>
Oscar Salvador writes:
> On Mon, 2019-07-15 at 21:41 +0530, Aneesh Kumar K.V wrote:
>> Oscar Salvador writes:
>>
>> > Since [1], shrink_{zone,node}_span work on PAGES_PER_SUBSECTION
>> > granularity.
>> > The problem is that deactivation of the section occurs later on in
>> > sparse_remove_sect
On 11-07-19, 15:09, Rajendra Nayak wrote:
> Sorry for the delay
Same here :)
> I seem to have completely missed this patch.
> I just gave this a try and here are some observations,
>
> I have a case where I have one device with 2 power domains, one of them
> is scale-able (supports perf state) a
On 7/16/19 10:42 PM, Dmitry Osipenko wrote:
В Tue, 16 Jul 2019 22:25:25 -0700
Sowjanya Komatineni пишет:
On 7/16/19 9:11 PM, Dmitry Osipenko wrote:
В Tue, 16 Jul 2019 19:35:49 -0700
Sowjanya Komatineni пишет:
On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:
On 7/16/19 3:06 PM, Sowjanya
On 17/07/19 5:28 AM, Baolin Wang wrote:
> In sdhci_runtime_resume_host() function, we will always do software reset
> for all, which will cause Spreadtrum host controller work abnormally after
> resuming.
>
> Thus for Spreadtrum platform that will not power down the SD/eMMC card during
> runtime s
Hello,
This patchset adds support for i.MXQXP AI_ML board from Einfochips.
This board is one of the Consumer Edition boards of the 96Boards family
based on i.MX8QXP SoC from NXP/Freescale.
The initial support includes following peripherals which are tested and
known to be working:
1. Debug seria
Add support for i.MX8QXP AI_ML board from Einfochips. This board is one
of the Consumer Edition boards of the 96Boards family based on i.MX8QXP
SoC from NXP/Freescale.
The initial support includes following peripherals which are tested and
known to be working:
1. Debug serial via UART2
2. uSD
3.
Add devicetree vendor prefix for Einfochips.
https://www.einfochips.com/
Signed-off-by: Manivannan Sadhasivam
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/d
Document devicetree binding of i.MX8QXP AI_ML board from Einfochips.
Signed-off-by: Manivannan Sadhasivam
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm
> From: linux-rdma-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Hariprasad Kelam
>
> fix below issue reported by coccicheck
> drivers/infiniband/hw/qedr/verbs.c:2454:5-7: Unneeded variable: "rc".
> Return "0" on line 2499
>
> Signed-off-by: Hariprasad Kelam
> ---
> drivers/infinib
This is based on mediatek's devfreq patches[1].
In MT8183 SoC, CCI and little core cluster share same regulator. In original
implementation, CCI frequency depends on regulator voltage, which results in
bad memory access performance if tasks are loaded on other cpus other than
little cluster (cpus
This series depends on following series:
1. mt8183 cpufreq and cci devfreq from andrew-sh.cheng
https://patchwork.kernel.org/cover/10946047/
2. cpu based scaling support to passive_governor from Sibi Sankar
https://lore.kernel.org/patchwork/patch/1101049/
This series uses cpu based scaling passiv
mt8183-cci shares vproc with small cluster. If the regulator is shared
between several devices then the lowest request voltage that meets the
system constraints will be used.
However, previous mediatek cpufreq implementation would cause race condition
if vproc is shared by multiple devices, which
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be signed. This is simpler than parsing *.mod
files in $(MODVERDIR).
The modules_sign target is only supported for in-kernel modules.
So, this commit does not take care of external modules.
Signed-off-by:
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be installed. This is simpler than parsing *.mod
files in $(MODVERDIR).
For external modules, $(KBUILD_EXTMOD)/modules.order should be read.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Change
The current format of *.mod is like this:
line 1: directory path to the .ko file
line 2: a list of objects linked into this module
line 3: unresolved symbols (only when CONFIG_TRIM_UNUSED_KSYMS=y)
Now that *.mod and *.ko are created in the same directory, the line 1
provides no valuable inf
Removing the 'kernel/' prefix will make our life easier because we can
simply do 'cat modules.order' to get all built modules with full paths.
Currently, we parse the first line of '*.mod' files in $(MODVERDIR).
Since we have duplicated functionality here, I plan to remove MODVERDIR
entirely.
In
Now that there is no rule for 'prepare1', it can go away.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
Makefile | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 9ad9f8d1130d..14458ab3d6a8 100644
--- a/Makefile
+
Nothing depends on this, so it is dead code.
Signed-off-by: Masahiro Yamada
---
Changes in v3: None
Changes in v2: None
drivers/scsi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index aeda53901064..c00e3dd57990 10064
Currently, *.mod is created as a side-effect of obj-m.
Split out *.mod as a dedicated build rule, which allows to unify
the %.c -> %.o rule, and remove the single-used-m rule.
This also makes the incremental build of allmodconfig faster because
it saves $(NM) invocation when there is no change in
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be processed. This is simpler than parsing *.mod
files in $(MODVERDIR).
For external modules, $(KBUILD_EXTMOD)/modules.order should be read.
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- Add ifd
Currently, only the top-level modules.order drops duplicated entries.
The modules.order files in sub-directories potentially contain
duplication. To list out the paths of all modules, I want to use
modules.order instead of parsing *.mod files in $(MODVERDIR).
To achieve this, I want to rip off du
Currently, $(objtree)/modules.order is touched in two places.
In the 'prepare0' rule, scripts/Makefile.build creates an empty
modules.order while processing 'obj=.'
In the 'modules' rule, the top-level Makefile overwrites it with
the correct list of modules.
While this might be a good side-effec
Towards the goal of removing MODVERDIR aka .tmp_versions, read out
modules.order to get the list of modules to be processed. This is
simpler than parsing *.mod files in .tmp_versions.
Signed-off-by: Masahiro Yamada
---
Changes in v3:
- New patch
Changes in v2: None
scripts/export_report.pl
While descending directories, Kbuild produces objects for modules,
but do not link final *.ko files; it is done in the modpost.
To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
for every module it is building. Some post-processing steps read the
necessary information from *.mo
On 7/16/19 9:38 PM, Stephen Rothwell wrote:
> Hi Randy,
>
> On Tue, 16 Jul 2019 20:50:11 -0700 Randy Dunlap wrote:
>>
>> drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):
>>
>> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig~linux-next
>> +++ a/drivers/gpu/drm/amd/amdgpu/Kconfig
On 7/16/19 11:19 PM, Randy Dunlap wrote:
> On 7/16/19 9:38 PM, Stephen Rothwell wrote:
>> Hi Randy,
>>
>> On Tue, 16 Jul 2019 20:50:11 -0700 Randy Dunlap
>> wrote:
>>>
>>> drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):
>>>
>>> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig~li
On 7/14/19 10:06 AM, Nikolai Zhubr wrote:
> Hi all,
>
> After reading some (apparently contradictory) revisions of DMA api references
> in Documentation/DMA-*.txt, some (contradictory) discussions thereof, and
> even digging through the in-tree drivers in search for a good enlightening
> exampl
- Some headers graduated from the blacklist
- hyperv_timer.h joined the header-test when CONFIG_X86=y
- nf_tables*.h joined the header-test when CONFIG_NF_TABLES is
enabled.
- The entry for nf_tables_offload.h was added to fix build error for
the combination of CONFIG_NF_TABLES=n and CONFIG_
В Tue, 16 Jul 2019 22:55:52 -0700
Sowjanya Komatineni пишет:
> On 7/16/19 10:42 PM, Dmitry Osipenko wrote:
> > В Tue, 16 Jul 2019 22:25:25 -0700
> > Sowjanya Komatineni пишет:
> >
> >> On 7/16/19 9:11 PM, Dmitry Osipenko wrote:
> >>> В Tue, 16 Jul 2019 19:35:49 -0700
> >>> Sowjanya Komatinen
Hi Stephen,
On Wed, Jul 17, 2019 at 8:28 AM Stephen Rothwell wrote:
>
> Hi,
>
> On Wed, 10 Jul 2019 14:30:36 +1000 Stephen Rothwell
> wrote:
> >
> > On Wed, 10 Jul 2019 11:04:43 +1000 Stephen Rothwell
> > wrote:
> > >
> > > On Tue, 9 Jul 2019 12:46:34 + Jason Gunthorpe
> > > wrote:
> >
On 19. 7. 16. 오후 10:03, Dmitry Osipenko wrote:
> 16.07.2019 14:47, Chanwoo Choi пишет:
>> On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
>>> There is no real need to keep interrupt always-enabled, will be nicer
>>> to keep it disabled while governor is inactive.
>>>
>>> Suggested-by: Thierry Reding
Hi Clark,
On 16/07/19 17:55, Clark Williams wrote:
> Saw this after applying my thermal lock to raw patch and the change in i915
> for lockdep. The
> splat occurred on boot when creating the kdump initramfs. System is an Intel
> NUC i7 with 32GB ram
> and 256GB SSD for rootfs.
>
> The booting
On 19. 7. 16. 오후 10:09, Dmitry Osipenko wrote:
> 16.07.2019 14:50, Chanwoo Choi пишет:
>> On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
>>> The EMC clock rate rounding technically could fail, hence let's handle
>>> the error cases properly.
>>>
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> driver
Hi Maxime:
Thanks for your reply.
>-Original Message-
>From: Maxime Ripard [mailto:maxime.rip...@bootlin.com]
>Sent: Thursday, July 11, 2019 7:21 PM
>To: Zengtao (B)
>Cc: kis...@ti.com; Chen-Yu Tsai ; Paul Kocialkowski
>; Sakari Ailus ;
>linux-kernel@vger.kernel.org; linux-arm-ker...@lis
On 7/16/19 11:33 PM, Dmitry Osipenko wrote:
В Tue, 16 Jul 2019 22:55:52 -0700
Sowjanya Komatineni пишет:
On 7/16/19 10:42 PM, Dmitry Osipenko wrote:
В Tue, 16 Jul 2019 22:25:25 -0700
Sowjanya Komatineni пишет:
On 7/16/19 9:11 PM, Dmitry Osipenko wrote:
В Tue, 16 Jul 2019 19:35:49 -070
On Mon, Jun 10, 2019 at 04:17:51PM +0800, yibin.g...@nxp.com wrote:
> From: Robin Gong
>
> Correct sdma compatible since ecspi errata ERR009165 has been fixed
> on i.mx6sll as i.mx6ul.
>
> Signed-off-by: Robin Gong
Applied, thanks.
On Mon, Jun 10, 2019 at 04:17:50PM +0800, yibin.g...@nxp.com wrote:
> From: Robin Gong
>
> Add dma support on ecspi.
>
> Signed-off-by: Robin Gong
Applied, thanks.
On 19. 7. 16. 오후 10:26, Dmitry Osipenko wrote:
> 16.07.2019 15:23, Chanwoo Choi пишет:
>> Hi Dmitry,
>>
>> Usually, the kernel log print for all users
>> such as changing the frequency, fail or success.
>>
>> But, if the log just show the register dump,
>> it is not useful for all users. It is just
Hi Richard,
Richard Cochran writes:
> On Tue, Jul 16, 2019 at 10:20:37AM +0300, Felipe Balbi wrote:
>> When this new flag is set, we can use single-shot output.
>>
>> Signed-off-by: Felipe Balbi
>> ---
>> include/uapi/linux/ptp_clock.h | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletio
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
> .. as "nopv" support needs it to be changeable at boot up stage.
>
> Checkpatch reports warning, so move variable declarations from
> hypervisor.c to hypervisor.h
[]
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.
On Mon, Jun 10, 2019 at 04:17:52PM +0800, yibin.g...@nxp.com wrote:
> From: Robin Gong
>
> Enable SDMA support on i.mx8mq/8mm chips, including enabling
> CONFIG_FW_LOADER_USER_HELPER/CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> for firmware loaded by udev.
>
> Signed-off-by: Robin Gong
Applied, tha
On 17.07.19 08:46, Joe Perches wrote:
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
.. as "nopv" support needs it to be changeable at boot up stage.
Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h
[]
diff --git a/arch/x86/xen/enlighten_hv
Hi,
Shannon Nelson writes:
> On 7/16/19 12:20 AM, Felipe Balbi wrote:
>> Add a driver supporting Intel Timed GPIO controller available as part
>> of some Intel PMCs.
>>
>> Signed-off-by: Felipe Balbi
>
> Hi Felipe, just a couple of quick comments:
>
> There are several places where a line is
Hi,
Richard Cochran writes:
> On Tue, Jul 16, 2019 at 10:20:33AM +0300, Felipe Balbi wrote:
>> TGPIO is a new IP which allows for time synchronization between systems
>> without any other means of synchronization such as PTP or NTP. The
>> driver is implemented as part of the PTP framework sin
On Wed, Jul 17, 2019 at 4:47 AM Thomas Gleixner wrote:
>
> The gold linker has known issues of failing the build both in random and in
> predictible ways:
>
> - The x86/X32 VDSO build fails with:
>
>arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres:
>error: reloca
On Tue, Jun 11, 2019 at 08:25:35PM +0800, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> Enable CONFIG_PINCTRL_IMX8MN by default to support i.MX8MN
> pinctrl driver.
>
> Signed-off-by: Anson Huang
> Reviewed-by: Dong Aisheng
Applied, thanks.
601 - 667 of 667 matches
Mail list logo
