Re: linux-next: build warnings after merge of the block tree

On 03/01/2018 05:56 AM, Stephen Rothwell wrote: > Hi Jens, > > After merging the block tree, today's linux-next build (x86_64 > allmodconfig) produced these warning: > > In file included from drivers/misc/cardreader/rts5209.c:24:0: > include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined >

Re: linux-next: build warnings after merge of the block tree

On 03/01/2018 05:56 AM, Stephen Rothwell wrote: > Hi Jens, > > After merging the block tree, today's linux-next build (x86_64 > allmodconfig) produced these warning: > > In file included from drivers/misc/cardreader/rts5209.c:24:0: > include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > Hi Everyone, So Oliver (CC) was having issues getting any of that to work for us. The problem is that acccording to him (I didn't double check the latest patches) you effectively hotplug the PCIe memory into the system when creating

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > Hi Everyone, So Oliver (CC) was having issues getting any of that to work for us. The problem is that acccording to him (I didn't double check the latest patches) you effectively hotplug the PCIe memory into the system when creating

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > > Hi Everyone, > > > So Oliver (CC) was having issues getting any of that to work for us. > > The problem is that acccording to him (I didn't double check the latest >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > > Hi Everyone, > > > So Oliver (CC) was having issues getting any of that to work for us. > > The problem is that acccording to him (I didn't double check the latest >

[PATCH v5] staging: typec: handle vendor defined part and modify drp toggling flow

From: ShuFan Lee Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export tcpci_irq. More operations can be extended in tcpci_data if needed. According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, TCPC shall not start DRP toggling until subsequently the

[PATCH v5] staging: typec: handle vendor defined part and modify drp toggling flow

From: ShuFan Lee Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export tcpci_irq. More operations can be extended in tcpci_data if needed. According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, TCPC shall not start DRP toggling until subsequently the TCPM writes to the

[PATCHv2] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

Let's add support for the GPIO controlled USB PHY on the MDM6600 modem. It is used on some Motorola Mapphone series of phones and tablets such as Droid 4. The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and is controlled by several GPIOs. The USB PHY is integrated into the

[PATCHv2] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

Let's add support for the GPIO controlled USB PHY on the MDM6600 modem. It is used on some Motorola Mapphone series of phones and tablets such as Droid 4. The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and is controlled by several GPIOs. The USB PHY is integrated into the

Re: [PATCH 11/12] PM / AVS: SmartReflex: Prepare to use device tree based probing

* Kevin Hilman [180301 03:08]: > Tony Lindgren writes: > > We are currently probing smartreflex with omap_device while we are > > already probing smartreflex related interconnect target module with > > ti-sysc driver and dts data. ... > Acked-by: Kevin

Re: [PATCH 11/12] PM / AVS: SmartReflex: Prepare to use device tree based probing

* Kevin Hilman [180301 03:08]: > Tony Lindgren writes: > > We are currently probing smartreflex with omap_device while we are > > already probing smartreflex related interconnect target module with > > ti-sysc driver and dts data. ... > Acked-by: Kevin Hilman > > I don't have anything else

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

On Wed, 2018-02-28 at 15:49 +0800, Zhiyong Tao wrote: > On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote: > > On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote: > > > For generic pins, parameter "arg" is 0 or 1. > > > For special pins, bias-disable is set by R0R1, > > > so we need transmited

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

On Wed, 2018-02-28 at 15:49 +0800, Zhiyong Tao wrote: > On Wed, 2018-02-28 at 15:33 +0800, Sean Wang wrote: > > On Mon, 2018-02-26 at 16:34 +0800, Zhiyong Tao wrote: > > > For generic pins, parameter "arg" is 0 or 1. > > > For special pins, bias-disable is set by R0R1, > > > so we need transmited

[PATCH v4] staging: typec: handle vendor defined part and modify drp toggling flow

From: ShuFanLee Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export tcpci_irq. More operations can be extended in tcpci_data if needed. According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, TCPC shall not start DRP toggling until subsequently the

[PATCH v4] staging: typec: handle vendor defined part and modify drp toggling flow

From: ShuFanLee Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export tcpci_irq. More operations can be extended in tcpci_data if needed. According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, TCPC shall not start DRP toggling until subsequently the TCPM writes to the

Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

* kbuild test robot [180219 07:47]: > > 354if (reset_gpio >= 0) >355gpiod_set_value_cansleep(reset_gpio, 1); Thanks this test can be just dropped. Will send out an updated version shortly. Regards, Tony

Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

* kbuild test robot [180219 07:47]: > > 354if (reset_gpio >= 0) >355gpiod_set_value_cansleep(reset_gpio, 1); Thanks this test can be just dropped. Will send out an updated version shortly. Regards, Tony

Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

* Rob Herring [180219 20:41]: > On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote: > > The GPIOs controlling MDM6600 are used to power MDM660 on and off, to > > MDM660 a typo? Thanks fixing. > > +Required properties: > > +- compatible Must be

Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

* Rob Herring [180219 20:41]: > On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote: > > The GPIOs controlling MDM6600 are used to power MDM660 on and off, to > > MDM660 a typo? Thanks fixing. > > +Required properties: > > +- compatible Must be "motorola,mapphone-mdm6600" > >

linux-next: Tree for Mar 1

Hi all, Changes since 20180228: The net-next tree gained a conflict against the net tree and also a build failure due to an interaction with the net tree for which I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 4348 4891 files changed, 184087 insertions(+), 124487

linux-next: Tree for Mar 1

Hi all, Changes since 20180228: The net-next tree gained a conflict against the net tree and also a build failure due to an interaction with the net tree for which I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 4348 4891 files changed, 184087 insertions(+), 124487

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi guys, if i'm reading the code right, the PM clk means: 1/ the clocks which would be enabled while power on 2/ these clocks are optional, it's ok if anything wrong with them 3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier) and currently we're adding all clocks of

Re: [PATCH] soc: rockchip: power-domain: remove PM clocks

Hi guys, if i'm reading the code right, the PM clk means: 1/ the clocks which would be enabled while power on 2/ these clocks are optional, it's ok if anything wrong with them 3/ controlled by pm_domain(or USE_PM_CLK_RUNTIME_OPS & pm_clk_add_notifier) and currently we're adding all clocks of

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

From: Bjorn Helgaas Date: Wed, 28 Feb 2018 17:08:29 -0600 > On Mon, Feb 19, 2018 at 10:30:25AM -0500, David Miller wrote: >> From: David Woodhouse >> Date: Mon, 19 Feb 2018 15:24:18 + >> >> >> For one, the sparc specific code allows mmap'ing any

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

From: Bjorn Helgaas Date: Wed, 28 Feb 2018 17:08:29 -0600 > On Mon, Feb 19, 2018 at 10:30:25AM -0500, David Miller wrote: >> From: David Woodhouse >> Date: Mon, 19 Feb 2018 15:24:18 + >> >> >> For one, the sparc specific code allows mmap'ing any address range >> >> within a PCI bus device. 

[PATCH] cpu_pm: add syscore_suspend error handling

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This will put the CPU in the correct state to resume from the failure. Signed-off-by: Derek Basehore --- kernel/cpu_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/cpu_pm.c

[PATCH] cpu_pm: add syscore_suspend error handling

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This will put the CPU in the correct state to resume from the failure. Signed-off-by: Derek Basehore --- kernel/cpu_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c index

[PATCH 1/2] dt-bindings: clock: mediatek: add binding for fixed-factor clock axisel_d4

From: Sean Wang Just add binding for a fixed-factor clock axisel_d4, which would be referenced by PWM devices on MT7623 or MT2701 SoC. Cc: sta...@vger.kernel.org Fixes: 1de9b21633d6 ("clk: mediatek: Add dt-bindings for MT2701 clocks") Signed-off-by: Sean Wang

[PATCH 2/2] clk: mediatek: fix PWM clock source by adding a fixed-factor clock

From: Sean Wang The clock for which all PWM devices on MT7623 or MT2701 actually depending on has to be divided by four from its parent clock axi_sel in the clock path prior to PWM devices. Consequently, adding a fixed-factor clock axisel_d4 as one-fourth of clock

[PATCH 1/2] dt-bindings: clock: mediatek: add binding for fixed-factor clock axisel_d4

From: Sean Wang Just add binding for a fixed-factor clock axisel_d4, which would be referenced by PWM devices on MT7623 or MT2701 SoC. Cc: sta...@vger.kernel.org Fixes: 1de9b21633d6 ("clk: mediatek: Add dt-bindings for MT2701 clocks") Signed-off-by: Sean Wang Cc: Rob Herring Cc: Mark Rutland

[PATCH 2/2] clk: mediatek: fix PWM clock source by adding a fixed-factor clock

From: Sean Wang The clock for which all PWM devices on MT7623 or MT2701 actually depending on has to be divided by four from its parent clock axi_sel in the clock path prior to PWM devices. Consequently, adding a fixed-factor clock axisel_d4 as one-fourth of clock axi_sel allows that PWM

[PATCH net-next 1/2] virtio-net: re enable XDP_REDIRECT for mergeable buffer

XDP_REDIRECT support for mergeable buffer was removed since commit 7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable() case"). This is because we don't reserve enough tailroom for struct skb_shared_info which breaks XDP assumption. Other complaints are, the complex linearize

[PATCH net-next 1/2] virtio-net: re enable XDP_REDIRECT for mergeable buffer

XDP_REDIRECT support for mergeable buffer was removed since commit 7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable() case"). This is because we don't reserve enough tailroom for struct skb_shared_info which breaks XDP assumption. Other complaints are, the complex linearize

[PATCH net-next 0/2] virtio-net: re enable XDP_REDIRECT for mergeable buffer

Hi: This series tries to re-enable XDP_REDIRECT for mergeable buffer which was removed since commit 7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable() case"). Main concerns are: - not enough tailroom was reserved which breaks cpumap - complex logic like EWMA and linearizing

[PATCH net-next 2/2] virtio-net: simplify XDP handling in small buffer

We used to do data copy through xdp_linearize_page() for the buffer without sufficient headroom, it brings extra complexity without helping for the performance. So this patch remove it and switch to use generic XDP routine to handle this case. Signed-off-by: Jason Wang ---

[PATCH net-next 0/2] virtio-net: re enable XDP_REDIRECT for mergeable buffer

Hi: This series tries to re-enable XDP_REDIRECT for mergeable buffer which was removed since commit 7324f5399b06 ("virtio_net: disable XDP_REDIRECT in receive_mergeable() case"). Main concerns are: - not enough tailroom was reserved which breaks cpumap - complex logic like EWMA and linearizing

[PATCH net-next 2/2] virtio-net: simplify XDP handling in small buffer

We used to do data copy through xdp_linearize_page() for the buffer without sufficient headroom, it brings extra complexity without helping for the performance. So this patch remove it and switch to use generic XDP routine to handle this case. Signed-off-by: Jason Wang ---

ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!

Hi Robin, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 97ace515f01439d4cf6e898b4094040dc12d36e7 commit: e1a50de37860b3a93a9d643b09638db5aff47650 arm64: cputype: Silence Sparse warnings date: 12 days ago

ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!

Hi Robin, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 97ace515f01439d4cf6e898b4094040dc12d36e7 commit: e1a50de37860b3a93a9d643b09638db5aff47650 arm64: cputype: Silence Sparse warnings date: 12 days ago

Re: [PATCH v8 03/13] kexec_file,x86,powerpc: factor out kexec_file_ops functions

On Wed, Feb 28, 2018 at 08:38:00PM +0800, Dave Young wrote: > On 02/26/18 at 07:01pm, AKASHI Takahiro wrote: > > On Fri, Feb 23, 2018 at 05:24:59PM +0800, Dave Young wrote: > > > Hi AKASHI, > > > > > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote: > > > > As arch_kexec_kernel_*_{probe,load}(),

Re: [PATCH v8 03/13] kexec_file,x86,powerpc: factor out kexec_file_ops functions

On Wed, Feb 28, 2018 at 08:38:00PM +0800, Dave Young wrote: > On 02/26/18 at 07:01pm, AKASHI Takahiro wrote: > > On Fri, Feb 23, 2018 at 05:24:59PM +0800, Dave Young wrote: > > > Hi AKASHI, > > > > > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote: > > > > As arch_kexec_kernel_*_{probe,load}(),

Re: [PATCH] PCI/ASPM: Change type of threshold_ns variable to u32

On 02/28/2018 02:55 PM, Bjorn Helgaas wrote: On Tue, Feb 27, 2018 at 05:19:52PM -0600, Gustavo A. R. Silva wrote: It seems that the expression threshold_us * 1000 will never exceed the 32-bit limits [1]. So changing the type of threshold_ns from u64 to u32 seems sensible [2]. [1]

Re: [PATCH] PCI/ASPM: Change type of threshold_ns variable to u32

On 02/28/2018 02:55 PM, Bjorn Helgaas wrote: On Tue, Feb 27, 2018 at 05:19:52PM -0600, Gustavo A. R. Silva wrote: It seems that the expression threshold_us * 1000 will never exceed the 32-bit limits [1]. So changing the type of threshold_ns from u64 to u32 seems sensible [2]. [1]

[PATCH] uml: Fix build with recent glibc

From: Andi Kleen Newer glibc did some include namespace "cleanups" and removed struct ucontext and friends. This already broke a lot of software, and UML seems to be the latest victim. Use the typedefs which are still available. They also work on older glibcs.

[PATCH] uml: Fix build with recent glibc

From: Andi Kleen Newer glibc did some include namespace "cleanups" and removed struct ucontext and friends. This already broke a lot of software, and UML seems to be the latest victim. Use the typedefs which are still available. They also work on older glibcs. Signed-off-by: Andi Kleen ---

Re: [PATCH 11/12] PM / AVS: SmartReflex: Prepare to use device tree based probing

Tony Lindgren writes: > We are currently probing smartreflex with omap_device while we are > already probing smartreflex related interconnect target module with > ti-sysc driver and dts data. > > Before we can flip things on for ti-sysc, we need to prepare the > smartreflex

Re: [PATCH 11/12] PM / AVS: SmartReflex: Prepare to use device tree based probing

Tony Lindgren writes: > We are currently probing smartreflex with omap_device while we are > already probing smartreflex related interconnect target module with > ti-sysc driver and dts data. > > Before we can flip things on for ti-sysc, we need to prepare the > smartreflex driver a bit: > > 1.

Re: [PATCH v8 02/13] kexec_file: make an use of purgatory optional

On Wed, Feb 28, 2018 at 08:33:59PM +0800, Dave Young wrote: > On 02/26/18 at 07:24pm, AKASHI Takahiro wrote: > > On Fri, Feb 23, 2018 at 04:49:34PM +0800, Dave Young wrote: > > > Hi AKASHI, > > > > > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote: > > > > On arm64, no trampline code between old

Re: [PATCH v8 02/13] kexec_file: make an use of purgatory optional

On Wed, Feb 28, 2018 at 08:33:59PM +0800, Dave Young wrote: > On 02/26/18 at 07:24pm, AKASHI Takahiro wrote: > > On Fri, Feb 23, 2018 at 04:49:34PM +0800, Dave Young wrote: > > > Hi AKASHI, > > > > > > On 02/22/18 at 08:17pm, AKASHI Takahiro wrote: > > > > On arm64, no trampline code between old

Re: [PATCH v4] Revert "f2fs crypto: avoid unneeded memory allocation in ->readdir"

On 2018/3/1 10:50, Jaegeuk Kim wrote: > On 02/28, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2018/2/28 13:48, Jaegeuk Kim wrote: >>> Hi Yunlong, >>> >>> As Eric pointed out, how do you think using nohighmem for directory likewise >> >> I'd like to ask, at the beginning, why we choose to use highmem

Re: [PATCH v4] Revert "f2fs crypto: avoid unneeded memory allocation in ->readdir"

On 2018/3/1 10:50, Jaegeuk Kim wrote: > On 02/28, Chao Yu wrote: >> Hi Jaegeuk, >> >> On 2018/2/28 13:48, Jaegeuk Kim wrote: >>> Hi Yunlong, >>> >>> As Eric pointed out, how do you think using nohighmem for directory likewise >> >> I'd like to ask, at the beginning, why we choose to use highmem

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

Mathieu Malaterre writes: > When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the > array feature_properties is defined as an empty array, which in turn > triggers the following warning (treated as error on W=1): > > CC arch/powerpc/kernel/prom.o >

Re: [PATCH 01/21] powerpc: Remove warning on array size when empty

Mathieu Malaterre writes: > When neither CONFIG_ALTIVEC, nor CONFIG_VSX or CONFIG_PPC64 is defined, the > array feature_properties is defined as an empty array, which in turn > triggers the following warning (treated as error on W=1): > > CC arch/powerpc/kernel/prom.o >

Re: [f2fs-dev] [PATCH 1/5 v2] f2fs: add mount option for segment allocation policy

On 02/28, Chao Yu wrote: > On 2018/2/28 13:09, Jaegeuk Kim wrote: > > Change log from v1: > > - add doc :) > > > > This patch adds an mount option, "alloc_mode=%s" having two options, > > "default" > > and "reuse". > > > > In "alloc_mode=reuse" case, f2fs starts to allocate segments from 0'th

