* Re: [PATCH v2 3/6] net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
From: David Miller @ 2018-09-01 5:55 UTC (permalink / raw)
To: david.gounaris; +Cc: qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-4-david.gounaris@infinera.com>
From: David Gounaris <david.gounaris@infinera.com>
Date: Wed, 29 Aug 2018 15:13:25 +0200
> @@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
> break;
>
> case ARPHRD_PPP:
> + case ARPHRD_ETHER:
> +
Please don't add such an extraneous empty line.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/6] net/wan/fsl_ucc_hdlc: allow PARITY_CRC16_PR0_CCITT parity
From: christophe leroy @ 2018-09-01 8:03 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-3-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 5cf6dcba039c..c8e526bf1130 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -781,7 +781,8 @@ static int ucc_hdlc_attach(struct net_device *dev, unsigned short encoding,
>
> if (parity != PARITY_NONE &&
> parity != PARITY_CRC32_PR1_CCITT &&
> - parity != PARITY_CRC16_PR1_CCITT)
> + parity != PARITY_CRC16_PR1_CCITT &&
> + parity != PARITY_CRC16_PR0_CCITT)
ERROR:TRAILING_WHITESPACE: trailing whitespace
#20: FILE: drivers/net/wan/fsl_ucc_hdlc.c:783:
+^I parity != PARITY_CRC16_PR1_CCITT && $
Also, you could have left the line 'parity != PARITY_CRC16_PR1_CCITT)'
as is and just have added 'parity != PARITY_CRC16_PR0_CCITT &&' on the
previous line, would make more sense to have PR0 before PR1, and instead
of having 2+1- you would only have 1+
> return -EINVAL;
>
> priv->encoding = encoding;
>
---
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
* Re: [PATCH v2 1/6] net/wan/fsl_ucc_hdlc: allow ucc index up to 7
From: christophe leroy @ 2018-09-01 7:58 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-2-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> There is a need to allow higher indexes to be
> able to support MPC83xx platforms. (UCC1-UCC8)
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 33df76405b86..5cf6dcba039c 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -1016,7 +1016,7 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
> }
>
> ucc_num = val - 1;
> - if ((ucc_num > 3) || (ucc_num < 0)) {
> + if ((ucc_num > UCC_MAX_NUM - 1) || (ucc_num < 0)) {
CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'ucc_num < 0'
#23: FILE: drivers/net/wan/fsl_ucc_hdlc.c:1018:
+ if ((ucc_num > UCC_MAX_NUM - 1) || (ucc_num < 0)) {
> dev_err(&pdev->dev, ": Invalid UCC num\n");
> return -EINVAL;
> }
>
---
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
* Re: [PATCH v2 3/6] net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
From: christophe leroy @ 2018-09-01 8:05 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-4-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> This patch is to avoid discarding ethernet
> packets when using HDLC_ETH protocol.
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index c8e526bf1130..0f703d7be5e0 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -376,6 +376,10 @@ static netdev_tx_t ucc_hdlc_tx(struct sk_buff *skb, struct net_device *dev)
> dev->stats.tx_bytes += skb->len;
> break;
>
> + case ARPHRD_ETHER:
> + dev->stats.tx_bytes += skb->len;
> + break;
> +
> default:
> dev->stats.tx_dropped++;
> dev_kfree_skb(skb);
> @@ -513,6 +517,8 @@ static int hdlc_rx_done(struct ucc_hdlc_private *priv, int rx_work_limit)
> break;
>
> case ARPHRD_PPP:
> + case ARPHRD_ETHER:
> +
ERROR:TRAILING_WHITESPACE: trailing whitespace
#34: FILE: drivers/net/wan/fsl_ucc_hdlc.c:520:
+^I^I^I$
Note that 'git show' would show it to you in red background so you
shouldn't miss it.
And this additional blank line is unnecessary.
> length -= HDLC_CRC_SIZE;
>
> skb = dev_alloc_skb(length);
>
---
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
* Re: [PATCH v2 4/6] net/wan/fsl_ucc_hdlc: hmask
From: christophe leroy @ 2018-09-01 8:06 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-5-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> Ability to set hmask in the device-tree,
> which can be used to change address
> filtering of packets.
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt | 6 ++++++
> drivers/net/wan/fsl_ucc_hdlc.c | 5 ++++-
> drivers/net/wan/fsl_ucc_hdlc.h | 1 +
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> index 03c741602c6d..6d2dd8a31482 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/network.txt
> @@ -98,6 +98,12 @@ The property below is dependent on fsl,tdm-interface:
> usage: optional for tdm interface
> value type: <empty>
> Definition : Internal loopback connecting on TDM layer.
> +- fsl,hmask
> + usage: optional
> + Value type: <u16>
> + Definition: HDLC address recognition. Set to zero to disable
> + address filtering of packets:
> + fsl,hmask = /bits/ 16 <0x0000>;
>
> Example for tdm interface:
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 0f703d7be5e0..be5b0096af3b 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -263,7 +263,7 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
> iowrite16be(MAX_FRAME_LENGTH, &priv->ucc_pram->mflr);
> iowrite16be(DEFAULT_RFTHR, &priv->ucc_pram->rfthr);
> iowrite16be(DEFAULT_RFTHR, &priv->ucc_pram->rfcnt);
> - iowrite16be(DEFAULT_ADDR_MASK, &priv->ucc_pram->hmask);
> + iowrite16be(priv->hmask, &priv->ucc_pram->hmask);
> iowrite16be(DEFAULT_HDLC_ADDR, &priv->ucc_pram->haddr1);
> iowrite16be(DEFAULT_HDLC_ADDR, &priv->ucc_pram->haddr2);
> iowrite16be(DEFAULT_HDLC_ADDR, &priv->ucc_pram->haddr3);
> @@ -1097,6 +1097,9 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
> if (ret)
> goto free_utdm;
> }
> +
ERROR:TRAILING_WHITESPACE: trailing whitespace
#51: FILE: drivers/net/wan/fsl_ucc_hdlc.c:1099:
+^I$
'git show' (or git log -p) would show it to you in red background.
> + if (of_property_read_u16(np, "fsl,hmask", &uhdlc_priv->hmask))
> + uhdlc_priv->hmask = DEFAULT_ADDR_MASK;
>
> ret = uhdlc_init(uhdlc_priv);
> if (ret) {
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.h b/drivers/net/wan/fsl_ucc_hdlc.h
> index c21134c1f180..b99fa2f1cd99 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.h
> +++ b/drivers/net/wan/fsl_ucc_hdlc.h
> @@ -106,6 +106,7 @@ struct ucc_hdlc_private {
>
> unsigned short encoding;
> unsigned short parity;
> + unsigned short hmask;
> u32 clocking;
> spinlock_t lock; /* lock for Tx BD and Tx buffer */
> #ifdef CONFIG_PM
>
---
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
* Re: [PATCH v2 5/6] net/wan/fsl_ucc_hdlc: GUMR for non tsa mode
From: christophe leroy @ 2018-09-01 8:08 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-6-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> The following bits in the GUMR is changed for non
> tsa mode: CDS, CTSP and CTSS are set to zero.
>
> When set, there is no tx interrupts from the controller.
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index be5b0096af3b..248f1f5bcd04 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -97,6 +97,13 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
> if (priv->tsa) {
> uf_info->tsa = 1;
> uf_info->ctsp = 1;
> + uf_info->cds = 1;
> + uf_info->ctss = 1;
> + }
> + else {
ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
#27: FILE: drivers/net/wan/fsl_ucc_hdlc.c:103:
+ }
+ else {
CHECK:BRACES: Unbalanced braces around else statement
#27: FILE: drivers/net/wan/fsl_ucc_hdlc.c:103:
+ else {
Should be:
} else {
> + uf_info->cds = 0;
> + uf_info->ctsp = 0;
> + uf_info->ctss = 0;
> }
>
> /* This sets HPM register in CMXUCR register which configures a
>
---
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
* Re: [PATCH v2 0/6] Ethernet over hdlc
From: christophe leroy @ 2018-09-01 8:10 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-1-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> Here is what has been changed in v2 after the review comments.
>
> v2-0001: Using UCC_MAX_NUM
This one has a warning/check from checkpatch
> v2-0002: Unchanged
> v2-0003: Changed commit message
> v2-0004: Adding fsl,hmask into the dt instead of changing the default value.
> v2-0005: Unchanged
> v2-0006: Unchanged
All the above have an error from checkpatch
You should run checkpatch on your patches and fix the errors and warnings.
You can also see them at
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=63075
Christophe
>
> Adding robh+dt@kernel.org for comments regarding dt.
>
> Best Regards
> David Gounaris
>
> David Gounaris (6):
> net/wan/fsl_ucc_hdlc: allow ucc index up to 7
> net/wan/fsl_ucc_hdlc: allow PARITY_CRC16_PR0_CCITT parity
> net/wan/fsl_ucc_hdlc: Adding ARPHRD_ETHER
> net/wan/fsl_ucc_hdlc: hmask
> net/wan/fsl_ucc_hdlc: GUMR for non tsa mode
> net/wan/fsl_ucc_hdlc: tx timeout handler
>
> .../devicetree/bindings/soc/fsl/cpm_qe/network.txt | 6 +++++
> drivers/net/wan/fsl_ucc_hdlc.c | 28 +++++++++++++++++++---
> drivers/net/wan/fsl_ucc_hdlc.h | 1 +
> 3 files changed, 32 insertions(+), 3 deletions(-)
>
---
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
* Re: [PATCH v2 6/6] net/wan/fsl_ucc_hdlc: tx timeout handler
From: christophe leroy @ 2018-09-01 8:10 UTC (permalink / raw)
To: David Gounaris, qiang.zhao, netdev, linuxppc-dev, robh+dt
In-Reply-To: <20180829131328.27901-7-david.gounaris@infinera.com>
Le 29/08/2018 à 15:13, David Gounaris a écrit :
> Added tx timerout handler. This helps
> when troubleshooting.
>
> Signed-off-by: David Gounaris <david.gounaris@infinera.com>
> ---
> drivers/net/wan/fsl_ucc_hdlc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
> index 248f1f5bcd04..629ef5049d27 100644
> --- a/drivers/net/wan/fsl_ucc_hdlc.c
> +++ b/drivers/net/wan/fsl_ucc_hdlc.c
> @@ -1002,11 +1002,15 @@ static const struct dev_pm_ops uhdlc_pm_ops = {
> #define HDLC_PM_OPS NULL
>
> #endif
> +static void uhdlc_tx_timeout(struct net_device *ndev) {
ERROR:OPEN_BRACE: open brace '{' following function definitions go on
the next line
#22: FILE: drivers/net/wan/fsl_ucc_hdlc.c:1004:
+static void uhdlc_tx_timeout(struct net_device *ndev) {
> + netdev_err(ndev, "%s\n", __FUNCTION__);
WARNING:USE_FUNC: __func__ should be used instead of gcc specific
__FUNCTION__
#23: FILE: drivers/net/wan/fsl_ucc_hdlc.c:1005:
+ netdev_err(ndev, "%s\n", __FUNCTION__);
> +}
> static const struct net_device_ops uhdlc_ops = {
> .ndo_open = uhdlc_open,
> .ndo_stop = uhdlc_close,
> .ndo_start_xmit = hdlc_start_xmit,
> .ndo_do_ioctl = uhdlc_ioctl,
> + .ndo_tx_timeout = uhdlc_tx_timeout,
> };
>
> static int ucc_hdlc_probe(struct platform_device *pdev)
> @@ -1125,6 +1129,7 @@ static int ucc_hdlc_probe(struct platform_device *pdev)
> hdlc = dev_to_hdlc(dev);
> dev->tx_queue_len = 16;
> dev->netdev_ops = &uhdlc_ops;
> + dev->watchdog_timeo = 2*HZ;
CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#38: FILE: drivers/net/wan/fsl_ucc_hdlc.c:1131:
+ dev->watchdog_timeo = 2*HZ;
> hdlc->attach = ucc_hdlc_attach;
> hdlc->xmit = ucc_hdlc_tx;
> netif_napi_add(dev, &uhdlc_priv->napi, ucc_hdlc_poll, 32);
>
---
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
* [PATCH] powerpc/powernv: Make possible for user to force a full ipl cec reboot
From: Vaibhav Jain @ 2018-09-01 8:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman
Cc: Vaibhav Jain, linuxppc-dev, Vasant Hegde, Michael Neuling,
Nicholas Piggin, Oliver O'Halloran
Ever since fast reboot is enabled by default in opal,
opal_cec_reboot() will use fast-reset instead of full IPL to perform
system reboot. This leaves the user with no direct way to force a full
IPL reboot except changing an nvram setting that persistently disables
fast-reset for all subsequent reboots.
This patch provides a more direct way for the user to force a one-shot
full IPL reboot by passing the command line argument 'full' to the
reboot command. So the user will be able to tweak the reboot behavior
via:
$ sudo reboot full # Force a full ipl reboot skipping fast-reset
or
$ sudo reboot # default reboot path (usually fast-reset)
The reboot command passes the un-parsed command argument to the kernel
via the 'Reboot' syscall which is then passed on to the arch function
pnv_restart(). The patch updates pnv_restart() to handle this cmd-arg
and issues opal_cec_reboot2 with OPAL_REBOOT_FULL_IPL to force a full
IPL reset.
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
arch/powerpc/include/asm/opal-api.h | 1 +
arch/powerpc/platforms/powernv/setup.c | 8 +++++++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index 8365353330b4..870fb7b239ea 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -1050,6 +1050,7 @@ enum OpalSysCooling {
enum {
OPAL_REBOOT_NORMAL = 0,
OPAL_REBOOT_PLATFORM_ERROR = 1,
+ OPAL_REBOOT_FULL_IPL = 2,
};
/* Argument to OPAL_PCI_TCE_KILL */
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index adddde023622..33d2faeacff8 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -224,7 +224,13 @@ static void __noreturn pnv_restart(char *cmd)
pnv_prepare_going_down();
while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
- rc = opal_cec_reboot();
+
+ /* See if we need to do a full IPL reboot */
+ if (cmd && strcmp(cmd, "full") == 0)
+ rc = opal_cec_reboot2(OPAL_REBOOT_FULL_IPL, NULL);
+ else
+ rc = opal_cec_reboot();
+
if (rc == OPAL_BUSY_EVENT)
opal_poll_events(NULL);
else
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv: Make possible for user to force a full ipl cec reboot
From: Nicholas Piggin @ 2018-09-01 9:53 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Benjamin Herrenschmidt, Michael Ellerman, linuxppc-dev,
Vasant Hegde, Michael Neuling, Oliver O'Halloran
In-Reply-To: <20180901081745.2165-1-vaibhav@linux.ibm.com>
On Sat, 1 Sep 2018 13:47:45 +0530
Vaibhav Jain <vaibhav@linux.ibm.com> wrote:
> Ever since fast reboot is enabled by default in opal,
> opal_cec_reboot() will use fast-reset instead of full IPL to perform
> system reboot. This leaves the user with no direct way to force a full
> IPL reboot except changing an nvram setting that persistently disables
> fast-reset for all subsequent reboots.
>
> This patch provides a more direct way for the user to force a one-shot
> full IPL reboot by passing the command line argument 'full' to the
> reboot command. So the user will be able to tweak the reboot behavior
> via:
>
> $ sudo reboot full # Force a full ipl reboot skipping fast-reset
>
> or
> $ sudo reboot # default reboot path (usually fast-reset)
>
> The reboot command passes the un-parsed command argument to the kernel
> via the 'Reboot' syscall which is then passed on to the arch function
> pnv_restart(). The patch updates pnv_restart() to handle this cmd-arg
> and issues opal_cec_reboot2 with OPAL_REBOOT_FULL_IPL to force a full
> IPL reset.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
This is nice but I wonder if the default should be IPL and fast
should be the option.
> ---
> arch/powerpc/include/asm/opal-api.h | 1 +
> arch/powerpc/platforms/powernv/setup.c | 8 +++++++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
> index 8365353330b4..870fb7b239ea 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -1050,6 +1050,7 @@ enum OpalSysCooling {
> enum {
> OPAL_REBOOT_NORMAL = 0,
> OPAL_REBOOT_PLATFORM_ERROR = 1,
> + OPAL_REBOOT_FULL_IPL = 2,
> };
>
> /* Argument to OPAL_PCI_TCE_KILL */
> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
> index adddde023622..33d2faeacff8 100644
> --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -224,7 +224,13 @@ static void __noreturn pnv_restart(char *cmd)
> pnv_prepare_going_down();
>
> while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
> - rc = opal_cec_reboot();
> +
> + /* See if we need to do a full IPL reboot */
> + if (cmd && strcmp(cmd, "full") == 0)
> + rc = opal_cec_reboot2(OPAL_REBOOT_FULL_IPL, NULL);
> + else
> + rc = opal_cec_reboot();
> +
> if (rc == OPAL_BUSY_EVENT)
> opal_poll_events(NULL);
> else
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH RFCv2 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock
From: David Hildenbrand @ 2018-09-01 14:03 UTC (permalink / raw)
To: Oscar Salvador
Cc: linux-mm, linux-kernel, linux-doc, linuxppc-dev, linux-acpi,
xen-devel, devel, Andrew Morton, Balbir Singh,
Benjamin Herrenschmidt, Boris Ostrovsky, Dan Williams,
Greg Kroah-Hartman, Haiyang Zhang, Heiko Carstens, John Allen,
Jonathan Corbet, Joonsoo Kim, Juergen Gross, Kate Stewart,
K. Y. Srinivasan, Len Brown, Martin Schwidefsky,
Mathieu Malaterre, Michael Ellerman, Michael Neuling,
Michal Hocko, Nathan Fontenot, Oscar Salvador, Paul Mackerras,
Pavel Tatashin, Philippe Ombredanne, Rafael J. Wysocki,
Rashmica Gupta, Stephen Hemminger, Thomas Gleixner,
Vlastimil Babka, YASUAKI ISHIMATSU
In-Reply-To: <20180831205457.GB3945@techadventures.net>
On 31.08.2018 22:54, Oscar Salvador wrote:
> On Tue, Aug 21, 2018 at 12:44:12PM +0200, David Hildenbrand wrote:
>> This is the same approach as in the first RFC, but this time without
>> exporting device_hotplug_lock (requested by Greg) and with some more
>> details and documentation regarding locking. Tested only on x86 so far.
>
> Hi David,
>
> I would like to review this but I am on vacation, so I will not be able to get to it
> soon.
> I plan to do it once I am back.
Sure, I won't be resending within next two weeks either way, as I am
also on vacation.
Have a nice vacation!
>
> Thanks
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* [PATCH RFC] powerpc/kernel: Don't check for dev->dma_mask in fsl_set_dma_mask
From: Darren Stevens @ 2018-09-02 11:30 UTC (permalink / raw)
To: linuxppc-dev, Christian Zigotzky, Julian Margetson, Scott Wood
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
AmigaOS...........: http://yam.ch/
Unix/MacOS/Windows: http://www.mozilla.com/thunderbird/
General information about MIME can be found at:
http://en.wikipedia.org/wiki/MIME
[-- Attachment #2: Type: text/plain, Size: 1037 bytes --]
To enable use of dma to all ram on a corenet generic system, we add the
function fsl_pci_dma_set_mask, and link it into the ppc.md structure.
But this function checks for the presence of dev->dma_mask and dma_ops
at entry, and fails if one or other are missing. Powerpc's dma_set_mask
(which it is called from) doesn't check this until after it has set the
dma_mask for pci devs, this difference shows up on a Cyrus (AmigaOne X5000)
- a soundblaster live pci card, will works properly if memory is limited
to <4G, but fail on probe with the following message if the memory is >=4G
[ 4.646531] snd_emu10k1 1000:04:04.0: architecture does not support PCI
busmaster DMA with mask 0x7fffffff
Remove the dev->mask tests to make the routines behave similarly.
Signed-off-by: Darren Stevens <darren@stevens-zone.net>
---
This fix looks wrong to me, although it works. The test needs to be removed,
moving it to the end of the function doesn't work either. This needs someone
with more knowledge of what's going on to take a look.
[-- Attachment #3: dma.patch --]
[-- Type: text/plain, Size: 551 bytes --]
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 918be81..36b3c86 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -127,9 +127,6 @@ static inline void setup_swiotlb_ops(struct pci_controller *hose) {}
static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)
{
- if (!dev->dma_mask || !dma_supported(dev, dma_mask))
- return -EIO;
-
/*
* Fix up PCI devices that are able to DMA to the large inbound
* mapping that allows addressing any RAM address from across PCI.
^ permalink raw reply related
* [PATCH AUTOSEL 4.18 044/131] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Sasha Levin @ 2018-09-02 13:03 UTC (permalink / raw)
To: stable@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Christophe Leroy, Alexander Shishkin, Peter Zijlstra,
linuxppc-dev@lists.ozlabs.org, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180902064601.183036-1-alexander.levin@microsoft.com>
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) =3D -1 ENOMEM (Cannot=
allocate memory)
--- SIGSEGV {si_signo=3DSIGSEGV, si_code=3DSI_KERNEL, si_addr=3D0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=3D-DMAX_NR_CPUS=3D1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.id=
si0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index d215714f48df..21bf7f5a3cf5 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -25,7 +25,9 @@ static inline unsigned long long rdclock(void)
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
=20
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
=20
extern const char *input_name;
extern bool perf_host, perf_guest;
--=20
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 29/89] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Sasha Levin @ 2018-09-02 13:06 UTC (permalink / raw)
To: stable@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Christophe Leroy, Alexander Shishkin, Peter Zijlstra,
linuxppc-dev@lists.ozlabs.org, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180902064918.183387-1-alexander.levin@microsoft.com>
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) =3D -1 ENOMEM (Cannot=
allocate memory)
--- SIGSEGV {si_signo=3DSIGSEGV, si_code=3DSI_KERNEL, si_addr=3D0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=3D-DMAX_NR_CPUS=3D1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.id=
si0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 55086389fc06..96f62dd7e3ed 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -24,7 +24,9 @@ static inline unsigned long long rdclock(void)
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
=20
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
=20
extern const char *input_name;
extern bool perf_host, perf_guest;
--=20
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 14/62] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Sasha Levin @ 2018-09-02 13:14 UTC (permalink / raw)
To: stable@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Christophe Leroy, Alexander Shishkin, Peter Zijlstra,
linuxppc-dev@lists.ozlabs.org, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180902131411.183978-1-alexander.levin@microsoft.com>
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) =3D -1 ENOMEM (Cannot=
allocate memory)
--- SIGSEGV {si_signo=3DSIGSEGV, si_code=3DSI_KERNEL, si_addr=3D0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=3D-DMAX_NR_CPUS=3D1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.id=
si0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 9a0236a4cf95..8f8d895d5b74 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -22,7 +22,9 @@ static inline unsigned long long rdclock(void)
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
=20
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
=20
extern const char *input_name;
extern bool perf_host, perf_guest;
--=20
2.17.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 12/47] perf tools: Allow overriding MAX_NR_CPUS at compile time
From: Sasha Levin @ 2018-09-02 13:15 UTC (permalink / raw)
To: stable@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Christophe Leroy, Alexander Shishkin, Peter Zijlstra,
linuxppc-dev@lists.ozlabs.org, Arnaldo Carvalho de Melo,
Sasha Levin
In-Reply-To: <20180902131533.184092-1-alexander.levin@microsoft.com>
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 21b8732eb4479b579bda9ee38e62b2c312c2a0e5 ]
After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
powerpc board, but still runs on a 128MB RAM board:
~# strace perf
execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) =3D -1 ENOMEM (Cannot=
allocate memory)
--- SIGSEGV {si_signo=3DSIGSEGV, si_code=3DSI_KERNEL, si_addr=3D0} ---
+++ killed by SIGSEGV +++
Segmentation fault
objdump -x shows that .bss section has a huge size of 24Mbytes:
27 .bss 016baca8 101cebb8 101cebb8 001cd988 2**3
With especially the following objects having quite big size:
10205f80 l O .bss 00140000 runtime_cycles_stats
10345f80 l O .bss 00140000 runtime_stalled_cycles_front_stats
10485f80 l O .bss 00140000 runtime_stalled_cycles_back_stats
105c5f80 l O .bss 00140000 runtime_branches_stats
10705f80 l O .bss 00140000 runtime_cacherefs_stats
10845f80 l O .bss 00140000 runtime_l1_dcache_stats
10985f80 l O .bss 00140000 runtime_l1_icache_stats
10ac5f80 l O .bss 00140000 runtime_ll_cache_stats
10c05f80 l O .bss 00140000 runtime_itlb_cache_stats
10d45f80 l O .bss 00140000 runtime_dtlb_cache_stats
10e85f80 l O .bss 00140000 runtime_cycles_in_tx_stats
10fc5f80 l O .bss 00140000 runtime_transaction_stats
11105f80 l O .bss 00140000 runtime_elision_stats
11245f80 l O .bss 00140000 runtime_topdown_total_slots
11385f80 l O .bss 00140000 runtime_topdown_slots_retired
114c5f80 l O .bss 00140000 runtime_topdown_slots_issued
11605f80 l O .bss 00140000 runtime_topdown_fetch_bubbles
11745f80 l O .bss 00140000 runtime_topdown_recovery_bubbles
This is due to commit 4d255766d28b1 ("perf: Bump max number of cpus
to 1024"), because many tables are sized with MAX_NR_CPUS
This patch gives the opportunity to redefine MAX_NR_CPUS via
$ make EXTRA_CFLAGS=3D-DMAX_NR_CPUS=3D1
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linuxppc-dev@lists.ozlabs.org
Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.id=
si0.si.c-s.fr
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
tools/perf/perf.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 90129accffbe..4341ed267d4e 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -29,7 +29,9 @@ static inline unsigned long long rdclock(void)
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
=20
+#ifndef MAX_NR_CPUS
#define MAX_NR_CPUS 1024
+#endif
=20
extern const char *input_name;
extern bool perf_host, perf_guest;
--=20
2.17.1
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv: Make possible for user to force a full ipl cec reboot
From: Vaibhav Jain @ 2018-09-02 14:26 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Benjamin Herrenschmidt, Michael Ellerman, linuxppc-dev,
Vasant Hegde, Michael Neuling, Oliver O'Halloran
In-Reply-To: <20180901195337.3080204b@roar.ozlabs.ibm.com>
Thanks for looking into this patch Nick,
Nicholas Piggin <npiggin@gmail.com> writes:
> This is nice but I wonder if the default should be IPL and fast
> should be the option.
Fast-reset should work most of the times so I think it should be
default. Its also the current default which I am bit relunctant to
change.
We usually need full IPL reset only when we need to update skiboot or
have malfunctioning device that isnt being reset properly during
fast-reset. So I am believe full IPL resets will be less frequent hence
should be explicitly requested.
--
Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* RE: [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Andy Tang @ 2018-09-03 1:17 UTC (permalink / raw)
To: Scott Wood, Vabhav Sharma, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, mturquette@baylibre.com,
sboyd@kernel.org, rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel-owner@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, gregkh@linuxfoundation.org, arnd@arndb.de,
kstewart@linuxfoundation.org, yamada.masahiro@socionext.com
Cc: Yogesh Narayan Gaur, linux@armlinux.org.uk, Udit Kumar,
Varun Sethi
In-Reply-To: <f6707cb54c3e6da1b50f45f915c996dfccfeacda.camel@buserror.net>
SGkgU2NvdHQsDQoNClBsZWFzZSBzZWUgbXkgcmVwbGF5IGluIGxpbmUuDQoNCj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTGludXhwcGMtZGV2DQo+IDxsaW51eHBwYy1kZXYt
Ym91bmNlcytiMjk5ODM9ZnJlZXNjYWxlLmNvbUBsaXN0cy5vemxhYnMub3JnPiBPbg0KPiBCZWhh
bGYgT2YgU2NvdHQgV29vZA0KPiBTZW50OiAyMDE45bm0OeaciDHml6UgNDoyOQ0KPiBUbzogQW5k
eSBUYW5nIDxhbmR5LnRhbmdAbnhwLmNvbT47IFZhYmhhdiBTaGFybWENCj4gPHZhYmhhdi5zaGFy
bWFAbnhwLmNvbT47IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+IGRldmljZXRyZWVA
dmdlci5rZXJuZWwub3JnOyByb2JoK2R0QGtlcm5lbC5vcmc7DQo+IG1hcmsucnV0bGFuZEBhcm0u
Y29tOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsNCj4gbGludXgtYXJtLWtlcm5lbEBs
aXN0cy5pbmZyYWRlYWQub3JnOyBtdHVycXVldHRlQGJheWxpYnJlLmNvbTsNCj4gc2JveWRAa2Vy
bmVsLm9yZzsgcmp3QHJqd3lzb2NraS5uZXQ7IHZpcmVzaC5rdW1hckBsaW5hcm8ub3JnOw0KPiBs
aW51eC1jbGtAdmdlci5rZXJuZWwub3JnOyBsaW51eC1wbUB2Z2VyLmtlcm5lbC5vcmc7DQo+IGxp
bnV4LWtlcm5lbC1vd25lckB2Z2VyLmtlcm5lbC5vcmc7IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29t
Ow0KPiB3aWxsLmRlYWNvbkBhcm0uY29tOyBncmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsgYXJu
ZEBhcm5kYi5kZTsNCj4ga3N0ZXdhcnRAbGludXhmb3VuZGF0aW9uLm9yZzsgeWFtYWRhLm1hc2Fo
aXJvQHNvY2lvbmV4dC5jb20NCj4gQ2M6IFlvZ2VzaCBOYXJheWFuIEdhdXIgPHlvZ2VzaG5hcmF5
YW4uZ2F1ckBueHAuY29tPjsNCj4gbGludXhAYXJtbGludXgub3JnLnVrOyBVZGl0IEt1bWFyIDx1
ZGl0Lmt1bWFyQG54cC5jb20+OyBWYXJ1biBTZXRoaQ0KPiA8Vi5TZXRoaUBueHAuY29tPg0KPiBT
dWJqZWN0OiBSZTogW1BBVENIIDMvNV0gZHJpdmVyczogY2xrLXFvcmlxOiBBZGQgY2xvY2tnZW4g
c3VwcG9ydCBmb3INCj4gbHgyMTYwYQ0KPiANCj4gT24gRnJpLCAyMDE4LTA4LTMxIGF0IDA2OjEy
ICswMDAwLCBBbmR5IFRhbmcgd3JvdGU6DQo+ID4gSGkgU2NvdHQsDQo+ID4NCj4gPiBQbGVhc2Ug
c2VlIG15IHJlcGxheSBpbmxpbmUuDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+ID4gPiBGcm9tOiBsaW51eC1hcm0ta2VybmVsDQo+ID4gPiA8bGludXgtYXJtLWtlcm5l
bC1ib3VuY2VzQGxpc3RzLmluZnJhZGVhZC5vcmc+DQo+ID4gPiBPbiBCZWhhbGYgT2YgU2NvdHQg
V29vZA0KPiA+ID4gU2VudDogMjAxOOW5tDjmnIgzMeaXpSAxOjQzDQo+ID4gPiBUbzogVmFiaGF2
IFNoYXJtYSA8dmFiaGF2LnNoYXJtYUBueHAuY29tPjsNCj4gPiA+IGxpbnV4LWtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOw0KPiA+ID4gcm9iaCtkdEBr
ZXJuZWwub3JnOyBtYXJrLnJ1dGxhbmRAYXJtLmNvbTsNCj4gPiA+IGxpbnV4cHBjLWRldkBsaXN0
cy5vemxhYnMub3JnOyBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7DQo+ID4g
PiBtdHVycXVldHRlQGJheWxpYnJlLmNvbTsgc2JveWRAa2VybmVsLm9yZzsgcmp3QHJqd3lzb2Nr
aS5uZXQ7DQo+ID4gPiB2aXJlc2gua3VtYXJAbGluYXJvLm9yZzsgbGludXgtY2xrQHZnZXIua2Vy
bmVsLm9yZzsNCj4gPiA+IGxpbnV4LXBtQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsLW93
bmVyQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tOyB3aWxs
LmRlYWNvbkBhcm0uY29tOw0KPiA+ID4gZ3JlZ2toQGxpbnV4Zm91bmRhdGlvbi5vcmc7IGFybmRA
YXJuZGIuZGU7DQo+ID4gPiBrc3Rld2FydEBsaW51eGZvdW5kYXRpb24ub3JnOyB5YW1hZGEubWFz
YWhpcm9Ac29jaW9uZXh0LmNvbQ0KPiA+ID4gQ2M6IFlvZ2VzaCBOYXJheWFuIEdhdXIgPHlvZ2Vz
aG5hcmF5YW4uZ2F1ckBueHAuY29tPjsgQW5keSBUYW5nDQo+ID4gPiA8YW5keS50YW5nQG54cC5j
b20+OyBsaW51eEBhcm1saW51eC5vcmcudWs7IFZhcnVuIFNldGhpDQo+ID4gPiA8Vi5TZXRoaUBu
eHAuY29tPjsgVWRpdCBLdW1hciA8dWRpdC5rdW1hckBueHAuY29tPg0KPiA+ID4gU3ViamVjdDog
UmU6IFtQQVRDSCAzLzVdIGRyaXZlcnM6IGNsay1xb3JpcTogQWRkIGNsb2NrZ2VuIHN1cHBvcnQN
Cj4gPiA+IGZvciBseDIxNjBhDQo+ID4gPg0KPiA+ID4gT24gVGh1LCAyMDE4LTA4LTMwIGF0IDEy
OjM5IC0wNTAwLCBTY290dCBXb29kIHdyb3RlOg0KPiA+ID4gPiBPbiBUaHUsIDIwMTgtMDgtMzAg
YXQgMDc6MzYgKzAwMDAsIFZhYmhhdiBTaGFybWEgd3JvdGU6DQo+ID4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gV2h5IGFyZSB5b3UgaW5jcmVhc2luZyBOVU1fQ01VWCBiZXlvbmQgOCBmb3IgYSBjaGlw
IHRoYXQNCj4gb25seQ0KPiA+ID4NCj4gPiA+IGhhcw0KPiA+ID4gPiA+ID4gOCBlbnRyaWVzIGlu
IGNtdXhfdG9fZ3JvdXA/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBDb25maWd1cmF0aW9uIGlzIDE2
IGNvcmVzLDggY2x1c3RlciB3aXRoIDIgY29yZXMgaW4gZWFjaCBjbHVzdGVyDQo+ID4gPiA+DQo+
ID4gPiA+IFNvPyAgVGhpcyBpcyBhYm91dCBjbXV4ZXMsIG5vdCBjb3Jlcy4gIFlvdSdyZSBpbmNy
ZWFzaW5nIHRoZSBhcnJheQ0KPiA+ID4gPiB3aXRob3V0IGV2ZXIgdXNpbmcgdGhlIG5ldyBzaXpl
Lg0KPiA+ID4NCj4gPiA+IE9oLCBhbmQgeW91IGFsc28gYnJva2UgcDQwODAgd2hpY2ggaGFzIDgg
Y211eGVzIGJ1dCBubyAtMQ0KPiA+ID4gdGVybWluYXRvciwgYmVjYXVzZSB0aGUgYXJyYXkgd2Fz
IG9mIGxlbmd0aCA4LiAgUHJvYmFibHkgdGhlIGFycmF5DQo+ID4gPiBzaG91bGQgYmUgY2hhbmdl
ZCB0byBOVU1fQ01VWCsxIHNvIGV2ZXJ5IGFycmF5IGNhbiBiZSAtMQ0KPiB0ZXJtaW5hdGVkLg0K
PiA+ID4NCj4gPg0KPiA+IFtBbmR5XSBIb3cgYWJvdXQgd2UgYWRkIC0xIHRlcm1pbmF0b3IgdG8g
cDQwODAgYW5kIGluY3JlYXNlDQo+IE5VTV9DTVVYIHRvIDE2Pw0KPiANCj4gV2h5IDE2PyAgV2hh
dCBkb2VzIHN1Y2ggYSBjaGFuZ2UgaGF2ZSB0byBkbyB3aXRoIHRoaXMgY2hpcCwgd2hpY2gNCj4g
YWNjb3JkaW5nIHRvIHRoZSByZXN0IG9mIHRoZSBwYXRjaCBoYXMgOCBjbXV4ZXM/DQpbQW5keV0g
TlVNX0NNVVggaXMgYSBsaW1pdGF0aW9uIG51bWJlci4gV2UgYmV0dGVyIGdpdmUgaXQgYW4gZXh0
cmEgYnVmZmVyLCBub3QgZXhhY3RseSBlcXVhbCB0byB0aGUgbGltaXRhdGlvbi4NCjE2IGlzIHRo
ZSBsaW1pdGF0aW9uIG51bWJlciB3aXRoIGV4dHJhIGJ1ZmZlci4NCg0KPiANCj4gPiBXZSBkb24n
dCB3YW50IHRvIGluY3JlYXNlIE5VTV9DTVVYIGVhY2ggdGltZSBuZXcgc29jIHdpdGggbW9yZQ0K
PiBjbXV4ZXMgYWRkZWQuDQo+IA0KPiBZb3UgZG9uJ3Qgd2FudCB0byBoYXZlIHRvIG1ha2UgYSB0
cml2aWFsIGNoYW5nZSBlYWNoIHRpbWUgeW91IGV4Y2VlZCBhDQo+IGxpbWl0IHRoYXQgaGFzIHll
dCB0byBiZSBleGNlZWRlZCBvbmNlIHNpbmNlIE5VTV9DTVVYIHdhcyBhZGRlZD8NCj4gVGhpcyBp
c24ndCBBQkkgb3IgaW4gYW55IG90aGVyIHdheSBoYXJkIHRvIGNoYW5nZS4gIEl0J3MgcmlnaHQg
aW4gdGhlIHNhbWUgZmlsZQ0KPiBhcyB0aGUgY2hpcCBkZXNjcmlwdGlvbiB5b3UnZCBiZSBhZGRp
bmcuDQo+IA0KPiBBbmQgZXZlbiBpZiBhIGNoaXAgZGlkIGNvbWUgYWxvbmcgd2l0aCAxNiBjbXV4
ZXMsIHlvdSdkIHRoZW4gbmVlZCB0bw0KPiBpbmNyZWFzZSB0aGUgYXJyYXkgdG8gMTcgdG8gaG9s
ZCB0aGUgLTEgaWYgeW91IGRvbid0IHdhbnQgdG8gbGVhdmUgYSBzaXR1YXRpb24NCj4gbGlrZSB0
aGUNCj4gcDQwODAgaXMgaW4gbm93LCB3aGVyZSBhIGNoaXAncyBjbXV4IGFycmF5IGNvdWxkIGJl
IGJyb2tlbiBieSBpbmNyZWFzaW5nDQo+IE5VTV9DTVVYIGZ1cnRoZXIuDQo+IA0KW0FuZHldIEFk
ZGluZyBidWZmZXIgdG8gYSBsaW1pdGF0aW9uIG51bWJlciBpcyBhbHdheXMgYSBnb29kIGhhYml0
IHdoZW4gY29kaW5nLiBXZSBvZnRlbiBmb3JnZXQgdG8gaW5jcmVhc2UgdGhpcyB2YWx1ZSB3aGVu
DQphIG5ldyBjaGlwIHdpdGggbW9yZSBjbXV4ZXMgYWRkZWQuIExpa2UgdGhpcyBwYXRjaCwgd2Ug
ZGlkbid0IGluY3JlYXNlIHRoaXMgdmFsdWUgYXQgZmlyc3QuIFdlIHNwZW50IGEgbG90IG9mIHRp
bWUgZmluZGluZyBvdXQgdGhhdCBOVU1fQ01VWCBuZWVkcyB0byBiZSBpbmNyZWFzZWQgdG9vLg0K
SXQgaXMgYSBwZXJzb25hbCBwcmVmZXJlbmNlIGhvdyB0byBzZXQgdGhpcyB2YWx1ZS4gSSB0aGlu
ayBpdCBpcyBiZXR0ZXIgdG8gaW5jcmVhc2UgaXQgdG8gMTYsIG5vdCBOVU1fQ01VWCsxIGFzIGxv
bmcgYXMgd2UgZml4IHRoZSBQNDA4MCBpc3N1ZQ0KZXZlbiB0aG91Z2ggaXQgaXMgYSB0cml2aWFs
IGNoYW5nZS4gQW5kIEkgYWdyZWUgdGhlIGRlc2NyaXB0aW9uIG5lZWRzIHRvIGJlIHVwZGF0ZWQu
DQoNCkJSLA0KQW5keQ0KDQo+IC1TY290dA0KDQo=
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Make possible for user to force a full ipl cec reboot
From: Andrew Donnellan @ 2018-09-03 3:10 UTC (permalink / raw)
To: Vaibhav Jain, Benjamin Herrenschmidt, Michael Ellerman
Cc: Michael Neuling, Nicholas Piggin, Vasant Hegde,
Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20180901081745.2165-1-vaibhav@linux.ibm.com>
On 01/09/18 18:17, Vaibhav Jain wrote:
> Ever since fast reboot is enabled by default in opal,
> opal_cec_reboot() will use fast-reset instead of full IPL to perform
> system reboot. This leaves the user with no direct way to force a full
> IPL reboot except changing an nvram setting that persistently disables
> fast-reset for all subsequent reboots.
>=20
> This patch provides a more direct way for the user to force a one-shot
> full IPL reboot by passing the command line argument 'full' to the
> reboot command. So the user will be able to tweak the reboot behavior
> via:
>=20
> $ sudo reboot full # Force a full ipl reboot skipping fast-reset
>=20
> or
> $ sudo reboot # default reboot path (usually fast-reset)
>=20
> The reboot command passes the un-parsed command argument to the kernel
> via the 'Reboot' syscall which is then passed on to the arch function
> pnv_restart(). The patch updates pnv_restart() to handle this cmd-arg
> and issues opal_cec_reboot2 with OPAL_REBOOT_FULL_IPL to force a full
> IPL reset.
>=20
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Oh good, someone else has finally picked this up and sent a kernel=20
patch, I did the skiboot half and then neglected to make it useful (I=20
sent an RFC at https://patchwork.ozlabs.org/patch/697604/ but never=20
followed up on it... this approach seems more usable, I think).
When you say "the reboot command" - is this behaviour of passing the=20
argument common to all the important init systems/reboot utils? What's=20
the correct systemd way to do it?
> while (rc =3D=3D OPAL_BUSY || rc =3D=3D OPAL_BUSY_EVENT) {
> - rc =3D opal_cec_reboot();
> +
> + /* See if we need to do a full IPL reboot */
> + if (cmd && strcmp(cmd, "full") =3D=3D 0)
> + rc =3D opal_cec_reboot2(OPAL_REBOOT_FULL_IPL, NULL);
You might want to check for OPAL_UNSUPPORTED here just in case we're=20
running on ancient firmware.
> + else
> + rc =3D opal_cec_reboot();
> +
> if (rc =3D=3D OPAL_BUSY_EVENT)
> opal_poll_events(NULL);
> else
>=20
--=20
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH kernel] KVM: PPC: Avoid mapping compound pages to TCEs in real mode
From: David Gibson @ 2018-09-03 3:28 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linuxppc-dev, kvm-ppc, Aneesh Kumar K.V, Michael Ellerman,
Nicholas Piggin, Paul Mackerras
In-Reply-To: <20180831060850.33010-1-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 7833 bytes --]
On Fri, Aug 31, 2018 at 04:08:50PM +1000, Alexey Kardashevskiy wrote:
> At the moment the real mode handler of H_PUT_TCE calls iommu_tce_xchg_rm()
> which in turn reads the old TCE and if it was a valid entry - marks
> the physical page dirty if it was mapped for writing. Since it is
> the real mode, realmode_pfn_to_page() is used instead of pfn_to_page()
> to get the page struct. However SetPageDirty() itself reads the compound
> page head and returns a virtual address for the head page struct and
> setting dirty bit for that kills the system.
>
> This moves dirty bit setting before updating the hardware table
Um.. but now you're setting DIRTY based on the *new* TCE's
permissions, instead of the old TCE's permissions, which I don't think
is correct.
> to make
> sure compound pages are never mapped in the real mode so when H_PUT_TCE
> or H_STUFF_TCE try clearing a TCE, they won't get a compound page to mark
> dirty.
>
> This changes kvmppc_rm_tce_validate() to check if the preregistered
> memory is backed with pages bigger than hardware IOMMU pages; if this is
> the case, we forward the request to the virtual mode handlers where it
> can be safely processed.
>
> The second check makes the first check rather unnecessary but since
> the actual crash happened at the SetPageDirty() call site, this marks
> the spot with WARN_ON_ONCE.
>
> In order to keep virtual and real mode handlers in sync, this adjusts
> iommu_tce_xchg() as well.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> This is made on top of:
> [PATCH kernel 0/4] KVM: PPC: Some error handling rework
> KVM: PPC: Validate all tces before updating tables
> KVM: PPC: Inform the userspace about TCE update failures
> KVM: PPC: Validate TCEs against preregistered memory page sizes
> KVM: PPC: Propagate errors to the guest when failed instead of
> ignoring
> ---
> arch/powerpc/include/asm/mmu_context.h | 3 ++-
> arch/powerpc/kernel/iommu.c | 19 ++++++++-----------
> arch/powerpc/kvm/book3s_64_vio_hv.c | 15 +++++++++++----
> arch/powerpc/mm/mmu_context_iommu.c | 4 +++-
> 4 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
> index b2f89b6..073d72f9b 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -31,7 +31,8 @@ extern void mm_iommu_cleanup(struct mm_struct *mm);
> extern struct mm_iommu_table_group_mem_t *mm_iommu_lookup(struct mm_struct *mm,
> unsigned long ua, unsigned long size);
> extern struct mm_iommu_table_group_mem_t *mm_iommu_lookup_rm(
> - struct mm_struct *mm, unsigned long ua, unsigned long size);
> + struct mm_struct *mm, unsigned long ua, unsigned long size,
> + unsigned int *pshift);
> extern struct mm_iommu_table_group_mem_t *mm_iommu_find(struct mm_struct *mm,
> unsigned long ua, unsigned long entries);
> extern long mm_iommu_ua_to_hpa(struct mm_iommu_table_group_mem_t *mem,
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index af7a20d..62e014d 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -998,12 +998,11 @@ long iommu_tce_xchg(struct iommu_table *tbl, unsigned long entry,
> {
> long ret;
>
> - ret = tbl->it_ops->exchange(tbl, entry, hpa, direction);
> -
> - if (!ret && ((*direction == DMA_FROM_DEVICE) ||
> - (*direction == DMA_BIDIRECTIONAL)))
> + if (*direction == DMA_FROM_DEVICE || *direction == DMA_BIDIRECTIONAL)
> SetPageDirty(pfn_to_page(*hpa >> PAGE_SHIFT));
>
> + ret = tbl->it_ops->exchange(tbl, entry, hpa, direction);
> +
> /* if (unlikely(ret))
> pr_err("iommu_tce: %s failed on hwaddr=%lx ioba=%lx kva=%lx ret=%d\n",
> __func__, hwaddr, entry << tbl->it_page_shift,
> @@ -1019,20 +1018,18 @@ long iommu_tce_xchg_rm(struct iommu_table *tbl, unsigned long entry,
> {
> long ret;
>
> - ret = tbl->it_ops->exchange_rm(tbl, entry, hpa, direction);
> -
> - if (!ret && ((*direction == DMA_FROM_DEVICE) ||
> - (*direction == DMA_BIDIRECTIONAL))) {
> + if (*direction == DMA_FROM_DEVICE || *direction == DMA_BIDIRECTIONAL) {
> struct page *pg = realmode_pfn_to_page(*hpa >> PAGE_SHIFT);
>
> if (likely(pg)) {
> + if (WARN_ON_ONCE(PageCompound(pg)))
> + return -EPERM;
> SetPageDirty(pg);
> - } else {
> - tbl->it_ops->exchange_rm(tbl, entry, hpa, direction);
> - ret = -EFAULT;
> }
> }
>
> + ret = tbl->it_ops->exchange_rm(tbl, entry, hpa, direction);
> +
> return ret;
> }
> EXPORT_SYMBOL_GPL(iommu_tce_xchg_rm);
> diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c b/arch/powerpc/kvm/book3s_64_vio_hv.c
> index 8d82133..ce4d2f4 100644
> --- a/arch/powerpc/kvm/book3s_64_vio_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
> @@ -118,11 +118,17 @@ static long kvmppc_rm_tce_validate(struct kvmppc_spapr_tce_table *stt,
> unsigned long hpa = 0;
> struct mm_iommu_table_group_mem_t *mem;
> long shift = stit->tbl->it_page_shift;
> + unsigned int memshift = 0;
>
> - mem = mm_iommu_lookup_rm(stt->kvm->mm, ua, 1ULL << shift);
> + mem = mm_iommu_lookup_rm(stt->kvm->mm, ua, 1ULL << shift,
> + &memshift);
> if (!mem)
> return H_TOO_HARD;
>
> + /* Marking compound pages dirty in real mode is too complex */
> + if (memshift > shift)
> + return H_TOO_HARD;
> +
> if (mm_iommu_ua_to_hpa_rm(mem, ua, shift, &hpa))
> return H_TOO_HARD;
> }
> @@ -222,7 +228,7 @@ static long kvmppc_rm_tce_iommu_mapped_dec(struct kvm *kvm,
> /* it_userspace allocation might be delayed */
> return H_TOO_HARD;
>
> - mem = mm_iommu_lookup_rm(kvm->mm, be64_to_cpu(*pua), pgsize);
> + mem = mm_iommu_lookup_rm(kvm->mm, be64_to_cpu(*pua), pgsize, NULL);
> if (!mem)
> return H_TOO_HARD;
>
> @@ -287,7 +293,7 @@ static long kvmppc_rm_tce_iommu_do_map(struct kvm *kvm, struct iommu_table *tbl,
> /* it_userspace allocation might be delayed */
> return H_TOO_HARD;
>
> - mem = mm_iommu_lookup_rm(kvm->mm, ua, 1ULL << tbl->it_page_shift);
> + mem = mm_iommu_lookup_rm(kvm->mm, ua, 1ULL << tbl->it_page_shift, NULL);
> if (!mem)
> return H_TOO_HARD;
>
> @@ -472,7 +478,8 @@ long kvmppc_rm_h_put_tce_indirect(struct kvm_vcpu *vcpu,
> if (kvmppc_gpa_to_ua(vcpu->kvm, tce_list, &ua, NULL))
> return H_TOO_HARD;
>
> - mem = mm_iommu_lookup_rm(vcpu->kvm->mm, ua, IOMMU_PAGE_SIZE_4K);
> + mem = mm_iommu_lookup_rm(vcpu->kvm->mm, ua, IOMMU_PAGE_SIZE_4K,
> + NULL);
> if (mem)
> prereg = mm_iommu_ua_to_hpa_rm(mem, ua,
> IOMMU_PAGE_SHIFT_4K, &tces) == 0;
> diff --git a/arch/powerpc/mm/mmu_context_iommu.c b/arch/powerpc/mm/mmu_context_iommu.c
> index c9ee9e2..5c31fa5 100644
> --- a/arch/powerpc/mm/mmu_context_iommu.c
> +++ b/arch/powerpc/mm/mmu_context_iommu.c
> @@ -344,7 +344,7 @@ struct mm_iommu_table_group_mem_t *mm_iommu_lookup(struct mm_struct *mm,
> EXPORT_SYMBOL_GPL(mm_iommu_lookup);
>
> struct mm_iommu_table_group_mem_t *mm_iommu_lookup_rm(struct mm_struct *mm,
> - unsigned long ua, unsigned long size)
> + unsigned long ua, unsigned long size, unsigned int *pshift)
> {
> struct mm_iommu_table_group_mem_t *mem, *ret = NULL;
>
> @@ -354,6 +354,8 @@ struct mm_iommu_table_group_mem_t *mm_iommu_lookup_rm(struct mm_struct *mm,
> (ua + size <= mem->ua +
> (mem->entries << PAGE_SHIFT))) {
> ret = mem;
> + if (pshift)
> + *pshift = mem->pageshift;
> break;
> }
> }
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array
From: Matthew Wilcox @ 2018-09-03 4:31 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Linus Walleij, Jonathan Corbet, Miguel Ojeda Sandonis,
Peter Korsgaard, Peter Rosin, Ulf Hansson, Andrew Lunn,
Florian Fainelli, David S. Miller, Dominik Brodowski,
Greg Kroah-Hartman, Kishon Vijay Abraham I, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, Hartmut Knaack,
Peter Meerwald-Stadler, Jiri Slaby, Willy Tarreau,
Geert Uytterhoeven, linux-doc, linux-i2c, linux-mmc, netdev,
linux-iio, devel, linux-serial, linux-gpio, linux-kernel,
Sebastien Bourdelin, Lukas Wunner, Rojhalat Ibrahim, Russell King,
Tony Lindgren, Yegor Yefremov, Uwe Kleine-König,
linuxppc-dev
In-Reply-To: <20180902120144.6855-2-jmkrzyszt@gmail.com>
> +++ b/drivers/auxdisplay/hd44780.c
> @@ -62,17 +62,12 @@ static void hd44780_strobe_gpio(struct hd44780 *hd)
> /* write to an LCD panel register in 8 bit GPIO mode */
> static void hd44780_write_gpio8(struct hd44780 *hd, u8 val, unsigned int rs)
> {
> - int values[10]; /* for DATA[0-7], RS, RW */
> - unsigned int i, n;
> -
> - for (i = 0; i < 8; i++)
> - values[PIN_DATA0 + i] = !!(val & BIT(i));
> - values[PIN_CTRL_RS] = rs;
> - n = 9;
> - if (hd->pins[PIN_CTRL_RW]) {
> - values[PIN_CTRL_RW] = 0;
> - n++;
> - }
> + DECLARE_BITMAP(values, 10); /* for DATA[0-7], RS, RW */
> + unsigned int n;
> +
> + *values = val;
> + __assign_bit(8, values, rs);
> + n = hd->pins[PIN_CTRL_RW] ? 10 : 9;
Doesn't this assume little endian bitmaps? Has anyone tested this on
big-endian machines?
^ permalink raw reply
* Re: [PATCH kernel] KVM: PPC: Avoid mapping compound pages to TCEs in real mode
From: Paul Mackerras @ 2018-09-03 5:15 UTC (permalink / raw)
To: David Gibson
Cc: Alexey Kardashevskiy, linuxppc-dev, kvm-ppc, Aneesh Kumar K.V,
Michael Ellerman, Nicholas Piggin
In-Reply-To: <20180903032844.GD2679@umbus.fritz.box>
On Mon, Sep 03, 2018 at 01:28:44PM +1000, David Gibson wrote:
> On Fri, Aug 31, 2018 at 04:08:50PM +1000, Alexey Kardashevskiy wrote:
> > At the moment the real mode handler of H_PUT_TCE calls iommu_tce_xchg_rm()
> > which in turn reads the old TCE and if it was a valid entry - marks
> > the physical page dirty if it was mapped for writing. Since it is
> > the real mode, realmode_pfn_to_page() is used instead of pfn_to_page()
> > to get the page struct. However SetPageDirty() itself reads the compound
> > page head and returns a virtual address for the head page struct and
> > setting dirty bit for that kills the system.
> >
> > This moves dirty bit setting before updating the hardware table
>
> Um.. but now you're setting DIRTY based on the *new* TCE's
> permissions, instead of the old TCE's permissions, which I don't think
> is correct.
He's setting dirty on the page which is about to be mapped if the new
TCE allows the page to be written by the device. Given that the page
is pinned, I don't see any reason why the dirty setting has to be done
when the page is unmapped rather than when it is mapped. Do you see a
reason?
Paul.
^ permalink raw reply
* Re: [PATCH kernel] KVM: PPC: Avoid mapping compound pages to TCEs in real mode
From: David Gibson @ 2018-09-03 5:17 UTC (permalink / raw)
To: Paul Mackerras
Cc: Alexey Kardashevskiy, linuxppc-dev, kvm-ppc, Aneesh Kumar K.V,
Michael Ellerman, Nicholas Piggin
In-Reply-To: <20180903051529.GA7848@fergus>
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
On Mon, Sep 03, 2018 at 03:15:29PM +1000, Paul Mackerras wrote:
> On Mon, Sep 03, 2018 at 01:28:44PM +1000, David Gibson wrote:
> > On Fri, Aug 31, 2018 at 04:08:50PM +1000, Alexey Kardashevskiy wrote:
> > > At the moment the real mode handler of H_PUT_TCE calls iommu_tce_xchg_rm()
> > > which in turn reads the old TCE and if it was a valid entry - marks
> > > the physical page dirty if it was mapped for writing. Since it is
> > > the real mode, realmode_pfn_to_page() is used instead of pfn_to_page()
> > > to get the page struct. However SetPageDirty() itself reads the compound
> > > page head and returns a virtual address for the head page struct and
> > > setting dirty bit for that kills the system.
> > >
> > > This moves dirty bit setting before updating the hardware table
> >
> > Um.. but now you're setting DIRTY based on the *new* TCE's
> > permissions, instead of the old TCE's permissions, which I don't think
> > is correct.
>
> He's setting dirty on the page which is about to be mapped if the new
> TCE allows the page to be written by the device. Given that the page
> is pinned, I don't see any reason why the dirty setting has to be done
> when the page is unmapped rather than when it is mapped. Do you see a
> reason?
Hrm. Couldn't the page get marked clean by some other path before it
is unmapped in that case?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/powernv: Make possible for user to force a full ipl cec reboot
From: Vaibhav Jain @ 2018-09-03 6:00 UTC (permalink / raw)
To: Andrew Donnellan, Benjamin Herrenschmidt, Michael Ellerman
Cc: Vasant Hegde, linuxppc-dev, Michael Neuling,
Oliver O'Halloran, Nicholas Piggin
In-Reply-To: <0fd029d2-e8ac-4392-6961-62e588ee5182@au1.ibm.com>
Thanks for looking into this Andrew,
Andrew Donnellan <andrew.donnellan@au1.ibm.com> writes:
> Oh good, someone else has finally picked this up and sent a kernel
> patch, I did the skiboot half and then neglected to make it useful (I
> sent an RFC at https://patchwork.ozlabs.org/patch/697604/ but never
> followed up on it... this approach seems more usable, I think).
Thanks for pointing that out. I wasnt aware of this patch.
> When you say "the reboot command" - is this behaviour of passing the
> argument common to all the important init systems/reboot utils? What's
> the correct systemd way to do it?
Mostly Yes,
On systemd the reboot command is just a symlink to systemctl binary that
checks argv[0] and maintains the a backward compatible behaviour. The
more systemd specific command 'systemctl reboot full' will also do the
same thing. So this patch should work on systemd.
Looking at 'upstart' I see support for adding an arg to the reboot
command since revision
https://bazaar.launchpad.net/~upstart-devel/upstart/trunk/revision/1432.3.1
. So upstart should also be supported.
I dont see support for sending an arg in 'SysVinit' halt command
yet. However this patch wont break the halt command. Just that SysVinit
systems will continue to use fast-reboot like today. Though
theorectially with this patch a SysVinit user can write a tool to issue
reboot syscall with cmd == LINUX_REBOOT_CMD_RESTART2 and arg == "full".
>> while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT) {
>> - rc = opal_cec_reboot();
>> +
>> + /* See if we need to do a full IPL reboot */
>> + if (cmd && strcmp(cmd, "full") == 0)
>> + rc = opal_cec_reboot2(OPAL_REBOOT_FULL_IPL, NULL);
>
> You might want to check for OPAL_UNSUPPORTED here just in case we're
> running on ancient firmware.
Good idea, will fix this in v2.
--
Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH RFC] powerpc/kernel: Don't check for dev->dma_mask in fsl_set_dma_mask
From: Christophe LEROY @ 2018-09-03 7:04 UTC (permalink / raw)
To: Darren Stevens, linuxppc-dev, Christian Zigotzky,
Julian Margetson, Scott Wood
In-Reply-To: <4c7f98c86ad.343ea8c1@auth.smtp.1and1.co.uk>
Hi,
Your patch should be sent as part of the message text and not as an
attached file.
By sending as an attached file, patchwork doesn't handle it properly
(all compilation tests fail) https://patchwork.ozlabs.org/patch/965082/
For reference, see
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text
Christophe
Le 02/09/2018 à 13:30, Darren Stevens a écrit :
> To enable use of dma to all ram on a corenet generic system, we add the
> function fsl_pci_dma_set_mask, and link it into the ppc.md structure.
>
> But this function checks for the presence of dev->dma_mask and dma_ops
> at entry, and fails if one or other are missing. Powerpc's dma_set_mask
> (which it is called from) doesn't check this until after it has set the
> dma_mask for pci devs, this difference shows up on a Cyrus (AmigaOne X5000)
> - a soundblaster live pci card, will works properly if memory is limited
> to <4G, but fail on probe with the following message if the memory is >=4G
>
> [ 4.646531] snd_emu10k1 1000:04:04.0: architecture does not support PCI
> busmaster DMA with mask 0x7fffffff
>
> Remove the dev->mask tests to make the routines behave similarly.
>
> Signed-off-by: Darren Stevens <darren@stevens-zone.net>
>
> ---
>
> This fix looks wrong to me, although it works. The test needs to be removed,
> moving it to the end of the function doesn't work either. This needs someone
> with more knowledge of what's going on to take a look.
>
^ 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