All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 2/3] remoteproc: qcom_q6v5_mss: Add MBA log extraction support
From: Bjorn Andersson @ 2020-07-17  4:57 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: agross, linux-arm-msm, linux-remoteproc, linux-kernel, evgreen,
	ohad
In-Reply-To: <20200716123630.21892-3-sibis@codeaurora.org>

On Thu 16 Jul 05:36 PDT 2020, Sibi Sankar wrote:

> On SC7180 the MBA firmware stores the bootup text logs in a 4K segment
> at the beginning of the MBA region. Add support to extract the logs
> which will be useful to debug mba boot/authentication issues.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 41 ++++++++++++++++++++++++++----
>  1 file changed, 36 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 95e21ed607cb9..4ddf084b2c6fc 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -9,6 +9,7 @@
>  
>  #include <linux/clk.h>
>  #include <linux/delay.h>
> +#include <linux/devcoredump.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/interrupt.h>
>  #include <linux/kernel.h>
> @@ -37,6 +38,8 @@
>  
>  #define MPSS_CRASH_REASON_SMEM		421
>  
> +#define MBA_LOG_SIZE			SZ_4K
> +
>  /* RMB Status Register Values */
>  #define RMB_PBL_SUCCESS			0x1
>  
> @@ -139,6 +142,7 @@ struct rproc_hexagon_res {
>  	int version;
>  	bool need_mem_protection;
>  	bool has_alt_reset;
> +	bool has_mba_logs;
>  	bool has_spare_reg;
>  };
>  
> @@ -200,6 +204,7 @@ struct q6v5 {
>  	struct qcom_sysmon *sysmon;
>  	bool need_mem_protection;
>  	bool has_alt_reset;
> +	bool has_mba_logs;
>  	bool has_spare_reg;
>  	int mpss_perm;
>  	int mba_perm;
> @@ -518,6 +523,19 @@ static int q6v5_rmb_mba_wait(struct q6v5 *qproc, u32 status, int ms)
>  	return val;
>  }
>  
> +static void q6v5_dump_mba_logs(struct q6v5 *qproc)
> +{
> +	struct rproc *rproc = qproc->rproc;
> +	void *data;
> +
> +	data = vmalloc(MBA_LOG_SIZE);
> +	if (!data)
> +		return;
> +
> +	memcpy(data, qproc->mba_region, MBA_LOG_SIZE);
> +	dev_coredumpv(&rproc->dev, data, MBA_LOG_SIZE, GFP_KERNEL);
> +}
> +
>  static int q6v5proc_reset(struct q6v5 *qproc)
>  {
>  	u32 val;
> @@ -838,6 +856,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  {
>  	int ret;
>  	int xfermemop_ret;
> +	bool mba_load_err = false;
>  
>  	qcom_q6v5_prepare(&qproc->q6v5);
>  
> @@ -931,7 +950,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  	q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
>  	q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
>  	q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_nc);
> -
> +	mba_load_err = true;
>  reclaim_mba:
>  	xfermemop_ret = q6v5_xfer_mem_ownership(qproc, &qproc->mba_perm, true,
>  						false, qproc->mba_phys,
> @@ -939,6 +958,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  	if (xfermemop_ret) {
>  		dev_err(qproc->dev,
>  			"Failed to reclaim mba buffer, system may become unstable\n");
> +	} else if (qproc->has_mba_logs & mba_load_err) {
> +		q6v5_dump_mba_logs(qproc);
>  	}
>  
>  disable_active_clks:
> @@ -968,7 +989,7 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  	return ret;
>  }
>  
> -static void q6v5_mba_reclaim(struct q6v5 *qproc)
> +static void q6v5_mba_reclaim(struct q6v5 *qproc, bool err_path)
>  {
>  	int ret;
>  	u32 val;
> @@ -1006,6 +1027,9 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
>  				      qproc->mba_size);
>  	WARN_ON(ret);
>  
> +	if (qproc->has_mba_logs && err_path && !ret)

Wouldn't it be possible to just call q6v5_dump_mba_logs() directly after
the return from q6v5_mba_reclaim()? That way we can avoid passing the
bool to indicate if the reclaim should also dump some stuff.

Sure we don't have a way to tell if the assign_mem failed, but we're
going to crash shortly anyways (which is something we should change).



I think you should move the has_mba_logs into q6v5_dump_mba_logs(),
making it cause an early return.

Regards,
Bjorn

> +		q6v5_dump_mba_logs(qproc);
> +
>  	ret = qcom_q6v5_unprepare(&qproc->q6v5);
>  	if (ret) {
>  		q6v5_pds_disable(qproc, qproc->proxy_pds,
> @@ -1255,7 +1279,7 @@ static void qcom_q6v5_dump_segment(struct rproc *rproc,
>  						false, true,
>  						qproc->mpss_phys,
>  						qproc->mpss_size);
> -			q6v5_mba_reclaim(qproc);
> +			q6v5_mba_reclaim(qproc, false);
>  		}
>  	}
>  }
> @@ -1297,7 +1321,7 @@ static int q6v5_start(struct rproc *rproc)
>  	return 0;
>  
>  reclaim_mpss:
> -	q6v5_mba_reclaim(qproc);
> +	q6v5_mba_reclaim(qproc, true);
>  
>  	return ret;
>  }
> @@ -1313,7 +1337,7 @@ static int q6v5_stop(struct rproc *rproc)
>  	if (ret == -ETIMEDOUT)
>  		dev_err(qproc->dev, "timed out on wait\n");
>  
> -	q6v5_mba_reclaim(qproc);
> +	q6v5_mba_reclaim(qproc, false);
>  
>  	return 0;
>  }
> @@ -1717,6 +1741,7 @@ static int q6v5_probe(struct platform_device *pdev)
>  
>  	qproc->version = desc->version;
>  	qproc->need_mem_protection = desc->need_mem_protection;
> +	qproc->has_mba_logs = desc->has_mba_logs;
>  
>  	ret = qcom_q6v5_init(&qproc->q6v5, pdev, rproc, MPSS_CRASH_REASON_SMEM,
>  			     qcom_msa_handover);
> @@ -1808,6 +1833,7 @@ static const struct rproc_hexagon_res sc7180_mss = {
>  	},
>  	.need_mem_protection = true,
>  	.has_alt_reset = false,
> +	.has_mba_logs = true,
>  	.has_spare_reg = true,
>  	.version = MSS_SC7180,
>  };
> @@ -1843,6 +1869,7 @@ static const struct rproc_hexagon_res sdm845_mss = {
>  	},
>  	.need_mem_protection = true,
>  	.has_alt_reset = true,
> +	.has_mba_logs = true,
>  	.has_spare_reg = false,
>  	.version = MSS_SDM845,
>  };
> @@ -1870,6 +1897,7 @@ static const struct rproc_hexagon_res msm8998_mss = {
>  	},
>  	.need_mem_protection = true,
>  	.has_alt_reset = false,
> +	.has_mba_logs = false,
>  	.has_spare_reg = false,
>  	.version = MSS_MSM8998,
>  };
> @@ -1900,6 +1928,7 @@ static const struct rproc_hexagon_res msm8996_mss = {
>  	},
>  	.need_mem_protection = true,
>  	.has_alt_reset = false,
> +	.has_mba_logs = false,
>  	.has_spare_reg = false,
>  	.version = MSS_MSM8996,
>  };
> @@ -1933,6 +1962,7 @@ static const struct rproc_hexagon_res msm8916_mss = {
>  	},
>  	.need_mem_protection = false,
>  	.has_alt_reset = false,
> +	.has_mba_logs = false,
>  	.has_spare_reg = false,
>  	.version = MSS_MSM8916,
>  };
> @@ -1974,6 +2004,7 @@ static const struct rproc_hexagon_res msm8974_mss = {
>  	},
>  	.need_mem_protection = false,
>  	.has_alt_reset = false,
> +	.has_mba_logs = false,
>  	.has_spare_reg = false,
>  	.version = MSS_MSM8974,
>  };
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply

* Re: [PATCH v2 0/6] [media] pci: use generic power management
From: Vaibhav Gupta @ 2020-07-17  4:56 UTC (permalink / raw)
  To: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
	Mauro Carvalho Chehab
  Cc: linux-kernel, linux-media, linux-kernel-mentees, Shuah Khan
In-Reply-To: <20200717035608.97254-1-vaibhavgupta40@gmail.com>

On Fri, Jul 17, 2020 at 09:26:02AM +0530, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
> 
> The purpose of this patch series is to upgrade power management in media
> drivers. This has been done by upgrading .suspend() and .resume() callbacks.
> 
> The upgrade makes sure that the involvement of PCI Core does not change the
> order of operations executed in a driver. Thus, does not change its behavior.
> 
> In general, drivers with legacy PM, .suspend() and .resume() make use of PCI
> helper functions like pci_enable/disable_device_mem(), pci_set_power_state(),
> pci_save/restore_state(), pci_enable/disable_device(), etc. to complete
> their job.
> 
> The conversion requires the removal of those function calls, change the
> callbacks' definition accordingly and make use of dev_pm_ops structure.
> 
> v2: v1 possibly broke cx23885 and cx25821.
v1 didn't break anything in real as patch was not applied. But it could have.
> 
> All patches are compile-tested only.
> 
> Test tools:
>     - Compiler: gcc (GCC) 10.1.0
>     - allmodconfig build: make -j$(nproc) W=1 all
> 
> Vaibhav Gupta (6):
>   sta2x11: use generic power management
>   cx23885: use generic power management
>   cx25821: use generic power management
>   cx88: use generic power management
>   meye: use generic power management
>   tw68: use generic power management
> 
>  drivers/media/pci/cx23885/cx23885-core.c |  3 --
>  drivers/media/pci/cx25821/cx25821-core.c |  3 --
>  drivers/media/pci/cx88/cx88-video.c      | 52 +++++--------------
>  drivers/media/pci/meye/meye.c            | 15 ++----
>  drivers/media/pci/sta2x11/sta2x11_vip.c  | 63 ++++++------------------
>  drivers/media/pci/tw68/tw68-core.c       | 30 +++++------
>  6 files changed, 44 insertions(+), 122 deletions(-)
> 
> -- 
> 2.27.0
> 

^ permalink raw reply

* Re: [Linux-kernel-mentees] [PATCH v2 0/6] [media] pci: use generic power management
From: Vaibhav Gupta @ 2020-07-17  4:56 UTC (permalink / raw)
  To: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
	Mauro Carvalho Chehab
  Cc: linux-kernel-mentees, linux-kernel, linux-media
In-Reply-To: <20200717035608.97254-1-vaibhavgupta40@gmail.com>

