Re: [PATCH v2] mm: introduce validity check on vm dirtiness settings

2017-09-20 23:33 GMT+08:00 Jan Kara : > On Tue 19-09-17 19:48:00, Yafang Shao wrote: >> 2017-09-19 16:35 GMT+08:00 Jan Kara : >> > On Tue 19-09-17 06:53:00, Yafang Shao wrote: >> >> + if (vm_dirty_bytes == 0 && vm_dirty_ratio == 0 && >> >> + (dirty_background_bytes != 0 ||

Re: usb/hid: slab-out-of-bounds read in usbhid_parse

Hi Alan 2017-09-21 0:50 GMT+09:00 Alan Stern : > On Wed, 20 Sep 2017, Kim Jaejoong wrote: > >> To. usb & input guys. >> >> While dig this report, i was wondering about bNumDescriptors in HID >> descriptor. >> HID document from usb.org said, 'this number must be at least one (1) >> as a Report

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Sep 20, 2017 at 05:27:02PM -0700, Dave Hansen wrote: > On 09/20/2017 05:09 PM, Tycho Andersen wrote: > >> I think the only thing that will really help here is if you batch the > >> allocations. For instance, you could make sure that the per-cpu-pageset > >> lists always contain either all

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Sep 20, 2017 at 05:27:02PM -0700, Dave Hansen wrote: > On 09/20/2017 05:09 PM, Tycho Andersen wrote: > >> I think the only thing that will really help here is if you batch the > >> allocations. For instance, you could make sure that the per-cpu-pageset > >> lists always contain either all

Re: [PATCH] block: consider merge of segments when merge bio into rq

On 09/21/2017 09:29 AM, Christoph Hellwig wrote: > So the check change here looks good to me. > > I don't like like the duplicate code, can you look into sharing > the new segment checks between the two functions and the existing > instance in ll_merge_requests_fn by passing say two struct bio

Re: [PATCH] block: consider merge of segments when merge bio into rq

On 09/21/2017 09:29 AM, Christoph Hellwig wrote: > So the check change here looks good to me. > > I don't like like the duplicate code, can you look into sharing > the new segment checks between the two functions and the existing > instance in ll_merge_requests_fn by passing say two struct bio

[PATCH] mm, swap: Make VMA based swap readahead configurable

From: Huang Ying This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif. This is more friendly for tiny kernels. And as pointed to by Minchan Kim, give people who want to disable the

[PATCH] mm, swap: Make VMA based swap readahead configurable

From: Huang Ying This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif. This is more friendly for tiny kernels. And as pointed to by Minchan Kim, give people who want to disable the swap readahead an

[V2] block: consider merge of segments when merge bio into rq

When account the nr_phys_segments during merging bios into rq, only consider segments merging in individual bio but not all the bios in a rq. This leads to the bigger nr_phys_segments of rq than the real one when the segments of bios in rq are contiguous and mergeable. The nr_phys_segments of rq

[V2] block: consider merge of segments when merge bio into rq

When account the nr_phys_segments during merging bios into rq, only consider segments merging in individual bio but not all the bios in a rq. This leads to the bigger nr_phys_segments of rq than the real one when the segments of bios in rq are contiguous and mergeable. The nr_phys_segments of rq

Re: [PATCH] block: consider merge of segments when merge bio into rq

So the check change here looks good to me. I don't like like the duplicate code, can you look into sharing the new segment checks between the two functions and the existing instance in ll_merge_requests_fn by passing say two struct bio *bio1 and struct bio *bio2 pointer instead of using req->bio

Re: [PATCH] block: consider merge of segments when merge bio into rq

So the check change here looks good to me. I don't like like the duplicate code, can you look into sharing the new segment checks between the two functions and the existing instance in ll_merge_requests_fn by passing say two struct bio *bio1 and struct bio *bio2 pointer instead of using req->bio

Re: 4.13 breaks suspend to ram wakeup

On Thu, Sep 21, 2017 at 12:48 AM, Norbert Preining wrote: > Dear all, > > thanks for the quick feedback. > > On Wed, 20 Sep 2017, Ming Lei wrote: >> Looks your issue is very similar with Oleksandr's report: > > Indeed, I am using dm-crypt (full disk encryption) and >

Re: 4.13 breaks suspend to ram wakeup

On Thu, Sep 21, 2017 at 12:48 AM, Norbert Preining wrote: > Dear all, > > thanks for the quick feedback. > > On Wed, 20 Sep 2017, Ming Lei wrote: >> Looks your issue is very similar with Oleksandr's report: > > Indeed, I am using dm-crypt (full disk encryption) and >

[PATCH 3/3] arm64: dts: mt2712: Add auxadc device node.

Add auxadc device node for MT2712. Signed-off-by: Zhiyong Tao --- This patch dependents on "Mediatek MT2712 clock and scpsys support"[1]. Please accept this patch together with [1]. [1]http://lists.infradead.org/pipermail/linux-mediatek/2017-September/010461.html ---

[PATCH 3/3] arm64: dts: mt2712: Add auxadc device node.

Add auxadc device node for MT2712. Signed-off-by: Zhiyong Tao --- This patch dependents on "Mediatek MT2712 clock and scpsys support"[1]. Please accept this patch together with [1]. [1]http://lists.infradead.org/pipermail/linux-mediatek/2017-September/010461.html ---

[PATCH 0/3] AUXADC: Mediatek auxadc driver for mt2712

This series includes three patches: 1.Add mt2712 auxadc compatible node in binding document. 2.Add mt2712 auxadc compatible node in "mt6577_auxadc.c". 2.Add mt2712 auxadc device node. Zhiyong Tao (3): dt-bindings: adc: mt2712: add binding document iio: adc: mt2712: Add compatible node for

[PATCH 0/3] AUXADC: Mediatek auxadc driver for mt2712

This series includes three patches: 1.Add mt2712 auxadc compatible node in binding document. 2.Add mt2712 auxadc compatible node in "mt6577_auxadc.c". 2.Add mt2712 auxadc device node. Zhiyong Tao (3): dt-bindings: adc: mt2712: add binding document iio: adc: mt2712: Add compatible node for

[PATCH 2/3] iio: adc: mt2712: Add compatible node for mt2712.

This commit adds mt2712 compatible node. Signed-off-by: Zhiyong Tao --- drivers/iio/adc/mt6577_auxadc.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c index 414cf44..70bfa1e 100644 ---

[PATCH 2/3] iio: adc: mt2712: Add compatible node for mt2712.

This commit adds mt2712 compatible node. Signed-off-by: Zhiyong Tao --- drivers/iio/adc/mt6577_auxadc.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c index 414cf44..70bfa1e 100644 --- a/drivers/iio/adc/mt6577_auxadc.c

[PATCH 1/3] dt-bindings: adc: mt2712: add binding document

The commit adds mt2712 compatible node in binding document. Signed-off-by: Zhiyong Tao --- .../devicetree/bindings/iio/adc/mt6577_auxadc.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt

[PATCH 1/3] dt-bindings: adc: mt2712: add binding document

The commit adds mt2712 compatible node in binding document. Signed-off-by: Zhiyong Tao --- .../devicetree/bindings/iio/adc/mt6577_auxadc.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt

Re: [PATCH v2] Makefile: kselftest and kselftest-clean fail for make O=dir case

2017-09-21 2:32 GMT+09:00 Shuah Khan : > kselftest and kselftest-clean targets fail when object directory is > specified to relocate objects. Fix it so it can find the source tree > to build from. > > make O=/tmp/kselftest_top kselftest > > make[1]: Entering directory

Re: [PATCH v2] Makefile: kselftest and kselftest-clean fail for make O=dir case

2017-09-21 2:32 GMT+09:00 Shuah Khan : > kselftest and kselftest-clean targets fail when object directory is > specified to relocate objects. Fix it so it can find the source tree > to build from. > > make O=/tmp/kselftest_top kselftest > > make[1]: Entering directory '/tmp/kselftest_top' >

Re: [PATCH 2/2] mfd: intel-lpss: switch to suspend_late()/resume_early()

On Wed, Sep 20, 2017 at 5:27 PM, Rafael J. Wysocki wrote: > On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: >> Ref: https://lkml.org/lkml/2017/9/19/649 >> >> The intel-lpss hosts the designware i2c controller device, which >> needs to be up and running

Re: [PATCH 2/2] mfd: intel-lpss: switch to suspend_late()/resume_early()

On Wed, Sep 20, 2017 at 5:27 PM, Rafael J. Wysocki wrote: > On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: >> Ref: https://lkml.org/lkml/2017/9/19/649 >> >> The intel-lpss hosts the designware i2c controller device, which >> needs to be up and running until all its i2c child devices have >>

Re: [PATCH 1/2] i2c: designware: switch to suspend_late/resume_early

On Wed, Sep 20, 2017 at 5:24 PM, Rafael J. Wysocki wrote: > On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: >> Ref: https://lkml.org/lkml/2017/9/19/649 >> >> The bus controllers should suspend the bus operations only after >> all of the devices on the

Re: [PATCH 1/2] i2c: designware: switch to suspend_late/resume_early

On Wed, Sep 20, 2017 at 5:24 PM, Rafael J. Wysocki wrote: > On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: >> Ref: https://lkml.org/lkml/2017/9/19/649 >> >> The bus controllers should suspend the bus operations only after >> all of the devices on the bus have suspended their device >>

Re: [RFC RESEND 3/3] arm: dts: add Hi3521A dts

On Wed, Sep 20, 2017 at 6:04 PM, Marty E. Plummer wrote: > On Wed, Sep 20, 2017 at 08:53:03PM +, Rob Herring wrote: >> On Sun, Sep 17, 2017 at 03:23:27AM -0500, Marty E. Plummer wrote: >> > Add hi3521a.dtsi and hi3521a-rs-dm290e.dts for RaySharp CCTV systems, >> >

Re: [RFC RESEND 3/3] arm: dts: add Hi3521A dts

On Wed, Sep 20, 2017 at 6:04 PM, Marty E. Plummer wrote: > On Wed, Sep 20, 2017 at 08:53:03PM +, Rob Herring wrote: >> On Sun, Sep 17, 2017 at 03:23:27AM -0500, Marty E. Plummer wrote: >> > Add hi3521a.dtsi and hi3521a-rs-dm290e.dts for RaySharp CCTV systems, >> > marketed under the name

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

Some platforms (e.g: Broadcom STB: BMIPS_GENERIC/ARCH_BRCMSTB) will lose their register contents when entering their lower power state. In such a case, the pinctrl-single driver that is used will not be able to restore the power states without telling the core about it and having

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

Some platforms (e.g: Broadcom STB: BMIPS_GENERIC/ARCH_BRCMSTB) will lose their register contents when entering their lower power state. In such a case, the pinctrl-single driver that is used will not be able to restore the power states without telling the core about it and having

[PATCH 0/2] pinctrl: Allow indicating loss of state across suspend/resume

Hello Linus, It's me again, so I have been thinking about the problem originally reported in: [PATCH fixes v3] pinctrl: Really force states during suspend/resume and other similar patches a while ago, and this new version allows a platform using pinctrl-single to specify whether its pins are

[PATCH 1/2] pinctrl: Allow a device to indicate when to force a state

It may happen that a device needs to force applying a state, e.g: because it only defines one state of pin states (default) but loses power/register contents when entering low power modes. Add a pinctrl_dev::flags bitmask to help describe future quirks and define PINCTRL_FLG_FORCE_STATE as such a

[PATCH 0/2] pinctrl: Allow indicating loss of state across suspend/resume

Hello Linus, It's me again, so I have been thinking about the problem originally reported in: [PATCH fixes v3] pinctrl: Really force states during suspend/resume and other similar patches a while ago, and this new version allows a platform using pinctrl-single to specify whether its pins are

[PATCH 1/2] pinctrl: Allow a device to indicate when to force a state

It may happen that a device needs to force applying a state, e.g: because it only defines one state of pin states (default) but loses power/register contents when entering low power modes. Add a pinctrl_dev::flags bitmask to help describe future quirks and define PINCTRL_FLG_FORCE_STATE as such a

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Sep 20, 2017 at 05:28:11PM -0700, Dave Hansen wrote: > At a high level, does this approach keep an attacker from being able to > determine the address of data in the linear map, or does it keep them > from being able to *exploit* it? It keeps them from exploiting it, by faulting when a

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Sep 20, 2017 at 05:28:11PM -0700, Dave Hansen wrote: > At a high level, does this approach keep an attacker from being able to > determine the address of data in the linear map, or does it keep them > from being able to *exploit* it? It keeps them from exploiting it, by faulting when a

Re: [PATCH 7/7] drm/rockchip: Cocci spatch "vma_pages"

On 2017年09月21日 06:29, Thomas Meyer wrote: Use vma_pages function on vma object instead of explicit computation. Found by coccinelle spatch "api/vma_pages.cocci" Signed-off-by: Thomas Meyer --- Looks good for me: Acked-by: Mark Yao diff -u -p

Re: [PATCH 7/7] drm/rockchip: Cocci spatch "vma_pages"

On 2017年09月21日 06:29, Thomas Meyer wrote: Use vma_pages function on vma object instead of explicit computation. Found by coccinelle spatch "api/vma_pages.cocci" Signed-off-by: Thomas Meyer --- Looks good for me: Acked-by: Mark Yao diff -u -p a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c

[PATCH 1/2] uio: dt-bindings: document binding for uio-pdrv-genirq

Signed-off-by: Chris Packham --- .../bindings/uio/linux,uio-pdrv-genirq.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/uio/linux,uio-pdrv-genirq.txt diff --git

[PATCH 1/2] uio: dt-bindings: document binding for uio-pdrv-genirq

Signed-off-by: Chris Packham --- .../bindings/uio/linux,uio-pdrv-genirq.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/uio/linux,uio-pdrv-genirq.txt diff --git

[PATCH 0/2] using uio_pdrv_genirq without module param

I found myself about to add a driver that was a sub-optimal clone of uio_pdrv_genirq the only difference was that I didn't want to modify the args passed to the kernel by my bootloader. If uio_pdrv_genirq had a default of_match entry I could simply use that. This series attempts to implement this.

[PATCH 0/2] using uio_pdrv_genirq without module param

I found myself about to add a driver that was a sub-optimal clone of uio_pdrv_genirq the only difference was that I didn't want to modify the args passed to the kernel by my bootloader. If uio_pdrv_genirq had a default of_match entry I could simply use that. This series attempts to implement this.

[PATCH 2/2] uio: add default compatible string to uio_pdrv_genirq

Add a default compatible string "linux,uio-pdrv-genirq" to uio_pdrv_genirq to make it usable without supplying a module parameter. The module parameter is still supported in addition to the default. Signed-off-by: Chris Packham ---

[PATCH 2/2] uio: add default compatible string to uio_pdrv_genirq

Add a default compatible string "linux,uio-pdrv-genirq" to uio_pdrv_genirq to make it usable without supplying a module parameter. The module parameter is still supported in addition to the default. Signed-off-by: Chris Packham --- drivers/uio/uio_pdrv_genirq.c | 3 ++- 1 file changed, 2

Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

On 09/20/2017 04:37 PM, Mario Hüttel wrote: > > > On 09/20/2017 10:19 PM, Franklin S Cooper Jr wrote: >> Hi Wenyou, >> >> On 09/17/2017 10:47 PM, Yang, Wenyou wrote: >>> >>> On 2017/9/14 13:06, Sekhar Nori wrote: On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote: > On

Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

On 09/20/2017 04:37 PM, Mario Hüttel wrote: > > > On 09/20/2017 10:19 PM, Franklin S Cooper Jr wrote: >> Hi Wenyou, >> >> On 09/17/2017 10:47 PM, Yang, Wenyou wrote: >>> >>> On 2017/9/14 13:06, Sekhar Nori wrote: On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote: > On

Re: [PATCH] arc: remove redundant UTS_MACHINE define in arch/arc/Makefile

On 09/20/2017 04:25 AM, Masahiro Yamada wrote: The top-level Makefile sets the default of UTS_MACHINE to $(ARCH). If ARCH and UTS_MACHINE match, arch/$(ARCH)/Makefile need not specify UTS_MACHINE explicitly. Signed-off-by: Masahiro Yamada Thx Masahiro san !

Re: [PATCH] arc: remove redundant UTS_MACHINE define in arch/arc/Makefile

On 09/20/2017 04:25 AM, Masahiro Yamada wrote: The top-level Makefile sets the default of UTS_MACHINE to $(ARCH). If ARCH and UTS_MACHINE match, arch/$(ARCH)/Makefile need not specify UTS_MACHINE explicitly. Signed-off-by: Masahiro Yamada Thx Masahiro san ! Applied to for-curr ! -Vineet

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 6:15 PM, Alan Stern wrote: > On Wed, 20 Sep 2017, Rafael J. Wysocki wrote: > >> >> Second, leaving devices in runtime suspend in the "suspend" phase of >> >> system >> >> suspend is fishy even when their runtime PM is disabled, because that >>

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 6:15 PM, Alan Stern wrote: > On Wed, 20 Sep 2017, Rafael J. Wysocki wrote: > >> >> Second, leaving devices in runtime suspend in the "suspend" phase of >> >> system >> >> suspend is fishy even when their runtime PM is disabled, because that >> >> doesn't >> >> guarantee

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach wrote: > On Wed, Sep 20, 2017 at 04:01:32PM +0200, Rafael J. Wysocki wrote: >> On Wed, Sep 20, 2017 at 2:28 PM, Ulf Hansson wrote: >> > On 20 September 2017 at 02:26, Rafael J. Wysocki

Re: [PATCH] PM: Document rules on using pm_runtime_resume() in system suspend callbacks

On Wed, Sep 20, 2017 at 6:27 PM, Johannes Stezenbach wrote: > On Wed, Sep 20, 2017 at 04:01:32PM +0200, Rafael J. Wysocki wrote: >> On Wed, Sep 20, 2017 at 2:28 PM, Ulf Hansson wrote: >> > On 20 September 2017 at 02:26, Rafael J. Wysocki >> > wrote: >> >> >> >> Second, leaving devices in

Re: Read-only `slaves` with shared subtrees?

On Wed, Sep 20, 2017 at 06:06:55PM -0500, Eric W. Biederman wrote: > ebied...@xmission.com (Eric W. Biederman) writes: > > > Ram Pai writes: > > > >> sorry forgot to copy Eric. > > > > Adding fs-devel as well. > > > >> On Wed, Sep 20, 2017 at 12:39:54PM -0700, Ram Pai wrote:

Re: Read-only `slaves` with shared subtrees?

On Wed, Sep 20, 2017 at 06:06:55PM -0500, Eric W. Biederman wrote: > ebied...@xmission.com (Eric W. Biederman) writes: > > > Ram Pai writes: > > > >> sorry forgot to copy Eric. > > > > Adding fs-devel as well. > > > >> On Wed, Sep 20, 2017 at 12:39:54PM -0700, Ram Pai wrote: > >>> On Tue, Sep

Re: [v2,3/3] can: m_can: Add PM Runtime

On 08/24/2017 03:30 AM, Sekhar Nori wrote: > + OMAP mailing list > > On Tuesday 25 July 2017 04:21 AM, Franklin Cooper wrote: >> Add support for PM Runtime which is the new way to handle managing clocks. >> However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk >> management

Re: [BACKPORT] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

On Wed, 20 Sep 2017, Leonard Crestez wrote: > On Mon, 2017-09-18 at 11:08 -0700, Stefano Stabellini wrote: > On Fri, 15 Sep 2017, Greg KH wrote: > > On Thu, Sep 14, 2017 at 04:23:05PM -0700, Stefano Stabellini wrote: > > > Hi all, > > >  > > > We are getting reports from Xen on ARM users about DMA

Re: [v2,3/3] can: m_can: Add PM Runtime

On 08/24/2017 03:30 AM, Sekhar Nori wrote: > + OMAP mailing list > > On Tuesday 25 July 2017 04:21 AM, Franklin Cooper wrote: >> Add support for PM Runtime which is the new way to handle managing clocks. >> However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk >> management

Re: [BACKPORT] swiotlb-xen: implement xen_swiotlb_dma_mmap callback

On Wed, 20 Sep 2017, Leonard Crestez wrote: > On Mon, 2017-09-18 at 11:08 -0700, Stefano Stabellini wrote: > On Fri, 15 Sep 2017, Greg KH wrote: > > On Thu, Sep 14, 2017 at 04:23:05PM -0700, Stefano Stabellini wrote: > > > Hi all, > > >  > > > We are getting reports from Xen on ARM users about DMA

[PATCH v2 5/8] PM / devfreq: Get the available next frequency on update_devfreq()

The update_devfreq() considers only user frequency (min_freq/max_freq) and the next target_freq provided by the governor. But, The commit a76caf55e5b35 ("thermal: Add devfreq cooling") is able to disable OPP as a cooling device. In result, the update_devfreq() have to consider the

[PATCH v2 5/8] PM / devfreq: Get the available next frequency on update_devfreq()

The update_devfreq() considers only user frequency (min_freq/max_freq) and the next target_freq provided by the governor. But, The commit a76caf55e5b35 ("thermal: Add devfreq cooling") is able to disable OPP as a cooling device. In result, the update_devfreq() have to consider the

[PATCH v2 6/8] PM / devfreq: Remove unneeded conditional statement

The commit 0ec09ac2cebe9 ("PM / devfreq: Set the freq_table of devfreq device") initializes the freq_table array of each devfreq device always. In result, it is unneeded to check whether profile->freq_table is NULL or not. Signed-off-by: Chanwoo Choi ---

[PATCH v2 6/8] PM / devfreq: Remove unneeded conditional statement

The commit 0ec09ac2cebe9 ("PM / devfreq: Set the freq_table of devfreq device") initializes the freq_table array of each devfreq device always. In result, it is unneeded to check whether profile->freq_table is NULL or not. Signed-off-by: Chanwoo Choi --- drivers/devfreq/devfreq.c | 7 +++ 1

[PATCH v2 7/8] PM / devfreq: Define the constant governor name

Prior to that, the devfreq device uses the governor name when adding the itself. In order to prevent the mistake used the wrong governor name, this patch defines the governor name as a constant and then uses them instead of using the string directly. Signed-off-by: Chanwoo Choi

[PATCH v2 3/8] 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 v2 3/8] 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 v2 7/8] PM / devfreq: Define the constant governor name

