[PATCH] staging: lustre: lnet: prefer kcalloc over kzalloc with multiply

Use kcalloc for allocating an array instead of kzalloc with multiply. kcalloc is the preferred API. Issue reported by checkpatch.pl Signed-off-by: Sumit Pundir --- drivers/staging/lustre/lnet/lnet/config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH] staging: lustre: lnet: prefer kcalloc over kzalloc with multiply

Use kcalloc for allocating an array instead of kzalloc with multiply. kcalloc is the preferred API. Issue reported by checkpatch.pl Signed-off-by: Sumit Pundir --- drivers/staging/lustre/lnet/lnet/config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

tsov/x86-kvm-hyperv-stable-clocksorce-for-L2-guests-when-running-nested-KVM-on-Hyper-V/20180119-160814 > > config: x86_64-allmodconfig (attached as .config) > > compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025 > > reproduce: > > # save the attached .config to linux

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

0180118] > > [cannot apply to tip/x86/core kvm/linux-next] > > [if your patch is applied to the wrong git tree, please drop us a note to > > help improve the system] > > > > url: > > https://github.com/0day-ci/linux/commits/Vitaly-Kuznetsov/x86-kvm-hype

[PATCH] f2fs: correct removexattr behavior for null valued extended attribute

From: Daeho Jeong __vfs_removexattr() transfers "NULL" value to the setxattr handler of the f2fs filesystem in order to remove the extended attribute. But, __f2fs_setxattr() just ignores the removal request when the value of the extended attribute is already NULL. We

[PATCH] f2fs: correct removexattr behavior for null valued extended attribute

From: Daeho Jeong __vfs_removexattr() transfers "NULL" value to the setxattr handler of the f2fs filesystem in order to remove the extended attribute. But, __f2fs_setxattr() just ignores the removal request when the value of the extended attribute is already NULL. We have to remove the extended

Re: [PATCH v2 4/8] watchdog: JZ4740: Drop module remove function

Hi Paul, On 30 December 2017 at 19:21, Paul Cercueil wrote: > When the watchdog was configured for nowayout, and after the > userspace watchdog daemon closed the dev node without sending the > magic character, unloading this module stopped the watchdog > hardware, which was

Re: [PATCH v2 4/8] watchdog: JZ4740: Drop module remove function

Hi Paul, On 30 December 2017 at 19:21, Paul Cercueil wrote: > When the watchdog was configured for nowayout, and after the > userspace watchdog daemon closed the dev node without sending the > magic character, unloading this module stopped the watchdog > hardware, which was clearly a problem. >

Re: ACPI: sbshc: remove raw pointer from printk message

On Sat, Jan 20, 2018 at 12:53:39AM +0100, Rafael J. Wysocki wrote: > On Fri, Jan 19, 2018 at 10:06 AM, Greg Kroah-Hartman > wrote: > > There's no need to be printing a raw kernel pointer to the kernel log at > > every boot. So just remove it, and change the whole

Re: ACPI: sbshc: remove raw pointer from printk message

On Sat, Jan 20, 2018 at 12:53:39AM +0100, Rafael J. Wysocki wrote: > On Fri, Jan 19, 2018 at 10:06 AM, Greg Kroah-Hartman > wrote: > > There's no need to be printing a raw kernel pointer to the kernel log at > > every boot. So just remove it, and change the whole message to use the > > correct

Re: [PATCH v2 3/8] watchdog: JZ4740: Register a restart handler

Hi Paul, On 30 December 2017 at 19:21, Paul Cercueil wrote: > The watchdog driver can restart the system by simply configuring the > hardware for a timeout of 0 seconds. > > Signed-off-by: Paul Cercueil > Reviewed-by: Guenter Roeck

Re: [PATCH v2 3/8] watchdog: JZ4740: Register a restart handler

Hi Paul, On 30 December 2017 at 19:21, Paul Cercueil wrote: > The watchdog driver can restart the system by simply configuring the > hardware for a timeout of 0 seconds. > > Signed-off-by: Paul Cercueil > Reviewed-by: Guenter Roeck > --- > drivers/watchdog/jz4740_wdt.c | 9 + > 1 file

[tip:x86/platform] x86/jailhouse: Respect pci=lastbus command line settings