Re: [f2fs-dev] [PATCH 1/5 v2] f2fs: add mount option for segment allocation policy

On 02/28, Chao Yu wrote: > On 2018/2/28 13:09, Jaegeuk Kim wrote: > > Change log from v1: > > - add doc :) > > > > This patch adds an mount option, "alloc_mode=%s" having two options, > > "default" > > and "reuse". > > > > In "alloc_mode=reuse" case, f2fs starts to allocate segments from 0'th

[PATCH v2 3/3] x86: devicetree: fix device IRQ settings in DT

IRQ parameters for SoC devices connected directly to I/O APIC lines (without PCI IRQ routing) may be specified in the Device Tree. Called from DT IRQ parser, irq_create_fwspec_mapping() calls irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg. But x86-specific DT IRQ allocation

[PATCH v2 3/3] x86: devicetree: fix device IRQ settings in DT

IRQ parameters for SoC devices connected directly to I/O APIC lines (without PCI IRQ routing) may be specified in the Device Tree. Called from DT IRQ parser, irq_create_fwspec_mapping() calls irq_domain_alloc_irqs() with a pointer to irq_fwspec structure as @arg. But x86-specific DT IRQ allocation

[PATCH v2 0/3] x86: devicetree: re-enable x86-specific implementation

Fixing x86-specific DT implementation in the kernel allows reusing most of firmware code for SoC that have ARM core replaced with x86, e.g. SC9853i. Changes since first version:  * Splitting a single patch into three parts Ivan Gorinov (3):   x86: devicetree: call early_init_dt_verify()   x86:

