* Re: [PATCH 00/36] [Set 4] Rid W=1 warnings in SCSI
From: Martin K. Petersen @ 2021-03-25 3:53 UTC (permalink / raw)
To: Lee Jones
Cc: Tyrel Datwyler, Hannes Reinecke, Anil Ravindranath, Brian Macy,
willy, Le Moal, David Chaw, Marvell, Jirka Hanika, Brian King,
Artur Paszkiewicz, target-devel, Drew Eckhardt, Linda Xie,
Ketan Mukadam, Paul Mackerras, linux-drivers, Dave Boutcher,
Brian King, linux-scsi, Subbu Seetharaman, Sathya Prakash,
Doug Ledford, Leonard N. Zubkoff, Christoph Hellwig,
Nicholas A. Bellinger, Colin DeVilbiss, Karan Tilak Kumar,
Badari Pulavarty, Alan Cox, Bryant G. Ly, Douglas Gilbert,
Jamie Lenehan, MPT-FusionLinux.pdl, Matthew R. Ochs,
MPT-FusionLinux.pdl, Eric Youngdale, Torben Mathiasen,
Michael Cyr, dc395x, Satish Kharat, Suganath Prabu Subramani,
James E.J. Bottomley, Luben Tuikov, Ali Akcaagac, Santiago Leon,
Jitendra Bhivare, Manoj N. Kumar, Hannes Reinecke, Erich Chen,
Dave Boutcher, Richard Gooch, Uma Krishnan, Sreekanth Reddy,
C.L. Huang, Martin K . Petersen, Oliver Neukum, linux-kernel,
Sesidhar Baddela, Bas Vermeulen, Alex Davis, Kurt Garloff,
Shaun Tancheff, FUJITA Tomonori, linuxppc-dev, Linux GmbH
In-Reply-To: <20210317091230.2912389-1-lee.jones@linaro.org>
On Wed, 17 Mar 2021 09:11:54 +0000, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> Lee Jones (36):
> scsi: myrb: Demote non-conformant kernel-doc headers and fix others
> scsi: ipr: Fix incorrect function names in their headers
> scsi: mvumi: Fix formatting and doc-rot issues
> scsi: sd_zbc: Place function name into header
> scsi: pmcraid: Fix a whole host of kernel-doc issues
> scsi: sd: Fix function name in header
> scsi: aic94xx: aic94xx_dump: Correct misspelling of function
> asd_dump_seq_state()
> scsi: be2iscsi: be_main: Ensure function follows directly after its
> header
> scsi: dc395x: Fix some function param descriptions
> scsi: initio: Fix a few kernel-doc misdemeanours
> scsi: a100u2w: Fix some misnaming and formatting issues
> scsi: myrs: Add missing ':' to make the kernel-doc checker happy
> scsi: pmcraid: Correct function name pmcraid_show_adapter_id() in
> header
> scsi: mpt3sas: mpt3sas_scs: Fix a few kernel-doc issues
> scsi: be2iscsi: be_main: Demote incomplete/non-conformant kernel-doc
> header
> scsi: isci: phy: Fix a few different kernel-doc related issues
> scsi: fnic: fnic_scsi: Demote non-conformant kernel-doc headers
> scsi: fnic: fnic_fcs: Kernel-doc headers must contain the function
> name
> scsi: isci: phy: Provide function name and demote non-conforming
> header
> scsi: isci: request: Fix a myriad of kernel-doc issues
> scsi: isci: host: Fix bunch of kernel-doc related issues
> scsi: isci: task: Demote non-conformant header and remove superfluous
> param
> scsi: isci: remote_node_table: Fix a bunch of kernel-doc misdemeanours
> scsi: isci: remote_node_context: Fix one function header and demote a
> couple more
> scsi: isci: port_config: Fix a bunch of doc-rot and demote abuses
> scsi: isci: remote_device: Fix a bunch of doc-rot issues
> scsi: isci: request: Fix doc-rot issue relating to 'ireq' param
> scsi: isci: port: Fix a bunch of kernel-doc issues
> scsi: isci: remote_node_context: Demote kernel-doc abuse
> scsi: isci: remote_node_table: Provide some missing params and remove
> others
> scsi: cxlflash: main: Fix a little do-rot
> scsi: cxlflash: superpipe: Fix a few misnaming issues
> scsi: ibmvscsi: Fix a bunch of kernel-doc related issues
> scsi: ibmvscsi: ibmvfc: Fix a bunch of misdocumentation
> scsi: ibmvscsi_tgt: ibmvscsi_tgt: Remove duplicate section 'NOTE'
> scsi: cxlflash: vlun: Fix some misnaming related doc-rot
>
> [...]
Applied to 5.13/scsi-queue, thanks!
[01/36] scsi: myrb: Demote non-conformant kernel-doc headers and fix others
https://git.kernel.org/mkp/scsi/c/12a1b740f225
[02/36] scsi: ipr: Fix incorrect function names in their headers
https://git.kernel.org/mkp/scsi/c/637b5c3ebc1c
[03/36] scsi: mvumi: Fix formatting and doc-rot issues
https://git.kernel.org/mkp/scsi/c/5ccd626516e1
[04/36] scsi: sd_zbc: Place function name into header
https://git.kernel.org/mkp/scsi/c/59863cb53d80
[05/36] scsi: pmcraid: Fix a whole host of kernel-doc issues
https://git.kernel.org/mkp/scsi/c/3673b7b0007b
[06/36] scsi: sd: Fix function name in header
https://git.kernel.org/mkp/scsi/c/ad907c54e36f
[07/36] scsi: aic94xx: aic94xx_dump: Correct misspelling of function asd_dump_seq_state()
https://git.kernel.org/mkp/scsi/c/3e2f4679ea03
[08/36] scsi: be2iscsi: be_main: Ensure function follows directly after its header
https://git.kernel.org/mkp/scsi/c/f1d50e8ee5c9
[09/36] scsi: dc395x: Fix some function param descriptions
https://git.kernel.org/mkp/scsi/c/33c8ef953ece
[10/36] scsi: initio: Fix a few kernel-doc misdemeanours
https://git.kernel.org/mkp/scsi/c/100ec495e01e
[11/36] scsi: a100u2w: Fix some misnaming and formatting issues
https://git.kernel.org/mkp/scsi/c/c548a6250627
[12/36] scsi: myrs: Add missing ':' to make the kernel-doc checker happy
https://git.kernel.org/mkp/scsi/c/9eb292eb2ef7
[13/36] scsi: pmcraid: Correct function name pmcraid_show_adapter_id() in header
https://git.kernel.org/mkp/scsi/c/a364a147b1dc
[14/36] scsi: mpt3sas: mpt3sas_scs: Fix a few kernel-doc issues
https://git.kernel.org/mkp/scsi/c/a8d548b0b3ee
[15/36] scsi: be2iscsi: be_main: Demote incomplete/non-conformant kernel-doc header
https://git.kernel.org/mkp/scsi/c/a90a8c607570
[16/36] scsi: isci: phy: Fix a few different kernel-doc related issues
https://git.kernel.org/mkp/scsi/c/6af1d9bd9051
[17/36] scsi: fnic: fnic_scsi: Demote non-conformant kernel-doc headers
https://git.kernel.org/mkp/scsi/c/c7eab0704c30
[18/36] scsi: fnic: fnic_fcs: Kernel-doc headers must contain the function name
https://git.kernel.org/mkp/scsi/c/2efd8631d6a5
[19/36] scsi: isci: phy: Provide function name and demote non-conforming header
https://git.kernel.org/mkp/scsi/c/6ab7ca5139b7
[20/36] scsi: isci: request: Fix a myriad of kernel-doc issues
https://git.kernel.org/mkp/scsi/c/db35a0835357
[21/36] scsi: isci: host: Fix bunch of kernel-doc related issues
https://git.kernel.org/mkp/scsi/c/44b7ca966128
[22/36] scsi: isci: task: Demote non-conformant header and remove superfluous param
https://git.kernel.org/mkp/scsi/c/0afdee03f2e7
[23/36] scsi: isci: remote_node_table: Fix a bunch of kernel-doc misdemeanours
https://git.kernel.org/mkp/scsi/c/103d61927ed3
[24/36] scsi: isci: remote_node_context: Fix one function header and demote a couple more
https://git.kernel.org/mkp/scsi/c/ad276048f1bc
[25/36] scsi: isci: port_config: Fix a bunch of doc-rot and demote abuses
https://git.kernel.org/mkp/scsi/c/29faa5ce26ae
[26/36] scsi: isci: remote_device: Fix a bunch of doc-rot issues
https://git.kernel.org/mkp/scsi/c/242e15d7a4f4
[27/36] scsi: isci: request: Fix doc-rot issue relating to 'ireq' param
https://git.kernel.org/mkp/scsi/c/a8604e44514d
[28/36] scsi: isci: port: Fix a bunch of kernel-doc issues
https://git.kernel.org/mkp/scsi/c/7292a8b039c5
[29/36] scsi: isci: remote_node_context: Demote kernel-doc abuse
https://git.kernel.org/mkp/scsi/c/d2d480f132e8
[30/36] scsi: isci: remote_node_table: Provide some missing params and remove others
https://git.kernel.org/mkp/scsi/c/188f513dd22c
[31/36] scsi: cxlflash: main: Fix a little do-rot
https://git.kernel.org/mkp/scsi/c/cf0ad7a15ac5
[32/36] scsi: cxlflash: superpipe: Fix a few misnaming issues
https://git.kernel.org/mkp/scsi/c/32b3edfd28f8
[33/36] scsi: ibmvscsi: Fix a bunch of kernel-doc related issues
https://git.kernel.org/mkp/scsi/c/841d7df0d416
[34/36] scsi: ibmvscsi: ibmvfc: Fix a bunch of misdocumentation
https://git.kernel.org/mkp/scsi/c/dd9c77297148
[35/36] scsi: ibmvscsi_tgt: ibmvscsi_tgt: Remove duplicate section 'NOTE'
https://git.kernel.org/mkp/scsi/c/cba3ebfc008e
[36/36] scsi: cxlflash: vlun: Fix some misnaming related doc-rot
https://git.kernel.org/mkp/scsi/c/a690baa47fd1
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* RE: [PATCH 15/17] iommu: remove DOMAIN_ATTR_NESTING
From: Tian, Kevin @ 2021-03-25 6:12 UTC (permalink / raw)
To: Auger Eric, Christoph Hellwig
Cc: freedreno@lists.freedesktop.org, Liu, Yi L, kvm@vger.kernel.org,
Will Deacon, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, Li Yang,
iommu@lists.linux-foundation.org, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <3a1194de-a053-84dd-3d6a-bff8e01ebcd3@redhat.com>
> From: Auger Eric
> Sent: Monday, March 15, 2021 3:52 PM
> To: Christoph Hellwig <hch@lst.de>
> Cc: kvm@vger.kernel.org; Will Deacon <will@kernel.org>; linuxppc-
> dev@lists.ozlabs.org; dri-devel@lists.freedesktop.org; Li Yang
> <leoyang.li@nxp.com>; iommu@lists.linux-foundation.org;
>
> Hi Christoph,
>
> On 3/14/21 4:58 PM, Christoph Hellwig wrote:
> > On Sun, Mar 14, 2021 at 11:44:52AM +0100, Auger Eric wrote:
> >> As mentionned by Robin, there are series planning to use
> >> DOMAIN_ATTR_NESTING to get info about the nested caps of the iommu
> (ARM
> >> and Intel):
> >>
> >> [Patch v8 00/10] vfio: expose virtual Shared Virtual Addressing to VMs
> >> patches 1, 2, 3
> >>
> >> Is the plan to introduce a new domain_get_nesting_info ops then?
> >
> > The plan as usual would be to add it the series adding that support.
> > Not sure what the merge plans are - if the series is ready to be
> > merged I could rebase on top of it, otherwise that series will need
> > to add the method.
> OK I think your series may be upstreamed first.
>
Agree. The vSVA series is still undergoing a refactor according to Jason's
comment thus won't be ready in short term. It's better to let this one
go in first.
Thanks
Kevin
^ permalink raw reply
* Re: [PATCH 15/17] iommu: remove DOMAIN_ATTR_NESTING
From: Christoph Hellwig @ 2021-03-25 6:51 UTC (permalink / raw)
To: Tian, Kevin
Cc: freedreno@lists.freedesktop.org, Liu, Yi L, kvm@vger.kernel.org,
Will Deacon, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, Li Yang, Auger Eric,
iommu@lists.linux-foundation.org, David Woodhouse,
netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, Christoph Hellwig,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <MWHPR11MB188688125518D050E384658F8C629@MWHPR11MB1886.namprd11.prod.outlook.com>
On Thu, Mar 25, 2021 at 06:12:37AM +0000, Tian, Kevin wrote:
> Agree. The vSVA series is still undergoing a refactor according to Jason's
> comment thus won't be ready in short term. It's better to let this one
> go in first.
Would be great to get a few more reviews while we're at it :)
^ permalink raw reply
* Re: [PATCH V3 -next] powerpc: kernel/time.c - cleanup warnings
From: Alexandre Belloni @ 2021-03-25 8:45 UTC (permalink / raw)
To: heying (H)
Cc: linux-rtc, a.zummo, geert+renesas, peterz, frederic, linux-kernel,
npiggin, kernelfans, paulus, geert, tglx, msuchanek, linuxppc-dev
In-Reply-To: <18a8d444-f1a5-61e0-b9f2-f85c03d71686@huawei.com>
On 24/03/2021 17:46:19+0800, heying (H) wrote:
> Many thanks for your suggestion. As you suggest, rtc_lock should be local to
> platforms.
>
> Does it mean not only powerpc but also all other platforms should adapt this
> change?
Not all the other ones, in the current state, x86 still needs it. I'll
work on that. Again, the patch is fine as is.
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] pseries: prevent free CPU ids to be reused on another node
From: Laurent Dufour @ 2021-03-25 9:35 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: nathanl, cheloha, linuxppc-dev, linux-kernel
When a CPU is hot added, the CPU ids are taken from the available mask from
the lower possible set. If that set of values was previously used for CPU
attached to a different node, this seems to application like if these CPUs
have migrated from a node to another one which is not expected in real
life.
To prevent this, it is needed to record the CPU ids used for each node and
to not reuse them on another node. However, to prevent CPU hot plug to
fail, in the case the CPU ids is starved on a node, the capability to reuse
other nodes’ free CPU ids is kept. A warning is displayed in such a case
to warn the user.
A new CPU bit mask (node_recorded_ids_map) is introduced for each possible
node. It is populated with the CPU onlined at boot time, and then when a
CPU is hot plug to a node. The bits in that mask remain when the CPU is hot
unplugged, to remind this CPU ids have been used for this node.
If no id set was found, a retry is made without removing the ids used on
the other nodes to try reusing them. This is the way ids have been
allocated prior to this patch.
The effect of this patch can be seen by removing and adding CPUs using the
Qemu monitor. In the following case, the first CPU from the node 2 is
removed, then the first one from the node 1 is removed too. Later, the
first CPU of the node 2 is added back. Without that patch, the kernel will
numbered these CPUs using the first CPU ids available which are the ones
freed when removing the second CPU of the node 0. This leads to the CPU ids
16-23 to move from the node 1 to the node 2. With the patch applied, the
CPU ids 32-39 are used since they are the lowest free ones which have not
been used on another node.
At boot time:
[root@vm40 ~]# numactl -H | grep cpus
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Vanilla kernel, after the CPU hot unplug/plug operations:
[root@vm40 ~]# numactl -H | grep cpus
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 1 cpus: 24 25 26 27 28 29 30 31
node 2 cpus: 16 17 18 19 20 21 22 23 40 41 42 43 44 45 46 47
Patched kernel, after the CPU hot unplug/plug operations:
[root@vm40 ~]# numactl -H | grep cpus
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 1 cpus: 24 25 26 27 28 29 30 31
node 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
Changes since V1 (no functional changes):
- update the test's output in the commit's description
- node_recorded_ids_map should be static
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
arch/powerpc/platforms/pseries/hotplug-cpu.c | 83 ++++++++++++++++++--
1 file changed, 76 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 12cbffd3c2e3..48c7943b25b0 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -39,6 +39,8 @@
/* This version can't take the spinlock, because it never returns */
static int rtas_stop_self_token = RTAS_UNKNOWN_SERVICE;
+static cpumask_var_t node_recorded_ids_map[MAX_NUMNODES];
+
static void rtas_stop_self(void)
{
static struct rtas_args args;
@@ -151,29 +153,61 @@ static void pseries_cpu_die(unsigned int cpu)
*/
static int pseries_add_processor(struct device_node *np)
{
- unsigned int cpu;
+ unsigned int cpu, node;
cpumask_var_t candidate_mask, tmp;
- int err = -ENOSPC, len, nthreads, i;
+ int err = -ENOSPC, len, nthreads, i, nid;
const __be32 *intserv;
+ bool force_reusing = false;
intserv = of_get_property(np, "ibm,ppc-interrupt-server#s", &len);
if (!intserv)
return 0;
- zalloc_cpumask_var(&candidate_mask, GFP_KERNEL);
- zalloc_cpumask_var(&tmp, GFP_KERNEL);
+ alloc_cpumask_var(&candidate_mask, GFP_KERNEL);
+ alloc_cpumask_var(&tmp, GFP_KERNEL);
+
+ /*
+ * Fetch from the DT nodes read by dlpar_configure_connector() the NUMA
+ * node id the added CPU belongs to.
+ */
+ nid = of_node_to_nid(np);
+ if (nid < 0 || !node_possible(nid))
+ nid = first_online_node;
nthreads = len / sizeof(u32);
- for (i = 0; i < nthreads; i++)
- cpumask_set_cpu(i, tmp);
cpu_maps_update_begin();
BUG_ON(!cpumask_subset(cpu_present_mask, cpu_possible_mask));
+again:
+ cpumask_clear(candidate_mask);
+ cpumask_clear(tmp);
+ for (i = 0; i < nthreads; i++)
+ cpumask_set_cpu(i, tmp);
+
/* Get a bitmap of unoccupied slots. */
cpumask_xor(candidate_mask, cpu_possible_mask, cpu_present_mask);
+
+ /*
+ * Remove free ids previously assigned on the other nodes. We can walk
+ * only online nodes because once a node became online it is not turned
+ * offlined back.
+ */
+ if (!force_reusing)
+ for_each_online_node(node) {
+ if (node == nid) /* Keep our node's recorded ids */
+ continue;
+ cpumask_andnot(candidate_mask, candidate_mask,
+ node_recorded_ids_map[node]);
+ }
+
if (cpumask_empty(candidate_mask)) {
+ if (!force_reusing) {
+ force_reusing = true;
+ goto again;
+ }
+
/* If we get here, it most likely means that NR_CPUS is
* less than the partition's max processors setting.
*/
@@ -191,12 +225,36 @@ static int pseries_add_processor(struct device_node *np)
cpumask_shift_left(tmp, tmp, nthreads);
if (cpumask_empty(tmp)) {
+ if (!force_reusing) {
+ force_reusing = true;
+ goto again;
+ }
printk(KERN_ERR "Unable to find space in cpu_present_mask for"
" processor %pOFn with %d thread(s)\n", np,
nthreads);
goto out_unlock;
}
+ /* Record the newly used CPU ids for the associate node. */
+ cpumask_or(node_recorded_ids_map[nid], node_recorded_ids_map[nid], tmp);
+
+ /*
+ * If we force reusing the id, remove these ids from any node which was
+ * previously using it.
+ */
+ if (force_reusing) {
+ cpu = cpumask_first(tmp);
+ pr_warn("Reusing free CPU ids %d-%d from another node\n",
+ cpu, cpu + nthreads - 1);
+
+ for_each_online_node(node) {
+ if (node == nid)
+ continue;
+ cpumask_andnot(node_recorded_ids_map[node],
+ node_recorded_ids_map[node], tmp);
+ }
+ }
+
for_each_cpu(cpu, tmp) {
BUG_ON(cpu_present(cpu));
set_cpu_present(cpu, true);
@@ -889,6 +947,7 @@ static struct notifier_block pseries_smp_nb = {
static int __init pseries_cpu_hotplug_init(void)
{
int qcss_tok;
+ unsigned int node;
#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE
ppc_md.cpu_probe = dlpar_cpu_probe;
@@ -910,8 +969,18 @@ static int __init pseries_cpu_hotplug_init(void)
smp_ops->cpu_die = pseries_cpu_die;
/* Processors can be added/removed only on LPAR */
- if (firmware_has_feature(FW_FEATURE_LPAR))
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ for_each_node(node) {
+ alloc_bootmem_cpumask_var(&node_recorded_ids_map[node]);
+
+ /* Record ids of CPU added at boot time */
+ cpumask_or(node_recorded_ids_map[node],
+ node_recorded_ids_map[node],
+ node_to_cpumask_map[node]);
+ }
+
of_reconfig_notifier_register(&pseries_smp_nb);
+ }
return 0;
}
--
2.31.0
^ permalink raw reply related
* Re: [PATCH v2 6/7] cmdline: Gives architectures opportunity to use generically defined boot cmdline manipulation
From: Christophe Leroy @ 2021-03-25 11:18 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, robh, daniel, devicetree, linux-kernel,
Paul Mackerras, linuxppc-dev, danielwa
In-Reply-To: <20210303175747.GD19713@willie-the-truck>
Le 03/03/2021 à 18:57, Will Deacon a écrit :
> On Tue, Mar 02, 2021 at 05:25:22PM +0000, Christophe Leroy wrote:
>> Most architectures have similar boot command line manipulation
>> options. This patchs adds the definition in init/Kconfig, gated by
>> CONFIG_HAVE_CMDLINE that the architectures can select to use them.
>>
>> In order to use this, a few architectures will have to change their
>> CONFIG options:
>> - riscv has to replace CMDLINE_FALLBACK by CMDLINE_FROM_BOOTLOADER
>> - architectures using CONFIG_CMDLINE_OVERRIDE or
>> CONFIG_CMDLINE_OVERWRITE have to replace them by CONFIG_CMDLINE_FORCE.
>>
>> Architectures also have to define CONFIG_DEFAULT_CMDLINE.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> init/Kconfig | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 56 insertions(+)
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index 22946fe5ded9..a0f2ad9467df 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -117,6 +117,62 @@ config INIT_ENV_ARG_LIMIT
>> Maximum of each of the number of arguments and environment
>> variables passed to init from the kernel command line.
>>
>> +config HAVE_CMDLINE
>> + bool
>> +
>> +config CMDLINE_BOOL
>> + bool "Default bootloader kernel arguments"
>> + depends on HAVE_CMDLINE
>> + help
>> + On some platforms, there is currently no way for the boot loader to
>> + pass arguments to the kernel. For these platforms, you can supply
>> + some command-line options at build time by entering them here. In
>> + most cases you will need to specify the root device here.
>
> Why is this needed as well as CMDLINE_FROM_BOOTLOADER? IIUC, the latter
> will use CONFIG_CMDLINE if it fails to get anything from the bootloader,
> which sounds like the same scenario.
>
>> +config CMDLINE
>> + string "Initial kernel command string"
>
> s/Initial/Default
>
> which is then consistent with the rest of the text here.
>
>> + depends on CMDLINE_BOOL
>
> Ah, so this is a bit different and I don't think lines-up with the
> CMDLINE_BOOL help text.
>
>> + default DEFAULT_CMDLINE
>> + help
>> + On some platforms, there is currently no way for the boot loader to
>> + pass arguments to the kernel. For these platforms, you can supply
>> + some command-line options at build time by entering them here. In
>> + most cases you will need to specify the root device here.
>
> (same stale text)
>
>> +choice
>> + prompt "Kernel command line type" if CMDLINE != ""
>> + default CMDLINE_FROM_BOOTLOADER
>> + help
>> + Selects the way you want to use the default kernel arguments.
>
> How about:
>
> "Determines how the default kernel arguments are combined with any
> arguments passed by the bootloader"
>
>> +config CMDLINE_FROM_BOOTLOADER
>> + bool "Use bootloader kernel arguments if available"
>> + help
>> + Uses the command-line options passed by the boot loader. If
>> + the boot loader doesn't provide any, the default kernel command
>> + string provided in CMDLINE will be used.
>> +
>> +config CMDLINE_EXTEND
>
> Can we rename this to CMDLINE_APPEND, please? There is code in the tree
> which disagrees about what CMDLINE_EXTEND means, so that will need be
> to be updated to be consistent (e.g. the EFI stub parsing order). Having
> the generic option with a different name means we won't accidentally end
> up with the same inconsistent behaviours.
Argh, yes. Seems like the problem is even larger than that IIUC:
- For ARM it means to append the bootloader arguments to the CONFIG_CMDLINE
- For Powerpc it means to append the CONFIG_CMDLINE to the bootloader arguments
- For SH it means to append the CONFIG_CMDLINE to the bootloader arguments
- For EFI it means to append the bootloader arguments to the CONFIG_CMDLINE
- For OF it means to append the CONFIG_CMDLINE to the bootloader arguments
So what happens on ARM for instance when it selects CONFIG_OF for instance ?
Or should we consider that EXTEND means APPEND or PREPEND, no matter which ?
Because EXTEND is for instance used for:
config INITRAMFS_FORCE
bool "Ignore the initramfs passed by the bootloader"
depends on CMDLINE_EXTEND || CMDLINE_FORCE
Christophe
^ permalink raw reply
* [PATCH AUTOSEL 5.11 22/44] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:24 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112459.1926846-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 21/39] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:25 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112558.1927423-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 15/24] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:26 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112651.1927828-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 11/20] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:27 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112724.1928174-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 09/16] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:27 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112751.1928421-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 7897d16e0990..727d4b321937 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -7,7 +7,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -46,7 +46,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 06/13] powerpc: Force inlining of cpu_has_feature() to avoid build failure
From: Sasha Levin @ 2021-03-25 11:28 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev
In-Reply-To: <20210325112814.1928637-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@csgroup.eu>
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based
on possible and always true values as defined per
CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance
book3e_all_defconfig on kisskb in the AMDGPU driver which uses
cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling
kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with
that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure"), for inlining of
cpu_has_feature().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.1615378209.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h
index 6e834caa3720..7b10b3ef7739 100644
--- a/arch/powerpc/include/asm/cpu_has_feature.h
+++ b/arch/powerpc/include/asm/cpu_has_feature.h
@@ -6,7 +6,7 @@
#include <linux/bug.h>
#include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature)
+static __always_inline bool early_cpu_has_feature(unsigned long feature)
{
return !!((CPU_FTRS_ALWAYS & feature) ||
(CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature));
@@ -45,7 +45,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature)
return static_branch_likely(&cpu_feature_keys[i]);
}
#else
-static inline bool cpu_has_feature(unsigned long feature)
+static __always_inline bool cpu_has_feature(unsigned long feature)
{
return early_cpu_has_feature(feature);
}
--
2.30.1
^ permalink raw reply related
* [PATCH v3 2/2] powerpc/perf: Add platform specific check_attr_config
From: Madhavan Srinivasan @ 2021-03-25 11:53 UTC (permalink / raw)
To: mpe; +Cc: Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <20210325115326.143151-1-maddy@linux.ibm.com>
Add platform specific attr.config value checks. Patch
includes checks for both power9 and power10.
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
---
Changelog v2:
- Changed function name as suggested.
- Added name of source document referred for reserved values
Changelog v1:
- No changes
arch/powerpc/perf/isa207-common.c | 42 +++++++++++++++++++++++++++++++
arch/powerpc/perf/isa207-common.h | 2 ++
arch/powerpc/perf/power10-pmu.c | 13 ++++++++++
arch/powerpc/perf/power9-pmu.c | 13 ++++++++++
4 files changed, 70 insertions(+)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index e4f577da33d8..358a0e95ba5f 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -694,3 +694,45 @@ int isa207_get_alternatives(u64 event, u64 alt[], int size, unsigned int flags,
return num_alt;
}
+
+int isa3XX_check_attr_config(struct perf_event *ev)
+{
+ u64 val, sample_mode;
+ u64 event = ev->attr.config;
+
+ val = (event >> EVENT_SAMPLE_SHIFT) & EVENT_SAMPLE_MASK;
+ sample_mode = val & 0x3;
+
+ /*
+ * MMCRA[61:62] is Random Sampling Mode (SM).
+ * value of 0b11 is reserved.
+ */
+ if (sample_mode == 0x3)
+ return -EINVAL;
+
+ /*
+ * Check for all reserved value
+ * Source: Performance Monitoring Unit User Guide
+ */
+ switch (val) {
+ case 0x5:
+ case 0x9:
+ case 0xD:
+ case 0x19:
+ case 0x1D:
+ case 0x1A:
+ case 0x1E:
+ return -EINVAL;
+ }
+
+ /*
+ * MMCRA[48:51]/[52:55]) Threshold Start/Stop
+ * Events Selection.
+ * 0b11110000/0b00001111 is reserved.
+ */
+ val = (event >> EVENT_THR_CTL_SHIFT) & EVENT_THR_CTL_MASK;
+ if (((val & 0xF0) == 0xF0) || ((val & 0xF) == 0xF))
+ return -EINVAL;
+
+ return 0;
+}
diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
index 1af0e8c97ac7..b4d2a2b2b346 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -280,4 +280,6 @@ void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
struct pt_regs *regs);
void isa207_get_mem_weight(u64 *weight);
+int isa3XX_check_attr_config(struct perf_event *ev);
+
#endif
diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
index a901c1348cad..f9d64c63bb4a 100644
--- a/arch/powerpc/perf/power10-pmu.c
+++ b/arch/powerpc/perf/power10-pmu.c
@@ -106,6 +106,18 @@ static int power10_get_alternatives(u64 event, unsigned int flags, u64 alt[])
return num_alt;
}
+static int power10_check_attr_config(struct perf_event *ev)
+{
+ u64 val;
+ u64 event = ev->attr.config;
+
+ val = (event >> EVENT_SAMPLE_SHIFT) & EVENT_SAMPLE_MASK;
+ if (val == 0x10 || isa3XX_check_attr_config(ev))
+ return -EINVAL;
+
+ return 0;
+}
+
GENERIC_EVENT_ATTR(cpu-cycles, PM_RUN_CYC);
GENERIC_EVENT_ATTR(instructions, PM_RUN_INST_CMPL);
GENERIC_EVENT_ATTR(branch-instructions, PM_BR_CMPL);
@@ -559,6 +571,7 @@ static struct power_pmu power10_pmu = {
.attr_groups = power10_pmu_attr_groups,
.bhrb_nr = 32,
.capabilities = PERF_PMU_CAP_EXTENDED_REGS,
+ .check_attr_config = power10_check_attr_config,
};
int init_power10_pmu(void)
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 2a57e93a79dc..ff3382140d7e 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -151,6 +151,18 @@ static int power9_get_alternatives(u64 event, unsigned int flags, u64 alt[])
return num_alt;
}
+static int power9_check_attr_config(struct perf_event *ev)
+{
+ u64 val;
+ u64 event = ev->attr.config;
+
+ val = (event >> EVENT_SAMPLE_SHIFT) & EVENT_SAMPLE_MASK;
+ if (val == 0xC || isa3XX_check_attr_config(ev))
+ return -EINVAL;
+
+ return 0;
+}
+
GENERIC_EVENT_ATTR(cpu-cycles, PM_CYC);
GENERIC_EVENT_ATTR(stalled-cycles-frontend, PM_ICT_NOSLOT_CYC);
GENERIC_EVENT_ATTR(stalled-cycles-backend, PM_CMPLU_STALL);
@@ -437,6 +449,7 @@ static struct power_pmu power9_pmu = {
.attr_groups = power9_pmu_attr_groups,
.bhrb_nr = 32,
.capabilities = PERF_PMU_CAP_EXTENDED_REGS,
+ .check_attr_config = power9_check_attr_config,
};
int init_power9_pmu(void)
--
2.26.2
^ permalink raw reply related
* [PATCH v3 1/2] powerpc/perf: Infrastructure to support checking of attr.config*
From: Madhavan Srinivasan @ 2021-03-25 11:53 UTC (permalink / raw)
To: mpe; +Cc: Madhavan Srinivasan, linuxppc-dev
Introduce code to support the checking of attr.config* for
values which are reserved for a given platform.
Performance Monitoring Unit (PMU) configuration registers
have fields that are reserved and some specific values for
bit fields are reserved. For ex., MMCRA[61:62] is
Random Sampling Mode (SM) and value of 0b11 for this field
is reserved.
Writing non-zero or invalid values in these fields will
have unknown behaviours.
Patch adds a generic call-back function "check_attr_config"
in "struct power_pmu", to be called in event_init to
check for attr.config* values for a given platform.
"check_attr_config" is valid only for raw event type.
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
---
Changelog v2:
-Fixed commit message
Changelog v1:
-Fixed commit message and in-code comments
arch/powerpc/include/asm/perf_event_server.h | 6 ++++++
arch/powerpc/perf/core-book3s.c | 14 ++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 00e7e671bb4b..dde97d7d9253 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -67,6 +67,12 @@ struct power_pmu {
* the pmu supports extended perf regs capability
*/
int capabilities;
+ /*
+ * Function to check event code for values which are
+ * reserved. Function takes struct perf_event as input,
+ * since event code could be spread in attr.config*
+ */
+ int (*check_attr_config)(struct perf_event *ev);
};
/*
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 6817331e22ff..c6eeb4fdc5fd 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1958,6 +1958,20 @@ static int power_pmu_event_init(struct perf_event *event)
if (ppmu->blacklist_ev && is_event_blacklisted(ev))
return -EINVAL;
+ /*
+ * PMU config registers have fields that are
+ * reserved and specific value to bit field as reserved.
+ * For ex., MMCRA[61:62] is Randome Sampling Mode (SM)
+ * and value of 0b11 to this field is reserved.
+ *
+ * This check is needed only for raw event type,
+ * since tools like fuzzer use raw event type to
+ * provide randomized event code values for test.
+ *
+ */
+ if (ppmu->check_attr_config &&
+ ppmu->check_attr_config(event))
+ return -EINVAL;
break;
default:
return -ENOENT;
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
From: Christophe Leroy @ 2021-03-25 12:03 UTC (permalink / raw)
To: Rob Herring
Cc: Daniel Gimpelevich, linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, xe-linux-external,
Andrew Morton, Will Deacon, Daniel Walker
In-Reply-To: <CAL_JsqKm76jRQYDcu3rGyUWKPLspoO=EZW_WFy=zAK+m_JYCTg@mail.gmail.com>
Le 24/03/2021 à 18:32, Rob Herring a écrit :
> On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 09/03/2021 à 22:29, Daniel Walker a écrit :
>>> On Tue, Mar 09, 2021 at 08:47:09AM +0100, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 09/03/2021 à 01:02, Daniel Walker a écrit :
>>>>> This is a scripted mass convert of the config files to use
>>>>> the new generic cmdline. There is a bit of a trim effect here.
>>>>> It would seems that some of the config haven't been trimmed in
>>>>> a while.
>>>>
>>>> If you do that in a separate patch, you loose bisectability.
>>>>
>>>> I think it would have been better to do things in a different way, more or less like I did in my series:
>>>> 1/ Provide GENERIC cmdline at the same functionnality level as what is
>>>> spread in the different architectures
>>>> 2/ Convert architectures to the generic with least churn.
>>>> 3/ Add new features to the generic
>>>
>>> You have to have the churn eventually, no matter how you do it. The only way you
>>> don't have churn is if you never upgrade the feature set.
>>>
>>>
>>>>>
>>>>> The bash script used to convert is as follows,
>>>>>
>>>>> if [[ -z "$1" || -z "$2" ]]; then
>>>>> echo "Two arguments are needed."
>>>>> exit 1
>>>>> fi
>>>>> mkdir $1
>>>>> cp $2 $1/.config
>>>>> sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config
>>>>
>>>> This is not correct.
>>>>
>>>> By default, on powerpc the provided command line is used only if the bootloader doesn't provide one.
>>>>
>>>> Otherwise:
>>>> - the builtin command line is appended to the one provided by the bootloader
>>>> if CONFIG_CMDLINE_EXTEND is selected
>>>> - the builtin command line replaces to the one provided by the bootloader if
>>>> CONFIG_CMDLINE_FORCE is selected
>>>
>>> I think my changes maintain most of this due to the override of
>>> CONFIG_CMDLINE_PREPEND. This is an upgrade and the inflexibility in powerpc is
>>> an example of why these changes were created in the first place.
>>
>> "inflexibility in powerpc" : Can you elaborate ?
>>
>>>
>>> For example , say the default command line is "root=/dev/issblk0" from iss476
>>> platform. And the bootloader adds "root=/dev/sda1"
>>>
>>> The result is <prepend><bootloader><append>.
>>
>>
>> I'm still having hard time understanding the benefit of having both <prepend> and <append>.
>> Could you please provide a complete exemple from real life, ie what exactly the problem is and what
>> it solves ?
>
> It doesn't matter. We already have both cases and 'extend' has meant either one.
>
> What someone wants is policy and the kernel shouldn't be defining the policy.
>
Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
Let's only provide once CMDLINE as of today, and ask the user to select whether he wants it appended
or prepended or replacee. Then no need to change all existing config to rename CONFIG_CMDLINE into
either of the new ones.
That's the main difference between my series and Daniel's series. So I'll finish taking Will's
comment into account and we'll send out a v3 soon.
Thanks
Christophe
^ permalink raw reply
* Re: [PATCH v7] powerpc/irq: Inline call_do_irq() and call_do_softirq()
From: Segher Boessenkool @ 2021-03-25 12:44 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <87k0pwhh5y.fsf@mpe.ellerman.id.au>
On Wed, Mar 24, 2021 at 11:26:01PM +1100, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> > Hmm. It is the first time we use named parameters in powerpc assembly, isn't it ?
> Yeah I'd like us to use it more, I think it helps readability a lot.
..in some cases. Not in most cases :-(
> > Wondering, how would the below look like with named parameters (from __put_user_asm2_goto) ?
> >
> > stw%X1 %L0, %L1
>
> Not sure, possibly that's too complicated for it :)
asm("stw%X[name1] %L[name0],%L[name1]" :: [name0]"r"(x), [name1]"m"(p));
Yes, it is not more readable *at all*.
Segher
^ permalink raw reply
* Re: [PATCH V2 1/5] powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
From: Arnaldo Carvalho de Melo @ 2021-03-25 13:01 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: ravi.bangoria, Athira Rajeev, peterz, linux-kernel,
linux-perf-users, jolsa, kjain, linuxppc-dev, kan.liang
In-Reply-To: <d7dd633b-e28a-155a-a8e2-0e5a83b4eead@linux.ibm.com>
Em Wed, Mar 24, 2021 at 10:05:23AM +0530, Madhavan Srinivasan escreveu:
>
> On 3/22/21 8:27 PM, Athira Rajeev wrote:
> > Performance Monitoring Unit (PMU) registers in powerpc provides
> > information on cycles elapsed between different stages in the
> > pipeline. This can be used for application tuning. On ISA v3.1
> > platform, this information is exposed by sampling registers.
> > Patch adds kernel support to capture two of the cycle counters
> > as part of perf sample using the sample type:
> > PERF_SAMPLE_WEIGHT_STRUCT.
> >
> > The power PMU function 'get_mem_weight' currently uses 64 bit weight
> > field of perf_sample_data to capture memory latency. But following the
> > introduction of PERF_SAMPLE_WEIGHT_TYPE, weight field could contain
> > 64-bit or 32-bit value depending on the architexture support for
> > PERF_SAMPLE_WEIGHT_STRUCT. Patches uses WEIGHT_STRUCT to expose the
> > pipeline stage cycles info. Hence update the ppmu functions to work for
> > 64-bit and 32-bit weight values.
> >
> > If the sample type is PERF_SAMPLE_WEIGHT, use the 64-bit weight field.
> > if the sample type is PERF_SAMPLE_WEIGHT_STRUCT, memory subsystem
> > latency is stored in the low 32bits of perf_sample_weight structure.
> > Also for CPU_FTR_ARCH_31, capture the two cycle counter information in
> > two 16 bit fields of perf_sample_weight structure.
>
> Changes looks fine to me.
>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
So who will process the kernel bits? I'm merging the tooling parts,
Thanks,
- Arnaldo
>
> > Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/include/asm/perf_event_server.h | 2 +-
> > arch/powerpc/perf/core-book3s.c | 4 ++--
> > arch/powerpc/perf/isa207-common.c | 29 +++++++++++++++++++++++++---
> > arch/powerpc/perf/isa207-common.h | 6 +++++-
> > 4 files changed, 34 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
> > index 00e7e671bb4b..112cf092d7b3 100644
> > --- a/arch/powerpc/include/asm/perf_event_server.h
> > +++ b/arch/powerpc/include/asm/perf_event_server.h
> > @@ -43,7 +43,7 @@ struct power_pmu {
> > u64 alt[]);
> > void (*get_mem_data_src)(union perf_mem_data_src *dsrc,
> > u32 flags, struct pt_regs *regs);
> > - void (*get_mem_weight)(u64 *weight);
> > + void (*get_mem_weight)(u64 *weight, u64 type);
> > unsigned long group_constraint_mask;
> > unsigned long group_constraint_val;
> > u64 (*bhrb_filter_map)(u64 branch_sample_type);
> > diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> > index 766f064f00fb..6936763246bd 100644
> > --- a/arch/powerpc/perf/core-book3s.c
> > +++ b/arch/powerpc/perf/core-book3s.c
> > @@ -2206,9 +2206,9 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
> > ppmu->get_mem_data_src)
> > ppmu->get_mem_data_src(&data.data_src, ppmu->flags, regs);
> > - if (event->attr.sample_type & PERF_SAMPLE_WEIGHT &&
> > + if (event->attr.sample_type & PERF_SAMPLE_WEIGHT_TYPE &&
> > ppmu->get_mem_weight)
> > - ppmu->get_mem_weight(&data.weight.full);
> > + ppmu->get_mem_weight(&data.weight.full, event->attr.sample_type);
> > if (perf_event_overflow(event, &data, regs))
> > power_pmu_stop(event, 0);
> > diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
> > index e4f577da33d8..5dcbdbd54598 100644
> > --- a/arch/powerpc/perf/isa207-common.c
> > +++ b/arch/powerpc/perf/isa207-common.c
> > @@ -284,8 +284,10 @@ void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> > }
> > }
> > -void isa207_get_mem_weight(u64 *weight)
> > +void isa207_get_mem_weight(u64 *weight, u64 type)
> > {
> > + union perf_sample_weight *weight_fields;
> > + u64 weight_lat;
> > u64 mmcra = mfspr(SPRN_MMCRA);
> > u64 exp = MMCRA_THR_CTR_EXP(mmcra);
> > u64 mantissa = MMCRA_THR_CTR_MANT(mmcra);
> > @@ -296,9 +298,30 @@ void isa207_get_mem_weight(u64 *weight)
> > mantissa = P10_MMCRA_THR_CTR_MANT(mmcra);
> > if (val == 0 || val == 7)
> > - *weight = 0;
> > + weight_lat = 0;
> > else
> > - *weight = mantissa << (2 * exp);
> > + weight_lat = mantissa << (2 * exp);
> > +
> > + /*
> > + * Use 64 bit weight field (full) if sample type is
> > + * WEIGHT.
> > + *
> > + * if sample type is WEIGHT_STRUCT:
> > + * - store memory latency in the lower 32 bits.
> > + * - For ISA v3.1, use remaining two 16 bit fields of
> > + * perf_sample_weight to store cycle counter values
> > + * from sier2.
> > + */
> > + weight_fields = (union perf_sample_weight *)weight;
> > + if (type & PERF_SAMPLE_WEIGHT)
> > + weight_fields->full = weight_lat;
> > + else {
> > + weight_fields->var1_dw = (u32)weight_lat;
> > + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> > + weight_fields->var2_w = P10_SIER2_FINISH_CYC(mfspr(SPRN_SIER2));
> > + weight_fields->var3_w = P10_SIER2_DISPATCH_CYC(mfspr(SPRN_SIER2));
> > + }
> > + }
> > }
> > int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp, u64 event_config1)
> > diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
> > index 1af0e8c97ac7..fc30d43c4d0c 100644
> > --- a/arch/powerpc/perf/isa207-common.h
> > +++ b/arch/powerpc/perf/isa207-common.h
> > @@ -265,6 +265,10 @@
> > #define ISA207_SIER_DATA_SRC_SHIFT 53
> > #define ISA207_SIER_DATA_SRC_MASK (0x7ull << ISA207_SIER_DATA_SRC_SHIFT)
> > +/* Bits in SIER2/SIER3 for Power10 */
> > +#define P10_SIER2_FINISH_CYC(sier2) (((sier2) >> (63 - 37)) & 0x7fful)
> > +#define P10_SIER2_DISPATCH_CYC(sier2) (((sier2) >> (63 - 13)) & 0x7fful)
> > +
> > #define P(a, b) PERF_MEM_S(a, b)
> > #define PH(a, b) (P(LVL, HIT) | P(a, b))
> > #define PM(a, b) (P(LVL, MISS) | P(a, b))
> > @@ -278,6 +282,6 @@ int isa207_get_alternatives(u64 event, u64 alt[], int size, unsigned int flags,
> > const unsigned int ev_alt[][MAX_ALT]);
> > void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> > struct pt_regs *regs);
> > -void isa207_get_mem_weight(u64 *weight);
> > +void isa207_get_mem_weight(u64 *weight, u64 type);
> > #endif
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH V2 1/5] powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
From: Arnaldo Carvalho de Melo @ 2021-03-25 13:06 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: ravi.bangoria, Athira Rajeev, peterz, linux-kernel,
linux-perf-users, jolsa, kjain, linuxppc-dev, kan.liang
In-Reply-To: <d7dd633b-e28a-155a-a8e2-0e5a83b4eead@linux.ibm.com>
Em Wed, Mar 24, 2021 at 10:05:23AM +0530, Madhavan Srinivasan escreveu:
>
> On 3/22/21 8:27 PM, Athira Rajeev wrote:
> > Performance Monitoring Unit (PMU) registers in powerpc provides
> > information on cycles elapsed between different stages in the
> > pipeline. This can be used for application tuning. On ISA v3.1
> > platform, this information is exposed by sampling registers.
> > Patch adds kernel support to capture two of the cycle counters
> > as part of perf sample using the sample type:
> > PERF_SAMPLE_WEIGHT_STRUCT.
> >
> > The power PMU function 'get_mem_weight' currently uses 64 bit weight
> > field of perf_sample_data to capture memory latency. But following the
> > introduction of PERF_SAMPLE_WEIGHT_TYPE, weight field could contain
> > 64-bit or 32-bit value depending on the architexture support for
> > PERF_SAMPLE_WEIGHT_STRUCT. Patches uses WEIGHT_STRUCT to expose the
> > pipeline stage cycles info. Hence update the ppmu functions to work for
> > 64-bit and 32-bit weight values.
> >
> > If the sample type is PERF_SAMPLE_WEIGHT, use the 64-bit weight field.
> > if the sample type is PERF_SAMPLE_WEIGHT_STRUCT, memory subsystem
> > latency is stored in the low 32bits of perf_sample_weight structure.
> > Also for CPU_FTR_ARCH_31, capture the two cycle counter information in
> > two 16 bit fields of perf_sample_weight structure.
>
> Changes looks fine to me.
You mean just the kernel part or can I add your Reviewed-by to all the
patchset?
> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
>
>
> > Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/include/asm/perf_event_server.h | 2 +-
> > arch/powerpc/perf/core-book3s.c | 4 ++--
> > arch/powerpc/perf/isa207-common.c | 29 +++++++++++++++++++++++++---
> > arch/powerpc/perf/isa207-common.h | 6 +++++-
> > 4 files changed, 34 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
> > index 00e7e671bb4b..112cf092d7b3 100644
> > --- a/arch/powerpc/include/asm/perf_event_server.h
> > +++ b/arch/powerpc/include/asm/perf_event_server.h
> > @@ -43,7 +43,7 @@ struct power_pmu {
> > u64 alt[]);
> > void (*get_mem_data_src)(union perf_mem_data_src *dsrc,
> > u32 flags, struct pt_regs *regs);
> > - void (*get_mem_weight)(u64 *weight);
> > + void (*get_mem_weight)(u64 *weight, u64 type);
> > unsigned long group_constraint_mask;
> > unsigned long group_constraint_val;
> > u64 (*bhrb_filter_map)(u64 branch_sample_type);
> > diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> > index 766f064f00fb..6936763246bd 100644
> > --- a/arch/powerpc/perf/core-book3s.c
> > +++ b/arch/powerpc/perf/core-book3s.c
> > @@ -2206,9 +2206,9 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
> > ppmu->get_mem_data_src)
> > ppmu->get_mem_data_src(&data.data_src, ppmu->flags, regs);
> > - if (event->attr.sample_type & PERF_SAMPLE_WEIGHT &&
> > + if (event->attr.sample_type & PERF_SAMPLE_WEIGHT_TYPE &&
> > ppmu->get_mem_weight)
> > - ppmu->get_mem_weight(&data.weight.full);
> > + ppmu->get_mem_weight(&data.weight.full, event->attr.sample_type);
> > if (perf_event_overflow(event, &data, regs))
> > power_pmu_stop(event, 0);
> > diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
> > index e4f577da33d8..5dcbdbd54598 100644
> > --- a/arch/powerpc/perf/isa207-common.c
> > +++ b/arch/powerpc/perf/isa207-common.c
> > @@ -284,8 +284,10 @@ void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> > }
> > }
> > -void isa207_get_mem_weight(u64 *weight)
> > +void isa207_get_mem_weight(u64 *weight, u64 type)
> > {
> > + union perf_sample_weight *weight_fields;
> > + u64 weight_lat;
> > u64 mmcra = mfspr(SPRN_MMCRA);
> > u64 exp = MMCRA_THR_CTR_EXP(mmcra);
> > u64 mantissa = MMCRA_THR_CTR_MANT(mmcra);
> > @@ -296,9 +298,30 @@ void isa207_get_mem_weight(u64 *weight)
> > mantissa = P10_MMCRA_THR_CTR_MANT(mmcra);
> > if (val == 0 || val == 7)
> > - *weight = 0;
> > + weight_lat = 0;
> > else
> > - *weight = mantissa << (2 * exp);
> > + weight_lat = mantissa << (2 * exp);
> > +
> > + /*
> > + * Use 64 bit weight field (full) if sample type is
> > + * WEIGHT.
> > + *
> > + * if sample type is WEIGHT_STRUCT:
> > + * - store memory latency in the lower 32 bits.
> > + * - For ISA v3.1, use remaining two 16 bit fields of
> > + * perf_sample_weight to store cycle counter values
> > + * from sier2.
> > + */
> > + weight_fields = (union perf_sample_weight *)weight;
> > + if (type & PERF_SAMPLE_WEIGHT)
> > + weight_fields->full = weight_lat;
> > + else {
> > + weight_fields->var1_dw = (u32)weight_lat;
> > + if (cpu_has_feature(CPU_FTR_ARCH_31)) {
> > + weight_fields->var2_w = P10_SIER2_FINISH_CYC(mfspr(SPRN_SIER2));
> > + weight_fields->var3_w = P10_SIER2_DISPATCH_CYC(mfspr(SPRN_SIER2));
> > + }
> > + }
> > }
> > int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp, u64 event_config1)
> > diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
> > index 1af0e8c97ac7..fc30d43c4d0c 100644
> > --- a/arch/powerpc/perf/isa207-common.h
> > +++ b/arch/powerpc/perf/isa207-common.h
> > @@ -265,6 +265,10 @@
> > #define ISA207_SIER_DATA_SRC_SHIFT 53
> > #define ISA207_SIER_DATA_SRC_MASK (0x7ull << ISA207_SIER_DATA_SRC_SHIFT)
> > +/* Bits in SIER2/SIER3 for Power10 */
> > +#define P10_SIER2_FINISH_CYC(sier2) (((sier2) >> (63 - 37)) & 0x7fful)
> > +#define P10_SIER2_DISPATCH_CYC(sier2) (((sier2) >> (63 - 13)) & 0x7fful)
> > +
> > #define P(a, b) PERF_MEM_S(a, b)
> > #define PH(a, b) (P(LVL, HIT) | P(a, b))
> > #define PM(a, b) (P(LVL, MISS) | P(a, b))
> > @@ -278,6 +282,6 @@ int isa207_get_alternatives(u64 event, u64 alt[], int size, unsigned int flags,
> > const unsigned int ev_alt[][MAX_ALT]);
> > void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
> > struct pt_regs *regs);
> > -void isa207_get_mem_weight(u64 *weight);
> > +void isa207_get_mem_weight(u64 *weight, u64 type);
> > #endif
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
From: Rob Herring @ 2021-03-25 13:45 UTC (permalink / raw)
To: Christophe Leroy
Cc: Daniel Gimpelevich, linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, xe-linux-external,
Andrew Morton, Will Deacon, Daniel Walker
In-Reply-To: <20fd7d44-8c39-48bc-25c3-990be9d9d911@csgroup.eu>
On Thu, Mar 25, 2021 at 6:06 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 24/03/2021 à 18:32, Rob Herring a écrit :
> > On Wed, Mar 24, 2021 at 11:01 AM Christophe Leroy
> > <christophe.leroy@csgroup.eu> wrote:
> >>
> >>
> >>
> >> Le 09/03/2021 à 22:29, Daniel Walker a écrit :
> >>> On Tue, Mar 09, 2021 at 08:47:09AM +0100, Christophe Leroy wrote:
> >>>>
> >>>>
> >>>> Le 09/03/2021 à 01:02, Daniel Walker a écrit :
> >>>>> This is a scripted mass convert of the config files to use
> >>>>> the new generic cmdline. There is a bit of a trim effect here.
> >>>>> It would seems that some of the config haven't been trimmed in
> >>>>> a while.
> >>>>
> >>>> If you do that in a separate patch, you loose bisectability.
> >>>>
> >>>> I think it would have been better to do things in a different way, more or less like I did in my series:
> >>>> 1/ Provide GENERIC cmdline at the same functionnality level as what is
> >>>> spread in the different architectures
> >>>> 2/ Convert architectures to the generic with least churn.
> >>>> 3/ Add new features to the generic
> >>>
> >>> You have to have the churn eventually, no matter how you do it. The only way you
> >>> don't have churn is if you never upgrade the feature set.
> >>>
> >>>
> >>>>>
> >>>>> The bash script used to convert is as follows,
> >>>>>
> >>>>> if [[ -z "$1" || -z "$2" ]]; then
> >>>>> echo "Two arguments are needed."
> >>>>> exit 1
> >>>>> fi
> >>>>> mkdir $1
> >>>>> cp $2 $1/.config
> >>>>> sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' $1/.config
> >>>>
> >>>> This is not correct.
> >>>>
> >>>> By default, on powerpc the provided command line is used only if the bootloader doesn't provide one.
> >>>>
> >>>> Otherwise:
> >>>> - the builtin command line is appended to the one provided by the bootloader
> >>>> if CONFIG_CMDLINE_EXTEND is selected
> >>>> - the builtin command line replaces to the one provided by the bootloader if
> >>>> CONFIG_CMDLINE_FORCE is selected
> >>>
> >>> I think my changes maintain most of this due to the override of
> >>> CONFIG_CMDLINE_PREPEND. This is an upgrade and the inflexibility in powerpc is
> >>> an example of why these changes were created in the first place.
> >>
> >> "inflexibility in powerpc" : Can you elaborate ?
> >>
> >>>
> >>> For example , say the default command line is "root=/dev/issblk0" from iss476
> >>> platform. And the bootloader adds "root=/dev/sda1"
> >>>
> >>> The result is <prepend><bootloader><append>.
> >>
> >>
> >> I'm still having hard time understanding the benefit of having both <prepend> and <append>.
> >> Could you please provide a complete exemple from real life, ie what exactly the problem is and what
> >> it solves ?
> >
> > It doesn't matter. We already have both cases and 'extend' has meant either one.
> >
> > What someone wants is policy and the kernel shouldn't be defining the policy.
> >
>
> Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
Well, I wasn't thinking about that part of it, but yes as long as no
arch currently needs that.
> Let's only provide once CMDLINE as of today, and ask the user to select whether he wants it appended
> or prepended or replacee. Then no need to change all existing config to rename CONFIG_CMDLINE into
> either of the new ones.
>
> That's the main difference between my series and Daniel's series. So I'll finish taking Will's
> comment into account and we'll send out a v3 soon.
Great.
Rob
^ permalink raw reply
* Re: [PATCH V2 1/5] powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
From: Peter Zijlstra @ 2021-03-25 14:38 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: ravi.bangoria, Athira Rajeev, linux-kernel, linux-perf-users,
Madhavan Srinivasan, jolsa, kjain, linuxppc-dev, kan.liang
In-Reply-To: <YFyJr+R24TlrMNrC@kernel.org>
On Thu, Mar 25, 2021 at 10:01:35AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 24, 2021 at 10:05:23AM +0530, Madhavan Srinivasan escreveu:
> >
> > On 3/22/21 8:27 PM, Athira Rajeev wrote:
> > > Performance Monitoring Unit (PMU) registers in powerpc provides
> > > information on cycles elapsed between different stages in the
> > > pipeline. This can be used for application tuning. On ISA v3.1
> > > platform, this information is exposed by sampling registers.
> > > Patch adds kernel support to capture two of the cycle counters
> > > as part of perf sample using the sample type:
> > > PERF_SAMPLE_WEIGHT_STRUCT.
> > >
> > > The power PMU function 'get_mem_weight' currently uses 64 bit weight
> > > field of perf_sample_data to capture memory latency. But following the
> > > introduction of PERF_SAMPLE_WEIGHT_TYPE, weight field could contain
> > > 64-bit or 32-bit value depending on the architexture support for
> > > PERF_SAMPLE_WEIGHT_STRUCT. Patches uses WEIGHT_STRUCT to expose the
> > > pipeline stage cycles info. Hence update the ppmu functions to work for
> > > 64-bit and 32-bit weight values.
> > >
> > > If the sample type is PERF_SAMPLE_WEIGHT, use the 64-bit weight field.
> > > if the sample type is PERF_SAMPLE_WEIGHT_STRUCT, memory subsystem
> > > latency is stored in the low 32bits of perf_sample_weight structure.
> > > Also for CPU_FTR_ARCH_31, capture the two cycle counter information in
> > > two 16 bit fields of perf_sample_weight structure.
> >
> > Changes looks fine to me.
> >
> > Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
>
> So who will process the kernel bits? I'm merging the tooling parts,
I was sorta expecting these to go through the powerpc tree. Let me know
if you want them in tip/perf/core instead.
^ permalink raw reply
* Re: [PATCH V2 1/5] powerpc/perf: Expose processor pipeline stage cycles using PERF_SAMPLE_WEIGHT_STRUCT
From: Arnaldo @ 2021-03-25 16:42 UTC (permalink / raw)
To: Peter Zijlstra, Arnaldo Carvalho de Melo
Cc: ravi.bangoria, Athira Rajeev, linux-kernel, linux-perf-users,
Madhavan Srinivasan, jolsa, kjain, linuxppc-dev, kan.liang
In-Reply-To: <YFygSdFOT5B0DwRU@hirez.programming.kicks-ass.net>
On March 25, 2021 11:38:01 AM GMT-03:00, Peter Zijlstra <peterz@infradead.org> wrote:
>On Thu, Mar 25, 2021 at 10:01:35AM -0300, Arnaldo Carvalho de Melo
>wrote:.
>> > > Also for CPU_FTR_ARCH_31, capture the two cycle counter
>information in
>> > > two 16 bit fields of perf_sample_weight structure.
>> >
>> > Changes looks fine to me.
>> >
>> > Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
>>
>> So who will process the kernel bits? I'm merging the tooling parts,
>
>I was sorta expecting these to go through the powerpc tree. Let me know
>if you want them in tip/perf/core instead.
Shouldn't matter by which tree it gets upstream, as long as it gets picked :-)
- Arnaldo
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: VDSO ELF header
From: Christophe Leroy @ 2021-03-25 16:46 UTC (permalink / raw)
To: Laurent Dufour, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <c45ae4f8-1cbc-c687-b6a2-9a431fafc85c@linux.ibm.com>
Hi Laurent
Le 25/03/2021 à 17:11, Laurent Dufour a écrit :
> Hi Christophe,
>
> Since v5.11 and the changes you made to the VDSO code, it no more exposing the ELF header at the
> beginning of the VDSO mapping in user space.
>
> This is confusing CRIU which is checking for this ELF header cookie
> (https://github.com/checkpoint-restore/criu/issues/1417).
How does it do on other architectures ?
>
> I'm not an expert in loading and ELF part and reading the change you made, I can't identify how this
> could work now as I'm expecting the loader to need that ELF header to do the relocation.
I think the loader is able to find it at the expected place.
>
> From my investigation it seems that the first bytes of the VDSO area are now the vdso_arch_data.
>
> Is the ELF header put somewhere else?
> How could the loader process the VDSO without that ELF header?
>
Like most other architectures, we now have the data section as first page and the text section
follows. So you will likely find the elf header on the second page.
Done in this commit: https://github.com/linuxppc/linux/commit/511157ab641eb6bedd00d62673388e78a4f871cf
Christophe
^ permalink raw reply
* Re: VDSO ELF header
From: Laurent Dufour @ 2021-03-25 16:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <9366c258-127f-f105-abd1-6baa9a6745c5@csgroup.eu>
Le 25/03/2021 à 17:46, Christophe Leroy a écrit :
> Hi Laurent
>
> Le 25/03/2021 à 17:11, Laurent Dufour a écrit :
>> Hi Christophe,
>>
>> Since v5.11 and the changes you made to the VDSO code, it no more exposing the
>> ELF header at the beginning of the VDSO mapping in user space.
>>
>> This is confusing CRIU which is checking for this ELF header cookie
>> (https://github.com/checkpoint-restore/criu/issues/1417).
>
> How does it do on other architectures ?
Good question, I'll double check the CRIU code.
>
>>
>> I'm not an expert in loading and ELF part and reading the change you made, I
>> can't identify how this could work now as I'm expecting the loader to need
>> that ELF header to do the relocation.
>
> I think the loader is able to find it at the expected place.
Actually, it seems the loader relies on the AUX vector AT_SYSINFO_EHDR. I guess
CRIU should do the same.
>>
>> From my investigation it seems that the first bytes of the VDSO area are now
>> the vdso_arch_data.
>>
>> Is the ELF header put somewhere else?
>> How could the loader process the VDSO without that ELF header?
>>
>
> Like most other architectures, we now have the data section as first page and
> the text section follows. So you will likely find the elf header on the second
> page.
>
> Done in this commit:
> https://github.com/linuxppc/linux/commit/511157ab641eb6bedd00d62673388e78a4f871cf
I'll double check on x86, but anyway, I think CRIU should rely on
AT_SYSINFO_EHDR and not assume that the ELF header is at the beginning of VDSO
mapping.
Thanks for your help.
Laurent.
^ permalink raw reply
* Re: [PATCH 1/2] ASoC: fsl-asoc-card: Add support for WM8958 codec
From: Mark Brown @ 2021-03-25 17:37 UTC (permalink / raw)
To: tiwai, perex, festevam, Xiubo.Lee, devicetree, linuxppc-dev,
nicoleotsuka, linux-kernel, timur, alsa-devel, Shengjiu Wang,
lgirdwood, robh+dt
Cc: Mark Brown
In-Reply-To: <1615986303-27959-1-git-send-email-shengjiu.wang@nxp.com>
On Wed, 17 Mar 2021 21:05:02 +0800, Shengjiu Wang wrote:
> WM8958 codec is used on some i.MX based platform.
> So add it support in this generic driver.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: fsl-asoc-card: Add support for WM8958 codec
commit: efd0b1660829a987354cea6a446179c7ac7cd0e6
[2/2] ASoC: bindings: fsl-asoc-card: add compatible string for WM8958 codec
commit: df8077c6fe64fe98c1b1c1f9ecf84afc773e726f
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v5 0/6] Add audio driver base on rpmsg on i.MX platform
From: Mark Brown @ 2021-03-25 17:37 UTC (permalink / raw)
To: tiwai, perex, festevam, Xiubo.Lee, devicetree, nicoleotsuka,
linuxppc-dev, linux-kernel, timur, alsa-devel, Shengjiu Wang,
lgirdwood, robh+dt
Cc: Mark Brown
In-Reply-To: <1615516725-4975-1-git-send-email-shengjiu.wang@nxp.com>
On Fri, 12 Mar 2021 10:38:39 +0800, Shengjiu Wang wrote:
> On Asymmetric multiprocessor, there is Cortex-A core and Cortex-M core,
> Linux is running on A core, RTOS is running on M core.
> The audio hardware device can be controlled by Cortex-M device,
> So audio playback/capture can be handled by M core.
>
> Rpmsg is the interface for sending and receiving msg to and from M
> core, that we can create a virtual sound on Cortex-A core side.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/6] ASoC: soc-component: Add snd_soc_pcm_component_ack
commit: 8bdfc0455e3a59e2c1207a56be22e910fae0e0d5
[2/6] ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg
commit: b73d9e6225e86492f6a901223a34ecfa7b55c178
[3/6] ASoC: dt-bindings: fsl_rpmsg: Add binding doc for rpmsg audio device
commit: 49c6bf62498344fa8f8af2314231f3eb37e0e150
[4/6] ASoC: imx-audio-rpmsg: Add rpmsg_driver for audio channel
commit: 1935050de0b6c6c961e9de51d5b5d05642f861f1
[5/6] ASoC: imx-pcm-rpmsg: Add platform driver for audio base on rpmsg
commit: 3c00eceb2a5391ed1ca6703b71cad35ab8cd4352
[6/6] ASoC: imx-rpmsg: Add machine driver for audio base on rpmsg
commit: 39f8405c3e502e7b9d0533fa0b0bfe715b3e89c1
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox