Re: [PATCH v3] mm, thp: introduce generic transparent huge page allocation interfaces

On Thu, 7 Dec 2017 18:54:19 +0800 changbin...@intel.com wrote: > From: Changbin Du > > This patch introduced 4 new interfaces to allocate a prepared transparent > huge page. These interfaces merge distributed two-step allocation as simple > single step. And they can

Re: [PATCH v3] mm, thp: introduce generic transparent huge page allocation interfaces

On Thu, 7 Dec 2017 18:54:19 +0800 changbin...@intel.com wrote: > From: Changbin Du > > This patch introduced 4 new interfaces to allocate a prepared transparent > huge page. These interfaces merge distributed two-step allocation as simple > single step. And they can avoid issue like forget to

Re: [PATCH] doc: convert printk-formats.txt to rst

On Thu, Dec 07, 2017 at 02:50:42PM -0800, Kees Cook wrote: > On Tue, Dec 5, 2017 at 5:45 PM, Tobin C. Harding wrote: > > Documentation/printk-formats.txt is a candidate for conversion to > > ReStructuredText format. Some effort has already been made to do this > > conversion even

Re: [PATCH] doc: convert printk-formats.txt to rst

On Thu, Dec 07, 2017 at 02:50:42PM -0800, Kees Cook wrote: > On Tue, Dec 5, 2017 at 5:45 PM, Tobin C. Harding wrote: > > Documentation/printk-formats.txt is a candidate for conversion to > > ReStructuredText format. Some effort has already been made to do this > > conversion even thought the

[RFC][PATCH] staging: ion: Fix ion_cma_heap allocations

In trying to add support for drm_hwcomposer to HiKey, I've needed to utilize the ION CMA heap, and I've noticed problems with allocations on newer kernels failing. It seems back with 204f672255c22 ("ion: Use CMA APIs directly"), the ion_cma_heap code was modified to use the CMA API, but kept the