Commit-ID: 3b42349d56c96e144401d2317d8eeb9937511423 Gitweb: https://git.kernel.org/tip/3b42349d56c96e144401d2317d8eeb9937511423 Author: Jan Kiszka AuthorDate: Fri, 19 Jan 2018 11:06:30 +0100 Committer: Thomas Gleixner CommitDate: Sat, 20 Jan

[tip:x86/platform] x86/jailhouse: Respect pci=lastbus command line settings

Commit-ID: 3b42349d56c96e144401d2317d8eeb9937511423 Gitweb: https://git.kernel.org/tip/3b42349d56c96e144401d2317d8eeb9937511423 Author: Jan Kiszka AuthorDate: Fri, 19 Jan 2018 11:06:30 +0100 Committer: Thomas Gleixner CommitDate: Sat, 20 Jan 2018 08:15:44 +0100 x86/jailhouse: Respect

[tip:x86/platform] x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ

Commit-ID: 11f19ec025dd421c54978c69e42d86758fa310de Gitweb: https://git.kernel.org/tip/11f19ec025dd421c54978c69e42d86758fa310de Author: Jan Kiszka AuthorDate: Fri, 19 Jan 2018 11:06:17 +0100 Committer: Thomas Gleixner CommitDate: Sat, 20 Jan

[tip:x86/platform] x86/jailhouse: Set X86_FEATURE_TSC_KNOWN_FREQ

Commit-ID: 11f19ec025dd421c54978c69e42d86758fa310de Gitweb: https://git.kernel.org/tip/11f19ec025dd421c54978c69e42d86758fa310de Author: Jan Kiszka AuthorDate: Fri, 19 Jan 2018 11:06:17 +0100 Committer: Thomas Gleixner CommitDate: Sat, 20 Jan 2018 08:15:43 +0100 x86/jailhouse: Set

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/19/18 13:20), Steven Rostedt wrote: [..] > I was thinking about this a bit more, and instead of offloading a > recursive printk, perhaps its best to simply throttle it. Because the > problem may not go away if a printk thread takes over, because the bug > is really the printk

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

On (01/19/18 13:20), Steven Rostedt wrote: [..] > I was thinking about this a bit more, and instead of offloading a > recursive printk, perhaps its best to simply throttle it. Because the > problem may not go away if a printk thread takes over, because the bug > is really the printk

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 01/19/2018 10:57 PM, Laura Abbott wrote: On 01/19/2018 10:15 PM, Tom Lendacky wrote: On 1/19/2018 11:25 PM, Gabriel C wrote: 2018-01-20 5:02 GMT+01:00 Laura Abbott : On 01/19/2018 06:23 PM, Gabriel C wrote: 2018-01-20 2:23 GMT+01:00 Laura Abbott :

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 01/19/2018 10:57 PM, Laura Abbott wrote: On 01/19/2018 10:15 PM, Tom Lendacky wrote: On 1/19/2018 11:25 PM, Gabriel C wrote: 2018-01-20 5:02 GMT+01:00 Laura Abbott : On 01/19/2018 06:23 PM, Gabriel C wrote: 2018-01-20 2:23 GMT+01:00 Laura Abbott : Hi, Hi , Fedora got multiple

Re: [PATCH v4 00/10] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams wrote: > Changes since v3 [1] > * Drop 'ifence_array_ptr' and associated compile-time + run-time > switching and just use the masking approach all the time. > > * Convert 'get_user' to use pointer sanitization via masking

Re: [PATCH v4 00/10] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 4:01 PM, Dan Williams wrote: > Changes since v3 [1] > * Drop 'ifence_array_ptr' and associated compile-time + run-time > switching and just use the masking approach all the time. > > * Convert 'get_user' to use pointer sanitization via masking rather than > lfence.

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 01/19/2018 10:15 PM, Tom Lendacky wrote: On 1/19/2018 11:25 PM, Gabriel C wrote: 2018-01-20 5:02 GMT+01:00 Laura Abbott : On 01/19/2018 06:23 PM, Gabriel C wrote: 2018-01-20 2:23 GMT+01:00 Laura Abbott : Hi, Hi , Fedora got multiple reports

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 01/19/2018 10:15 PM, Tom Lendacky wrote: On 1/19/2018 11:25 PM, Gabriel C wrote: 2018-01-20 5:02 GMT+01:00 Laura Abbott : On 01/19/2018 06:23 PM, Gabriel C wrote: 2018-01-20 2:23 GMT+01:00 Laura Abbott : Hi, Hi , Fedora got multiple reports of an early bootup crash post -rc8.

