Re: [PATCH] auxdisplay: ht16k33: select CONFIG_FB_SYS_FOPS

Hi Arnd, On Wed, 23 Nov 2016 14:06:49 +0100 Arnd Bergmann wrote: > The new driver caused a rare randconfig failure: > > drivers/auxdisplay/ht16k33.o:(.data.ht16k33_fb_ops+0xc): undefined reference > to `fb_sys_read' > drivers/auxdisplay/ht16k33.o:(.data.ht16k33_fb_ops+0x10):

Re: [PATCH] auxdisplay: ht16k33: select CONFIG_FB_SYS_FOPS

Hi Arnd, On Wed, 23 Nov 2016 14:06:49 +0100 Arnd Bergmann wrote: > The new driver caused a rare randconfig failure: > > drivers/auxdisplay/ht16k33.o:(.data.ht16k33_fb_ops+0xc): undefined reference > to `fb_sys_read' > drivers/auxdisplay/ht16k33.o:(.data.ht16k33_fb_ops+0x10): undefined

[PATCH] regulator: twl: drop of_match_ptr

We can safely drop of_match_ptr since the driver depends on CONFIG_OF symbol Signed-off-by: Nicolae Rosia --- Depends on "regulator: twl6030: add dependency on OF". After sending that one I realised that twl-regulator can also have that change. You can squash these two

[PATCH] regulator: twl: drop of_match_ptr

We can safely drop of_match_ptr since the driver depends on CONFIG_OF symbol Signed-off-by: Nicolae Rosia --- Depends on "regulator: twl6030: add dependency on OF". After sending that one I realised that twl-regulator can also have that change. You can squash these two if you like.

Re: Multiple problems with the Linux kernel on an AMD desktop

On Thu, Nov 24, 2016 at 09:39:57PM -0200, Rogério Brito wrote: > Before I go on describing the problems that I have, I want to say that I can > bisect the kernel, apply patches and give feedback for the problems that I > am seeing. Good. We're going to need them. Please checkout lates Linus

Re: Multiple problems with the Linux kernel on an AMD desktop

On Thu, Nov 24, 2016 at 09:39:57PM -0200, Rogério Brito wrote: > Before I go on describing the problems that I have, I want to say that I can > bisect the kernel, apply patches and give feedback for the problems that I > am seeing. Good. We're going to need them. Please checkout lates Linus

[PATCH] regulator: twl6030: add dependency on OF

This driver was converted to device tree only, add dependency on OF symbol and drop of_match_ptr Signed-off-by: Nicolae Rosia --- drivers/regulator/Kconfig | 1 + drivers/regulator/twl6030-regulator.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)

[PATCH] regulator: twl6030: add dependency on OF

This driver was converted to device tree only, add dependency on OF symbol and drop of_match_ptr Signed-off-by: Nicolae Rosia --- drivers/regulator/Kconfig | 1 + drivers/regulator/twl6030-regulator.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] z3fold: use %z modifier for format string

Hi Joe, On Thu, Nov 24, 2016 at 6:08 PM, Joe Perches wrote: > On Thu, 2016-11-24 at 17:31 +0100, Arnd Bergmann wrote: >> Printing a size_t requires the %zd format rather than %d: >> >> mm/z3fold.c: In function ‘init_z3fold’: >> include/linux/kern_levels.h:4:18: error: format

Re: [PATCH] z3fold: use %z modifier for format string

Hi Joe, On Thu, Nov 24, 2016 at 6:08 PM, Joe Perches wrote: > On Thu, 2016-11-24 at 17:31 +0100, Arnd Bergmann wrote: >> Printing a size_t requires the %zd format rather than %d: >> >> mm/z3fold.c: In function ‘init_z3fold’: >> include/linux/kern_levels.h:4:18: error: format ‘%d’ expects

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Fri, Nov 25, 2016 at 06:06:42PM +1100, Dave Chinner wrote: > > Tell that to Linus. You had been in the room, IIRC, when that had been > > brought up this year in Santa Fe. > > No, I wasn't at KS or plumbers, so this is all news to me. Sorry, thought you had been at KS ;-/ My apologies...

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Fri, Nov 25, 2016 at 06:06:42PM +1100, Dave Chinner wrote: > > Tell that to Linus. You had been in the room, IIRC, when that had been > > brought up this year in Santa Fe. > > No, I wasn't at KS or plumbers, so this is all news to me. Sorry, thought you had been at KS ;-/ My apologies...

