[PATCH 6/7] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

Signed-off-by: Jens Axboe --- block/Kconfig.iosched | 6 + block/Makefile| 1 + block/mq-deadline.c | 638 ++ 3 files changed, 645 insertions(+) create mode 100644 block/mq-deadline.c diff --git a/block/Kconfig.iosched

[PATCH 7/7] blk-mq-sched: allow setting of default IO scheduler

Signed-off-by: Jens Axboe --- block/Kconfig.iosched | 43 +-- block/blk-mq-sched.c| 19 +++ block/blk-mq-sched.h| 2 ++ block/blk-mq.c | 3 +++ block/elevator.c| 5 - drivers/nvme/host/pci.c |

[PATCH 6/7] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

Signed-off-by: Jens Axboe --- block/Kconfig.iosched | 6 + block/Makefile| 1 + block/mq-deadline.c | 638 ++ 3 files changed, 645 insertions(+) create mode 100644 block/mq-deadline.c diff --git a/block/Kconfig.iosched

[PATCH 7/7] blk-mq-sched: allow setting of default IO scheduler

Signed-off-by: Jens Axboe --- block/Kconfig.iosched | 43 +-- block/blk-mq-sched.c| 19 +++ block/blk-mq-sched.h| 2 ++ block/blk-mq.c | 3 +++ block/elevator.c| 5 - drivers/nvme/host/pci.c | 1 +

[PATCH 0/8] enable endian checks for all sparse builds

This is just a reposting of the patch that enables endian checks, with addition of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere. I plan to include this in my pull request unless I hear otherwise. Michael S. Tsirkin (8): linux/types.h: enable endian checks for all

[PATCH 0/8] enable endian checks for all sparse builds

This is just a reposting of the patch that enables endian checks, with addition of trivial patches that drop __bitwise__ and __CHECK_ENDIAN__ everywhere. I plan to include this in my pull request unless I hear otherwise. Michael S. Tsirkin (8): linux/types.h: enable endian checks for all

[PATCH 1/8] linux/types.h: enable endian checks for all sparse builds

By now, linux is mostly endian-clean. Enabling endian-ness checks for everyone produces about 200 new sparse warnings for me - less than 10% over the 2000 sparse warnings already there. Not a big deal, OTOH enabling this helps people notice they are introducing new bugs. So let's just drop

[PATCH 1/8] linux/types.h: enable endian checks for all sparse builds

By now, linux is mostly endian-clean. Enabling endian-ness checks for everyone produces about 200 new sparse warnings for me - less than 10% over the 2000 sparse warnings already there. Not a big deal, OTOH enabling this helps people notice they are introducing new bugs. So let's just drop

[PATCH 4/8] checkpatch: replace __bitwise__ with __bitwise

__bitwise__ is an implementation detail now. Signed-off-by: Michael S. Tsirkin --- scripts/checkpatch.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index fd3556b..982c52c 100755 ---

[PATCH 6/8] Documentation/sparse: drop __CHECK_ENDIAN__

It's no longer used. Signed-off-by: Michael S. Tsirkin --- Documentation/translations/zh_CN/sparse.txt | 7 +-- Documentation/dev-tools/sparse.rst | 7 +-- 2 files changed, 2 insertions(+), 12 deletions(-) diff --git

[PATCH 3/8] Documentation/sparse: drop __bitwise__

We dropped __CHECK_ENDIAN__ so __bitwise__ is now an implementation detail. People should use __bitwise everywhere. Signed-off-by: Michael S. Tsirkin --- Documentation/dev-tools/sparse.rst | 7 --- 1 file changed, 7 deletions(-) diff --git

[PATCH 7/8] fs/logfs: drop __CHECK_ENDIAN__

No need for it anymore: __bitwise checks are now on by default for everyone. Signed-off-by: Michael S. Tsirkin --- fs/logfs/logfs.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/logfs/logfs.h b/fs/logfs/logfs.h index 27d040e..11209ee 100644 ---

[PATCH 4/8] checkpatch: replace __bitwise__ with __bitwise

__bitwise__ is an implementation detail now. Signed-off-by: Michael S. Tsirkin --- scripts/checkpatch.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index fd3556b..982c52c 100755 --- a/scripts/checkpatch.pl +++

[PATCH 6/8] Documentation/sparse: drop __CHECK_ENDIAN__