On Fri, Jul 17, 2020 at 09:26:02AM +0530, Vaibhav Gupta wrote:
> Linux Kernel Mentee: Remove Legacy Power Management.
> 
> The purpose of this patch series is to upgrade power management in media
> drivers. This has been done by upgrading .suspend() and .resume() callbacks.
> 
> The upgrade makes sure that the involvement of PCI Core does not change the
> order of operations executed in a driver. Thus, does not change its behavior.
> 
> In general, drivers with legacy PM, .suspend() and .resume() make use of PCI
> helper functions like pci_enable/disable_device_mem(), pci_set_power_state(),
> pci_save/restore_state(), pci_enable/disable_device(), etc. to complete
> their job.
> 
> The conversion requires the removal of those function calls, change the
> callbacks' definition accordingly and make use of dev_pm_ops structure.
> 
> v2: v1 possibly broke cx23885 and cx25821.
v1 didn't break anything in real as patch was not applied. But it could have.
> 
> All patches are compile-tested only.
> 
> Test tools:
>     - Compiler: gcc (GCC) 10.1.0
>     - allmodconfig build: make -j$(nproc) W=1 all
> 
> Vaibhav Gupta (6):
>   sta2x11: use generic power management
>   cx23885: use generic power management
>   cx25821: use generic power management
>   cx88: use generic power management
>   meye: use generic power management
>   tw68: use generic power management
> 
>  drivers/media/pci/cx23885/cx23885-core.c |  3 --
>  drivers/media/pci/cx25821/cx25821-core.c |  3 --
>  drivers/media/pci/cx88/cx88-video.c      | 52 +++++--------------
>  drivers/media/pci/meye/meye.c            | 15 ++----
>  drivers/media/pci/sta2x11/sta2x11_vip.c  | 63 ++++++------------------
>  drivers/media/pci/tw68/tw68-core.c       | 30 +++++------
>  6 files changed, 44 insertions(+), 122 deletions(-)
> 
> -- 
> 2.27.0
> 
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

^ permalink raw reply

* Re: [PATCH] dt-bindings: uniphier-thermal: add minItems to socionext, tmod-calibration
From: Masahiro Yamada @ 2020-07-17  4:53 UTC (permalink / raw)
  To: Rob Herring
  Cc: DTML, Amit Kucheria, Kunihiko Hayashi, Linux PM mailing list,
	Daniel Lezcano, Linux Kernel Mailing List, Zhang Rui,
	Frank Rowand, linux-arm-kernel
In-Reply-To: <20200716230451.GA3041278@bogus>

On Fri, Jul 17, 2020 at 8:09 AM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jul 07, 2020 at 07:23:38PM +0900, Masahiro Yamada wrote:
> > As the description says, this property contains a pair of calibration
> > values. The number of items must be exactly 2.
> >
> > Add minItems to check a too short property.
> >
> > While I was here, I also added this property to the example because
> > this is the case in the real DT file,
> > arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> >
> > Also, fix the interrupt type (edge -> level) to align with the
> > real DT.
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > ---
> >
> >  .../bindings/thermal/socionext,uniphier-thermal.yaml          | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
> > index 553c9dcdaeeb..57ffd0c4c474 100644
> > --- a/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
> > +++ b/Documentation/devicetree/bindings/thermal/socionext,uniphier-thermal.yaml
> > @@ -29,6 +29,7 @@ properties:
> >
> >    socionext,tmod-calibration:
> >      $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    minItems: 2
>
> The intent was if minItems is not defined, then the default is the same
> as maxItems. This is not the default for json-schema, so the tooling is
> supposed to add it.


This implication is unclear.

maxItems should literally only define the max, and
we should stick to json-schema as much as possible, IMHO.




It would be nice if json-schema had something like:

numItems: 2

as a shorthand for

minItems: 2
maxItems: 2


Masahiro Yamada




> But looking at processed-schema.yaml, it doesn't
> seem to be happening for one case here. I'm working on a fix in the
> tools.
>
> Rob



--
Best Regards
Masahiro Yamada

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2] efi_loader: Rename and correct values for ARM_SMC_MM_*
From: Ilias Apalodimas @ 2020-07-17  4:55 UTC (permalink / raw)
  To: u-boot

Instead of adding the definition for the specific MM SVC used in
StandAloneMM we added the one used in the standard SMC calls.
So change the value from -4 to -5 to match the correct one defined in
EDK2 and rename them to avoid future confusion

Fixes 23a397d2e2fb: ("efi_loader: Add headers for EDK2 StandAloneMM communication")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
---
Changes since v1:
- v1 was efi_loader: Correct value for ARM_SMC_MM_RET_NO_MEMORY
- Renamed all the definitions according to EDK2 
 include/mm_communication.h        | 16 ++++++++--------
 lib/efi_loader/efi_variable_tee.c |  8 ++++----
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/mm_communication.h b/include/mm_communication.h
index f9c05bb7f104..e464cbb48e22 100644
--- a/include/mm_communication.h
+++ b/include/mm_communication.h
@@ -52,14 +52,14 @@ struct efi_mm_communicate_header {
 #define MM_COMMUNICATE_HEADER_SIZE \
 	(sizeof(struct efi_mm_communicate_header))
 
-/* Defined in EDK2 ArmPkg/Include/IndustryStandard/ArmStdSmc.h */
-
-/* MM return error codes */
-#define ARM_SMC_MM_RET_SUCCESS              0
-#define ARM_SMC_MM_RET_NOT_SUPPORTED       -1
-#define ARM_SMC_MM_RET_INVALID_PARAMS      -2
-#define ARM_SMC_MM_RET_DENIED              -3
-#define ARM_SMC_MM_RET_NO_MEMORY           -4
+/* Defined in EDK2 ArmPkg/Include/IndustryStandard/ArmMmSvc.h */
+
+/* SPM return error codes */
+#define ARM_SVC_SPM_RET_SUCCESS               0
+#define ARM_SVC_SPM_RET_NOT_SUPPORTED        -1
+#define ARM_SVC_SPM_RET_INVALID_PARAMS       -2
+#define ARM_SVC_SPM_RET_DENIED               -3
+#define ARM_SVC_SPM_RET_NO_MEMORY            -5
 
 /* Defined in EDK2 MdeModulePkg/Include/Guid/SmmVariableCommon.h */
 
diff --git a/lib/efi_loader/efi_variable_tee.c b/lib/efi_loader/efi_variable_tee.c
index c0423489388a..5f4aae60bf23 100644
--- a/lib/efi_loader/efi_variable_tee.c
+++ b/lib/efi_loader/efi_variable_tee.c
@@ -106,19 +106,19 @@ static efi_status_t optee_mm_communicate(void *comm_buf, ulong dsize)
 	tee_close_session(conn.tee, conn.session);
 
 	switch (param[1].u.value.a) {
-	case ARM_SMC_MM_RET_SUCCESS:
+	case ARM_SVC_SPM_RET_SUCCESS:
 		ret = EFI_SUCCESS;
 		break;
 
-	case ARM_SMC_MM_RET_INVALID_PARAMS:
+	case ARM_SVC_SPM_RET_INVALID_PARAMS:
 		ret = EFI_INVALID_PARAMETER;
 		break;
 
-	case ARM_SMC_MM_RET_DENIED:
+	case ARM_SVC_SPM_RET_DENIED:
 		ret = EFI_ACCESS_DENIED;
 		break;
 
-	case ARM_SMC_MM_RET_NO_MEMORY:
+	case ARM_SVC_SPM_RET_NO_MEMORY:
 		ret = EFI_OUT_OF_RESOURCES;
 		break;
 
-- 
2.28.0.rc0

^ permalink raw reply related

* Re: [PATCH 01/11] powerpc/smp: Cache node for reuse
From: Gautham R Shenoy @ 2020-07-17  4:51 UTC (permalink / raw)
  To: Srikar Dronamraju
  Cc: Nathan Lynch, Gautham R Shenoy, Oliver OHalloran, Michael Neuling,
	Michael Ellerman, Anton Blanchard, linuxppc-dev, Nick Piggin
In-Reply-To: <20200714043624.5648-2-srikar@linux.vnet.ibm.com>

On Tue, Jul 14, 2020 at 10:06:14AM +0530, Srikar Dronamraju wrote:
> While cpu_to_node is inline function with access to per_cpu variable.
> However when using repeatedly, it may be cleaner to cache it in a local
> variable.
> 
> Also fix a build error in a some weird config.
> "error: _numa_cpu_lookup_table_ undeclared"
> 
> No functional change
> 
> Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
> Cc: Michael Ellerman <michaele@au1.ibm.com>
> Cc: Nick Piggin <npiggin@au1.ibm.com>
> Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
> Cc: Nathan Lynch <nathanl@linux.ibm.com>
> Cc: Michael Neuling <mikey@linux.ibm.com>
> Cc: Anton Blanchard <anton@au1.ibm.com>
> Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
> Cc: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
> Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>


LGTM.

Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>

> ---
>  arch/powerpc/kernel/smp.c | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 73199470c265..680c0edcc59d 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -843,7 +843,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
> 
>  	DBG("smp_prepare_cpus\n");
> 
> -	/* 
> +	/*
>  	 * setup_cpu may need to be called on the boot cpu. We havent
>  	 * spun any cpus up but lets be paranoid.
>  	 */
> @@ -854,20 +854,24 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>  	cpu_callin_map[boot_cpuid] = 1;
> 
>  	for_each_possible_cpu(cpu) {
> +		int node = cpu_to_node(cpu);
> +
>  		zalloc_cpumask_var_node(&per_cpu(cpu_sibling_map, cpu),
> -					GFP_KERNEL, cpu_to_node(cpu));
> +					GFP_KERNEL, node);
>  		zalloc_cpumask_var_node(&per_cpu(cpu_l2_cache_map, cpu),
> -					GFP_KERNEL, cpu_to_node(cpu));
> +					GFP_KERNEL, node);
>  		zalloc_cpumask_var_node(&per_cpu(cpu_core_map, cpu),
> -					GFP_KERNEL, cpu_to_node(cpu));
> +					GFP_KERNEL, node);
> +#ifdef CONFIG_NEED_MULTIPLE_NODES
>  		/*
>  		 * numa_node_id() works after this.
>  		 */
>  		if (cpu_present(cpu)) {
> -			set_cpu_numa_node(cpu, numa_cpu_lookup_table[cpu]);
> -			set_cpu_numa_mem(cpu,
> -				local_memory_node(numa_cpu_lookup_table[cpu]));
> +			node = numa_cpu_lookup_table[cpu];
> +			set_cpu_numa_node(cpu, node);
> +			set_cpu_numa_mem(cpu, local_memory_node(node));
>  		}
> +#endif
>  	}
> 
>  	/* Init the cpumasks so the boot CPU is related to itself */
> -- 
> 2.17.1
> 

^ permalink raw reply

* [pm:bleeding-edge] BUILD SUCCESS 6aeb52cce12f3e09ec1af28bc4836406f0267483
From: kernel test robot @ 2020-07-17  4:52 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: linux-pm, devel, linux-acpi

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git  bleeding-edge
branch HEAD: 6aeb52cce12f3e09ec1af28bc4836406f0267483  Merge branch 'pm-cpufreq' into bleeding-edge

elapsed time: 722m

configs tested: 80
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a016-20200716
i386                 randconfig-a011-20200716
i386                 randconfig-a015-20200716
i386                 randconfig-a012-20200716
i386                 randconfig-a013-20200716
i386                 randconfig-a014-20200716
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply

* [Devel] [pm:bleeding-edge] BUILD SUCCESS 6aeb52cce12f3e09ec1af28bc4836406f0267483
From: kernel test robot @ 2020-07-17  4:52 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 4245 bytes --]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git  bleeding-edge
branch HEAD: 6aeb52cce12f3e09ec1af28bc4836406f0267483  Merge branch 'pm-cpufreq' into bleeding-edge

elapsed time: 722m

configs tested: 80
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm                                 defconfig
arm                              allyesconfig
arm                              allmodconfig
arm                               allnoconfig
arm64                            allyesconfig
arm64                               defconfig
arm64                            allmodconfig
arm64                             allnoconfig
i386                             allyesconfig
i386                                defconfig
i386                              debian-10.3
i386                              allnoconfig
ia64                             allmodconfig
ia64                                defconfig
ia64                              allnoconfig
ia64                             allyesconfig
m68k                             allmodconfig
m68k                              allnoconfig
m68k                           sun3_defconfig
m68k                                defconfig
m68k                             allyesconfig
nios2                               defconfig
nios2                            allyesconfig
openrisc                            defconfig
c6x                              allyesconfig
c6x                               allnoconfig
openrisc                         allyesconfig
nds32                               defconfig
nds32                             allnoconfig
csky                             allyesconfig
csky                                defconfig
alpha                               defconfig
alpha                            allyesconfig
xtensa                           allyesconfig
h8300                            allyesconfig
h8300                            allmodconfig
xtensa                              defconfig
arc                                 defconfig
arc                              allyesconfig
sh                               allmodconfig
sh                                allnoconfig
microblaze                        allnoconfig
mips                             allyesconfig
mips                              allnoconfig
mips                             allmodconfig
parisc                            allnoconfig
parisc                              defconfig
parisc                           allyesconfig
parisc                           allmodconfig
powerpc                             defconfig
powerpc                          allyesconfig
powerpc                          rhel-kconfig
powerpc                          allmodconfig
powerpc                           allnoconfig
i386                 randconfig-a016-20200716
i386                 randconfig-a011-20200716
i386                 randconfig-a015-20200716
i386                 randconfig-a012-20200716
i386                 randconfig-a013-20200716
i386                 randconfig-a014-20200716
riscv                            allyesconfig
riscv                             allnoconfig
riscv                               defconfig
riscv                            allmodconfig
s390                             allyesconfig
s390                              allnoconfig
s390                             allmodconfig
s390                                defconfig
sparc                            allyesconfig
sparc                               defconfig
sparc64                             defconfig
sparc64                           allnoconfig
sparc64                          allyesconfig
sparc64                          allmodconfig
x86_64                                   rhel
x86_64                                    lkp
x86_64                              fedora-25
x86_64                    rhel-7.6-kselftests
x86_64                               rhel-8.3
x86_64                                  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply

* [PATCH v4 00/25] x86: Enhance MTRR functionality to support multiple CPUs
From: Bin Meng @ 2020-07-17  4:50 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <CAPnjgZ1heEK91uZfNoM8HnNL3djkAZw7wgj0mj-YShwSLxhx1w@mail.gmail.com>

Hi Simon,

On Fri, Jul 17, 2020 at 11:24 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Tue, 7 Jul 2020 at 19:36, Simon Glass <sjg@chromium.org> wrote:
> >
> > At present MTRRs are mirrored to the secondary CPUs only once, as those
> > CPUs are started up. But U-Boot may add more MTRRs later, e.g. if it
> > decides that a video console must be set up.
> >
> > This series enhances the x86 multi-processor support to allow MTRRs to
> > be updated at any time. It also updates the 'mtrr' command to support
> > setting the MTRRs on CPUs other than the boot CPU.
> >
> > Changes in v4:
> > - Update get_bsp() to return zero when SMP is not inited
> > - Add a Kconfig to control this feature, enabled only on APL
> > - Only enable this feature of CONFIG_SMP_AP_WORK is enabled
> > - Allow running on the BSP if SMP is not enabled
> > - Update mp_next_cpu() to stop if CONFIG_SMP_AP_WORK is not enabled
>
> Is anything else needed with this series?

This series needs to be rebased on top of u-boot-x86/master. Currently
it does not apply.

Regards,
Bin

^ permalink raw reply

* Re: [git pull] drm fixes for 5.8-rc6
From: pr-tracker-bot @ 2020-07-17  4:50 UTC (permalink / raw)
  To: Dave Airlie; +Cc: Linus Torvalds, Daniel Vetter, dri-devel, LKML
In-Reply-To: <CAPM=9txCq=97pFiCoOGLz7-Ght-spbVFKURx_b0kVw9sO1+=zw@mail.gmail.com>

The pull request you sent on Fri, 17 Jul 2020 13:42:02 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8882572675c1bb1cc544f4e229a11661f1fc52e4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply

* Re: [git pull] drm fixes for 5.8-rc6
From: pr-tracker-bot @ 2020-07-17  4:50 UTC (permalink / raw)
  To: Dave Airlie; +Cc: Daniel Vetter, Linus Torvalds, LKML, dri-devel
In-Reply-To: <CAPM=9txCq=97pFiCoOGLz7-Ght-spbVFKURx_b0kVw9sO1+=zw@mail.gmail.com>

The pull request you sent on Fri, 17 Jul 2020 13:42:02 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8882572675c1bb1cc544f4e229a11661f1fc52e4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [gpio:ib-for-each-clump 4/4] include/linux/bitmap.h:639:45: sparse: sparse: shift too big (64) for type unsigned long
From: Syed Nayyar Waris @ 2020-07-17  4:49 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: kernel test robot, kbuild-all, open list:GPIO SUBSYSTEM,
	Linus Walleij
In-Reply-To: <CAHp75VezG1ZnC-1UWea2Q-q-=c_32HOcBTXrd7cy4HzB-uW8JA@mail.gmail.com>

On Fri, Jul 17, 2020 at 2:55 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Thu, Jul 16, 2020 at 11:13 PM kernel test robot <lkp@intel.com> wrote:
> >
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git ib-for-each-clump
> > head:   3358c938236d6a1be51124fbbb2698e50689d382
> > commit: 3358c938236d6a1be51124fbbb2698e50689d382 [4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value.
> > config: alpha-randconfig-s031-20200716 (attached as .config)
> > compiler: alpha-linux-gcc (GCC) 9.3.0
> > reproduce:
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # apt-get install sparse
> >         # sparse version: v0.6.2-49-g707c5017-dirty
> >         git checkout 3358c938236d6a1be51124fbbb2698e50689d382
> >         # save the attached .config to linux build tree
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=alpha
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> >
> >
> > sparse warnings: (new ones prefixed by >>)
> >
> > >> include/linux/bitmap.h:639:45: sparse: sparse: shift too big (64) for type unsigned long
> > >> include/linux/bitmap.h:639:45: sparse: sparse: shift too big (64) for type unsigned long
> >    include/linux/bitmap.h:594:63: sparse: sparse: shift too big (64) for type unsigned long
> > >> include/linux/bitmap.h:639:45: sparse: sparse: shift too big (64) for type unsigned long
> > >> include/linux/bitmap.h:638:17: sparse: sparse: invalid access past the end of 'old' (8 8)
> >
> > vim +639 include/linux/bitmap.h
> >
> > 169c474fb22d8a5 William Breathitt Gray 2019-12-04  613
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  614  /**
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  615   * bitmap_set_value - set n-bit value within a memory region
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  616   * @map: address to the bitmap memory region
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  617   * @value: value of nbits
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  618   * @start: bit offset of the n-bit value
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  619   * @nbits: size of value in bits
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  620   */
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  621  static inline void bitmap_set_value(unsigned long *map,
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  622                                      unsigned long value,
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  623                                      unsigned long start, unsigned long nbits)
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  624  {
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  625          const size_t index = BIT_WORD(start);
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  626          const unsigned long offset = start % BITS_PER_LONG;
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  627          const unsigned long ceiling = roundup(start + 1, BITS_PER_LONG);
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  628          const unsigned long space = ceiling - start;
>
> If start == 0:
>   index = 0, offset = 0, ceiling = 64, space = 64
>
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  629
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  630          value &= GENMASK(nbits - 1, 0);
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  631
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  632          if (space >= nbits) {
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  633                  map[index] &= ~(GENMASK(nbits + offset - 1, offset));
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  634                  map[index] |= value << offset;
>
> if nbits > space...
>
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  635          } else {
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  636                  map[index] &= ~BITMAP_FIRST_WORD_MASK(start);
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  637                  map[index] |= value << offset;
>
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27 @638                  map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits);
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27 @639                  map[index + 1] |= (value >> space);
>
> space = 64...
>
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  640          }
> > e77c9b6f35c4bdf Syed Nayyar Waris      2020-06-27  641  }
>
> I don't see the test case for this. Can you provide one?
>
>
> --
> With Best Regards,
> Andy Shevchenko

Thanks Andy, but actually, I intentionally want and need 'space' to be
64, in the scenario (situation) mentioned above.

I think this same sparse warning was discussed earlier also, when this
same warning was reported by the buildbot in an earlier version of
patch. Later it was clarified by the sparse-check maintainer that this
warning is to be ignored and no code fix is required.

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2202377.html

Regarding your question on the test case. Actually a 64 bit clump size
test is not added because the tests will always run; and when it runs
on machine where BITS_PER_LONG is 32 bits, it will fail, because in
'for_each_set_clump', it is needed that clump size is less than
BITS_PER_LONG.

I hope I have not misunderstood something.

Regards
Syed Nayyar Waris

^ permalink raw reply

* Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace redirection
From: Andy Lutomirski @ 2020-07-17  4:48 UTC (permalink / raw)
  To: Gabriel Krisman Bertazi
  Cc: Andy Lutomirski, Thomas Gleixner, LKML, kernel, Matthew Wilcox,
	Paul Gofman, Kees Cook, open list:KERNEL SELFTEST FRAMEWORK,
	Shuah Khan
In-Reply-To: <87wo32j394.fsf@collabora.com>

On Thu, Jul 16, 2020 at 7:15 PM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Andy Lutomirski <luto@kernel.org> writes:
>
> > On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi
> > <krisman@collabora.com> wrote:
> >>
> >
> > This is quite nice.  I have a few comments, though:
> >
> > You mentioned rt_sigreturn().  Should this automatically exempt the
> > kernel-provided signal restorer on architectures (e.g. x86_32) that
> > provide one?
>
> That seems reasonable.  Not sure how easy it is to do it, though.

For better or for worse, it's currently straightforward because the code is:

__kernel_sigreturn:
.LSTART_sigreturn:
        popl %eax               /* XXX does this mean it needs unwind info? */
        movl $__NR_sigreturn, %eax
        SYSCALL_ENTER_KERNEL

and SYSCALL_ENTER_KERNEL is hardwired as int $0x80.  (The latter is
probably my fault, for better or for worse.)  So this would change to:

__vdso32_sigreturn_syscall:
  SYSCALL_ENTER_KERNEL

and vdso2c would wire up __vdso32_sigreturn_syscall.  Then there would
be something like:

bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs);

and that would be that.  Does anyone have an opinion as to whether
this is a good idea?  Modern glibc shouldn't be using this mechanism,
I think, but I won't swear to it.

