[PATCH v3 1/4] KVM: VMX: use kvm_event_needs_reinjection

From: Wanpeng Li Use kvm_event_needs_reinjection() encapsulation. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index dd710d3..c5f43ab 100644

[PATCH v3 3/4] KVM: VMX: Move the nested_vmx_inject_exception_vmexit call from nested_vmx_check_exception to vmx_queue_exception

From: Wanpeng Li Move the nested_vmx_inject_exception_vmexit call from nested_vmx_check_exception to vmx_queue_exception. Signed-off-by: Wanpeng Li --- arch/x86/kvm/vmx.c | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/vmx.c

Re: Do we really need d_weak_revalidate???

On Wed, Aug 23 2017, Ian Kent wrote: > > That inconsistency has bothered me for quite a while now. > > It was carried over from the autofs module behavior when automounting > support was added to the VFS. What's worse is it prevents the use of > the AT_NO_AUTOMOUNT flag from working properly with

Re: Do we really need d_weak_revalidate???

On Wed, Aug 23 2017, Ian Kent wrote: > > That inconsistency has bothered me for quite a while now. > > It was carried over from the autofs module behavior when automounting > support was added to the VFS. What's worse is it prevents the use of > the AT_NO_AUTOMOUNT flag from working properly with

Re: [PATCH 12/12] PM / devfreq: Add opp_notifier_cb() function pointer to support OPP notifier

Dear all, On 2017년 08월 24일 10:42, Chanwoo Choi wrote: > The devfreq uses the OPP interface as a mandatory method > and so the devfreq has to support the OPP notifier in order to > catch the OPP events. So, this patch adds the new opp_notifier_cb() > function pointer in the struct

Re: [PATCH 12/12] PM / devfreq: Add opp_notifier_cb() function pointer to support OPP notifier

Dear all, On 2017년 08월 24일 10:42, Chanwoo Choi wrote: > The devfreq uses the OPP interface as a mandatory method > and so the devfreq has to support the OPP notifier in order to > catch the OPP events. So, this patch adds the new opp_notifier_cb() > function pointer in the struct

Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

Hi Rafael, Zheng, At 07/31/2017 06:50 PM, Dou Liyang wrote: Hi, At 07/14/2017 01:52 PM, Dou Liyang wrote: Linux uses acpi_early_init() to put the ACPI table management into the late stage from the early stage where the mapped ACPI tables is temporary and should be unmapped. But, now

Re: [PATCH v7 12/13] ACPI / init: Invoke early ACPI initialization earlier

Hi Rafael, Zheng, At 07/31/2017 06:50 PM, Dou Liyang wrote: Hi, At 07/14/2017 01:52 PM, Dou Liyang wrote: Linux uses acpi_early_init() to put the ACPI table management into the late stage from the early stage where the mapped ACPI tables is temporary and should be unmapped. But, now

Re: [PATCH v2] ASoC: Add a sanity check before using dai driver name

