Re: [PATCH 2/8] dt-bindings: crypto : Add new compatible strings for qcom-qce

Hi Rob, Thanks for your review. On Wed, 17 Mar 2021 at 03:58, Rob Herring wrote: > > On Wed, Mar 10, 2021 at 10:54:57AM +0530, Bhupesh Sharma wrote: > > Newer qcom chips support newer versions of the qce IP, so add > > new compatible strings for qcom-qce (in addition to the

Re: [PATCH 1/3] arm64: dts: qcom: sm8150: add other QUP nodes

_WRAP_2_S_AHB_CLK>; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + status = "disabled"; > + }; > + > config_noc: interconnect@150 { > compatible = "qcom,sm8150-config-noc"; > reg = <0 0x0150 0 0x7400>; LGTM, so: Reviewed-by: Bhupesh Sharma

Re: [PATCH 3/3] arm64: dts: qcom: sm8150: add i2c nodes

t;gpio44"; > + drive-strength = <0x02>; > + bias-disable; > + }; > + }; > + > + qup_i2c14_default: qup-i2c14-default { > + mux { > + pins = "gpio47", "gpio48"; > + function = "qup14"; > + }; > + > + config { > + pins = "gpio47", "gpio48"; > + drive-strength = <0x02>; > + bias-disable; > + }; > + }; > + > + qup_i2c15_default: qup-i2c15-default { > + mux { > + pins = "gpio27", "gpio28"; > + function = "qup15"; > + }; > + > + config { > + pins = "gpio27", "gpio28"; > + drive-strength = <0x02>; > + bias-disable; > + }; > + }; > + > + qup_i2c16_default: qup-i2c16-default { > + mux { > + pins = "gpio86", "gpio85"; > + function = "qup16"; > + }; > + > + config { > + pins = "gpio86", "gpio85"; > + drive-strength = <0x02>; > + bias-disable; > + }; > + }; > + > + qup_i2c17_default: qup-i2c17-default { > + mux { > + pins = "gpio55", "gpio56"; > + function = "qup17"; > + }; > + > + config { > + pins = "gpio55", "gpio56"; > + drive-strength = <0x02>; > + bias-disable; > + }; > + }; > + > + qup_i2c18_default: qup-i2c18-default { > + mux { > + pins = "gpio23", "gpio24"; > + function = "qup18"; > + }; > + > + config { > + pins = "gpio23", "gpio24"; > + drive-strength = <0x02>; > + bias-disable; > + }; > + }; > + > + qup_i2c19_default: qup-i2c19-default { > + mux { > + pins = "gpio57", "gpio58"; > + function = "qup19"; > + }; > + > + config { > + pins = "gpio57", "gpio58"; > + drive-strength = <0x02>; > + bias-disable; > + }; > + }; > }; > > remoteproc_mpss: remoteproc@408 { LGTM, so: Reviewed-by: Bhupesh Sharma

Re: [PATCH 2/3] arm64: dts: qcom: sm8150: add iommus to qups

Hello Caleb, Thanks for the patch. Some nitpicks inline: On Wed, 10 Mar 2021 at 22:02, Caleb Connolly wrote: > > Hook up the SMMU for doing DMA over i2c. Some peripherals like > touchscreens easily exceed 32-bytes per transfer, causing errors and > lockups without this. > > Signed-off-by: Caleb

Re: [PATCH 4/8] dt-bindings/clock: qcom: sm8250: Add gcc clocks for sm8250 crypto block

Hi Stephen, Thanks for the review. On Sun, 14 Mar 2021 at 02:45, Stephen Boyd wrote: > > Quoting Bhupesh Sharma (2021-03-09 21:24:59) > > This patch adds the global clock controller (gcc) clocks required > > $ git grep "This patch" -- Documentation/process/

[PATCH 8/8] arm64/dts: qcom: sm8250: Add dt entries to support crypto engine.

kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- arch/arm64/boot/dts/qcom/sm8250.dtsi | 36 1 file changed, 36 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/

[PATCH 7/8] drivers: crypto: qce: Enable support for crypto engine on sm8250.

Andy Gross Cc: Herbert Xu Cc: David S. Miller Cc: Stephen Boyd Cc: Michael Turquette Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- drivers/crypto/qce/

[PATCH 6/8] clk: qcom: Add gcc clocks for crypto block on sm8250

: Stephen Boyd Cc: Michael Turquette Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- drivers/clk/qcom/gcc-sm8250.c | 44 +++ 1

[PATCH 5/8] clk: qcom: clk-rpmh: Add CE clock on sm8250

Boyd Cc: Michael Turquette Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- drivers/clk/qcom/clk-rpmh.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 4/8] dt-bindings/clock: qcom: sm8250: Add gcc clocks for sm8250 crypto block

. Miller Cc: Stephen Boyd Cc: Michael Turquette Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- include/dt-bindings/clock/qcom,gcc-sm8250.h | 3 +++ 1 file

[PATCH 3/8] arm64/dts: qcom: sdm845: Use RPMH_CE_CLK macro directly

