Re: [PATCH v5 9/9] block: Assign a lock_class per gendisk used for wait_for_completion()

On Thu, Oct 26, 2017 at 07:50:46AM +0200, Ingo Molnar wrote: > > * Jens Axboe wrote: > > > On 10/25/2017 03:13 AM, Ingo Molnar wrote: > > > > > > * Byungchul Park wrote: > > > > > >> Darrick posted the following warning and Dave Chinner analyzed it: >

Re: [PATCH v5 9/9] block: Assign a lock_class per gendisk used for wait_for_completion()

On Thu, Oct 26, 2017 at 07:50:46AM +0200, Ingo Molnar wrote: > > * Jens Axboe wrote: > > > On 10/25/2017 03:13 AM, Ingo Molnar wrote: > > > > > > * Byungchul Park wrote: > > > > > >> Darrick posted the following warning and Dave Chinner analyzed it: > > >> > > >>>

scsi/NCR5380: Suppress SDTR and WDTR message logging

The 5380 drivers only support asynchronous transfers and the 5380 controllers only have narrow busses. Hence, the core driver will reject any SDTR and WDTR messages from target devices. Don't log this, it's expected behaviour. Also, fix the off-by-one array indices in the arguments to

scsi/NCR5380: Suppress SDTR and WDTR message logging

The 5380 drivers only support asynchronous transfers and the 5380 controllers only have narrow busses. Hence, the core driver will reject any SDTR and WDTR messages from target devices. Don't log this, it's expected behaviour. Also, fix the off-by-one array indices in the arguments to

Re: [PATCH v5 9/9] block: Assign a lock_class per gendisk used for wait_for_completion()

* Jens Axboe wrote: > On 10/25/2017 03:13 AM, Ingo Molnar wrote: > > > > * Byungchul Park wrote: > > > >> Darrick posted the following warning and Dave Chinner analyzed it: > >> > >>> == > >>>

Re: [PATCH v5 9/9] block: Assign a lock_class per gendisk used for wait_for_completion()

* Jens Axboe wrote: > On 10/25/2017 03:13 AM, Ingo Molnar wrote: > > > > * Byungchul Park wrote: > > > >> Darrick posted the following warning and Dave Chinner analyzed it: > >> > >>> == > >>> WARNING: possible circular locking dependency

[PATCH RESEND] f2fs: support soft block reservation

From: Yunlong Song It supports to extend reserved_blocks sysfs interface to be soft threshold, which allows user configure it exceeding current available user space. Signed-off-by: Yunlong Song Signed-off-by: Chao Yu ---

[PATCH RESEND] f2fs: support soft block reservation

From: Yunlong Song It supports to extend reserved_blocks sysfs interface to be soft threshold, which allows user configure it exceeding current available user space. Signed-off-by: Yunlong Song Signed-off-by: Chao Yu --- Documentation/ABI/testing/sysfs-fs-f2fs | 3 ++- fs/f2fs/f2fs.h

Re: [PATCH] power: supply: 88pm860x_battery array_soc first number is in mV

