* [PATCH 10/16] pinctrl: armada-37xx: use new match_string() helper/macro
From: Alexandru Ardelean @ 2019-05-08 11:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-ide, linux-clk,
linux-rpi-kernel, linux-arm-kernel, linux-rockchip, linux-pm,
linux-gpio, dri-devel, intel-gfx, linux-omap, linux-mmc,
linux-wireless, netdev, linux-pci, linux-tegra, devel, linux-usb,
kvm, linux-fbdev, linux-mtd, cgroups, linux-mm,
linux-security-module, linux-integrity, alsa-devel
Cc: gregkh, Alexandru Ardelean, andriy.shevchenko
In-Reply-To: <20190508112842.11654-1-alexandru.ardelean@analog.com>
The change is mostly cosmetic.
The `armada_37xx_pin_group` struct is defined as.
struct armada_37xx_pin_group {
const char *name;
unsigned int start_pin;
unsigned int npins;
u32 reg_mask;
u32 val[NB_FUNCS];
unsigned int extra_pin;
unsigned int extra_npins;
const char *funcs[NB_FUNCS];
unsigned int *pins;
};
The `funcs` field is a static array of strings, so using the
new `match_string()` helper (which does an implicit ARRAY_SIZE(gp->funcs))
should be fine.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index 07a5bcaa0067..68b0db5ef5e9 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -348,7 +348,7 @@ static int armada_37xx_pmx_set_by_name(struct pinctrl_dev *pctldev,
dev_dbg(info->dev, "enable function %s group %s\n",
name, grp->name);
- func = __match_string(grp->funcs, NB_FUNCS, name);
+ func = match_string(grp->funcs, name);
if (func < 0)
return -ENOTSUPP;
@@ -938,7 +938,7 @@ static int armada_37xx_fill_func(struct armada_37xx_pinctrl *info)
struct armada_37xx_pin_group *gp = &info->groups[g];
int f;
- f = __match_string(gp->funcs, NB_FUNCS, name);
+ f = match_string(gp->funcs, name);
if (f < 0)
continue;
--
2.17.1
^ permalink raw reply related
* [PATCH 11/16] mm/vmpressure.c: use new match_string() helper/macro
From: Alexandru Ardelean @ 2019-05-08 11:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-ide, linux-clk,
linux-rpi-kernel, linux-arm-kernel, linux-rockchip, linux-pm,
linux-gpio, dri-devel, intel-gfx, linux-omap, linux-mmc,
linux-wireless, netdev, linux-pci, linux-tegra, devel, linux-usb,
kvm, linux-fbdev, linux-mtd, cgroups, linux-mm,
linux-security-module, linux-integrity, alsa-devel
Cc: gregkh, Alexandru Ardelean, andriy.shevchenko
In-Reply-To: <20190508112842.11654-1-alexandru.ardelean@analog.com>
__match_string() is called on 2 static array of strings in this file. For
this reason, the conversion to the new match_string() macro/helper, was
done in this separate commit.
Using the new match_string() helper is mostly a cosmetic change (at this
point in time). The sizes of the arrays will be computed automatically,
which would only help if they ever get expanded.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
mm/vmpressure.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmpressure.c b/mm/vmpressure.c
index d43f33139568..b8149924f078 100644
--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -378,7 +378,7 @@ int vmpressure_register_event(struct mem_cgroup *memcg,
/* Find required level */
token = strsep(&spec, ",");
- level = __match_string(vmpressure_str_levels, VMPRESSURE_NUM_LEVELS, token);
+ level = match_string(vmpressure_str_levels, token);
if (level < 0) {
ret = level;
goto out;
@@ -387,7 +387,7 @@ int vmpressure_register_event(struct mem_cgroup *memcg,
/* Find optional mode */
token = strsep(&spec, ",");
if (token) {
- mode = __match_string(vmpressure_str_modes, VMPRESSURE_NUM_MODES, token);
+ mode = match_string(vmpressure_str_modes, token);
if (mode < 0) {
ret = mode;
goto out;
--
2.17.1
^ permalink raw reply related
* [PATCH 12/16] rdmacg: use new match_string() helper/macro
From: Alexandru Ardelean @ 2019-05-08 11:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-ide, linux-clk,
linux-rpi-kernel, linux-arm-kernel, linux-rockchip, linux-pm,
linux-gpio, dri-devel, intel-gfx, linux-omap, linux-mmc,
linux-wireless, netdev, linux-pci, linux-tegra, devel, linux-usb,
kvm, linux-fbdev, linux-mtd, cgroups, linux-mm,
linux-security-module, linux-integrity, alsa-devel
Cc: gregkh, Alexandru Ardelean, andriy.shevchenko
In-Reply-To: <20190508112842.11654-1-alexandru.ardelean@analog.com>
The `rdmacg_resource_names` array is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.
The change is mostly cosmetic.
No functionality change.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
kernel/cgroup/rdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup/rdma.c b/kernel/cgroup/rdma.c
index 65d4df148603..71c3d305bd1f 100644
--- a/kernel/cgroup/rdma.c
+++ b/kernel/cgroup/rdma.c
@@ -367,7 +367,7 @@ static int parse_resource(char *c, int *intval)
if (!name || !value)
return -EINVAL;
- i = __match_string(rdmacg_resource_names, RDMACG_RESOURCE_MAX, name);
+ i = match_string(rdmacg_resource_names, name);
if (i < 0)
return i;
--
2.17.1
^ permalink raw reply related
* [PATCH 13/16] drm/edid: use new match_string() helper/macro
From: Alexandru Ardelean @ 2019-05-08 11:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-ide, linux-clk,
linux-rpi-kernel, linux-arm-kernel, linux-rockchip, linux-pm,
linux-gpio, dri-devel, intel-gfx, linux-omap, linux-mmc,
linux-wireless, netdev, linux-pci, linux-tegra, devel, linux-usb,
kvm, linux-fbdev, linux-mtd, cgroups, linux-mm,
linux-security-module, linux-integrity, alsa-devel
Cc: gregkh, Alexandru Ardelean, andriy.shevchenko
In-Reply-To: <20190508112842.11654-1-alexandru.ardelean@analog.com>
The `generic_edid_name` is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.
The change is mostly cosmetic.
No functionality change.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/gpu/drm/drm_edid_load.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 1450051972ea..66e1e325ff37 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -186,7 +186,7 @@ static void *edid_load(struct drm_connector *connector, const char *name,
int i, valid_extensions = 0;
bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & DRM_UT_KMS);
- builtin = __match_string(generic_edid_name, GENERIC_EDIDS, name);
+ builtin = match_string(generic_edid_name, name);
if (builtin >= 0) {
fwdata = generic_edid[builtin];
fwsize = sizeof(generic_edid[builtin]);
--
2.17.1
^ permalink raw reply related
* [PATCH 14/16] staging: gdm724x: use new match_string() helper/macro
From: Alexandru Ardelean @ 2019-05-08 11:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-ide, linux-clk,
linux-rpi-kernel, linux-arm-kernel, linux-rockchip, linux-pm,
linux-gpio, dri-devel, intel-gfx, linux-omap, linux-mmc,
linux-wireless, netdev, linux-pci, linux-tegra, devel, linux-usb,
kvm, linux-fbdev, linux-mtd, cgroups, linux-mm,
linux-security-module, linux-integrity, alsa-devel
Cc: gregkh, Alexandru Ardelean, andriy.shevchenko
In-Reply-To: <20190508112842.11654-1-alexandru.ardelean@analog.com>
The `DRIVER_STRING` array is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.
The change is mostly cosmetic.
No functionality change.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/staging/gdm724x/gdm_tty.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_tty.c b/drivers/staging/gdm724x/gdm_tty.c
index 6e147a324652..81dd6795599f 100644
--- a/drivers/staging/gdm724x/gdm_tty.c
+++ b/drivers/staging/gdm724x/gdm_tty.c
@@ -56,8 +56,7 @@ static int gdm_tty_install(struct tty_driver *driver, struct tty_struct *tty)
struct gdm *gdm = NULL;
int ret;
- ret = __match_string(DRIVER_STRING, TTY_MAX_COUNT,
- tty->driver->driver_name);
+ ret = match_string(DRIVER_STRING, tty->driver->driver_name);
if (ret < 0)
return -ENODEV;
--
2.17.1
^ permalink raw reply related
* [PATCH 16/16] sched: debug: use new match_string() helper/macro
From: Alexandru Ardelean @ 2019-05-08 11:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-ide, linux-clk,
linux-rpi-kernel, linux-arm-kernel, linux-rockchip, linux-pm,
linux-gpio, dri-devel, intel-gfx, linux-omap, linux-mmc,
linux-wireless, netdev, linux-pci, linux-tegra, devel, linux-usb,
kvm, linux-fbdev, linux-mtd, cgroups, linux-mm,
linux-security-module, linux-integrity, alsa-devel
Cc: gregkh, Alexandru Ardelean, andriy.shevchenko
In-Reply-To: <20190508112842.11654-1-alexandru.ardelean@analog.com>
The `sched_feat_names` array is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.
The change is mostly cosmetic.
No functionality change.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
kernel/sched/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index b0efc5fe641e..6d5f370bdfde 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -111,7 +111,7 @@ static int sched_feat_set(char *cmp)
cmp += 3;
}
- i = __match_string(sched_feat_names, __SCHED_FEAT_NR, cmp);
+ i = match_string(sched_feat_names, cmp);
if (i < 0)
return i;
--
2.17.1
^ permalink raw reply related
* [PATCH 15/16] video: fbdev: pxafb: use new match_string() helper/macro
From: Alexandru Ardelean @ 2019-05-08 11:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-ide, linux-clk,
linux-rpi-kernel, linux-arm-kernel, linux-rockchip, linux-pm,
linux-gpio, dri-devel, intel-gfx, linux-omap, linux-mmc,
linux-wireless, netdev, linux-pci, linux-tegra, devel, linux-usb,
kvm, linux-fbdev, linux-mtd, cgroups, linux-mm,
linux-security-module, linux-integrity, alsa-devel
Cc: gregkh, Alexandru Ardelean, andriy.shevchenko
In-Reply-To: <20190508112842.11654-1-alexandru.ardelean@analog.com>
The `lcd_types` array is a static array of strings.
Using match_string() (which computes the array size via ARRAY_SIZE())
is possible.
This reduces the array by 1 element, since the NULL (at the end of the
array) is no longer needed.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
drivers/video/fbdev/pxafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 0025781e6e1e..e657a04f5b1d 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2114,7 +2114,7 @@ static void pxafb_check_options(struct device *dev, struct pxafb_mach_info *inf)
#if defined(CONFIG_OF)
static const char * const lcd_types[] = {
"unknown", "mono-stn", "mono-dstn", "color-stn", "color-dstn",
- "color-tft", "smart-panel", NULL
+ "color-tft", "smart-panel"
};
static int of_get_pxafb_display(struct device *dev, struct device_node *disp,
@@ -2129,7 +2129,7 @@ static int of_get_pxafb_display(struct device *dev, struct device_node *disp,
if (ret)
s = "color-tft";
- i = __match_string(lcd_types, -1, s);
+ i = match_string(lcd_types, s);
if (i < 0) {
dev_err(dev, "lcd-type %s is unknown\n", s);
return i;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 01/16] lib: fix match_string() helper on -1 array size
From: Ardelean, Alexandru @ 2019-05-08 11:31 UTC (permalink / raw)
To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org, linux-usb@vger.kernel.org,
linux-mmc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
cgroups@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-pm@vger.kernel.org, linux-mm@kvack.org,
linux-omap@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-security-module@vger.kernel.org, devel@driverdev.osuosl.org,
linux-integrity@vger.kernel.org, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org,
linux-clk@vger.kernel.org, linux-pci@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-tegra@vger.kernel.org
Cc: gregkh@linuxfoundation.org, andriy.shevchenko@linux.intel.com
In-Reply-To: <20190508112842.11654-2-alexandru.ardelean@analog.com>
On Wed, 2019-05-08 at 14:28 +0300, Alexandru Ardelean wrote:
> The documentation the `_match_string()` helper mentions that `n`
> should be:
> * @n: number of strings in the array or -1 for NULL terminated arrays
>
> The behavior of the function is different, in the sense that it exits on
> the first NULL element in the array, regardless of whether `n` is -1 or a
> positive number.
>
> This patch changes the behavior, to exit the loop when a NULL element is
> found and n == -1. Essentially, this aligns the behavior with the
> doc-string.
>
> There are currently many users of `match_string()`, and so, in order to
> go
> through them, the next patches in the series will focus on doing some
> cosmetic changes, which are aimed at grouping the users of
> `match_string()`.
>
This is the duplicate & should be dropped.
Sorry for this.
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> lib/string.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/string.c b/lib/string.c
> index 3ab861c1a857..76edb7bf76cb 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -648,8 +648,11 @@ int match_string(const char * const *array, size_t
> n, const char *string)
>
> for (index = 0; index < n; index++) {
> item = array[index];
> - if (!item)
> + if (!item) {
> + if (n != (size_t)-1)
> + continue;
> break;
> + }
> if (!strcmp(item, string))
> return index;
> }
^ permalink raw reply
* Re: [PATCH 03/16] lib,treewide: add new match_string() helper/macro
From: Ardelean, Alexandru @ 2019-05-08 13:22 UTC (permalink / raw)
To: andriy.shevchenko@linux.intel.com, gregkh@linuxfoundation.org
Cc: linux-wireless@vger.kernel.org, linux-fbdev@vger.kernel.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org,
alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, linux-mtd@lists.infradead.org,
linux-clk@vger.kernel.org, devel@driverdev.osuosl.org,
linux-rockchip@lists.infradead.org, linux-pm@vger.kernel.org,
intel-gfx@lists.freedesktop.org, linux-gpio@vger.kernel.org,
linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
cgroups@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-ide@vger.kernel.org,
netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190508131856.GB10138@kroah.com>
On Wed, 2019-05-08 at 15:18 +0200, Greg KH wrote:
>
>
> On Wed, May 08, 2019 at 04:11:28PM +0300, Andy Shevchenko wrote:
> > On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean wrote:
> > > This change re-introduces `match_string()` as a macro that uses
> > > ARRAY_SIZE() to compute the size of the array.
> > > The macro is added in all the places that do
> > > `match_string(_a, ARRAY_SIZE(_a), s)`, since the change is pretty
> > > straightforward.
> >
> > Can you split include/linux/ change from the rest?
>
> That would break the build, why do you want it split out? This makes
> sense all as a single patch to me.
>
Not really.
It would be just be the new match_string() helper/macro in a new commit.
And the conversions of the simple users of match_string() (the ones using
ARRAY_SIZE()) in another commit.
Thanks
Alex
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 09/16] mmc: sdhci-xenon: use new match_string() helper/macro
From: Ardelean, Alexandru @ 2019-05-08 13:26 UTC (permalink / raw)
To: dan.carpenter@oracle.com
Cc: linux-wireless@vger.kernel.org, linux-fbdev@vger.kernel.org,
kvm@vger.kernel.org, linux-pci@vger.kernel.org,
alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, linux-mtd@lists.infradead.org,
linux-clk@vger.kernel.org, devel@driverdev.osuosl.org,
andriy.shevchenko@linux.intel.com,
linux-rockchip@lists.infradead.org, linux-pm@vger.kernel.org,
intel-gfx@lists.freedesktop.org, linux-gpio@vger.kernel.org,
linux-rpi-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
cgroups@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-ide@vger.kernel.org,
gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, netdev@vger.kernel.org,
linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190508122010.GC21059@kadam>
On Wed, 2019-05-08 at 15:20 +0300, Dan Carpenter wrote:
>
>
> On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
> > -static const char * const phy_types[] = {
> > - "emmc 5.0 phy",
> > - "emmc 5.1 phy"
> > -};
> > -
> > enum xenon_phy_type_enum {
> > EMMC_5_0_PHY,
> > EMMC_5_1_PHY,
> > NR_PHY_TYPES
>
> There is no need for NR_PHY_TYPES now so you could remove that as well.
>
I thought the same.
The only reason to keep NR_PHY_TYPES, is for potential future patches,
where it would be just 1 addition
enum xenon_phy_type_enum {
EMMC_5_0_PHY,
EMMC_5_1_PHY,
+ EMMC_5_2_PHY,
NR_PHY_TYPES
}
Depending on style/preference of how to do enums (allow comma on last enum
or not allow comma on last enum value), adding new enum values woudl be 2
additions + 1 deletion lines.
enum xenon_phy_type_enum {
EMMC_5_0_PHY,
- EMMC_5_1_PHY
+ EMM
C_5_1_PHY,
+ EMMC_5_2_PHY
}
Either way (leave NR_PHY_TYPES or remove NR_PHY_TYPES) is fine from my
side.
Thanks
Alex
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [EXT] Re: [PATCH v1] timer:clock:ptp: add support the dynamic posix clock alarm set for ptp
From: Richard Cochran @ 2019-05-08 17:06 UTC (permalink / raw)
To: Po Liu
Cc: Roy Zang, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Leo Li, Claudiu Manoil, Mingkai Hu, Y.b. Lu,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
linux-arm-kernel@lists.infradead.org, deepa.kernel@gmail.com
In-Reply-To: <20190508143654.uj7266kcbhf744c3@localhost>
On Wed, May 08, 2019 at 07:36:54AM -0700, Richard Cochran wrote:
> No the alarm functionality has been removed. It will not be coming
> back, unless there are really strong arguments to support it.
Here is some more background:
commit 3a06c7ac24f9f24ec059cd77c2dbdf7fbfd0aaaf
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue May 30 23:15:38 2017 +0200
posix-clocks: Remove interval timer facility and mmap/fasync callbacks
The only user of this facility is ptp_clock, which does not implement any of
those functions.
Remove them to prevent accidental users. Especially the interval timer
interfaces are now more or less impossible to implement because the
necessary infrastructure has been confined to the core code. Aside of that
it's really complex to make these callbacks implemented according to spec
as the alarm timer implementation demonstrates. If at all then a nanosleep
callback might be a reasonable extension. For now keep just what ptp_clock
needs.
> Here is the result of a study of a prototype alarm method. It shows
> why the hrtimer method is better.
>
> https://sourceforge.net/p/linuxptp/mailman/message/35535965/
That test was with a PCIe card. With a SoC that has a PHC as a built
in peripheral, the hardware solution might outperform hrtimers.
So you might consider adding clock_nanosleep() for dynamic posix
clocks. But your code will have to support multiple users at the same
time.
Thanks,
Richard
^ permalink raw reply
* Re: IPIC_SERMR vs IPIC_SERMR
From: christophe leroy @ 2019-05-08 17:17 UTC (permalink / raw)
To: Rodriguez Quesada, Pablo, linuxppc-dev@lists.ozlabs.org
Cc: Ramirez Rojas, Luis Daniel (Daniel)
In-Reply-To: <0CDD4071D6ACF54ABB9CF1A6D90375A809BAF4E4@ALA-MBD.corp.ad.wrs.com>
Hi Pablo,
Le 07/05/2019 à 23:50, Rodriguez Quesada, Pablo a écrit :
> Hi, Christophe and everyone from the LinuxPPC community,
>
> Hope you are doing well!
>
> I was working with Daniel, and we were reviewing the ipic source code
> and came to these questions:
>
> 1.The first one came up while reviewing the document “Understanding
> IPIC” from NXP (*). The document states that:
>
> /System Error Status Register (SERSR) – 0x40: Each bit in the SERSR
> register corresponds to a non-maskable error source that generates a
> machine check exception (MCP). These bits are cleared by writing the bit
> location with a logic 1./
>
> /The interrupting source must be cleared before clearing the interrupts
> error status bit./
>
> /System Error Mask Register (SERMR) – 0x44 When a machine check
> exception is signaled from one of the peripheral modules, its
> corresponding flag bit in this register is set. Any of the interrupting
> sources can be individually masked./
I guess the above description is misleading.
In the MPC8323 Reference Manual, I find it more explicit:
8.5.14 System Error Mask Register (SERMR)
Each implemented bit in SERMR, shown in Figure 8-16, corresponds to an
external and an internal mcp source (MCP). The user masks an MCP by
clearing and enables an interrupt by setting the corresponding SERMR
bit. When a masked MCP occurs, the corresponding SERSR bit is set,
regardless of the setting of the corresponding SERMR bit although no MCP
request is passed to the core in this case. The SERMR can be read by the
user at any time.
>
> //
>
> We noticed that you changed the ipic_clear_mcp_status function by
> swapping SERMR to SERSR, but we don’t fully understand why. Could you
> please elaborate on why this change is made? This because we had a code
> that was working before the patch and we would fully understand why it
> stopped working. From our perspective, both SERSR and SERMR are related
> to MCEs and honestly don’t know what’s the difference at the hardware
> level, and the role of every register on the machine check flow. It is
> also weird for us that before your patch the register SERSR wasn’t used
> in any part of the Linux kernel.
I suppose you are referring to the patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/powerpc/sysdev/ipic.c?h=v5.1&id=6b148a7ce72a7f87c81cbcde48af014abc0516a9
For me the role of a function called ipic_clear_mcp_status() is ... to
clear the status, not to manipulate a mask. So it has to deal with the
status register (SERSR) and has nothing to do with the mask register
(SERMR).
>
> 2.In commit 8acb88682cc00a41a677c2455a7c992d you removed
> ipic_set_highest_priority(), ipic_enable_mcp() and
> ipic_disable_mcp()because it wasn’t used but here we are confused
> because ipic_clear_mcp_status() sets all bits with the mask and in the
> old disable function the bits from the mask are cleared with a bitwise
> AND,changing the other bits from the SERMR register but the mcp_irq.
Probably the parameter of ipic_clear_mcp_status() should not be called
'mask'. This parameter identifies the sources to clear. The bits set to
1 corresponds to the sources to clear. The bits set to 0 corresponds to
the sources we don't want to touch.
ipic_enable_mcp() and ipic_disable_mcp() had a different role, their
role was to activate or deactivate interrupts generated by MCP sources
iaw the description of SERMR.
>
> ipic_clear:
>
> ipic_write
> <https://elixir.bootlin.com/linux/v4.1.13/ident/ipic_write>(primary_ipic
> <https://elixir.bootlin.com/linux/v4.1.13/ident/primary_ipic>->regs,
> IPIC_SERMR <https://elixir.bootlin.com/linux/v4.1.13/ident/IPIC_SERMR>,
> mask);
>
> ipic_disable:
>
> temp <https://elixir.bootlin.com/linux/v4.1.13/ident/temp> = ipic_read
> <https://elixir.bootlin.com/linux/v4.1.13/ident/ipic_read>(ipic
> <https://elixir.bootlin.com/linux/v4.1.13/ident/ipic>->regs, IPIC_SERMR
> <https://elixir.bootlin.com/linux/v4.1.13/ident/IPIC_SERMR>);
>
> temp <https://elixir.bootlin.com/linux/v4.1.13/ident/temp> &= (1 << (31
> - mcp_irq));
>
> ipic_write
> <https://elixir.bootlin.com/linux/v4.1.13/ident/ipic_write>(ipic
> <https://elixir.bootlin.com/linux/v4.1.13/ident/ipic>->regs, IPIC_SERMR
> <https://elixir.bootlin.com/linux/v4.1.13/ident/IPIC_SERMR>, temp
> <https://elixir.bootlin.com/linux/v4.1.13/ident/temp>);
>
> Isn’t ipic_clear a set function instead of a clear
> function? This bring us confusion
No, ipic_clear() role is to clear the status in accordance with the
description of SERSR. In the description you copied, it is explicitely
said: "These bits are cleared by writing the bit location with a logic 1".
In the MPC8323 Reference Manual, it is even more explicit:
Each implemented bit in the SERSR, listed in Table 8-22, corresponds to
an external and an internal error source (mcp). When an error interrupt
signal is received, the interrupt controller sets the corresponding
SERSR bit. SERSR bits are cleared by writing ones to them. Unmasked
event register bits should be cleared before clearing SERSR bits.
Because the user can only clear bits in this register, writing zeros to
this register has no effect.
>
> Another question is why these functions were created in the first place?
I guess someone wanted to create a full API to the IPIC, but it was
never used, or it was used by out-of-tree drivers or was used before the
kernel was it GIT.
>
> 3.In the NXP document it states that: /These bits are cleared by writing
> the bit location with a logic 1. The interrupting source must be cleared
> before clearing the interrupts error status bit./
>
> Does this mean that these registers work with negative logic? How is
> this managed in the kernel?
>
> The interrupting source is the SERMR register, the SERSR or any other?
>
> 4.What is the real difference between MCP and MCE? What are their uses?
MCE means Machine Check Exception
A machine check exception can be generated for several reasons, not only
MCP. For instead a TEA will also generate a MCE.
Iaw MPC8323 Reference Manual:
MCP = Machine-check interrupt
In table 7.7:
Machine check 00200 Caused by the assertion of the tea signal during a
data bus transaction, assertion of mcp, an address or data parity error,
or an instruction or data cache parity error. Note that the e300 has
SRR1 register values that are different from the G2/G2_LE cores’ when a
machine check occurs
In §8.1:
The machine check exception is caused by the internal mcp signal
generated by the IPIC, informing the host processor of error conditions,
assertion of the external IRQ0 machine-check request (enabled when
SEMSR[SIRQ0] = 1), and other conditions.
>
> I know it is a lot of information but we are very confused about the use
> of these registers and we noticed that you are very involved on the PPC
> development. So we would like to hear from an expert.
>
> Thank you very much for your time,
You are welcome
Christophe
>
> Pablo
>
> (*) https://www.nxp.com/docs/en/application-note/AN3797.pdf
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Build failure in v4.4.y.queue (ppc:allmodconfig)
From: Guenter Roeck @ 2019-05-08 20:26 UTC (permalink / raw)
To: stable; +Cc: Greg Kroah-Hartman, linuxppc-dev
I see multiple instances of:
arch/powerpc/kernel/exceptions-64s.S:839: Error:
attempt to move .org backwards
in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
forwarding barrier at kernel entry/exit"), which is part of a large patch
series and can not easily be reverted.
Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Use early_mmu_has_feature() in set_kuap()
From: Russell Currey @ 2019-05-08 22:18 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20190508123047.10217-1-mpe@ellerman.id.au>
On Wed, May 8, 2019, at 10:31 PM, Michael Ellerman wrote:
> When implementing the KUAP support on Radix we fixed one case where
> mmu_has_feature() was being called too early in boot via
> __put_user_size().
>
> However since then some new code in linux-next has created a new path
> via which we can end up calling mmu_has_feature() too early.
>
> On P9 this leads to crashes early in boot if we have both PPC_KUAP and
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG enabled. Our early boot code
> calls printk() which calls probe_kernel_read(), that does a
> __copy_from_user_inatomic() which calls into set_kuap() and that uses
> mmu_has_feature().
>
> At that point in boot we haven't patched MMU features yet so the debug
> code in mmu_has_feature() complains, and calls printk(). At that point
> we recurse, eg:
>
> ...
> dump_stack+0xdc
> probe_kernel_read+0x1a4
> check_pointer+0x58
> ...
> printk+0x40
> dump_stack_print_info+0xbc
> dump_stack+0x8
> probe_kernel_read+0x1a4
> probe_kernel_read+0x19c
> check_pointer+0x58
> ...
> printk+0x40
> cpufeatures_process_feature+0xc8
> scan_cpufeatures_subnodes+0x380
> of_scan_flat_dt_subnodes+0xb4
> dt_cpu_ftrs_scan_callback+0x158
> of_scan_flat_dt+0xf0
> dt_cpu_ftrs_scan+0x3c
> early_init_devtree+0x360
> early_setup+0x9c
>
> And so on for infinity, symptom is a dead system.
>
> Even more fun is what happens when using the hash MMU (ie. p8 or p9
> with Radix disabled), and when we don't have
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG enabled. With the debug disabled
> we don't check if static keys have been initialised, we just rely on
> the jump label. But the jump label defaults to true so we just whack
> the AMR even though Radix is not enabled.
>
> Clearing the AMR is fine, but after we've done the user copy we write
> (0b11 << 62) into AMR. When using hash that makes all pages with key
> zero no longer readable or writable. All kernel pages implicitly have
> key zero, and so all of a sudden the kernel can't read or write any of
> its memory. Again dead system.
>
> In the medium term we have several options for fixing this.
> probe_kernel_read() doesn't need to touch AMR at all, it's not doing a
> user access after all, but it uses __copy_from_user_inatomic() just
> because it's easy, we could fix that.
>
> It would also be safe to default to not writing to the AMR during
> early boot, until we've detected features. But it's not clear that
> flipping all the MMU features to static_key_false won't introduce
> other bugs.
>
> But for now just switch to early_mmu_has_feature() in set_kuap(), that
> avoids all the problems with jump labels. It adds the overhead of a
> global lookup and test, but that's probably trivial compared to the
> writes to the AMR anyway.
>
> Fixes: 890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Russell Currey <ruscur@russell.cc>
> ---
> arch/powerpc/include/asm/book3s/64/kup-radix.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/kup-radix.h
> b/arch/powerpc/include/asm/book3s/64/kup-radix.h
> index 7679bd0c5af0..f254de956d6a 100644
> --- a/arch/powerpc/include/asm/book3s/64/kup-radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/kup-radix.h
> @@ -65,7 +65,7 @@
>
> static inline void set_kuap(unsigned long value)
> {
> - if (!mmu_has_feature(MMU_FTR_RADIX_KUAP))
> + if (!early_mmu_has_feature(MMU_FTR_RADIX_KUAP))
> return;
>
> /*
> --
> 2.20.1
>
>
^ permalink raw reply
* [Bug 203125] Kernel 5.1-rc1 fails to boot on a PowerMac G4 3,6: Caused by (from SRR1=141020): Transfer error ack signal
From: bugzilla-daemon @ 2019-05-08 22:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203125-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203125
--- Comment #4 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 282679
--> https://bugzilla.kernel.org/attachment.cgi?id=282679&action=edit
bisect.log
Finally, the results of the bisect...
f7354ccac844da7b1af8cc4f09da330fa3e960e4 is the first bad commit
commit f7354ccac844da7b1af8cc4f09da330fa3e960e4
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date: Thu Jan 31 10:09:04 2019 +0000
powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU
Now that thread_info is similar to task_struct, its address is in r2
so CURRENT_THREAD_INFO() macro is useless. This patch removes it.
This patch also moves the 'tovirt(r2, r2)' down just before the
reactivation of MMU translation, so that we keep the physical address
of 'current' in r2 until then. It avoids a few calls to tophys().
At the same time, as the 'cpu' field is not anymore in thread_info,
TI_CPU is renamed TASK_CPU by this patch.
It also allows to get rid of a couple of
'#ifdef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE' as ACCOUNT_CPU_USER_ENTRY()
and ACCOUNT_CPU_USER_EXIT() are empty when
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not defined.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Fix a missed conversion of TI_CPU idle_6xx.S]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
:040000 040000 c7a4d4ea7c2864b693e82a075f62e26dfcb82c84
a15e8516fdadda87981702d86b38b0e07672220b M arch
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [next-20190507][powerpc] WARN kernel/cgroup/cgroup.c:6008 with LTP ptrace01 test case
From: Roman Gushchin @ 2019-05-08 23:23 UTC (permalink / raw)
To: Sachin Sant
Cc: Tejun Heo, linux-next@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Oleg Nesterov
In-Reply-To: <A8995C41-9A8F-468C-89B2-AB6E44C7EADC@linux.vnet.ibm.com>
On Wed, May 08, 2019 at 03:06:30PM +0530, Sachin Sant wrote:
> While running LTP tests(specifically ptrace01) following WARNING is observed
> on POWER8 LPAR running next-20190507 built using 4K page size.
>
> [ 3969.979492] msgrcv04 (433) used greatest stack depth: 9328 bytes left
> [ 3981.452911] madvise06 (515): drop_caches: 3
> [ 4004.575752] WARNING: CPU: 5 PID: 721 at kernel/cgroup/cgroup.c:6008 cgroup_exit+0x2ac/0x2c0
> [ 4004.575781] Modules linked in: overlay rpadlpar_io rpaphp iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc kvm iptable_filter pseries_rng rng_core vmx_crypto ip_tables x_tables autofs4 [last unloaded: dummy_del_mod]
> [ 4004.575837] CPU: 5 PID: 721 Comm: ptrace01 Tainted: G O 5.1.0-next-20190507-autotest #1
> [ 4004.575846] NIP: c000000001b3026c LR: c000000001b30054 CTR: c000000001c9f020
> [ 4004.575855] REGS: c000000171fff840 TRAP: 0700 Tainted: G O (5.1.0-next-20190507-autotest)
> [ 4004.575863] MSR: 800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 44004824 XER: 20000000
> [ 4004.575885] CFAR: c000000001b30078 IRQMASK: 1
> [ 4004.575885] GPR00: c000000001b30054 c000000171fffad0 c000000003938700 c00000027b02fa18
> [ 4004.575885] GPR04: c00000027b02fa00 0000000000000000 c000000003ae8700 00000000001c180a
> [ 4004.575885] GPR08: 0000000000000001 0000000000000001 c000000003ae8700 0000000000000001
> [ 4004.575885] GPR12: 0000000000004400 c00000001ec7ea80 c000000003a4d670 0000000000000009
> [ 4004.575885] GPR16: 0000000000000000 0000000000040100 00000000418004fc 0000000008430000
> [ 4004.575885] GPR20: 0000000000000009 0000000000000001 c0000001715e9200 c00000016d8f4d00
> [ 4004.575885] GPR24: c000000171fffd90 0000000000000100 c000000168692478 c000000171fffb98
> [ 4004.575885] GPR28: c000000168692400 c00000016d8f4d00 c0000000036420d0 c00000027b02fa00
> [ 4004.575958] NIP [c000000001b3026c] cgroup_exit+0x2ac/0x2c0
> [ 4004.575966] LR [c000000001b30054] cgroup_exit+0x94/0x2c0
> [ 4004.575972] Call Trace:
> [ 4004.575979] [c000000171fffad0] [c000000001b30054] cgroup_exit+0x94/0x2c0 (unreliable)
> [ 4004.575990] [c000000171fffb30] [c0000000019cea98] do_exit+0x878/0x1ae0
> [ 4004.575999] [c000000171fffc00] [c0000000019cfe4c] do_group_exit+0xac/0x1d0
> [ 4004.576009] [c000000171fffc40] [c0000000019ed00c] get_signal+0x2bc/0x11c0
> [ 4004.576019] [c000000171fffd30] [c000000001867b14] do_notify_resume+0x384/0x900
> [ 4004.576029] [c000000171fffe20] [c00000000183e844] ret_from_except_lite+0x70/0x74
> [ 4004.576037] Instruction dump:
> [ 4004.576043] 314a0001 7d40492d 40c2fff4 3d42001b e92a7288 39290001 f92a7288 4bfffe5c
> [ 4004.576056] 3d42001b e92a7258 39290001 f92a7258 <0fe00000> 4bfffe0c 4be91e45 60000000
> [ 4004.576071] ---[ end trace 82a1a7c19005ebd6 ]—
>
> The WARN_ONCE was added by following commit
> 96b9c592def5 ("cgroup: get rid of cgroup_freezer_frozen_exit()”).
>
> Reverting the patch helps avoid the warning.
Hi Sachin!
Thank you for the report!
Can you, please, check that the patch at https://lkml.org/lkml/2019/5/8/938
solves the problem?
I'll appreciate it!
Thanks!
Roman
^ permalink raw reply
* Re: [PATCH v2 5/8] mm/memory_hotplug: Drop MHP_MEMBLOCK_API
From: osalvador @ 2019-05-08 23:08 UTC (permalink / raw)
To: David Hildenbrand, Dan Williams
Cc: linux-s390, Michal Hocko, linux-ia64, Pavel Tatashin, Linux-sh,
Mathieu Malaterre, Linux Kernel Mailing List, Wei Yang, Linux MM,
Qian Cai, Arun KS, Andrew Morton, linuxppc-dev, Joonsoo Kim
In-Reply-To: <edd762a1-c012-fe05-a72e-2505cd98188a@redhat.com>
On Wed, 2019-05-08 at 09:39 +0200, David Hildenbrand wrote:
> However I haven't really thought it through yet, smalles like that
> could
> as well just be handled by the caller of
> arch_add_memory()/arch_remove_memory() eventually, passing it via
> something like the altmap parameter.
>
> Let's leave it in place for now, we can talk about that once we have
> new
> patches from Oscar.
Hi David,
I plan to send a new patchset once this is and Dan's are merged,
otherwise I will have a mayhem with the conflicts.
I also plan/want to review this patchset, but time is tight this week.
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Move SCOM access code into powernv platform
From: Andrew Donnellan @ 2019-05-09 1:14 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <878svhw2po.fsf@concordia.ellerman.id.au>
On 8/5/19 10:27 pm, Michael Ellerman wrote:
> Andrew Donnellan <ajd@linux.ibm.com> writes:
>
>> The powernv platform is the only one that directly accesses SCOMs. Move the
>> support code to platforms/powernv, and get rid of the PPC_SCOM Kconfig
>> option, as SCOM support is always selected when compiling for powernv.
>
> This code was used on WSP / A2, back in the past which is why it
> originally lived in sysdev.
>
>> This also means that the Kconfig item for CONFIG_SCOM_DEBUGFS will actually
>> show up in menuconfig, as previously it was the only labelled option in
>> sysdev/Kconfig and wasn't actually in a menu.
>>
>> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
>> ---
>> arch/powerpc/include/asm/scom.h | 4 ++--
>
> Can't scom.h move into powernv as well?
>
...looks like it can.
> And do we even need the whole scom_controller abstraction?
Probably not. Looks like there's some completely dead code in there too.
Will send a v2.
>
> If we ever have another platform that needs it we can always bring it
> back.
>
> cheers
>
>> arch/powerpc/platforms/powernv/Kconfig | 5 ++++-
>> arch/powerpc/platforms/powernv/Makefile | 2 +-
>> arch/powerpc/{sysdev => platforms/powernv}/scom.c | 0
>> arch/powerpc/sysdev/Kconfig | 7 -------
>> arch/powerpc/sysdev/Makefile | 2 --
>> 6 files changed, 7 insertions(+), 13 deletions(-)
>> rename arch/powerpc/{sysdev => platforms/powernv}/scom.c (100%)
>>
>> diff --git a/arch/powerpc/include/asm/scom.h b/arch/powerpc/include/asm/scom.h
>> index f5cde45b1161..acc6532a9a9e 100644
>> --- a/arch/powerpc/include/asm/scom.h
>> +++ b/arch/powerpc/include/asm/scom.h
>> @@ -23,7 +23,7 @@
>>
>> #ifdef __KERNEL__
>> #ifndef __ASSEMBLY__
>> -#ifdef CONFIG_PPC_SCOM
>> +#ifdef CONFIG_PPC_POWERNV
>>
>> /*
>> * The SCOM bus is a sideband bus used for accessing various internal
>> @@ -161,7 +161,7 @@ static inline int scom_write(scom_map_t map, u64 reg, u64 value)
>> }
>>
>>
>> -#endif /* CONFIG_PPC_SCOM */
>> +#endif /* CONFIG_PPC_POWERNV */
>> #endif /* __ASSEMBLY__ */
>> #endif /* __KERNEL__ */
>> #endif /* _ASM_POWERPC_SCOM_H */
>> diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
>> index 850eee860cf2..938803eab0ad 100644
>> --- a/arch/powerpc/platforms/powernv/Kconfig
>> +++ b/arch/powerpc/platforms/powernv/Kconfig
>> @@ -12,7 +12,6 @@ config PPC_POWERNV
>> select EPAPR_BOOT
>> select PPC_INDIRECT_PIO
>> select PPC_UDBG_16550
>> - select PPC_SCOM
>> select ARCH_RANDOM
>> select CPU_FREQ
>> select PPC_DOORBELL
>> @@ -47,3 +46,7 @@ config PPC_VAS
>> VAS adapters are found in POWER9 based systems.
>>
>> If unsure, say N.
>> +
>> +config SCOM_DEBUGFS
>> + bool "Expose SCOM controllers via debugfs"
>> + depends on DEBUG_FS
>> diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
>> index da2e99efbd04..4b1644150135 100644
>> --- a/arch/powerpc/platforms/powernv/Makefile
>> +++ b/arch/powerpc/platforms/powernv/Makefile
>> @@ -4,12 +4,12 @@ obj-y += idle.o opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
>> obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
>> obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o
>> obj-y += opal-kmsg.o opal-powercap.o opal-psr.o opal-sensor-groups.o
>> +obj-y += opal-xscom.o scom.o
>>
>> obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
>> obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o
>> obj-$(CONFIG_CXL_BASE) += pci-cxl.o
>> obj-$(CONFIG_EEH) += eeh-powernv.o
>> -obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
>> obj-$(CONFIG_MEMORY_FAILURE) += opal-memory-errors.o
>> obj-$(CONFIG_OPAL_PRD) += opal-prd.o
>> obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
>> diff --git a/arch/powerpc/sysdev/scom.c b/arch/powerpc/platforms/powernv/scom.c
>> similarity index 100%
>> rename from arch/powerpc/sysdev/scom.c
>> rename to arch/powerpc/platforms/powernv/scom.c
>> diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
>> index e0dbec780fe9..7808d279ff1d 100644
>> --- a/arch/powerpc/sysdev/Kconfig
>> +++ b/arch/powerpc/sysdev/Kconfig
>> @@ -28,13 +28,6 @@ config PPC_MSI_BITMAP
>> source "arch/powerpc/sysdev/xics/Kconfig"
>> source "arch/powerpc/sysdev/xive/Kconfig"
>>
>> -config PPC_SCOM
>> - bool
>> -
>> -config SCOM_DEBUGFS
>> - bool "Expose SCOM controllers via debugfs"
>> - depends on PPC_SCOM && DEBUG_FS
>> -
>> config GE_FPGA
>> bool
>>
>> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
>> index aaf23283ba0c..35d52d1d2fc0 100644
>> --- a/arch/powerpc/sysdev/Makefile
>> +++ b/arch/powerpc/sysdev/Makefile
>> @@ -51,8 +51,6 @@ ifdef CONFIG_SUSPEND
>> obj-$(CONFIG_PPC_BOOK3S_32) += 6xx-suspend.o
>> endif
>>
>> -obj-$(CONFIG_PPC_SCOM) += scom.o
>> -
>> obj-$(CONFIG_PPC_EARLY_DEBUG_MEMCONS) += udbg_memcons.o
>>
>> obj-$(CONFIG_PPC_XICS) += xics/
>> --
>> 2.20.1
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* RE: PATCH v2 1/6] soc/fsl/qe: qe.c: drop useless static qualifier
From: Qiang Zhao @ 2019-05-09 2:28 UTC (permalink / raw)
To: Rasmus Villemoes, devicetree@vger.kernel.org, Leo Li
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
On 2019/5/1 17:29, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> -----Original Message-----
> From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> Sent: 2019年5月1日 17:29
> To: devicetree@vger.kernel.org; Qiang Zhao <qiang.zhao@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; Scott Wood
> <oss@buserror.net>; Christophe Leroy <christophe.leroy@c-s.fr>; Mark
> Rutland <mark.rutland@arm.com>; Rasmus Villemoes
> <Rasmus.Villemoes@prevas.se>
> Subject: [PATCH v2 1/6] soc/fsl/qe: qe.c: drop useless static qualifier
>
> The local variable snum_init has no reason to have static storage duration.
>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
> ---
> drivers/soc/fsl/qe/qe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
> 612d9c551be5..855373deb746 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -306,7 +306,7 @@ static void qe_snums_init(void)
> 0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
> 0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
> };
> - static const u8 *snum_init;
> + const u8 *snum_init;
>
> qe_num_of_snum = qe_get_num_of_snums();
>
> --
> 2.20.1
Best Regards
Qiang Zhao
^ permalink raw reply
* RE: PATCH v2 2/6] soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
From: Qiang Zhao @ 2019-05-09 2:30 UTC (permalink / raw)
To: Rasmus Villemoes, devicetree@vger.kernel.org, Leo Li
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
On 2019/5/1 17:29, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> -----Original Message-----
> From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> Sent: 2019年5月1日 17:29
> To: devicetree@vger.kernel.org; Qiang Zhao <qiang.zhao@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; Scott Wood
> <oss@buserror.net>; Christophe Leroy <christophe.leroy@c-s.fr>; Mark
> Rutland <mark.rutland@arm.com>; Rasmus Villemoes
> <Rasmus.Villemoes@prevas.se>
> Subject: [PATCH v2 2/6] soc/fsl/qe: qe.c: reduce static memory footprint
> by 1.7K
>
> The current array of struct qe_snum use 256*4 bytes for just keeping track of
> the free/used state of each index, and the struct layout means there's another
> 768 bytes of padding. If we just unzip that structure, the array of snum values
> just use 256 bytes, while the free/inuse state can be tracked in a 32 byte
> bitmap.
>
> So this reduces the .data footprint by 1760 bytes. It also serves as preparation
> for introducing another DT binding for specifying the snum values.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
> ---
> drivers/soc/fsl/qe/qe.c | 43 ++++++++++++-----------------------------
> 1 file changed, 12 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
> 855373deb746..303aa29cb27d 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -14,6 +14,7 @@
> * Free Software Foundation; either version 2 of the License, or (at your
> * option) any later version.
> */
> +#include <linux/bitmap.h>
> #include <linux/errno.h>
> #include <linux/sched.h>
> #include <linux/kernel.h>
> @@ -43,25 +44,14 @@ static DEFINE_SPINLOCK(qe_lock);
> DEFINE_SPINLOCK(cmxgcr_lock); EXPORT_SYMBOL(cmxgcr_lock);
>
> -/* QE snum state */
> -enum qe_snum_state {
> - QE_SNUM_STATE_USED,
> - QE_SNUM_STATE_FREE
> -};
> -
> -/* QE snum */
> -struct qe_snum {
> - u8 num;
> - enum qe_snum_state state;
> -};
> -
> /* We allocate this here because it is used almost exclusively for
> * the communication processor devices.
> */
> struct qe_immap __iomem *qe_immr;
> EXPORT_SYMBOL(qe_immr);
>
> -static struct qe_snum snums[QE_NUM_OF_SNUM]; /* Dynamically
> allocated SNUMs */
> +static u8 snums[QE_NUM_OF_SNUM]; /* Dynamically allocated
> SNUMs */
> +static DECLARE_BITMAP(snum_state, QE_NUM_OF_SNUM);
> static unsigned int qe_num_of_snum;
>
> static phys_addr_t qebase = -1;
> @@ -315,10 +305,8 @@ static void qe_snums_init(void)
> else
> snum_init = snum_init_46;
>
> - for (i = 0; i < qe_num_of_snum; i++) {
> - snums[i].num = snum_init[i];
> - snums[i].state = QE_SNUM_STATE_FREE;
> - }
> + bitmap_zero(snum_state, QE_NUM_OF_SNUM);
> + memcpy(snums, snum_init, qe_num_of_snum);
> }
>
> int qe_get_snum(void)
> @@ -328,12 +316,10 @@ int qe_get_snum(void)
> int i;
>
> spin_lock_irqsave(&qe_lock, flags);
> - for (i = 0; i < qe_num_of_snum; i++) {
> - if (snums[i].state == QE_SNUM_STATE_FREE) {
> - snums[i].state = QE_SNUM_STATE_USED;
> - snum = snums[i].num;
> - break;
> - }
> + i = find_first_zero_bit(snum_state, qe_num_of_snum);
> + if (i < qe_num_of_snum) {
> + set_bit(i, snum_state);
> + snum = snums[i];
> }
> spin_unlock_irqrestore(&qe_lock, flags);
>
> @@ -343,14 +329,9 @@ EXPORT_SYMBOL(qe_get_snum);
>
> void qe_put_snum(u8 snum)
> {
> - int i;
> -
> - for (i = 0; i < qe_num_of_snum; i++) {
> - if (snums[i].num == snum) {
> - snums[i].state = QE_SNUM_STATE_FREE;
> - break;
> - }
> - }
> + const u8 *p = memchr(snums, snum, qe_num_of_snum);
> + if (p)
> + clear_bit(p - snums, snum_state);
> }
> EXPORT_SYMBOL(qe_put_snum);
>
> --
> 2.20.1
Best Regards
Qiang Zhao
^ permalink raw reply
* RE: [PATCH v2 3/6] soc/fsl/qe: qe.c: introduce qe_get_device_node helper
From: Qiang Zhao @ 2019-05-09 2:31 UTC (permalink / raw)
To: Rasmus Villemoes, devicetree@vger.kernel.org, Leo Li
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
On 2019/5/1 17:29, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> -----Original Message-----
> From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> Sent: 2019年5月1日 17:29
> To: devicetree@vger.kernel.org; Qiang Zhao <qiang.zhao@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; Scott Wood
> <oss@buserror.net>; Christophe Leroy <christophe.leroy@c-s.fr>; Mark
> Rutland <mark.rutland@arm.com>; Rasmus Villemoes
> <Rasmus.Villemoes@prevas.se>
> Subject: [PATCH v2 3/6] soc/fsl/qe: qe.c: introduce qe_get_device_node
> helper
>
> The 'try of_find_compatible_node(NULL, NULL, "fsl,qe"), fall back to
> of_find_node_by_type(NULL, "qe")' pattern is repeated five times. Factor it
> into a common helper.
>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
> drivers/soc/fsl/qe/qe.c | 71 +++++++++++++++++------------------------
> 1 file changed, 29 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
> 303aa29cb27d..0fb8b59f61ad 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -56,6 +56,20 @@ static unsigned int qe_num_of_snum;
>
> static phys_addr_t qebase = -1;
>
> +static struct device_node *qe_get_device_node(void) {
> + struct device_node *qe;
> +
> + /*
> + * Newer device trees have an "fsl,qe" compatible property for the
> QE
> + * node, but we still need to support older device trees.
> + */
> + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (qe)
> + return qe;
> + return of_find_node_by_type(NULL, "qe"); }
> +
> static phys_addr_t get_qe_base(void)
> {
> struct device_node *qe;
> @@ -65,12 +79,9 @@ static phys_addr_t get_qe_base(void)
> if (qebase != -1)
> return qebase;
>
> - qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> - if (!qe) {
> - qe = of_find_node_by_type(NULL, "qe");
> - if (!qe)
> - return qebase;
> - }
> + qe = qe_get_device_node();
> + if (!qe)
> + return qebase;
>
> ret = of_address_to_resource(qe, 0, &res);
> if (!ret)
> @@ -164,12 +175,9 @@ unsigned int qe_get_brg_clk(void)
> if (brg_clk)
> return brg_clk;
>
> - qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> - if (!qe) {
> - qe = of_find_node_by_type(NULL, "qe");
> - if (!qe)
> - return brg_clk;
> - }
> + qe = qe_get_device_node();
> + if (!qe)
> + return brg_clk;
>
> prop = of_get_property(qe, "brg-frequency", &size);
> if (prop && size == sizeof(*prop)) @@ -557,16 +565,9 @@ struct
> qe_firmware_info *qe_get_firmware_info(void)
>
> initialized = 1;
>
> - /*
> - * Newer device trees have an "fsl,qe" compatible property for the QE
> - * node, but we still need to support older device trees.
> - */
> - qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> - if (!qe) {
> - qe = of_find_node_by_type(NULL, "qe");
> - if (!qe)
> - return NULL;
> - }
> + qe = qe_get_device_node();
> + if (!qe)
> + return NULL;
>
> /* Find the 'firmware' child node */
> fw = of_get_child_by_name(qe, "firmware"); @@ -612,16 +613,9
> @@ unsigned int qe_get_num_of_risc(void)
> unsigned int num_of_risc = 0;
> const u32 *prop;
>
> - qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> - if (!qe) {
> - /* Older devices trees did not have an "fsl,qe"
> - * compatible property, so we need to look for
> - * the QE node by name.
> - */
> - qe = of_find_node_by_type(NULL, "qe");
> - if (!qe)
> - return num_of_risc;
> - }
> + qe = qe_get_device_node();
> + if (!qe)
> + return num_of_risc;
>
> prop = of_get_property(qe, "fsl,qe-num-riscs", &size);
> if (prop && size == sizeof(*prop)) @@ -641,16 +635,9 @@ unsigned
> int qe_get_num_of_snums(void)
> const u32 *prop;
>
> num_of_snums = 28; /* The default number of snum for threads is 28
> */
> - qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> - if (!qe) {
> - /* Older devices trees did not have an "fsl,qe"
> - * compatible property, so we need to look for
> - * the QE node by name.
> - */
> - qe = of_find_node_by_type(NULL, "qe");
> - if (!qe)
> - return num_of_snums;
> - }
> + qe = qe_get_device_node();
> + if (!qe)
> + return num_of_snums;
>
> prop = of_get_property(qe, "fsl,qe-num-snums", &size);
> if (prop && size == sizeof(*prop)) {
> --
> 2.20.1
Best Regards
Qiang Zhao
^ permalink raw reply
* RE: [PATCH v2 5/6] soc/fsl/qe: qe.c: support fsl,qe-snums property
From: Qiang Zhao @ 2019-05-09 2:33 UTC (permalink / raw)
To: Rasmus Villemoes, devicetree@vger.kernel.org, Leo Li
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
On 2019/5/1 17:29, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> -----Original Message-----
> From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> Sent: 2019年5月1日 17:29
> To: devicetree@vger.kernel.org; Qiang Zhao <qiang.zhao@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; Scott Wood
> <oss@buserror.net>; Christophe Leroy <christophe.leroy@c-s.fr>; Mark
> Rutland <mark.rutland@arm.com>; Rasmus Villemoes
> <Rasmus.Villemoes@prevas.se>
> Subject: [PATCH v2 5/6] soc/fsl/qe: qe.c: support fsl,qe-snums property
>
> Add driver support for the newly introduced fsl,qe-snums property.
>
> Conveniently, of_property_read_variable_u8_array does exactly what we
> need: If the property fsl,qe-snums is found (and has an allowed size), the array
> of values get copied to snums, and the return value is the number of snums -
> we cannot assign directly to num_of_snums, since we need to check whether
> the return value is negative.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
> drivers/soc/fsl/qe/qe.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
> 0fb8b59f61ad..325d689cbf5c 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -283,7 +283,6 @@ EXPORT_SYMBOL(qe_clock_source);
> */
> static void qe_snums_init(void)
> {
> - int i;
> static const u8 snum_init_76[] = {
> 0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
> 0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89, @@
> -304,7 +303,21 @@ static void qe_snums_init(void)
> 0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
> 0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
> };
> + struct device_node *qe;
> const u8 *snum_init;
> + int i;
> +
> + bitmap_zero(snum_state, QE_NUM_OF_SNUM);
> + qe = qe_get_device_node();
> + if (qe) {
> + i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
> + snums, 1,
> QE_NUM_OF_SNUM);
> + of_node_put(qe);
> + if (i > 0) {
> + qe_num_of_snum = i;
> + return;
> + }
> + }
>
> qe_num_of_snum = qe_get_num_of_snums();
>
> @@ -313,7 +326,6 @@ static void qe_snums_init(void)
> else
> snum_init = snum_init_46;
>
> - bitmap_zero(snum_state, QE_NUM_OF_SNUM);
> memcpy(snums, snum_init, qe_num_of_snum); }
>
> --
> 2.20.1
Best Regards
Qiang Zhao
^ permalink raw reply
* RE: [EXT] [PATCH v2 6/6] soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init
From: Qiang Zhao @ 2019-05-09 2:35 UTC (permalink / raw)
To: Rasmus Villemoes, devicetree@vger.kernel.org, Leo Li
Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-7-rasmus.villemoes@prevas.dk>
On 2019/5/1 17:29, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> -----Original Message-----
> From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> Sent: 2019年5月1日 17:29
> To: devicetree@vger.kernel.org; Qiang Zhao <qiang.zhao@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-kernel@vger.kernel.org; Rob Herring <robh+dt@kernel.org>; Scott Wood
> <oss@buserror.net>; Christophe Leroy <christophe.leroy@c-s.fr>; Mark
> Rutland <mark.rutland@arm.com>; Rasmus Villemoes
> <Rasmus.Villemoes@prevas.se>
> Subject: [PATCH v2 6/6] soc/fsl/qe: qe.c: fold qe_get_num_of_snums into
> qe_snums_init
>
> The comment "No QE ever has fewer than 28 SNUMs" is false; e.g. the
> MPC8309 has 14. The code path returning -EINVAL is also a recipe for instant
> disaster, since the caller (qe_snums_init) uncritically assigns the return value to
> the unsigned qe_num_of_snum, and would thus proceed to attempt to copy
> 4GB from snum_init_46[] to the snum[] array.
>
> So fold the handling of the legacy fsl,qe-num-snums into qe_snums_init, and
> make sure we do not end up using the snum_init_46 array in cases other than
> the two where we know it makes sense.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
Reviewed-by: Qiang Zhao <qiang.zhao@nxp.com>
> drivers/soc/fsl/qe/qe.c | 46 ++++++++++++++---------------------------
> 1 file changed, 16 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
> 325d689cbf5c..276d7d78ebfc 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -308,24 +308,33 @@ static void qe_snums_init(void)
> int i;
>
> bitmap_zero(snum_state, QE_NUM_OF_SNUM);
> + qe_num_of_snum = 28; /* The default number of snum for threads
> + is 28 */
> qe = qe_get_device_node();
> if (qe) {
> i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
> snums, 1,
> QE_NUM_OF_SNUM);
> - of_node_put(qe);
> if (i > 0) {
> + of_node_put(qe);
> qe_num_of_snum = i;
> return;
> }
> + /*
> + * Fall back to legacy binding of using the value of
> + * fsl,qe-num-snums to choose one of the static arrays
> + * above.
> + */
> + of_property_read_u32(qe, "fsl,qe-num-snums",
> &qe_num_of_snum);
> + of_node_put(qe);
> }
>
> - qe_num_of_snum = qe_get_num_of_snums();
> -
> - if (qe_num_of_snum == 76)
> + if (qe_num_of_snum == 76) {
> snum_init = snum_init_76;
> - else
> + } else if (qe_num_of_snum == 28 || qe_num_of_snum == 46) {
> snum_init = snum_init_46;
> -
> + } else {
> + pr_err("QE: unsupported value of fsl,qe-num-snums: %u\n",
> qe_num_of_snum);
> + return;
> + }
> memcpy(snums, snum_init, qe_num_of_snum); }
>
> @@ -641,30 +650,7 @@ EXPORT_SYMBOL(qe_get_num_of_risc);
>
> unsigned int qe_get_num_of_snums(void)
> {
> - struct device_node *qe;
> - int size;
> - unsigned int num_of_snums;
> - const u32 *prop;
> -
> - num_of_snums = 28; /* The default number of snum for threads is 28
> */
> - qe = qe_get_device_node();
> - if (!qe)
> - return num_of_snums;
> -
> - prop = of_get_property(qe, "fsl,qe-num-snums", &size);
> - if (prop && size == sizeof(*prop)) {
> - num_of_snums = *prop;
> - if ((num_of_snums < 28) || (num_of_snums >
> QE_NUM_OF_SNUM)) {
> - /* No QE ever has fewer than 28 SNUMs */
> - pr_err("QE: number of snum is invalid\n");
> - of_node_put(qe);
> - return -EINVAL;
> - }
> - }
> -
> - of_node_put(qe);
> -
> - return num_of_snums;
> + return qe_num_of_snum;
> }
> EXPORT_SYMBOL(qe_get_num_of_snums);
>
> --
> 2.20.1
Best Regards
Qiang Zhao
^ permalink raw reply
* Re: [PATCH v2 09/16] powernv/fadump: process architected register state data provided by firmware
From: Hari Bathini @ 2019-05-09 4:42 UTC (permalink / raw)
To: Segher Boessenkool, Mahesh J Salgaonkar
Cc: Ananth N Mavinakayanahalli, Mahesh J Salgaonkar, Nicholas Piggin,
linuxppc-dev, Vasant Hegde, Stewart Smith, Daniel Axtens
In-Reply-To: <20190507160055.GG8599@gate.crashing.org>
On 07/05/19 9:30 PM, Segher Boessenkool wrote:
> On Tue, May 07, 2019 at 07:43:56PM +0530, Mahesh J Salgaonkar wrote:
>> Can we use SPRN_* #defines which are already present in asm/reg.h instead of
>> hard coding numbers for switch cases ? You may want to add new #defines
>> for NIP, MSR and CCR.
> But none of those three are SPRs. Please don't pollute that namespace.
> Put such defines into some fadump header, instead?
Sure, Segher.
I will stick with adding the defines in fadump header for the missing regs..
^ permalink raw reply
* Re: [PATCH v2 12/16] powerpc/powernv: export /proc/opalcore for analysing opal crashes
From: Hari Bathini @ 2019-05-09 4:46 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
Cc: Stewart Smith, Daniel Axtens, Mahesh J Salgaonkar, Vasant Hegde,
Ananth N Mavinakayanahalli
In-Reply-To: <1557274986.rnb0tqdbuc.astroid@bobo.none>
On 08/05/19 5:55 AM, Nicholas Piggin wrote:
> Hari Bathini's on April 16, 2019 8:35 pm:
>> From: Hari Bathini <hbathini@linux.vnet.ibm.com>
>>
>> Export /proc/opalcore file to analyze opal crashes. Since opalcore can
>> be generated independent of CONFIG_FA_DUMP support in kernel, add this
>> support under a new kernel config option CONFIG_OPAL_CORE. Also, avoid
>> code duplication by moving common code used for processing the register
>> state data to export /proc/vmcore and/or /proc/opalcore file(s).
> Can this go in /sys/firmware/opal/core or similar?
>
Sure. Will try to keep it that way..
- Hari
^ 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