Re: [PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > I work for MediaTek on maintaining the existing MediaTek SoC whose target > to home gateway such as MT7622 and MT7623 that is reusing MT2701 related > files and will keep adding

Re: [PATCH v2 4/4] pinctrl: mediatek: update MAINTAINERS entry with MediaTek pinctrl driver

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > I work for MediaTek on maintaining the existing MediaTek SoC whose target > to home gateway such as MT7622 and MT7623 that is reusing MT2701 related > files and will keep adding support for the following such kinds of SoCs > in the

Re: [PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has > the registers for pinctrl, pinconf and gpio mixed up in the same register > range. However, the IO core for

Re: [PATCH v2 3/4] pinctrl: mediatek: add pinctrl driver for MT7622 SoC

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > Add support for pinctrl on MT7622 SoC. The IO core found on the SoC has > the registers for pinctrl, pinconf and gpio mixed up in the same register > range. However, the IO core for the MT7622 SoC is completely distinct from >

Re: Maintainer docs for patch merging

On Wed, Dec 20, 2017 at 11:25:41AM +1100, Tobin C. Harding wrote: > Hi, > > Recently we started a maintainer book (merged into Jonathan's docs-next > branch). > > Would any current maintainers please be willing to explain how they go > about generating the automated emails one often receives

Re: Maintainer docs for patch merging

On Wed, Dec 20, 2017 at 11:25:41AM +1100, Tobin C. Harding wrote: > Hi, > > Recently we started a maintainer book (merged into Jonathan's docs-next > branch). > > Would any current maintainers please be willing to explain how they go > about generating the automated emails one often receives

Re: general protection fault in native_write_cr4

2017-12-20 15:49 GMT+08:00 syzbot : > Hello, > > syzkaller hit the following crash on > f6f3732162b5ae3c771b9285a5a32d72b8586920 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC)

Re: general protection fault in native_write_cr4

2017-12-20 15:49 GMT+08:00 syzbot : > Hello, > > syzkaller hit the following crash on > f6f3732162b5ae3c771b9285a5a32d72b8586920 > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. >

Re: BUG: unable to handle kernel NULL pointer dereference in rb_insert_color

On Tue, Dec 19, 2017 at 10:59 PM, Eric Biggers wrote: > On Tue, Dec 19, 2017 at 12:41:01AM -0800, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> 6084b576dca2e898f5c101baef151f7bfdbb606d >>

Re: BUG: unable to handle kernel NULL pointer dereference in rb_insert_color

On Tue, Dec 19, 2017 at 10:59 PM, Eric Biggers wrote: > On Tue, Dec 19, 2017 at 12:41:01AM -0800, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> 6084b576dca2e898f5c101baef151f7bfdbb606d >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master >> compiler:

Re: [PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > Since lots of MediaTek drivers had been added, it seems slightly better > for that adding cleanup for placing MediaTek pinctrl drivers under the > independent menu as other kinds of

Re: [PATCH v2 2/4] pinctrl: mediatek: cleanup for placing all drivers under the menu

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > Since lots of MediaTek drivers had been added, it seems slightly better > for that adding cleanup for placing MediaTek pinctrl drivers under the > independent menu as other kinds of drivers usually was done. > > Signed-off-by: Sean

Re: [PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > Add devicetree bindings for MediaTek MT7622 pinctrl driver. > > Signed-off-by: Sean Wang > Reviewed-by: Biao Huang Patch applied

Re: [PATCH v2 1/4] dt-bindings: pinctrl: add bindings for MediaTek MT7622 SoC

On Tue, Dec 12, 2017 at 7:24 AM, wrote: > From: Sean Wang > > Add devicetree bindings for MediaTek MT7622 pinctrl driver. > > Signed-off-by: Sean Wang > Reviewed-by: Biao Huang Patch applied with Rob's ACK. Yours, Linus Walleij

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On (12/19/17 09:40), Steven Rostedt wrote: > On Tue, 19 Dec 2017 13:58:46 +0900 > Sergey Senozhatsky wrote: > > > so you are not convinced that my scenarios real/matter; I'm not > > Well, not with the test module. I'm looking for actual code in the > upstream

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

On (12/19/17 09:40), Steven Rostedt wrote: > On Tue, 19 Dec 2017 13:58:46 +0900 > Sergey Senozhatsky wrote: > > > so you are not convinced that my scenarios real/matter; I'm not > > Well, not with the test module. I'm looking for actual code in the > upstream kernel. > > > convinced that I

Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > Add support of stm32mp157c evaluation board (part number: STM32MP157C-EV1) > split in 2 elements: > -Daughter board (part number: STM32MP157C-ED1) > which includes CPU,

Re: [PATCH V2 9/9] ARM: dts: stm32: add initial support of stm32mp157c eval board

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > Add support of stm32mp157c evaluation board (part number: STM32MP157C-EV1) > split in 2 elements: > -Daughter board (part number: STM32MP157C-ED1) > which includes CPU, memory and power supply > -Mother board (part

Re: [PATCH] staging: ccree: use size_t consistently

On Wed, Dec 20, 2017 at 07:23:31AM +, Gilad Ben-Yossef wrote: > Fix declaration, implementation and wrapper function to use > the same size_t type we actually define the parameter to be. > > Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params") > Signed-off-by: Gilad

Re: [PATCH] staging: ccree: use size_t consistently

On Wed, Dec 20, 2017 at 07:23:31AM +, Gilad Ben-Yossef wrote: > Fix declaration, implementation and wrapper function to use > the same size_t type we actually define the parameter to be. > > Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params") > Signed-off-by: Gilad

Re: [PATCH V2 6/9] pinctrl: stm32: Add STM32MP157 MPU support

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > This driver consists of 2 controllers due to a hole in mapping: > -1 controller for GPIO bankA to K. > -1 controller for GPIO bankZ. > > Signed-off-by: Alexandre Torgue

Re: [PATCH V2 6/9] pinctrl: stm32: Add STM32MP157 MPU support

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > This driver consists of 2 controllers due to a hole in mapping: > -1 controller for GPIO bankA to K. > -1 controller for GPIO bankZ. > > Signed-off-by: Alexandre Torgue > Signed-off-by: Ludovic Barre >

Re: [PATCH V2 1/9] devicetree: bindings: Document supported STM32 SoC family

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > This adds a list of supported STM32 SoC bindings. > > Signed-off-by: Gwenael Treuveur > Signed-off-by: Ludovic Barre >

Re: [PATCH V2 1/9] devicetree: bindings: Document supported STM32 SoC family

On Mon, Dec 18, 2017 at 4:17 PM, Ludovic Barre wrote: > From: Ludovic Barre > > This adds a list of supported STM32 SoC bindings. > > Signed-off-by: Gwenael Treuveur > Signed-off-by: Ludovic Barre > Reviewed-by: Rob Herring Patch applied. Yours, Linus Walleij

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

On Tue, 19 Dec 2017 13:20:43 -0800 Rao Shoaib wrote: > On 12/19/2017 12:41 PM, Jesper Dangaard Brouer wrote: > > On Tue, 19 Dec 2017 09:52:27 -0800 rao.sho...@oracle.com wrote: > > > >> +/* Main RCU function that is called to free RCU structures */ > >> +static void >

[PATCH v6 0/2] KVM: MMU: fix kvm_is_mmio_pfn()

Some reserved pages, such as those from NVDIMM DAX devices, are not for MMIO, and can be mapped with cached memory type for better performance. However, the above check misconceives those pages as MMIO. Because KVM maps MMIO pages with UC memory type, the performance of guest accesses to those

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

On Tue, 19 Dec 2017 13:20:43 -0800 Rao Shoaib wrote: > On 12/19/2017 12:41 PM, Jesper Dangaard Brouer wrote: > > On Tue, 19 Dec 2017 09:52:27 -0800 rao.sho...@oracle.com wrote: > > > >> +/* Main RCU function that is called to free RCU structures */ > >> +static void > >>

[PATCH v6 0/2] KVM: MMU: fix kvm_is_mmio_pfn()

Some reserved pages, such as those from NVDIMM DAX devices, are not for MMIO, and can be mapped with cached memory type for better performance. However, the above check misconceives those pages as MMIO. Because KVM maps MMIO pages with UC memory type, the performance of guest accesses to those

[PATCH v6 2/2] KVM: MMU: consider host cache mode in MMIO page check

Some reserved pages, such as those from NVDIMM DAX devices, are not for MMIO, and can be mapped with cached memory type for better performance. However, the above check misconceives those pages as MMIO. Because KVM maps MMIO pages with UC memory type, the performance of guest accesses to those

[PATCH v6 2/2] KVM: MMU: consider host cache mode in MMIO page check

Some reserved pages, such as those from NVDIMM DAX devices, are not for MMIO, and can be mapped with cached memory type for better performance. However, the above check misconceives those pages as MMIO. Because KVM maps MMIO pages with UC memory type, the performance of guest accesses to those

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 13:52, Ian Kent wrote: > On 20/12/17 11:29, NeilBrown wrote: >> >> Hi Ian, >> I've been looking at: >> >>> - add configuration option to use fqdn in mounts. >> >> (commit 9aeef772604) because using this new option causes a regression. >> If you are using the "replicated server"

[PATCH v6 1/2] x86/mm: add a function to check if a pfn is UC/UC-/WCee

Check whether the PAT memory type of a pfn cannot be overridden by MTRR UC memory type, i.e. the PAT memory type is UC, UC- or WC. This function will be used by KVM to determine whether it needs to map a host pfn to guest with UC memory type. Signed-off-by: Haozhong Zhang

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 13:52, Ian Kent wrote: > On 20/12/17 11:29, NeilBrown wrote: >> >> Hi Ian, >> I've been looking at: >> >>> - add configuration option to use fqdn in mounts. >> >> (commit 9aeef772604) because using this new option causes a regression. >> If you are using the "replicated server"

[PATCH v6 1/2] x86/mm: add a function to check if a pfn is UC/UC-/WCee

Check whether the PAT memory type of a pfn cannot be overridden by MTRR UC memory type, i.e. the PAT memory type is UC, UC- or WC. This function will be used by KVM to determine whether it needs to map a host pfn to guest with UC memory type. Signed-off-by: Haozhong Zhang Reviewed-by: Xiao

GOOD DAY FROM MOHAMMED AHMED .

My Dear Friend. I am Mr. Mohammed Ahmed, I work with Bank Of Africa Burkina Faso West Africa as their Auditing Manager. My Dear I am sending you this business proposal in regards to release and transfer of $13.5 M USD into a foreign account. Everything about the transaction shall be done legal

GOOD DAY FROM MOHAMMED AHMED .

My Dear Friend. I am Mr. Mohammed Ahmed, I work with Bank Of Africa Burkina Faso West Africa as their Auditing Manager. My Dear I am sending you this business proposal in regards to release and transfer of $13.5 M USD into a foreign account. Everything about the transaction shall be done legal

[PATCH] staging: ccree: use size_t consistently

Fix declaration, implementation and wrapper function to use the same size_t type we actually define the parameter to be. Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params") Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_driver.c | 2

Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power

On Mon, Dec 11, 2017 at 12:38 AM, Florian Fainelli wrote: > On 12/02/2017 04:48 AM, Linus Walleij wrote: >> This should solve your problem without having to alter the semantics >> of pinctrl_select_state() for everyone. > > This was exactly what I proposed initially here: >

[PATCH] staging: ccree: use size_t consistently

Fix declaration, implementation and wrapper function to use the same size_t type we actually define the parameter to be. Fixes: 3f268f5d6669 ("staging: ccree: turn compile time debug log to params") Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_driver.c | 2 +-

Re: [PATCH v2 2/2] pinctrl: Allow indicating loss of pin states during low-power

On Mon, Dec 11, 2017 at 12:38 AM, Florian Fainelli wrote: > On 12/02/2017 04:48 AM, Linus Walleij wrote: >> This should solve your problem without having to alter the semantics >> of pinctrl_select_state() for everyone. > > This was exactly what I proposed initially here: > >

Re: [PATCH v3 14/16] phy: Add notify_speed callback

Hi, On Wednesday 20 December 2017 11:59 AM, Manu Gautam wrote: > Hi, > > > On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote: >>> Hi, >>> >>> >>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote: Hi, On

Re: [PATCH v3 14/16] phy: Add notify_speed callback

Hi, On Wednesday 20 December 2017 11:59 AM, Manu Gautam wrote: > Hi, > > > On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote: >>> Hi, >>> >>> >>> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote: Hi, On

Re: [PATCH 03/15] staging: lustre: replace simple cases of LIBCFS_ALLOC with kzalloc.

Hi NeilBrown, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] [also build test ERROR on next-20171220] [cannot apply to v4.15-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 03/15] staging: lustre: replace simple cases of LIBCFS_ALLOC with kzalloc.

Hi NeilBrown, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] [also build test ERROR on next-20171220] [cannot apply to v4.15-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v10 1/5] add infrastructure for tagging functions as error injectable

On Tue, 19 Dec 2017 18:14:17 -0800 Alexei Starovoitov wrote: > On 12/18/17 10:29 PM, Masami Hiramatsu wrote: > >> > >> +#if defined(__KERNEL__) && !defined(__ASSEMBLY__) > >> +#ifdef CONFIG_BPF_KPROBE_OVERRIDE > > > > BTW, CONFIG_BPF_KPROBE_OVERRIDE is also confusable name. > >

Re: [PATCH v10 1/5] add infrastructure for tagging functions as error injectable

On Tue, 19 Dec 2017 18:14:17 -0800 Alexei Starovoitov wrote: > On 12/18/17 10:29 PM, Masami Hiramatsu wrote: > >> > >> +#if defined(__KERNEL__) && !defined(__ASSEMBLY__) > >> +#ifdef CONFIG_BPF_KPROBE_OVERRIDE > > > > BTW, CONFIG_BPF_KPROBE_OVERRIDE is also confusable name. > > Since this

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, not sure if you've been following the whole thread, so I'll try to summarize it here. apologies if it'll massively repeat the things that have already been said or will be too long. On (12/19/17 15:31), Michal Hocko wrote: > On Tue 19-12-17 10:24:55, Sergey Senozhatsky wrote: > > On

Re: [RFC][PATCHv6 00/12] printk: introduce printing kernel thread

Hello, not sure if you've been following the whole thread, so I'll try to summarize it here. apologies if it'll massively repeat the things that have already been said or will be too long. On (12/19/17 15:31), Michal Hocko wrote: > On Tue 19-12-17 10:24:55, Sergey Senozhatsky wrote: > > On

[PATCH] gitignore: add *.gcda files

Ignore the *.gcda files generated by gcov Signed-off-by: Jaejoong Kim --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 0c39aa2..580ef7c 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,7 @@ Module.symvers *.dwo *.su

[PATCH] gitignore: add *.gcda files

Ignore the *.gcda files generated by gcov Signed-off-by: Jaejoong Kim --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 0c39aa2..580ef7c 100644 --- a/.gitignore +++ b/.gitignore @@ -39,6 +39,7 @@ Module.symvers *.dwo *.su *.c.[012]*.* +*.gcda

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

On Tue, 19 Dec 2017 16:20:51 -0800 "Paul E. McKenney" wrote: > On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote: > > On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote: > > > If I had to implement this: I would choose to do the

Re: [PATCH] kfree_rcu() should use the new kfree_bulk() interface for freeing rcu structures

On Tue, 19 Dec 2017 16:20:51 -0800 "Paul E. McKenney" wrote: > On Tue, Dec 19, 2017 at 02:12:06PM -0800, Matthew Wilcox wrote: > > On Tue, Dec 19, 2017 at 09:41:58PM +0100, Jesper Dangaard Brouer wrote: > > > If I had to implement this: I would choose to do the optimization in > > >

Re: [PATCH v15 3/5] mfd: Add driver for RAVE Supervisory Processor

Andrey, On Wed, Dec 20, 2017 at 5:00 AM, Andrey Smirnov wrote: > Add a driver for RAVE Supervisory Processor, an MCU implementing > various bits of housekeeping functionality (watchdoging, backlight > control, LED control, etc) on RAVE family of products by Zodiac >

Re: [PATCH v15 3/5] mfd: Add driver for RAVE Supervisory Processor

Andrey, On Wed, Dec 20, 2017 at 5:00 AM, Andrey Smirnov wrote: > Add a driver for RAVE Supervisory Processor, an MCU implementing > various bits of housekeeping functionality (watchdoging, backlight > control, LED control, etc) on RAVE family of products by Zodiac > Inflight Innovations. >

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 14:10, Ian Kent wrote: > On 20/12/17 13:52, Ian Kent wrote: >> On 20/12/17 11:29, NeilBrown wrote: >>> >>> Hi Ian, >>> I've been looking at: >>> - add configuration option to use fqdn in mounts. >>> >>> (commit 9aeef772604) because using this new option causes a regression. >>>

Re: [ANNOUNCE] autofs 5.1.2 release

On 20/12/17 14:10, Ian Kent wrote: > On 20/12/17 13:52, Ian Kent wrote: >> On 20/12/17 11:29, NeilBrown wrote: >>> >>> Hi Ian, >>> I've been looking at: >>> - add configuration option to use fqdn in mounts. >>> >>> (commit 9aeef772604) because using this new option causes a regression. >>>

Re: [PATCH v2] cpufreq: powernv: Add support of frequency domain

On 20-12-17, 12:12, Abhishek Goel wrote: > diff --git a/drivers/cpufreq/powernv-cpufreq.c > b/drivers/cpufreq/powernv-cpufreq.c > index b6d7c4c..fd642bc 100644 > --- a/drivers/cpufreq/powernv-cpufreq.c > +++ b/drivers/cpufreq/powernv-cpufreq.c > @@ -37,6 +37,7 @@ > #include /* Required for

Re: [PATCH v2] cpufreq: powernv: Add support of frequency domain

On 20-12-17, 12:12, Abhishek Goel wrote: > diff --git a/drivers/cpufreq/powernv-cpufreq.c > b/drivers/cpufreq/powernv-cpufreq.c > index b6d7c4c..fd642bc 100644 > --- a/drivers/cpufreq/powernv-cpufreq.c > +++ b/drivers/cpufreq/powernv-cpufreq.c > @@ -37,6 +37,7 @@ > #include /* Required for

Re: [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation

On Thu, Dec 14, 2017 at 05:53:52PM +0100, Mathieu Malaterre wrote: > Improve the DTS files by removing all the leading "0x" and zeros to fix the > following dtc warnings: > > Warning (unit_address_format): Node /XXX unit name should not have leading > "0x" > > and > > Warning

Re: [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation

On Thu, Dec 14, 2017 at 05:53:52PM +0100, Mathieu Malaterre wrote: > Improve the DTS files by removing all the leading "0x" and zeros to fix the > following dtc warnings: > > Warning (unit_address_format): Node /XXX unit name should not have leading > "0x" > > and > > Warning

Re: [PATCH v2 2/5] mm: Extends local cpu counter vm_diff_nodestat from s8 to s16

On 2017年12月20日 01:21, Christopher Lameter wrote: > On Tue, 19 Dec 2017, Michal Hocko wrote: > >>> Well the reason for s8 was to keep the data structures small so that they >>> fit in the higher level cpu caches. The large these structures become the >>> more cachelines are used by the counters

Re: [PATCH v2 2/5] mm: Extends local cpu counter vm_diff_nodestat from s8 to s16

On 2017年12月20日 01:21, Christopher Lameter wrote: > On Tue, 19 Dec 2017, Michal Hocko wrote: > >>> Well the reason for s8 was to keep the data structures small so that they >>> fit in the higher level cpu caches. The large these structures become the >>> more cachelines are used by the counters

Re: [PATCH v2] IPI performance benchmark

Hi Yury, 2017-12-19 16:50 GMT+08:00 Yury Norov : > This benchmark sends many IPIs in different modes and measures > time for IPI delivery (first column), and total time, ie including > time to acknowledge the receive by sender (second column). > > The scenarios are: >

Re: [PATCH v2] IPI performance benchmark

Hi Yury, 2017-12-19 16:50 GMT+08:00 Yury Norov : > This benchmark sends many IPIs in different modes and measures > time for IPI delivery (first column), and total time, ie including > time to acknowledge the receive by sender (second column). > > The scenarios are: > Dry-run:do everything

[PATCH v2] cpufreq: powernv: Add support of frequency domain

Frequency-domain indicates group of CPUs that would share same frequency. It is detected using device-tree node "frequency-domain-indicator". frequency-domain-indicator is a bitmask which will have different value depending upon the generation of the processor. CPUs of the same chip for which the

[PATCH 1/2] clk: mediatek: group drivers under indpendent menu

From: Sean Wang Getting much MediaTek clock driver have been added to CCF, so it's better adding the cleanup for grouping drivers under the independent menu to simplify configuration selection. In addition, really trivial fixups for typos are added in the same patch.

[PATCH v2] cpufreq: powernv: Add support of frequency domain

Frequency-domain indicates group of CPUs that would share same frequency. It is detected using device-tree node "frequency-domain-indicator". frequency-domain-indicator is a bitmask which will have different value depending upon the generation of the processor. CPUs of the same chip for which the

[PATCH 1/2] clk: mediatek: group drivers under indpendent menu

From: Sean Wang Getting much MediaTek clock driver have been added to CCF, so it's better adding the cleanup for grouping drivers under the independent menu to simplify configuration selection. In addition, really trivial fixups for typos are added in the same patch. Signed-off-by: Sean Wang

[PATCH 2/2] clk: mediatek: fixup test-building of MediaTek clock drivers

From: Sean Wang Let the build system looking into the directiory where the clock drivers resides for the COMPILE_TEST alternative dependency allows test-building the drivers. Signed-off-by: Sean Wang --- drivers/clk/Makefile | 2 +- 1 file

[PATCH 2/2] clk: mediatek: fixup test-building of MediaTek clock drivers

From: Sean Wang Let the build system looking into the directiory where the clock drivers resides for the COMPILE_TEST alternative dependency allows test-building the drivers. Signed-off-by: Sean Wang --- drivers/clk/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 1/3] phy: core: Move runtime PM reference counting to the parent device

Hi Ulf, On Wednesday 20 December 2017 02:52 AM, Ulf Hansson wrote: > The runtime PM deployment in the phy core is a bit unnecessary complicated > and the main reason is because it operates on the phy device, which is > created by the phy core and assigned as a child device of the phy provider >

Re: [PATCH 1/3] phy: core: Move runtime PM reference counting to the parent device

Hi Ulf, On Wednesday 20 December 2017 02:52 AM, Ulf Hansson wrote: > The runtime PM deployment in the phy core is a bit unnecessary complicated > and the main reason is because it operates on the phy device, which is > created by the phy core and assigned as a child device of the phy provider >

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

Hi Viresh, On 12/20/2017 11:57 AM, Viresh Kumar wrote: > On 20-12-17, 11:55, Sricharan R wrote: + opp-14 { + opp-hz = /bits/ 64 <14>; + opp-microvolt-speed0-pvs0-v0 = <125>; >>> >>> Why speed0 and v0 in all the names ?

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

Hi Viresh, On 12/20/2017 11:57 AM, Viresh Kumar wrote: > On 20-12-17, 11:55, Sricharan R wrote: + opp-14 { + opp-hz = /bits/ 64 <14>; + opp-microvolt-speed0-pvs0-v0 = <125>; >>> >>> Why speed0 and v0 in all the names ?

Re: [PATCH 1/3] x86/entry: Fix idtentry unwind hint

On Wed, Dec 20, 2017 at 05:41:44AM +, Andrey Vagin wrote: > Hi Josh, > > > Now I see these two warnings on Linus' tree: > > [1.902454] WARNING: stack recursion on stack type 1 > [1.902466] WARNING: can't dereference iret registers at cd089a12 > for ip

Re: [PATCH 1/3] x86/entry: Fix idtentry unwind hint

On Wed, Dec 20, 2017 at 05:41:44AM +, Andrey Vagin wrote: > Hi Josh, > > > Now I see these two warnings on Linus' tree: > > [1.902454] WARNING: stack recursion on stack type 1 > [1.902466] WARNING: can't dereference iret registers at cd089a12 > for ip

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Am 19.12.2017 um 22:21 schrieb Long Li via samba-technical: >> depends on CIFS && INFINIBAND >> +depends on CIFS=m || INFINIBAND=y > > How about we change them to > > depends on CIFS=m && INFINIBAND || CIFS=y && INFINIBAND=y > > This makes it easy to read. I like it :-) metze

Re: [PATCH] CIFS: SMBD: fix configurations with INFINIBAND=m

Am 19.12.2017 um 22:21 schrieb Long Li via samba-technical: >> depends on CIFS && INFINIBAND >> +depends on CIFS=m || INFINIBAND=y > > How about we change them to > > depends on CIFS=m && INFINIBAND || CIFS=y && INFINIBAND=y > > This makes it easy to read. I like it :-) metze

Re: [PATCH v3 14/16] phy: Add notify_speed callback

Hi, On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote: >> Hi, >> >> >> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote: QCOM USB PHYs can

Re: [PATCH v3 14/16] phy: Add notify_speed callback

Hi, On 12/20/2017 11:19 AM, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 12 December 2017 08:54 PM, Manu Gautam wrote: >> Hi, >> >> >> On 12/12/2017 5:13 PM, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>> On Tuesday 21 November 2017 02:53 PM, Manu Gautam wrote: QCOM USB PHYs can

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

On 20-12-17, 11:55, Sricharan R wrote: > >> + opp-14 { > >> + opp-hz = /bits/ 64 <14>; > >> + opp-microvolt-speed0-pvs0-v0 = <125>; > > > > Why speed0 and v0 in all the names ? > > > > Ya, all the three (speed, pvs and version) are

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

On 20-12-17, 11:55, Sricharan R wrote: > >> + opp-14 { > >> + opp-hz = /bits/ 64 <14>; > >> + opp-microvolt-speed0-pvs0-v0 = <125>; > > > > Why speed0 and v0 in all the names ? > > > > Ya, all the three (speed, pvs and version) are

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

Hi Viresh, On 12/20/2017 8:56 AM, Viresh Kumar wrote: > On 19-12-17, 21:25, Sricharan R wrote: >> +cpu@0 { >> +compatible = "qcom,krait"; >> +enable-method = "qcom,kpss-acc-v1"; >> +device_type = "cpu"; >> +reg = <0>; >> +qcom,acc =

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

Hi Viresh, On 12/20/2017 8:56 AM, Viresh Kumar wrote: > On 19-12-17, 21:25, Sricharan R wrote: >> +cpu@0 { >> +compatible = "qcom,krait"; >> +enable-method = "qcom,kpss-acc-v1"; >> +device_type = "cpu"; >> +reg = <0>; >> +qcom,acc =

[PATCH v6 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

Make use of recently introduced device-managed version of i2c_new_dummy to simplify the code. Signed-off-by: Heiner Kallweit --- v2: - small improvements regarding code readability v3: - no changes v4: - no changes v5: - no changes v6: - rebased ---

[PATCH v6 3/3] eeprom: at24: switch to device-managed version of i2c_new_dummy

Make use of recently introduced device-managed version of i2c_new_dummy to simplify the code. Signed-off-by: Heiner Kallweit --- v2: - small improvements regarding code readability v3: - no changes v4: - no changes v5: - no changes v6: - rebased --- drivers/misc/eeprom/at24.c | 32

[PATCH v6 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

Currently i2c_new_device and i2c_new_dummy return just NULL in error case although they have more error details internally. Therefore move the functionality into new functions returning detailed errors and add wrappers for compatibilty with the current API. This allows to use these functions with

[PATCH v6 1/3] i2c: core: improve return value handling of i2c_new_device and i2c_new_dummy

Currently i2c_new_device and i2c_new_dummy return just NULL in error case although they have more error details internally. Therefore move the functionality into new functions returning detailed errors and add wrappers for compatibilty with the current API. This allows to use these functions with

[PATCH v6 2/3] i2c: core: add device-managed version of i2c_new_dummy

i2c_new_dummy is typically called from the probe function of the driver for the primary i2c client. It requires calls to i2c_unregister_device in the error path of the probe function and in the remove function. This can be simplified by introducing a device-managed version. Note the changed error

[PATCH v6 2/3] i2c: core: add device-managed version of i2c_new_dummy

i2c_new_dummy is typically called from the probe function of the driver for the primary i2c client. It requires calls to i2c_unregister_device in the error path of the probe function and in the remove function. This can be simplified by introducing a device-managed version. Note the changed error

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

On 12/18/2017 17:50, Neftin, Sasha wrote: On 12/18/2017 13:58, Pavel Machek wrote: On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote: On 12/18/2017 12:26, Pavel Machek wrote: Hi! In v4.15-rc2+, network manager can not see my ethernet card, and manual attempts to ifconfig it up did not really

Re: [Intel-wired-lan] v4.15-rc2 on thinkpad x60: ethernet stopped working

On 12/18/2017 17:50, Neftin, Sasha wrote: On 12/18/2017 13:58, Pavel Machek wrote: On Mon 2017-12-18 13:24:40, Neftin, Sasha wrote: On 12/18/2017 12:26, Pavel Machek wrote: Hi! In v4.15-rc2+, network manager can not see my ethernet card, and manual attempts to ifconfig it up did not really

Re: [PATCH v1] drm/tegra: gem: Correct iommu_map_sg() error checking

Hi Dmitry, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tegra/for-next] [also build test WARNING on v4.15-rc4 next-20171220] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v1] drm/tegra: gem: Correct iommu_map_sg() error checking

Hi Dmitry, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tegra/for-next] [also build test WARNING on v4.15-rc4 next-20171220] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

Hi Viresh, On 12/20/2017 9:06 AM, Viresh Kumar wrote: > On 19-12-17, 21:24, Sricharan R wrote: >> From: Stephen Boyd >> >> Register a cpufreq-generic device whenever we detect that a >> "qcom,krait" compatible CPU is present in DT. >> >> Cc: >>

Re: [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

Hi Viresh, On 12/20/2017 9:06 AM, Viresh Kumar wrote: > On 19-12-17, 21:24, Sricharan R wrote: >> From: Stephen Boyd >> >> Register a cpufreq-generic device whenever we detect that a >> "qcom,krait" compatible CPU is present in DT. >> >> Cc: >> [Sricharan: updated to use

[PATCH v6 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

i2c_new_dummy is typically called from the probe function of the driver for the primary i2c client. It requires calls to i2c_unregister_device in the error path of the probe function and in the remove function. This can be simplified by introducing a device-managed version. Make at24 driver the

[PATCH v6 0/3] i2c: introduce devm_i2c_new_dummy and use it in at24 driver

i2c_new_dummy is typically called from the probe function of the driver for the primary i2c client. It requires calls to i2c_unregister_device in the error path of the probe function and in the remove function. This can be simplified by introducing a device-managed version. Make at24 driver the

Re: [PATCH V2 net-next 02/17] net: hns3: add support to modify tqps number

On 2017/12/20 3:18, David Miller wrote: From: Lipeng Date: Tue, 19 Dec 2017 12:02:24 +0800 @@ -2651,6 +2651,19 @@ static int hns3_get_ring_config(struct hns3_nic_priv *priv) return ret; } +static void hns3_put_ring_config(struct hns3_nic_priv *priv) +{ +

Re: [PATCH V2 net-next 02/17] net: hns3: add support to modify tqps number

On 2017/12/20 3:18, David Miller wrote: From: Lipeng Date: Tue, 19 Dec 2017 12:02:24 +0800 @@ -2651,6 +2651,19 @@ static int hns3_get_ring_config(struct hns3_nic_priv *priv) return ret; } +static void hns3_put_ring_config(struct hns3_nic_priv *priv) +{ + struct

  1   2   3   4   5   6   7   8   9   10   >