It's no longer used. Signed-off-by: Michael S. Tsirkin --- Documentation/translations/zh_CN/sparse.txt | 7 +-- Documentation/dev-tools/sparse.rst | 7 +-- 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/Documentation/translations/zh_CN/sparse.txt

[PATCH 3/8] Documentation/sparse: drop __bitwise__

We dropped __CHECK_ENDIAN__ so __bitwise__ is now an implementation detail. People should use __bitwise everywhere. Signed-off-by: Michael S. Tsirkin --- Documentation/dev-tools/sparse.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/Documentation/dev-tools/sparse.rst

[PATCH 7/8] fs/logfs: drop __CHECK_ENDIAN__

No need for it anymore: __bitwise checks are now on by default for everyone. Signed-off-by: Michael S. Tsirkin --- fs/logfs/logfs.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/logfs/logfs.h b/fs/logfs/logfs.h index 27d040e..11209ee 100644 --- a/fs/logfs/logfs.h +++

[PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

That's the default now, no need for makefiles to set it. Signed-off-by: Michael S. Tsirkin --- drivers/bluetooth/Makefile| 2 -- drivers/net/can/Makefile | 1 - drivers/net/ethernet/altera/Makefile

[PATCH 5/8] linux: drop __bitwise__ everywhere

__bitwise__ used to mean "yes, please enable sparse checks unconditionally", but now that we dropped __CHECK_ENDIAN__ __bitwise is exactly the same. There aren't many users, replace it by __bitwise everywhere. Signed-off-by: Michael S. Tsirkin ---

[PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

That's the default now, no need for makefiles to set it. Signed-off-by: Michael S. Tsirkin --- drivers/bluetooth/Makefile| 2 -- drivers/net/can/Makefile | 1 - drivers/net/ethernet/altera/Makefile | 1 -

[PATCH 5/8] linux: drop __bitwise__ everywhere

__bitwise__ used to mean "yes, please enable sparse checks unconditionally", but now that we dropped __CHECK_ENDIAN__ __bitwise is exactly the same. There aren't many users, replace it by __bitwise everywhere. Signed-off-by: Michael S. Tsirkin --- arch/arm/plat-samsung/include/plat/gpio-cfg.h

[PATCH 2/8] tools: enable endian checks for all sparse builds

We dropped need for __CHECK_ENDIAN__ for linux, this mirrors this for tools. Signed-off-by: Michael S. Tsirkin --- tools/include/linux/types.h | 4 1 file changed, 4 deletions(-) diff --git a/tools/include/linux/types.h b/tools/include/linux/types.h index 8ebf627..c24b3e3

[PATCH 2/8] tools: enable endian checks for all sparse builds

We dropped need for __CHECK_ENDIAN__ for linux, this mirrors this for tools. Signed-off-by: Michael S. Tsirkin --- tools/include/linux/types.h | 4 1 file changed, 4 deletions(-) diff --git a/tools/include/linux/types.h b/tools/include/linux/types.h index 8ebf627..c24b3e3 100644 ---

Re: Patch for drm-next WAS Re: [PATCH] kref: prefer atomic_inc_not_zero to atomic_add_unless

On Tue, Jul 12, 2016 at 2:28 PM, Daniel Vetter wrote: > Sure can do, but I can't find the raw patch anywhere (I suck, I know). > Care to resend? Hey sorry I missed this email requesting the actual patch. I reposted it here: https://lkml.org/lkml/2016/12/14/814

Re: Patch for drm-next WAS Re: [PATCH] kref: prefer atomic_inc_not_zero to atomic_add_unless

On Tue, Jul 12, 2016 at 2:28 PM, Daniel Vetter wrote: > Sure can do, but I can't find the raw patch anywhere (I suck, I know). > Care to resend? Hey sorry I missed this email requesting the actual patch. I reposted it here: https://lkml.org/lkml/2016/12/14/814

[PATCH] kref: prefer atomic_inc_not_zero to atomic_add_unless

On most platforms, there exists this ifdef: #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0) This makes this patch functionally useless. However, on PPC, there is actually an explicit definition of atomic_inc_not_zero with its own assembly that is slightly more optimized than

[PATCH] kref: prefer atomic_inc_not_zero to atomic_add_unless

On most platforms, there exists this ifdef: #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0) This makes this patch functionally useless. However, on PPC, there is actually an explicit definition of atomic_inc_not_zero with its own assembly that is slightly more optimized than

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On 12/14/2016 06:50 PM, Eric Wheeler wrote: > Hi Jens, > > I know you're busy, so when you get a moment: > > I've not yet seen your ack/nack on this yet and I want to make sure it > gets in before the merge window closes for v4.10. I rebased it on > for-4.10/block as you asked so its tested

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On 12/14/2016 06:50 PM, Eric Wheeler wrote: > Hi Jens, > > I know you're busy, so when you get a moment: > > I've not yet seen your ack/nack on this yet and I want to make sure it > gets in before the merge window closes for v4.10. I rebased it on > for-4.10/block as you asked so its tested

Re: [PATCH 12/12] dma: Flexcard DMA ringbuffer demux driver

On Wed, Dec 14, 2016 at 01:11:53AM +0100, Holger Dengler wrote: > The Flexcard interface design split packet receive and transmit. All > received packets and card status information are multiplexed with a > Flexcard specific protocol and handled through a DMA capable ringbuffer. > The TX path has

Re: [PATCH 12/12] dma: Flexcard DMA ringbuffer demux driver

On Wed, Dec 14, 2016 at 01:11:53AM +0100, Holger Dengler wrote: > The Flexcard interface design split packet receive and transmit. All > received packets and card status information are multiplexed with a > Flexcard specific protocol and handled through a DMA capable ringbuffer. > The TX path has

Re: [PATCH v2 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical

Dear Sylwester, Could you please review this patch? -- Regards, Chanwoo Choi On 2016년 12월 08일 13:58, Chanwoo Choi wrote: > The ACLK_BUS0/1/2 are used for NoC (Network on Chip). If NoC's clocks are > disabled, the system halt happen. Following clock must be always enabled. > - CLK_ACLK_BUS0_400

Re: [PATCH v2 1/5] clk: samsung: exynos5433: Set NoC (Network On Chip) clocks as critical

Dear Sylwester, Could you please review this patch? -- Regards, Chanwoo Choi On 2016년 12월 08일 13:58, Chanwoo Choi wrote: > The ACLK_BUS0/1/2 are used for NoC (Network on Chip). If NoC's clocks are > disabled, the system halt happen. Following clock must be always enabled. > - CLK_ACLK_BUS0_400

[PATCH] drm/i915: use udelay for very short delays

tested with: x86_64_defconfig (implies CONFIG_DRM_I915) Patch is against 4.9.0 (localversion-next is next-20161214) drivers/gpu/drm/i915/intel_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 5b72c50..19fe86b

[PATCH] drm/i915: use udelay for very short delays

(implies CONFIG_DRM_I915) Patch is against 4.9.0 (localversion-next is next-20161214) drivers/gpu/drm/i915/intel_dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 5b72c50..19fe86b 100644 --- a/drivers/gpu

Re: [PATCH v4 1/4] siphash: add cryptographically secure hashtable function

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161215] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v4 1/4] siphash: add cryptographically secure hashtable function

Hi Jason, [auto build test ERROR on linus/master] [also build test ERROR on v4.9 next-20161215] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/1 linux-next] xfs: remove unnecessary return

