Re: [PATCH/RFC] iio: hi8435: do not enable all events by default

>> Still, isn't there subsystem-level default that all events are disabled >> by default? If such, then current hi8435 state breaks subsystem-level >> rules, which is a [userspace-visible] bug. I'm not sure how far should >> we go in bug compatibility. > > It is indeed the subsystem default (as

Re: [PATCH/RFC] iio: hi8435: do not enable all events by default

>> Still, isn't there subsystem-level default that all events are disabled >> by default? If such, then current hi8435 state breaks subsystem-level >> rules, which is a [userspace-visible] bug. I'm not sure how far should >> we go in bug compatibility. > > It is indeed the subsystem default (as

Re: [PATCH] ubifs: Add freeze support

On Mon, May 29, 2017 at 7:40 AM, Hyunchul Lee wrote: > > and I missed the following case. > > in some embedded systems, clean-up for shutdown should be fast. > during this clean-up, freeze file system to guarantee integrity. > umount with MNT_DETACH is not suitable because of

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

Hi Linus, After merging the gpio tree, today's linux-next build (arm orion5x_defconfig) failed like this: drivers/gpio/gpio-mvebu.c:1062: undefined reference to `__devm_regmap_init_mmio_clk' drivers/gpio/gpio-mvebu.c:1078: undefined reference to `__devm_regmap_init_mmio_clk' Caused by commit

Re: [PATCH] ubifs: Add freeze support

On Mon, May 29, 2017 at 7:40 AM, Hyunchul Lee wrote: > > and I missed the following case. > > in some embedded systems, clean-up for shutdown should be fast. > during this clean-up, freeze file system to guarantee integrity. > umount with MNT_DETACH is not suitable because of not killing tasks. >

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

Hi Linus, After merging the gpio tree, today's linux-next build (arm orion5x_defconfig) failed like this: drivers/gpio/gpio-mvebu.c:1062: undefined reference to `__devm_regmap_init_mmio_clk' drivers/gpio/gpio-mvebu.c:1078: undefined reference to `__devm_regmap_init_mmio_clk' Caused by commit

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

Reza Arbab writes: > On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote: >>Reza Arbab writes: >> >>> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote: The commit message for 3af229f2071f says: In

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

Reza Arbab writes: > On Fri, May 26, 2017 at 01:46:58PM +1000, Michael Ellerman wrote: >>Reza Arbab writes: >> >>> On Thu, May 25, 2017 at 04:19:53PM +1000, Michael Ellerman wrote: The commit message for 3af229f2071f says: In practice, we never see a system with 256 NUMA nodes,

[PATCH v2] mm: introduce MADV_RESET_HUGEPAGE

Currently applications can explicitly enable or disable THP for a memory region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of these advises is used, the region will always have VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags. The MADV_RESET_HUGEPAGE resets both these flags

[PATCH v2] mm: introduce MADV_RESET_HUGEPAGE

Currently applications can explicitly enable or disable THP for a memory region using MADV_HUGEPAGE or MADV_NOHUGEPAGE. However, once either of these advises is used, the region will always have VM_HUGEPAGE/VM_NOHUGEPAGE flag set in vma->vm_flags. The MADV_RESET_HUGEPAGE resets both these flags

[PATCH] Input: synaptics - clear device info before filling in

From: Eric Biggers synaptics_query_hardware() was being passed a 'struct synaptics_device_info' in uninitialized stack memory, then not always initializing all fields. This caused garbage to show up in certain fields, making the touchpad unusable. Fix by zeroing the device

[PATCH] Input: synaptics - clear device info before filling in

From: Eric Biggers synaptics_query_hardware() was being passed a 'struct synaptics_device_info' in uninitialized stack memory, then not always initializing all fields. This caused garbage to show up in certain fields, making the touchpad unusable. Fix by zeroing the device info, so all fields

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

Rob Landley writes: > On 05/25/2017 04:24 PM, Stephen Rothwell wrote: >> Hi Michael, >> >> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman >> wrote: >>> >>> It'll be: >>> >>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT") >>

Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

Rob Landley writes: > On 05/25/2017 04:24 PM, Stephen Rothwell wrote: >> Hi Michael, >> >> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman >> wrote: >>> >>> It'll be: >>> >>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT") >> >> And Andrew has asked me to drop that

Re: [PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Rafael, On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote: > On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote: >> While deferring the probe of IOMMU masters, xlate and >> add_device callbacks called from iort_iommu_configure >> can pass back error values like -ENODEV, which means >> the

Re: [PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Rafael, On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote: > On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote: >> While deferring the probe of IOMMU masters, xlate and >> add_device callbacks called from iort_iommu_configure >> can pass back error values like -ENODEV, which means >> the

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

Oops, sent last one without patch on accident. Attached this time. This has been happening for me since 4.10 dquot_writeback_dquots expects a lock to be held on super_block->s_umount , and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not obtain such a lock. Thus, the following

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

Oops, sent last one without patch on accident. Attached this time. This has been happening for me since 4.10 dquot_writeback_dquots expects a lock to be held on super_block->s_umount , and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not obtain such a lock. Thus, the following

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

This has been happening for me since 4.10 dquot_writeback_dquots expects a lock to be held on super_block->s_umount , and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not obtain such a lock. Thus, the following warning is generated: [Sun May 28 04:58:06 2017] [ cut

[PATCH 1/1] - Fix reiserfs WARNING in dquot_writeback_dquots

This has been happening for me since 4.10 dquot_writeback_dquots expects a lock to be held on super_block->s_umount , and reiserfs_sync_fs, which calls dquot_writeback_dquots, does not obtain such a lock. Thus, the following warning is generated: [Sun May 28 04:58:06 2017] [ cut

[PATCH V5] hwmon: (ibmpowernv) Add highest/lowest attributes to sensors

OCC provides historical minimum and maximum value for the sensor readings. This patch exports them as highest and lowest attributes for the inband sensors copied by OCC to main memory. Signed-off-by: Shilpasri G Bhat --- Changes from V4: - Got rid of 'len'

[PATCH V5] hwmon: (ibmpowernv) Add highest/lowest attributes to sensors

OCC provides historical minimum and maximum value for the sensor readings. This patch exports them as highest and lowest attributes for the inband sensors copied by OCC to main memory. Signed-off-by: Shilpasri G Bhat --- Changes from V4: - Got rid of 'len' variable in populate_attr_groups

Re: [PATCH] ubifs: Add freeze support

and I missed the following case. in some embedded systems, clean-up for shutdown should be fast. during this clean-up, freeze file system to guarantee integrity. umount with MNT_DETACH is not suitable because of not killing tasks. On Mon, May 29, 2017 at 10:18:34AM +0900, Hyunchul Lee wrote: >

Re: [PATCH] ubifs: Add freeze support

and I missed the following case. in some embedded systems, clean-up for shutdown should be fast. during this clean-up, freeze file system to guarantee integrity. umount with MNT_DETACH is not suitable because of not killing tasks. On Mon, May 29, 2017 at 10:18:34AM +0900, Hyunchul Lee wrote: >

[PATCH] pinctrl: xway: fix copy/paste error in xrx200_grps

Signed-off-by: Martin Schiller --- drivers/pinctrl/pinctrl-xway.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c index d4167e2..f9e98a7 100644 --- a/drivers/pinctrl/pinctrl-xway.c +++

[PATCH] pinctrl: xway: fix copy/paste error in xrx200_grps

Signed-off-by: Martin Schiller --- drivers/pinctrl/pinctrl-xway.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-xway.c b/drivers/pinctrl/pinctrl-xway.c index d4167e2..f9e98a7 100644 --- a/drivers/pinctrl/pinctrl-xway.c +++

Re: [PATCH] spi: add null check before pointer dereference

Hi Gustavo, > desc = dmaengine_prep_slave_sg(dma->ch, sgt->sgl, sgt->nents, > dma->direction, DMA_PREP_INTERRUPT); > > + if (!desc) { > + dev_err(>master->dev, > + "%s:dmaengine_prep_slave_sg Failed\n", __func__); >

Re: [PATCH] spi: add null check before pointer dereference

Hi Gustavo, > desc = dmaengine_prep_slave_sg(dma->ch, sgt->sgl, sgt->nents, > dma->direction, DMA_PREP_INTERRUPT); > > + if (!desc) { > + dev_err(>master->dev, > + "%s:dmaengine_prep_slave_sg Failed\n", __func__); >

linux-next: Tree for May 29

Hi all, Changes since 20170526: Non-merge commits (relative to Linus' tree): 2862 3154 files changed, 118750 insertions(+), 64872 deletions(-) I have created today's linux-next tree at

linux-next: Tree for May 29

Hi all, Changes since 20170526: Non-merge commits (relative to Linus' tree): 2862 3154 files changed, 118750 insertions(+), 64872 deletions(-) I have created today's linux-next tree at

Re: [PATCH v3 1/2] mmc: dw_mmc: Use device_property_read instead of of_property_read

On 05/27/2017 06:53 AM, David Woods wrote: > Using the device_property interfaces allows the dw_mmc driver to work > on platforms which run on either device tree or ACPI. > > Signed-off-by: David Woods > Reviewed-by: Chris Metcalf > Cc:

Re: [PATCH v3 1/2] mmc: dw_mmc: Use device_property_read instead of of_property_read

On 05/27/2017 06:53 AM, David Woods wrote: > Using the device_property interfaces allows the dw_mmc driver to work > on platforms which run on either device tree or ACPI. > > Signed-off-by: David Woods > Reviewed-by: Chris Metcalf > Cc: sta...@vger.linux.org Acked-by: Jaehoon Chung Best

Re: [PATCH v3 0/4] Add support for ThunderX2 pmu events using json files

Any further review comments on this patch series? can it go in 4.13? On Tue, May 16, 2017 at 2:03 PM, Ganapatrao Kulkarni wrote: > Extending json/jevent framework for parsing arm64 event files. > Adding jevents for ThunderX2 implementation defined PMU events. > >

Re: [PATCH v3 0/4] Add support for ThunderX2 pmu events using json files

Any further review comments on this patch series? can it go in 4.13? On Tue, May 16, 2017 at 2:03 PM, Ganapatrao Kulkarni wrote: > Extending json/jevent framework for parsing arm64 event files. > Adding jevents for ThunderX2 implementation defined PMU events. > > v3: >- Addressed comments

[PATCH] Top Makefile: tiny correction on `make help`

The help info of `make -C=1` is little confusing, make it clear. Signed-off-by: Cao jin --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index efa267a..b34a34d 100644 --- a/Makefile +++ b/Makefile @@ -1417,7 +1417,7

[PATCH] Top Makefile: tiny correction on `make help`

The help info of `make -C=1` is little confusing, make it clear. Signed-off-by: Cao jin --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index efa267a..b34a34d 100644 --- a/Makefile +++ b/Makefile @@ -1417,7 +1417,7 @@ help: @echo '

Re: [RESEND PATCH 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver

Hi Mark, Will, can you please review this patchset? On Wed, May 17, 2017 at 12:30 PM, Ganapatrao Kulkarni wrote: > This adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices. > The SoC has PMU support in its L3 cache controller (L3C) and in the > DDR4 Memory

Re: [RESEND PATCH 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver

Hi Mark, Will, can you please review this patchset? On Wed, May 17, 2017 at 12:30 PM, Ganapatrao Kulkarni wrote: > This adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices. > The SoC has PMU support in its L3 cache controller (L3C) and in the > DDR4 Memory Controller (DMC). > > Ganapatrao

RE: [PATCH v1 1/1] intel_telemetry_debugfs: fix oops found while load/unload module test

Thanks for catching this. BR, Souvik > -Original Message- > From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver- > x86-ow...@vger.kernel.org] On Behalf Of priyalee.kushw...@intel.com > Sent: Saturday, May 27, 2017 8:48 PM > To: dvh...@infradead.org; Chakravarty,

RE: [PATCH v1 1/1] intel_telemetry_debugfs: fix oops found while load/unload module test

Thanks for catching this. BR, Souvik > -Original Message- > From: platform-driver-x86-ow...@vger.kernel.org [mailto:platform-driver- > x86-ow...@vger.kernel.org] On Behalf Of priyalee.kushw...@intel.com > Sent: Saturday, May 27, 2017 8:48 PM > To: dvh...@infradead.org; Chakravarty,

[PATCH] Fixed hwmon_register_device() error regression

Signed-off-by: Josh Benson --- drivers/thermal/thermal_hwmon.c | 20 +++- 1 file changed, 3 insertions(+), 17 deletions(-) diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c index 541af5946203..c4a508a124dc 100644 ---

[PATCH] Fixed hwmon_register_device() error regression

Signed-off-by: Josh Benson --- drivers/thermal/thermal_hwmon.c | 20 +++- 1 file changed, 3 insertions(+), 17 deletions(-) diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c index 541af5946203..c4a508a124dc 100644 --- a/drivers/thermal/thermal_hwmon.c

Re: [PATCH] ubifs: Add freeze support

Hi, Richard. On Mon, May 29, 2017 at 09:43:46AM +0900, Hyunchul Lee wrote: > On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote: > > > +static int ubifs_freeze_super(struct super_block *sb) > > > +{ > > > + struct ubifs_info *c = sb->s_fs_info; > > > + int err; > > > + > > > +

Re: [PATCH] ubifs: Add freeze support

Hi, Richard. On Mon, May 29, 2017 at 09:43:46AM +0900, Hyunchul Lee wrote: > On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote: > > > +static int ubifs_freeze_super(struct super_block *sb) > > > +{ > > > + struct ubifs_info *c = sb->s_fs_info; > > > + int err; > > > + > > > +

[PATCH v2] spin loop primitives for busy waiting

Current busy-wait loops are implemented by repeatedly calling cpu_relax() to give an arch option for a low-latency option to improve power and/or SMT resource contention. This poses some difficulties for powerpc, which has SMT priority setting instructions (priorities determine how ifetch cycles

[PATCH v2] spin loop primitives for busy waiting

Current busy-wait loops are implemented by repeatedly calling cpu_relax() to give an arch option for a low-latency option to improve power and/or SMT resource contention. This poses some difficulties for powerpc, which has SMT priority setting instructions (priorities determine how ifetch cycles

Re: [PATCH] drivers/watchdog/Kconfig: Update CONFIG_WATCHDOG_RTAS dependencies

Guenter Roeck writes: > On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote: >> drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c, >> which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without >> setting CONFIG_PPC_RTAS throws

Re: [PATCH] drivers/watchdog/Kconfig: Update CONFIG_WATCHDOG_RTAS dependencies

Guenter Roeck writes: > On 05/26/2017 06:22 PM, Murilo Opsfelder Araujo wrote: >> drivers/watchdog/wdrtas.c uses symbols defined in arch/powerpc/kernel/rtas.c, >> which are exported iff CONFIG_PPC_RTAS is selected. Building wdrtas.c without >> setting CONFIG_PPC_RTAS throws the following errors:

[no subject]

hi Linux http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2 Yours Dennis

[no subject]

hi Linux http://www.retirodecasais.novidadedevida.com.br/poll_success.php?rule=266d8zbvkqkdm2 Yours Dennis

Re: [PATCH] ubifs: Add freeze support

Hi, Richard. On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote: > Hyunchul, > > Am 26.05.2017 um 01:30 schrieb Hyunchul Lee: > > From: Hyunchul Lee > > > > for un/freeze support, implement freeze_super and un/freeze_fs > > of super_operations. > >

Re: [PATCH] ubifs: Add freeze support

Hi, Richard. On Fri, May 26, 2017 at 11:52:42AM +0200, Richard Weinberger wrote: > Hyunchul, > > Am 26.05.2017 um 01:30 schrieb Hyunchul Lee: > > From: Hyunchul Lee > > > > for un/freeze support, implement freeze_super and un/freeze_fs > > of super_operations. > > ubifs_freeze_super just calls

[PATCH] zram: clean up duplicated codes in __zram_bvec_write

__zram_bvec_write has some of duplicated logic for zram meta data handling of same_page|dedup_page|compressed_page. This patch aims to clean it up without behavior change. Cc: Sergey Senozhatsky Signed-off-by: Minchan Kim ---

[PATCH] zram: clean up duplicated codes in __zram_bvec_write

__zram_bvec_write has some of duplicated logic for zram meta data handling of same_page|dedup_page|compressed_page. This patch aims to clean it up without behavior change. Cc: Sergey Senozhatsky Signed-off-by: Minchan Kim --- drivers/block/zram/zram_drv.c | 70

Re: [PATCH] ubifs: Add freeze support

On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote: > > +static int ubifs_freeze_super(struct super_block *sb) > > +{ > > + struct ubifs_info *c = sb->s_fs_info; > > + int err; > > + > > + dbg_gen("starting"); > > + /* freeze_super always succeeds if file system is in

Re: [PATCH] ubifs: Add freeze support

On Sat, May 27, 2017 at 01:23:38AM -0700, Christoph Hellwig wrote: > > +static int ubifs_freeze_super(struct super_block *sb) > > +{ > > + struct ubifs_info *c = sb->s_fs_info; > > + int err; > > + > > + dbg_gen("starting"); > > + /* freeze_super always succeeds if file system is in

Re: [PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

Hi Wolfram Thankyou for the fixup On 28/05/17 18:30, Wolfram Sang wrote: > It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. > > Signed-off-by: Wolfram Sang Acked-by: Kieran Bingham

Re: [PATCH 7/7] [media] v4l: rcar_fdp1: use proper name for the R-Car SoC

Hi Wolfram Thankyou for the fixup On 28/05/17 18:30, Wolfram Sang wrote: > It is 'R-Car', not 'RCar'. No code or binding changes, only descriptive text. > > Signed-off-by: Wolfram Sang Acked-by: Kieran Bingham Mauro, I'll leave this for you to pick up when you're ready. Thanks Kieran >

Linux 4.12-rc3

Hey, things continue to look good, and rc3 isn't even very big. I'm hoping there's not another shoe about to drop, but so far this really feels like a nice calm release cycle, despite the size of the merge window. Knock wood. Anyway, rc3 has a little bit of everything. The biggest single change

Linux 4.12-rc3

Hey, things continue to look good, and rc3 isn't even very big. I'm hoping there's not another shoe about to drop, but so far this really feels like a nice calm release cycle, despite the size of the merge window. Knock wood. Anyway, rc3 has a little bit of everything. The biggest single change

Re: [PATCH] PCI: Move test of INTx masking to pci_setup_device

On Fri, May 26, 2017 at 10:02:25PM +0100, Piotr Gregor wrote: > The test for INTx masking via config space command performed > in pci_intx_mask_supported() should be performed before PCI device > can be used. This is to avoid reading/writing of PCI_COMMAND_INTX_DISABLE > register which may collide

Re: [PATCH] PCI: Move test of INTx masking to pci_setup_device

On Fri, May 26, 2017 at 10:02:25PM +0100, Piotr Gregor wrote: > The test for INTx masking via config space command performed > in pci_intx_mask_supported() should be performed before PCI device > can be used. This is to avoid reading/writing of PCI_COMMAND_INTX_DISABLE > register which may collide

Re: [PATCH 0/2] blackfin: Remove dead DSA code

On 01/01/2017 02:42 PM, Florian Fainelli wrote: > Hi all, > > This patch series removes dead DSA code in the blackfin board specific > code. There is no in tree driver for the KSZ8893M, and clearly this > would not compile anymore. > > Preparatory patch to help remove the legacy DSA platform

Re: [PATCH 0/2] blackfin: Remove dead DSA code

On 01/01/2017 02:42 PM, Florian Fainelli wrote: > Hi all, > > This patch series removes dead DSA code in the blackfin board specific > code. There is no in tree driver for the KSZ8893M, and clearly this > would not compile anymore. > > Preparatory patch to help remove the legacy DSA platform

Re: [PATCH] JFS: do not ignore return code from write_one_page()

Hi Andrew, On Fri, 26 May 2017 23:36:00 -0700 Andrew Morton wrote: > > On Fri, 26 May 2017 15:48:51 -0500 Dave Kleikamp > wrote: > > > Andrew, > > > > Do you want to pick this up into akpm-current? I could push it through > > the jfs

Re: [PATCH] JFS: do not ignore return code from write_one_page()

Hi Andrew, On Fri, 26 May 2017 23:36:00 -0700 Andrew Morton wrote: > > On Fri, 26 May 2017 15:48:51 -0500 Dave Kleikamp > wrote: > > > Andrew, > > > > Do you want to pick this up into akpm-current? I could push it through > > the jfs tree, but without the change to write_one_page(), my

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev wrote: > So what about a middle ground where CoW semantics are used to enforce > the state of these allocations as RO, but provide a strictly > controlled pathway to read the RO data, copy and modify it, then write > and

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

On Sun, May 28, 2017 at 11:56 AM, Boris Lukashev wrote: > So what about a middle ground where CoW semantics are used to enforce > the state of these allocations as RO, but provide a strictly > controlled pathway to read the RO data, copy and modify it, then write > and seal into a new allocation.

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa wrote: > Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon > registration.") treats "struct security_hook_heads" as an implicit array > of "struct list_head" so that we can eliminate code for static

Re: [PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

On Sun, May 28, 2017 at 1:29 PM, Tetsuo Handa wrote: > Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon > registration.") treats "struct security_hook_heads" as an implicit array > of "struct list_head" so that we can eliminate code for static > initialization. Although we

Re: [PATCH] iio: adc: meson-saradc: use NULL instead of 0 for pointer

Hi Paolo, Hi Jonathan, On Sun, May 28, 2017 at 4:43 PM, Jonathan Cameron wrote: > On Sun, 28 May 2017 13:24:38 +0200 > Paolo Cretaro wrote: > >> Fix sparse warning: Using plain integer as NULL pointer >> >> Signed-off-by: Paolo Cretaro

Re: [PATCH] iio: adc: meson-saradc: use NULL instead of 0 for pointer

Hi Paolo, Hi Jonathan, On Sun, May 28, 2017 at 4:43 PM, Jonathan Cameron wrote: > On Sun, 28 May 2017 13:24:38 +0200 > Paolo Cretaro wrote: > >> Fix sparse warning: Using plain integer as NULL pointer >> >> Signed-off-by: Paolo Cretaro > This looks fine to me, but ideally you should always try

Re: [PATCH v4 9/9] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

Hi Sean, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.12-rc2 next-20170526] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v4 9/9] arm: dts: mt7623: add dts file for Bananapi R2 (BPI-R2) board

Hi Sean, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.12-rc2 next-20170526] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

On Wed, May 24, 2017 at 9:01 AM, Vince Weaver wrote: > > On Wed, 24 May 2017, Andi Kleen wrote: > > > > Right, I did not even consider the rdpmc, but yeah, you will get a count > > > that > > > is not relevant to the user visible event. Unless you fake it using the > >

Re: [PATCH 1/2] perf/x86/intel: enable CPU ref_cycles for GP counter

On Wed, May 24, 2017 at 9:01 AM, Vince Weaver wrote: > > On Wed, 24 May 2017, Andi Kleen wrote: > > > > Right, I did not even consider the rdpmc, but yeah, you will get a count > > > that > > > is not relevant to the user visible event. Unless you fake it using the > > > time > > > scaling

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon registration.") treats "struct security_hook_heads" as an implicit array of "struct list_head" so that we can eliminate code for static initialization. Although we haven't encountered compilers which do not treat

[PATCH v2] LSM: Convert security_hook_heads into explicit array of struct list_head

Commit 3dfc9b02864b19f4 ("LSM: Initialize security_hook_heads upon registration.") treats "struct security_hook_heads" as an implicit array of "struct list_head" so that we can eliminate code for static initialization. Although we haven't encountered compilers which do not treat

[PATCH] x86/microcode/AMD: Change load_microcode_amd()'s param to bool

From: Borislav Petkov With CONFIG_DEBUG_PREEMPT enabled, I get: BUG: using smp_processor_id() in preemptible [] code: swapper/0/1 caller is debug_smp_processor_id CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2 Call Trace: dump_stack

[PATCH] x86/microcode/AMD: Change load_microcode_amd()'s param to bool

From: Borislav Petkov With CONFIG_DEBUG_PREEMPT enabled, I get: BUG: using smp_processor_id() in preemptible [] code: swapper/0/1 caller is debug_smp_processor_id CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2 Call Trace: dump_stack check_preemption_disabled

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on > a global v2p8_gpio value rather then storing info in the gmin_subdev struct, > as such passing the subdev->dev pointer would be simply wrong. AFAICT the > v1p8 / v2p8 gpio code is the only caller passing in a NULL

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

> The code for the special v1p8 / v2p8 gpios is ugly as sin, it operates on > a global v2p8_gpio value rather then storing info in the gmin_subdev struct, > as such passing the subdev->dev pointer would be simply wrong. AFAICT the > v1p8 / v2p8 gpio code is the only caller passing in a NULL

Re: [PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

On Mon, 29 May 2017 02:06:41 +0800 Chen Guanqiao wrote: > Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings. > > Signed-off-by: Chen Guanqiao > --- Reviewed-by: Alan Cox

Re: [PATCH] staging: atomisp: lm3554: fix sparse warnings(was not declared. Should it be static?)

On Mon, 29 May 2017 02:06:41 +0800 Chen Guanqiao wrote: > Fix "symbol 'xxx' was not declared. Should it be static?" sparse warnings. > > Signed-off-by: Chen Guanqiao > --- Reviewed-by: Alan Cox

single-threaded wq lockdep is broken

Hi Tejun, I suspect this is a long-standing bug introduced by all the pool rework you did at some point, but I don't really know nor can I figure out how to fix it right now. I guess it could possibly also be a lockdep issue, or an issue in how it's used, but I definitely know that this used to

single-threaded wq lockdep is broken

Hi Tejun, I suspect this is a long-standing bug introduced by all the pool rework you did at some point, but I don't really know nor can I figure out how to fix it right now. I guess it could possibly also be a lockdep issue, or an issue in how it's used, but I definitely know that this used to

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

On Thu 2017-05-25 12:46:04, Bernd Petrovitsch wrote: > On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote: > > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote: > > > Proper fix is to introduce typed allocation macros with the following > > > signatures: > > > > > > T* lmalloc(T, gfp);

Re: [PATCH] CodingStyle: delete "kmalloc(sizeof(*var))" as preferred allocation form

On Thu 2017-05-25 12:46:04, Bernd Petrovitsch wrote: > On Thu, 2017-05-25 at 03:35 -0700, Joe Perches wrote: > > On Wed, 2017-05-24 at 13:18 +0300, Alexey Dobriyan wrote: > > > Proper fix is to introduce typed allocation macros with the following > > > signatures: > > > > > > T* lmalloc(T, gfp);

Re: [PATCH 5/5] power: supply: bq27xxx: Correct supply status with current draw

Hi! > The status reported directly by the battery controller is not always > reliable and should be corrected based on the current draw information. > > This implements such a correction with a dedicated function, called > when retrieving the supply status. > > @@ -1182,6 +1196,8 @@ static int

Re: [PATCH 5/5] power: supply: bq27xxx: Correct supply status with current draw

Hi! > The status reported directly by the battery controller is not always > reliable and should be corrected based on the current draw information. > > This implements such a correction with a dedicated function, called > when retrieving the supply status. > > @@ -1182,6 +1196,8 @@ static int

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

One-time sealable memory makes the most sense from a defensive perspective - red team reads this stuff, the races mentioned will be implemented as described to win the day, and probably in other innovative ways. If a gap is left in the implementation, without explicit coverage by an adjacent

Re: [kernel-hardening] Re: [PATCH 1/1] Sealable memory support

One-time sealable memory makes the most sense from a defensive perspective - red team reads this stuff, the races mentioned will be implemented as described to win the day, and probably in other innovative ways. If a gap is left in the implementation, without explicit coverage by an adjacent

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

On Sun, May 28, 2017 at 11:18 AM, Bernhard Held wrote: > Hi, > > this patch breaks the boot of my kernel. The last message is "Booting > the kernel.". > > My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a > Gigbayte G33-DS3R board (LGA 775). The BIOS is patched

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

On Sun, May 28, 2017 at 11:18 AM, Bernhard Held wrote: > Hi, > > this patch breaks the boot of my kernel. The last message is "Booting > the kernel.". > > My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a > Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the >

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

Hi, this patch breaks the boot of my kernel. The last message is "Booting the kernel.". My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the microcode of the E5450 and recognizes the CPU. Please find below the dmesg

Re: [tip:x86/urgent] x86/PAT: Fix Xorg regression on CPUs that don't support PAT

Hi, this patch breaks the boot of my kernel. The last message is "Booting the kernel.". My setup might be unusual: I'm running a Xenon E5450 (LGA 771) in a Gigbayte G33-DS3R board (LGA 775). The BIOS is patched with the microcode of the E5450 and recognizes the CPU. Please find below the dmesg

Re: [PATCH] clocksource: moxart: Add AST2500 compatible string

On 28/05/2017 15:59, Linus Walleij wrote: > On Tue, May 16, 2017 at 9:58 AM, Andrew Jeffery wrote: > >> Also clean up space-before-tab issues in the documentation. >> >> Signed-off-by: Andrew Jeffery > > Reviewed-by: Linus Walleij >

Re: [PATCH] clocksource: moxart: Add AST2500 compatible string

On 28/05/2017 15:59, Linus Walleij wrote: > On Tue, May 16, 2017 at 9:58 AM, Andrew Jeffery wrote: > >> Also clean up space-before-tab issues in the documentation. >> >> Signed-off-by: Andrew Jeffery > > Reviewed-by: Linus Walleij > > Does this collide with Daniel's 2500 patch? > > Sorry

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

Hi, On 28-05-17 19:08, Alan Cox wrote: On Sun, 28 May 2017 14:30:35 +0200 Hans de Goede wrote: Do not call dev_warn with a NULL device, this silence the following 2 warnings: [ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO [ 14.392257] (NULL

Re: [PATCH v5 2/7] staging: atomisp: Do not call dev_warn with a NULL device

Hi, On 28-05-17 19:08, Alan Cox wrote: On Sun, 28 May 2017 14:30:35 +0200 Hans de Goede wrote: Do not call dev_warn with a NULL device, this silence the following 2 warnings: [ 14.392194] (NULL device *): Failed to find gmin variable gmin_V2P8GPIO [ 14.392257] (NULL device *): Failed to

  1   2   3   4   5   >