Re: [PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation

On Thu, Dec 07, 2017 at 03:46:59PM +0100, Andrey Zhizhikin wrote: > Create Documentation portion of UIO driver with Generic Interrupt Handler. > > This patch creates a dt-binding documentation portion of the UIO Driver. > > In addition to definition of standard required properties, new optional

[RFC][PATCH] staging: ion: Fix ion_cma_heap allocations

In trying to add support for drm_hwcomposer to HiKey, I've needed to utilize the ION CMA heap, and I've noticed problems with allocations on newer kernels failing. It seems back with 204f672255c22 ("ion: Use CMA APIs directly"), the ion_cma_heap code was modified to use the CMA API, but kept the

Re: [PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation

On Thu, Dec 07, 2017 at 03:46:59PM +0100, Andrey Zhizhikin wrote: > Create Documentation portion of UIO driver with Generic Interrupt Handler. > > This patch creates a dt-binding documentation portion of the UIO Driver. > > In addition to definition of standard required properties, new optional

Re: [RFC PATCH] mm: kasan: suppress soft lockup in slub when !CONFIG_PREEMPT

On Fri, Dec 08, 2017 at 07:30:07AM +0800, Yang Shi wrote: > When running stress test with KASAN enabled, the below softlockup may > happen occasionally: > > NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! > hardirqs last  enabled at (0): [<          (null)>]      (null) > hardirqs last

Re: [RFC PATCH] mm: kasan: suppress soft lockup in slub when !CONFIG_PREEMPT

On Fri, Dec 08, 2017 at 07:30:07AM +0800, Yang Shi wrote: > When running stress test with KASAN enabled, the below softlockup may > happen occasionally: > > NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! > hardirqs last  enabled at (0): [<          (null)>]      (null) > hardirqs last

Re: [PATCH v0 1/5] x86_64: march=native support

One more thing: you HAVE to make arch/x86/include/asm/required-features.h aware of any features that the kernel unconditionally depend on. Again, using the gcc cpp macros that reflect what bits gcc itself broadcast. However, this is perhaps where CONFIG flags become important, since

Re: [PATCH v0 1/5] x86_64: march=native support

One more thing: you HAVE to make arch/x86/include/asm/required-features.h aware of any features that the kernel unconditionally depend on. Again, using the gcc cpp macros that reflect what bits gcc itself broadcast. However, this is perhaps where CONFIG flags become important, since

Re: [PATCH v6 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

On Thu, Dec 07, 2017 at 06:20:23PM +0800, Li Wei wrote: > add ufs node document for Hisilicon. > > Signed-off-by: Li Wei > --- Version history? > Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 38 > ++ > 1 file changed, 38 insertions(+) >

Re: [PATCH v6 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

On Thu, Dec 07, 2017 at 06:20:23PM +0800, Li Wei wrote: > add ufs node document for Hisilicon. > > Signed-off-by: Li Wei > --- Version history? > Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 38 > ++ > 1 file changed, 38 insertions(+) > create mode 100644

[PATCH v1 3/3] x86/mm: Encrypt the initrd earlier for BSP microcode update

Currently the BSP microcode update code examines the initrd very early in the boot process. If SME is active, the initrd is treated as being encrypted but it has not been encrypted (in place) yet. Update the early boot code that encrypts the kernel to also encrypt the initrd so that early BSP

[PATCH v1 3/3] x86/mm: Encrypt the initrd earlier for BSP microcode update

Currently the BSP microcode update code examines the initrd very early in the boot process. If SME is active, the initrd is treated as being encrypted but it has not been encrypted (in place) yet. Update the early boot code that encrypts the kernel to also encrypt the initrd so that early BSP

[PATCH v1 0/3] x86: SME: BSP/SME microcode update fix

This patch series addresses an issue when SME is active and the BSP is attempting to check for and load microcode during load_ucode_bsp(). Since the initrd has not been decrypted (yet) and the virtual address of the initrd treats the memory as encrypted, the CPIO archive parsing fails to locate

[PATCH v1 2/3] x86/mm: Prepare sme_encrypt_kernel() for PAGE aligned encryption

In preparation for encrypting more than just the kernel, the encryption support in sme_encrypt_kernel() needs to support 4KB page aligned encryption instead of just 2MB large page aligned encryption. Update the routines that populate the PGD to support non-2MB aligned addresses. This is done by

[PATCH v1 0/3] x86: SME: BSP/SME microcode update fix

This patch series addresses an issue when SME is active and the BSP is attempting to check for and load microcode during load_ucode_bsp(). Since the initrd has not been decrypted (yet) and the virtual address of the initrd treats the memory as encrypted, the CPIO archive parsing fails to locate

[PATCH v1 2/3] x86/mm: Prepare sme_encrypt_kernel() for PAGE aligned encryption

In preparation for encrypting more than just the kernel, the encryption support in sme_encrypt_kernel() needs to support 4KB page aligned encryption instead of just 2MB large page aligned encryption. Update the routines that populate the PGD to support non-2MB aligned addresses. This is done by

[PATCH v1 1/3] x86/mm: Centralize PMD flags in sme_encrypt_kernel()

In preparation for encrypting more than just the kernel during early boot processing, centralize the use of the PMD flag settings based on the type of mapping desired. When 4KB aligned encryption is added, this will allow either PTE flags or large page PMD flags to be used without requiring the

[PATCH v1 1/3] x86/mm: Centralize PMD flags in sme_encrypt_kernel()

In preparation for encrypting more than just the kernel during early boot processing, centralize the use of the PMD flag settings based on the type of mapping desired. When 4KB aligned encryption is added, this will allow either PTE flags or large page PMD flags to be used without requiring the

Re: [PATCH 1/3] doc: convert printk-formats.txt to rst

On Fri, Dec 08, 2017 at 09:27:54AM +1100, Tobin C. Harding wrote: [snip] New comments have come in from Kees Cook in thread for previous version. Please drop this set so Kees's suggestions can be implemented. thanks, Tobin.

Re: [PATCH 1/3] doc: convert printk-formats.txt to rst

On Fri, Dec 08, 2017 at 09:27:54AM +1100, Tobin C. Harding wrote: [snip] New comments have come in from Kees Cook in thread for previous version. Please drop this set so Kees's suggestions can be implemented. thanks, Tobin.

Re: [PATCH v3 2/4] regulator: bindings: Add properties for coupled regulators

On Thu, Dec 07, 2017 at 10:46:13AM +0100, Maciej Purski wrote: > Some regulators require keeping their voltage spread below defined > max_spread. > > Add properties to provide information on regulators' coupling. > > Signed-off-by: Maciej Purski > --- >

[RFC PATCH] mm: kasan: suppress soft lockup in slub when !CONFIG_PREEMPT

When running stress test with KASAN enabled, the below softlockup may happen occasionally: NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [blogbench:2997] Modules linked in: dm_mod(E) binfmt_misc(E) salsa20_generic(E) salsa20_x86_64(E) camellia_generic(E) camellia_aesni_avx_x86_64(E)

Re: [PATCH v3 2/4] regulator: bindings: Add properties for coupled regulators

On Thu, Dec 07, 2017 at 10:46:13AM +0100, Maciej Purski wrote: > Some regulators require keeping their voltage spread below defined > max_spread. > > Add properties to provide information on regulators' coupling. > > Signed-off-by: Maciej Purski > --- >

[RFC PATCH] mm: kasan: suppress soft lockup in slub when !CONFIG_PREEMPT

When running stress test with KASAN enabled, the below softlockup may happen occasionally: NMI watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [blogbench:2997] Modules linked in: dm_mod(E) binfmt_misc(E) salsa20_generic(E) salsa20_x86_64(E) camellia_generic(E) camellia_aesni_avx_x86_64(E)

Re: [PATCH] clk: qcom: gcc-msm8996: always enable aggre0_noc gdsc

On 07/12/17 22:54, Stephen Boyd wrote: .pwrsts = PWRSTS_OFF_ON, - .flags = VOTABLE, + .flags = VOTABLE | ALWAYS_ON, I dont think this flag has been added yet. Probably this needs to be folded into the other series? I agree, I will wait for Rajendras patches to land in or I

Re: [PATCH] clk: qcom: gcc-msm8996: always enable aggre0_noc gdsc

On 07/12/17 22:54, Stephen Boyd wrote: .pwrsts = PWRSTS_OFF_ON, - .flags = VOTABLE, + .flags = VOTABLE | ALWAYS_ON, I dont think this flag has been added yet. Probably this needs to be folded into the other series? I agree, I will wait for Rajendras patches to land in or I

Re: [PATCH v2 5/5] fpga: region: return NOTIFY_STOP if overlay shoud be accepted

On Wed, Nov 15, 2017 at 02:51:52PM -0600, Alan Tull wrote: > Recent changes to the Device Tree overlay notifier code have changed > how notifier return codes are interpreted, requiring a NOTIFY_STOP to > signal that the overlay should be accepted. This commit makes the > appropriate change to the

Re: [PATCH v2 5/5] fpga: region: return NOTIFY_STOP if overlay shoud be accepted

On Wed, Nov 15, 2017 at 02:51:52PM -0600, Alan Tull wrote: > Recent changes to the Device Tree overlay notifier code have changed > how notifier return codes are interpreted, requiring a NOTIFY_STOP to > signal that the overlay should be accepted. This commit makes the > appropriate change to the

[PATCH 4/4] checkpatch: add check for tag Co-Developed-by

From: Joe Perches Recently signature tag Co-Developed-by was added to the kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know about it yet. All prior tags used all lowercase characters except for first character. Checks for this format had to be re-worked

[PATCH 0/4] checkpatch: update warnings

This set is a combination of previous submissions [PATCH v2 0/3] checkpatch: warn for use of %px [PATCH] checkpatch: add check for tag Co-Developed-by Although seemingly unrelated, they both patch checkpatch.pl and they were both contributed to by Joe and myself. They are also tied together by

[PATCH 4/4] checkpatch: add check for tag Co-Developed-by

From: Joe Perches Recently signature tag Co-Developed-by was added to the kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know about it yet. All prior tags used all lowercase characters except for first character. Checks for this format had to be re-worked to allow for the

[PATCH 0/4] checkpatch: update warnings

This set is a combination of previous submissions [PATCH v2 0/3] checkpatch: warn for use of %px [PATCH] checkpatch: add check for tag Co-Developed-by Although seemingly unrelated, they both patch checkpatch.pl and they were both contributed to by Joe and myself. They are also tied together by

[PATCH 3/4] checkpatch: warn for use of %px

Usage of the new %px specifier potentially leaks sensitive inforamtion. Printing kernel addresses exposes the kernel layout in memory, this is potentially exploitable. We have tools in the kernel to help us do the right thing. We can have checkpatch warn developers of potential dangers of using

[PATCH 3/4] checkpatch: warn for use of %px

Usage of the new %px specifier potentially leaks sensitive inforamtion. Printing kernel addresses exposes the kernel layout in memory, this is potentially exploitable. We have tools in the kernel to help us do the right thing. We can have checkpatch warn developers of potential dangers of using

[PATCH 2/4] checkpatch: add sub routine get_stat_here()

checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_here() Signed-off-by: Tobin C. Harding --- scripts/checkpatch.pl | 54

[PATCH 2/4] checkpatch: add sub routine get_stat_here()

checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_here() Signed-off-by: Tobin C. Harding --- scripts/checkpatch.pl | 54 +++ 1

Re: possible deadlock in generic_file_write_iter (2)

On 12/8/2017 2:07 AM, Dmitry Vyukov wrote: On Wed, Dec 6, 2017 at 6:05 AM, Byungchul Park wrote: On 12/4/2017 5:33 PM, Jan Kara wrote: Hello, adding Peter and Byungchul to CC since the lockdep report just looks strange and cross-release seems to be involved. Guys,

[PATCH 1/4] checkpatch: add sub routine get_stat_real()

checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_real() Signed-off-by: Tobin C. Harding --- scripts/checkpatch.pl | 31 +++ 1 file

Re: possible deadlock in generic_file_write_iter (2)

On 12/8/2017 2:07 AM, Dmitry Vyukov wrote: On Wed, Dec 6, 2017 at 6:05 AM, Byungchul Park wrote: On 12/4/2017 5:33 PM, Jan Kara wrote: Hello, adding Peter and Byungchul to CC since the lockdep report just looks strange and cross-release seems to be involved. Guys, how did #5 get into the

[PATCH 1/4] checkpatch: add sub routine get_stat_real()

checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_real() Signed-off-by: Tobin C. Harding --- scripts/checkpatch.pl | 31 +++ 1 file changed, 15

Re: [PATCH v3 07/12] dt-bindings: Document the Rockchip MIPI RX D-PHY bindings

On Wed, Dec 06, 2017 at 07:19:34PM +0800, Jacob Chen wrote: > From: Jacob Chen > > Add DT bindings documentation for Rockchip MIPI D-PHY RX > > Signed-off-by: Jacob Chen > --- > .../bindings/media/rockchip-mipi-dphy.txt | 71 >

Re: [PATCH v3 07/12] dt-bindings: Document the Rockchip MIPI RX D-PHY bindings

On Wed, Dec 06, 2017 at 07:19:34PM +0800, Jacob Chen wrote: > From: Jacob Chen > > Add DT bindings documentation for Rockchip MIPI D-PHY RX > > Signed-off-by: Jacob Chen > --- > .../bindings/media/rockchip-mipi-dphy.txt | 71 > ++ > 1 file changed, 71

Re: [PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

On Thu, Dec 07, 2017 at 11:23:26PM +, Al Viro wrote: > On Fri, Dec 08, 2017 at 12:03:07AM +0100, Vasyl Gomonovych wrote: > > p could be NULL and passing into PTR_ERR > > > > Signed-off-by: Vasyl Gomonovych > > --- > > fs/seq_file.c | 4 ++-- > > 1 file changed, 2

Re: [PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

On Thu, Dec 07, 2017 at 11:23:26PM +, Al Viro wrote: > On Fri, Dec 08, 2017 at 12:03:07AM +0100, Vasyl Gomonovych wrote: > > p could be NULL and passing into PTR_ERR > > > > Signed-off-by: Vasyl Gomonovych > > --- > > fs/seq_file.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On Thu, 7 Dec 2017 16:31:23 +0300 Andrey Ryabinin wrote: > On 12/07/2017 03:49 AM, Andrew Morton wrote: > > (correcting Andrey's email address) > > > > > > From: Ding Tianhong > > Subject: lib/ubsan.c: don't handle misaligned address when

Re: [PATCH v2] ubsan: don't handle misaligned address when support unaligned access

On Thu, 7 Dec 2017 16:31:23 +0300 Andrey Ryabinin wrote: > On 12/07/2017 03:49 AM, Andrew Morton wrote: > > (correcting Andrey's email address) > > > > > > From: Ding Tianhong > > Subject: lib/ubsan.c: don't handle misaligned address when kernel supports > > unaligned access > > > > ubsan

Re: [PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

On Fri, Dec 08, 2017 at 12:03:07AM +0100, Vasyl Gomonovych wrote: > p could be NULL and passing into PTR_ERR > > Signed-off-by: Vasyl Gomonovych > --- > fs/seq_file.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/seq_file.c

Re: [PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

On Fri, Dec 08, 2017 at 12:03:07AM +0100, Vasyl Gomonovych wrote: > p could be NULL and passing into PTR_ERR > > Signed-off-by: Vasyl Gomonovych > --- > fs/seq_file.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/seq_file.c b/fs/seq_file.c > index

Re: [PATCH 0/9] media: imx: Add better OF graph support

Hi Hans, On 12/04/2017 05:44 AM, Hans Verkuil wrote: Hi Steve, On 10/28/2017 10:36 PM, Steve Longerbeam wrote: This is a set of patches that improve support for more complex OF graphs. Currently the imx-media driver only supports a single device with a single port connected directly to

Re: [PATCH 0/9] media: imx: Add better OF graph support

Hi Hans, On 12/04/2017 05:44 AM, Hans Verkuil wrote: Hi Steve, On 10/28/2017 10:36 PM, Steve Longerbeam wrote: This is a set of patches that improve support for more complex OF graphs. Currently the imx-media driver only supports a single device with a single port connected directly to

Re: [PATCH v9 01/13] Documentation: Add SLIMbus summary

Thankyou for taking time to review the patch, On 07/12/17 17:32, Jonathan Corbet wrote: On Thu, 7 Dec 2017 10:27:08 + srinivas.kandaga...@linaro.org wrote: A couple of overall comments... Documentation/driver-api/index.rst | 1 + Documentation/driver-api/slimbus/index.rst

Re: [PATCH v9 01/13] Documentation: Add SLIMbus summary

Thankyou for taking time to review the patch, On 07/12/17 17:32, Jonathan Corbet wrote: On Thu, 7 Dec 2017 10:27:08 + srinivas.kandaga...@linaro.org wrote: A couple of overall comments... Documentation/driver-api/index.rst | 1 + Documentation/driver-api/slimbus/index.rst

[GIT PULL] MD update for 4.15-rc2

Hi, Please pull some MD fixes. The notable one is a raid5-cache deadlock bug with dm-raid, others are not significant. Thanks, Shaohua The following changes since commit a0651c7fa2c088a605f63792279859608ed7f2c8: Merge tag 'powerpc-4.15-3' of

[GIT PULL] MD update for 4.15-rc2

Hi, Please pull some MD fixes. The notable one is a raid5-cache deadlock bug with dm-raid, others are not significant. Thanks, Shaohua The following changes since commit a0651c7fa2c088a605f63792279859608ed7f2c8: Merge tag 'powerpc-4.15-3' of

Re: [PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

On Fri, Dec 08, 2017 at 12:03:07AM +0100, Vasyl Gomonovych wrote: > p could be NULL and passing into PTR_ERR What makes you think this is correct? To quote the documentation: The next function to implement is called, amazingly, next(); its job is to move the iterator forward to the next

Re: [PATCH v3 06/12] dt-bindings: Document the Rockchip ISP1 bindings

On Wed, Dec 06, 2017 at 07:19:33PM +0800, Jacob Chen wrote: > From: Jacob Chen > > Add DT bindings documentation for Rockchip ISP1 > > Signed-off-by: Jacob Chen > --- > .../devicetree/bindings/media/rockchip-isp1.txt| 57 >

Re: [PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

On Fri, Dec 08, 2017 at 12:03:07AM +0100, Vasyl Gomonovych wrote: > p could be NULL and passing into PTR_ERR What makes you think this is correct? To quote the documentation: The next function to implement is called, amazingly, next(); its job is to move the iterator forward to the next

Re: [PATCH v3 06/12] dt-bindings: Document the Rockchip ISP1 bindings

On Wed, Dec 06, 2017 at 07:19:33PM +0800, Jacob Chen wrote: > From: Jacob Chen > > Add DT bindings documentation for Rockchip ISP1 > > Signed-off-by: Jacob Chen > --- > .../devicetree/bindings/media/rockchip-isp1.txt| 57 > ++ > 1 file changed, 57 insertions(+) >

Re: [PATCH 2/2] hwmon (pmbus): cffps: Add debugfs entries

On Thu, Dec 07, 2017 at 04:19:45PM -0600, Eddie James wrote: > > > On 12/07/2017 02:53 PM, Guenter Roeck wrote: > >On Thu, Dec 07, 2017 at 01:50:38PM -0600, Eddie James wrote: > >>From: "Edward A. James" > >> > >>Add debugfs entries for additional power supply data,

Re: [PATCH 2/2] hwmon (pmbus): cffps: Add debugfs entries

On Thu, Dec 07, 2017 at 04:19:45PM -0600, Eddie James wrote: > > > On 12/07/2017 02:53 PM, Guenter Roeck wrote: > >On Thu, Dec 07, 2017 at 01:50:38PM -0600, Eddie James wrote: > >>From: "Edward A. James" > >> > >>Add debugfs entries for additional power supply data, including part > >>number,

Re: [PATCH 2/5] -march=native: POPCNT support

On 12/07/17 14:41, Alexey Dobriyan wrote: > Mainline kernel can only generate "popcnt rax, rdi" instruction > with alternative masquareading as function call. Patch allows > to generate all POPCNT variations and inlines hweigth*() family of functions. > > $ objdump -dr ../obj/vmlinux |

Re: [PATCH 2/5] -march=native: POPCNT support

On 12/07/17 14:41, Alexey Dobriyan wrote: > Mainline kernel can only generate "popcnt rax, rdi" instruction > with alternative masquareading as function call. Patch allows > to generate all POPCNT variations and inlines hweigth*() family of functions. > > $ objdump -dr ../obj/vmlinux |

Re: [PATCH v2 2/6] dt: bindings: lp8860: Update DT label binding

Rob On 12/07/2017 04:45 PM, Rob Herring wrote: > On Tue, Dec 05, 2017 at 02:43:23PM -0600, Dan Murphy wrote: >> Update the lp8860 label binding to the LED >> standard as documented in >> >> Documentation/devicetree/bindings/leds/common.txt >> >> Signed-off-by: Dan Murphy >> ---

Re: [PATCH v2 2/6] dt: bindings: lp8860: Update DT label binding

Rob On 12/07/2017 04:45 PM, Rob Herring wrote: > On Tue, Dec 05, 2017 at 02:43:23PM -0600, Dan Murphy wrote: >> Update the lp8860 label binding to the LED >> standard as documented in >> >> Documentation/devicetree/bindings/leds/common.txt >> >> Signed-off-by: Dan Murphy >> --- >> >> v2 - Added

Re: [PATCH v2 1/6] dt: bindings: lp8860: Update bindings for lp8860

Rob Thanks On 12/07/2017 04:42 PM, Rob Herring wrote: > gOn Tue, Dec 05, 2017 at 02:43:22PM -0600, Dan Murphy wrote: >> Update the lp8860 bindings to fix various issues >> found. Add address-cells and size-cells, rename >> enable-gpio to enable-gpios, update the node name >> to the device name

Re: [PATCH v2 1/6] dt: bindings: lp8860: Update bindings for lp8860

Rob Thanks On 12/07/2017 04:42 PM, Rob Herring wrote: > gOn Tue, Dec 05, 2017 at 02:43:22PM -0600, Dan Murphy wrote: >> Update the lp8860 bindings to fix various issues >> found. Add address-cells and size-cells, rename >> enable-gpio to enable-gpios, update the node name >> to the device name

Re: [PATCH v2 1/6] dt: bindings: lp8860: Update bindings for lp8860

Rob On 12/07/2017 04:43 PM, Rob Herring wrote: > On Tue, Dec 05, 2017 at 02:43:22PM -0600, Dan Murphy wrote: >> Update the lp8860 bindings to fix various issues >> found. Add address-cells and size-cells, rename >> enable-gpio to enable-gpios, update the node name >> to the device name and

Re: [PATCH v2 1/6] dt: bindings: lp8860: Update bindings for lp8860

Rob On 12/07/2017 04:43 PM, Rob Herring wrote: > On Tue, Dec 05, 2017 at 02:43:22PM -0600, Dan Murphy wrote: >> Update the lp8860 bindings to fix various issues >> found. Add address-cells and size-cells, rename >> enable-gpio to enable-gpios, update the node name >> to the device name and

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

Just FYI: I sent out a v2 of this patch but in doing so I moved a few people from the "to" line to the "cc" line. For anyone who previously did not comment but still wanted to follow the discussion, here's the link to the v2 email: https://lkml.org/lkml/2017/12/7/1624 Thanks, -Maran On

Re: [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

Just FYI: I sent out a v2 of this patch but in doing so I moved a few people from the "to" line to the "cc" line. For anyone who previously did not comment but still wanted to follow the discussion, here's the link to the v2 email: https://lkml.org/lkml/2017/12/7/1624 Thanks, -Maran On

[PATCH v2] dt-bindings: Add an enable method to RISC-V

RISC-V doesn't currently specify a mechanism for enabling or disabling CPUs. Instead, we assume that all CPUs are enabled on boot, and if someone wants to save power we instead put a CPU to sleep via a WFI loop. Future systems may have an explicit mechanism for putting a CPU to sleep, so we're

[PATCH v2] dt-bindings: Add an enable method to RISC-V

RISC-V doesn't currently specify a mechanism for enabling or disabling CPUs. Instead, we assume that all CPUs are enabled on boot, and if someone wants to save power we instead put a CPU to sleep via a WFI loop. Future systems may have an explicit mechanism for putting a CPU to sleep, so we're

Re: [PATCH v8 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

Rob On 12/07/2017 04:49 PM, Rob Herring wrote: > On Tue, Dec 05, 2017 at 02:46:29PM -0600, Dan Murphy wrote: >> This adds the devicetree bindings for the LM3692x >> I2C LED string driver. >> >> Acked-by: Pavel Machek >> Signed-off-by: Dan Murphy >> --- >> >> v8 -

Re: [PATCH v8 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

Rob On 12/07/2017 04:49 PM, Rob Herring wrote: > On Tue, Dec 05, 2017 at 02:46:29PM -0600, Dan Murphy wrote: >> This adds the devicetree bindings for the LM3692x >> I2C LED string driver. >> >> Acked-by: Pavel Machek >> Signed-off-by: Dan Murphy >> --- >> >> v8 - Added address-cells and

Re: PI futexes + lock stealing woes

Julia Cartwright writes: > On Thu, Dec 07, 2017 at 08:57:59AM -0600, Gratian Crisan wrote: >> >> Peter Zijlstra writes: >> > The below compiles and boots, but is otherwise untested. Could you give >> > it a spin? >> >> Thank you! Yes, I'll start a test now. > > I gave it a spin with my minimal

Re: PI futexes + lock stealing woes

Julia Cartwright writes: > On Thu, Dec 07, 2017 at 08:57:59AM -0600, Gratian Crisan wrote: >> >> Peter Zijlstra writes: >> > The below compiles and boots, but is otherwise untested. Could you give >> > it a spin? >> >> Thank you! Yes, I'll start a test now. > > I gave it a spin with my minimal

[PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

p could be NULL and passing into PTR_ERR Signed-off-by: Vasyl Gomonovych --- fs/seq_file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/seq_file.c b/fs/seq_file.c index 4be761c..8b700b9 100644 --- a/fs/seq_file.c +++ b/fs/seq_file.c @@ -262,8

[PATCH] fs/seq_file: Fix warning of passing zero to 'PTR_ERR'

p could be NULL and passing into PTR_ERR Signed-off-by: Vasyl Gomonovych --- fs/seq_file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/seq_file.c b/fs/seq_file.c index 4be761c..8b700b9 100644 --- a/fs/seq_file.c +++ b/fs/seq_file.c @@ -262,8 +262,8 @@ ssize_t

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Tue, Dec 05, 2017 at 11:27:58AM +0100, Pavel Machek wrote: > Hi! > > > > Our ability to determine that userland hasn't been tampered with > > > depends on the kernel being trustworthy. If userland can upload > > > arbitrary firmware to DMA-capable devices then we can no longer trust > > > the

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Tue, Dec 05, 2017 at 11:27:58AM +0100, Pavel Machek wrote: > Hi! > > > > Our ability to determine that userland hasn't been tampered with > > > depends on the kernel being trustworthy. If userland can upload > > > arbitrary firmware to DMA-capable devices then we can no longer trust > > > the

Re: [PATCH] doc: convert printk-formats.txt to rst

On Thu, 7 Dec 2017 14:50:42 -0800 Kees Cook wrote: > > +These guides contain general information useful when writing kernel code. > > + > > +.. toctree:: > > + :maxdepth: 1 > > + > > + printk-formats > > I actually think this belongs in the kernel core API

Re: [PATCH] doc: convert printk-formats.txt to rst

On Thu, 7 Dec 2017 14:50:42 -0800 Kees Cook wrote: > > +These guides contain general information useful when writing kernel code. > > + > > +.. toctree:: > > + :maxdepth: 1 > > + > > + printk-formats > > I actually think this belongs in the kernel core API documentation > list

Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations

Roman, On Thu, Dec 7, 2017 at 11:23 PM, Jakub Kicinski wrote: > On Thu, 7 Dec 2017 18:39:09 +, Roman Gushchin wrote: >> This patch adds basic cgroup bpf operations to bpftool: >> cgroup list, attach and detach commands. >> >> Usage is described in the

Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations

Roman, On Thu, Dec 7, 2017 at 11:23 PM, Jakub Kicinski wrote: > On Thu, 7 Dec 2017 18:39:09 +, Roman Gushchin wrote: >> This patch adds basic cgroup bpf operations to bpftool: >> cgroup list, attach and detach commands. >> >> Usage is described in the corresponding man pages, >> and examples

Re: [PATCH] libsas: flush pending destruct work in sas_unregister_domain_devices()

On Thu, Dec 7, 2017 at 5:37 AM, John Garry wrote: > On 28/11/2017 17:04, Cong Wang wrote: >> >> I don't understand, the only caller of sas_unregister_domain_devices() >> is sas_deform_port(). >> > > And sas_deform_port() may be called from another worker on the same queue,

Re: [PATCH] libsas: flush pending destruct work in sas_unregister_domain_devices()

On Thu, Dec 7, 2017 at 5:37 AM, John Garry wrote: > On 28/11/2017 17:04, Cong Wang wrote: >> >> I don't understand, the only caller of sas_unregister_domain_devices() >> is sas_deform_port(). >> > > And sas_deform_port() may be called from another worker on the same queue, > right? As in

[PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues

There is nothing that says that number of TX queues == number of RX queues. E.g. the ARTPEC-6 SoC has 2 TX queues and 1 RX queue. This code is obviously wrong: for (chan = 0; chan < tx_channel_count; chan++) { struct stmmac_rx_queue *rx_q = >rx_queue[chan]; priv->rx_queue has size

[PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues

There is nothing that says that number of TX queues == number of RX queues. E.g. the ARTPEC-6 SoC has 2 TX queues and 1 RX queue. This code is obviously wrong: for (chan = 0; chan < tx_channel_count; chan++) { struct stmmac_rx_queue *rx_q = >rx_queue[chan]; priv->rx_queue has size

Re: [PATCH] clk: qcom: gcc-msm8996: always enable aggre0_noc gdsc

On 12/07, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > bus clks which depend on this gdsc are marked as critical, > so this patch flags this gdsc ALWAYS_ON so that bus clks status > does not get stuck at on or off. > > Signed-off-by:

Re: [PATCH] clk: qcom: gcc-msm8996: always enable aggre0_noc gdsc

On 12/07, srinivas.kandaga...@linaro.org wrote: > From: Srinivas Kandagatla > > bus clks which depend on this gdsc are marked as critical, > so this patch flags this gdsc ALWAYS_ON so that bus clks status > does not get stuck at on or off. > > Signed-off-by: Srinivas Kandagatla > --- >

Re: [PATCH] doc: convert printk-formats.txt to rst

On Tue, Dec 5, 2017 at 5:45 PM, Tobin C. Harding wrote: > Documentation/printk-formats.txt is a candidate for conversion to > ReStructuredText format. Some effort has already been made to do this > conversion even thought the suffix is currently .txt > > Changes required to

Re: [PATCH] doc: convert printk-formats.txt to rst

On Tue, Dec 5, 2017 at 5:45 PM, Tobin C. Harding wrote: > Documentation/printk-formats.txt is a candidate for conversion to > ReStructuredText format. Some effort has already been made to do this > conversion even thought the suffix is currently .txt > > Changes required to complete conversion >

Re: [PATCH] dt-bindings: at24/eeprom: add an undocumented compatible string

On Wed, Dec 06, 2017 at 11:12:19AM +0100, Bartosz Golaszewski wrote: > The "atmel,sdp" compatible is reported by checkpatch as undocumented. > > Add it to the device tree bindings document for at24. > > Signed-off-by: Bartosz Golaszewski > --- >

Re: [PATCH] dt-bindings: at24/eeprom: add an undocumented compatible string

On Wed, Dec 06, 2017 at 11:12:19AM +0100, Bartosz Golaszewski wrote: > The "atmel,sdp" compatible is reported by checkpatch as undocumented. > > Add it to the device tree bindings document for at24. > > Signed-off-by: Bartosz Golaszewski > --- >

Re: [PATCH v8 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On Tue, Dec 05, 2017 at 02:46:29PM -0600, Dan Murphy wrote: > This adds the devicetree bindings for the LM3692x > I2C LED string driver. > > Acked-by: Pavel Machek > Signed-off-by: Dan Murphy > --- > > v8 - Added address-cells and size-cells as well as child node

Re: [PATCH v8 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On Tue, Dec 05, 2017 at 02:46:29PM -0600, Dan Murphy wrote: > This adds the devicetree bindings for the LM3692x > I2C LED string driver. > > Acked-by: Pavel Machek > Signed-off-by: Dan Murphy > --- > > v8 - Added address-cells and size-cells as well as child node reg - >

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