Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, May 11, 2018 at 12:27:12PM -0400, Steven Rostedt wrote: > On Fri, 11 May 2018 12:25:28 -0400 > Steven Rostedt wrote: > > > I would also say that one should never call schedule() directly without > > changing its state to something other than TASK_RUNNING. Hence,

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, May 11, 2018 at 12:27:12PM -0400, Steven Rostedt wrote: > On Fri, 11 May 2018 12:25:28 -0400 > Steven Rostedt wrote: > > > I would also say that one should never call schedule() directly without > > changing its state to something other than TASK_RUNNING. Hence, calling > > schedule

Re: Another NVMe failure, this time with AER info

On Fri, May 11, 2018 at 11:57:52AM -0500, Bjorn Helgaas wrote: > We reported several corrected errors before the nvme timeout: > > [12750.281158] nvme nvme0: controller is down; will reset: CSTS=0x, > PCI_STATUS=0x10 > [12750.297594] nvme nvme0: I/O 455 QID 2 timeout, disable

Re: Another NVMe failure, this time with AER info

On Fri, May 11, 2018 at 11:57:52AM -0500, Bjorn Helgaas wrote: > We reported several corrected errors before the nvme timeout: > > [12750.281158] nvme nvme0: controller is down; will reset: CSTS=0x, > PCI_STATUS=0x10 > [12750.297594] nvme nvme0: I/O 455 QID 2 timeout, disable

Re: [PATCH v5 05/13] s390: vfio-ap: register matrix device with VFIO mdev framework

On 05/07/2018 05:11 PM, Tony Krowiak wrote: Registers the matrix device created by the VFIO AP device driver with the VFIO mediated device framework. Registering the matrix device will create the sysfs structures needed to create mediated matrix devices each of which will be used to configure

Re: [PATCH v5 05/13] s390: vfio-ap: register matrix device with VFIO mdev framework

On 05/07/2018 05:11 PM, Tony Krowiak wrote: Registers the matrix device created by the VFIO AP device driver with the VFIO mediated device framework. Registering the matrix device will create the sysfs structures needed to create mediated matrix devices each of which will be used to configure

use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

Ingo, Thomas, Al, any concerns with this series? On Thu, May 3, 2018 at 5:06 PM, Dan Williams wrote: > Changes since v2 [1]: > > * Fix source address increment in mcsafe_handle_tail() (Mika) > > * Extend the unit test to inject simulated write faults and validate >

use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

Ingo, Thomas, Al, any concerns with this series? On Thu, May 3, 2018 at 5:06 PM, Dan Williams wrote: > Changes since v2 [1]: > > * Fix source address increment in mcsafe_handle_tail() (Mika) > > * Extend the unit test to inject simulated write faults and validate > that data is properly