[PATCH v2 0/3] x86: devicetree: re-enable x86-specific implementation

Fixing x86-specific DT implementation in the kernel allows reusing most of firmware code for SoC that have ARM core replaced with x86, e.g. SC9853i. Changes since first version:  * Splitting a single patch into three parts Ivan Gorinov (3):   x86: devicetree: call early_init_dt_verify()   x86:

[PATCH v2 1/3] x86: devicetree: call early_init_dt_verify()

Call to early_init_dt_verify() is required to prepare DTB data. It was called from arch/arm and arch/powerpc, but not arch/x86. Signed-off-by: Ivan Gorinov ---  arch/x86/kernel/devicetree.c | 1 +  1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/devicetree.c

[PATCH v2 2/3] x86: devicetree: enable multiprocessing in DT

Adding code to register processors described in Device Tree. APIC ID is specified in 'intel-apic_id' propery as used in U-Boot. First address specified in 'reg' is used as default APIC ID. Signed-off-by: Ivan Gorinov ---  arch/x86/kernel/devicetree.c | 26

[PATCH v2 1/3] x86: devicetree: call early_init_dt_verify()

Call to early_init_dt_verify() is required to prepare DTB data. It was called from arch/arm and arch/powerpc, but not arch/x86. Signed-off-by: Ivan Gorinov ---  arch/x86/kernel/devicetree.c | 1 +  1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/devicetree.c