On Thu, Aug 24, 2017 at 11:34 AM, Jeffy Chen wrote: > list_for_each_entry(dai, >dai_list, list) { > if (dlc->dai_name && strcmp(dai->name, dlc->dai_name) > - && strcmp(dai->driver->name, dlc->dai_name)) >

Re: [PATCH v2] ASoC: Add a sanity check before using dai driver name

On Thu, Aug 24, 2017 at 11:34 AM, Jeffy Chen wrote: > list_for_each_entry(dai, >dai_list, list) { > if (dlc->dai_name && strcmp(dai->name, dlc->dai_name) > - && strcmp(dai->driver->name, dlc->dai_name)) > +

[PATCH v2] ASoC: Add a sanity check before using dai driver name

The dai driver's name is allowed to be NULL. So add a sanity check for that. Signed-off-by: Jeffy Chen Reported-by: Donglin Peng --- Changes in v2: Keep the oringinal check style. sound/soc/soc-core.c | 3 ++- 1 file changed, 2

[PATCH v2] ASoC: Add a sanity check before using dai driver name

The dai driver's name is allowed to be NULL. So add a sanity check for that. Signed-off-by: Jeffy Chen Reported-by: Donglin Peng --- Changes in v2: Keep the oringinal check style. sound/soc/soc-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-core.c

Re: linux-next: build failure after merge of the block tree

sk pointer and partitions > index") > > interacting with commit > > c775d2098d35 ("bio-integrity: Fix regression if profile verify_fn is NULL") > > from Linus' tree (before v4.13-rc5). > > This should have been fixed up in commit > > 3b

Re: linux-next: build failure after merge of the block tree

titions > index") > > interacting with commit > > c775d2098d35 ("bio-integrity: Fix regression if profile verify_fn is NULL") > > from Linus' tree (before v4.13-rc5). > > This should have been fixed up in commit > > 3b8848b41130 ("Merge bran

linux-next: build failure after merge of the block tree

rom Linus' tree (before v4.13-rc5). This should have been fixed up in commit 3b8848b41130 ("Merge branch 'master' into for-next") I have used the block tree from next-20170823 for today. -- Cheers, Stephen Rothwell

linux-next: build failure after merge of the block tree

rom Linus' tree (before v4.13-rc5). This should have been fixed up in commit 3b8848b41130 ("Merge branch 'master' into for-next") I have used the block tree from next-20170823 for today. -- Cheers, Stephen Rothwell

Re: [PATCH] ASoC: Add a sanity check before using dai driver name

Hi Mark, On 08/23/2017 07:06 PM, Mark Brown wrote: On Wed, Aug 23, 2017 at 07:42:55AM +0800, jeffy wrote: >i think the original check is allowing NULL dlc dai_name to be a match... >so we basically did: >reject when dlc dai_name is valid, but not match the dai name So it is, but this still

Re: [PATCH] ASoC: Add a sanity check before using dai driver name

Hi Mark, On 08/23/2017 07:06 PM, Mark Brown wrote: On Wed, Aug 23, 2017 at 07:42:55AM +0800, jeffy wrote: >i think the original check is allowing NULL dlc dai_name to be a match... >so we basically did: >reject when dlc dai_name is valid, but not match the dai name So it is, but this still

Re: [PATCH v2] net: stmmac: socfgpa: Ensure emac bit set in sys manager for MII/GMII/SGMII.

From: Stephan Gatzka Date: Tue, 22 Aug 2017 14:25:07 +0200 > When using MII/GMII/SGMII in the Altera SoC, the phy needs to be > wired through the FPGA. To ensure correct behavior, the appropriate > bit in the System Manager FPGA Interface Group register needs to be >

Re: [PATCH v2] net: stmmac: socfgpa: Ensure emac bit set in sys manager for MII/GMII/SGMII.

From: Stephan Gatzka Date: Tue, 22 Aug 2017 14:25:07 +0200 > When using MII/GMII/SGMII in the Altera SoC, the phy needs to be > wired through the FPGA. To ensure correct behavior, the appropriate > bit in the System Manager FPGA Interface Group register needs to be > set. > > Signed-off-by:

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 23, 2017 at 8:11 PM, Eric W. Biederman wrote: > -static int pty_get_peer(struct tty_struct *tty, int flags) > +int ptm_open_peer(struct file *master, struct tty_struct *tty, int flags) > { > int fd = -1; > struct file *filp = NULL; > int

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 23, 2017 at 8:11 PM, Eric W. Biederman wrote: > -static int pty_get_peer(struct tty_struct *tty, int flags) > +int ptm_open_peer(struct file *master, struct tty_struct *tty, int flags) > { > int fd = -1; > struct file *filp = NULL; > int retval = -EINVAL; > +

Re: [PATCH v5] mtd: spi-nor: add support for GD25Q256

Hi Andy, Le 23/08/2017 à 12:01, Andy Yan a écrit : > Add support for GD25Q256, a 32MiB SPI Nor > flash from GigaDevice. > > The GD25Q256 uses S6 to set QE, which is > different with other supported memories > from GigaDevice that use S9. So we introduce > a quad_enable function which can be set

Re: [PATCH v5] mtd: spi-nor: add support for GD25Q256

Hi Andy, Le 23/08/2017 à 12:01, Andy Yan a écrit : > Add support for GD25Q256, a 32MiB SPI Nor > flash from GigaDevice. > > The GD25Q256 uses S6 to set QE, which is > different with other supported memories > from GigaDevice that use S9. So we introduce > a quad_enable function which can be set

Re: Do we really need d_weak_revalidate???

On Wed, Aug 23 2017, Ian Kent wrote: > On 23/08/17 10:32, Ian Kent wrote: >> On 23/08/17 09:06, NeilBrown wrote: >>> On Mon, Aug 21 2017, Ian Kent wrote: >>> > > A mount isn't triggered by kern_path(pathname, 0, ). > That '0' would need to include one of > LOOKUP_PARENT |

Re: Do we really need d_weak_revalidate???

On Wed, Aug 23 2017, Ian Kent wrote: > On 23/08/17 10:32, Ian Kent wrote: >> On 23/08/17 09:06, NeilBrown wrote: >>> On Mon, Aug 21 2017, Ian Kent wrote: >>> > > A mount isn't triggered by kern_path(pathname, 0, ). > That '0' would need to include one of > LOOKUP_PARENT |

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Linus Torvalds writes: > On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds > wrote: >> >> Argh. And it's *not* fairly straightforward, because the >> tty_operations "ioctl()" function pointer only gets 'struct tty *'. >> >> So in the

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Linus Torvalds writes: > On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds > wrote: >> >> Argh. And it's *not* fairly straightforward, because the >> tty_operations "ioctl()" function pointer only gets 'struct tty *'. >> >> So in the TIOCGPTPEER path, we don't actually have access to the file >>

Re: [PATCH net-next v7 08/10] bpf: Add a Landlock sandbox example

On Mon, Aug 21, 2017 at 02:09:31AM +0200, Mickaël Salaün wrote: > Add a basic sandbox tool to create a process isolated from some part of > the system. This sandbox create a read-only environment. It is only > allowed to write to a character device such as a TTY: > > # :> X > # echo $? > 0

Re: [PATCH net-next v7 08/10] bpf: Add a Landlock sandbox example

On Mon, Aug 21, 2017 at 02:09:31AM +0200, Mickaël Salaün wrote: > Add a basic sandbox tool to create a process isolated from some part of > the system. This sandbox create a read-only environment. It is only > allowed to write to a character device such as a TTY: > > # :> X > # echo $? > 0

[PATCH V7] perf: Add PERF_SAMPLE_PHYS_ADDR

From: Kan Liang For understanding how the workload maps to memory channels and hardware behavior, it's very important to collect address maps with physical addresses. For example, 3D XPoint access can only be found by filtering the physical address. Add a new sample type

[PATCH V7] perf: Add PERF_SAMPLE_PHYS_ADDR

From: Kan Liang For understanding how the workload maps to memory channels and hardware behavior, it's very important to collect address maps with physical addresses. For example, 3D XPoint access can only be found by filtering the physical address. Add a new sample type for physical address.

Re: [PATCH v1 1/3] arm: npcm: add basic support for Nuvoton BMCs

Hi Brendan, [auto build test ERROR on linus/master] [also build test ERROR on v4.13-rc6 next-20170823] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Brendan-Higgins/arm-npcm-add-basic-support

Re: [PATCH v1 1/3] arm: npcm: add basic support for Nuvoton BMCs

Hi Brendan, [auto build test ERROR on linus/master] [also build test ERROR on v4.13-rc6 next-20170823] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Brendan-Higgins/arm-npcm-add-basic-support

[PATCH v2] binder: allow ANDROID_BINDER_IPC_32BIT to be unselected on 32bit ARM

As noted in commit d0bdff0db809 ("staging: Fix build issues with new binder API"), we can add back the choice for 32bit ARM "once a 64bit __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM: 8091/2: add get_user() support for 8 byte types") has added the support, so it's time to

[PATCH v2] binder: allow ANDROID_BINDER_IPC_32BIT to be unselected on 32bit ARM

As noted in commit d0bdff0db809 ("staging: Fix build issues with new binder API"), we can add back the choice for 32bit ARM "once a 64bit __get_user_asm_* implementation is merged." Commit e38361d032f1 ("ARM: 8091/2: add get_user() support for 8 byte types") has added the support, so it's time to

Re: [PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

On Sat, Aug 19, 2017 at 10:43 AM, Thang Q. Nguyen wrote: > From: "Thang Q. Nguyen" > > For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA > configuration"), sysdev points to devices known to the system firmware > or hardware for DMA parameters. >

Re: [PATCH v2 1/1] usb:xhci: update condition to select bus->sysdev from parent device

On Sat, Aug 19, 2017 at 10:43 AM, Thang Q. Nguyen wrote: > From: "Thang Q. Nguyen" > > For commit 4c39d4b949d3 ("usb: xhci: use bus->sysdev for DMA > configuration"), sysdev points to devices known to the system firmware > or hardware for DMA parameters. > However, the parent of the system

Re: [PATCH net-next v7 05/10] landlock: Add LSM hooks related to filesystem

On Mon, Aug 21, 2017 at 02:09:28AM +0200, Mickaël Salaün wrote: > Handle 33 filesystem-related LSM hooks for the Landlock filesystem > event: LANDLOCK_SUBTYPE_EVENT_FS. > > A Landlock event wrap LSM hooks for similar kernel object types (e.g. > struct file, struct path...). Multiple LSM hooks can

Re: [PATCH net-next v7 05/10] landlock: Add LSM hooks related to filesystem

On Mon, Aug 21, 2017 at 02:09:28AM +0200, Mickaël Salaün wrote: > Handle 33 filesystem-related LSM hooks for the Landlock filesystem > event: LANDLOCK_SUBTYPE_EVENT_FS. > > A Landlock event wrap LSM hooks for similar kernel object types (e.g. > struct file, struct path...). Multiple LSM hooks can

Re: [PATCH] scsi: lpfc: remove useless code in lpfc_sli4_bsg_link_diag_test

Gustavo, > Remove variable assignments. The value stored in local variable _rc_ > is overwritten at line 2448:rc = > lpfc_sli4_bsg_set_link_diag_state(phba, 0); before it can be used. Applied to 4.14/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: lpfc: remove useless code in lpfc_sli4_bsg_link_diag_test

Gustavo, > Remove variable assignments. The value stored in local variable _rc_ > is overwritten at line 2448:rc = > lpfc_sli4_bsg_set_link_diag_state(phba, 0); before it can be used. Applied to 4.14/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v4] iio: accel: mma8452: improvements to handle multiple events

> Am 23.08.2017 02:29 schrieb Harinath Nampally: > If rising: use transient OR ff_mt device-dependent like before. But now save > it in a simple flag, > whether transient registers are available. > Ok, is it good idea to add the flag to struct mma_chip_info like below? > * @mma_scales:

Re: [PATCH v4] iio: accel: mma8452: improvements to handle multiple events

> Am 23.08.2017 02:29 schrieb Harinath Nampally: > If rising: use transient OR ff_mt device-dependent like before. But now save > it in a simple flag, > whether transient registers are available. > Ok, is it good idea to add the flag to struct mma_chip_info like below? > * @mma_scales:

Re: [PATCH V3] dmaengine: qcom-bam: Process multiple pending descriptors

>> |DES 0| |DESC 1 |DESC 2 + INT | >> -- --- -- >> | >> | >>(INT) >>(CB for 0, 1, 2) >> >> MTD_SPEEDTEST READ PAGE: 3860 KiB/s >>

Re: [PATCH V3] dmaengine: qcom-bam: Process multiple pending descriptors

>> |DES 0| |DESC 1 |DESC 2 + INT | >> -- --- -- >> | >> | >>(INT) >>(CB for 0, 1, 2) >> >> MTD_SPEEDTEST READ PAGE: 3860 KiB/s >>

[PATCH v2 3/3] arm64: dts: rockchip: add cpu regulator for rk3328 evaluation board

From: Liang Chen RK3328 Evaluation Board use rk805 pmic, and one of the DCDCs in rk805 is for cpu regulator, assign the cpu regulator, so the cpufreq can work fine. Signed-off-by: Liang Chen --- arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 4 1

[PATCH v2 3/3] arm64: dts: rockchip: add cpu regulator for rk3328 evaluation board

From: Liang Chen RK3328 Evaluation Board use rk805 pmic, and one of the DCDCs in rk805 is for cpu regulator, assign the cpu regulator, so the cpufreq can work fine. Signed-off-by: Liang Chen --- arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v1 0/3] Enable some devices for rk3328 evaluation board

From: Liang Chen 1. enalbe sdio/sdmmc/emmc. 2. enable cpufreq. change in v2: 1. remove useless properties in mmc nodes. Liang Chen (3): arm64: dts: rockchip: add mmc nodes for rk3328 evaluation board cpufreq: rockchip: add support for rk3328 soc arm64: dts:

[PATCH v2 2/3] cpufreq: rockchip: add support for rk3328 soc

From: Liang Chen Add compatible rockchip,rk3328 to the machines table to launch cpufreq-dt driver for rk3328 soc. Signed-off-by: Liang Chen --- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v1 0/3] Enable some devices for rk3328 evaluation board

From: Liang Chen 1. enalbe sdio/sdmmc/emmc. 2. enable cpufreq. change in v2: 1. remove useless properties in mmc nodes. Liang Chen (3): arm64: dts: rockchip: add mmc nodes for rk3328 evaluation board cpufreq: rockchip: add support for rk3328 soc arm64: dts: rockchip: add cpu regulator

[PATCH v2 2/3] cpufreq: rockchip: add support for rk3328 soc

From: Liang Chen Add compatible rockchip,rk3328 to the machines table to launch cpufreq-dt driver for rk3328 soc. Signed-off-by: Liang Chen --- drivers/cpufreq/cpufreq-dt-platdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c

[PATCH v2 1/3] arm64: dts: rockchip: add mmc nodes for rk3328 evaluation board

From: Liang Chen Rockchip's rk3328 evaluation board has 3 mmc controllers for sdio/sdmmc/emmc, let's enable them. Signed-off-by: Liang Chen --- arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 66 + 1 file changed, 66

[PATCH v2 1/3] arm64: dts: rockchip: add mmc nodes for rk3328 evaluation board

From: Liang Chen Rockchip's rk3328 evaluation board has 3 mmc controllers for sdio/sdmmc/emmc, let's enable them. Signed-off-by: Liang Chen --- arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 66 + 1 file changed, 66 insertions(+) diff --git

Re: [PATCH net-next v7 03/10] bpf,landlock: Define an eBPF program type for a Landlock rule

On Mon, Aug 21, 2017 at 02:09:26AM +0200, Mickaël Salaün wrote: > Add a new type of eBPF program used by Landlock rules. > > This new BPF program type will be registered with the Landlock LSM > initialization. > > Add an initial Landlock Kconfig. > > Signed-off-by: Mickaël Salaün

Re: [PATCH net-next v7 01/10] selftest: Enhance kselftest_harness.h with a step mechanism

On Mon, Aug 21, 2017 at 02:09:24AM +0200, Mickaël Salaün wrote: > This step mechanism may be useful to return an information about the > error without being able to write to TH_LOG_STREAM. > > Set _metadata->no_print to true to print this counter. > > Signed-off-by: Mickaël Salaün

Re: [PATCH net-next v7 03/10] bpf,landlock: Define an eBPF program type for a Landlock rule

On Mon, Aug 21, 2017 at 02:09:26AM +0200, Mickaël Salaün wrote: > Add a new type of eBPF program used by Landlock rules. > > This new BPF program type will be registered with the Landlock LSM > initialization. > > Add an initial Landlock Kconfig. > > Signed-off-by: Mickaël Salaün > Cc: Alexei

Re: [PATCH net-next v7 01/10] selftest: Enhance kselftest_harness.h with a step mechanism

On Mon, Aug 21, 2017 at 02:09:24AM +0200, Mickaël Salaün wrote: > This step mechanism may be useful to return an information about the > error without being able to write to TH_LOG_STREAM. > > Set _metadata->no_print to true to print this counter. > > Signed-off-by: Mickaël Salaün > Cc: Andy

Re: [PATCH v2 3/4] net: phy: realtek: add disable RX internal delay mode

Hi Icenowy, [auto build test WARNING on net-next/master] [also build test WARNING on v4.13-rc6 next-20170823] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/Workaround-broken

Re: [PATCH v2 3/4] net: phy: realtek: add disable RX internal delay mode

Hi Icenowy, [auto build test WARNING on net-next/master] [also build test WARNING on v4.13-rc6 next-20170823] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Icenowy-Zheng/Workaround-broken

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote: > The new completion/crossrelease annotations interact unfavourable with > the extant flush_work()/flush_workqueue() annotations. > > The problem is that when a single work class does: > > wait_for_completion() > > and > >

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote: > The new completion/crossrelease annotations interact unfavourable with > the extant flush_work()/flush_workqueue() annotations. > > The problem is that when a single work class does: > > wait_for_completion() > > and > >

Re: [PATCH 2/2] tracing: Fix kmemleak in set_trigger_filter

On Wed, 23 Aug 2017 18:58:03 -0400 (EDT) Chunyu Hu wrote: > - Original Message - > > From: "Steven Rostedt" > > To: "Chunyu Hu" > > Cc: mi...@kernel.org, linux-kernel@vger.kernel.org > > Sent: Wednesday, August 23, 2017 12:52:49

Re: [PATCH 2/2] tracing: Fix kmemleak in set_trigger_filter

On Wed, 23 Aug 2017 18:58:03 -0400 (EDT) Chunyu Hu wrote: > - Original Message - > > From: "Steven Rostedt" > > To: "Chunyu Hu" > > Cc: mi...@kernel.org, linux-kernel@vger.kernel.org > > Sent: Wednesday, August 23, 2017 12:52:49 PM > > Subject: Re: [PATCH 2/2] tracing: Fix kmemleak in

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On Thu, 24 Aug 2017 09:41:03 +0900 Sergey Senozhatsky wrote: > On (08/23/17 16:48), Petr Mladek wrote: > [..] > > Sometimes people seems unclear when to use the %pS or %pF printk format. > > For example, see commit 51d96dc2e2dc ("random: fix warning message on

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On Thu, 24 Aug 2017 09:41:03 +0900 Sergey Senozhatsky wrote: > On (08/23/17 16:48), Petr Mladek wrote: > [..] > > Sometimes people seems unclear when to use the %pS or %pF printk format. > > For example, see commit 51d96dc2e2dc ("random: fix warning message on ia64 > > and parisc") which fixed

Re: [PATCH v2 7/8] iommu/mediatek: Enlarge the validate PA range for 4GB mode

Hi Yong, [auto build test ERROR on iommu/next] [also build test ERROR on next-20170823] [cannot apply to v4.13-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Yong-Wu/MT2712-IOMMU-SUPPORT

Re: [PATCH v2 7/8] iommu/mediatek: Enlarge the validate PA range for 4GB mode

Hi Yong, [auto build test ERROR on iommu/next] [also build test ERROR on next-20170823] [cannot apply to v4.13-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Yong-Wu/MT2712-IOMMU-SUPPORT

Re: [PATCH 4/4] iommu/pamu: Add support for generic iommu-device

Joerg Roedel writes: > Hello Michael, > > On Wed, Aug 23, 2017 at 10:17:39PM +1000, Michael Ellerman wrote: > >> [0.358192] Call Trace: >> [0.360624] [c000f7173680] [c000f7173710] 0xc000f7173710 >> (unreliable) >> [0.368088] [c000f7173710]

Re: [PATCH 4/4] iommu/pamu: Add support for generic iommu-device

Joerg Roedel writes: > Hello Michael, > > On Wed, Aug 23, 2017 at 10:17:39PM +1000, Michael Ellerman wrote: > >> [0.358192] Call Trace: >> [0.360624] [c000f7173680] [c000f7173710] 0xc000f7173710 >> (unreliable) >> [0.368088] [c000f7173710] [c02abf7c] >>

Re: [PATCH net] sctp: Avoid out-of-bounds reads from address storage

On Wed, Aug 23, 2017 at 11:27 PM, Stefano Brivio wrote: > inet_diag_msg_sctp{,l}addr_fill() and sctp_get_sctp_info() copy > sizeof(sockaddr_storage) bytes to fill in sockaddr structs used > to export diagnostic information to userspace. > > However, the memory allocated to

Re: [PATCH net] sctp: Avoid out-of-bounds reads from address storage

On Wed, Aug 23, 2017 at 11:27 PM, Stefano Brivio wrote: > inet_diag_msg_sctp{,l}addr_fill() and sctp_get_sctp_info() copy > sizeof(sockaddr_storage) bytes to fill in sockaddr structs used > to export diagnostic information to userspace. > > However, the memory allocated to store sockaddr

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

On Wed, Aug 23, 2017 at 12:20:48PM +0200, Peter Zijlstra wrote: > On Wed, Aug 23, 2017 at 11:12:17AM +0900, Byungchul Park wrote: > > > > > We have to detect dependecies if it exists, even in the following case: > > > > > > > > oooiii. > > > > |<- range for commit

Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING

On Wed, Aug 23, 2017 at 12:20:48PM +0200, Peter Zijlstra wrote: > On Wed, Aug 23, 2017 at 11:12:17AM +0900, Byungchul Park wrote: > > > > > We have to detect dependecies if it exists, even in the following case: > > > > > > > > oooiii. > > > > |<- range for commit

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds wrote: > > Argh. And it's *not* fairly straightforward, because the > tty_operations "ioctl()" function pointer only gets 'struct tty *'. > > So in the TIOCGPTPEER path, we don't actually have access to the file >

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 23, 2017 at 6:49 PM, Linus Torvalds wrote: > > Argh. And it's *not* fairly straightforward, because the > tty_operations "ioctl()" function pointer only gets 'struct tty *'. > > So in the TIOCGPTPEER path, we don't actually have access to the file > pointer of the fd we're doing the

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 23, 2017 at 6:32 PM, Linus Torvalds wrote: > > It should all be _fairly_ straightforward, but it's definitely a > rather bigger change than that "just fix the path" patch was. Argh. And it's *not* fairly straightforward, because the tty_operations

Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 23, 2017 at 6:32 PM, Linus Torvalds wrote: > > It should all be _fairly_ straightforward, but it's definitely a > rather bigger change than that "just fix the path" patch was. Argh. And it's *not* fairly straightforward, because the tty_operations "ioctl()" function pointer only gets

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

On Wed, 23 Aug 2017 13:48:47 -0500 Rob Herring wrote: > On Tue, Aug 22, 2017 at 9:57 PM, John Stultz wrote: > > On Tue, Aug 22, 2017 at 7:56 PM, John Stultz > > wrote: > >> On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang >

Re: [PATCH] binder: let ANDROID_BINDER_IPC_32BIT be selectable on 32bit ARM

On Wed, 23 Aug 2017 13:48:47 -0500 Rob Herring wrote: > On Tue, Aug 22, 2017 at 9:57 PM, John Stultz wrote: > > On Tue, Aug 22, 2017 at 7:56 PM, John Stultz > > wrote: > >> On Tue, Aug 22, 2017 at 7:34 PM, Jisheng Zhang > >> wrote: > >>> On Tue, 22 Aug 2017 18:51:08 -0700 Greg KH wrote:

[PATCH] zram: add zstd to the supported algorithms list

Add ZSTD to the list of supported compression algorithms. Official benchmarks [1]: Compressor name Ratio Compression Decompress. zstd 1.1.3 -1 2.877 430 MB/s1110 MB/s zlib 1.2.8 -1 2.743 110 MB/s400 MB/s brotli 0.5.2 -0 2.708 400

[PATCH] zram: add zstd to the supported algorithms list

Add ZSTD to the list of supported compression algorithms. Official benchmarks [1]: Compressor name Ratio Compression Decompress. zstd 1.1.3 -1 2.877 430 MB/s1110 MB/s zlib 1.2.8 -1 2.743 110 MB/s400 MB/s brotli 0.5.2 -0 2.708 400

[PATCH 12/12] PM / devfreq: Add opp_notifier_cb() function pointer to support OPP notifier

The devfreq uses the OPP interface as a mandatory method and so the devfreq has to support the OPP notifier in order to catch the OPP events. So, this patch adds the new opp_notifier_cb() function pointer in the struct devfreq_dev_profile. The user can add the their own callback function to

[PATCH 12/12] PM / devfreq: Add opp_notifier_cb() function pointer to support OPP notifier

The devfreq uses the OPP interface as a mandatory method and so the devfreq has to support the OPP notifier in order to catch the OPP events. So, this patch adds the new opp_notifier_cb() function pointer in the struct devfreq_dev_profile. The user can add the their own callback function to

[PATCH 09/12] PM / devfreq: Show whole available frequencies

The commit a76caf55e5b35 ("thermal: Add devfreq cooling") allows the devfreq device to use the cooling device. When the cooling down are required, the devfreq_cooling.c disables the OPP entry with the dev_pm_opp_disable(). In result, 'available_frequencies'[1] sysfs node never came to show the

[PATCH 10/12] PM / devfreq: Remove 'devfreq' prefix from helper function

This patch just removes the 'devfreq' prefix from internal helper function in order to clarify the role of the following functions. - devfreq_get_freq_level() - get_freq_level() - devfreq_set_freq_table() - set_freq_table() Also, this patch changes the return value of set_freq_table() from 'void'

[PATCH 10/12] PM / devfreq: Remove 'devfreq' prefix from helper function

This patch just removes the 'devfreq' prefix from internal helper function in order to clarify the role of the following functions. - devfreq_get_freq_level() - get_freq_level() - devfreq_set_freq_table() - set_freq_table() Also, this patch changes the return value of set_freq_table() from 'void'

[PATCH 09/12] PM / devfreq: Show whole available frequencies

The commit a76caf55e5b35 ("thermal: Add devfreq cooling") allows the devfreq device to use the cooling device. When the cooling down are required, the devfreq_cooling.c disables the OPP entry with the dev_pm_opp_disable(). In result, 'available_frequencies'[1] sysfs node never came to show the

[PATCH 11/12] PM / devfreq: Remove exported opp_notifier function

The devfreq provides the helper function to register the OPP notifier which is used to catch the change of OPP entry such as OPP_EVENT_ADD, OPP_EVENT_REMOVE, OPP_EVENT_DISABLE and OPP_EVENT_ENABLE. The OPP notifier is optional. But, the devfreq uses the OPP interface as a mandatory method to

[PATCH 07/12] Revert "PM / devfreq: Add show_one macro to delete the duplicate code"

This reverts commit 3104fa3081126c9bda35793af5f335d0ee0d5818. The {min|max}_freq_show() show the stored value of the struct devfreq. But, if the drivers/thermal/devfreq_cooling.c disables the specific frequency value, {min|max}_freq_show() have to check this situation before showing the stored

[PATCH 11/12] PM / devfreq: Remove exported opp_notifier function

The devfreq provides the helper function to register the OPP notifier which is used to catch the change of OPP entry such as OPP_EVENT_ADD, OPP_EVENT_REMOVE, OPP_EVENT_DISABLE and OPP_EVENT_ENABLE. The OPP notifier is optional. But, the devfreq uses the OPP interface as a mandatory method to

[PATCH 07/12] Revert "PM / devfreq: Add show_one macro to delete the duplicate code"

This reverts commit 3104fa3081126c9bda35793af5f335d0ee0d5818. The {min|max}_freq_show() show the stored value of the struct devfreq. But, if the drivers/thermal/devfreq_cooling.c disables the specific frequency value, {min|max}_freq_show() have to check this situation before showing the stored

[PATCH 05/12] PM / devfreq: Set min/max_freq when adding the devfreq device

Previously, the min/max_freq of devfreq device are always zero before the user changes the min/max_freq through sysfs entry. It might make the confusion of min/max_freq. This patch initializes the available min/max_freq by using the OPP API. Signed-off-by: Chanwoo Choi

[PATCH 05/12] PM / devfreq: Set min/max_freq when adding the devfreq device

Previously, the min/max_freq of devfreq device are always zero before the user changes the min/max_freq through sysfs entry. It might make the confusion of min/max_freq. This patch initializes the available min/max_freq by using the OPP API. Signed-off-by: Chanwoo Choi ---

[PATCH 08/12] PM / devfreq: Show the available min/max frequency through sysfs node

The existing {min|max}_freq sysfs nodes don't consider whether min/max_freq are available or not. Those sysfs nodes show just the stored value in the struct devfreq. The devfreq uses the OPP interface and then dev_pm_opp_{disable|add}() might change the state of the device's supported frequency.

[PATCH 08/12] PM / devfreq: Show the available min/max frequency through sysfs node

The existing {min|max}_freq sysfs nodes don't consider whether min/max_freq are available or not. Those sysfs nodes show just the stored value in the struct devfreq. The devfreq uses the OPP interface and then dev_pm_opp_{disable|add}() might change the state of the device's supported frequency.

[PATCH 00/12] PM / devfreq: Use OPP interface to handle the frequency

These patches makes the devfreq to use the OPP interface as a mandatory and fix the bug, clean-up codes. - patch 1/2 fix the bug. - patch 3 refactors the private code. - patch 4~12 are related to the OPP interfaces The commit a76caf55e5b3 ("thermal: Add devfreq cooling") provides the devfreq

[PATCH 02/12] PM / devfreq: Fix locking range for making the frequency table

Even if the freq_table is included in the struct devfreq, the commit 0ec09ac2cebe ("PM / devfreq: Set the freq_table of devfreq device") set the frequency table outside the mutex locking. So, this patch initializes the frequency table within the mutex locking. Cc: sta...@vger.kernel.org Fixes:

[PATCH 00/12] PM / devfreq: Use OPP interface to handle the frequency

These patches makes the devfreq to use the OPP interface as a mandatory and fix the bug, clean-up codes. - patch 1/2 fix the bug. - patch 3 refactors the private code. - patch 4~12 are related to the OPP interfaces The commit a76caf55e5b3 ("thermal: Add devfreq cooling") provides the devfreq

[PATCH 02/12] PM / devfreq: Fix locking range for making the frequency table

Even if the freq_table is included in the struct devfreq, the commit 0ec09ac2cebe ("PM / devfreq: Set the freq_table of devfreq device") set the frequency table outside the mutex locking. So, this patch initializes the frequency table within the mutex locking. Cc: sta...@vger.kernel.org Fixes:

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