[PATCH v2 2/2] f2fs: introduce CP_TRIMMED_FLAG to avoid unneeded discard

Introduce CP_TRIMMED_FLAG to indicate all invalid block were trimmed before umount, so once we do mount with image which contain the flag, we don't record invalid blocks as undiscard one, when fstrim is being triggered, we can avoid issuing redundant discard commands. Signed-off-by: Chao Yu

[PATCH v2 2/2] f2fs: introduce CP_TRIMMED_FLAG to avoid unneeded discard

Introduce CP_TRIMMED_FLAG to indicate all invalid block were trimmed before umount, so once we do mount with image which contain the flag, we don't record invalid blocks as undiscard one, when fstrim is being triggered, we can avoid issuing redundant discard commands. Signed-off-by: Chao Yu

Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta

Hi Ralph, On 4/27/2017 8:10 PM, Ralph Sennhauser wrote: > On Thu, 27 Apr 2017 19:05:09 +0530 > Sricharan R wrote: > >> Hi, >> >> On 4/26/2017 9:45 PM, Ralph Sennhauser wrote: >>> Hi Sricharan R, >>> >>> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe

Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta

Hi Ralph, On 4/27/2017 8:10 PM, Ralph Sennhauser wrote: > On Thu, 27 Apr 2017 19:05:09 +0530 > Sricharan R wrote: > >> Hi, >> >> On 4/26/2017 9:45 PM, Ralph Sennhauser wrote: >>> Hi Sricharan R, >>> >>> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe >>> time for

Re: [PATCH] fs: Handle register_shrinker failure

On Fri, Apr 28, 2017 at 05:30:46AM +0100, Al Viro wrote: > I really don't like that. Your "remove it from all lists and pray that > nobody has picked a reference of any kind" at the very least needs a careful > written proof of correctness. AFAICS, somebody might've found it on the > list and

Re: [PATCH] fs: Handle register_shrinker failure

On Fri, Apr 28, 2017 at 05:30:46AM +0100, Al Viro wrote: > I really don't like that. Your "remove it from all lists and pray that > nobody has picked a reference of any kind" at the very least needs a careful > written proof of correctness. AFAICS, somebody might've found it on the > list and

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/17 at 08:52am, Dave Hansen wrote: > On 04/27/2017 12:25 AM, Dave Young wrote: > > On 04/21/17 at 02:55pm, Dave Hansen wrote: > >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: > >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can > >>> determine if SME is active. >

Re: [PATCH v5 31/32] x86: Add sysfs support for Secure Memory Encryption

On 04/27/17 at 08:52am, Dave Hansen wrote: > On 04/27/2017 12:25 AM, Dave Young wrote: > > On 04/21/17 at 02:55pm, Dave Hansen wrote: > >> On 04/18/2017 02:22 PM, Tom Lendacky wrote: > >>> Add sysfs support for SME so that user-space utilities (kdump, etc.) can > >>> determine if SME is active. >

[PATCH v3 4/4] ACPI: Fix memory mapping leaks in current sysfs dumpable ACPI tables support

This patch adds acpi_put_table() to make all acpi_get_table() clone invocations balanced for sysfs ACPI table dump code. Since Linux does not use all of the tables, this can help to reduce some usless memory mappings. While originally, all tables will be remained to be mapped after a userspace

[PATCH v3 4/4] ACPI: Fix memory mapping leaks in current sysfs dumpable ACPI tables support

This patch adds acpi_put_table() to make all acpi_get_table() clone invocations balanced for sysfs ACPI table dump code. Since Linux does not use all of the tables, this can help to reduce some usless memory mappings. While originally, all tables will be remained to be mapped after a userspace

[PATCH v3 1/4] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

In the Linux kernel side, acpi_get_table() clones haven't been fully balanced by acpi_put_table() invocations. In ACPICA side, due to the design change, there are also unbalanced acpi_get_table_by_index() invocations requiring special care. So it is not a good timing to report acpi_get_table()

[PATCH v3 1/4] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

In the Linux kernel side, acpi_get_table() clones haven't been fully balanced by acpi_put_table() invocations. In ACPICA side, due to the design change, there are also unbalanced acpi_get_table_by_index() invocations requiring special care. So it is not a good timing to report acpi_get_table()

[PATCH v3 2/4] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

