[GIT PULL] dma mapping fix for 4.17

The following changes since commit b284d4d5a6785f8cd07eda2646a95782373cd01e: Merge tag 'ceph-for-4.17-rc1' of git://github.com/ceph/ceph-client (2018-04-10 12:25:30 -0700) are available in the Git repository at: git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.17-2 for

[GIT PULL] dma mapping fix for 4.17

The following changes since commit b284d4d5a6785f8cd07eda2646a95782373cd01e: Merge tag 'ceph-for-4.17-rc1' of git://github.com/ceph/ceph-client (2018-04-10 12:25:30 -0700) are available in the Git repository at: git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.17-2 for

[PATCH] drm: fix drm-get-put.cocci warnings

From: Fengguang Wu Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and drm_*_unreference() helpers. Generated by: scripts/coccinelle/api/drm-get-put.cocci Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver") Signed-off-by: Fengguang Wu

[PATCH] drm: fix drm-get-put.cocci warnings

From: Fengguang Wu Use drm_*_get() and drm_*_put() helpers instead of drm_*_reference() and drm_*_unreference() helpers. Generated by: scripts/coccinelle/api/drm-get-put.cocci Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver") Signed-off-by: Fengguang Wu Signed-off-by: Julia Lawall ---

[PATCH] drm: fix semicolon.cocci warnings

From: Fengguang Wu Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver") Signed-off-by: Fengguang Wu Signed-off-by: Julia Lawall ---

[PATCH] drm: fix semicolon.cocci warnings

From: Fengguang Wu Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: 6784ac15bc68 ("drm: Add ASPEED GFX driver") Signed-off-by: Fengguang Wu Signed-off-by: Julia Lawall --- aspeed_gfx_drv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ---

Re: [PATCH v1] scsi: ufs: add 2 lane support

On 2018-04-02 18:00, Vivek Gautam wrote: Hi Can, On 3/2/2018 1:48 PM, Can Guo wrote: From: Venkat Gopalakrishnan Qcom ufs controller v3.1.0 supports 2 lanes, add support to configure 2 lanes during phy initialization. Signed-off-by: Venkat Gopalakrishnan

Re: [PATCH v1] scsi: ufs: add 2 lane support

On 2018-04-02 18:00, Vivek Gautam wrote: Hi Can, On 3/2/2018 1:48 PM, Can Guo wrote: From: Venkat Gopalakrishnan Qcom ufs controller v3.1.0 supports 2 lanes, add support to configure 2 lanes during phy initialization. Signed-off-by: Venkat Gopalakrishnan Signed-off-by: Subhash Jadavani

Re: [PATCH 02/20] afs: Fix checker warnings

On Thu, Apr 05, 2018 at 09:29:42PM +0100, David Howells wrote: > Fix warnings raised by checker, including: > > (*) Warnings raised by unequal comparison for the purposes of sorting, > where the endianness doesn't matter: > > fs/afs/addr_list.c:246:21: warning: restricted __be16 degrades

Re: [PATCH 02/20] afs: Fix checker warnings

On Thu, Apr 05, 2018 at 09:29:42PM +0100, David Howells wrote: > Fix warnings raised by checker, including: > > (*) Warnings raised by unequal comparison for the purposes of sorting, > where the endianness doesn't matter: > > fs/afs/addr_list.c:246:21: warning: restricted __be16 degrades

Re: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi, Peng! On 04/12/2018 05:21 AM, Peng Fan wrote: Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? They are orthogonal Thanks, Peng.

Re: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi, Peng! On 04/12/2018 05:21 AM, Peng Fan wrote: Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? They are orthogonal Thanks, Peng.

Re: [PATCH v3 1/2] phy: Add QMP phy based UFS phy support for sdm845

On 4/12/2018 6:27 AM, c...@codeaurora.org wrote: On 2018-04-09 19:28, Vivek Gautam wrote: Hi Can, On 3/27/2018 12:48 PM, Can Guo wrote: Add UFS PHY support to make SDM845 UFS work with common PHY framework. Signed-off-by: Can Guo ---  

Re: [PATCH v3 1/2] phy: Add QMP phy based UFS phy support for sdm845