On 12/10/16 12:52 AM, Fabian Frederick wrote: > Commit f7a136aee3c1 > ("xfs: several xattr functions can be void") > > updated 2 end of function return 0 to return in void > functions. Remove it. > > Signed-off-by: Fabian Frederick Oh, sure. :) Reviewed-by: Eric Sandeen

Re: [PATCH 1/1 linux-next] xfs: remove unnecessary return

On 12/10/16 12:52 AM, Fabian Frederick wrote: > Commit f7a136aee3c1 > ("xfs: several xattr functions can be void") > > updated 2 end of function return 0 to return in void > functions. Remove it. > > Signed-off-by: Fabian Frederick Oh, sure. :) Reviewed-by: Eric Sandeen > --- >

[GIT PULL] xfs: updates for 4.10-rc1

Hi Linus, Can you please pull the XFS update from the tag below? There is quite a varied bunch of stuff in this update, and some of it you will have already merged through the ext4 tree which imported the dax-4.10-iomap-pmd topic branch from the XFS tree. There is also a new direct IO

[GIT PULL] xfs: updates for 4.10-rc1

Hi Linus, Can you please pull the XFS update from the tag below? There is quite a varied bunch of stuff in this update, and some of it you will have already merged through the ext4 tree which imported the dax-4.10-iomap-pmd topic branch from the XFS tree. There is also a new direct IO