Re: [PATCH v4 2/3] arm64: allwinner: axp803: Add drivevbus regulator

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki wrote: > Add reg_drivevbus regualtor for boards which are using > external regulator to drive the OTG VBus through N_VBUSEN > PMIC pin. > > Signed-off-by: Jagan Teki Reviewed-by: Chen-Yu Tsai

Re: [PATCH v4 2/3] arm64: allwinner: axp803: Add drivevbus regulator

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki wrote: > Add reg_drivevbus regualtor for boards which are using > external regulator to drive the OTG VBus through N_VBUSEN > PMIC pin. > > Signed-off-by: Jagan Teki Reviewed-by: Chen-Yu Tsai

Re: [PATCH v4 1/3] regulator: axp20x: add drivevbus support for axp803

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki wrote: > Like axp221, axp223, axp813 the axp803 is also supporting external > regulator to drive the OTG VBus through N_VBUSEN PMIC pin. > > Add support for it. > > Signed-off-by: Jagan Teki >

Re: [PATCH v4 1/3] regulator: axp20x: add drivevbus support for axp803

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki wrote: > Like axp221, axp223, axp813 the axp803 is also supporting external > regulator to drive the OTG VBus through N_VBUSEN PMIC pin. > > Add support for it. > > Signed-off-by: Jagan Teki > Reviewed-by: Rob Herring Reviewed-by: Chen-Yu Tsai

Re: [PATCH v4 3/3] arm64: allwinner: a64: bananapi-m64: add usb otg

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki wrote: > Add usb otg support for bananapi-m64 board, > - USB-ID connected with PH9 > - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC > > Signed-off-by: Jagan Teki > --- > Changes for v4: > -

Re: [PATCH v4 3/3] arm64: allwinner: a64: bananapi-m64: add usb otg

On Fri, Jan 12, 2018 at 2:30 PM, Jagan Teki wrote: > Add usb otg support for bananapi-m64 board, > - USB-ID connected with PH9 > - USB-DRVVBUS controlled by N_VBUSEN pin from PMIC > > Signed-off-by: Jagan Teki > --- > Changes for v4: > - rebase on master > - tested otg host mode. > Changes for

[PATCH v7 7/7] PCI/DPC: Enumerate the devices after DPC trigger event

Implement error_resume callback in DPC so, after DPC trigger event enumerates the devices beneath. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c index 7838b02..352f7f0 100644 --- a/drivers/pci/pcie/pcie-dpc.c +++

[PATCH v7 5/7] PCI/AER: Unify aer error defines at single space

This patch moves AER error defines to drivers/pci/pci.h. So that it unifies the error repoting codes at single place along with dpc Signed-off-by: Oza Pawandeep diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 6402f7f..216ee47 100644 ---

[PATCH v7 4/7] PCI/DPC: Unify and plumb error handling into DPC

Current DPC driver does not do recovery, e.g. calling end-point's driver's callbacks, which sanitize the sw. DPC driver implements link_reset callback, and calls pci_do_recovery. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index

[PATCH v7 6/7] PCI: Unify wait for link active into generic pci

Clients such as pciehp, dpc are using pcie_wait_link_active, which waits till the link becomes active or inactive. Made generic function and moved it to drivers/pci/pci.c Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/hotplug/pciehp_hpc.c

[PATCH v7 5/7] PCI/AER: Unify aer error defines at single space

This patch moves AER error defines to drivers/pci/pci.h. So that it unifies the error repoting codes at single place along with dpc Signed-off-by: Oza Pawandeep diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 6402f7f..216ee47 100644 --- a/drivers/acpi/apei/ghes.c +++

[PATCH v7 4/7] PCI/DPC: Unify and plumb error handling into DPC

Current DPC driver does not do recovery, e.g. calling end-point's driver's callbacks, which sanitize the sw. DPC driver implements link_reset callback, and calls pci_do_recovery. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index 665ff6c..3b79593 100644 ---

[PATCH v7 6/7] PCI: Unify wait for link active into generic pci

Clients such as pciehp, dpc are using pcie_wait_link_active, which waits till the link becomes active or inactive. Made generic function and moved it to drivers/pci/pci.c Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index

[PATCH v7 7/7] PCI/DPC: Enumerate the devices after DPC trigger event

Implement error_resume callback in DPC so, after DPC trigger event enumerates the devices beneath. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c index 7838b02..352f7f0 100644 --- a/drivers/pci/pcie/pcie-dpc.c +++

[PATCH v7 1/7] PCI/AER: Rename error recovery to generic pci naming

This patch renames error recovery to generic name with pci prefix Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c index 7448052..6cb1b36 100644 --- a/drivers/pci/pcie/aer/aerdrv_core.c +++

[PATCH v7 1/7] PCI/AER: Rename error recovery to generic pci naming

This patch renames error recovery to generic name with pci prefix Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c index 7448052..6cb1b36 100644 --- a/drivers/pci/pcie/aer/aerdrv_core.c +++ b/drivers/pci/pcie/aer/aerdrv_core.c @@

[PATCH v7 2/7] PCI/AER: factor out error reporting from AER

This patch factors out error reporting callbacks, which are currently tightly coupled with AER. DPC should be able to register callbacks and attmept recovery when DPC trigger event occurs. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index

[PATCH v7 3/7] PCI/ERR: add mutex to synchronize recovery

This patch protects pci_do_recovery with mutex. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c index a532fe0..8318c84 100644 --- a/drivers/pci/pcie/pcie-err.c +++ b/drivers/pci/pcie/pcie-err.c @@ -20,6 +20,8 @@ #include

[PATCH v7 2/7] PCI/AER: factor out error reporting from AER

This patch factors out error reporting callbacks, which are currently tightly coupled with AER. DPC should be able to register callbacks and attmept recovery when DPC trigger event occurs. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index f6b58b3..665ff6c

[PATCH v7 3/7] PCI/ERR: add mutex to synchronize recovery

This patch protects pci_do_recovery with mutex. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c index a532fe0..8318c84 100644 --- a/drivers/pci/pcie/pcie-err.c +++ b/drivers/pci/pcie/pcie-err.c @@ -20,6 +20,8 @@ #include #include

[PATCH v7 0/7] Address error and recovery for AER and DPC

This patch set brings in error handling support for DPC The current implementation of AER and error message broadcasting to the EP driver is tightly coupled and limited to AER service driver. It is important to factor out broadcasting and other link handling callbacks. So that not only when AER

[PATCH v7 0/7] Address error and recovery for AER and DPC

This patch set brings in error handling support for DPC The current implementation of AER and error message broadcasting to the EP driver is tightly coupled and limited to AER service driver. It is important to factor out broadcasting and other link handling callbacks. So that not only when AER

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 1/19/2018 11:25 PM, Gabriel C wrote: > 2018-01-20 5:02 GMT+01:00 Laura Abbott : >> On 01/19/2018 06:23 PM, Gabriel C wrote: >>> >>> 2018-01-20 2:23 GMT+01:00 Laura Abbott : Hi, >>> >>> >>> Hi , >>> Fedora got multiple reports of an

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 1/19/2018 11:25 PM, Gabriel C wrote: > 2018-01-20 5:02 GMT+01:00 Laura Abbott : >> On 01/19/2018 06:23 PM, Gabriel C wrote: >>> >>> 2018-01-20 2:23 GMT+01:00 Laura Abbott : Hi, >>> >>> >>> Hi , >>> Fedora got multiple reports of an early bootup crash post -rc8.

[PATCH] scsi: 3ware: use pci_iounmap instead of iounmap

'base_addr' has been mapped using 'pci_iomap()'. It should be freed with the corresponding 'pci_iounmap()' instead of 'iomap()'. Signed-off-by: Christophe JAILLET --- drivers/scsi/3w-sas.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] scsi: 3ware: use pci_iounmap instead of iounmap

'base_addr' has been mapped using 'pci_iomap()'. It should be freed with the corresponding 'pci_iounmap()' instead of 'iomap()'. Signed-off-by: Christophe JAILLET --- drivers/scsi/3w-sas.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/3w-sas.c

Re: [PATCH 1/1] ARM: dts: sunxi: Add Olimex A20-SOM204-EVB board

On Fri, Jan 19, 2018 at 9:27 PM, Stefan Mavrodiev wrote: > On 01/18/2018 04:28 PM, Chen-Yu Tsai wrote: >> >> On Thu, Jan 18, 2018 at 6:07 PM, Maxime Ripard >> wrote: >>> >>> Hi! >>> >>> On Mon, Jan 15, 2018 at 12:07:34PM +0200, Stefan

Re: [PATCH 1/1] ARM: dts: sunxi: Add Olimex A20-SOM204-EVB board

On Fri, Jan 19, 2018 at 9:27 PM, Stefan Mavrodiev wrote: > On 01/18/2018 04:28 PM, Chen-Yu Tsai wrote: >> >> On Thu, Jan 18, 2018 at 6:07 PM, Maxime Ripard >> wrote: >>> >>> Hi! >>> >>> On Mon, Jan 15, 2018 at 12:07:34PM +0200, Stefan Mavrodiev wrote: >> >> +/dts-v1/; >> +#include

Re: [PATCH] printk: drop redundant devkmsg_log_str memsets

On (01/19/18 09:17), Steven Rostedt wrote: > Yep, and even the sysctl checks for the terminating nul string, so > there's no leaks of any kind. > > Tested by adding: printk.devkmsg=on and running: > > $ hexdump -C /proc/sys/kernel/printk_devkmsg > 6f 6e 0a

Re: [PATCH] printk: drop redundant devkmsg_log_str memsets

On (01/19/18 09:17), Steven Rostedt wrote: > Yep, and even the sysctl checks for the terminating nul string, so > there's no leaks of any kind. > > Tested by adding: printk.devkmsg=on and running: > > $ hexdump -C /proc/sys/kernel/printk_devkmsg > 6f 6e 0a

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

2018-01-20 5:02 GMT+01:00 Laura Abbott : > On 01/19/2018 06:23 PM, Gabriel C wrote: >> >> 2018-01-20 2:23 GMT+01:00 Laura Abbott : >>> >>> Hi, >> >> >> Hi , >> >>> >>> Fedora got multiple reports of an early bootup crash post -rc8. >>> Bisection showed

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

2018-01-20 5:02 GMT+01:00 Laura Abbott : > On 01/19/2018 06:23 PM, Gabriel C wrote: >> >> 2018-01-20 2:23 GMT+01:00 Laura Abbott : >>> >>> Hi, >> >> >> Hi , >> >>> >>> Fedora got multiple reports of an early bootup crash post -rc8. >>> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Sat, Jan 20, 2018 at 02:02:37AM +, Al Viro wrote: > Note that those sizes are rather sensitive to lockdep, spinlock debugging, > etc. That they certainly are: on one of the testing .config I'm using it gave this: 1104 sizeof struct page = 56 81 sizeof struct

Re: [mm 4.15-rc8] Random oopses under memory pressure.

On Sat, Jan 20, 2018 at 02:02:37AM +, Al Viro wrote: > Note that those sizes are rather sensitive to lockdep, spinlock debugging, > etc. That they certainly are: on one of the testing .config I'm using it gave this: 1104 sizeof struct page = 56 81 sizeof struct

Re: [tip:sched/core] sched/rt: Simplify the IPI based RT balancing logic

Hi Steve, On Fri, Jan 19, 2018 at 02:51:15PM -0500, Steven Rostedt wrote: > On Sat, 20 Jan 2018 00:27:56 +0530 > Pavan Kondeti wrote: > > > Hi Steve, > > > > Thanks for the patch. > > > > On Fri, Jan 19, 2018 at 01:12:54PM -0500, Steven Rostedt wrote: > > > On Fri, 19

Re: [tip:sched/core] sched/rt: Simplify the IPI based RT balancing logic

Hi Steve, On Fri, Jan 19, 2018 at 02:51:15PM -0500, Steven Rostedt wrote: > On Sat, 20 Jan 2018 00:27:56 +0530 > Pavan Kondeti wrote: > > > Hi Steve, > > > > Thanks for the patch. > > > > On Fri, Jan 19, 2018 at 01:12:54PM -0500, Steven Rostedt wrote: > > > On Fri, 19 Jan 2018 13:11:21 -0500

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On 1/19/18 4:52 PM, Ming Lei wrote: > On Fri, Jan 19, 2018 at 10:38:41AM -0700, Jens Axboe wrote: >> On 1/19/18 9:37 AM, Ming Lei wrote: >>> On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote: On 1/19/18 9:26 AM, Ming Lei wrote: > On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jens