Re: [PATCH] z3fold: use %z modifier for format string

Hi Arnd, On Thu, Nov 24, 2016 at 5:31 PM, Arnd Bergmann wrote: > Printing a size_t requires the %zd format rather than %d: > > mm/z3fold.c: In function ‘init_z3fold’: > include/linux/kern_levels.h:4:18: error: format ‘%d’ expects argument of type > ‘int’, but argument 2 has type

Re: [PATCH] z3fold: use %z modifier for format string

Hi Arnd, On Thu, Nov 24, 2016 at 5:31 PM, Arnd Bergmann wrote: > Printing a size_t requires the %zd format rather than %d: > > mm/z3fold.c: In function ‘init_z3fold’: > include/linux/kern_levels.h:4:18: error: format ‘%d’ expects argument of type > ‘int’, but argument 2 has type ‘long unsigned

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

Hi Viresh, On 11/25/2016 03:57 PM, Viresh Kumar wrote: > On 25-11-16, 10:54, Joonyoung Shim wrote: >> I found this problem during system suspend/resume of Odroid-XU3 board. >> >> # rtcwake -m mem -s 3 >> wakeup from "mem" at Wed Apr 4 05:54:44 2001 >> [ 15.965996] PM: Syncing filesystems ...

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

Hi Viresh, On 11/25/2016 03:57 PM, Viresh Kumar wrote: > On 25-11-16, 10:54, Joonyoung Shim wrote: >> I found this problem during system suspend/resume of Odroid-XU3 board. >> >> # rtcwake -m mem -s 3 >> wakeup from "mem" at Wed Apr 4 05:54:44 2001 >> [ 15.965996] PM: Syncing filesystems ...

Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

On 11/25/2016 03:53 PM, Viresh Kumar wrote: > Joonyoung Shim reported an interesting problem on his ARM octa-core > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > was failing for a struct device for which dev_pm_opp_set_regulator() is > called earlier. > > This happened

Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

On 11/25/2016 03:53 PM, Viresh Kumar wrote: > Joonyoung Shim reported an interesting problem on his ARM octa-core > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > was failing for a struct device for which dev_pm_opp_set_regulator() is > called earlier. > > This happened

Re: automatic IRQ affinity for virtio

Btw, what's the best way to get any response to this series? But this and the predecessor seem to have completly fallen on deaf ears.

Re: automatic IRQ affinity for virtio