Re: [PATCH v2] mm: fadvise: avoid expensive remote LRU cache draining after FADV_DONTNEED

On Thursday, December 15, 2016 5:00 AM Johannes Weiner wrote: > When FADV_DONTNEED cannot drop all pages in the range, it observes > that some pages might still be on per-cpu LRU caches after recent > instantiation and so initiates remote calls to all CPUs to flush their > local caches. However,

Re: [PATCH v2] mm: fadvise: avoid expensive remote LRU cache draining after FADV_DONTNEED

On Thursday, December 15, 2016 5:00 AM Johannes Weiner wrote: > When FADV_DONTNEED cannot drop all pages in the range, it observes > that some pages might still be on per-cpu LRU caches after recent > instantiation and so initiates remote calls to all CPUs to flush their > local caches. However,

[PATCH v2] platform/x86: thinkpad_acpi: Initialize local in_tablet_mode and type

linux-next reported in_tablet_mode and type may be used uninitialized after: b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into separate function") This turns out to be a false positive as the pr_info call cannot be reached if tp_features.hotkey_tablet (global scope) is 0,

[PATCH v2] platform/x86: thinkpad_acpi: Initialize local in_tablet_mode and type

linux-next reported in_tablet_mode and type may be used uninitialized after: b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into separate function") This turns out to be a false positive as the pr_info call cannot be reached if tp_features.hotkey_tablet (global scope) is 0,

Re: linux-next: build warning after merge of the drivers-x86 tree

On Thu, Dec 15, 2016 at 11:02:19AM +1100, Stephen Rothwell wrote: > Hi Darren, > > On Wed, 14 Dec 2016 14:59:14 -0800 Darren Hart wrote: > > > > On Wed, Dec 14, 2016 at 02:21:38PM -0800, Darren Hart wrote: > > > On Wed, Dec 14, 2016 at 01:50:44PM +1100, Stephen Rothwell

Re: linux-next: build warning after merge of the drivers-x86 tree

On Thu, Dec 15, 2016 at 11:02:19AM +1100, Stephen Rothwell wrote: > Hi Darren, > > On Wed, 14 Dec 2016 14:59:14 -0800 Darren Hart wrote: > > > > On Wed, Dec 14, 2016 at 02:21:38PM -0800, Darren Hart wrote: > > > On Wed, Dec 14, 2016 at 01:50:44PM +1100, Stephen Rothwell wrote: > > > > > > > >

[PATCH] drm/i915: use udelay for very small delays

se here ? Patch was compile tested with: x86_64_defconfig (implies CONFIG_DRM_I915) Patch is against 4.9.0 (localvrsion-next is next-20161214) drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c b/driv

[PATCH] drm/i915: use udelay for very small delays

ile tested with: x86_64_defconfig (implies CONFIG_DRM_I915) Patch is against 4.9.0 (localvrsion-next is next-20161214) drivers/gpu/drm/i915/intel_dsi_pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c b/drivers/gpu/drm/i915/intel_dsi_p

[GIT PULL] Pull request for 4.10 for IPMI

The following changes since commit 9c953d639c2fb97e4e96f7398acbf4b675713b76: Merge branch 'for-linus' of git://git.kernel.dk/linux-block (2016-10-27 10:05:31 -0700) are available in the git repository at: git://git.code.sf.net/p/openipmi/linux-ipmi tags/for-linus-4.10 for you to fetch

[GIT PULL] Pull request for 4.10 for IPMI

The following changes since commit 9c953d639c2fb97e4e96f7398acbf4b675713b76: Merge branch 'for-linus' of git://git.kernel.dk/linux-block (2016-10-27 10:05:31 -0700) are available in the git repository at: git://git.code.sf.net/p/openipmi/linux-ipmi tags/for-linus-4.10 for you to fetch

[GIT PULL]: dmaengine updates for 4.10-rc1

Hi Linus, Here is the dmaengine pull request for 4.10-rc1. A fairly normal update with only driver updates. The ST FDMA driver updates feature the remoteproc changes as well which are coordinated with Bjorn. The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux

[GIT PULL]: dmaengine updates for 4.10-rc1