Re: [RFC PATCH] blk-mq: fixup RESTART when queue becomes idle

On 1/19/18 4:52 PM, Ming Lei wrote: > On Fri, Jan 19, 2018 at 10:38:41AM -0700, Jens Axboe wrote: >> On 1/19/18 9:37 AM, Ming Lei wrote: >>> On Fri, Jan 19, 2018 at 09:27:46AM -0700, Jens Axboe wrote: On 1/19/18 9:26 AM, Ming Lei wrote: > On Fri, Jan 19, 2018 at 09:19:24AM -0700, Jens

[PATCH 2/2] f2fs: recover some i_inline flags

This fixes lost i_inline flags during roll-forward. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 9 + 1 file changed, 9 insertions(+) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index cbeef73bc4dd..2354f1e05e19 100644 --- a/fs/f2fs/recovery.c +++

[PATCH 2/2] f2fs: recover some i_inline flags

This fixes lost i_inline flags during roll-forward. Signed-off-by: Jaegeuk Kim --- fs/f2fs/recovery.c | 9 + 1 file changed, 9 insertions(+) diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c index cbeef73bc4dd..2354f1e05e19 100644 --- a/fs/f2fs/recovery.c +++ b/fs/f2fs/recovery.c @@

[PATCH 1/2] f2fs: allow to recover node blocks given updated checkpoint

If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll- forward recovery. Let's relax the condition to recover them. Signed-off-by: Jaegeuk Kim --- fs/f2fs/node.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/node.h

[PATCH 1/2] f2fs: allow to recover node blocks given updated checkpoint

If fsck.f2fs changes crc, we have no way to recover some inode blocks by roll- forward recovery. Let's relax the condition to recover them. Signed-off-by: Jaegeuk Kim --- fs/f2fs/node.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 1/19/2018 8:38 PM, Linus Torvalds wrote: > On Fri, Jan 19, 2018 at 5:23 PM, Laura Abbott wrote: >> >> Fedora got multiple reports of an early bootup crash post -rc8. >> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce >> parameters for SME PGD mapping") . It

[PATCH] power: supply: da9030_battery: fix boolean value assignment in da9030_set_charge

Assign true or false to boolean variables instead of an integer value. This issue was detected with the help of Coccinelle. Fixes: 342d765e011f ("power_supply: Add Dialog DA9030 battery charger driver") Signed-off-by: Gustavo A. R. Silva ---

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 1/19/2018 8:38 PM, Linus Torvalds wrote: > On Fri, Jan 19, 2018 at 5:23 PM, Laura Abbott wrote: >> >> Fedora got multiple reports of an early bootup crash post -rc8. >> Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce >> parameters for SME PGD mapping") . It doesn't revert

[PATCH] power: supply: da9030_battery: fix boolean value assignment in da9030_set_charge

Assign true or false to boolean variables instead of an integer value. This issue was detected with the help of Coccinelle. Fixes: 342d765e011f ("power_supply: Add Dialog DA9030 battery charger driver") Signed-off-by: Gustavo A. R. Silva --- drivers/power/supply/da9030_battery.c | 4 ++-- 1

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 01/19/2018 06:23 PM, Gabriel C wrote: 2018-01-20 2:23 GMT+01:00 Laura Abbott : Hi, Hi , Fedora got multiple reports of an early bootup crash post -rc8. Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") . It doesn't revert

Re: Boot regression with bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") on top of -rc8

On 01/19/2018 06:23 PM, Gabriel C wrote: 2018-01-20 2:23 GMT+01:00 Laura Abbott : Hi, Hi , Fedora got multiple reports of an early bootup crash post -rc8. Bisection showed bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping") . It doesn't revert cleanly but if I

[PATCH] PCI: altera: Fix bool initialization in tlp_read_packet