>
> > The amount of syscall entry wiring that arches need to do is IMO
> > already a bit out of hand.  Should we instead rename TIF_SECCOMP to
> > TIF_SYSCALL_INTERCEPTION and have one generic callback that handles
> > seccomp and this new thing?
>
> Considering the previous suggestion from Kees to hide it inside the
> tracehook and Thomas rework of this path, I'm not sure what is the best
> solution here, but some rework of these flags is due.  Thomas suggested
> expanding these flags to 64 bits and having some arch specific and
> arch-agnostic flags.  With the storage expansion and arch-agnostic flags,
> would this still be desirable?

I think it would be desirable to consolidate this to avoid having
multiple arches need to separately wire up all of these mechanisms.
I'm not sure that the initial upstream implementation needs this, but
it might be nice to support this out of the box on all arches with
seccomp support.

>
> >> +int do_syscall_user_dispatch(struct pt_regs *regs)
> >> +{
> >> +       struct syscall_user_dispatch *sd = &current->syscall_dispatch;
> >> +       unsigned long ip = instruction_pointer(regs);
> >> +       char state;
> >> +
> >> +       if (likely(ip >= sd->dispatcher_start && ip <= sd->dispatcher_end))
> >> +               return 0;
> >> +
> >> +       if (likely(sd->selector)) {
> >> +               if (unlikely(__get_user(state, sd->selector)))
> >> +                       do_exit(SIGSEGV);
> >> +
> >> +               if (likely(state == 0))
> >> +                       return 0;
> >> +
> >> +               if (state != 1)
> >> +                       do_exit(SIGSEGV);
> >
> > This seems a bit extreme and hard to debug if it ever happens.
>
> Makes sense, but I don't see a better way to return the error here.
> Maybe a SIGSYS with a different si_errno?  Alternatively, we could
> revert to the previous behavior of allowing syscalls on state != 0, that
> existed in v1.  What do you think?
>

I don't have a strong opinion.  SIGSYS with different si_errno is
probably reasonable.

--Andy

^ permalink raw reply

* Re: [PATCH v3 02/12] powerpc/kexec_file: mark PPC64 specific code
From: Hari Bathini @ 2020-07-17  4:46 UTC (permalink / raw)
  To: Thiago Jung Bauermann
  Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
	Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
	Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <87v9io8c13.fsf@morokweng.localdomain>



On 16/07/20 7:19 am, Thiago Jung Bauermann wrote:
> 
> I didn't forget about this patch. I just wanted to see more of the
> changes before comenting on it.
> 
> Hari Bathini <hbathini@linux.ibm.com> writes:
> 
>> Some of the kexec_file_load code isn't PPC64 specific. Move PPC64
>> specific code from kexec/file_load.c to kexec/file_load_64.c. Also,
>> rename purgatory/trampoline.S to purgatory/trampoline_64.S in the
>> same spirit.
> 
> There's only a 64 bit implementation of kexec_file_load() so this is a
> somewhat theoretical exercise, but there's no harm in getting the code
> organized, so:
> 
> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> 
> I have just one question below.

<snip>

>> +/**
>> + * setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
>> + *                       being loaded.
>> + * @image:               kexec image being loaded.
>> + * @fdt:                 Flattened device tree for the next kernel.
>> + * @initrd_load_addr:    Address where the next initrd will be loaded.
>> + * @initrd_len:          Size of the next initrd, or 0 if there will be none.
>> + * @cmdline:             Command line for the next kernel, or NULL if there will
>> + *                       be none.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>> +			unsigned long initrd_load_addr,
>> +			unsigned long initrd_len, const char *cmdline)
>> +{
>> +	int chosen_node, ret;
>> +
>> +	/* Remove memory reservation for the current device tree. */
>> +	ret = delete_fdt_mem_rsv(fdt, __pa(initial_boot_params),
>> +				 fdt_totalsize(initial_boot_params));
>> +	if (ret == 0)
>> +		pr_debug("Removed old device tree reservation.\n");
>> +	else if (ret != -ENOENT) {
>> +		pr_err("Failed to remove old device-tree reservation.\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = setup_new_fdt(image, fdt, initrd_load_addr, initrd_len,
>> +			    cmdline, &chosen_node);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = fdt_setprop(fdt, chosen_node, "linux,booted-from-kexec", NULL, 0);
>> +	if (ret)
>> +		pr_err("Failed to update device-tree with linux,booted-from-kexec\n");
>> +
>> +	return ret;
>> +}
> 
> For setup_purgatory_ppc64() you start with an empty function and build
> from there, but for setup_new_fdt_ppc64() you moved some code here. Is
> the code above 64 bit specific?

Actually, I was not quiet sure if fdt updates like in patch 6 & patch 9 can be
done after setup_ima_buffer() call. If you can confirm, I will move them back
to setup_purgatory()

Thanks
Hari

^ permalink raw reply

* Re: [dpdk-dev] [PATCH v8 2/3] devtools: prevent use of rte atomic APIs in future patches
From: Phil Yang @ 2020-07-17  4:48 UTC (permalink / raw)
  To: Honnappa Nagarahalli, thomas@monjalon.net
  Cc: dev@dpdk.org, Mcnamara, John, David Christensen, dev,
	jerinj@marvell.com, Ananyev, Konstantin, Ola Liljedahl,
	Bruce Richardson, Ruifeng Wang, nd, David Marchand, nd, nd, nd
In-Reply-To: <DB6PR0802MB2216E14488C3DF27CDE9733D987F0@DB6PR0802MB2216.eurprd08.prod.outlook.com>

Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

<snip>
> 
> > >
> > > > Subject: Re: [dpdk-dev] [PATCH v8 2/3] devtools: prevent use of rte
> > > > atomic APIs in future patches
> > > >
> > > > 16/07/2020 12:48, David Marchand:
> > > > > On Thu, Jul 16, 2020 at 6:58 AM Phil Yang <phil.yang@arm.com> wrote:
> > > > > >  check_forbidden_additions() { # <patch>
> > > > > >         res=0
> > > > > > +       c11_atomics_dir="lib/librte_distributor lib/librte_hash
> > lib/librte_kni
> > > > > > +                        lib/librte_lpm lib/librte_rcu lib/librte_ring
> > > > > > +                        lib/librte_stack lib/librte_vhost
> > > > > > +                        drivers/event/octeontx drivers/event/octeontx2
> > > > > > +                        drivers/event/opdl drivers/net/bnx2x
> drivers/net/hinic
> > > > > > +                        drivers/net/hns3 drivers/net/memif
> > drivers/net/thunderx
> > > > > > +                        drivers/net/virtio examples/l2fwd-event"
> > > > >
> > > > > I prefer a form like:
> > > > >
> > > > > +    c11_atomics_dir=""
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/event/octeontx"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/event/octeontx2"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/event/opdl"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/net/bnx2x"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/net/hinic"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/net/hns3"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/net/memif"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/net/thunderx"
> > > > > +    c11_atomics_dir="$c11_atomics_dir drivers/net/virtio"
> > > > > +    c11_atomics_dir="$c11_atomics_dir examples/l2fwd-event"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_distributor"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_hash"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_kni"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_lpm"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_rcu"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_ring"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_stack"
> > > > > +    c11_atomics_dir="$c11_atomics_dir lib/librte_vhost"
> > > > >
> > > > > Easier to read and update.
> > > >
> > > > Why do we need this list at all?
> > > > Are we allowed to add new code with old atomics in other
> > > > directories?
> > > > How bad it is to have a warning on non-converted libs?
> > >
> > > From my perspective, the pros of this list are :
> > > 1. Avoid introducing false warnings in non-converted modules. Otherwise,
> > the maintainers have to wonder if that module is converted or not.
> >
> > Don't we want to convert all libs?
> The goal is to convert all the libs.
> 
> > If we are adding one more rte_atomic in a lib, we should ask the question
> > why not converting to C11, no?
> Agree, I am fine with this approach. That will kind of distribute the conversion
> work as well.

Will do in V9.

Thanks,
Phil
> 
> >
> > > 2. Keep non-converted modules compatible. C11 atomic builtins cannot
> be
> > used directly for rte_atomicXX_t variables.
> > >
> > > The cons are :
> > > 1. The list needs updating every time we convert a module.
> This list will go away once all the modules are converted.
> 
> > > 2. The script is not elegant as before.
> >
> >
> 


^ permalink raw reply

* Re: [PATCH] e1000e: using bottom half to send packets
From: Li Qiang @ 2020-07-17  4:46 UTC (permalink / raw)
  To: Jason Wang
  Cc: Paolo Bonzini, Dmitry Fleytman, Li Qiang, Qemu Developers,
	Michael S. Tsirkin
In-Reply-To: <281e3c85-b8eb-0c3e-afc3-41011861b8ea@redhat.com>

Jason Wang <jasowang@redhat.com> 于2020年7月17日周五 上午11:10写道:
>
>
> On 2020/7/17 上午12:14, Li Qiang wrote:
> > Alexander Bulekov reported a UAF bug related e1000e packets send.
> >
> > -->https://bugs.launchpad.net/qemu/+bug/1886362
> >
> > This is because the guest trigger a e1000e packet send and set the
> > data's address to e1000e's MMIO address. So when the e1000e do DMA
> > it will write the MMIO again and trigger re-entrancy and finally
> > causes this UAF.
> >
> > Paolo suggested to use a bottom half whenever MMIO is doing complicate
> > things in here:
> > -->https://lists.nongnu.org/archive/html/qemu-devel/2020-07/msg03342.html
> >
> > Reference here:
> > 'The easiest solution is to delay processing of descriptors to a bottom
> > half whenever MMIO is doing something complicated.  This is also better
> > for latency because it will free the vCPU thread more quickly and leave
> > the work to the I/O thread.'
>
>
> I think several things were missed in this patch (take virtio-net as a
> reference), do we need the following things:
>

Thanks Jason,
In fact I know this, I'm scared for touching this but I want to try.
Thanks for your advice.

> - Cancel the bh when VM is stopped.

Ok. I think add a vm state change notifier for e1000e can address this.

> - A throttle to prevent bh from executing too much timer?

Ok, I think add a config timeout and add a timer in e1000e can address this.

> - A flag to record whether or not this a pending tx (and migrate it?)

Is just a flag enough? Could you explain more about the idea behind
processing the virtio-net/e1000e using bh like this?
For example, if the guest trigger a lot of packets send and if the bh
is scheduled in IO thread. So will we lost packets?
How we avoid this in virtio-net.

Thanks,
Li Qiang



>
> Thanks
>
>
> >
> > This patch fixes this UAF.
> >
> > Signed-off-by: Li Qiang <liq3ea@163.com>
> > ---
> >   hw/net/e1000e_core.c | 25 +++++++++++++++++--------
> >   hw/net/e1000e_core.h |  2 ++
> >   2 files changed, 19 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
> > index bcd186cac5..6165b04b68 100644
> > --- a/hw/net/e1000e_core.c
> > +++ b/hw/net/e1000e_core.c
> > @@ -2423,32 +2423,27 @@ e1000e_set_dbal(E1000ECore *core, int index, uint32_t val)
> >   static void
> >   e1000e_set_tctl(E1000ECore *core, int index, uint32_t val)
> >   {
> > -    E1000E_TxRing txr;
> >       core->mac[index] = val;
> >
> >       if (core->mac[TARC0] & E1000_TARC_ENABLE) {
> > -        e1000e_tx_ring_init(core, &txr, 0);
> > -        e1000e_start_xmit(core, &txr);
> > +        qemu_bh_schedule(core->tx[0].tx_bh);
> >       }
> >
> >       if (core->mac[TARC1] & E1000_TARC_ENABLE) {
> > -        e1000e_tx_ring_init(core, &txr, 1);
> > -        e1000e_start_xmit(core, &txr);
> > +        qemu_bh_schedule(core->tx[1].tx_bh);
> >       }
> >   }
> >
> >   static void
> >   e1000e_set_tdt(E1000ECore *core, int index, uint32_t val)
> >   {
> > -    E1000E_TxRing txr;
> >       int qidx = e1000e_mq_queue_idx(TDT, index);
> >       uint32_t tarc_reg = (qidx == 0) ? TARC0 : TARC1;
> >
> >       core->mac[index] = val & 0xffff;
> >
> >       if (core->mac[tarc_reg] & E1000_TARC_ENABLE) {
> > -        e1000e_tx_ring_init(core, &txr, qidx);
> > -        e1000e_start_xmit(core, &txr);
> > +        qemu_bh_schedule(core->tx[qidx].tx_bh);
> >       }
> >   }
> >
> > @@ -3322,6 +3317,16 @@ e1000e_vm_state_change(void *opaque, int running, RunState state)
> >       }
> >   }
> >
> > +static void e1000e_core_tx_bh(void *opaque)
> > +{
> > +    struct e1000e_tx *tx = opaque;
> > +    E1000ECore *core = tx->core;
> > +    E1000E_TxRing txr;
> > +
> > +    e1000e_tx_ring_init(core, &txr, tx - &core->tx[0]);
> > +    e1000e_start_xmit(core, &txr);
> > +}
> > +
> >   void
> >   e1000e_core_pci_realize(E1000ECore     *core,
> >                           const uint16_t *eeprom_templ,
> > @@ -3340,6 +3345,8 @@ e1000e_core_pci_realize(E1000ECore     *core,
> >       for (i = 0; i < E1000E_NUM_QUEUES; i++) {
> >           net_tx_pkt_init(&core->tx[i].tx_pkt, core->owner,
> >                           E1000E_MAX_TX_FRAGS, core->has_vnet);
> > +        core->tx[i].core = core;
> > +        core->tx[i].tx_bh = qemu_bh_new(e1000e_core_tx_bh, &core->tx[i]);
> >       }
> >
> >       net_rx_pkt_init(&core->rx_pkt, core->has_vnet);
> > @@ -3367,6 +3374,8 @@ e1000e_core_pci_uninit(E1000ECore *core)
> >       for (i = 0; i < E1000E_NUM_QUEUES; i++) {
> >           net_tx_pkt_reset(core->tx[i].tx_pkt);
> >           net_tx_pkt_uninit(core->tx[i].tx_pkt);
> > +        qemu_bh_delete(core->tx[i].tx_bh);
> > +        core->tx[i].tx_bh = NULL;
> >       }
> >
> >       net_rx_pkt_uninit(core->rx_pkt);
> > diff --git a/hw/net/e1000e_core.h b/hw/net/e1000e_core.h
> > index aee32f7e48..94ddc6afc2 100644
> > --- a/hw/net/e1000e_core.h
> > +++ b/hw/net/e1000e_core.h
> > @@ -77,6 +77,8 @@ struct E1000Core {
> >           unsigned char sum_needed;
> >           bool cptse;
> >           struct NetTxPkt *tx_pkt;
> > +        QEMUBH *tx_bh;
> > +        E1000ECore *core;
> >       } tx[E1000E_NUM_QUEUES];
> >
> >       struct NetRxPkt *rx_pkt;
>


^ permalink raw reply

* Re: [PATCH] drm/amd/powerplay: widely share the API for data table retrieving
From: Alex Deucher @ 2020-07-17  4:47 UTC (permalink / raw)
  To: Evan Quan; +Cc: Deucher, Alexander, amd-gfx list
In-Reply-To: <20200716051226.23316-1-evan.quan@amd.com>

On Thu, Jul 16, 2020 at 1:12 AM Evan Quan <evan.quan@amd.com> wrote:
>
> Considering the data table retrieving can be more widely shared,
> amdgpu_atombios.c is the right place.
>
> Change-Id: Id89476c14709b5676bbf043371a27f27b94a58ed
> Signed-off-by: Evan Quan <evan.quan@amd.com>

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c    | 17 +++++++++++++++++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h    |  7 +++++++
>  drivers/gpu/drm/amd/powerplay/amdgpu_smu.c      | 16 ----------------
>  drivers/gpu/drm/amd/powerplay/arcturus_ppt.c    |  3 ++-
>  drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h  |  4 ----
>  drivers/gpu/drm/amd/powerplay/navi10_ppt.c      |  5 +++--
>  .../gpu/drm/amd/powerplay/sienna_cichlid_ppt.c  |  3 ++-
>  drivers/gpu/drm/amd/powerplay/smu_v11_0.c       |  5 +++--
>  8 files changed, 34 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> index c687432da426..29f767e026e4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> @@ -2036,3 +2036,20 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
>         return 0;
>  }
>
> +int amdgpu_atombios_get_data_table(struct amdgpu_device *adev,
> +                                  uint32_t table,
> +                                  uint16_t *size,
> +                                  uint8_t *frev,
> +                                  uint8_t *crev,
> +                                  uint8_t **addr)
> +{
> +       uint16_t data_start;
> +
> +       if (!amdgpu_atom_parse_data_header(adev->mode_info.atom_context, table,
> +                                          size, frev, crev, &data_start))
> +               return -EINVAL;
> +
> +       *addr = (uint8_t *)adev->mode_info.atom_context->bios + data_start;
> +
> +       return 0;
> +}
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
> index fd8f18074f7a..1321ec09c734 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h
> @@ -216,6 +216,13 @@ int amdgpu_atombios_get_svi2_info(struct amdgpu_device *adev,
>                               u8 voltage_type,
>                               u8 *svd_gpio_id, u8 *svc_gpio_id);
>
> +int amdgpu_atombios_get_data_table(struct amdgpu_device *adev,
> +                                  uint32_t table,
> +                                  uint16_t *size,
> +                                  uint8_t *frev,
> +                                  uint8_t *crev,
> +                                  uint8_t **addr);
> +
>  void amdgpu_atombios_fini(struct amdgpu_device *adev);
>  int amdgpu_atombios_init(struct amdgpu_device *adev);
>
> diff --git a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> index 03125c8a2145..01d669a36e1f 100644
> --- a/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/powerplay/amdgpu_smu.c
> @@ -676,22 +676,6 @@ static int smu_late_init(void *handle)
>         return 0;
>  }
>
> -int smu_get_atom_data_table(struct smu_context *smu, uint32_t table,
> -                           uint16_t *size, uint8_t *frev, uint8_t *crev,
> -                           uint8_t **addr)
> -{
> -       struct amdgpu_device *adev = smu->adev;
> -       uint16_t data_start;
> -
> -       if (!amdgpu_atom_parse_data_header(adev->mode_info.atom_context, table,
> -                                          size, frev, crev, &data_start))
> -               return -EINVAL;
> -
> -       *addr = (uint8_t *)adev->mode_info.atom_context->bios + data_start;
> -
> -       return 0;
> -}
> -
>  static int smu_init_fb_allocations(struct smu_context *smu)
>  {
>         struct amdgpu_device *adev = smu->adev;
> diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
> index 56dc20a617fd..578c50e294c7 100644
> --- a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
> @@ -27,6 +27,7 @@
>  #include "smu_internal.h"
>  #include "atomfirmware.h"
>  #include "amdgpu_atomfirmware.h"
> +#include "amdgpu_atombios.h"
>  #include "smu_v11_0.h"
>  #include "smu11_driver_if_arcturus.h"
>  #include "soc15_common.h"
> @@ -488,7 +489,7 @@ static int arcturus_append_powerplay_table(struct smu_context *smu)
>         index = get_index_into_master_table(atom_master_list_of_data_tables_v2_1,
>                                            smc_dpm_info);
>
> -       ret = smu_get_atom_data_table(smu, index, NULL, NULL, NULL,
> +       ret = amdgpu_atombios_get_data_table(smu->adev, index, NULL, NULL, NULL,
>                                       (uint8_t **)&smc_dpm_table);
>         if (ret)
>                 return ret;
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
> index 70181ba7ee0c..ba9beffb887d 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
> @@ -678,10 +678,6 @@ bool smu_mode1_reset_is_support(struct smu_context *smu);
>  int smu_mode1_reset(struct smu_context *smu);
>  int smu_mode2_reset(struct smu_context *smu);
>
> -extern int smu_get_atom_data_table(struct smu_context *smu, uint32_t table,
> -                                  uint16_t *size, uint8_t *frev, uint8_t *crev,
> -                                  uint8_t **addr);
> -
>  extern const struct amd_ip_funcs smu_ip_funcs;
>
>  extern const struct amdgpu_ip_block_version smu_v11_0_ip_block;
> diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> index ead135f39c7e..0c21e5de8997 100644
> --- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
> @@ -28,6 +28,7 @@
>  #include "smu_internal.h"
>  #include "atomfirmware.h"
>  #include "amdgpu_atomfirmware.h"
> +#include "amdgpu_atombios.h"
>  #include "soc15_common.h"
>  #include "smu_v11_0.h"
>  #include "smu11_driver_if_navi10.h"
> @@ -467,7 +468,7 @@ static int navi10_append_powerplay_table(struct smu_context *smu)
>         index = get_index_into_master_table(atom_master_list_of_data_tables_v2_1,
>                                            smc_dpm_info);
>
> -       ret = smu_get_atom_data_table(smu, index, NULL, NULL, NULL,
> +       ret = amdgpu_atombios_get_data_table(adev, index, NULL, NULL, NULL,
>                                       (uint8_t **)&smc_dpm_table);
>         if (ret)
>                 return ret;
> @@ -487,7 +488,7 @@ static int navi10_append_powerplay_table(struct smu_context *smu)
>                         sizeof(*smc_dpm_table) - sizeof(smc_dpm_table->table_header));
>                 break;
>         case 7: /* nv12 */
> -               ret = smu_get_atom_data_table(smu, index, NULL, NULL, NULL,
> +               ret = amdgpu_atombios_get_data_table(adev, index, NULL, NULL, NULL,
>                                               (uint8_t **)&smc_dpm_table_v4_7);
>                 if (ret)
>                         return ret;
> diff --git a/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c b/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
> index 5faef41b63a3..389d8350534a 100644
> --- a/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c
> @@ -28,6 +28,7 @@
>  #include "smu_internal.h"
>  #include "atomfirmware.h"
>  #include "amdgpu_atomfirmware.h"
> +#include "amdgpu_atombios.h"
>  #include "smu_v11_0.h"
>  #include "smu11_driver_if_sienna_cichlid.h"
>  #include "soc15_common.h"
> @@ -399,7 +400,7 @@ static int sienna_cichlid_append_powerplay_table(struct smu_context *smu)
>         index = get_index_into_master_table(atom_master_list_of_data_tables_v2_1,
>                                             smc_dpm_info);
>
> -       ret = smu_get_atom_data_table(smu, index, NULL, NULL, NULL,
> +       ret = amdgpu_atombios_get_data_table(smu->adev, index, NULL, NULL, NULL,
>                                       (uint8_t **)&smc_dpm_table);
>         if (ret)
>                 return ret;
> diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> index 829c15984847..06a2ea12cba0 100644
> --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
> @@ -32,6 +32,7 @@
>  #include "smu_internal.h"
>  #include "atomfirmware.h"
>  #include "amdgpu_atomfirmware.h"
> +#include "amdgpu_atombios.h"
>  #include "smu_v11_0.h"
>  #include "soc15_common.h"
>  #include "atom.h"
> @@ -416,7 +417,7 @@ int smu_v11_0_setup_pptable(struct smu_context *smu)
>                 index = get_index_into_master_table(atom_master_list_of_data_tables_v2_1,
>                                                     powerplayinfo);
>
> -               ret = smu_get_atom_data_table(smu, index, &atom_table_size, &frev, &crev,
> +               ret = amdgpu_atombios_get_data_table(adev, index, &atom_table_size, &frev, &crev,
>                                               (uint8_t **)&table);
>                 if (ret)
>                         return ret;
> @@ -631,7 +632,7 @@ int smu_v11_0_get_vbios_bootup_values(struct smu_context *smu)
>         index = get_index_into_master_table(atom_master_list_of_data_tables_v2_1,
>                                             firmwareinfo);
>
> -       ret = smu_get_atom_data_table(smu, index, &size, &frev, &crev,
> +       ret = amdgpu_atombios_get_data_table(smu->adev, index, &size, &frev, &crev,
>                                       (uint8_t **)&header);
>         if (ret)
>                 return ret;
> --
> 2.27.0
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply

* linux-next: manual merge of the tip tree with the crypto tree
From: Stephen Rothwell @ 2020-07-17  4:46 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	Herbert Xu, Linux Crypto List
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Uros Bizjak,
	Chang S. Bae, Sasha Levin

[-- Attachment #1: Type: text/plain, Size: 4279 bytes --]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/include/asm/inst.h

between commit:

  d7866e503bdc ("crypto: x86 - Remove include/asm/inst.h")

from the crypto tree and commit:

  eaad981291ee ("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")

from the tip tree.

I fixed it up (I brought the file back but removed what the crypto tree
no longer needed - see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

I think if the crypto tree brought back this file as well (even without
the RDPID macro, it would make this conflict much more manageable.

/* SPDX-License-Identifier: GPL-2.0 */
/*
 * Generate .byte code for some instructions not supported by old
 * binutils.
 */
#ifndef X86_ASM_INST_H
#define X86_ASM_INST_H

#ifdef __ASSEMBLY__

#define REG_NUM_INVALID		100

#define REG_TYPE_R32		0
#define REG_TYPE_R64		1
#define REG_TYPE_XMM		2
#define REG_TYPE_INVALID	100

	.macro R32_NUM opd r32
	\opd = REG_NUM_INVALID
	.ifc \r32,%eax
	\opd = 0
	.endif
	.ifc \r32,%ecx
	\opd = 1
	.endif
	.ifc \r32,%edx
	\opd = 2
	.endif
	.ifc \r32,%ebx
	\opd = 3
	.endif
	.ifc \r32,%esp
	\opd = 4
	.endif
	.ifc \r32,%ebp
	\opd = 5
	.endif
	.ifc \r32,%esi
	\opd = 6
	.endif
	.ifc \r32,%edi
	\opd = 7
	.endif
#ifdef CONFIG_X86_64
	.ifc \r32,%r8d
	\opd = 8
	.endif
	.ifc \r32,%r9d
	\opd = 9
	.endif
	.ifc \r32,%r10d
	\opd = 10
	.endif
	.ifc \r32,%r11d
	\opd = 11
	.endif
	.ifc \r32,%r12d
	\opd = 12
	.endif
	.ifc \r32,%r13d
	\opd = 13
	.endif
	.ifc \r32,%r14d
	\opd = 14
	.endif
	.ifc \r32,%r15d
	\opd = 15
	.endif
#endif
	.endm

	.macro R64_NUM opd r64
	\opd = REG_NUM_INVALID
#ifdef CONFIG_X86_64
	.ifc \r64,%rax
	\opd = 0
	.endif
	.ifc \r64,%rcx
	\opd = 1
	.endif
	.ifc \r64,%rdx
	\opd = 2
	.endif
	.ifc \r64,%rbx
	\opd = 3
	.endif
	.ifc \r64,%rsp
	\opd = 4
	.endif
	.ifc \r64,%rbp
	\opd = 5
	.endif
	.ifc \r64,%rsi
	\opd = 6
	.endif
	.ifc \r64,%rdi
	\opd = 7
	.endif
	.ifc \r64,%r8
	\opd = 8
	.endif
	.ifc \r64,%r9
	\opd = 9
	.endif
	.ifc \r64,%r10
	\opd = 10
	.endif
	.ifc \r64,%r11
	\opd = 11
	.endif
	.ifc \r64,%r12
	\opd = 12
	.endif
	.ifc \r64,%r13
	\opd = 13
	.endif
	.ifc \r64,%r14
	\opd = 14
	.endif
	.ifc \r64,%r15
	\opd = 15
	.endif
#endif
	.endm

	.macro XMM_NUM opd xmm
	\opd = REG_NUM_INVALID
	.ifc \xmm,%xmm0
	\opd = 0
	.endif
	.ifc \xmm,%xmm1
	\opd = 1
	.endif
	.ifc \xmm,%xmm2
	\opd = 2
	.endif
	.ifc \xmm,%xmm3
	\opd = 3
	.endif
	.ifc \xmm,%xmm4
	\opd = 4
	.endif
	.ifc \xmm,%xmm5
	\opd = 5
	.endif
	.ifc \xmm,%xmm6
	\opd = 6
	.endif
	.ifc \xmm,%xmm7
	\opd = 7
	.endif
	.ifc \xmm,%xmm8
	\opd = 8
	.endif
	.ifc \xmm,%xmm9
	\opd = 9
	.endif
	.ifc \xmm,%xmm10
	\opd = 10
	.endif
	.ifc \xmm,%xmm11
	\opd = 11
	.endif
	.ifc \xmm,%xmm12
	\opd = 12
	.endif
	.ifc \xmm,%xmm13
	\opd = 13
	.endif
	.ifc \xmm,%xmm14
	\opd = 14
	.endif
	.ifc \xmm,%xmm15
	\opd = 15
	.endif
	.endm

	.macro REG_TYPE type reg
	R32_NUM reg_type_r32 \reg
	R64_NUM reg_type_r64 \reg
	XMM_NUM reg_type_xmm \reg
	.if reg_type_r64 <> REG_NUM_INVALID
	\type = REG_TYPE_R64
	.elseif reg_type_r32 <> REG_NUM_INVALID
	\type = REG_TYPE_R32
	.elseif reg_type_xmm <> REG_NUM_INVALID
	\type = REG_TYPE_XMM
	.else
	\type = REG_TYPE_INVALID
	.endif
	.endm

	.macro PFX_OPD_SIZE
	.byte 0x66
	.endm

	.macro PFX_REX opd1 opd2 W=0
	.if ((\opd1 | \opd2) & 8) || \W
	.byte 0x40 | ((\opd1 & 8) >> 3) | ((\opd2 & 8) >> 1) | (\W << 3)
	.endif
	.endm

	.macro MODRM mod opd1 opd2
	.byte \mod | (\opd1 & 7) | ((\opd2 & 7) << 3)
	.endm

.macro RDPID opd
	REG_TYPE rdpid_opd_type \opd
	.if rdpid_opd_type == REG_TYPE_R64
	R64_NUM rdpid_opd \opd
	.else
	R32_NUM rdpid_opd \opd
	.endif
	.byte 0xf3
	.if rdpid_opd > 7
	PFX_REX rdpid_opd 0
	.endif
	.byte 0x0f, 0xc7
	MODRM 0xc0 rdpid_opd 0x7
.endm
#endif

#endif

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* Re: [PATCH v3 02/12] powerpc/kexec_file: mark PPC64 specific code
From: Hari Bathini @ 2020-07-17  4:46 UTC (permalink / raw)
  To: Thiago Jung Bauermann
  Cc: Pingfan Liu, Nayna Jain, Kexec-ml, Mahesh J Salgaonkar,
	Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain, Petr Tesarik,
	Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <87v9io8c13.fsf@morokweng.localdomain>



On 16/07/20 7:19 am, Thiago Jung Bauermann wrote:
> 
> I didn't forget about this patch. I just wanted to see more of the
> changes before comenting on it.
> 
> Hari Bathini <hbathini@linux.ibm.com> writes:
> 
>> Some of the kexec_file_load code isn't PPC64 specific. Move PPC64
>> specific code from kexec/file_load.c to kexec/file_load_64.c. Also,
>> rename purgatory/trampoline.S to purgatory/trampoline_64.S in the
>> same spirit.
> 
> There's only a 64 bit implementation of kexec_file_load() so this is a
> somewhat theoretical exercise, but there's no harm in getting the code
> organized, so:
> 
> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> 
> I have just one question below.

<snip>

>> +/**
>> + * setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
>> + *                       being loaded.
>> + * @image:               kexec image being loaded.
>> + * @fdt:                 Flattened device tree for the next kernel.
>> + * @initrd_load_addr:    Address where the next initrd will be loaded.
>> + * @initrd_len:          Size of the next initrd, or 0 if there will be none.
>> + * @cmdline:             Command line for the next kernel, or NULL if there will
>> + *                       be none.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>> +			unsigned long initrd_load_addr,
>> +			unsigned long initrd_len, const char *cmdline)
>> +{
>> +	int chosen_node, ret;
>> +
>> +	/* Remove memory reservation for the current device tree. */
>> +	ret = delete_fdt_mem_rsv(fdt, __pa(initial_boot_params),
>> +				 fdt_totalsize(initial_boot_params));
>> +	if (ret == 0)
>> +		pr_debug("Removed old device tree reservation.\n");
>> +	else if (ret != -ENOENT) {
>> +		pr_err("Failed to remove old device-tree reservation.\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = setup_new_fdt(image, fdt, initrd_load_addr, initrd_len,
>> +			    cmdline, &chosen_node);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = fdt_setprop(fdt, chosen_node, "linux,booted-from-kexec", NULL, 0);
>> +	if (ret)
>> +		pr_err("Failed to update device-tree with linux,booted-from-kexec\n");
>> +
>> +	return ret;
>> +}
> 
> For setup_purgatory_ppc64() you start with an empty function and build
> from there, but for setup_new_fdt_ppc64() you moved some code here. Is
> the code above 64 bit specific?

Actually, I was not quiet sure if fdt updates like in patch 6 & patch 9 can be
done after setup_ima_buffer() call. If you can confirm, I will move them back
to setup_purgatory()

Thanks
Hari

^ permalink raw reply

* Re: [PATCH v3 02/12] powerpc/kexec_file: mark PPC64 specific code
From: Hari Bathini @ 2020-07-17  4:46 UTC (permalink / raw)
  To: Thiago Jung Bauermann
  Cc: Pingfan Liu, Petr Tesarik, Nayna Jain, Kexec-ml,
	Mahesh J Salgaonkar, Mimi Zohar, lkml, linuxppc-dev, Sourabh Jain,
	Andrew Morton, Dave Young, Vivek Goyal, Eric Biederman
In-Reply-To: <87v9io8c13.fsf@morokweng.localdomain>



On 16/07/20 7:19 am, Thiago Jung Bauermann wrote:
> 
> I didn't forget about this patch. I just wanted to see more of the
> changes before comenting on it.
> 
> Hari Bathini <hbathini@linux.ibm.com> writes:
> 
>> Some of the kexec_file_load code isn't PPC64 specific. Move PPC64
>> specific code from kexec/file_load.c to kexec/file_load_64.c. Also,
>> rename purgatory/trampoline.S to purgatory/trampoline_64.S in the
>> same spirit.
> 
> There's only a 64 bit implementation of kexec_file_load() so this is a
> somewhat theoretical exercise, but there's no harm in getting the code
> organized, so:
> 
> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> 
> I have just one question below.

<snip>

>> +/**
>> + * setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
>> + *                       being loaded.
>> + * @image:               kexec image being loaded.
>> + * @fdt:                 Flattened device tree for the next kernel.
>> + * @initrd_load_addr:    Address where the next initrd will be loaded.
>> + * @initrd_len:          Size of the next initrd, or 0 if there will be none.
>> + * @cmdline:             Command line for the next kernel, or NULL if there will
>> + *                       be none.
>> + *
>> + * Returns 0 on success, negative errno on error.
>> + */
>> +int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
>> +			unsigned long initrd_load_addr,
>> +			unsigned long initrd_len, const char *cmdline)
>> +{
>> +	int chosen_node, ret;
>> +
>> +	/* Remove memory reservation for the current device tree. */
>> +	ret = delete_fdt_mem_rsv(fdt, __pa(initial_boot_params),
>> +				 fdt_totalsize(initial_boot_params));
>> +	if (ret == 0)
>> +		pr_debug("Removed old device tree reservation.\n");
>> +	else if (ret != -ENOENT) {
>> +		pr_err("Failed to remove old device-tree reservation.\n");
>> +		return ret;
>> +	}
>> +
>> +	ret = setup_new_fdt(image, fdt, initrd_load_addr, initrd_len,
>> +			    cmdline, &chosen_node);
>> +	if (ret)
>> +		return ret;
>> +
>> +	ret = fdt_setprop(fdt, chosen_node, "linux,booted-from-kexec", NULL, 0);
>> +	if (ret)
>> +		pr_err("Failed to update device-tree with linux,booted-from-kexec\n");
>> +
>> +	return ret;
>> +}
> 
> For setup_purgatory_ppc64() you start with an empty function and build
> from there, but for setup_new_fdt_ppc64() you moved some code here. Is
> the code above 64 bit specific?

Actually, I was not quiet sure if fdt updates like in patch 6 & patch 9 can be
done after setup_ima_buffer() call. If you can confirm, I will move them back
to setup_purgatory()

Thanks
Hari

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply

* Re: [RFC PATCH v3 16/18] gpu: host1x: mipi: Split tegra_mipi_calibrate and tegra_mipi_wait
From: Sowjanya Komatineni @ 2020-07-17  4:46 UTC (permalink / raw)
  To: Dmitry Osipenko, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
	jonathanh-DDmLM1+adcrQT0dZR+AlfA, frankc-DDmLM1+adcrQT0dZR+AlfA,
	hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sakari.ailus-X3B1VOXEql0,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	helen.koike-ZGY8ohtN/8qB+jHODAdFcQ
  Cc: sboyd-DgEjT+Ai2ygdnm+yROfE0A,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <550f1796-67ca-5856-223d-c68360243954-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>


On 7/16/20 5:16 PM, Sowjanya Komatineni wrote:
>
> On 7/16/20 4:47 PM, Dmitry Osipenko wrote:
>> 17.07.2020 02:09, Sowjanya Komatineni пишет:
>>> On 7/16/20 4:06 PM, Sowjanya Komatineni wrote:
>>>> On 7/16/20 4:01 PM, Dmitry Osipenko wrote:
>>>>> 17.07.2020 01:49, Sowjanya Komatineni пишет:
>>>>>>> What keeps MIPI clock enabled after completion of the
>>>>>>> tegra_mipi_calibrate() invocation?
>>>>>> MIPI clock is disabled at end of tegra_mipi_calibrate and is 
>>>>>> re-enabled
>>>>>> during tegra_mipi_wait.
>>>>>>
>>>>>> I think I should fix this to keep the clock enabled till calibration
>>>>>> results are latched.
>>>>>>
>>>>>> All consumers of tegra_mipi_calibrate() will call tegra_mipi_wait().
>>>>>>
>>>>>> So will remove clk_disable mipi clk at end of tegra_mipi_calibrate()
>>>>>> and
>>>>>> clk_enable mipi_clk at beginning of tegra_mipi_wait()
>>>>> Isn't it possible to perform the calibration after enabling CSI and
>>>>> before of starting the sensor streaming?
>>>> Currently this is what I am doing. Triggering calibration start during
>>>> CSI receiver being ready and then sensor streaming will happen where
>>>> internal MIPI CAL detects for LP -> HS transition and applies results
>>>> to pads. So checking for calibration results after sensor stream is
>>>> enabled
>>> 1. Calling tegra_mipi_calibrate() during CSI streaming where CSI pads
>>> are enabled and receiver is kept ready
>>>
>>> 2. Start Sensor stream
>>>
>>> 3. Calling tegra_mipi_wait() to check for MIPI Cal status.
>>>
>>> So as mipi cal clk need to be kept enabled till 3rd step, we can enable
>>> clock during tegra_mipi_calibrate() and leave it enabled and disable it
>>> in tegra_mipi_wait after status check.
>>  From TRM:
>>
>> The following sequence is recommended for capturing a single frame:
>>
>> 1. Set up CSI registers for use case such as number of lanes, virtual
>> channel, etc.
>> 2. Initialize and power up CSI interface
>> 3. Wait for initialization time or done signal from calibration logic
>> 4. Power up camera through the I2C interface
>> 5. All CSI data and clock lanes are in stop state, LP11
>> 6. Initiate frame capture through the I2C
>> 7. Frame done, CSI goes back to stop state, LP11
>>
>> Hence, is it really necessary to perform the manual calibration?
>
> done signal from calibration logic will happen only when it sees LP to 
> HS transition as thats when calibration results are applied to pads 
> and then done signal is set.
>
> Also MIPI Pads calibration need to be done on every power off/on. So 
> need to do calibration and trigger it along with CSI receiver 
> programming to keep it ready and then need to check/wait for status 
> only after sensor stream happens as thats where LP->HS transition happen.
>
Looks like sequence posted in TRM need to be updated clearly for proper 
MIPI CAL start and wait.

Correct steps should be like below

1. Set up CSI registers for use case such as number of lanes, virtual  
channel, etc.
2. Initialize and power up CSI CIL interface
3. Program MIPI CAL bias pads, cal configs, cal control registers and 
enable calibration start
4. Power up camera through the I2C interface and start sensor streaming 
through the I2C

Note: All sensors might not leave pads in LP-11 state as sensor may be 
power down when not in use.

So start streaming prior to checking for calibration done status as 
LP-11 -> HS transition happens during sensor stream and calibration 
logic can apply results to pads and update done status,

5. Wait for done signal from calibration logic

6. perform frame capture thru VI
7. Frame done, CSI goes back to stop state, LP11

Will work internally to correct sequence in TRM ...


In mipi driver will update as below to have mipi clk enabled till 
calibration status check is done.

Always tegra_mipi_wait() followes tegra_mipi_calibrate() in both DSI and 
CSI. So below sequence should work good.

tegra_mipi_calibrate()

- clk_enable mipi cal
- program mipi cal registers (bias pads cfgs, mipi cal ctrl and trigger 
calibration start)

tegra_mipi_wait()
- read mipi cal status and wait for active and done bits
- clk_disable mipi cal

Thanks

Sowjanya

^ permalink raw reply

* [PATCH] tools/memory-model: document the "one-time init" pattern
From: Eric Biggers @ 2020-07-17  4:44 UTC (permalink / raw)
  To: linux-kernel, linux-arch, Paul E . McKenney
  Cc: linux-fsdevel, Akira Yokosawa, Alan Stern, Andrea Parri,
	Boqun Feng, Daniel Lustig, Darrick J . Wong, Dave Chinner,
	David Howells, Jade Alglave, Luc Maranget, Nicholas Piggin,
	Peter Zijlstra, Will Deacon

From: Eric Biggers <ebiggers@google.com>

The "one-time init" pattern is implemented incorrectly in various places
in the kernel.  And when people do try to implement it correctly, it is
unclear what to use.  Try to give some proper guidance.

This is motivated by the discussion at
https://lkml.kernel.org/linux-fsdevel/20200713033330.205104-1-ebiggers@kernel.org/T/#u
regarding fixing the initialization of super_block::s_dio_done_wq.

Cc: Akira Yokosawa <akiyks@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrea Parri <parri.andrea@gmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Daniel Lustig <dlustig@nvidia.com>
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Jade Alglave <j.alglave@ucl.ac.uk>
Cc: Luc Maranget <luc.maranget@inria.fr>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Paul E. McKenney <paulmck@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 tools/memory-model/Documentation/recipes.txt | 151 +++++++++++++++++++
 1 file changed, 151 insertions(+)

diff --git a/tools/memory-model/Documentation/recipes.txt b/tools/memory-model/Documentation/recipes.txt
index 7fe8d7aa3029..04beb06dbfc7 100644
--- a/tools/memory-model/Documentation/recipes.txt
+++ b/tools/memory-model/Documentation/recipes.txt
@@ -519,6 +519,157 @@ CPU1 puts the waiting task to sleep and CPU0 fails to wake it up.
 
 Note that use of locking can greatly simplify this pattern.
 
+One-time init
+-------------
+
+The "one-time init" pattern is when multiple tasks can race to
+initialize the same data structure(s) on first use.
+
+In many cases, it's best to just avoid the need for this by simply
+initializing the data ahead of time.
+
+But in cases where the data would often go unused, one-time init can be
+appropriate to avoid wasting kernel resources.  It can also be
+appropriate if the initialization has other prerequisites which preclude
+it being done ahead of time.
+
+First, consider if your data has (a) global or static scope, (b) can be
+initialized from atomic context, and (c) cannot fail to be initialized.
+If all of those apply, just use DO_ONCE() from <linux/once.h>:
+
+	DO_ONCE(func);
+
+If that doesn't apply, you'll have to implement one-time init yourself.
+
+The simplest implementation just uses a mutex and an 'inited' flag.
+This implementation should be used where feasible:
+
+	static bool foo_inited;
+	static DEFINE_MUTEX(foo_init_mutex);
+
+	int init_foo_if_needed(void)
+	{
+		int err = 0;
+
+		mutex_lock(&foo_init_mutex);
+		if (!foo_inited) {
+			err = init_foo();
+			if (err == 0)
+				foo_inited = true;
+		}
+		mutex_unlock(&foo_init_mutex);
+		return err;
+	}
+
+The above example uses static variables, but this solution also works
+for initializing something that is part of another data structure.  The
+mutex may still be static.
+
+In where cases where taking the mutex in the "already initialized" case
+presents scalability concerns, the implementation can be optimized to
+check the 'inited' flag outside the mutex.  Unfortunately, this
+optimization is often implemented incorrectly by using a plain load.
+That violates the memory model and may result in unpredictable behavior.
+
+A correct implementation is:
+
+	static bool foo_inited;
+	static DEFINE_MUTEX(foo_init_mutex);
+
+	int init_foo_if_needed(void)
+	{
+		int err = 0;
+
+		/* pairs with smp_store_release() below */
+		if (smp_load_acquire(&foo_inited))
+			return 0;
+
+		mutex_lock(&foo_init_mutex);
+		if (!foo_inited) {
+			err = init_foo();
+			if (err == 0) /* pairs with smp_load_acquire() above */
+				smp_store_release(&foo_inited, true);
+		}
+		mutex_unlock(&foo_init_mutex);
+		return err;
+	}
+
+If only a single data structure is being initialized, then the pointer
+itself can take the place of the 'inited' flag:
+
+	static struct foo *foo;
+	static DEFINE_MUTEX(foo_init_mutex);
+
+	int init_foo_if_needed(void)
+	{
+		int err = 0;
+
+		/* pairs with smp_store_release() below */
+		if (smp_load_acquire(&foo))
+			return 0;
+
+		mutex_lock(&foo_init_mutex);
+		if (!foo) {
+			struct foo *p = alloc_foo();
+
+			if (p) /* pairs with smp_load_acquire() above */
+				smp_store_release(&foo, p);
+			else
+				err = -ENOMEM;
+		}
+		mutex_unlock(&foo_init_mutex);
+		return err;
+	}
+
+There are also cases in which the smp_load_acquire() can be replaced by
+the more lightweight READ_ONCE().  (smp_store_release() is still
+required.)  Specifically, if all initialized memory is transitively
+reachable from the pointer itself, then there is no control dependency
+so the data dependency barrier provided by READ_ONCE() is sufficient.
+
+However, using the READ_ONCE() optimization is discouraged for
+nontrivial data structures, as it can be difficult to determine if there
+is a control dependency.  For complex data structures it may depend on
+internal implementation details of other kernel subsystems.
+
+For the single-pointer case, a further optimized implementation
+eliminates the mutex and instead uses compare-and-exchange:
+
+	static struct foo *foo;
+
+	int init_foo_if_needed(void)
+	{
+		struct foo *p;
+
+		/* pairs with successful cmpxchg_release() below */
+		if (smp_load_acquire(&foo))
+			return 0;
+
+		p = alloc_foo();
+		if (!p)
+			return -ENOMEM;
+
+		/* on success, pairs with smp_load_acquire() above and below */
+		if (cmpxchg_release(&foo, NULL, p) != NULL) {
+			free_foo(p);
+			/* pairs with successful cmpxchg_release() above */
+			smp_load_acquire(&foo);
+		}
+		return 0;
+	}
+
+Note that when the cmpxchg_release() fails due to another task already
+having done it, a second smp_load_acquire() is required, since we still
+need to acquire the data that the other task released.  You may be
+tempted to upgrade cmpxchg_release() to cmpxchg() with the goal of it
+acting as both ACQUIRE and RELEASE, but that doesn't work here because
+cmpxchg() only guarantees memory ordering if it succeeds.
+
+Because of the above subtlety, the version with the mutex instead of
+cmpxchg_release() should be preferred, except potentially in cases where
+it is difficult to provide anything other than a global mutex and where
+the one-time data is part of a frequently allocated structure.  In that
+case, a global mutex might present scalability concerns.
 
 Rules of thumb
 ==============
-- 
2.27.0

^ permalink raw reply related

* Re: [dpdk-dev] [PATCH v8 1/3] doc: add optimizations using C11 atomic built-ins
From: Phil Yang @ 2020-07-17  4:44 UTC (permalink / raw)
  To: Honnappa Nagarahalli, thomas@monjalon.net,
	john.mcnamara@intel.com, drc@linux.vnet.ibm.com, dev@dpdk.org
  Cc: david.marchand@redhat.com, jerinj@marvell.com,
	konstantin.ananyev@intel.com, Ola Liljedahl,
	bruce.richardson@intel.com, Ruifeng Wang, nd, Marko Kovacevic, nd,
	nd
In-Reply-To: <DB6PR0802MB221637BEA39FB68E5E9017E3987F0@DB6PR0802MB2216.eurprd08.prod.outlook.com>

Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:

<snip>
> 
> > Subject: [PATCH v8 1/3] doc: add optimizations using C11 atomic built-ins
> >
> > Add information about possible optimizations using C11 atomic built-ins.
> >
> > Signed-off-by: Phil Yang <phil.yang@arm.com>
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> 
> Thanks for the changes, they look good now.
> 
> David wanted to change 'built-ins' to 'builtins', otherwise
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>

Will do in the next version.
Thanks.

> 
> > ---
> >  doc/guides/prog_guide/writing_efficient_code.rst | 59
> > +++++++++++++++++++++++-
> >  1 file changed, 58 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/prog_guide/writing_efficient_code.rst
> > b/doc/guides/prog_guide/writing_efficient_code.rst
> > index 849f63e..53a1ca1 100644
> > --- a/doc/guides/prog_guide/writing_efficient_code.rst
> > +++ b/doc/guides/prog_guide/writing_efficient_code.rst
> > @@ -167,7 +167,13 @@ but with the added cost of lower throughput.
> >  Locks and Atomic Operations
> >  ---------------------------
> >
> > -Atomic operations imply a lock prefix before the instruction,
> > +This section describes some key considerations when using locks and
> > +atomic operations in the DPDK environment.
> > +
> > +Locks
> > +~~~~~
> > +
> > +On x86, atomic operations imply a lock prefix before the instruction,
> >  causing the processor's LOCK# signal to be asserted during execution of
> the
> > following instruction.
> >  This has a big impact on performance in a multicore environment.
> >
> > @@ -176,6 +182,57 @@ It can often be replaced by other solutions like per-
> > lcore variables.
> >  Also, some locking techniques are more efficient than others.
> >  For instance, the Read-Copy-Update (RCU) algorithm can frequently
> replace
> > simple rwlocks.
> >
> > +Atomic Operations: Use C11 Atomic Built-ins
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +DPDK generic rte_atomic operations are implemented by __sync built-ins.
> > +These __sync built-ins result in full barriers on aarch64, which are
> > +unnecessary in many use cases. They can be replaced by __atomic
> > +built-ins that conform to the C11 memory model and provide finer
> memory
> > order control.
> > +
> > +So replacing the rte_atomic operations with __atomic built-ins might
> > +improve performance for aarch64 machines.
> > +
> > +Some typical optimization cases are listed below:
> > +
> > +Atomicity
> > +^^^^^^^^^
> > +
> > +Some use cases require atomicity alone, the ordering of the memory
> > +operations does not matter. For example, the packet statistics counters
> > +need to be incremented atomically but do not need any particular
> memory
> > ordering.
> > +So, RELAXED memory ordering is sufficient.
> > +
> > +One-way Barrier
> > +^^^^^^^^^^^^^^^
> > +
> > +Some use cases allow for memory reordering in one way while requiring
> > +memory ordering in the other direction.
> > +
> > +For example, the memory operations before the spinlock lock are allowed
> > +to move to the critical section, but the memory operations in the
> > +critical section are not allowed to move above the lock. In this case,
> > +the full memory barrier in the compare-and-swap operation can be
> replaced
> > with ACQUIRE memory order.
> > +On the other hand, the memory operations after the spinlock unlock are
> > +allowed to move to the critical section, but the memory operations in
> > +the critical section are not allowed to move below the unlock. So the
> > +full barrier in the store operation can use RELEASE memory order.
> > +
> > +Reader-Writer Concurrency
> > +^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Lock-free reader-writer concurrency is one of the common use cases in
> DPDK.
> > +
> > +The payload or the data that the writer wants to communicate to the
> > +reader, can be written with RELAXED memory order. However, the guard
> > +variable should be written with RELEASE memory order. This ensures that
> > +the store to guard variable is observable only after the store to payload is
> > observable.
> > +
> > +Correspondingly, on the reader side, the guard variable should be read
> > +with ACQUIRE memory order. The payload or the data the writer
> > +communicated, can be read with RELAXED memory order. This ensures
> that,
> > +if the store to guard variable is observable, the store to payload is also
> > observable.
> > +
> >  Coding Considerations
> >  ---------------------
> >
> > --
> > 2.7.4


^ permalink raw reply

* Re: [PATCH 03/20] thermal: rcar_gen3_thermal: Add r8a774e1 support
From: Daniel Lezcano @ 2020-07-17  4:44 UTC (permalink / raw)
  To: Lad Prabhakar, Geert Uytterhoeven, Wolfram Sang, Rob Herring,
	Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
	Jakub Kicinski, Mark Brown, Niklas, Zhang Rui, Wim Van Sebroeck,
	Guenter Roeck, Magnus Damm
  Cc: Amit Kucheria, Thomas Gleixner, Laurent Pinchart, linux-i2c,
	linux-kernel, devicetree, linux-can, netdev, linux-spi,
	linux-renesas-soc, linux-pm, linux-watchdog, Prabhakar
In-Reply-To: <1594811350-14066-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>

On 15/07/2020 13:08, Lad Prabhakar wrote:
> From: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> 
> Add r8a774e1 specific compatible string.
> 
> Signed-off-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> ---

Applied, thanks



-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

^ permalink raw reply

* Re: [PATCH -next] cpuidle/pseries: Make symbol 'pseries_idle_driver' static
From: Daniel Lezcano @ 2020-07-17  4:41 UTC (permalink / raw)
  To: Michael Ellerman, Hulk Robot, Wei Yongjun, Rafael J. Wysocki,
	Michael Ellerman
  Cc: linuxppc-dev, linux-pm
In-Reply-To: <159490401706.3805857.7133480973769495238.b4-ty@ellerman.id.au>

On 16/07/2020 14:56, Michael Ellerman wrote:
> On Tue, 14 Jul 2020 22:24:24 +0800, Wei Yongjun wrote:
>> The sparse tool complains as follows:
>>
>> drivers/cpuidle/cpuidle-pseries.c:25:23: warning:
>>  symbol 'pseries_idle_driver' was not declared. Should it be static?
>>
>> 'pseries_idle_driver' is not used outside of this file, so marks
>> it static.
> 
> Applied to powerpc/next.
> 
> [1/1] cpuidle/pseries: Make symbol 'pseries_idle_driver' static
>       https://git.kernel.org/powerpc/c/92fe8483b1660feaa602d8be6ca7efe95ae4789b

Rafael already picked the patch.


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.