Btw, what's the best way to get any response to this series? But this and the predecessor seem to have completly fallen on deaf ears.

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Fri, Nov 25, 2016 at 04:14:19AM +, Al Viro wrote: > [Linus Cc'd] > > On Fri, Nov 25, 2016 at 01:49:18PM +1100, Dave Chinner wrote: > > > they have become parts of stable userland ABI and are to be maintained > > > indefinitely. Don't expect "tracepoints are special case" to prevent > > >

Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing

On Fri, Nov 25, 2016 at 04:14:19AM +, Al Viro wrote: > [Linus Cc'd] > > On Fri, Nov 25, 2016 at 01:49:18PM +1100, Dave Chinner wrote: > > > they have become parts of stable userland ABI and are to be maintained > > > indefinitely. Don't expect "tracepoints are special case" to prevent > > >

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

On 25-11-16, 10:54, Joonyoung Shim wrote: > I found this problem during system suspend/resume of Odroid-XU3 board. > > # rtcwake -m mem -s 3 > wakeup from "mem" at Wed Apr 4 05:54:44 2001 > [ 15.965996] PM: Syncing filesystems ... done. > [ 15.976333] Freezing user space processes ...

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

On 25-11-16, 10:54, Joonyoung Shim wrote: > I found this problem during system suspend/resume of Odroid-XU3 board. > > # rtcwake -m mem -s 3 > wakeup from "mem" at Wed Apr 4 05:54:44 2001 > [ 15.965996] PM: Syncing filesystems ... done. > [ 15.976333] Freezing user space processes ...

Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

On 25-11-16, 12:23, Viresh Kumar wrote: > Joonyoung Shim reported an interesting problem on his ARM octa-core > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > was failing for a struct device for which dev_pm_opp_set_regulator() is > called earlier. > > This happened

Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

On 25-11-16, 12:23, Viresh Kumar wrote: > Joonyoung Shim reported an interesting problem on his ARM octa-core > Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() > was failing for a struct device for which dev_pm_opp_set_regulator() is > called earlier. > > This happened

[PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

Joonyoung Shim reported an interesting problem on his ARM octa-core Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() was failing for a struct device for which dev_pm_opp_set_regulator() is called earlier. This happened because an earlier call to

[PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

Joonyoung Shim reported an interesting problem on his ARM octa-core Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator() was failing for a struct device for which dev_pm_opp_set_regulator() is called earlier. This happened because an earlier call to

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

> Mark Lord [mailto:ml...@pobox.com] > > Sent: Friday, November 25, 2016 12:44 AM > [...] > > The bad data in this case is ASCII: > > > > "SRC=m3400:/ TARGET=/m340" > > > > This data is what is seen in /run/mount/utab, a file that is read/written > > over NFS > on > > each boot. > > > >

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

> Mark Lord [mailto:ml...@pobox.com] > > Sent: Friday, November 25, 2016 12:44 AM > [...] > > The bad data in this case is ASCII: > > > > "SRC=m3400:/ TARGET=/m340" > > > > This data is what is seen in /run/mount/utab, a file that is read/written > > over NFS > on > > each boot. > > > >

[tip:efi/core] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

Commit-ID: 018edcfac4c3b140366ad51b0907f3becb5bb624 Gitweb: http://git.kernel.org/tip/018edcfac4c3b140366ad51b0907f3becb5bb624 Author: Ard Biesheuvel AuthorDate: Thu, 24 Nov 2016 18:02:23 + Committer: Ingo Molnar CommitDate: Fri, 25 Nov

[tip:x86/asm] x86/boot/64: Use defines for page size

Commit-ID: 9b032d21f6482ee305dcdec418c15153614b1dcc Gitweb: http://git.kernel.org/tip/9b032d21f6482ee305dcdec418c15153614b1dcc Author: Borislav Petkov AuthorDate: Thu, 24 Nov 2016 22:05:50 +0100 Committer: Ingo Molnar CommitDate: Fri, 25 Nov 2016

[tip:efi/core] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

Commit-ID: 018edcfac4c3b140366ad51b0907f3becb5bb624 Gitweb: http://git.kernel.org/tip/018edcfac4c3b140366ad51b0907f3becb5bb624 Author: Ard Biesheuvel AuthorDate: Thu, 24 Nov 2016 18:02:23 + Committer: Ingo Molnar CommitDate: Fri, 25 Nov 2016 07:15:23 +0100 efi/libstub: Make

[tip:x86/asm] x86/boot/64: Use defines for page size

Commit-ID: 9b032d21f6482ee305dcdec418c15153614b1dcc Gitweb: http://git.kernel.org/tip/9b032d21f6482ee305dcdec418c15153614b1dcc Author: Borislav Petkov AuthorDate: Thu, 24 Nov 2016 22:05:50 +0100 Committer: Ingo Molnar CommitDate: Fri, 25 Nov 2016 07:11:29 +0100 x86/boot/64: Use

[tip:locking/urgent] locking/selftest: Fix output since KERN_CONT changes

Commit-ID: 2513940989fa2c56d0aeb4f5792d22804d92ab4c Gitweb: http://git.kernel.org/tip/2513940989fa2c56d0aeb4f5792d22804d92ab4c Author: Michael Ellerman AuthorDate: Fri, 25 Nov 2016 09:45:28 +1100 Committer: Ingo Molnar CommitDate: Fri, 25 Nov 2016

[tip:locking/urgent] locking/selftest: Fix output since KERN_CONT changes

Commit-ID: 2513940989fa2c56d0aeb4f5792d22804d92ab4c Gitweb: http://git.kernel.org/tip/2513940989fa2c56d0aeb4f5792d22804d92ab4c Author: Michael Ellerman AuthorDate: Fri, 25 Nov 2016 09:45:28 +1100 Committer: Ingo Molnar CommitDate: Fri, 25 Nov 2016 07:12:19 +0100 locking/selftest: Fix

Re: [PATCH] drm/hisilicon/hibmc: mark PM functions __maybe_unused

On Thu, Nov 24, 2016 at 05:30:26PM +0100, Arnd Bergmann wrote: > When CONFIG_PM_SLEEP is disabled, we get a harmless warning > > drm/hisilicon/hibmc/hibmc_drm_drv.c:115:12: error: ‘hibmc_pm_resume’ defined > but not used [-Werror=unused-function] > drm/hisilicon/hibmc/hibmc_drm_drv.c:97:12:

Re: [PATCH] drm/hisilicon/hibmc: mark PM functions __maybe_unused

On Thu, Nov 24, 2016 at 05:30:26PM +0100, Arnd Bergmann wrote: > When CONFIG_PM_SLEEP is disabled, we get a harmless warning > > drm/hisilicon/hibmc/hibmc_drm_drv.c:115:12: error: ‘hibmc_pm_resume’ defined > but not used [-Werror=unused-function] > drm/hisilicon/hibmc/hibmc_drm_drv.c:97:12:

Re: [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

On Fri, Nov 25, 2016 at 01:28:47AM +0100, meg...@megous.com wrote: > From: Ondrej Jirman > > When adjusting PLL_CPUX on H3, the PLL is temporarily driven > too high, and the system becomes unstable (oopses or hangs). > > Add a notifier to avoid this situation by temporarily

Re: [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

On Fri, Nov 25, 2016 at 01:28:47AM +0100, meg...@megous.com wrote: > From: Ondrej Jirman > > When adjusting PLL_CPUX on H3, the PLL is temporarily driven > too high, and the system becomes unstable (oopses or hangs). > > Add a notifier to avoid this situation by temporarily switching > to a

Re: [PATCH] staging: most: Eliminate symbolic permissions usage

On Thu, Nov 24, 2016 at 03:10:29PM -0700, Jason Litzinger wrote: > Fix checkpatch warnings regarding the use of symbolic permissions. > > Where the MOST_CHANNEL_ATTR macro is used, convert to octal permissions > over symbolic. > > Where _ATTR is used directly, replace with _ATTR_RW/_ATTR_WO and

Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on

On Fri, Nov 25, 2016 at 1:23 AM, Laurent Pinchart wrote: >> > Daniel, why do we have an API the is clearly related to interrupt handling >> > but requires the caller to implement a workqueue ? >> >> Because in general you need that workqueue anyway, and up to

Re: [PATCH] staging: most: Eliminate symbolic permissions usage

On Thu, Nov 24, 2016 at 03:10:29PM -0700, Jason Litzinger wrote: > Fix checkpatch warnings regarding the use of symbolic permissions. > > Where the MOST_CHANNEL_ATTR macro is used, convert to octal permissions > over symbolic. > > Where _ATTR is used directly, replace with _ATTR_RW/_ATTR_WO and

Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on

On Fri, Nov 25, 2016 at 1:23 AM, Laurent Pinchart wrote: >> > Daniel, why do we have an API the is clearly related to interrupt handling >> > but requires the caller to implement a workqueue ? >> >> Because in general you need that workqueue anyway, and up to now there was >> no driver ever who

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord [mailto:ml...@pobox.com] > Sent: Friday, November 25, 2016 12:44 AM [...] > The bad data in this case is ASCII: > > "SRC=m3400:/ TARGET=/m340" > > This data is what is seen in /run/mount/utab, a file that is read/written > over NFS on > each boot. > > "SRC=m3400:/

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord [mailto:ml...@pobox.com] > Sent: Friday, November 25, 2016 12:44 AM [...] > The bad data in this case is ASCII: > > "SRC=m3400:/ TARGET=/m340" > > This data is what is seen in /run/mount/utab, a file that is read/written > over NFS on > each boot. > > "SRC=m3400:/

Re: [PATCH 1/1 linux-next] ext4: add compatibility flag check

> On 25 November 2016 at 06:26 Theodore Ts'o wrote: > > > On Thu, Nov 24, 2016 at 08:47:41PM +0100, Fabian Frederick wrote: > > data=journal mount option should disable O_DIRECT access > > (See Documentation/filesystems/ext4.txt) but open operations > > using

Re: [PATCH 1/1 linux-next] ext4: add compatibility flag check

> On 25 November 2016 at 06:26 Theodore Ts'o wrote: > > > On Thu, Nov 24, 2016 at 08:47:41PM +0100, Fabian Frederick wrote: > > data=journal mount option should disable O_DIRECT access > > (See Documentation/filesystems/ext4.txt) but open operations > > using O_CREAT|O_RDWR|O_DIRECT|O_SYNC have

Re: [PATCH v2] dmaengine: sun6i: fix the uninitialized value for v_lli

On Sun, Nov 20, 2016 at 12:43:56AM +0800, Hao Zhang wrote: > dma_pool_alloc does not initialize the value of the newly allocated > block for the v_lli, and the uninitilize value make the tests failed > which is on pine64 with dmatest. > we can fix it just change the "|=" to "=" for the v_lli->cfg.

Re: [PATCH v2] dmaengine: sun6i: fix the uninitialized value for v_lli

On Sun, Nov 20, 2016 at 12:43:56AM +0800, Hao Zhang wrote: > dma_pool_alloc does not initialize the value of the newly allocated > block for the v_lli, and the uninitilize value make the tests failed > which is on pine64 with dmatest. > we can fix it just change the "|=" to "=" for the v_lli->cfg.

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord [mailto:ml...@pobox.com] > Sent: Thursday, November 24, 2016 11:25 PM [...] > x86 has near fully-coherent memory, so it is the "easy" platform > to get things working on. But Linux supports a very diverse number > of platforms, with varying degrees of cache/memory coherency, > and it

RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

Mark Lord [mailto:ml...@pobox.com] > Sent: Thursday, November 24, 2016 11:25 PM [...] > x86 has near fully-coherent memory, so it is the "easy" platform > to get things working on. But Linux supports a very diverse number > of platforms, with varying degrees of cache/memory coherency, > and it

Re: [PATCH] dmaengine: mv_xor: use builtin_platform_driver

On Fri, Nov 18, 2016 at 10:12:26PM +0800, Geliang Tang wrote: > Use builtin_platform_driver() helper to simplify the code. Applied, thanks -- ~Vinod

Re: [PATCH] dmaengine: mv_xor: use builtin_platform_driver

On Fri, Nov 18, 2016 at 10:12:26PM +0800, Geliang Tang wrote: > Use builtin_platform_driver() helper to simplify the code. Applied, thanks -- ~Vinod

RE: [PATCH V3 2/4] mfd: pv88080: MFD core support

On Monday, November 21, 2016 10:09 PM, Lee Jones Wrote: > > On Fri, 18 Nov 2016, Eric Jeong wrote: > > > > > From: Eric Jeong > > > > This patch adds supports for PV88080 MFD core device. > > > > It provides communication through the I2C interface. > > It

RE: [PATCH V3 2/4] mfd: pv88080: MFD core support

On Monday, November 21, 2016 10:09 PM, Lee Jones Wrote: > > On Fri, 18 Nov 2016, Eric Jeong wrote: > > > > > From: Eric Jeong > > > > This patch adds supports for PV88080 MFD core device. > > > > It provides communication through the I2C interface. > > It contains the following components: > >

Re: [PATCH v2 2/2] dmaengine: omap-dma: Support for slave devices with data port window

On Thu, Nov 17, 2016 at 02:50:17PM +0200, Peter Ujfalusi wrote: > @@ -921,11 +931,45 @@ static struct dma_async_tx_descriptor > *omap_dma_prep_slave_sg( > > d->ccr = c->ccr | CCR_SYNC_FRAME; > if (dir == DMA_DEV_TO_MEM) { > - d->ccr |= CCR_DST_AMODE_POSTINC |

Re: [PATCH v2 2/2] dmaengine: omap-dma: Support for slave devices with data port window

On Thu, Nov 17, 2016 at 02:50:17PM +0200, Peter Ujfalusi wrote: > @@ -921,11 +931,45 @@ static struct dma_async_tx_descriptor > *omap_dma_prep_slave_sg( > > d->ccr = c->ccr | CCR_SYNC_FRAME; > if (dir == DMA_DEV_TO_MEM) { > - d->ccr |= CCR_DST_AMODE_POSTINC |

Re: [PATCH 02/10] ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls

On Fri, Nov 25, 2016 at 1:43 PM, Icenowy Zheng wrote: > > > 12.11.2016, 14:57, "Chen-Yu Tsai" : >> The internal codec on A23/A33/H3 is split into 2 parts. The >> analog path controls are routed through an embedded custom register >> bus accessed through the PRCM

Re: [PATCH 02/10] ASoC: sunxi: Add support for A23/A33/H3 codec's analog path controls

On Fri, Nov 25, 2016 at 1:43 PM, Icenowy Zheng wrote: > > > 12.11.2016, 14:57, "Chen-Yu Tsai" : >> The internal codec on A23/A33/H3 is split into 2 parts. The >> analog path controls are routed through an embedded custom register >> bus accessed through the PRCM block. >> >> The SoCs share a

Re: module: extend 'rodata=off' boot cmdline parameter to module mappings

+++ AKASHI Takahiro [14/11/16 15:15 +0900]: The current "rodata=off" parameter disables read-only kernel mappings under CONFIG_DEBUG_RODATA: commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter to disable read-only kernel mappings") This patch is a logical extension to

Re: [PATCH] cpuset: Remove unused 'struct cpuset*' variable

On 2016/11/25 12:55, Kirtika Ruchandani wrote: > 'struct cpuset* cs' that is set but not used, was introduced in commit > 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from > subtree_control enabling"). > cpuset_cancel_attach() uses css_cs(css) instead. Compiling with W=1 >

Re: module: extend 'rodata=off' boot cmdline parameter to module mappings

+++ AKASHI Takahiro [14/11/16 15:15 +0900]: The current "rodata=off" parameter disables read-only kernel mappings under CONFIG_DEBUG_RODATA: commit d2aa1acad22f ("mm/init: Add 'rodata=off' boot cmdline parameter to disable read-only kernel mappings") This patch is a logical extension to

Re: [PATCH] cpuset: Remove unused 'struct cpuset*' variable

On 2016/11/25 12:55, Kirtika Ruchandani wrote: > 'struct cpuset* cs' that is set but not used, was introduced in commit > 1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from > subtree_control enabling"). > cpuset_cancel_attach() uses css_cs(css) instead. Compiling with W=1 >

RE: [patch v3 1/1] platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

> -Original Message- > From: Vadim Pasternak > Sent: Monday, November 14, 2016 10:10 AM > To: 'Andy Shevchenko' > Cc: Thomas Gleixner ; dvh...@infradead.org; platform- > driver-...@vger.kernel.org; x...@kernel.org;

RE: [patch v3 1/1] platform/x86: move module mlx-platform from arch/x86 to drivers/platform/x86

> -Original Message- > From: Vadim Pasternak > Sent: Monday, November 14, 2016 10:10 AM > To: 'Andy Shevchenko' > Cc: Thomas Gleixner ; dvh...@infradead.org; platform- > driver-...@vger.kernel.org; x...@kernel.org; linux-kernel@vger.kernel.org; > j...@resnulli.us;

Re: [PATCH net-next] virtio-net: enable multiqueue by default

On 2016年11月25日 12:43, Michael S. Tsirkin wrote: On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote: >We use single queue even if multiqueue is enabled and let admin to >enable it through ethtool later. This is used to avoid possible >regression (small packet TCP stream transmission).

Re: [PATCH net-next] virtio-net: enable multiqueue by default

On 2016年11月25日 12:43, Michael S. Tsirkin wrote: On Fri, Nov 25, 2016 at 12:37:26PM +0800, Jason Wang wrote: >We use single queue even if multiqueue is enabled and let admin to >enable it through ethtool later. This is used to avoid possible >regression (small packet TCP stream transmission).

Re: [PATCH 1/1 linux-next] ext4: add compatibility flag check

On Thu, Nov 24, 2016 at 08:47:41PM +0100, Fabian Frederick wrote: > data=journal mount option should disable O_DIRECT access > (See Documentation/filesystems/ext4.txt) but open operations > using O_CREAT|O_RDWR|O_DIRECT|O_SYNC have no warning in return and file is > being > created. This patch

Re: [PATCH 1/1 linux-next] ext4: add compatibility flag check

On Thu, Nov 24, 2016 at 08:47:41PM +0100, Fabian Frederick wrote: > data=journal mount option should disable O_DIRECT access > (See Documentation/filesystems/ext4.txt) but open operations > using O_CREAT|O_RDWR|O_DIRECT|O_SYNC have no warning in return and file is > being > created. This patch

Re: [PATCH 1/1] dmaengine: imx-sdma - correct the dma transfer residue calculation

On Tue, Oct 11, 2016 at 02:13:41PM +0300, Nandor Han wrote: > The residue calculation was taking in consideration that dma > transaction status will be always retrieved in the dma callback > used to inform that dma transfer is complete. However this is not > the case for all subsystems that use

Re: [PATCH 1/1] dmaengine: imx-sdma - correct the dma transfer residue calculation

On Tue, Oct 11, 2016 at 02:13:41PM +0300, Nandor Han wrote: > The residue calculation was taking in consideration that dma > transaction status will be always retrieved in the dma callback > used to inform that dma transfer is complete. However this is not > the case for all subsystems that use

Re: [PATCH 4/7] ovl: add infrastructure for intercepting file ops

On Thu, Nov 24, 2016 at 4:08 PM, Amir Goldstein wrote: > On Thu, Nov 24, 2016 at 3:51 PM, Miklos Szeredi wrote: >> On Thu, Nov 24, 2016 at 2:12 PM, Amir Goldstein wrote: >>> On Thu, Nov 24, 2016 at 2:03 PM, Miklos Szeredi

Re: [PATCH 4/7] ovl: add infrastructure for intercepting file ops

On Thu, Nov 24, 2016 at 4:08 PM, Amir Goldstein wrote: > On Thu, Nov 24, 2016 at 3:51 PM, Miklos Szeredi wrote: >> On Thu, Nov 24, 2016 at 2:12 PM, Amir Goldstein wrote: >>> On Thu, Nov 24, 2016 at 2:03 PM, Miklos Szeredi wrote: On Thu, Nov 24, 2016 at 12:52 PM, Amir Goldstein

[PATCH v7 08/12] iommu/amd: Add sanity check of irq remap information of old dev table entry

Firstly split the dev table entry copy into address translation part and irq remapping part. Because these two parts could be configured to be available indepentently. Secondly check if IntCtl and IntTabLen are 10b and 1000b if they are set. Signed-off-by: Baoquan He ---

[PATCH v7 08/12] iommu/amd: Add sanity check of irq remap information of old dev table entry

Firstly split the dev table entry copy into address translation part and irq remapping part. Because these two parts could be configured to be available indepentently. Secondly check if IntCtl and IntTabLen are 10b and 1000b if they are set. Signed-off-by: Baoquan He ---

[PATCH v7 07/12] iommu/amd: Use is_attach_deferred call-back

Implement call-back is_attach_deferred and use it to defer the domain attach from iommu driver init to device driver init when iommu is pre-enabled in kdump kernel. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 23 ++- 1 file changed, 22

[PATCH v7 03/12] iommu/amd: Define bit fields for DTE particularly

In amd-vi spec several bits of IO PTE fields and DTE fields are similar so that both of them can share the same MACRO definition. However defining their respecitve bit fields can make code more read-able. So do it in this patch. Signed-off-by: Baoquan He ---

[PATCH v7 04/12] iommu/amd: Add function copy_dev_tables

Add function copy_dev_tables to copy the old DEV table entries of the panicked kernel to the new allocated DEV table. Since all iommus share the same DTE table the copy only need be done once as long as the physical address of old DEV table is retrieved from iommu reg. Besides, we also need to:

[PATCH v7 01/12] iommu/amd: Detect pre enabled translation

Add functions to check whether translation is already enabled in IOMMU. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 25 + drivers/iommu/amd_iommu_proto.h | 1 + drivers/iommu/amd_iommu_types.h | 4 3 files changed, 30

[PATCH v7 07/12] iommu/amd: Use is_attach_deferred call-back

Implement call-back is_attach_deferred and use it to defer the domain attach from iommu driver init to device driver init when iommu is pre-enabled in kdump kernel. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 23 ++- 1 file changed, 22 insertions(+), 1

[PATCH v7 03/12] iommu/amd: Define bit fields for DTE particularly

In amd-vi spec several bits of IO PTE fields and DTE fields are similar so that both of them can share the same MACRO definition. However defining their respecitve bit fields can make code more read-able. So do it in this patch. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 8

[PATCH v7 04/12] iommu/amd: Add function copy_dev_tables

Add function copy_dev_tables to copy the old DEV table entries of the panicked kernel to the new allocated DEV table. Since all iommus share the same DTE table the copy only need be done once as long as the physical address of old DEV table is retrieved from iommu reg. Besides, we also need to:

[PATCH v7 01/12] iommu/amd: Detect pre enabled translation

Add functions to check whether translation is already enabled in IOMMU. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 25 + drivers/iommu/amd_iommu_proto.h | 1 + drivers/iommu/amd_iommu_types.h | 4 3 files changed, 30 insertions(+) diff --git

[PATCH v7 12/12] iommu/amd: Allocate memory below 4G for dev table if translation pre-enabled

AMD pointed out it's unsafe to update the device-table while iommu is enabled. It turns out that device-table pointer update is split up into two 32bit writes in the IOMMU hardware. So updating it while the IOMMU is enabled could have some nasty side effects. The only way to work around this is

[PATCH v7 00/12] Fix kdump faults on system with amd iommu

This is v7 post. The principle of the fix is similar to intel iommu. Just defer the assignment of device to domain to device driver init. In this version of post, a new call-back is_attach_deferred is added to iommu-ops, it's used to check whether we need defer the domain attach/detach in

[PATCH v7 11/12] iommu: Assign the direct mapped domain to group->domain

In iommu_request_dm_for_dev(), devices of group have all been attached to newly created direct mapped domain. We should store the domain into group->domain so that it works for iommu_get_domain_for_dev() and get_domain(). Signed-off-by: Baoquan He --- drivers/iommu/iommu.c | 1

[PATCH v7 09/12] iommu/amd: Don't copy GCR3 table root pointer

When in kdump kernel iommu is pre_enabled, if a device is set up with guest translations (DTE.GV=1), then don't copy GCR3 table root pointer but move the device over to an empty guest-cr3 table and handle the faults in the PPR log (which answer them with INVALID). After all these PPR faults are

[PATCH v7 05/12] iommu/amd: copy old trans table from old kernel

Here several things need be done: - If iommu is pre-enabled in a normal kernel, just disable it and print warning. - If failed to copy dev table of old kernel, continue to proceed as it does in normal kernel. - Disable and Re-enable event/cmd buffer, install the copied DTE table to reg,

[PATCH v7 11/12] iommu: Assign the direct mapped domain to group->domain

In iommu_request_dm_for_dev(), devices of group have all been attached to newly created direct mapped domain. We should store the domain into group->domain so that it works for iommu_get_domain_for_dev() and get_domain(). Signed-off-by: Baoquan He --- drivers/iommu/iommu.c | 1 + 1 file

[PATCH v7 09/12] iommu/amd: Don't copy GCR3 table root pointer

When in kdump kernel iommu is pre_enabled, if a device is set up with guest translations (DTE.GV=1), then don't copy GCR3 table root pointer but move the device over to an empty guest-cr3 table and handle the faults in the PPR log (which answer them with INVALID). After all these PPR faults are

[PATCH v7 05/12] iommu/amd: copy old trans table from old kernel

Here several things need be done: - If iommu is pre-enabled in a normal kernel, just disable it and print warning. - If failed to copy dev table of old kernel, continue to proceed as it does in normal kernel. - Disable and Re-enable event/cmd buffer, install the copied DTE table to reg,

[PATCH v7 12/12] iommu/amd: Allocate memory below 4G for dev table if translation pre-enabled

AMD pointed out it's unsafe to update the device-table while iommu is enabled. It turns out that device-table pointer update is split up into two 32bit writes in the IOMMU hardware. So updating it while the IOMMU is enabled could have some nasty side effects. The only way to work around this is

[PATCH v7 00/12] Fix kdump faults on system with amd iommu

This is v7 post. The principle of the fix is similar to intel iommu. Just defer the assignment of device to domain to device driver init. In this version of post, a new call-back is_attach_deferred is added to iommu-ops, it's used to check whether we need defer the domain attach/detach in

[PATCH v7 10/12] iommu/amd: Clear out the GV flag when handle deferred domain attach

When handle deferred domain attach, we need check if the domain is v2. If not, should try to clear out the GV flag which could be copied from the old device table entry. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 18 +- 1 file changed, 17

[PATCH v7 06/12] iommu: Add is_attach_deferred call-back to iommu-ops

This new call-back will be used to check if the domain attach need be deferred for now. If yes, the domain attach/detach will return directly. Signed-off-by: Baoquan He --- drivers/iommu/iommu.c | 8 include/linux/iommu.h | 1 + 2 files changed, 9 insertions(+) diff

[PATCH v7 10/12] iommu/amd: Clear out the GV flag when handle deferred domain attach

When handle deferred domain attach, we need check if the domain is v2. If not, should try to clear out the GV flag which could be copied from the old device table entry. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 18 +- 1 file changed, 17 insertions(+), 1

[PATCH v7 06/12] iommu: Add is_attach_deferred call-back to iommu-ops

This new call-back will be used to check if the domain attach need be deferred for now. If yes, the domain attach/detach will return directly. Signed-off-by: Baoquan He --- drivers/iommu/iommu.c | 8 include/linux/iommu.h | 1 + 2 files changed, 9 insertions(+) diff --git

[PATCH v7 02/12] iommu/amd: add several helper function

Move per iommu enabling code into a wrapper function early_enable_iommu(). This can make later kdump change easier. And also add iommu_disable_command_buffer and iommu_disable_event_buffer for later usage. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 42

[PATCH v7 02/12] iommu/amd: add several helper function

Move per iommu enabling code into a wrapper function early_enable_iommu(). This can make later kdump change easier. And also add iommu_disable_command_buffer and iommu_disable_event_buffer for later usage. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 42

  1   2   3   4   5   6   7   8   9   10   >