Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On Tue, May 30, 2017 at 05:16:56PM +0300, Andrey Ryabinin wrote: > On 05/29/2017 06:29 PM, Dmitry Vyukov wrote: > > Joonsoo, > > > > I guess mine (and Andrey's) main concern is the amount of additional > > complexity (I am still struggling to understand how it all works) and > > more

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

On Tue, May 30, 2017 at 05:16:56PM +0300, Andrey Ryabinin wrote: > On 05/29/2017 06:29 PM, Dmitry Vyukov wrote: > > Joonsoo, > > > > I guess mine (and Andrey's) main concern is the amount of additional > > complexity (I am still struggling to understand how it all works) and > > more

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

tch removes member client from struct ds1307. Rgds, Heiner > > Caused by commit > > 345b89453dda ("rtc: rtc-ds1307: enable support for mcp794xx as a wakeup > source without IRQ") > > interacting with commit > > 11e5890b5342 ("rtc: ds1307: convert driver to regmap") > > I have used the rtc tree from next-20170530 for today. >

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

tch removes member client from struct ds1307. Rgds, Heiner > > Caused by commit > > 345b89453dda ("rtc: rtc-ds1307: enable support for mcp794xx as a wakeup > source without IRQ") > > interacting with commit > > 11e5890b5342 ("rtc: ds1307: convert driver to regmap") > > I have used the rtc tree from next-20170530 for today. >

[PATCH] PCI: qcom: ix spelling mistake: "asser" -> "assert"

From: Colin Ian King Trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King --- drivers/pci/dwc/pcie-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/dwc/pcie-qcom.c

[PATCH] PCI: qcom: ix spelling mistake: "asser" -> "assert"

From: Colin Ian King Trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King --- drivers/pci/dwc/pcie-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c index 289cda1b4897..fbc79a5274c6

[PATCH][V2] PCI: qcom: fix spelling mistake: "asser" -> "assert"

From: Colin Ian King Trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King --- drivers/pci/dwc/pcie-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/dwc/pcie-qcom.c

[PATCH][V2] PCI: qcom: fix spelling mistake: "asser" -> "assert"

From: Colin Ian King Trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King --- drivers/pci/dwc/pcie-qcom.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c index 289cda1b4897..fbc79a5274c6

linux-next: Tree for May 31

Hi all, Changes since 20170530: The mfd tree gained a build failure so I used the version from next-20170530. The drivers-x86 tree gained the same build failure as the mfd tree so I used the version from next-20170530. The rtc tree gained a build failure so I used the version from next

linux-next: Tree for May 31

Hi all, Changes since 20170530: The mfd tree gained a build failure so I used the version from next-20170530. The drivers-x86 tree gained the same build failure as the mfd tree so I used the version from next-20170530. The rtc tree gained a build failure so I used the version from next

[PATCH v4 1/9] mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index

From: Kuppuswamy Sathyanarayanan TMU interrupts are registered as a separate interrupt chip, and hence it should start its interrupt index(BXTWC_TMU_IRQ) number from 0. But currently, BXTWC_TMU_IRQ is defined as part of enum bxtwc_irqs_level2 and its

[PATCH v4 1/9] mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index

From: Kuppuswamy Sathyanarayanan TMU interrupts are registered as a separate interrupt chip, and hence it should start its interrupt index(BXTWC_TMU_IRQ) number from 0. But currently, BXTWC_TMU_IRQ is defined as part of enum bxtwc_irqs_level2 and its index value is 11. Since this index value is

[PATCH v4 6/9] mfd: intel_soc_pmic_bxtwc: utilize devm_* functions in driver probe

From: Kuppuswamy Sathyanarayanan Cleanup the resource allocation/free code in probe function by using devm_* calls. Signed-off-by: Kuppuswamy Sathyanarayanan Acked-for-MFD-by: Lee Jones

[PATCH v4 6/9] mfd: intel_soc_pmic_bxtwc: utilize devm_* functions in driver probe

From: Kuppuswamy Sathyanarayanan Cleanup the resource allocation/free code in probe function by using devm_* calls. Signed-off-by: Kuppuswamy Sathyanarayanan Acked-for-MFD-by: Lee Jones --- drivers/mfd/intel_soc_pmic_bxtwc.c | 54 +- 1 file changed, 18

[PATCH v4 2/9] mfd: intel_soc_pmic_bxtwc: remove thermal second level irqs

From: Kuppuswamy Sathyanarayanan Since all second level thermal irqs are consumed by the same device(bxt_wcove_thermal), there is no need to expose them as separate interrupts. We can just export only the first level irqs for thermal and let the

[PATCH v4 2/9] mfd: intel_soc_pmic_bxtwc: remove thermal second level irqs

From: Kuppuswamy Sathyanarayanan Since all second level thermal irqs are consumed by the same device(bxt_wcove_thermal), there is no need to expose them as separate interrupts. We can just export only the first level irqs for thermal and let the device(bxt_wcove_thermal) driver handle the second

[PATCH v4 0/9] WCOVE chained IRQ fix

From: Kuppuswamy Sathyanarayanan Following patch set fixes the chained IRQ issue observed in WCOVE PMIC driver. Changes since v3: * Added fix for typec wcove driver. Kuppuswamy Sathyanarayanan (9): mfd: intel_soc_pmic_bxtwc: fix TMU interrupt

[PATCH v4 9/9] usb: typec: typec_wcove: Use charger irq chip to get usbc virq

From: Kuppuswamy Sathyanarayanan Currently, in Whiskey cove PMIC driver, USBC IRQ is moved under charger level2 irq chip. So use irq_chip_data_chgr to get the USBC virtual IRQ number. Signed-off-by: Kuppuswamy Sathyanarayanan

[PATCH v4 0/9] WCOVE chained IRQ fix

From: Kuppuswamy Sathyanarayanan Following patch set fixes the chained IRQ issue observed in WCOVE PMIC driver. Changes since v3: * Added fix for typec wcove driver. Kuppuswamy Sathyanarayanan (9): mfd: intel_soc_pmic_bxtwc: fix TMU interrupt index mfd: intel_soc_pmic_bxtwc: remove

[PATCH v4 9/9] usb: typec: typec_wcove: Use charger irq chip to get usbc virq

From: Kuppuswamy Sathyanarayanan Currently, in Whiskey cove PMIC driver, USBC IRQ is moved under charger level2 irq chip. So use irq_chip_data_chgr to get the USBC virtual IRQ number. Signed-off-by: Kuppuswamy Sathyanarayanan --- drivers/usb/typec/typec_wcove.c | 2 +- 1 file changed, 1

[PATCH v4 4/9] mfd: intel_soc_pmic_bxtwc: remove second level irq for gpio device

From: Kuppuswamy Sathyanarayanan Currently all PMIC GPIO domain irqs are consumed by the same device(bxt_wcove_gpio), so there is no need to export them as separate interrupts. We can just export only the first level GPIO irq(BXTWC_GPIO_LVL1_IRQ) as an

[PATCH v4 5/9] gpio: gpio-wcove: use first level PMIC GPIO irq

From: Kuppuswamy Sathyanarayanan PMIC mfd driver only exports first level irq for GPIO device. But currently we are reading the irqs from the second level irq chip, So this patch fixes this issue by adding support to use first level PMIC GPIO irq.

[PATCH v4 4/9] mfd: intel_soc_pmic_bxtwc: remove second level irq for gpio device

From: Kuppuswamy Sathyanarayanan Currently all PMIC GPIO domain irqs are consumed by the same device(bxt_wcove_gpio), so there is no need to export them as separate interrupts. We can just export only the first level GPIO irq(BXTWC_GPIO_LVL1_IRQ) as an irq resource and let the GPIO device

[PATCH v4 5/9] gpio: gpio-wcove: use first level PMIC GPIO irq

From: Kuppuswamy Sathyanarayanan PMIC mfd driver only exports first level irq for GPIO device. But currently we are reading the irqs from the second level irq chip, So this patch fixes this issue by adding support to use first level PMIC GPIO irq. Signed-off-by: Kuppuswamy Sathyanarayanan

[PATCH v4 3/9] thermal: intel_bxt_pmic_thermal: use first level PMIC thermal irq

From: Kuppuswamy Sathyanarayanan PMIC mfd driver only exports first level irq for thermal device. But currently we are reading the irqs from the second level irq chip, So this patch fixes this issue by adding support to use first level PMIC thermal

[PATCH v4 7/9] mfd: intel_soc_pmic_bxtwc: use chained irqs for second level irq chips

From: Kuppuswamy Sathyanarayanan Whishkey cove PMIC has support to mask/unmask interrupts at two levels. At first level we can mask/unmask interrupt domains like TMU, GPIO, ADC, CHGR, BCU THERMAL and PWRBTN and at second level, it provides facility to

[PATCH v4 3/9] thermal: intel_bxt_pmic_thermal: use first level PMIC thermal irq

From: Kuppuswamy Sathyanarayanan PMIC mfd driver only exports first level irq for thermal device. But currently we are reading the irqs from the second level irq chip, So this patch fixes this issue by adding support to use first level PMIC thermal irq. Signed-off-by: Kuppuswamy Sathyanarayanan

[PATCH v4 7/9] mfd: intel_soc_pmic_bxtwc: use chained irqs for second level irq chips

From: Kuppuswamy Sathyanarayanan Whishkey cove PMIC has support to mask/unmask interrupts at two levels. At first level we can mask/unmask interrupt domains like TMU, GPIO, ADC, CHGR, BCU THERMAL and PWRBTN and at second level, it provides facility to mask/unmask individual interrupts belong

[PATCH v4 8/9] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

From: Kuppuswamy Sathyanarayanan Currently in WCOVE PMIC mfd driver, all second level irq chips are chained to the respective first level irqs. So there is no need for explicitly unmasking the first level irq in this driver. This patches removes this

[PATCH v4 8/9] platform: x86: intel_bxtwc_tmu: remove first level irq unmask

From: Kuppuswamy Sathyanarayanan Currently in WCOVE PMIC mfd driver, all second level irq chips are chained to the respective first level irqs. So there is no need for explicitly unmasking the first level irq in this driver. This patches removes this level 1 irq unmask support. Signed-off-by:

Re: [PATCH v6 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g

On 2017.05.27 16:38:49 +0800, Xiaoguang Chen wrote: > decode frambuffer attributes of primary, cursor and sprite plane > > Signed-off-by: Xiaoguang Chen > --- > drivers/gpu/drm/i915/gvt/Makefile | 3 +- > drivers/gpu/drm/i915/gvt/display.c| 2 +- >

Re: [PATCH v6 3/6] drm/i915/gvt: Frame buffer decoder support for GVT-g

On 2017.05.27 16:38:49 +0800, Xiaoguang Chen wrote: > decode frambuffer attributes of primary, cursor and sprite plane > > Signed-off-by: Xiaoguang Chen > --- > drivers/gpu/drm/i915/gvt/Makefile | 3 +- > drivers/gpu/drm/i915/gvt/display.c| 2 +- > drivers/gpu/drm/i915/gvt/display.h

Re: [PATCH v3] scripts/gdb: make lx-dmesg command work (reliably)

Hi André, Jan, Andrew, On 26/05/17 20:28, Jan Kiszka wrote: > On 2017-05-26 13:22, André Draszik wrote: >> lx-dmesg needs access to the log_buf symbol from printk.c. >> Unfortunately, the symbol log_buf also exists in BPF's >> verifier.c and hence gdb can pick one or the other. If it >> happens

Re: [PATCH v3] scripts/gdb: make lx-dmesg command work (reliably)

Hi André, Jan, Andrew, On 26/05/17 20:28, Jan Kiszka wrote: > On 2017-05-26 13:22, André Draszik wrote: >> lx-dmesg needs access to the log_buf symbol from printk.c. >> Unfortunately, the symbol log_buf also exists in BPF's >> verifier.c and hence gdb can pick one or the other. If it >> happens

Re: [PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

Hey MNC, On Fri, 2017-05-26 at 22:14 -0500, Mike Christie wrote: > Thanks for the patch. > Btw, after running DATERA's internal longevity and scale tests across ~20 racks on v4.1.y with this patch over the long weekend, there haven't been any additional regressions. > On 05/26/2017 12:32 AM,

Re: [PATCH] iscsi-target: Fix initial login PDU asynchronous socket close OOPs

Hey MNC, On Fri, 2017-05-26 at 22:14 -0500, Mike Christie wrote: > Thanks for the patch. > Btw, after running DATERA's internal longevity and scale tests across ~20 racks on v4.1.y with this patch over the long weekend, there haven't been any additional regressions. > On 05/26/2017 12:32 AM,

Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

On 2017.05.27 16:38:48 +0800, Xiaoguang Chen wrote: > OpRegion is needed to support display related operation for > intel vgpu. > > A vfio device region is added to intel vgpu to deliver the > host OpRegion information to user space so user space can > construct the OpRegion for vgpu. > >

Re: [PATCH v6 2/6] drm/i915/gvt: OpRegion support for GVT-g

On 2017.05.27 16:38:48 +0800, Xiaoguang Chen wrote: > OpRegion is needed to support display related operation for > intel vgpu. > > A vfio device region is added to intel vgpu to deliver the > host OpRegion information to user space so user space can > construct the OpRegion for vgpu. > >

Re: [RFC PATCH v2] ASoC: Intel: sst: Delete sst_shim_regs64; saved regs are never used

On Tue, May 30, 2017 at 08:06:38PM +0300, Andy Shevchenko wrote: > On Tue, May 30, 2017 at 7:51 PM, Douglas Anderson > wrote: > > In commit 9a075265c6dc ("ASoC: Intel: sst: Remove unused function > > sst_restore_shim64()"), we deleted the sst_restore_shim64() since it > >

Re: [RFC PATCH v2] ASoC: Intel: sst: Delete sst_shim_regs64; saved regs are never used

On Tue, May 30, 2017 at 08:06:38PM +0300, Andy Shevchenko wrote: > On Tue, May 30, 2017 at 7:51 PM, Douglas Anderson > wrote: > > In commit 9a075265c6dc ("ASoC: Intel: sst: Remove unused function > > sst_restore_shim64()"), we deleted the sst_restore_shim64() since it > > was never used. ...but

Re: [RFC PATCH] vmalloc: show more detail info in vmallocinfo for clarify

Hi Tim, Thanks for comment! On 2017/5/31 8:56, Tim Chen wrote: > On 05/19/2017 11:47 PM, Yisheng Xie wrote: >> When ioremap a 67112960 bytes vm_area with the vmallocinfo: >> [..] >> 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vmalloc >> 0xec80-0xecbe1000 4067328

Re: [RFC PATCH] vmalloc: show more detail info in vmallocinfo for clarify

Hi Tim, Thanks for comment! On 2017/5/31 8:56, Tim Chen wrote: > On 05/19/2017 11:47 PM, Yisheng Xie wrote: >> When ioremap a 67112960 bytes vm_area with the vmallocinfo: >> [..] >> 0xec79b000-0xec7fa000 389120 ftl_add_mtd+0x4d0/0x754 pages=94 vmalloc >> 0xec80-0xecbe1000 4067328

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

gt;client->irq > 0 || ^ Caused by commit 345b89453dda ("rtc: rtc-ds1307: enable support for mcp794xx as a wakeup source without IRQ") interacting with commit 11e5890b5342 ("rtc: ds1307: convert driver to regmap") I have used t

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

gt;client->irq > 0 || ^ Caused by commit 345b89453dda ("rtc: rtc-ds1307: enable support for mcp794xx as a wakeup source without IRQ") interacting with commit 11e5890b5342 ("rtc: ds1307: convert driver to regmap") I have used t

Re: [GIT PULL] Immutable branch between MFD, GPIO, Thermal and X86 due for the v4.13 merge window

Hi All, On Tue, May 30, 2017 at 8:38 PM, Stephen Rothwell wrote: > Hi all, > > On Tue, 30 May 2017 09:53:06 +0100 Lee Jones wrote: >> >> Dear fellow Maintainers, >> >> Enjoy! >> >> The following changes since commit

Re: [GIT PULL] Immutable branch between MFD, GPIO, Thermal and X86 due for the v4.13 merge window

Hi All, On Tue, May 30, 2017 at 8:38 PM, Stephen Rothwell wrote: > Hi all, > > On Tue, 30 May 2017 09:53:06 +0100 Lee Jones wrote: >> >> Dear fellow Maintainers, >> >> Enjoy! >> >> The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: >> >> Linux 4.12-rc1 (2017-05-13

Re: [GIT PULL] Immutable branch between MFD, GPIO, Thermal and X86 due for the v4.13 merge window

Sorry, its a mistake from my end. It looks like typec wcove driver got merged recently and I missed to add it to my cleanup patch set. Lee, I have created a patch to fix this issue. Do you want me to send the entire series again with this fix or just send the fix alone. On Tue, May 30, 2017

Re: [GIT PULL] Immutable branch between MFD, GPIO, Thermal and X86 due for the v4.13 merge window

Sorry, its a mistake from my end. It looks like typec wcove driver got merged recently and I missed to add it to my cleanup patch set. Lee, I have created a patch to fix this issue. Do you want me to send the entire series again with this fix or just send the fix alone. On Tue, May 30, 2017

Re: [PATCH] macintosh: move mac_hid driver to input/mouse.

On Tue, May 30, 2017 at 02:56:18PM +0200, Michal Suchánek wrote: > > > > I concede userspace doesn't have the feature, but you should > > > > really have a look at libinput (i.e. open a bug on > > > > bugs.freedesktop.org) and request the feature here. > > > > > > > > > > > > > > > >

Re: [PATCH] macintosh: move mac_hid driver to input/mouse.

On Tue, May 30, 2017 at 02:56:18PM +0200, Michal Suchánek wrote: > > > > I concede userspace doesn't have the feature, but you should > > > > really have a look at libinput (i.e. open a bug on > > > > bugs.freedesktop.org) and request the feature here. > > > > > > > > > > > > > > > >

Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

Maxime Ripard writes: > Hi Kevin, > > On Thu, May 18, 2017 at 11:59:50AM -0700, Kevin Hilman wrote: >> On Fri, Mar 17, 2017 at 10:39 AM, Kevin Hilman wrote: >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard >> >

Re: [PATCH 4/4] ARM: multi_v7_defconfig: Switch AXP20x driver from module to built-in

Maxime Ripard writes: > Hi Kevin, > > On Thu, May 18, 2017 at 11:59:50AM -0700, Kevin Hilman wrote: >> On Fri, Mar 17, 2017 at 10:39 AM, Kevin Hilman wrote: >> > On Fri, Feb 10, 2017 at 12:42 AM, Maxime Ripard >> > wrote: >> >> On Wed, Feb 08, 2017 at 11:09:31PM +0100, Rask Ingemann Lambertsen

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/30/2017 10:48 PM, James Morris wrote: On Mon, 29 May 2017, Boris Lukashev wrote: With all due respect sir, i believe your review falls short of the purpose of this effort - to harden the kernel against flaws in userspace. Which effort? Kernel self protection is about protecting

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On 05/30/2017 10:48 PM, James Morris wrote: On Mon, 29 May 2017, Boris Lukashev wrote: With all due respect sir, i believe your review falls short of the purpose of this effort - to harden the kernel against flaws in userspace. Which effort? Kernel self protection is about protecting

Re: [HMM 14/15] mm/migrate: support un-addressable ZONE_DEVICE page in migration v2

On Wed, 24 May 2017 13:20:23 -0400 Jérôme Glisse wrote: > Allow to unmap and restore special swap entry of un-addressable > ZONE_DEVICE memory. > > Changed since v1: > - s/device unaddressable/device private/ > > Signed-off-by: Jérôme Glisse > Cc:

Re: [HMM 14/15] mm/migrate: support un-addressable ZONE_DEVICE page in migration v2

On Wed, 24 May 2017 13:20:23 -0400 Jérôme Glisse wrote: > Allow to unmap and restore special swap entry of un-addressable > ZONE_DEVICE memory. > > Changed since v1: > - s/device unaddressable/device private/ > > Signed-off-by: Jérôme Glisse > Cc: Kirill A. Shutemov > --- >

Re: [PATCH 1/2] ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties

On Tue, May 30, 2017 at 2:34 PM, Leonard Crestez wrote: > Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same > register values can be set through the micrel phy driver by using dts > properties. > > This seems preferable and allows cleanly fixing

Re: [PATCH 1/2] ARM: dts: imx6ul-14x14-evk: Add ksz8081 phy properties

On Tue, May 30, 2017 at 2:34 PM, Leonard Crestez wrote: > Right now mach-imx6ul registers a fixup for the ksz8081 phy. The same > register values can be set through the micrel phy driver by using dts > properties. > > This seems preferable and allows cleanly fixing suspend/resume. > >

Re: [PATCH] cpufreq: imx6q: imx6ull should use the same flow as imx6ul

On Tue, May 30, 2017 at 12:57 PM, Leonard Crestez wrote: > From: Octavian Purdila > > This fixes an issue with imx6ull where setting the frequency to 528Mhz > would actually set the ARM clock to 324Mhz. > > Signed-off-by: Octavian Purdila

Re: [PATCH] cpufreq: imx6q: imx6ull should use the same flow as imx6ul

On Tue, May 30, 2017 at 12:57 PM, Leonard Crestez wrote: > From: Octavian Purdila > > This fixes an issue with imx6ull where setting the frequency to 528Mhz > would actually set the ARM clock to 324Mhz. > > Signed-off-by: Octavian Purdila > Signed-off-by: Leonard Crestez Reviewed-by: Fabio

Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs

On Wed, 2017-05-31 at 12:28 +0900, Hirokazu Honda wrote: > If I understand a bitmap correctly, it is necessary to change the log level > for each message. > I didn't mean a bitmap will take a long CPU time. > I mean the work to change so takes a long time. No, none of the messages or levels need

Re: [PATCH v2] [media] vb2: core: Lower the log level of debug outputs

On Wed, 2017-05-31 at 12:28 +0900, Hirokazu Honda wrote: > If I understand a bitmap correctly, it is necessary to change the log level > for each message. > I didn't mean a bitmap will take a long CPU time. > I mean the work to change so takes a long time. No, none of the messages or levels need

Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c

On 5/27/2017 9:56 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 9:00 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 6:31 AM, kernel test robot wrote: FYI, we noticed the following commit: commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf

Re: [x86/mm] e2a7dcce31: kernel_BUG_at_arch/x86/mm/tlb.c

On 5/27/2017 9:56 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 9:00 AM, Andy Lutomirski wrote: On Sat, May 27, 2017 at 6:31 AM, kernel test robot wrote: FYI, we noticed the following commit: commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf ("x86/mm: Rework lazy TLB to track the

Re: [PATCH] powerpc/hotplug-mem: Fix aa_index match bug for hotplug

Nathan Fontenot writes: > On 05/30/2017 06:41 AM, Michael Ellerman wrote: >> Michael Bringmann writes: >>> When adding or removing memory, the aa_index (affinity value) for the >>> memblock must also be converted to match the endianness of the

Re: [PATCH] powerpc/hotplug-mem: Fix aa_index match bug for hotplug

Nathan Fontenot writes: > On 05/30/2017 06:41 AM, Michael Ellerman wrote: >> Michael Bringmann writes: >>> When adding or removing memory, the aa_index (affinity value) for the >>> memblock must also be converted to match the endianness of the rest >>> of the 'ibm,dynamic-memory' property.

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On Wed, 24 May 2017 13:20:21 -0400 Jérôme Glisse wrote: > This patch add a new memory migration helpers, which migrate memory > backing a range of virtual address of a process to different memory > (which can be allocated through special allocator). It differs from > numa

Re: [HMM 12/15] mm/migrate: new memory migration helper for use with device memory v4

On Wed, 24 May 2017 13:20:21 -0400 Jérôme Glisse wrote: > This patch add a new memory migration helpers, which migrate memory > backing a range of virtual address of a process to different memory > (which can be allocated through special allocator). It differs from > numa migration by working on

Re: [PATCH] cpufreq: imx6q: imx6ull should use the same flow as imx6ul

On 30-05-17, 18:57, Leonard Crestez wrote: > From: Octavian Purdila > > This fixes an issue with imx6ull where setting the frequency to 528Mhz > would actually set the ARM clock to 324Mhz. > > Signed-off-by: Octavian Purdila > Signed-off-by:

Re: [PATCH] cpufreq: imx6q: imx6ull should use the same flow as imx6ul

On 30-05-17, 18:57, Leonard Crestez wrote: > From: Octavian Purdila > > This fixes an issue with imx6ull where setting the frequency to 528Mhz > would actually set the ARM clock to 324Mhz. > > Signed-off-by: Octavian Purdila > Signed-off-by: Leonard Crestez > --- >

Re: [PATCH] remoteproc: fix spelling mistake: "Resouce" -> "Resource"

On Sun 28 May 23:23 PDT 2017, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err message > Thanks Colin, Regards, Bjorn

Re: [PATCH] remoteproc: fix spelling mistake: "Resouce" -> "Resource"

On Sun 28 May 23:23 PDT 2017, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err message > Thanks Colin, Regards, Bjorn

[PATCH 1/2] fs/dcache.c: New copy_dname method

From: "leilei.lin" locklessly and integrally copy dentry name. It will be used later for bugfix Signed-off-by: leilei.lin --- fs/dcache.c| 38 ++ include/linux/dcache.h | 2 ++ 2 files

[PATCH 0/2] fsnotify: fix mem overwritten

From: "leilei.lin" Slub alloced mem overwritten ocurrs when fsnotify thread was copying the dentry name and another rename thread change the dentry name at same time. These patches do the following: 1. A new copy_dname method was created which copy file_name to new

[PATCH 2/2] fsnotify: use method copy_dname copying filename

From: "leilei.lin" Kernel got panicked in inotify_handle_event, while running the rename operation against the same file. The root cause is that the race between fsnotify thread and file rename thread. When fsnotify thread was copying the dentry name, another rename

[PATCH 1/2] fs/dcache.c: New copy_dname method

From: "leilei.lin" locklessly and integrally copy dentry name. It will be used later for bugfix Signed-off-by: leilei.lin --- fs/dcache.c| 38 ++ include/linux/dcache.h | 2 ++ 2 files changed, 40 insertions(+) diff --git a/fs/dcache.c

[PATCH 0/2] fsnotify: fix mem overwritten

From: "leilei.lin" Slub alloced mem overwritten ocurrs when fsnotify thread was copying the dentry name and another rename thread change the dentry name at same time. These patches do the following: 1. A new copy_dname method was created which copy file_name to new alloc mem. The later

[PATCH 2/2] fsnotify: use method copy_dname copying filename

From: "leilei.lin" Kernel got panicked in inotify_handle_event, while running the rename operation against the same file. The root cause is that the race between fsnotify thread and file rename thread. When fsnotify thread was copying the dentry name, another rename thread could change the

Re: [PATCH] modpost: abort if a module name is too long

On 2017/5/31 11:30, Jessica Yu wrote: > +++ Wanlong Gao [31/05/17 10:23 +0800]: >> Hi Jessica, >> >> On 2017/5/29 17:10, Jessica Yu wrote: >>> +++ Xie XiuQi [20/05/17 15:46 +0800]: From: Wanlong Gao Module name has a limited length, but currently the build

Re: [PATCH] modpost: abort if a module name is too long

On 2017/5/31 11:30, Jessica Yu wrote: > +++ Wanlong Gao [31/05/17 10:23 +0800]: >> Hi Jessica, >> >> On 2017/5/29 17:10, Jessica Yu wrote: >>> +++ Xie XiuQi [20/05/17 15:46 +0800]: From: Wanlong Gao Module name has a limited length, but currently the build system allows the

linux-next 20170519 and later - ^S/^Q borkage on ttys.

4.12.0-rc3-next-20170530 #489 [ 1844.182078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1844.182085] kworker/u8:3D11008 129 2 0x [ 1844.182109] Workqueue: events_unbound flush_to_ldisc [ 1844.182118] Call Trace: [ 1844.182136

linux-next 20170519 and later - ^S/^Q borkage on ttys.

4.12.0-rc3-next-20170530 #489 [ 1844.182078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1844.182085] kworker/u8:3D11008 129 2 0x [ 1844.182109] Workqueue: events_unbound flush_to_ldisc [ 1844.182118] Call Trace: [ 1844.182136

Re: [PATCH] modpost: abort if a module name is too long

Hi Jessica, On 2017/5/31 11:30, Jessica Yu wrote: > +++ Wanlong Gao [31/05/17 10:23 +0800]: >> Hi Jessica, >> >> On 2017/5/29 17:10, Jessica Yu wrote: >>> +++ Xie XiuQi [20/05/17 15:46 +0800]: From: Wanlong Gao Module name has a limited length, but currently

Re: [PATCH] modpost: abort if a module name is too long

Hi Jessica, On 2017/5/31 11:30, Jessica Yu wrote: > +++ Wanlong Gao [31/05/17 10:23 +0800]: >> Hi Jessica, >> >> On 2017/5/29 17:10, Jessica Yu wrote: >>> +++ Xie XiuQi [20/05/17 15:46 +0800]: From: Wanlong Gao Module name has a limited length, but currently the build system

Re: [PATCH v7 1/2] soc: qcom: Add device tree binding for GLINK RPM

On Sat, May 27, 2017 at 04:23:34PM -0700, Bjorn Andersson wrote: > Add device tree binding documentation for the Qualcomm GLINK RPM, used > for communication with the Resource Power Management subsystem in > various Qualcomm SoCs. > > Acked-by: Rob Herring > Signed-off-by: Bjorn

Re: [GIT PULL] Immutable branch between MFD, GPIO, Thermal and X86 due for the v4.13 merge window

Hi all, On Tue, 30 May 2017 09:53:06 +0100 Lee Jones wrote: > > Dear fellow Maintainers, > > Enjoy! > > The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: > > Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) > > are available in the git repository

Re: [PATCH v7 1/2] soc: qcom: Add device tree binding for GLINK RPM

On Sat, May 27, 2017 at 04:23:34PM -0700, Bjorn Andersson wrote: > Add device tree binding documentation for the Qualcomm GLINK RPM, used > for communication with the Resource Power Management subsystem in > various Qualcomm SoCs. > > Acked-by: Rob Herring > Signed-off-by: Bjorn Andersson > ---

Re: [GIT PULL] Immutable branch between MFD, GPIO, Thermal and X86 due for the v4.13 merge window

Hi all, On Tue, 30 May 2017 09:53:06 +0100 Lee Jones wrote: > > Dear fellow Maintainers, > > Enjoy! > > The following changes since commit 2ea659a9ef488125eb46da6eb571de5eae5c43f6: > > Linux 4.12-rc1 (2017-05-13 13:19:49 -0700) > > are available in the git repository at: > >

Re: [RFC] tick/nohz: schedule TIMER_SOFTIRQ immediately for expired timers

On Tue, May 30, 2017 at 11:47:59PM +0200, Thomas Gleixner wrote: > On Fri, 26 May 2017, Octavian Purdila wrote: > > On Vi, 2017-05-26 at 14:55 +0200, Frederic Weisbecker wrote: > > > > Nice, it is less expensive and deletes some code :-) Thanks for the > > quick fix Frederic, I confirm it solves

Re: [RFC] tick/nohz: schedule TIMER_SOFTIRQ immediately for expired timers

On Tue, May 30, 2017 at 11:47:59PM +0200, Thomas Gleixner wrote: > On Fri, 26 May 2017, Octavian Purdila wrote: > > On Vi, 2017-05-26 at 14:55 +0200, Frederic Weisbecker wrote: > > > > Nice, it is less expensive and deletes some code :-) Thanks for the > > quick fix Frederic, I confirm it solves

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

soc_pmic_bxtwc: Use chained irqs for second level > irq chips") > > interacting with commit > > d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB > Type-C PHY") > > from Linus' tree (v4.12-rc1). grep is your friend. :-) > > I hav

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

s for second level > irq chips") > > interacting with commit > > d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB > Type-C PHY") > > from Linus' tree (v4.12-rc1). grep is your friend. :-) > > I have used the mfd tree fr

Re: [net-bluetooth] question about potential null pointer dereference

Hi Marcel, Quoting "Gustavo A. R. Silva" : Hi Marcel, Quoting Marcel Holtmann : Hi Gustavo, While looking into Coverity ID 1357456 I ran into the following piece of code at net/bluetooth/smp.c:166 166/* The following functions map to the LE

Re: [net-bluetooth] question about potential null pointer dereference

Hi Marcel, Quoting "Gustavo A. R. Silva" : Hi Marcel, Quoting Marcel Holtmann : Hi Gustavo, While looking into Coverity ID 1357456 I ran into the following piece of code at net/bluetooth/smp.c:166 166/* The following functions map to the LE SC SMP crypto functions 167 * AES-CMAC, f4,

[PATCH V2] qla4xxx: Fix a sleep-in-atomic bug

The driver may sleep under a write spin lock, the function call path is: qla4_82xx_wr_32 (acquire the lock) qla4_82xx_crb_win_lock schedule or cpu_relax To fix it, the lock is released before "schedule" and "cpu_relax", and the lock is acquired again after "schedule" and "cpu_relax".

[PATCH V2] qla4xxx: Fix a sleep-in-atomic bug

The driver may sleep under a write spin lock, the function call path is: qla4_82xx_wr_32 (acquire the lock) qla4_82xx_crb_win_lock schedule or cpu_relax To fix it, the lock is released before "schedule" and "cpu_relax", and the lock is acquired again after "schedule" and "cpu_relax".

Re: [PATCH v2 1/3] pwm: sun4i: improve hardware read out

On Wed, May 31, 2017 at 3:32 AM, Alexandre Belloni wrote: > Implement .get_state instead of only reading the polarity at probe time. > This allows to get the proper state, period and duty cycle. > > Signed-off-by: Alexandre Belloni

Re: [PATCH v2 1/3] pwm: sun4i: improve hardware read out

On Wed, May 31, 2017 at 3:32 AM, Alexandre Belloni wrote: > Implement .get_state instead of only reading the polarity at probe time. > This allows to get the proper state, period and duty cycle. > > Signed-off-by: Alexandre Belloni > --- > drivers/pwm/pwm-sun4i.c | 65 >

Re: [PATCH] modpost: abort if a module name is too long

+++ Wanlong Gao [31/05/17 10:23 +0800]: Hi Jessica, On 2017/5/29 17:10, Jessica Yu wrote: +++ Xie XiuQi [20/05/17 15:46 +0800]: From: Wanlong Gao Module name has a limited length, but currently the build system allows the build finishing even if the module name is too

Re: [PATCH] modpost: abort if a module name is too long

+++ Wanlong Gao [31/05/17 10:23 +0800]: Hi Jessica, On 2017/5/29 17:10, Jessica Yu wrote: +++ Xie XiuQi [20/05/17 15:46 +0800]: From: Wanlong Gao Module name has a limited length, but currently the build system allows the build finishing even if the module name is too long. CC

  1   2   3   4   5   6   7   8   9   10   >