linux-next: manual merge of the scsi-mkp tree with Linus' tree

Hi Martin, Today's linux-next merge of the scsi-mkp tree got a conflict in: drivers/scsi/qla2xxx/qla_os.c between commit: 2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery") from Linus' tree and commit: 33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")

linux-next: manual merge of the scsi-mkp tree with Linus' tree

Hi Martin, Today's linux-next merge of the scsi-mkp tree got a conflict in: drivers/scsi/qla2xxx/qla_os.c between commit: 2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery") from Linus' tree and commit: 33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")

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

On Thursday 22 March 2018 07:08 AM, Mark Brown wrote: On Wed, Mar 21, 2018 at 11:15:16AM +0530, Mukunda,Vijendar wrote: There is a patch dependency . Below patch not merged yet. We submitted for upstream review. [PATCH V2] ASoC: dwc: I2S Controller instance param added You need to mention

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

On Thursday 22 March 2018 07:08 AM, Mark Brown wrote: On Wed, Mar 21, 2018 at 11:15:16AM +0530, Mukunda,Vijendar wrote: There is a patch dependency . Below patch not merged yet. We submitted for upstream review. [PATCH V2] ASoC: dwc: I2S Controller instance param added You need to mention

[RESEND PATCH] mfd: sprd: Add one syscon cell to access PMIC global registers

There are some global registers in Spreadtrum sc27xx PMICs, which will be accessed by other drivers. So this patch adds one syscon cell to help to access the PMIC's global registers. Signed-off-by: Baolin Wang --- drivers/mfd/sprd-sc27xx-spi.c |3 +++ 1 file changed,

[RESEND PATCH] mfd: sprd: Add one syscon cell to access PMIC global registers

There are some global registers in Spreadtrum sc27xx PMICs, which will be accessed by other drivers. So this patch adds one syscon cell to help to access the PMIC's global registers. Signed-off-by: Baolin Wang --- drivers/mfd/sprd-sc27xx-spi.c |3 +++ 1 file changed, 3 insertions(+) diff

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

Hi Miquel, Thanks for reviewing the patch series. Please see my comments below. > -Original Message- > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > Sent: Tuesday, March 20, 2018 2:38 AM > To: nagasureshkumarre...@gmail.com > Cc: boris.brezil...@bootlin.com; rich...@nod.at;

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

Hi Miquel, Thanks for reviewing the patch series. Please see my comments below. > -Original Message- > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > Sent: Tuesday, March 20, 2018 2:38 AM > To: nagasureshkumarre...@gmail.com > Cc: boris.brezil...@bootlin.com; rich...@nod.at;

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

Hi, Kumar On Thu, 2018-03-22 at 11:30 +0800, Viresh Kumar wrote: > On 21-03-18, 18:21, Shunyong Yang wrote: > > > > When multiple cpus are related in one cpufreq policy, the first > > online cpu > > will be chosen by default to handle cpufreq operations. In a CPPC > > case, > > let's take two

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

Hi, Kumar On Thu, 2018-03-22 at 11:30 +0800, Viresh Kumar wrote: > On 21-03-18, 18:21, Shunyong Yang wrote: > > > > When multiple cpus are related in one cpufreq policy, the first > > online cpu > > will be chosen by default to handle cpufreq operations. In a CPPC > > case, > > let's take two

[PATCH] Documentation: Mention why %p prints ptrval

When debugging recent kernels, people will see '(ptrval)' but there isn't much information as to what that means. Briefly describe why it's there. Signed-off-by: Joel Stanley --- Documentation/core-api/printk-formats.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH] Documentation: Mention why %p prints ptrval

When debugging recent kernels, people will see '(ptrval)' but there isn't much information as to what that means. Briefly describe why it's there. Signed-off-by: Joel Stanley --- Documentation/core-api/printk-formats.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v10] mmc: Export host capabilities to debugfs.

On Friday 16 March 2018 01:27 PM, Ulf Hansson wrote: > On 16 March 2018 at 05:20, Harish Jenny K N wrote: >> >> On Thursday 15 March 2018 05:59 PM, Ulf Hansson wrote: >>> On 15 March 2018 at 11:26, Andy Shevchenko >>> wrote: On

Re: [PATCH v10] mmc: Export host capabilities to debugfs.

On Friday 16 March 2018 01:27 PM, Ulf Hansson wrote: > On 16 March 2018 at 05:20, Harish Jenny K N wrote: >> >> On Thursday 15 March 2018 05:59 PM, Ulf Hansson wrote: >>> On 15 March 2018 at 11:26, Andy Shevchenko >>> wrote: On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote: > On

Re: [PATCH v1 1/1] dmaengine: stm32-dmamux: fix a potential buffer overflow

On Tue, Mar 13, 2018 at 05:55:35PM +0100, Pierre-Yves MORDRET wrote: > The bitfield dma_inuse is allocated of size dma_requests bits, thus a > valid bit address is from 0 to (dma_requests - 1). > When find_first_zero_bit() fails, it returns dma_requests as invalid > address. > Using such address

Re: [PATCH v1 1/1] dmaengine: stm32-dmamux: fix a potential buffer overflow

On Tue, Mar 13, 2018 at 05:55:35PM +0100, Pierre-Yves MORDRET wrote: > The bitfield dma_inuse is allocated of size dma_requests bits, thus a > valid bit address is from 0 to (dma_requests - 1). > When find_first_zero_bit() fails, it returns dma_requests as invalid > address. > Using such address

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