[PATCH v2 2/3] x86: devicetree: enable multiprocessing in DT

Adding code to register processors described in Device Tree. APIC ID is specified in 'intel-apic_id' propery as used in U-Boot. First address specified in 'reg' is used as default APIC ID. Signed-off-by: Ivan Gorinov ---  arch/x86/kernel/devicetree.c | 26 --  1 file

Re: [PATCH v4] Revert "f2fs crypto: avoid unneeded memory allocation in ->readdir"

On 02/28, Chao Yu wrote: > Hi Jaegeuk, > > On 2018/2/28 13:48, Jaegeuk Kim wrote: > > Hi Yunlong, > > > > As Eric pointed out, how do you think using nohighmem for directory likewise > > I'd like to ask, at the beginning, why we choose to use highmem for dentry > page? > any history reason

Re: [PATCH] f2fs: fix to restore whint_mode in ->remount_fs

Hi Jaegeuk, On 2018/3/1 10:45, Jaegeuk Kim wrote: > On 02/28, Chao Yu wrote: >> From: Chao Yu >> >> If we fail in ->remount_fs, it needs to restore old whint_mode as other >> mount options. >> >> Fixes: e25afe01822f ("f2fs: support passing down write hints given by users >>

Re: [PATCH v4] Revert "f2fs crypto: avoid unneeded memory allocation in ->readdir"

On 02/28, Chao Yu wrote: > Hi Jaegeuk, > > On 2018/2/28 13:48, Jaegeuk Kim wrote: > > Hi Yunlong, > > > > As Eric pointed out, how do you think using nohighmem for directory likewise > > I'd like to ask, at the beginning, why we choose to use highmem for dentry > page? > any history reason

Re: [PATCH] f2fs: fix to restore whint_mode in ->remount_fs

Hi Jaegeuk, On 2018/3/1 10:45, Jaegeuk Kim wrote: > On 02/28, Chao Yu wrote: >> From: Chao Yu >> >> If we fail in ->remount_fs, it needs to restore old whint_mode as other >> mount options. >> >> Fixes: e25afe01822f ("f2fs: support passing down write hints given by users >> to block layer") >

[PATCH v2] hwmon: g762: handle cleanup with devm_add_action

Simplify code and use devm_add_action() to handle cleanup. Signed-off-by: Peng Hao --- drivers/hwmon/g762.c | 43 +-- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c index

[PATCH v2] hwmon: g762: handle cleanup with devm_add_action

Simplify code and use devm_add_action() to handle cleanup. Signed-off-by: Peng Hao --- drivers/hwmon/g762.c | 43 +-- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/drivers/hwmon/g762.c b/drivers/hwmon/g762.c index 6d1208b..49046b4 100644

Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

Hi, On Wed, Feb 28, 2018 at 08:39:42AM -0700, Jeffrey Hugo wrote: > On 2/27/2018 11:19 PM, AKASHI Takahiro wrote: > >Tyler, > > > ># I missed catching your patch as its subject doesn't contain arm64. > > > >On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar wrote: > >>Currently on arm64 ESRT

Re: [PATCH 0/2] ESRT fixes for relocatable kexec'd kernel

Hi, On Wed, Feb 28, 2018 at 08:39:42AM -0700, Jeffrey Hugo wrote: > On 2/27/2018 11:19 PM, AKASHI Takahiro wrote: > >Tyler, > > > ># I missed catching your patch as its subject doesn't contain arm64. > > > >On Fri, Feb 23, 2018 at 12:42:31PM -0700, Tyler Baicar wrote: > >>Currently on arm64 ESRT

[PATCH v3 1/2] mkfs.f2fs: support hot file extension

This patch adds new option '-E' to accept user configured hot file extension, in order to let kernel module handle hot/cold file's datas separately better. Signed-off-by: Chao Yu --- v3: - remove debug log. include/f2fs_fs.h | 5 ++-- mkfs/f2fs_format.c | 74

[PATCH v3 1/2] mkfs.f2fs: support hot file extension

This patch adds new option '-E' to accept user configured hot file extension, in order to let kernel module handle hot/cold file's datas separately better. Signed-off-by: Chao Yu --- v3: - remove debug log. include/f2fs_fs.h | 5 ++-- mkfs/f2fs_format.c | 74

Re: 4.16 regression: s2ram broken on non-PAE i686

Thomas Gleixner wrote: Woody, On Wed, 28 Feb 2018, Woody Suwalski wrote: Certainly. I understand you want dmesg output for kernels build with and without PAE, not just PAE=n on the cmdline :-) Here it is... Thanks for providing the data. It did not pinpoint the issue but at least it gave me