Hi Linus, Here is the dmaengine pull request for 4.10-rc1. A fairly normal update with only driver updates. The ST FDMA driver updates feature the remoteproc changes as well which are coordinated with Bjorn. The following changes since commit 1001354ca34179f3db924eb66672442a173147dc: Linux

kvm 4.10 merge grumbles wrt suspicious RCU usage , might_sleep() and sched: do not call blocking ops when !TASK_RUNNING

Grumpy master.today, w. tune for maximum bloat PREEMPT config. [ 101.898909] === [ 101.898910] [ INFO: suspicious RCU usage. ] [ 101.898912] 4.10.0-preempt #1 Tainted: GE [ 101.898913] --- [ 101.898914]

kvm 4.10 merge grumbles wrt suspicious RCU usage , might_sleep() and sched: do not call blocking ops when !TASK_RUNNING

Grumpy master.today, w. tune for maximum bloat PREEMPT config. [ 101.898909] === [ 101.898910] [ INFO: suspicious RCU usage. ] [ 101.898912] 4.10.0-preempt #1 Tainted: GE [ 101.898913] --- [ 101.898914]

Re: [PATCH v3] drm/mxsfb: use bus_format to determine LCD bus width

On 12/15/2016 02:28 AM, Stefan Agner wrote: > The LCD bus width does not need to align with the pixel format. The > LCDIF controller automatically converts between pixel formats and > bus width by padding or dropping LSBs. > > The DRM subsystem has the notion of bus_format which allows to >

Re: [PATCH v3] drm/mxsfb: use bus_format to determine LCD bus width

On 12/15/2016 02:28 AM, Stefan Agner wrote: > The LCD bus width does not need to align with the pixel format. The > LCDIF controller automatically converts between pixel formats and > bus width by padding or dropping LSBs. > > The DRM subsystem has the notion of bus_format which allows to >

[PATCH] x86/crash: Update the stale comment in reserve_crashkernel()

CRASH_KERNEL_ADDR_MAX was missing for a long time, update it with more detailed explanation. Cc: Robert LeBlanc Cc: Baoquan He Signed-off-by: Xunlei Pang --- arch/x86/kernel/setup.c | 5 - 1 file changed, 4 insertions(+), 1

[PATCH] x86/crash: Update the stale comment in reserve_crashkernel()

CRASH_KERNEL_ADDR_MAX was missing for a long time, update it with more detailed explanation. Cc: Robert LeBlanc Cc: Baoquan He Signed-off-by: Xunlei Pang --- arch/x86/kernel/setup.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/setup.c

Re: [PATCH 0/6] USB support for Broadcom NSP SoC

On Tue, Dec 13, 2016 at 7:50 AM, Florian Fainelli wrote: > On 11/09/2016 01:33 AM, Yendapally Reddy Dhananjaya Reddy wrote: >> This patch set contains the usb support for Broadcom NSP SoC. >> The usb phy is connected through mdio interface. The mdio interface >> can be used

Re: [PATCH 0/6] USB support for Broadcom NSP SoC

On Tue, Dec 13, 2016 at 7:50 AM, Florian Fainelli wrote: > On 11/09/2016 01:33 AM, Yendapally Reddy Dhananjaya Reddy wrote: >> This patch set contains the usb support for Broadcom NSP SoC. >> The usb phy is connected through mdio interface. The mdio interface >> can be used to access either

