* Wenwen Wang wrote:
> On Tue, Apr 16, 2019 at 3:33 PM Thomas Gleixner wrote:
> >
> > On Tue, 16 Apr 2019, Wenwen Wang wrote:
> >
> > > In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is firstly
> > > found through pirq_find_routing_table(). If the table is not found and
> > >
* Waiman Long wrote:
> On 04/16/2019 01:37 PM, Peter Zijlstra wrote:
> > On Tue, Apr 16, 2019 at 01:03:10PM -0400, Waiman Long wrote:
> >> On 04/16/2019 10:17 AM, Peter Zijlstra wrote:
> >>> On Tue, Apr 16, 2019 at 09:18:50AM -0400, Waiman Long wrote:
> On 04/16/2019 09:10 AM, Peter
On April 17, 2019 12:17:41 PM GMT+09:00, Andrew Morton
wrote:
> On Wed, 17 Apr 2019 02:59:43 +0200 Matteo Croce
> wrote:
>
> > In the sysctl code the proc_dointvec_minmax() function is often used
> to
> > validate the user supplied value between an allowed range. This
> function
> > uses the
* Ingo Molnar wrote:
> * Thara Gopinath wrote:
>
> > The test results below shows 3-5% improvement in performance when
> > using the third solution compared to the default system today where
> > scheduler is unware of cpu capacity limitations due to thermal events.
>
> The numbers look very
On Wed, Apr 17, 2019 at 3:01 AM Borislav Petkov wrote:
>
> On Mon, Apr 08, 2019 at 01:58:35PM +0800, Pingfan Liu wrote:
> > crashkernel=x@y or or =range1:size1[,range2:size2,...]@offset option may
> > fail to reserve the required memory region if KASLR puts kernel into the
> > region. To avoid
Hi Matteo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1-rc5]
[cannot apply to next-20190416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Wed, Apr 17, 2019 at 3:01 AM Borislav Petkov wrote:
>
> On Mon, Apr 08, 2019 at 01:58:34PM +0800, Pingfan Liu wrote:
> > Beside kernel, at early boot stage, the KASLR code also needs to parse the
> > crashkernel=x@y or crashkernel=ramsize-range:size[,...][@offset] option,
> > and avoid to put
* Thara Gopinath wrote:
> The test results below shows 3-5% improvement in performance when
> using the third solution compared to the default system today where
> scheduler is unware of cpu capacity limitations due to thermal events.
The numbers look very promising!
I've rearranged the
In order to avoid wasting user address space by using bottom-up mmap
allocation scheme, prefer top-down scheme when possible.
Before:
root@qemuriscv64:~# cat /proc/self/maps
0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils
00016000-00017000 r--p 5000 fe:00 6389
mips uses a top-down layout by default that fits the generic functions.
At the same time, this commit allows to fix problem uncovered
and not fixed for mips here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html
Signed-off-by: Alexandre Ghiti
---
arch/mips/Kconfig
Hi CK Hu,
you mean the problematic patch is fix possible_crtcs (4/4) and the others are
ok?
can you push the first 3 while working on the last one?
regards Frank
mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.
Signed-off-by: Alexandre Ghiti
---
arch/mips/mm/mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/mm/mmap.c
This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for mips here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html
Signed-off-by:
arm uses a top-down mmap layout by default that exactly fits the generic
functions, so get rid of arch specific code and use the generic version
by selecting ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.
Signed-off-by: Alexandre Ghiti
---
arch/arm/Kconfig | 1 +
mmap base address must be computed wrt stack top address, using TASK_SIZE
is wrong since STACK_TOP and TASK_SIZE are not equivalent.
Signed-off-by: Alexandre Ghiti
---
arch/arm/mm/mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmap.c
The CPUID.0x16 leaf provides "Bus (Reference) Frequency (in MHz)".
In the thread "No 8254 PIT & no HPET on new Intel N3350 platforms
causes kernel panic during early boot" we are exploring ways to have
the kernel avoid using the PIT/HPET IRQ0 timer in more cases, and
Thomas Gleixner suggested
This commit takes care of stack randomization and stack guard gap when
computing mmap base address and checks if the task asked for randomization.
This fixes the problem uncovered and not fixed for arm here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html
Signed-off-by:
arm64 handles top-down mmap layout in a way that can be easily reused
by other architectures, so make it available in mm.
It then introduces a new config ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
that can be set by other architectures to benefit from those functions.
Note that this new config depends
Hi Matteo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1-rc5]
[cannot apply to next-20190416]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Do not offset mmap base address because of stack randomization if
current task does not want randomization.
Signed-off-by: Alexandre Ghiti
---
arch/arm64/mm/mmap.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index
Each architecture has its own way to determine if a task is a compat task,
by using is_compat_task in arch_mmap_rnd, it allows more genericity and
then it prepares its moving to mm/.
Signed-off-by: Alexandre Ghiti
---
arch/arm64/mm/mmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This preparatory commit moves this function so that further introduction
of generic topdown mmap layout is contained only in mm/util.c.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Christoph Hellwig
---
fs/binfmt_elf.c| 20
include/linux/mm.h | 2 ++
mm/util.c
This series introduces generic functions to make top-down mmap layout
easily accessible to architectures, in particular riscv which was
the initial goal of this series.
The generic implementation was taken from arm64 and used successively
by arm, mips and finally riscv.
Note that in addition the
The mm-of-the-moment snapshot 2019-04-16-22-01 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
> On Apr 16, 2019, at 11:28 AM, Peter Zijlstra wrote:
>
> On Tue, Apr 16, 2019 at 10:45:05AM -0700, Linus Torvalds wrote:
>> So very much Ack on that patch, but maybe we could do a bit more cleanup
>> here?
>
> Yeah, Nadav was going to try and clean that up. But I figured we should
> get this
Hi Eugeniu
thanks for your test & comments and adding more people for review
I will add necessary backtrace information to description and
rephrase commit summary in V2 patch
Thanks,
Jiada
On 2019/04/17 2:48, Eugeniu Rosca wrote:
Hi Jiada,
Adding below people, since they've made recent
Hi Krzysztof,
On Tue, 16 Apr 2019 at 15:49, Krzysztof Kozlowski wrote:
>
> On Mon, 15 Apr 2019 at 14:24, Anand Moon wrote:
> > Cache Coherent Interface (CCI) among Cortex-A15 and Cortex-A7, G2D, G3D and
> > SSS
> >
> > Level 0 > CPU blocks such as Cortex-A15 (CA15), Cortex-A7 (CA7) are
> >
On Wed, 10 Apr 2019 23:37:18 +0800 Feng Tang wrote:
> Currently on panic, kernel will lower the loglevel and print out
> new printk msg only with console_flush_on_panic().
>
> Add an option for users to configure the "panic_print" to see
> all dmesg in buffer, some of which they may have never
Hi Arnd,
On Tue, Apr 16, 2019 at 03:17:30PM +0200, Arnd Bergmann wrote:
> The digicolor platform has three UARTs, but the Kconfig.debug
> file explicitly lists port zero as the one to be used for the
> console, while not providing any default values.
>
> This can get an automated randconfig
On Tue, Apr 16, 2019 at 12:08 PM Mark Rutland wrote:
>
> On Mon, Apr 15, 2019 at 10:22:27AM -0700, Nick Desaulniers wrote:
> > On Mon, Apr 15, 2019 at 10:06 AM Mark Rutland wrote:
> > > It would be nice if we could simply rely on a more recent binutils these
> > > days, which supports the
On Tue, Apr 16, 2019 at 4:04 PM Guenter Roeck wrote:
>
> On Tue, Apr 16, 2019 at 1:37 PM Dan Williams wrote:
> > Ah, no, the problem is that jump_label_init() is called by
> > setup_arch() on x86, and smp_prepare_boot_cpu() on powerpc, but not
> > until after parse_args() on ARM.
> >
> Anywhere
On Mon, Apr 15, 2019 at 7:58 AM Jitendra Sharma wrote:
>
> Hi Kees Cook/Luis,
>
> We are observing one kernel crash in next_tgid function through
> getdents64 path. Call stack is as shown below:
>
> -000|has_group_leader_pid(inline)
> -000|next_tgid(
> | [X20] ns = 0xFF87CABB1AC0,
> |
On Wed, 10 Apr 2019 10:07:24 +0200 David Hildenbrand wrote:
> Care to fixup both u64 to resource_size_t? Or should I send a patch?
> Whatever you prefer.
Please send along a fixup.
This patch series has no evidence of having been reviewed :(. Can you
suggest who could help us out here?
On 4/16/2019 8:30 PM, Alexander Shishkin wrote:
Sai Prakash Ranjan writes:
From: Mulu He
Bitmap allocation works on array of unsigned longs and
for stm master allocation when the number of software
channels is 32, 4 bytes are allocated and there is a out of
bound access at the first 8 bytes
> From: Anson Huang
> Sent: Tuesday, April 16, 2019 11:22 AM
>
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> controller, the system controller is in charge of system power, clock and
> thermal sensors etc. management, Linux kernel has to communicate with
> system
hi,
在 2019/4/16 下午6:12, Daniel Lezcano 写道:
Hi Elaine,
On 11/04/2019 09:46, elaine.zhang wrote:
hi,
在 2019/4/4 上午11:03, Daniel Lezcano 写道:
On 01/04/2019 08:43, Elaine Zhang wrote:
Based on the TSADC Tshut mode to select pinctrl,
instead of setting pinctrl based on architecture
(Not depends
On Tue, 16 Apr 2019 17:39:03 -0700 Guenter Roeck wrote:
> > > Has it been confirmed that this fixes
> > > mm-shuffle-initial-free-memory-to-improve-memory-side-cache-utilization.patch
> > > on beaglebone-black?
> >
> > This only fixes dynamically enabling the shuffling on 32-bit ARM.
> > Guenter
On Tue, Apr 16, 2019 at 10:21 PM Kees Cook wrote:
>
> On Mon, Apr 8, 2019 at 5:09 PM Matteo Croce wrote:
> >
> > Use the shared variables for range check, instead of declaring a local one
> > in every source file.
> >
> > Signed-off-by: Matteo Croce
> > ---
> > kernel/pid_namespace.c | 3 +-
Hi, Aisheng
Best Regards!
Anson Huang
> -Original Message-
> From: Aisheng Dong
> Sent: Wednesday, April 17, 2019 11:13 AM
> To: Anson Huang ; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> wsa+rene...@sang-engineering.com;
On Mon, Apr 8, 2019 at 5:09 PM Matteo Croce wrote:
>
> Use the shared variables for range check, instead of declaring a local one
> in every source file.
>
> Signed-off-by: Matteo Croce
> ---
> kernel/pid_namespace.c | 3 +-
> kernel/sysctl.c| 193
On Wed, 17 Apr 2019 02:59:43 +0200 Matteo Croce wrote:
> In the sysctl code the proc_dointvec_minmax() function is often used to
> validate the user supplied value between an allowed range. This function
> uses the extra1 and extra2 members from struct ctl_table as minimum and
> maximum allowed
[...]
> >
> > Fixes: 90ad2cbe88c2("i2c: imx: use clk notifier for rate changes")
> > Signed-off-by: Anson Huang
>
> Please also provide how to reproduce it.
> And it seems not a new issue, should we CC stable?
Besides above comments:
Reviewed-by: Dong Aisheng
Regards
Dong Aisheng
>
>
> From: Anson Huang
> Sent: Wednesday, April 17, 2019 10:00 AM
>
> The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call() is
> incorrect, should use clk_change_nb element to get correct address and avoid
> below kernel dump during POST_RATE_CHANGE notify by clk
> framework:
>
>
Hi Daniel
On 2019/04/17 4:22, Daniel Lezcano wrote:
On 11/04/2019 12:03, Jiada Wang wrote:
Currently IRQ is remain enabled after .remove, later if device is probed,
IRQ is requested before .thermal_init, this may cause IRQ function be
triggered but not able to clear IRQ status, thus cause
The call to of_get_cpu_node/of_find_compatible_node/of_parse_phandle...
returns a node pointer with refcount incremented thus it must be
explicitly decremented after the last usage.
We developed a coccinelle SmPL to detect drivers/firmware code and
found some issues.
This patch series fixes those
In sdei_present_dt function, fw_np is obtained by calling
of_find_node_by_name(), np is obtained by calling
of_find_matching_node(), and the reference counts of those
two device_nodes, fw_np and np, are increased.
But when the function exits, only of_node_put is called on np,
and fw_np's reference
The call to of_find_matching_node_and_match returns a node pointer
with refcount incremented thus it must be explicitly decremented
after the last usage.
672 int __init psci_dt_init(void)
673 {
674 struct device_node *np;
...
678 np = of_find_matching_node_and_match(...);
679
In stratix10_svc_init function, fw_np is obtained by calling
of_find_node_by_name(), np is obtained by calling
of_find_matching_node(), and the reference counts of those
two device_nodes, fw_np and np, are increased.
But when the function exits, only of_node_put is called on np,
and fw_np's
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
492 int ab8500_bm_of_probe(struct device *dev,
493struct device_node *np,
494struct abx500_bm_data *bm)
495 {
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/power/supply/power_supply_core.c:601:2-8: ERROR: missing of_node_put;
acquired a node pointer
The call to of_get_cpu_node/of_find_compatible_node/of_parse_phandle...
returns a node pointer with refcount incremented thus it must be
explicitly decremented after the last usage.
We developed a coccinelle SmPL to detect drivers/power code and
found some issues.
This patch series fixes those
On Tue, Apr 16, 2019 at 7:31 PM Cong Wang wrote:
> Yes it is, I have a stacktrace in production which clearly shows
> del_elem.isra.1+0x34/0x40, unlike the one I triggered via fake
> PFN's. I can show you if you want, it is on 4.14, so very unlikely
> it is interesting to anyone here.
Correct
On Tue, Apr 16, 2019 at 6:53 PM Luck, Tony wrote:
>
> On Tue, Apr 16, 2019 at 04:47:55PM -0700, Cong Wang wrote:
> > 229 static void del_elem(struct ce_array *ca, int idx)
> > 230 {
> > 231 /* Save us a function call when deleting the last element. */
> > 232 if (ca->n - (idx +
Hi all,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
fs/f2fs/node.c: In function 'f2fs_remove_inode_page':
fs/f2fs/node.c:1193:47: warning: format '%zu' expects argument of type
'size_t', but argument 5 has type 'blkcnt_t' {aka 'long long
Fixes the following sparse warnings:
drivers/regulator/stm32-pwr.c:35:5: warning:
symbol 'ready_mask_table' was not declared. Should it be static?
drivers/regulator/stm32-pwr.c:47:5: warning:
symbol 'stm32_pwr_reg_is_ready' was not declared. Should it be static?
In case of error, the function of_iomap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: 6cdae8173f67 ("regulator: Add support for stm32 power regulators")
Signed-off-by: Wei Yongjun
---
drivers/regulator/stm32-pwr.c | 4
On 16-04-19, 17:13, Madhumitha Prabakaran wrote:
> Fix a blank line after structure declarations. Also, convert
> macros into inline functions in order to maintain Linux kernel
> coding style based on which the inline function is
> preferable over the macro.
>
> Blank line fixes are suggested by
On 16-04-19, 11:52, Yangtao Li wrote:
> Allwinner Process Voltage Scaling Tables defines the voltage and
> frequency value based on the speedbin blown in the efuse combination.
> The sunxi-cpufreq-nvmem driver reads the efuse value from the SoC to
> provide the OPP framework with required
On 16-04-19, 11:52, Yangtao Li wrote:
> Add sunxi nvmem based CPU scaling driver, refers to qcom-cpufreq-kryo.
>
> Yangtao Li (2):
> cpufreq: Add sunxi nvmem based CPU scaling driver
> dt-bindings: cpufreq: Document allwinner,sun50i-h6-operating-points
>
>
The way of getting private imx_i2c_struct in i2c_imx_clk_notifier_call()
is incorrect, should use clk_change_nb element to get correct address
and avoid below kernel dump during POST_RATE_CHANGE notify by clk
framework:
Unable to handle kernel paging request at virtual address 03ef1488
pgd =
>From the last replies in the thread, it seems some work is going on. May I ask
when we can possibly roughly have a fix or workaround?
Thanks,
Zhe
On 3/21/19 10:15 AM, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> He Zhe reported a crash by enabling trace events and selecting
>
On Tue, Apr 16, 2019 at 04:47:55PM -0700, Cong Wang wrote:
> 229 static void del_elem(struct ce_array *ca, int idx)
> 230 {
> 231 /* Save us a function call when deleting the last element. */
> 232 if (ca->n - (idx + 1))
> 233 memmove((void *)>array[idx],
> 234
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
USB PowerShare is a policy which affects charging via the special
USB PowerShare port (marked with a small lightning bolt or battery icon)
when in low power states:
- In S0, the port will always provide power.
- In S0ix, if power_share is enabled, then power will be supplied to
the port when on
Boot on AC is a policy which makes the device boot from S5 when AC
power is connected. This is useful for users who want to run their
device headless or with a dock.
v3 changes:
- Add docstring to wilco_ec_add_sysfs()
- Tweak a comment
- Use val > 1 instead of val != 0 && val != 1
v2 changes:
-
Hi,
On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
> There is no need to insert memory barrier on each readl/writel
> invocation, hence use the relaxed versions.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra-devfreq.c | 8
> 1 file changed, 4 insertions(+), 4
Hi,
On 19. 4. 16. 오후 11:29, Dmitry Osipenko wrote:
> 16.04.2019 5:32, Chanwoo Choi пишет:
>> Hi,
>>
>> patch6/7/8/9 are for handling of exception handling in probe() function.
>> Actually, I'm not sure that there are special reason to split out
>> the patches. I think that you can squash
In the sysctl code the proc_dointvec_minmax() function is often used to
validate the user supplied value between an allowed range. This function
uses the extra1 and extra2 members from struct ctl_table as minimum and
maximum allowed value.
On sysctl handler declaration, in every source file there
On 19. 4. 16. 오후 10:57, Dmitry Osipenko wrote:
> 16.04.2019 11:00, Chanwoo Choi пишет:
>> Hi,
>>
>> On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
>>> The write memory barrier isn't needed because the BUS buffer is flushed
>>> by read after write that happens after the removed wmb(), we will also
Add control of the charging algorithm used on Wilco devices.
See Documentation/ABI/testing/sysfs-class-power-wilco for the
userspace interface and other info.
v4 changes:
-Move implementation from
drivers/platform/chrome/wilco_ec/charge_config.c to
drivers/power/supply/wilco_charger.c
-Move
Add "Standard", "Adaptive", and "Custom" modes to the charge_type
property, to expand the existing "Trickle" and "Fast" modes.
In addition, add POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD
and POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD properties, to expand
the existing CHARGE_CONTROL_*
On Tue, Apr 16, 2019 at 5:04 PM Dan Williams wrote:
>
> On Tue, Apr 16, 2019 at 4:44 PM Andrew Morton
> wrote:
> >
> > On Tue, 16 Apr 2019 13:54:04 -0700 Dan Williams
> > wrote:
> >
> > > When a module option, or core kernel argument, toggles a static-key it
> > > requires jump labels to be
On 4/16/19 1:11 PM, Borislav Petkov wrote:
>> +/*
>> + * Inform kmemleak about the hole in the .bss section since the
>> + * corresponding pages will be unmapped with DEBUG_PAGEALLOC=y.
>> + */
>> +kmemleak_free_part((void *)vaddr, vaddr_end - vaddr);
>>
On 04/15/2019 06:35 AM, Paolo Bonzini wrote:
The SVI, RVI, virtual-APIC page address and APIC-access page address fields
were left out of dump_vmcs. Add them.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx/vmx.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
Hi,
On 19. 4. 17. 오전 12:40, Dmitry Osipenko wrote:
> 16.04.2019 10:15, Chanwoo Choi пишет:
>> Hi,
>>
>> On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
>>> The frequency value potentially could change in-between. It doesn't
>>> cause any real problem at all right now, but that could change in the
On (04/16/19 16:53), Andrew Morton wrote:
> > Adding more Cc and stable (i thought this was 5.1 addition). Note that
> > without this patch on arch/kernel where PAGE_SIZE != 4096 userspace
> > could read random memory through a zram block device (thought userspace
> > probably would have no
Hi,
On 19. 4. 17. 오전 12:23, Dmitry Osipenko wrote:
> 16.04.2019 8:56, Chanwoo Choi пишет:
>> Hi,
>>
>> It looks good to me to drop the primary interrupt handler
>> but I have some comments. Please check it.
>>
>> On 19. 4. 15. 오후 11:54, Dmitry Osipenko wrote:
>>> There is no real need in the
On 19. 4. 17. 오전 12:49, Dmitry Osipenko wrote:
> 16.04.2019 10:48, Chanwoo Choi пишет:
>> Hi,
>>
>> On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote:
>>> The devfreq driver can be used on Tegra30 without any code change and
>>> it works perfectly fine, the default Tegra124 parameters are good enough
On 19. 4. 17. 오전 12:52, Dmitry Osipenko wrote:
> 16.04.2019 10:43, Chanwoo Choi пишет:
>> On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote:
>>> The driver's compilation doesn't have any specific dependencies, hence
>>> the COMPILE_TEST option can be supported in Kconfig.
>>>
>>> Signed-off-by: Dmitry
Hi,
On 19. 4. 17. 오전 1:11, Dmitry Osipenko wrote:
> 16.04.2019 11:31, Chanwoo Choi пишет:
>> Hi,
>>
>> On 19. 4. 15. 오후 11:55, Dmitry Osipenko wrote:
>>> Add devfreq driver for NVIDIA Tegra20 SoC's. The driver periodically
>>> reads out Memory Controller counters and adjusts memory frequency
On Tue, Apr 16, 2019 at 06:02:21PM +0100, Valentin Schneider wrote:
> Commit 7ee7ef24d02d ("scsi: arm64: defconfig: enable configs for Hisilicon
> ufs")
> set 'CONFIG_SCSI_UFS_HISI=y', but the configs it depends
> on
>
> (CONFIG_SCSI_HFSHCD_PLATFORM && CONFIG_SCSI_UFSHCD)
>
> were left to
Hi,
The v1.13 release of pahole and its friends is out, available at
the usual places:
Main git repo:
git://git.kernel.org/pub/scm/devel/pahole/pahole.git
Mirror git repo:
https://github.com/acmel/dwarves.git
tarball + gpg signature:
On Tue, Apr 16, 2019 at 02:18:40PM -0600, Mathieu Poirier wrote:
> Hi Leo,
>
> On Fri, 12 Apr 2019 at 04:28, Leo Yan wrote:
> >
> > CoreSight uses below bindings for replicator:
> >
> > Dynamic replicator, aka. configurable replicator:
> > "arm,coresight-dynamic-replicator",
On Tue, Apr 16, 2019 at 4:44 PM Andrew Morton wrote:
>
> On Tue, 16 Apr 2019 13:54:04 -0700 Dan Williams
> wrote:
>
> > When a module option, or core kernel argument, toggles a static-key it
> > requires jump labels to be initialized early. While x86, PowerPC, and
> > ARM64 arrange for
Dear Friend,
I know that this mail will come to you as a surprise as we have never
met before, but need not to worry as I am contacting you independently
of my investigation and no one is informed of this communication.
I need your urgent assistance in transferring the sum of $11.3million
On Wed, 10 Apr 2019 15:43:50 -0400 Jerome Glisse wrote:
> Adding more Cc and stable (i thought this was 5.1 addition). Note that
> without this patch on arch/kernel where PAGE_SIZE != 4096 userspace
> could read random memory through a zram block device (thought userspace
> probably would have
The of_device_id table needs to be registered as module alias in order
for automatic module loading to pick the kernel module based on the
DeviceTree compatible. So add MODULE_DEVICE_TABLE() to make this happen.
Fixes: e13d757279bb ("iio: adc: Add QCOM SPMI PMIC5 ADC driver")
Cc:
On 17/4/19 1:28 am, Nishad Kamdar wrote:
This patch corrects the SPDX License Identifier style
in the powerpc Hardware Architecture related files.
Suggested-by: Joe Perches
Signed-off-by: Nishad Kamdar
---
TIL there's a different style for source vs headers... sigh. :( Thanks
for fixing.
On Tue, Apr 16, 2019 at 4:28 PM Luck, Tony wrote:
>
> On Tue, Apr 16, 2019 at 04:18:57PM -0700, Cong Wang wrote:
> > > The problem case occurs when we've seen enough distinct
> > > errors that we have filled every entry, then we try to
> > > look up a pfn that is larger that any seen before.
> >
On Wed, 10 Apr 2019 15:59:55 -0700 Kees Cook wrote:
> On Wed, Apr 10, 2019 at 3:54 PM Matteo Croce wrote:
> >
> > On Thu, Apr 11, 2019 at 12:34 AM Kees Cook wrote:
> > >
> > > On Wed, Apr 10, 2019 at 3:30 PM Matteo Croce wrote:
> > > >
> > > > FYI, this are the stats from my local repo, just
On Tue, 16 Apr 2019 13:54:04 -0700 Dan Williams
wrote:
> When a module option, or core kernel argument, toggles a static-key it
> requires jump labels to be initialized early. While x86, PowerPC, and
> ARM64 arrange for jump_label_init() to be called before parse_args(),
> ARM does not.
>
>
On Tue, 16 Apr 2019 18:14:00 -0500 Kees Cook wrote:
> On Tue, Apr 16, 2019 at 6:04 PM Andrew Morton
> wrote:
> >
> > >
> > > Reported-by: Ali Saidi
> > > Link:
> > > https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=omfhx_p0nckp...@mail.gmail.com
> > > Fixes: eab09532d400
All,
I took another look at this patch and realized it was missing a #include.
I've added the appropriate #include to a new version of the patch.
Thanks,
Mike Salvatore
From 6fbf80fa3d5bc39fa054350a663080e1380046f8 Mon Sep 17 00:00:00 2001
From: Mike Salvatore
Date: Wed, 13 Mar 2019 22:11:37
On Tue, Apr 16, 2019 at 04:18:57PM -0700, Cong Wang wrote:
> > The problem case occurs when we've seen enough distinct
> > errors that we have filled every entry, then we try to
> > look up a pfn that is larger that any seen before.
> >
> > The loop:
> >
> > while (min < max) {
> >
On Tue, Apr 16, 2019 at 3:18 PM Luck, Tony wrote:
>
> On Tue, Apr 16, 2019 at 11:07:26AM +0200, Borislav Petkov wrote:
> > On Mon, Apr 15, 2019 at 06:20:00PM -0700, Cong Wang wrote:
> > > ce_arr.array[] is always within the range [0, ce_arr.n-1].
> > > However, the binary search code in
On Thu, 11 Apr 2019 17:32:12 +0200 Vitaly Wool wrote:
> This patchset implements page migration support and slightly better
> buddy search. To implement page migration support, z3fold has to move
> away from the current scheme of handle encoding. i. e. stop encoding
> page address in handles.
Why cannot we start simple and build from there? In other words I
do not
think we really need anything like N_CPU_MEM at all.
In this patchset N_CPU_MEM is used to tell us what nodes are cpuless
nodes.
They would be the preferred demotion target. Of course, we could
rely on
firmware to
On 4/16/19 4:04 PM, Dave Hansen wrote:
On 4/16/19 2:59 PM, Yang Shi wrote:
On 4/16/19 2:22 PM, Dave Hansen wrote:
Keith Busch had a set of patches to let you specify the demotion order
via sysfs for fun. The rules we came up with were:
1. Pages keep no history of where they have been
2.
On Tue, Apr 16, 2019 at 2:46 PM Borislav Petkov wrote:
>
> On Tue, Apr 16, 2019 at 02:33:50PM -0700, Cong Wang wrote:
> > ce_arr.array[] is always within the range [0, ce_arr.n-1].
> > However, the binary search code in __find_elem() uses ce_arr.n
> > as the maximum index, which could lead to an
On Tue, Apr 16, 2019 at 6:04 PM Andrew Morton wrote:
>
> On Mon, 15 Apr 2019 21:23:20 -0700 Kees Cook wrote:
>
> > Commit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"),
> > made changes in the rare case when the ELF loader was directly invoked
> > (e.g to set a non-inheritable
1 - 100 of 941 matches
Mail list logo