On Thu, 2017-10-26 at 13:21 +0800, winton.liu wrote: > Fix wrong comments of array_soc description. > First number is mV not mAh. [] > diff --git a/drivers/power/supply/88pm860x_battery.c > b/drivers/power/supply/88pm860x_battery.c [] > @@ -123,7 +123,7 @@ struct ccnt { > > /* > * State of

Re: [PATCH] power: supply: 88pm860x_battery array_soc first number is in mV

On Thu, 2017-10-26 at 13:21 +0800, winton.liu wrote: > Fix wrong comments of array_soc description. > First number is mV not mAh. [] > diff --git a/drivers/power/supply/88pm860x_battery.c > b/drivers/power/supply/88pm860x_battery.c [] > @@ -123,7 +123,7 @@ struct ccnt { > > /* > * State of

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On 2017年10月26日 03:01, Eric Dumazet wrote: On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn wrote: From skb->dev and netdev_priv, the tun device has flags 0x1002 == IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for IFF_NAPI and

Re: v4.14-rc3/arm64 DABT exception in atomic_inc() / __skb_clone()

On 2017年10月26日 03:01, Eric Dumazet wrote: On Wed, Oct 25, 2017 at 11:49 AM, Willem de Bruijn wrote: From skb->dev and netdev_priv, the tun device has flags 0x1002 == IFF_TAP | IFF_NO_PI. This kernel precedes the recent support for IFF_NAPI and IFF_NAPI_FRAGS. The allocation most likely

[PATCH] power: supply: 88pm860x_battery array_soc first number is in mV

Fix wrong comments of array_soc description. First number is mV not mAh. Signed-off-by: winton.liu <18502523...@163.com> --- drivers/power/supply/88pm860x_battery.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/supply/88pm860x_battery.c

[PATCH] power: supply: 88pm860x_battery array_soc first number is in mV

Fix wrong comments of array_soc description. First number is mV not mAh. Signed-off-by: winton.liu <18502523...@163.com> --- drivers/power/supply/88pm860x_battery.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/supply/88pm860x_battery.c

[PATCH] Bluetooth: hci_ldisc: Fix another race when closing the tty.

The following race condition still existed: P1P2 cancel_work_sync() hci_uart_tx_wakeup() hci_uart_write_work() hci_uart_dequeue()

[PATCH] Bluetooth: hci_ldisc: Fix another race when closing the tty.

The following race condition still existed: P1P2 cancel_work_sync() hci_uart_tx_wakeup() hci_uart_write_work() hci_uart_dequeue()

[PATCH v4] Add /proc/PID/smaps support for DAX

Memory behind device DAX is not attached into normal memory management system, when user mmap /dev/dax, smaps part is currently missing, so no idea for user to check how much device DAX memory are actually used in practice. Whether vma is backed up by normal page,huge page, or both at the same

[PATCH v4] Add /proc/PID/smaps support for DAX

Memory behind device DAX is not attached into normal memory management system, when user mmap /dev/dax, smaps part is currently missing, so no idea for user to check how much device DAX memory are actually used in practice. Whether vma is backed up by normal page,huge page, or both at the same

[PATCH v2] Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.

Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races") introduced locks in hci_ldisc that are held while calling the proto functions. These locks are rwlock's, and hence do not allow sleeping while they are held. However, the proto

[PATCH v2] Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.

Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc: Use rwlocking to avoid closing proto races") introduced locks in hci_ldisc that are held while calling the proto functions. These locks are rwlock's, and hence do not allow sleeping while they are held. However, the proto

Re: [PATCH 2/3] usb: phy: remove phy-msm-usb.c

Hi, On 10/26/2017 3:31 AM, Alex Elder wrote: > No Qualcomm SoC requires the "phy-msm-usb.c" USB phy driver support > any more, so remove the code. > > Suggested-by: Stephen Boyd > Signed-off-by: Alex Elder > Acked-by: Bjorn Andersson

Re: [PATCH 2/3] usb: phy: remove phy-msm-usb.c

Hi, On 10/26/2017 3:31 AM, Alex Elder wrote: > No Qualcomm SoC requires the "phy-msm-usb.c" USB phy driver support > any more, so remove the code. > > Suggested-by: Stephen Boyd > Signed-off-by: Alex Elder > Acked-by: Bjorn Andersson > Acked-by: Andy Gross > --- > drivers/usb/phy/Makefile

Re: [PATCH v3 4/6] drm/rockchip/dsi: add dual mipi channel support

On 10/25/2017 01:34 PM, Sean Paul wrote: On Wed, Oct 25, 2017 at 11:51:01AM +0800, Nickey Yang wrote: This patch add dual mipi channel support: 1.add definition of dsi1 register and grf operation. 2.dsi0 and dsi1 will work in master and slave mode when driving dual mipi panel. Signed-off-by:

Re: [PATCH v3 4/6] drm/rockchip/dsi: add dual mipi channel support

On 10/25/2017 01:34 PM, Sean Paul wrote: On Wed, Oct 25, 2017 at 11:51:01AM +0800, Nickey Yang wrote: This patch add dual mipi channel support: 1.add definition of dsi1 register and grf operation. 2.dsi0 and dsi1 will work in master and slave mode when driving dual mipi panel. Signed-off-by:

Re: [PATCH 1/3] usb: host: remove ehci-msm.c

Hi, On 10/26/2017 3:31 AM, Alex Elder wrote: > No Qualcomm SoC requires the "ehci-msm.c" code any more. So remove it. > > Suggested-by: Stephen Boyd > Signed-off-by: Alex Elder > Acked-by: Bjorn Andersson > Acked-by: Andy

Re: [PATCH 1/3] usb: host: remove ehci-msm.c

Hi, On 10/26/2017 3:31 AM, Alex Elder wrote: > No Qualcomm SoC requires the "ehci-msm.c" code any more. So remove it. > > Suggested-by: Stephen Boyd > Signed-off-by: Alex Elder > Acked-by: Bjorn Andersson > Acked-by: Andy Gross > --- > drivers/usb/host/Makefile | 1 - >

Re: I2C-Octeon: Use common error handling code in octeon_i2c_probe()

> NAK.  We don't need any more Markus Elfring spam. Why do you not like another update suggestion for this use case? >> Add a jump target so that a specific error message is stored only once >> at the end of this function implementation. > > Please read C standard about duplicate literal

Re: I2C-Octeon: Use common error handling code in octeon_i2c_probe()

> NAK.  We don't need any more Markus Elfring spam. Why do you not like another update suggestion for this use case? >> Add a jump target so that a specific error message is stored only once >> at the end of this function implementation. > > Please read C standard about duplicate literal

Re: [PATCH] coccinelle: grep Options and Requires fields more precisely

On Thu, 26 Oct 2017, Masahiro Yamada wrote: > Currently, the required version for badzero.cocci is picked up from > its "Comments:" line since it contains the word "Requires". > > Surprisingly, ld-version.sh can extract the version number from the > string "Requires Coccinelle version

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Wed, Oct 25, 2017 at 11:47 PM, Ross Zwisler wrote: > Add a test that exercises DAX's new MAP_SYNC flag. > > This test creates a file and writes to it via an mmap(), but never syncs > via fsync/msync. This process is tracked via dm-log-writes, then replayed. > >

Re: [PATCH] coccinelle: grep Options and Requires fields more precisely

On Thu, 26 Oct 2017, Masahiro Yamada wrote: > Currently, the required version for badzero.cocci is picked up from > its "Comments:" line since it contains the word "Requires". > > Surprisingly, ld-version.sh can extract the version number from the > string "Requires Coccinelle version

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Wed, Oct 25, 2017 at 11:47 PM, Ross Zwisler wrote: > Add a test that exercises DAX's new MAP_SYNC flag. > > This test creates a file and writes to it via an mmap(), but never syncs > via fsync/msync. This process is tracked via dm-log-writes, then replayed. > > If MAP_SYNC is working the

[RFC PATCH] coccinelle: fix parallel build with CHECK=scripts/coccicheck

If I run the following: $ make -j8 C=1 CHECK=scripts/coccicheck lots of "coccicheck failed" messages are displayed. I do not know the coccinell internals, but I guess --jobs does not work well if spatch is invoked from Make running in parallel. Disable --jobs in this case. Signed-off-by:

[PATCH] [irq] Fix boot failure when irqaffinity is passed.

When irqaffinity kernel param is passed in a CPUMASK_OFFSTACK=y build kernel, it fails to boot. zalloc_cpumask_var() cannot be used before initializing mm stuff (slab allocator) to allocate cpumask. So, use alloc_bootmem_cpumask_var(). Also in init_irq_default_affinity() removes unneeded ifdef,

[RFC PATCH] coccinelle: fix parallel build with CHECK=scripts/coccicheck

If I run the following: $ make -j8 C=1 CHECK=scripts/coccicheck lots of "coccicheck failed" messages are displayed. I do not know the coccinell internals, but I guess --jobs does not work well if spatch is invoked from Make running in parallel. Disable --jobs in this case. Signed-off-by:

[PATCH] [irq] Fix boot failure when irqaffinity is passed.

When irqaffinity kernel param is passed in a CPUMASK_OFFSTACK=y build kernel, it fails to boot. zalloc_cpumask_var() cannot be used before initializing mm stuff (slab allocator) to allocate cpumask. So, use alloc_bootmem_cpumask_var(). Also in init_irq_default_affinity() removes unneeded ifdef,

Re: [PATCH V8 1/2] printk: remove tabular output for NULL pointer

On Thu, 2017-10-26 at 13:53 +1100, Tobin C. Harding wrote: > Currently pointer() checks for a NULL pointer argument and then if so > attempts to print "(null)" with _some_ standard width. This width cannot > correctly be ascertained here because many of the printk specifiers > print pointers of

Re: [PATCH V8 1/2] printk: remove tabular output for NULL pointer

On Thu, 2017-10-26 at 13:53 +1100, Tobin C. Harding wrote: > Currently pointer() checks for a NULL pointer argument and then if so > attempts to print "(null)" with _some_ standard width. This width cannot > correctly be ascertained here because many of the printk specifiers > print pointers of

[PATCH] coccinelle: fix verbose message about .cocci file being run

If you run coccicheck with V=1 and COCCI=, you will see a strange path to the semantic patch file. For example, run the following: $ make V=1 COCCI=scripts/coccinelle/free/kfree.cocci coccicheck [ snip ] The semantic patch that makes this report is available in

[PATCH] coccinelle: fix verbose message about .cocci file being run

If you run coccicheck with V=1 and COCCI=, you will see a strange path to the semantic patch file. For example, run the following: $ make V=1 COCCI=scripts/coccinelle/free/kfree.cocci coccicheck [ snip ] The semantic patch that makes this report is available in

[PATCH] coccinelle: grep Options and Requires fields more precisely

Currently, the required version for badzero.cocci is picked up from its "Comments:" line since it contains the word "Requires". Surprisingly, ld-version.sh can extract the version number from the string "Requires Coccinelle version 1.0.0-rc20 or later", but this expectation is fragile. Fix the

[PATCH] coccinelle: grep Options and Requires fields more precisely

Currently, the required version for badzero.cocci is picked up from its "Comments:" line since it contains the word "Requires". Surprisingly, ld-version.sh can extract the version number from the string "Requires Coccinelle version 1.0.0-rc20 or later", but this expectation is fragile. Fix the

Re: [PATCH v2] sparc: Provide cmpxchg64 for 32-bit builds

On Wed, 2017-10-25 at 19:51 -0700, Guenter Roeck wrote: > Fix the following build error, seen when building sparc32:allmodconfig. > > drivers/net/ethernet/intel/i40e/i40e_ethtool.c: > In function 'i40e_set_priv_flags': > drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4150:2: error: >

Re: [PATCH v2] sparc: Provide cmpxchg64 for 32-bit builds

On Wed, 2017-10-25 at 19:51 -0700, Guenter Roeck wrote: > Fix the following build error, seen when building sparc32:allmodconfig. > > drivers/net/ethernet/intel/i40e/i40e_ethtool.c: > In function 'i40e_set_priv_flags': > drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4150:2: error: >

Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

On 10/25/2017 09:21 AM, Nickey Yang wrote: Configure dsi slave channel when driving a panel which needs 2 DSI links. Signed-off-by: Nickey Yang --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 ++ 1 file changed, 2 insertions(+)

Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

On 10/25/2017 09:21 AM, Nickey Yang wrote: Configure dsi slave channel when driving a panel which needs 2 DSI links. Signed-off-by: Nickey Yang --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [PATCH v3] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

On Thu 05 Oct 09:43 PDT 2017, Anup Patel wrote: > Currently, RPMSG_VIRTIO can only be enabled if some other kconfig > option selects it. This does not allow it to be enabled for > virtualized systems where Virtio RPMSG is available over Virtio > MMIO or PCI transport. > > This patch updates

Re: [PATCH v3] rpmsg: Allow RPMSG_VIRTIO to be enabled via menuconfig or defconfig

On Thu 05 Oct 09:43 PDT 2017, Anup Patel wrote: > Currently, RPMSG_VIRTIO can only be enabled if some other kconfig > option selects it. This does not allow it to be enabled for > virtualized systems where Virtio RPMSG is available over Virtio > MMIO or PCI transport. > > This patch updates

Re: n900 in next-20170901

On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171022 21:51]: > > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [171019 18:53]: > > > > Oops... I made a mistak. Could you test

Re: n900 in next-20170901

On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171022 21:51]: > > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [171019 18:53]: > > > > Oops... I made a mistak. Could you test with reverting commit > > > >

Re: [PATCH v9 1/7] mailbox: qcom: Convert APCS IPC driver to use regmap

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > This hardware block provides more functionalities that just IPC. Convert > it to regmap to allow other child platform devices to use the same regmap. > Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH v9 1/7] mailbox: qcom: Convert APCS IPC driver to use regmap

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > This hardware block provides more functionalities that just IPC. Convert > it to regmap to allow other child platform devices to use the same regmap. > Acked-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH v9 7/7] clk: qcom: Add APCS clock controller support

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > Add a driver for the APCS clock controller. It is part of the APCS > hardware block, which among other things implements also a combined > mux and half integer divider functionality. It can choose between a > fixed-rate clock or the dedicated

Re: [PATCH v9 7/7] clk: qcom: Add APCS clock controller support

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > Add a driver for the APCS clock controller. It is part of the APCS > hardware block, which among other things implements also a combined > mux and half integer divider functionality. It can choose between a > fixed-rate clock or the dedicated

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > > Ping for Peter, Ingo and other sched maintainers: > > I'd appreciate any feedback on this hard lockup issue, which occurred > on a system running kernel 4.4.52-grsec. > > To recap: a dual-socket Xeon (E5

Re: sched/fair: Hard lockup from idle_balance()/task_numa_migrate() race

Ping? On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote: > > Ping for Peter, Ingo and other sched maintainers: > > I'd appreciate any feedback on this hard lockup issue, which occurred > on a system running kernel 4.4.52-grsec. > > To recap: a dual-socket Xeon (E5 v4) server system had been

Re: [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > Move the structure shared by the APCS IPC device and its subdevices > into a separate header file. > As you're creating the apcs regmap with devm_regmap_init_mmio() you can just call dev_get_regmap(dev->parent) in your child to get the

Re: [PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > Move the structure shared by the APCS IPC device and its subdevices > into a separate header file. > As you're creating the apcs regmap with devm_regmap_init_mmio() you can just call dev_get_regmap(dev->parent) in your child to get the

Re: [PATCH v9 4/7] clk: qcom: Add A53 PLL support

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > diff --git a/drivers/clk/qcom/a53-pll.c b/drivers/clk/qcom/a53-pll.c [..] > + > +static const struct of_device_id qcom_a53pll_match_table[] = { > + { .compatible = "qcom,msm8916-a53pll" }, > + { } > +}; Move the match table below the

Re: [PATCH v9 4/7] clk: qcom: Add A53 PLL support

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > diff --git a/drivers/clk/qcom/a53-pll.c b/drivers/clk/qcom/a53-pll.c [..] > + > +static const struct of_device_id qcom_a53pll_match_table[] = { > + { .compatible = "qcom,msm8916-a53pll" }, > + { } > +}; Move the match table below the

Re: [PATCH v9 6/7] dt-bindings: clock: Document qcom,apcs binding

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > Add device-tree binding documentation for the Qualcom APCS clock > controller. This clock controller is a mux and half-integer divider > and provides the clock for the application CPU. > > Signed-off-by: Georgi Djakov

Re: [PATCH v9 6/7] dt-bindings: clock: Document qcom,apcs binding

On Thu 21 Sep 09:49 PDT 2017, Georgi Djakov wrote: > Add device-tree binding documentation for the Qualcom APCS clock > controller. This clock controller is a mux and half-integer divider > and provides the clock for the application CPU. > > Signed-off-by: Georgi Djakov > --- >

Re: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting

Hi, On 10/26/2017 06:39 AM, Brian Norris wrote: On Wed, Oct 25, 2017 at 03:57:19AM -0400, Sean Paul wrote: Archit asked a question about moving to dw-mipi-dsi That question made me think though: this approach seems backwards. It seems like someone did copy/paste/fork, and then we're asking

Re: [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting

Hi, On 10/26/2017 06:39 AM, Brian Norris wrote: On Wed, Oct 25, 2017 at 03:57:19AM -0400, Sean Paul wrote: Archit asked a question about moving to dw-mipi-dsi That question made me think though: this approach seems backwards. It seems like someone did copy/paste/fork, and then we're asking

Re: [PATCH] Coccinelle: make DEBUG_FILE option more useful

On Thu, 26 Oct 2017, Masahiro Yamada wrote: > Hi Julia, > > > 2017-10-15 18:55 GMT+09:00 Julia Lawall : > > Make coccicheck checked for the existence of DEBUG_FILE on each semantic > > patch, and bailed if it already existed. This meant that DEBUG_FILE was > > useless for

Re: [PATCH] Coccinelle: make DEBUG_FILE option more useful

On Thu, 26 Oct 2017, Masahiro Yamada wrote: > Hi Julia, > > > 2017-10-15 18:55 GMT+09:00 Julia Lawall : > > Make coccicheck checked for the existence of DEBUG_FILE on each semantic > > patch, and bailed if it already existed. This meant that DEBUG_FILE was > > useless for checking more than

Re: Detecting page cache trashing state

On Thu, Sep 28, 2017 at 9:19 PM, Ruslan Ruslichenko -X (rruslich - GLOBALLOGIC INC at Cisco) wrote: > Hi Johannes, > > Hopefully I was able to rebase the patch on top v4.9.26 (latest supported > version by us right now) > and test a bit. > The overall idea definitely looks

Re: Detecting page cache trashing state

On Thu, Sep 28, 2017 at 9:19 PM, Ruslan Ruslichenko -X (rruslich - GLOBALLOGIC INC at Cisco) wrote: > Hi Johannes, > > Hopefully I was able to rebase the patch on top v4.9.26 (latest supported > version by us right now) > and test a bit. > The overall idea definitely looks promising, although I

Re: [PATCH] thermal: cpu_cooling: pr_err() strings should end with newlines

On 24-10-17, 13:20, Arvind Yadav wrote: > pr_err() messages should end with a new-line to avoid other messages > being concatenated. > > Signed-off-by: Arvind Yadav > --- > drivers/thermal/cpu_cooling.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [PATCH] thermal: cpu_cooling: pr_err() strings should end with newlines

On 24-10-17, 13:20, Arvind Yadav wrote: > pr_err() messages should end with a new-line to avoid other messages > being concatenated. > > Signed-off-by: Arvind Yadav > --- > drivers/thermal/cpu_cooling.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

Agree On 2017/10/26 11:26, Chao Yu wrote: On 2017/10/26 11:07, Yunlong Song wrote: Yes, I agree with the soft semantic you introduce, it is too slow to increase cur_reserved_blocks only in dec_valid_block(,node)_count, e.g. if users want to set cur_reserved_blocks to 10G. Yup, Then how

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

Agree On 2017/10/26 11:26, Chao Yu wrote: On 2017/10/26 11:07, Yunlong Song wrote: Yes, I agree with the soft semantic you introduce, it is too slow to increase cur_reserved_blocks only in dec_valid_block(,node)_count, e.g. if users want to set cur_reserved_blocks to 10G. Yup, Then how

[PATCH] power: supply: 88pm860x_battery array_soc first number is in mV

0001-power-supply-88pm860x_battery-array_soc-first-number.patch Description: Binary data

[PATCH] power: supply: 88pm860x_battery array_soc first number is in mV

0001-power-supply-88pm860x_battery-array_soc-first-number.patch Description: Binary data

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

On 2017/10/26 11:07, Yunlong Song wrote: > Yes, I agree with the soft semantic you introduce, it is too slow to > increase cur_reserved_blocks only in > dec_valid_block(,node)_count, e.g. if users want to set > cur_reserved_blocks to 10G. Yup, > > Then how about fix the initialization of

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

On 2017/10/26 11:07, Yunlong Song wrote: > Yes, I agree with the soft semantic you introduce, it is too slow to > increase cur_reserved_blocks only in > dec_valid_block(,node)_count, e.g. if users want to set > cur_reserved_blocks to 10G. Yup, > > Then how about fix the initialization of

Re: [PATCH V8 2/2] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 4:53 AM, Tobin C. Harding wrote: > +static bool have_filled_random_ptr_key; __read_mostly

Re: [PATCH V8 2/2] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 4:53 AM, Tobin C. Harding wrote: > +static bool have_filled_random_ptr_key; __read_mostly

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

Yes, I agree with the soft semantic you introduce, it is too slow to increase cur_reserved_blocks only in dec_valid_block(,node)_count, e.g. if users want to set cur_reserved_blocks to 10G. Then how about fix the initialization of cur_reserved_blocks in fs/f2fs/super.c as following:

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

Yes, I agree with the soft semantic you introduce, it is too slow to increase cur_reserved_blocks only in dec_valid_block(,node)_count, e.g. if users want to set cur_reserved_blocks to 10G. Then how about fix the initialization of cur_reserved_blocks in fs/f2fs/super.c as following:

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

Hi Laurent, On Thu, Oct 26, 2017 at 12:48 AM, Laurent Pinchart wrote: > Hello, > > On Monday, 23 October 2017 11:45:01 EEST Alexandre Courbot wrote: >> On Thu, Oct 19, 2017 at 11:43 PM, Sakari Ailus wrote: >> > On Thu, Sep 28, 2017 at

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

Hi Laurent, On Thu, Oct 26, 2017 at 12:48 AM, Laurent Pinchart wrote: > Hello, > > On Monday, 23 October 2017 11:45:01 EEST Alexandre Courbot wrote: >> On Thu, Oct 19, 2017 at 11:43 PM, Sakari Ailus wrote: >> > On Thu, Sep 28, 2017 at 06:50:18PM +0900, Alexandre Courbot wrote: [snip] >> > Both

[tip:sched/core 58/58] ERROR: "housekeeping_cpumask" [drivers/net/ethernet/tile/tile_net.ko] undefined!

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core head: 32bf454c0e7568e0fdea85434d573daf1bbaff4a commit: 32bf454c0e7568e0fdea85434d573daf1bbaff4a [58/58] housekeeping: Handle the nohz_full= parameter config: tile-allmodconfig (attached as .config) compiler:

[tip:sched/core 58/58] ERROR: "housekeeping_cpumask" [drivers/net/ethernet/tile/tile_net.ko] undefined!

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core head: 32bf454c0e7568e0fdea85434d573daf1bbaff4a commit: 32bf454c0e7568e0fdea85434d573daf1bbaff4a [58/58] housekeeping: Handle the nohz_full= parameter config: tile-allmodconfig (attached as .config) compiler:

Re: [PATCH 0/2] cpufreq: arm_big_little: make function arguments and structures const

On 19-10-17, 12:59, Bhumika Goyal wrote: > Make some function arguments as const. After this change make the > cpufreq_arm_bL_ops structures const. Acked-by: Viresh Kumar -- viresh

Re: [PATCH 0/2] cpufreq: arm_big_little: make function arguments and structures const

On 19-10-17, 12:59, Bhumika Goyal wrote: > Make some function arguments as const. After this change make the > cpufreq_arm_bL_ops structures const. Acked-by: Viresh Kumar -- viresh

Re: [PATCH V8 2/2] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 01:53:56PM +1100, Tobin C. Harding wrote: > Currently there are many places in the kernel where addresses are being > printed using an unadorned %p. Kernel pointers should be printed using > %pK allowing some control via the kptr_restrict sysctl. Exposing addresses > gives

Re: [PATCH V8 2/2] printk: hash addresses printed with %p

On Thu, Oct 26, 2017 at 01:53:56PM +1100, Tobin C. Harding wrote: > Currently there are many places in the kernel where addresses are being > printed using an unadorned %p. Kernel pointers should be printed using > %pK allowing some control via the kptr_restrict sysctl. Exposing addresses > gives

[PATCH V8 2/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

[PATCH V8 2/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

[PATCH V8 1/2] printk: remove tabular output for NULL pointer

Currently pointer() checks for a NULL pointer argument and then if so attempts to print "(null)" with _some_ standard width. This width cannot correctly be ascertained here because many of the printk specifiers print pointers of varying widths. Remove the attempt to print NULL pointers with a

[PATCH V8 0/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

[PATCH V8 1/2] printk: remove tabular output for NULL pointer

Currently pointer() checks for a NULL pointer argument and then if so attempts to print "(null)" with _some_ standard width. This width cannot correctly be ascertained here because many of the printk specifiers print pointers of varying widths. Remove the attempt to print NULL pointers with a

[PATCH V8 0/2] printk: hash addresses printed with %p

Currently there are many places in the kernel where addresses are being printed using an unadorned %p. Kernel pointers should be printed using %pK allowing some control via the kptr_restrict sysctl. Exposing addresses gives attackers sensitive information about the kernel layout in memory. We can

[PATCH v2] sparc: Provide cmpxchg64 for 32-bit builds

Fix the following build error, seen when building sparc32:allmodconfig. drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function 'i40e_set_priv_flags': drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4150:2: error: implicit declaration of function 'cmpxchg64' Signed-off-by:

[PATCH v2] sparc: Provide cmpxchg64 for 32-bit builds

Fix the following build error, seen when building sparc32:allmodconfig. drivers/net/ethernet/intel/i40e/i40e_ethtool.c: In function 'i40e_set_priv_flags': drivers/net/ethernet/intel/i40e/i40e_ethtool.c:4150:2: error: implicit declaration of function 'cmpxchg64' Signed-off-by:

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

Hi Sakari, On Thu, Oct 19, 2017 at 11:43 PM, Sakari Ailus wrote: > Hi Alexandre, > > On Thu, Sep 28, 2017 at 06:50:18PM +0900, Alexandre Courbot wrote: >> Hi everyone, >> [snip] > > Still it shouldn't be forgotten that if the framework is geared towards > helping drivers

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

Hi Sakari, On Thu, Oct 19, 2017 at 11:43 PM, Sakari Ailus wrote: > Hi Alexandre, > > On Thu, Sep 28, 2017 at 06:50:18PM +0900, Alexandre Courbot wrote: >> Hi everyone, >> [snip] > > Still it shouldn't be forgotten that if the framework is geared towards > helping drivers "running one job at a

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

On Tue, Oct 24, 2017 at 10:12:58AM +0200, Vlastimil Babka wrote: > On 10/24/2017 06:44 AM, Joonsoo Kim wrote: > >>> I'm not sure what is the confusing semantic you mentioned. I think > >>> that set_migratetype_isolate() has confusing semantic and should be > >>> fixed since making the pageblock

Re: [PATCH 1/2] mm: drop migrate type checks from has_unmovable_pages

On Tue, Oct 24, 2017 at 10:12:58AM +0200, Vlastimil Babka wrote: > On 10/24/2017 06:44 AM, Joonsoo Kim wrote: > >>> I'm not sure what is the confusing semantic you mentioned. I think > >>> that set_migratetype_isolate() has confusing semantic and should be > >>> fixed since making the pageblock

  1   2   3   4   5   6   7   8   9   10   >