linux-next: Tree for Dec 15

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. Changes since 20161214: The btrfs-kdave tree gained a conflict against Linus' tree. The rdma tree gained a conflict against Linus' tree. Non-merge commits (relative

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

On Thu, Dec 15, 2016 at 10:41:04AM +0800, Xing Zheng wrote: > // Frank > > Hi Doug, Brain, > Thanks for the reply. > Sorry I forgot these patches have been sent earlier, and Frank > have some explained and discussed with Heiko. > Please see https://patchwork.kernel.org/patch/9255245/ >

linux-next: Tree for Dec 15

Hi all, Please do not add any material for v4.11 to your linux-next included branches until after v4.10-rc1 has been released. Changes since 20161214: The btrfs-kdave tree gained a conflict against Linus' tree. The rdma tree gained a conflict against Linus' tree. Non-merge commits (relative

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

On Thu, Dec 15, 2016 at 10:41:04AM +0800, Xing Zheng wrote: > // Frank > > Hi Doug, Brain, > Thanks for the reply. > Sorry I forgot these patches have been sent earlier, and Frank > have some explained and discussed with Heiko. > Please see https://patchwork.kernel.org/patch/9255245/ >

Re: [PATCH] arm64: mm: Fix NOMAP page initialization

hi Robert, On 2016/12/14 17:45, Robert Richter wrote: > On 12.12.16 17:53:02, Yisheng Xie wrote: >> It seems that memblock_is_memory() is also too strict for early_pfn_valid, >> so what about this patch, which use common pfn_valid as early_pfn_valid >> when CONFIG_HAVE_ARCH_PFN_VALID=y: >>

Re: [PATCH] arm64: mm: Fix NOMAP page initialization

hi Robert, On 2016/12/14 17:45, Robert Richter wrote: > On 12.12.16 17:53:02, Yisheng Xie wrote: >> It seems that memblock_is_memory() is also too strict for early_pfn_valid, >> so what about this patch, which use common pfn_valid as early_pfn_valid >> when CONFIG_HAVE_ARCH_PFN_VALID=y: >>

Re: [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT

On 2016/12/14 22:45, Ard Biesheuvel wrote: > On 14 December 2016 at 14:19, zhongjiang wrote: >> From: zhong jiang >> >> I think that CONT_PTE_SHIFT is more reasonable even if they are some >> value. and the patch is not any functional change. >> >

Re: [RESEND PATCH 1/2] arm64: change from CONT_PMD_SHIFT to CONT_PTE_SHIFT

On 2016/12/14 22:45, Ard Biesheuvel wrote: > On 14 December 2016 at 14:19, zhongjiang wrote: >> From: zhong jiang >> >> I think that CONT_PTE_SHIFT is more reasonable even if they are some >> value. and the patch is not any functional change. >> > This may be the case for 64k pages, but not for

Re: Build failures due to missing 'posix_timer_event'

Hello, On Wed, Dec 14, 2016 at 10:14:39AM -0500, Nicolas Pitre wrote: > On Wed, 14 Dec 2016, Guenter Roeck wrote: > > > avr32:allnoconfig: > > > > kernel/built-in.o: In function `do_adjtimex': > > (.text+0x1d748): undefined reference to `posix_timer_event' > > make[1]: *** [vmlinux] Error 1 > >

Re: Build failures due to missing 'posix_timer_event'

Hello, On Wed, Dec 14, 2016 at 10:14:39AM -0500, Nicolas Pitre wrote: > On Wed, 14 Dec 2016, Guenter Roeck wrote: > > > avr32:allnoconfig: > > > > kernel/built-in.o: In function `do_adjtimex': > > (.text+0x1d748): undefined reference to `posix_timer_event' > > make[1]: *** [vmlinux] Error 1 > >

Re: [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs

On Thu, 15 Dec 2016 01:09:20 +0100 Pali Rohár wrote: > On Thursday 15 December 2016 00:52:24 Russell King - ARM Linux wrote: > > On Wed, Dec 14, 2016 at 10:12:43PM +0100, Pali Rohár wrote: > > > Commit 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi > > > usage") broke

Re: [PATCH] arm: dt: Initialize boot_command_line from CONFIG_CMDLINE in case DT does not provide /chosen/bootargs

On Thu, 15 Dec 2016 01:09:20 +0100 Pali Rohár wrote: > On Thursday 15 December 2016 00:52:24 Russell King - ARM Linux wrote: > > On Wed, Dec 14, 2016 at 10:12:43PM +0100, Pali Rohár wrote: > > > Commit 008a2ebcd677 ("ARM: dts: omap3: Remove skeleton.dtsi > > > usage") broke support for setting

RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday, December 10, 2016 7:21 AM > To: Stephen Hemminger > Cc: Haiyang Zhang ; o...@aepfle.de; > jasow...@redhat.com; linux-kernel@vger.kernel.org; >

RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday, December 10, 2016 7:21 AM > To: Stephen Hemminger > Cc: Haiyang Zhang ; o...@aepfle.de; > jasow...@redhat.com; linux-kernel@vger.kernel.org; > bjorn.helg...@gmail.com; a...@canonical.com;

[GIT PULL] modules updates for 4.10

Linus, Please pull below to receive modules updates for the 4.10 merge window. This development cycle has been pretty quiet, mostly code cleanups, small bugfixes. Summary and details in the tag. Thanks, Jessica --- The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6:

[GIT PULL] modules updates for 4.10

Linus, Please pull below to receive modules updates for the 4.10 merge window. This development cycle has been pretty quiet, mostly code cleanups, small bugfixes. Summary and details in the tag. Thanks, Jessica --- The following changes since commit a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6:

[RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

->qsmask of an RCU leaf node is usually more sparse than the corresponding cpu_possible_mask. So replace the for_each_leaf_node_possible_cpu() in force_qs_rnp() with for_each_leaf_node_cpu() to save several checks. [Note we need to use "1UL << bit" instead of "1 << bit" to generate the

[RFC v2 4/5] rcu: Use for_each_leaf_node_cpu() in force_qs_rnp()

->qsmask of an RCU leaf node is usually more sparse than the corresponding cpu_possible_mask. So replace the for_each_leaf_node_possible_cpu() in force_qs_rnp() with for_each_leaf_node_cpu() to save several checks. [Note we need to use "1UL << bit" instead of "1 << bit" to generate the

[RFC v2 3/5] rcu: Use for_each_leaf_node_cpu() in ->expmask iteration

The ->expmask of an RCU leaf node should be more sparse than the corresponding part of cpu_possible_mask, iterating over ->expmask bitmap rather cpu_possible_mask to save some checks. Signed-off-by: Boqun Feng --- kernel/rcu/tree_exp.h | 16 1 file

[RFC v2 2/5] rcu: Use for_each_leaf_node_cpu() in RCU stall checking

Use for_each_leaf_node_cpu() in RCU stall checking code, to save some extra checks, based on the fact that ->qsmask is mostly more sparse than cpu_possible_mask. Signed-off-by: Boqun Feng --- kernel/rcu/tree.c | 20 ++-- 1 file changed, 10 insertions(+), 10

[RFC v2 5/5] rcu: Use for_each_leaf_node_cpu() in online CPU iteration

Though mostly identical, ->qsmaskinit(A.K.A rcu_rnp_online_cpus()) is sometimes more sparse than the corresponding part of cpu_possible_mask for an RCU leaf node. So we use for_each_leaf_node_cpu() in rcu_boost_kthread_setaffinity() instead to save some extra checks. Signed-off-by: Boqun Feng

[RFC v2 3/5] rcu: Use for_each_leaf_node_cpu() in ->expmask iteration

The ->expmask of an RCU leaf node should be more sparse than the corresponding part of cpu_possible_mask, iterating over ->expmask bitmap rather cpu_possible_mask to save some checks. Signed-off-by: Boqun Feng --- kernel/rcu/tree_exp.h | 16 1 file changed, 4 insertions(+), 12

[RFC v2 2/5] rcu: Use for_each_leaf_node_cpu() in RCU stall checking

Use for_each_leaf_node_cpu() in RCU stall checking code, to save some extra checks, based on the fact that ->qsmask is mostly more sparse than cpu_possible_mask. Signed-off-by: Boqun Feng --- kernel/rcu/tree.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff

[RFC v2 5/5] rcu: Use for_each_leaf_node_cpu() in online CPU iteration

Though mostly identical, ->qsmaskinit(A.K.A rcu_rnp_online_cpus()) is sometimes more sparse than the corresponding part of cpu_possible_mask for an RCU leaf node. So we use for_each_leaf_node_cpu() in rcu_boost_kthread_setaffinity() instead to save some extra checks. Signed-off-by: Boqun Feng

[RFC v2 1/5] rcu: Introduce for_each_leaf_node_cpu()

There are some places inside RCU core, where we need to iterate all mask (->qsmask, ->expmask, etc) bits in a leaf node, in order to iterate all corresponding CPUs. The current code iterates all possible CPUs in this leaf node and then checks with the mask to see whether the bit is set. However,

[RFC v2 0/5] rcu: Introduce for_each_leaf_node_cpu()

v1: https://marc.info/?l=linux-kernel=148127336205765 Changes since v1: * Rename the primitive to for_each_leaf_node_cpu() for a shorter and hopefully better name * Fix a bug report by Colin King about bit shifting * Drop iterator @bit based on suggestions from Mark

[RFC v2 1/5] rcu: Introduce for_each_leaf_node_cpu()

There are some places inside RCU core, where we need to iterate all mask (->qsmask, ->expmask, etc) bits in a leaf node, in order to iterate all corresponding CPUs. The current code iterates all possible CPUs in this leaf node and then checks with the mask to see whether the bit is set. However,

[RFC v2 0/5] rcu: Introduce for_each_leaf_node_cpu()

v1: https://marc.info/?l=linux-kernel=148127336205765 Changes since v1: * Rename the primitive to for_each_leaf_node_cpu() for a shorter and hopefully better name * Fix a bug report by Colin King about bit shifting * Drop iterator @bit based on suggestions from Mark

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

// Frank Hi Doug, Brain, Thanks for the reply. Sorry I forgot these patches have been sent earlier, and Frank have some explained and discussed with Heiko. Please see https://patchwork.kernel.org/patch/9255245/ Perhaps we can move to that patch tree to continue the discussion.

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

// Frank Hi Doug, Brain, Thanks for the reply. Sorry I forgot these patches have been sent earlier, and Frank have some explained and discussed with Heiko. Please see https://patchwork.kernel.org/patch/9255245/ Perhaps we can move to that patch tree to continue the discussion.

[PATCH V2] Coccinelle: check usleep_range() usage

0 where max < min (0.00%) Total: Bugs: 6.48%-10.70%* Crit: 3.09%-3.15%* (min < 10, min==max, max < min) Detectable by coccinelle: Bugs: 74/103 (71.8%) Crit: 50/52 (96.1%) * numbers estimated based on code review Patch is againts 4.9.0 (localversion-next is next-20161214) s

[PATCH V2] Coccinelle: check usleep_range() usage

.48%-10.70%* Crit: 3.09%-3.15%* (min < 10, min==max, max < min) Detectable by coccinelle: Bugs: 74/103 (71.8%) Crit: 50/52 (96.1%) * numbers estimated based on code review Patch is againts 4.9.0 (localversion-next is next-20161214) scripts/coccinelle/api/bad_usleep_range.c

Re: [PATCH] ocfs2: fix crash caused by stale lvb with fsdlm plugin

Hi, On 12/15/2016 09:46 AM, Joseph Qi wrote: In you description, this issue can only happen in case of stack user + fsdlm. Yes. So I feel we'd better to make stack user and o2cb behaves the same, other than treat it as a special case. Yes, I agree. But, actually, there is nothing wrong

Re: [PATCH] ocfs2: fix crash caused by stale lvb with fsdlm plugin

Hi, On 12/15/2016 09:46 AM, Joseph Qi wrote: In you description, this issue can only happen in case of stack user + fsdlm. Yes. So I feel we'd better to make stack user and o2cb behaves the same, other than treat it as a special case. Yes, I agree. But, actually, there is nothing wrong

Re: [PATCH/RFC] z3fold: add kref refcounting

On Thu, Dec 8, 2016 at 6:24 AM, Vitaly Wool wrote: > > Even with already present locking optimizations (and with the so...is your patch series for z3fold that's in mmotm getting resent? Wouldn't that be better than re-patching mistakes from the previous patches? None of

Re: [PATCH/RFC] z3fold: add kref refcounting

On Thu, Dec 8, 2016 at 6:24 AM, Vitaly Wool wrote: > > Even with already present locking optimizations (and with the so...is your patch series for z3fold that's in mmotm getting resent? Wouldn't that be better than re-patching mistakes from the previous patches? None of it's gone upstream to

[PATCH v8 1/1] crypto: add virtio-crypto driver

This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by

[PATCH v8 1/1] crypto: add virtio-crypto driver

This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by

[PATCH v8 0/1] virtio-crypto: add Linux driver

v8: - use per virtqueue lock instead of a whole device lock for data virtuqueue. [Halil & Xin] v7: - fix "BUG: smp_processor_id() in preemptible [] code" reported by Halil, using get_cpu/put_cpu instead of calling smp_processor_id() directly. - fix a possible spinlock recursion

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Wed, 14 Dec 2016 15:04:36 +0100 Hannes Frederic Sowa wrote: > On 09.12.2016 17:03, Greg Kroah-Hartman wrote: > > On Sat, Dec 10, 2016 at 01:56:53AM +1000, Nicholas Piggin wrote: > >> On Fri, 9 Dec 2016 15:36:04 +0100 > >> Stanislav Kozina wrote: > >>

<    1   2   3   4   5   6   7   8   9   10   >