Prior to that, the devfreq device uses the governor name when adding the itself. In order to prevent the mistake used the wrong governor name, this patch defines the governor name as a constant and then uses them instead of using the string directly. Signed-off-by: Chanwoo Choi Cc: Kukjin Kim

[PATCH v2 8/8] PM / devfreq: exynos-bus: Register cooling device

This patch registers the Exynos Bus-Frequency scaling device as a cooling device of thermal management. Signed-off-by: Chanwoo Choi Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: linux-samsung-...@vger.kernel.org Cc:

[PATCH v2 8/8] PM / devfreq: exynos-bus: Register cooling device

This patch registers the Exynos Bus-Frequency scaling device as a cooling device of thermal management. Signed-off-by: Chanwoo Choi Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: linux-samsung-...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org ---

[PATCH v2 2/8] 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 v2 2/8] 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 v2 1/8] PM / devfreq: Set min/max_freq when adding the devfreq device

Prior to that, the min/max_freq of the devfreq device are always zero before the user changes the min/max_freq through sysfs entries. It might make the confusion for the min/max_freq. This patch initializes the available min/max_freq by using the OPP during adding the devfreq device.

[PATCH v2 1/8] PM / devfreq: Set min/max_freq when adding the devfreq device

Prior to that, the min/max_freq of the devfreq device are always zero before the user changes the min/max_freq through sysfs entries. It might make the confusion for the min/max_freq. This patch initializes the available min/max_freq by using the OPP during adding the devfreq device.