Re: [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel

Hi Akashi, On 07/05/18 08:21, AKASHI Takahiro wrote: > On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote: >> On 25/04/18 07:26, AKASHI Takahiro wrote: >>> This patch provides kexec_file_ops for "Image"-format kernel. In this >>> implementation, a binary is always loaded with a fixed

Re: [PATCH v9 06/11] arm64: kexec_file: allow for loading Image-format kernel

Hi Akashi, On 07/05/18 08:21, AKASHI Takahiro wrote: > On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote: >> On 25/04/18 07:26, AKASHI Takahiro wrote: >>> This patch provides kexec_file_ops for "Image"-format kernel. In this >>> implementation, a binary is always loaded with a fixed

Re: [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory

Hi Akashi, On 07/05/18 06:22, AKASHI Takahiro wrote: > On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote: >> On 25/04/18 07:26, AKASHI Takahiro wrote: >>> diff --git a/arch/arm64/kernel/machine_kexec.c >>> b/arch/arm64/kernel/machine_kexec.c >>> index f76ea92dff91..f7dbba00be10 100644

Re: [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory

Hi Akashi, On 07/05/18 06:22, AKASHI Takahiro wrote: > On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote: >> On 25/04/18 07:26, AKASHI Takahiro wrote: >>> diff --git a/arch/arm64/kernel/machine_kexec.c >>> b/arch/arm64/kernel/machine_kexec.c >>> index f76ea92dff91..f7dbba00be10 100644

[PATCH 1/6] hwspinlock/core: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the Hwspinlock core driver source files and drop the previous boilerplate license text. Signed-off-by: Suman Anna --- drivers/hwspinlock/Kconfig | 1 + drivers/hwspinlock/hwspinlock_core.c | 10 +-

[PATCH 4/6] hwspinlock/sirf: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the CSR's SIRF hardware spinlock driver source file and drop the previous boilerplate license text. Cc: Wei Chen Cc: Barry Song Signed-off-by: Suman Anna --- drivers/hwspinlock/sirf_hwspinlock.c

[PATCH 1/6] hwspinlock/core: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the Hwspinlock core driver source files and drop the previous boilerplate license text. Signed-off-by: Suman Anna --- drivers/hwspinlock/Kconfig | 1 + drivers/hwspinlock/hwspinlock_core.c | 10 +-

[PATCH 4/6] hwspinlock/sirf: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the CSR's SIRF hardware spinlock driver source file and drop the previous boilerplate license text. Cc: Wei Chen Cc: Barry Song Signed-off-by: Suman Anna --- drivers/hwspinlock/sirf_hwspinlock.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH 2/6] hwspinlock/omap: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the OMAP hwspinlock driver source file and drop the previous boilerplate license text. Signed-off-by: Suman Anna --- drivers/hwspinlock/omap_hwspinlock.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git

[PATCH 2/6] hwspinlock/omap: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the OMAP hwspinlock driver source file and drop the previous boilerplate license text. Signed-off-by: Suman Anna --- drivers/hwspinlock/omap_hwspinlock.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git

[PATCH 5/6] hwspinlock/u8500: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the U8500 HWSEM driver source file and drop the previous boilerplate license text. Cc: Mathieu J. Poirier Cc: Linus Walleij Signed-off-by: Suman Anna ---

[PATCH 6/6] hwspinlock: sprd: Switch to SPDX license identifier

Use the appropriate SPDX license identifiers in the Spreadtrum hardware spinlock driver source file and drop the previous boilerplate license text. Cc: Baolin Wang Signed-off-by: Suman Anna --- drivers/hwspinlock/sprd_hwspinlock.c | 10 +- 1

[PATCH 5/6] hwspinlock/u8500: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the U8500 HWSEM driver source file and drop the previous boilerplate license text. Cc: Mathieu J. Poirier Cc: Linus Walleij Signed-off-by: Suman Anna --- drivers/hwspinlock/u8500_hsem.c | 10 +- 1 file changed, 1 insertion(+), 9

[PATCH 6/6] hwspinlock: sprd: Switch to SPDX license identifier

Use the appropriate SPDX license identifiers in the Spreadtrum hardware spinlock driver source file and drop the previous boilerplate license text. Cc: Baolin Wang Signed-off-by: Suman Anna --- drivers/hwspinlock/sprd_hwspinlock.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-)

[PATCH 3/6] hwspinlock: qcom: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the Qualcomm Hwspinlock driver source file and drop the previous boilerplate license text. Signed-off-by: Suman Anna --- drivers/hwspinlock/qcom_hwspinlock.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git

[PATCH 3/6] hwspinlock: qcom: Switch to SPDX license identifier

Use the appropriate SPDX license identifier in the Qualcomm Hwspinlock driver source file and drop the previous boilerplate license text. Signed-off-by: Suman Anna --- drivers/hwspinlock/qcom_hwspinlock.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git

[PATCH 0/6] hwspinlock: Convert to use SPDX license identifiers

Hi Bjorn, The following series switches over the current licensing text in various HwSpinlock drivers to the SPDX licensing format. Please let me know if you need any changes. If you are ok with the changes, I will make similar changes to the remoteproc and rpmsg drivers and post them at the

[PATCH 0/6] hwspinlock: Convert to use SPDX license identifiers

Hi Bjorn, The following series switches over the current licensing text in various HwSpinlock drivers to the SPDX licensing format. Please let me know if you need any changes. If you are ok with the changes, I will make similar changes to the remoteproc and rpmsg drivers and post them at the

Re: [RFC PATCH v4 2/3] acpi: apei: Rename ghes_severity() to ghes_cper_severity()

On 05/11/2018 11:19 AM, Borislav Petkov wrote: > On Fri, May 11, 2018 at 11:12:24AM -0500, Alex G. wrote: >> Because the GHES structure uses CPER values, but all the code is written >> to use GHES_SEV_ values. GHES_SEV_ is a made up enum, specifically for >> linux. > > Again, what does that

Re: [RFC PATCH v4 2/3] acpi: apei: Rename ghes_severity() to ghes_cper_severity()

On 05/11/2018 11:19 AM, Borislav Petkov wrote: > On Fri, May 11, 2018 at 11:12:24AM -0500, Alex G. wrote: >> Because the GHES structure uses CPER values, but all the code is written >> to use GHES_SEV_ values. GHES_SEV_ is a made up enum, specifically for >> linux. > > Again, what does that

Re: [RFC PATCH v4 3/3] acpi: apei: Do not panic() on PCIe errors reported through GHES

On 05/11/2018 11:29 AM, Borislav Petkov wrote: > On Fri, May 11, 2018 at 11:12:25AM -0500, Alex G. wrote: >>> I think *you* didn't get it: IS_ENABLED(CONFIG_ACPI_APEI_PCIEAER) is not >>> enough of a check to confirm that there actually *is* an AER driver to >>> handle the errors. If you really

Re: [RFC PATCH v4 3/3] acpi: apei: Do not panic() on PCIe errors reported through GHES

On 05/11/2018 11:29 AM, Borislav Petkov wrote: > On Fri, May 11, 2018 at 11:12:25AM -0500, Alex G. wrote: >>> I think *you* didn't get it: IS_ENABLED(CONFIG_ACPI_APEI_PCIEAER) is not >>> enough of a check to confirm that there actually *is* an AER driver to >>> handle the errors. If you really

RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM

> -Original Message- > From: Yinbo Zhu [mailto:yinbo@nxp.com] > Sent: Thursday, May 10, 2018 10:35 PM > To: Yinbo Zhu ; Rob Herring ; > Mark Rutland ; Catalin Marinas ) > ; Will Deacon )

RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM

> -Original Message- > From: Yinbo Zhu [mailto:yinbo@nxp.com] > Sent: Thursday, May 10, 2018 10:35 PM > To: Yinbo Zhu ; Rob Herring ; > Mark Rutland ; Catalin Marinas ) > ; Will Deacon ) ; > Lorenzo Pieralisi ) ; Leo Li > Cc: Xiaobo Xie ; Ran Wang ; > Daniel Lezcano ; Thomas

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On 05/11/2018 10:29 AM, Tejun Heo wrote: > Hello, Shuah. > > On Fri, May 11, 2018 at 08:55:28AM -0600, Shuah Khan wrote: >> I think we don't need to create a special branch and all. The following >> should work: >> >> linux-next already has the skip work. What we can do is: >> >> Do the cleanup

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On 05/11/2018 10:29 AM, Tejun Heo wrote: > Hello, Shuah. > > On Fri, May 11, 2018 at 08:55:28AM -0600, Shuah Khan wrote: >> I think we don't need to create a special branch and all. The following >> should work: >> >> linux-next already has the skip work. What we can do is: >> >> Do the cleanup

Re: KASAN: null-ptr-deref Read in rds_ib_get_mr

On 5/11/2018 12:48 AM, Yanjun Zhu wrote: On 2018/5/11 13:20, DaeRyong Jeong wrote: We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr Note that this bug is previously reported by syzkaller. https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91

Re: KASAN: null-ptr-deref Read in rds_ib_get_mr

On 5/11/2018 12:48 AM, Yanjun Zhu wrote: On 2018/5/11 13:20, DaeRyong Jeong wrote: We report the crash: KASAN: null-ptr-deref Read in rds_ib_get_mr Note that this bug is previously reported by syzkaller. https://syzkaller.appspot.com/bug?id=0bb56a5a48b000b52aa2b0d8dd20b1f545214d91

Re: Another NVMe failure, this time with AER info

Andrew wrote: > A friend of mine has a brand new LG laptop that has intermittent NVMe > failures. They mostly happen during a suspend/resume cycle > (apparently during suspend, not resume). Unlike the earlier > Dell/Samsung issue, the NVMe device isn't completely gone -- MMIO > reads fail, but

Re: Another NVMe failure, this time with AER info

Andrew wrote: > A friend of mine has a brand new LG laptop that has intermittent NVMe > failures. They mostly happen during a suspend/resume cycle > (apparently during suspend, not resume). Unlike the earlier > Dell/Samsung issue, the NVMe device isn't completely gone -- MMIO > reads fail, but

Re: [PATCH 2/2] arm64: dts: mt7622: add audio related device nodes

On 05/02/2018 05:53 AM, Sean Wang wrote: > Hi, Matthias > > On Wed, 2018-05-02 at 11:41 +0800, sean.w...@mediatek.com wrote: >> From: Ryder Lee >> >> Add audio device nodes and its proper setup for all used pins >> >> Signed-off-by: Ryder Lee >>

Re: [PATCH 2/2] arm64: dts: mt7622: add audio related device nodes

On 05/02/2018 05:53 AM, Sean Wang wrote: > Hi, Matthias > > On Wed, 2018-05-02 at 11:41 +0800, sean.w...@mediatek.com wrote: >> From: Ryder Lee >> >> Add audio device nodes and its proper setup for all used pins >> >> Signed-off-by: Ryder Lee >> Signed-off-by: Sean Wang >> --- >>

Re: [PATCH v5 5/7] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option

On Fri, May 11, 2018 at 2:46 AM Alexey Gladkov wrote: > + /* Limit procfs to only ptracable tasks */ > + if (limit_pids == PROC_LIMIT_PIDS_PTRACE) { > + cond_resched(); > + if (!has_pid_permissions(fs_info, task,

Re: [PATCH v5 5/7] proc: instantiate only pids that we can ptrace on 'limit_pids=1' mount option

On Fri, May 11, 2018 at 2:46 AM Alexey Gladkov wrote: > + /* Limit procfs to only ptracable tasks */ > + if (limit_pids == PROC_LIMIT_PIDS_PTRACE) { > + cond_resched(); > + if (!has_pid_permissions(fs_info, task, HIDEPID_NO_ACCESS)) > +

Re: [PATCH] selftests: memfd: split regular and hugetlbfs tests

On 05/10/2018 01:13 PM, Shuah Khan (Samsung OSG) wrote: > Split normal memfd and hugetlbfs tests to improve the test reporting. > Remove run_fuse_test.sh and memfd_test from run_tests.sh and add them > to the Makefile. > > Add memfd_test to TEST_GEN_PROGS to be run separately. > Rename

Re: [PATCH] selftests: memfd: split regular and hugetlbfs tests

On 05/10/2018 01:13 PM, Shuah Khan (Samsung OSG) wrote: > Split normal memfd and hugetlbfs tests to improve the test reporting. > Remove run_fuse_test.sh and memfd_test from run_tests.sh and add them > to the Makefile. > > Add memfd_test to TEST_GEN_PROGS to be run separately. > Rename

Re: [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp

Hi Lin, 2018-05-09 12:22 GMT+02:00 Lin Huang : > From: Chris Zhong > > We may support training outside firmware, so we need support > dpcd read/write to get the message or do some setting with > display. > > Signed-off-by: Chris Zhong

Re: [PATCH v2 1/4] drm/rockchip: add transfer function for cdn-dp

Hi Lin, 2018-05-09 12:22 GMT+02:00 Lin Huang : > From: Chris Zhong > > We may support training outside firmware, so we need support > dpcd read/write to get the message or do some setting with > display. > > Signed-off-by: Chris Zhong > Signed-off-by: Lin Huang > --- > > Changes in v2: > -

Re: [PATCH v2 00/12] refactor dts and add support for more boards

On 04/11/2018 10:53 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > Changes since v1: > - Dropped several patches which have been merged. > - Rebased to linux-next-20180410 where those dependent patches including > [1] and [2] all have been got merged. > -

Re: [PATCH v2 00/12] refactor dts and add support for more boards

On 04/11/2018 10:53 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > Changes since v1: > - Dropped several patches which have been merged. > - Rebased to linux-next-20180410 where those dependent patches including > [1] and [2] all have been got merged. > - Revised according to

[PATCH] pci/aer: Get rid of aer_recover_work_func() forward declaration

From: Borislav Petkov Just move the actual function up so that it is visible to its user aer_recover_queue(). No functional changes. Signed-off-by: Borislav Petkov --- drivers/pci/pcie/aer/aerdrv_core.c | 45 +++--- 1 file changed, 22

[PATCH] pci/aer: Get rid of aer_recover_work_func() forward declaration

From: Borislav Petkov Just move the actual function up so that it is visible to its user aer_recover_queue(). No functional changes. Signed-off-by: Borislav Petkov --- drivers/pci/pcie/aer/aerdrv_core.c | 45 +++--- 1 file changed, 22 insertions(+), 23 deletions(-)

Re: [PATCH v5 0/7] proc: modernize proc to support multiple private instances

On Fri, May 11, 2018 at 2:42 AM Alexey Gladkov wrote: > This is RFC v5 to modernize procfs and make it able to support multiple > private instances per the same pid namespace. So I have no big objections, but I would *really* like this to go through Al's vfs tree. Al?

Re: [PATCH v5 0/7] proc: modernize proc to support multiple private instances

On Fri, May 11, 2018 at 2:42 AM Alexey Gladkov wrote: > This is RFC v5 to modernize procfs and make it able to support multiple > private instances per the same pid namespace. So I have no big objections, but I would *really* like this to go through Al's vfs tree. Al? Have you looked at this

Re: [PATCH v4] dax: Change return type to vm_fault_t

On Fri, May 11, 2018 at 10:04 PM, Dan Williams wrote: > On Fri, May 11, 2018 at 9:34 AM, Souptick Joarder > wrote: >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT

Re: [PATCH v4] dax: Change return type to vm_fault_t

On Fri, May 11, 2018 at 10:04 PM, Dan Williams wrote: > On Fri, May 11, 2018 at 9:34 AM, Souptick Joarder > wrote: >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT value rather than an errno. Once all instances >>

Re: [PATCH v2 26/27] coresight: perf: Remove reset_buffer call back for sinks

On 08/05/18 20:42, Mathieu Poirier wrote: On Tue, May 01, 2018 at 10:10:56AM +0100, Suzuki K Poulose wrote: Right now we issue an update_buffer() and reset_buffer() call backs in succession when we stop tracing an event. The update_buffer is supposed to check the status of the buffer and make

Re: [PATCH v2 26/27] coresight: perf: Remove reset_buffer call back for sinks

On 08/05/18 20:42, Mathieu Poirier wrote: On Tue, May 01, 2018 at 10:10:56AM +0100, Suzuki K Poulose wrote: Right now we issue an update_buffer() and reset_buffer() call backs in succession when we stop tracing an event. The update_buffer is supposed to check the status of the buffer and make

[PATCH v2] staging: bcm2835-camera: Replace open-coded idr with a struct idr.

We just need some integer handles that can map back to our message struct when we're handling a reply, which struct idr is perfect for. v2: Fix error check to look at the right variable. Signed-off-by: Eric Anholt --- .../vc04_services/bcm2835-camera/mmal-vchiq.c | 135

[PATCH v2] staging: bcm2835-camera: Replace open-coded idr with a struct idr.

We just need some integer handles that can map back to our message struct when we're handling a reply, which struct idr is perfect for. v2: Fix error check to look at the right variable. Signed-off-by: Eric Anholt --- .../vc04_services/bcm2835-camera/mmal-vchiq.c | 135 -- 1

Re: [PATCH v4] dax: Change return type to vm_fault_t

On Fri, May 11, 2018 at 9:34 AM, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a

Re: [PATCH v4] dax: Change return type to vm_fault_t

On Fri, May 11, 2018 at 9:34 AM, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. > >

[PATCH v4] dax: Change return type to vm_fault_t

Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Commit 1c8f422059ae ("mm: change return type to vm_fault_t") Previously

[PATCH v4] dax: Change return type to vm_fault_t

Use new return type vm_fault_t for fault handler. For now, this is just documenting that the function returns a VM_FAULT value rather than an errno. Once all instances are converted, vm_fault_t will become a distinct type. Commit 1c8f422059ae ("mm: change return type to vm_fault_t") Previously

Re: [RFC PATCH v4 3/3] acpi: apei: Do not panic() on PCIe errors reported through GHES

On Fri, May 11, 2018 at 11:12:25AM -0500, Alex G. wrote: > > I think *you* didn't get it: IS_ENABLED(CONFIG_ACPI_APEI_PCIEAER) is not > > enough of a check to confirm that there actually *is* an AER driver to > > handle the errors. If you really want to make sure the driver is loaded > > and

Re: [RFC PATCH v4 3/3] acpi: apei: Do not panic() on PCIe errors reported through GHES

On Fri, May 11, 2018 at 11:12:25AM -0500, Alex G. wrote: > > I think *you* didn't get it: IS_ENABLED(CONFIG_ACPI_APEI_PCIEAER) is not > > enough of a check to confirm that there actually *is* an AER driver to > > handle the errors. If you really want to make sure the driver is loaded > > and

Re: [resend PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

On Tue, 2018-03-27 at 11:52 -0700, Joe Perches wrote: > When enabled, the current debug logging does not have a KERN_. > Add KERN_DEBUG to the logging macros. > > Miscellanea: > > o Remove #define redundancy and neaten the macros a bit ping? > Signed-off-by: Joe Perches >

Re: [resend PATCH] rxrpc: Neaten logging macros and add KERN_DEBUG logging level

On Tue, 2018-03-27 at 11:52 -0700, Joe Perches wrote: > When enabled, the current debug logging does not have a KERN_. > Add KERN_DEBUG to the logging macros. > > Miscellanea: > > o Remove #define redundancy and neaten the macros a bit ping? > Signed-off-by: Joe Perches > --- > > Resend of

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

Hello, Shuah. On Fri, May 11, 2018 at 08:55:28AM -0600, Shuah Khan wrote: > I think we don't need to create a special branch and all. The following > should work: > > linux-next already has the skip work. What we can do is: > > Do the cleanup and test it against linux-next. In linux-next SKIP

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

Hello, Shuah. On Fri, May 11, 2018 at 08:55:28AM -0600, Shuah Khan wrote: > I think we don't need to create a special branch and all. The following > should work: > > linux-next already has the skip work. What we can do is: > > Do the cleanup and test it against linux-next. In linux-next SKIP

Re: [tip/core/rcu, 05/21] rcu: Make rcu_gp_cleanup() more accurately predict need for new GP

On Fri, May 11, 2018 at 09:24:43AM -0700, Paul E. McKenney wrote: > On Thu, May 10, 2018 at 10:37:54AM -0700, Joel Fernandes wrote: > > On Thu, May 10, 2018 at 06:15:46AM -0700, Paul E. McKenney wrote: > > [...] > > > > Also in rcu_future_gp_cleanup, we call: > > > >

Re: [tip/core/rcu, 05/21] rcu: Make rcu_gp_cleanup() more accurately predict need for new GP

On Fri, May 11, 2018 at 09:24:43AM -0700, Paul E. McKenney wrote: > On Thu, May 10, 2018 at 10:37:54AM -0700, Joel Fernandes wrote: > > On Thu, May 10, 2018 at 06:15:46AM -0700, Paul E. McKenney wrote: > > [...] > > > > Also in rcu_future_gp_cleanup, we call: > > > >

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, 11 May 2018 12:25:28 -0400 Steven Rostedt wrote: > I would also say that one should never call schedule() directly without > changing its state to something other than TASK_RUNNING. Hence, calling > schedule directly is saying you are ready to sleep. But that is not

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, 11 May 2018 12:25:28 -0400 Steven Rostedt wrote: > I would also say that one should never call schedule() directly without > changing its state to something other than TASK_RUNNING. Hence, calling > schedule directly is saying you are ready to sleep. But that is not the > case with

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, 11 May 2018 12:23:21 -0400 Steven Rostedt wrote: > On Fri, 11 May 2018 09:17:46 -0700 > "Paul E. McKenney" wrote: > > > > >index ee8cf5fc..7432261 100644 > > > >--- a/include/linux/rcupdate.h > > > >+++ b/include/linux/rcupdate.h > > >

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, 11 May 2018 12:23:21 -0400 Steven Rostedt wrote: > On Fri, 11 May 2018 09:17:46 -0700 > "Paul E. McKenney" wrote: > > > > >index ee8cf5fc..7432261 100644 > > > >--- a/include/linux/rcupdate.h > > > >+++ b/include/linux/rcupdate.h > > > >@@ -195,8 +195,8 @@ static inline void

[PATCH 02/12] platform/early: don't WARN() on non-empty devres list for early devices

From: Bartosz Golaszewski Early platform devices can have devres objects allocated in early_probe(). This is not a bug so don't dump stack in this case. Signed-off-by: Bartosz Golaszewski --- drivers/base/dd.c | 2 +- 1 file changed, 1

[PATCH 02/12] platform/early: don't WARN() on non-empty devres list for early devices

From: Bartosz Golaszewski Early platform devices can have devres objects allocated in early_probe(). This is not a bug so don't dump stack in this case. Signed-off-by: Bartosz Golaszewski --- drivers/base/dd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 04/12] platform: provide a separate function for initializing platform devices

From: Bartosz Golaszewski The early platform driver framework will allocate platform devices using its own internal mechanisms. Provide a function that allows to initialize a platform device object without allocating it. Signed-off-by: Bartosz Golaszewski

[PATCH 04/12] platform: provide a separate function for initializing platform devices

From: Bartosz Golaszewski The early platform driver framework will allocate platform devices using its own internal mechanisms. Provide a function that allows to initialize a platform device object without allocating it. Signed-off-by: Bartosz Golaszewski --- drivers/base/platform.c |

[PATCH 06/12] of: add a new flag for OF device nodes

From: Bartosz Golaszewski This flag indicates that a device node has been populated early and that it needs different handling when called from of_platform_populate(). Signed-off-by: Bartosz Golaszewski --- include/linux/of.h | 1 + 1 file

[PATCH 06/12] of: add a new flag for OF device nodes

From: Bartosz Golaszewski This flag indicates that a device node has been populated early and that it needs different handling when called from of_platform_populate(). Signed-off-by: Bartosz Golaszewski --- include/linux/of.h | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, 11 May 2018 09:17:46 -0700 "Paul E. McKenney" wrote: > > >index ee8cf5fc..7432261 100644 > > >--- a/include/linux/rcupdate.h > > >+++ b/include/linux/rcupdate.h > > >@@ -195,8 +195,8 @@ static inline void exit_tasks_rcu_finish(void) { } > > > */ > > >

Re: [PATCH] rcu: Report a quiescent state when it's exactly in the state

On Fri, 11 May 2018 09:17:46 -0700 "Paul E. McKenney" wrote: > > >index ee8cf5fc..7432261 100644 > > >--- a/include/linux/rcupdate.h > > >+++ b/include/linux/rcupdate.h > > >@@ -195,8 +195,8 @@ static inline void exit_tasks_rcu_finish(void) { } > > > */ > > > #define

Re: [tip/core/rcu, 05/21] rcu: Make rcu_gp_cleanup() more accurately predict need for new GP

On Thu, May 10, 2018 at 10:37:54AM -0700, Joel Fernandes wrote: > On Thu, May 10, 2018 at 06:15:46AM -0700, Paul E. McKenney wrote: > [...] > > > Also in rcu_future_gp_cleanup, we call: > > > trace_rcu_future_gp(rnp, rdp, c, > > > needmore ? TPS("CleanupMore") :

Re: [tip/core/rcu, 05/21] rcu: Make rcu_gp_cleanup() more accurately predict need for new GP

On Thu, May 10, 2018 at 10:37:54AM -0700, Joel Fernandes wrote: > On Thu, May 10, 2018 at 06:15:46AM -0700, Paul E. McKenney wrote: > [...] > > > Also in rcu_future_gp_cleanup, we call: > > > trace_rcu_future_gp(rnp, rdp, c, > > > needmore ? TPS("CleanupMore") :

[PATCH 07/12] of/platform: provide a separate routine for setting up device resources

From: Bartosz Golaszewski The early platform driver framework will need to setup the device resources before the regular populating of the device tree happens. Provide a separate function for that. Signed-off-by: Bartosz Golaszewski ---

[PATCH 07/12] of/platform: provide a separate routine for setting up device resources

From: Bartosz Golaszewski The early platform driver framework will need to setup the device resources before the regular populating of the device tree happens. Provide a separate function for that. Signed-off-by: Bartosz Golaszewski --- drivers/of/platform.c | 54

[PATCH 05/12] platform: export platform_device_release() locally

From: Bartosz Golaszewski The early platform driver mechanism will use this function as the device release callback. Make it available in drivers/base. Signed-off-by: Bartosz Golaszewski --- drivers/base/base.h | 1 +

[PATCH 05/12] platform: export platform_device_release() locally

From: Bartosz Golaszewski The early platform driver mechanism will use this function as the device release callback. Make it available in drivers/base. Signed-off-by: Bartosz Golaszewski --- drivers/base/base.h | 1 + drivers/base/platform.c | 2 +- 2 files changed, 2 insertions(+), 1

[PATCH 09/12] platform/early: add an init section for early driver data

From: Bartosz Golaszewski Provide a separate section in which pointers to early platform driver structs will be stored. Signed-off-by: Bartosz Golaszewski --- include/asm-generic/vmlinux.lds.h | 11 +++ 1 file changed, 11

[PATCH 09/12] platform/early: add an init section for early driver data

From: Bartosz Golaszewski Provide a separate section in which pointers to early platform driver structs will be stored. Signed-off-by: Bartosz Golaszewski --- include/asm-generic/vmlinux.lds.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/asm-generic/vmlinux.lds.h

Re: [PATCH] perf/ring_buffer: ensure atomicity and order of updates

On Fri, May 11, 2018 at 11:59:32AM +0100, Mark Rutland wrote: > READ_ONCE() and WRITE_ONCE() "helpfully" make a silent fallback to a > memcpy in this case, so we're broken today, regardless of this change. > > I suspect that in practice we get single-copy-atomicity for the 32-bit > halves, and

Re: [PATCH] perf/ring_buffer: ensure atomicity and order of updates

On Fri, May 11, 2018 at 11:59:32AM +0100, Mark Rutland wrote: > READ_ONCE() and WRITE_ONCE() "helpfully" make a silent fallback to a > memcpy in this case, so we're broken today, regardless of this change. > > I suspect that in practice we get single-copy-atomicity for the 32-bit > halves, and

[PATCH 08/12] of/platform: provide a separate routine for device initialization

From: Bartosz Golaszewski The early platform device framework will need to initialize the platform device objects without them being allocated in of_device_alloc(). Provide a routine that allows it. Signed-off-by: Bartosz Golaszewski ---

[PATCH 11/12] misc: implement a dummy early platform driver

From: Bartosz Golaszewski Implement a very simple early platform driver. Its purpose is to show how such drivers can be registered and to emit a message when probed. It can be then added to the device tree or machine code to verify that the early platform devices work

[PATCH 10/12] platform/early: implement support for early platform drivers

From: Bartosz Golaszewski This introduces the core part of support for early platform drivers and devices. Signed-off-by: Bartosz Golaszewski --- drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 +

[PATCH 08/12] of/platform: provide a separate routine for device initialization

From: Bartosz Golaszewski The early platform device framework will need to initialize the platform device objects without them being allocated in of_device_alloc(). Provide a routine that allows it. Signed-off-by: Bartosz Golaszewski --- drivers/of/platform.c | 22 ++ 1

[PATCH 11/12] misc: implement a dummy early platform driver

From: Bartosz Golaszewski Implement a very simple early platform driver. Its purpose is to show how such drivers can be registered and to emit a message when probed. It can be then added to the device tree or machine code to verify that the early platform devices work as expected.

[PATCH 10/12] platform/early: implement support for early platform drivers

From: Bartosz Golaszewski This introduces the core part of support for early platform drivers and devices. Signed-off-by: Bartosz Golaszewski --- drivers/base/Kconfig | 3 + drivers/base/Makefile | 1 + drivers/base/early.c | 332

[PATCH 00/12] introduce support for early platform drivers

This series is a follow-up to the RFC[1] posted a couple days ago. NOTE: this series applies on top of my recent patches[2] that move the previous implementation of early platform devices to arch/sh. Problem: Certain class of devices, such as timers, certain clock drivers and irq chip drivers

[PATCH 00/12] introduce support for early platform drivers

This series is a follow-up to the RFC[1] posted a couple days ago. NOTE: this series applies on top of my recent patches[2] that move the previous implementation of early platform devices to arch/sh. Problem: Certain class of devices, such as timers, certain clock drivers and irq chip drivers

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