Bool initializations should use true and false. This issue was detected with the help of Coccinelle. Fixes: eaa6111b70a7 ("PCI: altera: Add Altera PCIe host controller driver") Signed-off-by: Gustavo A. R. Silva --- drivers/pci/host/pcie-altera.c | 2 +- 1 file changed,

[PATCH] PCI: altera: Fix bool initialization in tlp_read_packet

Bool initializations should use true and false. This issue was detected with the help of Coccinelle. Fixes: eaa6111b70a7 ("PCI: altera: Add Altera PCIe host controller driver") Signed-off-by: Gustavo A. R. Silva --- drivers/pci/host/pcie-altera.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] iommu/mediatek: Move attach_device after iommu-group is ready for M4Uv1

In the commit 05f80300dc8b, the iommu framework has supposed all the iommu drivers have their owner iommu-group, it get rid of the FIXME workarounds while the group is NULL. But the flow of Mediatek M4U gen1 looks a bit trick that it will hang at this case:

[PATCH] iommu/mediatek: Move attach_device after iommu-group is ready for M4Uv1

In the commit 05f80300dc8b, the iommu framework has supposed all the iommu drivers have their owner iommu-group, it get rid of the FIXME workarounds while the group is NULL. But the flow of Mediatek M4U gen1 looks a bit trick that it will hang at this case:

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

Hi Icenowy, On Sat, Jan 20, 2018 at 2:10 PM, Icenowy Zheng wrote: > > > 于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby 写到: >>Hi Icenowy, >> >>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng >>wrote: >>> Add option for Allwinner ARMv5

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

Hi Icenowy, On Sat, Jan 20, 2018 at 2:10 PM, Icenowy Zheng wrote: > > > 于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby 写到: >>Hi Icenowy, >> >>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng >>wrote: >>> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die >>used >>> for many

[PATCH 5/6] ARM: da8xx: Move CFGCHIP registration to init_time

This moves the registration of the CFGCHIP syscon device to the init_time callback. This is in preparation of moving to the common clock framework. There are a number of clocks in this syscon device so it will be needed at this point in boot to register the clocks. In da850.c also move the PLL

[PATCH 4/6] ARM: davinci: move davinci_clk_init() to init_time

This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. dm646x is a special case because we need to handle different ref_clk rates depending on which

[PATCH 3/6] phy: da8xx-usb: rename clock con_ids

This renames the clock con_ids in the DA8XX USB PHY driver as well as the matching names in the mach clock registration code. This is in preparation for using device tree clocks where these names will become part of the device tree bindings. The new names more closely match the names used in the

[PATCH 6/6] phy: da8xx-usb: drop use of syscon_regmap_lookup_by_pdevname()

This drops the use of syscon_regmap_lookup_by_pdevname() from the DA8XX USB PHY driver. There are no longer any boards that register a syscon platform device, so it is no longer needed. Signed-off-by: David Lechner --- drivers/phy/ti/phy-da8xx-usb.c | 2 -- 1 file changed,

[PATCH 5/6] ARM: da8xx: Move CFGCHIP registration to init_time

This moves the registration of the CFGCHIP syscon device to the init_time callback. This is in preparation of moving to the common clock framework. There are a number of clocks in this syscon device so it will be needed at this point in boot to register the clocks. In da850.c also move the PLL

[PATCH 4/6] ARM: davinci: move davinci_clk_init() to init_time

This moves the call of davinci_clk_init() from map_io to init_time for all boards. This is the proper place to init clocks. This is also done in preparation for moving to the common clock framework. dm646x is a special case because we need to handle different ref_clk rates depending on which

[PATCH 3/6] phy: da8xx-usb: rename clock con_ids

This renames the clock con_ids in the DA8XX USB PHY driver as well as the matching names in the mach clock registration code. This is in preparation for using device tree clocks where these names will become part of the device tree bindings. The new names more closely match the names used in the

[PATCH 6/6] phy: da8xx-usb: drop use of syscon_regmap_lookup_by_pdevname()

This drops the use of syscon_regmap_lookup_by_pdevname() from the DA8XX USB PHY driver. There are no longer any boards that register a syscon platform device, so it is no longer needed. Signed-off-by: David Lechner --- drivers/phy/ti/phy-da8xx-usb.c | 2 -- 1 file changed, 2 deletions(-) diff

[PATCH 2/6] phy: da8xx-usb: Always check for syscon compatible