[PATCH v2 4/8] PM / devfreq: Show the all 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 all

[PATCH v2 0/8] PM / devfreq: Use OPP interface to handle the frequency

These patches makes the devfreq to use the OPP interface and clean-up codes. - patch 1~5 are related to the OPP interfaces. - patch 6 removes the unneeded code. - patch 7 clean-up for the governor name. - patch 8 registers the cooling device for exynos-bus. [Detaild Descripion] The commit

[PATCH v2 4/8] PM / devfreq: Show the all 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 all

[PATCH v2 0/8] PM / devfreq: Use OPP interface to handle the frequency

These patches makes the devfreq to use the OPP interface and clean-up codes. - patch 1~5 are related to the OPP interfaces. - patch 6 removes the unneeded code. - patch 7 clean-up for the governor name. - patch 8 registers the cooling device for exynos-bus. [Detaild Descripion] The commit

Re: [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

On 09/20, Al Viro wrote: > On Wed, Sep 20, 2017 at 10:38:31AM -0700, Jaegeuk Kim wrote: > > This patch introduces UMOUNT_WAIT flag for umount(2) which let user wait for > > umount(2) to complete filesystem shutdown. This should fix a kernel panic > > triggered when a living filesystem tries to

Re: [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

On 09/20, Al Viro wrote: > On Wed, Sep 20, 2017 at 10:38:31AM -0700, Jaegeuk Kim wrote: > > This patch introduces UMOUNT_WAIT flag for umount(2) which let user wait for > > umount(2) to complete filesystem shutdown. This should fix a kernel panic > > triggered when a living filesystem tries to

Re: [v2,1/3] can: m_can: Make hclk optional

On 08/24/2017 03:00 AM, Sekhar Nori wrote: > + some OMAP folks and Linux OMAP list > > On Tuesday 25 July 2017 04:21 AM, Franklin Cooper wrote: >> Hclk is the MCAN's interface clock. However, for OMAP based devices such as >> DRA7 SoC family the interface clock is handled by hwmod. Therefore,

Re: [v2,1/3] can: m_can: Make hclk optional

On 08/24/2017 03:00 AM, Sekhar Nori wrote: > + some OMAP folks and Linux OMAP list > > On Tuesday 25 July 2017 04:21 AM, Franklin Cooper wrote: >> Hclk is the MCAN's interface clock. However, for OMAP based devices such as >> DRA7 SoC family the interface clock is handled by hwmod. Therefore,

Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On (09/20/17 22:14), Helge Deller wrote: > On 20.09.2017 18:29, Sergey Senozhatsky wrote: > > This patch set attempts to move ia64/ppc64/parisc64 C function > > pointer ABI details out of printk() to arch code. Function dereference > > code now checks if a pointer belongs to a .opd ELF

Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

On (09/20/17 22:14), Helge Deller wrote: > On 20.09.2017 18:29, Sergey Senozhatsky wrote: > > This patch set attempts to move ia64/ppc64/parisc64 C function > > pointer ABI details out of printk() to arch code. Function dereference > > code now checks if a pointer belongs to a .opd ELF

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

At a high level, does this approach keep an attacker from being able to determine the address of data in the linear map, or does it keep them from being able to *exploit* it? Can you have a ret2dir attack if the attacker doesn't know the address, for instance?

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

At a high level, does this approach keep an attacker from being able to determine the address of data in the linear map, or does it keep them from being able to *exploit* it? Can you have a ret2dir attack if the attacker doesn't know the address, for instance?

Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

On (09/20/17 10:38), Joe Perches wrote: > On Thu, 2017-09-21 at 01:29 +0900, Sergey Senozhatsky wrote: > > We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart > > enough to handle function pointer dereference on platforms where such > > dereference is required. > > > >

Re: [PATCH 2/2] mfd: intel-lpss: switch to suspend_late()/resume_early()

On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: > Ref: https://lkml.org/lkml/2017/9/19/649 > > The intel-lpss hosts the designware i2c controller device, which > needs to be up and running until all its i2c child devices have > suspended (child devices need to be

Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

On (09/20/17 10:38), Joe Perches wrote: > On Thu, 2017-09-21 at 01:29 +0900, Sergey Senozhatsky wrote: > > We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart > > enough to handle function pointer dereference on platforms where such > > dereference is required. > > > >

Re: [PATCH 2/2] mfd: intel-lpss: switch to suspend_late()/resume_early()

On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: > Ref: https://lkml.org/lkml/2017/9/19/649 > > The intel-lpss hosts the designware i2c controller device, which > needs to be up and running until all its i2c child devices have > suspended (child devices need to be accessible over i2c until >

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 09/20/2017 05:09 PM, Tycho Andersen wrote: >> I think the only thing that will really help here is if you batch the >> allocations. For instance, you could make sure that the per-cpu-pageset >> lists always contain either all kernel or all user data. Then remap the >> entire list at once and

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 09/20/2017 05:09 PM, Tycho Andersen wrote: >> I think the only thing that will really help here is if you batch the >> allocations. For instance, you could make sure that the per-cpu-pageset >> lists always contain either all kernel or all user data. Then remap the >> entire list at once and

Re: [PATCH 1/2] i2c: designware: switch to suspend_late/resume_early

On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: > Ref: https://lkml.org/lkml/2017/9/19/649 > > The bus controllers should suspend the bus operations only after > all of the devices on the bus have suspended their device > completely. Since the i2c_client drivers could be

Re: [PATCH 1/2] i2c: designware: switch to suspend_late/resume_early

On Thu, Sep 21, 2017 at 12:31 AM, Rajat Jain wrote: > Ref: https://lkml.org/lkml/2017/9/19/649 > > The bus controllers should suspend the bus operations only after > all of the devices on the bus have suspended their device > completely. Since the i2c_client drivers could be talking to > their

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Sep 20, 2017 at 04:21:15PM -0700, Dave Hansen wrote: > On 09/20/2017 03:34 PM, Tycho Andersen wrote: > >> I really have to wonder whether there are better ret2dir defenses than > >> this. The allocator just seems like the *wrong* place to be doing this > >> because it's such a hot path. >

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, Sep 20, 2017 at 04:21:15PM -0700, Dave Hansen wrote: > On 09/20/2017 03:34 PM, Tycho Andersen wrote: > >> I really have to wonder whether there are better ret2dir defenses than > >> this. The allocator just seems like the *wrong* place to be doing this > >> because it's such a hot path. >

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 09/20/2017 05:02 PM, Tycho Andersen wrote: > ...and makes it easier to pair tlb flushes with changing the > protections. I guess we still need the for loop, because we need to > set/unset the xpfo bits as necessary, but I'll switch it to a single > set_kpte(). This also implies that the xpfo

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 09/20/2017 05:02 PM, Tycho Andersen wrote: > ...and makes it easier to pair tlb flushes with changing the > protections. I guess we still need the for loop, because we need to > set/unset the xpfo bits as necessary, but I'll switch it to a single > set_kpte(). This also implies that the xpfo

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 09/07/2017 10:36 AM, Tycho Andersen wrote: > + /* > + * Map the page back into the kernel if it was previously > + * allocated to user space. > + */ > + if (test_and_clear_bit(XPFO_PAGE_USER, >flags)) { > +

Re: [PATCH v6 03/11] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

On 09/07/2017 10:36 AM, Tycho Andersen wrote: > + /* > + * Map the page back into the kernel if it was previously > + * allocated to user space. > + */ > + if (test_and_clear_bit(XPFO_PAGE_USER, >flags)) { > +

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