nel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boo

[PATCH 2/8] dt-bindings: crypto : Add new compatible strings for qcom-qce

nel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- Documentation/devicetree/bindings/crypto/qcom-qce.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.txt b/Documentation/devicetree/bindings/crypto/qcom-qce

[PATCH 1/8] dt-bindings: qcom-qce: Add 'iommus' to required properties

. Miller Cc: Stephen Boyd Cc: Michael Turquette Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Signed-off-by: Bhupesh Sharma --- Documentation/devicetree/bindings/crypto/qcom-qce.txt | 1

[PATCH 0/8] Enable Qualcomm Crypto Engine on sm8250

-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: bhupesh.li...@gmail.com Bhupesh Sharma (8): dt-bindings: qcom-qce: Add 'iommus' to required properties dt-bindings: crypto : Add new compatible strings for qcom-qce arm64/dts: qcom: sdm845

Re: [RFC PATCH 4/4] i40e: don't open i40iw client for kdump

Hello Coiby, On Mon, Feb 22, 2021 at 12:40 PM Coiby Xu wrote: > > i40iw consumes huge amounts of memory. For example, on a x86_64 machine, > i40iw consumed 1.5GB for Intel Corporation Ethernet Connection X722 for > for 1GbE while "craskernel=auto" only reserved 160M. With the module > parameter

Re: [PATCH v13 0/8] support reserving crashkernel above 4G on arm64 kdump

Hi Chen, On Wed, Nov 11, 2020 at 7:05 PM chenzhou wrote: > > Hi Baoquan, Bhupesh, > > > On 2020/11/11 11:01, Baoquan He wrote: > > Hi Zhou, Bhupesh > > > > On 10/31/20 at 03:44pm, Chen Zhou wrote: > >> There are following issues in arm64 kdump: > >> 1. We use crashkernel=X to reserve crashkernel

Re: [PATCH v12 0/9] support reserving crashkernel above 4G on arm64 kdump

Hi Catalin, On Tue, Oct 6, 2020 at 11:30 PM Catalin Marinas wrote: > > On Mon, Oct 05, 2020 at 11:12:10PM +0530, Bhupesh Sharma wrote: > > I think my earlier email with the test results on this series bounced > > off the mailing list server (for some weird reason), but I sti

Re: [PATCH v12 0/9] support reserving crashkernel above 4G on arm64 kdump

Hi Catalin, Chen, On Mon, Oct 5, 2020 at 10:39 PM Catalin Marinas wrote: > > On Sat, Sep 12, 2020 at 06:44:29AM -0500, John Donnelly wrote: > > On 9/7/20 8:47 AM, Chen Zhou wrote: > > > Chen Zhou (9): > > >x86: kdump: move CRASH_ALIGN to 2M > > >x86: kdump: make the lower bound of crash

Re: [PATCH v2 1/1] kdump: append uts_namespace.name offset to VMCOREINFO

> + VMCOREINFO_OFFSET(uts_namespace, name); > VMCOREINFO_SYMBOL(node_online_map); > #ifdef CONFIG_MMU > VMCOREINFO_SYMBOL_ARRAY(swapper_pg_dir); > -- > 2.26.2 Thanks for making the changes we discussed in the v1 review. Otherwise the patch looks fine to me, so: Reviewed-by: Bhupesh Sharma

[tip: perf/urgent] hw_breakpoint: Remove unused __register_perf_hw_breakpoint() declaration

The following commit has been merged into the perf/urgent branch of tip: Commit-ID: b55b3fdce3e554a6bbe8f8ca6a01a892d720e64e Gitweb: https://git.kernel.org/tip/b55b3fdce3e554a6bbe8f8ca6a01a892d720e64e Author:Bhupesh Sharma AuthorDate:Fri, 17 Jul 2020 13:01:00 +05:30

[RESEND PATCH] hw_breakpoint: Remove unused '__register_perf_hw_breakpoint' declaration

ation from 'hw_breakpoint.h' as well. Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Michael Ellerman Cc: linux-kernel@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Acked-by: Mark Rutland Signed-off-by: Bhupesh Sharma --- - Resending with Acked-by from

Re: [PATCH 2/2] arm64: Allocate crashkernel always in ZONE_DMA

Hi Chen, On Fri, Jul 3, 2020 at 10:54 AM chenzhou wrote: > > Hi Bhupesh, > > > On 2020/7/3 3:22, Bhupesh Sharma wrote: > > Hi Will, > > > > On Thu, Jul 2, 2020 at 1:20 PM Will Deacon wrote: > >> On Thu, Jul 02, 2020 at 03:44:20AM +0530, Bhupesh Sharm

Re: [PATCH v10 0/5] support reserving crashkernel above 4G on arm64 kdump

Hi Chen, On Fri, Jul 3, 2020 at 9:24 AM Chen Zhou wrote: > > This patch series enable reserving crashkernel above 4G in arm64. > > There are following issues in arm64 kdump: > 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail > when there is no enough low memory. > 2.

Re: [PATCH 2/2] arm64: Allocate crashkernel always in ZONE_DMA

Hi Will, On Thu, Jul 2, 2020 at 1:20 PM Will Deacon wrote: > > On Thu, Jul 02, 2020 at 03:44:20AM +0530, Bhupesh Sharma wrote: > > commit bff3b04460a8 ("arm64: mm: reserve CMA and crashkernel in > > ZONE_DMA32") allocates crashkernel for arm64 in the ZONE_DMA32.

Re: [PATCH 1/2] mm/memcontrol: Fix OOPS inside mem_cgroup_get_nr_swap_pages()

Hi Michal, On Thu, Jul 2, 2020 at 11:30 AM Michal Hocko wrote: > > On Thu 02-07-20 03:44:19, Bhupesh Sharma wrote: > > Prabhakar reported an OOPS inside mem_cgroup_get_nr_swap_pages() > > function in a corner case seen on some arm64 boards when kdump kernel > > runs wit

Re: [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

On Thu, Jul 2, 2020 at 10:45 PM Catalin Marinas wrote: > > On Thu, 14 May 2020 00:22:35 +0530, Bhupesh Sharma wrote: > > Apologies for the delayed update. Its been quite some time since I > > posted the last version (v5), but I have been really caught up in some > &g

[PATCH 1/2] mm/memcontrol: Fix OOPS inside mem_cgroup_get_nr_swap_pages()

Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: ke...@lists.infradead.org Reported-by: Prabhakar Kushwaha Signed-off-by: Bhupesh Sharma --- mm/memcontrol.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol

[PATCH 0/2] arm64/kdump: Fix OOPS and OOM issues in kdump kernel

Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: ke...@lists.infradead.org Reported-by: Prabhakar Kushwaha Signed-off-by: Bhupesh Sharma Bhupesh Sharma (2): mm/memcontrol: Fix OOPS inside mem_cgroup_get_nr_swap_pages() arm64: Allocate crashker

[PATCH 2/2] arm64: Allocate crashkernel always in ZONE_DMA

orse Cc: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Cc: cgro...@vger.kernel.org Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: ke...@lists.infradead.org Reported-by: Prabhakar Kushwaha Signed-off-by: Bhupesh Sharma --- arch/arm64/mm/init.

Re: Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

gt; changes are present) > When I used crash utility, following is the error: > > Thanks, > -Bharat > > > -Original Message- > From: Scott Branden [mailto:scott.bran...@broadcom.com] > Sent: Thursday, April 30, 2020 4:34 AM > To: Bhupesh Sharma; Amit Kachhap >

Re: [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

Hello Catalin, Will, On Tue, Jun 2, 2020 at 10:54 AM Bhupesh Sharma wrote: > > Hello, > > On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote: > > > > Apologies for the delayed update. Its been quite some time since I > > posted the last version (v5), but I have

Re: [PATCH] kexec: dump kmessage before machine_kexec

machine_shutdown(); > } > > + kmsg_dump(KMSG_DUMP_SHUTDOWN); > machine_kexec(kexec_image); > > #ifdef CONFIG_KEXEC_JUMP > -- > 2.25.1 LGTM, so: Reviewed-by: Bhupesh Sharma Thanks.

Re: Re: [RESEND PATCH v5 5/5] Documentation/vmcoreinfo: Add documentation for 'TCR_EL1.T1SZ'

Hello Scott, On Thu, Jun 4, 2020 at 12:17 AM Scott Branden wrote: > > Hi Bhupesh, > > Would be great to get this patch series upstreamed? > > On 2019-12-25 10:49 a.m., Bhupesh Sharma wrote: > > Hi James, > > > > On 12/12/2019 04:02 PM, James Morse wrote:

Re: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

Hi Kamlakant, Many thanks for having a look at the patchset. On Wed, Jun 3, 2020 at 4:50 PM Kamlakant Patel wrote: > > Hi Bhupesh, > > > -Original Message- > > From: kexec On Behalf Of Bhupesh > > Sharma > > Sent: Thursday, May 14, 20

Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump

2020 at 8:12 PM John Donnelly > >> wrote: > >>> > >>> > >>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha > >>>> wrote: > >>>> > >>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly > >>>&g

Re: [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

Hello, On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote: > > Apologies for the delayed update. Its been quite some time since I > posted the last version (v5), but I have been really caught up in some > other critical issues. > > Changes since v5: >

Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump

Hi John, On Tue, Jun 2, 2020 at 1:01 AM John Donnelly wrote: > > Hi, > > > On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote: > > Hi Chen, > > > > On Thu, May 21, 2020 at 3:05 PM Chen Zhou wrote: > >> This patch series enable reserving crashkernel above 4G in arm64. > >> > >> There are following

Re: [PATCH v7 0/4] support reserving crashkernel above 4G on arm64 kdump

Hi John, On Wed, May 20, 2020 at 1:53 AM John Donnelly wrote: > > > > > On May 19, 2020, at 5:21 AM, Arnd Bergmann wrote: > > > > On Thu, Mar 26, 2020 at 4:10 AM Chen Zhou wrote: > >> > >> Hi all, > >> > >> Friendly ping... > > > > I was asked about this patch series, and see that you last

Re: [PATCH] hw_breakpoint: Remove unused '__register_perf_hw_breakpoint' declaration

Hi Peter, Frederic, Ingo On Thu, Apr 30, 2020 at 9:49 AM Bhupesh Sharma wrote: > > Hi Mark, > > Thanks for the review. > > On Tue, Apr 28, 2020 at 3:37 PM Mark Rutland wrote: > > > > Hi Bhupesh, > > > > On Tue, Apr 28, 2020 at 02:22:17PM +0530, Bhupe

[PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

-by: John Donnelly Signed-off-by: Bhupesh Sharma --- Documentation/admin-guide/kdump/vmcoreinfo.rst | 11 +++ arch/arm64/include/asm/pgtable-hwdef.h | 1 + arch/arm64/kernel/crash_core.c | 10 ++ 3 files changed, 22 insertions(+) diff --git a/Documentation

[PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)

...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: ke...@lists.infradead.org Bhupesh Sharma (2): crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo Documentation/admin-guide/kdump/vmcoreinfo.rst | 16

[PATCH v6 1/2] crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo

-by: John Donnelly Signed-off-by: Bhupesh Sharma --- Documentation/admin-guide/kdump/vmcoreinfo.rst | 5 + kernel/crash_core.c| 1 + 2 files changed, 6 insertions(+) diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump

[PATCH v2 1/2] net: qed*: Reduce RX and TX default ring count when running inside kdump kernel

ed-off-by: Bhupesh Sharma --- drivers/net/ethernet/qlogic/qede/qede.h | 2 ++ drivers/net/ethernet/qlogic/qede/qede_main.c | 11 +-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qede/qede.h b/drivers/net/ethernet/qlogic/qede/qede.h

[PATCH v2 0/2] net: Optimize the qed* allocations inside kdump kernel

X ring count in kdump kernel. [PATCH 2/2] - Disables qed SRIOV feature in kdump kernel (as it is normally not a supported kdump target for saving vmcore). [1]. Memstrack tool: https://github.com/ryncsn/memstrack Bhupesh Sharma (2): net: qed*: Reduce RX and TX defaul

[PATCH v2 2/2] net: qed: Disable SRIOV functionality inside kdump kernel

-off-by: Bhupesh Sharma --- drivers/net/ethernet/qlogic/qed/qed_sriov.h | 10 +++--- drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.h b/drivers/net/ethernet/qlogic/qed/qed_sriov.h

Re: [EXT] [PATCH 1/2] net: qed*: Reduce RX and TX default ring count when running inside kdump kernel

Hello Igor, On Wed, May 6, 2020 at 12:21 PM Igor Russkikh wrote: > > > > > #include > > +#include > > #include > > #include > > #include > > @@ -574,13 +575,13 @@ int qede_add_tc_flower_fltr(struct qede_dev *edev, > > __be16 proto, > > #define RX_RING_SIZE

Re: [PATCH 1/2] net: qed*: Reduce RX and TX default ring count when running inside kdump kernel

Hi David, On Wed, May 6, 2020 at 2:54 AM David Miller wrote: > > From: Bhupesh Sharma > Date: Wed, 6 May 2020 00:34:40 +0530 > > > -#define NUM_RX_BDS_DEF ((u16)BIT(10) - 1) > > +#define NUM_RX_BDS_DEF ((is_kdump_kernel()) ? ((u16)BIT(6)

[PATCH 2/2] net: qed: Disable SRIOV functionality inside kdump kernel

-off-by: Bhupesh Sharma --- drivers/net/ethernet/qlogic/qed/qed_sriov.h | 10 +++--- drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.h b/drivers/net/ethernet/qlogic/qed/qed_sriov.h

[PATCH 1/2] net: qed*: Reduce RX and TX default ring count when running inside kdump kernel

ed-off-by: Bhupesh Sharma --- drivers/net/ethernet/qlogic/qede/qede.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qede/qede.h b/drivers/net/ethernet/qlogic/qede/qede.h index 234c6f30effb..b55ab32ef0b3 100644 --- a/drivers/net/ethernet/qlogic/qede/

[PATCH 0/2] net: Optimize the qed* allocations inside kdump kernel

ult TX and RX ring count in kdump kernel. [PATCH 2/2] - Disables qed SRIOV feature in kdump kernel (as it is normally not a supported kdump target for saving vmcore). [1]. Memstrack tool: https://github.com/ryncsn/memstrack - Bhupesh Sharma (2): net: qed*: Reduce RX

Re: [PATCH] hw_breakpoint: Remove unused '__register_perf_hw_breakpoint' declaration

Hi Mark, Thanks for the review. On Tue, Apr 28, 2020 at 3:37 PM Mark Rutland wrote: > > Hi Bhupesh, > > On Tue, Apr 28, 2020 at 02:22:17PM +0530, Bhupesh Sharma wrote: > > commit b326e9560a28 ("hw-breakpoints: Use overflow handler instead of > >

[PATCH] hw_breakpoint: Remove unused '__register_perf_hw_breakpoint' declaration

ation from 'hw_breakpoint.h' as well. Cc: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Signed-off-by: Bhupesh Sharma --- include/linux/hw_breakpoint.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h index 6058c3844a76..fe1302da8

[PATCH] arm64/kexec: Use consistent convention of initializing 'kxec_buf.mem' with KEXEC_BUF_MEM_UNKNOWN

ux-arm-ker...@lists.infradead.org Signed-off-by: Bhupesh Sharma --- arch/arm64/kernel/kexec_image.c| 2 +- arch/arm64/kernel/machine_kexec_file.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c index 2514fd6f12cb..29

Re: [RFC PATCH] vmcore: Add a kernel cmdline device_dump_limit

Hi Kairui, Thanks for the patch. Please see my comments in-line: On 05/10/2019 03:50 PM, Kairui Song wrote: Device dump allow drivers to add device related dump data to vmcore as they want. This have a potential issue, the data is stored in memory, drivers may append too much data and use too

[tip:core/urgent] proc/kcore: Remove unused kclist_add_remap()

Commit-ID: db779ef67ffeadbb44e9e818eb64dbe528e2f48f Gitweb: https://git.kernel.org/tip/db779ef67ffeadbb44e9e818eb64dbe528e2f48f Author: Bhupesh Sharma AuthorDate: Tue, 26 Mar 2019 12:20:28 +0530 Committer: Borislav Petkov CommitDate: Tue, 26 Mar 2019 16:36:03 +0100 proc/kcore: Remove

[PATCH v2 1/2] arm64, vmcoreinfo : Append 'PTRS_PER_PGD' to vmcoreinfo

address supported by underlying kernel. A reference 'makedumpfile' implementation which uses this approach to determining the maximum physical address is available in [0]. [0]. https://github.com/bhupesh-sharma/makedumpfile/blob/52-bit-va-support-via-vmcore-upstream-v3/arch/arm64.c#L459 Cc: Mark

[PATCH v2 0/2] Append new variables to vmcoreinfo (PTRS_PER_PGD for arm64 and MAX_PHYSMEM_BITS for all archs)

Herrenschmidt Cc: Dave Anderson Cc: Kazuhito Hagio Cc: x...@kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: ke...@lists.infradead.org Bhupesh Sharma (2): arm64, vmcoreinfo : Append 'PTRS_PER_PGD' to vmcoreinfo crash_core

[PATCH v2 2/2] crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo

fashion is available here: [0]. https://github.com/bhupesh-sharma/makedumpfile/blob/remove-max-phys-mem-bit-v1/arch/ppc64.c#L471 Cc: Boris Petkov Cc: Ingo Molnar Cc: Thomas Gleixner Cc: James Morse Cc: Will Deacon Cc: Michael Ellerman Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Cc: Dave

Re: [PATCH v5 1/4] tee: add bus driver framework for TEE based devices

> + DEVID(tee_client_device_id); > > > + DEVID_FIELD(tee_client_device_id, uuid); > > > + > > > return 0; > > > } > > > diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c > > > index a37af7d..d0e4172 100644 > > > --- a/scripts/mod/file2alias.c > > > +++ b/scripts/mod/file2alias.c > > > @@ -37,6 +37,9 @@ typedef unsigned char __u8; > > > typedef struct { > > > __u8 b[16]; > > > } uuid_le; > > > +typedef struct { > > > + __u8 b[16]; > > > +} uuid_t; > > > > > > /* Big exception to the "don't include kernel headers into userspace, > > > which > > > * even potentially has different endianness and word sizes, since > > > @@ -1287,6 +1290,21 @@ static int do_typec_entry(const char *filename, > > > void *symval, char *alias) > > > return 1; > > > } > > > > > > +/* Looks like: tee:uuid */ > > > +static int do_tee_entry(const char *filename, void *symval, char *alias) > > > +{ > > > + DEF_FIELD(symval, tee_client_device_id, uuid); > > > + > > > + sprintf(alias, > > > "tee:%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", > > > + uuid.b[0], uuid.b[1], uuid.b[2], uuid.b[3], uuid.b[4], > > > + uuid.b[5], uuid.b[6], uuid.b[7], uuid.b[8], uuid.b[9], > > > + uuid.b[10], uuid.b[11], uuid.b[12], uuid.b[13], uuid.b[14], > > > + uuid.b[15]); > > > + > > > + add_wildcard(alias); > > > + return 1; > > > +} > > > + > > > /* Does namelen bytes of name exactly match the symbol? */ > > > static bool sym_is(const char *name, unsigned namelen, const char > > > *symbol) > > > { > > > @@ -1357,6 +1375,7 @@ static const struct devtable devtable[] = { > > > {"fslmc", SIZE_fsl_mc_device_id, do_fsl_mc_entry}, > > > {"tbsvc", SIZE_tb_service_id, do_tbsvc_entry}, > > > {"typec", SIZE_typec_device_id, do_typec_entry}, > > > + {"tee", SIZE_tee_client_device_id, do_tee_entry}, > > > }; > > > > > > /* Create MODULE_ALIAS() statements. > > > -- > > > 2.7.4 > > > With Daniel's inputs addressed, for this patch: Reviewed-by: Bhupesh Sharma Thanks

Re: [PATCH v4 1/4] tee: add bus driver framework for TEE based devices

ev; > +}; > + > +#define to_tee_client_device(d) container_of(d, struct tee_client_device, > dev) > + > +/** > + * struct tee_client_driver - tee client driver > + * @id_table: device id table supported by this driver > + * @driver:driver structure > + */ > +struct tee_client_driver { > + const tee_client_device_id *id_table; > + struct device_driver driver; > +}; > + > +#define to_tee_client_driver(d) \ > + container_of(d, struct tee_client_driver, driver) > + > #endif /*__TEE_DRV_H*/ > -- > 2.7.4 > LGTM, if there are no further comments on this patch please free to add: Reviewed-by: Bhupesh Sharma Thanks.

Re: [PATCH v2 7/9] arm64: kdump: No need to mark crashkernel pages manually PG_reserved

ally marking pages as PG_reserved is not necessary, they are > already in the desired state (otherwise they would have been handed over > to the buddy as free pages and bad things would happen). > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: James Morse > Cc: Bhupesh Shar

Re: [PATCH v2 6/9] arm64: kexec: no need to ClearPageReserved()

Hi David, Thanks for the patch. On Mon, Jan 14, 2019 at 6:29 PM David Hildenbrand wrote: > > This will be done by free_reserved_page(). > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Bhupesh Sharma > Cc: James Morse > Cc: Marc Zyngier > Cc: Dave Kleikamp >

Re: [PATCH v3 1/4] tee: add bus driver framework for TEE based devices

Hi Sumit, Thanks for the patch. Some nitpicks in-line: On 01/11/2019 05:17 PM, Sumit Garg wrote: Introduce a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/services. In this TEE bus concept, devices/services are identified

Re: [PATCH v2] arm64: invalidate TLB just before turning MMU on

Hi Qian, On Sat, Dec 15, 2018 at 7:24 AM Qian Cai wrote: > > On 12/14/18 2:23 AM, Ard Biesheuvel wrote: > > On Fri, 14 Dec 2018 at 05:08, Qian Cai wrote: > >> Also tried to move the local TLB flush part around a bit inside > >> __cpu_setup(), although it did complete kdump some times, it did

Re: [PATCH 3/3] x86/platform/UV: use efi_runtime_sem to serialise BIOS calls

Hi Hedi, Thanks for the patchset. I will give this a go on my sgi-uv300 machine and come back with more detailed inputs, but I wanted to ask about the hang/panic you mentioned in the cover letter when efi_scratch gets clobbered. Can you describe the same (for e.g. how to reproduce this).

Re: [PATCH v2] arm64: invalidate TLB just before turning MMU on

On Fri, Dec 14, 2018 at 9:39 AM Qian Cai wrote: > > On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash > dump just hung. It has 4 threads on each core. Each 2-core share a same > L1 and L2 caches, so that is 8 CPUs shares those. All CPUs share a same > L3 cache. > > It turned

Re: [PATCH] arm64: invalidate TLB before turning MMU on

Hi Qian Cai, On Thu, Dec 13, 2018 at 10:53 AM Qian Cai wrote: > > On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash > dump just hung. It has 4 threads on each core. Each 2-core share a same > L1 and L2 caches, so that is 8 CPUs shares those. All CPUs share a same > L3 cache. >

Re: [PATCH arm64/kexec] arm64: kexec_file: forbid kdump via kexec_file_load()

xec_file_load' support to have made way upstream for arm64 as well, but I understand that it is stuck till we have an agreement on the DT side of things. So, refusing a crash image loading in such a case makes sense for now. So, please feel free to add: Reviewed-by: Bhupesh Sharma Thanks, Bhupesh

Re: [PATCH 00/10] GICv3 support for kexec/kdump on EFI systems

ing LPI property table @0x000fc042 [0.00] GICv3: CPU0: using reserved LPI pending table @0x000fc05c So, please feel to add: Tested-by: Bhupesh Sharma Thanks, Bhupesh

Re: [PATCH 00/10] GICv3 support for kexec/kdump on EFI systems

ing LPI property table @0x000fc042 [0.00] GICv3: CPU0: using reserved LPI pending table @0x000fc05c So, please feel to add: Tested-by: Bhupesh Sharma Thanks, Bhupesh

Re: [PATCH v3] proc/kcore: fix invalid memory access in multi-page read optimization

ret = -EFAULT; >> goto out; >> } >> + m = NULL; >> } else if (m->type == KCORE_VMALLOC) { >> vread(buf, (char *)start, tsz); >> /* we have to zero-fill user buffer even if no read */ >> -- >> 2.17.1 Looks sane to me, so: Reviewed-by: Bhupesh Sharma Thanks.

Re: [PATCH v3] proc/kcore: fix invalid memory access in multi-page read optimization

ret = -EFAULT; >> goto out; >> } >> + m = NULL; >> } else if (m->type == KCORE_VMALLOC) { >> vread(buf, (char *)start, tsz); >> /* we have to zero-fill user buffer even if no read */ >> -- >> 2.17.1 Looks sane to me, so: Reviewed-by: Bhupesh Sharma Thanks.

Re: [PATCH v4 1/9] proc/kcore: don't grab lock for kclist_add()

NUMBER(HUGETLB_PAGE_DTOR)=2 NUMBER(VA_BITS)=48 NUMBER(kimage_voffset)=0x5492f5c0 NUMBER(PHYS_OFFSET)=0xee138000 CRASHTIME=1532965574 So, for what it is worth: Reviewed-by and Tested

Re: [PATCH v4 1/9] proc/kcore: don't grab lock for kclist_add()

NUMBER(HUGETLB_PAGE_DTOR)=2 NUMBER(VA_BITS)=48 NUMBER(kimage_voffset)=0x5492f5c0 NUMBER(PHYS_OFFSET)=0xee138000 CRASHTIME=1532965574 So, for what it is worth: Reviewed-by and Tested

Re: [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes

have access to mips hardware, so I will be happy to update the v2 to add mips kernel bits as well, in case someone is willing to give it a try on their mips hardware. > On 19/07/18 15:55, Bhupesh Sharma wrote: >> On Thu, Jul 19, 2018 at 5:01 PM, James Morse wrote: >>> On 18/07/

Re: [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes

have access to mips hardware, so I will be happy to update the v2 to add mips kernel bits as well, in case someone is willing to give it a try on their mips hardware. > On 19/07/18 15:55, Bhupesh Sharma wrote: >> On Thu, Jul 19, 2018 at 5:01 PM, James Morse wrote: >>> On 18/07/

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

On Wed, Feb 28, 2018 at 3:37 PM, Andy Shevchenko <andriy.shevche...@linux.intel.com> wrote: > On Wed, 2018-02-28 at 00:29 +0530, Bhupesh Sharma wrote: >> On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins <jtopp...@redhat.com >> > wrote: >> > On 02/27

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

On Wed, Feb 28, 2018 at 3:37 PM, Andy Shevchenko wrote: > On Wed, 2018-02-28 at 00:29 +0530, Bhupesh Sharma wrote: >> On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins > > wrote: >> > On 02/27/2018 07:40 AM, Bhupesh Sharma wrote: >> > > > >> > F

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins <jtopp...@redhat.com> wrote: > On 02/27/2018 07:40 AM, Bhupesh Sharma wrote: >> Hi, >> >> On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins <jtopp...@redhat.com> >> wrote: >>> This patch allo

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

On Tue, Feb 27, 2018 at 8:14 PM, Jonathan Toppins wrote: > On 02/27/2018 07:40 AM, Bhupesh Sharma wrote: >> Hi, >> >> On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins >> wrote: >>> This patch allows a user to configure ACPI to be preferred over >>

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

Hi, On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins wrote: > This patch allows a user to configure ACPI to be preferred over > device-tree. > > Currently for ACPI to be used a user either has to set acpi=on on the > kernel command line or make sure any device tree passed

Re: [PATCH] arm64/acpi: make ACPI boot preference configurable

Hi, On Tue, Feb 27, 2018 at 11:35 AM, Jonathan Toppins wrote: > This patch allows a user to configure ACPI to be preferred over > device-tree. > > Currently for ACPI to be used a user either has to set acpi=on on the > kernel command line or make sure any device tree passed to the kernel > is

[PATCH] arm64: Fix compilation error while accessing MPIDR_HWID_BITMASK from .S files

for assigning the MPIDR_HWID_BITMASK macro value. Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com> --- arch/arm64/include/asm/cputype.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index eda8c5f629fc..350c76

[PATCH] arm64: Fix compilation error while accessing MPIDR_HWID_BITMASK from .S files

for assigning the MPIDR_HWID_BITMASK macro value. Signed-off-by: Bhupesh Sharma --- arch/arm64/include/asm/cputype.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index eda8c5f629fc..350c76a1d15b 100644 --- a/arch

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Tue, Dec 19, 2017 at 10:31 AM, AKASHI Takahiro <takahiro.aka...@linaro.org> wrote: > On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote: >> >> [snip..] >> >> [0.00] linux,usable-memory-range base e80, size 2000 >>

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Tue, Dec 19, 2017 at 10:31 AM, AKASHI Takahiro wrote: > On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote: >> >> [snip..] >> >> [0.00] linux,usable-memory-range base e80, size 2000 >> [0.00] - e80 , 2000 >> [

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Mon, Dec 18, 2017 at 4:48 PM, AKASHI Takahiro <takahiro.aka...@linaro.org> wrote: > Bhupesh, > > On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote: >> On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro >> <takahiro.aka...@linaro.org> wrote: >&g

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

On Mon, Dec 18, 2017 at 4:48 PM, AKASHI Takahiro wrote: > Bhupesh, > > On Mon, Dec 18, 2017 at 02:29:05PM +0530, Bhupesh SHARMA wrote: >> On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro >> wrote: >> > On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wr

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Hi Dave, On Mon, Dec 18, 2017 at 10:46 AM, Dave Young <dyo...@redhat.com> wrote: > kexec@fedoraproject... is for Fedora kexec scripts discussion, changed it > to ke...@lists.infradead.org > > Also add linux-acpi list > On 12/18/17 at 02:31am, Bhupesh Sharma wrote: >> O

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Hi Dave, On Mon, Dec 18, 2017 at 10:46 AM, Dave Young wrote: > kexec@fedoraproject... is for Fedora kexec scripts discussion, changed it > to ke...@lists.infradead.org > > Also add linux-acpi list > On 12/18/17 at 02:31am, Bhupesh Sharma wrote: >> On Fri, Dec 15, 2017 at 3:

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

lso add linux-acpi list > > Thank you. > >> On 12/18/17 at 02:31am, Bhupesh Sharma wrote: >> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel >> > <ard.biesheu...@linaro.org> wrote: >> > > On 15 December 2017 at 09:59, AKASHI Takahiro >> >

Re: arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP

Thank you. > >> On 12/18/17 at 02:31am, Bhupesh Sharma wrote: >> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel >> > wrote: >> > > On 15 December 2017 at 09:59, AKASHI Takahiro >> > > wrote: >> > >> On Wed, Dec 13, 201

Re: [PATCH 0/3] Use mm_struct and switch_mm() instead of manually

achines). So in addition to me testing this on the sgi-uv300 and Dell Optiplex EFI enabled machine, please feel free to add: Reviewed-by: Bhupesh Sharma <bhsha...@redhat.com> Thanks, Bhupesh > Note: > This patch set is based on Linus's tree v4.15-rc3 > > Sai Praneeth (3): &

Re: [PATCH 0/3] Use mm_struct and switch_mm() instead of manually

in the v3. Also as I noted during the v2 review, introducing the 'efi_switch_mm() ' helper instead of manually twiddling with %cr3 seems more cleaner (having personally debugged this leg several times on the underlying x86 EFI machines). So in addition to me testing this on the sgi-uv300 and Dell O

Re: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually

--Original Message- >> From: Sai Praneeth Prakhya [mailto:sai.praneeth.prak...@intel.com] >> Sent: Tuesday, September 5, 2017 7:43 PM >> To: Bhupesh Sharma <bhsha...@redhat.com> >> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Matt Fleming >> &

Re: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually

i Praneeth Prakhya [mailto:sai.praneeth.prak...@intel.com] >> Sent: Tuesday, September 5, 2017 7:43 PM >> To: Bhupesh Sharma >> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Matt Fleming >> ; Ard Biesheuvel ; >> j...@suse.com; Borislav Petkov ; Luck,

Re: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually

Hi Sai, On Sun, Sep 3, 2017 at 1:16 PM, Prakhya, Sai Praneeth wrote: >> > >> > Thanks for this v2. >> > Introducing the 'efi_switch_mm() ' helper instead of manually >> > twiddling with %cr3 seems more cleaner. >> > >> > I have tested this patchset on a x86_64

Re: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually

Hi Sai, On Sun, Sep 3, 2017 at 1:16 PM, Prakhya, Sai Praneeth wrote: >> > >> > Thanks for this v2. >> > Introducing the 'efi_switch_mm() ' helper instead of manually >> > twiddling with %cr3 seems more cleaner. >> > >> > I have tested this patchset on a x86_64 machine with the following >> >

Re: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually

On Sat, Sep 2, 2017 at 7:38 PM, Bhupesh Sharma <bhsha...@redhat.com> wrote: > Hi Sai, > > On Tue, Aug 29, 2017 at 5:07 AM, Sai Praneeth Prakhya > <sai.praneeth.prak...@intel.com> wrote: >> From: Sai Praneeth <sai.praneeth.prak...@intel.com> >> >> Pr

Re: [PATCH V2 0/3] Use mm_struct and switch_mm() instead of manually

On Sat, Sep 2, 2017 at 7:38 PM, Bhupesh Sharma wrote: > Hi Sai, > > On Tue, Aug 29, 2017 at 5:07 AM, Sai Praneeth Prakhya > wrote: >> From: Sai Praneeth >> >> Presently, in x86, to invoke any efi function like >> efi_set_virtual_address_map() or any

  1   2   >