Re: [PATCH] kbuild: remove KBUILD_SUBDIR_ASFLAGS and KBUILD_SUBDIR_CCFLAGS

On 10/10/2017 07:43 PM, Masahiro Yamada wrote: > Accumulate subdir-{cc,as}flags-y directly to KBUILD_{A,C}FLAGS. > Remove KBUILD_SUBDIR_{AS,CC}FLAGS. > > Signed-off-by: Masahiro Yamada > --- > > scripts/Makefile.lib | 8 > 1 file changed, 4

Re: [PATCH] kbuild: remove KBUILD_SUBDIR_ASFLAGS and KBUILD_SUBDIR_CCFLAGS

On 10/10/2017 07:43 PM, Masahiro Yamada wrote: > Accumulate subdir-{cc,as}flags-y directly to KBUILD_{A,C}FLAGS. > Remove KBUILD_SUBDIR_{AS,CC}FLAGS. > > Signed-off-by: Masahiro Yamada > --- > > scripts/Makefile.lib | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff

Re: [PATCH] ACPI / battery: add quirk for Asus GL502VSK and UX305LA

On Fri, Sep 22, 2017 at 4:27 PM, Kai-Heng Feng wrote: > On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when > battery is full and AC is plugged. > > However rate_now is correct under this circumstance, hence we can use > "rate_now == 0" as a

Re: [PATCH] ACPI / battery: add quirk for Asus GL502VSK and UX305LA

On Fri, Sep 22, 2017 at 4:27 PM, Kai-Heng Feng wrote: > On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when > battery is full and AC is plugged. > > However rate_now is correct under this circumstance, hence we can use > "rate_now == 0" as a predicate to report battery full

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

On Wed, Oct 11, 2017 at 5:43 PM, Will Deacon wrote: > On Thu, Aug 24, 2017 at 05:33:47PM +0530, Ganapatrao Kulkarni wrote: >> function get_cpuid_str returns MIDR string of the first online >> cpu from the range of cpus associated with the pmu core device. >> >> Signed-off-by:

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

On Wed, Oct 11, 2017 at 5:43 PM, Will Deacon wrote: > On Thu, Aug 24, 2017 at 05:33:47PM +0530, Ganapatrao Kulkarni wrote: >> function get_cpuid_str returns MIDR string of the first online >> cpu from the range of cpus associated with the pmu core device. >> >> Signed-off-by: Ganapatrao Kulkarni

Re: Add hierarchical irq_domain for i2c based gpio expander pca9505

+BCM kernel feedback. Sorry for duplicated mails, had HTML formatting issue. On Wed, Oct 11, 2017 at 5:50 PM, Abhishek Shah wrote: > Hi Linus, > > I am facing one issue, where; while disabling/ masking interrupts just > before kexec reboot, access to gpio expander

Re: Add hierarchical irq_domain for i2c based gpio expander pca9505

+BCM kernel feedback. Sorry for duplicated mails, had HTML formatting issue. On Wed, Oct 11, 2017 at 5:50 PM, Abhishek Shah wrote: > Hi Linus, > > I am facing one issue, where; while disabling/ masking interrupts just > before kexec reboot, access to gpio expander pca9505 residing over > i2c bus

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

On Tue, 10 Oct 2017 22:32:31 +0530 "Naveen N. Rao" wrote: > On 2017/09/19 10:00AM, Masami Hiramatsu wrote: > > Warn if optprobe handler tries to change execution path. > > As described in Documentation/kprobes.txt, with optprobe > > user handler can not change

Re: [PATCH -tip v3 3/7] kprobes: Warn if optprobe handler tries to change execution path

On Tue, 10 Oct 2017 22:32:31 +0530 "Naveen N. Rao" wrote: > On 2017/09/19 10:00AM, Masami Hiramatsu wrote: > > Warn if optprobe handler tries to change execution path. > > As described in Documentation/kprobes.txt, with optprobe > > user handler can not change instruction pointer. In that > >

Re: [PATCH 00/11] KASan for arm

On 10/12/2017 12:10 AM, Abbott Liu wrote: >On 10/11/2017 12:50 PM, Florian Fainelli wrote: >> On 10/11/2017 12:13 PM, Florian Fainelli wrote: >>> Hi Abbott, >>> >>> On 10/11/2017 01:22 AM, Abbott Liu wrote: Hi,all: These patches add arch specific code for kernel address sanitizer

Re: [PATCH 00/11] KASan for arm

On 10/12/2017 12:10 AM, Abbott Liu wrote: >On 10/11/2017 12:50 PM, Florian Fainelli wrote: >> On 10/11/2017 12:13 PM, Florian Fainelli wrote: >>> Hi Abbott, >>> >>> On 10/11/2017 01:22 AM, Abbott Liu wrote: Hi,all: These patches add arch specific code for kernel address sanitizer

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

On Wed, Oct 11, 2017 at 7:25 PM, Will Deacon wrote: > On Wed, Oct 11, 2017 at 03:24:31PM +0200, Robert Richter wrote: >> On 11.10.17 13:19:27, Will Deacon wrote: >> > On Tue, Aug 29, 2017 at 02:47:30PM +0200, Robert Richter wrote: >> > > Shaokun, >> > > >> > > On 29.08.17

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

On Wed, Oct 11, 2017 at 7:25 PM, Will Deacon wrote: > On Wed, Oct 11, 2017 at 03:24:31PM +0200, Robert Richter wrote: >> On 11.10.17 13:19:27, Will Deacon wrote: >> > On Tue, Aug 29, 2017 at 02:47:30PM +0200, Robert Richter wrote: >> > > Shaokun, >> > > >> > > On 29.08.17 17:26:00, Zhangshaokun

[PATCH v2 0/4] TDA1997x HDMI video receiver

This is a v4l2 subdev driver supporting the TDA1997x HDMI video receiver. I've tested this on a Gateworks GW54xx with an IMX6Q which uses the TDA19971 with 16bits connected to the IMX6 CSI. For this configuration I've tested both 16bit YUV422 and 8bit BT656 mode. While the driver should support

[PATCH v2 0/4] TDA1997x HDMI video receiver

This is a v4l2 subdev driver supporting the TDA1997x HDMI video receiver. I've tested this on a Gateworks GW54xx with an IMX6Q which uses the TDA19971 with 16bits connected to the IMX6 CSI. For this configuration I've tested both 16bit YUV422 and 8bit BT656 mode. While the driver should support

[PATCH v2 2/4] media: dt-bindings: Add bindings for TDA1997X

Cc: Rob Herring Signed-off-by: Tim Harvey --- v2: - add vendor prefix and remove _ from vidout-portcfg - remove _ from labels - remove max-pixel-rate property - describe and provide example for single output port - use new audio port bindings ---

[PATCH v2 2/4] media: dt-bindings: Add bindings for TDA1997X

Cc: Rob Herring Signed-off-by: Tim Harvey --- v2: - add vendor prefix and remove _ from vidout-portcfg - remove _ from labels - remove max-pixel-rate property - describe and provide example for single output port - use new audio port bindings ---

[PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

Add support for the TDA1997x HDMI receivers. Cc: Hans Verkuil Signed-off-by: Tim Harvey --- v2: - implement dv timings enum/cap - remove deprecated g_mbus_config op - fix dv_query_timings - add EDID get/set handling - remove max-pixel-rate support

[PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

Add support for the TDA1997x HDMI receivers. Cc: Hans Verkuil Signed-off-by: Tim Harvey --- v2: - implement dv timings enum/cap - remove deprecated g_mbus_config op - fix dv_query_timings - add EDID get/set handling - remove max-pixel-rate support - add audio codec DAI support - use new

[PATCH v2 4/4] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

The GW54xx has a front-panel microHDMI connector routed to a TDA19971 which is connected the the IPU CSI when using IMX6Q. Signed-off-by: Tim Harvey --- v2: - use new audio bindings - add HDMI audio input support --- arch/arm/boot/dts/imx6q-gw54xx.dts| 102

[PATCH v2 1/4] MAINTAINERS: add entry for NXP TDA1997x driver

Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2093060..de7124e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13019,6 +13019,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S:

[PATCH v2 4/4] ARM: dts: imx: Add TDA19971 HDMI Receiver to GW54xx

The GW54xx has a front-panel microHDMI connector routed to a TDA19971 which is connected the the IPU CSI when using IMX6Q. Signed-off-by: Tim Harvey --- v2: - use new audio bindings - add HDMI audio input support --- arch/arm/boot/dts/imx6q-gw54xx.dts| 102

[PATCH v2 1/4] MAINTAINERS: add entry for NXP TDA1997x driver

Signed-off-by: Tim Harvey --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2093060..de7124e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13019,6 +13019,14 @@ T: git git://linuxtv.org/mkrufky/tuners.git S: Maintained F:

[PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

IATU unroll feature can be enabled in EP mode as well, so we need to have this check in pcie-designware-ep.c, so instead of making this function as static in pcie-desigware-host.c, let's move this in pcie-designware.c so that both pcie-designware-host.c and pcie-designware-ep.c can use it.

[PATCH] PCI: designware: move dw_pcie_iatu_unroll_enabled to pcie-designware.c

IATU unroll feature can be enabled in EP mode as well, so we need to have this check in pcie-designware-ep.c, so instead of making this function as static in pcie-desigware-host.c, let's move this in pcie-designware.c so that both pcie-designware-host.c and pcie-designware-ep.c can use it.

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

Jes Sorensen writes: > On 10/11/2017 04:41 AM, Kalle Valo wrote: >> Jes Sorensen writes: >> >>> On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote: In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

Jes Sorensen writes: > On 10/11/2017 04:41 AM, Kalle Valo wrote: >> Jes Sorensen writes: >> >>> On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote: In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. >>> >>> While this isn't

[PATCH] x86: handle MSR exception when setting energy perf bias

On very rare occasions, immediately after a suspend, one of our SandyBridge CI boxes hits the exception below on CPU0 while trying to reconfigure the energy bias register. As far as I can tell, this is not likely a race in the kernel, since we have only one cpu online, no preempt and

[PATCH] x86: handle MSR exception when setting energy perf bias

On very rare occasions, immediately after a suspend, one of our SandyBridge CI boxes hits the exception below on CPU0 while trying to reconfigure the energy bias register. As far as I can tell, this is not likely a race in the kernel, since we have only one cpu online, no preempt and

Re: [PATCH v3 3/8] PM / devfreq: Show the available min/max frequency through sysfs node

On 2017년 10월 11일 21:57, Chanwoo Choi wrote: > On Wed, Oct 11, 2017 at 8:15 PM, MyungJoo Ham > wrote: >>> The existing {min|max}_freq sysfs nodes don't consider whether min/max_freq >>> are available or not. Those sysfs nodes show just the stored value >>> in the struct

Re: [PATCH v3 3/8] PM / devfreq: Show the available min/max frequency through sysfs node

On 2017년 10월 11일 21:57, Chanwoo Choi wrote: > On Wed, Oct 11, 2017 at 8:15 PM, MyungJoo Ham > wrote: >>> The existing {min|max}_freq sysfs nodes don't consider whether min/max_freq >>> are available or not. Those sysfs nodes show just the stored value >>> in the struct devfreq. >>> >>> The

[PATCH] documentation: Update ide-cd documentation to reflect CONFIG_BLK_DEV_HD_IDE removal

CONFIG_BLK_DEV_HD_IDE was removed in commit 80aa31cb460d ("ide: remove CONFIG_BLK_DEV_HD_IDE config option (take 2)") but the ide-cd documentation was not updated and still asks users to disable it, which is misleading and involves a fruitless search. Signed-off-by: Finn Thain

[PATCH] documentation: Update ide-cd documentation to reflect CONFIG_BLK_DEV_HD_IDE removal

CONFIG_BLK_DEV_HD_IDE was removed in commit 80aa31cb460d ("ide: remove CONFIG_BLK_DEV_HD_IDE config option (take 2)") but the ide-cd documentation was not updated and still asks users to disable it, which is misleading and involves a fruitless search. Signed-off-by: Finn Thain diff --git

Re: [PATCH v3 5/5] soc: qcom: smem: Increase the number of hosts

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > Increase the maximum number of hosts in a system to 10. > Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Chris Lew > --- > > Changes since

Re: [PATCH v3 5/5] soc: qcom: smem: Increase the number of hosts

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > Increase the maximum number of hosts in a system to 10. > Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Chris Lew > --- > > Changes since v1: > - None > > Changes since v2: > - None > >

[PATCH] PCI: endpoint: handle probable NULL pointer access

controller_group allocation in pci_ep_cfs_init function can fail so we should have a check while using it in pci_ep_cfs_add_epc_group for registering group, else we will hit NULL pointer access. This patch adds required check for the same and returns -EPROBE_DEFER, so that endpoint controller

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

Brian Norris writes: > Ping? Any comments? I know there's more than one way to slice this > problem, but it's most definitely a problem... I'm lagging behind with patches but I'll try to catch up this week. Sorry. -- Kalle Valo

[PATCH] PCI: endpoint: handle probable NULL pointer access

controller_group allocation in pci_ep_cfs_init function can fail so we should have a check while using it in pci_ep_cfs_add_epc_group for registering group, else we will hit NULL pointer access. This patch adds required check for the same and returns -EPROBE_DEFER, so that endpoint controller

Re: [PATCH] ath10k: fix core PCI suspend when WoWLAN is supported but disabled

Brian Norris writes: > Ping? Any comments? I know there's more than one way to slice this > problem, but it's most definitely a problem... I'm lagging behind with patches but I'll try to catch up this week. Sorry. -- Kalle Valo

Re: [PATCH v3 4/5] soc: qcom: smem: Support dynamic item limit

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > In V12 SMEM, SBL writes SMEM parameter information after the TOC. Use > the SBL provided item count as the max item number. > Acked-by: Bjorn Andersson Regards, Bjorn >

Re: [PATCH v3 4/5] soc: qcom: smem: Support dynamic item limit

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > In V12 SMEM, SBL writes SMEM parameter information after the TOC. Use > the SBL provided item count as the max item number. > Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Chris Lew > --- > > Changes since

Re: [PATCH v3 3/5] soc: qcom: smem: Support global partition

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > SMEM V12 creates a global partition to allocate global smem items from > instead of a global heap. The global partition has the same structure as > a private partition. > Acked-by: Bjorn Andersson

Re: [PATCH v3 3/5] soc: qcom: smem: Support global partition

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > SMEM V12 creates a global partition to allocate global smem items from > instead of a global heap. The global partition has the same structure as > a private partition. > Acked-by: Bjorn Andersson Regards, Bjorn >

Re: [PATCH v3 2/5] soc: qcom: smem: Read version from the smem header

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > The SMEM header structure includes the version information. Read the > version directly from the header instead of getting an item from the > global heap. > Acked-by: Bjorn Andersson

Re: [PATCH v3 2/5] soc: qcom: smem: Read version from the smem header

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > The SMEM header structure includes the version information. Read the > version directly from the header instead of getting an item from the > global heap. > Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Chris

Re: [PATCH v3 1/5] soc: qcom: smem: Use le32_to_cpu for comparison

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > Endianness can vary in the system, add le32_to_cpu when comparing > partition sizes from smem. > Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Chris Lew

Re: [PATCH v3 1/5] soc: qcom: smem: Use le32_to_cpu for comparison

On Wed 11 Oct 14:29 PDT 2017, Chris Lew wrote: > From: Chris Lew > > Endianness can vary in the system, add le32_to_cpu when comparing > partition sizes from smem. > Acked-by: Bjorn Andersson Regards, Bjorn > Signed-off-by: Chris Lew > --- > > Changes since v1: > - New change > >

Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ

On 10/11/2017 09:49 PM, Michael S. Tsirkin wrote: On Wed, Oct 11, 2017 at 02:03:20PM +0800, Wei Wang wrote: On 10/10/2017 11:15 PM, Michael S. Tsirkin wrote: On Mon, Oct 02, 2017 at 04:38:01PM +, Wang, Wei W wrote: On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote: On Sat,

Re: [PATCH v16 5/5] virtio-balloon: VIRTIO_BALLOON_F_CTRL_VQ

On 10/11/2017 09:49 PM, Michael S. Tsirkin wrote: On Wed, Oct 11, 2017 at 02:03:20PM +0800, Wei Wang wrote: On 10/10/2017 11:15 PM, Michael S. Tsirkin wrote: On Mon, Oct 02, 2017 at 04:38:01PM +, Wang, Wei W wrote: On Sunday, October 1, 2017 11:19 AM, Michael S. Tsirkin wrote: On Sat,

Re: [PATCH v3 7/9] soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap

On Tue, 2017-10-10 at 12:02 +0200, Matthias Brugger wrote: > > On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Add MediaTek MT6380 regulator becoming one of PMIC wrapper slave > > and also add extra new regmap_config of 32-bit mode for

Re: [PATCH v3 7/9] soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap

On Tue, 2017-10-10 at 12:02 +0200, Matthias Brugger wrote: > > On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Add MediaTek MT6380 regulator becoming one of PMIC wrapper slave > > and also add extra new regmap_config of 32-bit mode for MT6380 > > since old

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

Dear Kishon, Could you please review this patch? After that, I'll make the immutable brand and then send the pull request for power_supply, mfd, phy, usb and extcon framework. On 2017년 10월 10일 19:17, Chanwoo Choi wrote: > The extcon has two type of extcon devices as following. > - 'extcon

Re: [PATCH v2] extcon: Split out extcon header file for consumer and provider device

Dear Kishon, Could you please review this patch? After that, I'll make the immutable brand and then send the pull request for power_supply, mfd, phy, usb and extcon framework. On 2017년 10월 10일 19:17, Chanwoo Choi wrote: > The extcon has two type of extcon devices as following. > - 'extcon

RE: [PATCH 2/2] pci/layerscape: change the default error response behavior

Hi Bjorn, Thanks a lot for your review! > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 2017年10月12日 3:41 > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org;

RE: [PATCH 2/2] pci/layerscape: change the default error response behavior

Hi Bjorn, Thanks a lot for your review! > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 2017年10月12日 3:41 > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; bhelg...@google.com; Roy Zang > ;

[PATCH v13] MAINTAINERS: add entry for Rockchip RGA driver

Signed-off-by: Jacob Chen --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6671f375f7fc..b13dae0cbf42 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11509,6 +11509,13 @@ F: drivers/hid/hid-roccat* F:

[PATCH v13] MAINTAINERS: add entry for Rockchip RGA driver

Signed-off-by: Jacob Chen --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6671f375f7fc..b13dae0cbf42 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11509,6 +11509,13 @@ F: drivers/hid/hid-roccat* F: include/linux/hid-roccat* F:

[PATCH v2] net: ftgmac100: Request clock and set speed

According to the ASPEED datasheet, gigabit speeds require a clock of 100MHz or higher. Other speeds require 25MHz or higher. This patch configures a 100MHz clock if the system has a direct-attached PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz. There appear to be no

[PATCH v2] net: ftgmac100: Request clock and set speed

According to the ASPEED datasheet, gigabit speeds require a clock of 100MHz or higher. Other speeds require 25MHz or higher. This patch configures a 100MHz clock if the system has a direct-attached PHY, or 25MHz if the system is running NC-SI which is limited to 100MHz. There appear to be no

Re: [PATCH][bpf-next] bpf: remove redundant variable old_flags

From: Colin King Date: Wed, 11 Oct 2017 11:56:23 +0100 > From: Colin Ian King > > Variable old_flags is being assigned but is never read; it is redundant > and can be removed. > > Cleans up clang warning: Value stored to 'old_flags' is never

Re: [PATCH][bpf-next] bpf: remove redundant variable old_flags

From: Colin King Date: Wed, 11 Oct 2017 11:56:23 +0100 > From: Colin Ian King > > Variable old_flags is being assigned but is never read; it is redundant > and can be removed. > > Cleans up clang warning: Value stored to 'old_flags' is never read > > Signed-off-by: Colin Ian King Applied.

[PATCH] scripts: fix faddr2line to work on last symbol

If faddr2line is given a function name which is the last one listed by "nm -n", it will fail because it never finds the next symbol. So teach the awk script to catch that possibility, and use 'size' to provide the end point of the last function. Signed-off-by: NeilBrown ---

[PATCH] scripts: fix faddr2line to work on last symbol

If faddr2line is given a function name which is the last one listed by "nm -n", it will fail because it never finds the next symbol. So teach the awk script to catch that possibility, and use 'size' to provide the end point of the last function. Signed-off-by: NeilBrown --- scripts/faddr2line

Re: [PATCH v3 5/9] soc: mediatek: pwrap: add pwrap_write32 for writing in 32-bit mode

On Tue, 2017-10-10 at 11:38 +0200, Matthias Brugger wrote: > > On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Some regulators such as MediaTek MT6380 also has to be written in > > 32-bit mode. So the patch adds pwrap_write32, rename old

Re: [PATCH v3 5/9] soc: mediatek: pwrap: add pwrap_write32 for writing in 32-bit mode

On Tue, 2017-10-10 at 11:38 +0200, Matthias Brugger wrote: > > On 08/15/2017 11:09 AM, sean.w...@mediatek.com wrote: > > From: Sean Wang > > > > Some regulators such as MediaTek MT6380 also has to be written in > > 32-bit mode. So the patch adds pwrap_write32, rename old pwrap_write > > into

Re: [PATCH][net-next] net: mpls: make function ipgre_mpls_encap_hlen static

From: Colin King Date: Wed, 11 Oct 2017 10:53:28 +0100 > From: Colin Ian King > > The function ipgre_mpls_encap_hlen is local to the source and > does not need to be in global scope, so make it static. > > Cleans up sparse warning: > symbol

Re: [PATCH][net-next] net: mpls: make function ipgre_mpls_encap_hlen static

From: Colin King Date: Wed, 11 Oct 2017 10:53:28 +0100 > From: Colin Ian King > > The function ipgre_mpls_encap_hlen is local to the source and > does not need to be in global scope, so make it static. > > Cleans up sparse warning: > symbol 'ipgre_mpls_encap_hlen' was not declared. Should it

Re: [PATCH][next] sctp: make array sctp_sched_ops static

From: Colin King Date: Wed, 11 Oct 2017 11:17:57 +0100 > From: Colin Ian King > > The array sctp_sched_ops is local to the source and > does not need to be in global scope, so make it static. > > Cleans up sparse warning: > symbol

Re: [PATCH][next] sctp: make array sctp_sched_ops static

From: Colin King Date: Wed, 11 Oct 2017 11:17:57 +0100 > From: Colin Ian King > > The array sctp_sched_ops is local to the source and > does not need to be in global scope, so make it static. > > Cleans up sparse warning: > symbol 'sctp_sched_ops' was not declared. Should it be static? > >

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

Hi Bjorn, Thanks a lot for your comments! > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 2017年10月12日 3:38 > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org;

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

Hi Bjorn, Thanks a lot for your comments! > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 2017年10月12日 3:38 > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; bhelg...@google.com; Roy Zang >

Re: [PATCH net] net/ncsi: Don't limit vids based on hot_channel

From: Samuel Mendoza-Jonas Date: Wed, 11 Oct 2017 16:54:27 +1100 > Currently we drop any new VLAN ids if there are more than the current > (or last used) channel can support. Most importantly this is a problem > if no channel has been selected yet, resulting in a segfault.

Re: [PATCH net] net/ncsi: Don't limit vids based on hot_channel

From: Samuel Mendoza-Jonas Date: Wed, 11 Oct 2017 16:54:27 +1100 > Currently we drop any new VLAN ids if there are more than the current > (or last used) channel can support. Most importantly this is a problem > if no channel has been selected yet, resulting in a segfault. > > Secondly this

RE: [PATCH 0/5] arm64: add ls1012a and ls1046a pcie support

Hi Bjorn, I greatly appreciate for your review and picking up them. Acked-by: Minghuan Lian > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Thursday, October 12, 2017 2:57 AM > To: Z.q. Hou > Cc:

RE: [PATCH 0/5] arm64: add ls1012a and ls1046a pcie support

Hi Bjorn, I greatly appreciate for your review and picking up them. Acked-by: Minghuan Lian > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Thursday, October 12, 2017 2:57 AM > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;

Re: [PATCH] net: ftgmac100: Request clock and set speed

On Tue, Oct 10, 2017 at 4:14 PM, Benjamin Herrenschmidt wrote: > On Tue, 2017-10-10 at 15:19 +1030, Joel Stanley wrote: >> According to the ASPEED datasheet, gigabit speeds require a clock of >> 100MHz or higher. Other speeds require 25MHz or higher. > > Did you try

Re: [PATCH] net: ftgmac100: Request clock and set speed

On Tue, Oct 10, 2017 at 4:14 PM, Benjamin Herrenschmidt wrote: > On Tue, 2017-10-10 at 15:19 +1030, Joel Stanley wrote: >> According to the ASPEED datasheet, gigabit speeds require a clock of >> 100MHz or higher. Other speeds require 25MHz or higher. > > Did you try "live" changing by either

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

Hi Bjorn, Thanks for your review. Yes. All the freescale's PCIe controllers do not support to generate MSI interrupt. The PCIe controllers developed for the next generation SoC do not support it either. Acked-by: Minghuan Lian > -Original Message- > From: Bjorn

RE: [PATCH 1/2] PCI: Disable MSI for Freescale PCIe RC mode

Hi Bjorn, Thanks for your review. Yes. All the freescale's PCIe controllers do not support to generate MSI interrupt. The PCIe controllers developed for the next generation SoC do not support it either. Acked-by: Minghuan Lian > -Original Message- > From: Bjorn Helgaas

Re: [PATCH 1/2] drivers: firmware: psci: Add psci_is_available()

On Wed, 11 Oct 2017 10:03:01 +0200 Geert Uytterhoeven wrote: > PSCI support may be disabled at build time (by configuration) or at > run-time (PSCI firmware not present). While CONFIG_ARM_PSCI_FW can be > used to check for build time enablement, there is currently no simple > way to check if

Re: [PATCH 1/2] drivers: firmware: psci: Add psci_is_available()

On Wed, 11 Oct 2017 10:03:01 +0200 Geert Uytterhoeven wrote: > PSCI support may be disabled at build time (by configuration) or at > run-time (PSCI firmware not present). While CONFIG_ARM_PSCI_FW can be > used to check for build time enablement, there is currently no simple > way to check if

Re: [kernel-hardening] [PATCH] printk: hash addresses printed with %p

Removing k...@vger.kernel.org from the CC list. On Wed, Oct 11, 2017 at 01:48:58PM -0400, Theodore Ts'o wrote: > On Wed, Oct 11, 2017 at 02:48:16PM +1100, Tobin C. Harding wrote: > > +/* > > + * Obfuscates pointer (algorithm taken from kptr_obfuscate(). See > > kernel/kcmp.c) > > + * v is the

Re: [kernel-hardening] [PATCH] printk: hash addresses printed with %p

Removing k...@vger.kernel.org from the CC list. On Wed, Oct 11, 2017 at 01:48:58PM -0400, Theodore Ts'o wrote: > On Wed, Oct 11, 2017 at 02:48:16PM +1100, Tobin C. Harding wrote: > > +/* > > + * Obfuscates pointer (algorithm taken from kptr_obfuscate(). See > > kernel/kcmp.c) > > + * v is the

Re: [PATCH v3 22/33] tracing: Add support for 'field variables'

On Fri, Sep 22, 2017 at 03:00:02PM -0500, Tom Zanussi wrote: > Users should be able to directly specify event fields in hist trigger > 'actions' rather than being forced to explicitly create a variable for > that purpose. > > Add support allowing fields to be used directly in actions, which >

Re: [PATCH v3 22/33] tracing: Add support for 'field variables'

On Fri, Sep 22, 2017 at 03:00:02PM -0500, Tom Zanussi wrote: > Users should be able to directly specify event fields in hist trigger > 'actions' rather than being forced to explicitly create a variable for > that purpose. > > Add support allowing fields to be used directly in actions, which >

Re: [PATCHv2 1/1] ANDROID: mmc: core: export emmc revision

On Wed, 11 Oct 2017 13:51:26 -0700 Jin Qian wrote: > From: Jin Qian > > Expose emmc revision as part of device attributes. >> ANDROID: mmc: core: export emmc revision This commit probably back port from android linux kernel repo. Could we remove the

Re: [PATCHv2 1/1] ANDROID: mmc: core: export emmc revision

On Wed, 11 Oct 2017 13:51:26 -0700 Jin Qian wrote: > From: Jin Qian > > Expose emmc revision as part of device attributes. >> ANDROID: mmc: core: export emmc revision This commit probably back port from android linux kernel repo. Could we remove the ANDROID prefix > > Signed-off-by: Jin

Re: [PATCH] printk: hash addresses printed with %p

On Tue, Oct 10, 2017 at 09:06:50PM -0700, Joe Perches wrote: > On Wed, 2017-10-11 at 14:48 +1100, Tobin C. Harding wrote: > > Currently there are many places in the kernel where addresses are being > > printed using an unadorned %p. Kernel pointers should be printed using > > %pK allowing some

Re: [PATCH] printk: hash addresses printed with %p

On Tue, Oct 10, 2017 at 09:06:50PM -0700, Joe Perches wrote: > On Wed, 2017-10-11 at 14:48 +1100, Tobin C. Harding wrote: > > Currently there are many places in the kernel where addresses are being > > printed using an unadorned %p. Kernel pointers should be printed using > > %pK allowing some

Re: [PATCH v3 12/12] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs

On Thu, Oct 12, 2017 at 3:09 AM, Linus Walleij wrote: > On Wed, Oct 11, 2017 at 2:00 PM, Maxime Ripard > wrote: > >> What about not enforcing any muxing state when we want to mux to the >> "ldo" function? We just leave it to whatever

Re: [PATCH v3 12/12] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs

On Thu, Oct 12, 2017 at 3:09 AM, Linus Walleij wrote: > On Wed, Oct 11, 2017 at 2:00 PM, Maxime Ripard > wrote: > >> What about not enforcing any muxing state when we want to mux to the >> "ldo" function? We just leave it to whatever value it is, that way we >> keep it under the regulator

Re: [PATCH] radix-tree: get_slot_offset() returns invalid offset when parent is NULL

On Wed, Oct 11, 2017 at 04:39:40PM -0700, Andrew Morton wrote: >On Wed, 11 Oct 2017 10:33:39 +0800 Wei Yang wrote: > >> On Tue, Oct 10, 2017 at 01:53:11PM -0700, Andrew Morton wrote: >> >On Tue, 10 Oct 2017 10:52:01 +0800 Wei Yang >> >wrote:

Re: [PATCH] radix-tree: get_slot_offset() returns invalid offset when parent is NULL

On Wed, Oct 11, 2017 at 04:39:40PM -0700, Andrew Morton wrote: >On Wed, 11 Oct 2017 10:33:39 +0800 Wei Yang wrote: > >> On Tue, Oct 10, 2017 at 01:53:11PM -0700, Andrew Morton wrote: >> >On Tue, 10 Oct 2017 10:52:01 +0800 Wei Yang >> >wrote: >> > >> >> When parent is NULL, get_slot_offset()

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

On Wed, Oct 11, 2017 at 06:02:47PM +0530, Shreeya Patel wrote: > On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote: > > On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote: > > > > > > Remove NULL pointer dereference as it results in undefined > > > behaviour, and will usually

Re: [PATCH] Staging: rtlwifi: Remove NULL pointer dereference

On Wed, Oct 11, 2017 at 06:02:47PM +0530, Shreeya Patel wrote: > On Tue, 2017-10-10 at 11:06 +1100, Tobin C. Harding wrote: > > On Tue, Oct 10, 2017 at 02:48:58AM +0530, Shreeya Patel wrote: > > > > > > Remove NULL pointer dereference as it results in undefined > > > behaviour, and will usually

[PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver

This patchset adds a new hardware offload type in mqprio before adding mqprio hardware offload support in hns3 driver. Yunsheng Lin (2): mqprio: Add a new hardware offload type in mqprio net: hns3: Add mqprio hardware offload support in hns3 driver

[PATCH net-next 0/2] Add mqprio hardware offload support in hns3 driver

This patchset adds a new hardware offload type in mqprio before adding mqprio hardware offload support in hns3 driver. Yunsheng Lin (2): mqprio: Add a new hardware offload type in mqprio net: hns3: Add mqprio hardware offload support in hns3 driver

[PATCH net-next 2/2] net: hns3: Add mqprio hardware offload support in hns3 driver

When using tc qdisc, dcb_ops->setup_tc is used to tell hclge_dcb module to do the tm related setup. Only TC_MQPRIO_HW_OFFLOAD_DCB offload type is supported. Signed-off-by: Yunsheng Lin --- drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 +

[PATCH net-next 2/2] net: hns3: Add mqprio hardware offload support in hns3 driver

When using tc qdisc, dcb_ops->setup_tc is used to tell hclge_dcb module to do the tm related setup. Only TC_MQPRIO_HW_OFFLOAD_DCB offload type is supported. Signed-off-by: Yunsheng Lin --- drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 +

  1   2   3   4   5   6   7   8   9   10   >