For all frequent late stage acpi_get_table() clone invocations, we should only fix them altogether, otherwise, excessive acpi_put_table() could unexpectedly unmap the table used by the other users. Thus the current plan is to fix all acpi_get_table() clones together or to fix none of them. This

[PATCH v3 3/4] ACPI: sysfs: Fix acpi_get_table() leak

From: Dan Williams Reading an ACPI table through the /sys/firmware/acpi/tables interface more than 65,536 times leads to the following log message: ACPI Error: Table 88033595eaa8, Validation count is zero after increment (20170119/tbutils-423) Add the missing

[PATCH v3 2/4] ACPICA: Tables: Add mechanism to allow to balance late stage acpi_get_table() independently

For all frequent late stage acpi_get_table() clone invocations, we should only fix them altogether, otherwise, excessive acpi_put_table() could unexpectedly unmap the table used by the other users. Thus the current plan is to fix all acpi_get_table() clones together or to fix none of them. This

[PATCH v3 3/4] ACPI: sysfs: Fix acpi_get_table() leak

From: Dan Williams Reading an ACPI table through the /sys/firmware/acpi/tables interface more than 65,536 times leads to the following log message: ACPI Error: Table 88033595eaa8, Validation count is zero after increment (20170119/tbutils-423) Add the missing acpi_put_table() so the

[PATCH v2 1/4] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

In the Linux kernel side, acpi_get_table() clones haven't been fully balanced by acpi_put_table() invocations. In ACPICA side, due to the design change, there are also unbalanced acpi_get_table_by_index() invocations requiring special care. So it is not a good timing to report acpi_get_table()

[PATCH v2 1/4] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

In the Linux kernel side, acpi_get_table() clones haven't been fully balanced by acpi_put_table() invocations. In ACPICA side, due to the design change, there are also unbalanced acpi_get_table_by_index() invocations requiring special care. So it is not a good timing to report acpi_get_table()

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Correct Vivek's email address On 04/28/17 at 01:19pm, Dave Young wrote: > Vivek, can you help to give some comments about the locate hole isssue > in kexec_file? > > On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > > Thiago, > > > > Thank you for the comment. > > > > On Thu, Apr 27, 2017 at

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Correct Vivek's email address On 04/28/17 at 01:19pm, Dave Young wrote: > Vivek, can you help to give some comments about the locate hole isssue > in kexec_file? > > On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > > Thiago, > > > > Thank you for the comment. > > > > On Thu, Apr 27, 2017 at

Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