On 3/21/18 10:12 PM, Srivatsa S. Bhat wrote: > On 3/21/18 7:02 PM, Steve French wrote: >> Found a patch which solves the dependency issue. In my testing (on >> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this >> appears to fix the problem, but I will let Srivatsa confirm that it

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

On 3/21/18 10:12 PM, Srivatsa S. Bhat wrote: > On 3/21/18 7:02 PM, Steve French wrote: >> Found a patch which solves the dependency issue. In my testing (on >> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this >> appears to fix the problem, but I will let Srivatsa confirm that it

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

On 3/21/18 7:02 PM, Steve French wrote: > Found a patch which solves the dependency issue. In my testing (on > 4.9, with Windows 2016, and also to Samba) as Pavel suggested this > appears to fix the problem, but I will let Srivatsa confirm that it > also fixes it for him. The two attached

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

On 3/21/18 7:02 PM, Steve French wrote: > Found a patch which solves the dependency issue. In my testing (on > 4.9, with Windows 2016, and also to Samba) as Pavel suggested this > appears to fix the problem, but I will let Srivatsa confirm that it > also fixes it for him. The two attached

Re: [RFC PATCH 4/6] sched/fair: Introduce an energy estimation helper function

On Wednesday 21 Mar 2018 at 15:54:58 (+), Patrick Bellasi wrote: > On 21-Mar 14:26, Quentin Perret wrote: > > On Wednesday 21 Mar 2018 at 12:39:21 (+), Patrick Bellasi wrote: > > > On 20-Mar 09:43, Dietmar Eggemann wrote: > > > > From: Quentin Perret [...] > > So

Re: [RFC PATCH 4/6] sched/fair: Introduce an energy estimation helper function

On Wednesday 21 Mar 2018 at 15:54:58 (+), Patrick Bellasi wrote: > On 21-Mar 14:26, Quentin Perret wrote: > > On Wednesday 21 Mar 2018 at 12:39:21 (+), Patrick Bellasi wrote: > > > On 20-Mar 09:43, Dietmar Eggemann wrote: > > > > From: Quentin Perret [...] > > So actually, what I can do

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On Wed, Mar 21, 2018 at 07:15:14PM +0300, Kirill Tkhai wrote: > On 20.03.2018 17:34, Dave Chinner wrote: > > On Tue, Mar 20, 2018 at 04:15:16PM +0300, Kirill Tkhai wrote: > >> On 20.03.2018 03:18, Dave Chinner wrote: > >>> On Mon, Mar 19, 2018 at 02:06:01PM +0300, Kirill Tkhai wrote: > On

Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim

On Wed, Mar 21, 2018 at 07:15:14PM +0300, Kirill Tkhai wrote: > On 20.03.2018 17:34, Dave Chinner wrote: > > On Tue, Mar 20, 2018 at 04:15:16PM +0300, Kirill Tkhai wrote: > >> On 20.03.2018 03:18, Dave Chinner wrote: > >>> On Mon, Mar 19, 2018 at 02:06:01PM +0300, Kirill Tkhai wrote: > On

Re: [PATCH] arm64: avoid race condition issue in dump_backtrace

Hi Ji Zhang, On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote: > When we dump the backtrace of some specific task, there is a potential race > condition due to the task may be running on other cores if SMP enabled. > That is because for current implementation, if the task is not the

Re: [PATCH] arm64: avoid race condition issue in dump_backtrace

Hi Ji Zhang, On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote: > When we dump the backtrace of some specific task, there is a potential race > condition due to the task may be running on other cores if SMP enabled. > That is because for current implementation, if the task is not the

[PATCH] vfio iommu type1: improve memory pinning process for raw PFN mapping

When using vfio to pass through a PCIe device (e.g. a GPU card) that has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory pinning because PFNs of PCI BAR are not backed by struct page, and the corresponding VMA has flag VM_PFNMAP. With this change, when pinning a region which is a raw

[PATCH] vfio iommu type1: improve memory pinning process for raw PFN mapping

When using vfio to pass through a PCIe device (e.g. a GPU card) that has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory pinning because PFNs of PCI BAR are not backed by struct page, and the corresponding VMA has flag VM_PFNMAP. With this change, when pinning a region which is a raw

[PATCH] nfit: skip region registration for incomplete control regions

Per the ACPI specification the only functional purpose for a DIMM Control Region to be mapped into the system physical address space, from an OSPM perspective, is to support block-apertures. However, there are some BIOSen that publish DIMM Control Region SPA entries for pre-boot environment

Re: [PATCH v4 23/24] fpga: dfl: afu: add user afu sub feature support

On Wed, Mar 21, 2018 at 06:50:54PM -0500, Alan Tull wrote: > On Tue, Mar 20, 2018 at 2:10 AM, Wu Hao wrote: > > >> > +static int afu_mmap(struct file *filp, struct vm_area_struct *vma) > >> > +{ > >> > + struct fpga_afu_region region; > >> > + struct platform_device

[PATCH] nfit: skip region registration for incomplete control regions

Per the ACPI specification the only functional purpose for a DIMM Control Region to be mapped into the system physical address space, from an OSPM perspective, is to support block-apertures. However, there are some BIOSen that publish DIMM Control Region SPA entries for pre-boot environment

Re: [PATCH v4 23/24] fpga: dfl: afu: add user afu sub feature support

On Wed, Mar 21, 2018 at 06:50:54PM -0500, Alan Tull wrote: > On Tue, Mar 20, 2018 at 2:10 AM, Wu Hao wrote: > > >> > +static int afu_mmap(struct file *filp, struct vm_area_struct *vma) > >> > +{ > >> > + struct fpga_afu_region region; > >> > + struct platform_device *pdev =

Re: [PATCH v4 04/24] fpga: add device feature list support

On Wed, Mar 21, 2018 at 06:54:58PM -0500, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, > > > +static int > > +build_info_create_dev(struct build_feature_devs_info *binfo, > > + enum fpga_id_type type, const char *name, > > +

Re: [PATCH v4 04/24] fpga: add device feature list support

On Wed, Mar 21, 2018 at 06:54:58PM -0500, Alan Tull wrote: > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote: > > Hi Hao, > > > +static int > > +build_info_create_dev(struct build_feature_devs_info *binfo, > > + enum fpga_id_type type, const char *name, > > +

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

On Thu, 2018-03-22 at 13:37 +0900, y.k.oh wrote: > > On 03/14/2018 10:58 PM, Greg KH wrote: > > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote: > > > Cleanup checkpatch error: > > > ERROR: Macros with complex values should be enclosed in parentheses > > > > > > Signed-off-by:

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

On Thu, 2018-03-22 at 13:37 +0900, y.k.oh wrote: > > On 03/14/2018 10:58 PM, Greg KH wrote: > > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote: > > > Cleanup checkpatch error: > > > ERROR: Macros with complex values should be enclosed in parentheses > > > > > > Signed-off-by:

Re: [PATCH 0/7] HID core and multitouch fixups

On Tue, Mar 20, 2018 at 12:04:44PM +0100, Benjamin Tissoires wrote: > Hi, > > Patches 1 and 2 are related to the Razer Blade Stealth that has some dead zone > near the edges of the touchpad. > Patches 3 was previously sent and reviewed by Dmitry and he suggested patch 4 > at the time. > Patches

Re: [PATCH 0/7] HID core and multitouch fixups

On Tue, Mar 20, 2018 at 12:04:44PM +0100, Benjamin Tissoires wrote: > Hi, > > Patches 1 and 2 are related to the Razer Blade Stealth that has some dead zone > near the edges of the touchpad. > Patches 3 was previously sent and reviewed by Dmitry and he suggested patch 4 > at the time. > Patches

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

On 03/14/2018 10:58 PM, Greg KH wrote: > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote: >> Cleanup checkpatch error: >> ERROR: Macros with complex values should be enclosed in parentheses >> >> Signed-off-by: YOUNGKEUN OH >> --- >>

Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses

On 03/14/2018 10:58 PM, Greg KH wrote: > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote: >> Cleanup checkpatch error: >> ERROR: Macros with complex values should be enclosed in parentheses >> >> Signed-off-by: YOUNGKEUN OH >> --- >> drivers/tty/serial/samsung.c | 16

Re: [RESEND PATCH] crypto: Add zstd support

On (03/21/18 15:49), Nick Terrell wrote: > depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in Yikes! How come I missed that... :) > [0] > lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com Signed-off-by: Nick Terrell

Re: [RESEND PATCH] crypto: Add zstd support

On (03/21/18 15:49), Nick Terrell wrote: > depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in Yikes! How come I missed that... :) > [0] > lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com Signed-off-by: Nick Terrell ?

Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

CC: Vaneet Narang.   On (03/21/18 10:10), Maninder Singh wrote: > diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c > index cc7b6d4..185c358 100644 > --- a/lib/lz4/lz4_compress.c > +++ b/lib/lz4/lz4_compress.c > @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic( >

Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

CC: Vaneet Narang.   On (03/21/18 10:10), Maninder Singh wrote: > diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c > index cc7b6d4..185c358 100644 > --- a/lib/lz4/lz4_compress.c > +++ b/lib/lz4/lz4_compress.c > @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic( >

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

Hi Randy, Thanks for reviewing the patch. I will address below mentioned comments in next version of patch. Thanks, Naga Sureshkumar Relli. > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Thursday, March 15, 2018 5:27 AM > To:

RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver

Hi Randy, Thanks for reviewing the patch. I will address below mentioned comments in next version of patch. Thanks, Naga Sureshkumar Relli. > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Thursday, March 15, 2018 5:27 AM > To:

Re: [PATCH v5 4/5] typec: tcpm: Represent source supply through power_supply

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds a power_supply class instance to represent a PD source's voltage and current properties. This provides an interface for reading these properties from user-space or other drivers. For PPS enabled Sources, this also provides write

Re: [PATCH v5 4/5] typec: tcpm: Represent source supply through power_supply

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds a power_supply class instance to represent a PD source's voltage and current properties. This provides an interface for reading these properties from user-space or other drivers. For PPS enabled Sources, this also provides write

Re: [PATCH v5 3/5] power: supply: Add 'usb_type' property and supporting code

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds the 'usb_type' property to represent USB supplies which can report a number of different types based on a connection event. Examples of this already exist in drivers whereby the existing 'type' property is updated, based on an event,

Re: [PATCH v5 3/5] power: supply: Add 'usb_type' property and supporting code

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds the 'usb_type' property to represent USB supplies which can report a number of different types based on a connection event. Examples of this already exist in drivers whereby the existing 'type' property is updated, based on an event,

Re: [PATCH v5 1/5] typec: tcpm: Add core support for sink side PPS

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds code to handle requesting of PPS APDOs. Switching between standard PDOs and APDOs, and re-requesting an APDO to modify operating voltage/current will be triggered by an external call into TCPM. Signed-off-by: Adam Thomson

Re: [PATCH v5 1/5] typec: tcpm: Add core support for sink side PPS

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds code to handle requesting of PPS APDOs. Switching between standard PDOs and APDOs, and re-requesting an APDO to modify operating voltage/current will be triggered by an external call into TCPM. Signed-off-by: Adam Thomson Acked-by:

Re: [PATCH v5 5/5] typec: tcpm: Add support for sink PPS related messages

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds sink side support for Get_Status, Status, Get_PPS_Status and PPS_Status handling. As there's the potential for a partner to respond with Not_Supported, handling of this message is also added. Sending of Not_Supported is added to handle

Re: [PATCH v5 5/5] typec: tcpm: Add support for sink PPS related messages

On 03/20/2018 07:33 AM, Adam Thomson wrote: This commit adds sink side support for Get_Status, Status, Get_PPS_Status and PPS_Status handling. As there's the potential for a partner to respond with Not_Supported, handling of this message is also added. Sending of Not_Supported is added to handle

[PATCH] watchdog: booke_wdt: Disable the watchdog prior to setting a new timeout value in order to avoid the following situation

A watchdog timer exception also occurs if the selected time base bit transitions from 0 to 1 due to an mtspr that writes a 1 to the bit when its previous value was 0. Signed-off-by: Xiaofeng Wei --- drivers/watchdog/booke_wdt.c | 6 ++ 1 file changed, 6 insertions(+)

[PATCH] watchdog: booke_wdt: Disable the watchdog prior to setting a new timeout value in order to avoid the following situation

A watchdog timer exception also occurs if the selected time base bit transitions from 0 to 1 due to an mtspr that writes a 1 to the bit when its previous value was 0. Signed-off-by: Xiaofeng Wei --- drivers/watchdog/booke_wdt.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 0/2] Kexec_file: Load kernel at top of system ram

The current kexec_file ignores kexec_buf.top_down value when call arch_kexec_walk_mem() to allocate memory for loading kernel/initrd stuffs. This is not supposed to be what kexec_buf.top_down is used for. In patch 0001, introduce a new function walk_system_ram_res_rev() which is a variant of

[PATCH 1/2] resource: add walk_system_ram_res_rev()

From: AKASHI Takahiro This function, being a variant of walk_system_ram_res() introduced in commit 8c86e70acead ("resource: provide new functions to walk through resources"), walks through a list of all the resources of System RAM in reversed order, i.e., from higher

[PATCH 0/2] Kexec_file: Load kernel at top of system ram

The current kexec_file ignores kexec_buf.top_down value when call arch_kexec_walk_mem() to allocate memory for loading kernel/initrd stuffs. This is not supposed to be what kexec_buf.top_down is used for. In patch 0001, introduce a new function walk_system_ram_res_rev() which is a variant of

[PATCH 1/2] resource: add walk_system_ram_res_rev()

From: AKASHI Takahiro This function, being a variant of walk_system_ram_res() introduced in commit 8c86e70acead ("resource: provide new functions to walk through resources"), walks through a list of all the resources of System RAM in reversed order, i.e., from higher to lower. It will be used

[PATCH 2/2] kexec_file: Load kernel at top of system RAM if required

For kexec_file loading, if kexec_buf.top_down is 'true', the memory which is used to load kernel/initrd/purgatory is supposed to be allocated from top to down. This is also consistent with the old kexec loading interface. However, the current arch_kexec_walk_mem() doesn't do like this. It ignores

[PATCH 2/2] kexec_file: Load kernel at top of system RAM if required

For kexec_file loading, if kexec_buf.top_down is 'true', the memory which is used to load kernel/initrd/purgatory is supposed to be allocated from top to down. This is also consistent with the old kexec loading interface. However, the current arch_kexec_walk_mem() doesn't do like this. It ignores

[PATCH] arm: avoid race condition issue in dump_backtrace

When we dump the backtrace of some specific task, there is a potential race condition due to the task may be running on other cores if SMP enabled. That is because for current implementation, if the task is not the current task, we will get the registers used for unwind from cpu_context saved in

[PATCH] arm: avoid race condition issue in dump_backtrace

When we dump the backtrace of some specific task, there is a potential race condition due to the task may be running on other cores if SMP enabled. That is because for current implementation, if the task is not the current task, we will get the registers used for unwind from cpu_context saved in

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

On 21-03-18, 18:21, Shunyong Yang wrote: > When multiple cpus are related in one cpufreq policy, the first online cpu > will be chosen by default to handle cpufreq operations. In a CPPC case, > let's take two related cpus, cpu0 and cpu1 as an example. > > After system start, cpu0 is the first

Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online

On 21-03-18, 18:21, Shunyong Yang wrote: > When multiple cpus are related in one cpufreq policy, the first online cpu > will be chosen by default to handle cpufreq operations. In a CPPC case, > let's take two related cpus, cpu0 and cpu1 as an example. > > After system start, cpu0 is the first

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote: > > > On 2018年03月20日 12:26, Jonathan Helman wrote: > > > On Mar 19, 2018, at 7:31 PM, Jason Wang wrote: > > > > > > > > > > > > On 2018年03月20日 06:14, Jonathan Helman wrote: > > > > Export the number of

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote: > > > On 2018年03月20日 12:26, Jonathan Helman wrote: > > > On Mar 19, 2018, at 7:31 PM, Jason Wang wrote: > > > > > > > > > > > > On 2018年03月20日 06:14, Jonathan Helman wrote: > > > > Export the number of successful and failed hugetlb

[PATCH] arm64: avoid race condition issue in dump_backtrace

When we dump the backtrace of some specific task, there is a potential race condition due to the task may be running on other cores if SMP enabled. That is because for current implementation, if the task is not the current task, we will get the registers used for unwind from cpu_context saved in

[PATCH] arm64: avoid race condition issue in dump_backtrace

When we dump the backtrace of some specific task, there is a potential race condition due to the task may be running on other cores if SMP enabled. That is because for current implementation, if the task is not the current task, we will get the registers used for unwind from cpu_context saved in

[PATCH v4 4/5] pintcrl: support bias-disable of generic and special pins simultaneously

For generic pins, parameter "arg" is 0 or 1. For special pins, bias-disable is set by R0R1, so we need transmited "00" to set bias-disable When we set "bias-disable" as high-z property, the parameter should be "MTK_PUPD_SET_R1R0_00". Signed-off-by: Zhiyong Tao ---

[PATCH v4 4/5] pintcrl: support bias-disable of generic and special pins simultaneously

For generic pins, parameter "arg" is 0 or 1. For special pins, bias-disable is set by R0R1, so we need transmited "00" to set bias-disable When we set "bias-disable" as high-z property, the parameter should be "MTK_PUPD_SET_R1R0_00". Signed-off-by: Zhiyong Tao ---

[PATCH v4 3/5] pinctrl: add mt2712 pinctrl driver

The commit includes mt2712 pinctrl driver. Signed-off-by: Zhiyong Tao --- drivers/pinctrl/mediatek/Kconfig |7 + drivers/pinctrl/mediatek/Makefile |1 + drivers/pinctrl/mediatek/pinctrl-mt2712.c | 634 +

[PATCH v4 3/5] pinctrl: add mt2712 pinctrl driver

The commit includes mt2712 pinctrl driver. Signed-off-by: Zhiyong Tao --- drivers/pinctrl/mediatek/Kconfig |7 + drivers/pinctrl/mediatek/Makefile |1 + drivers/pinctrl/mediatek/pinctrl-mt2712.c | 634 + drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h

[PATCH v4 0/5] PINCTRL: Mediatek pinctrl driver for mt2712

This series includes five patches: 1.Add mt2712 pintcrl head file. 2.Add mt2712 pinctrl device node. 3.Add mt2712 pinctrl driver. 4.Support bias-disable of generic and special pins simultaneously. 5.fix check warnings. Changes in patch v4: 1)fix check warnings for mt2712. 2)add fix check warnings

[PATCH v4 0/5] PINCTRL: Mediatek pinctrl driver for mt2712

This series includes five patches: 1.Add mt2712 pintcrl head file. 2.Add mt2712 pinctrl device node. 3.Add mt2712 pinctrl driver. 4.Support bias-disable of generic and special pins simultaneously. 5.fix check warnings. Changes in patch v4: 1)fix check warnings for mt2712. 2)add fix check warnings

[PATCH v4 2/5] arm64: dts: mt2712: add pintcrl device node.

This patch adds pintcrl device node for mt2712. Signed-off-by: Zhiyong Tao --- arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi

[PATCH v4 2/5] arm64: dts: mt2712: add pintcrl device node.

This patch adds pintcrl device node for mt2712. Signed-off-by: Zhiyong Tao --- arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi index

[PATCH v4 1/5] arm64: dts: mt2712: add pintcrl file

This patch adds pinctrl file for mt2712. Signed-off-by: Zhiyong Tao Reviewed-by: Rob Herring --- arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 + 1 file changed, 1123 insertions(+) create mode 100644

[PATCH v4 1/5] arm64: dts: mt2712: add pintcrl file

This patch adds pinctrl file for mt2712. Signed-off-by: Zhiyong Tao Reviewed-by: Rob Herring --- arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 + 1 file changed, 1123 insertions(+) create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h diff --git

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

On Wed, Mar 21, 2018 at 06:29:41PM -0700, Nick Terrell wrote: > This patch set adds support for a ZSTD-compressed kernel and ramdisk > images in the kernel boot process. It only integrates the support with > x86, though the first patch is generic to all architectures. I'm running this patch set

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

On Wed, Mar 21, 2018 at 06:29:41PM -0700, Nick Terrell wrote: > This patch set adds support for a ZSTD-compressed kernel and ramdisk > images in the kernel boot process. It only integrates the support with > x86, though the first patch is generic to all architectures. I'm running this patch set

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

On (03/21/18 19:56), Nick Terrell wrote: [..] > This seems like a reasonable extension to the algorithm, and it looks like > LZ4_DYN is about a 5% improvement to compression ratio on your benchmark. > The biggest question I have is if it is worthwhile to maintain a separate > incompatible variant

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

On (03/21/18 19:56), Nick Terrell wrote: [..] > This seems like a reasonable extension to the algorithm, and it looks like > LZ4_DYN is about a 5% improvement to compression ratio on your benchmark. > The biggest question I have is if it is worthwhile to maintain a separate > incompatible variant

Re: [PATCH][next] phy: qcom-qusb2: fix missing assignment to an error return code

On 3/21/2018 11:15 PM, Colin King wrote: From: Colin Ian King The error return code is not being assigned to ret from the call to clk_prepare_enable and consequently the current check on ret picks up the previous error return. Fix this by adding in the missing

Re: [PATCH][next] phy: qcom-qusb2: fix missing assignment to an error return code

On 3/21/2018 11:15 PM, Colin King wrote: From: Colin Ian King The error return code is not being assigned to ret from the call to clk_prepare_enable and consequently the current check on ret picks up the previous error return. Fix this by adding in the missing assignment to ret. Detected by

Re: [Bug 199003] console stalled, cause Hard LOCKUP.

On (03/22/18 11:14), Sergey Senozhatsky wrote: [..] > Looking at > > printk()->call_console_drivers()->serial8250_console_putchar()->wait_for_xmitr() > > ... wait_for_xmitr() can spin for over 1 second waiting for the UART_MSR_CTS > bit. [..] > a 1+ second long busy loop in the console driver

Re: [Bug 199003] console stalled, cause Hard LOCKUP.

On (03/22/18 11:14), Sergey Senozhatsky wrote: [..] > Looking at > > printk()->call_console_drivers()->serial8250_console_putchar()->wait_for_xmitr() > > ... wait_for_xmitr() can spin for over 1 second waiting for the UART_MSR_CTS > bit. [..] > a 1+ second long busy loop in the console driver

Re: questions about header.S

Thanks very much for you hint! On 03/21/2018 05:57 PM, Thomas Gleixner wrote: > On Wed, 21 Mar 2018, Cao jin wrote: >> On 03/17/2018 06:01 PM, Cao jin wrote: >>>   I find two small questions which confuse me a little. >>> >>> 1. >>> # Check signature at end of setup >>>cmpl

Re: questions about header.S

Thanks very much for you hint! On 03/21/2018 05:57 PM, Thomas Gleixner wrote: > On Wed, 21 Mar 2018, Cao jin wrote: >> On 03/17/2018 06:01 PM, Cao jin wrote: >>>   I find two small questions which confuse me a little. >>> >>> 1. >>> # Check signature at end of setup >>>cmpl

Re: [PATCH v2] f2fs: no need to initialize zero value for GFP_F2FS_ZERO

On 2018/3/22 10:08, Yunlong Song wrote: > Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not > need to initialize zero value for its member any more. > > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu Thanks,

Re: [PATCH v2] f2fs: no need to initialize zero value for GFP_F2FS_ZERO

On 2018/3/22 10:08, Yunlong Song wrote: > Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not > need to initialize zero value for its member any more. > > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu Thanks,

Re: [PATCH v3 6/7] arm: dts: sun8i: a33: Add the DSI-related nodes

On Tue, Mar 6, 2018 at 9:56 PM, Maxime Ripard wrote: > From: Maxime Ripard > > The A33 has a MIPI-DSI block, along with its D-PHY. Let's add it in order > to use it in the relevant boards. > > Signed-off-by: Maxime Ripard

Re: [PATCH v3 6/7] arm: dts: sun8i: a33: Add the DSI-related nodes

On Tue, Mar 6, 2018 at 9:56 PM, Maxime Ripard wrote: > From: Maxime Ripard > > The A33 has a MIPI-DSI block, along with its D-PHY. Let's add it in order > to use it in the relevant boards. > > Signed-off-by: Maxime Ripard > --- > arch/arm/boot/dts/sun8i-a33.dtsi | 44

Re: [PATCH 1/2] ACPI / PM: Use register_reboot_notifier() instead of pm_power_off_prepare

Hi Pavel, On 21 March 2018 at 22:04, Pavel Machek wrote: > On Wed 2018-03-21 19:30:16, Baolin Wang wrote: >> We can register one notifier through register_reboot_notifier() function to >> prepare to power off the system, then we can remove the >> 'pm_power_off_prepare' >> hook in

Re: [PATCH 1/2] ACPI / PM: Use register_reboot_notifier() instead of pm_power_off_prepare

Hi Pavel, On 21 March 2018 at 22:04, Pavel Machek wrote: > On Wed 2018-03-21 19:30:16, Baolin Wang wrote: >> We can register one notifier through register_reboot_notifier() function to >> prepare to power off the system, then we can remove the >> 'pm_power_off_prepare' >> hook in following

linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/gvt/scheduler.c between commit: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx") from Linus' tree and commit: b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is

linux-next: manual merge of the drm-intel tree with Linus' tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/gvt/scheduler.c between commit: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx") from Linus' tree and commit: b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is

[PATCH] usbip: tools: usbipd: exclude exported devices from exportable device list

usbipd includes exported devices in response to exportable device list. Exclude exported devices from exportable device list to avoid: - import requests for devices that are exported only to fail the request. - revealing devices that are imported by a client to another client. Signed-off-by:

[PATCH] usbip: tools: usbipd: exclude exported devices from exportable device list

usbipd includes exported devices in response to exportable device list. Exclude exported devices from exportable device list to avoid: - import requests for devices that are exported only to fail the request. - revealing devices that are imported by a client to another client. Signed-off-by:

  1   2   3   4   5   6   7   8   9   10   >