On 4/12/2018 6:27 AM, c...@codeaurora.org wrote: On 2018-04-09 19:28, Vivek Gautam wrote: Hi Can, On 3/27/2018 12:48 PM, Can Guo wrote: Add UFS PHY support to make SDM845 UFS work with common PHY framework. Signed-off-by: Can Guo ---   drivers/phy/qualcomm/phy-qcom-qmp.c | 130

Re: [PATCH 3.18 000/121] 3.18.105-stable review

On 12 April 2018 12:05:03 AM IST, Greg Kroah-Hartman wrote: >This is the start of the stable review cycle for the 3.18.105 release. >There are 121 patches in this series, all will be posted as a response >to this one. If anyone has any issues with these being

Re: [PATCH 3.18 000/121] 3.18.105-stable review

On 12 April 2018 12:05:03 AM IST, Greg Kroah-Hartman wrote: >This is the start of the stable review cycle for the 3.18.105 release. >There are 121 patches in this series, all will be posted as a response >to this one. If anyone has any issues with these being applied, please >let me know. >

Re: [GIT PULL] Thermal management updates for v4.17-rc1

Hi, Linus, On 三, 2018-04-11 at 17:01 -0700, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 1:41 AM, Zhang Rui > wrote: > > > > > > Please pull from > >   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git > > next > Pulled, and then immediately unpulled again.

Re: [GIT PULL] Thermal management updates for v4.17-rc1

Hi, Linus, On 三, 2018-04-11 at 17:01 -0700, Linus Torvalds wrote: > On Wed, Apr 11, 2018 at 1:41 AM, Zhang Rui > wrote: > > > > > > Please pull from > >   git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git > > next > Pulled, and then immediately unpulled again. > > The code causes

Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