On Thu, Apr 27, 2017 at 10:48:45AM +, Chris Brandt wrote: > Hi Geert, > > On Thursday, April 27, 2017, Geert Uytterhoeven wrote: > > > + { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <_pins>; > > > + > > > + status = "okay"; > > > + > > > +

Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

On Thu, Apr 27, 2017 at 10:48:45AM +, Chris Brandt wrote: > Hi Geert, > > On Thursday, April 27, 2017, Geert Uytterhoeven wrote: > > > + { > > > + pinctrl-names = "default"; > > > + pinctrl-0 = <_pins>; > > > + > > > + status = "okay"; > > > + > > > +

Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller

On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi > wrote: > >this is 5th round of gpio/pincontroller for RZ/A1 devices. > > > > I have updated the pin controller driver to use the

Re: [PATCH v5 00/10] Renesas RZ/A1 pin and gpio controller

On Thu, Apr 27, 2017 at 10:42:02AM +0200, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi > wrote: > >this is 5th round of gpio/pincontroller for RZ/A1 devices. > > > > I have updated the pin controller driver to use the newly introduced > >

Re: [PATCH v5 07/10] arm: dts: genmai: Add SCIF2 pin group

On Thu, Apr 27, 2017 at 10:19:51AM +0200, Jacopo Mondi wrote: > Add pin configuration subnode for SCIF2 serial debug interface. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Geert Uytterhoeven As the dt-bindings (documentation) has been

Re: [PATCH v5 07/10] arm: dts: genmai: Add SCIF2 pin group

On Thu, Apr 27, 2017 at 10:19:51AM +0200, Jacopo Mondi wrote: > Add pin configuration subnode for SCIF2 serial debug interface. > > Signed-off-by: Jacopo Mondi > Reviewed-by: Geert Uytterhoeven As the dt-bindings (documentation) has been acked by Geert I'd be happy to queue up this and other

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Vivek, can you help to give some comments about the locate hole isssue in kexec_file? On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > Thiago, > > Thank you for the comment. > > On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote: > > Hello, > > > > Am Mittwoch, 26. April

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Vivek, can you help to give some comments about the locate hole isssue in kexec_file? On 04/28/17 at 09:51am, AKASHI Takahiro wrote: > Thiago, > > Thank you for the comment. > > On Thu, Apr 27, 2017 at 07:00:04PM -0300, Thiago Jung Bauermann wrote: > > Hello, > > > > Am Mittwoch, 26. April

Re: [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header

On Thu, Apr 27, 2017 at 10:38:39AM +0200, Geert Uytterhoeven wrote: > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi > wrote: > > Add dt-bindings for Renesas r7s72100 pin controller header file. > > > > Signed-off-by: Jacopo Mondi > >

Re: [PATCH v5 05/10] arm: dts: dt-bindings: Add Renesas RZ/A1 pinctrl header

On Thu, Apr 27, 2017 at 10:38:39AM +0200, Geert Uytterhoeven wrote: > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi > wrote: > > Add dt-bindings for Renesas r7s72100 pin controller header file. > > > > Signed-off-by: Jacopo Mondi > > Reviewed-by: Geert Uytterhoeven Thanks, I have queued this

[PATCH] mnt: allow to add a mount into an existing group

Now a shared group can be only inherited from a source mount. This patch adds an ability to add a mount into an existing shared group. mount(source, target, NULL, MS_SET_GROUP, NULL) mount() with the MS_SET_GROUP flag adds the "target" mount into a group of the "source" mount. The calling

[PATCH] mnt: allow to add a mount into an existing group

Now a shared group can be only inherited from a source mount. This patch adds an ability to add a mount into an existing shared group. mount(source, target, NULL, MS_SET_GROUP, NULL) mount() with the MS_SET_GROUP flag adds the "target" mount into a group of the "source" mount. The calling

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/27/2017 08:54 PM, Khuong Dinh wrote: > From: Khuong Dinh > > This patch makes pci-xgene-msi driver ACPI-aware and provides > MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. > > Signed-off-by: Khuong Dinh > Signed-off-by: Duc Dang

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/27/2017 08:54 PM, Khuong Dinh wrote: > From: Khuong Dinh > > This patch makes pci-xgene-msi driver ACPI-aware and provides > MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. > > Signed-off-by: Khuong Dinh > Signed-off-by: Duc Dang > Acked-by: Marc Zyngier Thanks.

Re: [PATCH] xen/x86: Call xen_smp_intr_init_pv() on BSP

On 26/04/17 15:42, Boris Ostrovsky wrote: > Recent code rework that split handling ov PV, HVM and PVH guests into > separate files missed calling xen_smp_intr_init_pv() on CPU0. > > Add this call. > > Signed-off-by: Boris Ostrovsky > Reported-by: Sander Eikelenboom

Re: [PATCH] xen/x86: Call xen_smp_intr_init_pv() on BSP

On 26/04/17 15:42, Boris Ostrovsky wrote: > Recent code rework that split handling ov PV, HVM and PVH guests into > separate files missed calling xen_smp_intr_init_pv() on CPU0. > > Add this call. > > Signed-off-by: Boris Ostrovsky > Reported-by: Sander Eikelenboom Reviewed-by: Juergen Gross

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 27-04-17, 16:20, Rajendra Nayak wrote: > > On 04/27/2017 03:12 PM, Sudeep Holla wrote: > [].. > > >> > >>> At qualcomm, we have an external M3 core (running its own firmware) which > >>> controls > >>> a few voltage rails (including AVS on those). The devices vote for the > >>> voltage

Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains

On 27-04-17, 16:20, Rajendra Nayak wrote: > > On 04/27/2017 03:12 PM, Sudeep Holla wrote: > [].. > > >> > >>> At qualcomm, we have an external M3 core (running its own firmware) which > >>> controls > >>> a few voltage rails (including AVS on those). The devices vote for the > >>> voltage

[PATCH] MAINTAINERS: Update MAX77802 PMIC entry

The Samsung email address will stop working soon, so use my personal email address instead. Also, there used to be a MFD and RTC drivers for max77802 but now these have been merged with the max77686 MFD and RTC drivers. The only driver that's still max77802 specific is the regulator one since

[PATCH] MAINTAINERS: Update MAX77802 PMIC entry

The Samsung email address will stop working soon, so use my personal email address instead. Also, there used to be a MFD and RTC drivers for max77802 but now these have been merged with the max77686 MFD and RTC drivers. The only driver that's still max77802 specific is the regulator one since

[PATCH v2 4/4] perf vendor events arm64: Add implementation defined pmu core events of ThunderX2

This is not a full event list, but a short list of useful events. Signed-off-by: Ganapatrao Kulkarni --- tools/perf/pmu-events/arch/arm64/mapfile.csv | 14 + .../arm64/thunderx2/implementation-defined.json| 62 ++ 2 files

[PATCH v2 3/4] perf utils: Add helper function is_pmu_core to detect PMU CORE devices

On some platforms, PMU core devices sysfs name is not cpu. Adding function is_pmu_core to detect as core device using core device specific hints in sysfs. For arm64 platforms, all core devices have file "cpus" in sysfs. Signed-off-by: Ganapatrao Kulkarni ---

[PATCH v2 4/4] perf vendor events arm64: Add implementation defined pmu core events of ThunderX2

This is not a full event list, but a short list of useful events. Signed-off-by: Ganapatrao Kulkarni --- tools/perf/pmu-events/arch/arm64/mapfile.csv | 14 + .../arm64/thunderx2/implementation-defined.json| 62 ++ 2 files changed, 76 insertions(+) create mode

[PATCH v2 3/4] perf utils: Add helper function is_pmu_core to detect PMU CORE devices

On some platforms, PMU core devices sysfs name is not cpu. Adding function is_pmu_core to detect as core device using core device specific hints in sysfs. For arm64 platforms, all core devices have file "cpus" in sysfs. Signed-off-by: Ganapatrao Kulkarni --- tools/perf/util/pmu.c | 44

[PATCH v2 1/4] perf utils: passing pmu as a parameter to function get_cpuid_str

cpuid string will not be same on all CPUs on heterogeneous platforms like ARM's big.LITTLE, adding provision(using pmu->cpus) to find cpuid string from associated CPUs of PMU CORE device. Signed-off-by: Ganapatrao Kulkarni ---

[PATCH v2 2/4] perf tools arm64: Add support for get_cpuid_str function.

function get_cpuid_str returns MIDR string of the first online cpu from the range of cpus associated with the pmu core device. Signed-off-by: Ganapatrao Kulkarni --- tools/perf/arch/arm64/util/Build| 1 + tools/perf/arch/arm64/util/header.c | 41

[PATCH v2 1/4] perf utils: passing pmu as a parameter to function get_cpuid_str

cpuid string will not be same on all CPUs on heterogeneous platforms like ARM's big.LITTLE, adding provision(using pmu->cpus) to find cpuid string from associated CPUs of PMU CORE device. Signed-off-by: Ganapatrao Kulkarni --- tools/perf/arch/powerpc/util/header.c | 3 ++-

[PATCH v2 2/4] perf tools arm64: Add support for get_cpuid_str function.

function get_cpuid_str returns MIDR string of the first online cpu from the range of cpus associated with the pmu core device. Signed-off-by: Ganapatrao Kulkarni --- tools/perf/arch/arm64/util/Build| 1 + tools/perf/arch/arm64/util/header.c | 41 + 2

[PATCH v2 0/4] Add support for ThunderX2 pmu events using json files

Extending json/jevent framework for parsing arm64 event files. Adding jevents for ThunderX2 implementation defined PMU events. v2: - Updated as per Mark Rutland's suggestions. - added provision for get_cpuid_str to get cpu id string from associated cpus of pmu core device. v1: Initial

[PATCH v2 0/4] Add support for ThunderX2 pmu events using json files

Extending json/jevent framework for parsing arm64 event files. Adding jevents for ThunderX2 implementation defined PMU events. v2: - Updated as per Mark Rutland's suggestions. - added provision for get_cpuid_str to get cpu id string from associated cpus of pmu core device. v1: Initial

[PATCH v2] [media] vb2: Fix an off by one error in 'vb2_plane_vaddr'

We should ensure that 'plane_no' is '< vb->num_planes' as done in 'vb2_plane_cookie' just a few lines below. Cc: sta...@vger.kernel.org Fixes: e23ccc0ad925 ("[media] v4l: add videobuf2 Video for Linux 2 driver framework") Signed-off-by: Christophe JAILLET --- v2:

[PATCH v2] [media] vb2: Fix an off by one error in 'vb2_plane_vaddr'

We should ensure that 'plane_no' is '< vb->num_planes' as done in 'vb2_plane_cookie' just a few lines below. Cc: sta...@vger.kernel.org Fixes: e23ccc0ad925 ("[media] v4l: add videobuf2 Video for Linux 2 driver framework") Signed-off-by: Christophe JAILLET --- v2: add CC and Fixes tags ---

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Hi AKASHI On 04/26/17 at 05:22pm, AKASHI Takahiro wrote: > The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at > the first memory region that has enough space for requested size even if > some of higher regions may also have. > This behavior is not consistent with

Re: [PATCH] kexec: allocate buffer in top-down, if specified, correctly

Hi AKASHI On 04/26/17 at 05:22pm, AKASHI Takahiro wrote: > The current kexec_locate_mem_hole(kbuf.top_down == 1) stops searching at > the first memory region that has enough space for requested size even if > some of higher regions may also have. > This behavior is not consistent with

nvdimm/pmem device lifetime

Hi, Just wondering the pmem struct device vs gendisk lifetimes.. from pmem_attach_disk(): device_add_disk(dev, disk); devm_add_action_or_reset(dev, pmem_release_disk, disk); where: static void pmem_release_disk(void *disk) { del_gendisk(disk); put_disk(disk); }

nvdimm/pmem device lifetime

Hi, Just wondering the pmem struct device vs gendisk lifetimes.. from pmem_attach_disk(): device_add_disk(dev, disk); devm_add_action_or_reset(dev, pmem_release_disk, disk); where: static void pmem_release_disk(void *disk) { del_gendisk(disk); put_disk(disk); }

linux-next: build failure after merge of the kvm-ppc tree

Hi Paul, After merging the kvm-ppc tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kvm/book3s_xive.c: In function 'xive_debugfs_init': arch/powerpc/kvm/book3s_xive.c:1852:52: error: 'powerpc_debugfs_root' undeclared (first use in this function)

linux-next: build failure after merge of the kvm-ppc tree

Hi Paul, After merging the kvm-ppc tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kvm/book3s_xive.c: In function 'xive_debugfs_init': arch/powerpc/kvm/book3s_xive.c:1852:52: error: 'powerpc_debugfs_root' undeclared (first use in this function)

[PATCH] of: unittest, fix possible use of unitialized variable

From: Frank Rowand Fix problem reported in the linux-next build. last_sibling may be unitialized in of_unittest() if the device tree is empty. Signed-off-by: Frank Rowand --- drivers/of/unittest.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] of: unittest, fix possible use of unitialized variable

From: Frank Rowand Fix problem reported in the linux-next build. last_sibling may be unitialized in of_unittest() if the device tree is empty. Signed-off-by: Frank Rowand --- drivers/of/unittest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/unittest.c

Re: [PATCH] fs: Handle register_shrinker failure

On Fri, Mar 24, 2017 at 09:55:40AM +0200, Nikolay Borisov wrote: > register_shrinker allocates dynamic memory and thus is susceptible to failures > under low-memory situation. Currently,get_userns ignores the return value of > register_shrinker, potentially exposing not fully initialised object.

Re: [PATCH] fs: Handle register_shrinker failure

On Fri, Mar 24, 2017 at 09:55:40AM +0200, Nikolay Borisov wrote: > register_shrinker allocates dynamic memory and thus is susceptible to failures > under low-memory situation. Currently,get_userns ignores the return value of > register_shrinker, potentially exposing not fully initialised object.

Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta

Hi Ralph, On 4/27/2017 7:05 PM, Sricharan R wrote: > Hi, > > On 4/26/2017 9:45 PM, Ralph Sennhauser wrote: >> Hi Sricharan R, >> >> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time >> for platform/amba/pci bus devices") causes a kernel panic as in the log >> below on an

Re: [REGRESSION next-20170426] Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") causes oops in mvneta

Hi Ralph, On 4/27/2017 7:05 PM, Sricharan R wrote: > Hi, > > On 4/26/2017 9:45 PM, Ralph Sennhauser wrote: >> Hi Sricharan R, >> >> Commit 09515ef5ddad ("of/acpi: Configure dma operations at probe time >> for platform/amba/pci bus devices") causes a kernel panic as in the log >> below on an

Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

On 27-04-17, 09:26, Eduardo Valentin wrote: > On Wed, Apr 26, 2017 at 04:17:52PM +0530, Viresh Kumar wrote: > > On 26-04-17, 11:41, Lukasz Luba wrote: > > > Hi Viresh, > > > > > > I went through the v4 code and it looks good to me. > > > Feel free to add for the v4 series > > > Reviewed-by:

Re: [PATCH V4 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

On 27-04-17, 09:26, Eduardo Valentin wrote: > On Wed, Apr 26, 2017 at 04:17:52PM +0530, Viresh Kumar wrote: > > On 26-04-17, 11:41, Lukasz Luba wrote: > > > Hi Viresh, > > > > > > I went through the v4 code and it looks good to me. > > > Feel free to add for the v4 series > > > Reviewed-by:

[PATCH] MAINTAINERS: Remove myself as reviewer for Exynos

I left Samsung and lost access to most Exynos hardware and documentation. Also, I likely won't be able to keep an eye on the platform anymore in the short term so remove myself as a reviewer for Exynos. Signed-off-by: Javier Martinez Canillas --- MAINTAINERS | 1 - 1 file

[PATCH] MAINTAINERS: Remove myself as reviewer for Exynos

I left Samsung and lost access to most Exynos hardware and documentation. Also, I likely won't be able to keep an eye on the platform anymore in the short term so remove myself as a reviewer for Exynos. Signed-off-by: Javier Martinez Canillas --- MAINTAINERS | 1 - 1 file changed, 1

Re: [PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

On Wed, 2017-04-26 at 06:37 +0100, Jonathan Cameron wrote: > On 19/04/17 15:05, Shrirang Bagul wrote: > > This patch fixes the sensor platform data initialisation for st_pressure > > and st_accel device drivers. Without this patch, the driver fails to > > register the sensors when the user removes

Re: [PATCH] iio: st_pressure: st_accel: Initialise sensor platform data properly

On Wed, 2017-04-26 at 06:37 +0100, Jonathan Cameron wrote: > On 19/04/17 15:05, Shrirang Bagul wrote: > > This patch fixes the sensor platform data initialisation for st_pressure > > and st_accel device drivers. Without this patch, the driver fails to > > register the sensors when the user removes

RE: [PATCH v2 1/2] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

Hi, Rafael I reconsidered your comments. Seems there are several problems you might not be aware of. Let me reply again. > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: Re: [PATCH v2 1/2] ACPICA: Tables: Fix

RE: [PATCH v2 1/2] ACPICA: Tables: Fix regression introduced by a too early mechanism enabling

Hi, Rafael I reconsidered your comments. Seems there are several problems you might not be aware of. Let me reply again. > From: linux-acpi-ow...@vger.kernel.org > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. > Wysocki > Subject: Re: [PATCH v2 1/2] ACPICA: Tables: Fix

[rhashtable] 6d684e5469: Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master commit 6d684e54690caef45cf14051ddeb7c71beeb681b Author: Herbert Xu AuthorDate: Thu Apr 27 13:44:51

[rhashtable] 6d684e5469: Kernel panic - not syncing: rtnetlink_init: cannot initialize rtnetlink

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master commit 6d684e54690caef45cf14051ddeb7c71beeb681b Author: Herbert Xu AuthorDate: Thu Apr 27 13:44:51 2017 +0800 Commit: David S.

Re: [PATCH v6 2/5] firmware: add extensible driver data API

Luis, On Fri, Apr 28, 2017 at 02:51:44AM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 13, 2017 at 06:36:17PM +0900, AKASHI Takahiro wrote: > > On Wed, Mar 29, 2017 at 08:25:11PM -0700, Luis R. Rodriguez wrote: > > > Signed-off-by: Luis R. Rodriguez > > > --- > > >

Re: [PATCH v6 2/5] firmware: add extensible driver data API

Luis, On Fri, Apr 28, 2017 at 02:51:44AM +0200, Luis R. Rodriguez wrote: > On Thu, Apr 13, 2017 at 06:36:17PM +0900, AKASHI Takahiro wrote: > > On Wed, Mar 29, 2017 at 08:25:11PM -0700, Luis R. Rodriguez wrote: > > > Signed-off-by: Luis R. Rodriguez > > > --- > > >

Re: [PATCH] pstore: Solve lockdep warning by moving inode locks

Hi, On Fri, Apr 28, 2017 at 8:20 AM, Kees Cook wrote: > Lockdep complains about a possible deadlock between mount and unlink > (which is technically impossible), but fixing this improves possible > future multiple-backend support, and keeps locking in the right order. > >

Re: [PATCH] pstore: Solve lockdep warning by moving inode locks

Hi, On Fri, Apr 28, 2017 at 8:20 AM, Kees Cook wrote: > Lockdep complains about a possible deadlock between mount and unlink > (which is technically impossible), but fixing this improves possible > future multiple-backend support, and keeps locking in the right order. > > The lockdep warning

Re: perf report warnings on tracepoint events hidden by ui

Hi, On Fri, Apr 28, 2017 at 9:31 AM, David Carrillo-Cisneros wrote: > When processing tracepoint events, perf report outputs warnings about > field not founds. The warnings are usually hidden by perf report UI > and appear when using the --stdio option. e.g. Yep, currently

Re: perf report warnings on tracepoint events hidden by ui

Hi, On Fri, Apr 28, 2017 at 9:31 AM, David Carrillo-Cisneros wrote: > When processing tracepoint events, perf report outputs warnings about > field not founds. The warnings are usually hidden by perf report UI > and appear when using the --stdio option. e.g. Yep, currently perf report TUI hides

Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt

Hi James, Thanks for your explanation and suggests. On 2017/4/25 1:14, James Morse wrote: > Hi Wang Xiongfeng, > > On 21/04/17 12:33, Xiongfeng Wang wrote: >> On 2017/4/20 16:52, James Morse wrote: >>> On 19/04/17 03:37, Xiongfeng Wang wrote: On 2017/4/18 18:51, James Morse wrote: >

Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt

Hi James, Thanks for your explanation and suggests. On 2017/4/25 1:14, James Morse wrote: > Hi Wang Xiongfeng, > > On 21/04/17 12:33, Xiongfeng Wang wrote: >> On 2017/4/20 16:52, James Morse wrote: >>> On 19/04/17 03:37, Xiongfeng Wang wrote: On 2017/4/18 18:51, James Morse wrote: >

Re: [PATCH] Enabled pstore write for powerpc

Kees Cook writes: > On Thu, Apr 27, 2017 at 4:33 AM, Ankit Kumar wrote: >> After commit c950fd6f201a kernel registers pstore write based on flag set. >> Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG) is not set >> for >> powerpc

Re: [PATCH] Enabled pstore write for powerpc

Kees Cook writes: > On Thu, Apr 27, 2017 at 4:33 AM, Ankit Kumar wrote: >> After commit c950fd6f201a kernel registers pstore write based on flag set. >> Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG) is not set >> for >> powerpc architecture. On panic, kernel doesn't write

Re: perf report warnings on tracepoint events hidden by ui

On Thu, 27 Apr 2017 20:51:28 -0600 David Ahern wrote: > On 4/27/17 8:49 PM, Steven Rostedt wrote: > > On Thu, 27 Apr 2017 20:13:43 -0600 > > David Ahern wrote: > > > >> On 4/27/17 7:41 PM, Steven Rostedt wrote: > >>> On Thu, 27 Apr 2017 19:31:12 -0500

Re: perf report warnings on tracepoint events hidden by ui

On Thu, 27 Apr 2017 20:51:28 -0600 David Ahern wrote: > On 4/27/17 8:49 PM, Steven Rostedt wrote: > > On Thu, 27 Apr 2017 20:13:43 -0600 > > David Ahern wrote: > > > >> On 4/27/17 7:41 PM, Steven Rostedt wrote: > >>> On Thu, 27 Apr 2017 19:31:12 -0500 > >>> David Carrillo-Cisneros wrote:

Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages

On Wed, 2017-04-26 at 03:13 +, Naoya Horiguchi wrote: > On Wed, Apr 26, 2017 at 12:10:15PM +1000, Balbir Singh wrote: > > On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote: > > > The commit b023f46813cd ("memory-hotplug: skip HWPoisoned page when > > > offlining pages") skip the

Re: [PATCH v2 2/2] mm: skip HWPoisoned pages when onlining pages

On Wed, 2017-04-26 at 03:13 +, Naoya Horiguchi wrote: > On Wed, Apr 26, 2017 at 12:10:15PM +1000, Balbir Singh wrote: > > On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote: > > > The commit b023f46813cd ("memory-hotplug: skip HWPoisoned page when > > > offlining pages") skip the

Re: perf report warnings on tracepoint events hidden by ui

On 4/27/17 8:49 PM, Steven Rostedt wrote: > On Thu, 27 Apr 2017 20:13:43 -0600 > David Ahern wrote: > >> On 4/27/17 7:41 PM, Steven Rostedt wrote: >>> On Thu, 27 Apr 2017 19:31:12 -0500 >>> David Carrillo-Cisneros wrote: >>> When processing

Re: perf report warnings on tracepoint events hidden by ui

On 4/27/17 8:49 PM, Steven Rostedt wrote: > On Thu, 27 Apr 2017 20:13:43 -0600 > David Ahern wrote: > >> On 4/27/17 7:41 PM, Steven Rostedt wrote: >>> On Thu, 27 Apr 2017 19:31:12 -0500 >>> David Carrillo-Cisneros wrote: >>> When processing tracepoint events, perf report outputs

Re: perf report warnings on tracepoint events hidden by ui

On Thu, 27 Apr 2017 20:13:43 -0600 David Ahern wrote: > On 4/27/17 7:41 PM, Steven Rostedt wrote: > > On Thu, 27 Apr 2017 19:31:12 -0500 > > David Carrillo-Cisneros wrote: > > > >> When processing tracepoint events, perf report outputs warnings about >

Re: perf report warnings on tracepoint events hidden by ui

On Thu, 27 Apr 2017 20:13:43 -0600 David Ahern wrote: > On 4/27/17 7:41 PM, Steven Rostedt wrote: > > On Thu, 27 Apr 2017 19:31:12 -0500 > > David Carrillo-Cisneros wrote: > > > >> When processing tracepoint events, perf report outputs warnings about > >> field not founds. The warnings are

Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

Hi, On Thu, 2017-04-27 at 20:55 +0200, Arnd Bergmann wrote: > On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee wrote: > > On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote: > >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee wrote: > > >> > +static

Re: [PATCH 1/2] PCI: mediatek: Add Mediatek PCIe host controller support

Hi, On Thu, 2017-04-27 at 20:55 +0200, Arnd Bergmann wrote: > On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee wrote: > > On Tue, 2017-04-25 at 14:38 +0200, Arnd Bergmann wrote: > >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee wrote: > > >> > +static int mtk_pcie_enable_ports(struct mtk_pcie *pcie)

Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Thu, 2017-04-27 at 21:06 +0200, Arnd Bergmann wrote: > On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee wrote: > > Hi > > > > On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote: > >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee wrote: > >> > Add

Re: [PATCH 2/2] dt-bindings: pcie: Add documentation for Mediatek PCIe

On Thu, 2017-04-27 at 21:06 +0200, Arnd Bergmann wrote: > On Wed, Apr 26, 2017 at 10:10 AM, Ryder Lee wrote: > > Hi > > > > On Tue, 2017-04-25 at 14:18 +0200, Arnd Bergmann wrote: > >> On Sun, Apr 23, 2017 at 10:19 AM, Ryder Lee wrote: > >> > Add documentation for PCIe host driver available in

Re: [lkp-robot] [perf] 924726b2b5: double_fault:#[##]

On 04/27, Sebastian Andrzej Siewior wrote: >On 2017-04-27 10:58:36 [+0800], kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: 924726b2b5e5000dfb8eb6032651baed1b1bdc6c ("perf: Cure hotplug lock >> ordering issues") >>

Re: [lkp-robot] [perf] 924726b2b5: double_fault:#[##]

On 04/27, Sebastian Andrzej Siewior wrote: >On 2017-04-27 10:58:36 [+0800], kernel test robot wrote: >> >> FYI, we noticed the following commit: >> >> commit: 924726b2b5e5000dfb8eb6032651baed1b1bdc6c ("perf: Cure hotplug lock >> ordering issues") >>

linux-next: build warning after merge of the devicetree tree

Hi Rob, After merging the devicetree tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/of/unittest.c: In function 'of_unittest': drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used uninitialized in this function [-Wmaybe-uninitialized]

linux-next: build warning after merge of the devicetree tree

Hi Rob, After merging the devicetree tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/of/unittest.c: In function 'of_unittest': drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used uninitialized in this function [-Wmaybe-uninitialized]

  1   2   3   4   5   6   7   8   9   10   >