* [RFC PATCH 2/4] powerpc/papr_scm: Add support for PAPR_SCM_PDSM_FETCH_PERF_STATS
From: Vaibhav Jain @ 2020-05-18 11:08 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Oliver O'Halloran, Aneesh Kumar K . V,
Vaibhav Jain, Dan Williams
In-Reply-To: <20200518110814.145644-1-vaibhav@linux.ibm.com>
Add support for pdsm PAPR_SCM_PDSM_FETCH_PERF_STATS that issues HCALL
H_SCM_PERFORMANCE_STATS to PHYP to fetch all the NVDIMM performance
stats and store them in per nvdimm 'struct papr_scm_priv' as member
'perf_stats'. A further PDSM request (introduced later) is needed to
read the contents of this performance stats buffer.
A new uapi struct 'nd_psdm_perf_stats_size' is introduced to be used
by libndctl to retrieve the size of buffer needed to store all NVDIMM
performance stats.
The patch updates papr_scm_service_pdsm() to route
PAPR_SCM_PDSM_FETCH_PERF_STATS to newly introduced
papr_scm_fetch_perf_stats() which then issues the HCALL and copies the
needed size to the PDSM payload.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
arch/powerpc/include/uapi/asm/papr_scm_pdsm.h | 13 ++++
arch/powerpc/platforms/pseries/papr_scm.c | 70 +++++++++++++++++++
2 files changed, 83 insertions(+)
diff --git a/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
index db0cf550dabe..40ec55d06f4c 100644
--- a/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
+++ b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
@@ -114,6 +114,7 @@ struct nd_pdsm_cmd_pkg {
enum papr_scm_pdsm {
PAPR_SCM_PDSM_MIN = 0x0,
PAPR_SCM_PDSM_HEALTH,
+ PAPR_SCM_PDSM_FETCH_PERF_STATS,
PAPR_SCM_PDSM_MAX,
};
@@ -170,4 +171,16 @@ struct nd_papr_pdsm_health_v1 {
/* Current version number for the dimm health struct */
#define ND_PAPR_PDSM_HEALTH_VERSION 1
+/*
+ * Return the maximum buffer size needed to hold all performance state.
+ * max_stats_size: The buffer size needed to hold all stat entries
+ */
+struct nd_pdsm_fetch_perf_stats_v1 {
+ __u32 max_stats_size;
+ __u8 reserved[4];
+} __packed;
+
+#define nd_pdsm_fetch_perf_stats nd_pdsm_fetch_perf_stats_v1
+#define ND_PDSM_FETCH_PERF_STATS_VERSION 1
+
#endif /* _UAPI_ASM_POWERPC_PAPR_SCM_PDSM_H_ */
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index fd9a12275315..f8b37a830aed 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -525,6 +525,73 @@ static int is_cmd_valid(struct nvdimm *nvdimm, unsigned int cmd, void *buf,
return 0;
}
+/* Return the size in bytes for returning all perf stats to libndctl */
+static int papr_scm_fetch_perf_stats(struct papr_scm_priv *p,
+ struct nd_pdsm_cmd_pkg *pkg)
+{
+ int rc = 0;
+ size_t copysize = sizeof(struct nd_pdsm_fetch_perf_stats);
+ struct nd_pdsm_fetch_perf_stats *sz =
+ (struct nd_pdsm_fetch_perf_stats *)pdsm_cmd_to_payload(pkg);
+
+ /*
+ * If the requested payload version is greater than one we know
+ * about, return the payload version we know about and let
+ * caller/userspace handle.
+ */
+ if (pkg->payload_version > ND_PDSM_FETCH_PERF_STATS_VERSION)
+ pkg->payload_version = ND_PDSM_FETCH_PERF_STATS_VERSION;
+
+ if (pkg->hdr.nd_size_out < copysize) {
+ dev_dbg(&p->pdev->dev, "Truncated payload (%u). Expected (%lu)",
+ pkg->hdr.nd_size_out, copysize);
+ rc = -ENOSPC;
+ goto out;
+ }
+
+ rc = mutex_lock_interruptible(&p->health_mutex);
+ if (rc)
+ goto out;
+
+ if (!p->len_stat_buffer) {
+ rc = -ENOENT;
+ goto out_unlock;
+ }
+
+ /* Setup the buffer and request phyp for all dimm perf stats data */
+ rc = drc_pmem_query_stats(p, p->perf_stats, p->len_stat_buffer, 0,
+ NULL);
+ if (rc)
+ goto out_unlock;
+
+ dev_dbg(&p->pdev->dev, "Copying payload size=%lu version=0x%x\n",
+ copysize, pkg->payload_version);
+
+ /*
+ * Put the buffer size needed in the payload buffer subtracting the
+ * perf_stat header size.
+ */
+ if (p->len_stat_buffer > sizeof(struct papr_scm_perf_stats))
+ sz->max_stats_size = p->len_stat_buffer -
+ sizeof(struct papr_scm_perf_stats);
+ else
+ sz->max_stats_size = 0;
+
+ pkg->hdr.nd_fw_size = copysize;
+
+out_unlock:
+ mutex_unlock(&p->health_mutex);
+out:
+ /*
+ * Put the error in out package and return success from function
+ * so that errors if any are propogated back to userspace.
+ */
+ pkg->cmd_status = rc;
+ dev_dbg(&p->pdev->dev, "completion code = %d\n", rc);
+
+ return 0;
+}
+
/* Fetch the DIMM health info and populate it in provided package. */
static int papr_scm_get_health(struct papr_scm_priv *p,
struct nd_pdsm_cmd_pkg *pkg)
@@ -594,6 +661,9 @@ static int papr_scm_service_pdsm(struct papr_scm_priv *p,
case PAPR_SCM_PDSM_HEALTH:
return papr_scm_get_health(p, call_pkg);
+ case PAPR_SCM_PDSM_FETCH_PERF_STATS:
+ return papr_scm_fetch_perf_stats(p, call_pkg);
+
default:
dev_dbg(&p->pdev->dev, "Unsupported PDSM request 0x%llx\n",
call_pkg->hdr.nd_command);
--
2.26.2
^ permalink raw reply related
* [RFC PATCH 0/4] powerpc/papr_scm: Add support for reporting NVDIMM performance statistics
From: Vaibhav Jain @ 2020-05-18 11:08 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Oliver O'Halloran, Aneesh Kumar K . V,
Vaibhav Jain, Dan Williams
The patch-set proposes to add support for fetching and reporting
performance statistics for PAPR compliant NVDIMMs as described in
documentation for H_SCM_PERFORMANCE_STATS hcall Ref[1]. The patch-set
also implements mechanisms to expose NVDIMM performance stats via
sysfs and newly introduced PDSMs[2] for libndctl.
This patch-set combined with corresponding ndctl and libndctl changes
proposed at Ref[3] should enable user to fetch PAPR compliant NVDIMMs
using following command:
# ndctl list -D --stats
[
{
"dev":"nmem0",
"stats":{
"Controller Reset Count":2,
"Controller Reset Elapsed Time":603331,
"Power-on Seconds":603931,
"Life Remaining":"100%",
"Critical Resource Utilization":"0%",
"Host Load Count":5781028,
"Host Store Count":8966800,
"Host Load Duration":975895365,
"Host Store Duration":716230690,
"Media Read Count":0,
"Media Write Count":6313,
"Media Read Duration":0,
"Media Write Duration":9679615,
"Cache Read Hit Count":5781028,
"Cache Write Hit Count":8442479,
"Fast Write Count":8969912
}
}
]
The patchset is dependent on existing patch-set "[PATCH v7 0/5]
powerpc/papr_scm: Add support for reporting nvdimm health" available
at Ref[2] that adds support for reporting PAPR compliant NVDIMMs in
'papr_scm' kernel module.
Structure of the patch-set
==========================
The patch-set starts with implementing functionality in papr_scm
module to issue H_SCM_PERFORMANCE_STATS hcall, fetch & parse dimm
performance stats and exposing them as a PAPR specific libnvdimm
attribute named 'perf_stats'
Patch-2 introduces a new PDSM named FETCH_PERF_STATS that can be
issued by libndctl asking papr_scm to issue the
H_SCM_PERFORMANCE_STATS hcall using helpers introduced earlier and
storing the results in a dimm specific perf-stats-buffer.
Patch-3 introduces a new PDSM named READ_PERF_STATS that can be
issued by libndctl to read the perf-stats-buffer in an incremental
manner to workaround the 256-bytes envelop limitation of libnvdimm.
Finally Patch-4 introduces a new PDSM named GET_PERF_STAT that can be
issued by libndctl to read values of a specific NVDIMM performance
stat like "Life Remaining".
References
==========
[1] Documentation/powerpc/papr_hcals.rst
[2] https://lore.kernel.org/linux-nvdimm/20200508104922.72565-1-vaibhav@linux.ibm.com/
[3] https://github.com/vaibhav92/ndctl/tree/papr_scm_stats_v1
Vaibhav Jain (4):
powerpc/papr_scm: Fetch nvdimm performance stats from PHYP
powerpc/papr_scm: Add support for PAPR_SCM_PDSM_FETCH_PERF_STATS
powerpc/papr_scm: Implement support for PAPR_SCM_PDSM_READ_PERF_STATS
powerpc/papr_scm: Add support for PDSM GET_PERF_STAT
Documentation/ABI/testing/sysfs-bus-papr-scm | 27 ++
arch/powerpc/include/uapi/asm/papr_scm_pdsm.h | 60 +++
arch/powerpc/platforms/pseries/papr_scm.c | 391 ++++++++++++++++++
3 files changed, 478 insertions(+)
--
2.26.2
^ permalink raw reply
* [RFC PATCH 1/4] powerpc/papr_scm: Fetch nvdimm performance stats from PHYP
From: Vaibhav Jain @ 2020-05-18 11:08 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Oliver O'Halloran, Aneesh Kumar K . V,
Vaibhav Jain, Dan Williams
In-Reply-To: <20200518110814.145644-1-vaibhav@linux.ibm.com>
Update papr_scm.c to query dimm performance statistics from PHYP via
H_SCM_PERFORMANCE_STATS hcall and export them to userspace as PAPR
specific NVDIMM attribute 'perf_stats' in sysfs. The patch also
provide a sysfs ABI documentation for the stats being reported and
their meanings.
During NVDIMM probe time in papr_scm_nvdimm_init() a special variant
of H_SCM_PERFORMANCE_STATS hcall is issued to check if collection of
performance statistics is supported or not. If yes then a per-nvdimm
performance stats buffer is of size as returned by PHYP is allocated
and stored along with its length in two newly introduced NVDIMM
private struct members 'perf_stats' and 'len_stat_buffer'.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
Documentation/ABI/testing/sysfs-bus-papr-scm | 27 ++++
arch/powerpc/platforms/pseries/papr_scm.c | 156 +++++++++++++++++++
2 files changed, 183 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-papr-scm b/Documentation/ABI/testing/sysfs-bus-papr-scm
index 6143d06072f1..ad06b3e9c315 100644
--- a/Documentation/ABI/testing/sysfs-bus-papr-scm
+++ b/Documentation/ABI/testing/sysfs-bus-papr-scm
@@ -25,3 +25,30 @@ Description:
NVDIMM have been scrubbed.
* "locked" : Indicating that NVDIMM contents cant
be modified until next power cycle.
+
+What: /sys/bus/nd/devices/nmemX/papr/perf_stats
+Date: May, 2020
+KernelVersion: v5.8
+Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org,
+Description:
+ (RO) Report various performance stats related to papr-scm NVDIMM
+ device. Each stat is reported on a new line with each line
+ composed of a stat-identifier followed by it value. Below are
+ currently known dimm performance stats which are reported:
+
+ * "CtlResCt" : Controller Reset Count
+ * "CtlResTm" : Controller Reset Elapsed Time
+ * "PonSecs " : Power-on Seconds
+ * "MemLife " : Life Remaining
+ * "CritRscU" : Critical Resource Utilization
+ * "HostLCnt" : Host Load Count
+ * "HostSCnt" : Host Store Count
+ * "HostSDur" : Host Store Duration
+ * "HostLDur" : Host Load Duration
+ * "MedRCnt " : Media Read Count
+ * "MedWCnt " : Media Write Count
+ * "MedRDur " : Media Read Duration
+ * "MedWDur " : Media Write Duration
+ * "CchRHCnt" : Cache Read Hit Count
+ * "CchWHCnt" : Cache Write Hit Count
+ * "FastWCnt" : Fast Write Count
\ No newline at end of file
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index c59bf17ad054..fd9a12275315 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -62,6 +62,24 @@
PAPR_SCM_DIMM_HEALTH_FATAL | \
PAPR_SCM_DIMM_HEALTH_UNHEALTHY)
+#define PAPR_SCM_PERF_STATS_EYECATCHER __stringify(SCMSTATS)
+#define PAPR_SCM_PERF_STATS_VERSION 0x1
+
+/* Struct holding a single performance metric */
+struct papr_scm_perf_stat {
+ u8 statistic_id[8];
+ u64 statistic_value;
+};
+
+/* Struct exchanged between kernel and PHYP for fetching drc perf stats */
+struct papr_scm_perf_stats {
+ u8 eye_catcher[8];
+ u32 stats_version; /* Should be 0x01 */
+ u32 num_statistics; /* Number of stats following */
+ /* zero or more performance matrics */
+ struct papr_scm_perf_stat scm_statistics[];
+} __packed;
+
/* private struct associated with each region */
struct papr_scm_priv {
struct platform_device *pdev;
@@ -89,6 +107,12 @@ struct papr_scm_priv {
/* Health information for the dimm */
struct nd_papr_pdsm_health health;
+
+ /* length of the stat buffer as expected by phyp */
+ size_t len_stat_buffer;
+
+ /* Cached version of all performance state */
+ struct papr_scm_perf_stats *perf_stats;
};
static int drc_pmem_bind(struct papr_scm_priv *p)
@@ -194,6 +218,75 @@ static int drc_pmem_query_n_bind(struct papr_scm_priv *p)
return drc_pmem_bind(p);
}
+/*
+ * Query the Dimm performance stats from PHYP and copy them (if returned) to
+ * provided struct papr_scm_perf_stats instance 'stats' of 'size' in bytes.
+ * The value of R4 is copied to 'out' if the pointer is provided.
+ */
+static int drc_pmem_query_stats(struct papr_scm_priv *p,
+ struct papr_scm_perf_stats *buff_stats,
+ size_t size, unsigned int num_stats,
+ uint64_t *out)
+{
+ unsigned long ret[PLPAR_HCALL_BUFSIZE];
+ struct papr_scm_perf_stat *stats;
+ s64 rc, i;
+
+ /* Setup the out buffer */
+ if (buff_stats) {
+ memcpy(buff_stats->eye_catcher,
+ PAPR_SCM_PERF_STATS_EYECATCHER, 8);
+ buff_stats->stats_version =
+ cpu_to_be32(PAPR_SCM_PERF_STATS_VERSION);
+ buff_stats->num_statistics =
+ cpu_to_be32(num_stats);
+ } else {
+ /* In case of no out buffer ignore the size */
+ size = 0;
+ }
+
+ /*
+ * Do the HCALL asking PHYP for info and if R4 was requested
+ * return its value in 'out' variable.
+ */
+ rc = plpar_hcall(H_SCM_PERFORMANCE_STATS, ret, p->drc_index,
+ __pa(buff_stats), size);
+ if (out)
+ *out = ret[0];
+
+ if (rc == H_PARTIAL) {
+ dev_err(&p->pdev->dev,
+ "Unknown performance stats, Err:0x%016lX\n", ret[0]);
+ return -ENOENT;
+ } else if (rc != H_SUCCESS) {
+ dev_err(&p->pdev->dev,
+ "Failed to query performance stats, Err:%lld\n", rc);
+ return -ENXIO;
+ }
+
+ /* Successfully fetched the requested stats from phyp */
+ if (size != 0) {
+ buff_stats->num_statistics =
+ be32_to_cpu(buff_stats->num_statistics);
+
+ /* Transform the stats buffer values from BE to cpu native */
+ for (i = 0, stats = buff_stats->scm_statistics;
+ i < buff_stats->num_statistics; ++i) {
+ stats[i].statistic_value =
+ be64_to_cpu(stats[i].statistic_value);
+ }
+ dev_dbg(&p->pdev->dev,
+ "Performance stats returned %d stats\n",
+ buff_stats->num_statistics);
+ } else {
+ /* Handle case where stat buffer size was requested */
+ dev_dbg(&p->pdev->dev,
+ "Performance stats size %ld\n", ret[0]);
+ }
+
+ return 0;
+}
+
/*
* Issue hcall to retrieve dimm health info and populate papr_scm_priv with the
* health information.
@@ -563,6 +656,47 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
return *cmd_rc;
}
+static ssize_t perf_stats_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int index, rc;
+ struct seq_buf s;
+ struct nvdimm *dimm = to_nvdimm(dev);
+ struct papr_scm_priv *p = nvdimm_provider_data(dimm);
+ struct papr_scm_perf_stat *stats = p->perf_stats->scm_statistics;
+
+ if (!p->len_stat_buffer)
+ return -ENOENT;
+
+ seq_buf_init(&s, buf, PAGE_SIZE);
+
+ /* Protect concurrent modifications to papr_scm_priv */
+ rc = mutex_lock_interruptible(&p->health_mutex);
+ if (rc)
+ return rc;
+
+ /* Ask phyp to return all dimm perf stats */
+ rc = drc_pmem_query_stats(p, p->perf_stats, p->len_stat_buffer, 0,
+ NULL);
+ if (!rc) {
+ /*
+ * Go through the returned output buffer and print stats and
+ * values. Since statistic_id is essentially a char string of
+ * 8 bytes, simply use the string format specifier to print it.
+ */
+ for (index = 0; index < p->perf_stats->num_statistics;
+ ++index) {
+ seq_buf_printf(&s, "%.8s = 0x%016llX\n",
+ stats[index].statistic_id,
+ stats[index].statistic_value);
+ }
+ }
+
+ mutex_unlock(&p->health_mutex);
+ return rc ? rc : seq_buf_used(&s);
+}
+DEVICE_ATTR_RO(perf_stats);
+
static ssize_t flags_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -615,6 +749,7 @@ DEVICE_ATTR_RO(flags);
/* papr_scm specific dimm attributes */
static struct attribute *papr_scm_nd_attributes[] = {
&dev_attr_flags.attr,
+ &dev_attr_perf_stats.attr,
NULL,
};
@@ -635,6 +770,7 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
struct nd_region_desc ndr_desc;
unsigned long dimm_flags;
int target_nid, online_nid;
+ u64 stat_size;
p->bus_desc.ndctl = papr_scm_ndctl;
p->bus_desc.module = THIS_MODULE;
@@ -698,6 +834,26 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
dev_info(dev, "Region registered with target node %d and online node %d",
target_nid, online_nid);
+ /* Try retriving the stat buffer and see if its supported */
+ if (!drc_pmem_query_stats(p, NULL, 0, 0, &stat_size)) {
+ /* Allocate the buffer for phyp where stats are written */
+ p->perf_stats = kzalloc(stat_size, GFP_KERNEL);
+
+ /* Failed allocation is non fatal and results in limited data */
+ if (!p->perf_stats)
+ dev_dbg(&p->pdev->dev,
+ "Unable to allocate %llu bytes for perf-state",
+ stat_size);
+ else
+ p->len_stat_buffer = (size_t)stat_size;
+ } else {
+ dev_dbg(&p->pdev->dev, "Unable to retrieve performace stats\n");
+ }
+
+ /* Check if perf-stats buffer was allocated */
+ if (!p->len_stat_buffer)
+ dev_info(&p->pdev->dev, "Limited dimm info available\n");
+
return 0;
err: nvdimm_bus_unregister(p->bus);
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau
From: Emil Velikov @ 2020-05-18 11:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-fbdev, Antonino Daplas, Bartlomiej Zolnierkiewicz,
ML dri-devel, Paul Mackerras, linuxppc-dev
In-Reply-To: <9b0db95949b973c682b449906573e7b28c6113ef.camel@kernel.crashing.org>
Hi Benjamin,
On Mon, 18 May 2020 at 01:45, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> On Sun, 2020-05-17 at 23:05 +0100, Emil Velikov wrote:
> > As mentioned in earlier commit, the riva and nvidia fbdev drivers
> > have
> > seen no love over the years, are short on features and overall below
> > par
> >
> > Users are encouraged to switch to the nouveau drm driver instead.
> >
> > v2: Split configs to separate patch, enable nouveau (Bartlomiej)
>
> Back when I still had these things to play with (years ago) nouveau
> didn't work properly on these ancient machines.
>
I believe you reported issues due to different page size for the CPU/GPU.
Have you tried nouveau recently, there has been a handful of patches
on the topic since your report.
Alternatively, it would make sense you rebase, cleanup and merge your patch.
-Emil
^ permalink raw reply
* [PATCH] ASoC: fsl_micfil: Fix indentation to put on one line affected code
From: Tang Bin @ 2020-05-18 10:59 UTC (permalink / raw)
To: broonie, timur, nicoleotsuka, Xiubo.Lee, perex
Cc: alsa-devel, linuxppc-dev, linux-kernel, Tang Bin
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line.
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
---
sound/soc/fsl/fsl_micfil.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index f7f2d29f1..79cf488fa 100644
--- a/sound/soc/fsl/fsl_micfil.c
+++ b/sound/soc/fsl/fsl_micfil.c
@@ -217,8 +217,7 @@ static int fsl_micfil_startup(struct snd_pcm_substream *substream,
struct fsl_micfil *micfil = snd_soc_dai_get_drvdata(dai);
if (!micfil) {
- dev_err(dai->dev,
- "micfil dai priv_data not set\n");
+ dev_err(dai->dev, "micfil dai priv_data not set\n");
return -EINVAL;
}
--
2.20.1.windows.1
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl_micfil: Fix format and unused assignment
From: Tang Bin @ 2020-05-18 10:47 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, timur, Xiubo.Lee, linux-kernel, perex, nicoleotsuka,
linuxppc-dev
In-Reply-To: <20200518102513.GA8699@sirena.org.uk>
On 2020/5/18 18:25, Mark Brown wrote:
> On Mon, May 18, 2020 at 03:44:05PM +0800, Tang Bin wrote:
>> In the function fsl_micfil_startup(), the two lines of dev_err()
>> can be shortened to one line. And delete unused initialized value
>> of 'ret', because it will be assigned by the function
>> fsl_micfil_set_mclk_rate().
> This is two separate changes with no overlap so would have been better
> sent as separate patches.
Got it, Thanks
Tang Bin
^ permalink raw reply
* Re: [PATCH] powerpc/sysdev: fix compile errors
From: Christophe Leroy @ 2020-05-18 10:36 UTC (permalink / raw)
To: Jiri Kosina, Christophe Leroy
Cc: Kate Stewart, linux-kernel, wenhu.pku, Paul Mackerras,
Greg Kroah-Hartman, WANG Wenhu, linuxppc-dev, Thomas Gleixner,
Allison Randal
In-Reply-To: <nycvar.YFH.7.76.2005181232140.25812@cbobk.fhfr.pm>
Le 18/05/2020 à 12:32, Jiri Kosina a écrit :
> On Mon, 18 May 2020, Jiri Kosina wrote:
>
>>>> Include linux/io.h into fsl_85xx_cache_sram.c to fix the
>>>> implicit-declaration compile errors when building Cache-Sram.
>>>>
>>>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
>>>> ‘instantiate_cache_sram’:
>>>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration
>>>> of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’?
>>>> [-Werror=implicit-function-declaration]
>>>> cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
>>>> ^~~~~~~~~~~~~~~~
>>>> bitmap_complement
>>>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes
>>>> pointer from integer without a cast [-Werror=int-conversion]
>>>> cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
>>>> ^
>>>> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration
>>>> of function ‘iounmap’; did you mean ‘roundup’?
>>>> [-Werror=implicit-function-declaration]
>>>> iounmap(cache_sram->base_virt);
>>>> ^~~~~~~
>>>> roundup
>>>> cc1: all warnings being treated as errors
>>>>
>>>> Fixed: commit 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
>>>> Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com>
>>>
>>> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> As this doesn't seem to have been picked up for linux-next yet, I am
>> picking it up now.
>
> Only now I've noticed that this is actually a dead code o_O as this file
> can't be built by any combination of config options. So I am dropping the
> patch again, but why do we keep it in the tree in the first place?
>
There is a series aiming at making use of it, see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172421
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc/sysdev: fix compile errors
From: Jiri Kosina @ 2020-05-18 10:32 UTC (permalink / raw)
To: Christophe Leroy
Cc: Kate Stewart, linux-kernel, wenhu.pku, Paul Mackerras,
Greg Kroah-Hartman, WANG Wenhu, linuxppc-dev, Thomas Gleixner,
Allison Randal
In-Reply-To: <nycvar.YFH.7.76.2005181228480.25812@cbobk.fhfr.pm>
On Mon, 18 May 2020, Jiri Kosina wrote:
> > > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > > implicit-declaration compile errors when building Cache-Sram.
> > >
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > > ‘instantiate_cache_sram’:
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration
> > > of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’?
> > > [-Werror=implicit-function-declaration]
> > > cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> > > ^~~~~~~~~~~~~~~~
> > > bitmap_complement
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes
> > > pointer from integer without a cast [-Werror=int-conversion]
> > > cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> > > ^
> > > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration
> > > of function ‘iounmap’; did you mean ‘roundup’?
> > > [-Werror=implicit-function-declaration]
> > > iounmap(cache_sram->base_virt);
> > > ^~~~~~~
> > > roundup
> > > cc1: all warnings being treated as errors
> > >
> > > Fixed: commit 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> > > Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com>
> >
> > Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> As this doesn't seem to have been picked up for linux-next yet, I am
> picking it up now.
Only now I've noticed that this is actually a dead code o_O as this file
can't be built by any combination of config options. So I am dropping the
patch again, but why do we keep it in the tree in the first place?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] powerpc/sysdev: fix compile errors
From: Jiri Kosina @ 2020-05-18 10:29 UTC (permalink / raw)
To: Christophe Leroy
Cc: Kate Stewart, linux-kernel, wenhu.pku, Paul Mackerras,
Greg Kroah-Hartman, WANG Wenhu, linuxppc-dev, Thomas Gleixner,
Allison Randal
In-Reply-To: <62251ec1-dd42-6522-dcb2-613838cd5504@c-s.fr>
On Mon, 2 Mar 2020, Christophe Leroy wrote:
> > Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> > implicit-declaration compile errors when building Cache-Sram.
> >
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function
> > ‘instantiate_cache_sram’:
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration
> > of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’?
> > [-Werror=implicit-function-declaration]
> > cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> > ^~~~~~~~~~~~~~~~
> > bitmap_complement
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes
> > pointer from integer without a cast [-Werror=int-conversion]
> > cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> > ^
> > arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration
> > of function ‘iounmap’; did you mean ‘roundup’?
> > [-Werror=implicit-function-declaration]
> > iounmap(cache_sram->base_virt);
> > ^~~~~~~
> > roundup
> > cc1: all warnings being treated as errors
> >
> > Fixed: commit 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> > Signed-off-by: WANG Wenhu <wenhu.wang@vivo.com>
>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
As this doesn't seem to have been picked up for linux-next yet, I am
picking it up now.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_micfil: Fix format and unused assignment
From: Mark Brown @ 2020-05-18 10:25 UTC (permalink / raw)
To: Tang Bin
Cc: alsa-devel, timur, Xiubo.Lee, linux-kernel, perex, nicoleotsuka,
linuxppc-dev
In-Reply-To: <20200518074405.14880-1-tangbin@cmss.chinamobile.com>
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
On Mon, May 18, 2020 at 03:44:05PM +0800, Tang Bin wrote:
> In the function fsl_micfil_startup(), the two lines of dev_err()
> can be shortened to one line. And delete unused initialized value
> of 'ret', because it will be assigned by the function
> fsl_micfil_set_mclk_rate().
This is two separate changes with no overlap so would have been better
sent as separate patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/wii: Fix declaration made after definition
From: Nathan Chancellor @ 2020-05-18 9:32 UTC (permalink / raw)
To: Michael Ellerman
Cc: kbuild test robot, linux-kernel, clang-built-linux,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20200413190644.16757-1-natechancellor@gmail.com>
On Mon, Apr 13, 2020 at 12:06:45PM -0700, Nathan Chancellor wrote:
> A 0day randconfig uncovered an error with clang, trimmed for brevity:
>
> arch/powerpc/platforms/embedded6xx/wii.c:195:7: error: attribute
> declaration must precede definition [-Werror,-Wignored-attributes]
> if (!machine_is(wii))
> ^
>
> The macro machine_is declares mach_##name but define_machine actually
> defines mach_##name, hence the warning.
>
> To fix this, move define_machine after the is_machine usage.
>
> Fixes: 5a7ee3198dfa ("powerpc: wii: platform support")
> Reported-by: kbuild test robot <lkp@intel.com>
> Link: https://github.com/ClangBuiltLinux/linux/issues/989
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> arch/powerpc/platforms/embedded6xx/wii.c | 25 ++++++++++++------------
> 1 file changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c
> index 67e48b0a164e..a802ef957d63 100644
> --- a/arch/powerpc/platforms/embedded6xx/wii.c
> +++ b/arch/powerpc/platforms/embedded6xx/wii.c
> @@ -172,19 +172,6 @@ static void wii_shutdown(void)
> flipper_quiesce();
> }
>
> -define_machine(wii) {
> - .name = "wii",
> - .probe = wii_probe,
> - .setup_arch = wii_setup_arch,
> - .restart = wii_restart,
> - .halt = wii_halt,
> - .init_IRQ = wii_pic_probe,
> - .get_irq = flipper_pic_get_irq,
> - .calibrate_decr = generic_calibrate_decr,
> - .progress = udbg_progress,
> - .machine_shutdown = wii_shutdown,
> -};
> -
> static const struct of_device_id wii_of_bus[] = {
> { .compatible = "nintendo,hollywood", },
> { },
> @@ -200,3 +187,15 @@ static int __init wii_device_probe(void)
> }
> device_initcall(wii_device_probe);
>
> +define_machine(wii) {
> + .name = "wii",
> + .probe = wii_probe,
> + .setup_arch = wii_setup_arch,
> + .restart = wii_restart,
> + .halt = wii_halt,
> + .init_IRQ = wii_pic_probe,
> + .get_irq = flipper_pic_get_irq,
> + .calibrate_decr = generic_calibrate_decr,
> + .progress = udbg_progress,
> + .machine_shutdown = wii_shutdown,
> +};
>
> base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136
> --
> 2.26.0
>
Gentle ping for review/acceptance.
Cheers,
Nathan
^ permalink raw reply
* [PATCH] ASoC: fsl_micfil: Fix format and unused assignment
From: Tang Bin @ 2020-05-18 7:44 UTC (permalink / raw)
To: broonie, timur, nicoleotsuka, Xiubo.Lee, perex
Cc: alsa-devel, linuxppc-dev, linux-kernel, Tang Bin
In the function fsl_micfil_startup(), the two lines of dev_err()
can be shortened to one line. And delete unused initialized value
of 'ret', because it will be assigned by the function
fsl_micfil_set_mclk_rate().
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
---
sound/soc/fsl/fsl_micfil.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index f7f2d29f1..a7a6118be 100644
--- a/sound/soc/fsl/fsl_micfil.c
+++ b/sound/soc/fsl/fsl_micfil.c
@@ -217,8 +217,7 @@ static int fsl_micfil_startup(struct snd_pcm_substream *substream,
struct fsl_micfil *micfil = snd_soc_dai_get_drvdata(dai);
if (!micfil) {
- dev_err(dai->dev,
- "micfil dai priv_data not set\n");
+ dev_err(dai->dev, "micfil dai priv_data not set\n");
return -EINVAL;
}
@@ -296,7 +295,7 @@ static int fsl_set_clock_params(struct device *dev, unsigned int rate)
{
struct fsl_micfil *micfil = dev_get_drvdata(dev);
int clk_div;
- int ret = 0;
+ int ret;
ret = fsl_micfil_set_mclk_rate(micfil, rate);
if (ret < 0)
--
2.20.1.windows.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau
From: Michael Ellerman @ 2020-05-18 7:30 UTC (permalink / raw)
To: Emil Velikov, dri-devel
Cc: linux-fbdev, Antonino Daplas, Bartlomiej Zolnierkiewicz,
emil.l.velikov, Paul Mackerras, linuxppc-dev
In-Reply-To: <20200517220524.4036334-2-emil.l.velikov@gmail.com>
Emil Velikov <emil.l.velikov@gmail.com> writes:
> As mentioned in earlier commit, the riva and nvidia fbdev drivers have
> seen no love over the years, are short on features and overall below par
>
> Users are encouraged to switch to the nouveau drm driver instead.
>
> v2: Split configs to separate patch, enable nouveau (Bartlomiej)
>
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
> ---
> Hi all unless, there are objections I would prefer to merge this via
> the drm tree.
Have you tested that the resulting kernels work on the relevant
hardware?
The old drivers may be crufty but they presumably have been tested by
people and at least somewhat work.
So I'd be inclined to leave the defconfigs alone until someone can test
that the new driver works at all.
I gave it a quick spin on a G5 I have access to and dmesg has a bunch of
errors in it (see below). I can't actually tell if the display is
working because the machine is remote, and I can't go and check it at
the moment because the office is closed.
cheers
[ 128.563251] nouveau 0000:f0:10.0: NVIDIA NV34 (034900b1)
[ 128.565720] nouveau 0000:f0:10.0: bios: version 04.34.20.18.00
[ 128.570994] nouveau 0000:f0:10.0: bios: OOB 1 00000cdd 00000cdd
[ 128.571702] nouveau 0000:f0:10.0: bios: OOB 1 00000ce1 00000ce1
[ 128.571723] nouveau 0000:f0:10.0: bios: OOB 1 00000cde 00000cde
[ 128.571731] nouveau 0000:f0:10.0: bios: OOB 1 00000cdf 00000cdf
[ 128.572438] nouveau 0000:f0:10.0: bios: OOB 1 00000ce5 00000ce5
[ 128.572459] nouveau 0000:f0:10.0: bios: OOB 1 00000ce2 00000ce2
[ 128.572468] nouveau 0000:f0:10.0: bios: OOB 1 00000ce3 00000ce3
[ 128.579187] nouveau 0000:f0:10.0: bios: OOB 1 00000ce9 00000ce9
[ 128.579210] nouveau 0000:f0:10.0: bios: OOB 1 00000ce6 00000ce6
[ 128.579219] nouveau 0000:f0:10.0: bios: OOB 1 00000ce7 00000ce7
[ 128.580230] nouveau 0000:f0:10.0: bios: OOB 1 00000ced 00000ced
[ 128.580252] nouveau 0000:f0:10.0: bios: OOB 1 00000cea 00000cea
[ 128.580261] nouveau 0000:f0:10.0: bios: OOB 1 00000ceb 00000ceb
[ 128.581543] nouveau 0000:f0:10.0: bios: OOB 1 00000cf1 00000cf1
[ 128.581567] nouveau 0000:f0:10.0: bios: OOB 1 00000cee 00000cee
[ 128.581576] nouveau 0000:f0:10.0: bios: OOB 1 00000cef 00000cef
[ 128.582456] nouveau 0000:f0:10.0: bios: OOB 1 00000cf5 00000cf5
[ 128.582479] nouveau 0000:f0:10.0: bios: OOB 1 00000cf2 00000cf2
[ 128.582487] nouveau 0000:f0:10.0: bios: OOB 1 00000cf3 00000cf3
[ 128.583314] nouveau 0000:f0:10.0: bios: OOB 1 00000cf9 00000cf9
[ 128.583336] nouveau 0000:f0:10.0: bios: OOB 1 00000cf6 00000cf6
[ 128.583344] nouveau 0000:f0:10.0: bios: OOB 1 00000cf7 00000cf7
[ 128.584186] nouveau 0000:f0:10.0: bios: OOB 1 00000cfd 00000cfd
[ 128.584208] nouveau 0000:f0:10.0: bios: OOB 1 00000cfa 00000cfa
[ 128.584217] nouveau 0000:f0:10.0: bios: OOB 1 00000cfb 00000cfb
[ 128.585635] nouveau 0000:f0:10.0: bios: OOB 1 00000d01 00000d01
[ 128.585658] nouveau 0000:f0:10.0: bios: OOB 1 00000cfe 00000cfe
[ 128.585666] nouveau 0000:f0:10.0: bios: OOB 1 00000cff 00000cff
[ 128.589405] nouveau 0000:f0:10.0: bios: OOB 1 00000d05 00000d05
[ 128.589428] nouveau 0000:f0:10.0: bios: OOB 1 00000d02 00000d02
[ 128.589436] nouveau 0000:f0:10.0: bios: OOB 1 00000d03 00000d03
[ 128.590316] nouveau 0000:f0:10.0: bios: OOB 1 00000d09 00000d09
[ 128.590338] nouveau 0000:f0:10.0: bios: OOB 1 00000d06 00000d06
[ 128.590346] nouveau 0000:f0:10.0: bios: OOB 1 00000d07 00000d07
[ 128.591173] nouveau 0000:f0:10.0: bios: OOB 1 00000d0d 00000d0d
[ 128.591196] nouveau 0000:f0:10.0: bios: OOB 1 00000d0a 00000d0a
[ 128.591205] nouveau 0000:f0:10.0: bios: OOB 1 00000d0b 00000d0b
[ 128.593513] nouveau 0000:f0:10.0: tmr: unknown input clock freq
[ 128.595886] nouveau 0000:f0:10.0: fb: 64 MiB DDR1
[ 128.609034] [TTM] Zone kernel: Available graphics memory: 500010 KiB
[ 128.609058] [TTM] Initializing pool allocator
[ 128.609106] nouveau 0000:f0:10.0: DRM: VRAM: 63 MiB
[ 128.609115] nouveau 0000:f0:10.0: DRM: GART: 128 MiB
[ 128.609134] nouveau 0000:f0:10.0: DRM: BMP version 5.38
[ 128.609144] nouveau 0000:f0:10.0: DRM: DCB version 2.2
[ 128.609155] nouveau 0000:f0:10.0: DRM: DCB outp 00: 01000122 00000004
[ 128.609168] nouveau 0000:f0:10.0: DRM: DCB outp 01: 02010200 11b088b8
[ 128.609177] nouveau 0000:f0:10.0: DRM: DCB outp 02: 02010201 11b00703
[ 128.609222] nouveau 0000:f0:10.0: DRM: Loading NV17 power sequencing microcode
[ 128.610947] nouveau 0000:f0:10.0: DRM: MM: using M2MF for buffer copies
[ 128.613371] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 128.615065] nouveau 0000:f0:10.0: DRM: Setting dpms mode 3 on TV encoder (output 2)
[ 128.707050] nouveau 0000:f0:10.0: TV-1: EDID is invalid:
[ 128.707075] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707083] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707091] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707099] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707106] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707114] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707121] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707129] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 128.707144] nouveau 0000:f0:10.0: DRM: DDC responded, but no EDID for TV-1
[ 128.750558] nouveau 0000:f0:10.0: DRM: allocated 1440x900 fb: 0x9000, bo 000000002677d038
[ 128.825341] nouveau 0000:f0:10.0: DRM: DDC responded, but no EDID for TV-1
[ 128.885351] nouveau 0000:f0:10.0: DRM: Pixel clock comparison table not found
[ 128.905884] Console: switching to colour frame buffer device 180x56
[ 128.907251] nouveau 0000:f0:10.0: fb0: nouveaudrmfb frame buffer device
[ 128.911832] [drm] Initialized nouveau 1.3.1 20120801 for 0000:f0:10.0 on minor 0
[ 129.168778] nouveau 0000:f0:10.0: DRM: DDC responded, but no EDID for TV-1
[ 131.014692] Adding 2947556k swap on /dev/sda4. Priority:-2 extents:1 across:2947556k
[ 133.501059] sungem_phy: PHY ID: 4061e4, addr: 0
[ 133.502214] gem 0001:03:0f.0 eth0: Found BCM5221 PHY
[ 135.940863] gem 0001:03:0f.0 eth0: Link is up at 100 Mbps, full-duplex
[ 135.941181] gem 0001:03:0f.0 eth0: Pause is disabled
[ 136.224079] nouveau 0000:f0:10.0: DRM: DDC responded, but no EDID for TV-1
[ 136.297015] nouveau 0000:f0:10.0: DRM: DDC responded, but no EDID for TV-1
[ 139.465278] nouveau 0000:f0:10.0: DRM: Pixel clock comparison table not found
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix early_init_mmu section mismatch
From: Christian Zigotzky @ 2020-05-18 7:05 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <87mu669d9j.fsf@mpe.ellerman.id.au>
OK, thanks.
> On 18. May 2020, at 04:40, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Christian Zigotzky <chzigotzky@xenosoft.de> writes:
>> Hi All,
>>
>> This patch wasn't included in the PowerPC fixes 5.7-4. Please add it.
>
> It's not an important bug. I'll take the patch for v5.8
>
> cheers
>
>>> On 29 April 2020 at 09:02 am, Nicholas Piggin wrote:
>>> Christian reports:
>>>
>>> MODPOST vmlinux.o
>>> WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in
>>> reference from the function .early_init_mmu() to the function
>>> .init.text:.radix__early_init_mmu()
>>> The function .early_init_mmu() references
>>> the function __init .radix__early_init_mmu().
>>> This is often because .early_init_mmu lacks a __init
>>> annotation or the annotation of .radix__early_init_mmu is wrong.
>>>
>>> WARNING: modpost: vmlinux.o(.text.unlikely+0x1ac): Section mismatch in
>>> reference from the function .early_init_mmu() to the function
>>> .init.text:.hash__early_init_mmu()
>>> The function .early_init_mmu() references
>>> the function __init .hash__early_init_mmu().
>>> This is often because .early_init_mmu lacks a __init
>>> annotation or the annotation of .hash__early_init_mmu is wrong.
>>>
>>> The compiler is uninlining early_init_mmu and not putting it in an init
>>> section because there is no annotation. Add it.
>>>
>>> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>>> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/include/asm/book3s/64/mmu.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
>>> index bb3deb76c951..3ffe5f967483 100644
>>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>>> @@ -208,7 +208,7 @@ void hash__early_init_devtree(void);
>>> void radix__early_init_devtree(void);
>>> extern void hash__early_init_mmu(void);
>>> extern void radix__early_init_mmu(void);
>>> -static inline void early_init_mmu(void)
>>> +static inline void __init early_init_mmu(void)
>>> {
>>> if (radix_enabled())
>>> return radix__early_init_mmu();
^ permalink raw reply
* Re: [PATCH v3] powerpc/64: Option to use ELF V2 ABI for big-endian kernels
From: Michael Ellerman @ 2020-05-18 6:35 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20200429011959.1423180-1-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> Provide an option to build big-endian kernels using the ELF V2 ABI. This works
> on GCC and clang (since about 2014). it is is not officially supported by the
> GNU toolchain, but it can give big-endian kernels some useful advantages of
> the V2 ABI (e.g., less stack usage).
>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> Since v1:
> - Improved the override flavour name suggested by Segher.
> - Improved changelog wording.
>
> Since v2:
> - Improved changelog, help text, to use the name ELF V2 ABI in the spec,
> and clarify things a bit more, suggested by Segher.
> - For option name, match the ELF_ABI_v1/2 which is already in the kernel.
> - Prefix options with PPC64_ to avoid arch clashes or confusion.
> - "elfv2" is the toolchain name of the ABI, so I kept that in the crypto
> perl scripts.
>
> arch/powerpc/Kconfig | 21 +++++++++++++++++++++
> arch/powerpc/Makefile | 15 ++++++++++-----
> arch/powerpc/boot/Makefile | 4 ++++
> drivers/crypto/vmx/Makefile | 8 ++++++--
> drivers/crypto/vmx/ppc-xlate.pl | 10 ++++++----
> 5 files changed, 47 insertions(+), 11 deletions(-)
This doesn't build with clang:
/tmp/aesp8-ppc-dad624.s: Assembler messages:
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_set_encrypt_key does not evaluate to a constant
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_set_decrypt_key does not evaluate to a constant
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_encrypt does not evaluate to a constant
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_decrypt does not evaluate to a constant
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_cbc_encrypt does not evaluate to a constant
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_ctr32_encrypt_blocks does not evaluate to a constant
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_xts_encrypt does not evaluate to a constant
/tmp/aesp8-ppc-dad624.s: Error: .size expression for aes_p8_xts_decrypt does not evaluate to a constant
clang: error: assembler command failed with exit code 1 (use -v to see invocation)
make[4]: *** [/linux/scripts/Makefile.build:349: drivers/crypto/vmx/aesp8-ppc.o] Error 1
make[4]: *** Waiting for unfinished jobs....
/tmp/ghashp8-ppc-01aa43.s: Assembler messages:
/tmp/ghashp8-ppc-01aa43.s: Error: .size expression for gcm_init_p8 does not evaluate to a constant
/tmp/ghashp8-ppc-01aa43.s: Error: .size expression for gcm_gmult_p8 does not evaluate to a constant
/tmp/ghashp8-ppc-01aa43.s: Error: .size expression for gcm_ghash_p8 does not evaluate to a constant
clang: error: assembler command failed with exit code 1 (use -v to see invocation)
make[4]: *** [/linux/scripts/Makefile.build:349: drivers/crypto/vmx/ghashp8-ppc.o] Error 1
make[3]: *** [/linux/scripts/Makefile.build:488: drivers/crypto/vmx] Error 2
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [/linux/scripts/Makefile.build:488: drivers/crypto] Error 2
make[2]: *** Waiting for unfinished jobs....
/linux/drivers/scsi/qla2xxx/qla_nx2.c:3226:1: warning: stack frame size of 2208 bytes in function 'qla8044_collect_md_data' [-Wframe-larger-than=]
qla8044_collect_md_data(struct scsi_qla_host *vha)
^
1 warning generated.
make[1]: *** [/linux/Makefile:1722: drivers] Error 2
make: *** [Makefile:180: sub-make] Error 2
I'm not sure if it can work with clang at all, so I'm happy if the
option depends on !CC_IS_CLANG.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/book3s64/radix/tlb: Determine hugepage flush correctly
From: Michael Ellerman @ 2020-05-18 6:34 UTC (permalink / raw)
To: Nicholas Piggin, Aneesh Kumar K.V, linuxppc-dev; +Cc: Bharata B Rao
In-Reply-To: <1589344088.xrvol2hteg.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Aneesh Kumar K.V's message of May 13, 2020 1:06 pm:
>> With a 64K page size flush with start and end value as below
>> (start, end) = (721f680d0000, 721f680e0000) results in
>> (hstart, hend) = (721f68200000, 721f68000000)
>>
>> Avoid doing a __tlbie_va_range with the wrong hstart and hend value in this
>> case.
>>
>> __tlbie_va_range will skip the actual tlbie operation for start > end.
>> But we still end up doing the tlbie fixup.
>
> Hm, good catch.
>
>> Reported-by: Bharata B Rao <bharata@linux.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> arch/powerpc/mm/book3s64/radix_tlb.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c b/arch/powerpc/mm/book3s64/radix_tlb.c
>> index 758ade2c2b6e..d592f9e1c037 100644
>> --- a/arch/powerpc/mm/book3s64/radix_tlb.c
>> +++ b/arch/powerpc/mm/book3s64/radix_tlb.c
>> @@ -884,10 +884,10 @@ static inline void __radix__flush_tlb_range(struct mm_struct *mm,
>> if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
>> hstart = (start + PMD_SIZE - 1) & PMD_MASK;
>> hend = end & PMD_MASK;
>> - if (hstart == hend)
>> - hflush = false;
>> - else
>> + if (hstart < hend)
>> hflush = true;
>> + else
>> + hflush = false;
>
> We can probably get rid of the else part since it is already false.
Yeah I can do that when applying.
cheers
^ permalink raw reply
* Re: [PATCH v2 7/9] powerpc/ps3: Add check for otheros image size
From: Michael Ellerman @ 2020-05-18 6:31 UTC (permalink / raw)
To: Geoff Levand
Cc: linuxppc-dev, Geert Uytterhoeven, Markus Elfring,
Emmanuel Nicolet
In-Reply-To: <65353693-f082-42eb-aa89-ab11ea5f623b@infradead.org>
Geoff Levand <geoff@infradead.org> writes:
> Hi Michael,
>
> On 5/14/20 7:02 PM, Michael Ellerman wrote:
>> Geoff Levand <geoff@infradead.org> writes:
> ...
>>> + # The ps3's flash loader has a size limit of 16 MiB for the uncompressed
>>> + # image. If a compressed image that exceeded this limit is written to
>>> + # flash the loader will decompress that image until the 16 MiB limit is
>>> + # reached, then enter the system reset vector of the partially decompressed
>>> + # image. No warning is issued.
>>> + rm -f "$odir"/{otheros,otheros-too-big}.bld
>>> + size=$(${CROSS}nm --no-sort --radix=d "$ofile" | egrep ' _end$' | cut -d' ' -f1)
>>> + bld="otheros.bld"
>>> + if [ $size -gt $((0x1000000)) ]; then
>>> + bld="otheros-too-big.bld"
>>> + echo " INFO: Uncompressed kernel is too large to program into PS3 flash memory;" \
>>
>> This now appears on all my ppc64_defconfig builds, which I don't really
>> like.
>
> No, neither do I. I didn't think of that case.
>
>> That does highlight the fact that ppc64_defconfig including
>> CONFIG_PPC_PS3 is not really helpful for people actually wanting to run
>> the kernel on a PS3.
>
> No, this is just for the bootloader image (.bld) that can be
> programed into flash memory. This is what is used to create,
> for example, a petitboot bootloader image.
>
> Normal usage is for the bootloader in flash to load a vmlinux
> image from disk or network, in which case running a ppc64_defconfig
> image would be fine.
Ah yep, that rings a bell.
>> So I wonder if we should drop CONFIG_PPC_PS3 from ppc64_defconfig, in
>> which case I'd be happy to keep the INFO message because it should only
>> appear on ps3 specific builds.
>
> I'd like to keep CONFIG_PPC_PS3 set in ppc64_defconfig. I feel it
> useful to get some build testing of the PS3 platform code.
>
>> The other option would be to drop the message, or only print it when
>> we're doing a verbose build.
>
> Building a boatloader image to program into flash memory is
> something only very advanced users would be doing. I don't
> think they would need this message. They would see the file
> name and understand the situation. I'll post a v3 patch that
> removes the message.
Great, thanks.
cheers
^ permalink raw reply
* Re: [PATCH v8 2/5] powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details
From: kajoljain @ 2020-05-18 5:32 UTC (permalink / raw)
To: Nathan Lynch
Cc: ravi.bangoria, maddy, anju, peterz, gregkh, suka,
alexander.shishkin, mingo, mpetlan, yao.jin, ak, mamatha4, acme,
jmario, namhyung, linuxppc-dev, jolsa, kan.liang
In-Reply-To: <87blmu2nac.fsf@linux.ibm.com>
On 5/12/20 2:37 AM, Nathan Lynch wrote:
> Hi,
>
> Kajol Jain <kjain@linux.ibm.com> writes:
>> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
>> index 48e8f4b17b91..8cf242aad98f 100644
>> --- a/arch/powerpc/perf/hv-24x7.c
>> +++ b/arch/powerpc/perf/hv-24x7.c
>> @@ -20,6 +20,7 @@
>> #include <asm/io.h>
>> #include <linux/byteorder/generic.h>
>>
>> +#include <asm/rtas.h>
>> #include "hv-24x7.h"
>> #include "hv-24x7-catalog.h"
>> #include "hv-common.h"
>> @@ -57,6 +58,75 @@ static bool is_physical_domain(unsigned domain)
>> }
>> }
>>
>> +/*
>> + * The Processor Module Information system parameter allows transferring
>> + * of certain processor module information from the platform to the OS.
>> + * Refer PAPR+ document to get parameter token value as '43'.
>> + */
>> +
>> +#define PROCESSOR_MODULE_INFO 43
>> +#define PROCESSOR_MAX_LENGTH (8 * 1024)
>> +
>> +DEFINE_SPINLOCK(rtas_local_data_buf_lock);
>> +EXPORT_SYMBOL(rtas_local_data_buf_lock);
>
> This should be static and not exported, correct?
>
>> +
>> +static u32 phys_sockets; /* Physical sockets */
>> +static u32 phys_chipspersocket; /* Physical chips per socket*/
>> +static u32 phys_coresperchip; /* Physical cores per chip */
>> +
>> +/*
>> + * Function read_sys_info_pseries() make a rtas_call which require
>> + * data buffer of size 8K. As standard 'rtas_data_buf' is of size
>> + * 4K, we are adding new local buffer 'rtas_local_data_buf'.
>
> Sorry if this has been covered before but I don't understand why it
> would require a larger buffer; by my reading this call will return *ten
> bytes* of output. Also, current versions of PAPR+ limit the output
> length to 4002 bytes. I feel like I'm missing something.
>
Hi Nathan,
Thanks for reviewing the patch. Actually when I was testing this patch in
both power8 and power9 machine, I got some issue in power9 because of buffer size.
And I checked the buffer size used in util_linux which is 8192. So, I increase the
buffer size.I will again test it as I did couple of changes after that with 4002 size.
>
>> + */
>> +static __be16 rtas_local_data_buf[PROCESSOR_MAX_LENGTH] __cacheline_aligned;
>> +
>> +/*
>> + * read_sys_info_pseries()
>> + * Retrieve the number of sockets and chips per socket and cores per
>> + * chip details through the get-system-parameter rtas call.
>> + */
>> +void read_sys_info_pseries(void)
>> +{
>> + int call_status, len, ntypes;
>> +
>> + /*
>> + * Making system parameter: chips and sockets and cores per chip
>> + * default to 1.
>> + */
>> + phys_sockets = 1;
>> + phys_chipspersocket = 1;
>> + phys_coresperchip = 1;
>> + memset(rtas_local_data_buf, 0, PROCESSOR_MAX_LENGTH * sizeof(__be16));
>
> Modifying global state outside of any critical section...? How do
> you prevent readers from seeing inconsistent results?
Yes right, Will update.
>
>
>> + spin_lock(&rtas_local_data_buf_lock);
>> +
>> + call_status = rtas_call(rtas_token("ibm,get-system-parameter"), 3, 1,
>> + NULL,
>> + PROCESSOR_MODULE_INFO,
>> + __pa(rtas_local_data_buf),
>> + PROCESSOR_MAX_LENGTH);
>> +
>> + spin_unlock(&rtas_local_data_buf_lock);
>
> Using this lock this way fails to provide any protection to the data
> buffer or the phys_* variables.
>
>
>> +
>> + if (call_status != 0) {
>> + pr_info("Error calling get-system-parameter (0x%x)\n",
>> + call_status);
>
> To be robust, this should handle busy (-2) and extended delay (990x)
> statuses. And if it's going to log errors it should use pr_err() and use
> decimal, not hex, to report the RTAS call status, since that's how
> they're specified in PAPR+.
Thanks for pointing it, Will update.
Thanks,
Kajol Jain
^ permalink raw reply
* Re: [PATCH V3 07/15] arch/kunmap_atomic: Consolidate duplicate code
From: Guenter Roeck @ 2020-05-18 4:29 UTC (permalink / raw)
To: Ira Weiny
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200518034938.GA3023182@iweiny-DESK2.sc.intel.com>
On Sun, May 17, 2020 at 08:49:39PM -0700, Ira Weiny wrote:
> On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> > On Thu, May 07, 2020 at 07:59:55AM -0700, ira.weiny@intel.com wrote:
> > > From: Ira Weiny <ira.weiny@intel.com>
> > >
> > > Every single architecture (including !CONFIG_HIGHMEM) calls...
> > >
> > > pagefault_enable();
> > > preempt_enable();
> > >
> > > ... before returning from __kunmap_atomic(). Lift this code into the
> > > kunmap_atomic() macro.
> > >
> > > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> > > be consistent.
> > >
> > > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> >
> > This patch results in:
> >
> > Starting init: /bin/sh exists but couldn't execute it (error -14)
> >
> > when trying to boot microblazeel:petalogix-ml605 in qemu.
>
> Thanks for the report. I'm not readily seeing the issue.
>
> Do you have a kernel config? Specifically is CONFIG_HIGHMEM set?
>
See below. Yes, CONFIG_HIGHMEM is set.
The scripts used to build and boot the image are at:
https://github.com/groeck/linux-build-test/tree/master/rootfs/microblazeel
Hope this helps,
Guenter
---
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_AUDIT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BASE_FULL is not set
CONFIG_KALLSYMS_ALL=y
CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_KERNEL_BASE_ADDR=0x50000000
CONFIG_XILINX_MICROBLAZE0_USE_MSR_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR=1
CONFIG_XILINX_MICROBLAZE0_USE_BARREL=1
CONFIG_XILINX_MICROBLAZE0_USE_DIV=1
CONFIG_XILINX_MICROBLAZE0_USE_HW_MUL=2
CONFIG_XILINX_MICROBLAZE0_USE_FPU=2
CONFIG_XILINX_MICROBLAZE0_HW_VER="10.0.a"
CONFIG_HZ_100=y
CONFIG_MMU=y
CONFIG_HIGHMEM=y
CONFIG_PCI_XILINX=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
# CONFIG_EFI_PARTITION is not set
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IPV6 is not set
CONFIG_BRIDGE=m
CONFIG_PCI=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_NETDEVICES=y
CONFIG_XILINX_EMACLITE=y
CONFIG_XILINX_LL_TEMAC=y
# CONFIG_INPUT is not set
# CONFIG_SERIO is not set
# CONFIG_VT is not set
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_UARTLITE=y
CONFIG_SERIAL_UARTLITE_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_XILINX_HWICAP=y
CONFIG_I2C=y
CONFIG_I2C_XILINX=y
CONFIG_SPI=y
CONFIG_SPI_XILINX=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_XILINX=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
CONFIG_XILINX_WATCHDOG=y
CONFIG_FB=y
CONFIG_FB_XILINX=y
# CONFIG_USB_SUPPORT is not set
CONFIG_UIO=y
CONFIG_UIO_PDRV_GENIRQ=y
CONFIG_UIO_DMEM_GENIRQ=y
CONFIG_EXT2_FS=y
# CONFIG_DNOTIFY is not set
CONFIG_CRAMFS=y
CONFIG_ROMFS_FS=y
CONFIG_NFS_FS=y
CONFIG_CIFS=y
CONFIG_CIFS_STATS2=y
CONFIG_ENCRYPTED_KEYS=y
CONFIG_DEBUG_INFO=y
CONFIG_KGDB=y
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_KDB=y
CONFIG_DEBUG_SLAB=y
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_SPINLOCK=y
^ permalink raw reply
* Re: [PATCH V3 07/15] arch/kunmap_atomic: Consolidate duplicate code
From: Ira Weiny @ 2020-05-18 3:49 UTC (permalink / raw)
To: Guenter Roeck
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200516223306.GA161252@roeck-us.net>
On Sat, May 16, 2020 at 03:33:06PM -0700, Guenter Roeck wrote:
> On Thu, May 07, 2020 at 07:59:55AM -0700, ira.weiny@intel.com wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> >
> > Every single architecture (including !CONFIG_HIGHMEM) calls...
> >
> > pagefault_enable();
> > preempt_enable();
> >
> > ... before returning from __kunmap_atomic(). Lift this code into the
> > kunmap_atomic() macro.
> >
> > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to
> > be consistent.
> >
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > Signed-off-by: Ira Weiny <ira.weiny@intel.com>
>
> This patch results in:
>
> Starting init: /bin/sh exists but couldn't execute it (error -14)
>
> when trying to boot microblazeel:petalogix-ml605 in qemu.
Thanks for the report. I'm not readily seeing the issue.
Do you have a kernel config? Specifically is CONFIG_HIGHMEM set?
>
> Bisect log attached.
>
> Guenter
>
> ---
> # bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific files for 20200515
> # good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
> git bisect start 'HEAD' 'v5.7-rc5'
> # good: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking branch 'crypto/master'
> git bisect good 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
> # good: [87f6f21783522e6d62127cf33ae5e95f50874beb] Merge remote-tracking branch 'spi/for-next'
> git bisect good 87f6f21783522e6d62127cf33ae5e95f50874beb
> # good: [5c428e8277d5d97c85126387d4e00aa5adde4400] Merge remote-tracking branch 'staging/staging-next'
> git bisect good 5c428e8277d5d97c85126387d4e00aa5adde4400
> # good: [f68de67ed934e7bdef4799fd7777c86f33f14982] Merge remote-tracking branch 'hyperv/hyperv-next'
> git bisect good f68de67ed934e7bdef4799fd7777c86f33f14982
> # bad: [54acd2dc52b069da59639eea0d0c92726f32fb01] mm/memblock: fix a typo in comment "implict"->"implicit"
> git bisect bad 54acd2dc52b069da59639eea0d0c92726f32fb01
> # good: [784a17aa58a529b84f7cc50f351ed4acf3bd11f3] mm: remove the pgprot argument to __vmalloc
> git bisect good 784a17aa58a529b84f7cc50f351ed4acf3bd11f3
> # good: [6cd8137ff37e9a37aee2d2a8889c8beb8eab192f] khugepaged: replace the usage of system(3) in the test
> git bisect good 6cd8137ff37e9a37aee2d2a8889c8beb8eab192f
> # bad: [6987da379826ed01b8a1cf046b67cc8cc10117cc] sparc: remove unnecessary includes
> git bisect bad 6987da379826ed01b8a1cf046b67cc8cc10117cc
> # good: [bc17b545388f64c09e83e367898e28f60277c584] mm/hugetlb: define a generic fallback for is_hugepage_only_range()
> git bisect good bc17b545388f64c09e83e367898e28f60277c584
> # bad: [9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011] arch-kmap_atomic-consolidate-duplicate-code-checkpatch-fixes
> git bisect bad 9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011
> # good: [0941a38ff0790c1004270f952067a5918a4ba32d] arch/kmap: remove redundant arch specific kmaps
> git bisect good 0941a38ff0790c1004270f952067a5918a4ba32d
> # good: [56e635a64c2cbfa815c851af10e0f811e809977b] arch-kunmap-remove-duplicate-kunmap-implementations-fix
> git bisect good 56e635a64c2cbfa815c851af10e0f811e809977b
> # bad: [60f96b2233c790d4f1c49317643051f1670bcb29] arch/kmap_atomic: consolidate duplicate code
> git bisect bad 60f96b2233c790d4f1c49317643051f1670bcb29
> # good: [7b3708dc3bf72a647243064fe7ddf9a76248ddfd] {x86,powerpc,microblaze}/kmap: move preempt disable
> git bisect good 7b3708dc3bf72a647243064fe7ddf9a76248ddfd
> # first bad commit: [60f96b2233c790d4f1c49317643051f1670bcb29] arch/kmap_atomic: consolidate duplicate code
I'm confused by this. This points to an earlier commit being bad?
commit 60f96b2233c790d4f1c49317643051f1670bcb29
Author: Ira Weiny <ira.weiny@intel.com>
Date: Thu May 14 13:39:54 2020 +1000
arch/kmap_atomic: consolidate duplicate code
Every arch has the same code to ensure atomic operations and a check for
!HIGHMEM page.
Remove the duplicate code by defining a core kmap_atomic() which only
calls the arch specific kmap_atomic_high() when the page is high memory.
Link: http://lkml.kernel.org/r/20200507150004.1423069-7-ira.weiny@intel.com
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Christian König <christian.koenig@amd.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Helge Deller <deller@gmx.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Any idea which one it is?
Ira
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Fix early_init_mmu section mismatch
From: Michael Ellerman @ 2020-05-18 2:40 UTC (permalink / raw)
To: Christian Zigotzky, Nicholas Piggin, linuxppc-dev
In-Reply-To: <0f2e656a-fcc4-588c-707d-f05bd8d889df@xenosoft.de>
Christian Zigotzky <chzigotzky@xenosoft.de> writes:
> Hi All,
>
> This patch wasn't included in the PowerPC fixes 5.7-4. Please add it.
It's not an important bug. I'll take the patch for v5.8
cheers
> On 29 April 2020 at 09:02 am, Nicholas Piggin wrote:
>> Christian reports:
>>
>> MODPOST vmlinux.o
>> WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in
>> reference from the function .early_init_mmu() to the function
>> .init.text:.radix__early_init_mmu()
>> The function .early_init_mmu() references
>> the function __init .radix__early_init_mmu().
>> This is often because .early_init_mmu lacks a __init
>> annotation or the annotation of .radix__early_init_mmu is wrong.
>>
>> WARNING: modpost: vmlinux.o(.text.unlikely+0x1ac): Section mismatch in
>> reference from the function .early_init_mmu() to the function
>> .init.text:.hash__early_init_mmu()
>> The function .early_init_mmu() references
>> the function __init .hash__early_init_mmu().
>> This is often because .early_init_mmu lacks a __init
>> annotation or the annotation of .hash__early_init_mmu is wrong.
>>
>> The compiler is uninlining early_init_mmu and not putting it in an init
>> section because there is no annotation. Add it.
>>
>> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/include/asm/book3s/64/mmu.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h b/arch/powerpc/include/asm/book3s/64/mmu.h
>> index bb3deb76c951..3ffe5f967483 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>> @@ -208,7 +208,7 @@ void hash__early_init_devtree(void);
>> void radix__early_init_devtree(void);
>> extern void hash__early_init_mmu(void);
>> extern void radix__early_init_mmu(void);
>> -static inline void early_init_mmu(void)
>> +static inline void __init early_init_mmu(void)
>> {
>> if (radix_enabled())
>> return radix__early_init_mmu();
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau
From: Benjamin Herrenschmidt @ 2020-05-18 0:44 UTC (permalink / raw)
To: Emil Velikov, dri-devel
Cc: linux-fbdev, Antonino Daplas, Bartlomiej Zolnierkiewicz,
Paul Mackerras, linuxppc-dev
In-Reply-To: <20200517220524.4036334-2-emil.l.velikov@gmail.com>
On Sun, 2020-05-17 at 23:05 +0100, Emil Velikov wrote:
> As mentioned in earlier commit, the riva and nvidia fbdev drivers
> have
> seen no love over the years, are short on features and overall below
> par
>
> Users are encouraged to switch to the nouveau drm driver instead.
>
> v2: Split configs to separate patch, enable nouveau (Bartlomiej)
Back when I still had these things to play with (years ago) nouveau
didn't work properly on these ancient machines.
Cheers,
Ben.
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
> ---
> Hi all unless, there are objections I would prefer to merge this via
> the drm tree.
>
> Thanks
> Emil
> ---
> arch/powerpc/configs/g5_defconfig | 10 ++++++++--
> arch/powerpc/configs/pasemi_defconfig | 9 +++++++--
> arch/powerpc/configs/pmac32_defconfig | 9 +++++++--
> arch/powerpc/configs/ppc6xx_defconfig | 10 +++++++---
> 4 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/configs/g5_defconfig
> b/arch/powerpc/configs/g5_defconfig
> index a68c7f3af10e..213472f373b3 100644
> --- a/arch/powerpc/configs/g5_defconfig
> +++ b/arch/powerpc/configs/g5_defconfig
> @@ -124,12 +124,18 @@ CONFIG_RAW_DRIVER=y
> CONFIG_I2C_CHARDEV=y
> CONFIG_AGP=m
> CONFIG_AGP_UNINORTH=m
> +CONFIG_DRM=y
> +CONFIG_DRM_NOUVEAU=m
> +# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
> +CONFIG_NOUVEAU_DEBUG=5
> +CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> +# CONFIG_NOUVEAU_DEBUG_MMU is not set
> +CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> +# CONFIG_DRM_NOUVEAU_SVM is not set
> CONFIG_FB=y
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_FB_OF=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> CONFIG_FB_RADEON=y
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_FRAMEBUFFER_CONSOLE=y
> diff --git a/arch/powerpc/configs/pasemi_defconfig
> b/arch/powerpc/configs/pasemi_defconfig
> index 08b7f4cef243..ccb3ab5e01da 100644
> --- a/arch/powerpc/configs/pasemi_defconfig
> +++ b/arch/powerpc/configs/pasemi_defconfig
> @@ -102,11 +102,16 @@ CONFIG_SENSORS_LM85=y
> CONFIG_SENSORS_LM90=y
> CONFIG_DRM=y
> CONFIG_DRM_RADEON=y
> +CONFIG_DRM_NOUVEAU=m
> +# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
> +CONFIG_NOUVEAU_DEBUG=5
> +CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> +# CONFIG_NOUVEAU_DEBUG_MMU is not set
> +CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> +# CONFIG_DRM_NOUVEAU_SVM is not set
> CONFIG_FIRMWARE_EDID=y
> CONFIG_FB_TILEBLITTING=y
> CONFIG_FB_VGA16=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> CONFIG_FB_RADEON=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> CONFIG_VGACON_SOFT_SCROLLBACK=y
> diff --git a/arch/powerpc/configs/pmac32_defconfig
> b/arch/powerpc/configs/pmac32_defconfig
> index 05e325ca3fbd..f858627385c8 100644
> --- a/arch/powerpc/configs/pmac32_defconfig
> +++ b/arch/powerpc/configs/pmac32_defconfig
> @@ -199,6 +199,13 @@ CONFIG_DRM=m
> CONFIG_DRM_RADEON=m
> CONFIG_DRM_LEGACY=y
> CONFIG_DRM_R128=m
> +CONFIG_DRM_NOUVEAU=m
> +# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
> +CONFIG_NOUVEAU_DEBUG=5
> +CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> +# CONFIG_NOUVEAU_DEBUG_MMU is not set
> +CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> +# CONFIG_DRM_NOUVEAU_SVM is not set
> CONFIG_FB=y
> CONFIG_FB_OF=y
> CONFIG_FB_CONTROL=y
> @@ -206,8 +213,6 @@ CONFIG_FB_PLATINUM=y
> CONFIG_FB_VALKYRIE=y
> CONFIG_FB_CT65550=y
> CONFIG_FB_IMSTT=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> CONFIG_FB_MATROX=y
> CONFIG_FB_MATROX_MILLENIUM=y
> CONFIG_FB_MATROX_MYSTIQUE=y
> diff --git a/arch/powerpc/configs/ppc6xx_defconfig
> b/arch/powerpc/configs/ppc6xx_defconfig
> index feb5d47d8d1e..48421f5007ed 100644
> --- a/arch/powerpc/configs/ppc6xx_defconfig
> +++ b/arch/powerpc/configs/ppc6xx_defconfig
> @@ -738,15 +738,19 @@ CONFIG_DRM_MGA=m
> CONFIG_DRM_SIS=m
> CONFIG_DRM_VIA=m
> CONFIG_DRM_SAVAGE=m
> +CONFIG_DRM_NOUVEAU=m
> +# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
> +CONFIG_NOUVEAU_DEBUG=5
> +CONFIG_NOUVEAU_DEBUG_DEFAULT=3
> +# CONFIG_NOUVEAU_DEBUG_MMU is not set
> +CONFIG_DRM_NOUVEAU_BACKLIGHT=y
> +# CONFIG_DRM_NOUVEAU_SVM is not set
> CONFIG_FB=y
> CONFIG_FB_CIRRUS=m
> CONFIG_FB_OF=y
> CONFIG_FB_PLATINUM=y
> CONFIG_FB_VALKYRIE=y
> CONFIG_FB_CT65550=y
> -CONFIG_FB_NVIDIA=y
> -CONFIG_FB_NVIDIA_I2C=y
> -CONFIG_FB_RIVA=m
> CONFIG_FB_MATROX=y
> CONFIG_FB_MATROX_MILLENIUM=y
> CONFIG_FB_MATROX_MYSTIQUE=y
^ permalink raw reply
* Re: [PATCH v5 2/2] powerpc/rtas: Implement reentrant rtas call
From: Nicholas Piggin @ 2020-05-17 22:52 UTC (permalink / raw)
To: Allison Randal, Thiago Jung Bauermann, Benjamin Herrenschmidt,
Daniel Axtens, Gautham R. Shenoy, Greg Kroah-Hartman,
Anshuman Khandual, Leonardo Bras, Michael Ellerman, Nadav Amit,
Nathan Lynch, Paul Mackerras, Thomas Gleixner
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1589614523.yfijifo1n6.astroid@bobo.none>
Excerpts from Nicholas Piggin's message of May 16, 2020 5:36 pm:
> Excerpts from Leonardo Bras's message of May 16, 2020 3:21 pm:
>> @@ -202,6 +220,7 @@ void __init __nostackprotector initialise_paca(struct paca_struct *new_paca, int
>> /* For now -- if we have threads this will be adjusted later */
>> new_paca->tcd_ptr = &new_paca->tcd;
>> #endif
>> + new_paca->reentrant_args = NULL;
>> }
>>
>> /* Put the paca pointer into r13 and SPRG_PACA */
>> @@ -274,6 +293,7 @@ void __init allocate_paca(int cpu)
>> #ifdef CONFIG_PPC_BOOK3S_64
>> paca->slb_shadow_ptr = new_slb_shadow(cpu, limit);
>> #endif
>> + paca->reentrant_args = new_rtas_args(cpu, limit);
>
> Good, I think tihs should work as you want now. Can you allocate it like
> lppacas? Put it under PSERIES (and in the paca) and check for !HV?
Oh and while there, could you prefix the name with rtas_?
Thanks,
Nick
^ permalink raw reply
* [PATCH v2 2/2] powerpc/configs: replace deprecated riva/nvidia with nouveau
From: Emil Velikov @ 2020-05-17 22:05 UTC (permalink / raw)
To: dri-devel
Cc: linux-fbdev, Antonino Daplas, Bartlomiej Zolnierkiewicz,
emil.l.velikov, Paul Mackerras, linuxppc-dev
In-Reply-To: <20200517220524.4036334-1-emil.l.velikov@gmail.com>
As mentioned in earlier commit, the riva and nvidia fbdev drivers have
seen no love over the years, are short on features and overall below par
Users are encouraged to switch to the nouveau drm driver instead.
v2: Split configs to separate patch, enable nouveau (Bartlomiej)
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
---
Hi all unless, there are objections I would prefer to merge this via
the drm tree.
Thanks
Emil
---
arch/powerpc/configs/g5_defconfig | 10 ++++++++--
arch/powerpc/configs/pasemi_defconfig | 9 +++++++--
arch/powerpc/configs/pmac32_defconfig | 9 +++++++--
arch/powerpc/configs/ppc6xx_defconfig | 10 +++++++---
4 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index a68c7f3af10e..213472f373b3 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -124,12 +124,18 @@ CONFIG_RAW_DRIVER=y
CONFIG_I2C_CHARDEV=y
CONFIG_AGP=m
CONFIG_AGP_UNINORTH=m
+CONFIG_DRM=y
+CONFIG_DRM_NOUVEAU=m
+# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
+CONFIG_NOUVEAU_DEBUG=5
+CONFIG_NOUVEAU_DEBUG_DEFAULT=3
+# CONFIG_NOUVEAU_DEBUG_MMU is not set
+CONFIG_DRM_NOUVEAU_BACKLIGHT=y
+# CONFIG_DRM_NOUVEAU_SVM is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_OF=y
-CONFIG_FB_NVIDIA=y
-CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_RADEON=y
# CONFIG_VGA_CONSOLE is not set
CONFIG_FRAMEBUFFER_CONSOLE=y
diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig
index 08b7f4cef243..ccb3ab5e01da 100644
--- a/arch/powerpc/configs/pasemi_defconfig
+++ b/arch/powerpc/configs/pasemi_defconfig
@@ -102,11 +102,16 @@ CONFIG_SENSORS_LM85=y
CONFIG_SENSORS_LM90=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
+CONFIG_DRM_NOUVEAU=m
+# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
+CONFIG_NOUVEAU_DEBUG=5
+CONFIG_NOUVEAU_DEBUG_DEFAULT=3
+# CONFIG_NOUVEAU_DEBUG_MMU is not set
+CONFIG_DRM_NOUVEAU_BACKLIGHT=y
+# CONFIG_DRM_NOUVEAU_SVM is not set
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_VGA16=y
-CONFIG_FB_NVIDIA=y
-CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_RADEON=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_VGACON_SOFT_SCROLLBACK=y
diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
index 05e325ca3fbd..f858627385c8 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -199,6 +199,13 @@ CONFIG_DRM=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_LEGACY=y
CONFIG_DRM_R128=m
+CONFIG_DRM_NOUVEAU=m
+# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
+CONFIG_NOUVEAU_DEBUG=5
+CONFIG_NOUVEAU_DEBUG_DEFAULT=3
+# CONFIG_NOUVEAU_DEBUG_MMU is not set
+CONFIG_DRM_NOUVEAU_BACKLIGHT=y
+# CONFIG_DRM_NOUVEAU_SVM is not set
CONFIG_FB=y
CONFIG_FB_OF=y
CONFIG_FB_CONTROL=y
@@ -206,8 +213,6 @@ CONFIG_FB_PLATINUM=y
CONFIG_FB_VALKYRIE=y
CONFIG_FB_CT65550=y
CONFIG_FB_IMSTT=y
-CONFIG_FB_NVIDIA=y
-CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index feb5d47d8d1e..48421f5007ed 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -738,15 +738,19 @@ CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
+CONFIG_DRM_NOUVEAU=m
+# CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set
+CONFIG_NOUVEAU_DEBUG=5
+CONFIG_NOUVEAU_DEBUG_DEFAULT=3
+# CONFIG_NOUVEAU_DEBUG_MMU is not set
+CONFIG_DRM_NOUVEAU_BACKLIGHT=y
+# CONFIG_DRM_NOUVEAU_SVM is not set
CONFIG_FB=y
CONFIG_FB_CIRRUS=m
CONFIG_FB_OF=y
CONFIG_FB_PLATINUM=y
CONFIG_FB_VALKYRIE=y
CONFIG_FB_CT65550=y
-CONFIG_FB_NVIDIA=y
-CONFIG_FB_NVIDIA_I2C=y
-CONFIG_FB_RIVA=m
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
--
2.25.1
^ permalink raw reply related
* Re: [PATCH V3 10/15] arch/kmap: Define kmap_atomic_prot() for all arch's
From: Guenter Roeck @ 2020-05-17 17:37 UTC (permalink / raw)
To: ira.weiny
Cc: Peter Zijlstra, Dave Hansen, dri-devel, linux-mips,
James E.J. Bottomley, Max Filippov, Paul Mackerras,
H. Peter Anvin, sparclinux, Dan Williams, Helge Deller, x86,
linux-csky, Christoph Hellwig, Ingo Molnar, linux-snps-arc,
linux-xtensa, Borislav Petkov, Al Viro, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Chris Zankel,
Thomas Bogendoerfer, linux-parisc, linux-kernel, Christian Koenig,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200507150004.1423069-11-ira.weiny@intel.com>
Hi,
On Thu, May 07, 2020 at 07:59:58AM -0700, ira.weiny@intel.com wrote:
> From: Ira Weiny <ira.weiny@intel.com>
>
> To support kmap_atomic_prot(), all architectures need to support
> protections passed to their kmap_atomic_high() function. Pass
> protections into kmap_atomic_high() and change the name to
> kmap_atomic_high_prot() to match.
>
> Then define kmap_atomic_prot() as a core function which calls
> kmap_atomic_high_prot() when needed.
>
> Finally, redefine kmap_atomic() as a wrapper of kmap_atomic_prot() with
> the default kmap_prot exported by the architectures.
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
This patch causes a variety of crashes whem booting powerpc images in qemu.
There are lots of warnings such as:
WARNING: CPU: 0 PID: 0 at lib/locking-selftest.c:743 irqsafe1_hard_spin_12+0x50/0xb0
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Tainted: G W 5.7.0-rc5-next-20200515 #1
NIP: c0660c7c LR: c0660c44 CTR: c0660c2c
REGS: c1223e68 TRAP: 0700 Tainted: G W (5.7.0-rc5-next-20200515)
MSR: 00021000 <CE,ME> CR: 28000224 XER: 20000000
GPR00: c0669c78 c1223f20 c113d560 c0660c44 00000000 00000001 c1223ea8 00000001
GPR08: 00000000 00000001 0000fffc ffffffff 88000222 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 c0000000 00000000 00000000 c1125084
GPR24: c1125084 c1230000 c1879538 fffffffc 00000001 00000000 c1011afc c1230000
NIP [c0660c7c] irqsafe1_hard_spin_12+0x50/0xb0
LR [c0660c44] irqsafe1_hard_spin_12+0x18/0xb0
Call Trace:
[c1223f20] [c1880000] megasas_mgmt_info+0xee4/0x1008 (unreliable)
[c1223f40] [c0669c78] dotest+0x38/0x550
[c1223f70] [c066aa4c] locking_selftest+0x8bc/0x1d54
[c1223fa0] [c10e0bc8] start_kernel+0x3ec/0x510
[c1223ff0] [c00003a0] set_ivor+0x118/0x154
Instruction dump:
81420000 38e80001 3d4a0001 2c080000 91420000 90e20488 40820008 91020470
81290000 5529031e 7d290034 5529d97e <0f090000> 3fe0c11c 3bff3964 3bff00ac
irq event stamp: 588
hardirqs last enabled at (587): [<c00b9fe4>] vprintk_emit+0x1b4/0x33c
hardirqs last disabled at (588): [<c0660c44>] irqsafe1_hard_spin_12+0x18/0xb0
softirqs last enabled at (0): [<00000000>] 0x0
softirqs last disabled at (0): [<00000000>] 0x0
---[ end trace b18fe9e172f99d03 ]---
This is followed by:
BUG: sleeping function called from invalid context at lib/mpi/mpi-pow.c:245
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: cryptomgr_test
INFO: lockdep is turned off.
CPU: 0 PID: 14 Comm: cryptomgr_test Tainted: G W 5.7.0-rc5-next-20200515 #1
Call Trace:
[ce221b58] [c008755c] ___might_sleep+0x280/0x2a8 (unreliable)
[ce221b78] [c06bc524] mpi_powm+0x634/0xc50
[ce221c38] [c05eafdc] rsa_dec+0x88/0x134
[ce221c78] [c05f3b40] test_akcipher_one+0x678/0x804
[ce221dc8] [c05f3d7c] alg_test_akcipher+0xb0/0x130
[ce221df8] [c05ee674] alg_test.part.0+0xb4/0x458
[ce221ed8] [c05ed2b0] cryptomgr_test+0x30/0x50
[ce221ef8] [c007cd74] kthread+0x134/0x170
[ce221f38] [c001433c] ret_from_kernel_thread+0x14/0x1c
Kernel panic - not syncing: Aiee, killing interrupt handler!
CPU: 0 PID: 14 Comm: cryptomgr_test Tainted: G W 5.7.0-rc5-next-20200515 #1
Call Trace:
[ce221e08] [c00530fc] panic+0x148/0x34c (unreliable)
[ce221e68] [c0056460] do_exit+0xac0/0xb40
[ce221eb8] [c00f5be8] find_kallsyms_symbol_value+0x0/0x128
[ce221ed8] [c05ed2d0] crypto_alg_put+0x0/0x70
[ce221ef8] [c007cd74] kthread+0x134/0x170
[ce221f38] [c001433c] ret_from_kernel_thread+0x14/0x1c
Bisect log is attached. The patch can not easily be reverted since
it results in compile errors.
Note that similar failures are seen with sparc32 images. Those bisect
to a different patch, but reverting that patch doesn't fix the problem.
The failure pattern (warnings followed by a crash in cryptomgr_test)
is the same.
Guenter
---
# bad: [bdecf38f228bcca73b31ada98b5b7ba1215eb9c9] Add linux-next specific files for 20200515
# good: [2ef96a5bb12be62ef75b5828c0aab838ebb29cb8] Linux 5.7-rc5
git bisect start 'HEAD' 'v5.7-rc5'
# good: [3674d7aa7a8e61d993886c2fb7c896c5ef85e988] Merge remote-tracking branch 'crypto/master'
git bisect good 3674d7aa7a8e61d993886c2fb7c896c5ef85e988
# good: [87f6f21783522e6d62127cf33ae5e95f50874beb] Merge remote-tracking branch 'spi/for-next'
git bisect good 87f6f21783522e6d62127cf33ae5e95f50874beb
# good: [5c428e8277d5d97c85126387d4e00aa5adde4400] Merge remote-tracking branch 'staging/staging-next'
git bisect good 5c428e8277d5d97c85126387d4e00aa5adde4400
# good: [f68de67ed934e7bdef4799fd7777c86f33f14982] Merge remote-tracking branch 'hyperv/hyperv-next'
git bisect good f68de67ed934e7bdef4799fd7777c86f33f14982
# bad: [54acd2dc52b069da59639eea0d0c92726f32fb01] mm/memblock: fix a typo in comment "implict"->"implicit"
git bisect bad 54acd2dc52b069da59639eea0d0c92726f32fb01
# good: [784a17aa58a529b84f7cc50f351ed4acf3bd11f3] mm: remove the pgprot argument to __vmalloc
git bisect good 784a17aa58a529b84f7cc50f351ed4acf3bd11f3
# good: [6cd8137ff37e9a37aee2d2a8889c8beb8eab192f] khugepaged: replace the usage of system(3) in the test
git bisect good 6cd8137ff37e9a37aee2d2a8889c8beb8eab192f
# bad: [6987da379826ed01b8a1cf046b67cc8cc10117cc] sparc: remove unnecessary includes
git bisect bad 6987da379826ed01b8a1cf046b67cc8cc10117cc
# good: [bc17b545388f64c09e83e367898e28f60277c584] mm/hugetlb: define a generic fallback for is_hugepage_only_range()
git bisect good bc17b545388f64c09e83e367898e28f60277c584
# good: [9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011] arch-kmap_atomic-consolidate-duplicate-code-checkpatch-fixes
git bisect good 9b5aa5b43f957f03a1f4a9aff5f7924e2ebbc011
# bad: [89194ba5ee31567eeee9c81101b334c8e3248198] arch/kmap: define kmap_atomic_prot() for all arch's
git bisect bad 89194ba5ee31567eeee9c81101b334c8e3248198
# good: [022785d2bea99f8bc2a37b7b6c525eea26f6ac59] arch-kunmap_atomic-consolidate-duplicate-code-checkpatch-fixes
git bisect good 022785d2bea99f8bc2a37b7b6c525eea26f6ac59
# good: [a13c2f39e3f0519ddee57d26cc66ec70e3546106] arch/kmap: don't hard code kmap_prot values
git bisect good a13c2f39e3f0519ddee57d26cc66ec70e3546106
# first bad commit: [89194ba5ee31567eeee9c81101b334c8e3248198] arch/kmap: define kmap_atomic_prot() for all arch's
^ 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