Re: 4.16 regression: s2ram broken on non-PAE i686

Thomas Gleixner wrote: Woody, On Wed, 28 Feb 2018, Woody Suwalski wrote: Certainly. I understand you want dmesg output for kernels build with and without PAE, not just PAE=n on the cmdline :-) Here it is... Thanks for providing the data. It did not pinpoint the issue but at least it gave me

Re: [PATCH] f2fs: fix to restore whint_mode in ->remount_fs

On 02/28, Chao Yu wrote: > From: Chao Yu > > If we fail in ->remount_fs, it needs to restore old whint_mode as other > mount options. > > Fixes: e25afe01822f ("f2fs: support passing down write hints given by users > to block layer") Hi Chao, It was not merged, so please

Re: [PATCH] f2fs: fix to restore whint_mode in ->remount_fs

On 02/28, Chao Yu wrote: > From: Chao Yu > > If we fail in ->remount_fs, it needs to restore old whint_mode as other > mount options. > > Fixes: e25afe01822f ("f2fs: support passing down write hints given by users > to block layer") Hi Chao, It was not merged, so please allow me to integrate

Re: [PATCH 4/5] f2fs: issue discard aggressively in the gc_urgent mode

Change log from v1: - relax more to issue discard commands This patch avoids to skip discard commands when user sets gc_urgent mode. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- fs/f2fs/segment.c | 11 +-- 1 file changed, 5 insertions(+),