Dear James, Thanks for this mail and sorry for my late response. 2018-02-16 1:55 GMT+08:00 James Morse : > Hi gengdongjiu, liu jun > > On 05/02/18 11:24, gengdongjiu wrote: [] >> >>> Is the emulated SError routed following the routing rules for HCR_EL2.{AMO, >>>

Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

Dear James, Thanks for this mail and sorry for my late response. 2018-02-16 1:55 GMT+08:00 James Morse : > Hi gengdongjiu, liu jun > > On 05/02/18 11:24, gengdongjiu wrote: [] >> >>> Is the emulated SError routed following the routing rules for HCR_EL2.{AMO, >>> TGE}? >> >> Yes, it

Re: [PATCH] arm64: dts: uniphier: fix input delay value for legacy mode of eMMC

2018-04-12 11:31 GMT+09:00 Masahiro Yamada : > The property of the legacy mode for the eMMC PHY turned out to > be worng. Some eMMC devices are unstable due to the set-up/hold > timing violation. Correct the delay value. Reminder for myself: Fix a type worng ->

Re: [PATCH] arm64: dts: uniphier: fix input delay value for legacy mode of eMMC

2018-04-12 11:31 GMT+09:00 Masahiro Yamada : > The property of the legacy mode for the eMMC PHY turned out to > be worng. Some eMMC devices are unstable due to the set-up/hold > timing violation. Correct the delay value. Reminder for myself: Fix a type worng -> wrong -- Best Regards

Re: [PATCH 1/2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock

Hi Jia-Ju, Thank you for the patch! Yet something to improve: [auto build test ERROR on ide/master] [also build test ERROR on v4.16 next-20180411] [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

Re: [PATCH 1/2] ide: pdc202xx_new: Replace mdelay with usleep_range in detect_pll_input_clock

Hi Jia-Ju, Thank you for the patch! Yet something to improve: [auto build test ERROR on ide/master] [also build test ERROR on v4.16 next-20180411] [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

[PATCH 03/14] ARM: OMAP2+: omap_hwmod: Introduce HWMOD_NEEDS_REIDLE

From: Dave Gerlach Some hwmods will not properly assert signals to the PRCM after a context loss if no driver is present which leads to issues with suspend. This can be caused by the SYSCONFIG register not being programmed correctly by default or a softreset being needed before

[PATCH 01/14] memory: ti-emif-sram: Add resume function to recopy sram code

From: Dave Gerlach After an RTC+DDR cycle we lose sram context so emif pm functions present in sram are lost. We can check if the first byte of the original code in DDR contains the same first byte as the code in sram, and if they do not match we know we have lost context and

[PATCH 03/14] ARM: OMAP2+: omap_hwmod: Introduce HWMOD_NEEDS_REIDLE

From: Dave Gerlach Some hwmods will not properly assert signals to the PRCM after a context loss if no driver is present which leads to issues with suspend. This can be caused by the SYSCONFIG register not being programmed correctly by default or a softreset being needed before the module will

[PATCH 01/14] memory: ti-emif-sram: Add resume function to recopy sram code

From: Dave Gerlach After an RTC+DDR cycle we lose sram context so emif pm functions present in sram are lost. We can check if the first byte of the original code in DDR contains the same first byte as the code in sram, and if they do not match we know we have lost context and must recopy the

[PATCH 05/14] ARM: OMAP2: Add functions to save and restore powerdomain context

From: Russ Dill The powerdomain control registers are stored in the WKUP powerdomain on AM33XX/AM43XX, which is lost on RTC-only suspend and also hibernate. This adds context save and restore functions for those registers. Sometimes the powerdomain state does not need to

[PATCH 05/14] ARM: OMAP2: Add functions to save and restore powerdomain context

From: Russ Dill The powerdomain control registers are stored in the WKUP powerdomain on AM33XX/AM43XX, which is lost on RTC-only suspend and also hibernate. This adds context save and restore functions for those registers. Sometimes the powerdomain state does not need to change, perhaps we only

[PATCH 08/14] ARM: OMAP2: Add functions to save and restore pinctrl context.

From: Russ Dill This adds a pair of context save/restore functions to save/restore the state of a set of pinctrl registers. This simplifies some of the AM33XX PM code as some of the pinctrl registers are lost when the per power domain loses power. The pincrtl code can

[PATCH 08/14] ARM: OMAP2: Add functions to save and restore pinctrl context.

From: Russ Dill This adds a pair of context save/restore functions to save/restore the state of a set of pinctrl registers. This simplifies some of the AM33XX PM code as some of the pinctrl registers are lost when the per power domain loses power. The pincrtl code can perform the necessary

[PATCH 09/14] ARM: OMAP2: Drop the concept of certain power domains not being able to lose context.

From: Russ Dill It isn't much of a win, and with hibernation, everything loses context. So Drop the concept of certain power domains not being able to lose context. Signed-off-by: Russ Dill Signed-off-by: Keerthy ---

[PATCH 06/14] ARM: AM33XX: Add functions to save/restore am33xx control registers.

From: Russ Dill These registers are part of the wkup domain and are lost during RTC only suspend and also hibernation, so storing/restoring their state is necessary. Signed-off-by: Russ Dill Signed-off-by: Keerthy ---

[PATCH 09/14] ARM: OMAP2: Drop the concept of certain power domains not being able to lose context.

From: Russ Dill It isn't much of a win, and with hibernation, everything loses context. So Drop the concept of certain power domains not being able to lose context. Signed-off-by: Russ Dill Signed-off-by: Keerthy --- arch/arm/mach-omap2/powerdomain.c | 41

[PATCH 06/14] ARM: AM33XX: Add functions to save/restore am33xx control registers.

From: Russ Dill These registers are part of the wkup domain and are lost during RTC only suspend and also hibernation, so storing/restoring their state is necessary. Signed-off-by: Russ Dill Signed-off-by: Keerthy --- arch/arm/mach-omap2/control.c | 84

[PATCH 12/14] OMAP: CLK: CLKSRC: Add suspend resume hooks

Add the save and restore for clksrc as part of suspend and resume so that it saves the counter value and restores. This is needed in modes like rtc+ddr in self-refresh not doing this stalls the time. Signed-off-by: Keerthy --- arch/arm/mach-omap2/timer.c | 37

[PATCH 12/14] OMAP: CLK: CLKSRC: Add suspend resume hooks

Add the save and restore for clksrc as part of suspend and resume so that it saves the counter value and restores. This is needed in modes like rtc+ddr in self-refresh not doing this stalls the time. Signed-off-by: Keerthy --- arch/arm/mach-omap2/timer.c | 37

[PATCH 13/14] ARM: hwmod: RTC: Don't assume lock/unlock will be called with irq enabled

From: Dave Gerlach When the RTC lock and unlock functions were introduced it was likely assumed that they would always be called from irq enabled context, hence the use of local_irq_disable/enable. This is no longer true as the RTC+DDR path makes a late call during the suspend

[PATCH 11/14] gpio: omap: Restore power_mode configuration at resume time

From: Dave Gerlach Commit 2dc983c565e0 ("gpio/omap: cleanup prepare_for_idle and resume_after_idle") introduces omap2_gpio_prepare_for_idle and omap2_gpio_resume_after_idle to properly configure gpios that are used as wake sources. When entering off mode,

[PATCH 11/14] gpio: omap: Restore power_mode configuration at resume time

From: Dave Gerlach Commit 2dc983c565e0 ("gpio/omap: cleanup prepare_for_idle and resume_after_idle") introduces omap2_gpio_prepare_for_idle and omap2_gpio_resume_after_idle to properly configure gpios that are used as wake sources. When entering off mode, omap2_gpio_prepare_for_idle can set a

[PATCH 13/14] ARM: hwmod: RTC: Don't assume lock/unlock will be called with irq enabled

From: Dave Gerlach When the RTC lock and unlock functions were introduced it was likely assumed that they would always be called from irq enabled context, hence the use of local_irq_disable/enable. This is no longer true as the RTC+DDR path makes a late call during the suspend path after irqs

[PATCH 14/14] ARM: OMAP2+: prm44xx: Introduce context save/restore for am43 PRCM IO

From: Dave Gerlach There are two registers on am43x needed for IO daisy chain wake to work properly, however currently after an RTC+DDR cycle they are lost. We must take care to save and restore these before and after entering RTC mode otherwise IO daisy chain wake will stop

[PATCH 10/14] gpio: omap: Drop the concept of gpio banks not being able to lose context.

From: Russ Dill It isn't much of a win, and with hibernation, everything loses context. Signed-off-by: Russ Dill Signed-off-by: Keerthy --- drivers/gpio/gpio-omap.c| 38 -

[PATCH 10/14] gpio: omap: Drop the concept of gpio banks not being able to lose context.

From: Russ Dill It isn't much of a win, and with hibernation, everything loses context. Signed-off-by: Russ Dill Signed-off-by: Keerthy --- drivers/gpio/gpio-omap.c| 38 - include/linux/platform_data/gpio-omap.h | 1 - 2 files changed, 14

[PATCH 14/14] ARM: OMAP2+: prm44xx: Introduce context save/restore for am43 PRCM IO

From: Dave Gerlach There are two registers on am43x needed for IO daisy chain wake to work properly, however currently after an RTC+DDR cycle they are lost. We must take care to save and restore these before and after entering RTC mode otherwise IO daisy chain wake will stop working from

[PATCH 02/14] ARM: OMAP2: Add functions to save and restore clockdomain context en-masse.

From: Russ Dill This is used to support suspend modes like RTC-only and hibernate where the state of the registers controlling clockdomains is lost. Signed-off-by: Russ Dill Signed-off-by: Dave Gerlach Signed-off-by: Keerthy

[PATCH 07/14] ARM: AM43XX: Add functions to save/restore am43xx control registers

From: Tero Kristo These registers are part of the wkup domain and are lost during RTC only suspend and also hibernation, so storing/restoring their state is necessary. Signed-off-by: Tero Kristo Signed-off-by: Keerthy ---

[PATCH 02/14] ARM: OMAP2: Add functions to save and restore clockdomain context en-masse.

From: Russ Dill This is used to support suspend modes like RTC-only and hibernate where the state of the registers controlling clockdomains is lost. Signed-off-by: Russ Dill Signed-off-by: Dave Gerlach Signed-off-by: Keerthy --- arch/arm/mach-omap2/clockdomain.c | 46

[PATCH 07/14] ARM: AM43XX: Add functions to save/restore am43xx control registers

From: Tero Kristo These registers are part of the wkup domain and are lost during RTC only suspend and also hibernation, so storing/restoring their state is necessary. Signed-off-by: Tero Kristo Signed-off-by: Keerthy --- arch/arm/mach-omap2/control.c | 94

[PATCH 00/14] arm: OMAP: AM437X: Save restores patches for rtc mode with DDR In self-refresh

RTC plus DDR in self-refresh is power a saving mode where in the entire system including the different voltage rails from PMIC are shutdown except the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the contents are preserved. RTC ALARM2 is connected to PMIC_EN line once we the

[PATCH 04/14] ARM: OMAP2: Add functions to save and restore omap hwmod context en-masse.

From: Russ Dill This is used to support suspend modes like RTC-only and hibernate where the state of these registers is lost. After the PRCM loses context in the case of an RTC+DDR cycle omap_hwmod attempts to return all hwmods to their previous state, however certain hwmods

[PATCH 00/14] arm: OMAP: AM437X: Save restores patches for rtc mode with DDR In self-refresh

RTC plus DDR in self-refresh is power a saving mode where in the entire system including the different voltage rails from PMIC are shutdown except the ones feeding on to RTC and DDR. DDR is kept in self-refresh hence the contents are preserved. RTC ALARM2 is connected to PMIC_EN line once we the

[PATCH 04/14] ARM: OMAP2: Add functions to save and restore omap hwmod context en-masse.

From: Russ Dill This is used to support suspend modes like RTC-only and hibernate where the state of these registers is lost. After the PRCM loses context in the case of an RTC+DDR cycle omap_hwmod attempts to return all hwmods to their previous state, however certain hwmods cannot just be

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On 04/11/2018 07:51 PM, Jae Hyun Yoo wrote: On 4/11/2018 5:34 PM, Guenter Roeck wrote: On 04/11/2018 02:59 PM, Jae Hyun Yoo wrote: Hi Guenter, Thanks a lot for sharing your time. Please see my inline answers. On 4/10/2018 3:28 PM, Guenter Roeck wrote: On Tue, Apr 10, 2018 at 11:32:11AM

[git pull] afs series

AFS series posted by dhowells depended upon lookup_one_len() rework; now that prereq is in the mainline, that series had been rebased on top of it and got some exposure and testing... The following changes since commit fd3b36d275660c905da9900b078eea341847d5e4: Merge branch 'work.namei'

[git pull] afs series

AFS series posted by dhowells depended upon lookup_one_len() rework; now that prereq is in the mainline, that series had been rebased on top of it and got some exposure and testing... The following changes since commit fd3b36d275660c905da9900b078eea341847d5e4: Merge branch 'work.namei'

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On 04/11/2018 07:51 PM, Jae Hyun Yoo wrote: On 4/11/2018 5:34 PM, Guenter Roeck wrote: On 04/11/2018 02:59 PM, Jae Hyun Yoo wrote: Hi Guenter, Thanks a lot for sharing your time. Please see my inline answers. On 4/10/2018 3:28 PM, Guenter Roeck wrote: On Tue, Apr 10, 2018 at 11:32:11AM

linux-next: Tree for Apr 12

Hi all, Please do not add any v4.18 destined stuff to your linux-next included trees until after v4.17-rc1 has been released. Changes since 20180411: The parisc-hd tree lost its build failure. Non-merge commits (relative to Linus' tree): 1143 1201 files changed, 42273 insertions(+), 23285

linux-next: Tree for Apr 12

Hi all, Please do not add any v4.18 destined stuff to your linux-next included trees until after v4.17-rc1 has been released. Changes since 20180411: The parisc-hd tree lost its build failure. Non-merge commits (relative to Linus' tree): 1143 1201 files changed, 42273 insertions(+), 23285

Re: [PATCH 2/5] pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver

Hi Amelie, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.16] [cannot apply to next-20180411] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH 2/5] pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver

Hi Amelie, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on robh/for-next] [also build test WARNING on v4.16] [cannot apply to next-20180411] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image

On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote: > > (*) CONFIG_LOCK_DOWN_KERNEL > > This makes lockdown available and applies it to all the points that > need to be locked down if the mode is set. Lockdown mode can be > enabled by providing: > >

Re: [PATCH 01/24] Add the ability to lock down access to the running kernel image

On Wed, Apr 11, 2018 at 9:24 AM, David Howells wrote: > > (*) CONFIG_LOCK_DOWN_KERNEL > > This makes lockdown available and applies it to all the points that > need to be locked down if the mode is set. Lockdown mode can be > enabled by providing: > > lockdown=1 By doing

Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down

On Wed, Apr 11, 2018 at 1:33 PM, Greg KH wrote: > On Wed, Apr 11, 2018 at 09:09:16PM +0100, David Howells wrote: >> Greg KH wrote: >> >> > Why not just disable debugfs entirely? This half-hearted way to sorta >> > lock it down is odd, it is meant to not be there

Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down

On Wed, Apr 11, 2018 at 1:33 PM, Greg KH wrote: > On Wed, Apr 11, 2018 at 09:09:16PM +0100, David Howells wrote: >> Greg KH wrote: >> >> > Why not just disable debugfs entirely? This half-hearted way to sorta >> > lock it down is odd, it is meant to not be there at all, nothing in your >> >

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On 4/11/2018 5:34 PM, Guenter Roeck wrote: On 04/11/2018 02:59 PM, Jae Hyun Yoo wrote: Hi Guenter, Thanks a lot for sharing your time. Please see my inline answers. On 4/10/2018 3:28 PM, Guenter Roeck wrote: On Tue, Apr 10, 2018 at 11:32:11AM -0700, Jae Hyun Yoo wrote: This commit adds PECI

Re: [PATCH v3 09/10] drivers/hwmon: Add PECI hwmon client drivers

On 4/11/2018 5:34 PM, Guenter Roeck wrote: On 04/11/2018 02:59 PM, Jae Hyun Yoo wrote: Hi Guenter, Thanks a lot for sharing your time. Please see my inline answers. On 4/10/2018 3:28 PM, Guenter Roeck wrote: On Tue, Apr 10, 2018 at 11:32:11AM -0700, Jae Hyun Yoo wrote: This commit adds PECI

[PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI bus to the guest, Hyper-V always provides unique PCI domain. commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") overrode unique domain with the serial number of the first device added to the virtual PCI

[PATCH v7] Revert "PCI: hv: Use device serial number as PCI domain"

When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI bus to the guest, Hyper-V always provides unique PCI domain. commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") overrode unique domain with the serial number of the first device added to the virtual PCI

[PATCH] arm64: dts: uniphier: fix input delay value for legacy mode of eMMC

The property of the legacy mode for the eMMC PHY turned out to be worng. Some eMMC devices are unstable due to the set-up/hold timing violation. Correct the delay value. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 +-

[PATCH] arm64: dts: uniphier: fix input delay value for legacy mode of eMMC

The property of the legacy mode for the eMMC PHY turned out to be worng. Some eMMC devices are unstable due to the set-up/hold timing violation. Correct the delay value. Signed-off-by: Masahiro Yamada --- arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 +-

Re: [PATCH v2] net: dsa: b53: Using sleep-able operations in b53_switch_reset_gpio

On 12/04/2018 09:48, Jia-Ju Bai wrote: b53_switch_reset_gpio() is never called in atomic context. The call chain ending up at b53_switch_reset_gpio() is: [1] b53_switch_reset_gpio() <- b53_switch_reset() <- b53_reset_switch() <- b53_setup() b53_switch_reset_gpio() is set as ".setup" in

Re: [PATCH v2] net: dsa: b53: Using sleep-able operations in b53_switch_reset_gpio

On 12/04/2018 09:48, Jia-Ju Bai wrote: b53_switch_reset_gpio() is never called in atomic context. The call chain ending up at b53_switch_reset_gpio() is: [1] b53_switch_reset_gpio() <- b53_switch_reset() <- b53_reset_switch() <- b53_setup() b53_switch_reset_gpio() is set as ".setup" in

Re: [PATCH v2] dec: tulip: de4x5: Replace mdelay with usleep_range in de4x5_hw_init

On 2018/4/12 10:21, arvindY wrote: On Thursday 12 April 2018 07:00 AM, Jia-Ju Bai wrote: On 2018/4/12 0:16, James Bottomley wrote: On Wed, 2018-04-11 at 23:39 +0800, Jia-Ju Bai wrote: de4x5_hw_init() is never called in atomic context. de4x5_hw_init() is only called by

Re: [PATCH v2] dec: tulip: de4x5: Replace mdelay with usleep_range in de4x5_hw_init

On 2018/4/12 10:21, arvindY wrote: On Thursday 12 April 2018 07:00 AM, Jia-Ju Bai wrote: On 2018/4/12 0:16, James Bottomley wrote: On Wed, 2018-04-11 at 23:39 +0800, Jia-Ju Bai wrote: de4x5_hw_init() is never called in atomic context. de4x5_hw_init() is only called by

Re: [PATCHv2] dmaengine: dmatest: Remove use of VLAs

On 4/10/2018 9:02 PM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs from the kernel > (https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. > The test already pre-allocates some buffers with kmalloc so turn > the two VLAs in to pre-allocated kmalloc buffers. > >

Re: [PATCHv2] dmaengine: dmatest: Remove use of VLAs

On 4/10/2018 9:02 PM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs from the kernel > (https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. > The test already pre-allocates some buffers with kmalloc so turn > the two VLAs in to pre-allocated kmalloc buffers. > >

Re: [PATCH v2] dec: tulip: de4x5: Replace mdelay with usleep_range in de4x5_hw_init

On Thursday 12 April 2018 07:00 AM, Jia-Ju Bai wrote: On 2018/4/12 0:16, James Bottomley wrote: On Wed, 2018-04-11 at 23:39 +0800, Jia-Ju Bai wrote: de4x5_hw_init() is never called in atomic context. de4x5_hw_init() is only called by de4x5_pci_probe(), which is only set as ".probe" in

RE: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? Thanks, Peng. > Subject: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV > display frontend > > From: Oleksandr Andrushchenko

Re: [PATCH v2] dec: tulip: de4x5: Replace mdelay with usleep_range in de4x5_hw_init

On Thursday 12 April 2018 07:00 AM, Jia-Ju Bai wrote: On 2018/4/12 0:16, James Bottomley wrote: On Wed, 2018-04-11 at 23:39 +0800, Jia-Ju Bai wrote: de4x5_hw_init() is never called in atomic context. de4x5_hw_init() is only called by de4x5_pci_probe(), which is only set as ".probe" in

RE: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

Hi Oleksandr, Just have a question, is this drm/xen-front stuff orthogonal to xen shared coprocessor framework for gpu, or are they exclusive? Thanks, Peng. > Subject: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV > display frontend > > From: Oleksandr Andrushchenko > >

Re: [PATCH v3 05/10] ARM: dts: aspeed: peci: Add PECI node

On 4/11/2018 4:52 AM, Joel Stanley wrote: On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds PECI bus/adapter node of AST24xx/AST25xx into aspeed-g4 and aspeed-g5. The patches to the device trees get merged by the ASPEED maintainer (me). Once you

Re: [PATCH v3 05/10] ARM: dts: aspeed: peci: Add PECI node

On 4/11/2018 4:52 AM, Joel Stanley wrote: On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds PECI bus/adapter node of AST24xx/AST25xx into aspeed-g4 and aspeed-g5. The patches to the device trees get merged by the ASPEED maintainer (me). Once you have the bindings reviewed you

[PATCH] reset: uniphier: fix USB clock line for LD20

For LD20, the bit 5 of the offset 0x200c turned out to be a USB3 reset. The hardware document says it is the GIO reset despite LD20 has no GIO bus, confusingly. Also, fix confusing comments for PXs3. Signed-off-by: Masahiro Yamada ---

[PATCH] reset: uniphier: fix USB clock line for LD20

For LD20, the bit 5 of the offset 0x200c turned out to be a USB3 reset. The hardware document says it is the GIO reset despite LD20 has no GIO bus, confusingly. Also, fix confusing comments for PXs3. Signed-off-by: Masahiro Yamada --- drivers/reset/reset-uniphier.c | 6 +++--- 1 file

Re: [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: pcistub_probe() is never called in atomic context. This function is only set as ".probe" in struct pci_driver. Despite never getting called from atomic context, pcistub_probe() calls kmalloc() with GFP_ATOMIC, which does not sleep for allocation.

Re: [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: pcistub_probe() is never called in atomic context. This function is only set as ".probe" in struct pci_driver. Despite never getting called from atomic context, pcistub_probe() calls kmalloc() with GFP_ATOMIC, which does not sleep for allocation.

Re: [PATCH v3 04/10] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

Hi Joel, On 4/11/2018 4:52 AM, Joel Stanley wrote: On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds a dt-bindings document of PECI adapter driver for Aspeed We try to capitalise ASPEED. Got it. Will capitalize all Aspeed words. AST24xx/25xx

Re: [PATCH v3 04/10] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

Hi Joel, On 4/11/2018 4:52 AM, Joel Stanley wrote: On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds a dt-bindings document of PECI adapter driver for Aspeed We try to capitalise ASPEED. Got it. Will capitalize all Aspeed words. AST24xx/25xx SoCs. ---

Re: [RFC tip/locking/lockdep v6 19/20] rcu: Equip sleepable RCU with lockdep dependency graph checks

On Wed, Apr 11, 2018 at 11:57:30AM -0700, Paul E. McKenney wrote: > On Wed, Apr 11, 2018 at 09:56:44PM +0800, Boqun Feng wrote: > > Although all flavors of RCU are annotated correctly with lockdep > > annotations as recursive read locks, the 'check' parameter for their > > calls to lock_acquire()

Re: [RFC tip/locking/lockdep v6 19/20] rcu: Equip sleepable RCU with lockdep dependency graph checks

On Wed, Apr 11, 2018 at 11:57:30AM -0700, Paul E. McKenney wrote: > On Wed, Apr 11, 2018 at 09:56:44PM +0800, Boqun Feng wrote: > > Although all flavors of RCU are annotated correctly with lockdep > > annotations as recursive read locks, the 'check' parameter for their > > calls to lock_acquire()

Re: [PATCH v3 01/10] Documentations: dt-bindings: Add documents of generic PECI bus, adapter and client drivers

Hi Joel, On 4/11/2018 4:52 AM, Joel Stanley wrote: Hi Jae, On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds documents of generic PECI bus, adapter and client drivers. Signed-off-by: Jae Hyun Yoo Reviewed-by: Haiyue

Re: [PATCH v3 01/10] Documentations: dt-bindings: Add documents of generic PECI bus, adapter and client drivers

Hi Joel, On 4/11/2018 4:52 AM, Joel Stanley wrote: Hi Jae, On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds documents of generic PECI bus, adapter and client drivers. Signed-off-by: Jae Hyun Yoo Reviewed-by: Haiyue Wang Reviewed-by: James Feist Reviewed-by: Vernon Mauery

Re: [PATCH v3 06/10] drivers/peci: Add a PECI adapter driver for Aspeed AST24xx/AST25xx

Hello Joel, Thanks for sharing your time. Please see my answers inline. On 4/11/2018 4:51 AM, Joel Stanley wrote: Hello Jae, On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds PECI adapter driver implementation for Aspeed AST24xx/AST25xx. The

Re: [PATCH v3 06/10] drivers/peci: Add a PECI adapter driver for Aspeed AST24xx/AST25xx

Hello Joel, Thanks for sharing your time. Please see my answers inline. On 4/11/2018 4:51 AM, Joel Stanley wrote: Hello Jae, On 11 April 2018 at 04:02, Jae Hyun Yoo wrote: This commit adds PECI adapter driver implementation for Aspeed AST24xx/AST25xx. The driver is looking good! It looks

Re: [PATCH] Revert "perf machine: Fix paranoid check in machine__set_kernel_mmap()"

On Wed, Apr 11, 2018 at 07:29:40PM -0500, Kim Phillips wrote: > On Thu, 12 Apr 2018 08:31:09 +0900 > Namhyung Kim wrote: > > > Hello, > > Hi, > > > On Wed, Apr 11, 2018 at 06:07:52PM -0500, Kim Phillips wrote: > > > --- > > > It's not clear to me what the specific intent

Re: [PATCH] Revert "perf machine: Fix paranoid check in machine__set_kernel_mmap()"

On Wed, Apr 11, 2018 at 07:29:40PM -0500, Kim Phillips wrote: > On Thu, 12 Apr 2018 08:31:09 +0900 > Namhyung Kim wrote: > > > Hello, > > Hi, > > > On Wed, Apr 11, 2018 at 06:07:52PM -0500, Kim Phillips wrote: > > > --- > > > It's not clear to me what the specific intent of the original commit

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Vivek, On 2018/4/11 13:15, Vivek Gautam wrote: > Hi Yisheng, > > > On 4/11/2018 6:52 AM, Yisheng Xie wrote: >> Hi Tomasz, >> >> On 2018/4/10 21:14, Tomasz Figa wrote: >>> Hi Yisheng, >>> >>> Sorry, I think we missed your question here. >>> >>> On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Vivek, On 2018/4/11 13:15, Vivek Gautam wrote: > Hi Yisheng, > > > On 4/11/2018 6:52 AM, Yisheng Xie wrote: >> Hi Tomasz, >> >> On 2018/4/10 21:14, Tomasz Figa wrote: >>> Hi Yisheng, >>> >>> Sorry, I think we missed your question here. >>> >>> On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie

  1   2   3   4   5   6   7   8   9   10   >