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
<&gcc GCC_QUPV3_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
mux {
> + pins = "gpio43", "gpio44";
> + function = "qup13";
> + };
> +
> + config {
> + pins = "gpio43", "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
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
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/submit
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/
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/
: 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
c: 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/clk-rpmh.c | 1 +
1 file changed, 1 insertion(+)
di
. 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
r.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/sdm845.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm6
r.kernel.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/qco
c: 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
---
Documentation/devicetree/bindings/crypto/qcom-q
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
Bhupesh Sharma (8):
dt-bindings: qcom-qce: Add 'iommus' to required properties
dt-bindings: crypto : Add new compatible strings for qcom-qce
arm
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 "
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
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
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 k
PAGESIZE(PAGE_SIZE);
>
> VMCOREINFO_SYMBOL(init_uts_ns);
> + 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
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
erf_hw_breakpoint' declaration
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
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
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. Curre
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.
&g
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
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
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
---
mm/memcontrol.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mm/
rnel.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
Bhupesh Sharma (2):
mm/memcontrol: Fix OOPS inside mem_cgroup_get_nr_swap_pages()
arm64: Allocate
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.
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
>
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
hine_shutdown();
> }
>
> + kmsg_dump(KMSG_DUMP_SHUTDOWN);
> machine_kexec(kexec_image);
>
> #ifdef CONFIG_KEXEC_JUMP
> --
> 2.25.1
LGTM, so:
Reviewed-by: Bhupesh Sharma
Thanks.
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:
>
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
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
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:
>
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 issue
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 post
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
: 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
Cc: scott.bran...@broadcom.com
Cc: Amit Kachhap
Cc: x...@kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-arm-ker...@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_BI
linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: ke...@lists.infradead.org
Tested-by: John Donnelly
Signed-off-by: Bhupesh Sharma
---
Documentation/admin-guide/kdump/vmcoreinfo.rst | 5 +
kernel/crash_core.c| 1 +
2 files changed, 6
r
Signed-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/q
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
er
Signed-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/q
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 ((u16)BIT(RX_RING_SIZE
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)
er
Signed-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/q
r
Signed-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/ql
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
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
> >
erf_hw_breakpoint' declaration
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_breakpoi
om
Cc: linux-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 2514fd
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 m
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
determine the maximum virtual 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
o Molnar
Cc: Thomas Gleixner
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Benjamin 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
Bhupe
n which reads the
'MAX_PHYSMEM_BITS' value from vmcoreinfo in a arch-independent 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: W
D(typec_device_id, mode);
> > >
> > > + 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
tee_client_device_id id;
> + struct device dev;
> +};
> +
> +#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.
y 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
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
>
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 via
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 tri
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).
Ni
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 out
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.
>
the complete 'kexec_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
distributor tables
[0.00] GICv3: using 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
loff_t *fpos)
>> 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.
NUMBER(PHYS_OFFSET)=0xee138000
CRASHTIME=1532965574
So, for what it is worth:
Reviewed-by and Tested-by: Bhupesh Sharma
Thanks,
Bhupesh
[1] https://www.spinics.net/lists/kexec/msg20842.html
[2] https://www.spinics.net/lists/kexec/msg20618.html
ide note, I don't 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 wrot
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
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
>>&g
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 emp
ffUL'
This patch fixes the same by using the UL() macro correctly 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/arm
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
>> [
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 wrote:
&
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:
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
qs_off') is fixed 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 testi
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,
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
>> > conf
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
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 efi_runtime_service() the code path
> typically involves read_cr3() (save previous pgd), write_cr3()
> (write ef
On Wed, Jun 7, 2017 at 2:59 PM, Michael Ellerman wrote:
> Daniel Micay writes:
>
>> Rather than doing this, the base should just be split for an ELF
>> interpreter like PaX.
>
> I don't quite parse that, I think you mean PaX uses a different base for
> an ELF interpreter vs a regular ET_DYN?
I a
7fff8a68-7fff8a6a r-xp 00:00 0
[vdso]
7fffc6d9-7fffc6dc rw-p 00:00 0
[stack]
Done
Cc: Anton Blanchard
Cc: Daniel Cashman
Cc: Kees Cook
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Signed-off-by: Bhupesh Sharma
---
arch/power
On Sat, May 6, 2017 at 5:06 AM, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote:
>> (Including the folks from SGI since this was hit on a UV system)
>
> Wasn't there a BIOS fix supplied at some point which obviated the need
> to boot with efi=old_map on SGI bo
On Thu, Apr 13, 2017 at 12:39 PM, Balbir Singh wrote:
>>>
>>> Yes. It was derived from TASK_SIZE :
>>>
>>> http://lxr.free-electrons.com/source/arch/powerpc/include/asm/processor.h#L105
>>>
>>
>> That is getting update to 128TB by default and conditionally to 512TB
>>
>
> Since this is compile tim
On Thu, Apr 13, 2017 at 12:28 PM, Aneesh Kumar K.V
wrote:
>
>
> On Thursday 13 April 2017 12:22 PM, Bhupesh Sharma wrote:
>>
>> Hi Aneesh,
>>
>> On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V
>> wrote:
>>>
>>> Bhupesh Sharma writes:
&
Hi Aneesh,
On Thu, Apr 13, 2017 at 12:06 PM, Aneesh Kumar K.V
wrote:
> Bhupesh Sharma writes:
>
>> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT)
>> for
>> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
>> for th
Hi Michael,
On Wed, Mar 29, 2017 at 1:15 AM, Bhupesh Sharma wrote:
> powerpc arch_mmap_rnd() currently uses hard-coded values - (23-PAGE_SHIFT) for
> 32-bit and (30-PAGE_SHIFT) for 64-bit, to generate the random offset
> for the mmap base address for a ASLR ELF.
>
> This patch
Commit-ID: 6e7300cff1c410dde7ac4354b6a0a8cb0a561e54
Gitweb: http://git.kernel.org/tip/6e7300cff1c410dde7ac4354b6a0a8cb0a561e54
Author: Bhupesh Sharma
AuthorDate: Tue, 4 Apr 2017 17:02:41 +0100
Committer: Ingo Molnar
CommitDate: Wed, 5 Apr 2017 12:27:25 +0200
efi/bgrt: Enable ACPI BGRT
Commit-ID: 75def552bb1e0d39918df31b86f7d09e754ea0fc
Gitweb: http://git.kernel.org/tip/75def552bb1e0d39918df31b86f7d09e754ea0fc
Author: Bhupesh Sharma
AuthorDate: Tue, 4 Apr 2017 17:02:40 +0100
Committer: Ingo Molnar
CommitDate: Wed, 5 Apr 2017 12:27:24 +0200
x86/efi/bgrt: Move efi
Commit-ID: b9d7cfccbbeebcd5a4efb34f4587f92bb2402f87
Gitweb: http://git.kernel.org/tip/b9d7cfccbbeebcd5a4efb34f4587f92bb2402f87
Author: Bhupesh Sharma
AuthorDate: Tue, 4 Apr 2017 17:02:41 +0100
Committer: Ingo Molnar
CommitDate: Wed, 5 Apr 2017 09:27:50 +0200
efi/bgrt: Enable ACPI BGRT
Commit-ID: 2ab6c5b95a34685477ec10650ab26aa6c144a1a1
Gitweb: http://git.kernel.org/tip/2ab6c5b95a34685477ec10650ab26aa6c144a1a1
Author: Bhupesh Sharma
AuthorDate: Tue, 4 Apr 2017 17:02:40 +0100
Committer: Ingo Molnar
CommitDate: Wed, 5 Apr 2017 09:27:50 +0200
x86/efi/bgrt: Move efi
, platform
developers may choose where to place this compromise.
Also this patch keeps the default values as new minimums.
Signed-off-by: Bhupesh Sharma
Reviewed-by: Kees Cook
---
* Changes since v2:
v2 can be seen here (https://patchwork.kernel.org/patch/9551509/)
- Changed a few minimum and
On Wed, Mar 8, 2017 at 3:05 PM, Borislav Petkov wrote:
> On Wed, Mar 08, 2017 at 05:09:55PM +0800, Baoquan He wrote:
>> Yes, it looks better. I can repost with this change. Thanks.
>
> No it doesn't:
>
> #define EFI_VA_START ( -4 * (_AC(1, UL) << 30))
> #define EFI_VA_END (-68 * (_AC(1,
Hi Dave,
On Wed, Mar 8, 2017 at 1:48 PM, Dave Young wrote:
> On 03/08/17 at 03:47pm, Baoquan He wrote:
>> EFI allocate runtime services regions down from EFI_VA_START, -4G.
>> It should be top-down handling.
>>
>> Signed-off-by: Baoquan He
>> ---
>> arch/x86/platform/efi/efi_64.c | 2 +-
>> 1 f
__START_KERNEL_map);
>> --
>> 2.5.5
>>
>
> Acked-by: Dave Young
>
Thanks Bao for this fix. This makes the KASLR code consistent with
Address space markers hints in [1]
[1] http://lxr.free-electrons.com/source/arch/x86/mm/dump_pagetables.c#L82
Reviewed-by: Bhupesh Sharma
Regards,
Bhupesh
1 - 100 of 107 matches
Mail list logo