This slightly changes the logic for getting the CFGCHIP syscon register. We now always call syscon_regmap_lookup_by_compatible() even when not using device tree. This is in preparation for some changes in how the CFGCHIP syscon regmap is registered on da8xx platforms. Signed-off-by: David Lechner

[PATCH 0/6] ARM: davinci: common clock prep work

This series contains some changes needed for the conversion of arch/arm/mach- davinci to the common clock framework. Most of the boards in mach-davinci do not have device tree support. However, CFGCHIP, which is a syscon regmap, is needed during clock init in early boot. Using a platform device

[PATCH 2/6] phy: da8xx-usb: Always check for syscon compatible

This slightly changes the logic for getting the CFGCHIP syscon register. We now always call syscon_regmap_lookup_by_compatible() even when not using device tree. This is in preparation for some changes in how the CFGCHIP syscon regmap is registered on da8xx platforms. Signed-off-by: David Lechner

[PATCH 0/6] ARM: davinci: common clock prep work

This series contains some changes needed for the conversion of arch/arm/mach- davinci to the common clock framework. Most of the boards in mach-davinci do not have device tree support. However, CFGCHIP, which is a syscon regmap, is needed during clock init in early boot. Using a platform device

[PATCH 1/6] mfd: syscon: Add syscon_register() function

This adds a new syscon_register() function that creates a new syscon regmap and adds it to the lookup list. This function serves two purposes: 1. This is needed for platforms without device tree support where the syscon regmap is needed in early boot (e.g. clocks), because using a platform

[PATCH 1/6] mfd: syscon: Add syscon_register() function

This adds a new syscon_register() function that creates a new syscon regmap and adds it to the lookup list. This function serves two purposes: 1. This is needed for platforms without device tree support where the syscon regmap is needed in early boot (e.g. clocks), because using a platform

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby 写到: >Hi Icenowy, > >On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng >wrote: >> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die >used >> for many new F-series products, including

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby 写到: >Hi Icenowy, > >On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng >wrote: >> Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die >used >> for many new F-series products, including F1C100A, F1C100s, F1C200s, >> F1C500, F1C600).

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

Hi Icenowy, On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng wrote: > Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die used > for many new F-series products, including F1C100A, F1C100s, F1C200s, > F1C500, F1C600). > > Signed-off-by: Icenowy Zheng

Re: [linux-sunxi] [RFC PATCH 2/9] ARM: sunxi: add Allwinner ARMv5 SoCs

Hi Icenowy, On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng wrote: > Add option for Allwinner ARMv5 SoCs and a SoC suniv (which is a die used > for many new F-series products, including F1C100A, F1C100s, F1C200s, > F1C500, F1C600). > > Signed-off-by: Icenowy Zheng > --- >

Re: [linux-sunxi] [RFC PATCH 1/9] ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner SoCs

Hi Icenowy, On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng wrote: > Allwinner also has some ARMv5 SoCs. > > In order to add support for them, add a CONFIG_ARCH_SUNXI_V7 option that > is selectable when ARMv7 is selceted, and make CONFIG_ARCH_SUNXI a > common bool config which

Re: [linux-sunxi] [RFC PATCH 1/9] ARM: add CONFIG_ARCH_SUNXI_V7 for differentiate ARMv5/v7 Allwinner SoCs

Hi Icenowy, On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng wrote: > Allwinner also has some ARMv5 SoCs. > > In order to add support for them, add a CONFIG_ARCH_SUNXI_V7 option that > is selectable when ARMv7 is selceted, and make CONFIG_ARCH_SUNXI a > common bool config which is selected by

Re: [PATCH] watchdog: core: make sure the watchdog_worker is not deferred

On 01/18/2018 03:11 AM, Christophe Leroy wrote: commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has the effect of deferring timer handling in case of high CPU load, hence delaying the delayed work allthought the worker is running which high realtime priority. As hrtimers are not

Re: [PATCH] watchdog: core: make sure the watchdog_worker is not deferred

On 01/18/2018 03:11 AM, Christophe Leroy wrote: commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has the effect of deferring timer handling in case of high CPU load, hence delaying the delayed work allthought the worker is running which high realtime priority. As hrtimers are not

  1   2   3   4   5   6   7   8   9   10   >