Re: [PATCH 4/5] f2fs: issue discard aggressively in the gc_urgent mode

Change log from v1: - relax more to issue discard commands This patch avoids to skip discard commands when user sets gc_urgent mode. Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim --- fs/f2fs/segment.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git

[PATCH 2/2] auxdisplay: make PANEL a menuconfig

lay/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20180228.orig/drivers/auxdisplay/Kconfig +++ linux-next-20180228/drivers/auxdisplay/Kconfig @@ -166,7 +166,7 @@ config ARM_CHARLCD endif # AUXDISPLAY -config PANEL +menuconfig PANEL tristate

[PATCH 1/2] auxdisplay: fix broken menu

nko <andriy.shevche...@linux.intel.com> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sando...@gmail.com> Signed-off-by: Randy Dunlap <rdun...@infradead.org> --- drivers/auxdisplay/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-next-20180228.ori

[PATCH 2/2] auxdisplay: make PANEL a menuconfig

Signed-off-by: Randy Dunlap Cc: Miguel Ojeda Sandonis Acked-by: Geert Uytterhoeven Reviewed-by: Andy Shevchenko --- drivers/auxdisplay/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20180228.orig/drivers/auxdisplay/Kconfig +++ linux-next-20180228/drivers/auxdispl

[PATCH 1/2] auxdisplay: fix broken menu

unlap --- drivers/auxdisplay/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-next-20180228.orig/drivers/auxdisplay/Kconfig +++ linux-next-20180228/drivers/auxdisplay/Kconfig @@ -14,9 +14,6 @@ menuconfig AUXDISPLAY If you say N, all options i

Re: [PATCH v2 11/11] test_firmware: test three firmware kernel configs using a proc knob

On Thu, Mar 01, 2018 at 12:38:16AM +, Luis R. Rodriguez wrote: > On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote: > > On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote: > > > So for folks who enable CONFIG_FW_LOADER=y, they'd now be forced to gain > > > an > > >

Re: [PATCH v2 11/11] test_firmware: test three firmware kernel configs using a proc knob

On Thu, Mar 01, 2018 at 12:38:16AM +, Luis R. Rodriguez wrote: > On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote: > > On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote: > > > So for folks who enable CONFIG_FW_LOADER=y, they'd now be forced to gain > > > an > > >

Re: [PATCH] arm64: defconfig: Enable typec-phy and extcon-usbc-cros-ec for rk3399

On Wed, Feb 28, 2018 at 11:02 PM, Enric Balletbo i Serra wrote: > Enables typec phyter and extcon driver for cable detection that is used by > USB 3.0 controller for Rockchip rk3399 SoCs. > > Signed-off-by: Enric Balletbo i Serra

Re: [PATCH] arm64: defconfig: Enable typec-phy and extcon-usbc-cros-ec for rk3399

On Wed, Feb 28, 2018 at 11:02 PM, Enric Balletbo i Serra wrote: > Enables typec phyter and extcon driver for cable detection that is used by > USB 3.0 controller for Rockchip rk3399 SoCs. > > Signed-off-by: Enric Balletbo i Serra Tested-by: Alexandre Courbot Thanks! This fixes a USB

Re: [PATCH v2] pvcalls-front: 64-bit align flags

On 02/28/2018 09:05 PM, Stefano Stabellini wrote: We are using test_and_* operations on the status and flag fields of struct sock_mapping. However, these functions require the operand to be 64-bit aligned on arm64. Currently, only status is 64-bit aligned. Make status and flags explicitly

Re: [PATCH v2] pvcalls-front: 64-bit align flags

On 02/28/2018 09:05 PM, Stefano Stabellini wrote: We are using test_and_* operations on the status and flag fields of struct sock_mapping. However, these functions require the operand to be 64-bit aligned on arm64. Currently, only status is 64-bit aligned. Make status and flags explicitly

Re: ftrace: Proposal for an Alternative RecordMcount framework

On Wed, Feb 28, 2018 at 05:12:52AM +0800, Steven Rostedt wrote: > On Tue, 27 Feb 2018 18:04:26 +0800 > Alan Kao wrote: > > > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2] > > Note, doing it at that stage takes the longest time. It makes small

Re: ftrace: Proposal for an Alternative RecordMcount framework

On Wed, Feb 28, 2018 at 05:12:52AM +0800, Steven Rostedt wrote: > On Tue, 27 Feb 2018 18:04:26 +0800 > Alan Kao wrote: > > > 1. During the final linking stages, do "objdump vmlinux.o | grep ..." [2] > > Note, doing it at that stage takes the longest time. It makes small > changes much longer

[PATCH v2] pvcalls-front: 64-bit align flags

We are using test_and_* operations on the status and flag fields of struct sock_mapping. However, these functions require the operand to be 64-bit aligned on arm64. Currently, only status is 64-bit aligned. Make status and flags explicitly 64-bit aligned. Signed-off-by: Stefano Stabellini

[PATCH v2] pvcalls-front: 64-bit align flags

We are using test_and_* operations on the status and flag fields of struct sock_mapping. However, these functions require the operand to be 64-bit aligned on arm64. Currently, only status is 64-bit aligned. Make status and flags explicitly 64-bit aligned. Signed-off-by: Stefano Stabellini ---

Re: [PATCH V2] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert

Hi Bart Thanks for your precious time to review this and kindly detailed response. On 03/01/2018 01:52 AM, Bart Van Assche wrote: > On Wed, 2018-02-28 at 16:55 +0800, Jianchao Wang wrote: >> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c >> index a86df9c..6fa7b0c 100644 >> ---

Re: [PATCH V2] scsi: core: use blk_mq_requeue_request in __scsi_queue_insert

Hi Bart Thanks for your precious time to review this and kindly detailed response. On 03/01/2018 01:52 AM, Bart Van Assche wrote: > On Wed, 2018-02-28 at 16:55 +0800, Jianchao Wang wrote: >> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c >> index a86df9c..6fa7b0c 100644 >> ---

Re: [PATCH] irqchip/gic-v3-its: handle rd_idx wrapping in its_wait_for_range_completion()

On 2018/2/12 2:45, Marc Zyngier wrote: Hi, Marc Sorry for replying so late. On Sun, 11 Feb 2018 03:42:01 +, Yang Yingliang wrote: Hi Yang, In direct case, rd_idx will wrap if other cpus post commands that make rd_idx increase. When rd_idx wrapped, the driver prints timeout messages but

Re: [PATCH] irqchip/gic-v3-its: handle rd_idx wrapping in its_wait_for_range_completion()

On 2018/2/12 2:45, Marc Zyngier wrote: Hi, Marc Sorry for replying so late. On Sun, 11 Feb 2018 03:42:01 +, Yang Yingliang wrote: Hi Yang, In direct case, rd_idx will wrap if other cpus post commands that make rd_idx increase. When rd_idx wrapped, the driver prints timeout messages but

Re: [PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

On Wed, Feb 28, 2018 at 03:13:54PM -0500, Alan Stern wrote: > This patch reorganizes the definition of rb in the Linux Kernel Memory > Consistency Model. The relation is now expressed in terms of > rcu-fence, which consists of a sequence of gp and rscs links separated > by rcu-link links, in

Re: [PATCH 2/2 v2 RFC] tools/memory-model: redefine rb in terms of rcu-fence

On Wed, Feb 28, 2018 at 03:13:54PM -0500, Alan Stern wrote: > This patch reorganizes the definition of rb in the Linux Kernel Memory > Consistency Model. The relation is now expressed in terms of > rcu-fence, which consists of a sequence of gp and rscs links separated > by rcu-link links, in

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